


Network Working Group                                       J. Lindquist
Internet-Draft                                                J. Maenpaa
Intended status: Informational                                  Ericsson
Expires: December 11, 2010                                  P. Rajagopal
                                                                Motorola
                                                               X. Marjou
                                                   France Telecom Orange
                                                            June 9, 2010


   Controlling Session Initiation Protocol (SIP)-Established Content
    Delivery Channels Using the Real-Time Streaming Protocol (RTSP)
                    draft-lindquist-sip-rtsp-02.txt

Abstract

   The Session Initiation Protocol (SIP) is widely used for establishing
   multimedia sessions, whereas the Real Time Streaming Protocol (RTSP)
   is used 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 SIP is also used for session establishment, there exists an
   overlap between the functionality provided by SIP and RTSP.  In this
   document, we describe a model adopted by ETSI TISPAN, 3GPP, and Open
   IPTV Forum (OIPF) 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 for RTSP-
   based streaming.  The model benefits applications such as Internet
   Protocol Television (IPTV).  In addition to the model, the document
   specifies two new variants of RTSP.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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




Lindquist, et al.       Expires December 11, 2010               [Page 1]

Internet-Draft           Combining SIP and RTSP                June 2010


   This Internet-Draft will expire on December 11, 2010.

Copyright Notice

   Copyright (c) 2010 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.  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 Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.























Lindquist, et al.       Expires December 11, 2010               [Page 2]

Internet-Draft           Combining SIP and RTSP                June 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Generic SIP-based Video Delivery Architectures . . . . . . . .  8
   4.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Reuse of Features of Existing Architectures  . . . . . . .  9
       4.1.1.  Authentication, Authorization, and Accounting
               Capabilities . . . . . . . . . . . . . . . . . . . . .  9
       4.1.2.  Quality of Service and Resource Reservation
               Capabilities . . . . . . . . . . . . . . . . . . . . .  9
       4.1.3.  Security Features  . . . . . . . . . . . . . . . . . . 10
       4.1.4.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . 10
     4.2.  Advanced Media Applications  . . . . . . . . . . . . . . . 10
   5.  High-level Procedures  . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Summary of the Procedures  . . . . . . . . . . . . . . . . 11
     5.2.  Details of the Procedures  . . . . . . . . . . . . . . . . 11
       5.2.1.  Establishment of Content Control and Content
               Delivery Channels  . . . . . . . . . . . . . . . . . . 11
       5.2.2.  Modification of Content Delivery Channels  . . . . . . 13
       5.2.3.  Teardown of Content Control Channel and the
               Associated Content Delivery Channel(s) . . . . . . . . 15
   6.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  Content Control Protocol Accessing Resources
           Established by Session Management Protocol . . . . . . . . 16
     6.2.  Use of Transport Addresses in Content Control and
           Session Management Protocols . . . . . . . . . . . . . . . 16
     6.3.  Session Termination  . . . . . . . . . . . . . . . . . . . 17
   7.  Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Combining SIP/SDP and RTSP . . . . . . . . . . . . . . . . . . 18
     8.1.  Method 1: Lightweight RTSP without Session Setup
           Semantics  . . . . . . . . . . . . . . . . . . . . . . . . 18
       8.1.1.  Session Establishment Initiated by UE  . . . . . . . . 18
       8.1.2.  Session Establishment Initiated by Controller  . . . . 20
       8.1.3.  Session Termination  . . . . . . . . . . . . . . . . . 22
       8.1.4.  Discussion on the Requirements . . . . . . . . . . . . 23
     8.2.  Method 2: Full RTSP  . . . . . . . . . . . . . . . . . . . 25
       8.2.1.  Session Establishment Initiated by UE  . . . . . . . . 25
       8.2.2.  Session Establishment Initiated by Controller  . . . . 26
       8.2.3.  Session Termination  . . . . . . . . . . . . . . . . . 27
       8.2.4.  Discussion on the Requirements . . . . . . . . . . . . 28
   9.  Establishment of Content Control and Content Delivery
       Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     9.1.  Procedures at the SDP Offerer  . . . . . . . . . . . . . . 29
       9.1.1.  UE as the SDP Offerer  . . . . . . . . . . . . . . . . 29
     9.2.  Procedures at SDP Answerer . . . . . . . . . . . . . . . . 31
       9.2.1.  Controller as SDP Answerer . . . . . . . . . . . . . . 31
     9.3.  Modification of Content Delivery Channel(s)  . . . . . . . 32



Lindquist, et al.       Expires December 11, 2010               [Page 3]

Internet-Draft           Combining SIP and RTSP                June 2010


   10. Content Control Protocol . . . . . . . . . . . . . . . . . . . 32
     10.1. Lightweight RTSP . . . . . . . . . . . . . . . . . . . . . 32
     10.2. Procedures at the UE . . . . . . . . . . . . . . . . . . . 33
       10.2.1. Media Setup Procedure  . . . . . . . . . . . . . . . . 33
       10.2.2. Media Playback Initiation Procedure  . . . . . . . . . 33
       10.2.3. Media Playback Modification Procedure  . . . . . . . . 34
       10.2.4. Media Playback Information Retrieval and Setting
               Procedure  . . . . . . . . . . . . . . . . . . . . . . 34
       10.2.5. Media Event Notification Procedure . . . . . . . . . . 34
       10.2.6. Media Teardown Procedure . . . . . . . . . . . . . . . 34
     10.3. Procedures at Media Server . . . . . . . . . . . . . . . . 34
   11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     11.1. Content on Demand Session Establishment Using
           Lightweight RTSP (Method 1)  . . . . . . . . . . . . . . . 35
     11.2. Content on Demand Session Establishment Using Full
           RTSP (Method 2)  . . . . . . . . . . . . . . . . . . . . . 37
     11.3. Content on Demand Session Termination Using
           Lightweight RTSP (Method 1)  . . . . . . . . . . . . . . . 40
     11.4. Content on Demand Session Termination Using Full RTSP
           (Method 2) . . . . . . . . . . . . . . . . . . . . . . . . 41
   12. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 42
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 43
     13.1. Man-in-the-middle Attack . . . . . . . . . . . . . . . . . 43
     13.2. Session Hijacking  . . . . . . . . . . . . . . . . . . . . 43
     13.3. Privacy Considerations . . . . . . . . . . . . . . . . . . 43
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 43
     14.1. Registration of the 'TCP/ETSI_RTSP' and
           'TCP/TLS/ETSI_RTSP' SDP 'proto' Values . . . . . . . . . . 43
     14.2. Registration of the SDP 'etsi_rtsp-uri' Attribute  . . . . 44
     14.3. Registration of the SDP 'etsi_rtsp-session' Attribute  . . 44
     14.4. Registration of the SDP 'etsi_rtsp-offset' Attribute . . . 45
     14.5. Registration of the SDP 'etsi_rtsp-version' Attribute  . . 45
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 46
     16.2. Informative References . . . . . . . . . . . . . . . . . . 46
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48














Lindquist, et al.       Expires December 11, 2010               [Page 4]

Internet-Draft           Combining SIP and RTSP                June 2010


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], 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 SIP 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 describe a model adopted by European
   Telecommunications Standards Institute (ETSI) Telecommunications and
   Internet converged Services and Protocols for Advanced Networking
   (TISPAN), 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.
   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, the 3rd Generation Partnership Project (3GPP)
   [3GPP TS 26.237] and the Open IPTV Forum (OIPF) [OIPF Volume 4] use
   the same model for using SIP to establish an RTSP control channel.
   The solution presented in this document is required by a growing
   number of Internet Protocol Television (IPTV) implementations.

   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.

   SIP/RTSP interaction has been discussed several times in the MMUSIC



Lindquist, et al.       Expires December 11, 2010               [Page 5]

