Funny. This exact point came up in a private conversation I was having
just a day ago.
Alok 2 Tiwari wrote:
> Hi,
> As per RFC-3261, the retry after timer is started by UAC itself after
> deciding the retry after duration based on call id ownership. So there is no
> need of retry after header in 491 response code. But since your
> implementation is as below:
>
> I am adding the party name to make you understand the answer of this query.
>
> The call flow is as below:
>
> Party A Party B
>
> INVITE ----------> B2BUA ----------> INVITE
> 100 <---------- B2BUA <---------- 100
> 183 <---------- B2BUA <---------- 183
> 200 <---------- B2BUA <---------- 200
> ACK ----------> B2BUA ----------> ACK
> <------------Call Established---------->
> REINVITE-------> B2BUA <-------REINVITE
> 491 <---------- B2BUA ----------> 491
>
> Here is the two part of the call.
>
> 1. Party A --------------------> B2BUA
> 2. B2BUA --------------------> Party B
>
> In first case, Party A is owner of the call id. So B2BUA will send 491
> response towards party A with the duration between 2.1 and 4 seconds in retry
> after header.
>
> In second case, Since B2BUA is call id owner so it will send 491 response
> towards party B with duration between 0 to 2 seconds in retry after header.
The above seems backward to the rules. Party B, and the B2BUA acting
toward Party A go first, while Party A and the B2BUA acting toward Party
B go later.
Practically speaking, the B2BUA will have to be passive in this - it
will simply relay the reinvites it gets. Hopefully it will get the one
from Party B before the one from Party A, and things will work out.
But there is another case that is more problematic:
Party A Party B
INVITE <--------- B2BUA ----------> INVITE
...
<------------Call Established---------->
REINVITE-------> B2BUA <-------REINVITE
491 <---------- B2BUA ----------> 491
In this case the B2BUA is the owner if both dialogs, so Parties A and B
will both choose to retry in between 0 and 2 seconds. In this case there
is much greater chance of repeated collision.
There isn't a lot the B2BUA can do about this. Perhaps it could make its
own decision about which party should receive preference, and
preemptively return another 491 if it receives a retry from the other
party first.
Thanks,
Paul
> Regards,
> Alok Tiwari
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamini Gangwani
> Sent: Friday, October 17, 2008 2:10 PM
> To: sip-implementors@lists.cs.columbia.edu
> Cc: Kamini Gangwani
> Subject: [Sip-implementors] Query regarding Retry-After timers in 491response
> in glare situation
>
> Hi
>
> I have one query regarding timers handling in 491 "Request Pending" for
> Re-Invite.
> The scenario is like this:
>
> A call is being established with an Application which is behaving as B2BUA.
> Now we receives Reinvite from both sides- UAC and UAS at same time and due to
> which a glare situation arises and B2BUA sends 491 "Request Pending" to both
> sides UAC and UAS. So my query is that: what should be the value of
> Retry-After timer in 491 for both call legs?
>
> INVITE ----------> B2BUA ----------> INVITE
> 100 <---------- B2BUA <---------- 100
> 183 <---------- B2BUA <---------- 183
> 200 <---------- B2BUA <---------- 200
> ACK ----------> B2BUA ----------> ACK
> <------------Call Established---------->
> REINVITE-------> B2BUA <-------REINVITE
> 491 <---------- B2BUA ----------> 491 (What should be the value of
> Retry-After timer in 491 response on both sides?)
>
> As per RFC-3261, I got this information:
>
> "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."
>
> But since in case of B2BUA, is it that we should check if it is side-1, then
> timer value should be 2-4 seconds and if it is side-2, then timer value
> should be 0-2 seconds.
> Is this correct understanding or anybody having some other views on this?
>
> Regards,
> kamini gangwani
> Aricent
>
> ________________________________
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received this
> message in error,please notify the originator immediately. If you are not the
> intended recipient, you are notified that you are strictly prohibited from
> using, copying, altering, or disclosing the contents of this message. Aricent
> accepts no responsibility for loss or damage arising from the use of the
> information transmitted by this email including damage from virus."
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received this
> message in error,please notify the originator immediately. If you are not the
> intended recipient, you are notified that you are strictly prohibited from
> using, copying, altering, or disclosing the contents of this message. Aricent
> accepts no responsibility for loss or damage arising from the use of the
> information transmitted by this email including damage from virus."
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
