I think "UPDATE during Re-INVITE" is clear.
1. In RFC311
In RFC3311, when the UPDATE is accepted by the other side(UPDATE/200OK), the change of states is committed and effort at once. If the other side can not accept it at once, it can reject it by 504.
The semantics is clear. And, the states including "dialog state" and "session state".
2. Considering Precondition
Some people may ask is "Precondition" the violation of the semantics mentioned above? There is no violation at all.
UPDATE/200OK committed and effort the Offer/Answer at once. But we must make sure the effect of the Offer/Answer.
In RFC3312, there is specific semantics of suspending/resuming session modification. And Offer/Answer using as sharing precondition view(as I called "Precondition notification") do not determine the session modification commitment.
So, this obeys RFC3311:
If the session description has changed, the UAS MUST adjust the session parameters accordingly and generate an answer in the 2xx response.
The UA adjust the session parameters accordingly(refresh the precondtion state table), but it has no impact on the commitment of the modification.
It is quite clear.
3. Considering part of SDP with Precondition
If the UPDATE/200OK just refresh the precondtion state table, it is the same as "2. Considering Precondition".
If the UPDATE adding more than "refresh the precondtion state table":
o Precondition not satisfied. UA should reject it with 504.
o Precondition satisfied, but need user's acknowledgement. UA should reject it 504.
o Precondition satisfied, without needing user's acknowledgement. UA can accept it. And the modification is committed at once.
All the above is clear.
-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
