Hi, This document http://www.ietf.org/id/draft-ietf-fecframe-interleaved-fec-scheme-06.txt has been through an IETF last call. Unfortunately this hasn't been announced on this list either in WG last call or when the IETF last call started. Thus I would like a review before bringing this to the IESG. I would be thankful if the review could happen before the 7th of January. However, if a committed reviewer needs additional time due to the holidays that can be granted. But please tell me so that I can postpone the IESG review. Here is the media type template for the 4 types present in this document. 5.1. Media Type Registration This registration is done using the template defined in [RFC4288] and following the guidance provided in [RFC3555]. Note to the RFC Editor: In the following sections, please replace "XXXX" with the number of this document prior to publication as an RFC. 5.1.1. Registration of audio/1d-interleaved-parityfec Type name: audio Subtype name: 1d-interleaved-parityfec 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 L: Number of columns of the source block. L is a positive integer that is less than or equal to 255. o D: Number of rows of the source block. D is a positive integer that is less than or equal to 255. o repair-window: The time that spans the source packets and the corresponding repair packets. An FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration. At the receiver, the FEC decoder tries to decode all the packets received within the repair window to recover the missing packets. Assuming that there is no issue of delay variation, the FEC decoder SHOULD NOT wait longer than the repair window since additional waiting would not help the recovery process. The size of the repair window is specified in microseconds. Optional parameters: None. Encoding considerations: This media type is framed (See Section 4.8 in the template document [RFC4288]) and contains binary data. Security considerations: See Section 9 of [RFCXXXX]. Interoperability considerations: None. Begen Expires June 18, 2010 [Page 15] Internet-Draft RTP Payload Format for Interleaved FEC December 2009 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. Additional information: None. Person & email address to contact for further information: Ali Begen <abegen@cisco.com> and IETF Audio/Video Transport 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]. Author: Ali Begen <abegen@cisco.com>. Change controller: IETF Audio/Video Transport Working Group delegated from the IESG. 5.1.2. Registration of video/1d-interleaved-parityfec Type name: video Subtype name: 1d-interleaved-parityfec 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 L: Number of columns of the source block. L is a positive integer that is less than or equal to 255. o D: Number of rows of the source block. D is a positive integer that is less than or equal to 255. o repair-window: The time that spans the source packets and the corresponding repair packets. An FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration. At the receiver, the FEC decoder tries to decode all the packets received within the repair window to recover the missing packets. Assuming that there is no issue of delay variation, the FEC decoder SHOULD NOT wait longer than the repair window since additional waiting would not Begen Expires June 18, 2010 [Page 16] Internet-Draft RTP Payload Format for Interleaved FEC December 2009 help the recovery process. The size of the repair window is specified in microseconds. Optional parameters: None. Encoding considerations: This media type is framed (See Section 4.8 in the template document [RFC4288]) and contains binary data. Security considerations: See 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. Additional information: None. Person & email address to contact for further information: Ali Begen <abegen@cisco.com> and IETF Audio/Video Transport 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]. Author: Ali Begen <abegen@cisco.com>. Change controller: IETF Audio/Video Transport Working Group delegated from the IESG. 5.1.3. Registration of text/1d-interleaved-parityfec Type name: text Subtype name: 1d-interleaved-parityfec 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 L: Number of columns of the source block. L is a positive integer that is less than or equal to 255. Begen Expires June 18, 2010 [Page 17] Internet-Draft RTP Payload Format for Interleaved FEC December 2009 o D: Number of rows of the source block. D is a positive integer that is less than or equal to 255. o repair-window: The time that spans the source packets and the corresponding repair packets. An FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration. At the receiver, the FEC decoder tries to decode all the packets received within the repair window to recover the missing packets. Assuming that there is no issue of delay variation, the FEC decoder SHOULD NOT wait longer than the repair window since additional waiting would not help the recovery process. The size of the repair window is specified in microseconds. Optional parameters: None. Encoding considerations: This media type is framed (See Section 4.8 in the template document [RFC4288]) and contains binary data. Security considerations: See 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. Additional information: None. Person & email address to contact for further information: Ali Begen <abegen@cisco.com> and IETF Audio/Video Transport 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]. Author: Ali Begen <abegen@cisco.com>. Change controller: IETF Audio/Video Transport Working Group delegated from the IESG. 5.1.4. Registration of application/1d-interleaved-parityfec Type name: application Begen Expires June 18, 2010 [Page 18] Internet-Draft RTP Payload Format for Interleaved FEC December 2009 Subtype name: 1d-interleaved-parityfec 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 L: Number of columns of the source block. L is a positive integer that is less than or equal to 255. o D: Number of rows of the source block. D is a positive integer that is less than or equal to 255. o repair-window: The time that spans the source packets and the corresponding repair packets. An FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration. At the receiver, the FEC decoder tries to decode all the packets received within the repair window to recover the missing packets. Assuming that there is no issue of delay variation, the FEC decoder SHOULD NOT wait longer than the repair window since additional waiting would not help the recovery process. The size of the repair window is specified in microseconds. Optional parameters: None. Encoding considerations: This media type is framed (See Section 4.8 in the template document [RFC4288]) and contains binary data. Security considerations: See 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. Additional information: None. Person & email address to contact for further information: Ali Begen <abegen@cisco.com> and IETF Audio/Video Transport Working Group. Intended usage: COMMON. Begen Expires June 18, 2010 [Page 19] Internet-Draft RTP Payload Format for Interleaved FEC December 2009 Restriction on usage: This media type depends on RTP framing, and hence, is only defined for transport via RTP [RFC3550]. Author: Ali Begen <abegen@cisco.com>. Change controller: IETF Audio/Video Transport Working Group delegated from the IESG. Thanks Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------