Many thanks for the pointers.
-----Original Message-----
From: Paul Kyzivat [mailto:[email protected]]
Sent: Monday, May 03, 2010 10:05 AM
To: Dushyant Godse
Cc: [email protected]
Subject: Re: [Sip-implementors] How to resolve 491 request pending cross
over on Re-INVITEs
Dushyant Godse wrote:
> Now UA2 receives re-invite w/ SDP on call leg #1 from UA1. UA1
extracts
> SDP from call leg #1 and sends a Re-INVITE to UA2 on call leg#2. At
the
> same time UA1 sends a re-invite on call leg#2 to UA2. These are part
of
> session refresh being triggered using re-invites.
>
> UA1 UA2
>
> -- INVITE w/ SDP (call leg#1)--- >
>
> <-- INVITE w/ SDP (call leg#2)---
> -- INVITE w/ SDP (call leg#2)--- >
>
> <--491 request pending (call leg#2)---
>
> -- 100 trying(call leg#2)--- >
>
> -- 491 request pending(call leg#2)--- >
>
> -- ACK(call leg#2)--- >
>
> <-- ACK (call leg #2)---
>
> Question is -
>
> When a re-invite and 491 pending cross over happens on a dialog (call
> dialog #2), how do both the UA resolve this. What retry timers are
used
> to resolve this and is there a draft available that addresses this
> issue?
You don't find 3261 section 14.1 sufficient?
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.
The above still applies (independently on each dialog) when B2BUAs are
involved. I got a little lost in your example, but I suspect you have
the B2BUA relaying a request from one leg to the other when it ought to
have already recognized glare and generated a 491.
The problem with the section 14.1 rules, as applied to B2BUAs comes when
the B2BUA is the "owner" of the call-ids for two calls that it is
coupling. The result may be that in a glare situation it may send a 491
in both directions, and then they will both choose the backoff in range
[0-2]. You can just ignore that and trust that they won't collide
indefinitely, or else you can do something "special".
Thanks,
Paul
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is authorized. Any
liability arising from any party acting, or refraining from acting, on any
information contained in this e-mail is hereby excluded. If you are not the
intended recipient, please notify the sender immediately, destroy the original
transmission and its attachments and do not disclose the contents to any other
person, use it for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or
its affiliated entities.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
