Summary:ASTERISK-14750: [patch] dtmf creating double digits if received out of order
Reporter:Erik Smith (eeman)Labels:
Date Opened:2009-09-01 20:17:16Date Closed:2010-06-30 12:36:02
Versions:Frequency of
Environment:Attachments:( 0) 15811.diff
( 1) customer.pcap
Description:Have an Adtran TotalAccess 916e with MLPPP bonded t1's registering with sip to an asterisk PBX (Asterisk on centos 5.2). Sip channels set up for dtmfmode RFC2833 and codec is g729. The devices calling through the adtran are unable to send DTMF correctly to remove IVR's or even to applications on the Asterisk PBX 99% of the time. I created a ticket and capture with Adtran and their response was that perhaps asterisk cannot handle out of order DTMF packets. Their response is in additional information.


Thanks for getting us the capture and debug output. As we discussed over the phone, I believe I see the issue. It looks like main issue is that the Asterisk is not properly detecting out of order RTP packets or the marker field. The best way to see the problem is to take the DSP capture and filter it with "rtpevent". The first "1" comes through fine, but you can see the second number, a "0", is out of order. Essentially, a number duration event comes in after the first of three end-of-event messages. The standard says to send three end-of-event messages in case one or two of the UDP datagrams are lost.

Below is my comparison of packet number to RTP sequence number.

1548 - 7942
1551 - 7943
1554 - 7944
1557 - 7946 // this is the out of order end of event
1558 - 7945 // this is where the Asterisk likely improperly plays the digit again
1560 - 7947 // end of event
1562 - 7948 // end of event

There are really two reasons why this shouldn't play a second digit. First, packet 1558 doesn't have its marker bit set to true to indicate the beginning of a digit. Second, it should be able to track the RTP sequence number. You may want to see if an Asterisk patch fixes this issue. Feel free to respond to this email if you have any questions.
Comments:By: Erik Smith (eeman) 2009-09-01 20:20:01

close 0015741, noone would update product version on that ticket. This bug exists in most recent stable version of the 1.4 branch.

By: Erik Smith (eeman) 2010-02-24 10:18:02.000-0600

any movement on this?

By: Mark Michelson (mmichelson) 2010-03-11 15:36:24.000-0600

Just commenting to say that this issue has been assigned to me now and so I am looking into getting a fix. When I have a patch prepared, I'll be sure to post it.

By: Mark Michelson (mmichelson) 2010-03-11 15:53:07.000-0600

Looking at both the Adtran comment plus Asterisk's RTP code, my initial inclination is that they are correct.

By: Mark Michelson (mmichelson) 2010-03-11 18:33:36.000-0600

I have uploaded a file called 15811.diff as a naive approach to solving the issue.

When we receive a begin/continuation RFC 2833 DTMF digit, we will not process the frame if the sequence number is less than the sequence number of the last RFC 2833 frame we received.

The reason I have termed this as a "naive" approach is that there are a few nuances of the RFC 2833 code that don't exactly make sense to me (and they may in fact be errors in the code). However, when I ran the RTP from the customer.pcap file through Asterisk after applying the patch, the DTMF appeared to be detected correctly.

The patch, by the way, was generated against Asterisk, the version reported on the issue. However, the patch should apply equally well to later versions of 1.4 as well, in case you have upgraded to a newer version since reporting this.

Please let me know if this works for you, and I will move the issue to the code review stage.

By: Erik Smith (eeman) 2010-03-12 05:56:32.000-0600

patch applied, will try and get this tested today. Requires re-enabling the fragment/interleave and then having the customer call out to remove ivr's.

By: Erik Smith (eeman) 2010-03-12 06:49:47.000-0600

2nd time i've typed r e m o t e and its been auto-corrected to 'remove'.. thats kinda odd

By: Erik Smith (eeman) 2010-03-12 20:44:43.000-0600

well customer says the no longer have problems contacting the physician's paging system when we asked them to test. Before, when interleaved, they could never page the doctors when calling up a service. We've left the customer on fragmentation/interleave throughout the day without issue. I'm leaving the customer this way until they report an issue. Hopefully this fixed it. Given the nature of the fix, it might also fix it so that I don't have to dial dtmf slowly on an ip handset to make sure it works.

By: Mark Michelson (mmichelson) 2010-03-18 10:49:00

Just thought I'd let you know how things are progressing here.

First off, thanks for testing the patch, and I'm glad things appear to be working well now.

I've posted a code review at https://reviewboard.asterisk.org/r/558 which is a patch against Asterisk trunk. The patch fixes this issue plus a couple of other RFC 2833 DTMF issues I noticed while looking at the code. In addition, I wrote a test script which exercises the changes and have posted the script for review at https://reviewboard.asterisk.org/r/560

Once I get those reviews signed off, I will be able to commit the changes and get this issue closed out. I've marked this as being "ready for review" since there are code review requests posted now.

By: Mark Michelson (mmichelson) 2010-03-26 11:09:33

The review I posted was approved, and my automated tests are showing that this has been fixed, therefore I am closing the issue. Please feel free to re-open if the issue persists.

Specifically, in the 1.4 branch, the commit that fixes this issue is revision 254452.