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

[hisham.khartabil at nokia.com]

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