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

From: Emil Ivov <[email-masked]>
Date: Wed, 04 May 2011 15:37:34 +0300

Hey Keith, all,

We are about to submit a new version and have addressed most of the
comments raised by you and others on this list. We just wanted to
clarify a couple of things before submitting:

На 28.03.11 13:29, DRAGE, Keith (Keith) написа:
> 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.

Does the following work?

   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 uses "General Mechanism for RTP Header Extensions"
   described in [RFC5285].

> 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. 

I am not sure I understand this comment.

> Surely the main conformance requirement is to
> carry 15 or less audio levels. This results in a maximum encoding of
> 14.

Yes this is what we had in mind and what the text currently says. Is
there a problem with it? Could you maybe suggest a better wording?

> 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.

We don't really change or override anything in here and it's mostly
a clarification. The thinking is that if a conferencing client does not
have conferencing capabilities, then they won't be sending the header
extension and would only be able to receive and process those coming
from the mixer. This translates to

    SHOULD always include the direction parameter in the "extmap"
    attribute setting it to "recvonly"

would it help if we simply removed the 2119 language and otherwise kept
the text as it is?

> 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"

Fixed.

> 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.

Changed.

> 6)	Section 8:
> 
> Add a note to RFC editor saying replace RFC XXXX by the number of
> this RFC.

Added.

> 7)	Section 12.2
> 
> RFC 3920, RFC 3551 appear to not be used as references.

Removed.

> 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.

OK.

> Finally I notice that the summary of changes since the previous
> version has been restricted to the last version. Could I ask that this
> material is reinstated, and we will delete it at the publication
> stage. In pursuance of this, please add a note to the RFC editor to
> delete this material during final editing.

Done. Whatever changelogs existed are back into the document.

We also removed the level renderer and added an overload parameter to
the AudioLevelCalculator as suggested by Peter Musgrave.

Cheers,
Emil

> 
> 
> Regards
> 
> Keith _______________________________________________ avtext mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/avtext
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
http://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: Emil Ivov <[email-masked]>
Date: Wed, 04 May 2011 16:20:54 +0300

Adding to my previous post:

> would it help if we simply removed the 2119 language and otherwise kept

Like this for example:

  Conferencing clients that support audio level indicators and
  have no mixing capabilities would not be able to 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.

Emil

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 4 May 2011 19:11:03 +0200

See below.

I've removed the fixed comments.

Keith

> -----Original Message-----
> From: Emil Ivov [mailto:[email-masked]]
> Sent: 04 May 2011 13:38
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-
> level
> 
> Hey Keith, all,
> 
That works.

> I am not sure I understand this comment.
As written, I found it very different to think of a test for the requirement based only on the MUST.

> there a problem with it? Could you maybe suggest a better wording?
Without investigating deeper I was unclear what the limitation is here. Is the value 15 possible but reserved elsewhere for extension or what.

If the coding already doesn't allow the value 15, but only the values 0 through 14, then I would assume we just need an informative statement pointing out the consequences or the normative requirement.

In the value 15 or more is allowed, then I would suggest just writing a statement that says "Implementations MUST NOT include more than 15 audio level values."

> would it help if we simply removed the 2119 language and otherwise kept
Yes.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 4 May 2011 19:12:21 +0200

Fine by me

Keith

> Sent: 04 May 2011 14:21

---

From: Emil Ivov <[email-masked]>
Date: Thu, 05 May 2011 12:52:39 +0300

Hey Keith,

(inline)

На 04.05.11 20:11, DRAGE, Keith (Keith) написа:
>>> 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.
>>> 
>>> 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.
>> 
>> Yes this is what we had in mind and what the text currently says.
>> Is there a problem with it? Could you maybe suggest a better
>> wording?
>> 
> Without investigating deeper I was unclear what the limitation is
> here. Is the value 15 possible but reserved elsewhere for extension
> or what.
> 
> If the coding already doesn't allow the value 15, but only the values
> 0 through 14, then I would assume we just need an informative
> statement pointing out the consequences or the normative
> requirement.
> 
> In the value 15 or more is allowed, then I would suggest just writing
> a statement that says "Implementations MUST NOT include more than 15
> audio level values."

OK I see. So how about this:

   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.  RFC 3550 [RFC3550] only
   allows RTP packets to carry a maximum of 15 CSRC IDs.  Given that
   audio levels directly refer to CSRC IDs, implementations MUST NOT
   include more than 15 audio level values.  The maximum value allowed
   in the len field is therefore 14.

Emil

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 5 May 2011 11:53:42 +0200

Fine by me.

Keith

> Sent: 05 May 2011 10:53