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

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

A couple of issues:

Is it correct to say that the template DEFINES the floors, much as it
defines streams and controls?

A stream may become available as a result of holding the floor, so there are
three things that result.

I'm confused about the definition of the templates and the FloorEnable.
I think that you specify the floorId, which is "this control/stream
is only available to holders of the following floors".  This is a 
template object specification.  The conference object would just show
enable=true if the participant held the proper floor.  I don't see
a reason to have floor enable + enable.  The stream/control would
not even be visible if the participant did not hold the floor.

Brian

-----Original Message-----
From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On Behalf Of Alan
Johnston
Sent: Wednesday, August 04, 2004 1:33 PM
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; Umesh.Chandra at nokia.com
Subject: Re: [XCON] XCON Media/Floor Control Joint Ad-Hoc Meeting

Here's the outcome of the meeting.  The teams discussed the following high 
level description of how floor control and media policy interact.  The 
design teams agreed to this description at a high level (see Cullen's notes 
at the end of this note).  Comments from all are most welcome.

Thanks,
Alan Johnston
MCI
sip:alan at sipstation.com

- - - - -

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