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

Versions: 00

MMUSIC Working Group                                        J. Lindquist
Internet-Draft                                                J. Maenpaa
Intended status: Informational                                  Ericsson
Expires: December 18, 2009                                  P. Rajagopal
                                                                Motorola
                                                               X. Marjou
                                                          France Telecom
                                                           June 16, 2009


                       SIP/SDP Overlap with RTSP
                 draft-lindquist-mmusic-sip-rtsp-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 December 18, 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.





Lindquist, et al.       Expires December 18, 2009               [Page 1]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


Abstract

   The Session Initiation Protocol (SIP) is widely used for establishing
   multimedia sessions, whereas the Real Time Streaming Protocol (RTSP)
   is a protocol for use in streaming media systems.  RTSP has a dual
   role: it establishes a media session for the delivery of streaming
   media as well as controls the streaming session once it has been set
   up.  Since RTSP is also used for session establishment, there exists
   an overlap between the functionality provided by SIP and RTSP.  In
   this document, we analyze a model in which SIP and the SDP offer/
   answer model are used to set up a streaming session with an RTSP
   control channel and one or more media delivery streams.  Such a model
   is beneficial since it allows the reuse of current architecture and
   functionality (e.g., authentication, charging, and QoS) established
   around SIP also for RTSP-based streaming.




































Lindquist, et al.       Expires December 18, 2009               [Page 2]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Split Architectures  . . . . . . . . . . . . . . . . . . . . .  5
   4.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Reuse of Existing Architecture and its Functionality . . .  6
     4.2.  Advanced Media Applications  . . . . . . . . . . . . . . .  7
     4.3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Problem Background . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Session Establishment  . . . . . . . . . . . . . . . . . .  8
     5.2.  Session Modification . . . . . . . . . . . . . . . . . . . 10
     5.3.  Session Termination  . . . . . . . . . . . . . . . . . . . 12
   6.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Content Control Protocol Accessing Resources
           Established by Session Management Protocol . . . . . . . . 13
     6.2.  Use of Transport Addresses in Content Control and
           Session Management Protocols . . . . . . . . . . . . . . . 13
     6.3.  Session Termination  . . . . . . . . . . . . . . . . . . . 14
   7.  Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Alternative 1: Full RTSP . . . . . . . . . . . . . . . . . 15
       7.1.1.  Session Establishment  . . . . . . . . . . . . . . . . 15
       7.1.2.  Session Termination  . . . . . . . . . . . . . . . . . 18
       7.1.3.  Identified Issues and Potential Solutions  . . . . . . 19
     7.2.  Alternative 2: Lightweight RTSP without Session Setup
           Semantics  . . . . . . . . . . . . . . . . . . . . . . . . 20
       7.2.1.  Session Establishment  . . . . . . . . . . . . . . . . 21
       7.2.2.  Session Termination  . . . . . . . . . . . . . . . . . 22
       7.2.3.  Solutions to the Identified Issues . . . . . . . . . . 23
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
     9.1.  Man-in-the-middle Attack . . . . . . . . . . . . . . . . . 25
     9.2.  Session Hijacking  . . . . . . . . . . . . . . . . . . . . 25
     9.3.  Privacy Considerations . . . . . . . . . . . . . . . . . . 25
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     11.2. Informative References . . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27












Lindquist, et al.       Expires December 18, 2009               [Page 3]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


1.  Introduction

   The Session Initiation Protocol (SIP) [RFC3261] is a widely-used
   session establishment and rendezvous protocol.  Many existing systems
   have established mechanisms such as authentication, charging, and
   Quality of Service (QoS) around SIP.  The Real Time Streaming
   Protocol (RTSP) [RFC2326], [I-D.ietf-mmusic-rfc2326bis], in turn, is
   a protocol for use in streaming media systems.  RTSP allows a client
   to remote control a streaming media server by issuing commands such
   as PLAY and PAUSE.  RTSP has a dual role: it establishes a media
   session for the delivery of streaming media as well as controls the
   streaming session once it has been set up.  Since RTSP is also used
   for session establishment, there exists an overlap between the
   functionality provided by SIP and RTSP.

   When using RTSP in systems that have established mechanisms such as
   authentication, charging, and QoS around SIP, one needs to implement
   these mechanisms for RTSP as well.  In this document, we argue that
   it would be more efficient to reuse the mechanisms that already exist
   for SIP.  Therefore, we analyze a model in which SIP is used to
   establish the streaming session.  In this model, SIP with SDP offer/
   answer exchange [RFC3264] is used to set up an RTSP media control
   channel and one or more media delivery streams.  The media delivery
   streams can be for instance Real Time Protocol (RTP) streams.  Thus,
   in this approach, RTSP is used to control the media streams that have
   been set up with SIP.

   It should be noted that a model in which SIP and SDP offer/answer
   exchange is used to establish a control channel is by no means a new
   one.  As an example, SIP with SDP offer/answer is used to establish a
   Binary Floor Control Protocol (BFCP) [RFC4582] control channel in
   floor controlled conferences [RFC4583].  BFCP is a protocol used to
   arbitrate access to shared resources (e.g., media streams) in a
   conference.

   An example of a network that has established mechanisms such as
   authentication, charging and QoS around SIP, and which uses also
   RTSP, is the IPTV system defined by ETSI TISPAN [ETSI TS 183 063].
   ETSI TISPAN uses a model in which SIP is used to establish an RTSP
   content control channel.  The TISPAN specifications allow for both
   full and partial support of the RTSP RFC [RFC2326] as part of the
   IPTV service.  In the case of partial support of RTSP, a lightweight
   version of RTSP without session setup semantics is used, whereas in
   the full support scenario, full RTSP with session setup semantics is
   used.  In addition to TISPAN, also the 3rd Generation Partnership
   Project (3GPP) [3GPP TS 26.237] and the Open IPTV Forum (OIPF) [OIPF
   Volume 4] have specified a model in which SIP is used to establish an
   RTSP control channel.



