A Binary Floor Control Protocol (BFCP) Control Package for the Media Control Channel Framework
University of NapoliVia Claudio 2180125NapoliItalylorenzo.miniero@unina.itUniversity of NapoliVia Claudio 2180125NapoliItalyspromano@unina.itPolycom94 Derech Em Hamoshavot49130Petach TikvaIsraelroni.even@polycom.co.ilHewlett-PackardGustav III:s boulevard 36SE-16985StockholmSwedenscott.mcglashan@hp.com
RAI
Network Working GroupMediaCtrlMedia Server ControlMedia Control Channel FrameworkBFCP
This document defines a Media Control Channel Framework Package for
BFCP-based conference moderation. The control of
Media Servers and their related resources in decomposed network
architectures plays an important role in various Next Generation
Networks. This Control Package aims at adding BFCP functionality
to conferences using the Media Control Channel Framework.
The Media Control Channel Framework
provides a generic approach for establishment and reporting
capabilities of remotely initiated commands. The Framework utilizes
many functions provided by the Session Initiation Protocol
(SIP) for the rendezvous and establishment of a reliable channel for
control interactions. The Control Framework also introduces the
concept of a Control Package. A Control Package is an explicit usage
of the Control Framework for a particular interaction set. This
specification defines a package for floor control in conferences based
on the use of the Binary Floor Control Protocol (BFCP) .
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 and
indicate requirement levels for compliant implementations.
TBD. Inherited from other documents, including
and .
TBD.
TBD.
TBD.
The Media Control Channel Framework
provides a generic approach for establishment and reporting
capabilities of remotely initiated commands. The Framework utilizes
many functions provided by the Session Initiation Protocol
(SIP) for the rendezvous and establishment of a reliable channel for
control interactions. The Control Framework also introduces the
concept of a Control Package. A Control Package is an explicit usage
of the Control Framework for a particular interaction set. This
specification defines a package for floor control in conferences based
on the use of the Binary Floor Control Protocol (BFCP) .
Floor control is needed whenever access to a resource, or set of resources,
needs to be moderated. A typical example is the right to talk in a conference.
In such a scenario, a participant willing to talk would first have to place
a request concerning the floor associated with such audio resource.
The participant would then be added to the conference mix only when his
request has been granted, by the server itself or by a designated chair.
RFC4582 defines a Binary Floor Control Protocol (BFCP)
to specifically deal with such a need. It defines all the relevant entities
(floors, queues, requests) and related actors (floor control servers, participants and chairs).
So, the scope of this package is adding BFCP-based floor control functionality
to complementary packages that might need it, as the Mixer Control Package
.
In particular, this package aims at dealing with the case where the Floor Control Server (FCS),
as defined in , is co-located with the Media Server (MS).
In fact, if the FCS were co-located with the Application Server (AS), floor
control would be part of the AS application logic, and thus out of scope for
the MS. A typical example of how this could be accomplished is the 'controller'
mechanism as specified in ,
where mixing in the MS and its contributors are actively setup by the AS, according
to any policy the AS might be enforcing, including floor control.
Considering users are added by the AS to the MS by means of a 3PCC
mechanism, a way to include BFCP negotiation
is needed. In fact, users willing to act as floor participants will need
to be made aware of all the relevant identifiers (i.e. the transport
address of the floor control server, the BFCP conference
ID associated with the mix, the BFCP user ID the user has been assigned,
all the floor identifiers and their mapping with existing resources, and
so on) to properly interact with a floor control server.
To achieve this, RFC4583 provides with
a way to negotiate BFCP connections within the context of a
SDP offer/answer .
This section fulfills the mandatory requirement for information that
MUST be specified during the definition of a Control Framework
Package, as detailed in Section 9 of
.
The Control Framework requires a Control Package definition to
specify and register a unique name and version.The name and version of this Control Package is "msc-bfcp/1.0"
(Media Server Control - Binary Floor Control - version 1.0).
BFCP functionality includes several different capabilities.
There must be means to appropriately create, modify and
destroy each of the available resources. This includes means
to create a BFCP conference with specified settings,
adding and removing floors to the conference, setting
or unsetting designated chairs for such floors and so on.
Proper subscription and notification mechanisms must also
be made available, in order to make the AS aware of all the
relevant events it might be interested to.
This package defines XML elements in
and provides an XML Schema in .
Additionally, some examples are provided in .
The XML elements in this package are split into requests, responses
and event notifications, all of which are contained within a root
<mscbfcp> element. Requests are carried in CONTROL message
bodies; <moderateconference> and <addfloor> elements
are examples of package requests. Responses are carried either in
REPORT message or Control Framework 200 response bodies; the
<response> element is defined as a package response. Event
notifications are instead carried in CONTROL message bodies; the
<event> element is defined for package event notifications. Event
subscription is accomplished by means of the <subscribe> element.
Note that package responses are different from framework response
codes. Framework error response codes (see Section 8 of
)
are used when the request or event notification is invalid; for example,
a request is invalid XML (400), or not understood (500). Package
responses are carried in 200 response or REPORT message bodies. This
package's response codes are defined in .
The schema uses the "connection-id" and "conf-id" attributes
which are imported from the schema defined in the core Control Framework
.
The Control Framework requires a Control Package definition to
specify if the attributes for media dialog or conference references
are required.
This package requires that the XML Schema in Section 17.1 of
MUST be supported for media dialogs and conferences.
The Control Framework requires a Control Package to define the
control body that can be contained within a CONTROL command request
and to indicate the location of detailed syntax definitions and
semantics for the appropriate body types.
When operating as Control Framework Server, the MS receives CONTROL
messages with a body containing an <mscbfcp> element with either a
floor control management or audit request child element.
The following mixer management request elements are carried in
CONTROL message bodies to MS: <moderateconference> (),
<unmoderateconference> (), <addfloor>
(), <modifyfloor> (), <removefloor>
(), <addparticipant> (),
<modifyparticipant> () and
<removeparticipant> () elements.
The <audit> request element () is also carried in
CONTROL message bodies.
When operating as Control Framework Client, the MS sends CONTROL
messages with a body containing a notification <event&gT; element
().
A valid REPORT body MUST conform to the schema defined in
and described in .
XML messages appearing in REPORT messages MUST contain a <response>
(), or a (notification)
<event> element ().
The Control Framework encourages Control Packages to specify whether
auditing is available, how it is triggered as well as the query/
response formats.
This Control Packages supports auditing of package capabilities and
dialogs on the MS. An audit request is carried in a CONTROL messages
and an audit response in a REPORT message (or a 200 reponse to the
CONTROL if it can execute the audit in time).
The syntax and semantics of audit request and response elements is
defined in Section 4.4.
Before delving into the details of the package elements,
a few words are worth being spent with respect to how
floors are assumed to be manipulated in this package.
Floors are defined as tokens associated with a
resource, or set of resources, in order to
moderate the access to their functionality
by users. This introduces the need for a mechanism
in the package to properly take care of this
kind of association, especially when dealing
about resources directly manipulated by
the Media Server (e.g. andio and video).
Let's consider the following figure, which
presents the view of an audio conference
with three participants, and the related
media labels associated with each participant's
media stream:
Even if each participant sees a different
label for the stream it has with the mixer,
the floor associated with the only available
resource in the conference (audio) is the same.
This means that the package needs to have
a way to address each resource in the conference
according to how it is defined in
,
e.g. "associate media 'audio' with floor 11" or
any other more complex assignment involving labels and the like.
Once a participant's media stream is attached to the
resource, the related label is consequently associated
with the floor as specified in .
depicts such the case
where all the participants have been attached to the
mix.
The same approach can be considered when dealing with
different floors associated with one or more different
resources, e.g. conferences with an audio and a video stream,
conferences with two different audio streams, and so on.
Each floor needs to be unambiguously associated with
a subset of the available resources (e.g. floor 11 is audio1
and floor 22 is video, or floor 11 is audio1 while floor 22 is
audio2, or floor 11 is audio1 AND audio2 AND video2, and
so on).
To achieve this, each floor, together with its configuration,
is defined in the package by the <floor> element, as
described in .
This section defines the XML messages for this control package.
[Editors Note: since XML Schema may not be able to express all
constraints expressed in these definitions, in cases where there is a
difference in constraints, the definitions in the section take
priority.]
The <mscbfcp> element has the following attributes
(in addition to standard XML namspace attributes such as xmlns):
version: a string specifying the mscbfcp package version. The
value is fixed as '1.0' for this version of the package. The
attribute is mandatory.
The <mscbfcp> element has the following defined child elements, only
one of which can occur:
create and configure a new BFCP conference, associated with
an existing framework conference instance to moderate - see
for details;
destroy a BFCP conference, thus stopping the moderation
of the associated framework conference instance - see
for details;
add and configure a new floor to an existing
BFCP conference - see
for details;
modify the configuration of a currently handled floor
in an existing BFCP conference - see
for details;
remove a currently handled floor from
an existing BFCP conference - see
for details;
add a floor participant to a BFCP conference - see
for details;
modify an existing floor participant in a BFCP conference - see
for details;
remove a floor participant from a BFCP conference - see
for details.
response to a floor control request - see
for details.
bfcp or subscription notification - see
for details.
All the previously introduced requests make use of the
same element specification to describe the desired operation.
Specifically, <moderateconference>, <addfloor> and
<modifyfloor> make use of the <floor> element
(), while <addparticipant>,
<modifyparticipant> and <removeparticipant> make
use of the <participant> element ().
The <floor> element is used in the package
to configure a floor in a BFCP conference. It addresses
all the relevant settings for a floor, including the
resource (or, again, set of resources) it must be
associated with, the maximum number of users that can
be granted the floor at the same time, the maximum number
of requests the same participant can place for this floor
at the same time, and the default policy the FCS considers
for incoming requests about the floor.
The <floor> element has the following
attributes:
string indicating the name of the BFCP floor.
This attribute is optional.
an element indicating the type of media associated with the
floor, i.e. the resource associated with the floor, as
defined in . The string
might be a comma-separated list in case the floor is associated
with more than one resource (e.g. media="audio,video").
This element is mandatory.
an element indicating the maximum number of users that
can be granted this floor at the same time: this basically
sets the size of the granted floor queue. In case all the
queue slots have already been granted, subsequent requests
are put on hold.
This element is optional: if missing, the default value
(max-users="1") is used.
an element indicating the maximum number of requests each user
can place for the floor before being granted it.
This element is optional: if missing, the default value
(max-requests"="1) is used.
an element indicating the default policy the FCS must take
whenever receiving requests for this floor and the chair
is missing. In fact, in case a chair is involved, the request
is forwarded to him, which then takes a decision about it.
The policy can be an 'autodeny' (deny all the requests for
this floor), 'autoaccept' (accept all the requests for this
floor) or 'ignore' (ignore all the requests for this floor and
put them on ice, waiting for a chair to appear) policy.
This element is optional: if missing, the default value
(policy="autoaccept") is used.
The "bfcp-floor-id" attribute has different roles
according to the request the <floor> element is part of.
The behaviour of the package changes accordingly. Specifically:
if the attribute is not specified,
the MS creates a unique name for the BFCP floor. The
value is used in subsequent references to the conference
(e.g. as bfcp-floor-id in a <modifyfloor>). The new value of
this attribute MUST be unique or else a 403 'Floor
already exists' package level error will be reported.
if the attribute is not specified,
the value of the attribute in the father element is used.
If it is specified, instead, it must not conflict with
the value of the attribute in the father element,
otherwise it is an error.
TBD. Elaborate the floor mechanism.
[Note: the first problem that comes to mind is the actual
association between a floor and a resource in the MS. Specifically,
enforcing the decisions might be an issue, since there's no way
this package and msc-mixer can talk with each other...]
TBD. Elaborate the participant mechanism.
[Note: this element will include the same mechanism used
in other packages to address a connection, in order to
associate a BFCP user identifier to it. Besides, it will
include means to specify whether or not a participant
is chair of any of the available floors.]
<moderateconference> is used in a request by the AS
to moderate an existing conference instance, by associating
to it a new, properly configured, BFCP conference.
The <moderateconference> element has the following
attributes:
string indicating the name of the conference
to moderate. The conference MUST be known by the
receiving entity or else a 404 'Conference does not
exist' package level error will be generated.
This attribute is mandatory.
string (an unsigned integer) indicating a unique name
for the BFCP conference. If this attribute is not specified,
the MS creates a unique name for the BFCP conference. The
value is used in subsequent references to the conference
(e.g. as bfcp-conf-id in a <response>), and in actual
BFCP protocol contents as well, and as such MUST adhere to
the syntax defined in . When present
in a <moderateconference> request, the new value of
this attribute MUST be unique or else a 403 'Conference
already exists' package level error will be reported.
The attribute is optional.
Additionally, to configure the new BFCP conference, the <moderateconference>
element has the following child elements defined:
an element () to configure a floor in the new BFCP conference
(see for more details). This element
only refers to floors already available at creation time.
New floors can still be added subsequently by means of
an <addfloor> request (see ).
This element is optional.
an element to request subscription to conference
events. (see for more details).
This element is optional.
Multiple <floor> elements may be defined, in case several
floors are needed.
When a MS has finished processing a <moderateconference>
request, it MUST reply with an appropriate <response> element
().
<unmoderateconference> is used in a request by the AS
to destroy a BFCP conference, thus stopping the moderatation
of the associated existing framework conference instance. A
successful processing of this request does NOT result in a
destruction of the associated media conference: it only
results in the media conference not being moderated by means
of BFCP anymore. The actual destruction of the media conference
itself is accomplished through the means provided in
.
The <unmoderateconference> element has the following
attributes:
string indicating the name of the BFCP conference
to destroy. The conference MUST be known by the
receiving entity or else a 404 'Conference does not
exist' package level error will be generated.
This attribute is mandatory.
The <unmoderateconference> element does not specify
any child elements.
When a MS has finished processing an <unmoderateconference>
request, it MUST reply with an appropriate <response> element
().
<addfloor> is used in a request by the AS to add one or
more floors to an existing BFCP conference instance.
The <addfloor> element has the following
attributes:
string indicating the name of the BFCP conference
to add the floor(s) to. The conference MUST be known by the
receiving entity or else a 404 'Conference does not
exist' package level error will be generated.
This attribute is mandatory.
Additionally, to configure the new floor(s), the <addfloor>
element has the following child elements defined:
an element to configure a new floor in the specified BFCP conference
(see for more details).
This element is mandatory.
Multiple <floor> elements may be defined, in case several
floors are to be added at the same time.
When a MS has finished processing an <addfloor>
request, it MUST reply with an appropriate <response> element
().
<modifyfloor> is used in a request by the AS to modify
the configuration of a floor in an existing BFCP conference instance.
The <modifyfloor> element has the following
attributes:
string indicating the name of the BFCP conference
to modify the floor's in. The conference MUST be known by the
receiving entity or else a 404 'Conference does not
exist' package level error will be generated.
This attribute is mandatory.
string indicating the name of the BFCP floor
to modify the floor. The floor MUST be known by the
receiving entity or else a 404 'Floor does not
exist' package level error will be generated.
This attribute is mandatory.
Additionally, to modify the configuration of the floor, the <modifyfloor>
element has the following child elements defined:
an element to configure the specified floor in the specified BFCP conference
(see for more details).
This element is mandatory.
It is an error if the provided <floor> element
conflicts with the BFCP floor identifier attribute.
When a MS has finished processing a <modifyfloor>
request, it MUST reply with an appropriate <response> element
().
<removefloor> is used in a request by the AS to remove
an existing floor from the BFCP conference instance it is in.
A successful processing of this request does NOT result in a
destruction of the associated resource (or set of resources): it only
results in the associated resource not being moderated by means
of BFCP anymore. The actual destruction of the resource (in
case it is directly handled and manipulated by the MS itself)
is accomplished through the means provided in
.
The <removefloor> element has the following
attributes:
string indicating the name of the BFCP conference
to remove the floor from. The conference MUST be known by the
receiving entity or else a 404 'Conference does not
exist' package level error will be generated.
This attribute is mandatory.
string indicating the name of the BFCP floor
to remove. The floor MUST be known by the
receiving entity or else a 404 'Floor does not
exist' package level error will be generated.
This attribute is mandatory.
The <removefloor> element does not specify
any child elements.
When a MS has finished processing a <removefloor>
request, it MUST reply with an appropriate <response> element
().
<addparticipant> is used in a request by the AS to add a
new BFCP participant instance to an existing BFCP conference. Some
additional details can also be provided about the new participant,
if it will be the chair of one of the floors for example.
The <addparticipant> element has the following
attributes:
string indicating the name of the BFCP conference
to add the participant to. The conference MUST be known by the
receiving entity or else a 404 'Conference does not
exist' package level error will be generated.
This attribute is mandatory.
string (an unsigned integer) indicating a unique name
for the new BFCP participant. If this attribute is not specified,
the MS creates a unique name for the BFCP participant. The
value is used in subsequent references to the conference
(e.g. as bfcp-conf-id in a <response>), and in actual
BFCP protocol contents as well, and as such MUST adhere to
the syntax defined in . When present
in an <addparticipant> request, the new value of
this attribute MUST be unique or else a 405 'User
already exists' package level error will be reported.
The attribute is optional.
Additionally, to configure the new participant, the <addparticipant>
element has the following child elements defined:
an element to configure a new floor in the specified BFCP conference
(see for more details).
This element is mandatory.
Only one <participant> element can be present, which means only
one BFCP participant instance can be added at the same time.
When a MS has finished processing an <addparticipant>
request, it MUST reply with an appropriate <response> element
().
[Note: is this really needed? there may be RFC4583 for that...]
<modifyparticipant> is used in a request by the AS to modify
the configuration of a participant in an existing BFCP conference instance.
A typical use case for this request is to set or unset a participant
as chair of a floor in a conference.
The <modifyparticipant> element has the following
attributes:
string indicating the name of the BFCP conference
to modify the floor's in. The conference MUST be known by the
receiving entity or else a 404 'Conference does not
exist' package level error will be generated.
This attribute is mandatory.
string indicating the name of the BFCP participant whose
settings must be modified. The participant MUST be known by the
receiving entity or else a 406 'User does not
exist' package level error will be generated.
This attribute is mandatory.
Additionally, to modify the configuration of the participant, the <modifyparticipant>
element has the following child elements defined:
an element to configure the specified participant in the specified BFCP conference
(see for more details).
This element is mandatory.
It is an error if the provided <participant> element
conflicts with the BFCP participant identifier attribute.
When a MS has finished processing a <modifyparticipant>
request, it MUST reply with an appropriate <response> element
().
<removeparticipant> is used in a request by the AS to remove
an existing participant from the BFCP conference instance it is in.
A successful processing of this request does NOT result in a
termination of the participant's media session: it only
results in the associated media streams not being moderated by means
of BFCP anymore..
The <removeparticipant> element has the following
attributes:
string indicating the name of the BFCP conference
to remove the floor from. The conference MUST be known by the
receiving entity or else a 404 'Conference does not
exist' package level error will be generated.
This attribute is mandatory.
string indicating the name of the BFCP participant
to remove. The participant MUST be known by the
receiving entity or else a 406 'User does not
exist' package level error will be generated.
This attribute is mandatory.
The <removeparticipant> element does not specify
any child elements.
When a MS has finished processing a <removeparticipant>
request, it MUST reply with an appropriate <response> element
().
[Note: is this really needed? there may be RFC4583 for that...]
All responses to the previously described requests
are specified in a <response> element. This element
may be contained in the body either of a REPORT framework message
or in a 200 framework message.
Reponses to requests are indicated by a <response>
element.
The <response> element has the
following attributes:
numeric code indicating the response status.
This attribute is mandatory.
string specifying a human readable description
of the reason for the response status.
This attribute is optional.
string identifying the BFCP conference the
request referred to.
This attribute is optional.
string identifying the BFCP floor the
request referred to.
This attribute is optional.
The following status codes are defined:
codedescription200OK4xxwhatever
TBD. Add all error codes and their meanings
In case the AS is interested in receiving events
regarding a BFCP conference, a notification mechanism
is provided in the package. The AS requests subscription to
such events by adding a <subscribe> child
element to the <moderateconference> request,
whereas the MS triggers the related events
in subsequent REPORT messages. Event notifications
are then delivered using the <event> element.
BFCP event notifications are defined when an
AS subscribes to notifications
for BFCP-related events using the <subscribe>
element in a <moderateconference> request.
The <subscribe> element has no attributes,
but has the following child elements defined:
contains the following attributes:
a string indicating the name of the event
to be notified. This attribute is mandatory.
Multiple <notify> elements may be specified.
The MS would then use the <event> element to send
notifications to the AS.
Delivery of events the AS subscribed for is accomplished
by means of an <event> element.
The <event> element has the following
attributes:
string indicating the name of the BFCP event.
This attribute is mandatory.
string identifying the BFCP conference the
event happened in.
This attribute is mandatory.
Additionally, to provide the AS with details upon the event, the <event>
element has the following child elements defined:
TBD. Elaborate the notification mechanism.
TBD.TBD.
TBD.
TBD.
TBD.
TBD.
The following are the major changes between the
-00 and the -01 versions of the draft:
updated references (mixer draft);updated authors;aligned syntax to the one used in msc-ivr and msc-mixer (<mscbfcp>);added placeholders for event notifications and auditing;added participant related methods, and moved floor related discussions;
TBD.