sipping Y. Gao Internet-Draft ZTE Intended status: Standards Track February 24, 2009 Expires: August 28, 2009 The Criterion of Session State draft-gaoyang-sipping-session-state-criterion-02.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 August 28, 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Gao Expires August 28, 2009 [Page 1] Internet-Draft The Criterion of Session State February 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. Drawback of current proposed solutions . . . . . . . . . . . . 4 2.1. Drawbacks of commit by Offer/Answer . . . . . . . . . . . 4 2.1.1. Intuitionistic drawback . . . . . . . . . . . . . . . 4 2.1.2. Confirmed state but not enough for usage . . . . . . . 4 2.1.3. Useless pending state . . . . . . . . . . . . . . . . 4 2.1.4. Illegal using session parameters . . . . . . . . . . . 5 2.2. Drawback of manual rollback . . . . . . . . . . . . . . . 5 2.2.1. Problems for ordinary SDP . . . . . . . . . . . . . . 5 2.2.2. Problems for non-integrative SDP . . . . . . . . . . . 5 3. Why nested transaction . . . . . . . . . . . . . . . . . . . . 6 3.1. Nested transaction concept in current RFCs . . . . . . . . 6 3.1.1. Precondition . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Late commitment of Re-INVITE 200OK . . . . . . . . . . 6 3.2. Opened for evolution and extension in the future . . . . . 6 4. The Criterion . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Explanation for current nested-transaction usages . . . . 8 4.1.1. Rules for current nested-transaction usages . . . . . 8 4.1.2. Explanation for some concepts . . . . . . . . . . . . 8 4.2. Rules in academic way . . . . . . . . . . . . . . . . . . 9 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Example of compound usage of Precondition and Late commitment of Re-INVITE 200OK . . . . . . . . . . . . . . 10 5.2. Example always arose confusion, but have clear state . . . 11 5.3. Racing condition free . . . . . . . . . . . . . . . . . . 12 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Normative references . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Gao Expires August 28, 2009 [Page 2] Internet-Draft The Criterion of Session State February 2009 1. Introduction In this paper, a solution of session state is proposed, which uses the concept of nested-transaction. As there has been some proposed solutions, then why a new one? The reasons are: o current proposed solutions have some drawback. o we should using nested-transaction for session state, because it is the natural property of session modification. Gao Expires August 28, 2009 [Page 3] Internet-Draft The Criterion of Session State February 2009 2. Drawback of current proposed solutions I collected two types of such solutions from discussion and other open way, such as drafts. o commit by Offer/Answer. o "manual rollback". 2.1. Drawbacks of commit by Offer/Answer 2.1.1. Intuitionistic drawback As mentioned in RFC3311: UPDATE needs to be answered immediately, ruling out the possibility of user approval. Such approval will frequently be needed, and is possible with a re-INVITE. It reveal the main difference of Re-INVITE and UPDATE. If we can not clarify the session state on unsuccessful re-INVITE, we just give up the advantages of Re-INVITE. And will just make Re-INVITE as UPDATE. And we may ask: Why we need Re-INVITE further while modification of session using Re-INVITE is just as the one using UPDATE? 2.1.2. Confirmed state but not enough for usage Considering such situation: One side using Re-INVITE to reduce the number of media types, such as audio and vedio session to audio session, or to use codec needing less resources. There are Offer/ Answer pairs before the final response of Re-INVITE. At last, the other side reject the modification. If we obey the rule "session parameters that have been sucessfully changed during the re-INVITE transaction MUST remain unchanged", the media types or resources are not enough for the user. Even if user sends a new Re-INVITE to reopen the media types, but there is not enough media types or resources during this new Re- INVITE and it violates the continuity of session usage. For advanced media type, such as virtual reality pursuing immersion for users, it will be terrible. 2.1.3. Useless pending state Reasons, such as precondition, can make the session state in pending state. And if the preconidtion is not met, the two sides can not use the resources. And it also violates the continuity of session usage. Gao Expires August 28, 2009 [Page 4] Internet-Draft The Criterion of Session State February 2009 2.1.4. Illegal using session parameters The modification in media level can be used illegally, while the modification is unsuccessful in signal level. 2.2. Drawback of manual rollback 2.2.1. Problems for ordinary SDP Sections mentioned above introduced "manual rollback" using a new Re- INVITE as the way to resume the session under ambiguous situations. But if the two sides have no consistent view of session state, no matter which side sends the new Re-INVITE, the other side will treat it as violation of session continuity because of different view of session state. 2.2.2. Problems for non-integrative SDP Because the SDP just describes part of the session, not all aspects of the session. It must be combined with the previous one(or ones) to show the effects, as the formula: "current session state" = "previous session state" + "modification session description". Even if using a new Re-INVITE with "modification session description", we can not rebulid the "current session state" without the definition of the "previous session state". So, the "previous session state" is important here, and we still need to give out a precise definition of session state to get the "previous session state" here. Gao Expires August 28, 2009 [Page 5] Internet-Draft The Criterion of Session State February 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 August 28, 2009 [Page 6] Internet-Draft The Criterion of Session State February 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 August 28, 2009 [Page 7] Internet-Draft The Criterion of Session State February 2009 4. The Criterion 4.1. Explanation for current nested-transaction usages 4.1.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.1.2. Explanation for some concepts 4.1.2.1. What is a precondition notification? Concluded from RFC3312: o Suspending/resuming of session modification is session level issue, so any m-lines with precondition will make session suspended. o An Offer/Answer with precondition notification and without any other modification of session, during suspending state of session modification, is called precondition notification. o An Offer/Answer with any other modification of session beyond precondition notification will make the Offer/Answer a new modification. o An Offer/Answer with precondition notification and without any other modification of session, but after suspending state of session modification MUST NOT be treated as precondition notification anymore. Gao Expires August 28, 2009 [Page 8] Internet-Draft The Criterion of Session State February 2009 4.1.2.2. What is s new modification request? Any new version of SDP can be treated as new modification, if there is no specific definition to make it a part of the original one. During a Re-INVITE, one side can send the same SDP with higer version number in UPDATE, for emergency reasons. The situation is unusual but legal. And if the other side accept the modification, it will be effective at once. So, it MUST be treated as a new modification. The same is for the Offer/Answer with precondition notification and without any other modification of session, but after suspending state of session modification. 4.2. Rules in academic way Current usage is simple, and the discription mentioned in chapter 4.1 is just about "Precondition" and "Late commitment of Re-INVITE 200OK". And to be reference for complex evolution and extension, we need more academic and abstract rules. o Rule 1: transactins and smaller nested-transactions can be taken as sub-transaction of a bigger nested-transaction. And this forms cascade level of transactions. We call the nested-transaction as "higer hevel" and its sub-transaction as "lower level". o Rule 2: considering the integrity, we define "Session Modification" as the root of any nested transaction. When the highest level sub- transaction in "Session Modification" committed, "Session Modification" commits. With the root nested transaction, any high level nested transaction is just the root's sub-transaction. And introducing new higher level of nested transaction would not make violation of the cascade level of transactions. o Rule 3: when nested transaction failed, it MUST rollback by discarding its committed sub-transactions. o Rule 4: when a higer or the same Level transaction succeeded during the pending state of a lower or the same level transaction, the new one MUST be committed and the original one discarded. o Rule 5: when a higer or the same Level transaction request is rejected during the pending state of a lower or the same level transaction, the original one can go on. Gao Expires August 28, 2009 [Page 9] Internet-Draft The Criterion of Session State February 2009 5. Examples 5.1. Example of compound usage of Precondition and Late commitment of Re-INVITE 200OK F1-F4: modification of session in precondition; F5:ringing; F6:user reject the modification request; Commit/Rollback Issue with re-INVITE transaction in precondition UAC UAS | session established | |<===================>| | | | F1 re-INVITE (SDP) | |-------------------->| | F2 1xx-rel (SDP) | |<--------------------| | F3 UPDATE | |-------------------->| | F4 2xx UPT | |<--------------------| | | | F5 180 ringing | |<--------------------| | | | F6 4xx/5xx/6xx INV | |<--------------------| | F7 ACK | |-------------------->| | | Figure 1 The session state before F1 is state1; The session state after F2 is state2' whitout commit of precondition; The session state after F4 is state2'' whit commit of precondition, but whitout commit of user; At the point of F6, the previous commited state in semantics explained in 2.2 is state1(although the previous commited state in semantics explained in 2.1 is state2''), it should be rollback to state1. Gao Expires August 28, 2009 [Page 10] Internet-Draft The Criterion of Session State February 2009 5.2. Example always arose confusion, but have clear state F1-F5 is the same as 4.1 F6: one part send UPDATE request inclue a new modification Example always arose confusion, but have clear state UAC UAS | session established | |<===================>| | | | F1 re-INVITE (SDP) | |-------------------->| | F2 1xx-rel (SDP) | |<--------------------| | F3 UPDATE | <- UPDATE request include state |-------------------->| notification | F4 2xx UPT | |<--------------------| | | | F5 180 ringing | |<--------------------| | | | F6 UPDATE | <- UPDATE request inclue a new |-------------------->| modification | F7 2xx UPT/504 | <- the response should be 504 |<--------------------| | F8 4xx/5xx/6xx INV | |<--------------------| | F9 ACK | |-------------------->| | | Figure 2 F7 is the important one: if it is 200OK with answer, it means that UAS accept the new modification. And in session level it is the new modification after the one trigged by Re-INVITE, so we have no reason to say that the the new successful modification should be commited by the signal(2XX of Re-INVITE) associate to the original modification request.And in signal level, Re-INVITE and UPDATE is independent transaction(SIP).As the new modification has been committed and its state have nothing to do whit F8, the session state is clear. Considering the UAS has the local policy that new modification must Gao Expires August 28, 2009 [Page 11] Internet-Draft The Criterion of Session State February 2009 notify the user, it must send 504 to reject F6. The confusing is because of some people hypotheses the relation of UPDATE and Re-INVITE. As the new modification have been committed, the original session state without committing should be discarded. 5.3. Racing condition free As the new modification has been committed and its state have nothing to do with F8, the problem of racing condition(200OK of Re-INVITE and UPDATE) described in 6.2 of "draft-ietf-sipping-sip-offeranswer" does not exist. Racing condition of 200OK 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 3 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. Gao Expires August 28, 2009 [Page 12] Internet-Draft The Criterion of Session State February 2009 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, the previous modification will go on. And session state is committed state of the modification triggered by F1. So, the session state is clear for this situation. And the solution is racing condition free. Gao Expires August 28, 2009 [Page 13] Internet-Draft The Criterion of Session State February 2009 6. Acknowledgment Thanks Christer Holmberg for his questions, suggestion and guidance. And thanks Paul Kyzivat for his discussion. Gao Expires August 28, 2009 [Page 14] Internet-Draft The Criterion of Session State February 2009 7. 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 August 28, 2009 [Page 15] Internet-Draft The Criterion of Session State February 2009 Author's Address Gao yang ZTE CHINA Email: gao.yang2@zte.com.cn Gao Expires August 28, 2009 [Page 16]