DTMF in the wrong order (English)

Here’s an interesting item I’ve come across at work which took me several weeks to figure out. Thought I’d like to share this issue and the possible reason why it’s happening and a workaround for it.

To give you an idea about the situation; this customer wants to call services where you have to enter a long code (usually 10 digits) using DTMF. It’s kind of important that the order of DTMF is correct and that’s where he got into trouble.

If he used one particular provider for this outgoing phonecall, the order of DTMF changed into random order digits after usually 4 or 5 correct ones. So, he sent 1234567890 to the service using his phone (DTMF) and the service received 1234598076 (or anything like that).

I tested this using several other trunk-providers and not a single one had this issue. So, my logical answer to the customer was that the trunk provider had the issue. We also tried different DTMF types, but only RFC2833 was working, so this was ruled out and there was nothing more we could change for DTMF within Asterisk.

But, after 2 weeks we received the support-ticket back. The provider did some testing and even though they told us the DTMF was in correct order received and forwarded, they just bounced the ticket back to us claiming ‘it is a timing issue’. Despite the fact we had at least 9 different trunkproviders without any issue, it became our problem again and we had to fix it for the customer.

The first tests were the easy things like checking our NTP-synchronisation (timing issue could imply we were out-of-sync), but no luck here.

Then we removed Asterisk from the system (as in, callrecording and forwarding of calls) and that seemed to fix the issue, but as expected the customer actually wants callrecording and callforwarding so there’s no way we could disable this.

Oddly enough, a (Centos) FreePBX install worked and exactly the same Asterisk version on Debian was also working just fine, even if it was on very slow hardware. For a day or two it looked like it was a Asterisk speed issue, though it wouldn’t explain why it ran on a slow machine with Debian just fine.

After much debugging, reading TCPdumps and reading VERBOSE messages from Asterisk, I saw on my slow Debian machine that the Asterisk Dial-line included the “A” options to stream 42ms of silence to the other party to make sure the RTP-port opens in case of a NAT-ed machine. On the Debian machine, this file was missing. On the FreePBX machine, this file was missing as well. On the system with the DTMF-issue, the file existed.

As soon as I removed the 42ms of audio, the DTMF-problems were gone. So, why not remove the 42ms of silence right? Well, we can if all our PBX-machines are without NAT and since IPv6 is still not common (Common phones don’t support IPv6, so why bother to use it in Asterisk right?). Removing the file and executing a blind-transfer between 2 SIP-peers means the router doesn’t get where the RTP is coming from (or going to) meaning no audio. We did found a workaround for that by setting the “progressinband” to “yes” in the sip.conf, creating other problems like doing a transfer between 2 different trunks (and RTP-servers).

Back to the original problem, we now have this ‘workaround’ by removing the 42ms of silence and setting the progressinband to yes, but it’s not something I would recommend using on systems with multiple trunks.

So, why is this trunk-provider the only one with DTMF problems in the first place. Well, I think I know why. DTMF is RTP-Type 101 while G711alaw is RTP-Type 08. My guess is that this trunk provider doesn’t understand the RTP-Type 08 while it is receiving RTP-type 101. Oddly enough, Asterisk seems to send pieces of audio right after the DTMF codes. I still don’t know why or what this exactly is (perhaps the 42ms audio?). Anyway, if you calculate the both RTP-types and consider it as one, the DTMF could be considered as late while another DTMF is already sent. Meaning, the order will change on the other side of this trunk-provider. My other possible idea is that the provider somehow expects an inband DTMF because of the RTP-type 08 right after the 101. I don’t know since I can’t login to their configuration.

For my rare readers, I’d like to see your opinion on this.

The Big VoIP Post

As self proclaimed VoIP-expert (and so does my boss say) I decided to create this blog post. English is not my normal language, already my apologies for the mistakes! Let me know if you find one 😉

The reason of this blog is partly because of my job. As already said, I’m a self proclaimed VoIP-expert and I’m lucky my boss also thinks like that. Because of this, I get all phone calls from customers who have problems with VoIP. Also I’m testing small PBX devices so I can give a fair shot of what the pro and cons are. I hope you enjoy the read. If you disagree, well.. let me know and even better, tell me why you disagree. Perhaps this will be updated!

VoIP in general

