Audio/Video Transport P. Yang Internet-Draft R. Even Intended status: Standards Track Huawei Technologies Co., Ltd. Expires: April 21, 2011 H. Moustafa France Telecom - Orange October 18, 2010 Switching from unicast to multicast for multicast short time-shift draft-yang-avt-switch-multicast-short-timeshift-00.txt Abstract When a client requests a time-shift service for a multicast session using RTP for media transport, like pause, instant replay, slow- motion video, frame-by-frame viewing, rewind, fast-forward, etc., it needs to switch from multicast session to unicast session. This unicast session will always serve for the time-shift service unless the client manually switches back to the multicast session. Actually a time- shift request may happens for all clients. That is, multicast session stream will be replaced by many unicast time-shift streams having significant impact on network bandwidth usage. In this document, we describe a method using existing RTP and RTCP protocol infrastructure that switches back to multicast session from unicast session of time-shift. In this method, a burst RTP flow which is a little faster than the primary multicast rate may be transmitted so that unicast session may catch up and switch back to multicast session. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 21, 2011. Copyright Notice Yang, et al. Expires April 21, 2011 [Page 1] Internet-Draft Switching for multicast short time-shift October 2010 Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. RTSP Time-shift and MST Reverse Switch . . . . . . . . . . 5 1.2. RAMS and MST Reverse Switch . . . . . . . . . . . . . . . 6 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Reverse switch for multicast short time-shift . . . . . . . . 7 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Yang, et al. Expires April 21, 2011 [Page 2] Internet-Draft Switching for multicast short time-shift October 2010 1. Introduction Interactive time-shift is an important service for media application. Through time-shift control operations (e.g. pause, instant replay, slow-motion video, frame-by-frame viewing, rewind and fast-forward), viewers can access recorded programming and live streams. The time- shift service is available for recorded media and real-time streaming. For the real-time streaming, time-shift service requires recording/caching of the information. The time-shifted information can be sent by the original media source or by a server in the network that caches the stream and provides the time-shift service. Note that time-shift service may run on the client side but this requires the client to be able to cache the stream and synchronization to the main multicast stream needs to be managed by the client and does not require any specific protocol. This document looks at time-shift services where the original content is delivered using multicast. In this use case the time-shift service is using a unicast stream from a Multicast Short Time-shift (MST) server to the client. The synchronization between the multicast and unicast stream can be achieved by the client if he is using control commands like fast forward or RTSP [ref] Scale request. The MST can notice that the client is receiving in the unicast stream the same information that is current in the multicast stream. Network traffic will rise with the increase in the number of clients using time-shift service, because the time-shift service traffic changes from a multicast stream (one multicast stream for all clients) to a large number of unicast streams (one unicast stream per client). Time- shift services like slow-motion view, instant replay, frame-by-frame viewing, pause and rewind may often occur for most of viewers in prime-time (e.g. when watching sports events). We can separate the time-shift services of primary live streams delivered over multicast/broadcast into multicast long time-shift and multicast short time-shift. Some of the manipulations requested by the viewers are multicast short time-shift (e.g. short pause, instant replay, slow-motion video and frame-by-frame viewing). For the multicast short time-shift, the time offset between the unicast time- shift playback, after the time-shift request, and the current time of the primary multicast stream is small enabling the unicast stream to catch up with primary multicast stream by speeding up the playback, and then switch back to the original multicast session. In this document, we propose a solution for enabling the time-shifted stream receivers to catch up with the original multicast stream using the tools offered by the existing RTP and RTCP protocols. The Yang, et al. Expires April 21, 2011 [Page 3] Internet-Draft Switching for multicast short time-shift October 2010 document also describes how to switch back to the primary multicast session from the unicast session initiated by either the client or the server. Using this solution allows the network bandwidth to be effectively saved for the time-shift service of multicast application. In the scenario that we consider in this draft, an intermediary network element (that we refer to as Multicast Short Time-shift server) joins the multicast session and continuously caches the multicast stream. When an RTP receiver sends a time-shift request, the MST server starts a new unicast RTP session and transmits the unicast stream to the RTP receiver over that session. A simplified network diagram showing this scenario employing an intermediary network element is shown in Figure 1, where the hashed lines show the unicast stream. +--------------------------------+ | Intermediary Network Element | | | | MST Server | +--------------------------------+ ^ : | : | : | v +-----------+ +-------------+ +-------------+ | Multicast | | |---------->| Time-shift | | |------->| Router | | RTP | | Source | | |..........>| Receiver | +-----------+ +-------------+ +-------------+ | | +-------------+ | | Existing | +---------------->| RTP | | Receiver | +-------------+ Figure 1: Reverse switch for multicast short time-shift through an intermediary network element The proposed solution is not dependent on a specific streaming control protocol like RTSP [ref]. It addresses the synchronization between a primary multicast RTP stream and a parallel time-shifted unicast RTP stream. A principle design goal is to use an existing protocol to define this solution. This improves the versatility of the existing implementations, and promotes faster deployment and better interoperability. To this effect, the proposal is to use the switching of flows from unicast stream to multicast stream described in RAMS [draft-ietf-avt-rapid-acquisition-for-rtp], and use the capabilities of RTCP to handle the signaling needed to accomplish Yang, et al. Expires April 21, 2011 [Page 4] Internet-Draft Switching for multicast short time-shift October 2010 this automatic reverse switch for multicast short time-shift. 1.1. RTSP Time-shift and MST Reverse Switch RTSP 2.0[draft-ietf-mmusic-rfc2326bis] is an application-level protocol for setup and control of the media delivery with real-time properties, and provides an extensible framework to enable controlled, on-demand delivery of real-time data, typically streaming media. RTSP defines any necessary media transport signalling with regards to RTP. In appendix C.1 it defines the interaction of RTSP with respect to the RTP protocol [RFC3550]. Yet RTSP is not limited to RTP media delivery control but any delivery type of data. It provides a general media delivery control mechanism to play out the media, pause media, or stop media over different delivery channels, such as UDP, multicast UDP, TCP, RTP over UDP, etc. RTSP can also provide interactive time-shift function with different scale and speed. Section 13.4.8 in [draft-ietf-mmusic-rfc2326bis] has a scenario for Playing Live with time-shift where a certain media server may offer time-shift services to their clients. The usage of this play method can implement time- shift for Live Media or On- demand Media. Section 16.44 in [draft-ietf-mmusic-rfc2326bis] addresses the scaling for video and audio, it suggests sending only key frames for video but this may not achieve the right scale speed since it depends on the locality of such frames in the stream. It also requires analysis of the media payload for all supported codecs to find the key frames. In this document we call the interactive time-shift function in [draft-ietf-mmusic-rfc2326bis] as "RTSP Time- shift". For Live Media using RTP multicast over UDP, RTSP Time-shift can provide an initial switch from multicast session to unicast session when time-shift happens, but it cannot complete the reverse switch from unicast session of time-shift to the original multicast session. An MST server can for example transmit the unicast stream of the time-shift by a short burst stream and indicate to the receivers to speed up the playback through Non-perceptual Speedup Playback. After the burst of the unicast stream of time-shift catches up with the primary multicast stream, the client can switch back to the primary multicast stream so that the network bandwidth can be effectively saved. The synchronization due to catch up with the primary multicast session may also happen due to the client operation like the fast forward. Yang, et al. Expires April 21, 2011 [Page 5] Internet-Draft Switching for multicast short time-shift October 2010 1.2. RAMS and MST Reverse Switch RAMS [draft-ietf-avt-rapid-acquisition-for-rtp] describes a method using the existing RTP and RTCP protocol for reducing the acquisition delay, allowing fast channel switch. RAMS defines the reverse switch from unicast burst session to the primary multicast session. 2. Conventions 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 [RFC2119]. 3. Definitions This document uses the following acronyms and definitions frequently: Time-shift Control: Refers to the manipulation control of time-shift service (e.g. pause, slow-motion video, frame-by-frame viewing, rewind, fast- forward, etc.), not include the play method. Time-shift Playback: Refers to the normal playback with a natural playback rate after the time-shift control. Multicast Time-shift Interval: Refers to the time interval or the number of packets between the primary multicast stream and the normal playback during the unicast session after the time-shift control. In other words, it presents the time interval between the start point frame of the unicast session and the frame of the current location of the primary multicast session. Multicast Short Time-shift: The case when the multicast Time-shift Interval is short, such as 30 seconds. The normal playback during the unicast session after the time-shift control means that viewers finish the time-shift control (e.g. pause, rewind and fast- forward)and start to receive the unicast stream and play back again at the speed of the Primary multicast stream. Primary multicast stream: The multicast stream before time-shift request. Instant Replay: It is the case of the replaying of video footage of an event or incident directly after its occurrence. In television broadcasting of sports events, instant replay is often used during live broadcast, to show a passage of play which was important or remarkable, or which was unclear on the first sight. Yang, et al. Expires April 21, 2011 [Page 6] Internet-Draft Switching for multicast short time-shift October 2010 Slow-motion Video: The case when the playback of a video clip appears to be slower than the natural speed of the events. Non-perceptual Speedup Playback: During the speedup playback, after each interval of some frames, one frame is skipped as if it was not present, the next frame is directly rendered to take the place of the skipped frame, while keeping a fixed Frame Per Second (FPS)during the playback speedup. 4. Reverse switch for multicast short time-shift This section gives an overview on the proposed method for reverse multicast time- shift switch from unicast time-shift RTP Sessions. 4.1. Overview RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback [RFC5760] specifies an extension to the RTCP to use unicast feedback to a multicast sender. The (Unicast RTCP) Feedback Target is a logical function to which RTCP unicast feedback traffic is addressed. The functions of the Feedback Target and the Distribution Source MAY be co-located or integrated in the same entity. In this case, The (Unicast RTCP) Feedback Target MAY be co-located or integrated in the Multicast Time-shift Server. This section presents a proposed method to switch back to the multicast session from the unicast session of time-shift considering multicast short time-shift. The proposed method allows the network bandwidth to be effectively saved when an RTP receiver finishes its time-shift request and starts its time- shift playback by unicast stream. A Multicast Short Time-shift Server (MST) and new RTCP feedback messages are also introduced for the proposed method. The MST server has a cache where the most recent packets from the primary multicast stream are continuously stored for some time. When a viewer wants to normally playback the unicast stream after time- shift request, the RTP receiver needs to send a playback request to the feedback target, and then receives the unicast stream from the MST server. In order to switch back to the original multicast stream, the MST server needs to transmit a burst unicast stream to RTP receivers. Using an accelerated bitrate (as compared to the bitrate of the original multicast stream). This means that at a certain point in time, the unicast burst will catch up with the original multicast stream. At this point, the RTP receiver no longer needs to receive the unicast burst and can switch back to the original multicast session. Yang, et al. Expires April 21, 2011 [Page 7] Internet-Draft Switching for multicast short time-shift October 2010 The transmission of the unicast burst stream of time-shift playback depends on the time-shift buffer size of RTP receivers and the Multicast Short Time-shift Interval. In the case when the time-shift buffer size of an RTP receiver can inadequately accommodate the number of packets of the Multicast Short Time-shift Interval, the receiver needs to playback for the duration of the speeding-up until the remaining number of packets does not overflow at the time-shift buffer. During the playback of the speeding-up, the receiver may speed up video playback by the non-perceptual speedup playback so that viewers could never perceived the existence of the speeding-up. Refer to [I-D.yang-avt-rtp-synced-playback] 4.2. Message Flows This section introduces the different messages for the proposed method and the related messages flows. - MST(Multicast Short Time-shift) synchronization transmission(MSTST): This is the generic form of the different messages that will be transmitted during the proposed method in this draft for reverse switch multicast short time-shift. -Time-Shift-Control-Commands: This message presents the request for the Time-Shift service (e.g. fast forward, pause, reverse, ..etc.). This message may be addressed by the MST server or other time-shift server. - MSTST Playback Request(MSTST-PReq): It's the message sent from the RTP receiver to the MST to request the playback after the time-shift request. - MSTST Playback Response(MSTST-PRes): It's the response message sent from the MST to the RTP receiver to confirm the playback process initiation. Following this message, the RTP receiver will receive the unicast burst RTP stream from the MST. - MSTST Synchronization Indication(MSTST-SInd): When the unicast burst catch up with the original multicast stream, this message is sent from the MST to the RTP receiver to indicate this fact. - MSTST Synchronization Response(MSTST-SRes): This message is sent by the RTP receiver as a response to the MST confirming the need to switch back to the original multicast session. Following this message the RTP receiver is able to receive the multicast stream. - MSTST Termination Request(MSTST-TReq): This message is sent by the RTP receiver to the MST to terminate the process of the time-shift. Yang, et al. Expires April 21, 2011 [Page 8] Internet-Draft Switching for multicast short time-shift October 2010 - MSTST Termination Response(MSTST-TRes): This message is a reply sent by the MST to the RTP to confirm to the MSTST-TReq. ------------------------- | MST Server | ----------- | ------ ------------ | -------- ------------ | Multicast | | | FT | | Burst/Ret. | | | | | RTP | | Source | | | | | Source | | | Router | | Receiver | | | | ------ ------------ | | | | (RTP_Rx) | ----------- | | -------- ------------ | ------------------------- | | | | | | |--- RTP Multicast->-------------------->| | | | | | | ................................................ | . . | . <::Time-shift control commands ::> . | . ..Time-shift media stream ..> . | ................................................ | | | | | |<''''''''' RTCP MSTST-PReq''''''''| | |'''''''''' RTCP MSTST-PRes'''''''>| | | | | | | | | | |....... Unicast RTP Burst .......>| | | | | | | | | | |'''''''''' RTCP MSTST-SInd'''''''>| | |<''''''''' RTCP MSTST-SRes''''''''| | | | | | | | | | | |<~SFGMP Join~| | | | | | | | | |------------------ RTP Multicast -------------------->| | | | | | | | | | |<''''''''' RTCP MSTST-TReq''''''''| | |'''''''''' RTCP MSTST-TRes ''''''>| | | | | | | | | | |<''''''''' (RTCP BYE) ''''''''''''| | | | | Yang, et al. Expires April 21, 2011 [Page 9] Internet-Draft Switching for multicast short time-shift October 2010 5. Security Considerations TBD. 6. IANA Considerations TBD. 7. Acknowledgements TBD. 8. 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-24 (work in progress), July 2010. [I-D.yang-avt-rtp-synced-playback] Yang, P. and Y. Wang, "Synchronized Playback in Rapid Acquisition of Multicast Sessions", draft-yang-avt-rtp-synced-playback-04 (work in progress), March 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. Authors' Addresses Peilin Yang Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District, Nanjing 210012 P.R.China Phone: +86-25-56622638 Email: yangpeilin@huawei.com Yang, et al. Expires April 21, 2011 [Page 10] Internet-Draft Switching for multicast short time-shift October 2010 Roni Even Huawei Technologies Co., Ltd. 14 David Hamelech, Tel Aviv 64953 Israel Email: even.roni@huawei.com Hassnaa Moustafa France Telecom - Orange 38-40 rue du General Leclerc Issy Les Moulineaux, 92794 Cedex 9 France Email: hassnaa.moustafa@orange-ftgroup.com Tina Tsou (editor) Huawei Technologies Section F, Huawei Industrial Base Bantian Longgang, Shenzhen 518129 P.R. China Phone: +86 755 28972912 Email: tena@huawei.com Gu Yingjie Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District, Nanjing 210012 P.R.China Email: guyingjie@huawei.com Yang, et al. Expires April 21, 2011 [Page 11]