Lindquist, et al.       Expires December 18, 2009               [Page 4]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   The objective of this document is to create a discussion within the
   MMUSIC working on how to best support RTSP-based media servers and
   clients in SIP/SDP-based networks.  The rest of the document is
   structured as follows.  In Section 3, we discuss architecture and
   functionality reuse as the main motivation for SIP/RTSP interaction.
   Section 4 describes split architectures composed of a controller and
   a media server.  In Section 5, we describe the background for the
   problem.  Section 6 states some requirements for a solution that uses
   separate protocols to establish a session and control the delivery of
   streaming media.  In Section 7, we present possible solutions that
   fulfill the requirements stated in Section 6.  Finally, Section 8
   concludes the document.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


   Content Control Protocol  We use the term content control protocol to
      refer to the protocol that is used to control the delivery of
      media streams.  An example of such a protocol is the Real Time
      Streaming Protocol (RTSP).

   Session Management Protocol  Session management protocol is the
      protocol that is used to establish content delivery streams and
      the control channel for the content control protocol.

   Content Delivery Protocol  The content delivery protocol is used for
      delivering content (e.g., media streams).

   Trick Play  Trick play refers to using controls such as pause, fast
      forward, rewind, slow-motion, etc.



3.  Split Architectures

   The systems considered in this document use a split (i.e., layered)
   architecture composed of a controller and a media server.  We are
   using such a generalized architecture to be able to cover different
   standardized SIP-based architectures for media and IPTV.  The media
   server is among other things responsible for storing media,
   delivering media flows to users, and transcoding content to different
   media formats.  The controller, in turn, provides user
   authentication, charging, resource reservation, checking user



Lindquist, et al.       Expires December 18, 2009               [Page 5]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   services, and keeping track of streaming (e.g., for keeping
   bookmarks), among other things.

   The expectation is that the controller does not only authenticate
   users and access to services, but is also able to monitor the session
   with the media server.  The controller may also use a URL to create a
   dynamic playlist on the media server.

   We refer to the protocol that is used between a user equipment (UE)
   and the controller for establishing content delivery stream(s) and a
   content control channel as the session management protocol.  This
   protocol is responsible for carrying information related to client
   authentication, charging, and resource reservation, among other
   things.  Between the UE and the media server, a content control
   protocol is used for the purpose of controlling content delivery.
   The protocol that is used between the UE and the media server for
   content delivery is referred to as the content delivery protocol.  In
   this document, we do not define which protocol is used on the
   interface between the controller and the media server.  Instead, we
   are using generic commands such as "create session", "modify
   session", and "destroy session" in the signaling flows.


4.  Motivation

4.1.  Reuse of Existing Architecture and its Functionality

   The main motivation for using SIP/SDP to establish an RTSP control
   channel is that it makes possible to reuse existing SIP mechanisms
   and architecture without the need to implement them for RTSP as well.
   Examples include authentication, authorization, accounting, security,
   and network resource management (QoS).

   Many architectures have established Authentication, Authorization,
   and Accounting (AAA) mechanisms around SIP.  An interface to AAA
   infrastructure for SIP servers is defined in RFC 4740 [RFC4740].  The
   Diameter SIP application specified in the RFC can be used to
   authenticate and authorize the usage of SIP-based multimedia
   services.  SIP has also been extended to carry charging information
   [RFC3455].  If SIP is used to establish RTSP-controlled media
   streams, the existing AAA interface can be used to authenticate and
   authorize the usage of streaming services and to do accounting.

   Many systems have also established QoS around SIP.  It is possible to
   negotiate the QoS mechanism to use for a particular media stream
   using SIP/SDP, as described in RFC 5432 [RFC5432].  Also resource
   management and SIP have been integrated [RFC3312].  The way QoS
   admission control is integrated with SIP and how a SIP proxy



Lindquist, et al.       Expires December 18, 2009               [Page 6]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   interfaces with QoS policy control is described in RFC 3313
   [RFC3313].  RTSP-controlled media streams could greatly benefit from
   the QoS mechanisms established around SIP.

   Certain SIP architectures use SIP Application Level Gateways (ALGs)
   such as Session Border Controllers (SBCs)
   [I-D.ietf-sipping-sbc-funcs] between the access network and a SIP
   core network or between two SIP core networks.  The SIP/RTSP model
   proposed in this document makes it possible to reuse this security
   infrastructure for RTSP-based streaming.

   The use of SIP to establish RTSP-controlled content delivery streams
   could make endpoint-hosted streaming easier.  The content that a user
   wants to stream may be stored on a remote user device located behind
   Network Address Translator (NAT).  However, if the remote device is
   running a SIP application and the user of the remote device has
   registered from the device to a SIP proxy, the connection that the
   remote device maintains to its SIP proxy can be used to send a SIP
   INVITE with SDP payload describing an RTSP control channel and
   content delivery stream(s) to the remote device.  This way the remote
   content can be streamed even if the remote device is located behind a
   NAT without requiring new infrastructure.

4.2.  Advanced Media Applications

   Closer interaction between SIP and RTSP would also enable service
   blending as in the case of an IPTV system wherein information about
   content being viewed can be shared via presence service or the users
   can chat about an ongoing program with instant messaging.  Also other
   "watching apart together" scenarios would become possible.  The
   ability to transfer a Content on Demand (CoD) session from one
   terminal to another is another example.

4.3.  Use Cases

   Use cases motivating SIP/RTSP interaction are discussed in an expired
   Internet-Draft "Media Playback Control Protocol Requirements"
   [I-D.ietf-whitehead-mmusic-sip-for-streaming-media].


