RE: [XCON] Conference Control

["Brian Rosen" <[e-mail]>]

This highlights the differences between my point of view and Sean's.

I view simple conferences as not needing xcon.  Creating conferences,
negotiating media, establishing connections to the mixer, finding out who is
in the conference, and even local operations like a local mute-yourself does
not need anything beyond SIP and the conference package.

If you need xcon, you have a highly functional client, and you want highly
interactive operations with the conference server.  I think that is mostly
in the domain of mixer state changes, which includes floor related
operations.  I don't think we need to be particularly clever in how we, for
example, establish a sidebar.  I think we need to be clever in how a user
manipulates his participation in the sidebar.  Since a sidebar has been
defined (against my way of thinking) as having its own URI, it's not even
clear to me that you need xcon to create sidebars.

As a consequence, I think the idea of having an index of URIs for membership
issues works.  It's a shorthand notation, and given sufficiently clever
compression you would not need the protocol to be explicit about shorthand
notation, but unless we are going to be so clever about compression (which I
don't think we should), then using an index seems appropriate.

Brian

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Oscar Novo (JO/LMF)
Sent: Thursday, February 09, 2006 2:58 AM
To: Sean Olson; Burger, Eric
Cc: XCON-IETF
Subject: RE: [XCON] Conference Control

Of course the URI is very important mainly for security issues
(authentication, ...) but for operations like "mute the audio of user X",
"change the display text of user X", and a big number of operations  I don´t
see the needed to send the "real" URI. It´s what I wanted to say in my last
email.

-----Original Message-----
From: Sean Olson [mailto:[e-mail]] 
Sent: 8. helmikuuta 2006 17:55
To: Oscar Novo (JO/LMF); Burger, Eric
Cc: XCON-IETF
Subject: RE: [XCON] Conference Control

>Actually the administrator of the network doesn´t care about the uri of 
>a user, media, or floor. It only needs a way to identify this user, 
>media, floor... inside his conference server and it should be the same 
>to identify one user as a "sip:muyser3241 @extension.provider.example.net"
or as a user "1".

Odd.... I'm very curious on what basis you would state this. The admins I've
spoken to are VERY interested in seeing the URI. But I understand where you
are going. Like I said, XML does compress very well. I'll do a similar
analysis for some real world examples from C3P and post that once I'm done.

Cheers,
Sean

-----Original Message-----
From: Oscar Novo (JO/LMF) [mailto:[e-mail]]
Sent: Wednesday, February 08, 2006 6:25 AM
To: Sean Olson; Burger, Eric
Cc: XCON-IETF
Subject: RE: [XCON] Conference Control

Just as an example, the Henning's SOAP proposal
(http://www.cs.columbia.edu/sip/draft/comp/draft-schulzrinne-xcon-comp-00.ht
ml) has three examples in section 6. If we count the words in every example
and the URIS, we have the following:

               Number of words   Number of URIs  %of URIS
--------------------------------------------------------
1 example           50                5            10%
2 example           10                0             0%
3 example           15                1           6.6%

The number of URIs per operation is quite small compared with the amount of
text.

If you still think that URIs are a big problem to create small operations.
Always we can create "relative" URIs in 8 bits that the conference server
can handle. Something like:

"1" -> "sip:[e-mail]"
"2" -> "sips:[e-mail]"
...

Actually the administrator of the network doesn´t care about the uri of a
user, media, or floor. It only needs a way to identify this user, media,
floor... inside his conference server and it should be the same to identify
one user as a "sip:[e-mail]" or as a user
"1".

Oscar

-----Original Message-----
From: Burger, Eric [mailto:[e-mail]]
Sent: Tuesday, February 07, 2006 6:58 PM
To: Sean Olson
Cc: XCON-IETF
Subject: RE: [XCON] Conference Control

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:[e-mail]" 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: [e-mail] [mailto:[e-mail]] On Behalf Of Sean
Olson
Sent: Friday, February 03, 2006 2:20 PM
To: [e-mail]; Henning Schulzrinne; Cullen Jennings
Cc: Chris Boulton; Adam Roach; [e-mail]; 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:[e-mail]]
Sent: Friday, February 03, 2006 10:55 AM
To: Sean Olson; 'Henning Schulzrinne'; 'Cullen Jennings'
Cc: 'Chris Boulton'; 'Adam Roach'; [e-mail]; '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:[e-mail]]
Sent: Friday, February 03, 2006 1:35 PM
To: [e-mail]; Henning Schulzrinne; Cullen Jennings
Cc: Chris Boulton; Adam Roach; [e-mail]; 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: [e-mail] [mailto:[e-mail]] On Behalf Of
Brian Rosen
Sent: Friday, February 03, 2006 4:49 AM
To: 'Henning Schulzrinne'; 'Cullen Jennings'
Cc: 'Chris Boulton'; 'Adam Roach'; [e-mail]; '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: [e-mail] [mailto:[e-mail]] On Behalf Of
Henning Schulzrinne
Sent: Thursday, February 02, 2006 4:24 PM
To: Cullen Jennings
Cc: Chris Boulton; Adam Roach; [e-mail]; 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" <[e-mail]> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/xcon


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


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

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

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



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