Subject: [AVT] Audio Level Indicators - new versions submitted

From: Emil Ivov <[email-masked]>
Date: Thu, 22 Oct 2009 11:25:20 +0200

All,

As requested by the chairs several weeks ago, Jonathan, Enrico and I
have submitted new versions of the client-to-mixer [1] and
mixer-to-client [2] audio level indication drafts. Both documents
reflect comments received on the mailing list such as:

* using a uniform way of encoding level
* add additional considerations/design choices sections
* change tittles so that they would be easier to distinguish from one
another
* others

Needless to say further comments are most welcome.

Cheers,
Emil

[1] - http://tools.ietf.org/html/draft-lennox-avt-rtp-audio-level-exthdr

[2] - http://tools.ietf.org/html/draft-ivov-avt-slic

---

From: Stefan Sayer <[email-masked]>
Date: Thu, 22 Oct 2009 11:57:38 +0200

Hello,

> Needless to say further comments are most welcome.
in [1] 3. Protocol Operation the levels are described as having values 
from 0 to 255, and referencing section 4 (which should be section 5):

    Each instance of this header contains a list of one-octet audio level
    values (see Section 4).  Such values indicate audio level on a 0 to
    255 scale where 0 is silence (i.e. same as omitting the corresponding
    source id from the CSRC list) and 255 corresponds to a threshold
    accepted by the mixer implementation as the maximum audio level that
    a participant is likely to reach during a conference.

while in section 5, the levels are described like in the comfort noise 
specification with values 0..127 being 0..-127 dBov, where 0 would be 
the maximum audio level threshold (not 255).

In [2], section 3,  the MSB of the level field is in the Figure 1 of the 
extension block:

           0                   1                   2
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |  ID   | len=1 |0| level       |V|  reserved   |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So it may make sense to add this to Figure 2 in [1] as well :
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  ID   |  len  |    level 1    |    level 2    |    level 3   ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: Audio level indicators extension format

would become:
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  ID   |  len  |0|  level 1    |0|  level 2    |0|  level 3   ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: Audio level indicators extension format

(or, alternatively remove it from Figure 1 in [2], but I think that it 
is good to have the MSB set to 0 in the Figure.)

Regards
Stefan

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Stefan Sayer
VoIP Services

[email-masked]
www.iptego.com

IPTEGO GmbH
Wittenbergplatz 1
10789 Berlin
Germany

Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann

---

From: Stefan Sayer <[email-masked]>
Date: Thu, 22 Oct 2009 12:52:35 +0200

Hello,

> mixer-to-client [2] audio level indication drafts. Both documents

Why not use the (so far unused) MSB of the audio level in the
mixer-to-client extension header as voice activity flag (live the V in
client-to-mixer) ?

While it is possible for the mixer, it may be impossible for the client 
to accurately determine voice activity of the participants (e.g. the 
spectral information is lost).

The format would then look like this:
     0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  ID   |  len  |V|  level 1    |V|  level 2    |V|  level 3   ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

An open question would be whether this is mandatory, or how a mixer 
could signal that it is not doing voice activity detection (i.e. V will 
be zero all the time).

Stefan

-- 
Stefan Sayer
VoIP Services

[email-masked]
www.iptego.com

IPTEGO GmbH
Wittenbergplatz 1
10789 Berlin
Germany

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 23 Oct 2009 15:25:47 +0200

> the maximum audio level threshold (not 255).

Correct, thanks for pointing it out.

> In [2], section 3,  the MSB of the level field is in the Figure 1 of the 

Agreed, the latter looks definitely better.

-- 
Ciao,
Enrico

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 23 Oct 2009 15:35:13 +0200

> The format would then look like this:

Well, I'd say that could be an optional feature negotiated in the SDP
along with the extension header.

-- 
Ciao,
Enrico

---

From: Emil Ivov <[email-masked]>
Date: Mon, 26 Oct 2009 19:03:29 +0100

Hey Stefan,

>> mixer-to-client extension header as voice activity flag (live the V in

I guess mainly because we didn't see what use a client would have for
such kind of information. However, now I am thinking that ambitious UI
builders might like to use some kind of content dependent color
indication (e.g. red bars for noise and green bars for speech).

> along with the extension header.

I am wondering whether we need to negotiate that at all. If we assume
that we are trying to solve the use case from my example above then we
could go for something like - 0 means the activity of a participant
corresponds to speech or that we don't know what it is (and hence we
show green bars) and 1 means this is most probably noise so the UA would
show the level bars in red.

This would however mean that we'd be assigning a meaning to this bit
which is exactly the opposite of the one in the client-to-mixer draft.
Therefore, assuming we'd like to have the same format in both drafts, we
could either reverse the meaning of the bit in the client-to-mixer draft
(Jonathan, is this an option?) or keep it as it is and rely on SDP to
indicate support for voice detection.

How does this sound?

Emil

---

From: Emil Ivov <[email-masked]>
Date: Tue, 27 Oct 2009 09:40:41 +0100

> the maximum audio level threshold (not 255).

Oops. That slipped in from the previous version, sorry about that. Just
fixed it:

http://tools.ietf.org/html/draft-ivov-avt-slic-02

Thanks!
Emil

---

From: Stefan Sayer <[email-masked]>
Date: Wed, 28 Oct 2009 00:46:33 +0100

Hello,

>> Stefan Sayer wrote:
[...]
> indicate support for voice detection.
I think that there may be applications where the client could really 
make use of voice activity, not only sound levels or noise levels. 
Examples that now come to my mind:
  - UI hint of current speaker(s), e.g. avatar in another color
    (as known from certain web conference services)
  - conference call recording, timeline annotated with who is speaking
  - attenuation or increasing gain if speaker is a certain person
    (e.g. make it louder if someone speaks who is difficult to
    understand otherwise)

It may be worth going through the extra trouble of indicating VAD in SDP 
for these applications, the way Mr Marocco suggested.

Stefan