Hi, >>But, as indicated in Gonzalo's draft, that can be avoided by the UAS >>sending an UPDATE instead of 4xx. > >I showed a example that UAC can not accept the UPDATE. But he did not give further explanation. > >session before Re-INVITE has two m-line, as m1 and m2 >UAC send Re-INVITE to add m3 and remove m2, m3 with precondition. >Then UAS can not alert the user. > >After m3's precondition OK, m2 has removed(because Offer/Answer pairs has exchanged). >Then user rejected the modification. > >Then the undo UPDATE re-open m2 and remove m3. Re-open m2 can need precondition. >Then the UAC can not accept it at once. If something has been removed there can always be situations when it is not possible to roll back. 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. 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. 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. 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
