[asterisk-users] DTMF digits falsely detected

[Matthew Jordan]

----- Original Message -----
> From: "Vladimir Mikhelson" <vlad at mikhelson.com>
> To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users at 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