Internet-Draft           Combining SIP and RTSP                June 2010


   working group of the IETF in the past.  The following drafts have
   dealt with the topic over the years:
   [I-D.ietf-whitehead-mmusic-sip-for-streaming-media],
   [I-D.ietf.marjou-mmusic-sdp-rtsp], and
   [I-D.ietf-lindquist-mmusic-sip-rtsp].  The purpose of the most recent
   draft, [I-D.ietf-lindquist-mmusic-sip-rtsp], was to bring the ETSI
   TISPAN solution (and adopted by 3GPP and OIPF), of combining SIP and
   RTSP to the attention of the MMUSIC working group.  The conclusion of
   the discussions triggered by the drafts was that there was no
   consensus that SIP/RTSP interaction is something that should be
   specified in the MMUSIC working group or any other working group of
   the IETF.  Hence, the authors decided to prepare an independent
   submission (i.e., the present document), whose intended status is
   informational, to describe the solution.  There is no intention to
   change the RTSP protocol defined in [RFC2326].  The present document
   serves two purposes.  First, it describes the solution for combining
   SIP and RTSP adopted by ETSI TISPAN, OIPF and 3GPP.  Second, it
   allocates new codepoints (i.e., new SDP attributes and new SDP
   'proto' field value) for the proposed solution.

   This document defines two new ETSI variants of RTSP, which are
   referred to as lightweight RTSP and full RTSP.  Both of the variants
   deal with the overlap between SIP and RTSP.  Lightweight RTSP removes
   the overlap by removing session setup and teardown semantics from
   RTSP.  Full RTSP keeps the overlap by imposing a number of
   requirements on clients.  In addition to removing session setup and
   teardown functionalities, lightweight RTSP does not use DNS to
   resolve RTSP URLs.  Similar to lightweight RTSP, also full RTSP does
   not use DNS to resolve RTSP URLs.  The use of the variants is
   indicated by the new SDP 'proto' field values TCP/ETSI_RTSP (used
   when RTSP runs directly on top of TCP) and TCP/TLS/ETSI_RTSP (used
   when RTSP runs on top of TLS, which in turn runs on top of TCP)
   defined later in this document.  The fact whether lightweight or full
   RTSP is used is determined based on the received SDP, as will be
   described in Section 9.2.1.

   The rest of the document is structured as follows.  Section 3
   describes generic SIP-based video delivery architectures composed of
   a UE, a controller, and a media server.  Section 4 discusses
   architecture and functionality reuse as the main motivation for SIP/
   RTSP interaction.  Section 5 describes the high-level procedures
   required to deliver multimedia streaming content within the
   architectural framework described in Section 3.  Section 6 states
   some requirements for a solution that uses separate protocols to
   establish a session and control the delivery of streaming media.
   Section 7 discusses the design goals of a combined SIP and RTSP
   solution.  Section 8 presents possible solutions that fulfill the
   requirements stated in Section 6.  Section 9 describes the SDP



Lindquist, et al.       Expires December 11, 2010               [Page 6]

Internet-Draft           Combining SIP and RTSP                June 2010


   procedures associated with establishing, modifying, and terminating
   the content control and content delivery channels.  Section 10
   defines the RTSP related procedures.  Section 12 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 Channel:  An end-to-end communication channel between
      a user equipment (UE) and media server used for carrying media
      trick play commands such as play, pause, rewind, etc.

   Content Control Protocol:  A protocol that is used to control the
      delivery of media streams.  An example of such a protocol is the
      Real Time Streaming Protocol (RTSP).

   Content Delivery Channel:  And end-to-end communication channel
      between the UE and media server for carrying content such as
      streaming media.

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

   Controller:  The systems considered in this document use an
      architecture composed of a controller and a media server.  The
      controller monitors the session with the media server and handles
      user authentication, charging, resource reservation, checking user
      services, and keeping track of streaming (e.g., for keeping
      bookmarks), among other things

   Media Server:  The media server is among other things responsible for
      storing media, delivering media flows to users, and transcoding
      content to different media formats.

   Middlebox:  A middlebox is defined as any intermediary device
      performing functions other than the normal, standard functions of
      an IP router on the datagram path between a source host and
      destination host [RFC3234].  In this document, a middlebox refers
      to an Application Level Gateway (ALG), firewall, or Network
      Address Translator (NAT) device located between a User Equipment
      (UE) and a controller.





Lindquist, et al.       Expires December 11, 2010               [Page 7]

Internet-Draft           Combining SIP and RTSP                June 2010



   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.

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



3.  Generic SIP-based Video Delivery Architectures

   The SIP-based video delivery systems considered in this document use
   an architecture composed of a controller and a media server.  The
   services provided by the controller and the media server are used by
   User Equipment (UE) devices.  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 UEs,
   and transcoding content to different media formats.  The controller,
   in turn, monitors the session with the media server and handles user
   authentication, charging, resource reservation, checking user
   services, and keeping track of streaming (e.g., for keeping
   bookmarks), among other things.

   The architecture is illustrated in Figure 1.  We refer to the
   protocol that is used between a 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, two protocols, a content control protocol and a content
   delivery protocol, are used.  The first is used for the purpose of
   controlling content delivery and the latter for the delivery of
   content.  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.

   Although not shown in Figure 1, the UE may be located behind a
   middlebox such as an Application Level Gateway (ALG), firewall, or a
   Network Address Translator (NAT).









Lindquist, et al.       Expires December 11, 2010               [Page 8]

Internet-Draft           Combining SIP and RTSP                June 2010


                               ____+--------------+
                              /    |  Controller  |
                             /     +--------------+
             Session        /             |
             management--> /              |
             protocol     /               |
                         /                |
                +--------+                |
                |   UE   |                | <-- Media server control
                +--------+                |
                  \     \      Content    |
                   \     \ <-- delivery   |
          Content   \     \    protocol   |
          control--> \     \              |
          protocol    \     \______+--------------+
                       \___________| Media Server |
                                   +--------------+

          Figure 1: Generic SIP-based video delivery architecture


4.  Motivation

4.1.  Reuse of Features of Existing Architectures

   The main motivation for using SIP/SDP to establish an RTSP control
   channel is that it makes it possible to reuse existing mechanisms and
   features available in SIP based architectures without the need to
   implement them for RTSP as well.

4.1.1.  Authentication, Authorization, and Accounting Capabilities

   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 (a Diameter application is not a software
   application, but a protocol based on the Diameter base protocol)
   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.

4.1.2.  Quality of Service and Resource Reservation Capabilities

   Many systems have also established QoS around SIP.  It is possible to
   negotiate the QoS mechanism to use for a particular media stream



Lindquist, et al.       Expires December 11, 2010               [Page 9]

Internet-Draft           Combining SIP and RTSP                June 2010


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

4.1.3.  Security Features

   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.

4.1.4.  NAT Traversal

   The content that a user wants to stream may be stored on a remote
   user device located behind a Network Address Translator (NAT).  The
   use of SIP to establish RTSP-controlled content delivery streams
   could make endpoint-hosted streaming easier, even if the remote user
   device is behind a NAT.  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 by the receiver 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.


5.  High-level Procedures

   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



Lindquist, et al.       Expires December 11, 2010              [Page 10]

Internet-Draft           Combining SIP and RTSP                June 2010


   modification, and session termination.

   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.  Summary of the Procedures

   This section briefly summarizes the overall operation of the session
   management and content control protocols.

   Establishment of content control and content delivery channels: the
   UE uses the session management protocol with the media server in
   order to establish the relevant content control channel and one or
   more content delivery channels that are to be controlled by the
   content control protocol.  Once the content control session has been
   established, media playback controls are issued directly using the
   content control protocol.  This includes trick play commands.

   Modification of content delivery channel(s): once established, the UE
   or media server may add, remove, or modify any of the content
   delivery channels using the session management protocol.

   Teardown of content control channel and the associated content
   delivery channel(s): teardown of content control and the associated
   content delivery channel(s) may be initiated by the UE or the media
   server using the session management protocol.  This releases all
   resources associated with the content control channel and the content
   delivery channels.

