Hi,
I think we can check whether this is happening everytime when similar
scenario is ran or sometime. This seems to be a race condition. If everytime
similar thing observed then it might be issue of UAS where its not able to
detect Re-INVITE is retransmitted.
Thanks and Regards,
Vivek Talwar
-----Original Message-----
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of EXT Paul
Kyzivat
Sent: Tuesday, September 22, 2015 8:22 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] In dialog UPDATE crossing reINVITE: allowed?
I was apparently writing my reply in parallel with Brett. And we have
arrived at essentially the same conclusion.
Thanks,
Paul
On 9/22/15 10:30 AM, Brett Tate wrote:
>> Consider SIP-dialog between UA1 & UA2.
>> UA1 sends reINVITE to UA2, and immediately also an in-dialog
>> UPDATE (to send updated P-Asserted-Identity value).
>
> Sending a request such as UPDATE immediately after re-INVITE is valid.
> However as you observed if the requests are received out-of-order (because
> of dropped packets or other reasons), it can cause a 500 response
> (hopefully with Retry-After 0) to be generated as mentioned within RFC
> 3261 section 12.2.2.
>
>
>> Is an in-dialog UPDATE that crosses a not-completed reINVITE
>> (as shown in above flow) allowed?
>
> Sending a request such as UPDATE immediately after re-INVITE is valid.
> Based upon the information you provided, it is behaving as though the
> first re-INVITE was somehow dropped and the CSeq ordering issue is
> observed when processing the retry after UPDATE.
>
>
>> Should the B2BUA wait with the UPDATE until the ACK?
>
> If the sender wants to ensure no ordering issue, it needs to queue the
> UPDATE. If the sender wants to recover from the CSeq issue, it should try
> again based upon the 500 response (which hopefully included a Retry-After
> 0). Unfortunately RFC 3261 did not allocate a response code specifically
> for the CSeq issue. Thus the UAC does not really know the 500 was because
> of a CSeq issue. However, the inclusion of a Retry-After header with a
> value of 0 provides a good indication that there was an ordering issue (or
> similar issue) and immediately trying again might work.
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
