A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources
RFC 7656

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

(Ben Campbell) Yes

Comment (2015-07-01 for -06)
No email
send info
A few editorial comments:

-- section 1: "in Real-Time Transport Protocol"

in _the_ Real-Time Transport Protocol...

"... has previously often been"

has previously been 

-- 4.1 and children:

It's confusing figuring out which section references are to CLUE vs to other sections in this document.

Alissa Cooper (was No Objection) Yes

Comment (2015-07-08 for -07)
No email
send info
Thanks for all your work on this. Caught some nits below.

= Sec 2.1.3 =

s/The time progressing stream/A Raw Stream is the time progressing stream/

= Sec 2.1.5 =

s/A stream of digital samples/A Source Stream is a stream of digital samples/

= Sec 2.1.6 =

s/Such Media Encoder produce/Such Media Encoders produce/

= Sec 2.1.9 =

s/and put their content/and putting their content/

= Sec 2.1.10 =

s/A stream of RTP packets/An RTP Stream is a stream of RTP packets/

= Sec 2.1.12 =

s/A RTP Stream (Section 2.1.10) that contains/A Redundancy RTP Stream is an RTP Stream (Section 2.1.10) that contains/

= Sec 2.1.19 =

s/The RTP Stream that is emitted/The Transported RTP Stream is the RTP Stream that is emitted/

= Sec 2.1.20 =

s/The receiver Endpoint's (Section 2.2.1) transformation/The Media Transport Receiver is the receiver Endpoint's (Section 2.2.1) transformation/

= Sec 2.1.23 =

s/The RTP Stream (Section 2.1.10) resulting/The Received RTP Stream is the RTP Stream (Section 2.1.10) resulting/

= Sec 2.1.24 =

s/The Redundancy RTP Stream (Section 2.1.12) resulting/The Received Redundancy RTP Stream is the Redundancy RTP Stream (Section 2.1.12) resulting/

= Sec 2.1.26 =

s/A Received RTP Stream (Section 2.1.23) for which/A Repaired RTP Stream is a Received RTP Stream (Section 2.1.23) for which/

= Sec 2.1.28 =

s/The received version of/The Received Encoded Stream is the received version of/

= Sec 2.1.30 =

s/The received version of a Source Stream/The Received Source Stream is the received version of a Source Stream/

= Sec 3.1.32 =

s/The received version of a Raw Stream/The Received Raw Stream is the received version of a Raw Stream/

= Sec 2.2.1 =

s/A single addressable entity/An Endpoint is a single addressable entity/

(Spencer Dawkins) Yes

Comment (2015-07-09 for -07)
No email
send info
Wow, I wish we'd had this document when RTCWeb and CLUE were starting in parallel! Thank you all for producing it.

Jitter is called out separately from delay in 2.1.16, but not in 2.1.18, 2.1.23, or 2.1.24. Was that intentional?

2.1.16 also calls out inter packet spacings separately. I'm not sure if that's also relevant in 2.1.18, 2.1.23, or 2.1.24, but wanted to ask.

Barry Leiba Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2015-07-08 for -07)
No email
send info
Thanks for this document. I particularly like the figures 1, 2 and 7, as entry points in the document.

For completeness, you might consider:
- adding a few words about the boundary between analog and digital (in the Physical Stimulus, I guess)
- inserting in figure 7 that a RTP session "is a group communications channel which can potentially carry a number of RTP Streams"

(Stephen Farrell) No Objection

(Joel Jaeggli) No Objection

(Terry Manderson) No Objection

Comment (2015-07-07 for -07)
No email
send info
A comprehensive document, and only a small comment that should be easy to clarify if I have misinterpreted.

4.14.  SSRC

It might be my stylistic approach, but I prefer the more complete definition from RFC3550 (Section 3:) that starts with:

"Synchronization source (SSRC): ..."

I understand that the document is long, but do consider that if a reader finds this tome the words provided in 4.14 don't seem to fix the opacity problem the draft is addressing.

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

Comment (2015-07-09 for -07)
No email
send info
While I won't stand in the way of publishing this document, I think that it may be better suited to live on in a Wiki where it can be updated in a more fluent fashion.  I didn't get a particularly warm fuzzy feeling from phrases like these: "This document provides *some* clarity..." or "For each concept *an attempt is made*...".  That text can be made firmer, but the point remains: it is probable that the concepts could be refined and the taxonomy may evolve.

(Martin Stiemerling) No Objection