Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Core/RTP
    • Labels:
      None
    • SVN Revision Number:
      12792
    • Mantis ID:
      6027
    • Regression:
      No

      Description

      Hi, we are experiencing a problem where we are receiving DTMF RTP packets out of order and asterisk seems to be interpreting these as multiple (separate) DTMF signals when it shouldn&ASTERISK-7996;t.

      Our setup is as follows,
      [PSTN Provider] > SIP > [Ast1] > SIP > [Ast2] + Voicemail APP

                • ADDITIONAL INFORMATION ******

      We call from a BT land line to our incoming number, this is then passed to us using SIP from our incoming number provider to Ast1 in our datacenter then from Ast1 to Ast2 which is on our local SDSL circuit which runs vocemailmain app and we use a username of &ASTERISK-7995;1234&ASTERISK-7996; and pin of &ASTERISK-7996;5678&ASTERISK-7996;.
      In all cases, we use dtmfmode=rfc2833.

      I have attached a couple traces, one from Ast1 and one from Ast2 of the same call.

      In Ast1.cap the DTMF packet numbers are,

      &ASTERISK-7995;1&ASTERISK-7996; = 301-306
      &ASTERISK-7995;2&ASTERISK-7996; = 320-325
      &ASTERISK-7995;3&ASTERISK-7996; = 342-347
      &ASTERISK-7995;4&ASTERISK-7996; = 385-390
      &ASTERISK-7995;#&ASTERISK-7996; = 410-415

      &ASTERISK-7995;5&ASTERISK-7996; = 557-562
      &ASTERISK-7995;6&ASTERISK-7996; = 574-579
      &ASTERISK-7995;7&ASTERISK-7996; = 591-596
      &ASTERISK-7995;8&ASTERISK-7996; = 604-609
      &ASTERISK-7995;#&ASTERISK-7996; = 621-626

      In Ast2.cap the packet numbers are,

      &ASTERISK-7995;1&ASTERISK-7996; = 309-314
      &ASTERISK-7995;2&ASTERISK-7996; = 328-333
      &ASTERISK-7995;3&ASTERISK-7996; = 350-355
      &ASTERISK-7995;4&ASTERISK-7996; = 393-398
      &ASTERISK-7995;#&ASTERISK-7996; = 418-424

      &ASTERISK-7995;5&ASTERISK-7996; = 565-571
      &ASTERISK-7995;6&ASTERISK-7996; = 582-587
      &ASTERISK-7995;7&ASTERISK-7996; = 599-604
      &ASTERISK-7995;8&ASTERISK-7996; = 612-617
      &ASTERISK-7995;#&ASTERISK-7996; = 629-634

      looking at Ast1.cap all the RTP packets are in order as expected but on the receiving side on Ast2 we see the DTMF packets out of order.
      Look at the &ASTERISK-7995;5&ASTERISK-7996; (565-571 in Ast2.cap) we can see

      565 start TS: 58904, Sequence: 17016
      566 end TS: 58904, Sequence: 17019
      567 start TS: 58904, Sequence: 17017
      568 start TS: 58904, Sequence: 17018
      569 end TS: 58904, Sequence: 17021
      570 end TS: 58904, Sequence: 17020

      now for this asterisk took it to mean &ASTERISK-7995;55&ASTERISK-7996; not just &ASTERISK-7995;5&ASTERISK-7996; I assume because it takes the 567 start as the start of a new DTMF tone and not a continuation of 565 as it should.

      1. ast1.cap
        212 kB
      2. ast2.cap
        215 kB
      3. delvar.20012006-1.svn.dtmf.patch
        5 kB
      4. fool4kate.rtp.dtmf.path
        4 kB
      5. rtp.diff
        4 kB
      6. rtpTraf.txt
        3 kB

        Activity

        Hide
        Adam Long added a comment -

        Hi Ronald,

        Delvars code is working for you?
        I tried it yesterday and it did not seem to help very much.

        The one line change (see my last post above) definitly did the trick however.

        Any ideas?

        -Adam

        Show
        Adam Long added a comment - Hi Ronald, Delvars code is working for you? I tried it yesterday and it did not seem to help very much. The one line change (see my last post above) definitly did the trick however. Any ideas? -Adam
        Hide
        Ronald Chan added a comment -

        Adam,

        Yes!, Well in my case the congestion is happening on my end due to bandwidth constraints, the other leg of the call was getting a duplicate dtmf signal which cause by network jitters.

        My Asterisk is SVN trunk rev 37174

        My setup is
        GSM
        UA -> SIP -> * -> SIP -> Voipjet/Teliax -> PSTN

        Avg. latency is 192-256 ms at any given time.

        Before the patch apply, if i call from any Toll number or even US did number i won't get thru even with 3 digit extensions on the called party.

        After the patch has been apply, 70-80% of the call went ok compare to NOTHING.

        Best regards,

        Ronald

        Show
        Ronald Chan added a comment - Adam, Yes!, Well in my case the congestion is happening on my end due to bandwidth constraints, the other leg of the call was getting a duplicate dtmf signal which cause by network jitters. My Asterisk is SVN trunk rev 37174 My setup is GSM UA -> SIP -> * -> SIP -> Voipjet/Teliax -> PSTN Avg. latency is 192-256 ms at any given time. Before the patch apply, if i call from any Toll number or even US did number i won't get thru even with 3 digit extensions on the called party. After the patch has been apply, 70-80% of the call went ok compare to NOTHING . Best regards, Ronald
        Hide
        Eldad Ran added a comment -

        I had the same problem cfieldmtm patch fixed it 100%

        Show
        Eldad Ran added a comment - I had the same problem cfieldmtm patch fixed it 100%
        Hide
        Serge Vecher added a comment -

        anybody testing trunk (the soon 1.4.beta to be) here may want to check out the following branches:

        http://svn.digium.com/view/asterisk/team/group/vldtmf/
        http://svn.digium.com/view/zaptel/team/group/vldtmf/

        AFAIK, functional vldtmf support is what's holding up the 1.4 release, so help make it happen!

        Show
        Serge Vecher added a comment - anybody testing trunk (the soon 1.4.beta to be) here may want to check out the following branches: http://svn.digium.com/view/asterisk/team/group/vldtmf/ http://svn.digium.com/view/zaptel/team/group/vldtmf/ AFAIK, functional vldtmf support is what's holding up the 1.4 release, so help make it happen!
        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