5.2.  Details of the Procedures

5.2.1.  Establishment of Content Control and Content Delivery Channels

   Figure 2 illustrates on a high level the main stages of using the
   session management protocol to establish the content control channel
   and the content delivery streams.  Although not illustrated below,
   session establishment may also be initiated by the controller.












Lindquist, et al.       Expires December 11, 2010              [Page 11]

Internet-Draft           Combining SIP and RTSP                June 2010


     +----+    +-------------+   +------------+         +--------------+
     | 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 2: Session Establishment

   The steps in the signaling flow are as follows:






Lindquist, et al.       Expires December 11, 2010              [Page 12]

Internet-Draft           Combining SIP and RTSP                June 2010


   1.   The UE uses the session management protocol to establish a
        content delivery 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 content
        delivery 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.2.  Modification of Content Delivery Channels

   This section illustrates how a content delivery session is modified.
   Session modification is necessary for instance when the user wants to
   add media streams to or remove media streams from an ongoing content
   delivery session.  Although not illustrated below, session
   modification may also be initiated by the controller.

   An example of session modification is shown in Figure 3.



















Lindquist, et al.       Expires December 11, 2010              [Page 13]

Internet-Draft           Combining SIP and RTSP                June 2010


     +----+    +-------------+   +------------+         +--------------+
     | 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 3: Session Modification

   The steps in Figure 3 are as follows:

   1.  The UE performs session modification by sending a session
       management protocol session modification request to the
       controller, as shown in step (1) of Figure 3.  The UE initiates
       session modification in order to add media streams to or remove
       media streams from the ongoing content delivery session.
   2.  The controller modifies the resources reserved for the content
       delivery session according to the session modification request.
   3.  The controller selects a media server.





Lindquist, et al.       Expires December 11, 2010              [Page 14]

Internet-Draft           Combining SIP and RTSP                June 2010


   4.  The controller orders the media server to modify the session.
   5.  The media server returns a success response to the controller.
   6.  The controller returns a session management protocol success
       response to the UE.
   7.  The controller commits the reservation.
   8.  The UE starts playback by issuing a content control protocol
       request.
   9.  The media server returns a content control protocol success
       response.

5.2.3.  Teardown of Content Control Channel and the Associated Content
        Delivery Channel(s)

   Figure 4 shows on a high level how media streams and the session are
   terminated.  Although not illustrated below, session termination may
   also be initiated by the controller.

     +----+    +-------------+   +------------+         +--------------+
     | 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 4: Session Termination

   The steps in the signaling flow are as follows:




Lindquist, et al.       Expires December 11, 2010              [Page 15]

Internet-Draft           Combining SIP and RTSP                June 2010


   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.
   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 content 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 the main requirements for a solution that uses a session
   management protocol to establish a control channel for a content
   control protocol and one or more content delivery channels (i.e.,
   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 content 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.




Lindquist, et al.       Expires December 11, 2010              [Page 16]

Internet-Draft           Combining SIP and RTSP                June 2010


   Since different protocols are used for session establishment and
   content 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
   messages should be sent to the transport addresses negotiated by the
   session management protocol and media 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 channels and for the content
   control channel.  The middlebox may not inspect the content control
   protocol messages.  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 (which is true when the content
   control protocol does not define session teardown semantics), but
   only the session management protocol is, the above-mentioned
   coordination is not necessary.


7.  Design Goals

   In the remainder of the document, we will assume that the session
   management protocol is SIP and that the content control protocol is
   RTSP.  This section provides an overview of the design goals of the
   combined SIP and RTSP solution.  These design goals are listed below:

   o  The session management protocol should be able to initiate,
      modify, and terminate content control and content delivery
      channels from the client side and server side using the SDP offer/
      answer mechanism.



Lindquist, et al.       Expires December 11, 2010              [Page 17]

Internet-Draft           Combining SIP and RTSP                June 2010


   o  The content control protocol must be negotiated using the SDP
      offer/answer mechanism.
   o  The content control protocol must allow for trick-play commands
      such as PLAY, REWIND, FORWARD, and PAUSE commands.
   o  The content control protocol must allow for asynchronous media
      event notifications (e.g., end-of-stream).
   o  The content control protocol must work over TCP.


8.  Combining SIP/SDP and RTSP

   In order to better understand the issues with the reuse of existing
   architectures and support of a SIP-based video delivery architecture,
   this section provides an overview of existing systems specified by
   standardization bodies such as ETSI TISPAN and 3GPP.  We will
   describe the interaction between SIP/SDP and RTSP protocols for these
   systems.

   Below, we present two approaches specified by ETSI TISPAN that
   fulfill the requirements stated in Section 6 and meet the design
   goals listed in Section 7.  In both of the approaches, SIP/SDP is
   used to establish an RTSP control stream and one or more content
   delivery streams.  In the first approach, the UE uses RTSP without
   session setup and teardown semantics, whereas in the second approach,
   the UE uses full RTSP.

8.1.  Method 1: 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.  The benefits of
   using a lightweight version of RTSP over using the full RTSP include
   that since lightweight RTSP does not specify session setup and
   teardown semantics, there is no overlap between SIP and RTSP
   signaling.  Further, less signaling is required and it is easier to
   correlate the two protocols.

8.1.1.  Session Establishment Initiated by UE

   The signaling flow in Figure 5 illustrates how proposed IPTV and
   streaming systems (e.g., ETSI 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].  In the figure, a lightweight version of RTSP without session
   setup and teardown semantics is used.





Lindquist, et al.       Expires December 11, 2010              [Page 18]

Internet-Draft           Combining SIP and RTSP                June 2010


     +----+    +-------------+   +------------+         +--------------+
     | 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 5: 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 channels, one for RTSP control and one or more for
        media transmission.  The SDP offer included in the INVITE
        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.  As an example, the UE may



Lindquist, et al.       Expires December 11, 2010              [Page 19]

Internet-Draft           Combining SIP and RTSP                June 2010


        obtain the relevant SDP parameters such as media type, transport
        etc. required for establishing the content delivery channels a
        priori via HTTP from a content guide server or an Electronic
        Programme Guide (EPG) server.  The contents of the SDP offer are
        defined in Section 9.1.1.
   2.   Upon receiving the SIP INVITE request, the controller reserves
        resources for the RTSP and RTP streams.
   3.   The controller selects an appropriate media server.
   4.   Next, 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.  Among
        other things, 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.
        The exact contents of the SDP answer are described in
        Section 9.2.1.
   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.  The contents of
        the PLAY requests are described in detail in Section 10.2.2.
   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.

8.1.2.  Session Establishment Initiated by Controller

   Figure 6 shows the case when the session establishment is initiated
   by the controller instead of the UE.
















Lindquist, et al.       Expires December 11, 2010              [Page 20]

Internet-Draft           Combining SIP and RTSP                June 2010


     +----+    +-------------+   +------------+         +--------------+
     | UE |    | (Middlebox) |   | Controller |         | Media server |
     +----+    +-------------+   +------------+         +--------------+
        |             |                 |                       |
        |          (1) INVITE           |                       |
        |<------------|<----------------|                       |
        |             |                 |                       |
        |          (2) 200 OK (INVITE)  |                       |
        |------------>|---------------->|                       |
        |             |           /-----------\                 |
        |             |          /(3) Resource \                |
        |             |          \ reservation /                |
        |             |           \-----------/                 |
        |             |                 |                       |
        |             |           /-----------\                 |
        |             |          / (4) Select  \                |
        |             |          \ media server/                |
        |             |           \-----------/                 |
        |             |                 |  (5) Create session   |
        |             |                 |---------------------->|
        |             |                 |       (6) OK          |
        |             |                 |<----------------------|
        |             |           /-----------\                 |
        |             |          /(7) Resource \                |
        |             |          \    commit   /                |
        |             |           \-----------/                 |
        |             |                 |                       |
        |          (8) ACK              |                       |
        |<------------|<----------------|                       |
        |             |                 |                       |
       /---------------------------------------------------------\
      (              Method 1: Steps 9-11 of Figure 5             )
       \---------------------------------------------------------/
        |             |                 |                       |
        |             |                 |                       |
       /---------------------------------------------------------\
      (              Method 2: Steps 9-13 of Figure 8             )
       \---------------------------------------------------------/
        |             |                 |                       |
        |             |                 |                       |

          Figure 6: RTSP Control Stream Established Using SIP/SDP

   The steps in the signaling flow are as follows:

   1.  The controller sends an initial SIP INVITE request to the UE.
       The INVITE request does not include an SDP body.




Lindquist, et al.       Expires December 11, 2010              [Page 21]

Internet-Draft           Combining SIP and RTSP                June 2010


   2.  The UE accepts the INVITE and sends a SIP 200 OK final response
       to the controller.  The 200 OK carries an SDP offer whose
       contents are described in Section 9.1.1
   3.  The controller reserves resources for the RTSP and RTP streams.
   4.  The controller selects an appropriate media server.
   5.  The controller orders the media server to create a streaming
       session.
   6.  The media server returns a success response to the controller.
   7.  The resource reservation is committed.
   8.  The controller returns a SIP ACK request to the UE.  The ACK
       contains an SDP answer the contents of which are described in
       Section 9.2.1.

   Having received the ACK, the UE can use one of two alternative
   methods to start receiving the content stream(s).  If Method 1
   (lightweight RTSP) is used, steps 9-11 of Figure 5 are executed.  If
   Method 2 (full RTSP) is used, the UE executes steps 9-13 of Figure 8.

8.1.3.  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 11, 2010              [Page 22]

Internet-Draft           Combining SIP and RTSP                June 2010


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

                       Figure 7: Session Termination

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

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

8.1.4.  Discussion on the Requirements

   Below, it is described how this method satisfies the requirements
   stated in Section 6.





Lindquist, et al.       Expires December 11, 2010              [Page 23]

Internet-Draft           Combining SIP and RTSP                June 2010


8.1.4.1.  Requirement 1 - Content Control Protocol Accessing Resources
          Established by Session Management Protocol

   The RTSP SETUP request is not used in this method.  To correlate SIP
   and RTSP, a session ID parameter MUST be returned by the controller
   in the SDP answer carried in the 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.

8.1.4.2.  Requirement 2 - Use of Transport Addresses in Content Control
          and Session Management Protocols

8.1.4.2.1.  DNS Lookup for RTSP URL

   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.
   This is problematic if the UE is located behind a middlebox: the
   middlebox may drop the packets sent to the new server address.

   To solve this issue, the UE MUST use the server IP address and port
   returned in the SDP answer (in "c=" and "m=" lines of the RTSP
   control channel) as the destination address of RTSP messages.

   If there is a need to change the server IP address, a session
   modification needs to be performed.

   Note that to avoid the issue with DNS lookups, deployments can choose
   to deliver IP addresses back to the UE within RTSP URLs.

8.1.4.2.2.  Redirection

   The media server is selected during SIP session establishment prior
   to sending RTSP PLAY and there is no RTSP SETUP request, so no
   redirection is expected.

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

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

8.1.4.3.  Requirement 3 - Session Termination

   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.




Lindquist, et al.       Expires December 11, 2010              [Page 24]

Internet-Draft           Combining SIP and RTSP                June 2010


8.2.  Method 2: Full RTSP

8.2.1.  Session Establishment Initiated by UE

   Figure 8 shows the way a session is established when full RTSP 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) SETUP      |                       |
        |------------>|---------------------------------------->|
        |             |  (10) 200 OK (SETUP)                    |
        |<------------|<----------------------------------------|
        |             |  (11) PLAY      |                       |
        |------------>|---------------------------------------->|
        |             |  (12) 200 OK (PLAY)                     |
        |<------------|<----------------------------------------|
        |             |  (13) RTP       |                       |
        |<============|<========================================|
        |             |                 |                       |

          Figure 8: RTSP Control Stream Established Using SIP/SDP



