DTMF or Dual Tone Multi-Frequency is the name for the beep beep tones your phone makes to place calls and to navigate IVRs. This means that when someone calls in to inContact, and navigates an inContact IVR, inContact has to have a way to ‘hear’ or know what digits were dialed. So lets talk about how inContact knows what digits you are dialing when you navigate an IVR.
There are two systems or methods by which inContact is fed DTMF digit information. We refer to our telecom soft-switch as the Enhanced Switched Network or ESN. The ESN employs both traditional TDM based telecom circuits (DS1 and DS3) and SIP based VOIP connections to send and receive calls from and to our carriers and the outside world. When a call enters our ESN via a traditional telecom DS3, we use an industry accepted gateway that converts that call from TDM to VOIP and delivers it to inContact. Besides converting the TDM call to VOIP it also listens for DTMF digits and whenever a DTMF digit is detected by the DSPs in the gateway a message is sent to inContact that indicates what digit was pressed. When a call is delivered via SIP to the ESN and then to inContact, the SIP or VOIP vendor provides the intelligence and it is the SIP vendor’s gateway that detects the DTMF digits and sends what is called an RFC2833 packet to inContact along with the audio that indicates which digit was pressed.
In both cases, inContact does not really ‘hear’ DTMF digits, it is TOLD what digits were dialed by these industry standard gateways. So when someone tells me that ‘inContact does not hear their digits’, I explain that the problem is probably not with inContact but lies somewhere else because inContact does not ‘HEAR’ digits, it is ‘TOLD’ what digits were dialed and that if we did in fact have a gateway or a carrier that was not processing DTMF digits properly, it would not just be their calls, but thousands of other calls as well because all the calls are using the same network and network gateways. Usually the problem is either related to the callers phone, or some error in the scripting, or some other odd element that is unique to their call flow. Finding that odd element is the trick, but we have a host of skilled analysts that can trap and dissect calls to resolve problems. What is key to tracking down DTMF problems is being able to duplicate the problem. So if you encounter issues with sending or receiving DTMF digits, be sure to document a reliable way to test and replicate the problem and open a ticket with our NOC. They will be able to engage the necessary tools and people to track this down and get your call flow working.
I wonder if Bell Labs knew that when they began developing DTMF and tone dialing in the 1940s that a little droid in a galaxy far far away, named R2D2 would still be using little tones just like that to defeat the Death Star.