A Binary Floor Control Protocol (BFCP) Control Package for the Media Control Channel Framework
draft-miniero-bfcp-control-package-01

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 9, 2009.

Abstract

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.

Table of Contents

1.  Introduction
2.  Conventions
3.  Terminology
4.  Overview
5.  Control Package Definition
    5.1.  Control Package Name
    5.2.  Framework Message Usage
    5.3.  Common XML Support
    5.4.  CONTROL Message Body
    5.5.  REPORT Message Body
    5.6.  Audit
6.  Floors Manipulation
7.  Element Definitions
    7.1. 
        7.1.1.  Shared elements
        7.1.2.  Requests
        7.1.3.  Responses
        7.1.4.  Notifications
    7.2.  Audit Elements
        7.2.1. 
        7.2.2. 
8.  Examples
9.  Formal Syntax
10.  Security Considerations
11.  IANA Considerations
12.  Change Summary
13.  Acknowledgements
14.  References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

The Media Control Channel Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.) 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) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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) [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.).

2.  Conventions

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) and indicate requirement levels for compliant implementations.

3.  Terminology

TBD. Inherited from other documents, including [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.) and [I‑D.ietf‑mediactrl‑mixer‑control‑package] (McGlashan, S., Melanchuk, T., and C. Boulton, “A Mixer Control Package for the Media Control Channel Framework,” February 2010.).

Application Server:

TBD.

Media Server:

TBD.

Control Package:

TBD.

4.  Overview

The Media Control Channel Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.) 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) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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) [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.).

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 [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.) 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 [I‑D.ietf‑mediactrl‑mixer‑control‑package] (McGlashan, S., Melanchuk, T., and C. Boulton, “A Mixer Control Package for the Media Control Channel Framework,” February 2010.). In particular, this package aims at dealing with the case where the Floor Control Server (FCS), as defined in [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.), 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 [I‑D.ietf‑mediactrl‑mixer‑control‑package] (McGlashan, S., Melanchuk, T., and C. Boulton, “A Mixer Control Package for the Media Control Channel Framework,” February 2010.), 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 [RFC3725] (Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” April 2004.) 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 [RFC4583] (Camarillo, G., “Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams,” November 2006.) provides with a way to negotiate BFCP connections within the context of a SDP offer/answer [RFC3264] (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.).

5.  Control Package Definition

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 [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.).

5.1.  Control Package Name

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

5.2.  Framework Message Usage

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 Section 7 (Element Definitions) and provides an XML Schema in Section 9 (Formal Syntax). Additionally, some examples are provided in Section 8 (Examples).

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 [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.)) 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 Section 7.1.3.1 ().

The schema uses the "connection-id" and "conf-id" attributes which are imported from the schema defined in the core Control Framework [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.).

5.3.  Common XML Support

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 [I‑D.ietf‑mediactrl‑sip‑control‑framework] (Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework,” October 2009.) MUST be supported for media dialogs and conferences.

5.4.  CONTROL Message Body

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> (Section 7.1.2.1 ()), <unmoderateconference> (Section 7.1.2.2 ()), <addfloor> (Section 7.1.2.3 ()), <modifyfloor> (Section 7.1.2.4 ()), <removefloor> (Section 7.1.2.5 ()), <addparticipant> (Section 7.1.2.6 ()), <modifyparticipant> (Section 7.1.2.7 ()) and <removeparticipant> (Section 7.1.2.8 ()) elements.

The <audit> request element (Section 7.2.1 ()) 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 (Section 7.1.4.2 ()).

5.5.  REPORT Message Body

A valid REPORT body MUST conform to the schema defined in Section 9 (Formal Syntax) and described in Section 7 (Element Definitions). XML messages appearing in REPORT messages MUST contain a <response> (Section 7.1.3.1 ()), or a (notification) <event> element (Section 7.1.4.2 ()).

5.6.  Audit

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.

6.  Floors Manipulation

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:

                              MS
                      +---------------+
        UAC A         |               |         UAC B
          o-----------+--x         x--+-----------o
             a1b2c3   |               |   d4e5f6
                      |               |
                      |       x       |
                      |       |       |
                      +-------+-------+
                              |
                              |   g7h8i9
                              |
                              o
                             UAC C

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 [I‑D.ietf‑mediactrl‑mixer‑control‑package] (McGlashan, S., Melanchuk, T., and C. Boulton, “A Mixer Control Package for the Media Control Channel Framework,” February 2010.), 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 [RFC4583] (Camarillo, G., “Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams,” November 2006.). Figure 2 (Audio Conference with labels and floors) depicts such the case where all the participants have been attached to the mix.

                              MS
                      +---------------+
        UAC A         |               |         UAC B
          o-----------+--+~~>[ ]<~~+--+-----------o
             a1b2c3   |       ^       |   d4e5f6
           (floor 11) |       |       | (floor 11)
                      |       +       |
                      |       |       |
                      +-------+-------+
                              |
                              |   g7h8i9
                              | (floor 11)
                              o
                            UAC C

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 Section 7.1.1.1 ().

