The Binary Floor Control Protocol (BFCP)
obsoleted by
- rfc-8855 — The Binary Floor Control Protocol (BFCP)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (30)
BFCP uses a binary (TLV) encoding rather than a text encoding to achieve small message sizes in low-bandwidth environments. Delay-sensitive messages (FloorRequest, FloorRelease, FloorRequestStatus, ChairAction) are designed to remain compact, and future extensions are expected not to increase their size significantly.
When a FloorRequest contains multiple FLOOR-ID attributes, the server treats the entire request as an atomic package: all floors are either granted together or denied together. This supports use cases where a participant needs simultaneous access to multiple resources (e.g., audio and whiteboard).
Clients obtain the transport address, conference identifier, and user identifier needed to establish a BFCP connection via mechanisms outside BFCP itself, such as an SDP offer/answer exchange as described in a companion document, or via the XCON conferencing framework.
The floor control server is ultimately responsible for maintaining a coherent floor state; ChairAction messages from floor chairs are advisory inputs that the server considers but need not follow exactly (e.g., a grant on one floor of an atomic multi-floor request does not take effect until all chairs agree).
A client MUST NOT use more than one TCP connection to communicate with a given floor control server within a conference; different logical clients (distinct User IDs) on the same physical host may each use a separate connection.
A client starting a client-initiated transaction MUST set a non-zero Transaction ID that MUST NOT be reused until a response is received; the server MUST copy the Conference ID, Transaction ID, and User ID from the request into the response.
All BFCP protocol values MUST be sent in network byte order (big-endian).
BFCP floor control servers and clients MUST support TLS; at minimum they MUST support the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.
BFCP messages received from a client that cannot be authorized MUST NOT be processed further; the floor control server generates an Error message with Error Code 5 (Unauthorized Operation).
If a BFCP entity receives data from TCP that cannot be parsed, it MUST close the TCP connection, and the connection SHOULD be reestablished. If a TCP connection times out while delivering a BFCP message, the connection SHOULD be reestablished.
If an unrecognized attribute with the M (Mandatory) bit set is received, the message MUST be rejected; unrecognized attributes with M=0 are ignored and the message is processed normally.
The Ver field in the COMMON-HEADER MUST be set to 1 to indicate this version of BFCP; Reserved bits MUST be ignored by the receiver.
When a floor participant sends a third-party FloorRequest (the sender is not the floor beneficiary), it SHOULD add a BENEFICIARY-ID attribute identifying the beneficiary.
A FloorRequest message MUST contain at least one FLOOR-ID attribute and optionally BENEFICIARY-ID, PARTICIPANT-PROVIDED-INFO, and PRIORITY. If more than one FLOOR-ID is included, the server treats all floors as an atomic package and must grant or deny them all together.
A HelloAck message is the floor control server's response to a Hello liveliness check and MUST include SUPPORTED-PRIMITIVES and SUPPORTED-ATTRIBUTES attributes, advertising the server's capabilities to the client.
BFCP defines 13 primitives in the Primitive field of the common header: FloorRequest (1), FloorRelease (2), FloorRequestQuery (3), FloorRequestStatus (4), UserQuery (5), UserStatus (6), FloorQuery (7), FloorStatus (8), ChairAction (9), ChairActionAck (10), Hello (11), HelloAck (12), and Error (13), each with defined sender/receiver roles.
Server-initiated transactions (notifications such as unsolicited FloorRequestStatus or FloorStatus messages) carry a Transaction ID of 0 in the common header and do not trigger a client response.
IANA created a Primitive Subregistry for BFCP with 13 initial primitive values (1–13). New values in the range 1–255 require IETF Consensus.
IANA created a Request Status Subregistry for BFCP with 7 initial values: Pending (1), Accepted (2), Granted (3), Denied (4), Cancelled (5), Released (6), Revoked (7). New values require IETF Consensus.
IANA created an Attribute Subregistry for BFCP under the 'floor control' registry, with 18 initial attribute types (1–18). New values in the range 1–127 require IETF Consensus; values 128–255 are reserved for private extensions.
IANA created an Error Code Subregistry for BFCP with 9 initial error codes (1–9), including 'Conference does not Exist' (1) through 'Use TLS' (9). New values require IETF Consensus.
A floor control server that receives a BFCP message over plain TCP (no TLS) may request TLS by responding with an Error message containing Error Code 9 (Use TLS); clients SHOULD ignore unauthenticated messages. The floor control server SHOULD also verify that messages on an authenticated TLS connection use an authorized User ID.
BFCP requires TLS-based mutual authentication between clients and floor control servers as the RECOMMENDED mechanism. It relies on an integrity-protected channel (e.g., SIP/SDP offer-answer) to exchange self-signed certificates or their fingerprints used at TLS establishment.
BFCP attributes use TLV (Type-Length-Value) encoding and are 32-bit aligned. Each attribute begins with a 7-bit Type field, a 1-bit Mandatory (M) flag, and an 8-bit Length field in octets (including Type, M, and Length fields); padding of 1–3 octets is added as needed.
The BENEFICIARY-ID attribute (type 1, Unsigned16 format) carries a 16-bit value uniquely identifying a user within a conference; used in third-party floor requests to identify the floor beneficiary, distinct from the User ID in the common header.
The BFCP COMMON-HEADER is 12 octets: a 3-bit Ver field (MUST be 1), 5-bit Reserved, 8-bit Primitive, 16-bit Payload Length (in 4-octet units, excluding the header), 32-bit Conference ID, 16-bit Transaction ID, and 16-bit User ID.
The ERROR-CODE attribute (type 6, OctetString format) carries an 8-bit Error Code field with nine defined values (e.g., 1=Conference does not Exist, 5=Unauthorized Operation, 9=Use TLS), optional Error Specific Details, and padding to 32-bit alignment.
The FLOOR-REQUEST-INFORMATION grouped attribute (type 15) consists of a header carrying a 16-bit Floor Request ID, followed by optional OVERALL-REQUEST-STATUS, one or more FLOOR-REQUEST-STATUS attributes, and optional BENEFICIARY-INFORMATION, REQUESTED-BY-INFORMATION, PRIORITY, and PARTICIPANT-PROVIDED-INFO.
The PRIORITY attribute (type 4, OctetString16 format) carries a 3-bit Prio field with values 0 (Lowest) through 4 (Highest); the default when the attribute is absent is 2 (Normal). Receivers MUST treat values greater than 4 as if the value were 4.
The REQUEST-STATUS attribute (type 5, OctetString16 format) carries an 8-bit Request Status field (Pending=1, Accepted=2, Granted=3, Denied=4, Cancelled=5, Released=6, Revoked=7) and an 8-bit Queue Position field indicating position in the floor request queue.