5.  Problem Background

   The purpose of this section is to describe the high level procedures
   required to deliver multimedia streaming content within the
   architectural framework described in Section 3.  The procedures are
   comprised of three main phases - session establishment, session
   modification, and session termination.




Lindquist, et al.       Expires December 18, 2009               [Page 7]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   The figures in this section include an optional middlebox [RFC3234]
   element, since in some environments, there might be an Application
   Level Gateway (ALG), firewall or Network Address Translator (NAT)
   device located between the UE and the controller.

5.1.  Session Establishment

   Figure 1 illustrates on a high level the main stages of using the
   session management protocol to establish the media stream protocol
   control channel and the content delivery streams.









































Lindquist, et al.       Expires December 18, 2009               [Page 8]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


     +----+    +-------------+   +------------+         +--------------+
     | UE |    | (Middlebox) |   | Controller |         | Media server |
     +----+    +-------------+   +------------+         +--------------+
        |             |                 |                       |
        | (1) Session establishment,    |                       |
        | session management protocol   |                       |
        |------------>|---------------->|                       |
        |             |                 |                       |
        |             |           /-----------\                 |
        |             |          /(2) Resource \                |
        |             |          \ reservation /                |
        |             |           \-----------/                 |
        |             |                 |                       |
        |             |           /-----------\                 |
        |             |          / (3) Select  \                |
        |             |          \ media server/                |
        |             |           \-----------/                 |
        |             |                 |  (4) Create session   |
        |             |                 |---------------------->|
        |             |                 |       (5) OK          |
        |            (6) OK             |<----------------------|
        |<------------|<----------------|                       |
        |             |                 |                       |
        |             |  (7) Session establishment, content     |
        |             |      control protocol                   |
        |------------>|---------------------------------------->|
        |             |  (8) OK         |                       |
        |<------------|<----------------------------------------|
        |             |           /-----------\                 |
        |             |          /(9) Resource \                |
        |             |          \    commit   /                |
        |             |           \-----------/                 |
        |             |                 |                       |
        |             |  (10) Media control command             |
        |------------>|---------------------------------------->|
        |             |  (11) OK        |                       |
        |<------------|<----------------------------------------|
        |             |                 |                       |
        |             |  (12) Media     |                       |
        |<============|<========================================|
        |             |                 |                       |

                      Figure 1: Session Establishment

   The steps in the signaling flow are as follows:






Lindquist, et al.       Expires December 18, 2009               [Page 9]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   1.   The UE uses the session management protocol to establish a
        session with the controller.  The session has at least two
        streams, one for media control and one or more for media
        transmission.
   2.   The controller reserves resources for the control channel and
        media streams.
   3.   The controller selects an appropriate media server.
   4.   The controller orders the media server to create a streaming
        session.
   5.   The media server returns a success response to the controller.
   6.   The controller returns a success response to the UE.
   7.   The resource reservation is committed.
   8.   The UE sends a content control protocol request to the media
        server to trigger content control protocol session
        establishment.  It should be noted that this step is only needed
        if the content control protocol contains session setup
        semantics.
   9.   The media server returns a success response to the UE.
   10.  The UE sends a content control command to the media server.
   11.  The media server sends a success response to the content control
        protocol request back to the UE.
   12.  The media stream is sent to the client.

5.2.  Session Modification

   This section illustrates how a media delivery session is modified.
   Session modification may be necessary for instance in the context of
   an IPTV service when the user pauses an ongoing broadcasted program
   (i.e., issues trick play commands).  Such an IPTV service is defined
   in [ETSI TS 183 063].  Two special use cases that exist for a
   broadcast session with trick play are discussed below.  By trick
   play, we mean commands such as pause, fast forward, rewind, slow-
   motion, etc.

   o  The broadcast session is modified to change from multicast to
      unicast flow.  This occurs when the UE activates the trick play
      mode (e.g., pause or rewind).  The same session is used so that
      the existing resource reservations can be used for the unicast
      flow.  If the session management protocol request that is used to
      modify the session fails, the broadcast session is kept.
   o  The broadcast session with trick play mode is modified to return
      to normal broadcast TV.  This happens when the UE deactivates the
      trick play mode by for instance switching from a paused channel to
      another live broadcast TV channel.

   The case in which a broadcast session is modified to change from
   multicast to unicast is illustrated in Figure 2.




Lindquist, et al.       Expires December 18, 2009              [Page 10]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


     +----+    +-------------+   +------------+         +--------------+
     | UE |    | (Middlebox) |   | Controller |         | Media server |
     +----+    +-------------+   +------------+         +--------------+
        |             |                 |                       |
        | (1) Session modification      |                       |
        | request, session management   |                       |
        | protocol    |                 |                       |
        |------------>|---------------->|                       |
        |             |                 |                       |
        |             |           /-----------\                 |
        |             |          /(2) Resource \                |
        |             |          \ reservation /                |
        |             |           \-----------/                 |
        |             |                 |                       |
        |             |           /-----------\                 |
        |             |          / (3) Select  \                |
        |             |          \ media server/                |
        |             |           \-----------/                 |
        |             |                 |  (4) Modify session   |
        |             |                 |---------------------->|
        |             |                 |        (5) OK         |
        |            (6) OK             |<----------------------|
        |<------------|<----------------|                       |
        |             |           /-----------\                 |
        |             |          /(7) Resource \                |
        |             |          \    commit   /                |
        |             |           \-----------/                 |
        |             |                 |                       |
        |    (8) Content control protocol trick play command    |
        |------------>|---------------------------------------->|
        |             |        (9) OK   |                       |
        |<------------|<----------------------------------------|
        |             |                 |                       |

                      Figure 2: Session Modification

   The steps in Figure 2 are as follows:

   1.  Upon activation of trick play mode, the UE performs session
       modification by sending a session management protocol session
       modification request to the controller, as shown in step (1) of
       Figure 2.
   2.  The controller receives additional resources for the media
       streams according to the session modification request.
   3.  The controller selects a media server.
   4.  The controller orders the media server to modify the session.