Lindquist, et al.       Expires December 11, 2010              [Page 25]

Internet-Draft           Combining SIP and RTSP                June 2010


   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
        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.  The contents of the SDP
        offer are described in Section 9.1.1.
   2.   Upon receiving the SIP INVITE request, the controller reserves
        resources for the RTSP and RTP streams.
   3.   Next, 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) final response to the
        UE.  The SDP answer included in the response contains among
        other things an RTSP URL.  The exact contents of the SDP answer
        are described in Section 9.2.1.
   7.   The resource reservation is committed.
   8.   The UE returns an ACK to the controller to acknowledge the
        reception of the SIP 200 OK (INVITE) final response.
   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
        of the SETUP request is set to the URL returned in the SDP
        answer as described in Section 10.2.1.
   10.  An RTSP 200 OK response for the RTSP SETUP request 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
        contents of the PLAY requests are described in Section 10.2.2.
   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.

8.2.2.  Session Establishment Initiated by Controller

   If the session establishment is initiated by the controller, the
   signaling flow is the same as in Figure 6 with the exception that
   after receiving the ACK, the UE proceeds by executing steps 9-13 of



Lindquist, et al.       Expires December 11, 2010              [Page 26]

Internet-Draft           Combining SIP and RTSP                June 2010


   Figure 8.

8.2.3.  Session Termination

   The figure below illustrates how a streaming session is terminated in
   [ETSI TS 183 063] when full RTSP is being used.

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

                       Figure 9: 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 disconnects the TCP connection that was used for RTSP
       signaling.
   5.  The UE sends a SIP BYE request to the controller.





Lindquist, et al.       Expires December 11, 2010              [Page 27]

Internet-Draft           Combining SIP and RTSP                June 2010


   6.  The controller releases the resources that have been reserved for
       the RTP and RTSP streams.
   7.  The controller orders the media server to destroy the session.
   8.  The media server returns a success response to the controller.
   9.  The controller returns a SIP 200 OK (BYE) response to the UE.

8.2.4.  Discussion on the Requirements

   In this section, we discuss how this method satisfies the
   requirements stated in Section 6.

8.2.4.1.  Requirement 1 - Content Control Protocol Accessing Resources
          Established by Session Management Protocol

   Correlating the SIP INVITE transaction and the RTSP SETUP request may
   be problematic since there is no RTSP session identifier returned in
   the INVITE response.

   To solve this problem, the RTSP URL returned in the SDP answer MUST
   convey correlation information as specified in [ETSI TS 183 063].

8.2.4.2.  Requirement 2 - Use of Transport Addresses in Content Control
          and Session Management Protocols

8.2.4.2.1.  DNS lookup for RTSP URL

   The same discussion applies as for Method 1 (see Section 8.1.4.2.1).

8.2.4.2.2.  Redirection

   The media server should not redirect 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
   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, redirection MUST NOT be
   used.




Lindquist, et al.       Expires December 11, 2010              [Page 28]

Internet-Draft           Combining SIP and RTSP                June 2010


   Note that if the service provider provides both the service and the
   content (i.e., the media server), the service provider is in full
   control of the media server's behavior.  In that case, there would be
   no redirection.  However, if the service provider and content
   provider are separate, then redirection might be an issue.

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

8.2.4.3.  Requirement 3 - Session Termination

   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 the TEARDOWN request if the resources in the network for
   the RTSP session have been released when receiving s 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 MUST 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 typical RTSP scenarios that can
   initiate session termination.  An example of such a node is SIP Back-
   to-Back User Agent (B2BUA).


