Internet DRAFT - draft-galanos-fecframe-rtp-reedsolomon-mf
draft-galanos-fecframe-rtp-reedsolomon-mf
FEC Framework S. Galanos
Internet-Draft RADVISION
Intended status: Standards Track July 1, 2009
Expires: January 2, 2010
RTP Payload Format for Reed Solomon FEC of Multiple Flows
draft-galanos-fecframe-rtp-reedsolomon-mf-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document defines a new RTP payload format for the Forward Error
Correction (FEC) that uses Reed-Solomon codes. The format defined by
this document enables the protection of multiple source flows with
Galanos Expires January 2, 2010 [Page 1]
Internet-Draft RTP Payload Format for RS FEC July 2009
one or more repair flows and is based on the FEC framework (described
in [I-D.ietf-fecframe-framework]) and the SDP Elements for FEC
Framework (described in [I-D.ietf-fecframe-sdp-elements]). The Reed-
Solomon codes used in this document belong to the class of Maximum
Distance Separable (MDS) codes which means they offer optimal
protection against random and bursty packet losses.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Definitions, Notations and Abbreviations . . . . . . . . . . . 3
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Reed Solomon Codes . . . . . . . . . . . . . . . . . . . . . . 4
5. Source Block Creation . . . . . . . . . . . . . . . . . . . . 4
6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Source Packets . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Repair Packets . . . . . . . . . . . . . . . . . . . . . . 7
6.2.1. RTP header format . . . . . . . . . . . . . . . . . . 7
6.2.2. FEC header format . . . . . . . . . . . . . . . . . . 8
6.2.3. Repair Data Format . . . . . . . . . . . . . . . . . . 9
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 9
7.1. Media Type Registration . . . . . . . . . . . . . . . . . 9
7.1.1. Registration of audio/reed-solomon-mf-fec . . . . . . 9
7.1.2. Registration of video/reed-solomon-mf-fec . . . . . . 10
7.1.3. Registration of text/reed-solomon-mf-fec . . . . . . . 11
7.1.4. Registration of application/reed-solomon-mf-fec . . . 13
7.2. Mapping of SDP Parameters . . . . . . . . . . . . . . . . 14
8. Protection and Recovery Procedures . . . . . . . . . . . . . . 14
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.2. Repair Packet Construction . . . . . . . . . . . . . . . . 14
8.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 15
8.3.1. Associating the Source and Repair Packets . . . . . . 15
8.3.2. Recovering the source packet . . . . . . . . . . . . . 16
9. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Offer/Answer considerations . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . . 18
14.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Galanos Expires January 2, 2010 [Page 2]
Internet-Draft RTP Payload Format for RS FEC July 2009
1. Introduction
This document defines new RTP payload formats for the Forward Error
Correction (FEC) that is generated by the Reed-Solomon code
calculated over multiple RTP flows.
By nature, Real-time applications are extremely sensitive to delay
and require very low latency. As a result, retransmission of lost
packets or using other closed-loop schemes are not valid options and
the use of Forward Error Correction (FEC) is an effective approach.
A primary requirement from FEC for real time applications is the
ability to perfectly recover from both random and bursty packet
losses. The Reed-Solomon FEC codes used in this document belong to
the class of Maximum Distance Separable (MDS) codes that are optimal
in terms of erasure recovery capability for both situations.
The format defined by this document enables the protection of
multiple source flows with one or more repair flows without adding
additional information to the source packets. Such behavior reduces
the delay presented by any FEC scheme and maintains backwards
compatibility with non-FEC enabled receivers.
Number of previous drafts were composed to draw different FEC schemes
suitable for different applications. The scheme defined in this
draft is designed to compensate a burst of packet loss over RTP
networks with minimum delay, which is needed in interactive IP-based
applications such as video conferencing.
The Read-Solomon codes used in this document have already been
specified by Luigi Rizzo (see [Rizzo97]). The document is compliant
with the Forward Error Correction (FEC) Framework (described in
[I-D.ietf-fecframe-framework]) and SDP Elements for FEC Framework
(described in [I-D.ietf-fecframe-sdp-elements]).
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Definitions, Notations and Abbreviations
This document uses the following definitions and notations. For
further definitions that apply to FEC Framework in general, see
[I-D.ietf-fecframe-framework].
Galanos Expires January 2, 2010 [Page 3]
Internet-Draft RTP Payload Format for RS FEC July 2009
3.1. Definitions
FEC: Forward Error Correction.
Source Flow: The packet flow to which FEC protection is to be
applied.
Repair Flow: The packet flow carrying FEC data.
Source Block: The group of source data packets which are to be FEC
protected as a single block.
Source Packets: Packets that are transmitted over a source flow
Repair/FEC Packets: Packets that are transmitted over a repair flow
FEC header: The header information contained in an FEC packet
3.2. Notations
K: The number of packets in a source block
N-K: The number of repair FEC packets generated from a single source
block
L: Source packet size
4. Reed Solomon Codes
The detailed operation and theory behind Reed Solomon codes is out of
the scope of this document. In general a Reed Solomon code takes a
group of K data blocks and generates N - K FEC block. A receiver
needs to receive any K of the N data or FEC blocks in order to
recover the remaining N-K data block. The algorithm operates over
multiple symbols each taken from a single data block. The symbol
size can be different in different implementations. Any symbol size
can be used in the format offered by this document. However, it is
recommended for simplicity to use symbol size of 8 bits (byte). For
more information of Reed Solomon codes, the reader is referred to
[Rizzo97].
5. Source Block Creation
Using this framework the application can protect multiple RTP source
flows using one or more FEC repair flows. Therefore, the source
block contains RTP packets taken from different flows (See Figure 1).
Galanos Expires January 2, 2010 [Page 4]
Internet-Draft RTP Payload Format for RS FEC July 2009
Moreover, a single source block MAY contain different number of
packets from the different flows.
+------------+
s_1 --------> | |
. Source | Source | +--------+ +--------+ +--------+
. Flows | Block |=> ..|SB_(j+1)| | SB_j | |SB_(j-1)|
s_n --------> | Generation | +--------+ +--------+ +--------+
+------------+
Figure 1: Source Block generation
A source block for the Reed-Solomon code contains K data blocks. In
the scheme presented by this document, each data block contains a
single RTP packet and therefore a source block contains exactly K RTP
packets. The Reed-Solomon codes generates N-K repair blocks that are
transmitted using N-K repair packets. Each repair packet contains a
single repair block. Such behavior is most suitable for packet-
switched networks where errors are on packet boundaries
To create a source block the steps outlined below should be followed.
1. For each packet protected in this source block create a byte
array as follows:
A. In the first two bytes place the unsigned network-ordered 16-
bit representation of the RTP packet size (including RTP
header +and payload)
B. Append the entire RTP packet including its RTP header
C. Add padding (bytes containing binary zeroes) so that the byte
array is in the size of the largest packet protected by this
source block including the two bytes from section a. (The
largest packet does not contain zero padding).
2. Append all the byte arrays one after the other in the following
way:
A. Packets from the same flow are consecutive in the source
block.
B. The packets of the same flow are in an increasing order of
the sequence number as it appears in the RTP packet header
taking wraparound into account
Galanos Expires January 2, 2010 [Page 5]
Internet-Draft RTP Payload Format for RS FEC July 2009
C. The sequence number of packets belonging to the same flow
must be consecutive in a single source block.
Figure 2 demonstrates how a source block is created from packets
taken from different flows. In this example three flows marked with
FID1, FID2 and FID3. The source block is constructed from one packet
(P1) taken from FID1, one packet (P2) taken from FID2 and two packets
(P3, P4) taken from FID3. The largest packet protected in this
source block has the size of 5 (L=5) and therefore P1 and P3 are both
padded with zeros to this size. The source block contains the RTP
packet size before each packet. (Note that this example is not a
binary representation of the source block. The Packet size spans
over two bytes as stated above)
FID1 P1 FID2 P2 FID3 P3 FID3 P4
L=3 L=5 L=4 L=5
+---+ +-----+ +----+ +-----+
|xxx| |xxxxx| |xxxx| |xxxxx|
+---+ +-----+ +----+ +-----+
|--- Source Block (K=4)-----|
+------+------+------+------+
|3xxx00|5xxxxx|4xxxx0|5xxxxx|
+------+------+------+------+
Figure 2: Structure of a Source Block
The FEC Reed-Solomon Scheme gets a source block created from K
packets and generates N-K FEC repair packets that protect the entire
source block. These packets are then transmitted in the repair flow.
Padding is done only for FEC packet calculation and the original
payloads are transmitted without extra padding.
6. Packet Formats
This section defines the formats of the source and repair packets
6.1. Source Packets
The FEC Framework requires that source packets contain information
identifying the source block and the position within the source block
occupied by the packet. However, in order to maintain backwards
compatibility, the scheme defined by this document enables the
receiver to get this information without appending additional
Galanos Expires January 2, 2010 [Page 6]
Internet-Draft RTP Payload Format for RS FEC July 2009
information to the source packet. Specifically this information is
obtained using the combination of sequence number found in the RTP
header and information provided in the FEC header of each repair
packet. Such behavior enables both non-FEC-capable and FEC-capable
receivers to receive and interpret the same source packets.
6.2. Repair Packets
The FEC repair packets contain information that enables the receiver
to reconstruct the source block in the remote end. This is done by
using the RTP header of the repair packets as well as another header
that is placed within the RTP payload. This header, referred to as
the FEC header, is shown in Figure 3.
+------------------------------+
| IP Header |
+------------------------------+
| Transport Header |
+------------------------------+
| RTP Header |
+------------------------------+ --_
| FEC Header | \
+------------------------------+ > RTP Payload
| Repair Data | _/
+------------------------------+ --
Figure 3: Format of repair packets
6.2.1. RTP header format
The RTP header is formatted according to [RFC3550] with some further
clarifications listed below:
o Marker (M) Bit: This bit is not used for this payload type, and
is set to 0.
o Payload Type: The (dynamic) payload type for the repair packets
is determined through out-of-band means. Note that this document
registers new payload formats for the repair packets (Refer to
Section 5 for details). According to [RFC3550], an RTP receiver
that cannot recognize a payload type must discard it. This
provides backward compatibility. The FEC mechanisms can then be
used in a multicast group with mixed FEC-capable and non-FEC-
capable receivers. If a non-FEC-capable receiver receives a
repair packet, it will not recognize the payload type, and hence,
will discard the repair packet.
Galanos Expires January 2, 2010 [Page 7]
Internet-Draft RTP Payload Format for RS FEC July 2009
o Sequence Number (SN): The sequence number has the standard
definition. It is one higher than the sequence number in the
previously transmitted repair packet. The initial value of the
sequence number is random (unpredictable) [RFC3550].
o Timestamp (TS): The timestamp is set to a time corresponding to
the repair packet's transmission time. Note that the timestamp
value has no use in the actual FEC protection process and is
usually useful for jitter calculations.
o Synchronization Source (SSRC): The SSRC value is randomly
assigned as suggested by [RFC3550].
6.2.2. FEC header format
The FEC header includes information that enables the receiver to
reconstruct the source block and to identify the repair packets
associated with each source block in their correct order.
The format of the FEC header is shown in figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FEC Header Len | N-K | i | Num flows |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID | Num Packets | SN Base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID | Num Packets | SN Base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID | Num Packets | SN Base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: FEC Header Format
The FEC header consists of the general information fields and the
per-flow fields.
The FEC header consists of the following general fields:
o FEC Header Len - The length of this FEC header. The FEC header
does not have a fixed length and the length is varied according to
the number of protected flows.
o N-K - The number of FEC packets used to protect this source block
Galanos Expires January 2, 2010 [Page 8]
Internet-Draft RTP Payload Format for RS FEC July 2009
o i - 0 based packet index in the N-K FEC packets sequence.
o Num flows - The numbers of flows protected by this FEC packet.
Following the general fields, the FEC header consists of the per-flow
fields that include:
o FID - flow ID. the same value as specified in the "id" SDP
parameter. See example in section 9.
o Num Packets - The number of packets taken from this Flow.
o SN Base - the sequence number of the first source packet in the
source block taken from this flow.
6.2.3. Repair Data Format
The repair data follows the FEC header in the RTP repair packet. It
includes the result of the Reed-Solomon code over the source block.
Note that the first two bytes of the repair data contain the result
of the Reed-Solomon code over the packet sizes in the source block
and that the size of the repair data equals the size of the largest
packet protected by this source block plus 2. Therefore, the size of
a FEC packet (FEC header and data) is larger than the longest source
packet.
7. Payload Format Parameters
According to the FEC framework, when RTP is used as a transport for
repair packet flows, the scheme must define an RTP Payload Format for
the repair data. This section provides the media subtype
registration for the Reed-Solomon FEC of Multiple Flows. The
parameters that are required to configure the FEC encoding and
decoding operations are also defined in this section.
7.1. Media Type Registration
This registration is done using the template defined in [RFC4288] and
following the guidance provided in [RFC3555].
7.1.1. Registration of audio/reed-solomon-mf-fec
Type name: audio
Subtype name: reed-solomon-mf-fec
Required parameters:
Galanos Expires January 2, 2010 [Page 9]
Internet-Draft RTP Payload Format for RS FEC July 2009
o max_N: The maximum number of source packets and FEC packets used
to protect the K source packets. max_N is a positive integer. The
application can change both K and N-K. max_N is the upper limit
for N.
o repair-window: The time that spans the source packets and the
corresponding repair packets. The size of the repair window is
specified in microseconds.
Optional parameters: None.
Encoding considerations: This media type is framed and binary, see
section 4.8 in [RFC4288]
Security considerations: Please see security consideration in
[I-D.ietf-fecframe-framework]
Interoperability considerations: None.
Published specification: TBD
Applications that use this media type: Multimedia applications that
want to improve resiliency against packet loss by sending redundant
data in addition to the source media.
Additional information: None.
Magic number(s): none defined
File extension(s): none defined
Macintosh file type code(s): none defined
Person & email address to contact for further information: Sarit
Galanos, sarit@radvision.com
Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [RFC3550]. Transport
within other framing protocols is not defined at this time.
7.1.2. Registration of video/reed-solomon-mf-fec
Type name: video
Subtype name: reed-solomon-mf-fec
Galanos Expires January 2, 2010 [Page 10]
Internet-Draft RTP Payload Format for RS FEC July 2009
Required parameters:
o max_N: The maximum number of source packets and FEC packets used
to protect the K source packets. max_N is a positive integer. The
application can change both K and N-K. max_N is the upper limit
for N.
o repair-window: The time that spans the source packets and the
corresponding repair packets. The size of the repair window is
specified in microseconds.
Optional parameters: None.
Encoding considerations: This media type is framed and binary, see
section 4.8 in [RFC4288]
Security considerations: Please see security consideration in
[I-D.ietf-fecframe-framework]
Interoperability considerations: None.
Published specification: TBD
Applications that use this media type: Multimedia applications that
want to improve resiliency against packet loss by sending redundant
data in addition to the source media.
Additional information: None.
Magic number(s): none defined
File extension(s): none defined
Macintosh file type code(s): none defined
Person & email address to contact for further information: Sarit
Galanos, sarit@radvision.com
Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [RFC3550]. Transport
within other framing protocols is not defined at this time.
7.1.3. Registration of text/reed-solomon-mf-fec
Type name: text
Galanos Expires January 2, 2010 [Page 11]
Internet-Draft RTP Payload Format for RS FEC July 2009
Subtype name: reed-solomon-mf-fec
Required parameters:
o max_N: The maximum number of source packets and FEC packets used
to protect the K source packets. max_N is a positive integer. The
application can change both K and N-K. max_N is the upper limit
for N.
o repair-window: The time that spans the source packets and the
corresponding repair packets. The size of the repair window is
specified in microseconds.
Optional parameters: None.
Encoding considerations: This media type is framed and binary, see
section 4.8 in [RFC4288]
Security considerations: Please see security consideration in
[I-D.ietf-fecframe-framework]
Interoperability considerations: None.
Published specification: TBD
Applications that use this media type: Multimedia applications that
want to improve resiliency against packet loss by sending redundant
data in addition to the source media.
Additional information: None.
Magic number(s): none defined
File extension(s): none defined
Macintosh file type code(s): none defined
Person & email address to contact for further information: Sarit
Galanos, sarit@radvision.com
Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [RFC3550]. Transport
within other framing protocols is not defined at this time.
Galanos Expires January 2, 2010 [Page 12]
Internet-Draft RTP Payload Format for RS FEC July 2009
7.1.4. Registration of application/reed-solomon-mf-fec
Type name: application
Subtype name: reed-solomon-mf-fec
Required parameters:
o max_N: The maximum number of source packets and FEC packets used
to protect the K source packets. max_N is a positive integer. The
application can change both K and N-K. max_N is the upper limit
for N.
o repair-window: The time that spans the source packets and the
corresponding repair packets. The size of the repair window is
specified in microseconds.
Optional parameters: None.
Encoding considerations: This media type is framed and binary, see
section 4.8 in [RFC4288]
Security considerations: Please see security consideration in
[I-D.ietf-fecframe-framework]
Interoperability considerations: None.
Published specification: TBD
Applications that use this media type: Multimedia applications that
want to improve resiliency against packet loss by sending redundant
data in addition to the source media.
Additional information: None.
Magic number(s): none defined
File extension(s): none defined
Macintosh file type code(s): none defined
Person & email address to contact for further information: Sarit
Galanos, sarit@radvision.com
Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [RFC3550]. Transport
Galanos Expires January 2, 2010 [Page 13]
Internet-Draft RTP Payload Format for RS FEC July 2009
within other framing protocols is not defined at this time.
7.2. Mapping of SDP Parameters
For a proper operation details of the FEC scheme have to be
communicated between the sender and the receiver. Specifically, the
receiver has to know the relationship between the source and the
repair flows, how the sender applied protection to the source flows
and how the repair flows can be used to recover the lost data. One
way to provide this information is to use the Session Description
Protocol (SDP) [RFC4566].
The mapping of the media type specification for "reed-solomon-mf-fec"
and their parameters in SDP is as follows:
o The media type (e.g., "application") goes into the "m=" line as
the media name.
o The media subtype goes into the "a=rtpmap" line as the encoding
name.
o The remaining required payload-format-specific parameters go into
the "a=fmtp" line by copying them directly from the media type
string as a semicolon-separated list of parameter=value pairs.
See section 9 for SDP examples.
8. Protection and Recovery Procedures
This section provides a complete specification of the protection and
recovery procedures.
8.1. Overview
The FEC packets allow end systems to recover from the loss of media
packets. The following sections specify the steps involved in
generating the repair packets and reconstructing the missing source
packets from the repair packets.
8.2. Repair Packet Construction
The RTP header of a repair packet is formed based on the guidelines
given in Section 6.2.1. The FEC header is formed based on the
guidelines given in Section 6.2.2. The repair data is then appended
to the FEC header. The repair data is the result of the protection
operation calculated on the source block. This is the direct output
of the Reed-Solomon code. Note that the repair data will span over
Galanos Expires January 2, 2010 [Page 14]
Internet-Draft RTP Payload Format for RS FEC July 2009
N-K packets.
8.3. Source Packet Reconstruction
Recovery requires two distinct operations. The first determines
which packets (media and FEC) must be combined in order to recover
the missing packets. Once this is done, the second step is the
reconstruction of the missing data.
8.3.1. Associating the Source and Repair Packets
Association of the Source and Repair packets is done using a
combination of the Source packet sequence number and the information
found in the RTP header and the FEC header of the repair packets.
The first step is to accumulate the N-K repair packets that were
generated in the protection operation. For that the application has
to follow the steps listed below:
o For each received packet, retrieve the payload type parameter from
the RTP header to identify the packet as a repair packet of the
reed-solomon-mf scheme.
o Once a repair packet has been identified, retrieve the sequence
number from the RTP header and the N-K and i parameters from the
FEC header.
o With these three parameters, identify the collection of FEC
packets generated for the source block. For example, if N-K=4,
i=2 and the sequence number is 1003, it means that 4 packets with
sequence numbers 1001,1002,1003 and 1004 were generated for a
specific source block.
The application should then use the FEC header to identify the
packets that constructed the source block. For that the application
has to follow the steps listed bellow:
o Retrieve the Num flows parameter from the FEC header. This
parameter specifies the number of rows in the per-flow information
table.
o For each flow retrieve the FID, Num Packets and SN base
parameters.
The order of packets in the source block is identified by the order
of the rows in the per-flow table.
Galanos Expires January 2, 2010 [Page 15]
Internet-Draft RTP Payload Format for RS FEC July 2009
8.3.2. Recovering the source packet
In order to recover the lost packets the application has to rebuild
the source block according to the guidelines given in section 5 and
append the repair data to it in the correct order. The order of the
packets in the source block is specified by the order of the flow IDs
in the FEC header. In place of the lost packets the application
should place blocks with zero padding. The size of these blocks in
bytes is the size of the repair data found in the repair packets.
The repair data is the RTP payload without the FEC header information
(see figure 3). The application then appends the repair data taken
from each repair packet. This new block is provided to the Reed-
Solomon code.
The Reed-Solomon code will reconstruct the lost data into the
provided source block overriding the zero padded blocks. The
application can then recover the lost packets as follows:
o The first two bytes include the RTP packet size.
o According to the packet size the application can retrieve the
entire RTP packet (RTP header and payload).
o The extra padding bytes if exist are ignored.
9. SDP Examples
The following example demonstrates two source flows with flow IDs of
0 and 1 that are protected by a single repair flow.
Galanos Expires January 2, 2010 [Page 16]
Internet-Draft RTP Payload Format for RS FEC July 2009
v=0
o=sarit 1122334455 1122334466 IN IP4 fec.example.com
s= Reed Solomon FEC for multiple flows Example
t=0 0
a=group:FEC S1 S2 R1
m=video 30000 RTP/AVP 100
c=IN IP4 224.1.1.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=video 30000 RTP/AVP 101
c=IN IP4 224.1.1.2/127
a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1
a=mid:S2
m=application 30000 RTP/AVP 110
c=IN IP4 224.1.2.1/127
a=rtpmap:110 reed-solomon-mf-fec /90000
a=fmtp:110 max_N:5; repair-window: 200000
a=mid:R1
Figure 5
10. Offer/Answer considerations
None.
11. Security Considerations
See [I-D.ietf-fecframe-framework]
12. IANA Considerations
New media subtypes are subject to IANA registration. For the
registration of the payload formats and their parameters introduced
in this document, refer to Section 5.
13. Acknowledgments
Some parts of this document are borrowed from the following
documents: [RFC5109], [draft-ietf-fecframe-1d2d-parity-scheme-01],
[draft-roca-fecframe-rs-00], [draft-ietf-avt-reedsolomon-00]. Thus,
the author would like to thank the editors of these documents.
Galanos Expires January 2, 2010 [Page 17]
Internet-Draft RTP Payload Format for RS FEC July 2009
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, November 2006.
14.2. Informative References
[I-D.ietf-fecframe-1d2d-parity-scheme]
Begen, A., "RTP Payload Format for Non-Interleaved and
Interleaved Parity FEC",
draft-ietf-fecframe-1d2d-parity-scheme-01 (work in
progress), May 2009.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007.
[I-D.ietf-avt-reedsolomon]
Rosenberg, J., "An RTP Payload Format for Reed Solomon
Codes", May 1999.
[Rizzo97] Rizzo, L., "Effective Erasure Codes for Reliable Computer
Communication Protocols", April 1997.
[RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo,
"Reed-Solomon Forward Error Correction (FEC) Schemes",
RFC 5510, April 2009.
[I-D.roca-fecframe-rs]
Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K.
Matsuzono, "Reed-Solomon Forward Error Correction (FEC)
Galanos Expires January 2, 2010 [Page 18]
Internet-Draft RTP Payload Format for RS FEC July 2009
Schemes for FECFRAME", draft-roca-fecframe-rs-00 (work in
progress), March 2009.
[I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-03 (work in progress),
October 2008.
[I-D.ietf-fecframe-sdp-elements]
Begen, A., "SDP Elements for FEC Framework",
draft-ietf-fecframe-sdp-elements-03 (work in progress),
June 2009.
[I-D.ietf-fecframe-pseudo-cdp]
Kozat, U. and A. Begen, "Pseudo Content Delivery Protocol
(CDP) for Protecting Multiple Source Flows in FEC
Framework", draft-ietf-fecframe-pseudo-cdp-01 (work in
progress), March 2009.
[I-D.ietf-fecframe-rtp-raptor]
Watson, M., "RTP Payload Format for Raptor FEC",
draft-ietf-fecframe-rtp-raptor-01 (work in progress),
March 2009.
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
"Raptor Forward Error Correction Scheme for Object
Delivery", RFC 5053, October 2007.
Author's Address
Sarit Galanos
RADVISION
24 Raul Wallenberg St.
Tel Aviv 69719
Israel
Email: sarit@radvision.com
Galanos Expires January 2, 2010 [Page 19]
