Subject: [AVT] Sound level indicators

From: "Jonathan Lennox" <[email-masked]>
Date: Wed, 17 Jun 2009 16:11:39 -0400

Hi all,

I've just submitted the following draft:

http://www.ietf.org/internet-drafts/draft-lennox-avt-rtp-audio-level-ext
hdr-00.txt

The draft addresses a similar, though not identical, issue, to
draft-ivov-avt-slic-00.

It defines an RTP extension header which indicates the audio level, and
voice activity detection state, of a packet's RTP audio payload.  In
large conferences, this can reduce the load on an audio mixer or other
middlebox which wants to forward only a few of the loudest audio
streams, without requiring it to decode and measure every stream it's
receiving.

Comments are welcome!

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

---

From: "Slava Borilin" <[email-masked]>
Date: Thu, 18 Jun 2009 00:21:13 +0400

Jonathan, 

You link doesn't open (

regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Lennox
Sent: Thursday, June 18, 2009 12:12 AM
To: [email-masked]
Subject: [AVT] Sound level indicators

Hi all,

Comments are welcome!

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

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

---

From: "Jonathan Lennox" <[email-masked]>
Date: Wed, 17 Jun 2009 16:23:40 -0400

Apologies -- my e-mail client seems to have decided to word-wrap the URL.

I'm sending this again using another client.  The URL should be:

http://www.ietf.org/internet-drafts/draft-lennox-avt-rtp-audio-level-exthdr-00.txt

The URL ends with ".txt" in case it's word-wrapped again.

-----Original Message-----
From: Slava Borilin [mailto:[email-masked]]
Sent: Wed 6/17/2009 4:21 PM
To: Jonathan Lennox; [email-masked]
Subject: RE: [AVT] Sound level indicators
 
Jonathan, 

You link doesn't open (

regards,
Slava Borilin

-----Original Message-----

Hi all,

Comments are welcome!

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 18 Jun 2009 16:25:04 +0200

> streams, without requiring it to decode and measure every stream it's

I may have not given enough thought to all the side issues, but it seems
to me that the two drafts deal with the very same kind of information
(and thus its encoding should be specified in only one place).

To me, the main issue with passing the sound level of a non-mixed stream
has to do with the fact that the RTP header is not going to be encrypted
when using SRTP: an in-line attacker could mute a conference participant
just mangling such value or, if the header is integrity protected,
dropping those packets where voice activity is reported.

-- 
Ciao,
Enrico

---

From: "Jonathan Lennox" <[email-masked]>
Date: Thu, 18 Jun 2009 11:32:04 -0400

Enrico Marocco [mailto:[email-masked]] writes: 

> I may have not given enough thought to all the side issues, but it 
> seems to me that the two drafts deal with the very same kind of
> information (and thus its encoding should be specified in only one
> place).

I absolutely agree that these drafts should be aligned as closely as
possible.

I also agree that standardizing encoding is a good idea -- this is why
my draft copies its definition and encoding of audio level from the
Comfort Noise payload. 

I'd be open to combining the two drafts, if the WG agrees that both
issues are worth working on, and feels that having a single document
addressing multiple issues is better than having two documents that
inevitably repeat or cross-reference information.

(Technically, I believe that having separate extension headers for "ssrc
level" and "csrc levels" is a good idea, but that's orthogonal to the
issue of document structure.)

> To me, the main issue with passing the sound level of a non-mixed
> stream to do with the fact that the RTP header is not going to be
> encrypted when using SRTP: an in-line attacker could mute a
> conference participant just mangling such value or, if the header
> is integrity protected, dropping those packets where voice activity
> is reported.

I'm not so worried about the first point -- SRTP strongly disrecommends
using encryption without authentication (which covers headers), and any
environment in which you're not willing to pay for the bandwidth
overhead of SRTP authentication is probably one in which you're not
willing to have extension headers either.

The second point is more of an issue, but the issue I'm most concerned
about is the fact (with either draft) that a passive attacker can see a
real-time waveform (at ptime resolution) of a participant's, or each
participant's, audio.

I've been pondering an SRTP extension to encrypt selected extension
headers; I think this might end up being necessary for both of these
drafts.

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

---

From: Emil Ivov <[email-masked]>
Date: Thu, 18 Jun 2009 19:07:40 +0200

> my draft copies its definition and encoding of audio level from the

Sounds reasonable. We were thinking of using relative non-normalized
sound levels to avoid conversion but using the comfort noise level
evaluation mechanism is also an option (especially in the use case you
describe).

> inevitably repeat or cross-reference information.

Agreed.

> level" and "csrc levels" is a good idea, 

I guess this depends on what you mean by "separate extension headers".

If it's only a matter of defining an extra URN then that's probably
alright. One could still wonder why we needed to explicitly
differentiate them though since they would hardly ever travel together.

I definitely think, however, that header syntax should be identical in
both cases.

> but that's orthogonal to the issue of document structure.)

Agreed again.

Cheers
Emil