9.  Establishment of Content Control and Content Delivery Channels

   This section describes the procedures to be performed for
   establishing an RTSP content control channel and the associated
   content delivery channel(s) using the SDP offer/answer model.

9.1.  Procedures at the SDP Offerer

9.1.1.  UE as the SDP Offerer

   The UE, as the SDP offerer, MUST follow the procedures in this
   section to establish the content control channel and one or more
   content delivery channels.  The SDP offer is per SDP specification
   [RFC4145].  A media line for the RTSP content control channel is
   included with the following values:





Lindquist, et al.       Expires December 11, 2010              [Page 29]

Internet-Draft           Combining SIP and RTSP                June 2010


   o  The media field MUST have a value of "application".
   o  The port field MUST indicate a TCP port.  The port MUST be set to
      a value of 9, which is the discard port.
   o  The transport field MUST be set to contain either the value "TCP/
      ETSI_RTSP" or "TCP/TLS/ETSI_RTSP".  The former is used when RTSP
      runs directly on top of TCP and the latter when RTSP runs on top
      of TLS, which in turn runs on top of TCP.
   o  The fmt (format) list is ignored for ETSI_RTSP.  It MUST contain a
      single "*" character.

   An "a=setup" attribute MUST be present and set to "active".

   An "a=connection" attribute MUST be present and set to "new".

   The SDP offer MUST additionally include at least one content delivery
   channel description and specify the related m-line(s).

   An "a=recvonly" attribute MUST be present.

   A "b=" line indicating the bandwidth necessary to handle this content
   delivery channel MAY be included.

   If a broadcast session is being switched to a unicast session, the
   offer MUST include an "etsi_rtsp-offset" attribute to specify the
   current playback position.  The UE will resume from this position
   when issuing an RTSP PLAY request.

   The offer MAY optionally include "etsi_rtsp-version" attributes to
   specify the RTSP versions that the UE supports.  If no "etsi_rtsp-
   version" attributes are included, the receiver of the offer MUST
   interpret this to mean that the offerer supports only RTSP version
   1.0.  At the time of writing the document, the ETSI TISPAN solution
   for combining SIP and RTSP used RTSP 1.0.  Since the intention of
   this document is to describe the ETSI TISPAN solution, the document
   specifies only the use of RTSP 1.0.

   The receiver of the SDP offer MUST interpret the offer so that all
   described content delivery channels are under the control of the
   content control protocol.

   When receiving any SDP answer, the UE MUST examine the media
   parameters in the received SDP.  The UE MUST use the received SDP
   parameters for content control procedures as described in
   Section 10.2.







Lindquist, et al.       Expires December 11, 2010              [Page 30]

Internet-Draft           Combining SIP and RTSP                June 2010


9.2.  Procedures at SDP Answerer

9.2.1.  Controller as SDP Answerer

   The controller, as the SDP answerer, MUST follow the procedures in
   this section to establish the content control channel and at least
   one content delivery channel.  The SDP answer is per the SDP
   specification [RFC4145].  The media line for RTSP content control
   channel is included with the following values:

   o  The media field MUST have a value of "application".
   o  The port field MUST be a TCP port and its value MUST be set to the
      port allocated at the media server.
   o  The transport field MUST be set to contain either the value "TCP/
      ETSI_RTSP" or "TCP/TLS/ETSI_RTSP".
   o  The fmt list MUST contain a single "*" character.

   An "a=setup" attribute MUST be present and set to "passive".

   An "a=connection" attribute MUST be present and set to "new".

   The answer MUST include one or more attribute lines representing RTSP
   content control specific attributes.  These attributes are set as
   follows:

   o  An "etsi_rtsp-uri" attribute MUST be present and set to the RTSP
      URL to be used in the RTSP content control requests.  The URI can
      be in form of an absolute or a relative URI.  If an absolute URI
      is specified, it is used by the UE as-is in subsequent RTSP
      requests.  If a relative URI is specified in the form of a media
      path, the RTSP absolute URL can be constructed by the UE using the
      IP address (from c-line) and port (from m-line) as the base
      followed by an etsi_rtsp-uri value for the media path.
   o  If the controller supports Method 1 (lightweight RTSP), the
      controller MUST include an "etsi_rtsp-session" attribute
      representing the session ID of the RTSP session.  If the
      controller uses Method 2 (full RTSP), such attribute MUST NOT be
      included.  The UE will determine whether to use Method 1 or Method
      2 based on the presence or absence of the "etsi_rtsp-session"
      attribute.  If the attribute is received in the SDP answer, the UE
      MUST use Method 1.  Otherwise the UE MUST use Method 2.  The value
      of the "etsi_rtsp-session" attribute has the following format:
      a=etsi_rtsp-session:<session ID> [<timeout>].  The timeout
      parameter is optional.  It specifies a numeric timeout interval in
      seconds.  The UE uses the value of the parameter for sending RTSP
      keepalives (e.g., GET_PARAMETER requests) to the server.  If no
      timeout parameter is included, the UE MUST use a default value of
      60 seconds



Lindquist, et al.       Expires December 11, 2010              [Page 31]

Internet-Draft           Combining SIP and RTSP                June 2010


   o  Optionally, the answer MAY include an "etsi_rtsp-offset" attribute
      to specify the current playback position.  The UE will resume from
      this position when issuing an RTSP PLAY request.
   o  The answer MAY optionally include "etsi_rtsp-version" attributes
      to specify the RTSP versions that the controller supports.  If no
      "etsi_rtsp-version" attributes are included, the receiver of the
      answer MUST interpret this to mean that the answerer supports only
      RTSP version 1.0.  After the offer/answer exchange has finished,
      the UE and the controller MUST use the highest RTSP version
      supported by both parties.  If, during the streaming session, the
      UE attempts to use an RTSP version that is not supported by the
      controller (or vice-versa) the RTSP request MUST be rejected with
      the error code '505 RTSP Version Not Supported'.

9.3.  Modification of Content Delivery Channel(s)

   Modification of the content delivery channels including adding,
   removing or modifying media parameters associated with the content
   delivery channels may be initiated by the UE or the Controller.

   The UE and the Controller MUST not modify the RTSP control channel
   m-line description in the SDP if the content delivery streams
   controlled by RTSP are not removed (port not set to zero in m-lines).


10.  Content Control Protocol

   This section describes procedures that a UE can use for controlling
   the content delivery channels that have been established using either
   full RTSP or a lightweight version of RTSP.

10.1.  Lightweight RTSP

   When using Method 1 (lightweight RTSP), all RTSP requests MUST use
   the same session ID as specified in the SDP etsi_rtsp-session
   attribute during content control session establishment.

   When the lightweight RTSP is used, the following methods MUST be
   supported for media playback control and media event notifications:
   o  RTSP PLAY (UE -> media server)
   o  RTSP PAUSE (UE -> media server)
   o  RTSP GET_PARAMETER (UE -> media server)
   o  RTSP SET_PARAMETER (UE -> media server)
   o  RTSP ANNOUNCE (media server -> UE)
   o  RTSP OPTIONS (UE -> media server)






Lindquist, et al.       Expires December 11, 2010              [Page 32]

Internet-Draft           Combining SIP and RTSP                June 2010


10.2.  Procedures at the UE

10.2.1.  Media Setup Procedure

   The UE sends an RTSP SETUP request only when Method 2 (full RTSP) is
   being used.  If Method 1 (lightweight RTSP) is being used, the UE
   MUST NOT send an RTSP SETUP request.  When sending an RTSP SETUP
   request, the UE MUST populate the header fields as follows:

   o  The RTSP URL MUST be set to the media RTSP URL received in the SDP
      answer from the controller.  If the RTSP URL contains a domain
      address, the UE MUST NOT perform a DNS lookup.  Instead, the
      target transport address (by transport address, we refer to IP
      address and transport protocol port number) of the RTSP SETUP
      request MUST be set to the IP address obtained from the connection
      line ("c=") in the SDP answer and the port specified in the media
      line ("m=") of the RTSP control stream.

   If full RTSP is being used, the UE MUST, on receiving a 200 OK
   response to the SETUP request, retrieve and store the Session header
   for the purpose of issuing an RTSP PLAY request later.

