Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100IETF‑orgGroupsStats
in Index   Prev   Next

RFC 8627

RTP Payload Format for Flexible Forward Error Correction (FEC)

Pages: 41
Group: PAYLOAD
Proposed STD
Part 1 of 2 – Pages 1 to 20
None   None   Next

Top   ToC   RFC8627 - Page 1
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.
Top   ToC   RFC8627 - Page 2
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
Top   ToC   RFC8627 - Page 3
   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  . . . . . . . . . . . . . . . . . . . . . . .  41

1.  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.
Top   ToC   RFC8627 - Page 4
   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
Top   ToC   RFC8627 - Page 5
                              +------------+
   +--+    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.
Top   ToC   RFC8627 - Page 6
   +--------------------------------------------------+    ---    +===+
   | 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 Packets

1.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
Top   ToC   RFC8627 - Page 7
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.
Top   ToC   RFC8627 - Page 8
                        +---+         +---+  +---+
                        | 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.
Top   ToC   RFC8627 - Page 9
                     +---+                +---+  +===+
                     | 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
Top   ToC   RFC8627 - Page 10
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.
Top   ToC   RFC8627 - Page 11
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.
Top   ToC   RFC8627 - Page 12
   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.
Top   ToC   RFC8627 - Page 13
   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.
Top   ToC   RFC8627 - Page 14
   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
Top   ToC   RFC8627 - Page 15
      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
Top   ToC   RFC8627 - Page 16
   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).
Top   ToC   RFC8627 - Page 17
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.
Top   ToC   RFC8627 - Page 18
   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
Top   ToC   RFC8627 - Page 19
   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
Top   ToC   RFC8627 - Page 20
   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)

Next Section