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

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

I had a brief scan of this document and came up with the following comments:

1)	I suspect that the reference to RFC 5285 will need to end up being a normative reference. While the text currently doesn't support this, I suspect that it is the existing text that is at fault, and this therefore needs to be revised.

2)	Section 3:

   The audio level for digital silence (e.g. all-0 pcmu audio), for
   example for a muted audio source, MAY be represented as 127 (-127
   dBov), regardless of the dynamic range of the encoded audio format.

I am unsure of the meaning of the RFC 2119 language here. Firstly I thought this was mainly an informative section, giving an overview of the existing status and what was needed, and therefore if there is the need for normative language it should be in a different section. Secondly "MAY" defines an option, and I do not see what the option is being defined here. Is this a statement that it is possibly to code this as value 127 (in which case "can") or something else.

3)	Section 6:

   Thus, while information about the correspondance between dB SPL and
   dBov, or encoded audio, could be useful, this document does not
   attempt to define it.  If there are circumstances in which this
   information would be useful, a separate header extension would be
   straightforward to define.  (The information carried by such a header
   extension could indeed be useful independently from the information
   in the header extension defined by this document.)

I wasn't sure whether this was expressing an open issue or not. If it is intended to include material on this in the draft, then we need to define it. If it is merely expressing that such material is out of scope, then it should be much more explicitly stated as out of scope, or just deleted entirely.

4)	Section 7:

   A malicious endpoint could choose to set the values in this header
   extension falsely, so as to falsely claim that audio or voice is or
   is not present.  It is not clear what could be gained by falsely
   claiming that audio is not present, but an endpoint falsely claiming
   that audio is present could perform a denial-of-service attack on an
   audio conference, so as to send silence to suppress other conference
   members' audio.  Thus, a device relying on audio level data from
   untrusted endpoints SHOULD periodically audit the level information
   transmitted, taking appropriate corrective action if endpoints appear
   to be sending incorrect data.  (Note that endpoints MAY choose to
   measure audio levels prior to encoding, so some degree of discrepancy
   SHOULD be tolerated.)

I do not think the RFC 2119 language currently stated in the parentheses is justified. If it is justified, then we need to more clearly state what the requirements really are in a manner that might actually be tested, or at least provide a clear understanding of what is conformant or what is not. I suspect that this text should really just be informative.

5)	Section 8:

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

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

7)	General:

Why are all the examples mu law specific?

Regards

Keith

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 28 Mar 2011 09:40:08 -0400

> 1)	I suspect that the reference to RFC 5285 will need to end up being a normative reference. While the text currently doesn't support this, I suspect that it is the existing text that is at fault,…

RFC 5285 is already listed as a Normative Reference, and I certainly always intended that it should be one.  Is there some text that implies otherwise?

> I am unsure of the meaning of the RFC 2119 language here. Firstly I thought this was mainly an informative section, giving an overview of the existing status and what was needed, and therefore if t…

The option being defined is this: a particular payload format may have (indeed, probably has) a dynamic range of less than 127 dB, and so under a strict reading of the definition of audio level, the audio level of digital silence would therefore have to be greater than -127.  This gives the option of instead coding digital silence as the minimum value.

It would probably be better to move this definition to another section of the document, i.e. the definition of the audio level, to make it more clearly normative.

> I wasn't sure whether this was expressing an open issue or not. If it is intended to include material on this in the draft, then we need to define it. If it is merely expressing that such material…

This is in response to a comment that was raised at a previous IETF; this is summarizing the decision the authors made in response, that it should be out of scope of this document.  I can either clarify this further, or drop the section entirely, as people prefer.

> I do not think the RFC 2119 language currently stated in the parentheses is justified. If it is justified, then we need to more clearly state what the requirements really are in a manner that might…

I agree that this section probably shouldn't use RFC 2119 language.  The "MAY choose to measure levels prior to encoding" text should probably go in the normative definition of the levels, however.

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

Ok.

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

We'll review this.

> Why are all the examples mu law specific?

Mostly because the examples in the RTP Comfort Noise payload format were all mu-law specific.  However, also, it's a payload format with a well-defined dynamic range narrower than of the corresponding Linear PCM, which is interesting and thus non-trivial.  Is there a particular other payload you'd like to see in the examples?  (Linear PCM itself would be the other obvious one to use, I suppose.)

--
Jonathan Lennox
[email-masked]