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
