Forward-Shifted RTP Redundancy Payload Support
RFC 6354

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

(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 -)
No email
send info
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

(Adrian Farrel) (was Discuss) No Objection

Comment (2010-09-09)
No email
send info
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 -)
No email
send info
Expand first occurrence of FEC.