Subject: [ietf-types] registeration of audio/video/text/application flexfec media subtypes

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 22 Nov 2018 13:52:28 +0000

Hi,
RTP payload formats for the Forward Error Correction (FEC)
in https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11    is ready for publication as a Payload WG document

The document registers flexfec subtype

The new registration is in Section 5.1 of the document and is also given below.

Comments on the registration are welcome.

Thanks.

Roni Even

Payload WG co-chair

5.1.1<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-5.1.1>.  Registration of audio/flexfec
   Type name: audio

   Subtype name: flexfec

   Required parameters:

   o  rate: The RTP timestamp (clock) rate.  The rate SHALL be larger
      than 1000 Hz to provide sufficient resolution to RTCP operations.
      However, it is RECOMMENDED to select the rate that matches the
      rate of the protected source RTP stream.

   o  repair-window: The time that spans the source packets and the
      corresponding repair packets.  The size of the repair window is
      specified in microseconds.

   Optional parameters:

   o  L: indicates the number of columns of the source block that are
      protected by this FEC block and it applies to all the source
      SSRCs.  L is a positive integer.

   o  D: indicates the number of rows of the source block that are
      protected by this FEC block and it applies to all the source
      SSRCs.  D is a positive integer.

   o  ToP: indicates the type of protection applied by the sender: 0 for
      1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC
      protection, 2 for 2-D parity FEC protection, and 3 for
      retransmission.  There can only be one value listed for ToP.

   Note that both L and D in the optional parameters should follow the
   value pairings stated in Section 4.2.2.2<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-4.2.2.2> if included.

   Encoding considerations: This media type is framed (See Section 4.8<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-4.8>
   in the template document [RFC6838<https://tools.ietf.org/html/rfc6838>]) and contains binary data.

   Security considerations: See Section 9<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-9> of [RFCXXXX].

   Interoperability considerations: None.

   Published specification: [RFCXXXX].

   Applications that use this media type: Multimedia applications that
   want to improve resiliency against packet loss by sending redundant
   data in addition to the source media.

   Fragment identifier considerations: None.

   Additional information: None.

   Person & email address to contact for further information: Varun
   Singh <[email-masked]> and IETF Audio/Video Transport Payloads
   Working Group.
   Intended usage: COMMON.

   Restriction on usage: This media type depends on RTP framing, and
   hence, is only defined for transport via RTP [RFC3550<https://tools.ietf.org/html/rfc3550>].

   Author: Varun Singh <[email-masked]>.

   Change controller: IETF Audio/Video Transport Working Group delegated
   from the IESG.

   Provisional registration? (standards tree only): Yes.

5.1.2<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-5.1.2>.  Registration of video/flexfec
   Type name: video

   Subtype name: flexfec

  Required parameters:

   o  rate: The RTP timestamp (clock) rate.  The rate SHALL be larger
      than 1000 Hz to provide sufficient resolution to RTCP operations.
      However, it is RECOMMENDED to select the rate that matches the
      rate of the protected source RTP stream.

   o  repair-window: The time that spans the source packets and the
      corresponding repair packets.  The size of the repair window is
      specified in microseconds.

   Optional parameters:

   o  L: indicates the number of columns of the source block that are
      protected by this FEC block and it applies to all the source
      SSRCs.  L is a positive integer.

   o  D: indicates the number of rows of the source block that are
      protected by this FEC block and it applies to all the source
      SSRCs.  D is a positive integer.

   o  ToP: indicates the type of protection applied by the sender: 0 for
      1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC
      protection, 2 for 2-D parity FEC protection, and 3 for
      retransmission.  There can only be one value listed for ToP.

   Note that both L and D in the optional parameters should follow the
   value pairings stated in Section 4.2.2.2<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-4.2.2.2> if included.

   Encoding considerations: This media type is framed (See Section 4.8<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-4.8>
   in the template document [RFC6838<https://tools.ietf.org/html/rfc6838>]) and contains binary data.

   Security considerations: See Section 9<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-9> of [RFCXXXX].

   Interoperability considerations: None.

   Published specification: [RFCXXXX].

   Applications that use this media type: Multimedia applications that
   want to improve resiliency against packet loss by sending redundant
   data in addition to the source media.

   Fragment identifier considerations: None.

   Additional information: None.

   Person & email address to contact for further information: Varun
   Singh <[email-masked]> and IETF Audio/Video Transport Payloads
   Working Group.

   Intended usage: COMMON.

   Restriction on usage: This media type depends on RTP framing, and
   hence, is only defined for transport via RTP [RFC3550<https://tools.ietf.org/html/rfc3550>].

   Author: Varun Singh <[email-masked]>.

   Change controller: IETF Audio/Video Transport Working Group delegated
   from the IESG.

   Provisional registration? (standards tree only): Yes.

5.1.3<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-5.1.3>.  Registration of text/flexfec
   Type name: text

   Subtype name: flexfec

   Required parameters:

   o  rate: The RTP timestamp (clock) rate.  The rate SHALL be larger
      than 1000 Hz to provide sufficient resolution to RTCP operations.
      However, it is RECOMMENDED to select the rate that matches the
      rate of the protected source RTP stream.

   o  repair-window: The time that spans the source packets and the
      corresponding repair packets.  The size of the repair window is
      specified in microseconds.

   Optional parameters:

   o  L: indicates the number of columns of the source block that are
      protected by this FEC block and it applies to all the source
      SSRCs.  L is a positive integer.

   o  D: indicates the number of rows of the source block that are
      protected by this FEC block and it applies to all the source
      SSRCs.  D is a positive integer.

   o  ToP: indicates the type of protection applied by the sender: 0 for
      1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC
      protection, 2 for 2-D parity FEC protection, and 3 for
      retransmission.  There can only be one value listed for ToP.

   Note that both L and D in the optional parameters should follow the
   value pairings stated in Section 4.2.2.2<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-4.2.2.2> if included.

   Encoding considerations: This media type is framed (See Section 4.8<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-4.8>
   in the template document [RFC6838<https://tools.ietf.org/html/rfc6838>]) and contains binary data.

   Security considerations: See Section 9<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-9> of [RFCXXXX].

   Interoperability considerations: None.

   Published specification: [RFCXXXX].

   Applications that use this media type: Multimedia applications that
   want to improve resiliency against packet loss by sending redundant
   data in addition to the source media.

   Fragment identifier considerations: None.

   Additional information: None.

   Person & email address to contact for further information: Varun
   Singh <[email-masked]> and IETF Audio/Video Transport Payloads
   Working Group.

   Intended usage: COMMON.

   Restriction on usage: This media type depends on RTP framing, and
   hence, is only defined for transport via RTP [RFC3550<https://tools.ietf.org/html/rfc3550>].

   Author: Varun Singh <[email-masked]>.

   Change controller: IETF Audio/Video Transport Working Group delegated
   from the IESG.

   Provisional registration? (standards tree only): Yes.

5.1.4<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-5.1.4>.  Registration of application/flexfec
   Type name: application

   Subtype name: flexfec

   Required parameters:

   o  rate: The RTP timestamp (clock) rate.  The rate SHALL be larger
      than 1000 Hz to provide sufficient resolution to RTCP operations.
      However, it is RECOMMENDED to select the rate that matches the
      rate of the protected source RTP stream.

   o  repair-window: The time that spans the source packets and the
      corresponding repair packets.  The size of the repair window is
      specified in microseconds.

   Optional parameters:

   o  L: indicates the number of columns of the source block that are
      protected by this FEC block and it applies to all the source
      SSRCs.  L is a positive integer.

   o  D: indicates the number of rows of the source block that are
      protected by this FEC block and it applies to all the source
      SSRCs.  D is a positive integer.

   o  ToP: indicates the type of protection applied by the sender: 0 for
      1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC
      protection, 2 for 2-D parity FEC protection, and 3 for
      retransmission.  There can only be one value listed for ToP.

   Note that both L and D in the optional parameters should follow the
   value pairings stated in Section 4.2.2.2<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-4.2.2.2> if included.

   Encoding considerations: This media type is framed (See Section 4.8<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-4.8>
   in the template document [RFC6838<https://tools.ietf.org/html/rfc6838>]) and contains binary data.

   Security considerations: See Section 9<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11#section-9> of [RFCXXXX].

   Interoperability considerations: None.

   Published specification: [RFCXXXX].

   Applications that use this media type: Multimedia applications that
   want to improve resiliency against packet loss by sending redundant
   data in addition to the source media.

   Fragment identifier considerations: None.

   Additional information: None.

   Person & email address to contact for further information: Varun
   Singh <[email-masked]> and IETF Audio/Video Transport Payloads
   Working Group.

   Intended usage: COMMON.

   Restriction on usage: This media type depends on RTP framing, and
   hence, is only defined for transport via RTP [RFC3550<https://tools.ietf.org/html/rfc3550>].

   Author: Varun Singh <[email-masked]>.

   Change controller: IETF Audio/Video Transport Working Group delegated
   from the IESG.

   Provisional registration? (standards tree only): Yes.