Network Working Group T. Einarsson Internet-Draft M. Westerlund Expires: December 21, 2006 T. Lohmar I. Johansson Ericsson June 19, 2006 Multiple aggregated control URIs for RTSP draft-einarsson-mmusic-rtsp-macuri-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 By introducing multiple aggregated control URIs to be used with PLAY requests inside one single RTSP session, it is possible to switch content channel with minimal delay. This is important for accessing content channels via unicast networks while keeping the content streams the same as for multicast/broadcast network. An important use case is hybrid unicast and broadcast distribution of live media, Einarsson, et al. Expires December 21, 2006 [Page 1] Internet-Draft Multi-aggregated URIs for RTSP June 2006 e.g. mobile TV. The possible control URIs can be specified using a new SDP control attribute altcontrol either explicitly or in a dynamic out-of-band way. 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use cases and requirements . . . . . . . . . . . . . . . . . . 4 3.1. Content switch in unicast only network . . . . . . . . . . 4 3.2. Unicast and Broadcast clients . . . . . . . . . . . . . . 4 3.3. Hybrid unicast-broadcast scenario . . . . . . . . . . . . 5 4. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Design choices . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Channel selection signalling . . . . . . . . . . . . . . . 6 4.3. SDP syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Einarsson, et al. Expires December 21, 2006 [Page 2] Internet-Draft Multi-aggregated URIs for RTSP June 2006 1. Definitions 1.1. Glossary 3GP - 3GPP file format 3GPP - Third Generation Partnership Project AC URI - Aggregated Control URI BC - Broadcast DVB-H - Digital Video Broadcasting Handheld FE - Front End IGMP - Internet Group Management Protocol MC - Multicast MBMS - Multimedia Broadcast/Multicast Service PSS - Packet-switched Streaming Service RTSP - Real Time Streaming Protocol SDP - Session Description Protocol UC - Unicast 2. Introduction Television services over IP networks are getting more and more popular, both in fixed and cellular networks. In cellular networks, the first TV services are using unicast radio bearers as e.g. the 3GPP standard PSS[pss] which is essentially RTSP streaming with RTP media transport. One way of achieving a unicast TV service with multiple TV channels is to set up a new RTSP session to start to receive a new TV channel. Another is to control a server node in the network to switch content channel inside one RTSP session by switching content source and change the media packets to achieve continuous RTP streams. However, there are also much efforts on providing broadcasted TV over IP to mobile devices. Two of the main standardization efforts are MBMS in 3GPP [mbms] and DVB-H [dvb-h]. MBMS uses the cellular network in a special broadcasting mode. In doing so, a number of TV channels can be broadcasted, but given the relatively small sizes of the cells, it is only economically feasible to broadcast the most popular programs that have many viewers, while less popular programs are better delivered using unicast transport. DVB-H, on the other hand is a pure broadcast network, but even here it might be necessary to compliment with unicast delivery of less common channels or in cases where the broadcast coverage is not sufficient. In the 3GPP Release 7 work on MBMS, one has started to look into how to combine PSS over unicast with MBMS over broadcast bearers. The purpose of this document is to suggest some changes to RTSP which Einarsson, et al. Expires December 21, 2006 [Page 3] Internet-Draft Multi-aggregated URIs for RTSP June 2006 makes it more easy to make a combined unicast and broadcast TV service. 3. Use cases and requirements In this section we give a number of use cases and list the requirements they lead to. 3.1. Content switch in unicast only network In this use case, a unicast client has access to a number of content channels, and wants to be able to switch between the channels in as short time as possible. In the back end, some of the channels are provided from multicast sources and some from unicast sources. ----------- ----------- ------- | Unicast |<----- RTSP ---->| RTSP | |<------ RTP UC --| Ch1 | | Client |<-\ | FE | | ------- ----------- \ |------| |<---\ ------- \- RTP UC----| Switch |<-\ \- RTP MC --| Ch2 | ----------- \ ------- \ ------- \- RTP MC --| Ch3 | ------ Unicast client with 3 channels available. In the back end, channels 2 and 3 are sent via Multicast (MC) while channel 1 is a Unicast (UC) flow. RTSP is used to control the RTP Unicast sessions between the client and the server (switch). For cellular networks with rather long round-trip delays, two requirements that arise from this use case are: R1) Short channel switching time in terms of signalling round trips. R2) Obtain synchronization information for audio and video as early as possible after a channel switch. 3.2. Unicast and Broadcast clients As a first step of introducing broadcast distribution of content channels, the broadcast and unicast clients are separated. This was the case in Release 6 of MBMS. The unicast client has only access to unicast traffic due to e.g. roaming in another operator's network. Einarsson, et al. Expires December 21, 2006 [Page 4] Internet-Draft Multi-aggregated URIs for RTSP June 2006 ----------- ----------- | Unicast |<----- RTSP ---->| RTSP | | | Client |<-\ | FE | | ----------- \ |------| |<---\ ------- \- RTP UC----| Switch |<-\ \- RTP MC --| Ch1 | ------------- ----------- \ / ------- | Broadcast |<----------------------------/\ ------- | Client |<------------------------------\- RTP MC --| Ch2 | ------------- ------- Here we have one broadcast client and one unicast client which can both view the same channels. For the Unicast (UC) case, RTSP is used to control the streams, while the broadcast client tunes in to different broadcast channels with different IP MC streams. This use case leads to no extra requirement since the broadcast and unicast clients are separated. 3.3. Hybrid unicast-broadcast scenario In this case, the most popular channel (Ch3) is only available via broadcast, the least popular channel (Ch1) is only available via unicast and the mid popular channel (Ch2) is available over broad or unicast depending on the number of viewers, or the popularity of the program that is currently sent. ----------- ----------- ------- | Hybrid |<----- RTSP ---->| RTSP | |<------ RTP UC --| Ch1 | | |<-\ | FE | | ------- | UC / BC | \ |------| | ------- | | \- RTP UC----| Switch |<----?- RTP MC --| Ch2 | | Client | ----------- / ------- | |<------------------------------/ ------- | |<--------------------------------- RTP MC --| Ch3 | ----------- ------- A more optimized case where the distribution channels are different depending on the viewing patterns. The least popular channel (Ch1) is only available via UC, the mid popular Ch2 is sometimes available via UC and sometimes via BC, and the most popular Ch3 is only available via BC. Channels 1 and 3 imply no extra requirements, but Ch2 with its dynamic distribution mode poses the following requirements: R3) Possibility of seamless transition between between broadcast and unicast. R4) Possibility of using the same media (RTP) encryption scheme for both broadcast and unicast. Einarsson, et al. Expires December 21, 2006 [Page 5] Internet-Draft Multi-aggregated URIs for RTSP June 2006 4. Proposed solution A reasonable setting for the use cases above, is that the media encoding and transport settings, as defined by e.g. media sections in an SDP file, are homogeneous for all the channels, or at least have a number of statically configured settings corresponding to different RTP PTYPE values. Assuming this, the media settings for all the channels can be made available before or at the start of the RTSP session. 4.1. Design choices The requirements above lead to the following design choices for controlling the UC sessions: D1) Avoid full RTSP setup to minimize the signalling round trips (R1). D2) Do not use use a packet-modifiying switch (R3 and R4). D3) Try to use the RTSP PLAY request since its response includes synchronization information via rtptime in the RTP-Info header (R2), and we need new synchronization information since we cannot modify the RTP header information according to D2. 4.2. Channel selection signalling The proposed design is to use RTSP PLAY requests inside an RTSP session to request a new TV channel (content source) via the RTSP front end in the switch. RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] section 11.4, it is stated that a new PLAY request shall replace another, which fits nicely with our needs. The switch then starts sending the RTP streams for the new content channel and provides synchronization information including new SSRC values in the RTSP PLAY response to the client. The possibility to send SSRC in the RTP-Info header is another new feature of RTSP 2.0. To distinguish different channels, one can either introduce a new header or use different aggregated control URIs for each channel. Among these two, we propose to use multiple aggregated control URIs (AC URIs) since URIs have a well-defined syntax and it is easy to extend SDP or other session descriptions to include multiple URIs. If an RTSP resource has the media control URIs: rtsp://example.com/videoTrack and rtsp://example.com/audioTrack, and the two AC URIs rtsp://example.com/channel1 and rtsp://example.com/channel2, then a session might look like: C->S: SETUP rtsp://example.com/videoTrack RTSP/2.0 Einarsson, et al. Expires December 21, 2006 [Page 6] Internet-Draft Multi-aggregated URIs for RTSP June 2006 C->S: SETUP rtsp://example.com/audioTrack RTSP/2.0 C->S: PLAY rtsp://example.com/channel1 RTSP/2.0 followed by C:->S: PLAY rtsp://example.com/channel2 RTSP/2.0 at a later point in time to change channel. When switching to a broadcasted channel, the RTSP session may be paused by using any AC URI C-> S: PAUSE rtsp://example.com/channel2 RTSP/2.0 Going back to receiving any unicast channel is then quickly accomplished by sending C->S: PLAY rtsp://example.com/channel1 RTSP/2.0 A seamless transition between unicast and broadcast reception of the same channel can be achieved by receiving both streams during a short period to avoid missing packets, and then continue listening to the new distribution channel, while closing down the old. To be backwards compatible with clients not supporting multiple AC URIs, a default AC URI SHALL be available and otherwise the session description should be fully understandable for receiving the default content. As usual, sessions with multiple aggregated control URIs should only be offered from servers supporting this extension. However, to prevent misconfigured systems from working, a new feature tag "multiple-control-uris" is defined and MUST be used. If the server responds 551 (Option Not Supported), the client MUST fallback to use the default AC URI. 4.3. SDP syntax An ordinary SDP [I-D.ietf-mmusic-sdp-new] description for an RTSP resource contains one AC URI, e.g. defaulturi, specified in the session part of SDP as: a=control: To ensure backwards compatible with non-extended clients, we propose to keep this unique control line, but add a new attribute "altcontrol", which can occur multiple times. The content channel that is associated with a specific alternative control URI is specified by other means, such as the User Service Description in Einarsson, et al. Expires December 21, 2006 [Page 7] Internet-Draft Multi-aggregated URIs for RTSP June 2006 MBMS[mbms]. In many cases, like time-limited TV channels, it is too restrictive to have a list of fixed AC URIs specified in an SDP file. Therefore, a mechanism that can tell that the possible control URIs are available by other means and can be dynamic is needed. To handle that case, an indicator value "dynamic" SHALL be used to signal that the possible altcontrol values are found by other means and may be dynamic. The ABNF [RFC4234] for this new SDP attribute is the following: altcontrol-line = "a=altcontrol:" control-type [sp rtsp-URI] control-type = "list" / "dynamic" / token rtsp-URI = The attributes on the session level in SDP may therefore look either as a=control:defaultchannel a=altcontrol:list channel1 a=altcontrol:list channel2 a=altcontrol:list channel3 or a=control:defaultchannel a=altcontrol:dynamic 5. IANA Considerations The SDP attribute "altcontrol" with its special value "dynamic" as well as the feature tag "multiple-control-uris" need to be registered with IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations Same as for RTSP [I-D.ietf-mmusic-rfc2326bis]. 7. Acknowledgements Einarsson, et al. Expires December 21, 2006 [Page 8] Internet-Draft Multi-aggregated URIs for RTSP June 2006 8. 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-mmusic-sdp-new] Handley, M., "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [dvb-h] DVB, "DVB-Handheld", 2006. [mbms] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346 6.4.0, 2006. [pss] 3GPP, "Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and Codecs", 3GPP TS 26.234 6.7.0, 2006. Einarsson, et al. Expires December 21, 2006 [Page 9] Internet-Draft Multi-aggregated URIs for RTSP June 2006 Authors' Addresses Torbjorn Einarsson Ericsson Torshamnsgatan 23 Stockholm, SE-16480 Sweden Phone: +46-8-7190000 Email: torbjorn.einarsson@ericsson.com Magnus Westerlund Ericsson Torshamnsgatan 23 Stockholm, SE-16480 Sweden Phone: +46-8-7190000 Email: magnus.westerlund@ericsson.com Thorsten Lohmar Ericsson Ericsson Allee 1 Herzogenrath, D-52134 Germany Phone: +49-2407-5757816 Email: thorsten.lohmar@ericsson.com Ingemar Johansson Ericsson Laboratoriegrand 11 Lulea, SE-97128 Sweden Phone: +46-8-7190000 Email: ingemar.s.johansson@ericsson.com Einarsson, et al. Expires December 21, 2006 [Page 10] Internet-Draft Multi-aggregated URIs for 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. Einarsson, et al. Expires December 21, 2006 [Page 11]