[asterisk-users] DTMF digits falsely detected

[Vladimir Mikhelson]

Matt,

Please see my answers in-line.  Thank you for looking into the issue.

-Vladimir


On 9/15/2012 12:36 PM, Matthew Jordan wrote:
> ----- 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.

Can you please quote the appropriate RFC here?  It looks like the UA
just uses the real time of an event for time stamping.  I still would
like to understand the logic and the math here as 121920+2400=124320,
not 122080 or 122240.

Why does the retransmission happen at all?  Maybe something else is broken?


>   Because RTP packets can arrive out of order, Asterisk is using
> the timestamp to determine if the packets correspond to the same DTMF event.

Is that something mandated by the respective RFC?  In other words is it
"MUST" or "MAY" per RFC?  Or is it not there at all?

> 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.

See the question above.

>
> 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.

Sorry, my mistake.  Somehow I assumed that dialing was processed in
IVR.  Even in this case my statement would have been incorrect as IVR is
yet another application.

I need to test with IVR, but my bet results will be the same as with
Voice Mail.  At least that is how it sounds from your explanation of
what behavior was modified and where.

> 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.

As I did not know what exactly caused the DTMF recognition failure I
tested almost all channels I use, e.g. I called in via a POTS line.

> 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.

Once again please refer to the RFC you use as the specification.

> --
> 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
>