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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Jun 2011 15:07:01 +0200

Hi,

I reviewed the draft and have some comments.

1. The intended status says Informational. This document is intended for
standards track.

2. Section 3, paqe 4:
"   Note that in some cases a mixer may be sending an RTP audio stream
   that only contains audio level information and no actual audio.
   Updating a (web) interface conference module may be one reason for
   this to happen."

My question would what value you stick into the payload type field if
you have no payload only header? It is not obvious that you can do this
without configuring a payload format that either is valid for a zero
length payload or define a specific for that case.

3. Section 4 and 5. I find the definition confusing, especially as
important rules of the actual format comes in later sections.
 a) First of all it is not written in generic engough way to support
both the short and long format.
 b) The actual extension formats that is the payload is in the next
section. Including important rules, like that the CSRC list shall be
mapped against the level list.

I would recommend that Section 4 and 5 is merged and that a more ordered
structure to the definition of the header extensions is made. Where
field values are clearly defined including explicit length in bits. And
where the rules around it is separated from the basic field definitions.

4. Section 5. I think the dBov definition needs to be really clear. Yes,
the convention is amplitudes are squared when doing dB calculation. But
it is not clear if this is done for the single highest value in the
measured range, or if it is done as an average over the measured range.
Please provide a definition or a reference.

5. Section 5 and Section 3:

I would note that the folllowing text in section 5:
   The audio level header extension only carries the level of the audio
   in the RTP payload of the packet it is associated with, with no long-
   term averaging or smoothing applied.

Makes it impossible for the following to be done:
Note that in some cases a mixer may be sending an RTP audio stream
   that only contains audio level information and no actual audio.
   Updating a (web) interface conference module may be one reason for
   this to happen.

This as there is no duration of audio indicated, only a first sample.

6. Section 5:
  "The audio level for digital silence, 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 don't like this MAY. To me it appears to only complicate
implementations. Either you mandate the behavior so that one can trust
sources muted by the application to always carry value 127. Or one
anyway need to have noise level detector so that one can determine when
there is signal above the noise level. One may have to have that anyway,
but I think we should consider if we want clear MUTED indication here or
not.

7. Section 6.
"Presence of the above attribute in the SDP description of a media
   stream indicates that some or all RTP packets in that stream would
   contain the audio level information RTP extension header."

To me this sentence is a mix between a usage rule:
"some or all packets may contain the header extension" and a signaling
rule: The presence of the attribute indicates the usage of the audio
level header extension.

In addition it not is the attribute per say that indicate it, it is the
attribute with the given URI is used to indicate that a particular value
is bound to identify the header extension defined in this doc.

8. Section 6.
  "This speicification does not define use of the audio level extensions
   in video streams.  Therefore, the extension defined in this document
   SHOULD NOT be advertised in anything but audio streams."

First spelling error of specification.

Secondly, we also have media types like text, where I also don't see a
logical mapping. Thus I wonder if this should be formulated in a way
that avoids being media specific. I also wonder if there is any point in
leaving the hole with "SHOULD NOT"? Either skip using that and formulate
that it is only defined for audio streams, or some other way?

9. Section 7:
I am missing a reference to the VBR consideration that I think contains
a much better and complete explanation to the issue with just energy
level or similar phonetic structure indicators.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------