Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams

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

Barry Leiba Yes

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-06-16)
Thank you for addressing my Discuss point.

A couple things I noticed while reviewing the diff:

Section 3.1's "might not be the choice suitable in another
situation or combination of reasons" seems like it's comparing things of different types.

Section 4.3.1 now has:

   SRTP [RFC3711] as specified uses per SSRC unique keys, however the
   original assumption was a single session master key from which SSRC
   specific RTP and RTCP keys where derived.  However, that assumption
   was proven incorrect, as the application usage and the developed key-
   mamangement mechanisms have chosen many different methods for
   ensuring SSRC unique keys.  The key-management functions have

I didn't try to look at RFC 3711 and see if there was now-believed-to-be-incorrect
text in need of an update or not.  I guess any potential violations of 3711 are
in the "application usage and the developed-key-management techniques" that
we describe, not in this document itself, so there's not really a question of this
document being in conflict with 3711.
Also, nit: s/mamangement/management/

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2020-03-03 for -11)
No email
send info
Thank you for an interesting, and readable document.

(Mirja Kühlewind) No Objection

Comment (2020-03-02 for -11)
One processing question: Should this document update RFC3550 given the last paragraph each in section 3.4.1 and 3.4.3?

And one comment on section 4.2.1:
"Different Differentiated
   Services Code Points (DSCP) can be assigned to different packets
   within a flow as well as within an RTP stream. "
not sure what you mean by flow here but at least RFC7657 says
"Should use a single DSCP for all packets within a reliable
      transport protocol session"
Maybe you can say a bit more here to ensure the guidance provided in RFC7657 is reflected accurately.

Even though I didn't see any discussion of the TSV-ART review (Thanks Bernard!) I believe all comments have been addressed. Thanks for that!

Fully editorial minor comments:
1) In the intro maybe:
 The authors hope that clarification on the usefulness
   of some functionalities in RTP will result in more complete
   implementations in the future.
This document aims to clarify the usefulness
   of some functionalities in RTP which will hopefully result in more complete
   implementations in the future.

2) sec 3.2
s/one or transport flows/one or more transport flows/
And maybe also
s/transport flows, e.g. an UDP destination port./transport flows, e.g. based on the UDP destination port./?

3) sec 3.2.1:
"   RTP does not contain a session identifier, yet different RTP sessions
   must be possible to identify both across different endpoints and
   within a single endpoint."
Not sure I can parse this sentence correctly...

4) sec 4.1.3:
s/Signalling, choosing and policing/Signalling, choosing, and policing/ -> missing comma

5) sec 6 maybe:
s/specification writers/specification designers/

(Alexey Melnikov) No Objection

Alvaro Retana No Objection

(Adam Roach) No Objection

Éric Vyncke No Objection

Magnus Westerlund (was Abstain) Recuse

Comment (2020-02-17 for -10)
No email
send info
I am a co-author