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]