sipping Y. Gao Internet-Draft ZTE Intended status: Standards Track February 11, 2009 Expires: August 15, 2009 The Criterion of Session State draft-gaoyang-sipping-session-state-criterion-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 15, 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 15, 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. Offer/Answer Usages In Current RFC . . . . . . . . . . . . . . 3 1.1. In RFC3264 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. In RFC3312 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. In RFC3261 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Current well known nested transactions in application level using Offer/Answer . . . . . . . . . . . . . . . . . . 4 2.1. Precondition . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Intuitionistic(user point of view) requirement for rejecting session modification . . . . . . . . . . . . . 4 2.3. 3GPP usage of Offer/Answer to refine(reduce) codec set . . 4 3. The Criterion . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Criterion description . . . . . . . . . . . . . . . . . . 5 3.2. The level of application/session usages of offer/answer in nest transaction . . . . . . . . . . . . 5 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Example of compound usage of 2.1 and 2.2 . . . . . . . . . 6 4.2. Example always arose confusion, but have clear state . . . 7 4.3. Racing condition of 200OK of Re-INVITE and UPDATE . . . . 8 4.3.1. Problem . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.2. Solution in theory . . . . . . . . . . . . . . . . . . 9 4.3.3. Recommendation of signal flow . . . . . . . . . . . . 9 5. Normative references . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Gao Expires August 15, 2009 [Page 2] Internet-Draft The Criterion of Session State February 2009 1. Offer/Answer Usages In Current RFC 1.1. In RFC3264 The offer/answer exchange is atomic; if the answer is rejected, the session reverts to the state prior to the offer (which may be absence of a session). 1.2. In RFC3312 Session parameter negotiation using precondition may be combination of more than one offer/answer.Session parameter negotiation using precondition itself should be atomic. From transaction(mean tranaction theory, not mean sip transaction) ponit of view, it forms nested transaction which use a offer/answer pair as a sub- transaction. 1.3. In RFC3261 If a UA receives a non-2xx final response to a re-INVITE, the session parameters MUST remain unchanged, as if no re-INVITE had been issued. And this is an intuitionistic(user point of view) requirement for rejecting session modification. We could conclude from there rules that there are nested transactions concept in application level above of offer/answer which use a offer/ answer pair as a sub-transaction. And the nested transactions has its own semantics of commit/rollback. So, we should not just talk about commit/rollback of session state in offer/answer level when the application level has nested transactional semantics of commit/ rollback. And it should be point out that if we just define the commit/rollback of session state in offer/answer level for all situation whitout considering the application level, we will restrict the application level usage of offer/answer in the future. We should accept the idea that the application level usage of offer/answer should be open for the future extension. For Example, in the future we define a complex application/session which need negotiation of session parameter using offer/answer in many times for one modification. Gao Expires August 15, 2009 [Page 3] Internet-Draft The Criterion of Session State February 2009 2. Current well known nested transactions in application level using Offer/Answer 2.1. Precondition As RFC3312 defines, a user agent server that receives an offer with preconditions SHOULD NOT alert the user until all the mandatory preconditions are met;session establishment(/modification) is suspended until that moment. So, any offer/answer pairs for reservation state notification is just part of the original session modification transaction(nested transaction). As the precondition defined in RFC3312 is session level extention, the semantics of commit/rollback of session modification transaction(nested transaction) is in session level. Other application level usage can using it as sub-transaction to form more complicated nested transaction. There will be an example later in this text. 2.2. Intuitionistic(user point of view) requirement for rejecting session modification There are some cases where it is useful to exchange offer(s)/ answer(s) even before re-INVITE completes. The case of adding a new media (like adding video to audio only session) which requires permission from the peer through some user interaction is one example. Offer/answer pairs forms as sub-transaction of the final commit/rollback of modification. As RFC3311 defines: However, unlike a re-INVITE, the UPDATE MUST be responded to promptly, and therefore the user cannot generally be prompted to approve the session changes. UPDATE did not have the nested transactional property in application level. 2.3. 3GPP usage of Offer/Answer to refine(reduce) codec set 3GPP usage of offer/answer in PRACK/200OK or UPDATE/200OK pair to refine(reduce) the codec set, just as part of the modification of original session modification. Gao Expires August 15, 2009 [Page 4] Internet-Draft The Criterion of Session State February 2009 3. The Criterion 3.1. Criterion description Using nest transaction theory, when one application/session usages of offer/answer failure, it just rollback to the previous commited state in its semantics. It maybe using other application/session usages of offer/answer as its sub-transaction, commited state in sub- transaction will be discarded. 3.2. The level of application/session usages of offer/answer in nest transaction It is open(free) for any new application/session usages of offer/ answer, but it should define the level of application/session usages of offer/answer in nest transaction for itself. Here, this paper point out the level of application/session usages of offer/answer in nest transaction for current well konwn application/session using Offer/Answer. Considering the integrity, we define the root transaction as "Session Modification".2.1,2.2,2.3 stand for the application/session using Offer/Answer defined in 2.1,2.2,2.3. Level definition: "Session Modification" contains 2.2; 2.2 contains 2.1 & 2.3; 2.1 contains 2.3. When starting of the new "Session Modification" before the committing of the previous "Session Modification", UA should rollback to committed state of the top level of application/session using Offer/ Answer. Now, the top level application/session using Offer/Answer is 2.2. Gao Expires August 15, 2009 [Page 5] Internet-Draft The Criterion of Session State February 2009 4. Examples 4.1. Example of compound usage of 2.1 and 2.2 F1-F4: modification of session in precondition(2.1); F5:ringing; F6:user reject the modification request(2.2); 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 15, 2009 [Page 6] Internet-Draft The Criterion of Session State February 2009 4.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 commitment 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 15, 2009 [Page 7] 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(the previous state of the new modification must be the committed state). 4.3. Racing condition of 200OK of Re-INVITE and UPDATE 4.3.1. Problem As the new modification commited and its state have nothing to do whit 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 But considering the possible failure of F5, there is a new condition: F6 before F5, the the previous state of the new modification will be state after F6(Re-INVITE modification effected); F6 after F5, the the previous state of the new modification will be state before F1(Re- INVITE modification discarded). Gao Expires August 15, 2009 [Page 8] Internet-Draft The Criterion of Session State February 2009 4.3.2. Solution in theory If UAS have doubt on the state of session, it may reject F5 using 491/500+retry after. When receving the ACK of F6(2xx INV), UAS can assure the sequence of ACK before UPDATE by CSeq(ACK for 2xx is end to end). Then, the UAS can be sure the previous state of the new modification will be state after F6. 4.3.3. Recommendation of signal flow The solution in 4.2 is theoretical, so we recommend another signal flow in practice. And we think that any UA should avoid of getting signal flow into a racing condition. The Recommendation of signal flow is that when UAC want to send a new modification of session during a ongoing Re-INVITE transaction(SIP), it should using Re-INVITE after the final response of previous Re- INVITE. If Re-INVITE is in a pending state(such as ringing, F5), UAC may send Cancel request for termination of Re-INVITE(F6). After F9, UAC send the new Re-INVITE request inclue the new modification(F11). Gao Expires August 15, 2009 [Page 9] Internet-Draft The Criterion of Session State February 2009 Recommendation of signal flow 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 Cancel | |-------------------->| <- UAC request termination of Re-INVITE | F7 2xx | |<--------------------| | F8 487 INV | |<--------------------| <- final response of Re-INVITE | F9 ACK | |-------------------->| | | | F11 re-INVITE (SDP)| |-------------------->| <- Re-INVITE request inclue a new modification Figure 4 Gao Expires August 15, 2009 [Page 10] Internet-Draft The Criterion of Session State February 2009 5. 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 15, 2009 [Page 11] 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 15, 2009 [Page 12]