I arranged a Q/A list. And the questions are people usually asked. And it is the process of my thought, so I once asked myself too.
[Q1] Why we need rollback?
[A1] That is the original concept of RFC3261. And it is the intuitionistic requirement for rejecting modification from user's view.
[Q2] And I think other SIP transaction(such as UPDATE) is independent transaction from Re-INVITE.
[A2] Yes.
[Q3] If I think that Offer/Answer in UPDATE/200OK will be committed alone, and if the UPDATE/200OK pair is during the Re-INVITE, what will happen. Committment/Rollback? It seems antinomy.
[A3] Yes. It seems that.
But the 200OK of Re-INVITE is the "Late Commitment" of the modification triggered by Re-INVITE. The commitment of other "new modification" with other transaction is the duty of that transaction 's 200OK.
[Q5] It puzzled me more. How can we treat a new modification during Re-INVITE?
[A5]If UA can not accept it at once, it should be rejected by 504. If UA accepts it, it will be committed at once. And it will have nothing to do with the Re-INVITE's failure or success.
[Q4] But there are really some special Offer/Answer. How can we treat it?
[A4] Such as precondition, it has the semantics of suspending/resuming of modification. So, it can be treated as part of the original modification. Then it will rollback with Re-INVITE's failure.
Before user is hinted, there can be more than one Offer/Answer pairs. But when he/she rejected the modification, he rejected all as atomic.
[Q6] Your mean differentiate the UPDATE during Re-INVITE?
[A6] Yes. Because some are really parts of the original modification and some are really new modifications.
-------------------------------------------------------- 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
