Subject: RE: [XCON] Conference Control

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sat, 4 Feb 2006 15:08:22 -0000

I'd be interested to know why this use cases cannot be met by using floor control and conference control in parallel. If it is really important to cut off a user from speaking as soon as possible and eject that user from the conference, then floor control can solve the stop from speaking issue.

As for mute, then is that not really a function for the floor control protocol anyway. Surely you are only putting it in the conference control protocol due to potential absence of floor control protocol.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Oscar Novo (JO/LMF)
> Sent: 03 February 2006 08:29
> To: Henning Schulzrinne; Cullen Jennings
> Cc: Chris Boulton; Adam Roach; [email-masked]; XCON-IETF
> Subject: RE: [XCON] Conference Control
> 
> 
> 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
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 4 Feb 2006 21:50:56 -0500

I've never thought there was anything magic about floor control.  It's one
of several relatively simple interactions between the conference controller
and a client that requires some notion of "real time" (100-300 ms if you
need it).  I've never thought that "ask for the floor" was any different
from "mute" (of any flavor) or "change the contents of my main window to
show George".  They are all requests to change mixer state.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Drage, Keith (Keith)
Sent: Saturday, February 04, 2006 10:08 AM
To: 'Oscar Novo (JO/LMF)'; 'Henning Schulzrinne'
Cc: 'XCON-IETF'
Subject: RE: [XCON] Conference Control

I'd be interested to know why this use cases cannot be met by using floor
control and conference control in parallel. If it is really important to cut
off a user from speaking as soon as possible and eject that user from the
conference, then floor control can solve the stop from speaking issue.

As for mute, then is that not really a function for the floor control
protocol anyway. Surely you are only putting it in the conference control
protocol due to potential absence of floor control protocol.

regards

Keith