Asterisk
  1. Asterisk
  2. ASTERISK-6491

[branch] Asterisk trunk [pre-1.4] and rfc2833 compliance

    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:
      40761
    • Mantis ID:
      6667
    • Regression:
      No

      Description

      Scenario to reproduce:

      SIPPhone -> asterisk -> SPA-3000 -> PSTN
      Asterisk stays in media path (canreinvite=no, dtmfmode=rfc2833)

      PSTN side is failed to receive DTMFs pressed on SIPPhone.

      Actually this issue can be considered as an issue of SPA-3000, as another IP->PSTN gateway (Quadro 4x), which is substituted SPA-3000 in mentioned scenario, successfully receives rfc2833 DTMFs from asterisk and put inband DTMFs to PSTN side.

      From the other side, problem is disappeared as well, if I exclude asterisk from media path (canreinvite=yes). In this case SPA-3000 receives rfc2833 DTMFs directly from SIPPhone and successfully sends them to PSTN side.

      So I assume that rfc2833 implementation of SPA-3000 is not robust enough, but asterisk itself surely is not fully compliant with rfc2833.

      Find below my patch against 1.2.4, which makes asterisk more compliant with rfc2833 and reliable enough for SPA-3000

                • ADDITIONAL INFORMATION ******

      I'm VoIP developer (mainly RTP guy) for more than 5 years now. During last 3 years I found too many broken rfc2833 implementations in the field. I reported rfc2833 compliance issues to xten, snom. Now these issues are fixed for a while.

      Rfc2833 contains some weak (not clarified) areas, which seems to be the reason for broken implementations.
      Drafts on rfc2833 are backward compatible with original document and contains mainly clarifications on it.
      The last one is: draft-ietf-avt-rfc2833bis-12

      I can go into details if accepted and needed.

        Activity

        Hide
        Arsen Chaloyan added a comment -

        I was waiting for bweschke's input on this issue, but seems he is unreachable to me, so I'm going to share my assumption regarding the reason of breakage at VON.

        "Sequence number must be incremented even on final packet (retransmit)".
        This is one of the issues, which my patch is intended to fix. As I stated before, rfc2833 isn't well formed, and has no detailed clarification how to send retransmitted packets, but the draft-ietf-avt-rfc2833bis-12 clearly states:

        2.5.1.6. RTP Sequence Number
        The RTP sequence number MUST be incremented by one in each successive
        RTP packet sent. Incrementing applies to retransmitted as well as
        initial instances of event reports, to permit the receiver to detect
        lost packets for RTCP receiver reports.

        In any case, it's not a major issue not to increment sequence number for final packet, but expecting this behavior from other devices is too wrong.
        See process_rfc2833

        } else if(event_end & 0x80) {
        if (rtp->resp) {
        if(rtp->lasteventendseqn != seqno)

        { f = send_dtmf(rtp); rtp->lasteventendseqn = seqno; }

        rtp->resp = 0;
        }
        Issue ASTERISK-5868 clearly states that asterisk has problems by duplicating dtmfs, when some packets are lost (missed) or reordered.
        So I assume that bweschke had some network issues at VON with lost or reordered packets, when patched asterisk behaved itself as alien device for terminating asterisk and made it to duplicate dtmfs. This is the only reason why reverting back can help.
        Hopefully I'm on right track and my thoughts is clear to you as well.

        joshnet: please share your consideration regarding this.

        Show
        Arsen Chaloyan added a comment - I was waiting for bweschke's input on this issue, but seems he is unreachable to me, so I'm going to share my assumption regarding the reason of breakage at VON. "Sequence number must be incremented even on final packet (retransmit)". This is one of the issues, which my patch is intended to fix. As I stated before, rfc2833 isn't well formed, and has no detailed clarification how to send retransmitted packets, but the draft-ietf-avt-rfc2833bis-12 clearly states: 2.5.1.6. RTP Sequence Number The RTP sequence number MUST be incremented by one in each successive RTP packet sent. Incrementing applies to retransmitted as well as initial instances of event reports, to permit the receiver to detect lost packets for RTCP receiver reports. In any case, it's not a major issue not to increment sequence number for final packet, but expecting this behavior from other devices is too wrong. See process_rfc2833 } else if(event_end & 0x80) { if (rtp->resp) { if(rtp->lasteventendseqn != seqno) { f = send_dtmf(rtp); rtp->lasteventendseqn = seqno; } rtp->resp = 0; } Issue ASTERISK-5868 clearly states that asterisk has problems by duplicating dtmfs, when some packets are lost (missed) or reordered. So I assume that bweschke had some network issues at VON with lost or reordered packets, when patched asterisk behaved itself as alien device for terminating asterisk and made it to duplicate dtmfs. This is the only reason why reverting back can help. Hopefully I'm on right track and my thoughts is clear to you as well. joshnet: please share your consideration regarding this.
        Hide
        BJ Weschke added a comment -

        arsen: We've all got bills to pay. I get to stuff that isn't revenue affecting when I can. I'm sure you understand. What kind of trace is it that you need?

        Show
        BJ Weschke added a comment - arsen: We've all got bills to pay. I get to stuff that isn't revenue affecting when I can. I'm sure you understand. What kind of trace is it that you need?
        Hide
        Arsen Chaloyan added a comment -

        bweschke: See my notes on 03-17-06 01:33 and 03-19-06 05:44 regarding capture I asked.

        "issue holder(s)": Please note, I don't use and I'm not going to use asterisk in any production environment (no interest in this). I'm just developer and asterisk still seems to be an interesting project to participate, from other side I'm getting tired with the way this issue is processed. I'll continue my activity if you need it, else just forget this patch and original reported issue as well.

        damin: Hopefully I'll find time to look at vldtmf branch or just wait it to be merged to trunk and maybe then I'll give some comments on dev mailing list.

        Show
        Arsen Chaloyan added a comment - bweschke: See my notes on 03-17-06 01:33 and 03-19-06 05:44 regarding capture I asked. "issue holder(s)": Please note, I don't use and I'm not going to use asterisk in any production environment (no interest in this). I'm just developer and asterisk still seems to be an interesting project to participate, from other side I'm getting tired with the way this issue is processed. I'll continue my activity if you need it, else just forget this patch and original reported issue as well. damin: Hopefully I'll find time to look at vldtmf branch or just wait it to be merged to trunk and maybe then I'll give some comments on dev mailing list.
        Hide
        damin added a comment -

        Alright.. I know this is a little late but.. As luck would have it, I was informed on IRC tonight that the last couple of obstacles in the new VLDTMF code have been cleaned up and we are now at the stage where we can begin testing and getting feedback on the new implementation. We would love to see if this solves your problem. The following instructions for checking out the new VLDTMF code was sent to me by Russell Bryant a few minutes ago

        From russell@digium.com Sat Aug 19 00:46:36 2006
        Date: Sat, 19 Aug 2006 00:34:03 -0400
        From: Russell Bryant <russell@digium.com>
        To: Greg Boehnlein <damin@nacs.net>
        Cc: jcolp@digium.com
        Subject: Testing VLDTMF

        $ svn co http://svn.digium.com/svn/zaptel/team/group/vldtmf [^] zaptel-vldtmf
        $ svn co http://svn.digium.com/svn/asterisk/team/group/vldtmf [^] asterisk-vldtmf
        $ cd zaptel-vldtmf ; ./configure ; make ; sudo make install
        $ cd ../asterisk-vldtmf ; ./configure ; make ; sudo make install

        That should be all there is to it. If you have any more questions,
        please let us know!

        Show
        damin added a comment - Alright.. I know this is a little late but.. As luck would have it, I was informed on IRC tonight that the last couple of obstacles in the new VLDTMF code have been cleaned up and we are now at the stage where we can begin testing and getting feedback on the new implementation. We would love to see if this solves your problem. The following instructions for checking out the new VLDTMF code was sent to me by Russell Bryant a few minutes ago From russell@digium.com Sat Aug 19 00:46:36 2006 Date: Sat, 19 Aug 2006 00:34:03 -0400 From: Russell Bryant <russell@digium.com> To: Greg Boehnlein <damin@nacs.net> Cc: jcolp@digium.com Subject: Testing VLDTMF $ svn co http://svn.digium.com/svn/zaptel/team/group/vldtmf [^] zaptel-vldtmf $ svn co http://svn.digium.com/svn/asterisk/team/group/vldtmf [^] asterisk-vldtmf $ cd zaptel-vldtmf ; ./configure ; make ; sudo make install $ cd ../asterisk-vldtmf ; ./configure ; make ; sudo make install That should be all there is to it. If you have any more questions, please let us know!
        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