Audio/Video Transport P. Yang Internet-Draft Huawei Technologies Co., Ltd. Intended status: Standards Track B. Lei Expires: July 28, 2009 China Telecom January 24, 2009 Extensions to RTCP for Rapid Synchronization draft-peilin-avt-rtp-burst-00.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 July 28, 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 (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. Abstract This document specifies an extension to "Extended RTP Profile for Yang & Lei Expires July 28, 2009 [Page 1] Internet-Draft Extension for Rapid Synch January 2009 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 . . . . . . . . . . . . . 5 4. The format of new extended RTCP Transport Layer Feedback Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. RTCP Rapid Synchronization Request (RSR) . . . . . . . . . 7 4.2. RTCP Rapid Synchronization Indication (RSI) . . . . . . . 7 4.3. RTCP Synchronization Rate Adaptation (SRA) . . . . . . . . 9 4.4. RTCP Synchronization Completed Notification (SCN) . . . . 11 4.5. RTCP Synchronization Completed Response(SCR) . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6.2. Informational References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Yang & Lei Expires July 28, 2009 [Page 2] Internet-Draft Extension for Rapid Synch January 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. 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 contains the SSRC of the packet sender and the SSRC of media source. The receiver indicates that it needs to receive media streaming with the key Yang & Lei Expires July 28, 2009 [Page 3] Internet-Draft Extension for Rapid Synch January 2009 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 must be obtained out-of-band or in-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)". 3) If Retransmission Server grants the rapid synchronization request, it transmits the unicast media stream 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, 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 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 a lower rate, and then sends the RTCP Message "RTCP Synchronization Completed Notification (SCN)" to the Receiver to join the multicast session and terminate the unicast burst media stream. This new RTCP Transport Layer Feedback Yang & Lei Expires July 28, 2009 [Page 4] Internet-Draft Extension for Rapid Synch January 2009 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. 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. 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) | | |<-------------------------------------------| Yang & Lei Expires July 28, 2009 [Page 5] Internet-Draft Extension for Rapid Synch January 2009 | | | | | | 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() | | |<-------------------------------------------| | | | | ----------------------------------------------------------------- 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 Yang & Lei Expires July 28, 2009 [Page 6] Internet-Draft Extension for Rapid Synch January 2009 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. The RTCP RSR field has the structure depicted in Figure 2. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 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. Yang & Lei Expires July 28, 2009 [Page 7] Internet-Draft Extension for Rapid Synch January 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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: 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 theMin 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 Numberfield is two octets. The First Yang & Lei Expires July 28, 2009 [Page 8] Internet-Draft Extension for Rapid Synch January 2009 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 Interva 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/100 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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved |L|I| Proposed Bitrate Increment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fraction lost | Reserved | Number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lowest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PID | BLP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Syntax for the SRA message Type The Type field is one octet. 1 for ACK Yang & Lei Expires July 28, 2009 [Page 9] Internet-Draft Extension for Rapid Synch January 2009 2 for NACK Lost Packet Flag (L): 1 bit Lost Packet Flag Bit is set to 1 if the RTCP Synchronization Rate Adaptation message contains the PIDs of lost packets. Proposed Bitrate Increment Flag(I): 1 bit Proposed Bitrate Increment Flag Bit is set to 1 if the RTCP Synchronization Rate Adaptation message proposes to decrease the transmitting bitrate. Proposed Bitrate Increment Flag Bit is set to 0 if the RTCP Synchronization Rate Adaptation message proposes to increase the transmitting bitrate. Proposed Bitrate Increment The Proposed Bitrate Increment field is 31bits. The Proposed Bitrate Increment field indicates a proposed reference value that the retranmission Server increases or decreases the increment of transmitting bitrate. Increasing or decreasing transmitting bitrate depends on the Proposed Bitrate Increment Flag field. If the Proposed Bitrate Increment Flag is set to 1, it meas that the transmitting bitrate will be decreased, otherwise,it will be increase. If the Proposed Bitrate Increment field is equal to 0, it means that the transmitting bitrate is stable and don't need to change. Fraction lost The Fraction lost field is one octet. The fraction of RTP data packets from Retransmission Server lost since the reception of the packet with Lowest sequence number received, expressed as a fixed point number with the binary point at the left edge of the field. (That is equivalent to taking the integer part after multiplying the loss fraction by 256.) This fraction is defined to be the number of packets lost divided by the total number of packets expected between Lowest sequence number received and Highest sequence number received. If the loss is negative due to duplicates, the fraction lost is set to zero. Reserved The Reserved fields are three octets and are set to zero on transmission, and ignored by the receiver. Number of packets lost Yang & Lei Expires July 28, 2009 [Page 10] Internet-Draft Extension for Rapid Synch January 2009 The Number of packets lost field is two octets. Lowest sequence number received The Lowest sequence number received field is four octets. The Lowest sequence number received field indicates that the packets were not lost before the Lowest sequence number. Highest sequence number received The Highest sequence number received field is four octets. The Highest sequence number received field indicates that the highest sequence number of the packet has currently received. 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. 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 |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Final Optimal Adaptive Bitrate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Syntax for the SCN messag Type The Type field is one octet. 1 for joining the multicast group immediately When the Type field is set to 1, it indicates that Retransmission Server notifies Receiver to join multicast group at once, it also means that the unicast stream and the multicast stream are synchronized. Reserved The Reserved fields are three octets and are set to zero on transmission, and ignored by the receiver. Notification Mode Flag(M): 1 bit Yang & Lei Expires July 28, 2009 [Page 11] Internet-Draft Extension for Rapid Synch January 2009 Notification Mode Flag Bit is set to 1 if the Type field is set to 1. Otherwise, it is other type. 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 group immediately When the Type field is set to 1. It indicates that the Receive responses the type of joining the multicast group immediately 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. 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. 5. Security Considerations TBC. Yang & Lei Expires July 28, 2009 [Page 12] Internet-Draft Extension for Rapid Synch January 2009 6. References 6.1. Normative References [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. 6.2. Informational 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. [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. Yang & Lei Expires July 28, 2009 [Page 13] Internet-Draft Extension for Rapid Synch January 2009 Authors' Addresses Peilin Yang Huawei Technologies Co., Ltd. No.91 Baixia Road Nanjing 210001 P.R.China Email: yangpeilin@huawei.com Baohua Lei China Telecom No.118, Xizhimenneidajie Xicheng District Beijing 100035 P.R.China Email: Leibh@ctbri.com.cn Yang & Lei Expires July 28, 2009 [Page 14]