* Magnus Westerlund wrote:
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.
I think it's confusing to re-iterate the same text in each template; the templates in RFCs are not used out of context, later templates should just reference the first one. I could not immediately find a rationale for registering the same sub type under 4 different top level types. It would be helpful if someone could post one to this list, and it should be added in the introductory section 5.1.
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.
I am not sure from this what the syntax is, the text makes it sound like rate="1001 Hz" might be it. Perhaps something like "The RTP time- stamp (clock) rate in Hz. The rate SHALL be larger than 1000 ..." to make it clearer. Alternatively "an integer ..." like some of the other parameters say.
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.
Here the syntax definition is also just "time".
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.
That's perhaps a bit too promotional and unspecific.
Additional information: None.
(I note that it is common for RTP-only types to omit this section.) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/