The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)
Extracted elements (27)
If BFCP encoding changes from binary TLV (e.g., to JSON serialization), a new subprotocol identifier would need to be selected, keeping the 'bfcp' identifier tied specifically to the current binary encoding.
WebSocket was chosen as a BFCP transport to enable usage in modern web browsers and client applications (smartphones, PCs) that expose WebSocket client stacks per the W3C WebSocket API, extending BFCP applicability beyond traditional TCP/UDP deployments.
While secure WebSocket (TCP/WSS) is recommended for security, TCP/WS is also permitted to achieve maximum compatibility among clients. A floor control server can enforce TLS upgrade via an error response if needed.
Browser-based WebSocket clients have no control over TLS algorithm selection via the WebSocket API, so standard web-based authentication methods are recommended instead of mutual TLS/DTLS as defined in RFC 8855.
Since WebSocket provides a reliable transport, the BFCP extensions defined in RFC 8855 for sending BFCP over unreliable transports are not applicable when using the WebSocket BFCP subprotocol.
The server MUST assign the SDP 'setup' attribute with a value of 'passive' when acting as SDP offerer in response to an offerless INVITE. The 'proto' field MUST be 'TCP/WSS/BFCP' if WebSocket is over TLS, else 'TCP/WS/BFCP'.
A BFCP WebSocket client MUST actively initiate a connection towards a BFCP WebSocket server; clients cannot receive incoming WebSocket connections initiated by any other peer.
An endpoint MUST create an SDP media description ('m=' line) for each BFCP-over-WebSocket media stream and MUST assign either 'TCP/WSS/BFCP' or 'TCP/WS/BFCP' to the 'proto' field. The server side MUST add a 'websocket-uri' attribute in the media section.
BFCP messages MUST be transported in unfragmented binary WebSocket frames (FIN: 1, opcode: %x2). The WebSocket frame data MUST be a valid BFCP message, and the payload length MUST be lower than 2^16 + 12 bytes.
Client and server transactions using WebSocket for transport MUST follow the procedures for reliable transports as defined in RFC 8855 and RFC 8856, since WebSocket provides a reliable transport.
Each BFCP message MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one BFCP message.
If the signaling or control protocol traffic used to set up the conference is authenticated and confidentiality and integrity protected, secure WebSocket (WSS) MUST be used, and the floor control server MUST authenticate the client.
It is RECOMMENDED that BFCP traffic transported over WebSocket be protected by using a Secure WebSocket connection (WSS using TLS over TCP). The BFCP WebSocket client MUST follow RFC 7525 procedures when setting up TLS.
The BFCP WebSocket client MUST include the value 'bfcp' in the Sec-WebSocket-Protocol header field in its handshake request, and the 101 reply from the server MUST contain 'bfcp' in its corresponding Sec-WebSocket-Protocol header field.
The SDP attribute 'websocket-uri' defined in RFC 8124 MUST be used when BFCP runs on top of WS or WSS, and when present in the media section, the procedures in Section 4 of RFC 8124 MUST be followed.
The WebSocket client MUST follow the procedures in RFC 7525 (including hostname verification per Section 6.1) while setting up a TLS connection with the WebSocket server. The 'websocket-uri' value MUST contain a hostname.
The SDP 'websocket-uri' attribute (from RFC 8124) is used in the media section to convey the WebSocket connection URI (ws-URI or wss-URI) for the BFCP WebSocket server.
The WebSocket BFCP subprotocol identifier is 'bfcp', negotiated via the Sec-WebSocket-Protocol header during the WebSocket opening handshake. It enables transport of binary BFCP messages over a WebSocket connection.
Two new SDP 'proto' field values are defined: 'TCP/WS/BFCP' for BFCP over plain WebSocket over TCP, and 'TCP/WSS/BFCP' for BFCP over secure WebSocket (TLS over TCP).
IANA registered the WebSocket BFCP subprotocol under the 'WebSocket Subprotocol Name Registry' with subprotocol identifier 'bfcp' and common name 'WebSocket Transport for BFCP (Binary Floor Control Protocol)', referencing RFC 8857.
Two new values 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' are registered in the SDP 'proto' subregistry within the 'Session Description Protocol (SDP) Parameters' registry, both referencing RFC 8857.
A floor control server that receives a message over TCP/WS can mandate the use of TCP/WSS by generating an Error message with error code 9 (Use TLS) as described in Section 13.8 of RFC 8855.
An attacker attempting to impersonate a floor control server or client is mitigated by accepting BFCP messages over WSS only, with clients verifying the server certificate per RFC 7525 including hostname verification.
Replay attacks are prevented by having floor control servers check that messages arriving over a given WSS connection use an authorized user ID. Message modification is prevented by using WSS between client and server.
The level of encryption protection when WSS is used is limited to the underlying TLS algorithm used by the WebSocket library, since the WebSocket API provides no way for applications to select specific encryption algorithms.
When using BFCP over WebSocket, the security mechanisms defined in RFC 8855 (such as TLS/DTLS mutual authentication) are not used; instead the application must rely on WebSocket security mechanisms from RFC 6455. WSS with server certificate validation replaces the RFC 8855 security model.
BFCP messages use TLV (Type-Length-Value) binary encoding and MUST be carried in unfragmented binary WebSocket frames with FIN bit set to 1 and opcode %x2 (binary frame). Maximum payload size is 2^16 + 12 bytes per RFC 8855.