Subject: [dispatch] Yet another problem to dispatch

From: Emil Ivov <[email-masked]>
Date: Fri, 22 May 2009 00:45:51 +0200

Hey folks,

We have been working on client side conference calls  for SIP
Communicator lately and were thinking about implementing participant
sound level indicators. The feature was inspired by Skype's Mac OS X GUI
which you can have a look at over here:

http://sip-communicator.org/skypeconf/skypeconf.png

Since we couldn't find an existing IETF mechanism for a mixer to
dispatch information on sound level to conference participants, Enrico
and I thought that this may be an issue that is worth addressing through
dispatch.

After talking to some of you privately and discussing it among ourselves
we have decided to come up with a document presenting the issue in some
more detail. We are also including short descriptions of what we
consider to be possible approaches for resolving it.

http://www.ietf.org/internet-drafts/draft-ivov-dispatch-slic-ps-00.txt

Comments are most welcome, as well as any show of interest or
indications of what you think would be the right place(s) to work on the
subject.

Thanks,
Emil

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 27 May 2009 11:14:59 -0600

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.

Cullen <in my individual contributor role>

On May 21, 2009, at 4:45 PM, Emil Ivov wrote:

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 27 May 2009 22:01:48 +0200

> no on my phone. Be interesting to look at all the existing approaches  

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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 May 2009 08:42:07 +0100

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. 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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Enrico Marocco
> Sent: 27 May 2009 21:02
> To: Cullen Jennings
> Cc: [email-masked]
> Subject: Re: [dispatch] Yet another problem to dispatch
> 
> Cullen Jennings wrote:

---

From: Emil Ivov <[email-masked]>
Date: Thu, 28 May 2009 15:01:34 +0200

Hey John,

Elwell, John wrote:
> 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

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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 May 2009 14:19:33 +0100

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.

These are just initial thoughts on my part, not firm opinions.

John

> From: Emil Ivov [mailto:[email-masked]] On Behalf 
> Of Emil Ivov
> Sent: 28 May 2009 14:02
> To: Elwell, John
> Cc: Enrico Marocco; Cullen Jennings; [email-masked]

---

From: Emil Ivov <[email-masked]>
Date: Thu, 28 May 2009 18:28:30 +0200

Hey John,

> 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