sipping Y. Gao Internet-Draft ZTE Intended status: Standards Track March 6, 2009 Expires: September 7, 2009 The Criterion of Session State draft-gaoyang-sipping-session-state-criterion-03.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 7, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Gao Expires September 7, 2009 [Page 1] Internet-Draft The Criterion of Session State March 2009 Abstract There is debate on the topic of "Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE". The reason of the confusion is some application/session usages of offer/answer imply the nest transaction(mean transaction theory, not mean sip transaction) concept, but whitout unambiguous definition. This paper reveal the concept of nest transactions in current RFC and other well known application/session usages. And then clarify that there is no ambiguous state of session modification using current RFC definition. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Atomicity's semantics . . . . . . . . . . . . . . . . . . . . 4 2.1. Atomicity's semantics of UPDATE . . . . . . . . . . . . . 4 2.2. Atomicity's semantics of Re-INVITE . . . . . . . . . . . . 4 2.3. Combination of the two ones . . . . . . . . . . . . . . . 4 2.3.1. Is precondition use-case violation of RFC3311 . . . . 5 2.4. Dialog state and session state clarification . . . . . . . 5 2.4.1. There is target refresh and session modification during Re-INVITE . . . . . . . . . . . . . . . . . . . 5 2.4.2. There is only target refresh during Re-INVITE . . . . 5 2.4.3. The UPDATE/200OK has target refresh and refreshing the precondtion state table . . . . . . . . . . . . . 6 3. Why nested transaction . . . . . . . . . . . . . . . . . . . . 7 3.1. Nested transaction concept in current RFCs . . . . . . . . 7 3.1.1. Precondition . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Late commitment of Re-INVITE 200OK . . . . . . . . . . 7 3.2. Opened for evolution and extension in the future . . . . . 7 4. The Criterion . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Rules for current nested-transaction usages . . . . . . . 9 4.2. Explanation for some concepts . . . . . . . . . . . . . . 9 4.3. This proposal has no racing condition . . . . . . . . . . 9 5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Normative references . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Gao Expires September 7, 2009 [Page 2] Internet-Draft The Criterion of Session State March 2009 1. Introduction There has been some confusion among dialog state and session state after unsuccessful Re-INVITE. In this document, we clarify that there is no ambiguous dialog state and session state by current RFC definition. Gao Expires September 7, 2009 [Page 3] Internet-Draft The Criterion of Session State March 2009 2. Atomicity's semantics As we know, atomicity's semantics is "all or nothing". And if new modification is acceptted, the older pending one would be discarded(that is the semantics of "nothing"). 2.1. Atomicity's semantics of UPDATE In RFC3311, when the UPDATE is accepted by the other side(UPDATE/ 200OK), the change of states is committed and effort at once. If the other side can not accept it at once, it can reject it by 504. The semantics is clear, and, the states including "dialog state" and "session state". 2.2. Atomicity's semantics of Re-INVITE If people want to form everything during Re-INVITE as a big nested transaction, there are problems as: o Casecade of the nested transaction must have specific definition at first. o Racing condition again(during or not during). o Violation of the RFC3311: If the session description has changed, the UAS MUST adjust the session parameters accordingly and generate an answer in the 2xx response. So, the modifications associated with Re-INVITE is the ones in Re- INVITE, not during Re-INVITE. So, I use the words "modification triggered by Re-INVITE" to distinguish from the later modification during Re-INVITE. The states including "dialog state" and "session state". 2.3. Combination of the two ones Except for later Offer/Answer pairs which are used as "refreshing the precondtion state table" during suspending state of session, any new Offer/Answer MUST be treated as a new modification. If a new modification is acceptted, the older pending one discard(that is the "nothing"). The discarding of the older pending one(Re-INVITE) obeys RFC3261. And commitment of the new one obeys RFC3311. Gao Expires September 7, 2009 [Page 4] Internet-Draft The Criterion of Session State March 2009 2.3.1. Is precondition use-case violation of RFC3311 In RFC3312, there can be UPDATE/200OK used as "refreshing the precondtion state table" before failure of Re-INVITE. And the anticipated session state is the one before Re-INVITE. Is this violation of Re-INVITE? First, we should make sure the effect of the later Offer/Answer pairs which are used as "refreshing the precondtion state table" during suspending state of session. By RFC3312, these Offer/Answer pairs just refresh the precondtion state table, but it has no impact on the commitment of the modification. Then, as the UAs has adjusted the session parameters(refresh the precondtion state table) accordingly, it obeys RFC3311. And as current pending session modification is still the one triggered by Re-INVITE, and it is discarded for the failure of Re- INVITE. This obeys RFC3261. 2.4. Dialog state and session state clarification Let's use some examples to show the concept mentioned above. 2.4.1. There is target refresh and session modification during Re- INVITE Re-INVITE failed, nothing in it is committed. This obeys RFC3261. The committed target refresh and session modification is by UPDATE/ 200OK. This obeys RFC3311. signaling | O/A state | remote target ---------------------+-----------+-------------- init-INVITE/200/ACK | state1 | c1 re-INVITE/183-rel | state2 | c2 PRACK/200OK | [noSDP] | - UPDATE/200OK | state3 | c3 4xx/ACK | state3 | c3 Figure 1 2.4.2. There is only target refresh during Re-INVITE Re-INVITE failed, nothing in it is committed. This obeys RFC3261. The committed target refresh is by UPDATE/200OK. This obeys RFC3311. Gao Expires September 7, 2009 [Page 5] Internet-Draft The Criterion of Session State March 2009 signaling | O/A state | remote target ---------------------+-----------+-------------- init-INVITE/200/ACK | state1 | c1 re-INVITE/183-rel | state2 | c2 PRACK/200OK | [noSDP] | - UPDATE/200OK | [noSDP] | c3 4xx/ACK | state1 | c3 Figure 2 2.4.3. The UPDATE/200OK has target refresh and refreshing the precondtion state table Re-INVITE failed, nothing in it is committed. This obeys RFC3261. The committed target refresh is by UPDATE/200OK. This obeys RFC3311. The committed "refreshing the precondtion state table" is by UPDATE/ 200OK. But the session state is given up by 4xx of Re-INVITE. signaling | O/A state | remote target ---------------------+-----------+-------------- init-INVITE/200/ACK | state1 | c1 re-INVITE/183-rel | state2 | c2 PRACK/200OK | [noSDP] | - UPDATE/200OK | state2.1 | c3 4xx/ACK | state1 | c3 Figure 3 Gao Expires September 7, 2009 [Page 6] Internet-Draft The Criterion of Session State March 2009 3. Why nested transaction Chapter 2 reveals the necessity of a new solution for session state. And this chapter is about why the new solution is based on the concept of nested-transaction. 3.1. Nested transaction concept in current RFCs 3.1.1. Precondition As RFC3312(Quality-of-Service precondition)\4032(Precondition Framework)\5027(Security Preconditions) defines, session establishment and modification suspended until precondtion is satisfied. And during the suspended state, there can be Offer/Answer pairs used as precondition notification. This is a typical nested transaction using Offer/Answer pairs as sub- transaction. 3.1.2. Late commitment of Re-INVITE 200OK As RFC3261 defines, for unsuccessful Re-INVITE, the session parameters MUST remain unchanged, as if no re-INVITE had been issued. This is about session modification triggered by Re-INVITE. And the "Late commitment of Re-INVITE 200OK" just corresponds to the modification triggered by the Re-INVITE. A new modification during the Re-INVITE has nothing to do with the final response of Re-INVITE, such as UPDATE with a new modification. This is also a typical nested transaction using Offer/Answer pair as sub-transaction. And it is intuitionistic requirement for rejecting session modification. What MUST be pointed out is that, by RFC3262, Offer/Answer of the modification triggered by Re-INVITE can be exchanged before final response. In signal level, the modification is in pending state and waits for late commitment. But in media level, the new session parameters can be used. And this obeys RFC3264 and RFC3262. 3.2. Opened for evolution and extension in the future We should accept the idea that using offer/answer as sub-transaction of modification should be open for the future extension. For example, in the future we can define a complex application which need negotiation of session parameter using more than one offer/answer pairs for one modification, just like "Precondition". As nested transaction is the natural property of session modification Gao Expires September 7, 2009 [Page 7] Internet-Draft The Criterion of Session State March 2009 and it is important for evolution and extension in the future, so the new solution is based on the concept of nested-transaction. Gao Expires September 7, 2009 [Page 8] Internet-Draft The Criterion of Session State March 2009 4. The Criterion 4.1. Rules for current nested-transaction usages "Late commitment of Re-INVITE 200OK" contains "Precondition". And that is "Precondition" can be sub-transaction of "Late commitment of Re-INVITE 200OK" to form a bigger nested-transaction. And this is practical for session modification with precondition using Re-INVITE. Rule 1: Late commitment of the modification triggered by Re-INVITE is 200OK. Before the 200OK, the modification is in pending state in the point of view of signal level. If the Re-INVITE is unsuccessful, the pending modification MUST rollback. Rule 2: Precondition notification is part of the original modification. Rule 3: when a new modification succeeds during the pending state of the previous modification, the new one MUST be committed and the original one discarded. Rule 4: when a new modification request is rejected during the pending state of the previous modification, the original one can go on. 4.2. Explanation for some concepts Precondition notification is later Offer/Answer pair which is used as "refreshing the precondtion state table" during suspending state of session. Except for Precondition notification, any new Offer/Answer MUST be treated as a new modification. 4.3. This proposal has no racing condition As the new modification has been committed and its state have nothing to do with F8, the problem of racing condition(4xx of Re-INVITE and UPDATE) described in 6.2 of "draft-ietf-sipping-sip-offeranswer" does not exist. Gao Expires September 7, 2009 [Page 9] Internet-Draft The Criterion of Session State March 2009 Racing condition of 4xx of Re-INVITE and UPDATE UAC UAS | session established | |===================| | | | F1 re-INVITE (SDP) | |--------------------| | F2 1xx-rel (SDP) | |--------------------| | F3 PRACK | |--------------------| | F4 2xx PRA | |--------------------| | | |F5 UPDATE F6 2xx INV | |---------\ /--------| | \/ | | /\ | |--------/ \-------| - UPDATE request inclue a new | | modification Figure 4 Currently, there are only two cases for the Offer in UPDATE: o precondtion notification; o a new modification request. If it is precondtion notification, the session state is clear. That is committed state of the modification triggered by F1. If it is a new modification request, there are only two cases for the UPDATE: o accepted by 200OK; o rejected by 4xx/5xx/6xx, such as 504. If it is accepted by 200OK, the new modification is committed. And the session state is committed state of the modification triggered by F5. If it is rejected, and the original modification failed, the session state is one before F1. Gao Expires September 7, 2009 [Page 10] Internet-Draft The Criterion of Session State March 2009 So, the session state is clear for this situation. And the solution is racing condition free. Gao Expires September 7, 2009 [Page 11] Internet-Draft The Criterion of Session State March 2009 5. Acknowledgment Thanks Gonzalo Camarillo, OKUMURA Shinji, Ian Elz and Christer Holmberg for discussion. Gao Expires September 7, 2009 [Page 12] Internet-Draft The Criterion of Session State March 2009 6. Normative references [I-D.ietf-sipping-sip-offeranswer] Sawada, T. and P. Kyzivat, "SIP (Session Initiation Protocol) Usage of the Offer/Answer Model", draft-ietf-sipping-sip-offeranswer-08 (work in progress), April 2008. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005. Gao Expires September 7, 2009 [Page 13] Internet-Draft The Criterion of Session State March 2009 Author's Address Gao yang ZTE CHINA Email: gao.yang2@zte.com.cn Gao Expires September 7, 2009 [Page 14]