Thanks for your standpoint. And more commment/feeling from more people are welcome.
Brett Tate <[email protected]> 2009-03-10 23:04 收件人 "[email protected]" <[email protected]>, SIP <[email protected]>, SIPPING <[email protected]> 抄送 主题 RE: [Sip] "UPDATE during Re-INVITE" discussion I think number 2 more accurately represents RFC 3261, RFC 3262, and RFC 3311. From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Sunday, March 08, 2009 10:49 PM To: SIP; SIPPING Subject: [Sip] "UPDATE during Re-INVITE" discussion There are two thought about "UPDATE during Re-INVITE". Which one is better or suits for current RFCs There are two thought about "UPDATE during Re-INVITE". 1. All UPDATEs during Re-INVITE are Re-INVITE's sub-transaction RFC3312(Precondition) is a case. As there is such case, we can making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction. 2. Not all UPDATE(during Re-INVITE) can be considered as sub-transaction of Re-INVITE There is really need nested-modification, such as precondition and more in the future. But the cascade of nested transaction should be defined in application-level, not signal-level. So, it is better to make Re-INVITE and UPDATE separatly expect for definition such as precondition. And this obeys current definition of RFC3311. In RFC3311, when the UPDATE is accepted by the other side(UPDATE/200OK), the change of states is committed and effort at once. And making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction can be violation of RFC3311. So, we shold not treat all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction. While UPDATE/200OK just refresh "precondition state table" in RFC3312("precondition state table" is modified at once, so this obeys RFC3312), having no impat on the commitment of modification triggered by Re-INVITE, these UPDATE/200OK can be treated as sub-transaction of Re-INVITE. Other UPDATE/200OK can not be treated as sub-transaction of Re-INVITE. Comments/feeling are welcome! -------------------------------------------------------- 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. -------------------------------------------------------- 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.
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
