RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting

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

(Richard Barnes) Yes

(Gonzalo Camarillo) Yes

(Spencer Dawkins) Yes

Comment (2013-06-21 for -12)
No email
send info
In 3.  Jitter Buffer Operation

   Overall user perceived delay = network round trip delay + local
   (jitter buffer (nominal) delay + encoder serialization delay) +
   remote (jitter buffer (nominal) delay + encoder serialization delay)

This is likely a stupid question, but are both local and remote serialization delays "encoder" delays? Or are "decoder" delays negligible? Or am I missing a term of RTCP art?

In 5.  SDP Signaling

   [RFC3611] defines the use of SDP (Session Description Protocol)
   [RFC4566] for signaling the use of XR blocks.  However XR blocks MAY
   be used without prior signaling (see section 5 of RFC3611).

This text is saying, to me:

- You can signal the use of XR blocks in SDP,

- or not

- but if you do signal the use of XR blocks in SDP, here's how you would do that for JB

Is there any guidance you can give about which choice an implementer should lean toward?

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) No Objection

Comment (2013-06-26 for -12)
No email
send info
Same remark as for draft-ietf-xrblock-rtcp-xr-discard. jitter buffer versus de-jitter buffer. I know it's mentioned in section 1.4, but some changes would ideal. The draft is not consistent.

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection