[RFCs/IDs] [Plain Text] [From draft-ietf-xcon-bfcp]
PROPOSED STANDARD
Network Working Group G. Camarillo
Request for Comments: 4582 Ericsson
Category: Standards Track J. Ott
Helsinki University of Technology
K. Drage
Lucent Technologies
November 2006
The Binary Floor Control Protocol (BFCP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
Floor control is a means to manage joint or exclusive access to
shared resources in a (multiparty) conferencing environment.
Thereby, floor control complements other functions -- such as
conference and media session setup, conference policy manipulation,
and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP).
BFCP is used between floor participants and floor control servers,
and between floor chairs (i.e., moderators) and floor control
servers.
Table of Contents
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Scope ...........................................................5
3.1. Floor Creation .............................................7
3.2. Obtaining Information to Contact a Floor Control Server ....7
3.3. Obtaining Floor-Resource Associations ......................7
3.4. Privileges of Floor Control ................................8
4. Overview of Operation ...........................................8
4.1. Floor Participant to Floor Control Server Interface ........8
4.2. Floor Chair to Floor Control Server Interface .............13
Camarillo, et al. Standards Track [Page 1]
RFC 4582 BFCP November 2006
5. Packet Format ..................................................14
5.1. COMMON-HEADER Format ......................................15
5.2. Attribute Format ..........................................16
5.2.1. BENEFICIARY-ID .....................................18
5.2.2. FLOOR-ID ...........................................18
5.2.3. FLOOR-REQUEST-ID ...................................19
5.2.4. PRIORITY ...........................................19
5.2.5. REQUEST-STATUS .....................................20
5.2.6. ERROR-CODE .........................................21
5.2.6.1. Error-Specific Details for Error Code 4 ...22
5.2.7. ERROR-INFO .........................................22
5.2.8. PARTICIPANT-PROVIDED-INFO ..........................23
5.2.9. STATUS-INFO ........................................24
5.2.10. SUPPORTED-ATTRIBUTES ..............................24
5.2.11. SUPPORTED-PRIMITIVES ..............................25
5.2.12. USER-DISPLAY-NAME .................................26
5.2.13. USER-URI ..........................................26
5.2.14. BENEFICIARY-INFORMATION ...........................27
5.2.15. FLOOR-REQUEST-INFORMATION .........................27
5.2.16. REQUESTED-BY-INFORMATION ..........................28
5.2.17. FLOOR-REQUEST-STATUS .............................29
5.2.18. OVERALL-REQUEST-STATUS ...........................30
5.3. Message Format ............................................30
5.3.1. FloorRequest .......................................31
5.3.2. FloorRelease .......................................31
5.3.3. FloorRequestQuery ..................................31
5.3.4. FloorRequestStatus .................................31
5.3.5. UserQuery ..........................................32
5.3.6. UserStatus .........................................32
5.3.7. FloorQuery .........................................32
5.3.8. FloorStatus ........................................33
5.3.9. ChairAction ........................................33
5.3.10. ChairActionAck ....................................33
5.3.11. Hello .............................................33
5.3.12. HelloAck ..........................................34
5.3.13. Error .............................................34
6. Transport ......................................................34
7. Lower-Layer Security ...........................................35
8. Protocol Transactions ..........................................35
8.1. Client Behavior ...........................................36
8.2. Server Behavior ...........................................36
9. Authentication and Authorization ...............................36
9.1. TLS-Based Mutual Authentication ...........................37
10. Floor Participant Operations ..................................37
10.1. Requesting a Floor .......................................37
10.1.1. Sending a FloorRequest Message ....................38
10.1.2. Receiving a Response ..............................38
10.2. Cancelling a Floor Request and Releasing a Floor .........40
Camarillo, et al. Standards Track [Page 2]
RFC 4582 BFCP November 2006
10.2.1. Sending a FloorRelease Message ....................40
10.2.2. Receiving a Response ..............................40
11. Chair Operations ..............................................41
11.1. Sending a ChairAction Message ............................41
11.2. Receiving a Response .....................................42
12. General Client Operations .....................................43
12.1. Requesting Information about Floors ......................43
12.1.1. Sending a FloorQuery Message ......................43
12.1.2. Receiving a Response ..............................43
12.2. Requesting Information about Floor Requests ..............44
12.2.1. Sending a FloorRequestQuery Message ...............45
12.2.2. Receiving a Response ..............................45
12.3. Requesting Information about a User ......................45
12.3.1. Sending a UserQuery Message .......................46
12.3.2. Receiving a Response ..............................46
12.4. Obtaining the Capabilities of a Floor Control Server .....46
12.4.1. Sending a Hello Message ...........................47
12.4.2. Receiving Responses ...............................47
13. Floor Control Server Operations ...............................47
13.1. Reception of a FloorRequest Message ......................48
13.1.1. Generating the First FloorRequestStatus Message ...48
13.1.2. Generation of Subsequent
FloorRequestStatus Messages .......................50
13.2. Reception of a FloorRequestQuery Message .................51
13.3. Reception of a UserQuery Message .........................52
13.4. Reception of a FloorRelease Message ......................53
13.5. Reception of a FloorQuery Message ........................54
13.5.1. Generation of the First FloorStatus Message .......55
13.5.2. Generation of Subsequent FloorStatus Messages .....56
13.6. Reception of a ChairAction Message .......................56
13.7. Reception of a Hello Message .............................57
13.8. Error Message Generation .................................58
14. Security Considerations .......................................58
15. IANA Considerations ...........................................59
15.1. Attribute Subregistry ....................................59
15.2. Primitive Subregistry ....................................60
15.3. Request Status Subregistry ...............................61
15.4. Error Code Subregistry ...................................62
16. Acknowledgements ..............................................62
17. References ....................................................63
17.1. Normative References .....................................63
17.2. Informational References .................................63
Camarillo, et al. Standards Track [Page 3]
RFC 4582 BFCP November 2006
1. Introduction
Within a conference, some applications need to manage the access to a
set of shared resources, such as the right to send media to a
particular media session. Floor control enables such applications to
provide users with coordinated (shared or exclusive) access to these
resources.
The Requirements for Floor Control Protocol [9] list a set of
requirements that need to be met by floor control protocols. The
Binary Floor Control Protocol (BFCP), which is specified in this
document, meets these requirements.
In addition, BFCP has been designed so that it can be used in
low-bandwidth environments. The binary encoding used by BFCP
achieves a small message size (when message signatures are not used)
that keeps the time it takes to transmit delay-sensitive BFCP
messages to a minimum. Delay-sensitive BFCP messages include
FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It
is expected that future extensions to these messages will not
increase the size of these messages in a significant way.
The remainder of this document is organized as follows: Section 2
defines the terminology used throughout this document, Section 3
discusses the scope of BFCP (i.e., which tasks fall within the scope
of BFCP and which ones are performed using different mechanisms),
Section 4 provides a non-normative overview of BFCP operation, and
subsequent sections provide the normative specification of BFCP.
2. Terminology
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 [1] and indicate requirement levels for
compliant implementations.
Media Participant: An entity that has access to the media resources
of a conference (e.g., it can receive a media stream). In floor-
controlled conferences, a given media participant is typically
colocated with a floor participant, but it does not need to be.
Third-party floor requests consist of having a floor participant
request a floor for a media participant when they are not colocated.
The protocol between a floor participant and a media participant
(that are not colocated) is outside the scope of this document.
Client: A floor participant or a floor chair that communicates with a
floor control server using BFCP.
Camarillo, et al. Standards Track [Page 4]
RFC 4582 BFCP November 2006
Floor: A temporary permission to access or manipulate a specific
shared resource or set of resources.
Floor Chair: A logical entity that manages one floor (grants, denies,
or revokes a floor). An entity that assumes the logical role of a
floor chair for a given transaction may assume a different role
(e.g., floor participant) for a different transaction. The roles of
floor chair and floor participant are defined on a transaction-by-
transaction basis. BFCP transactions are defined in Section 8.
Floor Control: A mechanism that enables applications or users to gain
safe and mutually exclusive or non-exclusive input access to the
shared object or resource.
Floor Control Server: A logical entity that maintains the state of
the floor(s), including which floors exists, who the floor chairs
are, who holds a floor, etc. Requests to manipulate a floor are
directed at the floor control server. The floor control server of a
conference may perform other logical roles (e.g., floor participant)
in another conference.
Floor Participant: A logical entity that requests floors, and
possibly information about them, from a floor control server. An
entity that assumes the logical role of a floor participant for a
given transaction may assume a different role (e.g., a floor chair)
for a different transaction. The roles of floor participant and
floor chair are defined on a transaction-by-transaction basis. BFCP
transactions are defined in Section 8. In floor-controlled
conferences, a given floor participant is typically colocated with a
media participant, but it does not need to be. Third-party floor
requests consist of having a floor participant request a floor for a
media participant when they are not colocated.
Participant: An entity that acts as a floor participant, as a media
participant, or as both.
3. Scope
As stated earlier, BFCP is a protocol to coordinate access to shared
resources in a conference following the requirements defined in [9].
Floor control complements other functions defined in the XCON
conferencing framework [10]. The floor control protocol BFCP defined
in this document only specifies a means to arbitrate access to
floors. The rules and constraints for floor arbitration and the
results of floor assignments are outside the scope of this document
and are defined by other protocols [10].
Camarillo, et al. Standards Track [Page 5]
RFC 4582 BFCP November 2006
Figure 1 shows the tasks that BFCP can perform.
+---------+
| Floor |
| Chair |
| |
+---------+
^ |
| |
Notification | | Decision
| |
| |
Floor | v
+-------------+ Request +---------+ +-------------+
| Floor |----------->| Floor | Notification | Floor |
| Participant | | Control |------------->| Participant |
| |<-----------| Server | | |
+-------------+ Granted or +---------+ +-------------+
Denied
Figure 1: Functionality provided by BFCP
BFCP provides a means:
o for floor participants to send floor requests to floor control
servers.
o for floor control servers to grant or deny requests to access a
given resource from floor participants.
o for floor chairs to send floor control servers decisions regarding
floor requests.
o for floor control servers to keep floor participants and floor
chairs informed about the status of a given floor or a given floor
request.
Even though tasks that do not belong to the previous list are outside
the scope of BFCP, some of these out-of-scope tasks relate to floor
control and are essential for creating floors and establishing BFCP
connections between different entities. In the following
subsections, we discuss some of these tasks and mechanisms to perform
them.
Camarillo, et al. Standards Track [Page 6]
RFC 4582 BFCP November 2006
3.1. Floor Creation
The association of a given floor with a resource or a set of
resources (e.g., media streams) is out of the scope of BFCP as
described in [10]. Floor creation and termination are also outside
the scope of BFCP; these aspects are handled using the conference
control protocol for manipulating the conference object.
Consequently, the floor control server needs to stay up to date on
changes to the conference object (e.g., when a new floor is created).
3.2. Obtaining Information to Contact a Floor Control Server
A client needs a set of data in order to establish a BFCP connection
to a floor control server. These data include the transport address
of the server, the conference identifier, and a user identifier.
Clients can obtain this information in different ways. One is to use
an SDP offer/answer [8] exchange, which is described in [7]. Other
mechanisms are described in the XCON framework [10] (and other
related documents).
3.3. Obtaining Floor-Resource Associations
Floors are associated with resources. For example, a floor that
controls who talks at a given time has a particular audio session as
its associated resource. Associations between floors and resources
are part of the conference object.
Floor participants and floor chairs need to know which resources are
associated with which floors. They can obtain this information by
using different mechanisms, such as an SDP offer/answer [8] exchange.
How to use an SDP offer/answer exchange to obtain these associations
is described in [7].
Note that floor participants perform SDP offer/answer exchanges
with the conference focus of the conference. So, the conference
focus needs to obtain information about associations between
floors and resources in order to be able to provide this
information to a floor participant in an SDP offer/answer
exchange.
Other mechanisms for obtaining this information, including discussion
of how the information is made available to a (SIP) Focus, are
described in the XCON framework [10] (and other related documents).
Camarillo, et al. Standards Track [Page 7]
RFC 4582 BFCP November 2006
3.4. Privileges of Floor Control
A participant whose floor request is granted has the right to use (in
a certain way) the resource or resources associated with the floor
that was requested. For example, the participant may have the right
to send media over a particular audio stream.
Nevertheless, holding a floor does not imply that others will not be
able to use its associated resources at the same time, even if they
do not have the right to do so. Determination of which media
participants can actually use the resources in the conference is
discussed in the XCON Framework [10].
4. Overview of Operation
This section provides a non-normative description of BFCP operations.
Section 4.1 describes the interface between floor participants and
floor control servers, and Section 4.2 describes the interface
between floor chairs and floor control servers.
BFCP messages, which use a TLV (Type-Length-Value) binary encoding,
consist of a common header followed by a set of attributes. The
common header contains, among other information, a 32-bit conference
identifier. Floor participants, media participants, and floor chairs
are identified by 16-bit user identifiers.
BFCP supports nested attributes (i.e., attributes that contain
attributes). These are referred to as grouped attributes.
There are two types of transactions in BFCP: client-initiated
transactions and server-initiated transactions. Client-initiated
transactions consist of a message from a client to the floor control
server and a response from the floor control server to the client.
Both messages can be related because they carry the same Transaction
ID value in their common headers. Server-initiated transactions
consist of a single message, whose Transaction ID is 0, from the
floor control server to a client.
4.1. Floor Participant to Floor Control Server Interface
Floor participants request a floor by sending a FloorRequest message
to the floor control server. BFCP supports third-party floor
requests. That is, the floor participant sending the floor request
need not be colocated with the media participant that will get the
floor once the floor request is granted. FloorRequest messages carry
the identity of the requester in the User ID field of the common
header, and the identity of the beneficiary of the floor (in third-
party floor requests) in a BENEFICIARY-ID attribute.
Camarillo, et al. Standards Track [Page 8]
RFC 4582 BFCP November 2006
Third-party floor requests can be sent, for example, by floor
participants that have a BFCP connection to the floor control
server but that are not media participants (i.e., they do not
handle any media).
FloorRequest messages identify the floor or floors being requested by
carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a
FloorRequest message carries more than one floor identifier, the
floor control server treats all the floor requests as an atomic
package. That is, the floor control server either grants or denies
all the floors in the FloorRequest message.
Floor control servers respond to FloorRequest messages with
FloorRequestStatus messages, which provide information about the
status of the floor request. The first FloorRequestStatus message is
the response to the FloorRequest message from the client, and
therefore has the same Transaction ID as the FloorRequest.
Additionally, the first FloorRequestStatus message carries the Floor
Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent
FloorRequestStatus messages related to the same floor request will
carry the same Floor Request ID. This way, the floor participant can
associate them with the appropriate floor request.
Messages from the floor participant related to a particular floor
request also use the same Floor Request ID as the first
FloorRequestStatus Message from the floor control server.
Figure 2 shows how a floor participant requests a floor, obtains it,
and, at a later time, releases it. This figure illustrates the use,
among other things, of the Transaction ID and the FLOOR-REQUEST-ID
attribute.
Camarillo, et al. Standards Track [Page 9]
RFC 4582 BFCP November 2006
Floor Participant Floor Control
Server
|(1) FloorRequest |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorRequestStatus |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Pending |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(3) FloorRequestStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(4) FloorRequestStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(5) FloorRelease |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->|
Camarillo, et al. Standards Track [Page 10]
RFC 4582 BFCP November 2006
| |
|(6) FloorRequestStatus |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Released |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
Figure 2: Requesting and releasing a floor
Figure 3 shows how a floor participant requests to be informed on the
status of a floor. The first FloorStatus message from the floor
control server is the response to the FloorQuery message and, as
such, has the same Transaction ID as the FloorQuery message.
Subsequent FloorStatus messages consist of server-initiated
transactions, and therefore their Transaction ID is 0. FloorStatus
message (2) indicates that there are currently two floor requests for
the floor whose Floor ID is 543. FloorStatus message (3) indicates
that the floor requests with Floor Request ID 764 has been granted,
and the floor request with Floor Request ID 635 is the first in the
queue. FloorStatus message (4) indicates that the floor request with
Floor Request ID 635 has been granted.
Floor Participant Floor Control
Server
|(1) FloorQuery |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
Camarillo, et al. Standards Track [Page 11]
RFC 4582 BFCP November 2006
| |
|(2) FloorStatus |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 2nd |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(3) FloorStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
Camarillo, et al. Standards Track [Page 12]
RFC 4582 BFCP November 2006
| |
|(4) FloorStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
Figure 3: Obtaining status information about a floor
FloorStatus messages contain information about the floor requests
they carry. For example, FloorStatus message (4) indicates that the
floor request with Floor Request ID 635 has as the beneficiary (i.e.,
the participant that holds the floor when a particular floor request
is granted) the participant whose User ID is 154. The floor request
applies only to the floor whose Floor ID is 543. That is, this is
not a multi-floor floor request.
A multi-floor floor request applies to more than one floor (e.g.,
a participant wants to be able to speak and write on the
whiteboard at the same time). The floor control server treats a
multi-floor floor request as an atomic package. That is, the
floor control server either grants the request for all floors or
denies the request for all floors.
4.2. Floor Chair to Floor Control Server Interface
Figure 4 shows a floor chair instructing a floor control server to
grant a floor.
Note, however, that although the floor control server needs to
take into consideration the instructions received in ChairAction
messages (e.g., granting a floor), it does not necessarily need to
perform them exactly as requested by the floor chair. The
operation that the floor control server performs depends on the
ChairAction message and on the internal state of the floor control
server.
Camarillo, et al. Standards Track [Page 13]
RFC 4582 BFCP November 2006
For example, a floor chair may send a ChairAction message granting a
floor that was requested as part of an atomic floor request operation
that involved several floors. Even if the chair responsible for one
of the floors instructs the floor control server to grant the floor,
the floor control server will not grant it until the chairs
responsible for the other floors agree to grant them as well. In
another example, a floor chair may instruct the floor control server
to grant a floor to a participant. The floor control server needs to
revoke the floor from its current holder before granting it to the
new participant.
So, the floor control server is ultimately responsible for keeping a
coherent floor state using instructions from floor chairs as input to
this state.
Floor Chair Floor Control
Server
|(1) ChairAction |
|Transaction ID: 769 |
|User ID: 357 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| Request Status: Granted |
|---------------------------------------------->|
| |
|(2) ChairActionAck |
|Transaction ID: 769 |
|User ID: 357 |
|<----------------------------------------------|
Figure 4: Chair instructing the floor control server
5. Packet Format
BFCP packets consist of a 12-octet common header followed by
attributes. All the protocol values MUST be sent in network byte
order.
Camarillo, et al. Standards Track [Page 14]
RFC 4582 BFCP November 2006
5.1. COMMON-HEADER Format
The following is the format of the common header.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |Reserved | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: COMMON-HEADER format
Ver: The 3-bit version field MUST be set to 1 to indicate this
version of BFCP.
Reserved: At this point, the 5 bits in the reserved field SHOULD be
set to zero by the sender of the message and MUST be ignored by the
receiver.
Primitive: This 8-bit field identifies the main purpose of the
message. The following primitive values are defined:
+-------+--------------------+------------------+
| Value | Primitive | Direction |
+-------+--------------------+------------------+
| 1 | FloorRequest | P -> S |
| 2 | FloorRelease | P -> S |
| 3 | FloorRequestQuery | P -> S ; Ch -> S |
| 4 | FloorRequestStatus | P <- S ; Ch <- S |
| 5 | UserQuery | P -> S ; Ch -> S |
| 6 | UserStatus | P <- S ; Ch <- S |
| 7 | FloorQuery | P -> S ; Ch -> S |
| 8 | FloorStatus | P <- S ; Ch <- S |
| 9 | ChairAction | Ch -> S |
| 10 | ChairActionAck | Ch <- S |
| 11 | Hello | P -> S ; Ch -> S |
| 12 | HelloAck | P <- S ; Ch <- S |
| 13 | Error | P <- S ; Ch <- S |
+-------+--------------------+------------------+
S: Floor Control Server
P: Floor Participant
Ch: Floor Chair
Table 1: BFCP primitives
Camarillo, et al. Standards Track [Page 15]
RFC 4582 BFCP November 2006
Payload Length: This 16-bit field contains the length of the message
in 4-octet units, excluding the common header.
Conference ID: This 32-bit field identifies the conference the
message belongs to.
Transaction ID: This field contains a 16-bit value that allows users
to match a given message with its response. The value of the
Transaction ID in server-initiated transactions is 0 (see Section 8).
User ID: This field contains a 16-bit value that uniquely identifies
a participant within a conference.
The identity used by a participant in BFCP, which is carried in
the User ID field, is generally mapped to the identity used by the
same participant in the session establishment protocol (e.g., in
SIP). The way this mapping is performed is outside the scope of
this specification.
5.2. Attribute Format
BFCP attributes are encoded in TLV (Type-Length-Value) format.
Attributes are 32-bit aligned.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Attribute Contents /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Attribute format
Type: This 7-bit field contains the type of the attribute. Each
attribute, identified by its type, has a particular format. The
attribute formats defined are:
Unsigned16: The contents of the attribute consist of a 16-bit
unsigned integer.
OctetString16: The contents of the attribute consist of 16 bits of
arbitrary data.
Camarillo, et al. Standards Track [Page 16]
RFC 4582 BFCP November 2006
OctetString: The contents of the attribute consist of arbitrary
data of variable length.
Grouped: The contents of the attribute consist of a sequence of
attributes.
Note that extension attributes defined in the future may define
new attribute formats.
The following attribute types are defined:
+------+---------------------------+---------------+
| Type | Attribute | Format |
+------+---------------------------+---------------+
| 1 | BENEFICIARY-ID | Unsigned16 |
| 2 | FLOOR-ID | Unsigned16 |
| 3 | FLOOR-REQUEST-ID | Unsigned16 |
| 4 | PRIORITY | OctetString16 |
| 5 | REQUEST-STATUS | OctetString16 |
| 6 | ERROR-CODE | OctetString |
| 7 | ERROR-INFO | OctetString |
| 8 | PARTICIPANT-PROVIDED-INFO | OctetString |
| 9 | STATUS-INFO | OctetString |
| 10 | SUPPORTED-ATTRIBUTES | OctetString |
| 11 | SUPPORTED-PRIMITIVES | OctetString |
| 12 | USER-DISPLAY-NAME | OctetString |
| 13 | USER-URI | OctetString |
| 14 | BENEFICIARY-INFORMATION | Grouped |
| 15 | FLOOR-REQUEST-INFORMATION | Grouped |
| 16 | REQUESTED-BY-INFORMATION | Grouped |
| 17 | FLOOR-REQUEST-STATUS | Grouped |
| 18 | OVERALL-REQUEST-STATUS | Grouped |
+------+---------------------------+---------------+
Table 2: BFCP attributes
M: The 'M' bit, known as the Mandatory bit, indicates whether support
of the attribute is required. If an unrecognized attribute with the
'M' bit set is received, the message is rejected. The 'M' bit is
significant for extension attributes defined in other documents only.
All attributes specified in this document MUST be understood by the
receiver so that the setting of the 'M' bit is irrelevant for these.
In all other cases, the unrecognised attribute is ignored but the
message is processed.
Length: This 8-bit field contains the length of the attribute in
octets, excluding any padding defined for specific attributes. The
length of attributes that are not grouped includes the Type, 'M' bit,
Camarillo, et al. Standards Track [Page 17]
RFC 4582 BFCP November 2006
and Length fields. The Length in grouped attributes is the length of
the grouped attribute itself (including Type, 'M' bit, and Length
fields) plus the total length (including padding) of all the included
attributes.
Attribute Contents: The contents of the different attributes are
defined in the following sections.
5.2.1. BENEFICIARY-ID
The following is the format of the BENEFICIARY-ID attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: BENEFICIARY-ID format
Beneficiary ID: This field contains a 16-bit value that uniquely
identifies a user within a conference.
Note that although the formats of the Beneficiary ID and of the
User ID field in the common header are similar, their semantics
are different. The Beneficiary ID is used in third-party floor
requests and to request information about a particular
participant.
5.2.2. FLOOR-ID
The following is the format of the FLOOR-ID attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FLOOR-ID format
Floor ID: This field contains a 16-bit value that uniquely identifies
a floor within a conference.
Camarillo, et al. Standards Track [Page 18]
RFC 4582 BFCP November 2006
5.2.3. FLOOR-REQUEST-ID
The following is the format of the FLOOR-REQUEST-ID attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: FLOOR-REQUEST-ID format
Floor Request ID: This field contains a 16-bit value that identifies
a floor request at the floor control server.
5.2.4. PRIORITY
The following is the format of the PRIORITY attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: PRIORITY format
Prio: This field contains a 3-bit priority value, as shown in
Table 3. Senders SHOULD NOT use values higher than 4 in this field.
Receivers MUST treat values higher than 4 as if the value received
were 4 (Highest). The default priority value when the PRIORITY
attribute is missing is 2 (Normal).
+-------+----------+
| Value | Priority |
+-------+----------+
| 0 | Lowest |
| 1 | Low |
| 2 | Normal |
| 3 | High |
| 4 | Highest |
+-------+----------+
Table 3: Priority values
Reserved: At this point, the 13 bits in the reserved field SHOULD be
set to zero by the sender of the message and MUST be ignored by the
receiver.
Camarillo, et al. Standards Track [Page 19]
RFC 4582 BFCP November 2006
5.2.5. REQUEST-STATUS
The following is the format of the REQUEST-STATUS attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: REQUEST-STATUS format
Request Status: This 8-bit field contains the status of the request,
as described in the following table.
+-------+-----------+
| Value | Status |
+-------+-----------+
| 1 | Pending |
| 2 | Accepted |
| 3 | Granted |
| 4 | Denied |
| 5 | Cancelled |
| 6 | Released |
| 7 | Revoked |
+-------+-----------+
Table 4: Request Status values
Queue Position: This 8-bit field contains, when applicable, the
position of the floor request in the floor request queue at the
server. If the Request Status value is different from Accepted, if
the floor control server does not implement a floor request queue, or
if the floor control server does not want to provide the client with
this information, all the bits of this field SHOULD be set to zero.
A floor request is in Pending state if the floor control server needs
to contact a floor chair in order to accept the floor request, but
has not done it yet. Once the floor control chair accepts the floor
request, the floor request is moved to the Accepted state.
Camarillo, et al. Standards Track [Page 20]
RFC 4582 BFCP November 2006
5.2.6. ERROR-CODE
The following is the format of the ERROR-CODE attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0|M| Length | Error Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Error Specific Details |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: ERROR-CODE format
Error Code: This 8-bit field contains an error code from the
following table. If an error code is not recognised by the receiver,
then the receiver MUST assume that an error exists, and therefore
that the message is processed, but the nature of the error is
unclear.
+-------+-----------------------------------------------------------+
| Value | Meaning |
+-------+-----------------------------------------------------------+
| 1 | Conference does not Exist |
| 2 | User does not Exist |
| 3 | Unknown Primitive |
| 4 | Unknown Mandatory Attribute |
| 5 | Unauthorized Operation |
| 6 | Invalid Floor ID |
| 7 | Floor Request ID Does Not Exist |
| 8 | You have Already Reached the Maximum Number of Ongoing |
| | Floor Requests for this Floor |
| 9 | Use TLS |
+-------+-----------------------------------------------------------+
Table 5: Error Code meaning
Error Specific Details: Present only for certain Error Codes. In
this document, only for Error Code 4 (Unknown Mandatory Attribute).
See Section 5.2.6.1 for its definition.
Padding: One, two, or three octets of padding added so that the
contents of the ERROR-CODE attribute is 32-bit aligned. If the
attribute is already 32-bit aligned, no padding is needed.
Camarillo, et al. Standards Track [Page 21]
RFC 4582 BFCP November 2006
The Padding bits SHOULD be set to zero by the sender and MUST be
ignored by the receiver.
5.2.6.1. Error-Specific Details for Error Code 4
The following is the format of the Error-Specific Details field for
Error Code 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Unknown attributes format
Unknown Type: These 7-bit fields contain the Types of the attributes
(which were present in the message that triggered the Error message)
that were unknown to the receiver.
R: At this point, this bit is reserved. It SHOULD be set to zero by
the sender of the message and MUST be ignored by the receiver.
5.2.7. ERROR-INFO
The following is the format of the ERROR-INFO attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: ERROR-INFO format
Text: This field contains UTF-8 [6] encoded text.
Camarillo, et al. Standards Track [Page 22]
RFC 4582 BFCP November 2006
In some situations, the contents of the Text field may be generated
by an automaton. If this automaton has information about the
preferred language of the receiver of a particular ERROR-INFO
attribute, it MAY use this language to generate the Text field.
Padding: One, two, or three octets of padding added so that the
contents of the ERROR-INFO attribute is 32-bit aligned. The Padding
bits SHOULD be set to zero by the sender and MUST be ignored by the
receiver. If the attribute is already 32-bit aligned, no padding is
needed.
5.2.8. PARTICIPANT-PROVIDED-INFO
The following is the format of the PARTICIPANT-PROVIDED-INFO
attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: PARTICIPANT-PROVIDED-INFO format
Text: This field contains UTF-8 [6] encoded text.
Padding: One, two, or three octets of padding added so that the
contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit
aligned. The Padding bits SHOULD be set to zero by the sender and
MUST be ignored by the receiver. If the attribute is already 32-bit
aligned, no padding is needed.
Camarillo, et al. Standards Track [Page 23]
RFC 4582 BFCP November 2006
5.2.9. STATUS-INFO
The following is the format of the STATUS-INFO attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: STATUS-INFO format
Text: This field contains UTF-8 [6] encoded text.
In some situations, the contents of the Text field may be generated
by an automaton. If this automaton has information about the
preferred language of the receiver of a particular STATUS-INFO
attribute, it MAY use this language to generate the Text field.
Padding: One, two, or three octets of padding added so that the
contents of the STATUS-INFO attribute is 32-bit aligned. The Padding
bits SHOULD be set to zero by the sender and MUST be ignored by the
receiver. If the attribute is already 32-bit aligned, no padding is
needed.
5.2.10. SUPPORTED-ATTRIBUTES
The following is the format of the SUPPORTED-ATTRIBUTES attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: SUPPORTED-ATTRIBUTES format
Camarillo, et al. Standards Track [Page 24]
RFC 4582 BFCP November 2006
Supp. Attr.: These fields contain the Types of the attributes that
are supported by the floor control server in the following format:
R: Reserved: This bit MUST be set to zero upon transmission and MUST
be ignored upon reception.
Padding: Two octets of padding added so that the contents of the
SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute
is already 32-bit aligned, no padding is needed.
The Padding bits SHOULD be set to zero by the sender and MUST be
ignored by the receiver.
5.2.11. SUPPORTED-PRIMITIVES
The following is the format of the SUPPORTED-PRIMITIVES attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 1|M| Length | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primitive | Primitive | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SUPPORTED-PRIMITIVES format
Primitive: These fields contain the types of the BFCP messages that
are supported by the floor control server. See Table 1 for the list
of BFCP primitives.
Padding: One, two, or three octets of padding added so that the
contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If
the attribute is already 32-bit aligned, no padding is needed.
The Padding bits SHOULD be set to zero by the sender and MUST be
ignored by the receiver.
Camarillo, et al. Standards Track [Page 25]
RFC 4582 BFCP November 2006
5.2.12. USER-DISPLAY-NAME
The following is the format of the USER-DISPLAY-NAME attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: USER-DISPLAY-NAME format
Text: This field contains the UTF-8 encoded name of the user.
Padding: One, two, or three octets of padding added so that the
contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The
Padding bits SHOULD be set to zero by the sender and MUST be ignored
by the receiver. If the attribute is already 32-bit aligned, no
padding is needed.
5.2.13. USER-URI
The following is the format of the USER-URI attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: USER-URI format
Text: This field contains the UTF-8 encoded user's contact URI, that
is, the URI used by the user to set up the resources (e.g., media
streams) that are controlled by BFCP. For example, in the context of
a conference set up by SIP, the USER-URI attribute would carry the
SIP URI of the user.
Camarillo, et al. Standards Track [Page 26]
RFC 4582 BFCP November 2006
Messages containing a user's URI in a USER-URI attribute also
contain the user's User ID. This way, a client receiving such a
message can correlate the user's URI (e.g., the SIP URI the user
used to join a conference) with the user's User ID.
Padding: One, two, or three octets of padding added so that the
contents of the USER-URI attribute is 32-bit aligned. The Padding
bits SHOULD be set to zero by the sender and MUST be ignored by the
receiver. If the attribute is already 32-bit aligned, no padding is
needed.
5.2.14. BENEFICIARY-INFORMATION
The BENEFICIARY-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as BENEFICIARY-
INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the BENEFICIARY-INFORMATION-HEADER:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 0|M| Length | Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: BENEFICIARY-INFORMATION-HEADER format
Beneficiary ID: This field contains a 16-bit value that uniquely
identifies a user within a conference.
The following is the ABNF (Augmented Backus-Naur Form) [2] of the
BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE
refers to extension attributes that may be defined in the future.)
BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER)
[USER-DISPLAY-NAME]
[USER-URI]
*[EXTENSION-ATTRIBUTE]
Figure 22: BENEFICIARY-INFORMATION format
5.2.15. FLOOR-REQUEST-INFORMATION
The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as FLOOR-REQUEST-
INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the FLOOR-REQUEST-INFORMATION-HEADER:
Camarillo, et al. Standards Track [Page 27]
RFC 4582 BFCP November 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 1|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format
Floor Request ID: This field contains a 16-bit value that identifies
a floor request at the floor control server.
The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.)
FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER)
[OVERALL-REQUEST-STATUS]
1*(FLOOR-REQUEST-STATUS)
[BENEFICIARY-INFORMATION]
[REQUESTED-BY-INFORMATION]
[PRIORITY]
[PARTICIPANT-PROVIDED-INFO]
*[EXTENSION-ATTRIBUTE]
Figure 24: FLOOR-REQUEST-INFORMATION format
5.2.16. REQUESTED-BY-INFORMATION
The REQUESTED-BY-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as REQUESTED-BY-
INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the REQUESTED-BY-INFORMATION-HEADER:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 0|M| Length | Requested-by ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: REQUESTED-BY-INFORMATION-HEADER format
Requested-by ID: This field contains a 16-bit value that uniquely
identifies a user within a conference.
The following is the ABNF of the REQUESTED-BY-INFORMATION grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.)
Camarillo, et al. Standards Track [Page 28]
RFC 4582 BFCP November 2006
REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER)
[USER-DISPLAY-NAME]
[USER-URI]
*[EXTENSION-ATTRIBUTE]
Figure 26: REQUESTED-BY-INFORMATION format
5.2.17. FLOOR-REQUEST-STATUS
The FLOOR-REQUEST-STATUS attribute is a grouped attribute that
consists of a header, which is referred to as
FLOOR-REQUEST-STATUS-HEADER, followed by a sequence of attributes.
The following is the format of the FLOOR-REQUEST-STATUS-HEADER:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 1|M| Length | Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: FLOOR-REQUEST-STATUS-HEADER format
Floor ID: this field contains a 16-bit value that uniquely identifies
a floor within a conference.
The following is the ABNF of the FLOOR-REQUEST-STATUS grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.)
FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER)
[REQUEST-STATUS]
[STATUS-INFO]
*[EXTENSION-ATTRIBUTE]
Figure 28: FLOOR-REQUEST-STATUS format
Camarillo, et al. Standards Track [Page 29]
RFC 4582 BFCP November 2006
5.2.18. OVERALL-REQUEST-STATUS
The OVERALL-REQUEST-STATUS attribute is a grouped attribute that
consists of a header, which is referred to as
OVERALL-REQUEST-STATUS-HEADER, followed by a sequence of attributes.
The following is the format of the OVERALL-REQUEST-STATUS-HEADER:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 1 0|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: OVERALL-REQUEST-STATUS-HEADER format
Floor Request ID: this field contains a 16-bit value that identifies
a floor request at the floor control server.
The following is the ABNF of the OVERALL-REQUEST-STATUS grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.)
OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER)
[REQUEST-STATUS]
[STATUS-INFO]
*[EXTENSION-ATTRIBUTE]
Figure 30: OVERALL-REQUEST-STATUS format
5.3. Message Format
This section contains the normative ABNF (Augmented Backus-Naur Form)
[2] of the BFCP messages. Extension attributes that may be defined
in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.
Camarillo, et al. Standards Track [Page 30]
RFC 4582 BFCP November 2006
5.3.1. FloorRequest
Floor participants request a floor by sending a FloorRequest message
to the floor control server. The following is the format of the
FloorRequest message:
FloorRequest = (COMMON-HEADER)
1*(FLOOR-ID)
[BENEFICIARY-ID]
[PARTICIPANT-PROVIDED-INFO]
[PRIORITY]
*[EXTENSION-ATTRIBUTE]
Figure 31: FloorRequest format
5.3.2. FloorRelease
Floor participants release a floor by sending a FloorRelease message
to the floor control server. Floor participants also use the
FloorRelease message to cancel pending floor requests. The following
is the format of the FloorRelease message:
FloorRelease = (COMMON-HEADER)
(FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE]
Figure 32: FloorRelease format
5.3.3. FloorRequestQuery
Floor participants and floor chairs request information about a floor
request by sending a FloorRequestQuery message to the floor control
server. The following is the format of the FloorRequestQuery
message:
FloorRequestQuery = (COMMON-HEADER)
(FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE]
Figure 33: FloorRequestQuery format
5.3.4. FloorRequestStatus
The floor control server informs floor participants and floor chairs
about the status of their floor requests by sending them
FloorRequestStatus messages. The following is the format of the
FloorRequestStatus message:
Camarillo, et al. Standards Track [Page 31]
RFC 4582 BFCP November 2006
FloorRequestStatus = (COMMON-HEADER)
(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE]
Figure 34: FloorRequestStatus format
5.3.5. UserQuery
Floor participants and floor chairs request information about a
participant and the floor requests related to this participant by
sending a UserQuery message to the floor control server. The
following is the format of the UserQuery message:
UserQuery = (COMMON-HEADER)
[BENEFICIARY-ID]
*[EXTENSION-ATTRIBUTE]
Figure 35: UserQuery format
5.3.6. UserStatus
The floor control server provides information about participants and
their related floor requests to floor participants and floor chairs
by sending them UserStatus messages. The following is the format of
the UserStatus message:
UserStatus = (COMMON-HEADER)
[BENEFICIARY-INFORMATION]
*(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE]
Figure 36: UserStatus format
5.3.7. FloorQuery
Floor participants and floor chairs request information about a floor
or floors by sending a FloorQuery message to the floor control
server. The following is the format of the FloorRequest message:
FloorQuery = (COMMON-HEADER)
*(FLOOR-ID)
*[EXTENSION-ATTRIBUTE]
Figure 37: FloorQuery format
Camarillo, et al. Standards Track [Page 32]
RFC 4582 BFCP November 2006
5.3.8. FloorStatus
The floor control server informs floor participants and floor chairs
about the status (e.g., the current holder) of a floor by sending
them FloorStatus messages. The following is the format of the
FloorStatus message:
FloorStatus = (COMMON-HEADER)
*1(FLOOR-ID)
*[FLOOR-REQUEST-INFORMATION]
*[EXTENSION-ATTRIBUTE]
Figure 38: FloorStatus format
5.3.9. ChairAction
Floor chairs send instructions to floor control servers by sending
ChairAction messages. The following is the format of the ChairAction
message:
ChairAction = (COMMON-HEADER)
(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE]
Figure 39: ChairAction format
5.3.10. ChairActionAck
Floor control servers confirm that they have accepted a ChairAction
message by sending a ChairActionAck message. The following is the
format of the ChairActionAck message:
ChairActionAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
Figure 40: ChairActionAck format
5.3.11. Hello
Floor participants and floor chairs check the liveliness of floor
control servers by sending a Hello message. The following is the
format of the Hello message:
Hello = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
Figure 41: Hello format
Camarillo, et al. Standards Track [Page 33]
RFC 4582 BFCP November 2006
5.3.12. HelloAck
Floor control servers confirm that they are alive on reception of a
Hello message by sending a HelloAck message. The following is the
format of the HelloAck message:
HelloAck = (COMMON-HEADER)
(SUPPORTED-PRIMITIVES)
(SUPPORTED-ATTRIBUTES)
*[EXTENSION-ATTRIBUTE]
Figure 42: HelloAck format
5.3.13. Error
Floor control servers inform floor participants and floor chairs
about errors processing requests by sending them Error messages. The
following is the format of the Error message:
Error = (COMMON-HEADER)
(ERROR-CODE)
[ERROR-INFO]
*[EXTENSION-ATTRIBUTE]
Figure 43: Error format
6. Transport
BFCP entities exchange BFCP messages using TCP connections. TCP
provides an in-order reliable delivery of a stream of bytes.
Consequently, message framing is implemented in the application
layer. BFCP implements application-layer framing using TLV-encoded
attributes.
A client MUST NOT use more than one TCP connection to communicate
with a given floor control server within a conference. Nevertheless,
if the same physical box handles different clients (e.g., a floor
chair and a floor participant), which are identified by different
User IDs, a separate connection per client is allowed.
If a BFCP entity (a client or a floor control server) receives data
from TCP that cannot be parsed, the entity MUST close the TCP
connection, and the connection SHOULD be reestablished. Similarly,
if a TCP connection cannot deliver a BFCP message and times out, the
TCP connection SHOULD be reestablished.
Camarillo, et al. Standards Track [Page 34]
RFC 4582 BFCP November 2006
The way connection reestablishment is handled depends on how the
client obtains information to contact the floor control server (e.g.,
using an SDP offer/answer exchange [7]). Once the TCP connection is
reestablished, the client MAY resend those messages for which it did
not get a response from the floor control server.
If a floor control server detects that the TCP connection towards one
of the floor participants is lost, it is up to the local policy of
the floor control server what to do with the pending floor requests
of the floor participant. In any case, it is RECOMMENDED that the
floor control server keep the floor requests (i.e., that it does not
cancel them) while the TCP connection is reestablished.
If a client wishes to end its BFCP connection with a floor control
server, the client closes (i.e., a graceful close) the TCP connection
towards the floor control server. If a floor control server wishes
to end its BFCP connection with a client (e.g., the Focus of the
conference informs the floor control server that the client has been
kicked out from the conference), the floor control server closes
(i.e., a graceful close) the TCP connection towards the client.
7. Lower-Layer Security
BFCP relies on lower-layer security mechanisms to provide replay and
integrity protection and confidentiality. BFCP floor control servers
and clients (which include both floor participants and floor chairs)
MUST support TLS [3]. Any BFCP entity MAY support other security
mechanisms.
BFCP entities MUST support, at a minimum, the TLS
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [5].
Which party, the client or the floor control server, acts as the TLS
server depends on how the underlying TCP connection is established.
For example, when the TCP connection is established using an SDP
offer/answer exchange [7], the answerer (which may be the client or
the floor control server) always acts as the TLS server.
8. Protocol Transactions
In BFCP, there are two types of transactions: client-initiated
transactions and server-initiated transactions (notifications).
Client-initiated transactions consist of a request from a client to a
floor control server and a response from the floor control server to
the client. The request carries a Transaction ID in its common
header, which the floor control server copies into the response.
Clients use Transaction ID values to match responses with previously
issued requests.
Camarillo, et al. Standards Track [Page 35]
RFC 4582 BFCP November 2006
Server-initiated transactions consist of a single message from a
floor control server to a client. Since they do not trigger any
response, their Transaction ID is set to 0.
8.1. Client Behavior
A client starting a client-initiated transaction MUST set the
Conference ID in the common header of the message to the Conference
ID for the conference that the client obtained previously.
The client MUST set the Transaction ID value in the common header to
a number that is different from 0 and that MUST NOT be reused in
another message from the client until a response from the server is
received for the transaction. The client uses the Transaction ID
value to match this message with the response from the floor control
server.
8.2. Server Behavior
A floor control server sending a response within a client-initiated
transaction MUST copy the Conference ID, the Transaction ID, and the
User ID from the request received from the client into the response.
Server-initiated transactions MUST contain a Transaction ID equal to
0.
9. Authentication and Authorization
BFCP clients SHOULD authenticate the floor control server before
sending any BFCP message to it or accepting any BFCP message from it.
Similarly, floor control servers SHOULD authenticate a client before
accepting any BFCP message from it or sending any BFCP message to it.
BFCP supports TLS-based mutual authentication between clients and
floor control servers, as specified in Section 9.1. This is the
RECOMMENDED authentication mechanism in BFCP.
Note that future extensions may define additional authentication
mechanisms.
In addition to authenticating BFCP messages, floor control servers
need to authorize them. On receiving an authenticated BFCP message,
the floor control server checks whether the client sending the
message is authorized. If the client is not authorized to perform
the operation being requested, the floor control server generates an
Error message, as described in Section 13.8, with an Error code with
a value of 5 (Unauthorized Operation). Messages from a client that
cannot be authorized MUST NOT be processed further.
Camarillo, et al. Standards Track [Page 36]
RFC 4582 BFCP November 2006
9.1. TLS-Based Mutual Authentication
BFCP supports TLS-based mutual authentication between clients and
floor control servers. BFCP assumes that there is an integrity-
protected channel between the client and the floor control server
that can be used to exchange their self-signed certificates or, more
commonly, the fingerprints of these certificates. These certificates
are used at TLS establishment time.
The implementation of such an integrity-protected channel using
SIP and the SDP offer/answer model is described in [7].
BFCP messages received over an authenticated TLS connection are
considered authenticated. A floor control server that receives a
BFCP message over TCP (no TLS) can request the use of TLS by
generating an Error message, as described in Section 13.8, with an
Error code with a value of 9 (Use TLS). Clients SHOULD simply ignore
unauthenticated messages.
Note that future extensions may define additional authentication
mechanisms that may not require an initial integrity-protected
channel (e.g., authentication based on certificates signed by a
certificate authority).
As described in Section 9, floor control servers need to perform
authorization before processing any message. In particular, the
floor control server SHOULD check that messages arriving over a given
authenticated TLS connection use an authorized User ID (i.e., a User
ID that the user that established the authenticated TLS connection is
allowed to use).
10. Floor Participant Operations
This section specifies how floor participants can perform different
operations, such as requesting a floor, using the protocol elements
described in earlier sections. Section 11 specifies operations that
are specific to floor chairs, such as instructing the floor control
server to grant or revoke a floor, and Section 12 specifies
operations that can be performed by any client (i.e., both floor
participants and floor chairs).
10.1. Requesting a Floor
A floor participant that wishes to request one or more floors does so
by sending a FloorRequest message to the floor control server.
Camarillo, et al. Standards Track [Page 37]
RFC 4582 BFCP November 2006
10.1.1. Sending a FloorRequest Message
The ABNF in Section 5.3.1 describes the attributes that a
FloorRequest message can contain. In addition, the ABNF specifies
normatively which of these attributes are mandatory, and which ones
are optional.
The floor participant sets the Conference ID and the Transaction ID
in the common header following the rules given in Section 8.1.
The floor participant sets the User ID in the common header to the
floor participant's identifier. This User ID will be used by the
floor control server to authenticate and authorize the request. If
the sender of the FloorRequest message (identified by the User ID) is
not the participant that would eventually get the floor (i.e., a
third-party floor request), the sender SHOULD add a BENEFICIARY-ID
attribute to the message identifying the beneficiary of the floor.
Note that the name space for both the User ID and the Beneficiary
ID is the same. That is, a given participant is identified by a
single 16-bit value that can be used in the User ID in the common
header and in several attributes: BENEFICIARY-ID, BENEFICIARY-
INFORMATION, and REQUESTED-BY-INFORMATION.
The floor participant must insert at least one FLOOR-ID attribute in
the FloorRequest message. If the client inserts more than one
FLOOR-ID attribute, the floor control server will treat all the floor
requests as an atomic package. That is, the floor control server
will either grant or deny all the floors in the FloorRequest message.
The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute
to state the reason why the floor or floors are being requested. The
Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for
human consumption.
The floor participant may request that the server handle the floor
request with a certain priority using a PRIORITY attribute.
10.1.2. Receiving a Response
A message from the floor control server is considered a response to
the FloorRequest message if the message from the floor control server
has the same Conference ID, Transaction ID, and User ID as the
FloorRequest message, as described in Section 8.1. On receiving such
a response, the floor participant follows the rules in Section 9 that
relate to floor control server authentication.
Camarillo, et al. Standards Track [Page 38]
RFC 4582 BFCP November 2006
The successful processing of a FloorRequest message at the floor
control server involves generating one or several FloorRequestStatus
messages. The floor participant obtains a Floor Request ID in the
Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in
the first FloorRequestStatus message from the floor control server.
Subsequent FloorRequestStatus messages from the floor control server
regarding the same floor request will carry the same Floor Request ID
in a FLOOR-REQUEST-INFORMATION attribute as the initial
FloorRequestStatus message. This way, the floor participant can
associate subsequent incoming FloorRequestStatus messages with the
ongoing floor request.
The floor participant obtains information about the status of the
floor request in the FLOOR-REQUEST-INFORMATION attribute of each of
the FloorRequestStatus messages received from the floor control
server. This attribute is a grouped attribute, and as such it
includes a number of attributes that provide information about the
floor request.
The OVERALL-REQUEST-STATUS attribute provides information about the
overall status of the floor request. If the Request Status value is
Granted, all the floors that were requested in the FloorRequest
message have been granted. If the Request Status value is Denied,
all the floors that were requested in the FloorRequest message have
been denied. A floor request is considered to be ongoing while it is
in the Pending, Accepted, or Granted states. If the floor request
value is unknown, then the response is still processed. However, no
meaningful value can be reported to the user.
The STATUS-INFO attribute, if present, provides extra information
that the floor participant MAY display to the user.
The FLOOR-REQUEST-STATUS attributes provide information about the
status of the floor request as it relates to a particular floor. The
STATUS-INFO attribute, if present, provides extra information that
the floor participant MAY display to the user.
The BENEFICIARY-INFORMATION attribute identifies the beneficiary of
the floor request in third-party floor requests. The
REQUESTED-BY-INFORMATION attribute need not be present in
FloorRequestStatus messages received by the floor participant that
requested the floor, as this floor participant is already identified
by the User ID in the common header.
The PRIORITY attribute, when present, contains the priority that was
requested by the generator of the FloorRequest message.
Camarillo, et al. Standards Track [Page 39]
RFC 4582 BFCP November 2006
If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is
described in the Error message.
10.2. Cancelling a Floor Request and Releasing a Floor
A floor participant that wishes to cancel an ongoing floor request
does so by sending a FloorRelease message to the floor control
server. The FloorRelease message is also used by floor participants
that hold a floor and would like to release it.
10.2.1. Sending a FloorRelease Message
The ABNF in Section 5.3.2 describes the attributes that a
FloorRelease message can contain. In addition, the ABNF specifies
normatively which of these attributes are mandatory, and which ones
are optional.
The floor participant sets the Conference ID and the Transaction ID
in the common header following the rules given in Section 8.1. The
floor participant sets the User ID in the common header to the floor
participant's identifier. This User ID will be used by the floor
control server to authenticate and authorize the request.
Note that the FloorRelease message is used to release a floor or
floors that were granted and to cancel ongoing floor requests
(from the protocol perspective, both are ongoing floor requests).
Using the same message in both situations helps resolve the race
condition that occurs when the FloorRelease message and the
FloorGrant message cross each other on the wire.
The floor participant uses the FLOOR-REQUEST-ID that was received in
the response to the FloorRequest message that the FloorRelease
message is cancelling.
Note that if the floor participant requested several floors as an
atomic operation (i.e., in a single FloorRequest message), all the
floors are released as an atomic operation as well (i.e., all are
released at the same time).
10.2.2. Receiving a Response
A message from the floor control server is considered a response to
the FloorRelease message if the message from the floor control server
has the same Conference ID, Transaction ID, and User ID as the
FloorRequest message, as described in Section 8.1. On receiving such
a response, the floor participant follows the rules in Section 9 that
relate to floor control server authentication.
Camarillo, et al. Standards Track [Page 40]
RFC 4582 BFCP November 2006
If the response is a FloorRequestStatus message, the Request Status
value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-
REQUEST-INFORMATION grouped attribute) will be Cancelled or Released.
If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is
described in the Error message.
It is possible that the FloorRelease message crosses on the wire with
a FloorRequestStatus message from the server with a Request Status
different from Cancelled or Released. In any case, such a
FloorRequestStatus message will not be a response to the FloorRelease
message, as its Transaction ID will not match that of the
FloorRelease.
11. Chair Operations
This section specifies how floor chairs can instruct the floor
control server to grant or revoke a floor using the protocol elements
described in earlier sections.
Floor chairs that wish to send instructions to a floor control server
do so by sending a ChairAction message.
11.1. Sending a ChairAction Message
The ABNF in Section 5.3.9 describes the attributes that a ChairAction
message can contain. In addition, the ABNF specifies normatively
which of these attributes are mandatory, and which ones are optional.
The floor chair sets the Conference ID and the Transaction ID in the
common header following the rules given in Section 8.1. The floor
chair sets the User ID in the common header to the floor
participant's identifier. This User ID will be used by the floor
control server to authenticate and authorize the request.
The ChairAction message contains instructions that apply to one or
more floors within a particular floor request. The floor or floors
are identified by the FLOOR-REQUEST-STATUS attributes and the floor
request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which
are carried in the ChairAction message.
For example, if a floor request consists of two floors that depend on
different floor chairs, each floor chair will grant its floor within
the floor request. Once both chairs have granted their floor, the
floor control server will grant the floor request as a whole. On the
other hand, if one of the floor chairs denies its floor, the floor
Camarillo, et al. Standards Track [Page 41]
RFC 4582 BFCP November 2006
control server will deny the floor request as a whole, regardless of
the other floor chair's decision.
The floor chair provides the new status of the floor request as it
relates to a particular floor using a FLOOR-REQUEST-STATUS attribute.
If the new status of the floor request is Accepted, the floor chair
MAY use the Queue Position field to provide a queue position for the
floor request. If the floor chair does not wish to provide a queue
position, all the bits of the Queue Position field SHOULD be set to
zero. The floor chair SHOULD use the Status Revoked to revoke a
floor that was granted (i.e., Granted status) and SHOULD use the
Status Denied to reject floor requests in any other status (e.g.,
Pending and Accepted).
The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the
ChairAction message to provide a new overall status for the floor
request. If the new overall status of the floor request is Accepted,
the floor chair MAY use the Queue Position field to provide a queue
position for the floor request.
Note that a particular floor control server may implement a
different queue for each floor containing all the floor requests
that relate to that particular floor, a general queue for all
floor requests, or both. Also note that a floor request may
involve several floors and that a ChairAction message may only
deal with a subset of these floors (e.g., if a single floor chair
is not authorized to manage all the floors). In this case, the
floor control server will combine the instructions received from
the different floor chairs in FLOOR-REQUEST-STATUS attributes to
come up with the overall status of the floor request.
Note that, while the action of a floor chair may communicate
information in the OVERALL-REQUEST-STATUS attribute, the floor
control server may override, modify, or ignore this field's
content.
The floor chair may use STATUS-INFO attributes to state the reason
why the floor or floors are being accepted, granted, or revoked. The
Text in the STATUS-INFO attribute is intended for human consumption.
11.2. Receiving a Response
A message from the floor control server is considered a response to
the ChairAction message if the message from the server has the same
Conference ID, Transaction ID, and User ID as the ChairAction
message, as described in Section 8.1. On receiving such a response,
the floor chair follows the rules in Section 9 that relate to floor
control server authentication.
Camarillo, et al. Standards Track [Page 42]
RFC 4582 BFCP November 2006
A ChairActionAck message from the floor control server confirms that
the floor control server has accepted the ChairAction message. An
Error message indicates that the floor control server could not
process the ChairAction message for some reason, which is described
in the Error message.
12. General Client Operations
This section specifies operations that can be performed by any
client. That is, they are not specific to floor participants or
floor chairs. They can be performed by both.
12.1. Requesting Information about Floors
A client can obtain information about the status of a floor or floors
in different ways, which include using BFCP and using out-of-band
mechanisms. Clients using BFCP to obtain such information use the
procedures described in this section.
Clients request information about the status of one or several floors
by sending a FloorQuery message to the floor control server.
12.1.1. Sending a FloorQuery Message
The ABNF in Section 5.3.7 describes the attributes that a FloorQuery
message can contain. In addition, the ABNF specifies normatively
which of these attributes are mandatory, and which ones are optional.
The client sets the Conference ID and the Transaction ID in the
common header following the rules given in Section 8.1. The client
sets the User ID in the common header to the client's identifier.
This User ID will be used by the floor control server to authenticate
and authorize the request.
The client inserts in the message all the Floor IDs it wants to
receive information about. The floor control server will send
periodic information about all of these floors. If the client does
not want to receive information about a particular floor any longer,
it sends a new FloorQuery message removing the FLOOR-ID of this
floor. If the client does not want to receive information about any
floor any longer, it sends a FloorQuery message with no FLOOR-ID
attribute.
12.1.2. Receiving a Response
A message from the floor control server is considered a response to
the FloorQuery message if the message from the floor control server
has the same Conference ID, Transaction ID, and User ID as the
Camarillo, et al. Standards Track [Page 43]
RFC 4582 BFCP November 2006
FloorRequest message, as described in Section 8.1. On receiving such
a response, the client follows the rules in Section 9 that relate to
floor control server authentication.
On reception of the FloorQuery message, the floor control server will
respond with a FloorStatus message or with an Error message. If the
response is a FloorStatus message, it will contain information about
one of the floors the client requested information about. If the
client did not include any FLOOR-ID attribute in its FloorQuery
message (i.e., the client does not want to receive information about
any floor any longer), the FloorStatus message from the floor control
server will not include any FLOOR-ID attribute either.
FloorStatus messages that carry information about a floor contain a
FLOOR-ID attribute that identifies the floor. After this attribute,
FloorStatus messages contain information about existing (one or more)
floor requests that relate to that floor. The information about each
particular floor request is encoded in a FLOOR-REQUEST-INFORMATION
attribute. This grouped attribute carries a Floor Request ID that
identifies the floor request, followed by a set of attributes that
provide information about the floor request.
After the first FloorStatus, the floor control server will continue
sending FloorStatus messages, periodically informing the client about
changes on the floors the