Re: [dispatch] Yet another problem to dispatch

Hi

When it comes to the use of header extensions I would believe that it is
better to reference to the freshly baked RFC5285 which describes a
general mechanism for the use of header extensions. 

Of all the listed options I personally find the header extension option
the most useful. The extension format would also be relatively compact
as the levels for each contributor can be put in the same order as the
contributors listed on the CSRC list. In addition, the header extension
does not need to be included in each packet, if a 10Hz update of the
meters is sufficient then the header extension would only be added every
5 packets (assuming a 20ms codec). The reading would be fast and most
important.. synchronized with the speech signal. The worst thing that
could happen if an endpoint (or whatever) discards the header extension
is that the client has to fall back to a binary CSRC activity
indication. 
Given that the levels are represented with one octet each a header
extension would add ~5+CC bytes to the packets size padded to the
nearest 32bit boundary (CC = number of CSRC) , I believe that this is
manageable especially as each CSRC cost 4 bytes.

I don't believe that implementing an alternative use/interpretation of
the CSRC list is a good idea, first of all I suspect that it would
likely be unsynchronized with the speech signal as one need to average
the activity for each contributor. Also participants makes all kinds of
noise (besides talking), often very short noise burst but they will
trigger an actvity signal for a longer time than the actual noise burst,
leading to unrealisticly high levels for the noisy persons. Finally, as
you point out there may be some interop issues.

Regards
Ingemar

> ------------------------------
> 
> Message: 2
> Date: Wed, 27 May 2009 11:14:59 -0600
> From: Cullen Jennings <fluffy@cisco.com>
> Subject: Re: [dispatch] Yet another problem to dispatch
> To: Emil Ivov <emcho@sip-communicator.org>
> Cc: dispatch@ietf.org
> Message-ID: <EA1CBEDB-319A-43BC-B874-909B8267F017@cisco.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> 
> 
> 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:
> 
> > 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
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 27 May 2009 14:18:03 -0400
> From: "Scott Lawrence" <scott.lawrence@nortel.com>
> Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription)
> 	requirements draft - draft-holmberg-dispatch-cbus-00.txt
> To: Christer Holmberg <christer.holmberg@ericsson.com>
> Cc: dispatch@ietf.org
> Message-ID: <1243448283.13614.283.camel@host.home.skrb.org>
> Content-Type: text/plain
> 
> On Wed, 2009-05-27 at 14:45 +0200, Christer Holmberg wrote:
> 
> > I've submitted a draft which proposes SIP requirements for 
> CBUS, based 
> > on work ongoing in OMA.
> 
> > (The most likely protocol output is going to be a new event 
> package, 
> > and some mechanism to provide conditions to the CBUS server).
> 
> The document would have been significantly easier to 
> understand had it actually defined some of the several 
> acronyms it used.
> 
> As far as I can tell, this describes (in very very general 
> terms) a framework for a particular application.  I don't see 
> anything here that motivates any new feature in the SIP 
> protocol, or indeed any reason why SIP is especially well 
> suited to the application.
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> End of dispatch Digest, Vol 2, Issue 22
> ***************************************
> 