Forward-Shifted RTP Redundancy Payload Support
RFC 6354

Note: This ballot was opened for revision 08 and is now closed.

Search Mailarchive

(Robert Sparks) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

Comment (2010-09-08 for -)
Section 3., paragraph 7:
>    Note, generally in a forward-shifted session, the timestamp offset in
>    the additional header SHOULD be set to '0'.

  When would it be valid and useful to not set it to zero?


Appendix A., paragraph 0:
> Appendix A.  Anti-shadow Loss Concealment Using Forward-shifted
>              Redundancy

  I assume this appendix is informational, i.e., not part of the
  normative specification. It may be useful to explicitly mark it as
  such.

(Adrian Farrel) (was Discuss) No Objection

Comment (2010-09-09)
Section 2

   The traditional backward-shifted
   redundant encoding scheme (i.e., redundant data is sent after the
   primary data), as currently supported by RFC 2198 [RFC2198], is known
   to be ineffective in dealing with such consecutive frame losses.

It would be useful to provide a reference for this statement.

(David Harrington) No Objection

(Russ Housley) No Objection

Alexey Melnikov (was Discuss) No Objection

(Tim Polk) (was Discuss) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) (was Discuss, No Objection) No Objection

(Sean Turner) No Objection

Comment (2010-09-08 for -)
Expand first occurrence of FEC.