7.  Element Definitions

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

7.1. 

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 Section 7.1.2.1 () for details;

:

destroy a BFCP conference, thus stopping the moderation of the associated framework conference instance - see Section 7.1.2.2 () for details;

:

add and configure a new floor to an existing BFCP conference - see Section 7.1.2.3 () for details;

:

modify the configuration of a currently handled floor in an existing BFCP conference - see Section 7.1.2.4 () for details;

:

remove a currently handled floor from an existing BFCP conference - see Section 7.1.2.5 () for details;

:

add a floor participant to a BFCP conference - see Section 7.1.2.6 () for details;

:

modify an existing floor participant in a BFCP conference - see Section 7.1.2.7 () for details;

:

remove a floor participant from a BFCP conference - see Section 7.1.2.8 () for details.

:

response to a floor control request - see Section 7.1.3 (Responses) for details.

:

bfcp or subscription notification - see Section 7.1.4 (Notifications) for details.

7.1.1.  Shared elements

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 (Section 7.1.1.1 ()), while <addparticipant>, <modifyparticipant> and <removeparticipant> make use of the <participant> element (Section 7.1.1.2 ()).

7.1.1.1. 

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:

bfcp-floor-id:

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 [I‑D.ietf‑mediactrl‑mixer‑control‑package] (McGlashan, S., Melanchuk, T., and C. Boulton, “A Mixer Control Package for the Media Control Channel Framework,” February 2010.). 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...]

7.1.1.2. 

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

7.1.2.  Requests

7.1.2.1. 

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

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.

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 [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.). 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 (Section 7.1.1.1 ()) to configure a floor in the new BFCP conference (see Section 7.1.1.1 () 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 Section 7.1.2.3 ()). This element is optional.

:

an element to request subscription to conference events. (see Section 7.1.4.1 () 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 (Section 7.1.3 (Responses)).

7.1.2.2. 

<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 [I‑D.ietf‑mediactrl‑mixer‑control‑package] (McGlashan, S., Melanchuk, T., and C. Boulton, “A Mixer Control Package for the Media Control Channel Framework,” February 2010.).

The <unmoderateconference> element has the following attributes:

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.

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 (Section 7.1.3.1 ()).

7.1.2.3. 

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

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.

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 Section 7.1.1.1 () 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 (Section 7.1.3.1 ()).

7.1.2.4. 

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

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.

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.

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 Section 7.1.1.1 () 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 (Section 7.1.3.1 ()).

7.1.2.5. 

<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 [I‑D.ietf‑mediactrl‑mixer‑control‑package] (McGlashan, S., Melanchuk, T., and C. Boulton, “A Mixer Control Package for the Media Control Channel Framework,” February 2010.).

The <removefloor> element has the following attributes:

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.

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.

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 (Section 7.1.3.1 ()).

7.1.2.6. 

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

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.

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 [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.). 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 Section 7.1.1.2 () 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 (Section 7.1.3.1 ()).

[Note: is this really needed? there may be RFC4583 for that...]

7.1.2.7. 

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

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.

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.

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 Section 7.1.1.2 () 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 (Section 7.1.3.1 ()).

7.1.2.8. 

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

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.

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.

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 (Section 7.1.3.1 ()).

[Note: is this really needed? there may be RFC4583 for that...]

7.1.3.  Responses

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.

7.1.3.1. 

Reponses to requests are indicated by a <response> element.

The <response> element has the following attributes:

status:

numeric code indicating the response status. This attribute is mandatory.

reason:

string specifying a human readable description of the reason for the response status. This attribute is optional.

bfcp-conf-id:

string identifying the BFCP conference the request referred to. This attribute is optional.

bfcp-floor-id:

string identifying the BFCP floor the request referred to. This attribute is optional.

The following status codes are defined:

TBD. Add all error codes and their meanings

7.1.4.  Notifications

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.

7.1.4.1. 

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:

name:

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.

7.1.4.2. 

Delivery of events the AS subscribed for is accomplished by means of an <event> element.

The <event> element has the following attributes:

name:

string indicating the name of the BFCP event. This attribute is mandatory.

bfcp-conf-id:

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.

7.2.  Audit Elements

7.2.1. 

TBD.

7.2.2. 

TBD.

8.  Examples

TBD.

9.  Formal Syntax

TBD.

10.  Security Considerations

TBD.

11.  IANA Considerations

TBD.

12.  Change Summary

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;

13.  Acknowledgements

TBD.

14. References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.