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:16	Date Closed:	2010-06-30 12:36:02
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
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 1.4.26.1 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. ****** 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 1.4.26.1, 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.