[asterisk-dev] SIP with canreinvite=yes through multiple Asterisk instances

[Raj Jain]

Edwin,

You are running into a RE-INVITE "glare" scenario. The Asterisk boxes
facing each other are racing to send RE-INVITE to each other to drop
the RTP hairpin. The Asterisk 1.4 does not retransmit a RE-INVITE on
receving a 491 response. It is treating 491 as a permanent failure and
therefore dropping the call.

I don't know what changed between 1.2 and 1.4 to explain why you are
seeing this only in 1.4 and not in 1.2. Since this is a race
condition, I'd imagine that this could occur in 1.2 as well and has
just not occured in your setup yet. Maybe some additional processing
in 1.4 is causing the race condition to occur more frequently.

Your Mantis bug report would basically ask for correct 491 processing
in Asterisk SIP channel. Here is how RFC 3261 (Section 14.1)
recommends this condition should be resolved:

   If a UAC receives a 491 response to a re-INVITE, it SHOULD start a
   timer with a value T chosen as follows:

      1. If the UAC is the owner of the Call-ID of the dialog ID
         (meaning it generated the value), T has a randomly chosen value
         between 2.1 and 4 seconds in units of 10 ms.

      2. If the UAC is not the owner of the Call-ID of the dialog ID, T
         has a randomly chosen value of between 0 and 2 seconds in units
         of 10 ms.

   When the timer fires, the UAC SHOULD attempt the re-INVITE once more,
   if it still desires for that session modification to take place.  For
   example, if the call was already hung up with a BYE, the re-INVITE
   would not take place.

Thanks,

Raj


On 8/16/07, Edwin Groothuis <edwin at mavetju.org> wrote:
> The story at http://www.mavetju.org/~edwin/asterisk-sip-reinvite.html
> describes a problem I experienced with calls coming from one of our
> providers where during the SIP handshake our equipment was reinviting
> the SIP session: The RTP stream was never setup. We experienced
> this after the upgrade from 1.2 to 1.4 (the latest SVN version),
> before that it always has worked.
>
> To simulate this problem, I have setup one SIP phone, three identical
> Asterisk instances and a connection towards the end-point: A Cisco
> Call Manager. The only varying factor in the experiments was the
> option "canreinvite": When using "canreinvite=no", it always worked
> fine, but when using "canreinvite=yes", it broke down after two
> hops.
>
> I have written down the whole setup, the configurations, the scenarios
> and the results at http://www.mavetju.org/~edwin/c2-flow.txt.
> Attached to each scenario are the SIP packets (captured with ngrep
> and processed into a flow visualiser).
>
> I hope that this can help you to find out if this is a problem with
> Asterisk. Oh, and help me to get the RTP streams directly between
> the two end-stations instead of via the Asterisk box. Once I have
> feedback from somebody I can open a bug at Mantis to bring it under
> the developers attention.
>
> Edwin
> --
> Edwin Groothuis      |            Personal website: http://www.mavetju.org
> edwin at mavetju.org    |              Weblog: http://www.mavetju.org/weblog/
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>