Asterisk
  1. Asterisk
  2. ASTERISK-5815

[patch] RFC-2833 DTMF support is broken in Asterisk 1.2.x

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Core/RTP
    • Labels:
      None
    • Mantis ID:
      5970
    • Regression:
      No

      Description

      I have two SIP Gateways working with Asterisk server. In sip.conf both configured as dtmfmode=rfc2833. When I making call from one gateway to another and press digits to generate dtmf tones I'm getting 'clicking' sounds - when I press keypad button on phone I hear cliks on the other side (meanwhile phone continually generates tone), when I release button on phone I getting another click from other side. If I press button shortly I can get 3 different results:
      1. digit was not recognized at other side at all
      2. digit was recognezed at oter side
      3. digit was recognized at other side as 2 digits

      In peer-2-peer mode (without asterisk) gateways works fine, so I think that this is Asterisk bug. Moreover, I looked into asterisk sources (rtp.c) and I think the problem is in ast_rtp_senddigit(). Here for every digit we are trying to send 6 RTP packet - first 3 for starting digit and last 3 for ending digit. RFC2833 defines two scenarios of transmitting DTMF tones, it seems that asterisk use first one, but at the moment it still do this wrong way. The point is, that in first 3 packets it send 0 for event duration (RFC says that it must be timestamp here), and for last 3 packet it send event duration 800 (according to RFC here we should have real timestamp when button was released)

      In RFC-compliant scenario when we press button and hold it we should get RTP packets with constantly increasing sequence number time stamps and event duration fields at least. When keypad button is released we should send RTPs with increasing sequence number, and timestamp, but event duration should be same for several packets.

      1. 20060118__bug5970.diff.txt
        3 kB
      2. 20060119__bug5970__50ms.diff.txt
        3 kB
      3. 20060128__bug5970.diff.txt
        4 kB
      4. ast_wave.mp3
        13 kB
      5. broadvox-dtmf-5970.cap
        253 kB
      6. dtmf-bvox-borked_rev0.txt
        0.8 kB
      7. Duplicate Digits.txt
        0.4 kB
      8. Event Between End Events Causes Duplicate Digit.cap
        13 kB
      9. p2p_wave.mp3
        9 kB
      10. p2pgw.dump
        484 kB
      11. rtp_changes.patch
        0.8 kB
      12. trace.txt
        2 kB
      1. Bad Events Sequence Causes Duplicate Digits.gif
        241 kB

        Activity

        Hide
        Max Glucksmann added a comment -

        Damin, Qwell,

        I appreciate very much your advice, but I got a couple of issues after installing the following:

        First, rm -rf /usr/lib/asterisk/modules/*

        then

        cd /usr/src/libpri-trunk
        ./configure; make clean; make install

        cd /usr/src/zaptel-vldtmf
        ./configure; make clean; make install

        cd /usr/src/asterisk-vldtmf
        ./configure; make clean; make install

        CD /usr/src/asterisk-addons-trunk
        ./configure; make clean; make install

        Then I had to disable the g729 and g723 Intel Codecs as they didn't work.

        When finally Asterisk started, no accountcodes where read from the Realtime DB and no CDR was being stored either in the DB...

        I'm going back to the Branch 1.2 version I had where everyhting worked and will test DTMF there again.

        I'm really worried since now I have to face various vendors that already were reselling our calling cards.

        Please keep present the comments posted on issue:
        http://bugs.digium.com/view.php?id=7758

        Thank you very much again.

        Hoping to hear from you soon and with best regards,
        Max

        Show
        Max Glucksmann added a comment - Damin, Qwell, I appreciate very much your advice, but I got a couple of issues after installing the following: First, rm -rf /usr/lib/asterisk/modules/* then cd /usr/src/libpri-trunk ./configure; make clean; make install cd /usr/src/zaptel-vldtmf ./configure; make clean; make install cd /usr/src/asterisk-vldtmf ./configure; make clean; make install CD /usr/src/asterisk-addons-trunk ./configure; make clean; make install Then I had to disable the g729 and g723 Intel Codecs as they didn't work. When finally Asterisk started, no accountcodes where read from the Realtime DB and no CDR was being stored either in the DB... I'm going back to the Branch 1.2 version I had where everyhting worked and will test DTMF there again. I'm really worried since now I have to face various vendors that already were reselling our calling cards. Please keep present the comments posted on issue: http://bugs.digium.com/view.php?id=7758 Thank you very much again. Hoping to hear from you soon and with best regards, Max
        Hide
        Serge Vecher added a comment -

        mglucksmann: does the small patch you have posted in bug ASTERISK-7554, note 0050519 fix out-of-order DTMF issues in 1.2.x branch? If so, could you please make a proper patch and attach it to this bugnote? See this page please http://www.asterisk.org/developers/Patch_Howto. Also, please confirm your disclaimer status. Thanks.

        Show
        Serge Vecher added a comment - mglucksmann: does the small patch you have posted in bug ASTERISK-7554 , note 0050519 fix out-of-order DTMF issues in 1.2.x branch? If so, could you please make a proper patch and attach it to this bugnote? See this page please http://www.asterisk.org/developers/Patch_Howto . Also, please confirm your disclaimer status. Thanks.
        Hide
        Max Glucksmann added a comment -

        Vechers: Disclaimer faxed and patch uploaded...

        I'd like to note that the patch is already found in the work from Russell in the vldtmf svn, as Damin commented, from where I extracted it.

        Once more thank you and I believe that most of the luck I've had is to have found such a great program and community.

        With best regards,
        Max

        Show
        Max Glucksmann added a comment - Vechers: Disclaimer faxed and patch uploaded... I'd like to note that the patch is already found in the work from Russell in the vldtmf svn, as Damin commented, from where I extracted it. Once more thank you and I believe that most of the luck I've had is to have found such a great program and community. With best regards, Max
        Hide
        Serge Vecher added a comment -

        mglucksmann: thanks. The reason I've asked for the patch was because the vldtmf branch will be merged into trunk, not 1.2. If this small enough change actually fixes some dtmf issues, I think it's worth considering for inclusion into 1.2 branch too.

        Could some people monitoring this bug and having issues with DTMF apply mglucksmann's patch and report on the results, please?

        Show
        Serge Vecher added a comment - mglucksmann: thanks. The reason I've asked for the patch was because the vldtmf branch will be merged into trunk, not 1.2. If this small enough change actually fixes some dtmf issues, I think it's worth considering for inclusion into 1.2 branch too. Could some people monitoring this bug and having issues with DTMF apply mglucksmann's patch and report on the results, please?
        Hide
        Joshua Colp added a comment -

        Okay folks here is the scoop - DTMF in 1.4 is vastly different to what it is in 1.2, and it can't be backported without A LOT of trouble... so I'm closing this bug. Please do give 1.4 a try as a beta, or wait for a release and open a new bug if you have issues with the implementation there. That is all and thanks all for holding on!

        Show
        Joshua Colp added a comment - Okay folks here is the scoop - DTMF in 1.4 is vastly different to what it is in 1.2, and it can't be backported without A LOT of trouble... so I'm closing this bug. Please do give 1.4 a try as a beta, or wait for a release and open a new bug if you have issues with the implementation there. That is all and thanks all for holding on!

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development