RE: [XCON] XCON Media/Floor Control Joint Ad-Hoc Meeting

["Brian Rosen" <br at brianrosen.net>]

I'm inclined to make the DEFINITION of floors in MPCP.
	This includes the name, how many holders, and what it does.
	What it does includes any streams and/or controls available
		to the holders of the floors
I'd make the policy of who can get a floor CPCP
	CPCP is also the place where correlation between MPCP,
		BFCP and SIP is done
I'd make the mechanism for requesting and granting the floor BFCP

That would mean:
	CPCP doesn't define floor ids or max floors or max holders
		(MPCP does)
	CPCP doesn't define how media relates to floors
		(MPCP does)
	CPCP does defines the policy for how floor control
		is managed, so the "algorithm" part would stay.
		There is some overlap here I'm not comfortable with

This discussion prompted me to look again at BFCP.  
I note:
The diagram should show a connection between BFCP server and
CPCP server, because the policy decisions are made in CPCP.
For example, who can get a floor is a CPCP function.

I think the text should say that MPCP defines the floors and
what the floors mean, and what happens when you get a floor.

Insofar as a floor is actually "created", I think it's correct
to say that CPCP does that.  I'm not clear what creation of 
a floor really means though.

I think that CPCP controls the correlation between the signaling
and MPCP, so you contact the CPCP server to get the BFCP server.
I would think that the BFCP client is intimately tied to the CPCP
client, and thus would not need to be told the conference id or
the participant id.  What would the BFCP client use as an identifier
to ask CPCP what these were?

I think that the text in 3.3 talking about using a SIP offer/answer
to get a shared secret is wrong.  Unless the floor is defined as
a media stream, I don't see how you can use SIP/SDP for this.
Instead I would say that CPCP gives you the way to contact the
BFCP server, and you define a message sequence that uses DH to
compute the shared secret.

Text in 3.4 should refer to MPCP not CPCP
Maybe:
MPCP defines what a floor does, and what resources (media streams,
controls, mixer functions) are related to a floor.  BFCP is not
aware of the consequences of what holding a floor means; it only
provides the mechanism to acquire and release a floor.

The policy enforcement section of 3.5 is convoluted.
MPCP defines what having the floor means.  CPCP defines who
is allowed to have a floor.  I think it is not possible
for a non floor holder to manipulate resources the template
reserves to floor holders.  The mixer wouldn't work that way.

The text then jumps into a discussion of getting floors.  It mentions
that you can make third party requests.  That text should talk about
finding out about participant ids through the roster function of
the conference package (?or via CPCP?)


-----Original Message-----
From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On Behalf Of Alan
Johnston
Sent: Thursday, August 05, 2004 4:45 PM
To: hisham.khartabil at nokia.com; xcon at ietf.org
Subject: RE: [XCON] XCON Media/Floor Control Joint Ad-Hoc Meeting

Hisham,

Thanks for  bringing this up.  Your points relate to how floor control, 
media policy, and conference policy interact.  We do need to sort these 
issues out.

There are some parts of floor control that clearly belong in CPCP - who can 
be a moderator, for example.  Other parts, such as the floors and names of 
floors could be either CPCP or MPCP.   I would say just MPCP but there are 
times in which floor control has no media function (no enforcement or 
enforcement done by an external application).  Clearly, the information 
should be defined in only one place - either CPCP or MPCP.

I'll let others comment on the details.

Thanks,
Alan
sip:alan at sipstation.com

Thanks,
Alan.At 11:29 PM 8/4/2004 +0300, hisham.khartabil at nokia.com wrote:


