< draft-ietf-payload-flexible-fec-scheme-17.txt   draft-ietf-payload-flexible-fec-scheme-18.txt >
PAYLOAD M. Zanaty PAYLOAD M. Zanaty
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track V. Singh Intended status: Standards Track V. Singh
Expires: August 16, 2019 callstats.io Expires: September 6, 2019 callstats.io
A. Begen A. Begen
Networked Media Networked Media
G. Mandyam G. Mandyam
Qualcomm Inc. Qualcomm Inc.
February 12, 2019 March 5, 2019
RTP Payload Format for Flexible Forward Error Correction (FEC) RTP Payload Format for Flexible Forward Error Correction (FEC)
draft-ietf-payload-flexible-fec-scheme-17 draft-ietf-payload-flexible-fec-scheme-18
Abstract Abstract
This document defines new RTP payload formats for the Forward Error This document defines new RTP payload formats for the Forward Error
Correction (FEC) packets that are generated by the non-interleaved Correction (FEC) packets that are generated by the non-interleaved
and interleaved parity codes from source media encapsulated in RTP. and interleaved parity codes from source media encapsulated in RTP.
These parity codes are systematic codes, where a number of FEC repair These parity codes are systematic codes, where a number of FEC repair
packets are generated from a set of source packets from one or more packets are generated from a set of source packets from one or more
source RTP streams. These FEC repair packets are sent in a source RTP streams. These FEC repair packets are sent in a
redundancy RTP stream separate from the source RTP stream(s) that redundancy RTP stream separate from the source RTP stream(s) that
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 16, 2019. This Internet-Draft will expire on September 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Parity Codes . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Parity Codes . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. One-Dimensional (1-D) Non-interleaved (Row) FEC 1.1.1. One-Dimensional (1-D) Non-interleaved (Row) FEC
Protection . . . . . . . . . . . . . . . . . . . . . 6 Protection . . . . . . . . . . . . . . . . . . . . . 5
1.1.2. 1-D Interleaved (Column) FEC Protection . . . . . . . 7 1.1.2. 1-D Interleaved (Column) FEC Protection . . . . . . . 6
1.1.3. Use Cases for 1-D FEC Protection . . . . . . . . . . 8 1.1.3. Use Cases for 1-D FEC Protection . . . . . . . . . . 7
1.1.4. Two-Dimensional (2-D) (Row and Column) FEC Protection 10 1.1.4. Two-Dimensional (2-D) (Row and Column) FEC Protection 8
1.1.5. FEC Protection with Flexible Mask . . . . . . . . . . 12 1.1.5. FEC Protection with Flexible Mask . . . . . . . . . . 10
1.1.6. FEC Overhead Considerations . . . . . . . . . . . . . 13 1.1.6. FEC Overhead Considerations . . . . . . . . . . . . . 10
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 13 1.1.7. Repair Window Considerations . . . . . . . . . . . . 10
3. Definitions and Notations . . . . . . . . . . . . . . . . . . 13 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 11
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 13 3. Definitions and Notations . . . . . . . . . . . . . . . . . . 11
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . 14 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. FEC Repair Packets . . . . . . . . . . . . . . . . . . . 15 4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. RTP Header of FEC Repair Packets . . . . . . . . . . 16 4.2. FEC Repair Packets . . . . . . . . . . . . . . . . . . . 12
4.2.2. FEC Header of FEC Repair Packets . . . . . . . . . . 17 4.2.1. RTP Header of FEC Repair Packets . . . . . . . . . . 13
5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 25 4.2.2. FEC Header of FEC Repair Packets . . . . . . . . . . 15
5.1. Media Type Registration - Parity Codes . . . . . . . . . 25 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 20
5.1.1. Registration of audio/flexfec . . . . . . . . . . . . 25 5.1. Media Type Registration - Parity Codes . . . . . . . . . 20
5.1.2. Registration of video/flexfec . . . . . . . . . . . . 26 5.1.1. Registration of audio/flexfec . . . . . . . . . . . . 21
5.1.3. Registration of text/flexfec . . . . . . . . . . . . 28 5.1.2. Registration of video/flexfec . . . . . . . . . . . . 22
5.1.4. Registration of application/flexfec . . . . . . . . . 29 5.1.3. Registration of text/flexfec . . . . . . . . . . . . 24
5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 31 5.1.4. Registration of application/flexfec . . . . . . . . . 25
5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 31 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 26
5.2.2. Declarative Considerations . . . . . . . . . . . . . 32 5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 27
6. Protection and Recovery Procedures - Parity Codes . . . . . . 32 5.2.2. Declarative Considerations . . . . . . . . . . . . . 28
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 32 6. Protection and Recovery Procedures - Parity Codes . . . . . . 28
6.2. Repair Packet Construction . . . . . . . . . . . . . . . 33 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3. Source Packet Reconstruction . . . . . . . . . . . . . . 34 6.2. Repair Packet Construction . . . . . . . . . . . . . . . 28
6.3.1. Associating the Source and Repair Packets . . . . . . 35 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . 30
6.3.2. Recovering the RTP Header . . . . . . . . . . . . . . 37 6.3.1. Associating the Source and Repair Packets . . . . . . 30
6.3.3. Recovering the RTP Payload . . . . . . . . . . . . . 38 6.3.2. Recovering the RTP Header . . . . . . . . . . . . . . 32
6.3.3. Recovering the RTP Payload . . . . . . . . . . . . . 33
6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC 6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC
Protection . . . . . . . . . . . . . . . . . . . . . 38 Protection . . . . . . . . . . . . . . . . . . . . . 34
7. Signaling Requirements . . . . . . . . . . . . . . . . . . . 42 7. Signaling Requirements . . . . . . . . . . . . . . . . . . . 36
7.1. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 43 7.1. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 37
7.1.1. Example SDP for Flexible FEC Protection with in-band 7.1.1. Example SDP for Flexible FEC Protection with in-band
SSRC mapping . . . . . . . . . . . . . . . . . . . . 43 SSRC mapping . . . . . . . . . . . . . . . . . . . . 37
7.1.2. Example SDP for Flexible FEC Protection with explicit 7.1.2. Example SDP for Flexible FEC Protection with explicit
signalling in the SDP . . . . . . . . . . . . . . . . 44 signalling in the SDP . . . . . . . . . . . . . . . . 38
7.2. On the Use of the RTP Stream Identifier Source 7.2. On the Use of the RTP Stream Identifier Source
Description . . . . . . . . . . . . . . . . . . . . . . . 44 Description . . . . . . . . . . . . . . . . . . . . . . . 38
8. Congestion Control Considerations . . . . . . . . . . . . . . 45 8. Congestion Control Considerations . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 45 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
12.1. Normative References . . . . . . . . . . . . . . . . . . 46 12.1. Normative References . . . . . . . . . . . . . . . . . . 40
12.2. Informative References . . . . . . . . . . . . . . . . . 48 12.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This document defines new RTP payload formats for the Forward Error This document defines new RTP payload formats for the Forward Error
Correction (FEC) that is generated by the non-interleaved and Correction (FEC) that is generated by the non-interleaved and
interleaved parity codes from a source media encapsulated in RTP interleaved parity codes from a source media encapsulated in RTP
[RFC3550]. The type of the source media protected by these parity [RFC3550]. The type of the source media protected by these parity
codes can be audio, video, text or application. The FEC data are codes can be audio, video, text or application. The FEC data are
generated according to the media type parameters, which are generated according to the media type parameters, which are
communicated out-of-band (e.g., in SDP). Furthermore, the communicated out-of-band (e.g., in SDP). Furthermore, the
skipping to change at page 13, line 26 skipping to change at page 10, line 38
o 1-D Non-interleaved FEC Protection: Overhead = 1/L o 1-D Non-interleaved FEC Protection: Overhead = 1/L
o 1-D Interleaved FEC Protection: Overhead = 1/D o 1-D Interleaved FEC Protection: Overhead = 1/D
o 2-D Parity FEC Protection: Overhead = 1/L + 1/D o 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, where L and D are the number of columns and rows in the source block,
respectively. respectively.
1.1.7. Repair Window Considerations
The value for the repair window duration depends on the L and D
values and cannot be chosen arbitrarily. More specifically, L and D
values determine the lower limit for the repair window duration. The
upper limit of the repair window duration does not depend on the L
and D values. 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.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Definitions and Notations 3. Definitions and Notations
skipping to change at page 15, line 24 skipping to change at page 13, line 6
source block they pertain to and the relationship between the source block they pertain to and the relationship between the
contained repair packets and the original source block. For this contained repair packets and the original source block. For this
purpose, the RTP header of the repair packets is used, as well as purpose, the RTP header of the repair packets is used, as well as
another header within the RTP payload, called the FEC header, as another header within the RTP payload, called the FEC header, as
shown in Figure 9. shown in Figure 9.
Note that all the source stream packets that are protected by a Note that all the source stream packets that are protected by a
particular FEC packet need to be in the same RTP session. particular FEC packet need to be in the same RTP session.
+------------------------------+ +------------------------------+
| IP Header | | IP Header |
+------------------------------+ +------------------------------+
| Transport Header | | Transport Header |
+------------------------------+ +------------------------------+
| RTP Header | | RTP Header |
+------------------------------+ ---+ +------------------------------+ ---+
| FEC Header | | | FEC Header | |
+------------------------------+ | RTP Payload +------------------------------+ | RTP Payload
| Repair "Payload" | | | Repair "Payload" | |
+------------------------------+ ---+ +------------------------------+ ---+
Figure 9: Format of FEC repair packets Figure 9: Format of FEC repair packets
The Repair "Payload", which follows the FEC Header, includes repair The Repair "Payload", which follows the FEC Header, includes repair
of everything following the fixed 12-byte RTP header of each source of everything following the fixed 12-byte RTP header of each source
packet, including any CSRC identifier list and header extensions if packet, including any CSRC identifier list and header extensions if
present. present.
4.2.1. RTP Header of FEC Repair Packets 4.2.1. RTP Header of FEC Repair Packets
The RTP header is formatted according to [RFC3550] with some further The RTP header is formatted according to [RFC3550] with some further
clarifications listed below: clarifications listed below:
Version (V) 2 bits: This MUST be set to 2 (binary 10), as this Version (V) 2 bits: This MUST be set to 2 (binary 10), as this
specification requires all source RTP packets and all FEC repair specification requires all source RTP packets and all FEC repair
packets to use RTP version 2. The reason for this restriction is packets to use RTP version 2.
the first 2 bits of the FEC header contain other information (R
and F bits) rather than recovering the RTP version field.
Padding (P) bit: Source packets can have optional RTP padding, Padding (P) bit: Source packets can have optional RTP padding,
which can be recovered. FEC repair packets can have optional RTP which can be recovered. FEC repair packets can have optional RTP
padding, which is independent of the RTP padding of the source padding, which is independent of the RTP padding of the source
packets. packets.
Extension (X) bit: Source packets can have optional RTP header Extension (X) bit: Source packets can have optional RTP header
extensions, which can be recovered. FEC repair packets can have extensions, which can be recovered. FEC repair packets can have
optional RTP header extensions, which are independent of the RTP optional RTP header extensions, which are independent of the RTP
header extensions of the source packets. header extensions of the source packets.
skipping to change at page 16, line 38 skipping to change at page 14, line 6
CSRC Count (CC) 4 bits, and CSRC List (CSRC_i) 32 bits each: 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 Source packets can have an optional CSRC list and count, which can
be recovered. FEC repair packets MUST use the CSRC list and count be recovered. FEC repair packets MUST use the CSRC list and count
to specify the SSRC(s) of the source RTP stream(s) protected by to specify the SSRC(s) of the source RTP stream(s) protected by
this FEC repair packet. this FEC repair packet.
Marker (M) bit: This bit is not used for this payload type, and Marker (M) bit: This bit is not used for this payload type, and
SHALL be set to 0 by senders, and SHALL be ignored by receivers. SHALL be set to 0 by senders, and SHALL be ignored by receivers.
Payload Type: The (dynamic) payload type for the FEC repair Payload Type: The (dynamic) payload type for the FEC repair
packets is determined through out-of-band means. Note that this packets is determined through out-of-band means (e.g. SDP). Note
document registers new payload formats for the repair packets that this document registers new payload formats for the repair
(Refer to Section 5 for details). According to [RFC3550], an RTP packets (Refer to Section 5 for details). According to [RFC3550],
receiver that cannot recognize a payload type must discard it. an RTP receiver that cannot recognize a payload type must discard
This provides backward compatibility. If a non-FEC-capable it. This provides backward compatibility. If a non-FEC-capable
receiver receives a repair packet, it will not recognize the receiver receives a repair packet, it will not recognize the
payload type, and hence, will discard the repair packet. payload type, and hence, will discard the repair packet.
Sequence Number (SN): The sequence number follows the standard Sequence Number (SN): The sequence number follows the standard
definition provided in [RFC3550]. definition. Therefore it must definition provided in [RFC3550]. Therefore it must be one higher
be one higher than the sequence number in the previously than the sequence number in the previously transmitted repair
transmitted repair packet, and the initial value of the sequence packet, and the initial value of the sequence number should be
number should be random (i.e. unpredictable). random (i.e. unpredictable).
Timestamp (TS): The timestamp SHALL be set to a time corresponding Timestamp (TS): The timestamp SHALL be set to a time corresponding
to the repair packet's transmission time. Note that the timestamp to the repair packet's transmission time. Note that the timestamp
value has no use in the actual FEC protection process and is value has no use in the actual FEC protection process and is
usually useful for jitter calculations. usually useful for jitter calculations.
Synchronization Source (SSRC): The SSRC value for each repair Synchronization Source (SSRC): The SSRC value for each repair
stream SHALL be randomly assigned as per the guidelines provided stream SHALL be randomly assigned as per the guidelines provided
in Section 8 of [RFC3550]. This allows the sender to multiplex in Section 8 of [RFC3550]. This allows the sender to multiplex
the source and repair RTP streams in the same RTP session, or the source and repair RTP streams in the same RTP session, or
multiplex multiple repair streams in an RTP session. The repair multiplex multiple repair streams in an RTP session. The repair
streams' SSRC's CNAME SHOULD be identical to the CNAME of the streams' SSRC's CNAME SHOULD be identical to the CNAME of the
source RTP stream(s) that this repair stream protects. An FEC source RTP stream(s) that this repair stream protects. An FEC
stream that protects multiple source RTP streams with different stream that protects multiple source RTP streams with different
CNAME's uses the CNAME associated with the entity generating the CNAME's uses the CNAME associated with the entity generating the
FEC stream or the CNAME of the entity on whose behalf it performs FEC stream or the CNAME of the entity on whose behalf it performs
the protection operation. In cases when the repair stream covers the protection operation. In cases when the repair stream covers
packets from multiple source RTP streams with different CNAME packets from multiple source RTP streams with different CNAME
values, any of these CNAME values MAY be used. 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 In some networks, the RTP Source, which produces the source
packets and the FEC Source, which generates the repair packets packets and the FEC Source, which generates the repair packets
from the source packets may not be the same host. In such from the source packets may not be the same host. In such
scenarios, using the same CNAME for the source and repair RTP scenarios, using the same CNAME for the source and repair RTP
streams means that the RTP Source and the FEC Source will share streams means that the RTP Source and the FEC Source will share
the same CNAME (for this specific source-repair stream the same CNAME (for this specific source-repair stream
association). A common CNAME may be produced based on an association). A common CNAME may be produced based on an
algorithm that is known both to the RTP and FEC Source [RFC7022]. algorithm that is known both to the RTP and FEC Source [RFC7022].
This usage is compliant with [RFC3550]. This usage is compliant with [RFC3550].
Note that due to the randomness of the SSRC assignments, there is Note that due to the randomness of the SSRC assignments, there is
a possibility of SSRC collision. In such cases, the collisions a possibility of SSRC collision. In such cases, the collisions
must be resolved as described in [RFC3550]. must be resolved as described in [RFC3550].
4.2.2. FEC Header of FEC Repair Packets 4.2.2. FEC Header of FEC Repair Packets
The format of the FEC header has 3 variants, depending on the values The format of the FEC header has 3 variants, depending on the values
in the first 2 bits (R and F bits) as shown in Figure 10. Two of in the first 2 bits (R and F bits) as shown in Figure 10. Note that
these variants are meant to describe different methods for deriving R and F stand for "retransmit" and "fixed block", respectively. Two
the source data from a source packet for a repair packet. This of these variants are meant to describe different methods for
allows for customizing the FEC method to allow for robustness against deriving the source data from a source packet for a repair packet.
different levels of burst errors and random packet losses. The third This allows for customizing the FEC method to allow for robustness
variant is for a straight retransmission of the source packet. 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
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 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... | |R|F|P|X| CC |M| PT recovery | ...varies depending on R/F... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| ...varies depending on R/F... | | ...varies depending on R/F... |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Repair "Payload" follows FEC Header : : Repair "Payload" follows FEC Header :
: : : :
Figure 10: FEC Header Figure 10: FEC Header
The Repair "Payload", which follows the FEC Header, includes repair The Repair "Payload", which follows the FEC Header, includes repair
of everything following the fixed 12-byte RTP header of each source of everything following the fixed 12-byte RTP header of each source
packet, including any CSRC identifier list and header extensions if packet, including any CSRC identifier list and header extensions if
present. present. An overview on how the repair payload can be used to
recover source packets is provided Section 6.
+---+---+----------------------------------------------------------+ +---+---+----------------------------------------------------------+
| R | F | FEC Header variant | | R | F | FEC Header variant |
+---+---+----------------------------------------------------------+ +---+---+----------------------------------------------------------+
| 0 | 0 | Flexible FEC Mask fields indicate source packets | | 0 | 0 | Flexible FEC Mask fields indicate source packets |
| 0 | 1 | Fixed FEC L/D (cols/rows) fields indicate source packets | | 0 | 1 | Fixed FEC L/D (cols/rows) fields indicate source packets |
| 1 | 0 | Retransmission of a single source packet | | 1 | 0 | Retransmission of a single source packet |
| 1 | 1 | Invalid, MUST NOT send, MUST ignore if received | | 1 | 1 | Invalid, MUST NOT send, MUST ignore if received |
+---+---+----------------------------------------------------------+ +---+---+----------------------------------------------------------+
Figure 11: R and F bit values for FEC Header variants 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 The first variant, when R=0 and F=0, has a mask to signal protected
source packets, as shown in Figure 12. source packets, as shown in Figure 12.
The second variant, when R=0 and F=1, has a number of columns (L) and 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. rows (D) to signal protected source packets, as shown in Figure 13.
skipping to change at page 19, line 46 skipping to change at page 16, line 39
fields: fields:
o The R bit MUST be set to 1 to indicate a retransmission packet, o The R bit MUST be set to 1 to indicate a retransmission packet,
and MUST be set to 0 for FEC repair packets. and MUST be set to 0 for FEC repair packets.
o The F bit indicates the type of FEC repair packets, as shown in 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 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. the R bit is 1 for retransmission packets.
o The P, X, CC, M and PT recovery fields are used to determine the o The P, X, CC, M and PT recovery fields are used to determine the
corresponding fields of the recovered packets. corresponding fields of the recovered packets (see also
Section 6.3.2).
4.2.2.1. FEC Header with Flexible Mask 4.2.2.1. FEC Header with Flexible Mask
When R=0 and F=0, the FEC Header includes flexible mask fields. When R=0 and F=0, the FEC Header includes flexible mask fields.
0 1 2 3 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 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 | |0|0|P|X| CC |M| PT recovery | length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery | | TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SN base_i |k| Mask [0-14] | | SN base_i |k| Mask [0-14] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|k| Mask [15-45] (optional) | |k| Mask [15-45] (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask [46-109] (optional) | | Mask [46-109] (optional) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... next SN base and Mask for CSRC_i in CSRC list ... | | ... next SN base and Mask for CSRC_i in CSRC list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Repair "Payload" follows FEC Header : : Repair "Payload" follows FEC Header :
: : : :
Figure 12: FEC Header for F=0 Figure 12: FEC Header for F=0
o The Length recovery (16 bits) field is used to determine the o The Length recovery (16 bits) field is used to determine the
length of the recovered packets. This length includes all octets length of the recovered packets. This length includes all octets
following the fixed 12-byte RTP header of source packets, following the fixed 12-byte RTP header of source packets,
including CSRC list and optional header extension(s) if present. including CSRC list and optional header extension(s) if present.
It excludes the fixed 12-byte RTP header of source packets. It excludes the fixed 12-byte RTP header of source packets.
skipping to change at page 22, line 6 skipping to change at page 18, line 26
When R=0 and F=1, the FEC Header includes L and D fields for fixed 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 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 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 the RTP Header (not FEC Header) describes the SSRC of the source
packets protected by this particular FEC packet. If there are packets protected by this particular FEC packet. If there are
multiple SSRC's protected by the FEC packet, then there will be 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 multiple blocks of data containing an SN base along with L and D
fields. fields.
0 1 2 3 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 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 | |0|1|P|X| CC |M| PT recovery | length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery | | TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SN base_i | L (columns) | D (rows) | | SN base_i | L (columns) | D (rows) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... next SN base and L/D for CSRC_i in CSRC list ... | | ... next SN base and L/D for CSRC_i in CSRC list ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Repair "Payload" follows FEC Header : : Repair "Payload" follows FEC Header :
: : : :
Figure 13: FEC Header for F=1 Figure 13: FEC Header for F=1
Consequently, the following conditions occur for L and D values: Consequently, the following conditions occur for L and D values:
If L=0, D=0, use the optional payload format parameters for L and D. If L=0, D=0, use the optional payload format parameters for L and D.
If L>0, D=0, indicates Row FEC, and no column FEC will follow. If L>0, D=0, indicates Row FEC, and no column FEC will follow.
Hence, FEC = SN, SN+1, SN+2, ... , SN+(L-1), SN+L. Hence, FEC = SN, SN+1, SN+2, ... , SN+(L-1), SN+L.
If L>0, D=1, indicates Row FEC, and column FEC will follow. If L>0, D=1, indicates Row FEC, and column FEC will follow.
Hence, FEC = SN, SN+1, SN+2, ... , SN+(L-1), SN+L will be Hence, FEC = SN, SN+1, SN+2, ... , SN+(L-1), SN+L will be
produced for each row. produced for each row.
Then FEC = SN, SN+L, SN+2L, ..., SN+(D-1)L will be produced Then FEC = SN, SN+L, SN+2L, ..., SN+(D-1)L will be produced
for each column. for each column.
After all row FEC's have been sent, then the column FEC's After all row FEC's have been sent, then the column FEC's
will be sent. will be sent.
If L>0, D>1, indicates column FEC of every L packet If L>0, D>1, indicates column FEC of every L packet
in a group of D packets starting at SN base. in a group of D packets starting at SN base.
Hence, FEC = SN+(Lx0), SN+(Lx1), ... , SN+(LxD). Hence, FEC = SN+(Lx0), SN+(Lx1), ... , SN+(LxD).
Figure 14: Interpreting the L and D field values 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. The "optional payload
format parameters" (Figure 14) to be used when L=0 and D=0 can be
determined through out-of-band signaling (see Section 5). If L=0 and
D=0 and cannot be determined through out-of-band signaling, 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.
It should be noted that the flexible mask-based approach may be It should be noted that the flexible mask-based approach may be
inefficient for protecting a large number of source packets, or inefficient for protecting a large number of source packets, or
impossible to signal if larger than the largest mask size. In such impossible to signal if larger than the largest mask size. In such
cases, the fixed columns and rows variant may be more useful. cases, the fixed columns and rows variant may be more useful.
4.2.2.3. FEC Header for Retransmissions 4.2.2.3. FEC Header for Retransmissions
When R=1 and F=0, the FEC packet is a retransmission of a single 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 source packet. Note that the layout of this retransmission packet is
different from other FEC repair packets. The sequence number (SN different from other FEC repair packets. The sequence number (SN
skipping to change at page 24, line 22 skipping to change at page 20, line 22
source packet streams (SSRCs). source packet streams (SSRCs).
This FEC header layout is identical to the source RTP (version 2) This FEC header layout is identical to the source RTP (version 2)
packet, starting with its RTP header, where the retransmission packet, starting with its RTP header, where the retransmission
"payload" is everything following the fixed 12-byte RTP header of the "payload" is everything following the fixed 12-byte RTP header of the
source packet, including CSRC list and extensions if present. source packet, including CSRC list and extensions if present.
Therefore, the only operation needed for sending retransmissions is Therefore, the only operation needed for sending retransmissions is
to prepend a new RTP header to the source packet. to prepend a new RTP header to the source packet.
0 1 2 3 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 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 |
|1|0| P|X| CC |M| Payload Type| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC | | SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Retransmission "Payload" follows FEC Header : : Retransmission "Payload" follows FEC Header :
: : : :
Figure 15: FEC Header for Retransmission Figure 15: FEC Header for Retransmission
5. Payload Format Parameters 5. Payload Format Parameters
This section provides the media subtype registration for the non- This section provides the media subtype registration for the non-
interleaved and interleaved parity FEC. The parameters that are interleaved and interleaved parity FEC. The parameters that are
required to configure the FEC encoding and decoding operations are required to configure the FEC encoding and decoding operations are
also defined in this section. If no specific FEC code is specified also defined in this section. If no specific FEC code is specified
skipping to change at page 32, line 9 skipping to change at page 27, line 44
FEC data and is not compatible with any other combination. A FEC data and is not compatible with any other combination. A
sender application may desire to offer multiple offers with sender application may desire to offer multiple offers with
different sets of L and D values as long as the parameter values different sets of L and D values as long as the parameter values
are valid. The receiver SHOULD choose the offer that has a are valid. The receiver SHOULD choose the offer that has a
sufficient amount of interleaving. If multiple such offers exist, sufficient amount of interleaving. If multiple such offers exist,
the receiver may choose the offer that has the lowest overhead or the receiver may choose the offer that has the lowest overhead or
the one that requires the smallest amount of buffering. The the one that requires the smallest amount of buffering. The
selection depends on the application requirements. selection depends on the application requirements.
o The value for the repair-window parameter depends on the L and D o The value for the repair-window parameter depends on the L and D
values and cannot be chosen arbitrarily. More specifically, L and values. Based on the values of L and D, a lower bound on the
D values determine the lower limit for the repair-window size. repair-window can be inferred (see Section 1.1.7).
The upper limit of the repair-window size does not depend on the L
and D values.
o Although combinations with the same L and D values but with o Although combinations with the same L and D values but with
different repair-window sizes produce the same FEC data, such different repair-window sizes produce the same FEC data, such
combinations are still considered different offers. The size of combinations are still considered different offers. The size of
the repair-window is related to the maximum delay between the the repair-window is related to the maximum delay between the
transmission of a source packet and the associated repair packet. transmission of a source packet and the associated repair packet.
This directly impacts the buffering requirement on the receiver This directly impacts the buffering requirement on the receiver
side and the receiver must consider this when choosing an offer. side and the receiver must consider this when choosing an offer.
o Any unknown option in the offer MUST be ignored and deleted from o Any unknown option in the offer must be ignored and deleted from
the answer. If FEC is not desired by the receiver, it can be the answer (see Section 6 of [RFC3264]). If FEC is not desired by
deleted from the answer. the receiver, it can be deleted from the answer.
5.2.2. Declarative Considerations 5.2.2. Declarative Considerations
In declarative usage, like SDP in the Real-time Streaming Protocol In declarative usage, like SDP in the Real-time Streaming Protocol
(RTSP, for RTSP 1.0 see [RFC2326] and for RTSP 2.0 see [RFC7826]) or (RTSP, for RTSP 1.0 see [RFC2326] and for RTSP 2.0 see [RFC7826]) or
the Session Announcement Protocol (SAP) [RFC2974], the following the Session Announcement Protocol (SAP) [RFC2974], the following
considerations apply: considerations apply:
o The payload format configuration parameters are all declarative o The payload format configuration parameters are all declarative
and a participant MUST use the configuration that is provided for and a participant MUST use the configuration that is provided for
skipping to change at page 33, line 20 skipping to change at page 29, line 5
The FEC Header and Repair "Payload" of repair packets are formed by The FEC Header and Repair "Payload" of repair packets are formed by
applying the XOR operation on the bit strings that are generated from applying the XOR operation on the bit strings that are generated from
the individual source packets protected by this particular repair the individual source packets protected by this particular repair
packet. The set of the source packets that are associated with a packet. The set of the source packets that are associated with a
given repair packet can be computed by the formula given in given repair packet can be computed by the formula given in
Section 6.3.1. Section 6.3.1.
The bit string is formed for each source packet by concatenating the The bit string is formed for each source packet by concatenating the
following fields together in the order specified: following fields together in the order specified:
o The first 16 bits of the RTP header (16 bits). o The first 16 bits of the RTP header (16 bits), though the first
two (version) bits will be ignored by the recovery procedure.
o Unsigned network-ordered 16-bit representation of the source o Unsigned network-ordered 16-bit representation of the source
packet length in bytes minus 12 (for the fixed RTP header), i.e., packet length in bytes minus 12 (for the fixed RTP header), i.e.,
the sum of the lengths of all the following if present: the CSRC the sum of the lengths of all the following if present: the CSRC
list, extension header, RTP payload and RTP padding (16 bits). list, extension header, RTP payload and RTP padding (16 bits).
o The timestamp of the RTP header (32 bits). o The timestamp of the RTP header (32 bits).
o All octets after the fixed 12-byte RTP header. (Note the SSRC o All octets after the fixed 12-byte RTP header. (Note the SSRC
field is skipped.) field is skipped.)
skipping to change at page 37, line 19 skipping to change at page 32, line 39
For a given set T, the procedure for the recovery of the RTP header For a given set T, the procedure for the recovery of the RTP header
of the missing packet, whose sequence number is denoted by SEQNUM, is of the missing packet, whose sequence number is denoted by SEQNUM, is
as follows: as follows:
1. For each of the source packets that are successfully received in 1. For each of the source packets that are successfully received in
T, compute the 80-bit string by concatenating the first 64 bits T, compute the 80-bit string by concatenating the first 64 bits
of their RTP header and the unsigned network-ordered 16-bit of their RTP header and the unsigned network-ordered 16-bit
representation of their length in bytes minus 12. representation of their length in bytes minus 12.
2. For the repair packet in T, compute the FEC bit string from the 2. For the repair packet in T, extract the FEC bit string as the
first 80 bits of the FEC header. first 80 bits of the FEC header.
3. Calculate the recovered bit string as the XOR of the bit strings 3. Calculate the recovered bit string as the XOR of the bit strings
generated from all source packets in T and the FEC bit string generated from all source packets in T and the FEC bit string
generated from the repair packet in T. generated from the repair packet in T.
4. Create a new packet with the standard 12-byte RTP header and no 4. Create a new packet with the standard 12-byte RTP header and no
payload. payload.
5. Set the version of the new packet to 2. Skip the first 2 bits 5. Set the version of the new packet to 2. Skip the first 2 bits
skipping to change at page 37, line 46 skipping to change at page 33, line 19
recovered bit string. recovered bit string.
8. Set the CC field to the next 4 bits in the recovered bit string. 8. Set the CC field to the next 4 bits in the recovered bit string.
9. Set the Marker bit in the new packet to the next bit in the 9. Set the Marker bit in the new packet to the next bit in the
recovered bit string. recovered bit string.
10. Set the Payload type in the new packet to the next 7 bits in the 10. Set the Payload type in the new packet to the next 7 bits in the
recovered bit string. recovered bit string.
11. Set the SN field in the new packet to SEQNUM. Skip the next 16 11. Set the SN field in the new packet to SEQNUM.
bits in the recovered bit string.
12. Set the TS field in the new packet to the next 32 bits in the
recovered bit string.
13. Take the next 16 bits of the recovered bit string and set the 12. Take the next 16 bits of the recovered bit string and set the
new variable Y to whatever unsigned integer this represents new variable Y to whatever unsigned integer this represents
(assuming network order). Convert Y to host order. Y (assuming network order). Convert Y to host order. Y
represents the length of the new packet in bytes minus 12 (for represents the length of the new packet in bytes minus 12 (for
the fixed RTP header), i.e., the sum of the lengths of all the the fixed RTP header), i.e., the sum of the lengths of all the
following if present: the CSRC list, header extension, RTP following if present: the CSRC list, header extension, RTP
payload and RTP padding. payload and RTP padding.
13. Set the TS field in the new packet to the next 32 bits in the
recovered bit string.
14. Set the SSRC of the new packet to the SSRC of the missing source 14. Set the SSRC of the new packet to the SSRC of the missing source
RTP stream. RTP stream.
This procedure recovers the header of an RTP packet up to (and This procedure recovers the header of an RTP packet up to (and
including) the SSRC field. including) the SSRC field.
6.3.3. Recovering the RTP Payload 6.3.3. Recovering the RTP Payload
Following the recovery of the RTP header, the procedure for the Following the recovery of the RTP header, the procedure for the
recovery of the RTP "payload" is as follows, where "payload" refers recovery of the RTP "payload" is as follows, where "payload" refers
to everything following the fixed 12-byte RTP header, including to everything following the fixed 12-byte RTP header, including
extensions, CSRC list, true payload and padding. extensions, CSRC list, true payload and padding.
1. Append Y bytes to the new packet. 1. Allocate Y additional bytes for the new packet generated in
Section 6.3.2.
2. For each of the source packets that are successfully received in 2. For each of the source packets that are successfully received in
T, compute the bit string from the Y octets of data starting with T, compute the bit string from the Y octets of data starting with
the 13th octet of the packet. If any of the bit strings the 13th octet of the packet. If any of the bit strings
generated from the source packets has a length shorter than Y, generated from the source packets has a length shorter than Y,
pad them to that length. The zero-padding octets MUST be added pad them to that length. The zero-padding octets MUST be added
at the end of the bit string. Note that the information of the at the end of the bit string. Note that the information of the
first 8 octets are protected by the FEC header. first 8 octets are protected by the FEC header.
3. For the repair packet in T, compute the FEC bit string from the 3. For the repair packet in T, compute the FEC bit string from the
repair packet payload, i.e., the Y octets of data following the repair packet payload, i.e., the Y octets of data following the
FEC header. Note that the FEC header may be different sizes FEC header. Note that the FEC header may be different sizes
depending on the variant and bitmask size. depending on the variant and bitmask size.
4. Calculate the recovered bit string as the XOR of the bit strings 4. Calculate the recovered bit string as the XOR of the bit strings
generated from all source packets in T and the FEC bit string generated from all source packets in T and the FEC bit string
generated from the repair packet in T. generated from the repair packet in T.
5. Append the recovered bit string (Y octets) to the new packet 5. Set the last Y octets in the new packet to the recovered bit
generated in Section 6.3.2. string.
6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC Protection 6.3.4. Iterative Decoding Algorithm for the 2-D Parity FEC Protection
In 2-D parity FEC protection, the sender generates both non- In 2-D parity FEC protection, the sender generates both non-
interleaved and interleaved FEC repair packets to combat with the interleaved and interleaved FEC repair packets to combat with the
mixed loss patterns (random and bursty). At the receiver side, these mixed loss patterns (random and bursty). At the receiver side, these
FEC packets are used iteratively to overcome the shortcomings of the FEC packets are used iteratively to overcome the shortcomings of the
1-D non-interleaved/interleaved FEC protection and improve the 1-D non-interleaved/interleaved FEC protection and improve the
chances of full error recovery. chances of full error recovery.
skipping to change at page 45, line 47 skipping to change at page 39, line 33
corresponding multicast sessions to receive the repair stream(s) that corresponding multicast sessions to receive the repair stream(s) that
is best for them. is best for them.
9. Security Considerations 9. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550] and in any applicable RTP profile. The main specification [RFC3550] and in any applicable RTP profile. The main
security considerations for the RTP packet carrying the RTP payload security considerations for the RTP packet carrying the RTP payload
format defined within this memo are confidentiality, integrity and format defined within this memo are confidentiality, integrity and
source authenticity. Confidentiality is achieved by encrypting the source authenticity. Confidentiality can be provided by encrypting
RTP payload. Integrity of the RTP packets is achieved through a the RTP payload. Integrity of the RTP packets is achieved through a
suitable cryptographic integrity protection mechanism. Such a suitable cryptographic integrity protection mechanism. Such a
cryptographic system may also allow the authentication of the source cryptographic system may also allow the authentication of the source
of the payload. A suitable security mechanism for this RTP payload of the payload. A suitable security mechanism for this RTP payload
format should provide confidentiality, integrity protection, and at format should provide confidentiality, integrity protection, and at
least source authentication capable of determining if an RTP packet least source authentication capable of determining if an RTP packet
is from a member of the RTP session. is from a member of the RTP session.
Note that the appropriate mechanism to provide security to RTP and Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the payloads following this memo may vary. It is dependent on the
application, transport and signaling protocol employed. Therefore, a application, transport and signaling protocol employed. Therefore, a
single mechanism is not sufficient, although if suitable, using the single mechanism is not sufficient, although if suitable, using the
Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended.
Other mechanisms that may be used are IPsec [RFC4301] and Datagram Other mechanisms that may be used are IPsec [RFC4301] and Datagram
Transport Layer Security (DTLS, see [RFC6347]) (RTP over UDP); other Transport Layer Security (DTLS, see [RFC6347]) (RTP over UDP); other
alternatives may exist. alternatives may exist.
Given that FLEX FEC enables the protection of multiple source Given that FLEX FEC enables the protection of multiple source
streams, there exists the possibility that multiple source buffers streams, there exists the possibility that multiple source buffers
may be created that may not be used. An attacker could leverage may be created that may not be used. An attacker could leverage
unused source buffers to as a means of occupying memory in a FLEX FEC unused source buffers to as a means of occupying memory in a FLEX FEC
endpoint. Moreover the application source data may not be perfectly endpoint. In addition, an attack against the FEC parameters
matched with FLEX FEC source partitioning. If this is the case, themselves (e.g. repair window, D or L values) can result in a
there is a possibility for unprotected source data if, for instance, receiver having to allocate source buffer space that may also lead to
the FLEX FEC implementation discards data that does not fit perfectly excessive consumption of resources. Similarly, a network attacker
into its source processing requirements. could modify the recovery fields corresponding to packet lengths
(assuming there are no message integrity mechanisms) which in turn
could force unnecessarily large memory allocations at the receiver.
Moreover the application source data may not be perfectly matched
with FLEX FEC source partitioning. If this is the case, there is a
possibility for unprotected source data if, for instance, the FLEX
FEC implementation discards data that does not fit perfectly into its
source processing requirements.
10. IANA Considerations 10. IANA Considerations
New media subtypes are subject to IANA registration. For the New media subtypes are subject to IANA registration. For the
registration of the payload formats and their parameters introduced registration of the payload formats and their parameters introduced
in this document, refer to Section 5.1. in this document, refer to Section 5.1.
11. Acknowledgments 11. Acknowledgments
Some parts of this document are borrowed from [RFC5109]. Thus, the Some parts of this document are borrowed from [RFC5109]. Thus, the
skipping to change at page 49, line 22 skipping to change at page 43, line 17
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
<https://www.rfc-editor.org/info/rfc7656>. <https://www.rfc-editor.org/info/rfc7656>.
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, Ed., "Real-Time Streaming Protocol and M. Stiemerling, Ed., "Real-Time Streaming Protocol
Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December
2016, <https://www.rfc-editor.org/info/rfc7826>. 2016, <https://www.rfc-editor.org/info/rfc7826>.
[SMPTE2022-1] [SMPTE2022-1]
SMPTE 2022-1-2007, "Forward Error Correction for Real-Time "Forward Error Correction for Real-Time Video/Audio
Video/Audio Transport over IP Networks", 2007. Transport over IP Networks", 2007.
Authors' Addresses Authors' Addresses
Mo Zanaty Mo Zanaty
Cisco Cisco
Raleigh, NC Raleigh, NC
USA USA
Email: mzanaty@cisco.com Email: mzanaty@cisco.com
 End of changes. 105 change blocks. 
173 lines changed or deleted 137 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/