Re: [dispatch] Yet another problem to dispatch

[Emil Ivov <[e-mail]>]

Hey Ingemar,

Thanks for your thoughts!

A few comments inline

Ingemar Johansson S wrote:
> 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. 

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
> 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). 

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
> 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. 

Yes, agreed.

> 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. 

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
> noise (besides talking), often very short noise burst but they will
> trigger an actvity signal for a longer time than the actual noise burst,

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.

> leading to unrealisticly high levels for the noisy persons. Finally, as
> 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
> 
> Regards
> Ingemar
> 
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 27 May 2009 11:14:59 -0600
>> From: Cullen Jennings <[e-mail]>
>> Subject: Re: [dispatch] Yet another problem to dispatch
>> To: Emil Ivov <[e-mail]>
>> Cc: [e-mail]
>> Message-ID: <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 27 May 2009 14:18:03 -0400
>> From: "Scott Lawrence" <[e-mail]>
>> Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription)
>> 	requirements draft - draft-holmberg-dispatch-cbus-00.txt
>> To: Christer Holmberg <[e-mail]>
>> Cc: [e-mail]
>> Message-ID: <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>
>> End of dispatch Digest, Vol 2, Issue 22
>> ***************************************
>>
> 

-- 
Emil Ivov, Ph.D.                               30a rue de la Patrie
Project Lead                                   67300 Schiltigheim
SIP Communicator
[e-mail]                     FAX:   [phone]
http://sip-communicator.org                    PHONE: [phone]