[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

dispatch                                                    G. Camarillo
Internet-Draft                                                J. Maenpaa
Intended status: Standards Track                                Ericsson
Expires: September 9, 2010                                       G. Yang
                                                                     ZTE
                                                           March 8, 2010


Media State under Preconditions in the Session Initiation Protocol (SIP)
                 draft-camarillo-sipping-precons-01.txt

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
   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.

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 9, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Camarillo, et al.       Expires September 9, 2010               [Page 1]


Internet-Draft       Media State under Preconditions          March 2010


   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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Starting Using the Media Parameters Subject to
       Preconditions . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   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  . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



























Camarillo, et al.       Expires September 9, 2010               [Page 2]


Internet-Draft       Media State under Preconditions          March 2010


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, et al.       Expires September 9, 2010               [Page 3]


Internet-Draft       Media State under Preconditions          March 2010


   eventually redesigned in order to have more explicit signalling
   (i.e., offer/answer exchanges) about what addresses were being used
   at the media level.
















































Camarillo, et al.       Expires September 9, 2010               [Page 4]


Internet-Draft       Media State under Preconditions          March 2010


3.  Examples

                    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, et al.       Expires September 9, 2010               [Page 5]


Internet-Draft       Media State under Preconditions          March 2010


                 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, et al.       Expires September 9, 2010               [Page 6]


Internet-Draft       Media State under Preconditions          March 2010


            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

   When the callee finally accepts the addition of the video stream, the
   UAS sends an UPDATE request (12) indicating that the video stream is



Camarillo, et al.       Expires September 9, 2010               [Page 7]


Internet-Draft       Media State under Preconditions          March 2010


   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 issues.  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.


8.  Normative References

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.



Camarillo, et al.       Expires September 9, 2010               [Page 8]


Internet-Draft       Media State under Preconditions          March 2010


              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.


Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com


   Jouni Maenpaa
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Jouni.Maenpaa@ericsson.com


   Gao Yang
   ZTE
   China

   Email: gao.yang2@zte.com.cn














Camarillo, et al.       Expires September 9, 2010               [Page 9]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/