RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting
RFC 7266
Yes
(Gonzalo Camarillo)
(Spencer Dawkins)
No Objection
(Adrian Farrel)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Sean Turner)
(Stewart Bryant)
Note: This ballot was opened for revision 13 and is now closed.
Gonzalo Camarillo Former IESG member
Yes
Yes
(for -13)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(for -13)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -13)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2014-02-05 for -13)
Unknown
Pete has my comments covered.
Benoît Claise Former IESG member
(was Discuss)
No Objection
No Objection
(2014-02-13 for -15)
Unknown
Thanks for addressing my DISCUSS point.
Brian Haberman Former IESG member
No Objection
No Objection
(for -13)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -13)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -13)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -13)
Unknown
Pete Resnick Former IESG member
(was Discuss)
No Objection
No Objection
(2014-02-26 for -16)
Unknown
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 IESG member
No Objection
No Objection
(for -13)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(for -13)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-02-06 for -13)
Unknown
Be nice to expand MOS in the abstract.
Stewart Bryant Former IESG member
No Objection
No Objection
(for -13)
Unknown
Ted Lemon Former IESG member
(was Discuss)
No Objection
No Objection
(2014-02-13 for -15)
Unknown
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.