RFC 8627
RTP Payload Format for Flexible Forward Error Correction (FEC)
Internet Engineering Task Force (IETF) M. Zanaty Request for Comments: 8627 Cisco Category: Standards Track V. Singh ISSN: 2070-1721 callstats.io A. Begen Networked Media G. Mandyam Qualcomm Inc. July 2019 RTP Payload Format for Flexible Forward Error Correction (FEC)Abstract
This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP. These parity codes are systematic codes (Flexible FEC, or "FLEX FEC"), where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams. These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes that are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of complexity. The RTP payload formats that are defined in this document address scalability issues experienced with the earlier specifications and offer several improvements. Due to these changes, the new payload formats are not backward compatible with earlier specifications; however, endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8627.
Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Parity Codes . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. One-Dimensional (1-D) Non-interleaved (Row) FEC Protection . . . . . . . . . . . . . . . . . . . . . 5 1.1.2. 1-D Interleaved (Column) FEC Protection . . . . . . . 6 1.1.3. Use Cases for 1-D FEC Protection . . . . . . . . . . 7 1.1.4. Two-Dimensional (2-D) (Row and Column) FEC Protection 8 1.1.5. FEC Protection with Flexible Mask . . . . . . . . . . 10 1.1.6. FEC Overhead Considerations . . . . . . . . . . . . . 10 1.1.7. FEC Protection with Retransmission . . . . . . . . . 10 1.1.8. Repair Window Considerations . . . . . . . . . . . . 11 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 11 3. Definitions and Notations . . . . . . . . . . . . . . . . . . 11 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . 12 4.2. FEC Repair Packets . . . . . . . . . . . . . . . . . . . 13 4.2.1. RTP Header of FEC Repair Packets . . . . . . . . . . 13 4.2.2. FEC Header of FEC Repair Packets . . . . . . . . . . 15 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 20 5.1. Media Type Registration -- Parity Codes . . . . . . . . . 20 5.1.1. Registration of audio/flexfec . . . . . . . . . . . . 21 5.1.2. Registration of video/flexfec . . . . . . . . . . . . 22 5.1.3. Registration of text/flexfec . . . . . . . . . . . . 23 5.1.4. Registration of application/flexfec . . . . . . . . . 24 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 25 5.2.1. Offer/Answer Model Considerations . . . . . . . . . . 25 5.2.2. Declarative Considerations . . . . . . . . . . . . . 26
6. Protection and Recovery Procedures -- Parity Codes . . . . . 26 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 26 6.2. Repair Packet Construction . . . . . . . . . . . . . . . 26 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . 28 6.3.1. Associating the Source and Repair Packets . . . . . . 28 6.3.2. Recovering the RTP Header . . . . . . . . . . . . . . 30 6.3.3. Recovering the RTP Payload . . . . . . . . . . . . . 31 6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC Protection . . . . . . . . . . . . . . . . . . . . . 31 7. Signaling Requirements . . . . . . . . . . . . . . . . . . . 34 7.1. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 35 7.1.1. Example SDP for Flexible FEC Protection with In-Band SSRC Mapping . . . . . . . . . . . . . . . . . . . . 35 7.1.2. Example SDP for Flexible FEC Protection with Explicit Signaling in the SDP . . . . . . . . . . . . . . . . 35 7.2. On the Use of the RTP Stream Identifier Source Description . . . . . . . . . . . . . . . . . . . . . . . 36 8. Congestion Control Considerations . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 11.1. Normative References . . . . . . . . . . . . . . . . . . 38 11.2. Informative References . . . . . . . . . . . . . . . . . 39 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 411. Introduction
This document defines new RTP payload formats for the Forward Error Correction (FEC) that is generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP [RFC3550]. The type of the source media protected by these parity codes can be audio, video, text, or application. The FEC data are generated according to the media type parameters, which are communicated out of band (e.g., in the Session Description Protocol (SDP)). Furthermore, the associations or relationships between the source and repair RTP streams may be communicated in or out of band. The in-band mechanism is advantageous when the endpoint is adapting the FEC parameters. The out-of-band mechanism may be preferable when the FEC parameters are fixed. While this document fully defines the use of FEC to protect RTP streams, it also leverages several definitions along with the basic source/repair header description from [RFC6363] in their application to the parity codes defined here. The Redundancy RTP Stream [RFC7656] repair packets proposed in this document protect the Source RTP Stream packets that belong to the same RTP session.
The RTP payload formats that are defined in this document address the scalability issues experienced with the formats defined in earlier specifications including [RFC2733], [RFC5109], and [SMPTE2022-1].1.1. Parity Codes
Both the non-interleaved and interleaved parity codes use the eXclusive OR (XOR) operation to generate the repair packets. The following steps take place: 1. The sender determines a set of source packets to be protected by FEC based on the media type parameters. 2. The sender applies the XOR operation on the source packets to generate the required number of repair packets. 3. The sender sends the repair packet(s) along with the source packets, in different RTP streams, to the receiver(s). The repair packets may be sent proactively or on demand based on RTCP feedback messages such as NACK [RFC4585]. At the receiver side, if all of the source packets are successfully received, there is no need for FEC recovery and the repair packets are discarded. However, if there are missing source packets, the repair packets can be used to recover the missing information. Figures 1 and 2 describe example block diagrams for the systematic parity FEC encoder and decoder, respectively. +------------+ +--+ +--+ +--+ +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ | Encoder | | (Sender) | --> +==+ +==+ +------------+ +==+ +==+ Source Packet: +--+ Repair Packet: +==+ +--+ +==+ Figure 1: Block Diagram for Systematic Parity FEC Encoder
+------------+ +--+ X X +--+ --> | Systematic | --> +--+ +--+ +--+ +--+ +--+ +--+ | Parity FEC | +--+ +--+ +--+ +--+ | Decoder | +==+ +==+ --> | (Receiver) | +==+ +==+ +------------+ Source Packet: +--+ Repair Packet: +==+ Lost Packet: X +--+ +==+ Figure 2: Block Diagram for Systematic Parity FEC Decoder In Figure 2, it is clear that the FEC repair packets have to be received by the endpoint within a certain amount of time for the FEC recovery process to be useful. The repair window is defined as the time that spans a FEC block, which consists of the source packets and the corresponding repair packets. At the receiver side, the FEC decoder SHOULD buffer source and repair packets at least for the duration of the repair window to allow all the repair packets to arrive. The FEC decoder can start decoding the already-received packets sooner; however, it should not register a FEC decoding failure until it waits at least for the duration of the repair window.1.1.1. One-Dimensional (1-D) Non-interleaved (Row) FEC Protection
Consider a group of D x L source packets that have Sequence Numbers starting from 1 running to D x L (where D and L are as defined in Section 3.2) and a repair packet is generated by applying the XOR operation to every L consecutive packets as sketched in Figure 3. This process is referred to as "1-D non-interleaved FEC protection". As a result of this process, D repair packets are generated, which are referred to as non-interleaved (or row) FEC repair packets. In general, D and L represent values that describe how packets are grouped together from a depth and length perspective (respectively) when interleaving all D x L source packets.
+--------------------------------------------------+ --- +===+ | S_1 S_2 S3 ... S_L | + |XOR| = |R_1| +--------------------------------------------------+ --- +===+ +--------------------------------------------------+ --- +===+ | S_L+1 S_L+2 S_L+3 ... S_2xL | + |XOR| = |R_2| +--------------------------------------------------+ --- +===+ . . . . . . . . . . . . . . . . . . +--------------------------------------------------+ --- +===+ | S_(D-1)xL+1 S_(D-1)xL+2 S_(D-1)xL+3 ... S_DxL | + |XOR| = |R_D| +--------------------------------------------------+ --- +===+ Figure 3: Generating Non-interleaved (Row) FEC Repair Packets1.1.2. 1-D Interleaved (Column) FEC Protection
Consider the case where the XOR operation is applied to the group of the source packets whose Sequence Numbers are L apart from each other, as sketched in Figure 4. In this case, the endpoint generates L repair packets. This process is referred to as "1-D interleaved FEC protection", and the resulting L repair packets are referred to as "interleaved (or column) FEC repair packets". +-------------+ +-------------+ +-------------+ +-------+ | S_1 | | S_2 | | S3 | ... | S_L | | S_L+1 | | S_L+2 | | S_L+3 | ... | S_2xL | | . | | . | | | | | | . | | . | | | | | | . | | . | | | | | | S_(D-1)xL+1 | | S_(D-1)xL+2 | | S_(D-1)xL+3 | ... | S_DxL | +-------------+ +-------------+ +-------------+ +-------+ + + + + ------------- ------------- ------------- ------- | XOR | | XOR | | XOR | ... | XOR | ------------- ------------- ------------- ------- = = = = +===+ +===+ +===+ +===+ |C_1| |C_2| |C_3| ... |C_L| +===+ +===+ +===+ +===+ Figure 4: Generating Interleaved (Column) FEC Repair Packets
1.1.3. Use Cases for 1-D FEC Protection
A sender may generate one non-interleaved repair packet out of L consecutive source packets or one interleaved repair packet out of D nonconsecutive source packets. Regardless of whether the repair packet is a non-interleaved or an interleaved one, it can provide a full recovery of the missing information if there is only one packet missing among the corresponding source packets. This implies that 1-D non-interleaved FEC protection performs better when the source packets are randomly lost. However, if the packet losses occur in bursts, 1-D interleaved FEC protection performs better provided that L is chosen to be large enough, i.e., L-packet duration is not shorter than the observed burst duration. If the sender generates non-interleaved FEC repair packets and a burst loss hits the source packets, the repair operation fails. This is illustrated in Figure 5. +---+ +---+ +===+ | 1 | X X | 4 | |R_1| +---+ +---+ +===+ +---+ +---+ +---+ +---+ +===+ | 5 | | 6 | | 7 | | 8 | |R_2| +---+ +---+ +---+ +---+ +===+ +---+ +---+ +---+ +---+ +===+ | 9 | | 10| | 11| | 12| |R_3| +---+ +---+ +---+ +---+ +===+ Figure 5: Example Scenario: 1-D Non-interleaved FEC Protection Fails Error Recovery (Burst Loss) The sender may generate interleaved FEC repair packets to combat the bursty packet losses. However, two or more random packet losses may hit the source and repair packets in the same column. In that case, the repair operation fails as well. This is illustrated in Figure 6. Note that it is possible that two burst losses occur back-to-back, in which case, interleaved FEC repair packets may still fail to recover the lost data.
+---+ +---+ +---+ | 1 | X | 3 | | 4 | +---+ +---+ +---+ +---+ +---+ +---+ | 5 | X | 7 | | 8 | +---+ +---+ +---+ +---+ +---+ +---+ +---+ | 9 | | 10| | 11| | 12| +---+ +---+ +---+ +---+ +===+ +===+ +===+ +===+ |C_1| |C_2| |C_3| |C_4| +===+ +===+ +===+ +===+ Figure 6: Example Scenario: 1-D Interleaved FEC Protection Fails Error Recovery (Periodic Loss)1.1.4. Two-Dimensional (2-D) (Row and Column) FEC Protection
In networks where the source packets are lost both randomly and in bursts, the sender ought to generate both non-interleaved and interleaved FEC repair packets. This type of FEC protection is known as "2-D parity FEC protection". At the expense of generating more FEC repair packets, thus increasing the FEC overhead, 2-D FEC provides superior protection against mixed loss patterns. However, it is still possible for 2-D parity FEC protection to fail to recover all of the lost source packets if a particular loss pattern occurs. An example scenario is illustrated in Figure 7.
+---+ +---+ +===+ | 1 | X X | 4 | |R_1| +---+ +---+ +===+ +---+ +---+ +---+ +---+ +===+ | 5 | | 6 | | 7 | | 8 | |R_2| +---+ +---+ +---+ +---+ +===+ +---+ +---+ +===+ | 9 | X X | 12| |R_3| +---+ +---+ +===+ +===+ +===+ +===+ +===+ |C_1| |C_2| |C_3| |C_4| +===+ +===+ +===+ +===+ Figure 7: Example Scenario #1: 2-D Parity FEC Protection Fails Error Recovery 2-D parity FEC protection also fails when at least two rows are missing a source and the FEC packet and the missing source packets (in at least two rows) are aligned in the same column. An example loss pattern is sketched in Figure 8. Similarly, 2-D parity FEC protection cannot repair all missing source packets when at least two columns are missing a source and the FEC packet and the missing source packets (in at least two columns) are aligned in the same row. +---+ +---+ +---+ | 1 | | 2 | X | 4 | X +---+ +---+ +---+ +---+ +---+ +---+ +---+ +===+ | 5 | | 6 | | 7 | | 8 | |R_2| +---+ +---+ +---+ +---+ +===+ +---+ +---+ +---+ | 9 | | 10| X | 12| X +---+ +---+ +---+ +===+ +===+ +===+ +===+ |C_1| |C_2| |C_3| |C_4| +===+ +===+ +===+ +===+ Figure 8: Example Scenario #2: 2-D Parity FEC Protection Fails Error Recovery
1.1.5. FEC Protection with Flexible Mask
It is possible to define FEC protection for selected packets in the source stream. This would enable differential protection, i.e., application of FEC selectively to packets that require a higher level of reliability than the other packets in the source stream. The sender will be required to send a bitmap indicating the packets to be protected, i.e., a "mask", to the receiver. Since the mask can be modified during an RTP session ("flexible mask"), this kind of FEC protection can also be used to implement FEC dynamically (e.g., for adaptation to different types of traffic during the RTP session).1.1.6. FEC Overhead Considerations
The overhead is defined as the ratio of the number of bytes belonging to the repair packets to the number of bytes belonging to the protected source packets. Generally, repair packets are larger in size than the source packets. Also, not all the source packets are necessarily equal in size. However, assuming that each repair packet carries an equal number of bytes as carried by a source packet, the overhead for different FEC protection methods can be computed as follows: 1-D Non-interleaved FEC Protection: Overhead = 1/L 1-D Interleaved FEC Protection: Overhead = 1/D 2-D Parity FEC Protection: Overhead = 1/L + 1/D where L and D are the number of columns and rows in the source block, respectively.1.1.7. FEC Protection with Retransmission
This specification supports both forward error correction, i.e., before any loss is reported, as well as retransmission of source packets after the loss is reported. The retransmission includes the RTP header of the source packet in addition to the payload. If a peer supporting both FLEX FEC and other RTP retransmission methods (see [RFC4588]) receives an Offer including both FLEX FEC and another RTP retransmission method, it MUST respond with an Answer containing only FLEX FEC.
1.1.8. Repair Window Considerations
The value for the repair window duration is related to the maximum L and D values that are expected during a FLEX FEC session; therefore, it cannot be chosen arbitrarily. Repair packets that include L and D values larger than the repair window MUST NOT be sent. The rate of the source streams should also be considered, as the repair window duration should ideally span several packetization intervals in order to leverage the error correction capabilities of the parity code. Because the FEC configuration can change with each repair packet (see Section 4.2.2), for any given repair packet, the FLEX FEC receiver MUST support all possible L and D combinations (both 1-D and 2-D interleaved over all source flows) and all flexible mask configurations (over all source flows) within the repair window to which it has agreed (e.g., through SDP or out-of-band signaling) for a FLEX FEC RTP session. In addition, the FLEX FEC receiver MUST support receipt of a retransmission of any source flow packet within the repair window to which it has agreed.2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.3. Definitions and Notations
3.1. Definitions
This document uses a number of definitions from [RFC6363]. Additionally, it defines the following and/or updates their definitions from [RFC6363]. 1-D Non-interleaved Row FEC: A protection scheme that operates on consecutive source packets in the source block, able to recover a single lost source packet per row of the source block. 1-D Interleaved Column FEC: A protection scheme that operates on interleaved source packets in the source block, able to recover a single lost source packet per column of the source block. 2-D FEC: A protection scheme that combines row and column FEC. Source Block: A set of source packets that are protected by a set of 1-D or 2-D FEC repair packets.
FEC Block: A source block and its corresponding FEC repair packets.
Repair Window: The time that spans a FEC block, which consists of
the source packets and the corresponding FEC repair packets.
XOR Parity Codes: A FEC code that uses the eXclusive OR (XOR) parity
operation to encode a set of source packets to form a FEC repair
packet.
3.2. Notations
L: Number of columns of the source block (length of each row).
D: Number of rows of the source block (depth of each column).
bitmask: A 15-bit, 46-bit, or 110-bit mask indicating which source
packets are protected by a FEC repair packet. If the bit i in the
mask is set to 1, the source packet number N + i is protected by
this FEC repair packet, where N is the Sequence Number base
indicated in the FEC repair packet. The most significant bit of
the mask corresponds to i=0. The least significant bit of the
mask corresponds to i=14 in the 15-bit mask, i=45 in the 46-bit
mask, or i=109 in the 110-bit mask.
4. Packet Formats
This section describes the formats of the source packets and defines
the formats of the FEC repair packets.
4.1. Source Packets
The source packets contain the information that identifies the source
block and the position within the source block occupied by the
packet. Since the source packets that are carried within an RTP
stream already contain unique Sequence Numbers in their RTP headers
[RFC3550], the source packets can be identified in a straightforward
manner and there is no need to append any additional fields. The
primary advantage of not modifying the source packets in any way is
that it provides backward compatibility for the receivers that do not
support FEC at all. In multicast scenarios, this backward
compatibility becomes quite useful as it allows the non-FEC-capable
and FEC-capable receivers to receive and interpret the same source
packets sent in the same multicast session.
The source packets are transmitted as usual without altering them.
They are used along with the FEC repair packets to recover any
missing source packets, making this scheme a systematic code.
The source packets are full RTP packets with optional contributing source (CSRC) list, RTP header extension, and padding. If any of these optional elements are present in the source RTP packet, and that source packet is lost, they are recovered by the FEC repair operation, which recovers the full source RTP packet including these optional elements.4.2. FEC Repair Packets
The FEC repair packets will contain information that identifies the source block they pertain to and the relationship between the contained repair packets and the original source block. For this purpose, the RTP header of the repair packets is used, as well as another header within the RTP payload, called the "FEC header", as shown in Figure 9. Note that all the source stream packets that are protected by a particular FEC packet need to be in the same RTP session. +------------------------------+ | IP Header | +------------------------------+ | Transport Header | +------------------------------+ | RTP Header | +------------------------------+ ---+ | FEC Header | | +------------------------------+ | RTP Payload | Repair Payload | | +------------------------------+ ---+ Figure 9: Format of FEC Repair Packets The Repair Payload, which follows the FEC header, includes repair of everything following the fixed 12-byte RTP header of each source packet, including any CSRC identifier list and header extensions if present.4.2.1. RTP Header of FEC Repair Packets
The RTP header is formatted according to [RFC3550] with some further clarifications listed below: Version (V) 2 bits: This MUST be set to 2 (binary 10), as this specification requires all source RTP packets and all FEC repair packets to use RTP version 2.
Padding (P) bit: Source packets can have optional RTP padding, which
can be recovered. FEC repair packets can have optional RTP
padding, which is independent of the RTP padding of the source
packets.
Extension (X) bit: Source packets can have optional RTP header
extensions, which can be recovered. FEC repair packets can have
optional RTP header extensions, which are independent of the RTP
header extensions of the source packets.
CSRC Count (CC) 4 bits, and CSRC List (CSRC_i) 32 bits each: Source
packets can have an optional CSRC list and count, which can be
recovered. FEC repair packets MUST use the CSRC list and count to
specify the synchronization sources (SSRCs) of the source RTP
stream(s) protected by this FEC repair packet.
Marker (M) bit: This bit is not used for this payload type, SHALL be
set to 0 by senders, and SHALL be ignored by receivers.
Payload Type: The (dynamic) payload type for the FEC repair packets
is determined through out-of-band means (e.g., SDP). 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. If a non-FEC-capable
receiver receives a repair packet, it will not recognize the
payload type; hence, it will discard the repair packet.
Sequence Number (SN): The Sequence Number follows the standard
definition provided in [RFC3550]. Therefore, it must be one
higher than the Sequence Number in the previously transmitted
repair packet, and the initial value of the Sequence Number should
be random (i.e., unpredictable).
Timestamp (TS): The timestamp SHALL be 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.
Synchronization Source (SSRC): The SSRC value for each repair stream
SHALL be randomly assigned as per the guidelines provided in
Section 8 of [RFC3550]. This allows the sender to multiplex the
source and repair RTP streams in the same RTP session, or
multiplex multiple repair streams in an RTP session. The repair
stream's SSRC's CNAME SHOULD be identical to the CNAME of the
source RTP stream(s) that this repair stream protects. A FEC
stream that protects multiple source RTP streams with different
CNAME's uses the CNAME associated with the entity generating the
FEC stream or the CNAME of the entity on whose behalf it performs
the protection operation. In cases when the repair stream covers
packets from multiple source RTP streams with different CNAME
values and none of these CNAME values can be associated with the
entity generating the FEC stream, any of these CNAME values MAY be
used.
In some networks, the RTP Source, which produces the source
packets, and the FEC Source, which generates the repair packets
from the source packets, may not be the same host. In such
scenarios, using the same CNAME for the source and repair RTP
streams means that the RTP Source and the FEC Source will share
the same CNAME (for this specific source-repair stream
association). A common CNAME may be produced based on an
algorithm that is known both to the RTP and FEC Source [RFC7022].
This usage is compliant with [RFC3550].
Note that due to the randomness of the SSRC assignments, there is
a possibility of SSRC collision. In such cases, the collisions
must be resolved as described in [RFC3550].
4.2.2. FEC Header of FEC Repair Packets
The format of the FEC header has three variants, depending on the
values in the first two bits (R and F bits) as shown in Figure 10.
Note that R and F stand for "retransmit" and "fixed block",
respectively. Two of these variants are meant to describe different
methods for deriving the source data from a source packet for a
repair packet. This allows for customizing the FEC method to allow
for robustness against different levels of burst errors and random
packet losses. The third variant is for a straight retransmission of
the source packet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|F|P|X| CC |M| PT recovery | ...varies depending on R/F... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ...varies depending on R/F... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Repair Payload follows FEC header :
: :
Figure 10: FEC header
The Repair Payload, which follows the FEC header, includes repair of everything following the fixed 12-byte RTP header of each source packet, including any CSRC identifier list and header extensions if present. An overview on how the Repair Payload can be used to recover source packets is provided in Section 6. +---+---+-----------------------------------------------------+ | R | F | FEC header variant | +---+---+-----------------------------------------------------+ | 0 | 0 | Flexible FEC Mask fields indicate source packets | | 0 | 1 | Fixed FEC L/D (cols/rows) indicate source packets | | 1 | 0 | Retransmission of a single source packet | | 1 | 1 | Reserved for future use, MUST NOT send, MUST ignore | +---+---+-----------------------------------------------------+ Figure 11: R and F Bit Values for FEC Header Variants The first variant, when R=0 and F=0, has a mask to signal protected source packets, as shown in Figure 12. The second variant, when R=0 and F=1, has a number of columns (L) and rows (D) to signal protected source packets, as shown in Figure 13. The final variant, when R=1 and F=0, is a retransmission format as shown in Figure 15. No variant presently uses R=1 and F=1, which is reserved for future use. Current FLEX FEC implementations MUST NOT send packets with this variant, and receivers MUST ignore these packets. Future FLEX FEC implementations may use this by updating the media type registration. The FEC header for all variants consists of the following common fields: o The R bit MUST be set to 1 to indicate a retransmission packet, and MUST be set to 0 for FEC repair packets. o The F bit indicates the type of FEC repair packets, as shown in Figure 11, when the R bit is 0. The F bit MUST be set to 0 when the R bit is 1 for retransmission packets. o The P, X, CC, M, and PT recovery fields are used to determine the corresponding fields of the recovered packets (see also Section 6.3.2).
4.2.2.1. FEC Header with Flexible Mask
When R=0 and F=0, the FEC header includes flexible Mask fields. 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|P|X| CC |M| PT recovery | length recovery | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS recovery | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SN base_i |k| Mask [0-14] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |k| Mask [15-45] (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask [46-109] (optional) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... next SN base and Mask for CSRC_i in CSRC list ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Repair Payload follows FEC header : : : Figure 12: FEC Header for F=0 o The Length recovery (16 bits) field is used to determine the length of the recovered packets. This length includes all octets following the fixed 12-byte RTP header of source packets, including CSRC list and optional header extension(s) if present. It excludes the fixed 12-byte RTP header of source packets. o The TS recovery (32 bits) field is used to determine the timestamp of the recovered packets. o The CSRC_i (32 bits) field in the RTP header (not FEC header) describes the SSRC of the source packets protected by this particular FEC packet. If a FEC packet protects multiple SSRCs (indicated by the CSRC Count > 1 in the RTP header), there will be multiple blocks of data containing the SN base and Mask fields. o The SN base_i (16 bits) field indicates the lowest sequence number, taking wrap around into account, of the source packets for a particular SSRC (indicated in CSRC_i) protected by this repair packet.
o The Mask fields indicate a bitmask of which source packets are
protected by this FEC repair packet, where bit j of the mask set
to 1 indicates that the source packet with Sequence Number (SN
base_i + j) is protected by this FEC repair packet, where j=0 is
the most significant bit in the mask.
o The k-bit in the bitmasks indicates if the mask is 15, 46, or 110
bits. k=1 denotes that another mask follows, and k=0 denotes that
it is the last block of mask.
o The Repair Payload, which follows the FEC header, includes repair
of everything following the fixed 12-byte RTP header of each
source packet, including any CSRC identifier list and header
extensions if present.
4.2.2.2. FEC Header with Fixed L Columns and D Rows
When R=0 and F=1, the FEC header includes L and D fields for fixed
columns and rows. The other fields are the same as the prior
section. As in the previous section, the CSRC_i (32 bits) field in
the RTP header (not FEC Header) describes the SSRC of the source
packets protected by this particular FEC packet. If there are
multiple SSRC's protected by the FEC packet, then there will be
multiple blocks of data containing an SN base along with L and D
fields.
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|1|P|X| CC |M| PT recovery | length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SN base_i | L (columns) | D (rows) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... next SN base and L/D for CSRC_i in CSRC list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Repair Payload follows FEC header :
: :
Figure 13: FEC Header for F=1
Consequently, the following conditions occur for L and D values: If L=0, D=0, reserved for future use, MUST NOT send, MUST ignore if received. If L>0, D=0, indicates row FEC, and no column FEC will follow (1D). Source packets for each row: SN, SN+1, ..., SN+(L-1) If L>0, D=1, indicates row FEC, and column FEC will follow (2D). Source packets for each row: SN, SN+1, ..., SN+(L-1) Source packets for each col: SN, SN+L, ..., SN+(D-1)*L After all row FEC packets have been sent, the column FEC packets will be sent. If L>0, D>1, indicates column FEC of every L packet, D times. Source packets for each col: SN, SN+L, ..., SN+(D-1)*L Figure 14: Interpreting the L and D Field Values Given the 8-bit limit on L and D (as depicted in Figure 13), the maximum value of either parameter is 255. If L=0 and D=0 are in a packet, then the repair packet MUST be ignored by the receiver. In addition, when L=1 and D=0, the repair packet becomes a retransmission of a corresponding source packet. The values of L and D for a given block of recovery data will correspond to the type of recovery in use for that block of data. In particular, for 2-D repair, the (L,D) values may not be constant across all packets for a given SSRC being repaired. Similarly, the L and D values can differ across different blocks of repair data (repairing different SSRCs) in a single packet. If the values of L and D result in a repair packet that exceed the repair window of the FLEX FEC session, then the repair packet MUST be ignored. It should be noted that the flexible mask-based approach may be inefficient for protecting a large number of source packets, or impossible to signal if larger than the largest mask size. In such cases, the fixed columns and rows variant may be more useful.4.2.2.3. FEC Header for Retransmissions
When R=1 and F=0, the FEC packet is a retransmission of a single source packet. Note that the layout of this retransmission packet is different from other FEC repair packets. The Sequence Number (SN base_i) replaces the length recovery in the FEC header, since the length is already known for a single packet. There are no L, D, or Mask fields, since only a single packet is retransmitted, identified by the Sequence Number in the FEC header. The source packet SSRC is
included in the FEC header for retransmissions, not in the RTP header CSRC list as in the FEC header variants with R=0. When performing retransmissions, a single repair packet stream (SSRC) MAY be used for retransmitting packets from multiple source packet streams (SSRCs), as well as transmitting FEC repair packets that protect multiple source packet streams (SSRCs). This FEC header layout is identical to the source RTP (version 2) packet, starting with its RTP header, where the retransmission "payload" is everything following the fixed 12-byte RTP header of the source packet, including the CSRC list and extensions if present. Therefore, the only operation needed for sending retransmissions is to prepend a new RTP header to the source packet. 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|P|X| CC |M| Payload Type| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Retransmission Payload follows FEC header : : : Figure 15: FEC Header for Retransmission
(page 20 continued on part 2)
