Audio/Video Transport P. Yang Internet-Draft Huawei Technologies Co., Ltd. Intended status: Standards Track B. Lei Expires: September 9, 2009 China Telecom Z. Zou Huawei Technologies Co., Ltd. March 8, 2009 Extensions to RTCP for Rapid Synchronization draft-peilin-avt-rtp-burst-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 September 9, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Yang, et al. Expires September 9, 2009 [Page 1] Internet-Draft Extension for Rapid Synch March 2009 Abstract This document specifies an extension to "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) " [RFC4585] to reduce multicast session synchronization time and improve the user experience when a video receiver joins a multicast stream. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rapid Synchronization Mechanism Description . . . . . . . . . 3 3. Rapid Synchronization Mechanism Flow . . . . . . . . . . . . . 6 4. The format of new extended RTCP Transport Layer Feedback Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. RTCP Rapid Synchronization Request(RSR) . . . . . . . . . 7 4.2. RTCP Rapid Synchronization Indication(RSI) . . . . . . . . 8 4.3. RTCP Synchronization Rate Adaptation(SRA) . . . . . . . . 10 4.4. RTCP Synchronization Completed Notification(SCN) . . . . . 10 4.5. RTCP Synchronization Completed Response(SCR) . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Yang, et al. Expires September 9, 2009 [Page 2] Internet-Draft Extension for Rapid Synch March 2009 1. Introduction Both "Extensions to RTCP Feedback Mechanism for Burst Streaming" [I-D.levin-avt-rtcp-burst] and "Unicast-Based Rapid Synchronization with RTP Multicast Sessions" [I-D.versteeg-avt-rapid-synchronization-for-rtp] introduce some reasons, such as the key information to appear in the stream, for a synchronization delay while joining a multicast group to receive video multicast streaming in a random point in time. These reasons are main factors affecting the experience of multicast session synchronization. It is clear that the IETF needs to define a method to solve these reasons and improve multicast session synchronization which can be used to extend the existing RTP and RTCP mechanisms. This document proposes extensions for rapid synchronization multicast session based on RTP control protocol(RTCP) to improve the experience of multicast session and reduce synchronization time when a receiver wishes to join another multicast session. 1.1. Terminology 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]. 2. Rapid Synchronization Mechanism Description The real-time transport protocol (RTP) [RFC3550] provides video delivery services with real-time characteristics, such as video broadcasts in which receivers can frequently switch among different multicast sessions. In order to achieve rapid synchronization and reduce the synchronization delay between multicast sessions, a cached Retransmission Server (RS) is employed to send an accelerated unicast streaming to the requesting Receiver and temporarily replace the multicast session. The set of new extended RTCP Transport Layer Feedback Messages defined in this document is designed to support rapid synchronization mechanism as described below: 1) Receiver sends a rapid synchronization request for the new channel and at the same time to request to cease all the data streams of the current unicast channel if it is being used. This request is sent in an extended RTCP Transport Layer Feedback Message "RTCP Rapid Synchronization Request (RSR)", which is defined in the Section 4.1. The extended RTCP message includes the SSRC of the media source of Yang, et al. Expires September 9, 2009 [Page 3] Internet-Draft Extension for Rapid Synch March 2009 the current channel that should stop and the SSRC of media source of the new channel. The receiver indicates that it needs to receive media streaming with the key information "as soon as possible" using the default Bitrate on the first RSR request by sending the new extended RTCP RSR Message to the Retransmission Server. Later, an adaptive Bitrate will be used for the following RTCP RSR Message requests. The Adaptive Bitrate will be adjusted based on receiver's feedback of network transportation situation. Note that since no RTP packets have been received yet for this session, the SSRC should be obtained out-of-band. 2) Retransmission Server receives the RTCP RSR Message, and decides whether to accept it or not. The Retransmission Server sends a new extended RTCP Message "RTCP Rapid Synchronization Indication" (RSI) to the Receiver. This new RTCP Transport Layer Feedback Message "RTCP Rapid Synchronization Indication" (RSI) is defined in Section 4.2. The RTCP RSI Message contains the result of Rapid Synchronization Request, First sequence number of the unicast stream and the expected minimum interval of the extend RTCP Transport Layer Feedback Message "RTCP Synchronization Rate Adaptation (SRA)". Note that when Retransmission Server Receives RTCP RSR Message, it MUST also disable all the data streams of the current channel provided to the Receiver. For example, the Retransmission Server should cancel the earlier pending rapid synchronization operation or stop the ongoing synchronization operation by ceasing the relevant unicast burst media stream of the current channel. The retransmission service for the current channel provided to the receiver also SHOULD be disabled. 3) If Retransmission Server grants the rapid synchronization request, it transmits the unicast media stream of the new channel to Receiver at an accelerated rate. 4) Since it receives the unicast burst media stream, Receiver can test for a maximum optimal network speed for the burst media stream transfer. The method for testing the maximum optimal network speed is based on the receiving packets of unicast burst media stream. If there is no packet loss or stationary loss, it indicates that higher bitrate is possible. It indicates that lower bitrate is necessary if packet loss is higher. The Receiver will make its feedback to Retransmission Server by sending a new extended RTCP Message "RTCP Synchronization Rate Adaptation (SRA)" according to the result of the maximum optimal network speed test, and give a Proposed Adaptive Bitrate. This new RTCP Transport Layer Feedback Message "RTCP Synchronization Rate Adaptation (SRA)" is defined in Section 4.3. 5) Receiving the RTCP SRA Message, the Retransmission Server adjusts Yang, et al. Expires September 9, 2009 [Page 4] Internet-Draft Extension for Rapid Synch March 2009 its current transmitting bitrate to the maximum optimal bitrate according to the RTCP SRA Message proposal of the Receiver and the current condition of Retransmission Server. 6) Once unicast burst media stream is synchronized with multicast media stream(that is to say, the unicast burst media catches up with Real-time multicast media stream, Retransmission Server first decreases its transmitting bitrate to a lower rate, and then sends the RTCP Message "RTCP Synchronization Completed Notification (SCN)" to instruct the Receiver to join the multicast session. This new RTCP Transport Layer Feedback Message "RTCP Synchronization Completed Notification (SCN)" is defined in Section 4.4. 7) After the Receiver receives the RTCP SCN Message, it immediately sends multicast session join message to start receiving real-time multicast media stream. 8) When the Receiver receives the multicast RTP flow, it sends the RTCP Message "RTCP Synchronization Completed Response (SCR)" to the Retransmission Server to ask to terminate the unicast burst media stream. This new RTCP Transport Layer Feedback Message "RTCP Synchronization Completed Response (SCR)" is defined in Section 4.5. The RTCP SCR message contains the first sequence number of the multicast RTP flow. Note that during the burst unicast streaming, either the loss of key information or data of random access point should cause the receiver join the new multicast session. Whereafter, the receiver sends RTCP Message "RTCP Synchronization Completed Response (SCR)", which includes the reason of termination, to the Retransmission Server to request for ceasing the current burst unicast. 9) When the Retransmission Server receives the first sequence number of the multicast RTP flow, it will transmit the unicast media stream until the first sequence number. 10) When the Receiver requests to switch to a second channel, the rapid synchronization request message - the RTCP Transport Layer Feedback Message "RTCP Rapid Synchronization Request (RSR)" shall use the previous optimal bitrate for optimal rapid Synchronization of multicast session. Note that when the Receiver requests to switch to a second channel, there may be an earlier rapid synchronization operation that is pending or active. If the Receiver does not receive unicast burst media stream. So RTCP RSR message shall use the default bitrate. If the Receiver has received unicast burst media stream, RTCP RSR message shall use the actual bitrate by measuring the burst unicast Yang, et al. Expires September 9, 2009 [Page 5] Internet-Draft Extension for Rapid Synch March 2009 media stream. 3. Rapid Synchronization Mechanism Flow The flow diagram for rapid synchronization mechanism is illustrated in Figure 1. This mechanism can be implemented using the extensions of RTCP Transport Layer Feedback Messages defined in this document. In this rapid synchronization mechanism, it can be supported by sending video streaming based on unicast with key information from Retransmission Server to Receiver. In the meantime, Retransmission Server will adjust to the optimal maximum sending bitrate in terms of network situation based on Receiver's feedback. RTP Retransmission Router Receiver Sender Server v v v v | | | | | | | | | RTP multicast session flow | | |===================================>| | | | | | | RTCP Rapid Synchronization Request(default bitrate) | | |<-------------------------------------------| | | | | | | RTCP Rapid Synchronization Indication() | | |------------------------------------------->| | | | | | | RTP unicast burst (at actual bitrate) | | |===========================================>| | | | | | | RTCP Synchronization Rate Adaptation() | | |<-------------------------------------------| | | | | | | RTP unicast burst(at adaptive bitrate) | | |===========================================>| | | | | | RTCP Synchronization Completed Notification() | | |------------------------------------------->| | | | | | | | IGMP Join | | | |<-------------------| | | | | | RTP multicast session flow | |===================================>|===================>| | | | | | RTCP Synchronization Completed Response() | Yang, et al. Expires September 9, 2009 [Page 6] Internet-Draft Extension for Rapid Synch March 2009 | |<-------------------------------------------| | | | | ----------------------------------------------------------------- Change to the second channel ----------------------------------------------------------------- | | | | | RTCP Rapid Synchronization Request(adaptive bitrate) | | |<-------------------------------------------| | | | | | | RTCP Rapid Synchronization Indication() | | |------------------------------------------->| | | | | | | RTP unicast burst(at adaptive bitrate) | | |===========================================>| | | | | | | | | v v v v Figure 1: Flow diagram for rapid synchronization 4. The format of new extended RTCP Transport Layer Feedback Messages This section defines the format of new RTCP Transport Layer Feedback Messages that are exchanged between the Retransmission Server and Receiver during rapid synchronization. 4.1. RTCP Rapid Synchronization Request(RSR) The RTCP RSR Request message is identified by PT=RTPFB and FMT=5. The RTCP RSR Request is mandatory. The RTCP RSR Request is used by Receiver to request rapid synchronization for a new multicast RTP session and to request for ceasing all data streams associated with the current channel provided to the receiver . The RTCP RSR field has the structure depicted in Figure 2. Yang, et al. Expires September 9, 2009 [Page 7] Internet-Draft Extension for Rapid Synch March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Default/Adaptive Bitrate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Current Unicast Burst | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Syntax for the RSR messag Default Bitrate/Adaptive Bitrate The Default Bitrate/Adaptive Bitrate field is four octets. The Default Bitrate indicated by Receiver at the first time to request rapid synchronization, it depends on the Receiver's configuration. Adaptive Bitrate: Adaptive Bitrate is used when the Receiver requests a second rapid synchronization. It is the final adaptive bitrate of previous rapid synchronization. The Adaptive Bitrate will be adjusted dependence on network transportation situation. The Default Bitrate/Adaptive Bitrate must be higher than multicast bitrate. SSRC of Current Unicast Burst The SSRC of Current Unicast Burst field is four octets. The SSRC of unicast burst indicates the unicast burst media stream of the current channel. This field is used to request Retransmission Server to cease the unicast burst media stream of the current channel. 4.2. RTCP Rapid Synchronization Indication(RSI) The RTCP RSI Indication message is identified by PT=RTPFB and FMT=6. The RTCP RSI field has the structure depicted in Figure 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result | Reserved |I| Reason-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First Unicast Sequence Number | Min SRA Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Syntax for the RSI message Result The Result field is one octet. The Result value are assigned as follows: Yang, et al. Expires September 9, 2009 [Page 8] Internet-Draft Extension for Rapid Synch March 2009 1 for Success 2 for Failure Min SRA Interval Flag (I): 1 bit When theMin SRA Interval Flag Bit is set to 1, the Min SRA Interval field indicates the interval in number of packets. Otherwise, when the Min SRA Interval Flag Bit is set to 0,the Min SRA Interval field indicates the time interval. Its default value is set to 0. Reserved The Reserved fields are one octet and are set to zero on transmission, and ignored on reception. Reason-type The Reason-type field is two octets. The Reason-type field depends on the Result field. This field defines the initial set of successful type when the Result field set to 1 (Success). In the meantime, this field also defines the initial set of failure reason when the Result field set to 2 (Failure). for Success Result: 1 for joining the multicast session immediately 2 for waiting for notification to join multicast session First Unicast Sequence Number The First Unicast Sequence Number field is two octets. The First Unicast Sequence Number field indicates the first packet that will be sent as part of the rapid synchronization. This field allows Receiver to know if one or more packets are dropped at the beginning of rapid synchronization. The First Unicast Sequence Number field is constructed by putting the 16-bit RTP sequence number. Min SRA Interval The Min SRA Interval field is two octets. The Min SAR Interval field specifies the allowed minimum time/packet number before sending a Synchronization Rate Adaptation(SAR). If theMin SRA Interval Flag Bit is set to 0, it is in units of 1/10 second. Otherwise, the Min SRA Interval field indicates the interval in number of packets. If network situation is unstable, Receiver will send the RTCP SAR Message at "Min SRA Interval" interval ( or receiving the packet Yang, et al. Expires September 9, 2009 [Page 9] Internet-Draft Extension for Rapid Synch March 2009 number of the "Min SRA Interval"). When transmitting bitrate reach a stable state - maximum optimal bitrate, Receiver will send the RTCP SAR Message at longer interval and even won't send. 4.3. RTCP Synchronization Rate Adaptation(SRA) The RTCP SAR Request message is identified by PT=RTPFB and FMT=7. The RTCP SRA field has the structure depicted in Figure 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposed Adaptive Bitrate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of packet loss | Period of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Syntax for the SRA message Proposed Adaptive Bitrate The Proposed Adaptive Bitrate field is four octets. The Proposed Adaptive Bitrate field indicates that the final optimum rate of transportation is used from Retransmission Server to Receiver. It gradually adjusts the bitreate that Reveive can receive. If there is no packet loss or stationary loss, it indicates that higher bitrate is possible. It indicates that lower bitrate is necessary if packet loss is higher. Number of packets lost The Number of packets lost field is two octets. Period of packets lost The Period of packets lost field is two octets. It is in units of 1/10 second. 4.4. RTCP Synchronization Completed Notification(SCN) The RTCP SCN notification indication message is identified by PT=RTPFB and FMT=8. The RTCP SCN field has the structure depicted in Figure 5. Yang, et al. Expires September 9, 2009 [Page 10] Internet-Draft Extension for Rapid Synch March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Final Optimal Adaptive Bitrate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Syntax for the SCN messag Final Optimal Adaptive Bitrate The Final Optimal Adaptive Bitrate field is four octets. The Final Optimal Adaptive Bitrate field indicates the final optimal transmission rate from Retransmission Server to Receiver. Receiver can use this rate to request subsequent Rapid Synchronization. 4.5. RTCP Synchronization Completed Response(SCR) The RTCP SCR response message is identified by PT=RTPFB and FMT=9. The RTCP SCR field has the structure depicted in Figure 6. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved |First Multicast Sequence Number| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Syntax for the SCR message Type 1 for the response of joining the multicast session immediately 2 2 for indicating either key information or data of random access point of the current burst unicast media stream get lost and requesting to cease the current burst unicast media stream for the associated multicast session that the Receiver is going to join. When the Type field is set to 1. It indicates that the Receive responses the type of joining the multicast session immediately When the Type field is set to 2. It indicates that either key information or data of random access point of the current burst unicast media stream get lost,the receiver requests the Retransmission Server to cease the current burst unicast media stream for the associated multicast session that the Receiver is going to join . Yang, et al. Expires September 9, 2009 [Page 11] Internet-Draft Extension for Rapid Synch March 2009 Note that when the Type field is set to 2. The SSRC field in RTCP extension feedback message indicates the SSRC of burst unicast media stream for the associated multicast group that the Receiver is going to join. Reserved The Reserved fields are three octets and are set to zero on transmission, and ignored by the receiver. First Multicast Sequence Number The First Multicast Sequence Number field is two octets. When the Type field is set to 1, the First Multicast Sequence Number field indicates the first sequence number received from the multicast stream. When Retransmission Server receives the message, it sends unicast stream until First Multicast Sequence Number. When the Type field is set to 2, the First Multicast Sequence Number is set to 0x0. 5. Security Considerations TBC. 6. Change Log The following are the major changes compared to version 00: 1.In the Rapid Synchronization Mechanism Description section, some steps' descriptions have been modified 2. In the format of new extended RTCP Transport Layer Feedback Messages section, some fields of feedback message have been redefined. 3. Editorial changes to several points 7. Normative References [I-D.ietf-avt-rtcp-guidelines] Ott, J. and C. Perkins, "Guidelines for Extending the RTP Control Protocol (RTCP)", draft-ietf-avt-rtcp-guidelines-00 (work in progress), July 2008. Yang, et al. Expires September 9, 2009 [Page 12] Internet-Draft Extension for Rapid Synch March 2009 [I-D.levin-avt-rtcp-burst] Levin, O. and Z. Vax, "Extensions to RTCP Feedback Mechanism for Burst Streaming", draft-levin-avt-rtcp-burst-00 (work in progress), October 2008. [I-D.versteeg-avt-rapid-synchronization-for-rtp] Steeg, B., Begen, A., and T. Caenegem, "Unicast-Based Rapid Synchronization with RTP Multicast Sessions", draft-versteeg-avt-rapid-synchronization-for-rtp-01 (work in progress), November 2008. [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. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. Authors' Addresses Peilin Yang Huawei Technologies Co., Ltd. No.91 Baixia Road Nanjing 210001 P.R.China Email: yangpeilin@huawei.com Yang, et al. Expires September 9, 2009 [Page 13] Internet-Draft Extension for Rapid Synch March 2009 Baohua Lei China Telecom No.118, Xizhimenneidajie Xicheng District Beijing 100035 P.R.China Email: Leibh@ctbri.com.cn Zixuan Zou Huawei Technologies Co., Ltd. Huawei Industrial Base Shenzhen P.R.China Email: tendyntu@huawei.com Yang, et al. Expires September 9, 2009 [Page 14]