Subject: RE: [XCON] Conference Control

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Fri, 3 Feb 2006 09:29:01 +0100

Hello Henning,

Comments inline. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: 2. helmikuuta 2006 23:24
To: Cullen Jennings
Cc: Chris Boulton; Adam Roach; [email-masked]; XCON-IETF
Subject: Re: [XCON] Conference Control

While floor control, in its push-to-talk usage at least, had some notion of real-time needs, this appears far less of an issue for creating and managing conferences. 

[ON]There are some cases managing a conference where the real-time needs in CCP is important, for instance, "mute" a user in a conference, or "eject" a user from a conference.

In addition, many of the items that needed for conference creation are naturally strings, such as descriptions or URIs. 
I'd be surprised if a binary approach were to offer significant improvements in effective length, particularly once compression has been applied.

[ON] The fact that in the binary approach you don´t need compression is a significants improvement respect the other proposals. Compression requires more CPU processing and adds "latency". Compression is a solution for limited bandwidth but not for latency. You can compress the data, but latency is still there. 

Thus, I don't see the analogy.

Cullen Jennings wrote:
> On 2/1/06 9:18 AM, "Sean Olson" <[email-masked]> wrote:
> 
>> I do not however agree that a decision to use a binary encoding for 
>> floor control necessarily means we should generally be constrained to 
>> use a binary encoding for conference control.
> 
> I certainly have mixed feelings on this myself. I do think that it 
> makes a fairly strong argument that we need to at least have one 
> protocol that supports the functionality and is usable in the same 
> environment that BFCP was designed for. That does not stop us from 
> having a second protocol with the same functionality that does not 
> work in the environment BFCP was designed for.
> 
> I'm pretty sure that I did point this all out back when we approved 
> BFCP that selecting one of the key protocols before having even a 
> rough idea on the architecture was going to constrain our options 
> later and that if we were accepting the BFCP requirements, well we had 
> to accept them for enough to do xcon conferences on that sort of 
> device, and that would imply similar constraints on the other 
> protocols.  No one seemed to have a problem with this back when we did 
> BFCP. Ironically, I was the one of the only people that had any reservations about BFCP.

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 3 Feb 2006 09:28:07 -0500

Have you actually measured the latency for compression? We're  
probably talking 2-3 ms here, based on my experience.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 3 Feb 2006 10:06:00 -0500

I don't see a problem.  This is not in a media channel, it's in a control
channel.  You could have 100 ms latency and not really notice.  In this
case, the latency would be the time from when your UI recorded a button
press, and the time the received audio (say) changed in response.

That would be a one way (assuming no error) message on the control channel,
processing at both ends for the message, the actual change to mixer state,
and the delay in getting the next packet out of the mixer to the receiver
audio subsystem.  The packetization delay on the audio is 15-20 ms of that.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Friday, February 03, 2006 9:28 AM
To: Oscar Novo ((JO/LMF))
Cc: Cullen Jennings; Chris Boulton; Adam Roach; [email-masked];
XCON-IETF
Subject: Re: [XCON] Conference Control

---

From: "Sean Olson" <[email-masked]>
Date: Fri, 3 Feb 2006 10:31:54 -0800

[HS] In addition, many of the items that needed for conference creation are naturally strings, such as descriptions or URIs. 
I'd be surprised if a binary approach were to offer significant improvements in effective length, particularly once compression has been applied.

[SO]A string is a string. What is the "binary" encoding for a SIP URI besides UTF-8?

---

From: "Sean Olson" <[email-masked]>
Date: Fri, 3 Feb 2006 10:36:06 -0800

Completely agree. We should not be worrying about latency for the
control channel at this level of granularity. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Friday, February 03, 2006 7:06 AM
To: 'Henning Schulzrinne'; 'Oscar Novo ((JO/LMF))'
Cc: 'Cullen Jennings'; 'Chris Boulton'; 'Adam Roach';
[email-masked]; 'XCON-IETF'
Subject: RE: [XCON] Conference Control

I don't see a problem.  This is not in a media channel, it's in a
control channel.  You could have 100 ms latency and not really notice.
In this case, the latency would be the time from when your UI recorded a
button press, and the time the received audio (say) changed in response.

That would be a one way (assuming no error) message on the control
channel, processing at both ends for the message, the actual change to
mixer state, and the delay in getting the next packet out of the mixer
to the receiver audio subsystem.  The packetization delay on the audio
is 15-20 ms of that.

Brian

-----Original Message-----

Have you actually measured the latency for compression? We're probably
talking 2-3 ms here, based on my experience.

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 3 Feb 2006 20:23:34 -0000

Don't know what the best message to inject this into this thread, but I have 
a compact text based encoding method that competes well with the less 
aggressive binary encoding methods on message size (should compete well with 
BFCP level, but not ASN.1 PER level) that sounds ideal for these scenarios.

It has a formal message definition language and formal 'on-the-wire' spec. 
It's also very extensible by various methods (standards based and 
proprietary).  It's written up in a draft at 
http://www.ietf.org/internet-drafts/draft-cordell-lumas-03.txt.

There is a brief description of it at: 
http://www.tech-know-ware.com/lumas/lumas-example.html

There's C and Perl parsers, along with a message definition syntax checker 
at http://tech-know-ware.com/lumas/.  There is also the beginnings of a tool 
that converts the message definition into an ABNF definition, so that you 
can use your favourite ABNF to code route, making it a risk free.

HTH,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
                         for XML to C++ data binding visit
                         http://www.tech-know-ware.com/lmx
                         (or http://www.xml2cpp.com)
=============================================

----- Original Message ----- 
From: "Sean Olson" <[email-masked]>
To: "Oscar Novo (JO/LMF)" <[email-masked]>; "Henning Schulzrinne" 
<[email-masked]>; "Cullen Jennings" <[email-masked]>
Cc: "Chris Boulton" <[email-masked]>; "Adam Roach" 
<[email-masked]>; <[email-masked]>; "XCON-IETF" <[email-masked]>
Sent: Friday, February 03, 2006 6:31 PM
Subject: RE: [XCON] Conference Control

[HS] In addition, many of the items that needed for conference creation are 
naturally strings, such as descriptions or URIs.
I'd be surprised if a binary approach were to offer significant improvements 
in effective length, particularly once compression has been applied.

[ON] The fact that in the binary approach you don´t need compression is a 
significants improvement respect the other proposals. Compression requires 
more CPU processing and adds "latency". Compression is a solution for 
limited bandwidth but not for latency. You can compress the data, but 
latency is still there.

[SO]A string is a string. What is the "binary" encoding for a SIP URI 
besides UTF-8?