Troubleshooting DTMF

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 the user presses 1, but no digits are captured duplicate digits appear in a few cases for example the user presses ‘12345’, but the digits captured are ‘123455’ a few digits are missing for example the user presses ‘12345’, but the digits captured are like ‘1345’ digits are recognized wrongly for example, the user presses ‘12345’, but the digits captured appear like ‘22345’ in the rarest of rare cases, the 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 a combination of the 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 the user presses the keys too quickly for the dtmf to be interpreted few other observations with regard to dtmf capture the use of the 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 the 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, the 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 the dial pad tone was switched off, dtmf inputs were captured and in cases where they weren't toggling the '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 a 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 the 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 an 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 hello\@exotel in with your inquiries on this, specifically, if you are observing such issues continuously across multiple handsets we can also assist you to explore alternate solutions 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 is higher in the case of long extensions also, the probability of anomaly occurring in the input increases as the number of dtmf inputs increases note please make sure your application endpoint is capturing the “digits” parameter correctly while using the ivr or the gather applet if you are using passthru, it should be placed immediately after the ‘gather’ applet