MMUSIC Working Group J. Lindquist Internet-Draft J. Maenpaa Intended status: Informational Ericsson Expires: December 18, 2009 P. Rajagopal Motorola X. Marjou France Telecom June 16, 2009 SIP/SDP Overlap with RTSP draft-lindquist-mmusic-sip-rtsp-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 18, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Lindquist, et al. Expires December 18, 2009 [Page 1] Internet-Draft SIP/SDP Overlap with RTSP June 2009 Abstract The Session Initiation Protocol (SIP) is widely used for establishing multimedia sessions, whereas the Real Time Streaming Protocol (RTSP) is a protocol for use in streaming media systems. RTSP has a dual role: it establishes a media session for the delivery of streaming media as well as controls the streaming session once it has been set up. Since RTSP is also used for session establishment, there exists an overlap between the functionality provided by SIP and RTSP. In this document, we analyze a model in which SIP and the SDP offer/ answer model are used to set up a streaming session with an RTSP control channel and one or more media delivery streams. Such a model is beneficial since it allows the reuse of current architecture and functionality (e.g., authentication, charging, and QoS) established around SIP also for RTSP-based streaming. Lindquist, et al. Expires December 18, 2009 [Page 2] Internet-Draft SIP/SDP Overlap with RTSP June 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Split Architectures . . . . . . . . . . . . . . . . . . . . . 5 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Reuse of Existing Architecture and its Functionality . . . 6 4.2. Advanced Media Applications . . . . . . . . . . . . . . . 7 4.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Problem Background . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Session Establishment . . . . . . . . . . . . . . . . . . 8 5.2. Session Modification . . . . . . . . . . . . . . . . . . . 10 5.3. Session Termination . . . . . . . . . . . . . . . . . . . 12 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Content Control Protocol Accessing Resources Established by Session Management Protocol . . . . . . . . 13 6.2. Use of Transport Addresses in Content Control and Session Management Protocols . . . . . . . . . . . . . . . 13 6.3. Session Termination . . . . . . . . . . . . . . . . . . . 14 7. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Alternative 1: Full RTSP . . . . . . . . . . . . . . . . . 15 7.1.1. Session Establishment . . . . . . . . . . . . . . . . 15 7.1.2. Session Termination . . . . . . . . . . . . . . . . . 18 7.1.3. Identified Issues and Potential Solutions . . . . . . 19 7.2. Alternative 2: Lightweight RTSP without Session Setup Semantics . . . . . . . . . . . . . . . . . . . . . . . . 20 7.2.1. Session Establishment . . . . . . . . . . . . . . . . 21 7.2.2. Session Termination . . . . . . . . . . . . . . . . . 22 7.2.3. Solutions to the Identified Issues . . . . . . . . . . 23 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9.1. Man-in-the-middle Attack . . . . . . . . . . . . . . . . . 25 9.2. Session Hijacking . . . . . . . . . . . . . . . . . . . . 25 9.3. Privacy Considerations . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Lindquist, et al. Expires December 18, 2009 [Page 3] Internet-Draft SIP/SDP Overlap with RTSP June 2009 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] is a widely-used session establishment and rendezvous protocol. Many existing systems have established mechanisms such as authentication, charging, and Quality of Service (QoS) around SIP. The Real Time Streaming Protocol (RTSP) [RFC2326], [I-D.ietf-mmusic-rfc2326bis], in turn, is a protocol for use in streaming media systems. RTSP allows a client to remote control a streaming media server by issuing commands such as PLAY and PAUSE. RTSP has a dual role: it establishes a media session for the delivery of streaming media as well as controls the streaming session once it has been set up. Since RTSP is also used for session establishment, there exists an overlap between the functionality provided by SIP and RTSP. When using RTSP in systems that have established mechanisms such as authentication, charging, and QoS around SIP, one needs to implement these mechanisms for RTSP as well. In this document, we argue that it would be more efficient to reuse the mechanisms that already exist for SIP. Therefore, we analyze a model in which SIP is used to establish the streaming session. In this model, SIP with SDP offer/ answer exchange [RFC3264] is used to set up an RTSP media control channel and one or more media delivery streams. The media delivery streams can be for instance Real Time Protocol (RTP) streams. Thus, in this approach, RTSP is used to control the media streams that have been set up with SIP. It should be noted that a model in which SIP and SDP offer/answer exchange is used to establish a control channel is by no means a new one. As an example, SIP with SDP offer/answer is used to establish a Binary Floor Control Protocol (BFCP) [RFC4582] control channel in floor controlled conferences [RFC4583]. BFCP is a protocol used to arbitrate access to shared resources (e.g., media streams) in a conference. An example of a network that has established mechanisms such as authentication, charging and QoS around SIP, and which uses also RTSP, is the IPTV system defined by ETSI TISPAN [ETSI TS 183 063]. ETSI TISPAN uses a model in which SIP is used to establish an RTSP content control channel. The TISPAN specifications allow for both full and partial support of the RTSP RFC [RFC2326] as part of the IPTV service. In the case of partial support of RTSP, a lightweight version of RTSP without session setup semantics is used, whereas in the full support scenario, full RTSP with session setup semantics is used. In addition to TISPAN, also the 3rd Generation Partnership Project (3GPP) [3GPP TS 26.237] and the Open IPTV Forum (OIPF) [OIPF Volume 4] have specified a model in which SIP is used to establish an RTSP control channel. Lindquist, et al. Expires December 18, 2009 [Page 4] Internet-Draft SIP/SDP Overlap with RTSP June 2009 The objective of this document is to create a discussion within the MMUSIC working on how to best support RTSP-based media servers and clients in SIP/SDP-based networks. The rest of the document is structured as follows. In Section 3, we discuss architecture and functionality reuse as the main motivation for SIP/RTSP interaction. Section 4 describes split architectures composed of a controller and a media server. In Section 5, we describe the background for the problem. Section 6 states some requirements for a solution that uses separate protocols to establish a session and control the delivery of streaming media. In Section 7, we present possible solutions that fulfill the requirements stated in Section 6. Finally, Section 8 concludes the document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Content Control Protocol We use the term content control protocol to refer to the protocol that is used to control the delivery of media streams. An example of such a protocol is the Real Time Streaming Protocol (RTSP). Session Management Protocol Session management protocol is the protocol that is used to establish content delivery streams and the control channel for the content control protocol. Content Delivery Protocol The content delivery protocol is used for delivering content (e.g., media streams). Trick Play Trick play refers to using controls such as pause, fast forward, rewind, slow-motion, etc. 3. Split Architectures The systems considered in this document use a split (i.e., layered) architecture composed of a controller and a media server. We are using such a generalized architecture to be able to cover different standardized SIP-based architectures for media and IPTV. The media server is among other things responsible for storing media, delivering media flows to users, and transcoding content to different media formats. The controller, in turn, provides user authentication, charging, resource reservation, checking user Lindquist, et al. Expires December 18, 2009 [Page 5] Internet-Draft SIP/SDP Overlap with RTSP June 2009 services, and keeping track of streaming (e.g., for keeping bookmarks), among other things. The expectation is that the controller does not only authenticate users and access to services, but is also able to monitor the session with the media server. The controller may also use a URL to create a dynamic playlist on the media server. We refer to the protocol that is used between a user equipment (UE) and the controller for establishing content delivery stream(s) and a content control channel as the session management protocol. This protocol is responsible for carrying information related to client authentication, charging, and resource reservation, among other things. Between the UE and the media server, a content control protocol is used for the purpose of controlling content delivery. The protocol that is used between the UE and the media server for content delivery is referred to as the content delivery protocol. In this document, we do not define which protocol is used on the interface between the controller and the media server. Instead, we are using generic commands such as "create session", "modify session", and "destroy session" in the signaling flows. 4. Motivation 4.1. Reuse of Existing Architecture and its Functionality The main motivation for using SIP/SDP to establish an RTSP control channel is that it makes possible to reuse existing SIP mechanisms and architecture without the need to implement them for RTSP as well. Examples include authentication, authorization, accounting, security, and network resource management (QoS). Many architectures have established Authentication, Authorization, and Accounting (AAA) mechanisms around SIP. An interface to AAA infrastructure for SIP servers is defined in RFC 4740 [RFC4740]. The Diameter SIP application specified in the RFC can be used to authenticate and authorize the usage of SIP-based multimedia services. SIP has also been extended to carry charging information [RFC3455]. If SIP is used to establish RTSP-controlled media streams, the existing AAA interface can be used to authenticate and authorize the usage of streaming services and to do accounting. Many systems have also established QoS around SIP. It is possible to negotiate the QoS mechanism to use for a particular media stream using SIP/SDP, as described in RFC 5432 [RFC5432]. Also resource management and SIP have been integrated [RFC3312]. The way QoS admission control is integrated with SIP and how a SIP proxy Lindquist, et al. Expires December 18, 2009 [Page 6] Internet-Draft SIP/SDP Overlap with RTSP June 2009 interfaces with QoS policy control is described in RFC 3313 [RFC3313]. RTSP-controlled media streams could greatly benefit from the QoS mechanisms established around SIP. Certain SIP architectures use SIP Application Level Gateways (ALGs) such as Session Border Controllers (SBCs) [I-D.ietf-sipping-sbc-funcs] between the access network and a SIP core network or between two SIP core networks. The SIP/RTSP model proposed in this document makes it possible to reuse this security infrastructure for RTSP-based streaming. The use of SIP to establish RTSP-controlled content delivery streams could make endpoint-hosted streaming easier. The content that a user wants to stream may be stored on a remote user device located behind Network Address Translator (NAT). However, if the remote device is running a SIP application and the user of the remote device has registered from the device to a SIP proxy, the connection that the remote device maintains to its SIP proxy can be used to send a SIP INVITE with SDP payload describing an RTSP control channel and content delivery stream(s) to the remote device. This way the remote content can be streamed even if the remote device is located behind a NAT without requiring new infrastructure. 4.2. Advanced Media Applications Closer interaction between SIP and RTSP would also enable service blending as in the case of an IPTV system wherein information about content being viewed can be shared via presence service or the users can chat about an ongoing program with instant messaging. Also other "watching apart together" scenarios would become possible. The ability to transfer a Content on Demand (CoD) session from one terminal to another is another example. 4.3. Use Cases Use cases motivating SIP/RTSP interaction are discussed in an expired Internet-Draft "Media Playback Control Protocol Requirements" [I-D.ietf-whitehead-mmusic-sip-for-streaming-media]. 5. Problem Background The purpose of this section is to describe the high level procedures required to deliver multimedia streaming content within the architectural framework described in Section 3. The procedures are comprised of three main phases - session establishment, session modification, and session termination. Lindquist, et al. Expires December 18, 2009 [Page 7] Internet-Draft SIP/SDP Overlap with RTSP June 2009 The figures in this section include an optional middlebox [RFC3234] element, since in some environments, there might be an Application Level Gateway (ALG), firewall or Network Address Translator (NAT) device located between the UE and the controller. 5.1. Session Establishment Figure 1 illustrates on a high level the main stages of using the session management protocol to establish the media stream protocol control channel and the content delivery streams. Lindquist, et al. Expires December 18, 2009 [Page 8] Internet-Draft SIP/SDP Overlap with RTSP June 2009 +----+ +-------------+ +------------+ +--------------+ | UE | | (Middlebox) | | Controller | | Media server | +----+ +-------------+ +------------+ +--------------+ | | | | | (1) Session establishment, | | | session management protocol | | |------------>|---------------->| | | | | | | | /-----------\ | | | /(2) Resource \ | | | \ reservation / | | | \-----------/ | | | | | | | /-----------\ | | | / (3) Select \ | | | \ media server/ | | | \-----------/ | | | | (4) Create session | | | |---------------------->| | | | (5) OK | | (6) OK |<----------------------| |<------------|<----------------| | | | | | | | (7) Session establishment, content | | | control protocol | |------------>|---------------------------------------->| | | (8) OK | | |<------------|<----------------------------------------| | | /-----------\ | | | /(9) Resource \ | | | \ commit / | | | \-----------/ | | | | | | | (10) Media control command | |------------>|---------------------------------------->| | | (11) OK | | |<------------|<----------------------------------------| | | | | | | (12) Media | | |<============|<========================================| | | | | Figure 1: Session Establishment The steps in the signaling flow are as follows: Lindquist, et al. Expires December 18, 2009 [Page 9] Internet-Draft SIP/SDP Overlap with RTSP June 2009 1. The UE uses the session management protocol to establish a session with the controller. The session has at least two streams, one for media control and one or more for media transmission. 2. The controller reserves resources for the control channel and media streams. 3. The controller selects an appropriate media server. 4. The controller orders the media server to create a streaming session. 5. The media server returns a success response to the controller. 6. The controller returns a success response to the UE. 7. The resource reservation is committed. 8. The UE sends a content control protocol request to the media server to trigger content control protocol session establishment. It should be noted that this step is only needed if the content control protocol contains session setup semantics. 9. The media server returns a success response to the UE. 10. The UE sends a content control command to the media server. 11. The media server sends a success response to the content control protocol request back to the UE. 12. The media stream is sent to the client. 5.2. Session Modification This section illustrates how a media delivery session is modified. Session modification may be necessary for instance in the context of an IPTV service when the user pauses an ongoing broadcasted program (i.e., issues trick play commands). Such an IPTV service is defined in [ETSI TS 183 063]. Two special use cases that exist for a broadcast session with trick play are discussed below. By trick play, we mean commands such as pause, fast forward, rewind, slow- motion, etc. o The broadcast session is modified to change from multicast to unicast flow. This occurs when the UE activates the trick play mode (e.g., pause or rewind). The same session is used so that the existing resource reservations can be used for the unicast flow. If the session management protocol request that is used to modify the session fails, the broadcast session is kept. o The broadcast session with trick play mode is modified to return to normal broadcast TV. This happens when the UE deactivates the trick play mode by for instance switching from a paused channel to another live broadcast TV channel. The case in which a broadcast session is modified to change from multicast to unicast is illustrated in Figure 2. Lindquist, et al. Expires December 18, 2009 [Page 10] Internet-Draft SIP/SDP Overlap with RTSP June 2009 +----+ +-------------+ +------------+ +--------------+ | UE | | (Middlebox) | | Controller | | Media server | +----+ +-------------+ +------------+ +--------------+ | | | | | (1) Session modification | | | request, session management | | | protocol | | | |------------>|---------------->| | | | | | | | /-----------\ | | | /(2) Resource \ | | | \ reservation / | | | \-----------/ | | | | | | | /-----------\ | | | / (3) Select \ | | | \ media server/ | | | \-----------/ | | | | (4) Modify session | | | |---------------------->| | | | (5) OK | | (6) OK |<----------------------| |<------------|<----------------| | | | /-----------\ | | | /(7) Resource \ | | | \ commit / | | | \-----------/ | | | | | | (8) Content control protocol trick play command | |------------>|---------------------------------------->| | | (9) OK | | |<------------|<----------------------------------------| | | | | Figure 2: Session Modification The steps in Figure 2 are as follows: 1. Upon activation of trick play mode, the UE performs session modification by sending a session management protocol session modification request to the controller, as shown in step (1) of Figure 2. 2. The controller receives additional resources for the media streams according to the session modification request. 3. The controller selects a media server. 4. The controller orders the media server to modify the session. Lindquist, et al. Expires December 18, 2009 [Page 11] Internet-Draft SIP/SDP Overlap with RTSP June 2009 5. The media server returns a success response to the controller. 6. The controller returns a session management protocol OK response to the UE. 7. The controller commits the reservation. 8. The UE starts trick-mode playback by issuing a content control protocol request. 9. The media server returns an content control protocol OK response. 5.3. Session Termination Figure 3 shows on a high level how media streams and the session are terminated. +----+ +-------------+ +------------+ +--------------+ | UE | | (Middlebox) | | Controller | | Media server | +----+ +-------------+ +------------+ +--------------+ | | | | | | Media | | |<============|<========================================| | | (1) Media teardown | |------------>|---------------------------------------->| | | | | | | (2) Media stream(s) terminated | | | | | | | (3) OK | | |<------------|<----------------------------------------| | | | | | (4) Session termination | | |------------>|---------------->| | | | /-----------\ | | | /(5) Resource \ | | | \ release / | | | \-----------/ | | | | (6) Destroy session | | | |---------------------->| | | | (7) OK | | (8) OK |<----------------------| |<------------|<----------------| | | | | | Figure 3: Session Termination The steps in the signaling flow are as follows: 1. The UE uses the content control protocol to tear down the media stream(s). It should be noted that this step is only needed if the content control protocol contains session teardown semantics. Lindquist, et al. Expires December 18, 2009 [Page 12] Internet-Draft SIP/SDP Overlap with RTSP June 2009 2. The media server stops sending the media stream(s). 3. The media server returns a content control protocol success response to the UE. 4. The UE uses the session management protocol to terminate the session. 5. The controller releases the resources that have been reserved for the media stream(s) and the media control channel. 6. The controller orders the media server to destroy the session. 7. The media server returns a success response to the controller. 8. The controller returns a session management protocol success response to the UE. 6. Requirements Based on the signaling flows shown in Section 5, this section identifies some requirements for a solution that uses a session management protocol to establish a control channel for a content control protocol and one or more media streams for content delivery. 6.1. Content Control Protocol Accessing Resources Established by Session Management Protocol REQ-1 The content control protocol needs to be able to access and use resources that have been configured and established by the session management protocol. Different protocols are used for setting up the media streams and for controlling media stream delivery. Thus, there needs to be a way for the content control protocol to refer to the media streams that were set up using the session management protocol. 6.2. Use of Transport Addresses in Content Control and Session Management Protocols REQ-2 The session management protocol is responsible for negotiating media transport related information. The content control protocol and the media stream delivery protocol should use the transport addresses that were negotiated for the media streams and content control channel by the session management protocol. If these addresses need to be changed, the change must be negotiated using the session management protocol. Since different protocols are used for session establishment and media stream control, both protocol stacks need to have the same view on the local and remote transport addresses used for the media streams and the control channel. Therefore, content control protocol Lindquist, et al. Expires December 18, 2009 [Page 13] Internet-Draft SIP/SDP Overlap with RTSP June 2009 messages should be sent to the transport addresses negotiated by the session management protocol and edia should be sent to the transport addresses negotiated during session establishment. Additional problems may arise if the content control protocol is used to redirect the client to connect to another media server. The main issue with redirection is middleboxes. A middlebox inspects the information carried in the session management protocol so that it can open pinholes for the content delivery streams and for the content control channel. The middlebox may not inspect the content control protocol messages sent on the content control channel. Thus, if the media server uses the content control protocol to redirect the UE to connect to another media server, the middlebox state may not get updated. As a result, the media streams sent by the new media server might never reach the UE (or the UE may not even be able to contact the new media server). 6.3. Session Termination REQ-3 The session management protocol and the content control protocol need to perform session termination in a coordinated way. This kind of coordination is required to make sure that the session management protocol will not release resources in the network before the content control protocol has successfully terminated the media streams. Therefore, media teardown procedures should be carried out before the session management protocol is used to terminate the session. Alternatively, if the content control protocol is not used to terminate the media streams, but only the session management protocol is, the above-mentioned coordination is not necessary. 7. Possible Solutions In order to better understand the issues with the reuse of existing architectures and support of a split architecture, this section provides an analysis of existing systems specified by standardization bodies such as ETSI TISPAN and 3GPP. In the remainder of the document, we will assume that the session management protocol is SIP and that the content control protocol is RTSP. The analysis shows the interaction between SIP/SDP and RTSP protocols for these systems and provides alternatives for how RTSP protocol support is supported. The objective is to expose the issues to MMUSIC WG and determine whether the MMUSIC WG considers this work interesting and if so, what should be the next steps to achieve better SIP and RTSP interaction. In this section, we present two alternative solutions that fulfill the requirements stated in Section 6. In both of the solutions, SIP/ Lindquist, et al. Expires December 18, 2009 [Page 14] Internet-Draft SIP/SDP Overlap with RTSP June 2009 SDP is used to establish an RTSP control stream and one or more content delivery streams. In the first alternative, the UE uses full RTSP, whereas in the second alternative, the UE uses RTSP without session setup semantics. 7.1. Alternative 1: Full RTSP 7.1.1. Session Establishment The signaling flow in Figure 4 illustrates how proposed IPTV and streaming systems (e.g., TISPAN) use SIP to set up an RTSP content control channel and RTP content delivery channel(s) in the context of a Content on Demand (CoD) service. The figure is a generalized version of the signaling flow specified in [ETSI TS 183 063]. Lindquist, et al. Expires December 18, 2009 [Page 15] Internet-Draft SIP/SDP Overlap with RTSP June 2009 +----+ +-------------+ +------------+ +--------------+ | UE | | (Middlebox) | | Controller | | Media server | +----+ +-------------+ +------------+ +--------------+ | | | | | (1) INVITE | | |------------>|---------------->| | | | | | | | /-----------\ | | | /(2) Resource \ | | | \ reservation / | | | \-----------/ | | | | | | | /-----------\ | | | / (3) Select \ | | | \ media server/ | | | \-----------/ | | | | (4) Create session | | | |---------------------->| | | | (5) OK | | (6) 200 OK (INVITE) |<----------------------| |<------------|<----------------| | | | /-----------\ | | | /(7) Resource \ | | | \ commit / | | | \-----------/ | | | | | | (8) ACK | | |------------>|---------------->| | | | (9) SETUP | | |------------>|---------------------------------------->| | | (10) 200 OK (SETUP) | |<------------|<----------------------------------------| | | (11) PLAY | | |------------>|---------------------------------------->| | | (12) 200 OK (PLAY) | |<------------|<----------------------------------------| | | (13) RTP | | |<============|<========================================| | | | | Figure 4: RTSP Control Stream Established Using SIP/SDP The steps in the signaling flow are as follows: 1. The UE sends a SIP INVITE request to the controller to set up at least two streams, one for RTSP control and one or more for media transmission. If there is a firewall or SIP ALG between the UE and the controller, it forwards the INVITE and inspects Lindquist, et al. Expires December 18, 2009 [Page 16] Internet-Draft SIP/SDP Overlap with RTSP June 2009 the SDP offer included in the INVITE in order to be able to open pinholes for the streams. It is assumed that the client already knows what resources (i.e., media streams) are associated with the content it is requesting to view. 2. The controller reserves resources for the RTSP and RTP streams. 3. The controller selects an appropriate media server. 4. The controller orders the media server to create a streaming session. 5. The media server returns a success response to the controller. 6. The controller sends a SIP 200 OK (INVITE) response to the UE. The SDP answer included in the response contains an RTSP URL. 7. The resource reservation is committed. 8. The UE returns an ACK to the controller. 9. The UE sends an RTSP SETUP to the media server to trigger RTSP session initiation. The UE learned the server IP address and port for RTSP since the controller returned them in the SDP answer included in the SIP INVITE 200 OK response. The RTSP URL is set to the URL returned in the SDP answer. 10. RTSP 200 OK for RTSP SETUP is sent back to the UE. The RTSP network parameters exchanged in the SETUP request and response are the same as the RTSP network parameters agreed during the SDP offer/answer exchange. The UE should store the Session header included in the response for issuing the RTSP PLAY request. 11. The UE sends an RTSP PLAY request to the media server. The RTSP URL header is set to the URL returned in the SDP answer. 12. The media server sends an RTSP 200 OK for RTSP PLAY back to the UE. 13. The RTP stream is sent to the client IP address indicated by the SDP offer and RTSP SETUP. On sending the RTSP SETUP request, the UE populates the RTSP URL header and determines the destination transport address (by transport address, we refer to IP address and transport protocol port number) as follows: as described above, the RTSP URL header is set to the corresponding media RTSP URL which has been obtained in the SDP answer from the controller. If the RTSP URL contains a domain address, the UE should not perform a DNS lookup. Instead, the target transport address of the RTSP SETUP message should be set to contain the IP address included in the connection line ("c=") of the SDP answer and the port specified in the media line ("m=") of the RTSP control stream. The media server acts as defined in [RFC2326]. The media server must not redirect the RTSP methods using either the REDIRECT method or Redirection status code (3xx). Redirection is not allowed in order to avoid misaligning the information conveyed in the SDP. The problem occurs if the redirected URL differs from the address and Lindquist, et al. Expires December 18, 2009 [Page 17] Internet-Draft SIP/SDP Overlap with RTSP June 2009 port conveyed in the SDP connection and media lines. This is because SIP is used for opening proxies and firewalls for the content control and the content delivery paths. 7.1.2. Session Termination The figure below illustrates how a streaming session is terminated in [ETSI TS 183 063]. +----+ +-------------+ +------------+ +--------------+ | UE | | (Middlebox) | | Controller | | Media server | +----+ +-------------+ +------------+ +--------------+ | | | | | | RTP stream | | |<============|<========================================| | | (1) TEARDOWN | |------------>|---------------------------------------->| | | | | | | (2) RTP stream terminated | | | | | | | (3) 200 OK (TEARDOWN) | |<------------|<----------------------------------------| | | | | | (4) BYE | | |------------>|---------------->| | | | /-----------\ | | | /(5) Resource \ | | | \ release / | | | \-----------/ | | | | (6) Destroy session | | | |---------------------->| | | | (7) OK | | (8) 200 OK (BYE) |<----------------------| |<------------|<----------------| | | | | | Figure 5: Session Termination The steps in the signaling flow are as follows: 1. The UE sends an RTSP TEARDOWN request to the media server. 2. The media server stops sending the RTP content stream(s). 3. The media server returns a 200 OK (TEARDOWN) response to the UE. 4. The UE sends a SIP BYE request to the controller. 5. The controller releases the resources that have been reserved for the RTP and RTSP streams. Lindquist, et al. Expires December 18, 2009 [Page 18] Internet-Draft SIP/SDP Overlap with RTSP June 2009 6. The controller orders the media server to destroy the session. 7. The media server returns a success response to the controller. 8. The controller returns a SIP 200 OK (BYE) response to the UE. 7.1.3. Identified Issues and Potential Solutions In this section, we discuss some issues with the signaling flows shown in the figures above. 7.1.3.1. Correlating SIP INVITE and RTSP SETUP Correlating the SIP INVITE transaction and the RTSP SETUP request may be problematic since there is no session identifier. Also, there is no special IP address and port that would be unique to the session. To solve this problem, either the RTSP URL returned in the SDP answer needs to convey correlation information (as specified in [ETSI TS 183 063]) or a session ID parameter needs to be added to the RTSP SETUP request in order to correlate the RTSP SETUP and SIP INVITE requests. 7.1.3.2. DNS lookup for RTSP URL As explained above, the UE should not perform a DNS lookup for the RTSP URL that the controller returns in the SDP answer. Otherwise there is a risk that a different destination transport address than was returned in the SDP answer will be used for RTSP messages sent to the media server. Also, if the server IP address for RTSP signaling changes from the one negotiated during SDP offer/answer exchange and the UE is located behind a middlebox, the middlebox may drop the packets sent to the new server address. To solve this issue, either the RTSP URL returned in the SDP answer has to include an IP address and port or the UE needs to use the server IP address and port returned in the SDP answer (in "c=" and "m=" lines) for the RTSP control channel as the destination address for RTSP messages. 7.1.3.3. Redirection The media server should not perform redirection for the RTSP SETUP request. The redirection has to be already known prior to the RTSP SETUP since the SDP answer for the SIP INVITE response needs to contain the final destination of the media server. If there is a SIP ALG between the UE and the controller, the SIP ALG opens pinholes for the media delivery stream(s) based on the Lindquist, et al. Expires December 18, 2009 [Page 19] Internet-Draft SIP/SDP Overlap with RTSP June 2009 information conveyed in the SDP offer/answer exchange. If an RTSP REDIRECT request or Redirection status code is later issued on the RTSP control channel, the SIP ALG may never learn the address of the new server. This is because the SIP ALG may not inspect RTSP messages. The result is that new pinholes will not be opened for the RTSP control channel and the media delivery stream(s) coming from the new server. Because of the above-mentioned problems, no redirection should be allowed. 7.1.3.4. Correlating Transport Address in SDP Offer with Transport Header in SETUP The Transport header of the RTSP SETUP request must contain the same information as the SDP offer in the SIP INVITE request. The problem is how to ensure that a client with separate SIP and RTSP stacks can keep the same client IP address and port without affecting the implementation of the stacks. To solve this issue, addresses must be used consistently between SIP INVITE SDP offer and RTSP SETUP transport header. 7.1.3.5. SIP BYE and RTSP TEARDOWN Teardown of the streaming session will not always be possible according to the procedures defined in [RFC2326]. This is because the UE may not be able to send an RTSP TEARDOWN request or receive a response to TEARDOWN request if the resources in the network for the RTSP session have been released when receiving the SIP BYE request. To address this issue, SIP session termination and RTSP session termination must be carried out in a coordinated way. When using both SIP BYE and RTSP TEARDOWN, the media teardown procedures using RTSP TEARDOWN should be executed before the SIP BYE request is sent. An additional issue is that there may be more nodes than the two end- points that normally exist in RTSP that can initiate session termination, for example SIP Back-to-Back User Agents (B2BUAs). As a solution, SIP session termination and RTSP session termination must be carried out in a coordinated way. 7.2. Alternative 2: Lightweight RTSP without Session Setup Semantics In the signaling flows shown in the figures below, a lightweight version of RTSP without session setup semantics is used to control media streams that have been set up using SIP/SDP. Lindquist, et al. Expires December 18, 2009 [Page 20] Internet-Draft SIP/SDP Overlap with RTSP June 2009 7.2.1. Session Establishment Figure 6 illustrates how a session is established when a lightweight RTSP without session setup and teardown semantics is used. +----+ +-------------+ +------------+ +--------------+ | UE | | (Middlebox) | | Controller | | Media server | +----+ +-------------+ +------------+ +--------------+ | | | | | (1) INVITE | | |------------>|---------------->| | | | | | | | /-----------\ | | | /(2) Resource \ | | | \ reservation / | | | \-----------/ | | | | | | | /-----------\ | | | / (3) Select \ | | | \ media server/ | | | \-----------/ | | | | (4) Create session | | | |---------------------->| | | | (5) OK | | (6) 200 OK (INVITE) |<----------------------| |<------------|<----------------| | | | /-----------\ | | | /(7) Resource \ | | | \ commit / | | | \-----------/ | | | | | | (8) ACK | | |------------>|---------------->| | | | (9) PLAY | | |------------>|---------------------------------------->| | | (10) 200 OK (PLAY) | |<------------|<----------------------------------------| | | (11) RTP | | |<============|<========================================| | | | | Figure 6: RTSP without Session Setup Semantics The steps in the signaling flow are as follows: 1. The UE sends a SIP INVITE request to the controller to set up at least two streams, one for RTSP control and one or more for media transmission. The SDP offer included in the INVITE Lindquist, et al. Expires December 18, 2009 [Page 21] Internet-Draft SIP/SDP Overlap with RTSP June 2009 contains a media description for the RTSP content control channel and one or more media descriptions for the content delivery channels. It is assumed that the client already knows what resources (i.e., media streams) are associated with the content it is requesting to view. 2. The controller reserves resources for the RTSP and RTP streams. 3. The controller selects an appropriate media server. 4. The controller orders the media server to create a streaming session. 5. The media server returns a success response to the controller. 6. The controller returns a SIP 200 OK response to the UE. The SDP answer included in the response contains an RTSP session ID parameter. The SDP answer also contains a media description for the RTSP content control channel and one or more media descriptions for the content delivery channels. 7. The resource reservation is committed. 8. The UE returns a SIP ACK to the controller. 9. The UE sends an RTSP PLAY request to the media server. The UE knows the server IP address and port for RTSP since the controller returned them in the SIP INVITE 200 OK response. The session ID parameter the server returned in the SDP answer is included in the Session header of the request. 10. The media server sends a 200 OK response to RTSP PLAY request back to the UE. 11. The RTP stream is sent to the client IP address indicated in the SDP offer. 7.2.2. Session Termination Figure 7 illustrates how a session is terminated when a lightweight RTSP without session setup and teardown semantics is used. Lindquist, et al. Expires December 18, 2009 [Page 22] Internet-Draft SIP/SDP Overlap with RTSP June 2009 +----+ +-------------+ +------------+ +--------------+ | UE | | (Middlebox) | | Controller | | Media server | +----+ +-------------+ +------------+ +--------------+ | | | | | | RTP stream | | |<============|<========================================| | | | | | (1) BYE | | |------------>|---------------->| | | | | | | | | (2) Destroy session | | | |---------------------->| | | | | | | (3) RTP stream terminated | | | | | | | | (4) OK | | | |<----------------------| | | | | | | /-----------\ | | | /(5) Resource \ | | | \ release / | | | \-----------/ | | (6) 200 OK (BYE) | | |<------------|<----------------| | | | | | Figure 7: Session Termination The steps in the signaling flow of Figure 7 are described below: 1. The UE sends a SIP BYE request to the controller to terminate the session and to tear down the media stream(s). 2. The controller orders the media server to destroy the session. 3. The media server stops sending the RTP content stream(s). 4. The media server returns a success response to the controller. 5. The controller releases the resources that have been reserved for the RTP and RTSP streams. 6. The controller returns a SIP 200 OK (BYE) response to the UE. 7.2.3. Solutions to the Identified Issues Below, the same issues that were identified for the signaling flow shown in Figure 4 are discussed for this alternative. 7.2.3.1. Correlating SIP INVITE and RTSP SETUP The RTSP SETUP request is not used in this alternative. A session ID parameter must be returned by the controller in the SDP answer Lindquist, et al. Expires December 18, 2009 [Page 23] Internet-Draft SIP/SDP Overlap with RTSP June 2009 carried in SIP 200 OK response to the SIP INVITE request. This session ID is used in the Session header of RTSP messages such as the PLAY request. 7.2.3.2. DNS Lookup for RTSP URL The same discussion applies as for alternative 1 (see Section 7.1.3.2). 7.2.3.3. Redirection Selection of media server is performed prior to RTSP PLAY, so no redirection is expected. 7.2.3.4. Correlating Transport Address in SDP Offer with Transport Header in SETUP Since RTSP SETUP is not used, there is no correlation issue. 7.2.3.5. SIP BYE and RTSP TEARDOWN Since RTSP TEARDOWN is not used, there is no overlap between SIP BYE and RTSP TEARDOWN requests. Resources are released when the SIP BYE request is received. 8. Conclusion This document requests a guideline from the MMUSIC WG regarding how to achieve better interaction between the SIP and RTSP protocols. We see such an interaction beneficial since it makes it possible to reuse much of the architecture and functionality (e.g., authentication, charging, and QoS) that have already been established around SIP also for RTSP streaming. In this document, we propose a model in which SIP/SDP is used to establish an RTSP control channel and one or more media delivery streams. A similar model has already been adopted by standardization bodies such as ETSI TISPAN, 3GPP, and Open IPTV Forum, which proves that there exists a clear need in the industry for a solution like this. Two alternatives are provided. The first alternative tries to keep both SIP and RTSP as intact as possible, whereas the second alternative removes session setup and teardown semantics from the RTSP protocol. The purpose of this document is to find out whether the MMUSIC WG considers this work interesting and if so, what should be the next steps to achieve better SIP and RTSP interaction. Lindquist, et al. Expires December 18, 2009 [Page 24] Internet-Draft SIP/SDP Overlap with RTSP June 2009 9. Security Considerations RFC 4145 [RFC4145] discusses security issues related to the establishment of TCP connections using the offer/answer model. Security issues related to the SDP offer/answer model and SDP are discussed in the SDP offer/answer model RFC [RFC3264], and the SDP RFC [RFC4566], respectively. 9.1. Man-in-the-middle Attack Numerous attacks are possible if an attacker can modify SDP offers or answers in transit. These attacks are discussed in the SDP offer/ answer model RFC [RFC3264]. 9.2. Session Hijacking A session ID parameter is used to correlate SIP and RTSP. Session hijacking may be possible if the session ID is exposed to a third party. 9.3. Privacy Considerations If the identity of a client is to remain hidden, the instructions in [RFC3261] can be followed to generate anonymous SIP header field values. 10. IANA Considerations This document has no actions for IANA. 11. References 11.1. Normative References [I-D.ietf-mmusic-rfc2326bis] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", draft-ietf-mmusic-rfc2326bis-20 (work in progress), March 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. Lindquist, et al. Expires December 18, 2009 [Page 25] Internet-Draft SIP/SDP Overlap with RTSP June 2009 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 11.2. Informative References [3GPP TS 26.237] "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) based Packet Switch Streaming (PSS) and Multimedia Broadcast/Multicast Service (MBMS) User Service; Protocols (Release 8)", 3GPP TS 26.237 V8.1.1 (2009-03). [ETSI TS 183 063] "Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); IMS-based IPTV Stage 3 Specification", ETSI TS 183 063 v2.1.0 (2008-06). [I-D.ietf-sipping-sbc-funcs] Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen, A., and M. Bhatia, "Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments", draft-ietf-sipping-sbc-funcs-08 (work in progress), January 2009. [I-D.ietf-whitehead-mmusic-sip-for-streaming-media] Whitehead, S., Montpetit, M., Marjou, X., Ganesan, S., and J. Lindquist, "Media Playback Control Protocol Requirements", draft-whitehead-mmusic-sip-for-streaming-media-05 (expired) May 2008. [OIPF Volume 4] "Open IPTV Forum - Release 1 Specification; Volume 4 - Protocols", V1.0 (January 6, 2009). Lindquist, et al. Expires December 18, 2009 [Page 26] Internet-Draft SIP/SDP Overlap with RTSP June 2009 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [RFC3313] Marshall, W., "Private Session Initiation Protocol (SIP) Extensions for Media Authorization", RFC 3313, January 2003. [RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003. [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006. [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006. [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C., and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", RFC 4740, November 2006. [RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)", RFC 5432, March 2009. Authors' Addresses Jan Lindquist Ericsson Tellusborgsvaegen 83-87 Hagersten 12637 Sweden Email: jan.lindquist@ericsson.com Lindquist, et al. Expires December 18, 2009 [Page 27] Internet-Draft SIP/SDP Overlap with RTSP June 2009 Jouni Maenpaa Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Jouni.Maenpaa@ericsson.com Priya Rajagopal Motorola 900 Chelmsford street ; T1;09 Lowell, MA 01891 USA Email: priya.rajagopal@motorola.com Xavier Marjou France Telecom 2, avenue Pierre Marzin Lannion 22307 France Email: xavier.marjou@orange-ftgroup.com Lindquist, et al. Expires December 18, 2009 [Page 28]