RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)
Note: This ballot was opened for revision 09 and is now closed.
Magnus Westerlund Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Ralph Droms) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
(Pasi Eronen) No Objection
(Adrian Farrel) No Objection
(Russ Housley) (was Discuss) No Objection
Alexey Melnikov (was Discuss) No Objection
Comment (2010-01-11 for -** No value found for 'p.get_dochistory.rev' **)
After Magnus explained limitation of SDP regarding use of MIME types (the same top level MIME type has to be used for all media streams), I remove my DISCUSS about registration of text/1d-interleaved-parityfec. I wish SDP didn't have this limitation, but not much I can do about that anyway. Comments from ietf-types review (see <http://eikenes.alvestrand.no/pipermail/ietf-types/2009-December/002300.html>): >> 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. Magnus replied: Yes, I would agree, because the value is just the integer "rate=1001".
(Tim Polk) No Objection
(Dan Romascanu) No Objection
(Robert Sparks) (was No Record, Discuss) No Objection
Would it make sense to explain the relationship of this document and 5109 (which obsoleted 2733 and 3009) in section 1.3?