RFC 8855
The Binary Floor Control Protocol (BFCP)
Part 1 of 21 🎀
The Binary Floor Control Protocol (BFCP) 💖
Title Block 📋
- RFC number: 8855 ✨
- Title: The Binary Floor Control Protocol (BFCP)
- Authors: G. Camarillo (Ericsson), K. Drage, T. Kristensen (Jotron), J. Ott (Technical University Munich), C. Eckel (Cisco)
- Category: Standards Track 🦋
- Date: January 2021 🌸
- ISSN: 2070-1721
- Obsoletes: RFC 4582 💅
Abstract
Okay so, floor control is basically how you manage who gets to use shared stuff, either together or one person at a time, in a (multiparty) conference 🎀 It's a total main character feature, and it works alongside other stuff like setting up the conference and media sessions, changing conference policy, and controlling media. Those other jobs get handled by other protocols, so floor control just slides right in next to them 💜
This document defines the Binary Floor Control Protocol (BFCP) ✨ BFCP gets used between floor participants and floor control servers, and also between floor chairs (aka moderators) and floor control servers 👑
This document obsoletes RFC 4582 💀
Status of This Memo
This is an Internet Standards Track document 🔥
This document is a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶 If you want more info on Internet Standards, check out Section 2 of RFC 7841 🍓
For the latest status, any errata, and how to send feedback on this document, head to https://www.rfc-editor.org/info/rfc8855 🧚
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these docs carefully, because they explain your rights and restrictions for this document 📜 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶
Table of Contents 🗂️
1. Introduction
2. Terminology
3. Scope
3.1. Floor Creation
3.2. Obtaining Information to Contact a Floor Control Server
3.3. Obtaining Floor-Resource Associations
3.4. Privileges of Floor Control
4. Overview of Operation
4.1. Floor Participant to Floor Control Server Interface
4.2. Floor Chair to Floor Control Server Interface
5. Packet Format
5.1. COMMON-HEADER Format
5.2. Attribute Format
5.2.1. BENEFICIARY-ID
5.2.2. FLOOR-ID
5.2.3. FLOOR-REQUEST-ID
5.2.4. PRIORITY
5.2.5. REQUEST-STATUS
5.2.6. ERROR-CODE
5.2.6.1. Error Specific Details for Error Code 4
5.2.7. ERROR-INFO
5.2.8. PARTICIPANT-PROVIDED-INFO
5.2.9. STATUS-INFO
5.2.10. SUPPORTED-ATTRIBUTES
5.2.11. SUPPORTED-PRIMITIVES
5.2.12. USER-DISPLAY-NAME
5.2.13. USER-URI
5.2.14. BENEFICIARY-INFORMATION
5.2.15. FLOOR-REQUEST-INFORMATION
5.2.16. REQUESTED-BY-INFORMATION
5.2.17. FLOOR-REQUEST-STATUS
5.2.18. OVERALL-REQUEST-STATUS
5.3. Message Format
5.3.1. FloorRequest
5.3.2. FloorRelease
5.3.3. FloorRequestQuery
5.3.4. FloorRequestStatus
5.3.5. UserQuery
5.3.6. UserStatus
5.3.7. FloorQuery
5.3.8. FloorStatus
5.3.9. ChairAction
5.3.10. ChairActionAck
5.3.11. Hello
5.3.12. HelloAck
5.3.13. Error
5.3.14. FloorRequestStatusAck
5.3.15. FloorStatusAck
5.3.16. Goodbye
5.3.17. GoodbyeAck
6. Transport
6.1. Reliable Transport
6.2. Unreliable Transport
6.2.1. Congestion Control
6.2.2. ICMP Error Handling
6.2.3. Fragmentation Handling
6.2.4. NAT Traversal
7. Lower-Layer Security
8. Protocol Transactions
8.1. Client Behavior
8.2. Server Behavior
8.3. Timers
8.3.1. Request Retransmission Timer, T1
8.3.2. Response Retransmission Timer, T2
8.3.3. Timer Values
9. Authentication and Authorization
9.1. TLS/DTLS Based Mutual Authentication
10. Floor Participant Operations
10.1. Requesting a Floor
10.1.1. Sending a FloorRequest Message
10.1.2. Receiving a Response
10.1.3. Reception of a Subsequent FloorRequestStatus Message
10.2. Cancelling a Floor Request and Releasing a Floor
10.2.1. Sending a FloorRelease Message
10.2.2. Receiving a Response
11. Chair Operations
11.1. Sending a ChairAction Message
11.2. Receiving a Response
12. General Client Operations
12.1. Requesting Information about Floors
12.1.1. Sending a FloorQuery Message
12.1.2. Receiving a Response
12.1.3. Reception of a Subsequent FloorStatus Message
12.2. Requesting Information about Floor Requests
12.2.1. Sending a FloorRequestQuery Message
12.2.2. Receiving a Response
12.3. Requesting Information about a User
12.3.1. Sending a UserQuery Message
12.3.2. Receiving a Response
12.4. Obtaining the Capabilities of a Floor Control Server
12.4.1. Sending a Hello Message
12.4.2. Receiving Responses
13. Floor Control Server Operations
13.1. Reception of a FloorRequest Message
13.1.1. Generating the First FloorRequestStatus Message
13.1.2. Generation of Subsequent FloorRequestStatus Messages
13.2. Reception of a FloorRequestQuery Message
13.3. Reception of a UserQuery Message
13.4. Reception of a FloorRelease Message
13.5. Reception of a FloorQuery Message
13.5.1. Generation of the First FloorStatus Message
13.5.2. Generation of Subsequent FloorStatus Messages
13.6. Reception of a ChairAction Message
13.7. Reception of a Hello Message
13.8. Error Message Generation
14. Security Considerations
15. IANA Considerations
15.1. Attributes Subregistry
15.2. Primitives Subregistry
15.3. Request Statuses Subregistry
15.4. Error Codes Subregistry
16. Changes from RFC 4582
16.1. Extensions for an Unreliable Transport
16.2. Other Changes
17. References
17.1. Normative References
17.2. Informative References
Appendix A. Example Call Flows for BFCP over an Unreliable
Transport
Appendix B. Motivation for Supporting an Unreliable Transport
B.1. Motivation
B.1.1. Alternatives Considered
B.1.1.1. ICE TCP
B.1.1.2. Teredo
B.1.1.3. GUT
B.1.1.4. UPnP IGD
B.1.1.5. NAT PMP
B.1.1.6. SCTP
B.1.1.7. BFCP over UDP Transport
Acknowledgements
Authors' Addresses1. Introduction ✨
Okay so, in a conference, some apps need to manage access to a set of shared resources, like the right to send media on a particular media session 🎀 Floor control is what lets those apps give users coordinated access to these resources, whether that's shared or exclusive 💅
The Requirements for Floor Control Protocol [18] lists a set of requirements that floor control protocols need to meet 📋 The Binary Floor Control Protocol (BFCP), which this document specifies, meets those requirements. It's giving compliance, bestie 💖
BFCP was also designed to work in low-bandwidth environments 🌸 It uses a binary encoding, so when message signatures aren't used, the messages stay pretty small, which keeps the time it takes to send delay-sensitive BFCP messages super low 🦋 The delay-sensitive ones are FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. The expectation is that future extensions to these messages won't make them much bigger, which is so iconic 🫶
Here's how the rest of this document is laid out 🗺️ Section 2 defines the terminology used throughout. Section 3 covers the scope of BFCP, meaning which tasks BFCP handles and which ones are done with different mechanisms 🍓 Section 4 gives a non-normative overview of how BFCP operates. The sections after that hold the normative specification of BFCP 🧚 And Section 16 summarizes the changes from RFC 4582 [3] 👑
2. Terminology ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [1] [10] when, and only when, they appear in all capitals, as shown here. 💅
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 co-located 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 co-located. The protocol between a floor participant and a media participant (that are not co-located) is outside the scope of this document. 🎀
Client: A floor participant or a floor chair that communicates with a floor control server using BFCP. 🦋
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 co-located 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 co-located. 🌸
Participant: An entity that acts as a floor participant, as a media participant, or as both. 🌈
BFCP Connection: A transport association between BFCP entities, used to exchange BFCP messages. 💜
Transaction Failure Window: When communicating over an unreliable transport, this is some period of time less than or equal to T1*2^(4) (see Section 8.3). For reliable transports, this period of time is unbounded. 💀
3. Scope 🌷
As stated earlier, BFCP is a protocol to coordinate access to shared resources in a conference following the requirements defined in [18]. Floor control complements other functions defined in the Centralized Conferencing (XCON) Framework [19]. 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 [19].
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 +---------+ +-------------+
DeniedFigure 1: Functionality provided by BFCP
BFCP provides a means:
- for floor participants to send floor requests to floor control servers.
- for floor control servers to grant or deny requests to access a given resource from floor participants.
- for floor chairs to send floor control servers decisions regarding floor requests.
- 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. 🧁
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 [19]. 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).
Conference control clients using Centralized Conferencing Manipulation Protocol (CCMP) [23] can specify such floor-related settings in the <floor-information> element [22] of the to-be created conference object provided in the body of a CCMP confRequest/create message issued to the conference control server. 🛠️
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 a Session Description Protocol (SDP) offer/answer [17] exchange, which is described in [12]. How to establish a connection to a BFCP floor control server is outside the context of an offer/answer exchange when using a reliable transport is described in [4]. Other mechanisms are described in the XCON Framework [19] (and other related documents). For unreliable transports, the use of an SDP offer/answer exchange is the only specified mechanism. 🌟
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 [17] exchange. How to use an SDP offer/answer exchange to obtain these associations is described in [12].
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 [19] (and other related documents). According to the conferencing system policies, conference control clients using CCMP [23] can modify the floor settings of a conference by issuing CCMP confRequest/update messages providing the specific updates to the <floor-information> element of the target conference object. More information about CCMP and BFCP interaction can be found in [24]. 🍓
3.4. Privileges of Floor Control
A participant whose floor request is granted has the right to use 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 [19]. 🙈
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. Section 8 describes both types of transactions in detail. 🔁
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 co-located 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. 🙋♀️
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. bestie, this is the atomic all-or-nothing energy we love 🌈✨
Okay bestie, the floor control server answers every FloorRequest with a FloorRequestStatus message 💅, and that message spills the tea on where the floor request stands ✨. The first FloorRequestStatus is the reply to the client's FloorRequest, so it carries the same Transaction ID as that FloorRequest 🦋.
The first FloorRequestStatus also tucks the Floor Request ID inside a FLOOR-REQUEST-INFORMATION attribute 🎀. Every later FloorRequestStatus about that same floor request carries the same Floor Request ID too, so the floor participant can match each one to the right request 🫶.
Messages the floor participant sends about a particular floor request also use that same Floor Request ID, the one from the first FloorRequestStatus the server sent 🧚.
Figure 2 and Figure 3 are example call flows where BFCP runs over a reliable transport 🌸. Appendix A has the same call flow examples but over an unreliable transport 💜.
Figure 2 is the one where a floor participant requests a floor, gets it, and releases it later on 👑. It shows off the Transaction ID and the FLOOR-REQUEST-ID attribute, among other things 😭.
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 |
|---------------------------------------------->|
| |
|(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 floorFigure 3 is where a floor participant asks to be kept in the loop about a floor's status 📣. The first FloorStatus from the server is the reply to the FloorQuery, so it has the same Transaction ID as that FloorQuery 💖.
The later FloorStatus messages are server-initiated transactions, which is why their Transaction ID is 0 here 🌈. This example runs over a reliable transport, by the way ✨. FloorStatus message (2) says there are currently two floor requests for the floor with Floor ID 543 🍓. FloorStatus message (3) says the floor request with Floor Request ID 764 has been granted, and the floor request with Floor Request ID 635 is first in line 🥳. FloorStatus message (4) says the floor request with Floor Request ID 635 has been granted too 🎉.
Floor Participant Floor Control
Server
|(1) FloorQuery |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(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 |
|<----------------------------------------------|
| |
|(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 floorFloorStatus messages hold info about the floor requests they carry 🗂️. For instance, FloorStatus message (4) says the floor request with Floor Request ID 635 has as its beneficiary (that's the participant who holds the floor once that request is granted) the participant whose User ID is 154 💁♀️. This floor request only applies to the floor with Floor ID 543, so it is not a multi-floor floor request 🙅♀️.
Here's the note about multi-floor requests, which is super important 👀:
| 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 telling a floor control server to grant a floor 🎀
👀 Quick heads up: the floor control server has to take ChairAction messages into account (like granting a floor), but it doesn't have to do exactly what the floor chair asked. What it actually does depends on the ChairAction message and its own internal state 💅
For example, a floor chair might send a ChairAction message granting a floor that was requested as part of an atomic floor request operation involving several floors. Even if the chair in charge of one of those floors tells the server to grant it, the server won't grant it until the chairs for the other floors agree too 🫶 Another example: a floor chair can tell the server to grant a floor to a participant. The server needs to revoke the floor from its current holder before handing it to the new participant 🦋
So the floor control server is ultimately responsible for keeping a coherent floor state. It uses instructions from floor chairs as input, but it's the one running the show 👑
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 server5. Packet Format 📦
BFCP packets are made up of a 12-octet COMMON-HEADER followed by attributes. All the protocol values MUST be sent in network byte order 🌸
5.1. COMMON-HEADER Format
Here's the COMMON-HEADER layout, bestie 🧚
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 |R|F| Res | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID |
+> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Fragment Offset (if F is set) | Fragment Length (if F is set) |
+> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+---- These fragment fields are never present
when using reliable transports
Figure 5: COMMON-HEADER formatVer: this 3-bit field tells you which version of BFCP the message follows 🎀 This spec defines two versions, 1 and 2. The Ver field MUST be set to 1 when BFCP runs over a reliable transport, and MUST be set to 2 when it runs over an unreliable transport. If a floor control server gets a message with an unsupported Ver value, or a version number that isn't allowed on the transport it arrived over, the server MUST tell the sender it doesn't support that version by sending an Error message with parameter value 12 (Unsupported Version). Heads up: BFCP entities that only support the [3] subset won't support this parameter value 🙈
R: the Transaction Responder (R) flag only matters when BFCP runs over an unreliable transport 🦋 When it's cleared, the message is a request starting a new transaction, and the Transaction ID that follows was generated for that transaction. When it's set, the message is a response to an earlier request, and the Transaction ID that follows is the one tied to that request. When BFCP runs over a reliable transport, this flag means nothing: the sender MUST clear it and the receiver MUST ignore it 💅
F: the Fragmentation (F) flag also only matters over an unreliable transport ✨ When it's cleared, the message isn't fragmented. When it's set, the message is a fragment of a large, fragmented BFCP message. (The optional Fragment Offset and Fragment Length fields described below only show up when the F flag is set.) Over a reliable transport this flag has no significance either: the sender MUST clear it, and the receiver MUST ignore it. In that case the receiver should also ignore the Fragment Offset and Fragment Length fields when processing the COMMON-HEADER 🫶
Res: the 3 bits in this reserved field MUST be set to zero by the sender and MUST be ignored by the receiver 🌈
Primitive: this 8-bit field says what the main purpose of the message is 💜 Here are the primitive values that 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 |
+-------+-----------------------+--------------------+
| 14 | FloorRequestStatusAck | P -> S ; Ch -> S |
+-------+-----------------------+--------------------+
| 15 | FloorStatusAck | P -> S ; Ch -> S |
+-------+-----------------------+--------------------+
| 16 | Goodbye | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+
| 17 | GoodbyeAck | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+
| S: Floor Control Server |
| P: Floor Participant |
| Ch: Floor Chair |
+----------------------------------------------------+
Table 1: BFCP primitivesPayload Length: this 16-bit field holds the length of the message in 4-octet units, not counting the COMMON-HEADER 📏 If a floor control server gets a message with a wrong Payload Length value, the server MUST send an Error message with parameter value 13 (Incorrect Message Length) to say so, and then drop the message. Other entities that receive a message with the wrong length MUST drop it too 🙅♀️
📝 Note: BFCP is built for small message sizes (see Section 1), and BFCP entities are REQUIRED to keep their messages smaller than what the 16-bit Payload Length field can express. If you need to convey info that isn't really about floor control, use other protocols instead, like the XCON Framework (cf. Section 3) 💖
Conference ID: this 32-bit unsigned integer identifies the conference the message belongs to 🎀 It is RECOMMENDED that the conference identifier be chosen at random. (Heads up: if you use predictable conference identifiers together with a nonsecure transport protocol, BFCP becomes open to off-path data injection attacks, where an attacker can forge a request or response message. Yikes 😭)
Transaction ID: this 16-bit value lets users match a message with its response (see Section 8) 🦋
User ID: this 16-bit unsigned integer uniquely identifies a participant within a conference 🧚
🌷 The identity a participant uses in BFCP, which is carried in the User ID field, is usually mapped to the identity that same participant uses in the session establishment protocol (e.g., SIP). How that mapping works is outside the scope of this spec.
Fragment Offset: this optional field only shows up when the F flag is set 🧩 It holds a 16-bit value saying how many 4-octet units are in the previous fragments, not counting the COMMON-HEADER.
Fragment Length: this optional field also only shows up when the F flag is set 🧩 It holds a 16-bit value saying how many 4-octet units are in this fragment, not counting the COMMON-HEADER. BFCP entities that receive fragments which, on their own or added together, go over the Payload Length value MUST drop the message. On top of that, if the receiver is a floor control server, it MUST also send an Error message with parameter value 13 (Incorrect Message Length) 🔥
5.2. Attribute Format
okay so BFCP attributes are all encoded in TLV (Type-Length-Value) format 🎀, and they're 32-bit aligned ✨, so everything lines up super neatly 💅
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 formatType: this 7-bit field holds the type of the attribute 🦋. Each attribute, identified by its type, has its own particular format. The attribute formats defined are:
Unsigned16: the contents are a 16-bit unsigned integer 🔢OctetString16: the contents are 16 bits of arbitrary dataOctetString: the contents are arbitrary data of variable lengthGrouped: the contents are a sequence of attributes 🧺
Note that extension attributes defined in the future may define new attribute formats.
The attribute types that are defined are listed here, so you can see who's who 👑
+======+===========================+===============+
| 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 attributesM: this is the 'M' bit, also known as the Mandatory bit 🛡️. It tells you whether support for the attribute is REQUIRED. If a floor control server gets an unrecognized attribute with the 'M' bit set, the server MUST send an Error message with parameter value 4 (Unknown Mandatory Attribute) to say so 🚨. The 'M' bit only matters for extension attributes defined in other documents. All attributes specified in this document MUST be understood by the receiver, so the setting of the 'M' bit doesn't matter for these 🙈. Unrecognized attributes, like ones that might be specified in future extensions, that don't have the 'M' bit set are ignored, but the message still gets processed ✨.
Length: this 8-bit field holds the length of the attribute in octets 📏, not counting any padding defined for specific attributes. For attributes that aren't grouped, the length includes the Type, 'M' bit, and Length fields. For grouped attributes, the Length is the length of the grouped attribute itself (including the 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
okay here's 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 formatBeneficiary ID: this field holds 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
here's the FLOOR-ID format 🍓
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 formatFloor ID: this field holds a 16-bit value that uniquely identifies a floor within a conference 🏳️🌈.
5.2.3. FLOOR-REQUEST-ID
and here's the FLOOR-REQUEST-ID format 🧚
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 formatFloor Request ID: this field holds a 16-bit value that identifies a floor request at the floor control server 📬.
5.2.4. PRIORITY
the PRIORITY attribute is next, and it's giving main character energy 👑
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 formatPrio: this field holds 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 they received were 4 (Highest) 💪. If the PRIORITY attribute is missing, the default Priority value is 2 (Normal) 💅.
+=======+==========+
| Value | Priority |
+=======+==========+
| 0 | Lowest |
+-------+----------+
| 1 | Low |
+-------+----------+
| 2 | Normal |
+-------+----------+
| 3 | High |
+-------+----------+
| 4 | Highest |
+-------+----------+
Table 3: Priority valuesReserved: the 13 bits in the reserved field MUST be set to zero by the sender of the message, and they MUST be ignored by the receiver 🤫.
5.2.5. REQUEST-STATUS
last but not least, 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 formatRequest Status: this 8-bit field holds the status of the request, as described in the table below 🚦.
+=======+===========+
| Value | Status |
+=======+===========+
| 1 | Pending |
+-------+-----------+
| 2 | Accepted |
+-------+-----------+
| 3 | Granted |
+-------+-----------+
| 4 | Denied |
+-------+-----------+
| 5 | Cancelled |
+-------+-----------+
| 6 | Released |
+-------+-----------+
| 7 | Revoked |
+-------+-----------+
Table 4: Request
Status valuesQueue Position: this 8-bit field holds, when it applies, 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 doesn't implement a floor request queue, or if the floor control server doesn't want to share this info with the client, 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 hasn't done that yet ⏳. Once the floor control chair accepts the floor request, the floor request moves to the Accepted state 🎉.
5.2.6. ERROR-CODE 🚨
Okay bestie, the ERROR-CODE attribute is where the drama lives 😭 Here's its layout:
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 formatError Code 💅: this 8-bit field holds an error code from the table below. If the receiver doesn't recognize the code, the receiver MUST assume that an error exists, so the original message that triggered the Error message gets processed anyway, but it's unclear what actually went wrong 💀
+=======+=============================================+
| 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 |
+-------+---------------------------------------------+
| 10 | Unable to Parse Message |
+-------+---------------------------------------------+
| 11 | Use DTLS |
+-------+---------------------------------------------+
| 12 | Unsupported Version |
+-------+---------------------------------------------+
| 13 | Incorrect Message Length |
+-------+---------------------------------------------+
| 14 | Generic Error |
+-------+---------------------------------------------+
Table 5: Error Code meaningNote: The Generic Error error code is intended to be used when an error occurs and the other specific error codes do not apply. ✨
Error Specific Details 🔍: this field is only there for certain error codes. In this document, it only shows up 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 the contents of the ERROR-CODE attribute are 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
The Padding bits MUST 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 🦋
Okay, so here's 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 formatUnknown Type 🧐: these 7-bit fields hold the Types of the attributes (the ones in the message that triggered the Error message) that the receiver didn't know about.
Reserved (R) 🔒: this bit is reserved. It MUST be set to zero by the sender of the message and MUST be ignored by the receiver. ✨
5.2.7. ERROR-INFO 📝
Here's 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 formatText 💬: this field contains UTF-8 encoded text [9].
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 the contents of the ERROR-INFO attribute are 32-bit aligned. The Padding bits MUST 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 🌸
Here's 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 formatText 💬: this field contains UTF-8 encoded text [9].
Padding 🧩: one, two, or three octets of padding added so the contents of the PARTICIPANT-PROVIDED-INFO attribute are 32-bit aligned. The Padding bits MUST 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.9. STATUS-INFO 📣
Here's 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 formatText 💬: this field contains UTF-8 encoded text [9].
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 the contents of the STATUS-INFO attribute are 32-bit aligned. The Padding bits MUST 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 👑
Last one in this batch, and it's a main character 🦋 Here's 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 formatSupp. Attr. 📋: these fields contain the BFCP attribute types that are supported by the floor control server. See Table 2 for the list of BFCP attributes.
Reserved (R) 🔒: This bit MUST be set to zero upon transmission and MUST be ignored upon reception.
Padding 🧩: one, two, or three octets of padding added so the contents of the SUPPORTED-ATTRIBUTES attribute are 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. 💖
5.2.11. SUPPORTED-PRIMITIVES 💜
okay so this one is the SUPPORTED-PRIMITIVES attribute, and it's giving "here's the menu of what I can handle" 🍓 Here's the layout:
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 formatPrimitive: these fields hold the types of the BFCP messages that the floor control server supports. Peek at Table 1 for the full list of BFCP primitives 👀
Padding: one, two, or three octets of padding get tossed in so the SUPPORTED-PRIMITIVES contents land on a 32-bit boundary. If the attribute is already 32-bit aligned, no padding is needed ✨
The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. 🫶
5.2.12. USER-DISPLAY-NAME 🎀
this is the USER-DISPLAY-NAME attribute, aka the name everyone actually sees 🦋
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 formatText: this field holds the UTF-8 encoded name of the user. Serving UTF-8 realness 🌈
Padding: one, two, or three octets of padding get added so the USER-DISPLAY-NAME contents are 32-bit aligned. The Padding bits MUST 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 🌸
now the USER-URI attribute, which is the user's contact URI. It's giving "how do I reach you" 📞
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 formatText: this field holds the UTF-8 encoded user's contact URI, meaning the URI the user taps to set up the resources (like media streams) that BFCP controls. For example, if a conference is set up with SIP, the USER-URI attribute carries the user's SIP URI 📱
Messages that carry a user's URI in a USER-URI attribute also carry the user's User ID. That way, a client that receives one can match up the user's URI (for example, the SIP URI they used to join the conference) with their User ID. iykyk 🔗
Padding: one, two, or three octets of padding get added so the USER-URI contents are 32-bit aligned. The Padding bits MUST 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 👑
BENEFICIARY-INFORMATION is a grouped attribute, which means it's a header followed by a whole sequence of attributes stacked up inside it. The header is called BENEFICIARY-INFORMATION-HEADER, and here's what it looks like:
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 formatBeneficiary ID: this field holds a 16-bit value that uniquely identifies a user within a conference. One user, one ID, no mix-ups 🙈
Here's the ABNF (Augmented Backus-Naur Form) [5] for the BENEFICIARY-INFORMATION grouped attribute. Quick heads up: EXTENSION-ATTRIBUTE is the placeholder for extension attributes that might get defined later 🔮
BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER
[USER-DISPLAY-NAME]
[USER-URI]
*EXTENSION-ATTRIBUTE
Figure 22: BENEFICIARY-INFORMATION format5.2.15. FLOOR-REQUEST-INFORMATION 🦋
FLOOR-REQUEST-INFORMATION is another grouped attribute: a header called FLOOR-REQUEST-INFORMATION-HEADER, then a sequence of attributes. The header looks like this:
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 formatFloor Request ID: this field holds a 16-bit value that identifies a floor request at the floor control server. Every request gets its own little name tag 🏷️
The ABNF of the FLOOR-REQUEST-INFORMATION grouped attribute is below. EXTENSION-ATTRIBUTE, again, stands for 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 format5.2.16. REQUESTED-BY-INFORMATION 🌈
REQUESTED-BY-INFORMATION is a grouped attribute too (you're noticing a pattern, bestie 😭). It has a header called REQUESTED-BY-INFORMATION-HEADER, which looks like this:
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 formatRequested-by ID: this field holds a 16-bit value that uniquely identifies a user within a conference. Same energy as the Beneficiary ID, just for the person asking 🙋
Here's the ABNF of the REQUESTED-BY-INFORMATION grouped attribute. EXTENSION-ATTRIBUTE means the same thing as before: future extension attributes that may be defined 🔮
REQUESTED-BY-INFORMATION = REQUESTED-BY-INFORMATION-HEADER
[USER-DISPLAY-NAME]
[USER-URI]
*EXTENSION-ATTRIBUTE
Figure 26: REQUESTED-BY-INFORMATION format5.2.17. FLOOR-REQUEST-STATUS 💖
FLOOR-REQUEST-STATUS is a grouped attribute with a header called FLOOR-REQUEST-STATUS-HEADER, followed by a sequence of attributes. The header is this:
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 formatFloor ID: this field holds a 16-bit value that uniquely identifies a floor within a conference 🪧
The ABNF of the FLOOR-REQUEST-STATUS grouped attribute is here. EXTENSION-ATTRIBUTE covers 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 format5.2.18. OVERALL-REQUEST-STATUS 🔥
OVERALL-REQUEST-STATUS is one more grouped attribute, with a header called OVERALL-REQUEST-STATUS-HEADER and a sequence of attributes after it. The header is:
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 formatFloor Request ID: this field holds a 16-bit value that identifies a floor request at the floor control server. Yep, the same field name as before, same job 🎀
Here's the ABNF of the OVERALL-REQUEST-STATUS grouped attribute. EXTENSION-ATTRIBUTE, as always, means 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 format5.3. Message Format 📨
This section has the normative ABNF (Augmented Backus-Naur Form) [5] for the BFCP messages. Any extension attributes that may be defined in the future show up as EXTENSION-ATTRIBUTE in the ABNF 🧚
5.3.1. FloorRequest 🙌
Floor participants ask for a floor by sending a FloorRequest message to the floor control server. Here's the format of the FloorRequest message:
FloorRequest = COMMON-HEADER
1*FLOOR-ID
[BENEFICIARY-ID]
[PARTICIPANT-PROVIDED-INFO]
[PRIORITY]
*EXTENSION-ATTRIBUTE
Figure 31: FloorRequest format5.3.2. FloorRelease 🎀
Floor participants release a floor by sending a FloorRelease message to the floor control server 💖 They also use FloorRelease to cancel pending floor requests, so it's kind of a two-for-one 💅 Here's the format:
FloorRelease = COMMON-HEADER
FLOOR-REQUEST-ID
*EXTENSION-ATTRIBUTE
Figure 32: FloorRelease format5.3.3. FloorRequestQuery 🦋
Floor participants and floor chairs can ask about a floor request by sending a FloorRequestQuery message to the floor control server. Bestie, it's basically "hey, what's the tea on this request?" 👀 Here's the format:
FloorRequestQuery = COMMON-HEADER
FLOOR-REQUEST-ID
*EXTENSION-ATTRIBUTE
Figure 33: FloorRequestQuery format5.3.4. FloorRequestStatus 🌸
The floor control server keeps floor participants and floor chairs in the loop about their floor requests by sending them FloorRequestStatus messages 🫶 Format:
FloorRequestStatus = COMMON-HEADER
FLOOR-REQUEST-INFORMATION
*EXTENSION-ATTRIBUTE
Figure 34: FloorRequestStatus format5.3.5. UserQuery 🧚
Floor participants and floor chairs can ask about a participant, plus the floor requests tied to that participant, by sending a UserQuery message to the floor control server. It's giving "tell me everything about this person's requests" energy ✨ Here's the format:
UserQuery = COMMON-HEADER
[BENEFICIARY-ID]
*EXTENSION-ATTRIBUTE
Figure 35: UserQuery format5.3.6. UserStatus 💜
The floor control server spills the info about participants and their related floor requests by sending UserStatus messages to floor participants and floor chairs 🙈 Here's the format:
UserStatus = COMMON-HEADER
[BENEFICIARY-INFORMATION]
*FLOOR-REQUEST-INFORMATION
*EXTENSION-ATTRIBUTE
Figure 36: UserStatus format5.3.7. FloorQuery 🌈
Floor participants and floor chairs can ask about one floor, or several, by sending a FloorQuery message to the floor control server. Format:
FloorQuery = COMMON-HEADER
*FLOOR-ID
*EXTENSION-ATTRIBUTE
Figure 37: FloorQuery format5.3.8. FloorStatus 👑
The floor control server updates floor participants and floor chairs on the status of a floor (for example, who the current holder is) by sending FloorStatus messages. Iconic behavior, honestly 🔥 Format:
FloorStatus = COMMON-HEADER
*FLOOR-ID
*FLOOR-REQUEST-INFORMATION
*EXTENSION-ATTRIBUTE
Figure 38: FloorStatus format5.3.9. ChairAction 🍓
Floor chairs send instructions to floor control servers by sending ChairAction messages. Think of it as the chair being the boss of the room 💅 Format:
ChairAction = COMMON-HEADER
FLOOR-REQUEST-INFORMATION
*EXTENSION-ATTRIBUTE
Figure 39: ChairAction format5.3.10. ChairActionAck ⭐
When a floor control server has accepted a ChairAction message, it confirms that by sending back a ChairActionAck message. Receipt confirmed, no cap ✨ Format:
ChairActionAck = COMMON-HEADER
*EXTENSION-ATTRIBUTE
Figure 40: ChairActionAck format5.3.11. Hello 🌸
Floor participants and floor chairs MAY check whether a floor control server is still alive by sending a Hello message. Also, clients talking to a floor control server over an unreliable transport use Hello to start the conversation with the server 🫶 Format:
Hello = COMMON-HEADER
*EXTENSION-ATTRIBUTE
Figure 41: Hello format5.3.12. HelloAck 🦋
When a floor control server gets a Hello message, it confirms that it's alive by sending a HelloAck message. Format:
HelloAck = COMMON-HEADER
SUPPORTED-PRIMITIVES
SUPPORTED-ATTRIBUTES
*EXTENSION-ATTRIBUTE
Figure 42: HelloAck format5.3.13. Error 💀
Floor control servers let floor participants and floor chairs know about errors while processing requests by sending Error messages. Not the vibe, but it's good to know 😭 Format:
Error = COMMON-HEADER
ERROR-CODE
[ERROR-INFO]
*EXTENSION-ATTRIBUTE
Figure 43: Error format5.3.14. FloorRequestStatusAck 🎀
When communicating over an unreliable transport, floor participants and chairs acknowledge that they got a later FloorRequestStatus message from the floor control server (see Section 13.1.2) by sending a FloorRequestStatusAck message. Acknowledged, bestie ✨ Format:
FloorRequestStatusAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE
Figure 44: FloorRequestStatusAck format5.3.15. FloorStatusAck 💖
When communicating over an unreliable transport, floor participants and chairs acknowledge that they got a later FloorStatus message from the floor control server (see Section 13.5.2) by sending a FloorStatusAck message. Format:
FloorStatusAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE
Figure 45: FloorStatusAck format5.3.16. Goodbye 👋
BFCP entities talking over an unreliable transport that want to dissociate themselves from their remote participant do it by sending a Goodbye. Lowkey the most dramatic exit in the whole protocol 😭 Format:
Goodbye = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE
Figure 46: Goodbye format5.3.17. GoodbyeAck 🌙
BFCP entities talking over an unreliable transport acknowledge that they received a Goodbye message from a peer. Format:
GoodbyeAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE
Figure 47: GoodbyeAck format6. Transport 🚗
The transport BFCP entities use to swap messages depends on the information the clients get for contacting the floor control server, as described in Section 3.2 🗺️ Two transports are supported. TCP is the right pick where connectivity isn't blocked by network elements like NAT devices or media relays. UDP is for deployments where TCP might not be applicable or appropriate ✨
Note: In practice, products are configured to try one transport first and then use the other transport as a fallback. Whether TCP or UDP is chosen as underlying transport depends on the type of product and the deployment environment. See Appendix B for additional considerations.
6.1. Reliable Transport 💎
BFCP entities may choose to exchange BFCP messages using TCP connections. TCP gives you in-order, reliable delivery of a stream of bytes, so message framing has to be handled at the application layer. BFCP does its framing with TLV-encoded attributes 🧩
A client MUST NOT use more than one TCP connection to communicate with a given floor control server within a conference. That said, if the same physical box handles different clients (for example, a floor chair and a floor participant) that 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 it can't parse, the entity MUST close the TCP connection, and the connection SHOULD be reestablished. Similarly, if a TCP connection can't deliver a BFCP message and times out, or it gets an ICMP port unreachable message mid-connection, the TCP connection SHOULD be reestablished 😵💫
How reconnecting works depends on how the client got the info to contact the floor control server. Once the TCP connection is back up, the client MAY resend the messages it didn't get a response to from the floor control server 🔁
If a floor control server notices that the TCP connection to one of the floor participants is lost, it's up to the server's local policy what happens to that participant's pending floor requests. Either way, it is RECOMMENDED that the floor control server keep the floor requests (in other words, that it does not cancel them) while the TCP connection is reestablished 🥹
If a client wants to end its BFCP connection with a floor control server, the client closes the TCP connection towards the floor control server (a graceful close). If a floor control server wants to end its BFCP connection with a client (for example, the focus of the conference tells the floor control server that the client has been kicked out of the conference), the floor control server closes the TCP connection towards the client (also a graceful close) 🚪
When a BFCP entity reestablishes a connection because of protocol errors like the ones described above, the entity SHOULD NOT keep reestablishing the connection over and over. If the same protocol errors keep showing up, the entity MUST stop trying, and it SHOULD report the error to the human user and/or log the event 📝 This doesn't stop the entity from reestablishing a connection when it's facing a different set of errors. Still, entities MUST avoid overloading the server with reestablishment requests, so a connection MUST NOT be reestablished too frequently. How often is up to the implementation, but it SHOULD NOT be attempted more than once in a 30 second period of time ⏱️
6.2. Unreliable Transport 🦋
okay so BFCP entities can totally choose to swap BFCP messages over UDP datagrams 🌸 UDP is the chaotic option where nobody promises delivery OR order, no cap. So each BFCP UDP datagram MUST contain exactly one BFCP message or message fragment 💖 To keep big messages from getting chopped up at the IP layer, BFCP does the fragmenting itself whenever a message is bigger than the path MTU ✨ The fragmentation stuff is covered in Section 6.2.3, bestie. The message format is the same whether it's riding UDP or a TCP stream, which is honestly iconic 💅
Clients MUST announce their presence to the floor control server by sending a Hello message 🧚 The server answers with a HelloAck, and the client only considers the floor control server present and available once it actually gets that HelloAck 🫶 What happens when timers fire, including figuring out that a connection is broken, is in Section 8.3.
As Section 8 explains, every request a floor participant or chair sends forms a client transaction, and it expects an acknowledgement from the floor control server within a transaction failure window 🔥 Same energy in reverse: messages the server starts on its own (like FloorStatus announcements that come from a FloorQuery subscription) need acknowledgements from the floor participant and chair entities they were sent to 👑
If a floor control server gets data it can't parse, the server MUST send an Error message with parameter value 10 (Unable to Parse Message) to say "hey, that was malformed," as long as it's possible to parse the message enough to actually build an Error message 💀
Entities MUST have at most one outstanding request transaction per peer at any one time 🙈 Now, implicit subscriptions happen for a client-initiated request whose acknowledgement is implied by the first server-initiated response for that transaction, followed by zero or more later server-initiated messages for the same transaction 🌈 For example, a FloorRequest can get multiple responses from the floor control server as it moves through intermediate states until it reaches a terminal state (like Granted or Denied) ✨ Each later change in state is a new transaction. The server picks its Transaction ID, and the participant acknowledges receipt with a FloorRequestStatusAck message 💜
By only letting entities have at most one pending transaction open in a BFCP connection, we keep out-of-order messages and congestion in check 🎀 More congestion details are in Section 6.2.1. Now here's the tea: if a participant gets a server-initiated request (like a FloorStatus from the floor control server) while it's still waiting on a response to its own transaction (say it sent a FloorRequest and is waiting for a FloorRequestStatus), the participant MUST treat the server-initiated request as superseding any response to its client-initiated transaction 👀 The floor control server can't send a second update to the implicit floor status subscription until the first one is acknowledged, so ordinality is maintained, which is very much the point 🍓
If a client wants to end its BFCP connection with a floor control server, it is REQUIRED that the client send a Goodbye message so it can let go of any allocated resources 🦋 And if the floor control server wants to end its BFCP connection with a client (like when the focus of the conference tells the server the client got kicked out 😤), it is REQUIRED that the server send a Goodbye message towards the client 💅
6.2.1. Congestion Control 🌊
BFCP counts as "low data-volume" traffic under the classification in [15] 🌸 Even so, we still NEED suitable and necessary congestion control for BFCP over UDP, no exceptions 💖 As Section 6.2 says, within the same BFCP connection, every entity (client or server) is only allowed to send one request at a time and has to wait for the acknowledging response ✨ So at most one datagram goes out per RTT, assuming the message isn't lost in transit 🫶 If it IS lost, the request retransmission timer T1 from Section 8.3.1 fires, and the message gets retransmitted up to three times, on top of the original send 🔥 The default initial interval MUST be set to 500 ms, but it gets adjusted dynamically as described in Section 8.3.1 🧚 The interval MUST be doubled after each retransmission attempt 👑 This is similar to timer A and its initial value T1 in SIP, as described in Section 17.1.1.2 of [20], except that T1 in this protocol isn't fixed from one transaction to another 🎀
6.2.2. ICMP Error Handling 🙈
ICMP is not usable when BFCP runs over an unreliable transport, because of the risks tied to off-path attacks 😭 So any ICMP messages associated with BFCP running over an unreliable transport MUST be ignored 🚫
6.2.3. Fragmentation Handling 🧩
When you're using UDP, a single BFCP message could get fragmented at the IP layer if its total size goes over the path MTU of the network 🌸 To avoid that drama at the IP layer, BFCP has its own fragmentation scheme, defined below 💅
BFCP is built for small messages thanks to its binary encoding (see Section 1), so the fragmentation scheme is deliberately kept simple and straightforward, because fragmentation of BFCP messages is rare 🦋 By design, the scheme doesn't acknowledge individual fragments. The whole BFCP message gets acknowledged once it's received completely ✨
BFCP entities SHOULD consider the path MTU size available between the sender and the receiver, and MAY run MTU discovery, such as the methods in [25], [26], and [27], to figure that out 🔍
When a sender transmits a BFCP message bigger than the path MTU, it MUST fragment the message into a series of N contiguous data ranges 🍰 Each of these N messages MUST be smaller than the path MTU, which helps prevent fragmentation overlap attacks 🛡️ The value for N is ceil((message size -- COMMON-HEADER size) / (path MTU size -- COMMON-HEADER size)), where ceil is the integer ceiling function, and the COMMON-HEADER size includes the Fragment Offset and Fragment Length fields 🧮 The sender then creates N BFCP fragment messages (one per data range) with the same Transaction ID 💜 The size of each of these N messages, COMMON-HEADER included, MUST be smaller than the path MTU 🫧 The F flag in the COMMON-HEADER of all the fragments gets set to show that the BFCP message is fragmented 🚩
For each fragment, the Fragment Offset and Fragment Length fields are included in the COMMON-HEADER 🎀 The Fragment Offset is the number of 4-octet units contained in the previous fragments, excluding the COMMON-HEADER 🌈 The Fragment Length is the length of the fragment itself, also excluding the COMMON-HEADER ✨ Note that the Payload Length field holds the length of the entire, unfragmented message 💖
When a BFCP implementation receives a fragment, it MUST buffer it until either the entire BFCP message has arrived or the Response Retransmission Timer expires 🫙 The state machine should handle the BFCP message only after all of its fragments have been received 🧠
If a fragment is lost, the sender won't get an acknowledgement for the message, so it will retransmit the message with the same Transaction ID, as described in Section 8.3 🔁 If the receiver's acknowledgement gets lost, the sender resends the entire message 📨 The receiver MUST then retransmit the acknowledgement 🙌 The receiver MAY discard an incomplete buffer using the Response Retransmission Timer, starting that timer when the first fragment arrives ⏱️
A Denial of Service (DoS) attack using the fragmentation scheme above is mitigated by the fact that the Response Retransmission Timer starts when the first BFCP message fragment arrives 🚨 On top of that, the Payload Length field can be compared with the Fragment Offset and Fragment Length fields to verify fragments as they show up 🔎 To make DoS attacks with spoofed IP addresses difficult, BFCP entities SHOULD use the cookie exchange mechanism in DTLS [8] 🔐
When deciding the fragment size based on the path MTU, BFCP fragmentation handling should account for how DTLS record framing expands the datagram size, as described in Section 4.1.1.1 of [8] 📏
6.2.4. NAT Traversal 🧭
One of the big wins of using UDP for BFCP is that it can ride on the existing NAT traversal infrastructure and strategies already deployed for the media in video conferencing sessions 🎥 Depending on the deployment, that infrastructure usually includes some subset of Interactive Connectivity Establishment (ICE) [16] 💫
To set up NAT bindings initially, and keep them alive once they exist, BFCP entities using an unreliable transport are RECOMMENDED to use STUN [14] Binding Indication for keepalives, as described for ICE [16] 💗 Section 6.7 of [28] has useful tips for middlebox interaction when DTLS is used 🌷
Note: Since the version number is set to 2 when BFCP is used over an unreliable transport (see the Ver field in Section 5.1), it's easy to tell STUN and BFCP packets apart even without checking the STUN magic cookie [14] 🤓
To get BFCP packets through NATs smoothly, BFCP entities using an unreliable transport are RECOMMENDED to use symmetric ports for sending and receiving BFCP packets, as recommended for RTP/RTP Control Protocol (RTCP) [13] 🦋
7. Lower-Layer Security 🔒
BFCP leans on lower-layer security mechanisms for replay and integrity protection and for confidentiality 🫶 BFCP floor control servers and clients (which include both floor participants and floor chairs) MUST support TLS for transport over TCP [11], and MUST support DTLS [8] for transport over UDP 💜 Any BFCP entity MAY support other security mechanisms 🌈
BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite [7] for backwards compatibility with existing implementations of RFC 4582 🕰️ In accordance with the recommendations and guidelines in [30], BFCP entities SHOULD support the following cipher suites 🔐
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_DHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
8. Protocol Transactions ✨
okay so BFCP has two kinds of transactions 🦋 client-initiated ones and server-initiated ones. 💅
A client-initiated transaction is a request from a client to a floor control server, plus the response the server sends back. 🎀
Server-initiated transactions behave differently depending on what transport is underneath 🌸
- With a reliable transport, a server-initiated transaction is just one message from the floor control server to a client (basically a notification). Nothing comes back, so there's no response. 🫶
- With an unreliable transport, it's a request from the floor control server to a client, and then a response from the client back to the server. 🔁
When BFCP runs over an unreliable transport, retransmission timer T1 (see Section 8.3) MUST be used for all requests until the transaction is completed. ⏱️ T1 can change over time, but it stays the same for the whole life of one transaction and only gets updated once that transaction is done. So it's steady within each transaction, no drama 💜
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 the client got earlier. 🍓
The client MUST set the Transaction ID value in the COMMON-HEADER to a number that is different from 0. That number MUST NOT be reused in another message from the client until the server's response for that transaction arrives. ✨ The client uses it to match its message up with the response from the floor control server, so it's like a little name tag 🏷️
Over an unreliable transport, picking the right Transaction ID is a big deal 😭 It has to let the receiver tell apart a brand new message in a sequence from a retransmission of an older one. That's why BFCP entities using an unreliable transport MUST use monotonically increasing Transaction ID values (except for wrap-around). ⭐
A client that receives a server-initiated transaction over an unreliable transport MUST copy the Transaction ID from the request it got from the server into its response. 🫶
8.2. Server Behavior
When a floor control server sends a response inside a client-initiated transaction, it MUST copy the Conference ID, the Transaction ID, and the User ID from the request it received from the client into that response. 💖
Server-initiated transactions MUST contain a Transaction ID equal to zero when BFCP is used over a reliable transport. Over an unreliable transport, though, the Transaction ID shall have the same properties as it does for client-initiated transactions. 🦋 The server uses that value to match the message with the response from the floor participant or floor chair. 🎀
8.3. Timers
When BFCP entities talk over an unreliable transport, two retransmission timers team up to help cover for datagrams that get lost along the way 🌈 Over a reliable transport, retransmission and response caching are not required. 💅
8.3.1. Request Retransmission Timer, T1
T1 is the timer that schedules retransmission of a request. It keeps going until either a proper response shows up or the maximum number of retransmissions has happened. ⏰
The timer is worked out with the smoothed round-trip time algorithm defined in [2]. It starts with an initial retransmission timeout (RTO) value of 500 ms and a clock granularity (G) of 100 ms. Now here's the twist 🙈 Unlike step 2.4 of Section 2 of [2], if the computed RTO comes out below 500 ms, then RTO shall be set to 500 ms.
T1 MUST be adjusted whenever a response comes back to each request that was sent, so the RTO stays accurate. That adjusted value is the effective T1. 📈 The RTT value R is the time in milliseconds from when a request is transmitted to when the initial response to that request is received. ⏱️
Responses to retransmitted packets MUST NOT be used to recompute the RTO value, because you can't tell whether a response belongs to the original request or to a retransmitted one. 🙅♀️
If T1 keeps expiring on the very first transmission of brand new requests, that's a hint the recommended initial T1 (and RTO) value is too low. In that case it SHOULD be increased by doubling the initial values of T1 (and RTO), and you keep doubling until T1 stops expiring when a new request is sent. 🚀
When a request gets retransmitted, T1 is doubled every time, and the whole thing fails after three unacknowledged retransmission attempts. 💀
If a valid response isn't received for a client- or server-initiated transaction, the implementation MUST consider the BFCP connection as broken. 😱 Implementations SHOULD follow the reestablishment procedure described in Section 6. 🔧
8.3.2. Response Retransmission Timer, T2
T2 is the timer that, once it fires, tells the BFCP entity that it's allowed to let go of its knowledge of the transaction it was running against. 🫧 It starts the first time the response to a request gets transmitted, and it's the only thing that releases that response from the BFCP entity. ✨
Any later retransmissions of the same request can be answered by replaying the cached response. That cached value sticks around until the timer has fired 🧚 For T2's role in the fragmentation handling scheme, refer to Section 6.2.3.
8.3.3. Timer Values
Here's the table with the timers you need when BFCP entities communicate over an unreliable transport 🌸
+=======+======================================+=================+
| Timer | Description | Value/s |
+=======+======================================+=================+
| T1 | Initial request retransmission timer | 0.5 s (initial) |
+-------+--------------------------------------+-----------------+
| T2 | Response retransmission timer | (T1*2^(4))*1.25 |
+-------+--------------------------------------+-----------------+
Table 6: TimersThe initial value for T1 is 500 ms, which is an estimate of the RTT for finishing the transaction. How that value gets computed follows the procedures in Section 8.3.1, including the exponential backoffs on retransmissions. 📊
T2 MUST be set so that it covers all the legal retransmissions per T1, plus a bit of extra room for network latency between BFCP entities, processing delays, and so on. 🫶
9. Authentication and Authorization 🔐
BFCP clients SHOULD authenticate the floor control server before they send any BFCP message to it or accept any BFCP message from it. Floor control servers SHOULD do the same for clients, authenticating a client before they accept any BFCP message from it or send any BFCP message to it. 🤝
If the signaling or control protocol traffic used to set up the conference is authenticated and has confidentiality and integrity protection, and the extensions in this document are supported, then BFCP clients MUST authenticate the floor control server, and floor control servers MUST authenticate the client, before they communicate as described above. 🔒 Heads up though: BFCP entities that only support the [3] subset may not be able to comply with this mandatory authentication requirement. 👀
BFCP supports TLS/DTLS mutual authentication between clients and floor control servers, as specified in Section 9.1. This is the RECOMMENDED authentication mechanism in BFCP. 💜
Future extensions may define additional authentication mechanisms. 🔮
Authenticating messages isn't the whole story, though 💅 Floor control servers also need to authorize them. When an authenticated BFCP message arrives, the floor control server checks whether the client that sent it is authorized. If the client isn't allowed to do the operation it's asking for, the floor control server generates an Error message, as described in Section 13.8, with an error code of 5 (Unauthorized Operation). 🚫 Messages from a client that can't be authorized MUST NOT be processed any further. 🛑
9.1. TLS/DTLS Based Mutual Authentication
BFCP supports TLS/DTLS based mutual authentication between clients and floor control servers. If TLS/DTLS is in use, an initial integrity-protected channel is REQUIRED between the client and the floor control server. That channel is what they use to swap their certificates (which MAY be self-signed certificates) or, more commonly, the fingerprints of those certificates. The certificates are then used when TLS/DTLS gets set up. 🔐
The implementation of such an integrity-protected channel using SIP and the SDP offer/answer model is described in [12].
BFCP messages that come in over an authenticated TLS/DTLS connection count as authenticated. 🎀 A floor control server that gets a BFCP message over TCP/UDP (with no TLS/DTLS) MAY ask for TLS/DTLS to be used. It does that by generating an Error message, as described in Section 13.8, with an error code of 9 (Use TLS) or 11 (Use DTLS), depending on which one it wants. Clients that are configured to require TLS/DTLS MUST ignore unauthenticated messages. 🙅♀️
Future extensions may define additional authentication mechanisms that don't need an initial integrity-protected channel, like authentication based on certificates signed by a certificate authority. 🌈
As described in Section 9, floor control servers need to do authorization before they process any message. Specifically, the floor control server MUST check that messages arriving over a given authenticated TLS/DTLS connection use an authorized User ID. That means a User ID the user who set up that authenticated TLS/DTLS connection is actually allowed to use. 🫶
10. Floor Participant Operations 🎀
This section explains how floor participants can do different things, like requesting a floor, using the protocol elements from the earlier sections. Section 11 covers operations that are specific to floor chairs, like telling the floor control server to grant or revoke a floor. Section 12 covers operations any client can do, meaning both floor participants and floor chairs. 👑
10.1. Requesting a Floor
A floor participant who wants one or more floors does that by sending a FloorRequest message to the floor control server. 🙋♀️✨
10.1.1. Sending a FloorRequest Message ✨
okay so the ABNF in Section 5.3.1 is the official list of every attribute a FloorRequest message can carry 📜 It also spells out which attributes are mandatory and which are optional, so that's the bible 💅
The floor participant fills in the Conference ID and the Transaction ID in the COMMON-HEADER by following the rules in Section 8.1 🎀
The floor participant sets the User ID in the COMMON-HEADER to their own identifier 🫶 If the sender of the FloorRequest (the one named by the User ID) isn't the participant who'd actually end up with the floor, aka a third-party floor request 👀, the sender SHOULD add a BENEFICIARY-ID attribute saying who the beneficiary of the floor is 💖
Note that the namespace for both the User ID and the Beneficiary ID is the same ✨ So one participant gets one 16-bit value, and that same value can show up as the User ID in theCOMMON-HEADERand in a bunch of attributes:BENEFICIARY-ID,BENEFICIARY-INFORMATION, andREQUESTED-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 means it will either grant or deny all the floors in that message. No splitting, no drama 💀
The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute to say why the floor or floors are being requested 🙈 The Text field in that attribute is meant for humans to read.
The floor participant may ask the server to 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 counts as a response to the FloorRequest message if it has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1 🔍 Once it lands, the floor participant follows the rules in Section 9 about floor control server authentication 🔐
Successfully processing a FloorRequest message at the floor control server involves generating one or several FloorRequestStatus messages ✨ The floor participant gets a Floor Request ID from the Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in the first FloorRequestStatus message from the server. Later FloorRequestStatus messages about the same floor request carry that same Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute, just like the first one did. That's how the participant knows which ongoing floor request each new message belongs to 🧩
The floor participant learns the status of the floor request from the FLOOR-REQUEST-INFORMATION attribute in each FloorRequestStatus message it receives 📊 It's a grouped attribute, so it holds a bunch of other attributes that tell you about the request.
The OVERALL-REQUEST-STATUS attribute gives 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 it's Denied, all of them have been denied 😤 A floor request is considered ongoing while it's in the Pending, Accepted, or Granted states. If the floor request value is unknown, the response still gets processed, but no meaningful value can be reported to the user 🤷♀️
The STATUS-INFO attribute, if present, carries extra info the floor participant can show the user 💬
The FLOOR-REQUEST-STATUS attributes tell you the status of the floor request as it relates to one particular floor 🌸 The STATUS-INFO attribute, if present, gives extra info the floor participant can display to the user.
The BENEFICIARY-INFORMATION attribute identifies the beneficiary in third-party floor requests 👑 The REQUESTED-BY-INFORMATION attribute doesn't need to be in FloorRequestStatus messages received by the floor participant who requested the floor, since that 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 🚀
If the response is an Error message, the floor control server couldn't process the FloorRequest message for some reason, and the Error message describes it 🚨
10.1.3. Reception of a Subsequent FloorRequestStatus Message 🔁
When you're communicating over an unreliable transport and you get a FloorRequestStatus message from a floor control server 🛰️ the participant MUST respond with a FloorRequestStatusAck message within the transaction failure window to complete the transaction 💅
10.2. Cancelling a Floor Request and Releasing a Floor 🦋
A floor participant that wants to cancel an ongoing floor request does it by sending a FloorRelease message to the floor control server 🙅♀️ The FloorRelease message is also what floor participants use when they 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 a FloorRelease message can contain 📖 It also specifies normatively which of those attributes are mandatory and which are optional.
The floor participant sets the Conference ID and the Transaction ID in the COMMON-HEADER following the rules in Section 8.1 🎀 and sets the User ID in the COMMON-HEADER to their own identifier.
Note that theFloorReleasemessage 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 happens when theFloorReleasemessage and theFloorGrantmessage 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 (in a single FloorRequest message), all the floors are released as an atomic operation too (so they all go at the same time) 🫧
10.2.2. Receiving a Response 📨
A message from the floor control server counts as a response to the FloorRelease message if it has the same Conference ID, Transaction ID, and User ID as the FloorRelease message, as described in Section 8.1 🔎 Once it arrives, the floor participant follows the rules in Section 9 that relate to floor control server authentication 🔐
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, and the Error message describes it 🚨
It's possible that the FloorRelease message crosses on the wire with a FloorRequestStatus message from the server whose Request Status is different from Cancelled or Released 🫣 Either way, that FloorRequestStatus message won't be a response to the FloorRelease message, because its Transaction ID won't match the FloorRelease message's Transaction ID 🙅♀️
11. Chair Operations 🪑👑
This section spells out how floor chairs can instruct the floor control server to grant or revoke a floor, using the protocol elements we covered in earlier sections 🎀
Floor chairs who want to send instructions to a floor control server do it by sending a ChairAction message 💌
11.1. Sending a ChairAction Message
Okay bestie, the ABNF in Section 5.3.9 is where you find every attribute a ChairAction message can carry 📜✨ and it also tells you which ones are mandatory and which 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 chair's identifier 🫶
A ChairAction message carries instructions for one or more floors inside a particular floor request 🦋 The floors are named by the FLOOR-REQUEST-STATUS attributes, and the floor request itself is named by the FLOOR-REQUEST-INFORMATION-HEADER. Both get tucked into the ChairAction message 🌸
Here's the vibe: say a floor request has two floors and each depends on a different floor chair. Each chair grants its own floor inside that request 👑 Once both have said yes, the floor control server grants the whole request ✨ But if one chair denies its floor, the server denies the entire request, no matter what the other chair decided 😭 Iconic drama 💀
The floor chair gives the new status of the request for a particular floor using a FLOOR-REQUEST-STATUS attribute 💖 If the new status is Accepted, the floor chair MAY use the Queue Position field to hand out a queue position for the request 🍓 If the floor chair doesn't want to give a queue position, all the bits of the Queue Position field MUST be set to zero 🙈 The floor chair MUST use the Status Revoked to revoke a floor that was granted (that is, Granted status) 🔥 and MUST use the Status Denied to reject floor requests in any other status (for example, Pending and Accepted) 💅
The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the ChairAction message to give a new overall status for the floor request 🌈 If that new overall status is Accepted, the floor chair can use the Queue Position field to give a queue position for the request ⭐
📝 Note, bestie: a floor control server can run a different queue for each floor, one general queue for every floor request, or both 🧚 A floor request can involve several floors, and a ChairAction message only handles a subset of them (for example, when one floor chair isn't allowed to manage every floor) 🦋 In that case the floor control server combines the instructions from the different floor chairs in the FLOOR-REQUEST-STATUS attributes to work out the overall status of the request 💜 Also, even though the floor chair's action can share info in the OVERALL-REQUEST-STATUS attribute, the floor control server MAY override, modify, or ignore that field's content 🙅♀️💀
The floor chair MAY include STATUS-INFO attributes to explain why the floor or floors are being accepted, granted, or revoked 🌸 The Text in the STATUS-INFO attribute is meant for humans to read 🫶
11.2. Receiving a Response
A message from the floor control server counts as a response to the ChairAction message if it has the same Conference ID, Transaction ID, and User ID as the ChairAction message, as described in Section 8.1 🎀 When that response arrives, the floor chair follows the rules in Section 9 that cover floor control server authentication 🔐✨
A ChairActionAck message from the floor control server confirms that the server accepted the ChairAction message 💖 An Error message means the server couldn't process the ChairAction message for some reason, and the reason is spelled out inside the Error message 😭
- General Client Operations
This section covers operations any client can do 🌈 They aren't specific to floor participants or floor chairs, so both can do them 💅
12.1. Requesting Information about Floors
A client can grab info about the status of a floor or floors in a few ways, including using BFCP and using out-of-band mechanisms 🦋 Clients that use BFCP for this follow the procedures in this section 🎀
Clients ask 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 lists the attributes a FloorQuery message can contain 📜 It also spells out normatively which attributes are mandatory and which are optional 💅
The client sets the Conference ID and the Transaction ID in the COMMON-HEADER following the rules in Section 8.1 🌸 The client sets the User ID in the COMMON-HEADER to the client's identifier 🫶
The client puts in every Floor ID it wants info about 💖 The floor control server then sends periodic info about all of those floors ✨ If the client stops wanting info about a particular floor, it sends a new FloorQuery message that removes that floor's FLOOR-ID 🙅♀️ If the client wants no info about any floor anymore, it sends a FloorQuery message with no FLOOR-ID attribute at all 😭
12.1.2. Receiving a Response
A message from the floor control server counts as a response to the FloorQuery message if it has the same Conference ID, Transaction ID, and User ID as the FloorQuery message, as described in Section 8.1 🎀 On getting that response, the client follows the rules in Section 9 that cover floor control server authentication 🔐
When the floor control server receives a FloorQuery message, it MUST respond with a FloorStatus message or with an Error message 💅 If the response is a FloorStatus message, it contains info about one of the floors the client asked about 🦋 If the client didn't include any FLOOR-ID attribute in its FloorQuery message (so it doesn't want info about any floor anymore), the FloorStatus message from the floor control server won't include any FLOOR-ID attribute either 🌈
FloorStatus messages that carry info about a floor include a FLOOR-ID attribute that identifies the floor 🧚 After that attribute, the FloorStatus message has info about existing floor requests (one or more) for that floor 💜 The info about each 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 giving info about the floor request ⭐
After the first FloorStatus, the floor control server keeps sending FloorStatus messages, periodically telling the client about changes to the floors it asked about 🔥👑
12.1.3. Reception of a Subsequent FloorStatus Message
When communicating over an unreliable transport, and upon receiving a FloorStatus message from a floor control server, the participant MUST respond with a FloorStatusAck message within the transaction failure window to complete the transaction 🫶💖
12.2. Requesting Information about Floor Requests
A client can grab info about the status of one or several floor requests in a few ways, including using BFCP and using out-of-band mechanisms 🌸 Clients that use BFCP for this follow the procedures in this section 💅
Clients ask about the current status of a floor request by sending a FloorRequestQuery message to the floor control server ✨
Asking about a particular floor request is super useful in a bunch of situations 🦋 For example, when a floor control server gets a FloorRequest message, it may choose to return FloorRequestStatus messages only when the floor request changes state (say, from Accepted to Granted), and not when the request moves up in its queue 🎀 In that case, if the user asks for it, the floor participant can send a FloorRequestQuery message to poll the floor control server for the status of the floor request 🧚
12.2.1. Sending a FloorRequestQuery Message
The ABNF in Section 5.3.3 lists the attributes a FloorRequestQuery message can contain 📜 It also spells out normatively which attributes are mandatory and which are optional 💅
The client sets the Conference ID and the Transaction ID in the COMMON-HEADER following the rules in Section 8.1 🌸 The client sets the User ID in the COMMON-HEADER to the client's identifier 🫶
The client MUST insert a FLOOR-REQUEST-ID attribute that identifies the floor request at the floor control server 🔥
12.2.2. Receiving a Response
A message from the floor control server counts as a response to the FloorRequestQuery message if it has the same Conference ID, Transaction ID, and User ID as the FloorRequestQuery message, as described in Section 8.1 🎀 When that response arrives, the client follows the rules in Section 9 that cover floor control server authentication 🔐✨
If the response is a FloorRequestStatus message, the client gets info about the status of the FloorRequest it asked about, carried in a FLOOR-REQUEST-INFORMATION attribute 💖
If the response is an Error message, the floor control server couldn't process the FloorRequestQuery message for some reason, and the Error message explains what that reason is 😭
12.3. Requesting Information about a User
A client can grab info about a participant and the floor requests tied to that participant in a few ways, including using BFCP and using out-of-band mechanisms 🦋 Clients that use BFCP for this follow the procedures in this section 🌈
Clients ask for info about a participant and the floor requests related to them by sending a UserQuery message to the floor control server 🧚
This is useful for floor chairs or floor participants who want the display name and URI of a particular floor participant 💅 A floor participant can also find it handy to ask about itself 🫶 For example, say a floor participant loses connectivity (its TCP connection with the floor control server was down for a while and then came back). It may need to ask about all the floor requests tied to itself that still exist 😭💜
12.3.1. Sending a UserQuery Message 💌
okay so the ABNF in Section 5.3.5 is where you find every attribute a UserQuery message can carry 📜. It also spells out (normatively, bestie 🫶) which attributes are mandatory and which are optional.
the client sets the Conference ID and the Transaction ID in the COMMON-HEADER following the rules in Section 8.1 🦋. Then it sets the User ID in the COMMON-HEADER to the client's own identifier 💖.
if the floor participant the client is asking about is not the client sending the UserQuery (the one identified by the User ID in the COMMON-HEADER), the client MUST insert a BENEFICIARY-ID attribute 🙈.
12.3.2. Receiving a Response 📩
a message from the floor control server counts as a response to the UserQuery if it has the same Conference ID, Transaction ID, and User ID as the UserQuery, as described in Section 8.1 🔥. once you get one of those, the client follows the rules in Section 9 that relate to floor control server authentication 🔐.
if the response is a UserStatus message, the client finds info about the floor participant in a BENEFICIARY-INFORMATION grouped attribute. It also finds the status of that participant's floor requests in FLOOR-REQUEST-INFORMATION attributes 👑.
if the response is an Error message, the floor control server couldn't process the UserQuery for some reason. The reason is spelled out in the Error message 💀.
12.4. Obtaining the Capabilities of a Floor Control Server 🧚
a client that wants to know what a floor control server can do sends it a Hello message 🌈.
12.4.1. Sending a Hello Message 🎀
the ABNF in Section 5.3.11 describes the attributes a Hello message can contain. It also says (normatively, obviously 💅) which ones are mandatory and which are optional 🌸.
the client sets the Conference ID and the Transaction ID in the COMMON-HEADER following the rules in Section 8.1 ✨. It sets the User ID in the COMMON-HEADER to the client's identifier 🍓.
12.4.2. Receiving Responses 📬
a message from the floor control server counts as a response to the Hello message if it has the same Conference ID, Transaction ID, and User ID as the Hello message, as described in Section 8.1 💜. When that happens, the client follows the rules in Section 9 that relate to floor control server authentication 🔐.
if the response is a HelloAck message, the floor control server could process the Hello successfully 🎉. The SUPPORTED-PRIMITIVES and SUPPORTED-ATTRIBUTES attributes tell you which primitives and which attributes, respectively, the server supports 🧠.
if the response is an Error message, the floor control server couldn't process the Hello for some reason. That reason is described in the Error message 🫠.
13. Floor Control Server Operations 👑
this section is all about how floor control servers run their operations (like granting a floor) using the protocol elements from earlier sections 💅.
on reception of a message from a client, the floor control server MUST check whether the value of the primitive is supported. If it isn't, the floor control server MUST send an Error message, as described in Section 13.8, with Error Code 3 (Unknown Primitive) 🚫.
on reception of a message from a client, the floor control server MUST check whether the value of the Conference ID matched an existing conference. If it didn't, the floor control server MUST send an Error message, as described in Section 13.8, with Error Code 1 (Conference Does Not Exist) 🫥.
on reception of a message from a client, the floor control server follows the rules in Section 9 that relate to the authentication of the message 🔒.
on reception of a message from a client, the floor control server MUST check whether it understands all the mandatory ('M' bit set) attributes in the message. If it doesn't understand all of them, the floor control server MUST send an Error message, as described in Section 13.8, with Error Code 4 (Unknown Mandatory Attribute) 😤. The Error message SHOULD list the attributes that weren't understood 📝.
13.1. Reception of a FloorRequest Message 🙋
on reception of a FloorRequest message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization 🛡️. If it runs into an error while processing the FloorRequest message, it MUST generate an Error response following the procedures in Section 13.8 🚨.
okay bestie, quick side quest 🧵: BFCP lets floor participants have several ongoing floor requests for the same floor. (Like, the same participant can hold more than one spot in a queue at the same time.) A floor control server that only supports a certain number of ongoing floor requests per participant (e.g., one) can use Error Code 8 (You have Already Reached the Maximum Number of Ongoing Floor Requests for This Floor) to let the participant know 💅.
when communicating over an unreliable transport, and upon receiving a FloorRequest from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction ⏳.
13.1.1. Generating the First FloorRequestStatus Message 🦋
successfully processing a FloorRequest message means the server generates one or several FloorRequestStatus messages. The first of those SHOULD be generated as soon as possible ⚡. If the floor control server can't accept, grant, or deny the request right away (e.g., a decision from a chair is needed), it SHOULD use a Request Status value of Pending in the OVERALL-REQUEST-STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message it generates 🕰️.
the policy a floor control server follows to grant or deny floors is outside the scope of this document 📚. One server might decide everything automatically, while another might check with a human chair every single time it needs a decision 🧑⚖️.
the floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequest into the FloorRequestStatus, as described in Section 8.2 💌. On top of that, it MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes inside this grouped attribute carry info about the floor request 🎀.
the floor control server MUST assign an identifier to this floor request that is unique within the conference, and it MUST insert that identifier in the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute 🔑. The floor participant (or a chair or chairs) uses this identifier to refer to this specific floor request later on 🫶.
the floor control server MUST copy the Floor IDs in the FLOOR-ID attributes of the FloorRequest into the FLOOR-REQUEST-STATUS attributes in the FLOOR-REQUEST-INFORMATION grouped attribute 🌸. These Floor IDs identify the floors being requested, meaning the floors associated with this particular floor request 💜.
the floor control server SHOULD copy (if present) the contents of the BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute 🍓. On top of that, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute 🌈.
the floor control server MAY provide info about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute 🧾.
the floor control server MAY copy (if present) the PRIORITY attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute 🏅.
this attribute carries the priority the participant requested 💁♀️. The priority the floor control server assigns to the floor request depends on both the priority requested by the participant and the rights the participant has under the conference policy. For example, a participant who's only allowed to use theNormalpriority may requestHighestpriority. In that case, the floor control server would ignore the priority the participant requested 😭.
the floor control server MAY copy (if present) the PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute 🌟.
13.1.2. Generation of Subsequent FloorRequestStatus Messages 💅
okay so a floor request is considered ongoing for as long as it is not in the Cancelled, Released, or Revoked states 🦋. If the OVERALL-REQUEST-STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the very first FloorRequestStatus message the floor control server generated didn't show any of those states, then the floor control server is gonna need to send more FloorRequestStatus messages after that 🧚.
When the status of the floor request changes, the floor control server SHOULD send new FloorRequestStatus messages with the appropriate Request Status ✨. The floor control server MUST add a FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to the one sent in the first FloorRequestStatus message to any new FloorRequestStatus that's related to the same floor request. (The Floor Request ID is how you know which floor request that FloorRequestStatus is about 🎀.)
When using BFCP over a reliable transport, the floor control server MUST set the Transaction ID of subsequent FloorRequestStatus messages to zero. When using BFCP over an unreliable transport, the Transaction ID MUST be non-zero and unique in the context of outstanding transactions over an unreliable transport, as described in Section 8 🔥.
The rate at which the floor control server sends FloorRequestStatus messages is a matter of local policy 🙈. One server might send a new message every time the floor request moves in the floor request queue, while another might only send a new message when the floor request is Granted or Denied.
The floor control server may add a STATUS-INFO attribute to any of the FloorRequestStatus messages it generates, so it can give extra info about its decisions on the floor request (like why it was denied) 💖.
Floor participants and floor chairs may request to be informed about the status of a floor by following the procedures in Section 12.1 🫶. If processing a floor request changes the status of a floor (for example, the floor request is granted and the floor now has a new holder), the floor control server needs to follow the procedures in Section 13.5 to inform the clients that asked for that information 👑.
The COMMON-HEADER and the rest of the attributes are the same as in the first FloorRequestStatus message 🌸.
The floor control server can discard the state information about a particular floor request once it reaches a status of Cancelled, Released, or Revoked 🧹.
When communicating over an unreliable transport and a FloorRequestStatusAck message is not received within the transaction failure window, the floor control server MUST retransmit the FloorRequestStatus message according to Section 6.2 😭🔁.
13.2. Reception of a FloorRequestQuery Message 🍓
On reception of a FloorRequestQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization 🔐. If the floor control server runs into an error while processing the FloorRequestQuery message, it MUST generate an Error response following the procedures described in Section 13.8 🚨.
Successfully processing a FloorRequestQuery message means generating a FloorRequestStatus message, which SHOULD be generated as soon as possible ⚡.
When communicating over an unreliable transport and upon receiving a FloorRequestQuery from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction 💌.
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequestQuery message into the FloorRequestStatus message, as described in Section 8.2 📋. On top of that, the floor control server MUST include information about the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute of the FloorRequestStatus 🧠.
The floor control server MUST copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute 🪪.
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute, identifying the floors being requested (that is, the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute) 🗺️.
The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute, identifying the beneficiary of the floor request 🎀. Extra bonus: the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute ✨.
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute 🙋.
The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO 💬.
The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request, and a STATUS-INFO attribute with extra information about the floor request 🌈.
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request 📍. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes 💅.
13.3. Reception of a UserQuery Message 🧚♀️
On reception of a UserQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization 🔐. If the floor control server runs into an error while processing the UserQuery message, it MUST generate an Error response following the procedures described in Section 13.8 🚨.
Successfully processing a UserQuery message means generating a UserStatus message, which SHOULD be generated as soon as possible 💨.
When communicating over an unreliable transport and upon receiving a UserQuery from a participant, the floor control server MUST respond with a UserStatus message within the transaction failure window to complete the transaction 🫶.
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the UserQuery message into the UserStatus message, as described in Section 8.2 📋.
The sender of the UserQuery message is asking for info about all the floor requests associated with a given participant (that is, the floor requests where that participant is either the beneficiary or the requester) 👀. That participant is identified by a BENEFICIARY-ID attribute or, if there isn't one, by the User ID in the COMMON-HEADER of the UserQuery message 🪪.
The floor control server MUST copy, if present, the contents of the BENEFICIARY-ID attribute from the UserQuery message into a BENEFICIARY-INFORMATION attribute in the UserStatus message. Extra bonus: the floor control server MAY provide the display name and the URI of the participant that the UserStatus message is about in this BENEFICIARY-INFORMATION attribute 🌸.
The floor control server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute to the UserStatus message for each floor request related to the participant (that is, the floor requests where the participant is either the beneficiary or the requester) 🍓. For each FLOOR-REQUEST-INFORMATION attribute, the floor control server follows these steps 🧁:
The floor control server MUST identify the floor request that the FLOOR-REQUEST-INFORMATION attribute applies to by filling in the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute 🏷️.
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute, identifying the floors being requested (that is, the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute) 🗺️.
The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute, identifying the beneficiary of the floor request 🎀. The floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute ✨.
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute 🙋.
The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO 💬.
The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request 🔥.
The floor control server MUST include the current status of the floor request in an OVERALL-REQUEST-STATUS attribute added to the FLOOR-REQUEST-INFORMATION grouped attribute 📍. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request 💅.
The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes 🌈.
13.4. Reception of a FloorRelease Message 🎀
okay so when a FloorRelease message lands, the floor control server checks the client's identity and permissions using the rules in Section 9 🔐. if anything goes wrong while it's processing, it MUST send back an Error response following the procedures in Section 13.8 🚨.
a successful FloorRelease means the server builds a FloorRequestStatus message, and it SHOULD do that as soon as possible ⚡.
if you're on an unreliable transport and a participant sends a FloorRelease, the floor control server MUST reply with a FloorRequestStatus message inside the transaction failure window to finish the transaction 🔁.
the server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRelease into the FloorRequestStatus, as described in Section 8.2 🫶.
the server MUST also add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. the attributes inside that grouped attribute carry the info about the floor request 💜.
the FloorRelease points at its floor request with a FLOOR-REQUEST-ID. the server MUST copy whatever is in that FLOOR-REQUEST-ID attribute into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute 🦋.
the server MUST list the floors being released in FLOOR-REQUEST-STATUS attributes inside the FLOOR-REQUEST-INFORMATION grouped attribute. these are the floors tied to the floor request named in the FLOOR-REQUEST-ID attribute 🌸.
the server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute too. the Request Status value SHOULD be Released if the floor (or floors) had already been granted, or Cancelled if they hadn't been granted yet 💅. the server MAY also add a STATUS-INFO attribute with extra info about the floor request ✨.
13.5. Reception of a FloorQuery Message 🧚
when a FloorQuery shows up, the floor control server checks client authentication using the rules in Section 9 👀. if it hits an error while processing, it MUST generate an Error response following the procedures in Section 13.8 🙅♀️.
over an unreliable transport, when a participant sends a FloorQuery, the floor control server MUST answer with a FloorStatus message inside the transaction failure window to complete the transaction ⏱️.
a floor control server that gets a FloorQuery from a client SHOULD keep that client updated on the floors named in the FLOOR-ID attributes of the FloorQuery 📣. it does this by sending FloorStatus messages 💌.
each FloorStatus message is about one floor only 🍓. so if a FloorQuery asks about more than one floor, the server has to send a separate FloorStatus for each floor 🌈.
what the FloorQuery returns can depend on who's asking 👑. for example, a chair might be allowed to see pending requests, while a regular user might not be authorized to see them 🙈.
13.5.1. Generation of the First FloorStatus Message 💖
a successful FloorQuery means the server creates one or more FloorStatus messages, and the first one SHOULD go out as soon as possible 🚀.
the server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorQuery into the FloorStatus, as described in Section 8.2 🫶.
if the FloorQuery didn't have any FLOOR-ID attribute, the server sends the FloorStatus without adding any extra attribute. it does not send any later FloorStatus messages to the floor participant 🤷♀️.
if the FloorQuery did have one or more FLOOR-ID attributes, the server picks one of them and adds that FLOOR-ID attribute to the FloorStatus 🎯. the server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request tied to that floor 🗂️. each one holds a bunch of attributes describing the floor request. for every FLOOR-REQUEST-INFORMATION attribute, the server follows the steps below 📝.
the server MUST identify which floor request a FLOOR-REQUEST-INFORMATION attribute is about by filling in the Floor Request ID field of that attribute 🔖.
the server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute, naming the floors being requested. these are the floors tied to the floor request identified by the FLOOR-REQUEST-ID attribute 💜.
the server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute, identifying who the beneficiary of the floor request is 🎀. it MAY also put the beneficiary's display name and URI in this BENEFICIARY-INFORMATION attribute 🦋.
the server MAY share info about who requested the floor, inside a REQUESTED-BY-INFORMATION attribute in the FLOOR-REQUEST-INFORMATION grouped attribute 👀.
the server MAY share the reason the floor participant gave for requesting the floor, using PARTICIPANT-PROVIDED-INFO 💬.
the server MAY also add a PRIORITY attribute to the FLOOR-REQUEST-INFORMATION grouped attribute, with the Priority value that was requested for the floor request ⭐.
the server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute, with the floor request's current status 📊. it MAY add a STATUS-INFO attribute with extra info about the floor request 🌸.
the server MAY also share the status of the floor request for each floor it's asking about, using the FLOOR-REQUEST-STATUS attributes 🧁.
13.5.2. Generation of Subsequent FloorStatus Messages 🌷
if the FloorQuery carried more than one FLOOR-ID attribute, the server SHOULD generate a FloorStatus for each of them as soon as possible. the only one skipped is the FLOOR-ID that was used for the first FloorStatus 🏃♀️. these follow the same rules as the first FloorStatus (see Section 13.5.1) 📋. their Transaction ID is 0 on a reliable transport, and non-zero and unique among outstanding transactions on an unreliable one (cf. Section 8) 🔢.
after those are generated, the server keeps sending FloorStatus messages from time to time so the client stays updated on every floor it asked about 🔄. the Transaction ID of these messages MUST be 0 on a reliable transport, and non-zero and unique among outstanding transactions on an unreliable one (cf. Section 8) 💫.
The rate at which the floor control server sends FloorStatus messages is a matter of local policy. One server might send a new FloorStatus every time a new floor request comes in, while another might only send one when a new floor request is Granted. 🌈
when you're on an unreliable transport and no FloorStatusAck arrives inside the transaction failure window, the floor control server MUST retransmit the FloorStatus message according to Section 6.2 🔁.
13.6. Reception of a ChairAction Message 👑
when a ChairAction message comes in, the floor control server checks client authentication and authorization using the rules in Section 9 🔐. if it hits an error while processing, it MUST generate an Error response following the procedures in Section 13.8 🙅♀️.
a successful ChairAction means the server generates a ChairActionAck message, and it SHOULD do that as soon as possible ⚡.
over an unreliable transport, when a ChairAction arrives from a chair, the floor control server MUST respond with a ChairActionAck message inside the transaction failure window to complete the transaction ⏱️.
the server MUST copy the Conference ID, the Transaction ID, and the User ID from the ChairAction into the ChairActionAck, as described in Section 8.2 🫶.
the server has to think about the operation the ChairAction asks for (like granting a floor) 🧠. but it doesn't have to do exactly what the floor chair asked 🙃. what it actually does depends on the ChairAction and on its own internal state 💅.
for example, a floor chair might send a ChairAction granting a floor that was requested as part of an atomic floor request involving several floors 🧩. even if the chair in charge of one floor tells the server to grant it, the server won't grant it until the chairs for the other floors agree to grant theirs too 🤝.
so the floor control server is ultimately responsible for keeping a coherent floor state 🎀. the instructions from floor chairs are just input to that state 💖.
if the new Status in the ChairAction is Accepted and every bit of the Queue Position field is zero, the floor chair is asking the server to assign a queue position (e.g., the last in the queue) to the floor request, based on the server's local policy 🎫. (of course, that request only applies if the floor control server actually implements a queue 🙈.)
13.7. Reception of a Hello Message 👋
okay so when a Hello shows up, the floor control server runs it through the client-authentication rules from Section 9 🔐. If anything goes wrong while it's handling that Hello, it MUST generate an Error response, following the steps in Section 13.8. no skipping this 💅
If the BFCP version in the version field of the COMMON-HEADER is supported by the floor control server, it MUST reply with that same version number in the HelloAck. This sets the version for every later BFCP message in this BFCP Connection, so it's a big deal 🎀
When you're on an unreliable transport and a participant sends a Hello, the floor control server MUST send a HelloAck inside the transaction failure window to finish the transaction ⏰
Processing a Hello successfully means generating a HelloAck, and that SHOULD happen as soon as possible 🏃♀️ The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the Hello into the HelloAck, as described in Section 8.2 💌
The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to the HelloAck. This lists every primitive (aka every BFCP message) the server supports 📜
The floor control server MUST also add a SUPPORTED-ATTRIBUTES attribute to the HelloAck, listing every attribute the server supports 🧾
13.8. Error Message Generation 🚨
Error messages are always sent in response to an earlier client message, as part of a client-initiated transaction. The ABNF in Section 5.3.13 lays out which attributes an Error message can contain. The ABNF also says, normatively, which of those attributes are mandatory and which are optional 🧐
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the client's message into the Error message, as described in Section 8.2 🫶
The floor control server MUST add an ERROR-CODE attribute to the Error message. That attribute holds an error code from Table 5 ❌ On top of that, the floor control server may add an ERROR-INFO attribute with extra info about the error 🔍
14. Security Considerations 🛡️
okay this section is SERIOUS bestie 😭 BFCP uses TLS/DTLS to give clients and servers mutual authentication. TLS/DTLS also brings replay protection, integrity protection, and confidentiality. It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. When signaling and control traffic is properly protected, as described in Section 9, it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms to interwork with legacy implementations that do not use TLS/DTLS, as long as those mechanisms give similar security properties. One example of another mechanism that can effectively secure a nonsecure BFCP connection is IPsec [21] 🔐
The rest of this section goes through some of the threats to BFCP and how they get handled 👀
An attacker might try to impersonate a client (a floor participant or a floor chair) so they can send forged floor requests or grant or deny existing ones. 🚫 Client impersonation gets blocked when servers only accept BFCP messages over authenticated TLS/DTLS connections. The floor control server assumes attackers can't hijack the TLS/DTLS connection, so messages on it come from the client who was originally authenticated 🧑💻
An attacker might also try to impersonate a floor control server. If they pulled that off, they could make clients think they hold a particular floor. Then the clients might try to access a resource (like sending media) without any legit rights to it 😱 Server impersonation gets blocked when servers only accept BFCP messages over authenticated TLS/DTLS connections, and clients only send and accept messages over authenticated TLS/DTLS connections as well 🛑
Attackers might try to modify messages exchanged between a client and a floor control server. The integrity protection from TLS/DTLS connections stops this 🧱
An attacker might try to grab a valid message a client sent to a floor control server and replay it over a connection between the attacker and the server. This gets prevented when floor control servers check that messages arriving over a given authenticated TLS/DTLS connection use an authorized user ID. That means a user ID the user who set up the authenticated connection is actually allowed to use ✅
Attackers might also try to snoop on messages between the floor control server and a client to get confidential info, like why a floor request got denied 🕵️♀️ TLS/DTLS confidentiality stops this. So it is REQUIRED that TLS/DTLS be used with an encryption algorithm according to Section 7 💜
15. IANA Considerations 📋
The IANA has created a registry for BFCP parameters called "The Binary Floor Control Protocol (BFCP) Parameters" 🗂️ This registry has a bunch of subregistries, and they're each described in the sections that follow 💖
15.1. Attributes Subregistry 🏷️
This section sets up the "Attributes" subregistry under the BFCP Parameters registry. As per the terminology in RFC 8126 [6], the registration policy for BFCP attributes is "Specification Required". For this subregistry, any BFCP attribute that's up for IANA registration MUST be defined by a Standards Track RFC. Such an RFC MUST specify the attribute's type, name, format, and semantics 🧠
For each BFCP attribute, IANA registers its type, its name, and the reference to the RFC where the attribute is defined. Here are the initial values for this subregistry 👇
+======+===========================+===========+
| Type | Attribute | Reference |
+======+===========================+===========+
| 1 | BENEFICIARY-ID | RFC 8855 |
+------+---------------------------+-----------+
| 2 | FLOOR-ID | RFC 8855 |
+------+---------------------------+-----------+
| 3 | FLOOR-REQUEST-ID | RFC 8855 |
+------+---------------------------+-----------+
| 4 | PRIORITY | RFC 8855 |
+------+---------------------------+-----------+
| 5 | REQUEST-STATUS | RFC 8855 |
+------+---------------------------+-----------+
| 6 | ERROR-CODE | RFC 8855 |
+------+---------------------------+-----------+
| 7 | ERROR-INFO | RFC 8855 |
+------+---------------------------+-----------+
| 8 | PARTICIPANT-PROVIDED-INFO | RFC 8855 |
+------+---------------------------+-----------+
| 9 | STATUS-INFO | RFC 8855 |
+------+---------------------------+-----------+
| 10 | SUPPORTED-ATTRIBUTES | RFC 8855 |
+------+---------------------------+-----------+
| 11 | SUPPORTED-PRIMITIVES | RFC 8855 |
+------+---------------------------+-----------+
| 12 | USER-DISPLAY-NAME | RFC 8855 |
+------+---------------------------+-----------+
| 13 | USER-URI | RFC 8855 |
+------+---------------------------+-----------+
| 14 | BENEFICIARY-INFORMATION | RFC 8855 |
+------+---------------------------+-----------+
| 15 | FLOOR-REQUEST-INFORMATION | RFC 8855 |
+------+---------------------------+-----------+
| 16 | REQUESTED-BY-INFORMATION | RFC 8855 |
+------+---------------------------+-----------+
| 17 | FLOOR-REQUEST-STATUS | RFC 8855 |
+------+---------------------------+-----------+
| 18 | OVERALL-REQUEST-STATUS | RFC 8855 |
+------+---------------------------+-----------+
Table 7: Initial values of the BFCP
Attributes subregistry15.2. Primitives Subregistry 🧩
This section sets up the "Primitives" subregistry under the BFCP Parameters registry. As per the terminology in RFC 8126 [6], the registration policy for BFCP primitives is "Specification Required". For this subregistry, any BFCP primitive that's up for IANA registration MUST be defined by a Standards Track RFC. Such an RFC MUST specify the primitive's value, name, format, and semantics ✨
For each BFCP primitive, IANA registers its value, its name, and the reference to the RFC where the primitive is defined. The initial values for this subregistry are in the table below 🎯
+=======+=======================+===========+
| Value | Primitive | Reference |
+=======+=======================+===========+
| 1 | FloorRequest | RFC 8855 |
+-------+-----------------------+-----------+
| 2 | FloorRelease | RFC 8855 |
+-------+-----------------------+-----------+
| 3 | FloorRequestQuery | RFC 8855 |
+-------+-----------------------+-----------+
| 4 | FloorRequestStatus | RFC 8855 |
+-------+-----------------------+-----------+
| 5 | UserQuery | RFC 8855 |
+-------+-----------------------+-----------+
| 6 | UserStatus | RFC 8855 |
+-------+-----------------------+-----------+
| 7 | FloorQuery | RFC 8855 |
+-------+-----------------------+-----------+
| 8 | FloorStatus | RFC 8855 |
+-------+-----------------------+-----------+
| 9 | ChairAction | RFC 8855 |
+-------+-----------------------+-----------+
| 10 | ChairActionAck | RFC 8855 |
+-------+-----------------------+-----------+
| 11 | Hello | RFC 8855 |
+-------+-----------------------+-----------+
| 12 | HelloAck | RFC 8855 |
+-------+-----------------------+-----------+
| 13 | Error | RFC 8855 |
+-------+-----------------------+-----------+
| 14 | FloorRequestStatusAck | RFC 8855 |
+-------+-----------------------+-----------+
| 15 | FloorStatusAck | RFC 8855 |
+-------+-----------------------+-----------+
| 16 | Goodbye | RFC 8855 |
+-------+-----------------------+-----------+
| 17 | GoodbyeAck | RFC 8855 |
+-------+-----------------------+-----------+
Table 8: Initial values of the BFCP
Primitives subregistry15.3. Request Statuses Subregistry ✨
okay so this section sets up the "Request Statuses" subregistry under the BFCP Parameters registry 💅 as per RFC 8126 [6] terminology, the registration policy for BFCP request statuses is "Specification Required". for this subregistry, any BFCP request status that IANA registration is requested for MUST be defined by a Standards Track RFC 🎀 and that RFC MUST specify the value and the semantics of the request status 🫶
for each BFCP request status, IANA registers its value, its meaning, and the reference to the RFC where the request status is defined 🦋 the initial values of this subregistry are in the table below 🌸
+=======+===========+===========+
| Value | Status | Reference |
+=======+===========+===========+
| 1 | Pending | RFC 8855 |
+-------+-----------+-----------+
| 2 | Accepted | RFC 8855 |
+-------+-----------+-----------+
| 3 | Granted | RFC 8855 |
+-------+-----------+-----------+
| 4 | Denied | RFC 8855 |
+-------+-----------+-----------+
| 5 | Cancelled | RFC 8855 |
+-------+-----------+-----------+
| 6 | Released | RFC 8855 |
+-------+-----------+-----------+
| 7 | Revoked | RFC 8855 |
+-------+-----------+-----------+
Table 9: Initial values of
the Request Statuses
subregistry15.4. Error Codes Subregistry 💜
okay this section sets up the "Error Codes" subregistry under the BFCP Parameters registry 🧚 per RFC 8126 [6] terminology, the registration policy for BFCP error codes is "Specification Required". for this subregistry, any BFCP error code that IANA registration is requested for MUST be defined by a Standards Track RFC 💖 and that RFC MUST specify the value and the semantics of the error code, plus any Error Specific Details that apply to it ✨
for each BFCP primitive, IANA registers its value, its meaning, and the reference to the RFC where the primitive is defined 🌈 the initial values of this subregistry are in the table below 💅
+=======+=============================================+===========+
| Value | Meaning | Reference |
+=======+=============================================+===========+
| 1 | Conference Does Not Exist | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 2 | User Does Not Exist | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 3 | Unknown Primitive | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 4 | Unknown Mandatory Attribute | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 5 | Unauthorized Operation | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 6 | Invalid Floor ID | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 7 | Floor Request ID Does Not Exist | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 8 | You have Already Reached the Maximum Number | RFC 8855 |
| | of Ongoing Floor Requests for This Floor | |
+-------+---------------------------------------------+-----------+
| 9 | Use TLS | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 10 | Unable to Parse Message | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 11 | Use DTLS | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 12 | Unsupported Version | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 13 | Incorrect Message Length | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 14 | Generic Error | RFC 8855 |
+-------+---------------------------------------------+-----------+
Table 10: Initial values of the Error Codes subregistry16. Changes from RFC 4582 🦋
here's the list of technical changes and other non-trivial fixes from [3] 🎀
16.1. Extensions for an Unreliable Transport 🌸
the main point of this work was to update the spec so BFCP can run over an unreliable transport 🚀 that brought in these changes:
- Overview of Operation (Section 4): changed how client-initiated and server-initiated transactions are described, referring to Section 8.
- COMMON-HEADER Format (Section 5.1): the Ver(sion) field now uses the value 2 for the extensions for an unreliable transport 💖 new R and F flag bits were added for an unreliable transport 💅 the Res(erved) field is now 3 bit 🫶 and there are new optional Fragment Offset and Fragment Length fields ✨
- New primitives (Section 5.1): four new primitives were added:
FloorRequestStatusAck,FloorStatusAck,Goodbye, andGoodbyeAck🧚 - New error codes (Section 5.2.6): three new error codes were added:
"Unable to Parse Message","Use DTLS"and"Unsupported Version"💜 two more error codes were also added, see Section 16.2 👑 - ABNF for new primitives (Section 5.3): new subsections with normative ABNF for the new primitives were added 🌈
- Transport split in two (Section 6): Section 6 was split into two subsections: Section 6.1 for a reliable transport and Section 6.2 for an unreliable transport 🔥 the unreliable transport spec deals with reliability, congestion control, fragmentation and ICMP, among other issues 🙈
- Mandated DTLS (Section 7 and Section 9): DTLS support is now mandated when transport over UDP is used 🔒
- Transaction changes (Section 8): server-initiated transactions over an unreliable transport have non-zero and unique Transaction IDs 🦋 over an unreliable transport, the retransmit timers T1 and T2 described in Section 8.3 apply ⏱️
- Timely response required (Section 8.3, Section 10.1.2, Section 10.2.2, Section 11.2, Section 12.1.2, Section 12.2.2, Section 12.3.2, Section 12.4.2, Section 10.1.3 and Section 12.1.3): it's now described that a given response must be sent within the transaction failure window to complete the transaction ⏰
- Updated IANA Considerations (Section 15): the new primitives and error codes were added to Section 15.2 and Section 15.4 respectively 🎀
- Examples over an unreliable transport (Appendix A): sample interactions over an unreliable transport were added for the scenarios in Figure 2 and Figure 3 📖
- Motivation for an unreliable transport (Appendix B): an introduction to, and the motivation for, extending BFCP to support an unreliable transport were added 🌟
16.2. Other Changes 💅
clarifications and bug fixes, bestie 🫶
- ABNF fixes (Figure 22, Figure 24, Figure 26, Figure 28, Figure 30, and the ABNF figures in Section 5.3): the notation was already formally correct in [3], but it changed in a number of figures to an equivalent form for clarity 🧁 for example,
s/*1(FLOOR-ID)/[FLOOR-ID]/in Figure 38 ands/*[XXX]/*(XXX)/in the other figures ✨ - Typo (Section 12.4.2): changed from
SUPPORTED-PRIMITVIEStoSUPPORTED-PRIMITIVESin the second paragraph 🙈 - Corrected attribute type (Section 13.1.1): changed from
PARTICIPANT-PROVIDED-INFOto thePRIORITYattribute in the eighth paragraph 💖 this is because the note below describes priority, and the last paragraph deals withPARTICIPANT-PROVIDED-INFO🧚 - New error codes (Section 5.2.6): two additional error codes were added:
"Incorrect Message Length"and"Generic Error"💜 - New cipher suites (Section 7): additional cipher suites are now specified which should be supported 🔐
- Assorted clarifications (Across the document): language was clarified as a result of reviews 📝 the normative language was also tightened where appropriate, i.e. changed from SHOULD strength to MUST in a number of places 👑
17. References ✨
17.1. Normative References 📚
okay bestie, these are the must-reads 💅 every single one of these is needed to really understand the spec, so don't skip them 🫶
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[2] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[3] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, November 2006, <https://www.rfc-editor.org/info/rfc4582>.
[4] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, DOI 10.17487/RFC5018, September 2007, <https://www.rfc-editor.org/info/rfc5018>.
[5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[6] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[9] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[10] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[11] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[12] Camarillo, G., Kristensen, T., and C. Holmberg, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 8856, DOI 10.17487/RFC8856, January 2021, <https://www.rfc-editor.org/info/rfc8856>.
[13] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, <https://www.rfc-editor.org/info/rfc4961>.
[14] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[15] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[16] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
17.2. Informative References 🧚
and now the extra credit reading 🌸 these ones give you the background and the bigger picture, iykyk 🔥
[17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[18] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, DOI 10.17487/RFC4376, February 2006, <https://www.rfc-editor.org/info/rfc4376>.
[19] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239, June 2008, <https://www.rfc-editor.org/info/rfc5239>.
[20] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[21] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[22] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501, March 2012, <https://www.rfc-editor.org/info/rfc6501>.
[23] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, DOI 10.17487/RFC6503, March 2012, <https://www.rfc-editor.org/info/rfc6503>.
[24] Barnes, M., Miniero, L., Presta, R., and S P. Romano, "Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples", RFC 6504, DOI 10.17487/RFC6504, March 2012, <https://www.rfc-editor.org/info/rfc6504>.
[25] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[26] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[27] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[28] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.
[29] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <https://www.rfc-editor.org/info/rfc6951>.
[30] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[31] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, <https://www.rfc-editor.org/info/rfc4380>.
[32] Thaler, D., "Teredo Extensions", RFC 6081, DOI 10.17487/RFC6081, January 2011, <https://www.rfc-editor.org/info/rfc6081>.
[33] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[34] Rosenberg, J., Keranen, A., Lowekamp, B. B., and A. B. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, <https://www.rfc-editor.org/info/rfc6544>.
[35] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling (GUT)", Work in Progress, Internet-Draft, draft-manner-tsvwg-gut-02, 12 July 2010, <https://tools.ietf.org/html/draft-manner-tsvwg-gut-02>.
[36] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, Internet-Draft, draft-ietf-mmusic-media-path-middleboxes-07, 30 May 2013, <https://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-07>.
[37] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", 2005, <https://www.usenix.org/legacy/event/imc05/tech/full_papers/guha/guha.pdf>.
[38] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer Communication Across Network Address Translators", April 2005, <https://www.usenix.org/legacy/events/usenix05/tech/general/full_papers/ford/ford.pdf>.
Appendix A. Example Call Flows for BFCP over an Unreliable Transport 🎀
okay so bestie, this appendix is basically the cute little comic strip version of how the floor stuff works 🦋 It's all about BFCP running over an unreliable transport, and it's looking at Section 4.1 for reference. These figures show how you request a floor, release it, and check on a floor's status 💅 Everything here is a lossless interaction, so nothing gets dropped and the messages all arrive, which is very nice of them 🌸
Floor Participant Floor Control
Server
|(1) FloorRequest |
|Transaction Responder: 0 |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorRequestStatus |
|Transaction Responder: 1 |
|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 Responder: 0 |
|Transaction ID: 124 |
|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) FloorRequestStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 124 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(5) FloorRequestStatus |
|Transaction Responder: 0 |
|Transaction ID: 125 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(6) FloorRequestStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 125 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(7) FloorRelease |
|Transaction Responder: 0 |
|Transaction ID: 126 |
|User ID: 234 |
|FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->|
| |
|(8) FloorRequestStatus |
|Transaction Responder: 1 |
|Transaction ID: 126 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Released |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|Figure 48: Requesting and releasing a floor
okay so, in Figure 48 the participant asks for the floor, the server says "pending", then "accepted" with the 1st spot in the queue, and then "granted" 👑 Then the participant lets it go and the server confirms it's released 🫶 Ngl the vibe is immaculate. Also, the FloorRequestStatus the server sends back in response to Transaction ID 126 is a transaction-closing message, since it's answering the client's transaction. That means there is no FloorRequestStatusAck coming back from the participant after it 💀 No cap, it's the last message in that little convo.
Floor Participant Floor Control
Server
|(1) FloorQuery |
|Transaction Responder: 0 |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorStatus |
|Transaction Responder: 1 |
|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 Responder: 0 |
|Transaction ID: 258 |
|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 |
|<----------------------------------------------|
| |
|(4) FloorStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 258 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(5) FloorStatus |
|Transaction Responder: 0 |
|Transaction ID: 259 |
|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 |
|<----------------------------------------------|
| |
|(6) FloorStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 259 |
|User ID: 234 |
|---------------------------------------------->|Figure 49: Obtaining status information about a floor
Now the second one is the "what's going on with this floor??" check 👀 The participant sends a FloorQuery for floor 543, and the server answers with a whole FloorStatus full of requests. Request 764 is accepted in 1st place and belongs to beneficiary 124, and request 635 is accepted in 2nd place and belongs to beneficiary 154 🌈 Then the server updates things: 764 gets granted, and 635 moves up to 1st place. After that, 635 gets granted too, with beneficiary 154 🎉 Every FloorStatus that the server sends gets an ack back from the participant, which is very responsible of them ✨
Appendix B. Motivation for Supporting an Unreliable Transport 🧚
okay bestie, this appendix is the "why are we even doing this?" section 💜 It's here to help you understand the background and the reasoning behind adding support for an unreliable transport 🦋 Think of it as the backstory before the main character gets her powers, and honestly it's giving very important lore 🌸
B.1. Motivation ✨
Okay so bestie, here's the big "why" 💖 In existing video conferencing setups, BFCP manages the floor for content sharing during the call 🎀. For peer-to-peer stuff like business-to-business calls, or point-to-point calls in general 📞, one or both endpoints are often sitting behind a NAT. BFCP roles get sorted out in the offer/answer exchange described in [12], so one endpoint ends up being the one that opens the TCP connection BFCP uses 🧚.
+---------+
| Network |
+---------+
+-----+ / \ +-----+
| NAT |/ \| NAT |
+-----+ +-----+
+----+ / \ +----+
|BFCP|/ \|BFCP|
| UA | | UA |
+----+ +----+
Figure 50: Use caseThe call itself usually has a bunch of RTP over UDP media streams for audio and video, plus a BFCP connection for floor control 🦋. Existing deployments are most common in enterprise networks, but they're not limited to those 💼. In those deployments, NAT traversal for the RTP streams works with ICE and/or other methods, including the ones described in [36] 🔥.
When you're adding content sharing to an existing SIP-based video conferencing deployment, the BFCP connection is often the problem 😭. There are two main reasons. First, there's usually a strong preference for UDP-based signaling in general. On high-capacity endpoints like PSTN gateways or SIP/H.323 inter-working gateways, TCP can suffer from head-of-line blocking, and it eats a lot of kernel buffers 💀. Network operators see UDP as a way to dodge both of those 👑.
Second, setting up and traversing a TCP connection that uses ephemeral ports, which is typically the case with BFCP over TCP, can be a mess, as described in Appendix A of [34] 🙈. A broad study of NAT behavior and peer-to-peer TCP establishment, covering a comprehensive set of TCP NAT traversal techniques across a wide range of commercial NAT products, concluded that it was not possible to establish a TCP connection in 11% of the cases [37]. It gets worse when you focus on enterprise NATs. Another study of hole-punching as a NAT traversal technique, across a wide variety of deployed NATs, reported consistently higher success rates with UDP than with TCP [38] 🫶.
It's worth noting that BFCP over UDP is already being used in real deployments 🌈. That's why there's a real need for a common way to exchange BFCP messages where TCP isn't appropriate. Otherwise you'd get a pile of different, non-interoperable implementations fighting it out in the market 😤. The purpose of this document is to extend the standard specification to support unreliable transport, so implementations can actually interoperate fully ✨.
B.1.1. Alternatives Considered
When we picked UDP as an alternate transport for BFCP, a bunch of other options got considered and explored to some degree 🧐. Each one gets a quick look in the subsections below. The short version: the options that weren't chosen work in some scenarios, but on their own they aren't enough for the use case this document targets 🙅. The last one, in Appendix B.1.1.7, is the one that got picked and specified here 💅.
It's also worth noting that the IETF Transport Area was asked for a way to tunnel TCP over UDP, but at that point there was no consensus on how to do it 🤷♀️.
B.1.1.1. ICE TCP
ICE TCP [34] extends ICE to TCP-based media, including the ability to offer a mix of TCP- and UDP-based candidates for a single stream 🎀. But ICE TCP usually has a lower success probability for getting TCP connectivity without a relay when both hosts are behind a NAT (see Appendix A of [34]) than UDP connectivity has in the same scenarios 😬.
Why? Lots of currently deployed NATs in video conferencing networks don't support the flow of TCP handshake packets you see in a TCP simultaneous-open. Either they don't allow incoming TCP SYN packets from an address the endpoint recently sent a SYN to, or they don't process the follow-up SYNACK properly 🙃. The techniques for candidate collection advocated in [34] should boost the success probability, but a lot of them need help from network elements like the NATs. That kind of support isn't common in enterprise NATs 💔.
B.1.1.2. Teredo
Teredo [31] lets nodes behind one or more IPv4 NATs get IPv6 connectivity by tunneling packets over UDP 🌸. Teredo extensions [32] add more capabilities, including support for more types of NATs and more efficient communication ⭐.
As defined, Teredo could make BFCP work for the video conferencing use cases in this document 🙌. But running it needs "Teredo servers" and "Teredo relays" [31] 🧚, and those generally don't exist in current video conferencing deployments 😵. It also needs IPv6 awareness on the endpoints 💅.
ICMP6 is another wrinkle. Teredo uses it to finish an initial protocol exchange and confirm that the right NAT bindings are set up. But ICMP6 isn't a conventional feature of IPv4 or even IPv6, and some currently deployed IPv6 firewalls discard ICMP messages 🚫. As these networks keep evolving and tackle the move to IPv6, Teredo servers and relays may get deployed, which would make Teredo a suitable alternative to BFCP over UDP 🦋.
B.1.1.3. GUT
GUT [35] tries to make tunneling over UDP work by encapsulating the native transport protocol and its payload (in general the whole IP payload) inside a UDP packet destined to the well-known port GUT_P 🎁. Unfortunately, it requires user-space TCP, there's no readily available implementation of that, and creating one is a huge project in itself 😩. This document has expired, and its future is still unclear since it hasn't been adopted by a working group 🥲.
B.1.1.4. UPnP IGD
Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on the edge of the network 🌐. They provide connectivity to the Internet for computers inside the LAN, but they don't allow Internet devices to connect to computers on the internal LAN 🙅♀️. IGDs let a computer on an internal LAN create port mappings on their NAT, so hosts on the Internet can send data that gets forwarded to that computer 🪄. IGDs may be self-contained hardware devices or software components provided within an operating system 💻.
Now, several issues exist. Not all NATs support UPnP, and many that do ship with it turned off by default 🙈. NATs are often multilayered, and UPnP doesn't work well with those. For example, a typical DSL modem acts as a NAT, and then the user plugs in a wireless access point behind it, which adds another layer of NAT 📶. The client can discover the first layer of NAT using multicast, but it's harder to figure out how to discover and control the NATs in the next layer up 😵💫.
B.1.1.5. NAT PMP
The NAT Port Mapping Protocol (NAT PMP) lets a computer in a private network (behind a NAT router) automatically configure the router so parties outside the private network can contact it 🔓. It runs over UDP and basically automates port forwarding 🤖. It also includes a method for retrieving the public IP address of a NAT gateway, so a client can make that public IP address and port number known to peers that might want to talk to it 📣.
Many NATs don't support PMP. For those that do, it has similar issues with negotiating multilayer NATs as UPnP 😤. Video conferencing is used extensively in enterprise networks, and NAT PMP isn't generally available in enterprise-class routers 💼.
B.1.1.6. SCTP
It would be pretty straightforward to specify a BFCP binding for Stream Control Transmission Protocol (SCTP) [33], and then tunnel SCTP over UDP in the use case described in Appendix B.1 🌊. SCTP is gaining momentum right now. There was ongoing discussion in the RTCWeb Working Group about this approach, which resulted in [29] 🗣️. However, this approach to tunneling over UDP wasn't mature enough when it was considered, and it wasn't even fully specified 🥀.
B.1.1.7. BFCP over UDP Transport
To overcome the problems with establishing TCP flows between BFCP entities, an alternative is to define UDP as an alternate transport for BFCP 🎯. It leverages the same mechanisms already in place for the RTP over UDP media streams used for the BFCP communication. When using UDP as the transport, following the guidelines provided in [15] is recommended ✅.
There are minor changes to the transaction model, since all requests now get an appropriate response to complete the transaction 🔁. The requests are sent with a retransmission timer associated with the response, which is how reliability is achieved ⏱️. This alternative doesn't change the semantics of BFCP. It just permits UDP as an alternate transport 🦋.
Existing implementations, in the spirit of the approach detailed in earlier draft versions of this document, have shown that this approach is feasible 🎉. Initial compatibility among implementations was achieved at previous interoperability events 🤝. The authors view this extension as a pragmatic solution to an existing deployment challenge 💖. This is the chosen approach, and the extensions are specified in this document 👑.
Acknowledgements ✨
The XCON Working Group chairs, Adam Roach and Alan Johnston, gave useful ideas for RFC 4582 [3] 🫶. Xiaotao Wu, Paul Kyzivat, Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morgan, and Oscar Novo gave useful comments during the work on RFC 4582 💬.
The authors also thank Geir Arne Sandbakken, who had the initial idea, plus Alfred E. Heggestad, Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, Jörg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman, Vijaya Mandava, and Alan Ford 🌟. They contributed to the revision of BFCP for use over an unreliable transport.
In the final phase, Ernst Horvath did a thorough review, revealing issues that needed clarification and changes 🔍. Useful and important final reviews were done by Mary Barnes 💜. Paul Jones helped tremendously as editor for changes addressing IESG review comments 🙌.
Authors' Addresses ✨
okay bestie, here's the squad who wrote this doc and how to reach each of them 🫶
Gonzalo Camarillo 💖
Gonzalo Camarillo
Ericsson
Hirsalantie 11
FI-02420 Jorvas
Finland
Email: gonzalo.camarillo@ericsson.comKeith Drage 🌸
Keith Drage
Email: drageke@ntlworld.comTom Kristensen 🦋
Tom Kristensen
Jotron AS
Ringdalskogen 8
3270 Larvik
Norway
Email: tom.kristensen@jotron.com, tomkri@ifi.uio.noJörg Ott 🧚
Jörg Ott
Technical University Munich
Boltzmannstrasse 3
85748 Garching
Germany
Email: ott@in.tum.deCharles Eckel 👑
Charles Eckel
Cisco
707 Tasman Drive
Milpitas, California 95035
United States of America
Email: eckelcu@cisco.comthat's the whole author crew, periodt ✨💅
📦 where this page comes from
- ietf: rfc8855 2021-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms