Baresip – An Open Source modular SIP User-Agent with audio and video support
github.com
github.com
Is there such thing as a SIP to mobile phone bridge, so that you can make phone calls over the net via a mobile phone that is in some remote location?
The application in my case is making local calls in a country that is expensive to call into. If it exists its the kind of thing that is resistant to search, unless it's called something I'm not aware of.
Edit: I think I might be looking for a SIP GSM Gateway running on an Android phone
To clarify I'm looking for:
initiate voip handset call => internet => call is initiated from remote mobile phone
remote mobile phone receives call => internet => voip handset rings
Or put another way something that exposes the Android phone as a trunk line.
It is one of those slow burn projects I work on every couple of months. mainly because I hate doing anything on the phone. but the idea is I have an asterisk server at the office that ties into the dialed phone world via sip trunk. I should be able to put a sip client on the phone, tunnel a secure connection to the office then the cell phone is just another office phone... anywhere in the world.
Only piece left is the tunnel, I have my heart set on ipsec. is this folly? should I be looking into other tunnel tech?
Getting just plain SIP and RTP through consumer, enterprise, and cell carrier nets can be troublesome. For example, SIP especially is NAT-antagonistic, and edge routers can try to be "helpful" and do half-baked proxying or deep packet mangling that just messes up your smarter VoIP server. Consumer ISPs have a tendency to block SIP altogether. Throwing in encryption complications may give you another layer of hard-to-diagnose headaches. (Of course, if you can get the secure layer through the net it might force intermediaries to keep their fingers out. Other tricks like using non-standard ports can help with that, too.)
Source: used to run the signalling/media dev team for a VoIP provder many moons ago, but we didn't bother with the secure modes/protocols.
[1] https://en.wikipedia.org/wiki/Session_Initiation_Protocol#En...
[2] https://en.wikipedia.org/wiki/Secure_Real-time_Transport_Pro...
Sadly Google dumped that support out in Android 12 so I'm still using an old lineageOS phone for this reason.
But baresip is unusable for voice on the same phone that runs built in SIP just fine.
SIP is the control channel and you use it to login to the server (once registered calls to a number will be sent to your program) and control both sending and receiving calls. The actual audio protocol is RTP, typically 20ms of audio is sent or received per RTP packet.
If you've got VoIP service for a landline, it's probably SIP. I think VoLTE might be SIP too? There's extensions for text messaging over SIP as well.
UMTS an similar 2G and 3G protocols could do neat things like have multiple towers compare the signals received from your phone to enable more reliable calling, but this functionality did not survive to make it into cellular's LTE or 5G New Radio (NR) standards.
The whole PBX was running on SIP using Asterisk.
I have had the free 3CX sip client on an android mobile, using a UDP vpn back to a freeswitch server which was connected to the UK phone system. Proof of concept thing.
Because of the nature of the mobile data, which is like bursts of data, it made it hard to have a conversation even around midnight and 1am when cell traffic volumes are low.
I was told UK Telco's give voice data priority as this needs to be realtime and then other data has lower levels of priority making it hard to have a reliable stream of data.
FYI, 56K is the minimum standard for voice calls, although with 4G and beyond, its possible to hear the higher bitrate protocols being used on the main mobile networks, as its not so muffled, like someone turning up the high end frequency's on a graphic equaliser, and they are fully down with the 56k protocols.
I dont know what the minimum video protocol bitrate would be, but I did find this which might be useful. > H.264 will only consume around 10 kbps with around 2 fps in 176x144.
When Skype first came out, it was peer to peer, so as a proof of concept to test the new 3G network I did manage to maintain a voice call for an hour which was impressive, but also shows that mobile networks can maintain the mobile data streams if its not encrypted inside a VPN in the UK.
I don't think any of the US networks do that, unless you want to set up your own phone operator :(
https://www.t-mobile.com/support/plans-features/t-mobile-vid...
I don't think it still works, and/or it requires some strange confluence of events to work.
I developed 3G video phone dating in 2010.
I recall bambuser also used to have a live video streaming over 3G app around that time.
As for the complications... Yeah.
The folks who invented VoIP had a dream. They saw the existing extremely centralized, extremely locked-down phone carriers as The Enemy. Instead, they envisioned a loose decentralized federation of peers who directly contacted one another over the Internet to make calls.
Since there weren't supposed to be any all-knowing, all-powerful, all-standard-enforcing choke points, everything had to be negotiated and a consensus built up across the interconnected parts as to the call state and control. Worse, intermediate services (proxies) were allowed to be stateless. So the consensus has to be continually reinforced during and after the call.
Another design choice was to split functionality into lots of optional tiny pieces. "SIP" has a bazillion RFCs (standards specs), and some pretty byzantine control flows to implement all the interconnections. (To be fair, The Enemy is just as bad or worse. Both camps were dealing with extremely limited computing power and bandwidth in the distant past, plus incremental feature enhancement.)
My poster child is "call parking". This allows you to "park" a call from one phone by putting it on hold, and then picking it on another. The suggested SIP call from (don't remember which RFC it's part of) involves specialized "parking services"; all these do is receive a call and then later forward it. The minimal flow diagram has dozens of distinct steps involving half-a-dozen players.
SIP was a standard, not proprietary, and "good enough", so became the overwhelming standard for interconnecton of VoIP players. In reality, the vast majority of conrol flows are:
1. Phone says "hey central server, here's a phone number. Call them."
2. Central server says "Hey phone, here's an incoming call."
3. Phone says: "OK, I'll answer".
4. Phone to server: "Hang up".
5. Server to phone: "Hang up".
6. Phone: "Here's some random buttons my user pushed mid-call." (This includes digits for IVR menu trees, and on/off hold).
Audio almost always uses one of three or four popular encoding choices: 1) "Dead stupid" (G.711), 2) "Bad compression" (G.729), 3) "Oooh! Hifi!" (G.722), 4) "Something open, decent, and from the current century" (Opus). Video is usually H.263 or one of its relatives.
This seems to be exactly what I need!
Now, why did you have to write it in pure C?!? It's not a big deal for me, my VoIP devices are already in a separate VLAN without external access, but still.
I say that as someone who's been writing C for decades, and still does very regularly.
(sarcasm)
I hate X11 and C as much as any other human, but let's be real:
- If your hardware can decode video, it can probably deal with X11
- As you noted, security is easy if you never have to communicate with malicious devices. Don't "but still" me.
Ideally, I would use something like HomeAssistant Operating System for the base, with my code running in a Docker container.
> I want to have as few dependencies as possible, and for the code to work with minimal to no changes for the next 10 years.
Then a C program sounds like an ideal choice!
VLAN is what makes it not such a big deal. However, I want to offer the same solution to other people in our HOA, and I most definitely don't want to set up VLANs for each one of them.
> Then a C program sounds like an ideal choice!
Not really? No package management, for one thing.
I would personally try to hook into one of the many other apps I have in my phone that support video calling, but SIP shouldn't require an app if your carrier supports ViLTE.