Dear Christer Holmberg
In my draft, Offer/Answer pair is the smallest transaction. I do not prefer to divide it into m lines commitment separately.
And in RFC3264, there is no definition of transaction smaller than Offer/Answer pair, so I use Offer/Answer pair as the base of nested transaction.
Your understanding is much near ours :)
For the reason I mentioned above, the commitment of session modification should be together for all m-lines of one Offer/Answer.
And if the Offer/Answer is by UPDATE/200OK, and it is a new modification, your presentation is correct. And we have the same understanding of semantics of "a new modification from the previous one".
But if the Offer/Answer is in Re-INVITE, such as Offer(in Re-INVITE)/Answer(in 18x) or Offer(in 18x)/Answer(in PRACK), so this Offer/Answer(or say this modification) is triggered by Re-INVITE. And 2xx of Re-INVITE is the late commitment of this modification. This is the property I called "late commitment of 200OK of Re-INVITE", which is defined in RFC3261 and emphasized again in RFC3311. It is really necessary for user's rejecting of session modification. So, this case, the modification need rollback.
And if there is not new modification (such as the one in UPDATE/200OK), and the new one committed, the previous one(triggered by Re-INVITE) will be discarded, no matter the final response. And curently, if the Offer/Answer in UPDATE/200OK is not precondition notification, it would be a new modification. And this obeys the issue 3GPP concerns.
Gaoyang
-------------------------------------------------------- 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