> > -----Original Message-----
> > From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org]On Behalf Of
> > ext Alan Johnston
> > Sent: 04.August.2004 20:33
> > To: xcon at ietf.org
> > Cc: Cullen Jennings; Drage,Keith (Keith); Joerg Ott;
> > mtrayer at nortelnetworks.com; Even, Roni; cboulton at ubiquity.com; Gonzalo
> > Camarillo; Chandra Umesh (Nokia-NRC/Dallas)
> > Subject: Re: [XCON] XCON Media/Floor Control Joint Ad-Hoc Meeting
> >
> >
>
> >
> > Media Policy and Floor Control
> >
> > Media policy defines *what* happens when a participant is granted the
> > floor.  (Compare to CPCP which says if floor control is to be
> > used and who
> > is the moderator, and whether floor information is made
> > available.  Compare
> > to BFCP which carries floor requests/releases, chair
> > notifications/decisions, and floor status notifications.)
> >
> > As such, any template must discuss floor control.  It must
> > say if floor
> > control is allowed (a parameter setting, perhaps?)  How many
> > floors and
> > what the floor IDs will be during the conference.
>
>But the current CPCP document dictates how many floors there should be and 
>the floor ID. Read section 4.3.8.
>
> >  What
> > changes occur as
> > the floor holder changes.  A template will list each floor ID and, if
> > applicable, relate it to a media type/stream.
>
>The current CPCP document also shows how media relates to a floor 
>(correlation)
>
> >  Note that some
> > floors may
> > NOT have any relation to a media stream.  Since there can be multiple
> > simultaneous holders of a floor, the template needs to define
> > it this is
> > possible and what it means.  For example, for a push to talk
> > conference,
> > there can only be one floor holder at a time.  For floors that enable
> > additional controls, it is perfectly OK to have multiple
> > floor holders who
> > can manipulate the same set of shared controls.
>
>Again CPCP defines <max-floor-users> dictating how many users can hold a 
>floor at one time.
>
>There is also <algorithm> dictating the conrtol of the floor,whether it is 
>moderator, random, first come first serve, etc. You did not say anything 
>about that.
>
>Do we want these things out of CPCP? If so, then we need them also out of 
>the requirements document.
>
>Regards,
>Hisham
>
> >  Support for
> > floor control
> > should be a parameter in a template, since not every
> > conference bridge will
> > support it, or policy may specify that it be turned off.
> >
> > Two things may happen when a participant becomes a floor holder: the
> > conference mix may change, the controls available to the
> > floor holder may
> > change.  These are the only two observable/quantifiable
> > changes in the
> > conference.
> >
> > How the conference mix changes is specified in the template.  It is a
> > textual description for humans to understand what happens
> > (does everyone
> > see/hear my media now?) and information for the mixer to make
> > the right
> > thing happen.  Of course, the flow graph work will need to
> > have a mechanism
> > to express floor in mixing, just as it needs to be able to
> > express loudest
> > speaker, last speaker, etc.
> >
> > The controls which become available to a participant while
> > they hold the
> > floor is also specified in the template.  Just as controls
> > now have an
> > enable flag, they need to have a floor-enable flag.  A TRUE
> > value for this
> > flag indicates that the specified control is *only* active when the
> > participant holds the floor.  A FALSE value indicates that
> > this control is
> > active regardless of whether the participant holds the floor.
> >  If the value
> > is TRUE, the floor-id flag must be included which identifies
> > which floor
> > this control relates to.  It is possible to have a floor which *only*
> > results in control availability changes and is not related to
> > *any* media
> > stream.
> >
> > What a change in floor control IS NOT:
> >
> > - It is NOT a change in Role.  Each role which may assume the
> > floor must
> > include any floor-related controls defined.  There is never a
> > role Floor
> > Holder.  Instead, each role indicates whether a participant
> > of that role
> > may assume the floor.
> >
> > - It is NOT a change in permissions allowing the participant to make
> > arbitrary media policy changes.  At the start of the conference, the
> > template and the parameters are fixed and are not changed during the
> > conference.  All changes to the state of the conference are
> > made using
> > controls.  What controls are active may be a function of who
> > holds the floor.
> >
> > Here is Cullen's notes from the meeting:
> >
> > >Participants:
> > >
> > >Roni,
> > >Gonzalo
> > >Keith,
> > >Cullen
> > >Alan
> > >Mark,
> > >Tim,
> > >Joerg
> > >Chris,
> > >Umesh
> > >
> > >Joerg - thinks it probably needs a few more things but looks ok
> > >
> > >We need a framework document that explains how this goes together
> > >Needs to have:
> > >Who allocated conf id and user id.
> > >
> > >Should we allow authorization rules based on Role in the CPCP?
> > >
> > >Point that in case of things like white boarding, there may
> > be floor control
> > >even though it made no change to the "mixing" of this media.
> > Can have floor
> > >control without any media interaction.
> > >
> > >Need to check that we can handle one focus and multiple mixers.
> > >
> > >SDP - the allows the UA to find out about control. The media
> > stuff in SDP
> > >references in labels of media streams they are associated
> > with. Can have
> > >more than one media stream or no label.
> > >
> > >-------------
> > >
> > >Separate topic - need to deal with text changed to closed
> > caption style
> > >video stuff
> >
> >
> >
> > At 03:14 PM 8/2/2004 -0500, Alan Johnston wrote:
> > >All,
> > >
> > >The XCON Media Design Team and the Floor Control Design team will be
> > >holding a joint meeting in San Diego at 7:30am - 9am on
> > Tuesday August
> > >3.  We will meet at the IETF registration table at 7:30am
> > and move to an
> > >empty room.
> > >
> > >All are welcome - the main topic is the relationship between
> > floor control
> > >and media policy.
> > >
> > >Thanks,
> > >Alan Johnston
> > >MCI
> > >
> > >
> > >_______________________________________________
> > >XCON mailing list
> > >XCON at ietf.org
> > >https://www1.ietf.org/mailman/listinfo/xcon
> >
> >
> > _______________________________________________
> > XCON mailing list
> > XCON at ietf.org
> > https://www1.ietf.org/mailman/listinfo/xcon
> >


_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon





_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon