Hi, >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". I don't know what text you are referring to, but there is always a risk that the UPDATE will be rejected. We can't assume, it won't. >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. Yes, but in my example there was already an answer in 18x. >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. And I think Gonzalo's draft says the same thing. >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). I don't want a new thread - I want a solution. Regards, Christer _______________________________________________ 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
