Skip to main content

RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications
RFC 7294

Yes

(Alissa Cooper)

No Objection

(Alia Atlas)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
(Ted Lemon)

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

(Alissa Cooper; former steering group member) Yes

Yes (for -11)

                            

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2014-04-10 for -11)
Thanks. The RFC Editor Note addresses my concerns

(Alia Atlas; former steering group member) No Objection

No Objection (for -11)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2014-04-08 for -11)
Adrian's right, and the block in Section 4 gets it correct -- only Section 3 is wrong (in two places).

(Brian Haberman; former steering group member) No Objection

No Objection (2014-04-07 for -11)
I support Adrian's DISCUSS point.  I followed the chain of related RFCs back to 3550 as far as the definition of an RTP Extension Header goes.  Section 5.3.1 of 3550 says the following:

   The header extension contains a 16-bit length field that
   counts the number of 32-bit words in the extension, excluding the
   four-octet extension header (therefore zero is a valid length).

So, 6 appears to be the correct length for the report structure in 3.1.

(Jari Arkko; former steering group member) No Objection

No Objection (for -11)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -11)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (for -11)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -11)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (2014-04-09 for -11)
Just editorial stuff:

In 3.2 and 4.2, you say things like:

      If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE
      MUST be reported to indicate an over-range measurement.  If the
      measurement is unavailable, the value 0xFFFFFFFF MUST be reported.

You should instead use the style that appears in draft-ietf-xrblock-rtcp-xr-qoe:

      Two values are reserved: A value of 0xFFFE indicates out of range
      and a value of 0xFFFF indicates that the measurement is
      unavailable.

If you wanted to clarify even more, you could say:

      Two values are reserved: A value of 0xFFFFFFFE indicates out of
      range (that is, a measured value exceeding 0xFFFFFFFD) and a value
      of 0xFFFFFFFF indicates that the measurement is unavailable.

The MUSTs are unnecessary. These are definitions, not protocol requirements.

4.2: I would strike the words "For clarification". While reading this, it declarified things for me for a moment. :-)

5.1: No need to redefine DIGIT. Just put a reference to RFC 5234 in section 2.

(Richard Barnes; former steering group member) No Objection

No Objection (for -11)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -11)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2014-04-08 for -11)
- section 2.2 confused me a bit, you said these new
values are in seconds, but then present the binary
fraction encoding. Is that latter really needed for
this one? (Just checking, I assume it is used in some
field.)

(Ted Lemon; former steering group member) No Objection

No Objection (for -11)