MMUSIC Working Group X. Marjou Internet-Draft France Telecom Expires: August 28, 2008 J. Lindquist Ericsson P. Rajagopal Motorola M. Said France Telecom S. Ganesan Motorola February 25, 2008 Session Description Protocol (SDP) Offer/Answer Model For Media Control Protocol draft-marjou-mmusic-sdp-rtsp-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Marjou, et al. Expires August 28, 2008 [Page 1] Internet-Draft SDP Offer/Answer February 2008 Abstract This draft presents an approach to content on demand that relies on a session management protocol and SDP offer/answer model [6] to establish media control and media delivery flows. this approach would be beneficial for some applications such as IPTV or applications that require a mix of real-time and streaming flows. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Characteristics . . . . . . . . . . . . . . . . . . . 4 5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 5 8. Establishment of Media Control and Media Delivery Channels . . 6 8.1. Procedures at the SDP Offerer . . . . . . . . . . . . . . 6 8.1.1. Media Control Client as SDP offerer . . . . . . . . . 6 8.1.2. Media Control Server as SDP offerer . . . . . . . . . 7 8.2. Procedures at SDP Answerer . . . . . . . . . . . . . . . . 8 8.2.1. Media Control Server as SDP answerer . . . . . . . . . 8 8.2.2. Media Control Client as SDP answerer . . . . . . . . . 9 9. Media Control Protocol . . . . . . . . . . . . . . . . . . . . 9 9.1. Procedures at the Media Control Client . . . . . . . . . . 10 9.1.1. Media Playback Initiation Procedure . . . . . . . . . 10 9.1.2. Media Playback Modification Procedure . . . . . . . . 10 9.1.3. Media Playback Information Retrieval and Setting Procedure . . . . . . . . . . . . . . . . . . . . . . 10 9.1.4. Media Event Notification Procedure . . . . . . . . . . 11 9.2. Procedures at Media Control Server . . . . . . . . . . . . 11 10. Modification of Media Delivery Channel(s) . . . . . . . . . . 11 11. Teardown of Media Control and Media Delivery Channels . . . . 11 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 15. Security Considerations . . . . . . . . . . . . . . . . . . . 12 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Marjou, et al. Expires August 28, 2008 [Page 2] Internet-Draft SDP Offer/Answer February 2008 1. Introduction IP-based networks are continually improving in terms of bandwidth capacity and transport quality of service. At the same time, broadband services are continually expanding globally - both in terms of reach and value-added services. These developments are leading to an increase in the number and variety of deployment scenarios for streaming media applications. Many of these scenarios impose challenging new requirements on the signaling protocols used for these applications in terms of flexibility, scalability and network independence. This ID describes the establishment of a streaming session using session management protocol and SDP offer/answer model [6] to establish media control and media delivery flows. The media control protocol could based on a lightweight Real Time Streaming Protocol (RTSP) [3] compatible protocol as described in this document. The justification for using session management protocol such as SIP [2] and lightweight version of a streaming protocol such as RTSP is that SIP is used as a rendez-vous mechanism (among other capabilities to go through NAT, to restrict a media session to a given user), while RTSP is used for the trick-play mechanism within a multimedia session. While this approach has created some controversy as RTSP and SIP are not used in the same context and RTSP is a basic protocol for a large number of commercial Video on demand and content players, the protocol presented here is required by a growing number of Internet Protocol Television (IPTV) implementations. It remains fully compatible with standard SIP and RTSP. 2. Problem Analysis Although RTSP works perfectly well as a standalone solution, there are some use cases when it is desirable to establish RTSP-like session with the SDP offer/answer model. A first example of use-case is a scenario mixing video-surveillance with a regular call: a user monitors a remote scene, possibly with trick play commands, and when a remote user appears at the remote scene, he engages a multimedia conversation with this remote user. A second example of use-case is a scenario where trick play commands are possible within a conference. A user joins a conference late and uses a fast rewind command to come back to the beginning of the presentation and possibly learn the names of the participants.This is also reflected by the convergence in industry between essentially the telecommunications (where signaling SIP is dominant) and entertainment (where RTSP streaming is the favored solution). A last exemple of use-case is a scenario where the network wants to Marjou, et al. Expires August 28, 2008 [Page 3] Internet-Draft SDP Offer/Answer February 2008 control the usage of content of demand by the user and may initiate network-initiated deactivation of streaming session. The use-cases clearly show that most of the time RTSP only or another media control protocol is not sufficient. The use cases also show that that the session setup negotiations are usually independent of the media controls. It is also important to to note that other Standards Developing Organizations (SDOs) like the European Telecommunications Standards Institute (ETSI) TISPAN are considering an using an integrated SIP/ RTSP approach for delivering IPTV services with SIP/SDP being used used for session management and RTSP for media control. RTSPhas been widely adopted, has been proven successful and provides a good "running code and rough consensus" reason to keep it for media controls within SIP sessions. Although this draft investigates the use of SDP to convey RTSP media control information, this does not preclude the option of using this approach for other media control protocols. 3. Requirements In this document, the key words "MUST", "MUST NOT", "REQUIRED", "will", "will NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, [1] and indicate requirement levels for compliant implementations. 4. Protocol Characteristics The following section provides an overview of the design goals of the protocol o The session management protocol should be able to initiate/modify/ terminate media control and media delivery flows from client and server side using SDP offer/answer mechanism o The media control protocol for the delivery of A/V must be negotiated using SDP offer/answer mechanism o The media control protocol must have the possibility to select the controlled media among the different media of the session (ie: media grouping) o The media control protocol must allow for trick-play commands such as PLAY, REWIND, FORWARD, PAUSE commands o The media control protocol must allow for asynchronous media event notifications (eg: end-of-stream)" Marjou, et al. Expires August 28, 2008 [Page 4] Internet-Draft SDP Offer/Answer February 2008 o The media control protocol should work over tcp 5. Terminology Media Control Client : Entity that is consumer of the media streams. It implements a lightweight version of RTSP client and uses SDP offer-answer model to negotiate the media control channel. Media Control Server: Entity that is consumer of the media streams. It implements a lightweight version of RTSP server and uses SDP offer-answer model to negotiate the media control channel. Media Control Channel: End-to-end communication channel between the Media Control Client and Media Control Serverused for carrying media trick play commands such as play,pause, rewind etc. Media Delivery Channel:End-to-end communication channel between the Media Control Client and Media Control Serverfor carrying the streaming media Agent:Refers to Media Control Server or Media Control Client See [3] and [2] for terminology. 6. Acronyms COD Content on demand 7. Overall Operation The overall operation is as follows:- Establishment of Media Control and Media Delivery Channels :The Media Control Client uses the session management protocol associated to the SDP offer-answer exchange with the Media Control Serverin order to establish the relevant media control channel and one or more media delivery channels that are to be controlled by the RTSP media control channel. The relevant SDP parameters such as media type, transport etc. required for establishing the content delivery channels may be obtained apriori by the Media Control Client via HTTP from content guide server, EPG server etc. or may even be delivered as part of initial SDP exchange. Media control :Once the media control session is established, media playback controls are issued directly using the media control Marjou, et al. Expires August 28, 2008 [Page 5] Internet-Draft SDP Offer/Answer February 2008 protocol (e.g. subset of RTSP) as well as handling of any media events. This includes trick play commands. If a subset of RTSP is used, examples of commands would be RTSP PAUSE,RTSP PLAY etc. Note that in the future other media control protocols than RTSP-based may be used for media playback control. Modification of Media Delivery channel(s) : Once established, the Media Control Client or Media Control Servermay add/remove/modify any of the media delivery channels using the session management protocol by updating SDP description. Teardown of Media Control and associated Media Delivery Channel : Teardown of media control and associated media delivery channels may be initiated by the Media Control Client or the Media Control Serverusing the session management protocol. This is used to release all resources associated with the media control channel and the media delivery channels. 8. Establishment of Media Control and Media Delivery Channels This section describes the procedures to be performed at an agent for establishing Media Control Channel session and associated Media Delivery Channel using SDP offer/answer model. 8.1. Procedures at the SDP Offerer 8.1.1. Media Control Client as SDP offerer If the Media Control Client is the SDP offerer, then the procedures in this section MUST be followed to establish the media control session and one or more media delivery channels. The SDP offer is per SDP specification [7]. The media line for RTSP media control channel is included with following values- o The media field MUST have a value of "application". o The port field MUST indicate a TCP port, it MUST be set to a value of 9, which is the discard port. o This specification defines two new values for the transport field: TCP/LTW_RTSP and TCP/TLS/LTW_RTSP. The former is used when RTSP runs directly on top of TCP and the latter is used when RTSP runs on top of TLS, which in turn runs on top of TCP. o The fmt parameter MUST be included and MUST indicate the media control protocol. This document defines "control_ltw_rtsp". An "a=setup" attribute must be present and set to "active" An "a= connection" attribute must be present and set as "new" Marjou, et al. Expires August 28, 2008 [Page 6] Internet-Draft SDP Offer/Answer February 2008 The SDP offer MUST additionally include at least one media delivery channel descriptions by specifying the relative m-line(s) It MUST include a "a=recvonly" attribute. It MAY include a "b=" line indicating the bandwidth necessary to handle this media delivery channel. The SDP offer MAY indicate the association between the Media Control channel and the Media Delivery Channels that are under its control. If not included, it is assumed that all described Media Delivery Channel are under its control. If not, it MUST be explicitly indicated. [OPEN ISSUE1: Further analysis is required on how to specify the association of media delivery channels with the lightweight RTSP media control channel.This is to allow SDP description to interleave media delivery streams that are associated with lightweight RTSP media control channels with those media delivery channels that are not controlled] When receiving any SDP answer, the Media Control Client MUST examine the media parameters in the received SDP. The Media Control Client MUST use received SDP parameters for media control procedures as described in section [TBD] 8.1.2. Media Control Server as SDP offerer If the Media Control Serveris the SDP offerer, then the procedures in this section MUST be followed to establish the Media Control Channel and at least one Media Delivery Channel.This SDP offer is specified as per the SDP specification [7].The media line for RTSP media control channel is included with following values- o The media field MUST have a value of "application". o The port field MUST be a TCP port and is set to the port allocated by the Media Control Server. o This specification defines two new values for the transport field: TCP/LTW_RTSP and TCP/TLS/LTW_RTSP. The former is used when RTSP runs directly on top of TCP and the latter is used when RTSP runs on top of TLS, which in turn runs on top of TCP. o The fmt parameter will be set to cotrol_ltw rtsp An "a=setup" attribute MUST be present and set as "passive" An "a=connection" attribute MUST be present and set as "new" One or more a=fmtp lines representing RTSP specific attributes set as follows Marjou, et al. Expires August 28, 2008 [Page 7] Internet-Draft SDP Offer/Answer February 2008 o a "fmtp:control_ltw_rtsp h-session" attribute representing the session Id of the RTSP session o a "fmtp:control_ltw_rtsp h-uri" attribute will be set to the RTSP URL to be used in the RTSP requests The h-uri can be in form of absolute or relative URI. If absolute URI is specified then it is used as is in subsequent RTSP requests by UE. If relative URI is specified in form of a media path, then the RTSP absolute URL is constructed by the Media Control Client using the IPAddress (from c-line) and port (from m-line) as the base followed by h-uri value for the media path. o Optionally a "fmtp:control_ltw_rtsp h-offset" attribute may be included to specify the playback position The SDP offer MUST additionally include at least one Media Delivery Channel descriptions by specifying the relative m-line(s) It MUST include a "a=sendonly" attribute. It MAY include a "b=" line indicating the bandwidth necessary to handle this media delivery channel. 8.2. Procedures at SDP Answerer 8.2.1. Media Control Server as SDP answerer If the Media Control Serveris the SDP answerer, then the procedures in this section MUST be followed to establish the Media Control Channel and at least one Media Delivery channel. The SDP answer is per SDP specification [7]. The media line for RTSP media control channel is included with following values- o The media field will have a value of "application". o The port field MUST be a TCP port and is set to the port allocated by the Media Control Server. A "a=setup" attribute MUST be present and set as "passive" A "a= connection" attribute MUST be present and set as "new" One or more a=fmtp lines representing RTSP media control specific attributes set as follows: o a "fmtp:control_ltw_rtsp h-uri" attribute MUST be set to the RTSP URL to be used in the RTSP media control requests The h-uri can be in form of absolute or relative URI. If absolute URI is specified then it is used as by Media Control Client as-is in subsequent RTSP requests. If relative URI is specified in form of a media path, then the RTSP absolute URL could be constructed by the Media Control Client using the IPAddress (from c-line) and port (from Marjou, et al. Expires August 28, 2008 [Page 8] Internet-Draft SDP Offer/Answer February 2008 m-line) as the base followed by h-uri value for the media path. o a "fmtp:control_ltw_rtsp h-session" attribute representing the session Id of the RTSP session o Optionally a "fmtp:control_ltw_rtsp h-offset" attribute may be included to specify the current playback position. 8.2.2. Media Control Client as SDP answerer If the Media Control Client is the SDP answerer, then the procedures in this section MUST be followed to establish the Media Control Channel and at least one Media Delivery Channel. The SDP answer is per SDP specification [7]. A media line for RTSP media control channel is included with following values- o The media field MUST have a value of "application". o The port field MUST indicate a TCP port, it MUST be set to a value of 9, which is the discard port. o This specification defines two new values for the transport field: TCP/LTW_RTSP and TCP/TLS/LTW_RTSP. The former is used when RTSP runs directly on top of TCP and the latter is used when RTSP runs on top of TLS, which in turn runs on top of TCP. o The fmt parameter MUST indicate the media control protocol. This document defines the value of control_ltw_rtsp. 9. Media Control Protocol This section describes procedures to be performed at an agent for controlling the media delivery channels that have been established using SDP procedures specified in section [TBD] using light weight version of RTSP streaming protocol All the RTSP requests MUST use the same session id as specified in the SDP h-session attribute during media control session establishment. The following RTSP methods MUST be supported for media playback control and media event notifications : o RTSP PLAY(Media Control Client ->Media Control Server) o RTSP PAUSE(Media Control Client -> Media Control Server) o RTSP GET_PARAMETER(Media Control Client -> Media Control Server) o RTSP SET_PARAMETER(Media Control Client -> Media Control Server) o RTSP ANNOUNCE (Media Control Server-> Media Control Client)(TBD: Add reference) o RTSP OPTION (Media Control Client > Media Control Server) Marjou, et al. Expires August 28, 2008 [Page 9] Internet-Draft SDP Offer/Answer February 2008 9.1. Procedures at the Media Control Client 9.1.1. Media Playback Initiation Procedure The Media Control Client MUST follow procedures in this section to initiate media playback using RTSP PLAY method.The RTSP fields in the RTSP PLAY message will be filled as follows: o The RTSP URL will be set to the value retrieved from the h-uri attribute in the SDP response from Media Control Serverin the case of an absolute URI. If the value of h-url is a relative URI that is in the form of a media path, then the RTSP absolute URL is constructed by the Media Control Client using the SDP IPAddress (from c-line) and port (from m-line) as the base followed by h-uri value for the media path. If the value of h-url is a absolute URL the Media Control Client shall not perform DNS lookup. The IP header for the RTSP PLAY message shall be set to the IP address from the connection line ("c=") in the SDP answer and the port from the media line ("m="). Note-The Media Control Client should not perform DNS lookup in order to avoid misaligning the information conveyed in the SDP with whats obtained from DNS lookup. If the IP address provided after the DNS lookup differs from the ones conveyed in the connection and media line the Media Control Client would be required to renegotiate the media control channel in order to open proxies and firewalls that may be in the path o The Range parameter MAY be present and set to the value retrieved from the SDP h-offset attribute. 9.1.2. Media Playback Modification Procedure The Media Control Client MUST follow procedures in this section to change the 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 [3] and [4] 9.1.3. Media Playback Information Retrieval and Setting Procedure The Media Control Client may retrieve the following information using RTSP GET_PARAMETER: o Position: The position in the media in seconds. o Scale: The allowed scales that can be used in the PLAY request. An empty body is allowed for RTSP keep alive.The Media Control Client may also set the position parameter by sending the RTSP SET_PARAMETER request. Marjou, et al. Expires August 28, 2008 [Page 10] Internet-Draft SDP Offer/Answer February 2008 9.1.4. Media Event Notification Procedure If the Media Control Client receives a RTSP ANNOUNCE with a notice- code that it does not recognize, it simply will ignore the request. 9.2. Procedures at Media Control Server The Media Control ServerMUST answer as defined in [3] and [2] The Media Control Server may use an RTSP ANNOUNCE to notify the Media Control Client of any asynchronous events related to the media stream (for example, end-of-stream). 10. Modification of Media Delivery Channel(s) Modification of the media delivery channels including adding, removing or modifying media parameters associated with media delivery channels may be initiated by the Media Control Client or Media Control Server. The Media Control Client and the Media Control Server MUST not modify RTSP control channel m-line description in the SDP if the media delivery streams controlled by RTSP are not removed(port not set to zero in m-lines) in the SDP. 11. Teardown of Media Control and Media Delivery Channels Teardown of the RTSP media control and associated media delivery channels (if any) MAY be initiated by the Media Control Client or Media Control Server. Before any session termination request at session management protocol level, the Media Control Client or the Media Control ServerMUST close he underlying TCP connection if one exists (such as in case of persistent TCP connection) 12. Examples TBD: Some examples of protocol usage to be included 13. Recommendations We propose that further consideration for standardisation in MMUSIC be given to this ID as it is being actively pursued by other IPTV Marjou, et al. Expires August 28, 2008 [Page 11] Internet-Draft SDP Offer/Answer February 2008 standardization bodies for IPTV delivery. 14. IANA Considerations ANy new encoding'encoding format' and the media attributes may need to be registered. 15. Security Considerations TBD. 16. Acknowledgements The authors would like to acknowledge those who provided valuable inputs namely Steven Whitehead from Verizon , Marie-Jose Montpetit from Motorola, David Ress from Nortel, Darren Loher, C. Steck, Osher Hmelnizky, Jonathan Rosenberg, Ravishankar Shiroor, Martti Mela, Alexandre Carinhas and Xupei Li. 17. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Schulzrinne, H., Rao, A., and R. Lanphier, "RTSP: Real Time Streaming Protocol", RFC 2326, April 1998. [4] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and A. Narasimhan, "Real Time Streaming Protocol 2.0 (RTSP)", October 2005. [5] Shanmugan, S., Monaco, P., and B. Eberman, "A Media Resource Control Protocol (MRCP)", RFC 4463, April 2006. [6] Schulzrinne, H. and J. Rosenberg, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005 2005. Marjou, et al. Expires August 28, 2008 [Page 12] Internet-Draft SDP Offer/Answer February 2008 Authors' Addresses Xavier Marjou France Telecom 2, avenue Pierre Marzin Lannion 22307 France Email: xavier.marjou@orange-ftgroup.com Lindquist Ericsson Tellusborgsvaegen 83-87 Hagersten, Hagersten 12637 Sweden Email: jan.lindquist@ericsson.com Priya Rajagopal Motorola 900 Chelmsford street ; T1;09 Lowell, MA 01891 USA Email: priya.rajagopal@motorola.com Mikhael Said France Telecom 38-40 rue du General Leclerc Issy Moulineaux 92794 France Email: mikhael.said@orange-ftgroup.com Sam Ganesan Motorola 80, Central street Boxboro, MA 01719 USA Email: Sam.Ganesan@motorola.com Marjou, et al. Expires August 28, 2008 [Page 13] Internet-Draft SDP Offer/Answer February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Marjou, et al. Expires August 28, 2008 [Page 14]