RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting
RFC 7266
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
(Gonzalo Camarillo; former steering group member) Yes
(Spencer Dawkins; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
Pete has my comments covered.
(Benoît Claise; former steering group member) (was Discuss) No Objection
Thanks for addressing my DISCUSS point.
(Brian Haberman; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) (was Discuss) No Objection
Thanks for addressing my DISCUSSion points. One last comment, which Gonzalo could simply change in an RFC Editor note if you decide to do so; you don't need to do a new draft: In section 3: This block reports the media quality in the form of a 1-5 MOS range That's not really precise. Probably better to say: This block reports the media quality in the form of a MOS range (e.g., 1-5, 0-10, or 0-100, as specified by the calculation algorithm)
(Richard Barnes; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
Be nice to expand MOS in the abstract.
(Stewart Bryant; former steering group member) No Objection
(Ted Lemon; former steering group member) (was Discuss) No Objection
After the most recent update to 4.2, the text is still slightly broken:
understand the extension SHOULD NOT include it from the SDP answer
I believe that this should be "SHOULD NOT include it in the SDP answer" instead. The same error repeats in the next paragraph.
---
Former DISCUSS, which has been addressed:
In section 4.2, third paragraph (not counting bullet items above it):
Segment extensions, with their directions, MAY be signaled for an
"inactive" stream. It is an error to use an extension direction
incompatible with the stream direction (e.g., a "sendonly" attribute
for a "recvonly" stream).
How is this error handled? You an address this DISCUSS point by adding text that says how, or pointing out why it isn't a problem.
Comments that have been addressed:
Page 6, first paragraph:
measurement techniques allows much large scale measurements to
This is obviously a typo; could be much larger scale measurements or much large scale measurement. Might want to disambiguate before the copyedit happens to avoid misunderstandings.
In this document, MOS Metrics MAY be reported for intervals or
for the duration of the media stream (cumulative) however it
is not recommended that sampled values are used.
Section 3.2, just above the Reserved heading:
In this document, MOS Metrics MAY be reported for intervals or
for the duration of the media stream (cumulative) however it
is not recommended that sampled values are used.
It might be better to forbid sampled values if they aren't useful, so that implementations don't have to handle them. Just a suggestion—you know better than I. No need to explain if you disagree.