----- Original Message ----- > From: "Vladimir Mikhelson" <v...@mikhelson.com> > To: "Asterisk Users Mailing List - Non-Commercial Discussion" > <asterisk-users@lists.digium.com> > Sent: Saturday, September 15, 2012 11:41:23 AM > Subject: Re: [asterisk-users] DTMF digits falsely detected > > Please take a look at the case > https://issues.asterisk.org/jira/browse/ASTERISK-20424?actionOrder=asc > I uploaded the PCAP captured on the Soft Phone end and the RTP debug > log. > > I ran the "old" Soft Phone", dialed *98, then entered "430", the > application heard "444333000". >
Thank you for uploading the log files. It appears as if the UA sending the DTMF is incorrectly increasing the timestamp in the end event retransmissions: [2012-09-15 11:02:49] VERBOSE[6392] res_rtp_asterisk.c: Got RTP RFC2833 from 172.17.135.5:13000 (type 101, seq 000231, ts 121920, len 000004, mark 0, event 00000004, end 1, duration 02400) [2012-09-15 11:02:49] VERBOSE[6392] res_rtp_asterisk.c: Got RTP RFC2833 from 172.17.135.5:13000 (type 101, seq 000232, ts 122080, len 000004, mark 0, event 00000004, end 1, duration 02400) [2012-09-15 11:02:49] VERBOSE[6392] res_rtp_asterisk.c: Got RTP RFC2833 from 172.17.135.5:13000 (type 101, seq 000233, ts 122240, len 000004, mark 0, event 00000004, end 1, duration 02400) You'll note that the timestamp is increasing in each subsequent retransmission. The timestamp should be the same across all three packets with an increasing sequence number. Because RTP packets can arrive out of order, Asterisk is using the timestamp to determine if the packets correspond to the same DTMF event. The fact that both the sequence number and the timestamp are increasing would typically imply that the next end packet received is actually an out of order packet for a subsequent DTMF digit. I'm not entirely sure what you mean by the following: "Another interesting thing which our friend Matt apparently did not pay attention to was the fact that dialing worked fine with Minipax, it was the applications where problems started. Sounds like his latest patch was not applied consistently throughout the system. Good news for now, but could change in the future." Dialing would not apply here, as a SIP device will not use RFC2833 DTMF to indicate the UA it wishes to establish a dialog with in an INVITE request (its in the INVITE request itself) - unless overlap dialing somehow became involved. I doubt that's what you referring to here, however. This would only exhibit once the UA in question was actually sending DTMF over RTP. This patch only applied to decoding RFC2833 DTMF on the inbound read side of res_rtp_asterisk. That's the only place it made sense to apply the handling for receiving out of order RFC2833 DTMF. Outbound transmission would obviously not be affected. Similarly, devices communicating using chan_ooh323 - or even the majority of SIP devices - would not reproduce this, as they may be transmitting the DTMF digits correctly. I'm not sure how chan_dahdi would enter into this at all, as its certainly not going to use the RTP engine. Again, thanks for uploading the files. We'll take a look at this issue on Monday to see if there's anyway the behavior can be modified to account for the non-compliant endpoint while still handling out of order DTMF transmission. -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users