| Summary: | ASTERISK-14677: dtmf creating double digits if received out of order | ||
| Reporter: | Erik Smith (eeman) | Labels: | |
| Date Opened: | 2009-08-18 14:02:36 | Date Closed: | 2009-09-01 21:35:13 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/RTP |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) customer.pcap | |
| Description: | Have an Adtran TotalAccess 916e with MLPPP bonded t1's registering with sip to an asterisk PBX (Asterisk 1.4.24.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-08-18 14:04:24 capture of events referenced in adran email are now attached. By: Erik Smith (eeman) 2009-08-19 09:13:32 last night I upgraded to asterisk 1.4.26.1 and confirmed this problem still exists. please revise version information to latest 1.4 build. By: Erik Smith (eeman) 2009-08-25 19:33:03 this problem exists in current 1.4.26 branch please update version and build By: snuffy (snuffy) 2009-09-01 21:35:13 User requested to use newer ticket | ||