The <Gather> TwiML verb works by passing data from touch-tone key presses along to your application. When a user presses a key on their phone, the key press produces Dual-tone multi-frequency signaling (DTMF), which is the source of the familiar sounds you hear when dialing a phone. DTMF have been standardized so that they can be understood and decoded by machines.
Timeline of a key press
- The user presses a key and produces DTMF tones.
- The call passes through several carriers. One of these carriers (not always the same one) interprets the DTMF tones and translates the audio data into structured data. This structured data is then sent parallel to, but not as part of, the audio of the call.
- Twilio receives structured data indicating which key was pressed. Twilio only receives structured data and does not interpret the DTMF.
By the time we reach step 3, the audible DTMF tone will have been replaced with indistinguishable clicks where the sounds used to be, so there's no possibility that Twilio is interpreting the key presses incorrectly.
Common causes for issues with <Gather>
<?xml version="1.0" encoding="UTF-8"?>
<Gather timeout="10" numDigits="1">
<Say>Please press any key to continue.</Say>
Problems might also arise if a user presses a key too quickly for the DTMF to be interpreted.
DTMF Type Support
The <Gather> TwiML verb is only able to detect DTMF keypress inputs in the RFC 2833 / 4733 standard. This transmits the keypresses over as specific event packets - rather than sounds within the audio stream - to make keypresses easier to identify and collect, and reduce the effects of poor line or audio quality.
SIP INFO DTMF, and in-band DTMF are not supported by <Gather>. These methods may be the default DTMF setting for some VoIP phones systems. These problems can usually be resolved by altering the settings on the VoIP system itself. If a VoIP system provides multiple DTMF options, try testing each of these options to see which one works the best.
The browser based version of Google Voice has known issues with DTMF.
Any issue which causes sound to be lost or altered, such as poor reception, poor audio quality or significant background noise, can also make it difficult for carriers to distinguish between DTMF and other noise.
Very, very rarely DTMF will not be interpreted or transmitted properly by a carrier.
There is no test which can be done to definitively determine where a problem with <Gather> comes from. The best approach to take is to do everything possible to isolate the issue. Try the following:
- Use several different phones from different carriers. If the problem is occurring reliably on multiple telephones from multiple service providers, please contact Twilio support. If the issue is happening reliably, but only on phones from a particular carrier, you might want to contact that carrier directly to report the issue.
- If the issue is happening intermittently, it may be due to environmental factors or the style of use from a particular user. Try to see if there is a particular user, phone or location that experiences this issue more often.
Using Speech Recognition as DTMF backup
Speech recognition can be added to <Gather> by appending the input parameter and setting it to "dtmf speech" which will allow for users to use speech as well as DTMF input to navigate your application.
For example, in the event that DTMF input is failing, offering an option to "Say or press one to speak with Sales" will allow callers to navigate the IVR using speech even the DTMF isn't working for whatever reason.
Problems related to <Gather>
One thing which shouldn't be overlooked when troubleshooting issues with <Gather> is the possibility that <Gather> is receiving all of the digits, but that the request which Twilio is making the URL specified in <Gather action=""> isn't being handled by your application. Be sure to check that action="" is pointed to the correct location, and that that location is able to accept requests made with the method you are using.