Network Working Group J. Lindquist Internet-Draft J. Maenpaa Intended status: Informational Ericsson Expires: November 7, 2010 P. Rajagopal Motorola X. Marjou France Telecom May 6, 2010 Controlling Session Initiation Protocol (SIP)-Established Content Delivery Channels Using the Real-Time Streaming Protocol (RTSP) draft-lindquist-sip-rtsp-00.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 November 7, 2010 [Page 1] Internet-Draft Combining SIP and RTSP May 2010 This Internet-Draft will expire on November 7, 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 November 7, 2010 [Page 2] Internet-Draft Combining SIP and RTSP May 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 . . . . . . . . . . . . . . . . 30 9.2.1. Controller as SDP Answerer . . . . . . . . . . . . . . 30 9.3. Modification of Content Delivery Channel(s) . . . . . . . 31 Lindquist, et al. Expires November 7, 2010 [Page 3] Internet-Draft Combining SIP and RTSP May 2010 10. Content Control Protocol . . . . . . . . . . . . . . . . . . . 32 10.1. Lightweight RTSP . . . . . . . . . . . . . . . . . . . . . 32 10.2. Procedures at the UE . . . . . . . . . . . . . . . . . . . 32 10.2.1. Media Setup Procedure . . . . . . . . . . . . . . . . 32 10.2.2. Media Playback Initiation Procedure . . . . . . . . . 32 10.2.3. Media Playback Modification Procedure . . . . . . . . 33 10.2.4. Media Playback Information Retrieval and Setting Procedure . . . . . . . . . . . . . . . . . . . . . . 33 10.2.5. Media Event Notification Procedure . . . . . . . . . . 33 10.2.6. Media Teardown Procedure . . . . . . . . . . . . . . . 33 10.3. Procedures at Media Server . . . . . . . . . . . . . . . . 34 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11.1. Content on Demand Session Establishment Using Lightweight RTSP (Method 1) . . . . . . . . . . . . . . . 34 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 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 16.1. Normative References . . . . . . . . . . . . . . . . . . . 45 16.2. Informative References . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 Lindquist, et al. Expires November 7, 2010 [Page 4] Internet-Draft Combining SIP and RTSP May 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 bet> yes, something along those lines would work. In any case, I think Jouni > is currently editing the draft in order to address my comments.ween 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. Lindquist, et al. Expires November 7, 2010 [Page 5] Internet-Draft Combining SIP and RTSP May 2010 SIP/RTSP interaction has been discussed several times in the MMUSIC 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 conclusion of the discussions triggered by the drafts has been that there is 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) to describe the solution specified by ETSI TISPAN. 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 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. Lindquist, et al. Expires November 7, 2010 [Page 6] Internet-Draft Combining SIP and RTSP May 2010 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. 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. Lindquist, et al. Expires November 7, 2010 [Page 7] Internet-Draft Combining SIP and RTSP May 2010 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 November 7, 2010 [Page 8] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 9] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 10] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 11] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 12] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 13] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 14] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 15] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 16] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 17] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 18] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 19] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 20] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 21] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 22] Internet-Draft Combining SIP and RTSP May 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 RTSP session that was established during session initiation by closing the underlying TCP connection. 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 November 7, 2010 [Page 23] Internet-Draft Combining SIP and RTSP May 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. 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 November 7, 2010 [Page 24] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 25] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 26] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 27] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 28] Internet-Draft Combining SIP and RTSP May 2010 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: 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. Lindquist, et al. Expires November 7, 2010 [Page 29] Internet-Draft Combining SIP and RTSP May 2010 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 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. 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". Lindquist, et al. Expires November 7, 2010 [Page 30] Internet-Draft Combining SIP and RTSP May 2010 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: []. 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 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 Optionally, the answer MAY also include an "etsi_rtsp-timeout" attribute to . 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). Lindquist, et al. Expires November 7, 2010 [Page 31] Internet-Draft Combining SIP and RTSP May 2010 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) 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: Lindquist, et al. Expires November 7, 2010 [Page 32] Internet-Draft Combining SIP and RTSP May 2010 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. 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: Lindquist, et al. Expires November 7, 2010 [Page 33] Internet-Draft Combining SIP and RTSP May 2010 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). 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. Lindquist, et al. Expires November 7, 2010 [Page 34] Internet-Draft Combining SIP and RTSP May 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: From: user1 ;tag=1180443107619999153 Call-ID: C-1180443107619999154@10.5.1.72 CSeq: 1 INVITE Contact: user1 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 November 7, 2010 [Page 35] Internet-Draft Combining SIP and RTSP May 2010 SIP/2.0 200 OK To: ;tag=f2ad5t6i-4b From: "user1";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: Contact: 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: To: ;tag=f2ad5t6i-4b From: user1 ;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 November 7, 2010 [Page 36] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 37] Internet-Draft Combining SIP and RTSP May 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: From: user1 ;tag=1180443107619999153 Call-ID: C-1180443107619999154@10.5.1.72 CSeq: 1 INVITE Contact: user1 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 November 7, 2010 [Page 38] Internet-Draft Combining SIP and RTSP May 2010 SIP/2.0 200 OK To: ;tag=f2ad5t6i-4b From: "user1";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: Contact: 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: To: ;tag=f2ad5t6i-4b From: user1 ;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 November 7, 2010 [Page 39] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 40] Internet-Draft Combining SIP and RTSP May 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: To: ;tag=f2adcfg0-4i From: user1 ;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: ;tag=f2adcfg0-4i From: "user1";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 November 7, 2010 [Page 41] Internet-Draft Combining SIP and RTSP May 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: To: ;tag=f2adcfg0-4i From: user1 ;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: ;tag=f2adcfg0-4i From: "user1";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 November 7, 2010 [Page 42] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 43] Internet-Draft Combining SIP and RTSP May 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 November 7, 2010 [Page 44] Internet-Draft Combining SIP and RTSP May 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: []. 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 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 Lindquist, et al. Expires November 7, 2010 [Page 45] Internet-Draft Combining SIP and RTSP May 2010 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 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 Lindquist, et al. Expires November 7, 2010 [Page 46] Internet-Draft Combining SIP and RTSP May 2010 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, "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 Lindquist, et al. Expires November 7, 2010 [Page 47] Internet-Draft Combining SIP and RTSP May 2010 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 Priya Rajagopal Motorola 900 Chelmsford street ; T1;09 Lowell, MA 01891 USA Email: priya.rajagopal@motorola.com Xavier Marjou France Telecom 2, avenue Pierre Marzin Lannion 22307 France Email: xavier.marjou@orange-ftgroup.com Lindquist, et al. Expires November 7, 2010 [Page 48]