Network Working Group S. Whitehead Internet-Draft Verizon Laboratories Inc. Intended status: Informational M. Montpetit Expires: August 25, 2008 Motorola X. Marjou France Telecom S. Ganesan Motorola February 22, 2008 Media Playback Control Protocol Requirements draft-whitehead-mmusic-sip-for-streaming-media-03 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 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The media playback control functionality controls the delivery of streaming media by the means of commands like pause, fast forward, fast rewind, slow forward, slow rewind. This document presents some Whitehead, et al. Expires August 25, 2008 [Page 1] Internet-Draft media playback control requirements February 2008 of the requirements for a media control protocol that does not contain any session setup semantics in it. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Characteristics . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Use Case Descriptions . . . . . . . . . . . . . . . . . . . 4 3.3. Server Control of Streaming Session . . . . . . . . . . . . 5 3.4. Private/Firewalled video content . . . . . . . . . . . . . 5 3.5. VOD services that requires resource or QOS-guarantees . . . 6 3.6. Intelligent selection of media encoding . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Informative references . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Whitehead, et al. Expires August 25, 2008 [Page 2] Internet-Draft media playback control requirements February 2008 1. Introduction This document defines the requirements for a media control protocol distinct from the session control protocol for Content on demand media streams. Historically Content on Demand(COD) or Video on Demand (VOD) stream delivery has been controlled by RTSP as both the session set up protocol as well as the media control protocol. RTSP [1] and its successor [2] define semantics for both session setup as well as media control, viz commands like pause, Rewind etc. Similarly SIP has been the protocol of choice for end to end session establishment and rendezvous [3] . These functionalities in the context of conversational services has been the main raison d'etre and forte of SIP. There exist environments, circumstances and use cases where it is desirable to use SIP for session establishment and rendezvous, while retaining RTSP's capabilities for media and play back control. Such circumstances are increasing in number given that user agents with wide ranging capabilities are become much more common in deployments. Good Integration with existing RTSP deployments is also desirable under these conditions. Section 3 describes some use cases that motivate additional work around a media control protocol for Content on Demand. Section 4 lays out the requirements for a media control protocol, ideally some form of lightweight RTSP without its session establishment semantics, that can be used with a session establishment and rendezvous protocol. 2. Terminology In this document, the following key words are used with the interpretations as follows. MUST - The use of this phrase means that it is an absolute requirement. SHOULD - The use of this phrase implies that while this is a requirement, there may be exigent circumstances when this requirement may be waived; however, the circumstances of the waiver must be thoroughly understood, and carefully weighed before choosing a different course. Whitehead, et al. Expires August 25, 2008 [Page 3] Internet-Draft media playback control requirements February 2008 MAY - The use of this phrase deems that this item is truly optional. A given implementation may choose to include this item due to market place and implementation constraints, while another may completely ignore it. 3. Use Case Scenarios The scope of scenarios for this document includes applications with the following characteristics: content-on-demand, streaming media, unicast-media streams, live or recorded content, ubiquitous access (any-device, any-access). While of interest, non-streaming media applications, such as downloaded media services, are outside the scope of this document. 3.1. Characteristics For the purposes of this document, the term 'controlled streaming media application' represents a class of applications with the following characteristics: o Multiple servers that can be a source of content but showing up as a single muxed stream at the client. o One or more clients can receive the content. o The media stream(s) needs to be delivered isochronously, in the most common case: the client intends to begin rendering the media before delivery is complete. o Less common but equally valid, the server does not have resources to buffer content until the client is ready to receive it, e.g., a live feed. o A session exists between source (e.g. server or peer) and destination (e.g. client or peer). o The session is established, managed, and terminated through the use of a signaling protocol, in which control messages are exchanged (either directly or indirectly) between the source and the destination referred to as 'session signaling'. o The application supports media stream control. The client(s), or a proxy element acting on behalf of the client(s), has the ability to manipulate the media stream (or other aspect of the application) via signaling. This is referred to as media control signaling (or application signaling ). 3.2. Use Case Descriptions As IP-based broadband data services have continued to develop and expand, opportunities for streaming media applications have also Whitehead, et al. Expires August 25, 2008 [Page 4] Internet-Draft media playback control requirements February 2008 proliferated and expanded beyond the traditional framework. This section describes several streaming media application use case scenarios. These scenarios illustrate the variety of conditions and environments in which streaming media applications need to operate. Use cases are used with the purpose of clarifying the 'streaming media application' and to explore the application space. The objectives are to: o Clarify the frame / scope the discussion. o Illustrate some of usage scenarios. o Identify some of the key attributes that characterize these use cases. 3.3. Server Control of Streaming Session During a streaming session, the operator may want to redirect or move pending sessions in order to for e.g., upgrade the server. Therefore, the server will initiate a session redirect. Another use case of Server control operation is when the server decides to initiate a session to the user, based on user preconfigured-settings (e.g. reminders). Further, sessions that are indefinitely paused by the client need to be terminated and server resources reclaimed at the operators discretion. This would also be true for sessions where the client may have become unresponsive. 3.4. Private/Firewalled video content In this use case, the user, while not on his home network, wants to access content that is stored on his personal or home network, e.g., a pre-recorded show on a PVR device, or a monitoring camera at his or her home location that is capable of providing a live feed as well as record it locally as a PVR asset. In the case of a live monitoring camera in a home network, the user wishes to transition from watching a live stream of the feed to being able to move backwards and forwards using media control commands on the stored content of the monitoring device. This translates logically to transitioning from watching live TV programming to Time shifted TV or PVR type of viewing. Being able to do it in the context of the same session is desirable. In the case of a home network based PVR, it is more than likely that the home gateway is not set up to be an inbound device for various session setup requests to enable the external client to traverse the protocol unaware IP NAT device commonly found at the edge of home networks. Whitehead, et al. Expires August 25, 2008 [Page 5] Internet-Draft media playback control requirements February 2008 In both these cases, the video server is behind a firewall. In the first case, the transition from one mode (live feed) to another (COD), would entail multiple messages for staying within a session. Also, the client being exterior to the firewall, needs to establish a TCP connection from "out" to "in". RTSP as in stands currently does not deal with these adequately. A rendezvous capable protocol like SIP could provide this in addition to client identity and location. 3.5. VOD services that requires resource or QOS-guarantees Consider a Video on Demand (stored video) service provided as a unicast session to an end user device from a server. The user requests a VOD movie. If the operator uses a network proxy to request and guarentee QoS for the delivery of the movie from the server to the client, currently RTSP does not provide the means of guarenteeing that all subsequent messages that form part of the RTSP session will go through the network proxy that manages the QoS. In this particular use case, an end to end session setup and management protocol would be helpful. 3.6. Intelligent selection of media encoding A user orders content to be delivered to its current device the content could exist in different format (e.g. standard definition or high definition) or encoding (MPEG2 or MPEG4 for example). Media negotiations may need to be determined based on network transport capabilities. This is based on knowledge of access-network type. 4. Requirements This section outlines the key requirements that need to be satisfied in order to have a media control protocol acting as a control stream within a multimedia session. REQ-1 The media control protocol must support commands such as play, pause, rewind, forward, fast rewind, fast forward, slow rewind, and slow forward. REQ-2 It must be possible to negotiate the media control control protocol of a media stream. REQ-3 If the media control protocol does not apply to all media streams of a given session, it must be possible to indicate the specific media streams that are under the scope of the trick-play control protocol. Whitehead, et al. Expires August 25, 2008 [Page 6] Internet-Draft media playback control requirements February 2008 REQ-4 The media control protocol must allow for asynchronous media event notifications (e.g.: end-of-stream)". REQ-5 The protocol SHOULD work over TCP. REQ-6 [[Any other?]]. 5. Security Considerations T.B.D. 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgements T.B.D. 8. Informative references [1] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [2] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", draft-ietf-mmusic-rfc2326bis-16 (work in progress), November 2007. [3] 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. [4] Shanmugham, S., Monaco, P., and B. Eberman, "A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks", RFC 4463, April 2006. [5] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006. Whitehead, et al. Expires August 25, 2008 [Page 7] Internet-Draft media playback control requirements February 2008 Authors' Addresses Steven Whitehead Verizon Laboratories Inc. 40 Sylvan Road Waltham, MA 02451 USA Email: steven.d.whitehead@verizon.com Marie-Jose Montpetit Motorola 900 Chelmsford Street Lowell, MA 01851 USA Email: mmontpetit@motorola.com Xavier Marjou France Telecom Rue Pierre Marzin Lannion, Brittany 22307 France Email: xavier.marjou@orange-ftgroup.com Sam Ganesan Motorola 80 Central Street Boxborough, MA 01719 US Email: sam.ganesan@motorola.com URI: Whitehead, et al. Expires August 25, 2008 [Page 8] Internet-Draft media playback control requirements 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). Whitehead, et al. Expires August 25, 2008 [Page 9]