A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication
Note: This ballot was opened for revision 06 and is now closed.
(Gonzalo Camarillo) Yes
(Robert Sparks) (was Discuss) Yes
Comment (2011-11-01 for -)
The code in the appendix should be explicitly marked as a code component as indicated in Sean's discuss.
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) No Objection
Comment (2011-10-30 for -)
Same comments as for client-to-mixer (1) If vad can expose encrypted vbr, then why don't the security considerations here say "if encrypting vbr and doing vad then you MUST use apply commemsurate protection to both"? I don't get the logic in the current section 6 where it says "if encrypting vbr and doing vad then you SHOULD use some additional mechanism" - what's the exceptional case that justifies the SHOULD there and why would you ever do something appreciably weaker or stronger? (2) Is the alternative to srtp-encrypted-header-ext to use IPsec or TLS or what? It'd be better to reference those since if you don't then I don't get how srtp-encrypted-header-ext isn't a normative reference? I'd suggest adding a reference to either TLS or IPsec, whichever is more likely to be used.
(Russ Housley) No Objection
(Pete Resnick) No Objection
(Dan Romascanu) No Objection
Comment (2011-10-30 for -)
1. Lionel Morand made in his OPS-DIR review a number of comments which I suggest to be taken into consideration by the authors or RFC Editor: * Overall comment: the document defines a new optional RTP header extension to support a new service capability. However, it should be clarified somewhere (e.g. in the protocol description) the condition of service applicability e.g. all the entities involved need to support this extension. * In section 1, figure 1: even if it is just for illustration, please indicate what would be the meaning of (S) and (M) * In section 3: I'm not a specialist of RTP and use of mixers. However it might be desirable to extend the section dealing with the possible cascade of mixers. It is not obvious how each mixer will be involved along the path. Especially, it is not clear what is the rational that leads to the conclusion: "it is likely that in such situations average audio levels would be perceptibly different for the participants located behind the different mixers." * In section 5, it is said: "Conferencing clients that support audio level indicators and have no mixing capabilities would not be able to provide content for this audio level extension and would hence have to always include the direction parameter in the "extmap" attribute with a value of "recvonly". Conference focus entities with mixing capabilities can omit the direction or set it to "sendrecv" in SDP offers. Such entities would need to set it to "sendonly" in SDP answers to offers with a "recvonly" parameter and to "sendrecv" when answering other "sendrecv" offers." Question: Is the setting of the direction parameter purely informative (sorry for my ignorance)? If not i.e. there are associated requirements, the above text is not appropriate (e.g. "would have to always", "would need") and "MUST" should be used instead. * Figure 4 and 5: The description of each example should be put above the figures. Even if obvious, please indicate for clarification "SDP Offer:" and "SDP Answer:" on top of the lists of SDP parameter. * Figure 4: "A client-initiated example SDP offer/answer exchange negotiating an audio stream with one-way flow of of audio level information." s/one-way flow of of audio/one-way flow of audio 2. Please expand CSRC at first occurence 3. Please replace the conditional language in the first paragraph of the IANA considerations section.
(Peter Saint-Andre) No Objection
(Sean Turner) (was Discuss) No Objection
I noted the same things as Stephen.