Request to review type in draft-ietf-fecframe-interleaved-fec-scheme
Magnus Westerlund
magnus.westerlund at ericsson.com
Wed Dec 16 09:57:44 CET 2009
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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at ericsson.com
----------------------------------------------------------------------
More information about the Ietf-types
mailing list