International VoIP providers, DTMF, broken SIP implementations (and more!)

June 29, 2020

(I started writing this at the beginning of May 2020, and probably finalizing near July; so yeah be warned.)

Ever since I released my writeup about the (in)security of Türk Telekom's home gateway management, the VoIP config I found stuck in my head.

This led to many attempts to create a large home phone system. I failed hard. However in the process of doing that, I learned how cursed SIP services are and even got a free Cisco IP Phone from an ISP contact.

SIP Trunking not working with...correct data?

SIP servers/gateways never completely follow the actual standards guiding the protocol.

For example; Türk Telekom's “SIP server” is actually an IMS (IP Multimedia Subsystem) gateway from ZTE and sends incoming calls with the tel: URI instead of the usual sip: URI.

Asterisk doesn't support tel: URIs at all. Kamailio kinda does, but breaks very often due to the VoIP config I mentioned above. 3CX worked at the time I tested (around mid 2019), however I really don't like commercial “licensing” of products utilizing SIP.

FreeSWITCH from SignalWire on the other hand... It. just. works.™️ It has its own quirks as well, but I'll go into that a bit later.

There are many issues other than this too, however this is just the beginning of many problems a PBX trunk operator can face.

Let's talk about DTMF. But not its analog perspective of it but rather how its (mis)implemented on the digital world.

Today, we have a few different DTMF signaling methods. All comes down to two types.

Inband
Out-of-band

Inband is still in-call tone-generation. However some implementations do it slightly different than others (ie. event “packets” in the RTP stream (see RFC 4733 and the deprecated RFC 2833)).

Out-of-band is literally done out of RTP. You either send the tone “map” via a SIP INFO or SIP NOTIFY message. In larger telco operations, SS6 and/or SS7 are utilized. (also see RFC 4733 and the deprecated RFC 2833 because somehow both of these contain descriptions for both types????)

On today's VoIP providers, none of them fully detail what method (and how) they support. And that's where the fun starts.

Twilio supports both inband and OOB signaling (as its defined in RFC 2833) however if you do SIP trunking, make sure that you use OOB because most of the time their “inband” doesn't seem to work.

NetGSM, a large Turkish VoIP provider (along with almost all Turkish VoIP providers) supports the good ol' inband only. So if your trunk has a global setting for DTMF, now its time to do this for each trunk.

If you double trunk and have a Cisco phone connected, well good luck.

“OH MY GOD WHAT IS THIS CONFIGURATION”

Well, welcome to the wonderful hell of PBX configuration. Unless you have a polished frontend like FreePBX (which utilizes Asterisk) etc. you need to mess with files. A crap ton of them.

Asterisk is by far the easiest, if you use the legacy dialplan and peer configurations.

FreeSWITCH however, consists of hundreds of XML files interconnected with each other in such way that one variable in one file eventually gets overridden by another file. If you don't check your configuration at least 100 times, you'll probably realize that you have RTP Early Media off and Mixed RTP Codec Negotiation disabled.

Faxing the Fax machine never works as expected

This is a short rant about FreeSWITCH's SpanDSP module. For no certain reason, it only does T.30/38 and both are broken in some ways. I just gave up trying to get it working.

Just LEAVE IT

Yeah, once you set up your trunks and get it to work, never ever look back to it. At least that's what I've done.

For now.

linuxgemini's space of text