Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
obsoletes
- rfc-4583 — Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
Extracted elements (31)
For TLS, the original RFC 4583 procedure for determining which endpoint acts as TLS server was retained to maintain backward compatibility, even though the rest of the document was substantially revised.
The 'c-s' floorctrl role (acting as both client and server simultaneously) was removed because it was underspecified in RFC 4583 and implemented inconsistently — many implementations treated it as equivalent to 'c-only s-only'. The new specification drops it from generation but requires accepting it for backward compatibility.
The primary purpose of this revision over RFC 4583 was to add signaling support for BFCP over unreliable (UDP) transport, adding proto values 'TCP/DTLS/BFCP', 'UDP/BFCP', and 'UDP/TLS/BFCP', and the new 'bfcpver' attribute for version negotiation.
All ICE-enabled BFCP-over-DTLS endpoints SHOULD implement support for UDP/TLS/BFCP to maximize interoperability. Endpoints treat all ICE candidate pairs on a BFCP stream as part of the same DTLS association, resulting in a single DTLS handshake.
Endpoints compliant with RFC 4583 may omit the 'floorctrl' attribute. For backward compatibility, if the attribute is absent, the offerer acts as floor control client and the answerer acts as floor control server.
For TLS over TCP, the answerer always acts as TLS server once the underlying connection is established. Subsequent SDP offers and answers will not impact previously negotiated TLS roles unless a new TLS connection is negotiated.
The first SDP example in RFC 4583 Section 9 erroneously used 'm-stream' instead of the correct 'mstrm' in the 'floorid' attribute. It is RECOMMENDED to support parsing 'm-stream' as equivalent to 'mstrm' when receiving, since some implementations use it.
The proto values 'TCP/BFCP' and 'TCP/TLS/BFCP' are backward compatible with endpoints compliant with RFC 4583, while 'UDP/BFCP', 'UDP/TLS/BFCP', and 'TCP/DTLS/BFCP' are not.
A BFCP stream MUST NOT be associated with a BUNDLE group (RFC 8843), though BFCP-controlled media streams themselves may be multiplexed with other media streams.
An implementation compliant with RFC 8856 MUST NOT include the 'c-s' 'floorctrl' attribute value in an offer or answer, but MUST accept it in an offer and process it as equivalent to 'c-only s-only'.
If 'bfcpver' is absent, endpoints MUST assume a default value per RFC 8855: '1' for reliable transports and '2' for unreliable transports, inferred from the 'm=' line proto value.
If the offerer includes 'floorctrl' with 's-only' or 'c-s' values, it MUST also include 'confid', 'userid', 'floorid' attributes in the BFCP 'm=' section, and an SDP 'label' attribute in each BFCP-controlled media stream's 'm=' section.
The fmt list of 'm=' lines for any BFCP-related proto value MUST contain a single '*' character; any other value in the fmt list MUST be ignored.
The media field in the 'm=' line describing a BFCP connection MUST have a value of 'application'.
When an SDP offer or answer conveys multiple ICE candidates for a BFCP stream, UDP-based candidates SHOULD be included and the default candidate SHOULD be chosen from UDP candidates.
When DTLS is used with UDP (proto 'UDP/TLS/BFCP' or 'TCP/DTLS/BFCP'), the generic procedures defined in Section 5 of RFC 8842 MUST be followed.
When generating an initial SDP offer, the offerer MUST include both an SDP 'floorctrl' attribute and an SDP 'bfcpver' attribute in the 'm=' section describing the BFCP stream.
When generating an SDP answer, the answerer MUST check version compatibility via 'bfcpver'; if no supported BFCP version is found, it MUST NOT accept the 'm=' section. If accepted, it MUST include 'bfcpver' in the answer with values that are a subset of those in the offer.
When the existing TCP connection is closed and needs re-establishment per RFC 8855 rules, the floor control client MUST send an offer to the floor control server to re-establish it. If a timeout occurs, the endpoint that detected the timeout MUST send an offer.
The SDP 'bfcpver' media-level attribute negotiates the BFCP version using decimal integer representation (ABNF: bfcp-version = version *(SP version)). The BFCP version ultimately used is confirmed via a BFCP-level Hello/HelloAck exchange.
The SDP 'confid' media-level attribute conveys the conference ID from floor control server to client using decimal integer representation (ABNF: conference-id = 1*DIGIT). Its maximum value is bounded by the BFCP COMMON-HEADER format.
The SDP 'floorctrl' media-level attribute determines floor control roles. Its ABNF is: floor-control = role *(SP role); role = 'c-only' / 's-only' / 'c-s'. An offerer MAY include multiple roles; an answerer MUST include only one: 'c-only' or 's-only'.
The SDP 'floorid' media-level attribute conveys a floor identifier and optional pointers to BFCP-controlled media streams (ABNF: floor-id = 1*DIGIT SP 'mstrm:' token *(SP token)). Each token value corresponds to the 'label' attribute of a BFCP-controlled media stream.
The SDP 'm=' line for a BFCP stream MUST have media field 'application', a fmt list containing only '*', and one of five proto values: 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP', 'UDP/BFCP', or 'UDP/TLS/BFCP'. A port value of zero indicates rejection of the media stream regardless of proto.
The SDP 'userid' media-level attribute conveys the user ID from floor control server to client using decimal integer representation (ABNF: user-id = 1*DIGIT). Its maximum value is bounded by the BFCP COMMON-HEADER format.
This document registers five SDP media-level attributes in the 'Session Description Protocol (SDP) Parameters' registry: 'floorctrl', 'confid', 'userid', 'floorid' (carried over from RFC 4583 with updated references), and 'bfcpver' (newly added).
This document registers five SDP 'proto' field values in the 'Session Description Protocol (SDP) Parameters' registry: 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP', 'UDP/BFCP', and 'UDP/TLS/BFCP'. Three of these ('TCP/DTLS/BFCP', 'UDP/BFCP', 'UDP/TLS/BFCP') are new registrations.
The SDP attributes defined in this specification (floorctrl, confid, userid, floorid, bfcpver) do not reveal content of individual BFCP-controlled media streams, but they do reveal which media streams will be BFCP-controlled, which may be sensitive information.
Using proto values 'TCP/BFCP' or 'UDP/BFCP' results in a BFCP stream not protected by TLS or DTLS. Operators must provide integrity and confidentiality protection through other means when using these unencrypted transports.
The 'floorctrl' attribute value is encoded as space-separated role tokens: 'c-only' (client only), 's-only' (server only), or legacy 'c-s' (both). In an answer, exactly one role token MUST appear.
The 'floorid' attribute encodes as '1*DIGIT SP "mstrm:" token *(SP token)', where the integer is the BFCP Floor ID field value and each token matches an SDP 'label' attribute of a BFCP-controlled stream.