Re: [dispatch] Yet another problem to dispatch

Hey John,

Elwell, John wrote:
> Emil,
> 
> But then you would need some sort of throttling, to prevent the UI
> constantly changing the list of names whose volumes are displayed. If
> the mixer were to do this throttling it would reduce the frequency of
> messages, which might allow a bigger choice of potential solutions.

I am not sure I understand exactly what you mean by throttling. Mixers
could be implemented to only include sound level information for the
loudest speakers thus having the possibility to ignore silent and almost
silent ones. It should be up to the mixer to determine the exact
threshold since that's where bandwidth would be most precious. Is this
what you are suggesting?

Then, once a client gets this information it can consider (and I guess
that's in line with 3550) that all CSRCs not present in a particular
packet have been silent for the corresponding period of time.

As to how exactly the client would render the sound level information,
whether or not it would display all of it, and whether it would somehow
rearrange participants, that should really be up to the UI implementors.

Does this make sense?

Cheers
Emil

> 
> These are just initial thoughts on my part, not firm opinions.
> 
> John
> 
> 
>> -----Original Message-----
>> From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf 
>> Of Emil Ivov
>> Sent: 28 May 2009 14:02
>> To: Elwell, John
>> Cc: Enrico Marocco; Cullen Jennings; dispatch@ietf.org
>> Subject: Re: [dispatch] Yet another problem to dispatch
>>
>> Hey John,
>>
>> Elwell, John wrote:
>>> Background noise in conferences is certainly a big issue. 
>> The web-type
>>> interface that Cullen mentions does in fact allow the moderator to
>>> momentarily mute each suspected noisy party in turn to 
>> discover who is
>>> the culprit. Clearly this is not scalable to large 
>> conferences. But also
>>> a simultaneous display of noise levels (e.g., in the form 
>> of bar graphs)
>>> is not scalable. 
>> One way to address this would be to allow mixer implementors to only
>> include sound levels for the N loudest participants. UI implementors
>> could then use a similar algorithm when presenting the information.
>>
>> How does this sound?
>>
>> Cheers
>> Emil
>>
>>
>>> Whilst it might be easy to find protocol solutions, we
>>> need to be confident that people will find ways of 
>> exploiting them in a
>>> reasonable way at the user interface. Certainly worth exploring.
>>>
>>> John
>>>
>>>
>>>> -----Original Message-----
>>>> From: dispatch-bounces@ietf.org 
>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Enrico Marocco
>>>> Sent: 27 May 2009 21:02
>>>> To: Cullen Jennings
>>>> Cc: dispatch@ietf.org
>>>> Subject: Re: [dispatch] Yet another problem to dispatch
>>>>
>>>> Cullen Jennings wrote:
>>>>> I find this "active speaker" problem very interesting. Often the  
>>>>> device that wants to display the active speaker information 
>>>> is not the  
>>>>> same as the device dealing with the RTP. For example, most the  
>>>>> conference systems I am using a phone but there is a web 
>> interface  
>>>>> that is dealing with active speaker information on my 
>>>> browser which is  
>>>>> no on my phone. Be interesting to look at all the existing 
>>>> approaches  
>>>>> to this.
>>>> Yes, I'm familiar with that kind of systems. However, the 
>>>> information we
>>>> are considering -- instantaneous sound levels of each 
>>>> participant -- is
>>>> definitely changing more rapidly than just active speaker 
>>>> indication and
>>>> also has more stringent synchronization requirements. 
>> That's why our
>>>> favorite approach would be to carry it in the media streams 
>>>> themselves,
>>>>  with some sort of a modulation of the RTP CSRC fields 
>> that could be
>>>> considered either an hack or an elegant solution. I would be very
>>>> interested in hearing any opinions about that.
>>>>
>>>> -- 
>>>> Ciao,
>>>> Enrico
>>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>> -- 
>> Emil Ivov, Ph.D.                               30a rue de la Patrie
>> Project Lead                                   67300 Schiltigheim
>> SIP Communicator
>> emcho@sip-communicator.org                     FAX:   
>> +33.1.77.62.47.31
>> http://sip-communicator.org                    PHONE: 
>> +33.1.77.62.43.30
>>
> 

-- 
Emil Ivov, Ph.D.                               30a rue de la Patrie
Project Lead                                   67300 Schiltigheim
SIP Communicator
emcho@sip-communicator.org                     FAX:   +33.1.77.62.47.31
http://sip-communicator.org                    PHONE: +33.1.77.62.43.30