[asterisk-bugs] [JIRA] Commented: (ASTERISK-20424) Erroneous Multiple DTMF Digit Detection

Matt Jordan (JIRA) noreply at issues.asterisk.org
Tue Sep 25 08:54:27 CDT 2012


    [ https://issues.asterisk.org/jira/browse/ASTERISK-20424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197559#comment-197559 ] 

Matt Jordan commented on ASTERISK-20424:
----------------------------------------

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.

> Erroneous Multiple DTMF Digit Detection
> ---------------------------------------
>
>                 Key: ASTERISK-20424
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20424
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_read, Channels/General
>    Affects Versions: 1.8.16.0
>         Environment: CentOS 5.7
> FreePBX 2.10.1.2
>            Reporter: Vladimir Mikhelson
>            Assignee: Vladimir Mikhelson
>         Attachments: annotated-dtmf-log.txt, ASTERISK-20424-1.8.diff, rtp-debug.txt, vm-430.pcapng
>
>
> Starting with asterisk 1.8.16.0 longer DTMF tones transmitted per RFC3822 get interpreted as double, triple, etc. digits.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list