Lindquist, et al.       Expires December 18, 2009              [Page 11]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   5.  The media server returns a success response to the controller.
   6.  The controller returns a session management protocol OK response
       to the UE.
   7.  The controller commits the reservation.
   8.  The UE starts trick-mode playback by issuing a content control
       protocol request.
   9.  The media server returns an content control protocol OK response.

5.3.  Session Termination

   Figure 3 shows on a high level how media streams and the session are
   terminated.

     +----+    +-------------+   +------------+         +--------------+
     | UE |    | (Middlebox) |   | Controller |         | Media server |
     +----+    +-------------+   +------------+         +--------------+
        |             |                 |                       |
        |             |          Media  |                       |
        |<============|<========================================|
        |             |      (1) Media teardown                 |
        |------------>|---------------------------------------->|
        |             |                 |                       |
        |             |      (2) Media stream(s) terminated     |
        |             |                 |                       |
        |             |      (3) OK     |                       |
        |<------------|<----------------------------------------|
        |             |                 |                       |
        |   (4) Session termination     |                       |
        |------------>|---------------->|                       |
        |             |           /-----------\                 |
        |             |          /(5) Resource \                |
        |             |          \   release   /                |
        |             |           \-----------/                 |
        |             |                 | (6) Destroy session   |
        |             |                 |---------------------->|
        |             |                 |         (7) OK        |
        |            (8) OK             |<----------------------|
        |<------------|<----------------|                       |
        |             |                 |                       |

                       Figure 3: Session Termination

   The steps in the signaling flow are as follows:

   1.  The UE uses the content control protocol to tear down the media
       stream(s).  It should be noted that this step is only needed if
       the content control protocol contains session teardown semantics.




Lindquist, et al.       Expires December 18, 2009              [Page 12]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   2.  The media server stops sending the media stream(s).
   3.  The media server returns a content control protocol success
       response to the UE.
   4.  The UE uses the session management protocol to terminate the
       session.
   5.  The controller releases the resources that have been reserved for
       the media stream(s) and the media control channel.
   6.  The controller orders the media server to destroy the session.
   7.  The media server returns a success response to the controller.
   8.  The controller returns a session management protocol success
       response to the UE.


6.  Requirements

   Based on the signaling flows shown in Section 5, this section
   identifies some requirements for a solution that uses a session
   management protocol to establish a control channel for a content
   control protocol and one or more media streams for content delivery.

6.1.  Content Control Protocol Accessing Resources Established by
      Session Management Protocol

   REQ-1  The content control protocol needs to be able to access and
      use resources that have been configured and established by the
      session management protocol.

   Different protocols are used for setting up the media streams and for
   controlling media stream delivery.  Thus, there needs to be a way for
   the content control protocol to refer to the media streams that were
   set up using the session management protocol.

6.2.  Use of Transport Addresses in Content Control and Session
      Management Protocols

   REQ-2  The session management protocol is responsible for negotiating
      media transport related information.

   The content control protocol and the media stream delivery protocol
   should use the transport addresses that were negotiated for the media
   streams and content control channel by the session management
   protocol.  If these addresses need to be changed, the change must be
   negotiated using the session management protocol.

   Since different protocols are used for session establishment and
   media stream control, both protocol stacks need to have the same view
   on the local and remote transport addresses used for the media
   streams and the control channel.  Therefore, content control protocol



Lindquist, et al.       Expires December 18, 2009              [Page 13]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   messages should be sent to the transport addresses negotiated by the
   session management protocol and edia should be sent to the transport
   addresses negotiated during session establishment.

   Additional problems may arise if the content control protocol is used
   to redirect the client to connect to another media server.  The main
   issue with redirection is middleboxes.  A middlebox inspects the
   information carried in the session management protocol so that it can
   open pinholes for the content delivery streams and for the content
   control channel.  The middlebox may not inspect the content control
   protocol messages sent on the content control channel.  Thus, if the
   media server uses the content control protocol to redirect the UE to
   connect to another media server, the middlebox state may not get
   updated.  As a result, the media streams sent by the new media server
   might never reach the UE (or the UE may not even be able to contact
   the new media server).

6.3.  Session Termination

   REQ-3  The session management protocol and the content control
      protocol need to perform session termination in a coordinated way.

   This kind of coordination is required to make sure that the session
   management protocol will not release resources in the network before
   the content control protocol has successfully terminated the media
   streams.  Therefore, media teardown procedures should be carried out
   before the session management protocol is used to terminate the
   session.  Alternatively, if the content control protocol is not used
   to terminate the media streams, but only the session management
   protocol is, the above-mentioned coordination is not necessary.


7.  Possible Solutions

   In order to better understand the issues with the reuse of existing
   architectures and support of a split architecture, this section
   provides an analysis of existing systems specified by standardization
   bodies such as ETSI TISPAN and 3GPP.  In the remainder of the
   document, we will assume that the session management protocol is SIP
   and that the content control protocol is RTSP.  The analysis shows
   the interaction between SIP/SDP and RTSP protocols for these systems
   and provides alternatives for how RTSP protocol support is supported.
   The objective is to expose the issues to MMUSIC WG and determine
   whether the MMUSIC WG considers this work interesting and if so, what
   should be the next steps to achieve better SIP and RTSP interaction.

   In this section, we present two alternative solutions that fulfill
   the requirements stated in Section 6.  In both of the solutions, SIP/



