Subject: Re: [XCON] Conference Control

From: Cullen Jennings <[email-masked]>
Date: Wed, 01 Feb 2006 01:26:39 -0800

On 1/27/06 7:59 AM, "Henning Schulzrinne" <[email-masked]> wrote:

> Let's not trot out the same non-relevant arguments each time.

Right - we had this argument and the conclusion was that BFCP was needed and
that bandwidth was an issue. I don't even know if I think we made the right
decision or not - but we did make a decision on the topic. I suspect that if
you review the arguments that let to selection of BFCP, you will come to the
conclusion that the same arguments apply to "mute participant". It was less
about the actual bandwidth used and more about the latency that large
messages (something like over 160 bytes) would introduce.

I do think we could split the arguments on couple exists. One is encoding of
XML or SOAP or Binary. Another axis's is what are the operations. I suspect
the operations are actually the more contentious issue.

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

---

From: "Sean Olson" <[email-masked]>
Date: Wed, 1 Feb 2006 09:18:49 -0800

Just one correction I would like to make. 

Encoding is XML or Binary or X ...
Transport/Binding is SOAP or X ...

I do agree we need to review the operations with more scrutiny perhaps
than this encoding discussion. 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. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Wednesday, February 01, 2006 1:27 AM
To: Henning Schulzrinne; Chris Boulton
Cc: [email-masked]; Adam Roach; XCON-IETF
Subject: Re: [XCON] Conference Control

> Let's not trot out the same non-relevant arguments each time.

Right - we had this argument and the conclusion was that BFCP was needed
and that bandwidth was an issue. I don't even know if I think we made
the right decision or not - but we did make a decision on the topic. I
suspect that if you review the arguments that let to selection of BFCP,
you will come to the conclusion that the same arguments apply to "mute
participant". It was less about the actual bandwidth used and more about
the latency that large messages (something like over 160 bytes) would
introduce.

I do think we could split the arguments on couple exists. One is
encoding of XML or SOAP or Binary. Another axis's is what are the
operations. I suspect the operations are actually the more contentious
issue.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 01 Feb 2006 20:48:13 -0800

On 2/1/06 9:18 AM, "Sean Olson" <[email-masked]> wrote:

> I do not however agree that a decision to

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.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 02 Feb 2006 16:23:42 -0500

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.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 3 Feb 2006 07:48:59 -0500

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

---

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

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

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 3 Feb 2006 13:55:09 -0500

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

Brian

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

enough

---

From: "Sean Olson" <[email-masked]>
Date: Fri, 3 Feb 2006 11:19:55 -0800

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

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

Brian

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

enough

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Feb 2006 15:38:54 -0500

> work that way for consistency.  I think Aki would have some misgivings...

OR, you might want to think about changing voice/video conferences to 
work more like IM.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 3 Feb 2006 15:41:31 -0500

Okay, that's what I thought.

I can see a method which was add/delete/eject user from conference/sidebar
One or three functions with parameters.

I can see methods which is create/delete conference/sidebar

Mute/Unmute would not be a method; that's a set/get of a datum

Of course there is no difference here between IM and audio/video.

The thing is, these are very low incidence messages.  They are important,
and unless we used a generic list management method, probably necessary.
I certainly don't see these methods as influencing protocol choice.

Brian

-----Original Message-----
From: Sean Olson [mailto:[email-masked]] 
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

- 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

---

From: "Sean Olson" <[email-masked]>
Date: Fri, 3 Feb 2006 13:45:53 -0800

Hmmm... I see your perspective, I just disagree. I have the reverse
problem. I'd like to make sure we don't unduly influence the design of
the conference control parts based on the media control parts. 

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

I can see a method which was add/delete/eject user from
conference/sidebar One or three functions with parameters.

The thing is, these are very low incidence messages.  They are
important, and unless we used a generic list management method, probably
necessary.
I certainly don't see these methods as influencing protocol choice.

Brian

-----Original Message-----
From: Sean Olson [mailto:[email-masked]]
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

- 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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 3 Feb 2006 17:28:35 -0500

Well, I've thought of that, but it tends not to work.
You have an audio channel (RTP stream) in, and another one out.  If you
tried to open another, the SBCs (and lots of silly proxies that shouldn't be
looking) get confused.  Try it, you won't like the results.

It does work within an enterprise.

Now, having said that, the same SBCs won't deal with video.

Brian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, February 03, 2006 3:39 PM
To: [email-masked]
Cc: 'Sean Olson'; 'Henning Schulzrinne'; 'Cullen Jennings'; 'Chris Boulton';
'Adam Roach'; [email-masked]; 'XCON-IETF'
Subject: Re: [XCON] Conference Control

> Most of them, once established, don't do anything except send messages,
but

	Paul