Subject: RE: [XCON] Conference Control

From: "Burger, Eric" <[email-masked]>
Date: Tue, 7 Feb 2006 21:58:23 -0500

Most of these commands have a URI.  Last time I looked, URI's were
8-bits per character octets.  Octets are binary.  Octets are huge.

Ask anyone who lived through the H.248 wars.  Binary encodings ranged
from 10% smaller than text to 3% larger.  Transport compression
effectively brought the PDU's to the same size.  Why? Because the big
win is not to say "DELETE CONFERENCE" in 3 bits but to be able to say
"sip:[email-masked]" in 8 bits.  You can
create a complex protocol that generates and hands around handles, or
you can use a simple protocol, take the TLS library that is on the
handset, and get the compression free. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sean Olson
Sent: Friday, February 03, 2006 2:20 PM
To: [email-masked]; Henning Schulzrinne; Cullen Jennings
Cc: Chris Boulton; Adam Roach; [email-masked]; XCON-IETF
Subject: RE: [XCON] Conference Control

Sure, let's start with IM. I can see the need for the following:

- Create Conference
- Add User
- Delete/Eject User 
- End Conference
- Create Sidebar
- End Sidebar
- Move User to Sidebar
- "Mute"/"Unmute" User

I don't consider any of these noise. They are all critical. And,
obviously, apply to conferences with other media types as well. You'll
also notice that most of the parameters to these would be strings where
binary encoding won't help. These are also not as time sensitive as
other media control commands might be. 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, February 03, 2006 10:55 AM
To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings'
Cc: 'Chris Boulton'; 'Adam Roach'; [email-masked]; 'XCON-IETF'
Subject: RE: [XCON] Conference Control

All right, then let's talk about an IM conference.
Most of them, once established, don't do anything except send messages,
but there are sidebars.  Sidebar is "media" control - who sees what you
type.
You create a sidebar - that's in the noise part.  You then send messages
inside the sidebar or in the main conference.  It's an interesting
difference between audio/video conferences and IM conferences; with
audio/video, you don't send to a "channel", you send a control message
to change what we do with a fixed channel.  Might want to think about
making IM work that way for consistency.  I think Aki would have some
misgivings...

Anyway, what other messages would you expect?

I'll stick with my prediction; 90% of messages sent, in the aggregate,
over this protocol, are likely to be media control messages, for which
set/get works well, binary encoding works well, and there aren't very
many interesting special purpose methods.

Brian

-----Original Message-----
From: Sean Olson [mailto:[email-masked]]
Sent: Friday, February 03, 2006 1:35 PM
To: [email-masked]; Henning Schulzrinne; Cullen Jennings
Cc: Chris Boulton; Adam Roach; [email-masked]; XCON-IETF
Subject: RE: [XCON] Conference Control

That's assuming of course that all you care about is audio or video --
while those are very important types of media, I hope that we are not
designing a system that caters only to audio/video conferencing.

The other "noise" you talk about is where I think we need to place more
emphasis, not less. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Friday, February 03, 2006 4:49 AM
To: 'Henning Schulzrinne'; 'Cullen Jennings'
Cc: 'Chris Boulton'; 'Adam Roach'; [email-masked]; 'XCON-IETF'
Subject: RE: [XCON] Conference Control

If you count messages in a conference, 90% of them will be for things
like adjusting volume controls, requesting/granting the floor, changing
your view, etc.  These are the controls on the mixer.  Then will come
the functions for managing sidebars, also mostly mixer controls.  Then,
down in the couple percent range, will be the creation and upper
management stuff.

The design center for the protocol should be mixer controls.  They are
mostly short and sweet (set this control to this value).  The other
stuff is really in the noise.  This observation is one reason I like end
system mixing.  It also argues for a BFCP-like approach if centralized
mixers are the norm.

It also occurs to me, as I think of it, that we either want to use a
learned dictionary compression system for the restricted bandwidth
control channel situations (wireless) or have handles for participants.
We're either going to repeatedly be sending the same URI over and over
again, or we assign a handle to the URI and send that.  If I want to
adjust my volume control for your speech, "your" is indentified in the
protocol as either your URI that I learn from the roster, or a handle
for it.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Thursday, February 02, 2006 4:24 PM
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. 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.

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

_______________________________________________
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: "Sean Olson" <[email-masked]>
Date: Tue, 7 Feb 2006 19:02:50 -0800

I'm a bit confused...

I agree that TLS compression can help (btw, DEFLATE works quite well
with XML
and there are even better methods that are XML-specific)

I agree that UTF-8 encoding of URIs means 8-bits per character in
general (for ASCII at least)

I don't see the leap of logic to take a SIP URI and cram it into 8
bits.... Other than generic token compression which I think we've
already covered works as well for "text" as "binary" 

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

- Create Conference
- Add User
- Delete/Eject User
- End Conference
- Create Sidebar
- End Sidebar
- Move User to Sidebar
- "Mute"/"Unmute" User

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Friday, February 03, 2006 10:55 AM
To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings'
Cc: 'Chris Boulton'; 'Adam Roach'; [email-masked]; 'XCON-IETF'
Subject: RE: [XCON] Conference Control

Brian

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

Brian

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

enough
similar