Lindquist, et al.       Expires December 18, 2009              [Page 14]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   SDP is used to establish an RTSP control stream and one or more
   content delivery streams.  In the first alternative, the UE uses full
   RTSP, whereas in the second alternative, the UE uses RTSP without
   session setup semantics.

7.1.  Alternative 1: Full RTSP

7.1.1.  Session Establishment

   The signaling flow in Figure 4 illustrates how proposed IPTV and
   streaming systems (e.g., TISPAN) use SIP to set up an RTSP content
   control channel and RTP content delivery channel(s) in the context of
   a Content on Demand (CoD) service.  The figure is a generalized
   version of the signaling flow specified in [ETSI TS 183 063].





































Lindquist, et al.       Expires December 18, 2009              [Page 15]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


     +----+    +-------------+   +------------+         +--------------+
     | UE |    | (Middlebox) |   | Controller |         | Media server |
     +----+    +-------------+   +------------+         +--------------+
        |             |                 |                       |
        |          (1) INVITE           |                       |
        |------------>|---------------->|                       |
        |             |                 |                       |
        |             |           /-----------\                 |
        |             |          /(2) Resource \                |
        |             |          \ reservation /                |
        |             |           \-----------/                 |
        |             |                 |                       |
        |             |           /-----------\                 |
        |             |          / (3) Select  \                |
        |             |          \ media server/                |
        |             |           \-----------/                 |
        |             |                 |  (4) Create session   |
        |             |                 |---------------------->|
        |             |                 |       (5) OK          |
        |          (6) 200 OK (INVITE)  |<----------------------|
        |<------------|<----------------|                       |
        |             |           /-----------\                 |
        |             |          /(7) Resource \                |
        |             |          \    commit   /                |
        |             |           \-----------/                 |
        |             |                 |                       |
        |          (8) ACK              |                       |
        |------------>|---------------->|                       |
        |             |  (9) SETUP      |                       |
        |------------>|---------------------------------------->|
        |             |  (10) 200 OK (SETUP)                    |
        |<------------|<----------------------------------------|
        |             |  (11) PLAY      |                       |
        |------------>|---------------------------------------->|
        |             |  (12) 200 OK (PLAY)                     |
        |<------------|<----------------------------------------|
        |             |  (13) RTP       |                       |
        |<============|<========================================|
        |             |                 |                       |

          Figure 4: RTSP Control Stream Established Using SIP/SDP

   The steps in the signaling flow are as follows:

   1.   The UE sends a SIP INVITE request to the controller to set up at
        least two streams, one for RTSP control and one or more for
        media transmission.  If there is a firewall or SIP ALG between
        the UE and the controller, it forwards the INVITE and inspects



Lindquist, et al.       Expires December 18, 2009              [Page 16]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


        the SDP offer included in the INVITE in order to be able to open
        pinholes for the streams.  It is assumed that the client already
        knows what resources (i.e., media streams) are associated with
        the content it is requesting to view.
   2.   The controller reserves resources for the RTSP and RTP streams.
   3.   The controller selects an appropriate media server.
   4.   The controller orders the media server to create a streaming
        session.
   5.   The media server returns a success response to the controller.
   6.   The controller sends a SIP 200 OK (INVITE) response to the UE.
        The SDP answer included in the response contains an RTSP URL.
   7.   The resource reservation is committed.
   8.   The UE returns an ACK to the controller.
   9.   The UE sends an RTSP SETUP to the media server to trigger RTSP
        session initiation.  The UE learned the server IP address and
        port for RTSP since the controller returned them in the SDP
        answer included in the SIP INVITE 200 OK response.  The RTSP URL
        is set to the URL returned in the SDP answer.
   10.  RTSP 200 OK for RTSP SETUP is sent back to the UE.  The RTSP
        network parameters exchanged in the SETUP request and response
        are the same as the RTSP network parameters agreed during the
        SDP offer/answer exchange.  The UE should store the Session
        header included in the response for issuing the RTSP PLAY
        request.
   11.  The UE sends an RTSP PLAY request to the media server.  The RTSP
        URL header is set to the URL returned in the SDP answer.
   12.  The media server sends an RTSP 200 OK for RTSP PLAY back to the
        UE.
   13.  The RTP stream is sent to the client IP address indicated by the
        SDP offer and RTSP SETUP.

   On sending the RTSP SETUP request, the UE populates the RTSP URL
   header and determines the destination transport address (by transport
   address, we refer to IP address and transport protocol port number)
   as follows: as described above, the RTSP URL header is set to the
   corresponding media RTSP URL which has been obtained in the SDP
   answer from the controller.  If the RTSP URL contains a domain
   address, the UE should not perform a DNS lookup.  Instead, the target
   transport address of the RTSP SETUP message should be set to contain
   the IP address included in the connection line ("c=") of the SDP
   answer and the port specified in the media line ("m=") of the RTSP
   control stream.

   The media server acts as defined in [RFC2326].  The media server must
   not redirect the RTSP methods using either the REDIRECT method or
   Redirection status code (3xx).  Redirection is not allowed in order
   to avoid misaligning the information conveyed in the SDP.  The
   problem occurs if the redirected URL differs from the address and



Lindquist, et al.       Expires December 18, 2009              [Page 17]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   port conveyed in the SDP connection and media lines.  This is because
   SIP is used for opening proxies and firewalls for the content control
   and the content delivery paths.