10.2.2.  Media Playback Initiation Procedure

   The UE MUST follow the procedures in this section to initiate media
   playback using the RTSP PLAY method.  The RTSP fields in the RTSP
   PLAY message MUST be filled as follows:

   o  The RTSP URL will be set to the value retrieved from the
      etsi_rtsp-uri attribute in the SDP answer from the controller in
      the case of an absolute URI.  If the value of the etsi_rtsp-uri is
      a relative URI that is in the form of a media path, then the RTSP
      absolute URL is constructed by the UE using the SDP IP address
      (from c-line) and port (from m-line) as the base followed by a
      etsi_rtsp-uri value for the media path (e.g.,
      rtsp://10.5.1.72:22554/TV3/823527).  If the value of the
      etsi_rtsp-uri is an absolute URL, the UE MUST NOT perform a DNS
      lookup.  The target transport address of the RTSP PLAY message
      MUST be set to the IP address obtained from the connection line
      ("c=") in the SDP answer and the port from the media line ("m=").
   o  The Range parameter MAY be present and set to the value retrieved
      from the SDP etsi_rtsp-offset attribute.
   o  If using Method 2 (full RTSP), a Session header MUST be included.
      The value of the header MUST be set to the same value as in the
      RTSP SETUP request.






Lindquist, et al.       Expires December 11, 2010              [Page 33]

Internet-Draft           Combining SIP and RTSP                June 2010


10.2.3.  Media Playback Modification Procedure

   The UE MUST follow the procedures in this section to modify media
   playback.  The direction and/or speed of media playback is modified
   by including a Scale header within the RTSP PLAY request as specified
   in [RFC2326].

10.2.4.  Media Playback Information Retrieval and Setting Procedure

   The UE MAY retrieve the following information using the RTSP
   GET_PARAMETER request:

   o  position: the position in the media in seconds.
   o  scales: the allowed scales that can be used in the PLAY request.
   o  duration

   The UE MAY also set the position parameter by sending an RTSP
   SET_PARAMETER request.  An empty body is allowed for RTSP keepalives.

10.2.5.  Media Event Notification Procedure

   If the UE receives an RTSP ANNOUNCE with a notice-code that it does
   not recognize, it should ignore the request.

10.2.6.  Media Teardown Procedure

   A TEARDOWN request is only allowed if Method 2 (full RTSP) is being
   used.  If Method 1 (lightweight RTSP) is being used, a TEARDOWN
   request MUST NOT be sent.  The contents of a TEARDOWN request MUST be
   set as follows:

   o  The RTSP URL header MUST be set to the media RTSP URL obtained
      from the session initiation.  If a domain address is used in the
      RTSP URL, the UE MUST NOT perform a DNS lookup.  The target
      transport address of the RTSP SETUP request MUST be set to the IP
      address obtained from the connection line ("c=") in the SDP answer
      and the port from the media line ("m=").
   o  The value of the Session header MUST be set to the same value as
      in the SETUP request.

10.3.  Procedures at Media Server

   The media server MUST answer as defined in [RFC2326] and [RFC3261].

   The media server may use an RTSP ANNOUNCE to notify the UE of any
   asynchronous events related to the media stream (e.g., end-of-
   stream).




Lindquist, et al.       Expires December 11, 2010              [Page 34]

Internet-Draft           Combining SIP and RTSP                June 2010


11.  Examples

   The examples below illustrate how the SDP offer/answer model can be
   used to establish an RTSP content control channel and a video stream
   controlled by RTSP.

11.1.  Content on Demand Session Establishment Using Lightweight RTSP
       (Method 1)

   This section shows examples of SIP and RTSP messages used to
   establish a content on demand session using Method 1 (lightweight
   RTSP).  The corresponding signaling flow is shown in Figure 5.

   Figure 10 shows the SIP INVITE request sent in step (1) of Figure 5.


   INVITE sip:vod1234@10.2.6.123 SIP/2.0
   Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443107619999155
   Max-Forwards: 70
   To: <sip:vod1234@10.2.6.123>
   From: user1 <sip:user1@iptv.example.com>;tag=1180443107619999153
   Call-ID: C-1180443107619999154@10.5.1.72
   CSeq: 1 INVITE
   Contact: user1 <sip:user1@10.5.1.72:5060;transport=udp>
   Content-Length: 156
   Content-Type: application/sdp

   v=0
   o=- 1180443107599999 1 IN IP4 10.5.1.72
   s=-
   t=0 0
   m=application 9 TCP/ETSI_RTSP *
   c=IN IP4 10.5.1.72
   a=setup:active
   a=connection:new
   m=video 10002 RTP/AVP 33
   c=IN IP4 10.5.1.72
   b=AS:17000
   a=recvonly

               Figure 10: SIP INVITE request with SDP offer

   Figure 11 shows the SIP 200 OK (INVITE) response sent in step (6) of
   Figure 5.







Lindquist, et al.       Expires December 11, 2010              [Page 35]

Internet-Draft           Combining SIP and RTSP                June 2010


   SIP/2.0 200 OK
   To: <sip:vod1234@iptv.example.com>;tag=f2ad5t6i-4b
   From: "user1"<sip:user1@iptv.example.com>;tag=1180443107619999153
   Call-ID: C-1180443107619999154@10.5.1.72
   CSeq: 1 INVITE
   Content-Length: 349
   Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443107619999155
   Record-Route: <sip:3Zqkv5baiCsip%3Auser1%40iptv.example.com@
       proxy.iptv.example.com:5060;maddr=130.100.86.35;lr>
   Contact: <sip:10.2.6.123:5060>
   Content-Type: application/sdp

   v=0
   o=- 2890844526 2 IN IP4 10.5.1.72
   s=-
   t=0 0
   m=application 554 TCP/ETSI_RTSP *
   c=IN IP4 10.2.6.123
   a=setup:passive
   a=connection:new
   a=etsi_rtsp-session:56465465
   a=etsi_rtsp-uri:rtsp://foo.com/TV3/TimeShift/823527
   a=etsi_rtsp-offset:0
   m=video 4002 RTP/AVP 33
   c=IN IP4 10.2.6.123
   b=AS:0
   a=sendonly


          Figure 11: SIP 200 OK response (INVITE) with SDP answer

   Figure 12 shows the SIP ACK request sent in step (8) of Figure 5.


   ACK sip:10.2.6.123:5060 SIP/2.0
   Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443108219999156
   Max-Forwards: 70
   Route: <sip:3Zqkv5baiCsip%3Auser1%40iptv.example.com@
       pcscf.iptv.example.com:5060;maddr=130.100.86.35;lr>
   To: <sip:vod1234@10.2.6.123>;tag=f2ad5t6i-4b
   From: user1 <sip:user1@iptv.example.com>;tag=1180443107619999153
   Call-ID: C-1180443107619999154@10.5.1.72
   CSeq: 1 ACK
   Content-Length: 0


                        Figure 12: SIP ACK request




Lindquist, et al.       Expires December 11, 2010              [Page 36]

Internet-Draft           Combining SIP and RTSP                June 2010


   Figure 13 shows the RTSP PLAY request sent in step (9) of Figure 5.


   PLAY rtsp://foo.com/TV3/TimeShift/823527 RTSP/1.0
   CSeq: 2
   Session: 56465465
   Scale: 1
   Range: npt=0-


                       Figure 13: RTSP PLAY request

   Figure 14 shows the RTSP 200 OK (PLAY) response sent in step (10) of
   Figure 5.


   RTSP/1.0 200 OK
   CSeq: 2
   Session: 56465465


                  Figure 14: RTSP 200 OK response (PLAY)

11.2.  Content on Demand Session Establishment Using Full RTSP (Method
       2)

   This section shows examples of SIP and RTSP messages used to
   establish a content on demand session using Method 2 (full RTSP).
   The corresponding signaling flow is shown in Figure 8.

   Figure 15 shows the SIP INVITE request sent in step (1) of Figure 8.




















Lindquist, et al.       Expires December 11, 2010              [Page 37]

Internet-Draft           Combining SIP and RTSP                June 2010


   INVITE sip:vod1234@10.2.6.123 SIP/2.0
   Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443107619999155
   Max-Forwards: 70
   To: <sip:vod1234@10.2.6.123>
   From: user1 <sip:user1@iptv.example.com>;tag=1180443107619999153
   Call-ID: C-1180443107619999154@10.5.1.72
   CSeq: 1 INVITE
   Contact: user1 <sip:user1@10.5.1.72:5060;transport=udp>
   Content-Length: 156
   Content-Type: application/sdp

   v=0
   o=- 1180443107599999 1 IN IP4 10.5.1.72
   s=-
   t=0 0
   m=application 9 TCP/ETSI_RTSP *
   c=IN IP4 10.5.1.72
   a=setup:active
   a=connection:new
   m=video 10002 RTP/AVP 33
   c=IN IP4 10.5.1.72
   b=AS:17000
   a=recvonly

               Figure 15: SIP INVITE request with SDP offer

   Figure 16 shows the SIP 200 OK (INVITE) response sent in step (6) of
   Figure 8.























Lindquist, et al.       Expires December 11, 2010              [Page 38]

Internet-Draft           Combining SIP and RTSP                June 2010


   SIP/2.0 200 OK
   To: <sip:vod1234@iptv.example.com>;tag=f2ad5t6i-4b
   From: "user1"<sip:user1@iptv.example.com>;tag=1180443107619999153
   Call-ID: C-1180443107619999154@10.5.1.72
   CSeq: 1 INVITE
   Content-Length: 349
   Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443107619999155
   Record-Route: <sip:3Zqkv5baiCsip%3Auser1%40iptv.example.com@
       proxy.iptv.example.com:5060;maddr=130.100.86.35;lr>
   Contact: <sip:10.2.6.123:5060>
   Content-Type: application/sdp

   v=0
   o=- 2890844526 2 IN IP4 10.5.1.72
   s=-
   t=0 0
   m=application 554 TCP/ETSI_RTSP *
   c=IN IP4 10.2.6.123
   a=setup:passive
   a=connection:new
   a=etsi_rtsp-uri:rtsp://foo.com/TV3/TimeShift/823527
   a=etsi_rtsp-offset:0
   m=video 4002 RTP/AVP 33
   c=IN IP4 10.2.6.123
   b=AS:0
   a=sendonly


          Figure 16: SIP 200 OK response (INVITE) with SDP answer

   Figure 17 shows the SIP ACK request sent in step (8) of Figure 8.


   ACK sip:10.2.6.123:5060 SIP/2.0
   Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443108219999156
   Max-Forwards: 70
   Route: <sip:3Zqkv5baiCsip%3Auser1%40iptv.example.com@
       pcscf.iptv.example.com:5060;maddr=130.100.86.35;lr>
   To: <sip:vod1234@10.2.6.123>;tag=f2ad5t6i-4b
   From: user1 <sip:user1@iptv.example.com>;tag=1180443107619999153
   Call-ID: C-1180443107619999154@10.5.1.72
   CSeq: 1 ACK
   Content-Length: 0


                        Figure 17: SIP ACK request

   Figure 18 shows the RTSP SETUP request sent in step (9) of Figure 8.



Lindquist, et al.       Expires December 11, 2010              [Page 39]

Internet-Draft           Combining SIP and RTSP                June 2010


   SETUP rtsp://foo.com/TV3/TimeShift/823527 RTSP/1.0
   CSeq: 1
   Transport: RTP/AVP/UDP;unicast;client_port=10002-10003


                       Figure 18: RTSP SETUP request

   Figure 19 shows the RTSP 200 OK (SETUP) response sent in step (10) of
   Figure 8.


   RTSP/1.0 200 OK
   CSeq: 1
   Session: 12345678
   Transport: RTP/AVP/UDP;unicast;client_port=10002-10003;
       server_port=4002-4003


                  Figure 19: RTSP 200 OK response (SETUP)

   Figure 20 shows the RTSP PLAY request sent in step (11) of Figure 8.


   PLAY rtsp://foo.com/TV3/TimeShift/823527 RTSP/1.0
   CSeq: 2
   Session: 12345678
   Scale: 1
   Range: npt=0-


                       Figure 20: RTSP PLAY request

   Figure 21 shows the RTSP 200 OK (PLAY) response sent in step (12) of
   Figure 8.


   RTSP/1.0 200 OK
   CSeq: 2
   Session: 12345678


                  Figure 21: RTSP 200 OK response (PLAY)

11.3.  Content on Demand Session Termination Using Lightweight RTSP
       (Method 1)

   This section shows examples of SIP messages used to terminate a
   content on demand session using Method 1 (lightweight RTSP).  The



Lindquist, et al.       Expires December 11, 2010              [Page 40]

Internet-Draft           Combining SIP and RTSP                June 2010


   corresponding signaling flow is shown in Figure 7.

   Figure 22 shows the SIP BYE request sent in step (2) of Figure 7.


   BYE sip:10.2.6.123:5060 SIP/2.0
   Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443149349999157
   Max-Forwards: 70
   Route: <sip:3Zqkv5baiCsip%3Auser1%40iptv.example.com@
       pcscf.iptv.example.com:5060;maddr=130.100.86.35;lr>
   To: <sip:vod1234@10.2.6.123>;tag=f2adcfg0-4i
   From: user1 <sip:user1@iptv.example.com>;tag=1180443107619999153
   Call-ID: C-1180443107619999154@10.5.1.72
   CSeq: 2 BYE
   Content-Length: 0


                        Figure 22: SIP BYE request

   Figure 23 shows the SIP 200 OK (BYE) response sent in step (7) of
   Figure 7.


   SIP/2.0 200 OK
   To: <sip:vod1234@10.2.6.123>;tag=f2adcfg0-4i
   From: "user1"<sip:user1@iptv.example.com>;tag=1180443107619999153
   Call-ID: C-1180443107619999154@10.5.1.72
   CSeq: 2 BYE
   Content-Length: 0
   Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443149349999157


                   Figure 23: SIP 200 OK response (BYE)

11.4.  Content on Demand Session Termination Using Full RTSP (Method 2)

   This section shows examples of SIP and RTSP messages used to
   terminate a content on demand session using Method 2 (full RTSP).
   The corresponding signaling flow is shown in Figure 9.

   Figure 24 shows the RTSP TEARDOWN request sent in step (1) of
   Figure 9.

   TEARDOWN rtsp://foo.com/TV3/TimeShift/823527 RTSP/1.0
   CSeq: 3
   Session: 12345678





Lindquist, et al.       Expires December 11, 2010              [Page 41]

Internet-Draft           Combining SIP and RTSP                June 2010


                     Figure 24: RTSP TEARDOWN request

   Figure 25 shows the RTSP 200 OK (TEARDOWN) response sent in step (3)
   of Figure 9.

   RTSP/1.0 200 OK
   CSeq: 3

                Figure 25: RTSP 200 OK response (TEARDOWN)

   Figure 26 shows the SIP BYE request sent in step (5) of Figure 9.


   BYE sip:10.2.6.123:5060 SIP/2.0
   Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443149349999157
   Max-Forwards: 70
   Route: <sip:3Zqkv5baiCsip%3Auser1%40iptv.example.com@
       pcscf.iptv.example.com:5060;maddr=130.100.86.35;lr>
   To: <sip:vod1234@10.2.6.123>;tag=f2adcfg0-4i
   From: user1 <sip:user1@iptv.example.com>;tag=1180443107619999153
   Call-ID: C-1180443107619999154@10.5.1.72
   CSeq: 2 BYE
   Content-Length: 0


                        Figure 26: SIP BYE request

   Figure 27 shows the SIP 200 OK (BYE) response sent in step (9) of
   Figure 9.


   SIP/2.0 200 OK
   To: <sip:vod1234@10.2.6.123>;tag=f2adcfg0-4i
   From: "user1"<sip:user1@iptv.example.com>;tag=1180443107619999153
   Call-ID: C-1180443107619999154@10.5.1.72
   CSeq: 2 BYE
   Content-Length: 0
   Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443149349999157


                   Figure 27: SIP 200 OK response (BYE)


12.  Conclusion

   This document described the steps taken at ETSI TISPAN 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



Lindquist, et al.       Expires December 11, 2010              [Page 42]

Internet-Draft           Combining SIP and RTSP                June 2010


   the architecture and functionality (e.g., authentication, charging,
   and QoS) that have already been established around SIP also for RTSP
   streaming.  The document described a model in which SIP/SDP is used
   to establish an RTSP control channel and one or more content delivery
   streams.  The fact that this model has already been adopted by
   standardization bodies such as ETSI TISPAN, 3GPP, and Open IPTV Forum
   proves that there exists a clear need in the industry for a solution
   like this.  Two approaches for combining SIP and RTSP were described.
   The first approach removes session setup and teardown semantics from
   the RTSP protocol, whereas the second approach tries to keep both SIP
   and RTSP as intact as possible


13.  Security Considerations

   RFC 4145 [RFC4145] discusses security issues related to the
   establishment of TCP connections using the SDP 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.

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

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

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


14.  IANA Considerations

14.1.  Registration of the 'TCP/ETSI_RTSP' and 'TCP/TLS/ETSI_RTSP' SDP
       'proto' Values

   This document defines the following two new values for the SDP
   'proto' field under the Session Description Protocol (SDP) Parameters
   registry:



Lindquist, et al.       Expires December 11, 2010              [Page 43]

Internet-Draft           Combining SIP and RTSP                June 2010


                     +-------------------+-----------+
                     |       Value       | Reference |
                     +-------------------+-----------+
                     |   TCP/ETSI_RTSP   |  RFCAAAA  |
                     | TCP/TLS/ETSI_RTSP |  RFCAAAA  |
                     +-------------------+-----------+

                 Table 1: Values for the SDP 'proto' field

14.2.  Registration of the SDP 'etsi_rtsp-uri' Attribute

   This document defines the following SDP att-field under the Session
   Description Protocol (SDP) Parameters registry:

   Contact name:  Jouni.Maenpaa@ericsson.com

   Attribute name:  etsi_rtsp-uri

   Long-form attribute name:  ETSI RTSP URI

   Type of attribute:  Media Level

   Subject to charset:  No

   Purpose of the attribute:  Contains the RTSP URL that is to be used
      in the RTSP content control requests.

   Allowed attribute values:  A string specifying an RTSP URL

14.3.  Registration of the SDP 'etsi_rtsp-session' Attribute

   This document defines the following SDP att-field under the Session
   Description Protocol (SDP) Parameters registry:

   Contact name:  Jouni.Maenpaa@ericsson.com

   Attribute name:  etsi_rtsp-session

   Long-form attribute name:  ETSI RTSP Session

   Type of attribute:  Media Level

   Subject to charset:  No








Lindquist, et al.       Expires December 11, 2010              [Page 44]

Internet-Draft           Combining SIP and RTSP                June 2010


   Purpose of the attribute:  Contains the session ID of the RTSP
      session.  May also specify optionally a keepalive interval for
      RTSP.

   Allowed attribute values:  a=etsi_rtsp-session:<session ID>
      [<timeout>].  The "session ID" attribute is a token specifying an
      RTSP session ID.  The optional "timeout" parameter specifies an
      RTSP keepalive interval in seconds.

14.4.  Registration of the SDP 'etsi_rtsp-offset' Attribute

   This document defines the following SDP att-field under the Session
   Description Protocol (SDP) Parameters registry:

   Contact name:  Jouni.Maenpaa@ericsson.com

   Attribute name:  etsi_rtsp-offset

   Long-form attribute name:  ETSI RTSP Offset

   Type of attribute:  Media Level

   Subject to charset:  No

   Purpose of the attribute:  Specifies the current playback position in
      seconds.

   Allowed attribute values:  A token

14.5.  Registration of the SDP 'etsi_rtsp-version' Attribute

   This document defines the following SDP att-field under the Session
   Description Protocol (SDP) Parameters registry:

   Contact name:  Jouni.Maenpaa@ericsson.com

   Attribute name:  etsi_rtsp-version

   Long-form attribute name:  ETSI RTSP Version

   Type of attribute:  Media Level

   Subject to charset:  No








Lindquist, et al.       Expires December 11, 2010              [Page 45]

Internet-Draft           Combining SIP and RTSP                June 2010


   Purpose of the attribute:  Specifies the RTSP protocol version.

   Allowed attribute values:  As an example, if the sender supports RTSP
      version 1.0, the value of the attribute is "1.0".  If the sender
      supports RTSP 2.0, the value is "2.0".


15.  Acknowledgements

   The authors would like to acknowledge those who have made
   contributions to combining SIP and RTSP over the years.  Among those
   who have provided valuable feedback are Sam Ganesan from Motorola,
   Magnus Westerlund from Ericsson, Steven Whitehead from Verizon,
   Marie-Jose Montpetit from MIT Media Labs, Mikhael Said, Hadriel
   Kaplan from Acme Packet and David Ress from Nortel.


16.  References

16.1.  Normative References

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

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

16.2.  Informative References

   [3GPP TS 26.237]
              "3rd Generation Partnership Project; Technical
              Specification Group Services and System Aspects; IP



Lindquist, et al.       Expires December 11, 2010              [Page 46]

Internet-Draft           Combining SIP and RTSP                June 2010


              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-lindquist-mmusic-sip-rtsp]
              Lindquist, J., Maenpaa, J., Rajagopal, P., and X. Marjou,
              "Session Description Protocol (SDP) Offer/Answer Model For
              Media Control Protocol",
              draft-lindquist-mmusic-sip-rtsp-00 Jun 2009.

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

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

   [I-D.ietf.marjou-mmusic-sdp-rtsp]
              Marjou, X., Lindquist, J., Rajagopal, P., Said, M., and S.
              Ganesan, "Session Description Protocol (SDP) Offer/Answer
              Model For Media Control Protocol",
              draft-marjou-mmusic-sdp-rtsp-01 (expired) Feb 2008.

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

   [RFC2048]  Freed, N., Klensin, J., and J. Postel, "Multipurpose
              Internet Mail Extensions (MIME) Part Four: Registration
              Procedures", BCP 13, RFC 2048, November 1996.

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

   [RFC3312]  Camarillo, G., Marshall, W., and J. Rosenberg,



Lindquist, et al.       Expires December 11, 2010              [Page 47]

Internet-Draft           Combining SIP and RTSP                June 2010


              "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


   Jouni Maenpaa
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Jouni.Maenpaa@ericsson.com




Lindquist, et al.       Expires December 11, 2010              [Page 48]

Internet-Draft           Combining SIP and RTSP                June 2010


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

   Email: priyarajagopal@motorola.com


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

   Email: xavier.marjou@orange-ftgroup.com



































Lindquist, et al.       Expires December 11, 2010              [Page 49]


