Subject: Re: [AVT] next step in Sound level indication in RTP - should we adopt this work

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 7 Sep 2009 17:02:32 +0200

Hi

I would belive that none of the projected use cases are controversial,
the framework for this is already there with RFC5285. 
The problem is more that the general interest in participating in this
is not very big but this is nothing new. For instance the image
attribute draft (in MMUSIC, with me as co-author) shares this fate. This
was still accepted as a WG item mainly as another SDO wanted it to
happen. 

Even though the general interest seems to be low I can envision that the
work (at least the mixer to client) will be used by some implementors. I
am less sure about the client to mixer scenario. Nevertheless, I support
the work on both drafts, not because I will implement it right away but
because there is an interest in getting it done and especially since
clients such as Skype already has that (proof of concept).
I don't have the time to participate actively in the work but I can
offer to review the drafts. 

Regards
/Ingemar

> Message: 4
> Date: Mon, 07 Sep 2009 17:03:46 +0300
> From: Roni Even <[email-masked]>
> Subject: [AVT] next step in Sound level indication in RTP - should we
> 	adopt	this work
> To: 'IETF AVT WG' <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi,
> 
> I sent the email bellow to the mailing list after IETF 75.
> 
> The list discussion points that there is some interest in the 
> work but the two drafts are offering different solutions and 
> have different requirements.
> Even though both are trying to convey meta data about the 
> sound level of the audio stream the information has different 
> use and therefore different requirements. I think that the 
> term "level" does not have the same meaning in both cases.
> 
>  
> 
> The mixer to client provide normalized information as defined 
> by the mixer of the contributing streams to the mix. The use 
> cases are for using the information as a  UI tool that will 
> help the participants to identify who injects background 
> noise or putting the conference on hold and mute them.
> This solution will work with systems that has a UI but will 
> probably not work for PSTN telephony based audio conferences 
> where there is no UI (the analysis will most probably fail if 
> done by automata).
> 
>  
> 
> The client to mixer case whose purpose is to help the mixer 
> select the contributing sources has led to discussion about 
> the definition of level and how to provide common information 
> from different clients implementations.
> 
>  
> 
> My conclusion is that if we take this work we will have two 
> separate solutions defining a different parameter and semantics.
> 
>  
> 
> I would like to get feedback on the following two questions
> 
>  
> 
> 1.       Should we adopt the work on sound level indication 
> between the
> mixer and client.
> 
> 2.       Should we adopt the work on sound level indications 
> between the
> client and mixer
> 
>  
> 
> Please respond to these two questions
> 
>  
> 
> Thanks
> 
>  
> 
> Roni Even
> 
> AVT co-chair
> 
>  
> 
>  
> 
> From: Roni Even [mailto:[email-masked]]
> Sent: Wednesday, July 29, 2009 1:56 PM
> To: [email-masked]'
> Subject: Sound level indication in RTP
> 
>  
> 
> Hi,
> 
> During the IETF75 AVT Monday session  the topic of sound 
> level indication was presented.
> 
> To recap the topic there are two suggestions.
> 
> 1.       Provide the sound level indication from the endpoint 
> to the mixer,
> this will help the mixer with selection the candidates to be mixed
> 
> 2.       Provide the incoming sound levels of all the 
> participants in the
> mixed as measured by the mixer. This may be displayed to the 
> conference participants helping them to know who are the 
> speaker and if there is someone causing constant noise like typing.
> 
> We did not have enough time to discuss at the session and we 
> are looking for feedback in order to see how to continue with 
> this work.
> 
>  
> 
> We want to know if this is a good idea, which of the two 
> proposal is interesting (maybe both). 
> 
> What use cases people see for sound level indications
> 
>  
> 
> Please respond so we can see if there is support for this 
> work and to verify the way forward.
> 
>  
> 
> Thanks
> 
> Roni Even
> 
> AVT co-chair
> 
>  
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://www.ietf.org/mail-archive/web/avt/attachments/20090907
> /3ce7ade8/attachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> End of avt Digest, Vol 65, Issue 13
> ***********************************
>

---

From: Enrico Marocco <[email-masked]>
Date: Mon, 7 Sep 2009 17:25:11 +0200

> offer to review the drafts. 

Well, current authors will be happy to provide the editing cycles
required to do the work; what will be really essential is indeed
guidance (and review) from the WG. Additionally, I'm aware of a
development effort going on at SIP Communicator concerning the
implementation of a Skype-like interface that will also feature the
display of sound levels for conference participants. So, FWIW, the specs
in this case would most likely come accompanied by running code from day
one.

-- 
Ciao,
Enrico

---

From: Eric Burger <[email-masked]>
Date: Wed, 9 Sep 2009 06:25:11 -0400

