> 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
