Subject: Re: [AVT] Sound level indication in RTP

From: Roni Even <[email-masked]>
Date: Mon, 07 Sep 2009 15:13:25 +0300

Eric,
Are you saying that we will need to define two different parameters. One for
mixer to user and the other user to mixer. These two parameters have no
relations but both are called sound level indications
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Eric Burger
> Sent: Friday, July 31, 2009 12:25 PM
> To: IETF AVT WG
> Subject: Re: [AVT] Sound level indication in RTP
> 
> I agree in principle.  What I would offer is the levels that get
> displayed to the end users are calculated by the mixer. There is no
> value in having non-zero levels for people not in the mix: that could
> be a source of customer confusion.  However, there is no harm in the
> user's endpoint sending level info towards the mixer.  Some mixers can
> use that information for building light-weight, low complexity mixers.
> Really dumb mixers (RTP switches) can forward the selected stream's
> level indication.
> 
> Thus, the mixer MUST generate AGC-compensated levels for the 1/3/5/n
> streams in the mix.  Endpoints MAY generate sound level detected.
> 
> Of course, that DOES mean one needs to specify endpoint sound levels,
> but that is an exercise for the signal processing guys.
> 
> On Jul 30, 2009, at 10:55 PM, Jonathan Lennox wrote:
> 
> > Eric Burger writes:
> >
> >> The mixer, on the other hand, has to do full analysis of the media
> to
> >> do the mix in the first place. Moreover, most advanced mixers (media
> >> servers) will do level balancing, which means endpoint sound levels
> >> will not even be relatively correct as a representation of the mix.
> >> Lastly, advanced mixers will do noise suppression, which means a
> non-
> >> talker with an unmuted mobile phone in the wind will have a
> >> relatively high sound level, yet not be in the mix at all.
> >
> > Yes, all this is true, and a mixer is still going to have to do all
> of
> > this -- on the streams it chooses to insert into the mix -- in order
> > to do a high-quality job of mixing.
> >
> > However, that doesn't obviate the use of the levels sent in the
> draft.
> > If a mixer which is receiving fifty audio streams can discard packets
> > from forty of them, without needing to decode and measure them all
> > before it processes the remaining few and making the final decision
> > about which ones it actually wants to mix, the number of conferences
> > it can support will increase dramatically.
> >
> > Another important point I raised: for this purpose, a mixer can't
> just
> > trust the level carried in a single packet.  Instead, it may need to
> > watch a source's levels over a period of time, and only decide the
> > participant is speaking once its elevated levels continue for a
> while.
> > (This is to avoid switching someone in on a cough, or when they drop
> > their microphone, or whatever.)
> >
> > Another important point -- this one is pointed out in the draft's
> > security considerations -- is that the mixer also needs to
> > periodically audit the levels participants are sending; otherwise
> > there's some incentive to lie and claim that your levels are higher
> > than they
> > actually are.   (However, I don't off-hand see any motivation to lie
> > by
> > sending *lower* levels; if you're trying not to get into the mix, why
> > send audio at all?)
> >
> > --
> > Jonathan Lennox
> > Vidyo, Inc
> > [email-masked]
> >