7.1.2.  Session Termination

   The figure below illustrates how a streaming session is terminated in
   [ETSI TS 183 063].

     +----+    +-------------+   +------------+         +--------------+
     | UE |    | (Middlebox) |   | Controller |         | Media server |
     +----+    +-------------+   +------------+         +--------------+
        |             |                 |                       |
        |             |      RTP stream |                       |
        |<============|<========================================|
        |             |      (1) TEARDOWN                       |
        |------------>|---------------------------------------->|
        |             |                 |                       |
        |             |      (2) RTP stream terminated          |
        |             |                 |                       |
        |             |      (3) 200 OK (TEARDOWN)              |
        |<------------|<----------------------------------------|
        |             |                 |                       |
        |            (4) BYE            |                       |
        |------------>|---------------->|                       |
        |             |           /-----------\                 |
        |             |          /(5) Resource \                |
        |             |          \   release   /                |
        |             |           \-----------/                 |
        |             |                 | (6) Destroy session   |
        |             |                 |---------------------->|
        |             |                 |         (7) OK        |
        |          (8) 200 OK (BYE)     |<----------------------|
        |<------------|<----------------|                       |
        |             |                 |                       |

                       Figure 5: Session Termination

   The steps in the signaling flow are as follows:

   1.  The UE sends an RTSP TEARDOWN request to the media server.
   2.  The media server stops sending the RTP content stream(s).
   3.  The media server returns a 200 OK (TEARDOWN) response to the UE.
   4.  The UE sends a SIP BYE request to the controller.
   5.  The controller releases the resources that have been reserved for
       the RTP and RTSP streams.





Lindquist, et al.       Expires December 18, 2009              [Page 18]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   6.  The controller orders the media server to destroy the session.
   7.  The media server returns a success response to the controller.
   8.  The controller returns a SIP 200 OK (BYE) response to the UE.

7.1.3.  Identified Issues and Potential Solutions

   In this section, we discuss some issues with the signaling flows
   shown in the figures above.

7.1.3.1.  Correlating SIP INVITE and RTSP SETUP

   Correlating the SIP INVITE transaction and the RTSP SETUP request may
   be problematic since there is no session identifier.  Also, there is
   no special IP address and port that would be unique to the session.

   To solve this problem, either the RTSP URL returned in the SDP answer
   needs to convey correlation information (as specified in [ETSI TS 183
   063]) or a session ID parameter needs to be added to the RTSP SETUP
   request in order to correlate the RTSP SETUP and SIP INVITE requests.

7.1.3.2.  DNS lookup for RTSP URL

   As explained above, the UE should not perform a DNS lookup for the
   RTSP URL that the controller returns in the SDP answer.  Otherwise
   there is a risk that a different destination transport address than
   was returned in the SDP answer will be used for RTSP messages sent to
   the media server.

   Also, if the server IP address for RTSP signaling changes from the
   one negotiated during SDP offer/answer exchange and the UE is located
   behind a middlebox, the middlebox may drop the packets sent to the
   new server address.

   To solve this issue, either the RTSP URL returned in the SDP answer
   has to include an IP address and port or the UE needs to use the
   server IP address and port returned in the SDP answer (in "c=" and
   "m=" lines) for the RTSP control channel as the destination address
   for RTSP messages.

7.1.3.3.  Redirection

   The media server should not perform redirection for the RTSP SETUP
   request.  The redirection has to be already known prior to the RTSP
   SETUP since the SDP answer for the SIP INVITE response needs to
   contain the final destination of the media server.

   If there is a SIP ALG between the UE and the controller, the SIP ALG
   opens pinholes for the media delivery stream(s) based on the



Lindquist, et al.       Expires December 18, 2009              [Page 19]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   information conveyed in the SDP offer/answer exchange.  If an RTSP
   REDIRECT request or Redirection status code is later issued on the
   RTSP control channel, the SIP ALG may never learn the address of the
   new server.  This is because the SIP ALG may not inspect RTSP
   messages.  The result is that new pinholes will not be opened for the
   RTSP control channel and the media delivery stream(s) coming from the
   new server.

   Because of the above-mentioned problems, no redirection should be
   allowed.

7.1.3.4.  Correlating Transport Address in SDP Offer with Transport
          Header in SETUP

   The Transport header of the RTSP SETUP request must contain the same
   information as the SDP offer in the SIP INVITE request.  The problem
   is how to ensure that a client with separate SIP and RTSP stacks can
   keep the same client IP address and port without affecting the
   implementation of the stacks.

   To solve this issue, addresses must be used consistently between SIP
   INVITE SDP offer and RTSP SETUP transport header.

7.1.3.5.  SIP BYE and RTSP TEARDOWN

   Teardown of the streaming session will not always be possible
   according to the procedures defined in [RFC2326].  This is because
   the UE may not be able to send an RTSP TEARDOWN request or receive a
   response to TEARDOWN request if the resources in the network for the
   RTSP session have been released when receiving the SIP BYE request.

   To address this issue, SIP session termination and RTSP session
   termination must be carried out in a coordinated way.  When using
   both SIP BYE and RTSP TEARDOWN, the media teardown procedures using
   RTSP TEARDOWN should be executed before the SIP BYE request is sent.

   An additional issue is that there may be more nodes than the two end-
   points that normally exist in RTSP that can initiate session
   termination, for example SIP Back-to-Back User Agents (B2BUAs).

   As a solution, SIP session termination and RTSP session termination
   must be carried out in a coordinated way.

7.2.  Alternative 2: Lightweight RTSP without Session Setup Semantics

   In the signaling flows shown in the figures below, a lightweight
   version of RTSP without session setup semantics is used to control
   media streams that have been set up using SIP/SDP.



Lindquist, et al.       Expires December 18, 2009              [Page 20]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


