Asterisk
  1. Asterisk
  2. ASTERISK-10237

SIP Reinvite behaviour does not work as expected with certain dial() options

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

      Description

      With canreinvite=no on any SIP peer, the call is never reinvited (this is correct behaviour)

      With canreinvite=yes, and using with a Dial() option from below, re-invites are not issued correctly. (actually, reinvites should not be issued at all...)

      Asterisk is not supposed to perform a re-invite when using any of the following Dial() options: t, T, h, H, w, W or L (with multiple arguments)
      This is not the case.
      Asterisk still issues a Re-invite to one of the call legs causing an asytmetrical RTP traffic flow (causing one-way audio if the SIP peer filters RTP packets coming from somehwere that was not in it's own SDP)

      EG
      SIPPeerA-----ASTERISK----SIPPeerB

      SIPPeerA calls SIPPeerB

      If either or both SIPPeerA or SIPPeerB have canreinvite=no, the RTP flow is always via Asterisk - this is correct.

      If Both SIPPeers are canreinvite=yes, AND the dial command contains any of the above dial() options, then the RTP flow forms a triangle due to a single re-invite STILL being issued by Asterisk. EG A's RTP goes to Asterisk, Asterisk's RTP goes to B, but B's RTP goes to A. This is because Asterisk issues a re-invite and tells B to talk to A when it shouldn't.
      If Asterisk does issue a re-invite for one leg, it should issue a re-invite for both legs! But in this case it should not issues any re-invites at all.

                • ADDITIONAL INFORMATION ******

      Possibly apparent in every 1.4.x version. Confirmed faulty behaviour in 1.4.5 and 1.4.11.

      I think this is also what is breaking certain T.38 calls too... and possibly the root of several other problems we are experiencing.

      Very easy to reproduce. Confirmed with Dial Options t T h H, and combinations thereof. They all perform the same (wrong behaviour).

        Activity

        Hide
        Joshua Colp added a comment -

        Suspending since the original reporter has not gotten in contact with me... as for the L option, I've added support for native bridging with it in trunk as of revision 103314.

        Show
        Joshua Colp added a comment - Suspending since the original reporter has not gotten in contact with me... as for the L option, I've added support for native bridging with it in trunk as of revision 103314.
        Hide
        Joshua Colp added a comment -

        Reopened per request.

        Show
        Joshua Colp added a comment - Reopened per request.
        Hide
        Joshua Colp added a comment -

        Status update: Reporter has been given exact code flow and is tracking it down on their own.

        Show
        Joshua Colp added a comment - Status update: Reporter has been given exact code flow and is tracking it down on their own.
        Hide
        Joshua Colp added a comment -

        Any progress based on the information of how things work I gave?

        Show
        Joshua Colp added a comment - Any progress based on the information of how things work I gave?
        Hide
        Joshua Colp added a comment -

        While I hate to suspend this it has been quite some time, and I've given all the information requested. Was the issue outside the scope of Asterisk? Did you need more information?

        Show
        Joshua Colp added a comment - While I hate to suspend this it has been quite some time, and I've given all the information requested. Was the issue outside the scope of Asterisk? Did you need more information?

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development