One document matched: draft-miniero-bfcp-control-package-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="full3978" docName="draft-miniero-bfcp-control-package-01">
<front>
<title abbrev="BFCP Control Package">
A Binary Floor Control Protocol (BFCP) Control Package for the Media Control Channel Framework
</title>
<author initials="L." surname="Miniero" fullname="Lorenzo Miniero">
<organization>University of Napoli</organization>
<address>
<postal>
<street>Via Claudio 21</street>
<code>80125</code>
<city>Napoli</city>
<country>Italy</country>
</postal>
<email>lorenzo.miniero@unina.it</email>
</address>
</author>
<author initials="S P" surname="Romano" fullname="Simon Pietro Romano">
<organization>University of Napoli</organization>
<address>
<postal>
<street>Via Claudio 21</street>
<code>80125</code>
<city>Napoli</city>
<country>Italy</country>
</postal>
<email>spromano@unina.it</email>
</address>
</author>
<author initials="R." surname="Even" fullname="Roni Even">
<organization>Polycom</organization>
<address>
<postal>
<street>94 Derech Em Hamoshavot</street>
<code>49130</code>
<city>Petach Tikva</city>
<country>Israel</country>
</postal>
<email>roni.even@polycom.co.il</email>
</address>
</author>
<author initials="S." surname="McGlashan" fullname="Scott McGlashan">
<organization>Hewlett-Packard</organization>
<address>
<postal>
<street>Gustav III:s boulevard 36</street>
<code>SE-16985</code>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>scott.mcglashan@hp.com</email>
</address>
</author>
<date month="July" year="2008"/>
<area>RAI</area>
<workgroup>Network Working Group</workgroup>
<keyword>MediaCtrl</keyword>
<keyword>Media Server Control</keyword>
<keyword>Media Control Channel Framework</keyword>
<keyword>BFCP</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<!-- Introduction -->
<section title="Introduction" anchor="sec-intro">
<t>
The Media Control Channel Framework <xref target="I-D.ietf-mediactrl-sip-control-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) <xref target="RFC3261"/> 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) <xref target="RFC4582"/>.
</t>
</section>
<!-- Conventions -->
<section title="Conventions" anchor="sec-conv">
<t>
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 <xref target="RFC2119"/> and
indicate requirement levels for compliant implementations.
</t>
</section>
<!-- Terminology -->
<section title="Terminology" anchor="sec-teminology">
<t>
TBD. Inherited from other documents, including
<xref target="I-D.ietf-mediactrl-sip-control-framework"/>
and <xref target="I-D.ietf-mediactrl-mixer-control-package"/>.
</t>
<t>
<list style="hanging">
<t hangText="Application Server:">
TBD.
</t>
<vspace blankLines='1'/>
<t hangText="Media Server:">
TBD.
</t>
<vspace blankLines='1'/>
<t hangText="Control Package:">
TBD.
</t>
</list>
</t>
</section>
<!-- Overview -->
<section title="Overview" anchor="sec-overview">
<t>
The Media Control Channel Framework <xref target="I-D.ietf-mediactrl-sip-control-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) <xref target="RFC3261"/> 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) <xref target="RFC4582"/>.
</t>
<t>
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 <xref target="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
<xref target="I-D.ietf-mediactrl-mixer-control-package"/>.
In particular, this package aims at dealing with the case where the Floor Control Server (FCS),
as defined in <xref target="RFC4582"/>, 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 <xref target="I-D.ietf-mediactrl-mixer-control-package"/>,
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.
</t>
<t>
Considering users are added by the AS to the MS by means of a 3PCC
<xref target="RFC3725"/> 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 <xref target="RFC4583"/> provides with
a way to negotiate BFCP connections within the context of a
SDP offer/answer <xref target="RFC3264"/>.
</t>
</section>
<!-- Control Package Definition -->
<section title="Control Package Definition" anchor="sec-ctrlpkg">
<t>
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
<xref target="I-D.ietf-mediactrl-sip-control-framework"/>.
</t>
<section title="Control Package Name" anchor="sec-ctrlpkg-name">
<t>
<t>The Control Framework requires a Control Package definition to
specify and register a unique name and version.</t>
<t>The name and version of this Control Package is "msc-bfcp/1.0"
(Media Server Control - Binary Floor Control - version 1.0).</t>
</t>
</section>
<section title="Framework Message Usage" anchor="sec-ctrlpkg-msg">
<t>
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.
</t>
<t>
This package defines XML elements in <xref target="sec-element"/>
and provides an XML Schema in <xref target="sec-syntax"/>.
Additionally, some examples are provided in <xref target="sec-examples"/>.
</t>
<t>
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.
</t>
<t>
Note that package responses are different from framework response
codes. Framework error response codes (see Section 8 of
<xref target="I-D.ietf-mediactrl-sip-control-framework"/>)
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 <xref target="sec-response"/>.
</t>
<t>
The schema uses the "connection-id" and "conf-id" attributes
which are imported from the schema defined in the core Control Framework
<xref target="I-D.ietf-mediactrl-sip-control-framework"/>.
</t>
</section>
<section title="Common XML Support" anchor="sec-ctrlpkg-xml">
<t>
The Control Framework requires a Control Package definition to
specify if the attributes for media dialog or conference references
are required.
</t>
<t>
This package requires that the XML Schema in Section 17.1 of
<xref target="I-D.ietf-mediactrl-sip-control-framework"/>
MUST be supported for media dialogs and conferences.
</t>
</section>
<section title="CONTROL Message Body" anchor="sec-ctrlpkg-control">
<t>
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.
</t>
<t>
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.
</t>
<t>
The following mixer management request elements are carried in
CONTROL message bodies to MS: <moderateconference> (<xref target="sec-moderate"/>),
<unmoderateconference> (<xref target="sec-unmoderate"/>), <addfloor>
(<xref target="sec-addfloor"/>), <modifyfloor> (<xref target="sec-modifyfloor"/>), <removefloor>
(<xref target="sec-removefloor"/>), <addparticipant> (<xref target="sec-addparticipant"/>),
<modifyparticipant> (<xref target="sec-modifyparticipant"/>) and
<removeparticipant> (<xref target="sec-removeparticipant"/>) elements.
</t>
<t>
The <audit> request element (<xref target="sec-audit-root"/>) is also carried in
CONTROL message bodies.
</t>
<t>
When operating as Control Framework Client, the MS sends CONTROL
messages with a body containing a notification <event&gT; element
(<xref target="sec-event"/>).
</t>
</section>
<section title="REPORT Message Body" anchor="sec-ctrlpkg-report">
<t>
A valid REPORT body MUST conform to the schema defined in
<xref target="sec-syntax"/> and described in <xref target="sec-element"/>.
XML messages appearing in REPORT messages MUST contain a <response>
(<xref target="sec-response"/>), or a (notification)
<event> element (<xref target="sec-event"/>).
</t>
</section>
<section title="Audit" anchor="sec-ctrlpkg-audit">
<t>
The Control Framework encourages Control Packages to specify whether
auditing is available, how it is triggered as well as the query/
response formats.
</t>
<t>
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).
</t>
<t>
The syntax and semantics of audit request and response elements is
defined in Section 4.4.
</t>
</section>
</section>
<section title="Floors Manipulation" anchor="sec-floors">
<t>
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.
</t>
<t>
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).
</t>
<t>
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:
</t>
<t>
<figure anchor="fig-conf-audio" title="Audio Conference with labels">
<artwork>
<![CDATA[
MS
+---------------+
UAC A | | UAC B
o-----------+--x x--+-----------o
a1b2c3 | | d4e5f6
| |
| x |
| | |
+-------+-------+
|
| g7h8i9
|
o
UAC C
]]>
</artwork>
</figure>
</t>
<t>
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
<xref target="I-D.ietf-mediactrl-mixer-control-package"/>,
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 <xref target="RFC4583"/>.
<xref target="fig-conf-bfcp"/> depicts such the case
where all the participants have been attached to the
mix.
</t>
<t>
<figure anchor="fig-conf-bfcp" title="Audio Conference with labels and floors">
<artwork>
<![CDATA[
MS
+---------------+
UAC A | | UAC B
o-----------+--+~~>[ ]<~~+--+-----------o
a1b2c3 | ^ | d4e5f6
(floor 11) | | | (floor 11)
| + |
| | |
+-------+-------+
|
| g7h8i9
| (floor 11)
o
UAC C
]]>
</artwork>
</figure>
</t>
<t>
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).
</t>
<t>
To achieve this, each floor, together with its configuration,
is defined in the package by the <floor> element, as
described in <xref target="sec-floor"/>.
</t>
</section>
<!-- Element Definitions -->
<section title="Element Definitions" anchor="sec-element">
<t>
This section defines the XML messages for this control package.
</t>
<t>
[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.]
</t>
<section title="<mscbfcp>" anchor="sec-mscbfcp">
<t>
The <mscbfcp> element has the following attributes
(in addition to standard XML namspace attributes such as xmlns):
</t>
<t>
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.
</t>
<t>
The <mscbfcp> element has the following defined child elements, only
one of which can occur:
</t>
<t>
<list style="hanging">
<t hangText="<moderateconference>:">
create and configure a new BFCP conference, associated with
an existing framework conference instance to moderate - see
<xref target="sec-moderate"/> for details;
</t>
<vspace blankLines='1'/>
<t hangText="<unmoderateconference>:">
destroy a BFCP conference, thus stopping the moderation
of the associated framework conference instance - see
<xref target="sec-unmoderate"/> for details;
</t>
<vspace blankLines='1'/>
<t hangText="<addfloor>:">
add and configure a new floor to an existing
BFCP conference - see
<xref target="sec-addfloor"/> for details;
</t>
<vspace blankLines='1'/>
<t hangText="<modifyfloor>:">
modify the configuration of a currently handled floor
in an existing BFCP conference - see
<xref target="sec-modifyfloor"/> for details;
</t>
<vspace blankLines='1'/>
<t hangText="<removefloor>:">
remove a currently handled floor from
an existing BFCP conference - see
<xref target="sec-removefloor"/> for details;
</t>
<vspace blankLines='1'/>
<t hangText="<addparticipant>:">
add a floor participant to a BFCP conference - see
<xref target="sec-addparticipant"/> for details;
</t>
<vspace blankLines='1'/>
<t hangText="<modifyparticipant>:">
modify an existing floor participant in a BFCP conference - see
<xref target="sec-modifyparticipant"/> for details;
</t>
<vspace blankLines='1'/>
<t hangText="<removeparticipant>:">
remove a floor participant from a BFCP conference - see
<xref target="sec-removeparticipant"/> for details.
</t>
<vspace blankLines='1'/>
<t hangText="<response>:">
response to a floor control request - see
<xref target="sec-responses"/> for details.
</t>
<vspace blankLines='1'/>
<t hangText="<event>:">
bfcp or subscription notification - see
<xref target="sec-notifications"/> for details.
</t>
</list>
</t>
<section title="Shared elements" anchor="sec-shared">
<t>
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
(<xref target="sec-floor"/>), while <addparticipant>,
<modifyparticipant> and <removeparticipant> make
use of the <participant> element (<xref target="sec-participant"/>).
</t>
<section title="<floor>" anchor="sec-floor">
<t>
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.
</t>
<t>
The <floor> element has the following
attributes:
</t>
<t>
<list style="hanging">
<t hangText="bfcp-floor-id:">
string indicating the name of the BFCP floor.
This attribute is optional.
</t>
<vspace blankLines='1'/>
<t hangText="<media>:">
an element indicating the type of media associated with the
floor, i.e. the resource associated with the floor, as
defined in <xref target="I-D.ietf-mediactrl-mixer-control-package"/>. 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.
</t>
<vspace blankLines='1'/>
<t hangText="<max-users>:">
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.
</t>
<vspace blankLines='1'/>
<t hangText="<max-requests>:">
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.
</t>
<vspace blankLines='1'/>
<t hangText="<policy>:">
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.
</t>
</list>
</t>
<t>
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:
</t>
<t>
<list style="hanging">
<t hangText="<moderateconference|addfloor>:">
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.
</t>
<vspace blankLines='1'/>
<t hangText="<modifyfloor>:">
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.
</t>
</list>
</t>
<t>
TBD. Elaborate the floor mechanism.
</t><t>
[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...]
</t>
</section>
<section title="<participant>" anchor="sec-participant">
<t>
TBD. Elaborate the participant mechanism.
</t>
<t>
[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.]
</t>
</section>
</section>
<section title="Requests" anchor="sec-requests">
<section title="<moderateconference>" anchor="sec-moderate">
<t>
<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.
</t>
<t>
The <moderateconference> element has the following
attributes:
</t>
<t>
<list style="hanging">
<t hangText="conf-id:">
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.
</t>
<vspace blankLines='1'/>
<t hangText="bfcp-conf-id:">
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 <xref target="RFC4582"/>. 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.
</t>
</list>
</t>
<t>
Additionally, to configure the new BFCP conference, the <moderateconference>
element has the following child elements defined:
</t>
<t>
<list style="hanging">
<t hangText="<floor>:">
an element (<xref target="sec-floor"/>) to configure a floor in the new BFCP conference
(see <xref target="sec-floor"/> 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 <xref target="sec-addfloor"/>).
This element is optional.
</t>
<vspace blankLines='1'/>
<t hangText="<subscribe>:">
an element to request subscription to conference
events. (see <xref target="sec-subscribe"/> for more details).
This element is optional.
</t>
</list>
</t>
<t>
Multiple <floor> elements may be defined, in case several
floors are needed.
</t>
<t>
When a MS has finished processing a <moderateconference>
request, it MUST reply with an appropriate <response> element
(<xref target="sec-responses"/>).
</t>
</section>
<section title="<unmoderateconference>" anchor="sec-unmoderate">
<t>
<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
<xref target="I-D.ietf-mediactrl-mixer-control-package"/>.
</t>
<t>
The <unmoderateconference> element has the following
attributes:
</t>
<t>
<list style="hanging">
<t hangText="bfcp-conf-id:">
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.
</t>
</list>
</t>
<t>
The <unmoderateconference> element does not specify
any child elements.
</t>
<t>
When a MS has finished processing an <unmoderateconference>
request, it MUST reply with an appropriate <response> element
(<xref target="sec-response"/>).
</t>
</section>
<section title="<addfloor>" anchor="sec-addfloor">
<t>
<addfloor> is used in a request by the AS to add one or
more floors to an existing BFCP conference instance.
</t>
<t>
The <addfloor> element has the following
attributes:
</t>
<t>
<list style="hanging">
<t hangText="bfcp-conf-id:">
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.
</t>
</list>
</t>
<t>
Additionally, to configure the new floor(s), the <addfloor>
element has the following child elements defined:
</t>
<t>
<list style="hanging">
<t hangText="<floor>:">
an element to configure a new floor in the specified BFCP conference
(see <xref target="sec-floor"/> for more details).
This element is mandatory.
</t>
</list>
</t>
<t>
Multiple <floor> elements may be defined, in case several
floors are to be added at the same time.
</t>
<t>
When a MS has finished processing an <addfloor>
request, it MUST reply with an appropriate <response> element
(<xref target="sec-response"/>).
</t>
</section>
<section title="<modifyfloor>" anchor="sec-modifyfloor">
<t>
<modifyfloor> is used in a request by the AS to modify
the configuration of a floor in an existing BFCP conference instance.
</t>
<t>
The <modifyfloor> element has the following
attributes:
</t>
<t>
<list style="hanging">
<t hangText="bfcp-conf-id:">
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.
</t>
<vspace blankLines='1'/>
<t hangText="bfcp-floor-id:">
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.
</t>
</list>
</t>
<t>
Additionally, to modify the configuration of the floor, the <modifyfloor>
element has the following child elements defined:
</t>
<t>
<list style="hanging">
<t hangText="<floor>:">
an element to configure the specified floor in the specified BFCP conference
(see <xref target="sec-floor"/> for more details).
This element is mandatory.
</t>
</list>
</t>
<t>
It is an error if the provided <floor> element
conflicts with the BFCP floor identifier attribute.
</t>
<t>
When a MS has finished processing a <modifyfloor>
request, it MUST reply with an appropriate <response> element
(<xref target="sec-response"/>).
</t>
</section>
<section title="<removefloor>" anchor="sec-removefloor">
<t>
<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
<xref target="I-D.ietf-mediactrl-mixer-control-package"/>.
</t>
<t>
The <removefloor> element has the following
attributes:
</t>
<t>
<list style="hanging">
<t hangText="bfcp-conf-id:">
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.
</t>
<vspace blankLines='1'/>
<t hangText="bfcp-floor-id:">
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.
</t>
</list>
</t>
<t>
The <removefloor> element does not specify
any child elements.
</t>
<t>
When a MS has finished processing a <removefloor>
request, it MUST reply with an appropriate <response> element
(<xref target="sec-response"/>).
</t>
</section>
<section title="<addparticipant>" anchor="sec-addparticipant">
<t>
<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.
</t>
<t>
The <addparticipant> element has the following
attributes:
</t>
<t>
<list style="hanging">
<t hangText="bfcp-conf-id:">
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.
</t>
<vspace blankLines='1'/>
<t hangText="bfcp-user-id:">
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 <xref target="RFC4582"/>. 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.
</t>
</list>
</t>
<t>
Additionally, to configure the new participant, the <addparticipant>
element has the following child elements defined:
</t>
<t>
<list style="hanging">
<t hangText="<participant>:">
an element to configure a new floor in the specified BFCP conference
(see <xref target="sec-participant"/> for more details).
This element is mandatory.
</t>
</list>
</t>
<t>
Only one <participant> element can be present, which means only
one BFCP participant instance can be added at the same time.
</t>
<t>
When a MS has finished processing an <addparticipant>
request, it MUST reply with an appropriate <response> element
(<xref target="sec-response"/>).
</t>
<t>
[Note: is this really needed? there may be RFC4583 for that...]
</t>
</section>
<section title="<modifyparticipant>" anchor="sec-modifyparticipant">
<t>
<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.
</t>
<t>
The <modifyparticipant> element has the following
attributes:
</t>
<t>
<list style="hanging">
<t hangText="bfcp-conf-id:">
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.
</t>
<vspace blankLines='1'/>
<t hangText="bfcp-user-id:">
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.
</t>
</list>
</t>
<t>
Additionally, to modify the configuration of the participant, the <modifyparticipant>
element has the following child elements defined:
</t>
<t>
<list style="hanging">
<t hangText="<participant>:">
an element to configure the specified participant in the specified BFCP conference
(see <xref target="sec-participant"/> for more details).
This element is mandatory.
</t>
</list>
</t>
<t>
It is an error if the provided <participant> element
conflicts with the BFCP participant identifier attribute.
</t>
<t>
When a MS has finished processing a <modifyparticipant>
request, it MUST reply with an appropriate <response> element
(<xref target="sec-response"/>).
</t>
</section>
<section title="<removeparticipant>" anchor="sec-removeparticipant">
<t>
<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..
</t>
<t>
The <removeparticipant> element has the following
attributes:
</t>
<t>
<list style="hanging">
<t hangText="bfcp-conf-id:">
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.
</t>
<vspace blankLines='1'/>
<t hangText="bfcp-user-id:">
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.
</t>
</list>
</t>
<t>
The <removeparticipant> element does not specify
any child elements.
</t>
<t>
When a MS has finished processing a <removeparticipant>
request, it MUST reply with an appropriate <response> element
(<xref target="sec-response"/>).
</t>
<t>
[Note: is this really needed? there may be RFC4583 for that...]
</t>
</section>
</section>
<section title="Responses" anchor="sec-responses">
<t>
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.
</t>
<section title="<response>" anchor="sec-response">
<t>
Reponses to requests are indicated by a <response>
element.
</t>
<t>
The <response> element has the
following attributes:
</t>
<t>
<list style="hanging">
<t hangText="status:">
numeric code indicating the response status.
This attribute is mandatory.
</t>
<vspace blankLines='1'/>
<t hangText="reason:">
string specifying a human readable description
of the reason for the response status.
This attribute is optional.
</t>
<vspace blankLines='1'/>
<t hangText="bfcp-conf-id:">
string identifying the BFCP conference the
request referred to.
This attribute is optional.
</t>
<vspace blankLines='1'/>
<t hangText="bfcp-floor-id:">
string identifying the BFCP floor the
request referred to.
This attribute is optional.
</t>
</list>
</t>
<t>
The following status codes are defined:
</t>
<t>
<texttable anchor="tab-error-codes" title="<response> Status codes">
<ttcol align='left'>code</ttcol>
<ttcol align='left'>description</ttcol>
<c>200</c><c>OK</c>
<c>4xx</c><c>whatever</c>
</texttable>
</t>
<t>
TBD. Add all error codes and their meanings
</t>
</section>
</section>
<section title="Notifications" anchor="sec-notifications">
<t>
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.
</t>
<section title="<subscribe>" anchor="sec-subscribe">
<t>
BFCP event notifications are defined when an
AS subscribes to notifications
for BFCP-related events using the <subscribe>
element in a <moderateconference> request.
</t>
<t>
The <subscribe> element has no attributes,
but has the following child elements defined:
</t>
<t>
<list style="hanging">
<t hangText="<notify>:">
contains the following attributes:
<list style="hanging">
<t hangText="name:">
a string indicating the name of the event
to be notified. This attribute is mandatory.
</t>
</list>
</t>
</list>
</t>
<t>
Multiple <notify> elements may be specified.
</t>
<t>
The MS would then use the <event> element to send
notifications to the AS.
</t>
</section>
<section title="<event>" anchor="sec-event">
<t>
Delivery of events the AS subscribed for is accomplished
by means of an <event> element.
</t>
<t>
The <event> element has the following
attributes:
</t>
<t>
<list style="hanging">
<t hangText="name:">
string indicating the name of the BFCP event.
This attribute is mandatory.
</t>
<vspace blankLines='1'/>
<t hangText="bfcp-conf-id:">
string identifying the BFCP conference the
event happened in.
This attribute is mandatory.
</t>
</list>
</t>
<t>
Additionally, to provide the AS with details upon the event, the <event>
element has the following child elements defined:
</t>
<t>
<!--
<list style="hanging">
<t hangText="<data>:">
an element to configure the specified floor in the specified BFCP conference
(see <xref target="sec-floor"/> for more details).
This element is mandatory.
</t>
</list>
-->
TBD. Elaborate the notification mechanism.
</t>
</section>
</section>
</section>
<section title="Audit Elements" anchor="sec-audit">
<section title="<audit>" anchor="sec-audit-root">
<t>TBD.</t>
</section>
<section title="<auditresponse>" anchor="sec-audit-response">
<t>TBD.</t>
</section>
</section>
</section>
<!-- Examples -->
<section title="Examples" anchor="sec-examples">
<t>
TBD.
</t>
</section>
<!-- Formal Syntax -->
<section title="Formal Syntax" anchor="sec-syntax">
<t>
TBD.
</t>
</section>
<!-- Security Considerations -->
<section title="Security Considerations" anchor="sec-security">
<t>
TBD.
</t>
</section>
<!-- IANA -->
<section title="IANA Considerations" anchor="sec-iana">
<t>
TBD.
</t>
</section>
<!-- Changelog -->
<section title="Change Summary" anchor="sec-changes">
<t>
The following are the major changes between the
-00 and the -01 versions of the draft:
</t>
<t>
<list style="symbols">
<t>updated references (mixer draft);</t>
<vspace blankLines='1'/>
<t>updated authors;</t>
<vspace blankLines='1'/>
<t>aligned syntax to the one used in msc-ivr and msc-mixer (<mscbfcp>);</t>
<vspace blankLines='1'/>
<t>added placeholders for event notifications and auditing;</t>
<vspace blankLines='1'/>
<t>added participant related methods, and moved floor related discussions;</t>
</list>
</t>
</section>
<!-- Acknowledgements -->
<section title="Acknowledgements" anchor="sec-acks">
<t>
TBD.
</t>
</section>
</middle>
<back>
<references title="References">
<!-- BNF -->
<?rfc include="reference.RFC.2234"?>
<!-- Terminology -->
<?rfc include="reference.RFC.2119"?>
<!-- IANA Guidelines -->
<?rfc include="reference.RFC.2434"?>
<!-- SIP -->
<?rfc include="reference.RFC.3261"?>
<!-- SIP/SDP -->
<?rfc include="reference.RFC.3264"?>
<!-- 3PCC -->
<?rfc include="reference.RFC.3725"?>
<!-- RTP -->
<?rfc include="reference.RFC.3550"?>
<!-- BFCP -->
<?rfc include="reference.RFC.4582"?>
<!-- BFCP/SDP -->
<?rfc include="reference.RFC.4583"?>
<!-- Label -->
<?rfc include="reference.RFC.4574"?>
<!-- Media Control Channel Framework -->
<?rfc include="reference.I-D.ietf-mediactrl-sip-control-framework"?>
<!-- IVR package -->
<?rfc include="reference.I-D.ietf-mediactrl-ivr-control-package"?>
<!-- Conferencing package -->
<?rfc include="reference.I-D.ietf-mediactrl-mixer-control-package"?>
<!-- VoiceXML package -->
<?rfc include="reference.I-D.boulton-ivr-vxml-control-package"?>
</references>
</back>
</rfc>
<!-- LocalWords: xref PPR PPA SAA RTA RTR LIR LIA CDATA -->
| PAFTECH AB 2003-2026 | 2026-04-23 14:22:27 |