7.2.1.  Session Establishment

   Figure 6 illustrates how a session is established when a lightweight
   RTSP without session setup and teardown semantics is used.

     +----+    +-------------+   +------------+         +--------------+
     | UE |    | (Middlebox) |   | Controller |         | Media server |
     +----+    +-------------+   +------------+         +--------------+
        |             |                 |                       |
        |          (1) INVITE           |                       |
        |------------>|---------------->|                       |
        |             |                 |                       |
        |             |           /-----------\                 |
        |             |          /(2) Resource \                |
        |             |          \ reservation /                |
        |             |           \-----------/                 |
        |             |                 |                       |
        |             |           /-----------\                 |
        |             |          / (3) Select  \                |
        |             |          \ media server/                |
        |             |           \-----------/                 |
        |             |                 |  (4) Create session   |
        |             |                 |---------------------->|
        |             |                 |         (5) OK        |
        |          (6) 200 OK (INVITE)  |<----------------------|
        |<------------|<----------------|                       |
        |             |           /-----------\                 |
        |             |          /(7) Resource \                |
        |             |          \    commit   /                |
        |             |           \-----------/                 |
        |             |                 |                       |
        |          (8) ACK              |                       |
        |------------>|---------------->|                       |
        |             |  (9) PLAY       |                       |
        |------------>|---------------------------------------->|
        |             |  (10) 200 OK (PLAY)                     |
        |<------------|<----------------------------------------|
        |             |  (11) RTP       |                       |
        |<============|<========================================|
        |             |                 |                       |

              Figure 6: RTSP without Session Setup Semantics

   The steps in the signaling flow are as follows:

   1.   The UE sends a SIP INVITE request to the controller to set up at
        least two streams, one for RTSP control and one or more for
        media transmission.  The SDP offer included in the INVITE



Lindquist, et al.       Expires December 18, 2009              [Page 21]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


        contains a media description for the RTSP content control
        channel and one or more media descriptions for the content
        delivery channels.  It is assumed that the client already knows
        what resources (i.e., media streams) are associated with the
        content it is requesting to view.
   2.   The controller reserves resources for the RTSP and RTP streams.
   3.   The controller selects an appropriate media server.
   4.   The controller orders the media server to create a streaming
        session.
   5.   The media server returns a success response to the controller.
   6.   The controller returns a SIP 200 OK response to the UE.  The SDP
        answer included in the response contains an RTSP session ID
        parameter.  The SDP answer also contains a media description for
        the RTSP content control channel and one or more media
        descriptions for the content delivery channels.
   7.   The resource reservation is committed.
   8.   The UE returns a SIP ACK to the controller.
   9.   The UE sends an RTSP PLAY request to the media server.  The UE
        knows the server IP address and port for RTSP since the
        controller returned them in the SIP INVITE 200 OK response.  The
        session ID parameter the server returned in the SDP answer is
        included in the Session header of the request.
   10.  The media server sends a 200 OK response to RTSP PLAY request
        back to the UE.
   11.  The RTP stream is sent to the client IP address indicated in the
        SDP offer.

7.2.2.  Session Termination

   Figure 7 illustrates how a session is terminated when a lightweight
   RTSP without session setup and teardown semantics is used.




















Lindquist, et al.       Expires December 18, 2009              [Page 22]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


     +----+    +-------------+   +------------+         +--------------+
     | UE |    | (Middlebox) |   | Controller |         | Media server |
     +----+    +-------------+   +------------+         +--------------+
        |             |                 |                       |
        |             |      RTP stream |                       |
        |<============|<========================================|
        |             |                 |                       |
        |            (1) BYE            |                       |
        |------------>|---------------->|                       |
        |             |                 |                       |
        |             |                 | (2) Destroy session   |
        |             |                 |---------------------->|
        |             |                 |                       |
        |             |  (3) RTP stream terminated              |
        |             |                 |                       |
        |             |                 |         (4) OK        |
        |             |                 |<----------------------|
        |             |                 |                       |
        |             |           /-----------\                 |
        |             |          /(5) Resource \                |
        |             |          \   release   /                |
        |             |           \-----------/                 |
        |       (6) 200 OK (BYE)        |                       |
        |<------------|<----------------|                       |
        |             |                 |                       |

                       Figure 7: Session Termination

   The steps in the signaling flow of Figure 7 are described below:

   1.  The UE sends a SIP BYE request to the controller to terminate the
       session and to tear down the media stream(s).
   2.  The controller orders the media server to destroy the session.
   3.  The media server stops sending the RTP content stream(s).
   4.  The media server returns a success response to the controller.
   5.  The controller releases the resources that have been reserved for
       the RTP and RTSP streams.
   6.  The controller returns a SIP 200 OK (BYE) response to the UE.

7.2.3.  Solutions to the Identified Issues

   Below, the same issues that were identified for the signaling flow
   shown in Figure 4 are discussed for this alternative.

7.2.3.1.  Correlating SIP INVITE and RTSP SETUP

   The RTSP SETUP request is not used in this alternative.  A session ID
   parameter must be returned by the controller in the SDP answer



Lindquist, et al.       Expires December 18, 2009              [Page 23]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   carried in SIP 200 OK response to the SIP INVITE request.  This
   session ID is used in the Session header of RTSP messages such as the
   PLAY request.

7.2.3.2.  DNS Lookup for RTSP URL

   The same discussion applies as for alternative 1 (see
   Section 7.1.3.2).

7.2.3.3.  Redirection

   Selection of media server is performed prior to RTSP PLAY, so no
   redirection is expected.

7.2.3.4.  Correlating Transport Address in SDP Offer with Transport
          Header in SETUP

   Since RTSP SETUP is not used, there is no correlation issue.

7.2.3.5.  SIP BYE and RTSP TEARDOWN

   Since RTSP TEARDOWN is not used, there is no overlap between SIP BYE
   and RTSP TEARDOWN requests.  Resources are released when the SIP BYE
   request is received.


