Internet Draft A. Li
draft-ietf-avt-ulp-07.txt F. Liu
November 4, 2002 J. Villasenor
Expires: May 4, 2003 Univ. of Calif., LA
J.H. Park
D.S. Park
Y.L. Lee
Samsung Electronics
J. Rosenberg
DynamicSoft
H. Shulzrinne
Columbia University
An RTP Payload Format for Generic FEC with Uneven Level Protection
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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
anytime. 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.
ABSTRACT
This document specifies a payload format for generic forward error
correction to achieve uneven level protection (ULP) for media data
encapsulated in RTP. It is based on the same exclusive-or (parity)
operation as in RFC 2733 [1], but it generalized and included the
algorithms of that RFC. This draft will obsolete RFC 2733 and RFC
3009. The payload format described in this draft allows end systems
to apply protection using arbitrary protection lengths and levels, in
addition to using arbitrary protection group sizes. It also enables
both complete recovery or partial recovery of the critical payload
and RTP header fields depending on the packet loss situation. This
Adam H. Li, et al. [Page 1]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
scheme is completely backward compatible with non-FEC capable hosts.
Those receivers that do not know about ULP forward error correction
can simply ignore the extensions.
Table of Contents
1. Introduction ................................................... 3
1.1. General Overview ............................................. 3
1.2. Application Statement ........................................ 4
2. Terminology .................................................... 6
3. Basic Operation ................................................ 6
4. RTP Media Packet Structure ..................................... 7
5. ULP FEC Packet Structure ....................................... 8
5.1. RTP Header of ULP FEC Packets ................................ 8
5.2. FEC Header ................................................... 9
5.3. ULP Level Header ............................................. 9
6. Protection Operation .......................................... 10
7. Recovery Procedure ............................................ 11
8. Examples ...................................................... 12
8.1. An Example With Only Protection Level 0 ..................... 12
8.2. An Example That Has Identical Protection as in RFC 2733 ..... 13
8.3. An Example With Two Protection Levels (0 and 1) ............. 14
9. Security and Congestion Considerations ........................ 18
10. Indication ULP FEC Usage in SDP .............................. 19
10.1. ULP FEC as a Separate Stream ............................... 19
10.2. Use with Redundant Encoding ................................ 20
10.3. Usage with RTSP ............................................ 21
11. MIME Registrations ........................................... 21
11.1. Registration of audio/ulpfec ............................... 21
11.2. Registration of video/ulpfec ............................... 22
11.3. Registration of text/ulpfec ................................ 23
11.4. Registration of application/ulpfec ......................... 25
12. Acknowledgements ............................................. 26
13. Bibliography ................................................. 26
14. Authors' Address ............................................. 27
Adam H. Li, et al. [Page 2]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
1. Introduction
1.1. General Overview
Because of the real-time nature of many applications, they have more
stringent delay requirements than normal data transmissions. As a
result, retransmission of the lost packets is generally not a valid
option for such applications. In these cases, a better method to
attempt recovery of information from packet loss is through Forward
Error Correction (FEC). FEC has been one of the main methods used to
protect against packet loss over packet switched networks [2].
In many cases, the bandwidth of the network connections is a very
limited resource. However, most of traditional FEC schemes are not
designed for optimal utilization of the limited bandwidth resource. A
more efficient way to utilize the limited bandwidth would be to use
unequal error protection to provide different levels of protection
for different parts of the data stream which vary in importance.
These unequal error protection schemes can make more efficient use of
the bandwidth to provide better overall protection of the data stream
against the loss. Proper protocol support is essential for realizing
these unequal error protection mechanisms. However, the application
of most of the unequal error protection schemes requires the
knowledge of the importance for different parts of the data stream.
Most of such schemes are designed for a particular type of media
according to the structure of the media protected, and as a result,
are not generic.
In many multimedia streams, the more important parts of the data are
always at the beginning of the data packet. This is the common
practice for most codecs since the beginning of the packet is closer
to the re-synchronization marker at the header and thus is more
likely to be correctly decoded. Also, almost all media formats have
the frame headers at the beginning of the packet, which is the most
vital part of the packet.
For video streams, most modern formats have optional data
partitioning modes to improve error resilience in which the video
macroblock header data, the motion vector data, and DCT coefficient
data are separated into their individual partitions. In ITU-T H.263
version 3, there is the optional data partitioned syntax of Annex V.
In MPEG-4 Visual Simple Profile, there is the optional data
partitioning mode. When these modes are enabled, the video macroblock
(MB) header and motion vector partitions (which are much more
important to the quality of the video reconstruction) are transmitted
in the partition(s) at the beginning of the video packet while
residue DCT coefficient partitions (which are less important) are
transmitted in the partition close to the end of the packet. Because
the data is arranged in descending order of importance, it would be
beneficial to provide more protection to the beginning part of the
packet in transmission.
Adam H. Li, et al. [Page 3]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
For audio streams, the bitstreams generated by many of the new audio
codecs also contain data with different classes of importance. These
different classes are then transmitted in order of descending
importance. Thus, applying more protection to the beginning of the
packet would also be beneficial in these cases. Even for uniform-
significance audio streams, special stretching techniques can be
applied to the partially recovered audio data packets. In cases where
audio redundancy coding is used, more protection should be applied to
the original data located in the first half of the packet. The rest
of the packet containing the redundant copies of the data, does not
need the same level of protection.
It is clear that audio/video applications would generally benefit
from an unequal error protection scheme that gives more protection to
the beginning part of each packet. This document defines a payload
format for RTP [3] that allows for generic forward error correction
with unequal error protection for real-time media. The payload data
are protected by one or more protection levels. Lower protection
levels provide greater protection by using smaller group sizes
(compared to higher protection levels) for generating the FEC packet.
The data that are closer to the beginning of the packet are protected
by lower protection levels because these data are in general more
important, and they tend to carry more information than the data
further behind in the packet.
This document specifies an RTP payload format that extends the
generic forward error correction schemes as specified in RFC 2733
[1]. This extension enables different levels of protection to be
applied to different parts of the packet. While the whole packet can
always be treated as a single level (same as in RFC 2733), this
multiple Uneven Level Protection (ULP) can potentially achieve more
efficient protection of the media payload.
1.2. Application Statement
The ULP algorithm specified in this document is designed to deal with
any type of packet loss occurring in transmission, just as does RFC
2733, which it extends. The ULP algorithm is designed to be fully
interoperable between the hosts that are ULP-capable and those that
are not. Since the media payload is not altered and the protection is
sent as additional information, the receivers that are unaware of ULP
can simply ignore the additional ULP information and process the main
media payload. This interoperability is particularly important for
backward compatibility with existing hosts, and also in the scenario
where many different hosts need to communicate with each other at the
same time, such as during multicast.
The ULP algorithm is also a generic protection algorithm with the
following features: (1) it is independent of the nature of the media
being protected, whether that media is audio, video, or otherwise,
(2) it is flexible enough to support a wide variety of FEC mechanisms
and settings, (3) it is designed for adaptivity, so that the FEC
parameters can be modified easily without resorting to out of band
Adam H. Li, et al. [Page 4]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
signaling, and (4) it supports a number of different mechanisms for
transporting the FEC packets.
An Unequal Erasure Protection (UXP) scheme has also been proposed in
the AVT Working Group in "An RTP Payload Format for Erasure-Resilient
Transmission of Progressive Multimedia Streams". The UXP scheme
applies unequal error protection to the media payloads by
interleaving the payload stream to be protected with the additional
redundancy information obtained using Reed-Solomon operations.
By altering the structure of the protected media payload, the UXP
scheme sacrifices the backward compatibility with terminals that do
not support UXP. This makes it more difficult to apply UXP when
backward compatibility is desired. In the case of ULP, however, the
media payload remains un-altered and can always be used by the
terminals. The extra protection can simply be ignored if the
receiving terminals do not support ULP.
At the same time, also because the structure of the media payload is
altered in UXP, UXP offers the unique ability to change packet size
independent of the original media payload structure and protection
applied, and is only subject to the protocol overhead constraint.
This property is useful in scenarios when altering the packet size of
the media at transport level is desired.
Because of the interleaving used in UXP, delays will be introduced at
both the encoding and decoding sides. For UXP, all data within a
transmission block need to arrive before encoding can begin, and a
reasonable number of packets must be received before a transmission
block can be decoded. The ULP scheme introduces little delay at the
encoding side. On the decoding side, correctly received packets can
be delivered immediately. Delay is only introduced in ULP when packet
losses occur.
Because UXP is an interleaved scheme, the un-recoverable errors
occurring in data protected by UXP usually result in a number of
corrupted holes in the payload stream. In ULP, on the other hand, the
unrecoverable errors due to packet loss in the bitstream usually
appear as contiguous missing pieces at the end of the packets.
Depending on the encoding of the media payload stream, many
applications may find it easier to parse and extract data from a
packet with only a contiguous piece missing at the end than a packet
with multiple corrupted holes, especially when the holes are not
coincident with the independently decodable fragment boundaries.
The exclusive-or (XOR) parity check operation used by ULP is simpler
and faster than the more complex operations required by Reed-Solomon
codes. This makes ULP more suitable for applications where
computational cost is a constraint.
As discussed above, both the ULP and the UXP schemes apply unequal
error protection to the RTP media stream, but each uses a different
Adam H. Li, et al. [Page 5]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
technique. Both schemes have their own unique characteristics, and
each can be applied to scenarios with different requirements.
2. Terminology
The following terms are used throughout this document:
Media Payload: The raw, un-protected user data that are transmitted
from the sender. The media payload is placed inside of an RTP packet.
Media Header: The RTP header for the packet containing the media
payload.
Media Packet: The combination of a media payload and media header is
called a media packet.
ULP FEC Packet: The uneven level protection FEC algorithms at the
transmitter take the media packets as an input. They output both the
media packets that they are passed, and newly generated packets
called ULP FEC packets, which contain redundant media data used for
error correction. The ULP FEC packets are formatted according to the
rules specified in this document.
FEC Header: The header information contained in an FEC packet.
FEC Payload: The payload of an FEC packet.
Associated: A ULP FEC packet is said to be "associated" with one or
more media packets when those media packets are used to generate the
ULP FEC packet (by use of the exclusive-or operation).
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 RFC 2119 [4].
3. Basic Operation
The payload format described here is used whenever the sender in an
RTP session would like to protect the media stream it is sending with
uneven level protection (ULP) FEC. The ULP FEC supported by the
format is based on the same simple exclusive-or (XOR) parities used
in RFC 2733 [1]. The sender takes the packets from the media stream
requiring protection and determines the protection levels for these
packets and the protection length for each level. The data of each
level are grouped as described below in Section 6 to provide each
level with a different degree of error resilience. An XOR operation
is applied across the payload to generate the ULP FEC information for
each level. The lower protection levels (which provide higher
protection, or greater error resilience) are applied to the data that
are closer to the beginning of the packet to ensure more protection.
The result based on the procedures defined here is an RTP packet
Adam H. Li, et al. [Page 6]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
containing ULP FEC information. This packet can be used at the
receiver to recover the packets or parts of the packets used to
generate the ULP FEC packet. By using uneven error protection, this
scheme can make more efficient use of the channel bandwidth, and
provide more efficient error resilience for transmission over error
prone channels.
The payload format contains information that allows the sender to
tell the receiver exactly which media packets are protected by the
ULP FEC packet, and the protection levels and lengths for each of the
levels. Specifically, each ULP FEC packet contains a protection
length L(k) and an offset mask m(k) for each protection level k. If
the bit i in the mask m(k) is set to 1, then media packet number N +
i is protected by this ULP FEC packet at level k. N is called the
sequence number base, and is sent in the ULP FEC packet as well. The
amount of data that are protected at level k is indicated by L(k).
The protection length, offset mask and payload type are sufficient to
signal ULP forward error correction schemes based on arbitrarily
defined parity protection with little overhead. A set of rules is
described in Section 5.3 that defines how the mask should be set for
different protection levels, with examples in Section 8.
This document also describes procedures on transmitting all the
protection operation parameters in-band. This allows the sender great
flexibility; the sender can adapt the code to current network
conditions and be certain the receivers can still make use of the ULP
FEC for recovery.
At the receiver, the ULP FEC and original media are received. If no
media packets are lost, the ULP FEC can be ignored. In the event of a
loss, the ULP FEC packets can be combined with other received media
and ULP FEC packets to recover all or part of the missing media
packets. When ULP is used, the decoder is expected to receive and
handle partially recovered packets with contiguous pieces missing at
the end of the packets.
RTP packets that contain data formatted according to this
specification (i.e., ULP FEC packets) use dynamic RTP payload types.
4. RTP Media Packet Structure
The formatting of the media packets is unaffected by ULP FEC. If the
ULP FEC is sent as a separate stream, the media packets are sent as
if there was no FEC.
This scheme leads to a very efficient encoding. When little or no ULP
FEC is used, the transmitted stream contains mostly media packets.
The overhead for using the ULP FEC scheme is only present in ULP FEC
packets, and can be easily monitored and adjusted by tracking the
amount of FEC in use.
Adam H. Li, et al. [Page 7]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
5. ULP FEC Packet Structure
A ULP FEC packet is constructed by placing an FEC header and the ULP
FEC payload into the RTP payload, as shown in Figure 1:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ULP FEC Header (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ULP Level 0 Header (5 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ULP Level 0 Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ULP Level 1 Header (5 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ULP Level 1 Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cont. |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ULP FEC Packet Structure
5.1. RTP Header of ULP FEC Packets
The version field is set to 2. The extension bit is set to 0. The
market bit is set to 0. The padding bit, the CC field, and the CSRC
list are set according to RFC 1889[3].
The SSRC value will generally be the same as the SSRC value of the
media stream it protects, though it MAY be different if the ULP FEC
stream is being demultiplexed via the SSRC value.
The sequence number has the standard definition: it MUST be one
higher than the sequence number in the previously transmitted ULP FEC
packet. The timestamp MUST be set to the value of the media RTP clock
at the instant the ULP FEC packet is transmitted. Thus, the TS value
in ULP FEC packets is always monotonically increasing.
The payload type for the ULP FEC packet is determined through
dynamic, out of band means. According to RFC 1889 [3], RTP
participants that cannot recognize a payload type must discard it.
This provides backwards compatibility. The ULP FEC mechanisms can
then be used in a multicast group with mixed ULP-FEC-capable and ULP-
FEC-incapable receivers. In such a case, the ULP stream will have a
payload type which is not recognized by the ULP-FEC-incapable
receivers, and will thus be disregarded.
Adam H. Li, et al. [Page 8]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
5.2. FEC Header
This header is 2-octet long. The format of the header is shown in
Figure 2 and consists of an SN base field and the length recovery
field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SN base | length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: FEC Header Format
The SN base field MUST be set to the minimum sequence number of those
media packets protected by FEC. This allows for the FEC operation to
extend over any string of at most 24 packets.
The length recovery field is used to determine the length of any
recovered packets. It is computed via the protection operation
applied to the unsigned network-ordered 16 bit representation of the
sums of the lengths (in bytes) of the media payload, CSRC list,
extension and padding of media packets associated with this FEC
packet (in other words, the CSRC list, extension, and padding, if
present, are "counted" as part of the payload). This allows the FEC
procedure to be applied even when the lengths of the media packets
are not identical. For example, assume an FEC packet is being
generated by xor'ing two media packets together. The length of the
two media packets are 3 (0b011) and 5 (0b101) bytes, respectively.
The length recovery field is then encoded as 0b011 xor 0b101 = 0b110.
5.3. ULP Level Header
The ULP Level Header is 5-octet long. The formats of the headers are
shown in Figure 3 and consist of a Protection Length field and a mask
field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection Length | mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask (cont.) |
+-+-+-+-+-+-+-+-+
Figure 3: ULP Level Header Format
The Protection Length field is 16 bits. It indicates the protection
length provided by the ULP FEC for the current protection level
Adam H. Li, et al. [Page 9]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
(i.e., the payload length for the current protection level after the
header).
The mask field is 24 bits. If bit i in the mask is set to 1, then the
media packet with sequence number N + i is associated with this ULP
FEC packet of current protection level, where N is the SN Base field
in the ULP FEC packet header. The least significant bit corresponds
to i=0, and the most significant to i=23.
The SN base field in the FEC header MUST be set to the minimum
sequence number of those media packets protected by ULP FEC. This
allows for the ULP FEC operation to extend over any string of at most
24 packets.
The setting of mask field shall follow the following rules:
a. A media packet can only be protected at each protection level
once.
b. For a media packet to be protected at level p, it must also be
protect at level p-1.
c. If an ULP FEC packet contains protection at level p, it must
also contain protection at level p-1.
The payload of the ULP FEC packet of each level is the protection
operation applied to the concatenation of the CSRC list, RTP
extension, media payload, and padding of the media packets associated
with the ULP FEC packet. Details are described in the next section on
the protection operation.
6. Protection Operation
The protection operation involves copying the payload, padding it
with zeroes, and computing the parity (XOR) across the resulting bit
strings.
The following procedure MAY be followed for the protection operation.
Other procedures MAY be used, but the end result MUST be identical to
the one described here.
Starting from the first octet of the media RTP packet header for the
Level 0, the protected data of the corresponding packets of length of
Protection Length 0 are copied into the bit strings. If the packet
ends before the Protection Length of the current level is reached,
the string is padded to that length. Any value may be used for the
padding. The padding MUST be added at the end of the bit string.
The parity operation is applied across the protected data of the
corresponding packets. The generated ULP FEC bit of that level is
then appended to the payload of the ULP FEC packet.
Adam H. Li, et al. [Page 10]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
This operation is repeated for all the assigned protection levels.
7. Recovery Procedures
The ULP FEC packets allow end systems to recover from the loss of
media packets. This section describes the procedure for performing
this recovery.
Recovery requires two distinct operations. The first determines which
packets (media and FEC) must be combined in order to recover a
missing packet. Once this is done, the second step is to actually
reconstruct the data. The second step MUST be performed as described
below. The first step MAY be based on any algorithm chosen by the
implementer. Different algorithms result in a tradeoff between
complexity and the ability to recover missing packets, if possible.
Let T be the list of packets (ULP FEC and media) which can be
combined to recover some media packet xi. The procedure is as
follows:
1. For the media packet in T, get the protection length of that
level. Copy the data of the that protection level (data of the
length read following the level header) to the bit strings.
2. If any of the bit strings generated from the media packets are
shorter than the Protection Length of the current level, pad
them to that length. The padding MUST be added at the end of
the bit string, and MUST be of the same value as used in the
process of generating the ULP FEC packets.
3. Perform the exclusive-or (parity) operation across the bit
strings, resulting in a recovery bit string.
The data protected at lower protection level is almost always
recoverable if the higher level protected data is recoverable. This
procedure (together with the procedure for the lower protection
levels) will usually recover both the header and payload of an RTP
packet up to the Protection Length of the current level.
Adam H. Li, et al. [Page 11]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
8. Examples
Consider 4 media packets to be sent, A, B, C and D, from SSRC 2.
Their sequence numbers are 8, 9, 10 and 11, respectively, and have
timestamps of 3, 5, 7 and 9, respectively. Packet A and C uses
payload type 11, and packet B and D uses payload type 18. Packet A is
has 200 bytes of payload, packet B 140, packet C 100 and packet D
340. Packet A and C have their marker bit set.
8.1. An Example With Only Protection Level 0
Suppose we want to protect the data of length L0 = 70 bytes of them
at the beginning of these packets, as illustrated in Figure 4 below.
+------:------------+
Packet A | : |
+------:------+-----+
Packet B | : |
+------:--+---+
Packet C | : |
+------:--+-----------------------+
Packet D | : |
+------:--------------------------+
:
+------+
Packet FEC | |
+------+
: :
:<-L0->:
Figure 4 ULP FEC scheme with only protection level 0
An ULP FEC packet is generated from these four packets. We assume
that payload type 127 is used to indicate an FEC packet. The
resulting RTP header is shown in Figure 5.
The FEC header in the ULP FEC packet is shown in Figure 6.
The ULP header for level 0 in the ULP FEC packet is shown in Figure
7.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|0|0|0 0 0 0|0|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adam H. Li, et al. [Page 12]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
Version: 2
Padding: 0
Extension: 0
Marker: 0
PT: 127
SN: 1
TS: 9
SSRC: 2
Figure 5: RTP Header of ULP FEC for Packets A, B, C and D (one level)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 1 0 1 1 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SN base: 8 [min(8,9,10,11)]
len. rec.: 372 [200 XOR 140 XOR 100 XOR 340]
E: 1 [ULP FEC]
PT rec.: 0 [11 XOR 18 XOR 11 XOR 18]
mask: 15 [with Packet 8, 9, 10, and 11 marked]
TS rec.: 8 [3 XOR 5 XOR 7 XOR 9]
Figure 6: FEC Header of ULP Packet (one level)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L0: 70
The payload length for level 0 is 70 bytes.
Figure 7: ULP Level Header (Level 0)
8.2. An Example That Has Identical Protection as in RFC 2733
We can choose to extend the level 0 protection to cover the whole
length of the packets (as shown in Figure 8). This gives almost
identical protection as provided in RFC 2733. Please note that when
using ULP this way, each ULP FEC packet will use two more bytes (for
the level 0 payload length field) than that of RFC 2733 - a small
price to pay for the added flexbility.
Adam H. Li, et al. [Page 13]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
+-------------------+ :
Packet A | | :
+-------------+-----+ :
Packet B | | :
+---------+---+ :
Packet C | | :
+---------+-----------------------+
Packet D | |
+---------------------------------+
:
+---------------------------------+
Packet FEC | |
+---------------------------------+
: :
:<------------- L0 -------------->:
Figure 8 ULP FEC scheme with only protection level 0
The resulting ULP FEC packet will have the RTP header same as shown
in Figure 5 and FEC header same as shown in Figure 6. The ULP level
header is shown in Figure 9.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L0: 340 [max(200,140,100,340)]
The payload length for level 0 is 340 bytes.
Figure 9: ULP Level Header (Level 0)
8.3. An Example With Two Protection Levels (0 and 1)
A more complete example is to use ULP at two levels. The level 0 ULP
will provide greater protection to the beginning part of the payload
packets. The level 1 ULP will apply additional protection to the rest
of the packets. This is illustrated in Figure 10. In this example, we
take L0 = 70 and L1 = 90.
Adam H. Li, et al. [Page 14]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
+------:--------:---+
Packet A | : : |
+------:------+-:---+
Packet B | : | :
+------:--+---+ :
: :
+------+ :
ULP #1 | | :
+------+ :
: :
+------:--+ :
Packet C | : | :
+------:--+-----:-----------------+
Packet D | : : |
+------:--------:-----------------+
: :
+------:--------+
ULP #2 | : |
+------:--------+
: : :
:<-L0->:<--L1-->:
Figure 10 ULP FEC scheme with protection level 0 and level 1
This will result in two ULP FEC packets - #1 and #2.
The resulting ULP FEC packet #1 will have the RTP header as shown in
Figure 11. The FEC header for ULP FEC packet #1 will be as shown in
Figure 12. The level 0 ULP header for #1 will be shown in Figure 13.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|0|0|0 0 0 0|1|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 2
Padding: 0
Extension: 0
Marker: 1
PT: 127
SN: 1
TS: 5
SSRC: 2
Figure 11: RTP Header of ULP FEC #1
Adam H. Li, et al. [Page 15]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SN base: 8 [min(8,9)]
len. rec.: 68 [200 XOR 140]
E: 1 [ULP FEC]
PT rec.: 25 [11 XOR 18]
mask: 3 [Packet 8 and 9 marked]
TS rec.: 6 [3 XOR 5]
Figure 12: FEC Header of ULP FEC Packet #1
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L0: 70
The payload length for level 0 is 70 bytes.
Figure 13: ULP Level Header (Level 0) for ULP FEC Packet #1
The resulting ULP FEC packet #2 will have the RTP header as shown in
Figure 14. The FEC header for ULP FEC packet #2 will be as shown in
Figure 15. The level 0 ULP header for #2 will be shown in Figure 16.
The level 1 ULP header for #2 will be shown in Figure 17.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|0|0|0 0 0 0|1|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 2
Padding: 0
Extension: 0
Marker: 1
PT: 127
Adam H. Li, et al. [Page 16]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
SN: 2
TS: 9
SSRC: 2
Figure 14: RTP Header of ULP FEC Packet #2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 1 0 0 1 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SN base: 8 [min(8,9,10,11)]
len. rec.: 308 [100 XOR 340]
E: 1 [ULP FEC]
PT rec.: 25 [11 XOR 18]
mask: 12 [Packet 10 and 11 marked]
TS rec.: 6 [7 XOR 9]
Figure 15: FEC Header of ULP Packet #2
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L0: 70
The payload length for level 0 is 70 bytes.
Figure 16: ULP Level Header (Level 0) for ULP Packet #2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 1 0 1 1 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 1 1|
+-+-+-+-+-+-+-+-+
L1: 90
mask: 15 [Packet 8, 9, 10, and 11 marked]
The payload length for level 1 is 90 bytes.
Figure 17: ULP Level Header (Level 1) for ULP Packet #2
Adam H. Li, et al. [Page 17]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
9. Security and Congestion Considerations
The use of ULP FEC has implications on the usage and changing of keys
for encryption. As the ULP FEC packets do consist of a separate
stream, there are a number of combinations on the usage of
encryption. These include:
o The ULP FEC stream may be encrypted, while the media stream is
not.
o The media stream may be encrypted, while the ULP FEC stream is
not.
o The media stream and ULP FEC stream are both encrypted, but
using different keys.
o The media stream and ULP FEC stream are both encrypted, but
using the same key.
The first three of these would require all application level
signaling protocols used to be aware of the usage of ULP FEC, and to
thus exchange keys and negotiate encryption usage on the media and
ULP FEC streams separately. In the final case, no such additional
mechanisms are needed. The first two cases present a layering
violation, as ULP FEC packets should be treated no differently than
other RTP packets. Encrypting just one stream may also make certain
known-plaintext attacks possible. For these reasons, applications
utilizing encryption SHOULD encrypt both streams.
The changing of encryption keys is another crucial issue needs to be
addressed. Consider the case where two packets a and b are sent along
with the ULP FEC packet that protects them. The keys used to encrypt
a and b are different, so which key should be used to decode the ULP
FEC packet? In general, old keys need to be cached, so that when the
keys change for the media stream, the old key can be used until it is
determined that the key has changed for the ULP FEC packets as well.
Another issue with the use of ULP FEC is its impact on network
congestion. In many situations, the packet loss in the network is
induced by congestions. In such scenarios, adding FEC when
encountering increasing network losses should be avoided. If it is
used on a widespread basis, this can result in increased congestion
and eventual congestion collapse. The applications may include
stronger protections while at the same time reduce the bandwidth for
the payload packets. In any event, implementations MUST NOT
substantially increase the total amount of bandwidth in use
(including the payload and the ULP FEC) as network losses increase.
Adam H. Li, et al. [Page 18]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
10. Indicating ULP FEC Usage in SDP
FEC packets contain RTP packets with dynamic payload type values. In
addition, the FEC packets can be sent on separate multicast groups or
separate ports from the media. The ULP FEC can even be carried in
packets containing media using the redundant encoding payload format
[5]. These configuration options MUST be indicated out of band. This
section describes how this can be accomplished using the Session
Description Protocol (SDP), specified in RFC 2327 [6].
10.1. ULP FEC as a Separate Stream
In the first case, the ULP FEC packets are sent as a separate stream.
This means that they can be sent on a different port and/or multicast
group from the media. When this is done, several pieces of
information must be conveyed:
o The address and port where the ULP FEC is being sent to
o The payload type number for the ULP FEC
o Which media stream the ULP FEC is protecting
The payload type number for the ULP FEC is conveyed in the m line of
the media it is protecting, listed as if it were another valid
encoding for the stream. There is no static payload type assignment
for ULP FEC, so dynamic payload type numbers MUST be used. The
binding to the number is indicated by an rtpmap attribute. The name
used in this binding is "ulpfec".
The presence of the payload type number in the m line of the media it
is protecting does not mean the ULP FEC is sent to the same address
and port as the media. Instead, this information is conveyed through
an fmtp attribute line. The presence of the ULP FEC payload type on
the m line of the media serves only to indicate which stream the ULP
FEC is protecting.
The format for the fmtp line for ULP FEC is:
a=fmtp:<number> <port> <network type> <addresss type> <connection
address>
where 'number' is the payload type number present in the m line. Port
is the port number where the ULP FEC is sent to. The remaining three
items - network type, address type, and connection address - have the
same syntax and semantics as the c line from SDP. This allows the
fmtp line to be partially parsed by the same parser used on the c
lines. Note that since ULP FEC cannot be hierarchically encoded, the
<number of addresses> parameter MUST NOT appear in the connection
address.
The following is an example SDP for ULP FEC:
Adam H. Li, et al. [Page 19]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
v=0
o=hamming 2890844526 2890842807 IN IP4 128.97.90.168
s=ULP FEC Seminar
c=IN IP4 224.2.17.12/127
t=0 0
m=audio 49170 RTP/AVP 0 78
a=rtpmap:78 ulpfec/8000
a=fmtp:78 49172 IN IP4 224.2.17.12/127
m=video 51372 RTP/AVP 31 79
a=rtpmap:79 ulpfec/8000
a=fmtp:79 51372 IN IP4 224.2.17.13/127
The presence of two m lines in this SDP indicates that there are two
media streams - one audio and one video. The media format of 0
indicates that the audio uses PCM, and is protected by ULP FEC with
payload type number 78. The ULP FEC is sent to the same multicast
group and TTL as the audio, but on a port number two higher (49172).
The video is protected by ULP FEC with payload type number 79. The
ULP FEC appears on the same port as the video (51372), but on a
different multicast address.
10.2. Use with Redundant Encoding
When the ULP FEC stream is being sent as a secondary codec in the
redundant encoding format, this must be signaled through SDP. To do
this, the procedures defined in RFC 2198 [5] are used to signal the
use of redundant encoding. The ULP FEC payload type is indicated in
the same fashion as any other secondary codec. An rtpmap attribute
MUST be used to indicate a dynamic payload type number for the ULP
FEC packets. The ULP FEC MUST protect only the main codec. In this
case, the fmtp attribute for the ULP FEC MUST NOT be present.
For example:
m=audio 12345 RTP/AVP 121 0 5 100
a=rtpmap:121 red/8000/1
a=rtpmap:100 ulpfec/8000
a=fmtp:121 0/5/100
This SDP indicates that there is a single audio stream, which can
consist of PCM (media format 0) , DVI (media format 5), the redundant
encodings (indicated by media format 121, which is bound to read
through the rtpmap attribute), or ULP FEC (media format 100, which is
bound to ulpfec through the rtpmap attribute). Although the ULP FEC
format is specified as a possible coding for this stream, the ULP FEC
MUST NOT be sent by itself for this stream. Its presence in the m
line is required only because non-primary codecs must be listed here
according to RFC 2198. The fmtp attribute indicates that the
redundant encodings format can be used, with DVI as a secondary
coding and ULP FEC as a tertiary encoding.
Adam H. Li, et al. [Page 20]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
10.3. Usage with RTSP
RTSP [7] can be used to request ULP FEC packets to be sent as a
separate stream. When SDP is used with RTSP, the Session Description
does not include a connection address and port number for each
stream. Instead, RTSP uses the concept of a "Control URL". Control
URLs are used in SDP in two distinct ways.
1. There is a single control URL for all streams. This is referred
to as "aggregate control". In this case, the fmtp line for the ULP
FEC stream is omitted.
2. There is a Control URL assigned to each stream. This is
referred to as "non-aggregate control". In this case, the
fmtp line specifies the Control URL for the stream of ULP FEC
packets. The URL may be used in a SETUP command by an RTSP client.
The format for the fmtp line for ULP FEC with RTSP and non-aggregate
control is:
a=fmtp:<number> <control URL>
where 'number' is the payload type number present in the m line.
Control URL is the URL used to control the stream of ULP FEC packets.
Note that the Control URL does not need to be an absolute URL. The
rules for converting a relative Control URL to an absolute URL are
given in RFC 2326, Section C.1.1.
11. MIME Registrations
Four new MIME sub-type as described in this section is to be
registered.
11.1. Registration of audio/ulpfec
To: ietf-types@iana.org
Subject: Registration of MIME media type audio/ulpfec
MIME media type name: audio
MIME subtype name: ulpfec
Required parameters: none
Note that it is mandated that RTP payload formats without a defined
rate must define a rate parameter as part of their MIME registration.
The payload format for ULP FEC does not specify a rate parameter.
However, the rate for ULP FEC data is equal to the rate of the media
data it protects.
Optional parameters: none
Adam H. Li, et al. [Page 21]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
Typical optional parameters [8], such as the number of channels, and
the duration of audio per packet, do not apply to ULP FEC data. The
number of channels is effectively the same as the media data it
protects; the same is true for the duration of audio per packet.
Encoding considerations: This format is only defined for transport
within the Real Time Transport protocol (RTP) [3]. Its transport
within RTP is fully specified with RFC xxxx.
Security considerations: the same security considerations apply to
these MIME registrations as to the payloads for them, as detailed in
RFC xxxx.
Interoperability considerations: none
Published specification: RFC xxxx.
Applications which use this media type: Audio and video streaming
tools which seek to improve resiliency to loss by sending additional
data with the media stream.
Additional information: none
Person & email address to contact for further information:
Adam Li
Department of Electrical Engineering
University of California
Los Angeles, CA 90095
adamli@icsl.ucla.edu
Intended usage: COMMON
Author/Change controller: This registration is part of the IETF
registration tree.
RTP and SDP Issues: Usage of this format within RTP and the Session
Description Protocol (SDP) [6] are fully specified within Section 10
of RFC xxxx.
11.2. Registration of video/ulpfec
To: ietf-types@iana.org
Subject: Registration of MIME media type video/ulpfec
MIME media type name: video
MIME subtype name: ulpfec
Required parameters: none
Adam H. Li, et al. [Page 22]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
Note that it is mandated that RTP payload formats without a defined
rate must define a rate parameter as part of their MIME registration.
The payload format for ULP FEC does not specify a rate parameter.
However, the rate for ULP FEC data is equal to the rate of the media
data it protects.
Optional parameters: none
Typical optional parameters [8], such as the number of channels, and
the duration of audio per packet, do not apply to ULP FEC data. The
number of channels is effectively the same as the media data it
protects; the same is true for the duration of video per packet.
Encoding considerations: This format is only defined for transport
within the Real Time Transport protocol (RTP) [3]. Its transport
within RTP is fully specified with RFC xxxx.
Security considerations: the same security considerations apply to
these MIME registrations as to the payloads for them, as detailed in
RFC xxxx.
Interoperability considerations: none
Published specification: RFC xxxx.
Applications which use this media type: Audio and video streaming
tools which seek to improve resiliency to loss by sending additional
data with the media stream.
Additional information: none
Person & email address to contact for further information:
Adam Li
Department of Electrical Engineering
University of California
Los Angeles, CA 90095
adamli@icsl.ucla.edu
Intended usage: COMMON
Author/Change controller: This registration is part of the IETF
registration tree.
RTP and SDP Issues: Usage of this format within RTP and the Session
Description Protocol (SDP) [6] are fully specified within Section 10
of RFC xxxx.
11.3. Registration of text/ulpfec
To: ietf-types@iana.org
Subject: Registration of MIME media type text/ulpfec
Adam H. Li, et al. [Page 23]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
MIME media type name: text
MIME subtype name: ulpfec
Required parameters: none
Note that it is mandated that RTP payload formats without a defined
rate must define a rate parameter as part of their MIME registration.
The payload format for ULP FEC does not specify a rate parameter.
However, the rate for ULP FEC data is equal to the rate of the media
data it protects.
Optional parameters: none
Typical optional parameters [8], such as the number of channels, and
the duration of audio per packet, do not apply to ULP FEC data. The
number of channels is effectively the same as the media data it
protects; the same is true for the duration of video per packet.
Encoding considerations: This format is only defined for transport
within the Real Time Transport protocol (RTP) [3]. Its transport
within RTP is fully specified with RFC xxxx.
Security considerations: the same security considerations apply to
these MIME registrations as to the payloads for them, as detailed in
RFC xxxx.
Interoperability considerations: none
Published specification: RFC xxxx.
Applications which use this media type: Audio, video and text
streaming tools which seek to improve resiliency to loss by
sending additional data with the media stream.
Additional information: none
Person & email address to contact for further information:
Adam Li
Department of Electrical Engineering
University of California
Los Angeles, CA 90095
adamli@icsl.ucla.edu
Intended usage: COMMON
Author/Change controller: This registration is part of the IETF
registration tree.
Adam H. Li, et al. [Page 24]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
RTP and SDP Issues: Usage of this format within RTP and the Session
Description Protocol (SDP) [6] are fully specified within Section 10
of RFC xxxx.
11.4. Registration of application/ulpfec
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ulpfec
MIME media type name: application
MIME subtype name: ulpfec
Required parameters: none
Note that it is mandated that RTP payload formats without a defined
rate must define a rate parameter as part of their MIME registration.
The payload format for ULP FEC does not specify a rate parameter.
However, the rate for ULP FEC data is equal to the rate of the media
data it protects.
Optional parameters: none
Typical optional parameters [8], such as the number of channels, and
the duration of audio per packet, do not apply to ULP FEC data. The
number of channels is effectively the same as the media data it
protects; the same is true for the duration of video per packet.
Encoding considerations: This format is only defined for transport
within the Real Time Transport protocol (RTP) [3]. Its transport
within RTP is fully specified with RFC xxxx.
Security considerations: the same security considerations apply to
these MIME registrations as to the payloads for them, as detailed in
RFC xxxx.
Interoperability considerations: none
Published specification: RFC xxxx.
Applications which use this media type: Audio/video streaming tools
and other applications which seek to improve resiliency to loss by
sending additional data with the media stream.
Additional information: none
Person & email address to contact for further information:
Adam Li
Department of Electrical Engineering
University of California
Los Angeles, CA 90095
Adam H. Li, et al. [Page 25]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
adamli@icsl.ucla.edu
Intended usage: COMMON
Author/Change controller: This registration is part of the IETF
registration tree.
RTP and SDP Issues: Usage of this format within RTP and the Session
Description Protocol (SDP) [6] are fully specified within Section 10
of RFC xxxx.
12. Acknowledgments
The authors would also like to acknowledge the suggestions from many
people, particularly Tao Tian, Matthieu Tisserand, Stephen Wenger,
Jay Fahlen, and Jeffery Tseng.
13. Bibliography
[1] J. Rosenberg and H. Schulzrine, "An RTP Payload Format for
Generic Forward Error Correction," Request for Comments (Proposed
Standard) 2733, Internet Engineering Task Force, December 1999.
[2] C. Perkins and O. Hodson, "Options for repair of streaming media,
"Request for Comments (Informational) 2354, Internet Engineering Task
Force, June 1998.
[3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," Request for Comments
(Proposed Standard) 1889, Internet Engineering Task Force, January
1996.
[4] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments (Best Current Practice) 2119, Internet
Engineering Task Force, March 1997.
[5] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C.
Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload for
Redundant Audio Data", RFC 2198, September 1997.
[6] M. Handley, and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[7] H. Schulzrinne, A. Rao, and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[8] S. Casner, and P. Hoschka, "MIME type registration of RTP payload
formats", Work in Progress.
Adam H. Li, et al. [Page 26]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
[9] J. Rosenberg and H. Schulzrine, "Registration of parityfec MIME
types", Request for Comments (Proposed Standard) 3009, Internet
Engineering Task Force, November 2000.
14. Authors' Addresses
Adam H. Li
Electrical Engineering Department
University of California, Los Angeles
Los Angeles, CA 90095
USA
Phone: +1-310-825-5178
Fax : +1-310-825-7928
EMail: adamli@icsl.ucla.edu
Fang Liu
Electrical Engineering Department
University of California, Los Angeles
Los Angeles, CA 90095
USA
Phone: +1-310-825-5178
Fax : +1-310-825-7928
EMail: fanliu@icsl.ucla.edu
John D. Villasenor
Electrical Engineering Department
University of California, Los Angeles
Los Angeles, CA 90095
USA
Phone: +1-310-825-0228
Fax : +1-310-825-7928
EMail: villa@icsl.ucla.edu
Jeong-Hoon Park
Samsung Electronics
Suwon City, Kyungki-Do
Korea
442-742
Phone: +82-31-200-3747
Fax : +82-31-200-3147
Email: jeonghoon@samsung.com
Dong-Seek Park
Samsung Electronics
Suwon City, Kyungki-Do
Korea
442-742
Phone: +82-31-279-5090
Fax : +82-31-279-5130
Email: dspark@samsung.com
Adam H. Li, et al. [Page 27]
I-Draft An RTP Payload Format for Generic FEC with ULP Nov. 2002
Yung-Lyul Lee
Samsung Electronics
Suwon City, Kyungki-Do
Korea
442-742
Phone: +82-31-200-3719
Fax : +82-31-200-3147
Email: yllee@samsung.com
Jonathan D. Rosenberg
DynamicSoft Inc.
72 Eagle Rock Avenue
East Hanover, NJ 07936
USA
Phone: +1-973-952-5000
Fax : +1-983-952-5050
Email: jdrosen@dynamicsoft.com
Henning Schulzrinne
Department of Computer Science
Columbia University
New York, NY 10027
USA
Phone: +1-212-939-7000
Fax : +1-212-981-4470
Email: hgs@cs.columbia.edu
Adam H. Li, et al. [Page 28]
