[Home]

Summary:ASTERISK-20424: Erroneous Multiple DTMF Digit Detection
Reporter:Vladimir Mikhelson (vmikhelson)Labels:
Date Opened:2012-09-14 22:35:36Date Closed:2012-09-24 17:09:25
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_read Channels/General
Versions:1.8.16.0 Frequency of
Occurrence
Constant
Related
Issues:
Environment:CentOS 5.7 FreePBX 2.10.1.2Attachments:( 0) annotated-dtmf-log.txt
( 1) ASTERISK-20424-1.8.diff
( 2) rtp-debug.txt
( 3) vm-430.pcapng
Description:Starting with asterisk 1.8.16.0 longer DTMF tones transmitted per RFC3822 get interpreted as double, triple, etc. digits.
Comments:By: Vladimir Mikhelson (vmikhelson) 2012-09-14 22:37:04.639-0500

In my case digits were repeated 3 times.

Several observations:

   * The problem only manifested itself on SIP channel.  OOH323 and DAHDI did not exhibit this problem.
   * I was able to dial the extension with no issues, the problem started in the Voice Mail application.

For example, in the case below I entered "430#"

Please see the log attachment which was supposed to be located in line, but was moved out by some Digium employee, I guess.

[2012-09-14 11:50:06] VERBOSE[32019] app_read.c:     -- User entered '444333000'

Following is the excerpt from the DTMF log:

[Edit by Rusty Newton - removed inline debug and attached as annotated-dtmf-log.txt as mentioned in [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines#AsteriskIssueGuidelines-Submittingthebugreportinformationrequirements]

I believe Asterisk 1.8.16.0 introduced an issue where a longer DTMF causes a multiple digit recognition effect.

By: Vladimir Mikhelson (vmikhelson) 2012-09-15 11:35:46.381-0500

Attached PCAP and the rtp debug log of a Soft Phone call to a Voice Mail application. "430" was dialed as an extension number, the application captured "444333000".

By: Rusty Newton (rnewton) 2012-09-15 16:45:30.562-0500

Added link to thread on mailing list for reference

By: Matt Jordan (mjordan) 2012-09-19 16:43:56.582-0500

Vladimir, I think the patch I've just attached (ASTERISK-20424-1.8.diff) should compensate for your endpoint's behavior.  If you could test it out and let me know if it does, I'd appreciate it.  Thanks!

By: Vladimir Mikhelson (vmikhelson) 2012-09-19 18:48:35.201-0500

Matt,

The patch worked fine, i.e. the problem seems to be fixed.

I tested with both "new" and "old" Soft Phones.

Thank you,
Vladimir

By: Matt Jordan (mjordan) 2012-09-24 17:09:17.771-0500

So, unfortunately, the patch I committed for this issue (r373236) broke a lot of things.  Yikes.

The issue is that the patch attempts to work around the endpoint increasing its timestamp by absorbing end of event packets that occur within the last known end of event timestamp plus a delta of 320 ms (which, at 'normal' sampling rates, should account for all end of event retransmissions).  There are at least two problems with this:

(1) In situations with *extremely* short duration DTMF, those DTMF packets could be missed.  This is more theoretical than practical, but it could happen.

(2) More realistically - and this is where things blew up - when an RTP source changes its SSRC ID, the RTP timestamps are reset.  Because the timestamp is an unsigned 32-bit field, the last known end of event timestamp is initialized to 0.  If a DTMF packet arrives immediately after this - within the first 320 ms - that DTMF packet will be missed, as it occurs within the 'buffer window'.  This can easily occur when the system integrating with Asterisk is manipulated not by a human (which are usually relatively 'slow' on mashing the keypad) but when its another piece of software.  Asterisk to Asterisk integrations easily broke this scenario.

As such, I'm going to have to revert this patch, and close this issue out as "Won't Fix".  While we strive to not affect endpoints in existence between Asterisk versions, the fact remains that this endpoint is non-compliant, and the fix to maintain compatibility with it will be worse than the problem itself.  I'm very sorry for this - you can of course use the patch provided which will make the endpoint work with your system.

By: Vladimir Mikhelson (vmikhelson) 2012-09-24 18:58:34.906-0500

Matt,

How about leaving your patch code in the trunk with some IF <variable> statement, where <variable> is set per SIP client, with a default being to bypass the code?

Ignoring backwards compatibility tastes bad.

Thank you,
Vladimir

By: Matt Jordan (mjordan) 2012-09-25 08:53:28.090-0500

Its not quite that simple.

The patch I proposed has some fundamental flaws in it that - even on a system that required it due to some UA sending DTMF inappropriately - could result in some DTMF digits being lost if the SSRC changed and the DTMF was sent fast enough.  That right there is reason alone to not make it generally available.  It would be incredibly difficult to reproduce and debug, and would make handling such issues in the future very difficult.

Assuming the patch on this issue isn't sufficient, the other idea would be to support the 'old' mechanism for detecting DTMF digits, which relied upon changes in the DTMF value.  However, that would restore behavior in multiple places in {{process_dtmf_rfc2833}} that isn't as simple as a single {{if}} statement.  There are a few more fundamental places where the behavior would have to be changed, and what would result would be multiple decision points as to what behavior to use.

Then, there's the issue of maintainability: Asterisk already supports multiple modes of detecting RFC 2833 DTMF - rfc2833compensate in chan_sip - which was added to maintain support with pre-1.4 installations of Asterisk.  Having a third mode of RFC 2833 DTMF interpretation will only make the maintainability problem worse.  While we can sometimes justify a maintenance burden when the need for maintaining backwards compatibility is justified, there do not seem to be a plethora of endpoints that behave in the manner observed and MiniPax is hardly an endpoint with a wide spread adoption rate.  The cost of maintaining three ways of interpreting RFC 2833 DTMF is not worth the benefit.

Finally, I wouldn't say we're ignoring backwards compatibility.  We tried.  But trying to maintain compatibility with software that is flat out doing it wrong at the cost of breaking interoperability with software that isn't would just be a bad decision.

By: Vladimir Mikhelson (vmikhelson) 2012-09-25 11:33:59.142-0500

Matt,

I hear you. I understand your logic.

My experience as a software developer tells me that the lack of a backwards compatibility will get you sooner or later.  It is not a matter of MiniPax or other broken UA being used or not used widely.  It is a matter of consistency, predictability and finally reliability of a software product.  I mean Asterisk.

Decision is yours.

Thank you,
Vladimir