Network Working Group T. Lohmar Internet-Draft T. Einarsson Expires: December 21, 2006 M. Westerlund I. Johansson Ericsson June 19, 2006 Controlling FLUTE sessions with Real-Time Streaming Protocol (RTSP) draft-lohmar-mmusic-rtsp-flute-00 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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract File Delivery over Unidirectional Transport (FLUTE) is defined in RFC 3926 and provide an extensible framework for delivering any type of files over UDP. FLUTE is mostly intended for IP multicast comminication, but the use with IP unicast is not excluded. Real- time Streaming Protocol (RTSP) allow the play-out of media packets to multicast and unicast sessions. Lohmar, et al. Expires December 21, 2006 [Page 1] Internet-Draft Controlling FLUTE sessions with RTSP June 2006 Requirements Language 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. On-demand Playback using Multicast . . . . . . . . . . . . 3 2.2. Unicast distribution of Live and Stored content . . . . . 4 3. RTSP extensions . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. General Procedure Description . . . . . . . . . . . . . . 4 3.2. FLUTE specific SDP extensions . . . . . . . . . . . . . . 4 3.3. RTSP Method Handling . . . . . . . . . . . . . . . . . . . 4 3.3.1. Session Set-up . . . . . . . . . . . . . . . . . . . . 4 3.3.2. RTSP PLAY method . . . . . . . . . . . . . . . . . . . 5 3.3.3. RTSP PAUSE method . . . . . . . . . . . . . . . . . . 5 3.3.4. RTSP Teardown method . . . . . . . . . . . . . . . . . 5 4. Flute Data Considerations . . . . . . . . . . . . . . . . . . 5 4.1. Congestion Control . . . . . . . . . . . . . . . . . . . . 5 4.2. Adaption of FLUTE data flow . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Lohmar, et al. Expires December 21, 2006 [Page 2] Internet-Draft Controlling FLUTE sessions with RTSP June 2006 1. Introduction File Delivery over Unidirectional Transport (FLUTE) is defined in RFC 3926 [RFC3926] and provide an extensible framework for delivering any type of files over UDP. FLUTE is primarily intended for multicast communication, but not restricted to it. 3GPP Multimedia Broadcast and Multicast Service (MBMS) [3GPP.26.346], and Open Mobile Allicance (OMA) BAC BCAST specifications [OMA-BCAST]) supports the usage of FLUTE sessions in combination with RTP sessions. On important use- case of FLUTE transmissions simultaneously to RTP transmissions are voting and general interactivity services for Mobile TV applications. OMA BAC BCAST defines so-called InteractivityMedia documents, which may be transmitted simultaneously with RTP sessions using FLUTE. OMA BAC BCAST [OMA-BCAST] also allows the usage of FLUTE on unicast IP sessions. To efficiently use RTSP for OMA BAC BCAST enabled multicast server control, a FLUTE session establishment needs to be added in RTSP. RTSP already allows to control the playback of content into a multicast group. Therefore, it is natural to extend RTSP to control also FLUTE sessions. This internet-draft proposes the definition of a FLUTE session establishment and control with RTSP. A FLUTE enabled streaming server can be then controlled using the RTSP protocol to playback a predefined session onto a multicast address. Note, that MPEG is currently defining FLUTE hint-tracks for the ISO file format. This will simplify even the playback of strored sessions. This internet draft also defines the FLUTE session establishment for unicast communication. A client can use RTSP to establish a FLUTE unicast session between itself and the server. 2. Use Cases This section describes three use cases for FLUTE play-out control by RTSP. The use-cases here are alined to the use-cases described in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 2.1. On-demand Playback using Multicast It is possible to use RTSP to request that media is delivered to a multicast group. FLUTE may be used together with a multicast session, since it was primarily designed for File-delivery over multicast IP session. The content may be pre-recorded or generated on the fly (live). Lohmar, et al. Expires December 21, 2006 [Page 3] Internet-Draft Controlling FLUTE sessions with RTSP June 2006 2.2. Unicast distribution of Live and Stored content FLUTE is primarily designed for multicast transmissions. However, the use on unicast is not restricted by FLUTE. A live server may offer a session via multicast and also via unicast distribution. In such a case, the same UDP payload may be transmitted towards the multicast session and the unicast on-demand sessions. The streaming server however needs to be configured with the destination address and port. In the unicast case the streaming server will need to adjust the IP and UDP headers of the flute packets for the distribution method. 3. RTSP extensions This section first describe the general procedures of the FLUTE session configuration and then the necessary RTSP Method handling. 3.1. General Procedure Description FLUTE [RFC3926] is a unidirectional file delivery protocol. A file is partitioned into smaller chunks, which fit into UDP packets of predefined size. The file properties, such as the file name, MIME type, etc are described in the FLUTE File Delivery Table (FDT). The FDT is send in-band in the FLUTE session and is identified by a well- defined value in the FLUTE packet header (i.e. Transport Object Identifier is set to zero). A FLUTE session may uilize several UDP ports simultaneously. If more than one UDP port is required, this is indicated in the "flute-ch" attribute in the SDP. 3.2. FLUTE specific SDP extensions he FLUTE specific SDP extensions are defined in [I-D.mehta-rmt-flute- sdp]. For the FLUTE session establishment using RTSP, a control URI as defined in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] SHALL be present for the FLUTE media description. The control URI is used within the RTSP SETUP method to establish the described FLUTE sessions. 3.3. RTSP Method Handling 3.3.1. Session Set-up A control URI as defined in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] SHALL be present for each FLUTE media description in the SDP. The control URI is used within the RTSP SETUP method to establish the described FLUTE sessions. If the "flute-ch" attribute is present for the FLUTE session, an Lohmar, et al. Expires December 21, 2006 [Page 4] Internet-Draft Controlling FLUTE sessions with RTSP June 2006 according number of FLUTE sessions is established. The syntax for transport protocol specifiers in RTSP 2.0 transport header is defined as one or more tokens separated by a "/" (See ABNF in section 19.2.3 of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. The RTSP transport protocol specifier for FLUTE SHALL be "FLUTE/UDP". One and only one UDP port is allocated for each FLUTE channel. 3.3.2. RTSP PLAY method The PLAY method tells the server to start sending data including FLUTE session data as defined in [I-D.ietf-mmusic-rfc2326bis]. For "Live" session, the RTSP server forwards the FLUTE packets as they are received. For stored sessions, it is expected that transmission timing information for the FLUTE packets are stored with the FLUTE session. 3.3.3. RTSP PAUSE method The PAUSE request causes the stream delivery includeing all FLUTE sessions to be interrupted (halted) as defined in [I-D.ietf-mmusic- rfc2326bis]. 3.3.4. RTSP Teardown method The TEARDOWN client to server request stops the stream delivery including all FLUTE data delivery for the given URI, freeing the resources associated with it. Details for the TEARDOWN method are defined in [I-D.ietf-mmusic-rfc2326bis]. 4. Flute Data Considerations There are a few considerations need when implementing the support for controlling FLUTE sessions. 4.1. Congestion Control When using this extension to deliver FLUTE packets over best-effort networks there is a need to monitor the congestion state of the path so that this transmission does not cause severe congestion or are significantly unfair against other flows. The method for accomplishing this is for future study. Lohmar, et al. Expires December 21, 2006 [Page 5] Internet-Draft Controlling FLUTE sessions with RTSP June 2006 4.2. Adaption of FLUTE data flow The FLUTE data flow may contain FEC data. In these case the streaming server MAY adapt the flow to the known error properties of the path between the server and the client. However the feasability of this is dependent on the FEC code in use. 5. IANA Considerations The transport header protocol specifier: "FLUTE/UDP" will be registed with the IANA. The registration will follow the rules defined in section 21.5 of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 6. Security Considerations See [I-D.ietf-mmusic-rfc2326bis] for security considerations related to the Real-Time Streaming Protocol. There are some confidentiality and integrity issues with FLUTE sessions. Please also see the security considerations in [I-D.ietf- rmt-flute-revised]and in [I-D.mehta-rmt-flute-sdp]. There might be a need to confidentiality protect the file in a FLUTE session. It is possible to use SMIME within FLUTE sessions. There is currently no approch to confidentiality and/or integrity protect the FLUTE FDT. Malicious FLUTE FDT packets might detern a FLUTE client from receiving files. 7. Acknowledgements The authors would like to thank all the people who gave feedback on this document. 8. References 8.1. Normative References [I-D.ietf-mmusic-rfc2326bis] Schulzrinne, H., "Real Time Streaming Protocol 2.0 (RTSP)", draft-ietf-mmusic-rfc2326bis-12 (work in progress), March 2006. [I-D.ietf-rmt-flute-revised] Lohmar, et al. Expires December 21, 2006 [Page 6] Internet-Draft Controlling FLUTE sessions with RTSP June 2006 Paila, T., "FLUTE - File Delivery over Unidirectional Transport", draft-ietf-rmt-flute-revised-01 (work in progress), January 2006. [I-D.mehta-rmt-flute-sdp] Mehta, H., "SDP Descriptors for FLUTE", draft-mehta-rmt-flute-sdp-05 (work in progress), January 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004. 8.2. Informative References [3GPP.26.346] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346 6.4.0, March 2006. [OMA-BCAST] Open Mobile Alliance BAC BCAST, "Mobile Broadcast Services, OMA-TS-BCAST_Services-V1_0", OMA TS OMA-TS- BCAST_Services-V1_0, April 2006. Lohmar, et al. Expires December 21, 2006 [Page 7] Internet-Draft Controlling FLUTE sessions with RTSP June 2006 Authors' Addresses Thorsten Lohmar Ericsson Ericsson Allee 1 Herzogenrath, D-52134 Germany Phone: +49-2407-5757816 Fax: Email: thorsten.lohmar@ericsson.com URI: Torbjoern Einarsson Ericsson Torshamnsgatan 23 Stockholm, SE-16480 Sweden Phone: +46-8-7190000 Fax: Email: torbjorn.einarsson@ericsson.com URI: Magnus Westerlund Ericsson Torshamnsgatan 23 Stockholm, SE-16480 Sweden Phone: +46-8-7190000 Fax: Email: magnus.westerlund@ericsson.com URI: Lohmar, et al. Expires December 21, 2006 [Page 8] Internet-Draft Controlling FLUTE sessions with RTSP June 2006 Ingemar Johansson Ericsson Laboratoriegrand 11 Lulea, SE-976 32 SWEDEN Phone: +46 8 7190000 Fax: Email: ingemar.s.johansson@ericsson.com URI: Lohmar, et al. Expires December 21, 2006 [Page 9] Internet-Draft Controlling FLUTE sessions with RTSP June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lohmar, et al. Expires December 21, 2006 [Page 10]