Internet Draft A. Li
draft-ietf-avt-ulp-02.txt F. Liu
October 24, 2001 J. Villasenor
Expires: April 24 2002 Univ. of Calif., LA
J.H. Park
D.S. Park
Y.L. Lee
Samsung Electronics
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 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.
ABSTRACT
This document specifies a payload format for generic forward error
correction to achieve uneven level protection (ULP) of media
encapsulated in RTP. It is an extension to the forward error
correction scheme specified in RFC 2733 [1], and it is also based on
the exclusive-or (parity) operation. The payload format allows end
systems to transmit using arbitrary protection length and levels, in
additional to using arbitrary block lengths. It also allows for the
both complete recovery of the critical payload and RTP header fields,
and partial recovery when complete recovery is not possible due to
the packet lost situation. This scheme is backward compatible with
non-FEC capable hosts, and hosts that are only capable of FEC schemes
specified in RFC 2733 [1], so that receivers which do not wish to
implement ULP forward error correction can just ignore the
extensions.
Adam H. Li, et al. [Page 1]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
Table of Contents
1. Introduction ................................................... 2
2. Terminology ..... .............................................. 4
3. Basic Operation ................................................ 4
4. RTP Media Packet Structure ..................................... 6
5. ULP FEC Packet Structure ....................................... 6
5.1. RTP Header of ULP FEC Packets ................................ 6
5.2. FEC Header ................................................... 7
5.3. ULP Layer Header ............................................. 7
6. Protection Operation ........................................... 8
6.1. Protection Level 0 ........................................... 9
6.2. Protection Level 1 and Higher ............................... 10
7. Recovery Procedure ............................................ 10
7.1. Reconstruction of Level 0 ................................... 10
7.2. Reconstruction of Level 1 and Higher ........................ 12
8. Examples ...................................................... 12
8.1. An Example That Has Only Protection Level 0 ................. 12
8.2. An Example That Generates Idential Protection as in RFC 2733 14
8.3. An Example That Has Two Protection Levels (0 and 1) ......... 15
9. Security and Congestion Considerations ........................ 19
10. Indication ULP FEC Usage in SDP .............................. 20
10.1. ULP FEC as a Separate Stream ............................... 20
10.2. Use with Redundant Encoding ................................ 21
10.3. Usage with RTSP ............................................ 22
11. MIME Registrations ........................................... 22
11.1. Registration of audio/ulpfec ............................... 22
11.2. Registration of video/ulpfec ............................... 23
11.3. Registration of text/ulpfec ................................ 24
11.4. Registration of application/ulpfec ......................... 26
12. Acknowledgements ............................................. 27
13. Bibliography ................................................. 27
14. Authors' Address ............................................. 28
1. Introduction
Because of the real time nature of many applications, they have more
strict delay requirement than a pure data transmission. As a result,
retransmission of the lost packets is generally not a valid option
such applications. A better way to attempt to recover information
about a lost packet in this case is FEC. Thus forward error
correction (FEC) has been used to compensate for packet loss in the
Internet [2]. In particular, the error correction has to be on the
packet level, because any correction within the packet will be
useless if the whole packet is lost.
In many cases for the network connections, the bandwidth is a very
limited resource. However, many traditional FEC schemes are not
designed for optimal usage of the limited bandwidth resource. A more
efficient way is to provide different protection levels for different
parts of the data stream of different importance. These unequal error
protection schemes make more efficient use of the bandwidth to
Adam H. Li, et al. [Page 2]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
provide overall better protection of the data stream against the
lost. To support these mechanisms, protocol support is required.
However, most of the unequal error protection schemes require the
knowledge of the importance level or class of data stream. As a
result, most of such schemes depend on the nature and structure of
the media being protected, and are not generic.
In many cases for multimedia streams, we have some very important
knowledge about the stream. In general, 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 if the data is variable length
coded. Also, almost all media formats have the frame headers at the
beginning of the packet.
For video streams, most modern formats have optional data
partitioning modes to improve error resilience, where the video
macroblock header data, the motion vector data and DCT coefficient
data are separated in their individual partitions. In ITU-T H.263
version 3, when the optional data partitioned syntax of Annex V is
enabled, when the optional data partitioning mode is enabled in MPEG-
4 Visual Simple Profile, the video macroblock (MB) header and motion
vector partitions (which are much more important to the quality of
video reconstruction) transmitted in the partition 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 the order of more
important data to less important data, it would help to provide more
protection to the beginning part of the packet.
In case of audio stream, many new audio codecs do encode into
bitstream data of different importance classes and transmit them in
the order of more important to less important. Applying more
protection to the beginning of the packet would benefit. Even for
uniform-significance audio streams, special stretching techniques can
be applied the partially recovered audio data packets. Also, if there
is audio redundancy coding, it makes sense to have more protection
applied to the original data which is at the first half of the
packet, while with no protections for the redundant copies which is
at the trailing half of the packet.
So the application should benefit from unequal error protections
scheme with more emphasis on the beginning part of the packets. This
document defines a payload format for RTP [3] which allows for
generic forward error correction with unequal error protection for
real time media. The payload data is protected by one or more
protection levels. The lower protection level provides more
protection by using smaller group size (compare to higher protection
levels) to generate the FEC packet. The data that is closer to the
beginning of the packet is protected by lower protection levels
because these data are in general more important and carrying more
information than those further behind.
Adam H. Li, et al. [Page 3]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
In this context, generic means that the FEC protocol is (1)
independent of the nature of the media being protected, be it audio,
video, or otherwise, (2) flexible enough to support a wide variety of
FEC mechanisms, (3) designed for adaptivity so that the FEC technique
can be modified easily without out of band signaling, and (4)
supportive of a number of different mechanisms for transporting the
FEC packets.
2. Terminology
The following terms are used throughout this document:
Media Payload: is a piece of raw, un-protected user data which is to
be transmitted from the sender. The media payload is placed inside of
an RTP packet.
Media Header: is 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.
FEC Packet: The forward error correction algorithms at the
transmitter take the media packets as an input. They output both the
media packets that they are passed, and new packets called FEC
packets. The FEC packets are formatted according to the rules
specified in this document.
FEC Header: The FEC header is the header information contained in an
FEC packet.
FEC Payload: The FEC payload is the payload in an FEC packet.
Associated: An FEC packet is said to be "associated" with one or more
media packets when those media packets are used to generate the 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 a participant in
an RTP session would like to protect a media stream it is sending
with uneven level protection (ULP) FEC. The ULP FEC supported by the
format are based on simple exclusive-or (xor) parities as used also
in RFC 2733 [1]. The sender takes the packets from the media stream
that need to be protected, and determines the protection level it
wants for these packets and the length for each level. The data of
Adam H. Li, et al. [Page 4]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
each level are grouped in a way that is described below to provide
each level a different error resilience capability by adjusting the
size of the group. An xor operation is applied across the payload to
generate the ULP FEC information for that level. The lower protection
levels (which provides high protection, or high error resilience) are
applied to the data that is closer to the beginning of the packet to
ensure more protection there. Based on the procedures defined here,
the result is an RTP packet containing ULP FEC information. This
packet can be used at the receiver to recover any one packets used to
generate the ULP FEC packet, or to recover part of the packet
depending on the packet lost situation. 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 this
ULP FEC packet and the protection levels and lengths for each of
them. Specifically, each ULP FEC packet contains a set of protection
length and bitmask, called the offset mask, for each protection
level. If bit i in the mask m(k) (i.e., the mask for protection level
k) is set to 1, data of length L(k) in the media packet with sequence
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 protection length, offset mask and payload type are
sufficient to signal arbitrary parity based forward error correction
schemes with little overhead. There are a set of rules as described
below on how the mask should be set for different protection levels.
This will ensure that if data of protection level k for a packet is
recoverable, all the data of protection level lower than k is
recoverable for that particular packet.
This document also describes procedures that allow the receiver to
make use of the ULP FEC without having to know the details of
specific codes. This allows the sender much flexibility; it can adapt
the code in use based on 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
loss, the ULP FEC packets can be combined with other media and ULP
FEC packets that have been received, resulting in recovery of the
whole or part of the missing media packets.
RTP packets which contain data formatted according to this
specification (i.e., ULP FEC packets) are using dynamic RTP payload
types.
Adam H. Li, et al. [Page 5]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
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 lends to a very efficient encoding. When little (or no) ULP FEC
is used, there are mostly media packets being sent. This means that
the overhead (present in ULP FEC packets only) tracks the amount of
FEC in use.
5. ULP FEC Packet Structure
An ULP FEC packet is constructed by placing an FEC header and ULP FEC
payload in the RTP payload, as shown in Figure 1:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ULP Layer 0 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ULP Layer 0 Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ULP Layer 1 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ULP Layer 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 padding bit is computed via the
protection operation, defined below. The extension bit is also
computed via the protection operation. The SSRC value will generally
be the same as the SSRC value of the media stream it protects. It MAY
be different if the FEC stream is being demultiplexed via the SSRC
value. The CC value is computed via the protection operation. The
CSRC list is never present, independent of the value of the CC field.
The extension is never present, independent of the value of the X
bit. The marker bit is computed via the protection operation.
Adam H. Li, et al. [Page 6]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
The sequence number has the standard definition: it MUST be one
higher than the sequence number in the previously transmitted FEC
packet. The timestamp MUST be set to the value of the media RTP clock
at the instant the ULP FEC packet is transmitted. This results in the
TS value in FEC packets to be monotonically increasing, independent
of the FEC scheme.
The payload type for the ULP FEC packet is determined through
dynamic, out of band means. According to RFC 1889 [3], RTP
participants which 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.
5.2. FEC Header
This header is 12 bytes. The format of the header is shown in Figure
2, and consists of an SN base field, length recovery field, E field,
PT recovery field, mask field and TS 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| PT recovery | mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: FEC Header Format
This is exactly as the FEC header used in RFC 2733 [1]. The usage
will also be the exactly the same as specified as in RFC 2733, except
that the E bit MUST set to one for this version.
5.3. ULP Layer Header
The ULP Layer Header is 2 bytes for ULP layer 0, and 5 bytes for ULP
layer 1 and higher. The format of the header is shown in Figure 3 and
Figure 4, and consists of a Protection Length field, and mask field
(for layer 1 and higher headers).
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ULP Layer Header Format (Level 0)
Adam H. Li, et al. [Page 7]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
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 4: ULP Layer Header Format (Level 1 and higher)
The Protection Length field is 16 bits. It indicates the protection
length provided by the ULP FEC for the current protection level
(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. The detail is described in the next section
on the protection operation
6. Protection Operation
The protection operation involves copying the payload, padding with
zeroes, and computing the xor across the resulting bit strings. In
additional, for protection of level 0, it also involves concatenating
specific fields from the RTP header of the media packet before the
Adam H. Li, et al. [Page 8]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
payload data. The resulting bit string is used to generate the ULP
FEC packet.
The following procedure MAY be followed for the protection operation.
Other procedures MAY be followed, but the end result MUST be
identical to the one described here.
6.1. Protection Level 0
For each media packet to be protected, a bit string is generated by
concatenating the following fields together in the order specifed:
o Padding Bit (1 bit)
o Extension Bit (1 bit)
o CC bits (4 bits)
o Marker bit (1 bit)
o Payload Type (7 bits)
o Timestamp (32 bits)
o Unsigned network-ordered 16 bit representation of the sum of the
lengths of the CSRC List, length of the padding, length of the
extension, and length of the media packet (16 bits)
o if CC is nonzero, the CSRC List (variable length)
o if X is 1, the Header Extension (variable length)
o the payload (variable length)
o Padding, if present (variable length)
Note that the Padding Bit (first entry above) forms the most
significant bit of the bit string.
If the lengths of the bit strings are not equal, each bit string that
is shorter than the Protection Length 0 plus 96 bits, MUST be padded
to that length. Any value for the pad may be used. The pad MUST be
added at the end of the bit string.
The parity operation is then applied across the bit strings. The
result is the bit string used to build the ULP FEC packet. Call this
the ULP FEC bit string (level 0).
The first (most significant) bit in the ULP FEC bit string is written
into the Padding Bit of the ULP FEC packet. The second bit in the ULP
FEC bit string is written into the Extension bit of the ULP FEC
packet. The next four bits of the ULP FEC bit string are written into
the CC field of the ULP FEC packet. The next bit of the ULP FEC bit
Adam H. Li, et al. [Page 9]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
string is written into the marker bit of the ULP FEC packet. The next
7 bits of the ULP FEC bit string are written into the PT recovery
field in the ULP FEC packet header. The next 32 bits of the ULP FEC
bit string are written into the TS recovery field in the packet
header. The next 16 bits are written into the length recovery field
in the ULP FEC packet header. This is exactly the same as in RFC 2733
[1].
The remaining bits (of length Protection Length 0) are set to be the
payload of the ULP FEC packet.
6.2. Protection Level 1 and Higher
The protected data of the corresponding packets 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.
7. Recovery Procedures
The ULP FEC packets allow end systems to recover from the loss of
media packets. All of the header fields of the missing packets,
including CSRC lists, extensions, padding bits, marker and payload
type, are recoverable. 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 at all
possible.
7.1. Reconstruction of Level 0
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 packets in T, compute the bit string as
described in the protection operation of the previous section.
2. For the ULP FEC packet in T, compute the bit string in the
same fashion, except always set the CSRC list, extension, and
Adam H. Li, et al. [Page 10]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
padding to null. Read the Protection Length 0. Read string of
that length from that ULP FEC packet.
3. If any of the bit strings generated from the media packets are
shorter than the bit string generated from the ULP FEC packet,
pad them to be the same length as the bit string generated
from the ULP FEC. The padding MUST be added at the end of the
bit string, and MAY be of any value.
4. Perform the exclusive-or (parity) operation across the bit
strings, resulting in a recovery bit string.
5. Create a new packet with the standard 12 byte RTP header and
no payload.
6. Set the version of the new packet to 2.
7. Set the Padding bit in the new packet to the first bit in the
recovery bit string.
8. Set the Extension bit in the new packet to the second bit in
the recovery bit string.
9. Set the CC field to the next four bits in the recovery bit
string.
10. Set the marker bit in the new packet to the next bit in the
recovery bit string.
11. Set the payload type in the new packet to the next 7 bits in
the recovery bit string.
12. Set the SN field in the new packet to xi.
13. Set the TS field in the new packet to the next 32 bits in the
recovery bit string.
14. Take the next 16 bits of the recovery bit string. Whatever
unsigned integer this represents (assuming network-order),
take that many bytes from the recovery bit string and append
them to the new packet. This represents the CSRC list,
extension, payload, and padding.
15. Set the SSRC of the new packet to the SSRC of the media stream
it's protecting.
This procedure will recover both the header and payload of an RTP
packet up to the Protection Length of level 0.
Adam H. Li, et al. [Page 11]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
7.2. Reconstruction of Level 1 and Higher
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.
Because the data protected at lower protection level is always
recoverable if the higher level protected data is recoverable. This
procedure (together with the procedure for the lower protection
levels) will recover both the header and payload of an RTP packet up
to the Protection Length of the current level.
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, with
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 That Has 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 5 below.
Adam H. Li, et al. [Page 12]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
+------:------------+
Packet A | : |
+------:------+-----+
Packet B | : |
+------:--+---+
Packet C | : |
+------:--+-----------------------+
Packet D | : |
+------:--------------------------+
:
+------+
Packet FEC | |
+------+
: :
:<-L0->:
Figure 5 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 6.
The FEC header in the ULP FEC packet is shown in Figure 7.
The ULP header for layer 0 in the ULP FEC packet is shown in Figure
8.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 2
Padding: 0
Extension: 0
Marker: 0
PT: 127
SN: 1
TS: 9
SSRC: 2
Figure 6: RTP Header of ULP FEC for Packets A, B, C and D (one level)
Adam H. Li, et al. [Page 13]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
TS rec.: 8 [3 xor 5 xor 7 xor 9]
Figure 7: 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 8: ULP Layer Header (Level 0)
8.2. An Example That Generates Identical Protection as in RFC 2733
We can choose to extend the level 0 protection to cover all the
length of the packets (as shown in Figure 9). This is give us 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 extra flexbility.
Adam H. Li, et al. [Page 14]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
+-------------------+ :
Packet A | | :
+-------------+-----+ :
Packet B | | :
+---------+---+ :
Packet C | | :
+---------+-----------------------+
Packet D | |
+---------------------------------+
:
+---------------------------------+
Packet FEC | |
+---------------------------------+
: :
:<------------- L0 -------------->:
Figure 9 ULP FEC scheme with only protection level 0
The resulting ULP FEC packet will have the RTP header same as shown
in Figure 6 and FEC header same as shown in Figure 7. The ULP layer
header is shown in Figure 10.
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 10: ULP Layer Header (Level 0)
8.3. An Example That Has Two Protection Levels (0 and 1)
A more complete example is to use ULP at two levels. The level 0 ULP
will put more 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 11. In this example, we
take L0 = 70 and L1 = 90.
Adam H. Li, et al. [Page 15]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
+------:--------:---+
Packet A | : : |
+------:------+-:---+
Packet B | : | :
+------:--+---+ :
: :
+------+ :
ULP #1 | | :
+------+ :
: :
+------:--+ :
Packet C | : | :
+------:--+-----:-----------------+
Packet D | : : |
+------:--------:-----------------+
: :
+------:--------+
ULP #2 | : |
+------:--------+
: : :
:<-L0->:<--L1-->:
Figure 11 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 12. The FEC header for ULP FEC packet #1 will be as shown in
Figure 13. The level 0 ULP header for #1 will be shown in Figure 14.
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 12: RTP Header of ULP FEC #1
Adam H. Li, et al. [Page 16]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
TS rec.: 6 [3 xor 5]
Figure 13: 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 14: ULP Layer Header (Level 0) for ULP FEC Packet #1
The resulting ULP FEC packet #2 will have the RTP header as shown in
Figure 15. The FEC header for ULP FEC packet #2 will be as shown in
Figure 16. The level 0 ULP header for #2 will be shown in Figure 17.
The level 1 ULP header for #2 will be shown in Figure 18.
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 17]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
SN: 2
TS: 9
SSRC: 2
Figure 15: 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
TS rec.: 6 [7 xor 9]
Figure 16: 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 17: ULP Layer 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
The payload length for level 1 is 90 bytes.
Figure 18: ULP Layer Header (Level 1) for ULP Packet #2
Adam H. Li, et al. [Page 18]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
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 permutations on the usage of
encryption. In particular:
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 any application level
signaling protocols to be aware of the usage of ULP FEC, and to thus
exchange keys for it and negotiate its 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 really be treated no differently than other RTP
packets. Encrypting just one may also make certain known-plaintext
attacks possible. For these reasons, applications utilizing
encryption SHOULD encrypt both streams.
The changing of keys is another issue needs to be taken good care of.
For example, if two packets a and b are sent, and ULP FEC packet
protects a and b is sent, and the keys used for a and b are
different, which key should be used to decode the ULP FEC packet? In
general, old keys will likely need to be cached, so that when the
keys change for the media stream, the old key is kept, and used,
until it is determined that the key has changed on 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 are
induced by congestions. In such scenarios, adding FEC in the face of
increasing network losses should be avoided, as it can lead to
increased congestion and eventual congestion collapse if done on a
widespread basis. The applications may include stronger protections
while at the same time reduce the bandwidth for the payload packets.
In any event, implementers MUST NOT substantially increase the total
amount of bandwidth (including the payload and the ULP FEC) in use as
network losses increase.
Adam H. Li, et al. [Page 19]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
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 can mean they are 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 20]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
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 21]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
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 22]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
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 23]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
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 24]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
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 25]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
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 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
Adam H. Li, et al. [Page 26]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
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
This text is partially based on an RFC 2733 [1] and RFC 3009 [9] on
generic RTP FEC payload format by H. Schulzrinne and J. Rosenburg.
The authors would also like to acknowledge the suggestions from many
people, particularly Tao Tian, Matthieu Tisserand, and Stephen
Wenger.
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 27]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
[9] J. Rosenberg and H. Schulzrine, "Registration of parityfec MIME
types", Request for Comments (Proposed Standard) 3009, Internet
Engineering Task Force, November 2000.
14. Author's Addresses
Adam H. Li
Electronic 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
Electronic 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
Electronic Engineering Department
University of California, Los Angeles
Los Angeles, CA 90095
USA
Phone: +1-310-825-5178
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-200-3674
Fax : +82-31-200-3147
Email: dspark@samsung.com
Adam H. Li, et al. [Page 28]
I-Draft An RTP Payload Format for Generic FEC with ULP October 2001
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
Adam H. Li, et al. [Page 29]
