> How should a UAC handle a following situation - after > receiving 180 for it's INVITE from the server, the > app wants to initiate an update transaction,
RFC3311 section 5.1 discusses many of the limitations concerning sending UPDATE. The UPDATE must not contain an SDP unless the prior offer/answer has been reliably completed which would require the use 100rel for 180 response. > it sends out an update message and then UAC > receives an OK from the server, does the call > considered confirmed? and the update transaction, > does it continue or ignored by the UAC ? It sounds like you are asking about the situation of UPDATE sent by caller and the INVITE 200 response is received prior to UPDATE 200 response. The caller receiving the INVITE 200 response does not directly impact the outstanding UPDATE transaction. If an UPDATE 200 is subsequently received, the UPDATE modification was accepted. There is some potential for ambiguity concerning retries, delivery order, etcetera, over non reliable transports. However I'm unaware of anyone formalizing a mechanism to avoid the situation beyond using reliable transports. For completeness, the following draft discusses many of the offer/answer race conditions. http://tools.ietf.org/wg/sipping/draft-ietf-sipping-sip-offeranswer/draf t-ietf-sipping-sip-offeranswer-00.txt _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
