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
