So, if the UAS sends a "rollback UPDATE", and offers m1 and m2 to be put
back, and the UAC cannot accept it, the UAC should of course reject the
UPDATE. What happens after that is an implementation issue, I think.
[Gao] But Gonzalo's draft using "should not", but this is a case "MUST".
You could end up in the same situations even without preconditions
intermediate UPDATEs. For example:
- Session before re-INVITE = m1 and m2
- Re-INVITE adds m3 and removes m1 and m2
- UAS rejects the re-INVITE
Now, m1 and m2 has been removed, and no matter if the UAS sends 4xx, or
a rollback UPDATE, the UAC may not be able to put m1 and m2 back.
[Gao] Without precondition, there is no such problem at all.
UAS can reject the Offer, without giving answer, such as 488.
The only way to solve this would be to say that any committed change (no
matter whether the change has been done using reINV/18x or UPD/200) is
never rolled back - which is the current solution.
[Gao] We are talking session state in theory level. And
I think I have show in my draft that we have definitive session state obeying current RFCs.
How to get to the session state, is practical level thing.
If you are interested in it. You can make a new thread, and I will share my ways(I think we have many ways to do so).
-------------------------------------------------------- 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
