AVT B. Ver Steeg
Internet-Draft A. Begen
Intended status: Standards Track Cisco Systems
Expires: January 8, 2009 T. Van Caenegem
Alcatel-Lucent Bell
July 7, 2008
Unicast-Based Rapid Synchronization with RTP Multicast Sessions
draft-versteeg-avt-rapid-synchronization-for-rtp-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 January 8, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
When a receiver joins a multicast session, it may need to acquire and
parse certain key information before it can process any data sent in
the multicast session. Depending on the join time, length of the key
information repetition interval, size of the key information as well
as the application and transport properties, the time lag before a
receiver can usefully consume the multicast data, which we refer to
VerSteeg, et al. Expires January 8, 2009 [Page 1]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
as the synchronization delay, varies and may be large. This is an
undesirable phenomenon for receivers that frequently switch among
different multicast sessions, such as video broadcasts. In this
document, we describe a method using existing RTP and RTCP protocol
machinery that reduces the synchronization delay. In this method, an
auxiliary unicast RTP session carrying the key information to the
receiver precedes/accompanies the multicast flow. This unicast flow
may be transmitted at a faster than natural rate to further
accelerate the synchronization. The motivating use case for this
capability is multicast applications that carry real-time compressed
audio and video. However, the proposed method can also be used in
other types of multicast applications where the synchronization delay
is long enough to be a problem.
VerSteeg, et al. Expires January 8, 2009 [Page 2]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Elements of Delay in Multicast Streams . . . . . . . . . . . . 7
5. Elements of Delay in Video Systems . . . . . . . . . . . . . . 9
5.1. Overview of MPEG-2 Transport Streams . . . . . . . . . . . 9
5.2. Key Information Latency in Video Applications . . . . . . 11
5.2.1. PSI (PAT/CAT/PMT) Acquisition Delay . . . . . . . . . 11
5.2.2. Random Access Point Acquisition Delay . . . . . . . . 11
5.3. Buffering Delays in Video Applications . . . . . . . . . . 12
5.3.1. Network-Related Buffering Delays . . . . . . . . . . . 13
5.3.2. Application-Related Buffering Delays . . . . . . . . . 13
5.4. Breakdown of Typical Synchronization Delays in IPTV . . . 14
6. Rapid Synchronization . . . . . . . . . . . . . . . . . . . . 14
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Message flows and State Machines . . . . . . . . . . . . . 16
6.3. Encoding of the Signaling Protocol . . . . . . . . . . . . 19
6.4. Shaping the Burst . . . . . . . . . . . . . . . . . . . . 19
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 19
7. Session Description Protocol (SDP) Signaling . . . . . . . . . 19
8. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 22
9. Open Source RTP Receiver Implementation . . . . . . . . . . . 22
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Protocol Encoding Option #A . . . . . . . . . . . . . 24
A.1. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.2. RTP Sequence Number for the First Rapid
Synchronization Packet . . . . . . . . . . . . . . . . . . 26
A.3. Earliest IGMP Join Time . . . . . . . . . . . . . . . . . 26
A.4. Rapid Synchronization End Time . . . . . . . . . . . . . . 26
A.5. TSRAP Data . . . . . . . . . . . . . . . . . . . . . . . . 26
A.6. Actual Rapid Synchronization Fill . . . . . . . . . . . . 27
A.7. Join-Time Rapid Synchronization Fill . . . . . . . . . . . 27
Appendix B. Protocol Encoding Option #B . . . . . . . . . . . . . 27
B.1. RMS-R RTCP Message Format . . . . . . . . . . . . . . . . 27
B.2. RMS-I RTCP Message Format . . . . . . . . . . . . . . . . 27
B.3. RMS-T RTCP Message Format . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 30
VerSteeg, et al. Expires January 8, 2009 [Page 3]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
1. Introduction
Most multicast flows carry a stream of inter-related data. Certain
information must first be acquired by the receivers to start
processing any data sent in the multicast session. This document
refers to this information as "Key Information." The key information
is conventionally sent periodically in the multicast session and
usually consists of items such as a description of the schema for the
rest of the data, references to which data to process for the
receivers, encryption information including keys, as well as any
other information required to process the data in the multicast flow.
Real-time multicast applications require the receivers to buffer
data. The receiver may have to buffer data to smooth out the network
jitter, to allow loss-repair methods such as forward error correction
and retransmission to recover the missing packets, and to satisfy the
data processing requirements of the application layer.
When a receiver joins a multicast session, it has no control over
what point in the flow is currently being transmitted. Sometimes the
receiver may join the session right before the key information is
sent in the session. In this case, the required waiting time is
usually minimal. Similarly, the receiver may also join the session
right after the key information has been transmitted. In this case
the receiver has to wait for the key information to appear again in
the stream before it can start processing any multicast data. In
some other cases, the key information is not contiguous in the flow
but dispersed over a large period, which forces the receiver to wait
for all of the key information to arrive before starting to process
the rest of the data.
The net effect of waiting for the key information and waiting for
various buffers to fill up is that the receivers may experience
significantly large delays in data processing. In this document, we
refer to the difference between the time a receiver joins the
multicast session and the time the receiver acquires all the
necessary key information as the "Synchronization Delay." The
synchronization delay may not be the same for different receivers; it
usually varies depending on the join time, length of the key
information repetition interval, size of the key information as well
as the application and transport properties.
The varying nature of the synchronization delay adversely affects the
receivers that frequently switch among multicast sessions. In this
specification, we address this problem for RTP-based multicast
applications and describe a method that uses the fundamental tools
offered by the existing RTP and RTCP protocols [RFC3550]. In this
method, either the multicast source (or the distribution source in a
VerSteeg, et al. Expires January 8, 2009 [Page 4]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
single-source multicast (SSM) session) retains key information for a
period after transmission, or an intermediary network element joins
the multicast session and continuously caches the key information as
it is sent in the session and acts as a feedback target (See
[I-D.ietf-avt-rtcpssm]) for the session. When a receiver wishes to
join the same multicast session, instead of simply issuing an
Internet Group Management Protocol (IGMP) [RFC3376] Join message, it
sends a request to the feedback target address for the session asking
for the key information. The feedback target starts a unicast
retransmission RTP session and sends the key information to the
receiver over that session. If there is spare bandwidth, the
feedback target may also burst the key information at a faster than
natural rate. As soon as the receiver acquires the key information,
it can join the multicast group and start processing the multicast
data. This method potentially reduces the synchronization delay. We
refer to this method as "Unicast-based Rapid Synchronization with RTP
Multicast Sessions." A simplified network diagram showing the rapid
synchronization method through an intermediary network element is
depicted in Figure 1.
+-----------------+
+--->| Intermediary |
| ...| Network Element |
| : |(Feedback Target)|
| : +-----------------+
| v
+--------+ +------+ +--------+
| RTP |---->|Router|........>|Joining |
| Sender | | |-------->| RTP |
+--------+ +------+ |Receiver|
| +--------+
|
| +--------+
+----------->|Existing|
| RTP |
|Receiver|
+--------+
---> RTP Multicast Flow
...> RTP Unicast Flow
Figure 1: Rapid synchronization through an intermediary network
element
A primary design goal in this solution is to use the existing tools
in the RTP protocol family. This improves the versatility of the
existing implementations, and promotes faster deployment and better
interoperability. To this effect, we use the unicast retransmission
VerSteeg, et al. Expires January 8, 2009 [Page 5]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
support of RTP [RFC4588] and the capabilities of RTCP to handle the
signaling needed to accomplish the synchronization. The packet(s)
carrying the key information are sent by the feedback target in the
auxiliary unicast session for rapid synchronization. These are
constructed as retransmission packets that would have been sent in a
unicast RTP session to recover the missing packets at a receiver that
has never received any packet. In fact, there is a single RTP
session used for both rapid synchronization and loss repair. The
conventional RTCP feedback message that requests the retransmission
of the missing packets [RFC4585] indicates their sequence numbers.
However, upon joining a new session the receiver has never received a
packet and thus, does not know the sequence numbers. Instead, the
receiver sends an RTCP feedback message indicating "picture loss" to
request the key information needed to rapidly synchronize with the
main multicast session. [RFC4585] provides support for this special
RTCP feedback message. It is also worth noting that in order to
issue the initial RTCP message to the feedback target, the SSRC of
the session to be joined must be known prior to any packet reception,
and hence, needs to be signaled out-of-band (or in-band). In a
Session Description Protocol (SDP) description, the SSRC MUST be
signaled through the 'ssrc' attribute [I-D.ietf-avt-rtcpssm].
In the rest of this specification, we have the following outline: In
Section 4, we describe the delay components in generic multicast
applications. In Section 5, we introduce the delay components that
are specific to MPEG-based video. We provide the protocol details of
the rapid synchronization method in Section 6. Section 7 and
Section 8 discuss the SDP signaling issues with examples and NAT-
related issues, respectively. Finally, in Section 9 we provide a
pointer to an open source RTP Receiver code that implements the
functionalities introduced in this document. Note that Section 3
provides a list of the acronyms used frequently in this document.
It should be noted that while we primarily focus on multicast
applications that carry compressed audio and video in explaining the
protocol details, the same described method can also be used in
multicast applications that carry other types of data.
2. Requirements Notation
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].
VerSteeg, et al. Expires January 8, 2009 [Page 6]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
3. Acronyms
This document uses the following acronyms frequently:
CAT: Conditional access table.
DTS: Decoding timestamp.
ECM: Entitlement control message.
EMM: Entitlement management message.
ES: Elementary stream.
GoP: Group of pictures.
IDR: Instantaneous decoding refresh.
MPEG2-TS: MPEG2 transport stream.
MPTS: Multi program transport stream.
PAT: Program association table.
PCR: Program clock reference.
PMT: Program map table.
PSI: Program specific information.
PTS: Presentation timestamp.
RAP: Random access point.
SPTS: Single program transport stream.
TSRAP: Transport stream random access point.
4. Elements of Delay in Multicast Streams
In an any-source (ASM) or a single-source (SSM) multicast delivery
system, there are three major elements that contribute to the overall
synchronization delay when a receiver switches from one multicast
session to another one. These are:
VerSteeg, et al. Expires January 8, 2009 [Page 7]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
o Multicast switching delay
o Key information latency
o Buffering delays
Multicast switching delay is the delay that is experienced to leave
the current multicast session (if any) and join the new multicast
session. In typical systems, the multicast join and leave operations
are handled by a group management protocol. For example, the
receivers and routers participating in a multicast session may use
the Internet Group Management Protocol (IGMP) [RFC3376]. In
[RFC3376], when a receiver wants to join a multicast session, it
sends an IGMP Join message to its upstream router and the routing
infrastructure sets up the multicast forwarding state to deliver the
packets of the multicast session to the new receiver. Depending on
the proximity of the upstream router, the current state of the
multicast tree, the load on the system and the protocol
implementation, the join times vary. Current systems provide join
latencies usually less than 200 milliseconds (ms). If the receiver
had been participating in another multicast session before joining
the new session, it needs to send an IGMP Leave message to its
upstream router to leave the session. The leave times are usually
smaller than the join times, however, it is possible that the Leave
and Join messages may get lost, in which case the multicast switching
delay inevitably increases.
Key information latency is the time it takes the receiver to acquire
the key information. It is highly dependent on the proximity of the
actual time the receiver joined the session to the next time the key
information will be sent to the receivers in the session, whether the
key information is sent contiguously or not, and the size of the key
information. For some multicast flows, there is a little or no
interdependency in the data, in which case the key information
latency will be nil or negligible. For other multicast flows, there
is a high degree of interdependency. One example is the multicast
flows that carry compressed audio/video. For these flows, the key
information latency may become quite large and be a major contributor
to the overall delay. We describe the interdependency associated
with audio/video flows in detail in Section 5.
The buffering component of the overall synchronization delay is
driven by the way the application layer processes the payload. In
many multicast applications, an unreliable transport protocol such as
UDP [RFC0768] is often used to transmit the data packets, and the
reliability, if needed, is usually addressed through other means such
as forward error correction and retransmission
[I-D.ietf-rmt-pi-norm-revised]. These loss repair methods require
VerSteeg, et al. Expires January 8, 2009 [Page 8]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
buffering at the receiver side to function properly. In many
applications, it is also often necessary to de-jitter the incoming
data packets before feeding them to the application. The de-
jittering process also increases the buffering delays. Besides these
network-related buffering delays, there are also specific buffering
needs that are required by the individual applications. For example,
MPEG decoders require a significant amount of content to be available
in the decoder buffers prior to starting to decode the content. We
describe these buffering requirements for audio/video applications in
detail in Section 5.
5. Elements of Delay in Video Systems
For typical multicast-based video delivery systems, the multicast
switching delay (time required to leave the previous multicast
session and join the new session) is not the primary contributor to
the overall synchronization delay. The multicast flows are typically
already present at the edge or deep in the network, the propagation
delays for join operations are modest, and the multicast routers can
typically process the Join and Leave messages quickly. Even if the
edge multicast router is not currently a member of the requested
multicast session, the multicast routing control messages propagate
through the network rapidly and trees are built without experiencing
large delays. Even in cases where a number of tree branches need to
be built to the edge multicast router, this cost is frequently
amortized over a large number of receivers such that only the first
receiver joining the group experiences the increased delay. Further,
this delay can be eliminated at the cost of extra bandwidth in the
network core by having the edge routers do static joins for the set
of sessions they expect receivers to be interested in. These
techniques usually provide a well-bounded multicast switching delay.
Once the join operation completes and a receiver starts receiving
media content for the first time in a multicast session, it often
experiences a considerable amount of key information latency and
buffering delays. In the following subsections, we discuss the
details of these delay elements, using MPEG2 Transport Streams as the
motivating use case.
5.1. Overview of MPEG-2 Transport Streams
MPEG2 Transport Stream (MPEG2-TS) [MPEG2TS] is an encapsulation
method and transport that multiplexes digital video and audio
content, together with ancillary metadata, and produces a
synchronized multiplexed stream that is tailored for transport over
packet or cell-oriented networks. MPEG2-TS is ubiquitous in
broadcast applications over both terrestrial and satellite networks.
VerSteeg, et al. Expires January 8, 2009 [Page 9]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
Both Advanced Television Systems Committee (ATSC) in North America
and Digital Video Broadcasting (DVB) in Europe use MPEG2-TS in their
standards. MPEG2-TS has been standardized by both ISO and ITU
[MPEG2TS]. While MPEG2-TS was originally limited to carry MPEG-2
encoded content, the specification was later extended to cover MPEG-
4/AVC video/audio encoding standards as well.
MPEG2-TS is a container format that describes the schema of the audio
and video content and the in-band control information. Prior to
multiplexing, an audio and a video encoder output audio and video
Elementary Streams (ES), respectively. The ES streams are then
packetized to form the Packetized Elementary Streams (PES). The
resulting elements are called PES packets. A transport stream (TS)
encapsulates several PES streams and other data, and carries them in
TS packets. The RTP payload format for carrying TS packets in an RTP
stream is specified in [RFC2250]. In addition to the audio and video
ES streams, there are ES streams that carry control data.
Program Specific Information (PSI) consists of metadata carried in
the transport stream. PSI includes Program Association Table (PAT),
Conditional Access Table (CAT) and Program Map Table (PMT). A PAT
has information about all the programs carried in the transport
stream. It lists the 13-bit Program IDs (PID) for all the PMTs,
associating them with the individual programs. Each of the ES
streams of a particular program in the transport stream also has the
same PID values. This way, a decoder at the receiving side can
extract the desired TS packets from the transport stream by checking
their PID values. If the transport stream is not a Multi-Program
Transport Stream (MPTS), but rather it is a Single-Program Transport
Stream (SPTS), all the ES streams in the transport stream correspond
to a single program and the PAT data is not carried.
CAT defines the type of the scrambling used (either at the PES or TS
level), and identifies all the PID values of the TS packets that
contain the Entitlement Management Messages (EMM). In addition to
containing the PID values of each ES stream associated with a
particular program, the PMT table also includes private data
associated with the program such as the PID value of the packet
containing the Entitlement Control Messages (ECM). The data
contained in the EMM and ECM messages are vital in descrambling
encrypted content. Note that PSI is carried in clear and is never
scrambled so that a receiver which just started receiving the
transport stream can process the PSI. The PAT, CAT and PMT tables
must be parsed by the decoder in order to find the ES streams,
private data as well as the encryption information for a given
program.
MPEG2-TS produces output that is synchronized to a common clock
VerSteeg, et al. Expires January 8, 2009 [Page 10]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
across all the ESs in the multiplex. To assist the audio and video
decoders, programs periodically provide a Program Clock Reference
(PCR) value in the transport stream. PCR values are embedded in the
TS adaptation field headers and are inserted by the encoder at least
every 100 ms. A PCR timestamp represents the value of the encoder's
system clock when it was sampled. The system clock is driven by a
local 27 MHz oscillator.
PCR is extremely important in native MPEG-2 transport to keep the
decoders synchronized. For example, the periodically sent Decoding
Timestamps (DTS) and Presentation Timestamps (PTS) are specified
relative to the PCR value and the decoders use the PCR value as the
basis for a master clock during decoding and playout.
5.2. Key Information Latency in Video Applications
We classify the key information latency into two categories.
5.2.1. PSI (PAT/CAT/PMT) Acquisition Delay
As we discussed in Section 5.1, the video (and the audio as well) in
an MPEG2 TS is self describing, and the receiver must parse certain
control information in the PAT, CAT and PMT tables (i.e., PSI)
contained in the transport stream in order to know how to parse the
rest of the stream (i.e., to find the audio and video elementary
streams, private data and the encryption information for a given
program).
Many video services employ content encryption and the encryption keys
must be parsed as well for decrypting the content. In order to
enable various system elements to process video effectively, certain
portions of the stream are left unencrypted. The PAT/PMT tables are
always in the clear. The structure of the ECMs is also in the clear,
although the ECM content which contains keying material is encrypted.
The PSI information is repeated periodically in the transport stream,
thus, when a receiver joins the multicast session, it needs to wait
until the next time PSI is sent in the transport stream.
Editor's note: Do we need to list how frequent PSI/PCR/etc is
repeated in ATSC and/or DVB standards? Update: This will be
addressed in the next revision.
5.2.2. Random Access Point Acquisition Delay
Conventional MPEG2 video encoders encode the video content in Groups
of Pictures (GoP). Each GoP is encoded independently from other GoPs
and starts with an intra-coded frame (I-frame) that does not have any
reference to other frames in the same GoP, i.e., an I-frame contains
VerSteeg, et al. Expires January 8, 2009 [Page 11]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
the representation of an entire picture and can be decoded
independently. Thus, the start of an I-frame is said to be a Random
Access Point (RAP).
On the other hand, due to the temporal compression, rest of the
frames in the same GoP may have references to the I-frame or to other
frames in the same GoP. Due to this interdependency among the
frames, one generally has to receive certain elements of the GoP
prior to decoding or rendering any part of the GoP. For example, the
decoder can decode a frame that is dependent on two other frames only
after these two frames are decoded.
Usually, GoP durations are between 500 ms and one second. However,
more advanced codecs may use longer GoPs to gain from the encoding
efficiency. When a receiver joins the multicast session, it needs to
wait until the next RAP shows up in the multicast stream before it
can start decoding. Since the frame that is currently being
multicast does not depend on the join time, the average time a
receiver waits for RAP, i.e., the average RAP acquisition delay, is
half of the GoP duration. Hence, for longer GoPs, the RAP
acquisition delay is proportionally longer.
Advanced Video Coding (AVC) (also called MPEG4 part 10) compression
is very similar to MPEG2 compression. It has a few more compression
tools available, including Hierarchical GoPs. In a hierarchical GoP,
the dependent frames of a GoP may reference the key frame at the
start of this GoP or the key frame at the start of the next GoP.
This additional dependency causes a longer RAP acquisition delay, as
the decoder must receive two I-frames (spread between two logical
GoPs) before decoding can commence. AVC also has the ability to
insert Instantaneous Decoding Refresh (IDR) frames. Frames that
follow an IDR frame cannot reference frames that precede an IDR
frame. IDR frames are useful for editing AVC streams, but are
typically do not appear often enough in streaming video to be useful
in a stream synchronization context.
Note that in order for an intermediary network element such as a
retransmission server to find the random access points in the video
stream (e.g., I-frames), the necessary structural information must be
in the clear if the intermediary is not in possession of the
necessary keys.
5.3. Buffering Delays in Video Applications
We classify the buffering delays into two categories.
VerSteeg, et al. Expires January 8, 2009 [Page 12]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
5.3.1. Network-Related Buffering Delays
In general, multicast-based video applications use an unreliable
underlying transport protocol such as UDP [RFC0768] to distribute the
content to a large number of receivers. This is largely due to the
fact that these applications are one way in nature and providing
closed-loop reliability does not scale well when the number of
receivers is large or the acceptable playout delay is small, or both.
Rather, if there is a need for reliability, the applications may
employ one or more loss-repair methods to recover the packets missing
at each receiver (The Reliable Multicast Transport Working Group has
several standardized solutions for this problem. Refer to
[I-D.ietf-rmt-pi-norm-revised] for details). For example, forward
error correction (FEC) may be used proactively and/or on-demand to
provide reliable transmission to a potentially very large multicast
group in a scalable manner [I-D.ietf-fecframe-framework]. Similarly,
retransmissions may be used in RTP-based SSM sessions where the
retransmissions can be handled by local repair servers rather than
the source itself [I-D.ietf-avt-rtcpssm]. However, regardless of the
type of the loss-repair method(s) adopted by an application, loss-
recovery operations always require additional buffering at the
receiver side. The amount of buffering increases with the FEC block
size when FEC is used, and with the round-trip time between the
receiver and the local repair server when retransmission is used.
Audio and video decoders demand almost jitter-free content. If any
jitter is introduced during the transmission in the network or due to
the loss repair methods, the jitter has to be smoothed out before the
content is fed to the decoder. This is called de-jittering and it
usually adds up to the buffering delay.
5.3.2. Application-Related Buffering Delays
The application buffering requirements for MPEG-encoded content are
quite rigorous, particularly for the MPEG-based video applications.
Video compression devices apply more bits to represent certain scenes
than they do for other scenes. A very complex scene (individual
picture) requires considerably more information than a simple scene.
Furthermore, pictures that are entirely intra-coded, e.g., I-frames,
consume more bits compared to pictures that make use of predictive
coding. Each scene is shown by the decoder at a certain fixed frame
rate (e.g., 24 fps or 30 fps). Since some scenes are comprised more
bits than other scenes, the output rate of the decoder buffer is
usually variable. However, the network flow is typically Constant
Bit Rate (CBR) or Capped Variable Bit Rate (Capped VBR). The net
effect is that the input rate to the decoder buffer is close to
constant, but the output rate is highly variable.
VerSteeg, et al. Expires January 8, 2009 [Page 13]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
The video encoders keep track of the decoder buffer size, and use
this information to regulate the temporal compression. This forces
the decoder buffer to "breathe." In order to avoid underflow, the
decoder buffer must fill up to a certain level prior to starting to
decode and play the content. The decoder buffer size required to
avoid underflow is dependent on the encoder, and the encoder signals
the decoder buffering requirements in-band. Typical decoder buffer
requirements for MPEG2 content range from one second to two seconds.
However, AVC/MPEG4 part 10 encoders usually tend to use more temporal
compression, and thus require a larger buffer at the decoder side.
This consequently increases the buffering delays.
5.4. Breakdown of Typical Synchronization Delays in IPTV
Editor's note: This section will provide typical ranges for each of
the delay components based on our observations in the field. This
section is for educational and illustrative purposes.
6. Rapid Synchronization
The video systems we consider as a use case in this document
encapsulate multicast video flows in an IP/UDP/RTP/MPEG2-TS/<codec>
format. Typical codecs include MPEG2 and AVC/MPEG4 part 10, although
other codecs are also in use. The IP and UDP wrappers are well
understood and ubiquitous. Many legacy video deployments do not use
RTP encapsulation. However, in order to use the rapid
synchronization method specified in this document, RTP encapsulation
is clearly required.
We start this section with an overview of the rapid synchronization
method.
6.1. Overview
RTP [RFC3550], together with [RFC4588] and [RFC4585] provide the
mechanisms needed to encapsulate a data flow and use RTCP feedback to
implement a robust error-recovery mechanism for that flow. When
packets are lost, a receiver may use RTCP NACK messages to request
retransmission of those packets using RTP retransmission packets.
In order to achieve rapid synchronization, the receiver can use this
retransmission mechanism to request all of the data from the most
recent RAP. We therefore employ a new RTP/RTCP-based mechanism that
boils down to "I do not have synchronization with the stream. Send
me a repair burst that will cover all of the required data from a
recent RAP to the point the stream has reached in the multicast
session." Note that the rapid synchronization flow and the normal
VerSteeg, et al. Expires January 8, 2009 [Page 14]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
repair flow share the same RTP session.
In order to reduce the synchronization delay associated with
processing a new RTP encapsulated multicast flow, either the media
source may retain the stream state, and/or a Retransmission Server
(RS) may cache that flow near the egress edge and provide an
accelerated unicast burst to the requesting receiver. Which element
performs these functions depends on the desired scale of the system.
The protocol machinery is agnostic to the difference, as both use the
RTCP feedback target address as the way to identify the element
performing these functions.
Where a Retransmission Server (RS) is employed, it semi-permanently
joins the multicast session and receives the RTP steams it wishes to
cache so that it can perform the retransmission functions. For the
rapid synchronization support, RS parses the incoming flows, looking
for the key information. The key information may be segregated by RS
into two components - the key information that occurs in sequence
with the RTP data and that which does not occur in RTP sequence
order.
When acquiring an RTP session, the RTP Receiver (RR) sends an RTCP
message to the feedback target requesting an accelerated burst of
data from the multicast session via unicast including any key
information that occurs in sequence with the RTP data plus any
optional key information that does not occur in RTP sequence order.
In the case of IP/UDP/RTP/MPEG2-TS encapsulated video streams, the
key information that may not occur in the RTP sequence order may
consist of the information required to demultiplex and decode the
MPEG2 TS. We refer to this information as the Transport Stream
Random Access Point (TSRAP). The TSRAP information includes the PAT,
PMT, PCR and optionally the ECMs. The TSRAP information can be
either provided in the unicast burst to RR or it is sent from the
feedback target to RR in an RTCP packet.
The sequential key information, on the other hand, (i.e., the PES
header, I-frame and subsequent data) is always sent in the unicast
RTP flow, using the RTP retransmission payload format. This has
several advantages, including easy correlation between the packets in
the RTP session carrying the unicast burst and those of the multicast
session, and the ability of the receiver to utilize the same
algorithms for reception and processing the key information as it
does for dealing with RTP retransmissions during the normal session
operation.
The RTP data is sent from the feedback target to the receiver
starting with the sequential key information via unicast as described
VerSteeg, et al. Expires January 8, 2009 [Page 15]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
above. The MPEG data sent in the unicast burst starts with an
Elementary Stream Random Access Point (ESRAP). This includes a PES
header containing a PTS, followed by a sequence header, followed by
an I-frame. The unicast burst continues at a higher than natural
rate until the unicast burst catches up with the real-time multicast
flow.
6.2. Message flows and State Machines
The flow diagram for unicast-based rapid synchronization is sketched
in Figure 2. In this figure, we have an RTP Sender and an RTP
Receiver (RR). The rapid synchronization support is provided in this
scenario by a Retransmission Server (RS), although the message flows
are identical to the case where the rapid synchronization is
performed by a feedback target co-located with the media source.
Note that [I-D.ietf-avt-rtcpssm] permits the feedback target to be a
retransmission server, since it is a logical function to which RRs
send their unicast feedback.
Editor's note: In Figure 2, not all messages are shown. The flow
diagram will be revised and improved in the next revision.
+--------+
| RTP |
| Sender |
+--------+
|
v
+--------------+
| Router |<----- (1) IGMP Leave -------+
| |<----- (5) IGMP Join ------+ |
+--------------+ | |
| | | |
+-------+ +--- (6) New Multicast Flow ---+ | |
| | | |
v v | |
+--------------+ +----------+
| | <.... (2) RTCP NACK PLI .... | |
|Retransmission| & Buffer Requirements | RTP |
| Server | .. (3) Burst Description ..> | Receiver |
| (RS) | .... (4) Unicast Burst ....> | (RR) |
| | <.. (7) Burst Termination .. | |
+--------------+ +----------+
---> Multicast Flows and IGMP Messages
...> Unicast Flows
VerSteeg, et al. Expires January 8, 2009 [Page 16]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
Figure 2: Flow diagram for unicast-based rapid synchronization
The following steps describe rapid synchronization in detail:
1. RR sends an IGMP Leave message [RFC3376] to its upstream
multicast router to leave the current multicast session.
2. RR sends an RTCP packet that contains a NACK PLI message
[RFC4585] for the new multicast RTP session to the feedback
target address of that session. [RFC4585] specifies that the
packet type for a payload-specific feedback message to be 206 and
the feedback message type to be 1. The RTCP packet contains the
SSRC of RR and the SSRC of the media source. Note that since no
RTP packets have yet been received for this session, the SSRC
must be obtained out-of-band or in-band. For sessions described
using SDP [RFC4566], the SSRC MUST be signaled using the 'ssrc'
attribute of the media description (The 'cname' source attribute
MUST also be present [I-D.ietf-mmusic-sdp-source-attributes]).
RR may also send an RTCP APP packet that specifies the minimum
amount of data it requires from RS and optionally the maximum
amount of data it can receive from RS (Note that this APP packet
is usually sent in a compound RTCP packet that also includes the
NACK PLI message). This information is used by RS to prepare a
rapid synchronization that conforms with RR's buffer
requirements. The format of this APP packet is described in
Appendix A. As an alternative to the APP packet, a new RTCP
transport-layer feedback message [RFC4585] called Rapid Multicast
Synchronization Request (RMS-R) could also be defined. This
message may contain the buffer sizing information of RR in its
feedback control information field.
3. RS receives the NACK PLI and APP packets, and decides whether to
accept the rapid synchronization request or not. If RS accepts
the request, it sends an RTCP packet to RR that comprises fields
that can be used to describe the burst that RS will generate and
send, including the indication when RR should switch to the
multicast stream. This RTCP message is referred to as the Rapid
Multicast Synchronization Information (RMS-I). For the RMS-I
message, Appendix A defines an RTCP APP packet format and
Appendix B defines a new RTCP message. The RMS-I message may be
sent multiple times towards RR. Note that RS learns the IP
address and port information for RR from the RTCP NACK PLI or
RMS-R packet it received. (This description glosses over the NAT
details. Refer to Section 8 for a discussion of NAT-related
issues.)
If RS cannot provide a unicast rapid synchronization session, RS
VerSteeg, et al. Expires January 8, 2009 [Page 17]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
rejects the request and informs RR immediately via the RMS-I
message. If RR receives RMS-I indicating that the rapid
synchronization request has been denied, it abandons the rapid
synchronization attempt and immediately joins the RTP multicast
session by sending an IGMP Join message [RFC3376] to its upstream
multicast router for the new multicast session.
4. If RS accepts the rapid synchronization request, it transmits (in
addition to the RMS-I message) the unicast RTP burst data and any
additional RTCP APP message(s) that may contain key information
(TSRAP) that is not provided in the unicast RTP burst. The RTCP
RMS-I message is either sent prior to the data burst or during
the data burst, with the appropriate value settings in its
fields.
5. At the appropriate moment (as indicated or computed from the
burst parameters in the RTCP packet), RR sends an IGMP Join
message [RFC3376] to its upstream multicast router for the new
RTP multicast session.
6. RR starts receiving the multicast RTP flow.
7. If RS had not explicitly indicated the size of the unicast burst
in the RMS-I message, RR can be asked in the RMS-I message to
explicitly indicate to RS when multicast synchronization has been
completed which triggers RS to stop the unicast burst. To this
effect, a new RTCP message called Rapid Multicast Synchronization
Process Termination (RMS-T) is to be defined. This may be a new
transport-layer feedback RTCP message [RFC4585] that may be
transmitted more than once by RR for redundancy reasons.
Alternatively, an RTCP BYE message can be used to make RS stop
the unicast burst.
Note that when RR joins the multicast session, RR may receive the
same packet from both the multicast session and unicast burst. The
impact of this and measures that can be taken to minimize the impact
of receiving duplicate packets will be addressed in Section 6.4.
It is possible that RR may decide to switch to a new multicast
session while an earlier rapid synchronization request is still
pending or active. In that case, RR SHOULD cancel the pending/active
rapid synchronization operation before it sends a new request for the
new multicast session. To cancel the pending request and stop any
existing rapid synchronization operation, RR SHOULD send an RTCP BYE
packet for the unicast retransmission session. Upon receiving an
RTCP BYE packet, RS MUST terminate the rapid synchronization
operation, and cease transmitting any further packets of the
associated unicast burst. Note that in addition to the RTCP BYE
VerSteeg, et al. Expires January 8, 2009 [Page 18]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
packet in the unicast session, an RTCP BYE packet MUST also be sent
for the session associated with the multicast source stream if RR
already joined the multicast session.
Against the possibility of the RTCP BYE packet being lost and thus
failing to stop the rapid synchronization operation, RR MAY send
multiple BYE packets for the unicast session as long as it follows
the RTCP timer rules of [RFC3550].
6.3. Encoding of the Signaling Protocol
Editor's note: This section discusses the format of the control
packets that are exchanged to support rapid synchronization.
Currently, there are two proposals. These proposals are explained in
Appendix A and Appendix B. Based on the discussion in the WG, we
will adopt one of these proposals, or a hybrid of the two.
TBC.
6.4. Shaping the Burst
Editor's note: This section will discuss sizing of the buffers,
output buffer overload protection, output bandwidth management,
adjustment of burst rate and duration.
TBC.
6.5. Failure Cases
Editor's note: This section will discuss what happens if the request
for rapid synchronization gets lost, or rapid synchronization fails,
or when there are no available resources, etc.
TBC.
7. Session Description Protocol (SDP) Signaling
This section provides an SDP [RFC4566] example for enabling rapid
synchronization with RTP multicast sessions. The following example
uses the SDP grouping semantics [RFC3388], the RTP/AVPF profile
[RFC4585], the RTP retransmissions [RFC4588], the RTCP extensions for
SSM sessions with unicast feedback [I-D.ietf-avt-rtcpssm] and the
source-specific media attributes
[I-D.ietf-mmusic-sdp-source-attributes].
In the example, we have two primary source streams and two unicast
retransmission streams for each of these source streams. The source
VerSteeg, et al. Expires January 8, 2009 [Page 19]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
streams are multicast from a distribution source (with a source IP
address of 8.166.1.1) in different multicast groups. For each source
stream, a feedback target address (9.30.30.1) is also specified with
the 'rtcp' attribute. The receiver(s) can report missing packets on
the source stream to the feedback target and request retransmissions.
The parameter 'rtx-time' specifies the time in milliseconds (measured
from the time a packet was first sent) that the sender (in this case
the feedback target) keeps an RTP packet in its buffers available for
retransmission.
For the first source stream, only the conventional retransmission
support is enabled. For the second source stream, both the
conventional retransmission and rapid synchronization support is
enabled. This is achieved by the "a=rtcp-fb:98 nack pli" line. The
parameter 'pli' denotes a payload-specific feedback message and
stands for Picture Loss Indication [RFC4585].
When a receiver requires rapid synchronization for a new multicast
session it wants to join, it sends an RTCP NACK PLI message to the
feedback target. This RTCP packet has to have the SSRC of the
primary source session for which rapid synchronization is requested
for. However, since this receiver has not received any RTP packets
from this primary source session yet, the receiver MUST learn the
SSRC value from the 'ssrc' attribute of the media description
[I-D.ietf-avt-rtcpssm]. In addition to the SSRC value, the 'cname'
source attribute MUST also be present in the SDP description
[I-D.ietf-mmusic-sdp-source-attributes]. Note that listing the SSRC
values for the primary source sessions in the SDP file does not
create a problem in SSM sessions when an SSRC collision occurs. This
is because in SSM sessions, a receiver that observed an SSRC
collision with a media source MUST change its own SSRC
[I-D.ietf-avt-rtcpssm] by following the rules defined in [RFC3550].
A feedback target that receives a NACK PLI feedback message becomes
aware that the prediction chain at the receiver side has been broken
or does not exist any more. If the necessary conditions are
satisfied (as outlined in Section 7 of [RFC4585]) and available
resources exist, the feedback target MAY react to the NACK PLI
message by sending the key information and an intra update.
VerSteeg, et al. Expires January 8, 2009 [Page 20]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
v=0
o=ali 1122334455 1122334466 IN IP4 rtp.rocks.com
s=Rapid Synchronization Examples
t=0 0
a=group:FID 1 2
a=group:FID 3 4
a=rtcp-unicast:rsi
m=video 40000 RTP/AVPF 96
i=Primary Source Stream #1
c=IN IP4 224.1.1.1/255
a=source-filter: incl IN IP4 224.1.1.1 8.166.1.1
a=recvonly
a=rtpmap:96 MP2T/90000
a=rtcp:40001 IN IP4 9.30.30.1
a=rtcp-fb:96 nack
a=mid:1
m=video 40002 RTP/AVPF 97
i=Unicast Retransmission Stream #1 (Ret. Support Only)
c=IN IP4 9.30.30.1
a=recvonly
a=rtpmap:97 rtx/90000
a=rtcp:40003
a=fmtp:97 apt=96
a=fmtp:97 rtx-time=3000
a=mid:2
m=video 41000 RTP/AVPF 98
i=Primary Source Stream #2
c=IN IP4 224.1.1.2/255
a=source-filter: incl IN IP4 224.1.1.2 8.166.1.1
a=recvonly
a=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 9.30.30.1
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=ssrc:123321 cname:iptv-ch32@rtp.rocks.com
a=mid:3
m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream #2 (Ret. and Rapid Synch. Support)
c=IN IP4 9.30.30.1
a=recvonly
a=rtpmap:99 rtx/90000
a=rtcp:41003
a=fmtp:99 apt=98
a=fmtp:99 rtx-time=5000
a=mid:4
VerSteeg, et al. Expires January 8, 2009 [Page 21]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
8. NAT Considerations
TBC.
9. Open Source RTP Receiver Implementation
An open source RTP Receiver code that implements the functionalities
introduced in this document is available at the following URL:
http://www.cisco.com/en/US/docs/video/cds/cda/vqe/2_0/user/guide/
ch1_over.html
The code is also available at:
ftp://ftpeng.cisco.com/ftp/vqec/
10. Open Issues
o Do we need a new RTCP XR [RFC3611] block type for reporting the
performance of rapid synchronization?
o Do we need a new nack parameter for indicating rapid
synchronization support for non-video streams in an SDP? PLI is
mostly meaningful in video applications.
11. Security Considerations
TBC.
12. IANA Considerations
This document will register new RTCP packet types.
TBC.
13. Acknowledgments
TBC.
14. References
VerSteeg, et al. Expires January 8, 2009 [Page 22]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
14.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MPEG2TS] ITU-T H.222.0, "Generic Coding of Moving Pictures and
Associated Audio Information: Systems", May 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
[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.
[I-D.ietf-avt-rtcpssm]
Ott, J., "RTCP Extensions for Single-Source Multicast
Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17
(work in progress), January 2008.
[I-D.ietf-mmusic-sdp-source-attributes]
Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", draft-ietf-mmusic-sdp-source-attributes-01 (work
in progress), February 2008.
14.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[I-D.ietf-rmt-pi-norm-revised]
Adamson, B., "NACK-Oriented Reliable Multicast (NORM)
Protocol", draft-ietf-rmt-pi-norm-revised-06 (work in
progress), January 2008.
VerSteeg, et al. Expires January 8, 2009 [Page 23]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
[I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-01 (work in progress),
November 2007.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar,
"RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250,
January 1998.
[I-D.ott-avt-rtcp-guidelines]
Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP)", draft-ott-avt-rtcp-guidelines-01
(work in progress), June 2008.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003.
Appendix A. Protocol Encoding Option #A
[RFC3550] specifies the format of the RTCP APP packets as depicted in
Figure 6. In an RTCP APP packet, the payload type MUST be set to
204. The Subtype field is used to allow a set of APP packets to be
defined under one unique name or for any application-dependent data.
The Name field is chosen by the person defining the APP packets and
it MUST be unique among the APP packets the intended application
might receive. The Application-dependent data field contains the
information (at a length of in multiples of 32 bits) to be
interpreted by the intended application (not RTP itself). [RFC3550]
specifies that RTP receivers SHOULD ignore the APP packets with
unrecognized names.
VerSteeg, et al. Expires January 8, 2009 [Page 24]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Subtype | PT=APP=204 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Application-dependent data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of an RTCP APP packet
Section 6.7 of [RFC3550] and [I-D.ott-avt-rtcp-guidelines] state that
RTCP APP packets are intended for experimental use and they are not
appropriate to be registered in a standards document. Thus, as part
of the standardization process of this specification, we are planning
to convert the APP packets into standardized RTCP packet types and
register them with IANA. This will promote interoperability among
different implementations.
The data is encoded in the Application-dependent data field by using
Type/Length/Value (TLV) elements.
o Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element.
o Length: A two-octet field that indicates the length of the Value
field.
o Value: Variable sized set of octets that contains the specific
value for the parameter.
Note that all multi-octet values are in network-byte order.
The following TLV elements are defined in this document:
A.1. Padding
This type has no Length or Value fields. It is to pad the
Application-dependent data field to a multiple of 32-bit words
[RFC3550].
VerSteeg, et al. Expires January 8, 2009 [Page 25]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
Type Length Value
iana_tlv1 - -
A.2. RTP Sequence Number for the First Rapid Synchronization Packet
This is the RTP sequence number of the first packet that will be sent
as part of the rapid synchronization. This allows RR to know if one
or more packets are dropped at the beginning of rapid
synchronization.
Type Length Value
iana_tlv2 4 32-bit extended RTP sequence number
32-bit extended RTP sequence number is constructed by putting the 16-
bit RTP sequence number in the lower two bytes and octet 0's in the
higher two bytes.
A.3. Earliest IGMP Join Time
This is time difference (in RTP clock ticks) between the start of
rapid synchronization and the earliest time instant when RR could
join the new multicast session.
Type Length Value
iana_tlv3 4 32-bit delta time in RTP clock ticks
A.4. Rapid Synchronization End Time
This is time difference (in RTP clock ticks) between the end of the
first packet sent in rapid synchronization and the time instant when
rapid synchronization will end.
Type Length Value
iana_tlv4 4 32-bit delta time in RTP clock ticks
A.5. TSRAP Data
Description.
Type Length Value
iana_tlv5 N Encoded TSRAP data
Editor's note: This section should define the TLV elements for the
TSRAP data.
VerSteeg, et al. Expires January 8, 2009 [Page 26]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
A.6. Actual Rapid Synchronization Fill
This is the amount of backfill that RR can expect in its buffer as a
result of the rapid synchronization (in ms).
Type Length Value
iana_tlv6 4 Amount of rapid synchronization fill in ms
A.7. Join-Time Rapid Synchronization Fill
This is the amount of backfill that RR can expect in its buffer as a
result of the rapid synchronization at the time of the earliest IGMP
Join (in ms).
Type Length Value
iana_tlv7 4 Amount of rapid synchronization fill at IGMP Join in ms
Appendix B. Protocol Encoding Option #B
B.1. RMS-R RTCP Message Format
This is an RTCP transport-layer feedback message [RFC4585].
The fields are set as follows:
FMT field: 2
FCI field:
4-byte field: Amount of rapid synchronization fill in milliseconds.
B.2. RMS-I RTCP Message Format
This is similar to the RTCP transport-layer feedback message
[RFC4585] but with a new payload type.
FCI comprises:
2-byte field: RTP sequence number for the first rapid
synchronization packet.
4-byte field: Earliest IGMP join time. All zeroes means not
specified.
4-byte field: Rapid synchronization end time. All zeroes means not
specified.
VerSteeg, et al. Expires January 8, 2009 [Page 27]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
1-byte field: IGMP join time now. This can only have value 0 or 1;
1 = time to join multicast is now. If 1, then previous 2 fields MUST
be all zeroes.
1-byte field: RS response. This can only have value 0 or 1 or 2; 0
= RS will not service rapid synchronization request. 1 = RS services
rapid synchronization request; RR MUST NOT issue RMS-T message when
multicast is received. 2 = RS services rapid synchronization request;
RR MUST issue RMS-T message when multicast is received.
The RMS-I message may be sent multiple times at the start or prior to
the RTP unicast burst, or during the RTP unicast burst.
B.3. RMS-T RTCP Message Format
FMT field: 3
FCI field:
2-byte packet identifier field: Contains the sequence number of the
first received RTP packet of the multicast stream.
Authors' Addresses
Bill Ver Steeg
Cisco Systems
5030 Sugarloaf Parkway
Lawrenceville, GA 30044
USA
Email: billvs@cisco.com
Ali Begen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: abegen@cisco.com
VerSteeg, et al. Expires January 8, 2009 [Page 28]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
Tom Van Caenegem
Alcatel-Lucent Bell
Copernicuslaan 50
Antwerpen, 2018
Belgium
Email: Tom.Van_Caenegem@alcatel-lucent.be
VerSteeg, et al. Expires January 8, 2009 [Page 29]
Internet-Draft Rapid Synchronization for RTP Flows July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
VerSteeg, et al. Expires January 8, 2009 [Page 30]