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]