DTMF (Dual-tone multi-frequency signalling) uses voice frequency which is transmitted over telephone lines for capturing digits upon key press. Such tones are passed from the handset across one or more intermediate operator lines, before it finally reaches Exotel.
DTMF can be sent across phone networks in multiple ways, one is “In-Band Signalling”, where the DTMF tones are played in the audio channel of the call; whereas in the case of “Out-of-Band signalling”, the tones are sent in a separate signalling channel.
Scenarios: What can go wrong in DTMF capture-
Digits are not captured at all even after key presses from the users of a specific handset. For example - User presses 1, but no digits are captured.
Duplicate digits appear in a few cases. For example - User presses ‘12345’, but digits captured are ‘123455’
Few digits are missing. For example - User presses ‘12345’, but digits captured are like ‘1345’
Digits are recognised wrongly. For example, user presses ‘12345’, but digits captured appear like ‘22345’. In rarest of rare cases, alphabet (A, B, C, D) can also appear instead of digits as they are part of the DTMF tones.
Possible reasons why DTMF is not captured correctly:
Handset Issues: The handset is not sending the DTMF tones correctly over the telephony lines. This could be because of the settings in the handset, manufacturing defect, speaker/earphone mode etc.
Carrier Issues: One or more carriers involved during the transmission of DTMF tones fail to transmit it properly (This could be due to combination of handset, operators, location/cell towers involved).
Environmental Factors: Any factor which can cause sound (DTMF tone) to be altered or lost, such as background noise, poor reception, poor audio quality etc. can make it difficult to distinguish the DTMF tones, or can also lead to duplicate tones being detected (if a noise chops a single DTMF sound into two parts).
User Behaviour: Problems might arise if a user provides DTMF key inputs in mute or speaker mode. It may also be because user presses the keys too quickly for the DTMF to be interpreted.
Few other observations with regard to DTMF capture
The use of hash '#' key -
Most Android diallers don't pick it up automatically i.e. although 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 instead of # in your application/link. Ex: VN,digits%23
The digits NOT showing up on the dialler, once the preprogrammed VN,digits# tuple is triggered
This could be device specific or Android version specific issue. It is observed that when the user clicks on the VN,digits# tuple, only the ExoPhone showed up on their dialler screen. (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 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 was switched-off, DTMF inputs were captured and in 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.
DTMF issues can be more prominent in 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.
Actions to take if an issue is observed
We suggest that if the issue is happening continuously, but only on particular phones from a particular carrier, you might want to contact that carrier or the handset manufacturer directly to report the issue. If the issue is happening intermittently, it may be due to environmental factors or any other intermittent occurrence of reasons mentioned above.
For troubleshooting, there is no single test that can be done to definitively determine where a problem with DTMF comes from. The best approach to take is to perform various scenarios possible to isolate the issue. For cases where such issue is occurring repeatedly for specific users, tests can be conducted which require the end users to try the same SIM card on a different handset and/or try a different SIM card (or carrier) on the same handset. This will help isolate if the issue is with the handset or the SIM provider (carrier).
You can also attempt to make calls to capture DTMF digits using an alternate region’s ExoPhone to isolate if it’s occurring across different network combinations.
You can configure your handset settings to enable DTMF tones, try different modes (speaker, normal, earphones), turn off mute if enabled etc.
While there isn’t a permanent solution to fix all of DTMF constraints given that there are different possible reasons (viz. noise, user, handset, operators), do write to us at firstname.lastname@example.org with your inquiries on this, specifically if you are observing such issues continuously across multiple handsets. We can also assist you to explore alternate solution based on your use-case.
Best Practice: 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 are higher in case of longer extensions. Also, probability of anomaly occurring in the input increases as the number of DTMF input increase.
NOTE: Please make sure your application endpoint is capturing “digits” parameter correctly while using the IVR or the gather applet. If you are using passthru, it should be placed immediately after ‘Gather’ applet.