DTMF (Dual-tone multi-frequency) is an in-band telecommunication signaling system using the voice-frequency band over telephone lines between telephone equipment, other communications devices and switching centers. The tones are decoded on the receiving end and used for practical applications such as interacting with computer systems and answering machines. The interaction with a computer system is achieved using an IVR (Interactive voice response) system.
Over a regular landline, DTMF is sent as audio signals & the tones are transmitted through the same wires that carry the voice signals. In the case of mobile phones, DTMF tones can be generated only after the connection is established.
How do we use it?
This feature is often used by call centers for gathering inputs from callers for selection of IVR menus, capturing account information for phone banking facilities and so on, however this is prone to errors such as echo or packet loss during transmission, distorting the data and making it difficult to rebuild the key press combination at the receiving end.
One of the ways our clients use the Last mile delivery solution is by triggering calls programmatically via the ExoPhone,digits# tuple (Ex: 08033013302,12345#) & often times, we see them reach out to us inquiring as to why DTMF doesn’t always get captured.
In this case, the call flow would roughly have the following applet(s) -
Gather > Connect
Note that while these call flows always start with a Gather applet, the way DTMF works and what have been our findings will hold good even for the normal IVR use-cases as well.
Here are some of our observations that we were able to capture, based on our own, internal testing -
The use of hash '#' key -
Most Android diallers don't pick it up automatically i.e. though the app/link is programmed to pass VN,digits# the dialler only gets VN,digits (without the hash)
Here, VN = Virtual Number = ExoPhone
Solution is to use %23 - Ex: VN,digits%23
The digits NOT showing up on the dialler, once the preprogrammed VN,digits# tuple is triggered
While we’re unsure if this is device specific or Android version specific, what was noticed was that when they clicked on the VN,digits# tuple, only the ExoPhones showed up on their diallers (Ex: Lenovo Vibe P1m, Motorola G3 etc.)
In some Android devices, the DTMF input tone is not “heard” after the tuple is triggered
Practically speaking, user interprets this as a gap in the process where 'nothing is happening' (given that there is no noise from when the tuple is triggered to the time the DTMF input fully finishes) and either disconnects or tries typing in the digits themselves
Toggling dial pad tone on/off can affect the way DTMF inputs are captured
Unfortunately, there's is no straightforward way to know exactly how each and every device brand, make/model would behave if the dial pad tone were not switched on, as we did identify instances where even when dial pad tone were switched-off, DTMF inputs were captured and cases, where they weren't
Toggling 'mute' option during the call run can impact the way DTMF inputs get captured
Behaviour to differ when the VN,digits# tuple is triggered and loudspeaker is enabled/disabled, whilst toggling mute option
Noise cancellation that's handled by a device can have an impact on how / what DTMF inputs are passed from device to operator and from operator to our platform
We recommend using a shorter extension (3 or 4 digits) as opposed to longer ones (7 to 10 or more) given that the deviation that we’ve observed after crunching our survey results are as follows -
3 to 4 digits: ~3-5% discrepancy with DTMF capture
9 to 10 digits: ~13-15% discrepancy with DTMF capture
DTMF issues exist in all the networks where there is an intermixing of IP network and pure PSTN (Public switched telephone network) network. In India, most of the calls use both networks, hence issues with DTMF capture might be more. Currently, some of the calls from our primary operator take routes through NGN (Next-generation Network) which is IP based and they may be able to minimize DTMF issues by changing the route to a complete TDMA (Time-division multiple access) network.
We’re working with our operators too to ensure they’re doing everything they can to mitigate this but this is a work in continuity.
While there isn’t a permanent solution to fix all of DTMF constraints given that there are multiple point of failures (viz. operator, handset as well as platform), do please write to us at firstname.lastname@example.org with your inquiries on this, so we may help explore alternatives based on your use-case.