8.  Conclusion

   This document requests a guideline from the MMUSIC WG regarding how
   to achieve better interaction between the SIP and RTSP protocols.  We
   see such an interaction beneficial since it makes it possible to
   reuse much of the architecture and functionality (e.g.,
   authentication, charging, and QoS) that have already been established
   around SIP also for RTSP streaming.  In this document, we propose a
   model in which SIP/SDP is used to establish an RTSP control channel
   and one or more media delivery streams.  A similar model has already
   been adopted by standardization bodies such as ETSI TISPAN, 3GPP, and
   Open IPTV Forum, which proves that there exists a clear need in the
   industry for a solution like this.  Two alternatives are provided.
   The first alternative tries to keep both SIP and RTSP as intact as
   possible, whereas the second alternative removes session setup and
   teardown semantics from the RTSP protocol.  The purpose of this
   document is to find out whether the MMUSIC WG considers this work
   interesting and if so, what should be the next steps to achieve
   better SIP and RTSP interaction.






Lindquist, et al.       Expires December 18, 2009              [Page 24]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


9.  Security Considerations

   RFC 4145 [RFC4145] discusses security issues related to the
   establishment of TCP connections using the offer/answer model.
   Security issues related to the SDP offer/answer model and SDP are
   discussed in the SDP offer/answer model RFC [RFC3264], and the SDP
   RFC [RFC4566], respectively.

9.1.  Man-in-the-middle Attack

   Numerous attacks are possible if an attacker can modify SDP offers or
   answers in transit.  These attacks are discussed in the SDP offer/
   answer model RFC [RFC3264].

9.2.  Session Hijacking

   A session ID parameter is used to correlate SIP and RTSP.  Session
   hijacking may be possible if the session ID is exposed to a third
   party.

9.3.  Privacy Considerations

   If the identity of a client is to remain hidden, the instructions in
   [RFC3261] can be followed to generate anonymous SIP header field
   values.


10.  IANA Considerations

   This document has no actions for IANA.


11.  References

11.1.  Normative References

   [I-D.ietf-mmusic-rfc2326bis]
              Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
              and M. Stiemerling, "Real Time Streaming Protocol 2.0
              (RTSP)", draft-ietf-mmusic-rfc2326bis-20 (work in
              progress), March 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
              Streaming Protocol (RTSP)", RFC 2326, April 1998.




Lindquist, et al.       Expires December 18, 2009              [Page 25]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


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

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              September 2005.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

11.2.  Informative References

   [3GPP TS 26.237]
              "3rd Generation Partnership Project; Technical
              Specification Group Services and System Aspects; IP
              Multimedia Subsystem (IMS) based Packet Switch Streaming
              (PSS) and Multimedia Broadcast/Multicast Service (MBMS)
              User Service; Protocols (Release 8)", 3GPP TS 26.237
              V8.1.1 (2009-03).

   [ETSI TS 183 063]
              "Telecommunications and Internet Converged Services and
              Protocols for Advanced Networking (TISPAN); IMS-based IPTV
              Stage 3 Specification", ETSI TS 183 063 v2.1.0 (2008-06).

   [I-D.ietf-sipping-sbc-funcs]
              Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen,
              A., and M. Bhatia, "Requirements from SIP (Session
              Initiation Protocol) Session Border Control  Deployments",
              draft-ietf-sipping-sbc-funcs-08 (work in progress),
              January 2009.

   [I-D.ietf-whitehead-mmusic-sip-for-streaming-media]
              Whitehead, S., Montpetit, M., Marjou, X., Ganesan, S., and
              J. Lindquist, "Media Playback Control Protocol
              Requirements",
              draft-whitehead-mmusic-sip-for-streaming-media-05
              (expired) May 2008.

   [OIPF Volume 4]
              "Open IPTV Forum - Release 1 Specification; Volume 4 -
              Protocols", V1.0 (January 6, 2009).



Lindquist, et al.       Expires December 18, 2009              [Page 26]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, February 2002.

   [RFC3312]  Camarillo, G., Marshall, W., and J. Rosenberg,
              "Integration of Resource Management and Session Initiation
              Protocol (SIP)", RFC 3312, October 2002.

   [RFC3313]  Marshall, W., "Private Session Initiation Protocol (SIP)
              Extensions for Media Authorization", RFC 3313,
              January 2003.

   [RFC3455]  Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
              Header (P-Header) Extensions to the Session Initiation
              Protocol (SIP) for the 3rd-Generation Partnership Project
              (3GPP)", RFC 3455, January 2003.

   [RFC4582]  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
              Control Protocol (BFCP)", RFC 4582, November 2006.

   [RFC4583]  Camarillo, G., "Session Description Protocol (SDP) Format
              for Binary Floor Control Protocol (BFCP) Streams",
              RFC 4583, November 2006.

   [RFC4740]  Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
              Canales-Valenzuela, C., and K. Tammi, "Diameter Session
              Initiation Protocol (SIP) Application", RFC 4740,
              November 2006.

   [RFC5432]  Polk, J., Dhesikan, S., and G. Camarillo, "Quality of
              Service (QoS) Mechanism Selection in the Session
              Description Protocol (SDP)", RFC 5432, March 2009.


Authors' Addresses

   Jan Lindquist
   Ericsson
   Tellusborgsvaegen 83-87
   Hagersten  12637
   Sweden

   Email: jan.lindquist@ericsson.com









Lindquist, et al.       Expires December 18, 2009              [Page 27]


Internet-Draft          SIP/SDP Overlap with RTSP              June 2009


   Jouni Maenpaa
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Jouni.Maenpaa@ericsson.com


   Priya Rajagopal
   Motorola
   900 Chelmsford street ; T1;09
   Lowell, MA  01891
   USA

   Email: priya.rajagopal@motorola.com


   Xavier Marjou
   France Telecom
   2, avenue Pierre Marzin
   Lannion  22307
   France

   Email: xavier.marjou@orange-ftgroup.com


























Lindquist, et al.       Expires December 18, 2009              [Page 28]


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