I'm hoping people can suggest some ideas for debugging a problem that I'm having with DTMF.<br><br>Unlike most of the DTMF problems reported here, it has nothing to do with Asterisk interpreting DTMF. My problem is with the synthesis of DTMF tones on outbound calls on a PRI connected to a TE412P card.
<br><br>I'm running * <a href="http://1.4.10.1">1.4.10.1</a> with Zaptel 1.4.4. It is important to note that these problems never occurred when we were using 1.2. They started immediately after upgrading to 1.4 (1.4.4
and <a href="http://1.4.2.1">1.4.2.1</a> at the time IIRC)<br><br>The original problem people would report is that they have problems using IVRs that they call over the PSTN. Duplicated digits, missed digits, etc. I've tried to replicate the problem using various user agents (Polycom 430, Grandstream GXP2000, Linksys SPA942, eyeBeam, etc.) and have observed the problem. It's not consistent, but that's probably due to the inconsistency of user input. If you concentrate very carefully and hit the keys for a consistent period of time with consistent spacing, the problem doesn't seem to happen. I also found that when the user agent was directed into DISA() and then dialed the IVR from within that application, they didn't have problems with their DTMF being recognized.
<br><br>In an attempt to quantify the problem, I set up the following test harness, sending calls out of Asterisk into an ITSP system. The final termination of the call is a different Asterisk box from the one that generated the call, though running the same version. DTMF from the ITSP to the second Asterisk system is SIP INFO.
<br><br>Asterisk -> PRI (TE412P) -> PSTN -> ITSP -> Asterisk<br clear="all"><br>I generated calls that executed SendDTMF(). On the other Asterisk system, I used Read() to capture the DTMF and stick it in a database. I did 1250 calls (250 to each of the 4 PRIs connected to the TE412P and 250 without regard to the PRI used). Across all of those calls, I didn't see one missed or doubled-up digit.
<br><br>I then did some manual tests where I placed calls from the Polycom 430 to the same application (basically putting myself in place of SendDTMF). Immediately I saw doubled up an missed digits. I turned on DTMF debugging on the second Asterisk box, and doubled-up digits always seem to take this form:
<br><br>[Aug 17 10:50:05] DTMF[25160] channel.c: DTMF begin emulation of '4' with duration 90 queued on SIP/5060-08da0d70<br>[Aug 17 10:50:05] DTMF[25160] channel.c: DTMF end emulation of '4' queued on SIP/5060-08da0d70
<br>[Aug 17 10:50:05] DTMF[25160] channel.c: DTMF end '4' received on SIP/5060-08da0d70, duration 70 ms<br>[Aug 17 10:50:05] DTMF[25160] channel.c: DTMF begin emulation of '4' with duration 80 queued on SIP/5060-08da0d70
<br>[Aug 17 10:50:05] DTMF[25160] channel.c: DTMF end emulation of '4' queued on SIP/5060-08da0d70<br>[Aug 17 10:50:05] DTMF[25160] channel.c: DTMF end '4' received on SIP/5060-08da0d70, duration 50 ms<br>
[Aug 17 10:50:05] DTMF[25160] channel.c: DTMF begin emulation of '4' with duration 80 queued on SIP/5060-08da0d70<br>[Aug 17 10:50:05] DTMF[25160] channel.c: DTMF end emulation of '4' queued on SIP/5060-08da0d70
<br><br>That's a single keypress. As I understand it, synthesized DTMF tones should consistently have a duration of 100 ms, and indeed most of what shows up in the DTMF log does have that duration (or something close to it):
<br><br>[Aug 17 10:49:55] DTMF[25160] channel.c: DTMF end '1' received on SIP/5060-08da0d70, duration 100 ms<br>[Aug 17 10:49:55] DTMF[25160] channel.c: DTMF begin emulation of '1' with duration 100 queued on SIP/5060-08da0d70
<br>[Aug 17 10:49:55] DTMF[25160] channel.c: DTMF end emulation of '1' queued on SIP/5060-08da0d70<br>[Aug 17 10:49:57] DTMF[25160] channel.c: DTMF end '2' received on SIP/5060-08da0d70, duration 100 ms<br>
[Aug 17 10:49:57] DTMF[25160] channel.c: DTMF begin emulation of '2' with duration 100 queued on SIP/5060-08da0d70<br>[Aug 17 10:49:57] DTMF[25160] channel.c: DTMF end emulation of '2' queued on SIP/5060-08da0d70
<br>[Aug 17 10:49:58] DTMF[25160] channel.c: DTMF end '3' received on SIP/5060-08da0d70, duration 110 ms<br>[Aug 17 10:49:58] DTMF[25160] channel.c: DTMF begin emulation of '3' with duration 110 queued on SIP/5060-08da0d70
<br>[Aug 17 10:49:58] DTMF[25160] channel.c: DTMF end emulation of '3' queued on SIP/5060-08da0d70<br>[Aug 17 10:50:00] DTMF[25160] channel.c: DTMF end '4' received on SIP/5060-08da0d70, duration 100 ms<br>
[Aug 17 10:50:00] DTMF[25160] channel.c: DTMF begin emulation of '4' with duration 100 queued on SIP/5060-08da0d70<br>[Aug 17 10:50:01] DTMF[25160] channel.c: DTMF end emulation of '4' queued on SIP/5060-08da0d70
<br>[Aug 17 10:50:02] DTMF[25160] channel.c: DTMF end '4' received on SIP/5060-08da0d70, duration 100 ms<br><br>Yet from time to time, the ITSP "hears" that supposed 100ms tone as two tones of 70 and 50ms, or 90 and 40, or some combination that makes it appear to be a doubled-up digit.
<br><br>I'd be tempted to say that the problem is whatever part of the ITSP that is interpreting the DTMF coming in from the PSTN, but the IVRs that my users complain about are operated by tons of different companies. I have trouble dialing extensions on a 10 year old Meridian system; someone else can't use Audible's account management IVR; another user can't get WestJet to work, etc.
<br><br>What evidence I've collected seems to suggest two things:<br><br>- there is a difference between DTMF that is generated inside of Asterisk (such as is the case for SendDTMF and digits picked up inside of DISA and then regenerated on another call leg) and DTMF received from a connected user agent (SIP INFO or RFC2833)
<br><br>- the audio of tones that the TE412P (or Asterisk; not sure exactly where the tone generation is happening or if this is PRI specific) are not consistent enough for many other systems to interpret correctly.<br><br>
Can anyone suggest what I should do next? Changes to testing methodology, data collection, etc. I'm pretty much open to anything that doesn't require me to take the system with the TE412P down or restart it (or rather; I can do that only overnight, so several such changes and testing have to play out over several days)
<br><br>Much appreciated.<br><br>-- <br>j.