Subject: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-level

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 28 Mar 2011 12:29:28 +0200

Again a brief scan and identified some comments:

1)	Section 3:

   This document describes an RTP header extension that allows mixers to
   indicate the audio-level of every conference participant (CSRC) in
   addition to simply indicating their on/off status.  This new header
   extension is based on the "General Mechanism for RTP Header
   Extensions" [RFC5285].

RFC 5285 is a normative reference, and therefore the use of the term "is based" is inappropriate. Need to be much more precise about how RFC 5285 is followed (although some of that is covered by later references.

2)	Section 4:

   The 4-bit len field is the number minus one of data bytes (i.e. audio
   level values) transported in this header extension element following
   the one-byte header.  Therefore, the value zero in this field
   indicates that one byte of data follows.  A value of 15 is not
   allowed by this specification and it MUST NOT be used as the RTP
   header can carry a maximum of 15 CSRC IDs.  The maximum value allowed
   is therefore 14 indicating a following sequence of 15 audio level
   values.

I suspect that any RFC 2119 language here actually belongs in a procedural section, but I was also unclear what the real conformance requirement was here. Surely the main conformance requirement is to carry 15 or less audio levels. This results in a maximum encoding of 14.

3)	Section 6:

   Conferencing clients that support audio level indicators and have no
   mixing capabilities SHOULD always include the direction parameter in
   the "extmap" attribute setting it to "recvonly".  Conference focus
   entities with mixing capabilities MAY omit the direction or set it to
   "sendrecv" in SDP offers.  Such entities SHOULD set it to "sendonly"
   in SDP answers to offers with a "recvonly" parameter and to
   "sendrecv" when answering other "sendrecv" offers.

Is such a requirement in scope of this document? I suspect it ends up updating an existing MMUSIC RFC.

4)	Section 6:

   An example SDP offer/answer exchange between two conference focus
   entities with mixing capabilities negotiating an audio stream with
   bidirectional flwo of audio level information.

Typo "flow"

5)	Section 7:

   2.  Furthermore, the fact that audio level values would not be
       protected even in an SRTP session may be of concern in some cases
       where the activity of a particular participant in a conference is
       confidential.

Change "may" to "can" or "might" to avoid RFC 2119 style sentences.

6)	Section 8:

Add a note to RFC editor saying replace RFC XXXX by the number of this RFC.

7)	Section 12.2

RFC 3920, RFC 3551 appear to not be used as references.

8)	General:

I suspect the editors could do with putting the two drafts side by side and aligning the text from one to the other in the areas where they are both trying to say the same thing. This is not a call for a single document - I think they are distinct in that respect, but there are similarities in the requirements and we should only say similar things in the same way.

Regards

Keith