mmusic Y. Gao Internet-Draft ZTE Intended status: Standards Track February 9, 2009 Expires: August 13, 2009 Session State Analysis draft-gaoyang-sipping-session-state-analysis-01.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 13, 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 13, 2009 [Page 1] Internet-Draft Session State Analysis February 2009 Abstract Session state on unsuccessful re-INVITE is an open issue[1]. Many people interested in this topics and there has been a lot of discussion in the mail list publicly or among participants privately. This text tried to analyse incorrectness or drawback of some of the methods to reveal the imortance of precise definition of session state. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rollback to session state before Re-INVITE . . . . . . . . . . 4 3. Commit any session parameters that have been sucessfully changed . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Intuitionistic drawback . . . . . . . . . . . . . . . . . 5 3.2. Confirmed state but not enough for usage . . . . . . . . . 5 3.3. Useless pending state . . . . . . . . . . . . . . . . . . 5 3.4. Inconsistent state . . . . . . . . . . . . . . . . . . . . 6 4. Manual rollback using a new Re-INVITE . . . . . . . . . . . . 7 4.1. Problems for ordinary SDP . . . . . . . . . . . . . . . . 7 4.2. Problems for non-integrative SDP . . . . . . . . . . . . . 7 4.2.1. Theoretical analysis . . . . . . . . . . . . . . . . . 7 4.2.2. Unable to construct the new complete SDP . . . . . . . 7 5. Giving out a precise definition of session state . . . . . . . 8 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Gao Expires August 13, 2009 [Page 2] Internet-Draft Session State Analysis February 2009 1. Introduction There are more than one method to solve the problem mentioned above. I collected four types of such way from discussion and other open way, such as drafts. o rollback to session state before Re-INVITE; o commit any session parameters that have been sucessfully changed; o "manual rollback" using a new Re-INVITE; o giving out a precise definition of session state; I will analyse incorrectness and drawback of the first three ways to reveal the importance of precise definition of session state. This text is not intend to introduce any solution in the fourth way, and one of such way can be found in [2]. Gao Expires August 13, 2009 [Page 3] Internet-Draft Session State Analysis February 2009 2. Rollback to session state before Re-INVITE If the Offer/Answer pairs belonging to or during(such as UPDATE) the Re-INVITE is just parts of the original modification triggered by Re- INVITE, such as precondition notification, should rollback with the failure of Re-INVITE. There will be one and only one Offer/Answer pair belonging to Re- INVITE, others is just during the Re-INVITE. The succedent Offer/ Answer pairs during the Re-INVITE, can be parts of the original modification or a new modification of the same session. If it is a new modification, and having been processed successfully, it must not rollback with the failure of Re-INVITE. The reason is that 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). The new modification commitment and its state have nothing to do whit the success/failure of Re-INVITE. So, we can find that ignoring the relationship among Offer/Answer pairs, and just "rollback to session state before Re-INVITE" is arbitrary. This method is not acceptable. Gao Expires August 13, 2009 [Page 4] Internet-Draft Session State Analysis February 2009 3. Commit any session parameters that have been sucessfully changed 3.1. Intuitionistic drawback As mentioned in RFC3311: Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is because an 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. "Commit any session parameters that have been sucessfully changed" 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? 3.2. Confirmed state but not enough for usage Considering 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 duration of 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. 3.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. Perhaps, the only way to resuming the session is to send a new Re- INVITE. So the violation of continuity of session usage is also exist here. It is ironic that if the session state has been rollbacked to the one before the previous Re-INVITE, the session state will be clear, and it can assure the continuity of session Gao Expires August 13, 2009 [Page 5] Internet-Draft Session State Analysis February 2009 usage by the rules in section 8 of RFC3264. 3.4. Inconsistent state Considering precondition(in fact any modification overlaps more than one Offer/Answer may be same), the two sides just has a shared view of the status of a media stream, not the precondition. So the precondition in each side can be different The suspending and resuming of modification is operated by each user agent itself[6]. Then the modification here might not be consistent. For example, if precondition of one side is met and the other side is not met, the two sides will have inconsistent states. As 3.3, the only way to resuming the session is to send a new Re-INVITE. The situations mentioned above show that this method has problems. This method is not acceptable. Since there are some cases in this section need help of "manual rollback" using a new Re-INVITE, this method is not acceptable. And incorrectness or drawback of "manual rollback" using a new Re-INVITE is in section 4. Gao Expires August 13, 2009 [Page 6] Internet-Draft Session State Analysis February 2009 4. Manual rollback using a new Re-INVITE 4.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. So, from the points of session continuity, a precise definition of session state, as the fourth way, is needed for all situations mentioned above. 4.2. Problems for non-integrative SDP 4.2.1. Theoretical analysis Because the SDP just describe 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. 4.2.2. Unable to construct the new complete SDP Some persons may ask that can we construct the new complete SDP. First, complete SDP might not be constructed for syntax of non- integrative SDP, such as the usage in [7]. RFC4566 pointed out that attribute interpretation depends on the media tool being invoked. And if the interpretation refer to some kind of complex function expression. The rollback of modification can only be processed in the media tool side. The other side(controlling side) have no way to construct the new complete SDP. So it can not do such rollback by a new Re-INVITE. Situations unable to rollback using "manual rollback", can be treated as proof of the importance of precise definition of session state. Gao Expires August 13, 2009 [Page 7] Internet-Draft Session State Analysis February 2009 5. Giving out a precise definition of session state A precise definition of session state is the way giving out the rules which can be practical in all situations. This text is not intend to introduce any solution in this way, and one of such way can be found in [2]. Gao Expires August 13, 2009 [Page 8] Internet-Draft Session State Analysis February 2009 6. Conclusion Considering incorrectness or drawback of the first three ways, we can admit that a precise definition of session state is important for current SIP/SDP usage and for the evolvement in the future. Gao Expires August 13, 2009 [Page 9] Internet-Draft Session State Analysis February 2009 7. Acknowledgements Thanks for Christer Holmberg and Paul Kyzivat for discussion on this topic in SIPPING mail list. And thanks for my colleagues Wang Libo, Shi hao for discussion on this topic in daily work. Gao Expires August 13, 2009 [Page 10] Internet-Draft Session State Analysis February 2009 8. References [I-D.gaoyang-mmusic-classification-of-sdp] yang, G. and W. Libo, "Classification of SDP", draft-gaoyang-mmusic-classification-of-sdp-00 (work in progress), February 2009. [I-D.gaoyang-sipping-session-state-criterion] Yang, G., "The Criterion of Session State", draft-gaoyang-sipping-session-state-criterion-00 (work in progress), January 2009. [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. [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001. [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. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. Gao Expires August 13, 2009 [Page 11] Internet-Draft Session State Analysis February 2009 Author's Address Gao yang ZTE CHINA Email: gao.yang2@zte.com.cn Gao Expires August 13, 2009 [Page 12]