Subject: Re: [dispatch] Yet another problem to dispatch

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 28 May 2009 07:54:29 +0200

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 <[email-masked]>
> Subject: Re: [dispatch] Yet another problem to dispatch
> To: Emil Ivov <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 27 May 2009 14:18:03 -0400
> From: "Scott Lawrence" <[email-masked]>
> Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription)
> 	requirements draft - draft-holmberg-dispatch-cbus-00.txt
> To: Christer Holmberg <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> End of dispatch Digest, Vol 2, Issue 22
> ***************************************
>

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 28 May 2009 14:57:34 +0200

> general mechanism for the use of header extensions. 

Yes, if people agree that such a problem will be best addressed with an
RTP extension, 5285 is probably the right way to go.

> you point out there may be some interop issues.

Hmm, I'm not sure if that's what would actually happen. If a noise burst
reached, say, volume level 8 for 40ms, that would be signaled only in
two RTP packets, resulting in the client detecting just a level-2 signal.

-- 
Ciao,
Enrico

---

From: Emil Ivov <[email-masked]>
Date: Thu, 28 May 2009 14:59:50 +0200

Hey Ingemar,

Thanks for your thoughts!

A few comments inline

Ingemar Johansson S wrote:
> contributors listed on the CSRC list. 

As a matter of fact that would also have been our first choice but we
were a bit concerned with the use of the extension header since RFC3550
insists on its experimental nature. I guess RFC5285 obsoletes the
warnings against use of the extension header so thanks for pointing it out!

Incidentally, RFC5285 seems to be extending SDP for the extension
mappings. If we go down this path we need to be aware that we would lose
the inherent compatibility with other signaling protocols such as XMPP.
Making the solution work for them would require some extra effort.

> In addition, the header extension
> 5 packets (assuming a 20ms codec). 

Definitely sounds reasonable but this is also a bit of a slippery slope
since it may somewhat compromise reliability. The trade off consists in
choosing between a few extra bytes in every RTP packet or losing the
meta information which may make the UI look a bit jumpy at times. It
would probably be a good idea to leave the choice to implementors.

> The reading would be fast and most

Yes, agreed.

> the activity for each contributor. 

Granted .. although I wouldn't say it's more of an issue than losing a
packet containing the extension header in the case where we only send it
in every fifth packet.

> Also participants makes all kinds of

Indeed, although a noise burst representation in the UI that lasts less
than a hundred milliseconds is likely to go unnoticed by the user,
anyway. Many sound level indicators (like for example most of the
microphone configuration UIs built in popular OSs) would intentionally
add some delay when representing peaks.

> you point out there may be some interop issues.

Yes and again, if the experimental nature of the RTP extension header is
no longer meant for experimentation only and the community is
comfortable with the XMPP compatibility issue then this is clearly the
way to go.

Thanks again for your comments Ingemar!

Cheers
Emil

-- 
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: Enrico Marocco <[email-masked]>
Date: Fri, 29 May 2009 09:32:37 +0200

Ingemar Johansson S wrote:
>> Hmm, I'm not sure if that's what would actually happen. If a 
>> noise burst reached, say, volume level 8 for 40ms, that would 
>> be signaled only in two RTP packets, resulting in the client 
>> detecting just a level-2 signal.
> 
> The way I understand it there will only be a 0% or 100% indication. So if
> one CSRC is inluded in 2 out of 10 packets the resulting average level would
> be 20%.

Correct. IOW, the problem with very short noise bursts is that their
representation in the UI would be smoothed, but they would not cause a
longer activity signal.

-- 
Ciao,
Enrico