AVT A. Begen
Internet-Draft Cisco Systems
Intended status: Standards Track March 4, 2009
Expires: September 5, 2009
RTP Payload Format for MPEG2-TS Preamble
draft-begen-avt-rtp-mpeg2ts-preamble-00
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 5, 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.
Begen Expires September 5, 2009 [Page 1]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
Abstract
Demultiplexing and decoding an MPEG2 Transport Stream (MPEG2-TS)
requires the knowledge of specific information about the transport
stream, which we refer to as the MPEG2-TS Preamble. While this
information is spread over different locations throughout the
transport stream and can be eventually assembled after some time a
receiver started receiving the MPEG2-TS, the time it takes to
retrieve all this information (especially in multicast environments)
may be long. Instead, having this information readily available as a
Preamble and sending the Preamble to a receiver that will shortly
start receiving the transport stream will virtually eliminate the
waiting time and let the receiver start processing/decoding the
MPEG2-TS sooner. In this document, we give an overview of the
MPEG2-TS and the delay components in video systems, and motivate the
need for constructing and using the MPEG2-TS Preamble for rapidly
synchronizing with the source stream in RTP multicast sessions. We
also define and register the RTP payload format for the MPEG2-TS
Preamble.
Begen Expires September 5, 2009 [Page 2]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6
3. Elements of Delay in Video Systems . . . . . . . . . . . . . . 7
3.1. Overview of MPEG-2 Transport Streams . . . . . . . . . . . 7
3.2. Key Information Latency in Video Applications . . . . . . 8
3.2.1. PSI (PAT/CAT/PMT) Acquisition Delay . . . . . . . . . 8
3.2.2. Random Access Point Acquisition Delay . . . . . . . . 9
3.3. Buffering Delays in Video Applications . . . . . . . . . . 10
3.3.1. Network-Related Buffering Delays . . . . . . . . . . . 10
3.3.2. Application-Related Buffering Delays . . . . . . . . . 11
4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 14
5.1. Media Type Registration . . . . . . . . . . . . . . . . . 14
5.1.1. Registration of audio/mpeg2-ts-preamble . . . . . . . 14
5.1.2. Registration of video/mpeg2-ts-preamble . . . . . . . 14
5.1.3. Registration of text/mpeg2-ts-preamble . . . . . . . . 14
5.1.4. Registration of application/mpeg2-ts-preamble . . . . 14
5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 14
5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 15
5.2.2. Declarative Considerations . . . . . . . . . . . . . . 15
6. Session Description Protocol (SDP) Signaling . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Begen Expires September 5, 2009 [Page 3]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
1. Introduction
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.
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 audio/video encoding standards as well.
Due to the inherent design of MPEG2-TS, a receiver must first acquire
certain information before demultiplexing and decoding an incoming
MPEG2-TS. As will be explained in Section 3.1, this information
resides in the transport stream. However, it is often not contiguous
and is usually dispersed over a large period. Thus, a receiver
starting to receive an MPEG2-TS at a random location will have to
wait until the whole required information shows up in the received
data. In multicast applications, since the joining receivers do not
have any control over what point in the flow is currently being
transmitted, their waiting times will vary. This problem has been
identified and examined in detail in
[I-D.versteeg-avt-rapid-synchronization-for-rtp], where the time lag
before a receiver can usefully consume the multicast data is referred
to as the Synchronization Delay. Section 3 provides an overview of
the delay components in video systems that contribute to the
synchronization delay.
[I-D.versteeg-avt-rapid-synchronization-for-rtp] refers to the
information that must first be acquired before starting to process
any data sent in the multicast session as the Key Information. In
this document, we refer to the subset of the key information that is
related to the MPEG2-TS as the MPEG2-TS Preamble.
For multicast applications running over RTP,
[I-D.versteeg-avt-rapid-synchronization-for-rtp] proposes an approach
where an auxiliary unicast RTP session is established between a
retransmission server and the joining RTP receiver. Over this
unicast RTP session, the retransmission server provides the key
information the RTP receiver needs to rapidly synchronize with the
multicast session. If the source stream in the RTP multicast session
is carrying an MPEG2-TS, the key information will comprise the
MPEG2-TS Preamble as well. For its proper transmission from the
retransmission server to the joining RTP receiver, a new RTP payload
Begen Expires September 5, 2009 [Page 4]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
format has to be defined for the MPEG2-TS Preamble. This document
defines and registers this payload format.
Begen Expires September 5, 2009 [Page 5]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
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].
Begen Expires September 5, 2009 [Page 6]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
3. 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-TS as the motivating use
case.
3.1. Overview of MPEG-2 Transport Streams
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
Begen Expires September 5, 2009 [Page 7]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
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.
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
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.
3.2. Key Information Latency in Video Applications
We classify the key information latency into two categories.
3.2.1. PSI (PAT/CAT/PMT) Acquisition Delay
As we discussed in Section 3.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
Begen Expires September 5, 2009 [Page 8]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
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.
3.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
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
approximately equal to 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
Begen Expires September 5, 2009 [Page 9]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
GoPs) before decoding can commence. In an Open GOP, a frame in one
GoP may refer to a frame in a previous GoP. 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.
3.3. Buffering Delays in Video Applications
We classify the buffering delays into two categories.
3.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 multicast 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.
Begen Expires September 5, 2009 [Page 10]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
3.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.
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 a few hundreds of
milliseconds to a few 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.
Begen Expires September 5, 2009 [Page 11]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
4. Packet Format
This section defines the MPEG2-TS Preamble packet format.
The RTP header is formatted according to [RFC3550] with some further
clarifications listed below:
o Marker (M) Bit: This bit MAY be used to indicate the last packet
carrying the MPEG2-TS Preamble information if there are more than
one such packets.
Editor's note: This should be discussed.
o Payload Type: The (dynamic) payload type for the MPEG2-TS
Preamble packets is determined through out-of-band means. Note
that this document registers a new payload format for the MPEG2-TS
Preamble packets (Refer to Section 5 for details). According to
[RFC3550], an RTP receiver that cannot recognize a payload type
must discard it. This provides backward compatibility.
o Sequence Number (SN): The sequence number has the standard
definition. It MUST be one higher than the sequence number in the
previously transmitted MPEG2-TS Preamble packet. The initial
value of the sequence number SHOULD be random (unpredictable)
[RFC3550].
o Timestamp (TS): The timestamp SHALL be set to a time
corresponding to the packet's transmission time.
o Synchronization Source (SSRC): Per [RFC3550], the SSRC value
SHOULD be chosen randomly with collision detection. However,
since the RTP session carrying MPEG2-TS Preamble has a short
lifetime, using the same SSRC value with the source RTP session
carrying the MPEG2-TS may also make sense.
Editor's note: This issue should be discussed.
The payload has the structure depicted in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TBC :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the MPEG2-TS Preamble payload
Begen Expires September 5, 2009 [Page 12]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
Editor's note: The format of this message is TBD.
Begen Expires September 5, 2009 [Page 13]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
5. Payload Format Parameters
This section provides the media subtype registration for the MPEG2-TS
Preamble.
5.1. Media Type Registration
This registration is done using the template defined in [RFC4288] and
following the guidance provided in [RFC3555].
5.1.1. Registration of audio/mpeg2-ts-preamble
TBC.
5.1.2. Registration of video/mpeg2-ts-preamble
TBC.
5.1.3. Registration of text/mpeg2-ts-preamble
TBC.
5.1.4. Registration of application/mpeg2-ts-preamble
TBC.
5.2. Mapping to SDP Parameters
Applications that are using RTP transport commonly use Session
Description Protocol (SDP) [RFC4566] to describe their RTP sessions.
The information that is used to specify the media types in an RTP
session has specific mappings to the fields in an SDP description.
In this section, we provide these mappings for the media subtype
registered by this document ("mpeg2-ts-preamble"). Note that if an
application does not use SDP to describe the RTP sessions, an
appropriate mapping must be defined and used to specify the media
types and their parameters for the control/description protocol
employed by the application.
The mapping of the media type specification for "mpeg2-ts-preamble"
and its parameters in SDP is as follows:
o The media type (e.g., "application") goes into the "m=" line as
the media name.
o The media subtype ("mpeg2-ts-preamble") goes into the "a=rtpmap"
line as the encoding name. The RTP clock rate parameter ("rate")
also goes into the "a=rtpmap" line as the clock rate.
Begen Expires September 5, 2009 [Page 14]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
o The remaining required payload-format-specific parameters go into
the "a=fmtp" line by copying them directly from the media type
string as a semicolon-separated list of parameter=value pairs.
SDP examples are provided in Section 6.
5.2.1. Offer-Answer Model Considerations
TBC.
5.2.2. Declarative Considerations
TBC.
Begen Expires September 5, 2009 [Page 15]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
6. Session Description Protocol (SDP) Signaling
This section provides an SDP [RFC4566] example.
TBC.
Begen Expires September 5, 2009 [Page 16]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
7. Security Considerations
TBC.
Begen Expires September 5, 2009 [Page 17]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
8. IANA Considerations
New media subtypes are subject to IANA registration. For the
registration of the payload format and its parameters introduced in
this document, refer to Section 5.
Begen Expires September 5, 2009 [Page 18]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
9. Acknowledgments
TBC.
Begen Expires September 5, 2009 [Page 19]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
10. References
10.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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
10.2. Informative References
[MPEG2TS] ITU-T H.222.0, "Generic Coding of Moving Pictures and
Associated Audio Information: Systems", May 2006.
[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.
[RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar,
"RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250,
January 1998.
[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.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[I-D.ietf-rmt-pi-norm-revised]
Adamson, B., Bormann, C., London, U., and J. Macker,
"NACK-Oriented Reliable Multicast Protocol",
draft-ietf-rmt-pi-norm-revised-08 (work in progress),
December 2008.
Begen Expires September 5, 2009 [Page 20]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
[I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-03 (work in progress),
October 2008.
Begen Expires September 5, 2009 [Page 21]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009
Author's Address
Ali Begen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: abegen@cisco.com
Begen Expires September 5, 2009 [Page 22]