The Binary Floor Control Protocol (BFCP)
obsoletes
- rfc-4582 — The Binary Floor Control Protocol (BFCP)
Extracted elements (28)
BFCP uses compact binary TLV encoding to minimize message size in low-bandwidth environments. Delay-sensitive primitives (FloorRequest, FloorRelease, FloorRequestStatus, ChairAction) are specifically designed to be small; future extensions are expected not to increase these sizes significantly.
The floor control server retains ultimate authority over floor state even when a ChairAction instructs a specific outcome. For example, a chair granting one floor of an atomic multi-floor request will not result in a grant until chairs for all floors agree — the server enforces consistency.
UDP transport was added (producing BFCP version 2) to address NAT traversal problems that make TCP impractical in many WebRTC and peer-to-peer deployments. ICE TCP, Teredo, GUT, UPnP IGD, NAT-PMP, SCTP, and prior BFCP-over-UDP proposals were evaluated and found insufficient before this approach was chosen.
BFCP version 1 is used with reliable (TCP/TLS) transport and version 2 with unreliable (UDP/DTLS) transport. Entities implementing only RFC 4582 (version 1) will not recognize error code 12 (Unsupported Version) or the fragment fields, and must not receive version-2 messages.
A client MUST NOT use more than one TCP connection to communicate with a given floor control server within a conference. If unparseable data is received, the entity MUST close the TCP connection. Reconnection attempts MUST NOT exceed once per 30-second period to avoid server overload.
If a floor control server receives a message with an incorrect Payload Length, it MUST send an Error message with parameter value 13 (Incorrect Message Length) and discard the message. Other entities that receive an incorrect length MUST also discard the message.
If a floor control server receives an unrecognized attribute with the Mandatory ('M') bit set, it MUST send an Error message with parameter value 4 (Unknown Mandatory Attribute). Unrecognized attributes without 'M' set are silently ignored and the message is still processed.
It is RECOMMENDED that the 32-bit Conference ID be randomly chosen. Predictable conference identifiers with a nonsecure transport make BFCP susceptible to off-path data injection attacks where an attacker can forge requests or responses.
Over UDP, clients MUST announce their presence by sending a Hello message before any other BFCP interaction. The client considers the server available only upon receiving the HelloAck response. Each BFCP UDP datagram MUST contain exactly one BFCP message or fragment.
Over unreliable transport, floor participants and chairs MUST acknowledge subsequent server-initiated FloorRequestStatus messages with FloorRequestStatusAck, and subsequent FloorStatus messages with FloorStatusAck. This stops the server's retransmission timer T2.
The Version field MUST be set to 1 over reliable transport and MUST be set to 2 over unreliable transport. If a server receives an unsupported version or a version inconsistent with the transport, it MUST send an Error message with error code 12 (Unsupported Version).
To avoid IP-layer fragmentation, BFCP messages exceeding the path MTU MUST be fragmented at the BFCP application layer using the Fragment Offset and Fragment Length fields in the COMMON-HEADER. Receivers that detect fragments exceeding the Payload Length MUST discard the message; servers MUST also send Error code 13.
BFCP defines 17 message primitives: FloorRequest (1), FloorRelease (2), FloorRequestQuery (3), FloorRequestStatus (4), UserQuery (5), UserStatus (6), FloorQuery (7), FloorStatus (8), ChairAction (9), ChairActionAck (10), Hello (11), HelloAck (12), Error (13), FloorRequestStatusAck (14), FloorStatusAck (15), Goodbye (16), and GoodbyeAck (17).
Goodbye (Primitive 16) and GoodbyeAck (Primitive 17) are used exclusively over unreliable transport for graceful session teardown. A BFCP entity transmits Goodbye to dissociate from a remote participant; the peer responds with GoodbyeAck.
The FloorRequest message carries one or more FLOOR-ID attributes, an optional BENEFICIARY-ID for third-party requests, optional PARTICIPANT-PROVIDED-INFO, and optional PRIORITY. When multiple FLOOR-IDs are present, the server treats them as an atomic package and either grants or denies all floors together.
The HelloAck message includes mandatory SUPPORTED-PRIMITIVES and SUPPORTED-ATTRIBUTES attributes, advertising server capabilities. Over unreliable transport, the Hello/HelloAck exchange also serves as the mandatory session initiation handshake before any other messages can be sent.
The PRIORITY attribute (Type 4, OctetString16) carries a 3-bit priority value (0=Lowest through 4=Highest). Senders SHOULD NOT use values above 4; receivers MUST treat values above 4 as 4. The default priority when the attribute is absent is 2 (Normal).
IANA maintains the 'BFCP Attributes' subregistry with 18 defined attribute types (BENEFICIARY-ID=1 through OVERALL-REQUEST-STATUS=18). The 'M' bit in extension attributes signals whether support is mandatory. New attributes require IETF Review.
IANA maintains the 'BFCP Error Codes' subregistry with 14 defined codes (Conference Does Not Exist=1 through Generic Error=14). New error codes require IETF Review.
IANA maintains the 'BFCP Primitives' subregistry with 17 defined primitive values (FloorRequest=1 through GoodbyeAck=17). New primitives require IETF Review.
IANA maintains the 'BFCP Request Statuses' subregistry with 7 defined values: Pending (1), Accepted (2), Granted (3), Denied (4), Cancelled (5), Released (6), and Revoked (7). New values require IETF Review.
BFCP messages MUST be protected using TLS over TCP or DTLS over UDP to prevent tampering, eavesdropping, and replay attacks. Error code 9 (Use TLS) and error code 11 (Use DTLS) allow servers to redirect clients to a secure transport when an insecure connection is attempted.
TLS/DTLS mutual authentication is required to authorize floor participants and floor chairs, preventing unauthorized floor operations such as illegitimate floor grants or releases. Without mutual authentication, an attacker could impersonate a floor chair.
A floor request transitions through states encoded in the REQUEST-STATUS attribute: Pending (server awaiting floor chair contact), Accepted (chair accepted; in queue), Granted, Denied, Cancelled, Released, and Revoked. An 8-bit Queue Position field accompanies the Accepted state when applicable.
BFCP attributes are encoded in TLV format and are 32-bit aligned. Each attribute begins with a 7-bit Type, a 1-bit Mandatory (M) flag, and an 8-bit Length field (in octets, excluding padding), followed by variable-length Attribute Contents. Padding of 1–3 octets aligns the attribute to 32-bit boundaries.
The BFCP COMMON-HEADER is 12 octets (or 16 if fragmented) and contains: a 3-bit Version, R (Transaction Responder) flag, F (Fragmentation) flag, 3 reserved bits, an 8-bit Primitive, a 16-bit Payload Length, a 32-bit Conference ID, a 16-bit Transaction ID, and a 16-bit User ID. When F is set (unreliable transport only), 16-bit Fragment Offset and Fragment Length fields follow.
The ERROR-CODE attribute (Type 6, OctetString) encodes an 8-bit error code plus optional Error Specific Details. Defined codes include: 1 Conference Does Not Exist, 4 Unknown Mandatory Attribute, 5 Unauthorized Operation, 9 Use TLS, 11 Use DTLS, 12 Unsupported Version, 13 Incorrect Message Length, and 14 Generic Error (14 codes total).
The FLOOR-REQUEST-INFORMATION grouped attribute (Type 15) header carries a 16-bit Floor Request ID, followed by an optional OVERALL-REQUEST-STATUS, one or more FLOOR-REQUEST-STATUS sub-attributes, and optional BENEFICIARY-INFORMATION, REQUESTED-BY-INFORMATION, PRIORITY, and PARTICIPANT-PROVIDED-INFO.