First of all, VoIP is really not that hard. The biggest difference between old school telephones and VoIP is basically the network. You probably think now, that’s pretty obvious and it is. Lot of customers don’t know this and there’s the first problem. While plain old telephones working with 2-wires, are the 2 wires replaces by UDP traffic over IP when using the standard VoIP. The customers telephone system has to convert that digital data into analog data which a phone will understand. The audio will be packed into small packets (UDP) and transported over the Internet. As you can imagine now, the packets had to come in the telephone system with a good stream and preferable directly behind each other. Back to the customer who doesn’t know that VoIP is traveling on network and thru routers. These people go to the local computer shop and buy the most cheap router there is. Result is a very bad VoIP connection (caused by this cheap router who cannot handle the traffic well) and the provider gets the blame. It’s the same as buying a huge and beautiful caravan while having a T-Ford pulling the thing. So, my first advice:
Use a decent router if you want to use VoIP!

In my tests, I’ll be using a Asterisk 1.4-based trunk which is directly connected to the Internet. It supports DDI and T.38 thru G711.alaw. Also support for G711.ulaw and G729, but these don’t work with T.38.

If you’re not aware what DDI and T.38 are, it’s probably better to read some wikipedia articles about this. 😉

Telephone systems / PBX

Hardware solutions using old telephone systems

The first systems I tested with were the default PBX systems which were originally older phone systems and with some added hardware they become suitable for VoIP. These systems are usually set up by old phone-expert with almost no knowledge of networking. Most common are Siemens, Panasonic, Alcatel and probably some more.

The problem is that these systems usually aren’t capable of firewalling. So, they put a cheap ass router before it and suddenly they have one-way audio, cracking sound and much other inexplainable problems. At one of the customers I found a Netgear firewall. Great systems, but terrible in VoIP transporting. Especially when a PBX uses 2 IP addresses to do VoIP (control IP and the UDP Stream IP). The Netgears SIP Helper cannot handle this. Panasonic PBX is known to do this. Ask your local PBX supplier how your system works and if it uses only one IP address, use the SIP helper. It will prevent problems!

All the above systems work good with a decent router in front of it. Put a nice Cisco there and it works. DDI has to be on for all named systems, else they simply refuse to work. T.38 is also working like a charm.

For old hardware VoIP/PBX solutions (Panasonic, Siemens, Alcatel):
Pro:

  • It works when good configured
  • T.38 Support and DDI Support are perfect.

Cons:

  • Pretty expensive
  • No sense of security, so external firewall is needed
  • Trunk providers has to pay to get support from the maker.

Software Solutions

There are a plenty of software solutions. I can’t test them all because there are simply too much. I like the software solution the best because the whole networking/firewalling part could be done by the operating system. Some of them are even free (like Asterisk) and really work like a charm in basically anything. Also some of them (Swyxware) have huge problems with T.38 (Swyx only supports G771ulaw for T.38 which doesn’t work everywhere). Some software tools cannot use DDI (XLite) and depending on which software you choose, it will only support one line (again X-lite).

Pro:

  • Networking/security done by operating system
  • Support of T.38/DDI/Codecs depend on software
  • Can be free.

Cons:

  • Can be relatively expensive.
  • Not always decent support.
  • Not all software

Home office all-in-1 devices

In this category I only have 2 tested. Both devices are basically doing the same.

– FritzBox 7120 –

The all known Fritzbox. Beautiful device which does routing, firewalling, ADSL / Dialup and being a (wireless) switch. Also T.38 fax works perfectly and with the good working Fax2Email functionality it will save a few trees as well. There is only one major Con on this device, there is and there never will be DDI support. So, you can not make it a real PBX in an office environment (unless all phones can ring at the same time).

– Draytek IPPBX 2820n –

This can do exactly the same as the FritzBox with 2 differences. DDI is working perfectly (even with menu’s, call forwarding based on phone number and/or office hours). So, I thought I found a winner. With the latest firmware release they say to support T.38 and that’s the other difference. T.38 doesn’t work. Again, a big con. Voicemail to Email works nice and even fallback to PSTN works. Really a device which can make it in the VoIP world as cheap device

– Gigaset 800 series –

Gigaset is a bit odd one here. It’s not an all-in-one device but only a PBX. In the background it runs Linux and Asterisk. Gigaset only created a nice interface with Asterisk and ask a lot of money for it. Because it runs on Asterisk, everything works. So, nothing more to add except I think it’s too expensive.

VoIP to PSTN/ISDN

Only a few tested and these simply work. T.38 support is questionable. So far, only a Linksys is tested and that one worked.

VoIP Phones

Well, generally these work with DDI and not with T.38. One exception, the Gigaset. This one is not supporting DDI at the moment.

What I hope to reach with this blog

Well, I hope that some vendors will make their VoIP products better. I also hope that all people who are thinking of starting to use VoIP, also think about how the VoIP device (or devices) will be connected to the network. Use a decent router. The router is 80% responsible of how you’ll experience the quality of VoIP! Remember that!

If you have any questions, feel free to respond below. I’d love to see comments and hopefully I made some things clear.