Skip to main content

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 steering group member) Yes

Yes (for -13)

                            

(Spencer Dawkins; former steering group member) Yes

Yes (for -13)

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (for -13)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2014-02-05 for -13)
Pete has my comments covered.

(Benoît Claise; former steering group member) (was Discuss) No Objection

No Objection (2014-02-13 for -15)
Thanks for addressing my DISCUSS point.

(Brian Haberman; former steering group member) No Objection

No Objection (for -13)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -13)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -13)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -13)

                            

(Pete Resnick; former steering group member) (was Discuss) No Objection

No Objection (2014-02-26 for -16)
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

No Objection (for -13)

                            

(Sean Turner; former steering group member) No Objection

No Objection (for -13)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2014-02-06 for -13)
Be nice to expand MOS in the abstract.

(Stewart Bryant; former steering group member) No Objection

No Objection (for -13)

                            

(Ted Lemon; former steering group member) (was Discuss) No Objection

No Objection (2014-02-13 for -15)
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.