[responding here, but also to Roni's message of Sep 7, 2009]

Roni gets it in one: there are  two distinct  things we are talking  
about here.

My *opinion* is that mixer -> client level indication is immediately  
useful and has market demand as it is user-visible and proprietary  
systems offer it today.

My opinion is that client -> mixer level indication is useful for  
today's closed proprietary mixers and will, over the next few years,  
possibly become useful in general if we can encourage a majority of  
clients to implement the feature.

Thus, I would offer mixer -> client work is of a much higher priority  
than client -> mixer. However, that does not mean that client -> mixer  
is unworthy of work in the group.

---

From: Roni Even <[email-masked]>
Date: Wed, 09 Sep 2009 14:41:45 +0300

Hi,
Using header extension is one way to provide the information the other being
an RTCP message.
Note that the header extension are not encrypted according to SRTP and care
should be made about what information is carried there.
This should be discussed once we decide to accept the topic as a WG item
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ingemar Johansson S
> Sent: Monday, September 07, 2009 6:03 PM
> To: [email-masked]
> Subject: Re: [AVT] next step in Sound level indication in RTP - should
> we adopt this work
> 
> Hi
>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 9 Sep 2009 13:59:47 +0200

Agree, I picked up the header extension as I see it as the most handy
solution. However I recongize the security concerns and these need to be
adressed in the drafts (if they become WG items)

/Ingemar 

> From: Roni Even [mailto:[email-masked]] 
> Sent: den 9 september 2009 13:42
> To: Ingemar Johansson S; [email-masked]
> Subject: RE: [AVT] next step in Sound level indication in RTP 
> - should we adoptthis work
> 
> Hi,
> Using header extension is one way to provide the information 
> the other being an RTCP message.
> Note that the header extension are not encrypted according to 
> SRTP and care should be made about what information is carried there.
> This should be discussed once we decide to accept the topic 
> as a WG item Roni Even
> 
> > Even though the general interest seems to be low I can 
> envision that 
> > the work (at least the mixer to client) will be used by some 
> > implementors.
> > I
> > am less sure about the client to mixer scenario. Nevertheless, I 
> > support the work on both drafts, not because I will 
> implement it right 
> > away but because there is an interest in getting it done and 
> > especially since clients such as Skype already has that (proof of 
> > concept).
> > > The list discussion points that there is some interest in 
> the work 
> > > but the two drafts are offering different solutions and have 
> > > different requirements.
> > > Even though both are trying to convey meta data about the sound 
> > > level of the audio stream the information has different use and 
> > > therefore different requirements. I think that the term 
> "level" does 
> > > not have the same meaning in both cases.
> > >
> > >
> > >
> > > The mixer to client provide normalized information as 
> defined by the 
> > > mixer of the contributing streams to the mix. The use 
> cases are for 
> > > using the information as a  UI tool that will help the 
> participants 
> > > to identify who injects background noise or putting the 
> conference 
> > > on hold and mute them.
> > > This solution will work with systems that has a UI but 
> will probably 
> > > not work for PSTN telephony based audio conferences where 
> there is 
> > > no UI (the analysis will most probably fail if done by automata).
> > >
> > >
> > >
> > > The client to mixer case whose purpose is to help the 
> mixer select 
> > > the contributing sources has led to discussion about the 
> definition 
> > > of level and how to provide common information from different 
> > > clients implementations.
> > >
> > >
> > >
> > > My conclusion is that if we take this work we will have 
> two separate 
> > > solutions defining a different parameter and semantics.
> > >
> > >
> > >
> > > During the IETF75 AVT Monday session  the topic of sound level 
> > > indication was presented.
> > >
> speaker and 
> > > if there is someone causing constant noise like typing.
> > >
> > > We did not have enough time to discuss at the session and we are 
> > > looking for feedback in order to see how to continue with 
> this work.
> > >
> > >
> > >
> > > -------------- next part -------------- An HTML attachment was 
> > > scrubbed...
> > > URL:

---

From: stephen botzko <[email-masked]>
Date: Wed, 9 Sep 2009 09:23:36 -0400

I think that longer term the client->mixer work may have more value.

It potentially enables scalable distributed mixers (through a Media-Aware
Network Element),  It the signaling also includes some form of voice
activity measure, then it also would allow clients (and MANEs) to identify
the current speaker(s) in a multipoint video conference.

Regards,
Stephen Botzko
Polycom

On Wed, Sep 9, 2009 at 6:25 AM, Eric Burger <[email-masked]>wrote:

> Roni gets it in one: there are  two distinct  things we are talking about
> here.
>
> My *opinion* is that mixer -> client level indication is immediately useful
> and has market demand as it is user-visible and proprietary systems offer it
> today.
>
> My opinion is that client -> mixer level indication is useful for today's
> closed proprietary mixers and will, over the next few years, possibly become
> useful in general if we can encourage a majority of clients to implement the
> feature.
>
> Thus, I would offer mixer -> client work is of a much higher priority than
> client -> mixer. However, that does not mean that client -> mixer is
> unworthy of work in the group.
>
>