RE: [XCON] Conference Control

["Oscar Novo \(JO/LMF\)" <[e-mail]>]

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