SIPPING G. Camarillo Internet-Draft Ericsson Intended status: Informational March 3, 2009 Expires: September 4, 2009 Media State under Preconditions in the Session Initiation Protocol (SIP) draft-camarillo-sipping-precons-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 4, 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. Abstract In this document, we describe how a UAS (User Agent Server) involved in a session modification can explicitly signal the point where the new session parameters start being used. Explicitly signalling such Camarillo Expires September 4, 2009 [Page 1] Internet-Draft Media State under Preconditions March 2009 a change in the session parameters can be useful so that network intermediaries such as B2BUAs (Back-to-back User Agents) have a clear picture of the session's state at every point. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Starting Using the Media Parameters Subject to Preconditions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Tradeoff between Being Bandwidth Efficient and Having Explicit Signalling . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Camarillo Expires September 4, 2009 [Page 2] Internet-Draft Media State under Preconditions March 2009 1. Introduction The preconditions mechanism in SIP [RFC3261], as specified in RFC 3312 [RFC3312] and RFC 4032 [RFC4032], was designed to allow UAs to reach a common view on the state of the preconditions for a media session. The UAs perform offer/answer exchanges updating each other on the status of their preconditions so that session establishment (in the case of an initial INVITE request) or session modification (in the case of a re-INVITE) can proceed. Once all mandatory preconditions are met, the UAS can proceed with the session establishment or the session modification. 2. Starting Using the Media Parameters Subject to Preconditions Preconditions are stream specific. That is, they apply to the media parameters to be used in a media stream. When the mandatory preconditions for a media stream are met, the UAs can start using the media parameters that were subject to the preconditions. However, the fact that the UAs can start using the new media parameters does not mean that they need to start using them immediately. When preconditions are used, the UAS decides when to start using them. During a session establishment, the UAS can wait for using the media parameters until the callee starts being alerted or until the callee accepts the session. During a session modification, the UAS can wait until the callee accepts the changes to the session. The preconditions specifications do not mandate UAs to perform a new offer/answer exchange when the new media parameters start being used. The UAS starts using them and the UAC discovers that the new media parameters are in use at the media level. In a session modification, the UAC stops using the old media parameters at that point. Discovering when the new media parameters start being used at the media level saves an additional offer/answer exchange. However, network intermediaries such as B2BUAs will not know what the current state of the media session is. Therefore, UASs in environments where intermediaries that require knowledge of the current media state of the session may be present should consider performing such additional offer/answer exchanges. The examples in the following section illustrate this point. Note that ICE faced the same issue when it was being designed. ICE was originally designed in a similar way as the preconditions mechanism. That is, endpoints were supposed to agree on the addresses to use for the session at the media level. ICE was Camarillo Expires September 4, 2009 [Page 3] Internet-Draft Media State under Preconditions March 2009 eventually redesigned in order to have more explicit signalling (i.e., offer/answer exchanges) about what addresses were being used at the media level. 3. Examples Camarillo Expires September 4, 2009 [Page 4] Internet-Draft Media State under Preconditions March 2009 UAC UAS | | |-------------(1) INVITE SDP1--------------->| | | |<------------(2) 200 OK SDP2----------------| | | |------------------(3) ACK------------------>| | | | | |-------------(4) INVITE SDP3--------------->| | | |<------(5) 183 Session Progress SDP4--------| | *** *** | |--*R*-----------(6) PRACK-------------*R*-->| | *E* *E* | |<-*S*-------(7) 200 OK (PRACK)--------*S*---| | *E* *E* | | *R* *R* | | *V* *V* | | *A* *A* | | *T* *T* | | *I* *I* | | *O* *O* | | *N* *N* | | *** *** | | *** | | *** | |-------------(8) UPDATE SDP5--------------->| | | |<--------(9) 200 OK (UPDATE) SDP6-----------| | | |<-----------(10) UPDATE SDP7----------------| | | |--------(11) 200 OK (UPDATE) SDP8---------->| | | | | |<-----------(12) UPDATE SDP9----------------| | | |--------(13) 200 OK (UPDATE) SDP10--------->| | | |<-----------(14) 200 OK (INVITE)------------| | | |------------------(15) ACK----------------->| | | Camarillo Expires September 4, 2009 [Page 5] Internet-Draft Media State under Preconditions March 2009 Figure 1: Acceptance of a video stream by the user The UAs perform an offer/answer exchange to establish an audio only session: SDP1: m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.1 SDP2: m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5 At a later point, the UAC sends a re-INVITE (4) in order to change the IP address where it receives the audio stream to a new IP address and add a video stream to the session. Both media streams are subject to preconditions. SDP3: m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.2 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv m=video 30002 RTP/AVP 31 c=IN IP4 192.0.2.2 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv SDP4 m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv a=conf:qos e2e recv m=video 30002 RTP/AVP 31 c=IN IP4 192.0.2.5 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv a=conf:qos e2e recv When the UAC finishes resource reservations in its 'send' direction, it sends an UPDATE request (8) indicating so. Camarillo Expires September 4, 2009 [Page 6] Internet-Draft Media State under Preconditions March 2009 SDP5: m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.2 a=curr:qos e2e send a=des:qos mandatory e2e sendrecv m=video 30002 RTP/AVP 31 c=IN IP4 192.0.2.2 a=curr:qos e2e send a=des:qos mandatory e2e sendrecv In its response to the UPDATE request (9), the UAS indicates that all preconditions for both media streams are met. SDP6 m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5 a=curr:qos e2e sendrecv a=des:qos mandatory e2e sendrecv m=video 30002 RTP/AVP 31 c=IN IP4 192.0.2.5 a=curr:qos e2e sendrecv a=des:qos mandatory e2e sendrecv The UAS is configured to automatically accept changes in IP addresses. Therefore, it starts using the new remote IP address for the audio stream. In order to explicitly signal this at the SIP level, the UAS sends an UPDATE request (10) removing the preconditions from the audio stream. This indicates that the audio stream is now in use. SDP7 m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5 m=video 30002 RTP/AVP 31 c=IN IP4 192.0.2.5 a=curr:qos e2e sendrecv a=des:qos mandatory e2e sendrecv SDP8: m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.2 m=video 30002 RTP/AVP 31 c=IN IP4 192.0.2.2 a=curr:qos e2e send a=des:qos mandatory e2e sendrecv Camarillo Expires September 4, 2009 [Page 7] Internet-Draft Media State under Preconditions March 2009 When the callee finally accepts the addition of the video stream, the UAS sends an UPDATE request (12) indicating that the video stream is now in use. SDP9 m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5 m=video 30002 RTP/AVP 31 c=IN IP4 192.0.2.5 SDP10: m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.2 m=video 30002 RTP/AVP 31 c=IN IP4 192.0.2.2 4. Tradeoff between Being Bandwidth Efficient and Having Explicit Signalling In order to have explicit SIP signalling about the media-level state, UAs need to perform more offer/answer exchanges. Those offer/answer exchanges consume bandwidth. For instance, in the previous example, the price to pay for having explicit SIP signalling was the last two UPDATE transactions. UAs should consider this tradeoff when deciding how to behave in a particular network setting. 5. Security Considerations This document does not introduce any new security issue. Security issues related to preconditions are discussed in RFC 3312 [RFC3312] and RFC 4032 [RFC4032]. 6. IANA Considerations There are no IANA actions associated with this document. 7. Acknowledgements Paul Kyzivat, Christer Holmberg, and Yang Gao provided useful ideas on the topics discussed in this document. Camarillo Expires September 4, 2009 [Page 8] Internet-Draft Media State under Preconditions March 2009 8. Normative References [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. [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. Author's Address Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Camarillo Expires September 4, 2009 [Page 9]