RFC 4582
The Binary Floor Control Protocol (BFCP)
RFC 4582: The Binary Floor Control Protocol (BFCP) 🎀
(part 1 of 13 💫)
Okay bestie, let's start with the vibes. This RFC is from the Network Working Group 🧚 and it's in the Standards Track category ✨, which means it's an official Internet standards document. It came out in November 2006 🍓.
It was written by three amazing people: G. Camarillo (Ericsson), J. Ott (Helsinki University of Technology), and K. Drage (Lucent Technologies) 👑. The title block doesn't list anything this document obsoletes or updates, so there's no drama there 💅.
Status of This Memo
Okay, so this part is the legal-ish stuff, but it matters! This document specifies an Internet standards track protocol for the Internet community 🌈, and it asks everyone to discuss it and suggest improvements 🫶. If you want to know where this protocol stands in the official standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. And distribution of this memo is unlimited, so share it with everyone you know 💖.
Copyright Notice
Copyright (C) The IETF Trust (2006) ✨.
Abstract
Floor control is basically a way to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment 🎤. It's giving "who gets to talk right now" energy 😭. It complements other functions, like conference and media session setup, conference policy manipulation, and media control, which other protocols handle 🦋.
This document specifies the Binary Floor Control Protocol (BFCP) 🔥. BFCP is used between floor participants and floor control servers, and also between floor chairs (aka moderators) and floor control servers 👑.
Table of Contents
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Scope ...........................................................5
3.1. Floor Creation .............................................7
3.2. Obtaining Information to Contact a Floor Control Server ....7
3.3. Obtaining Floor-Resource Associations ......................7
3.4. Privileges of Floor Control ................................8
4. Overview of Operation ...........................................8
4.1. Floor Participant to Floor Control Server Interface ........8
4.2. Floor Chair to Floor Control Server Interface .............13
5. Packet Format ..................................................14
5.1. COMMON-HEADER Format ......................................15
5.2. Attribute Format ..........................................16
5.2.1. BENEFICIARY-ID .....................................18
5.2.2. FLOOR-ID ...........................................18
5.2.3. FLOOR-REQUEST-ID ...................................19
5.2.4. PRIORITY ...........................................19
5.2.5. REQUEST-STATUS .....................................20
5.2.6. ERROR-CODE .........................................21
5.2.6.1. Error-Specific Details for Error Code 4 ...22
5.2.7. ERROR-INFO .........................................22
5.2.8. PARTICIPANT-PROVIDED-INFO ..........................23
5.2.9. STATUS-INFO ........................................24
5.2.10. SUPPORTED-ATTRIBUTES ..............................24
5.2.11. SUPPORTED-PRIMITIVES ..............................25
5.2.12. USER-DISPLAY-NAME .................................26
5.2.13. USER-URI ..........................................26
5.2.14. BENEFICIARY-INFORMATION ...........................27
5.2.15. FLOOR-REQUEST-INFORMATION .........................27
5.2.16. REQUESTED-BY-INFORMATION ..........................28
5.2.17. FLOOR-REQUEST-STATUS .............................29
5.2.18. OVERALL-REQUEST-STATUS ...........................30
5.3. Message Format ............................................30
5.3.1. FloorRequest .......................................31
5.3.2. FloorRelease .......................................31
5.3.3. FloorRequestQuery ..................................31
5.3.4. FloorRequestStatus .................................31
5.3.5. UserQuery ..........................................32
5.3.6. UserStatus .........................................32
5.3.7. FloorQuery .........................................32
5.3.8. FloorStatus ........................................33
5.3.9. ChairAction ........................................33
5.3.10. ChairActionAck ....................................33
5.3.11. Hello .............................................33
5.3.12. HelloAck ..........................................34
5.3.13. Error .............................................34
6. Transport ......................................................34
7. Lower-Layer Security ...........................................35
8. Protocol Transactions ..........................................35
8.1. Client Behavior ...........................................36
8.2. Server Behavior ...........................................36
9. Authentication and Authorization ...............................36
9.1. TLS-Based Mutual Authentication ...........................37
10. Floor Participant Operations ..................................37
10.1. Requesting a Floor .......................................37
10.1.1. Sending a FloorRequest Message ....................38
10.1.2. Receiving a Response ..............................38
10.2. Cancelling a Floor Request and Releasing a Floor .........40
10.2.1. Sending a FloorRelease Message ....................40
10.2.2. Receiving a Response ..............................40
11. Chair Operations ..............................................41
11.1. Sending a ChairAction Message ............................41
11.2. Receiving a Response .....................................42
12. General Client Operations .....................................43
12.1. Requesting Information about Floors ......................43
12.1.1. Sending a FloorQuery Message ......................43
12.1.2. Receiving a Response ..............................43
12.2. Requesting Information about Floor Requests ..............44
12.2.1. Sending a FloorRequestQuery Message ...............45
12.2.2. Receiving a Response ..............................45
12.3. Requesting Information about a User ......................45
12.3.1. Sending a UserQuery Message .......................46
12.3.2. Receiving a Response ..............................46
12.4. Obtaining the Capabilities of a Floor Control Server .....46
12.4.1. Sending a Hello Message ...........................47
12.4.2. Receiving Responses ...............................47
13. Floor Control Server Operations ...............................47
13.1. Reception of a FloorRequest Message ......................48
13.1.1. Generating the First FloorRequestStatus Message ...48
13.1.2. Generation of Subsequent
FloorRequestStatus Messages .......................50
13.2. Reception of a FloorRequestQuery Message .................51
13.3. Reception of a UserQuery Message .........................52
13.4. Reception of a FloorRelease Message ......................53
13.5. Reception of a FloorQuery Message ........................54
13.5.1. Generation of the First FloorStatus Message .......55
13.5.2. Generation of Subsequent FloorStatus Messages .....56
13.6. Reception of a ChairAction Message .......................56
13.7. Reception of a Hello Message .............................57
13.8. Error Message Generation .................................58
14. Security Considerations .......................................58
15. IANA Considerations ...........................................59
15.1. Attribute Subregistry ....................................59
15.2. Primitive Subregistry ....................................60
15.3. Request Status Subregistry ...............................61
15.4. Error Code Subregistry ...................................62
16. Acknowledgements ..............................................62
17. References ....................................................63
17.1. Normative References .....................................63
17.2. Informational References .................................631. Introduction ✨
Okay so, within a conference, some apps need to manage who gets access to a set of shared resources 🎀, like the right to send media to a particular media session. That's where floor control comes in. It lets these apps give users coordinated access to those resources, either shared or exclusive 💅.
The Requirements for Floor Control Protocol [9] lists a set of requirements that floor control protocols need to meet 📝. The Binary Floor Control Protocol (BFCP), which is what this document specifies, meets those requirements 🦋.
BFCP was also designed so it can be used in low-bandwidth environments 🌸. Its binary encoding gives it a small message size (when message signatures are not used) 🍓, which keeps the time it takes to transmit delay-sensitive BFCP messages super low ⭐. The delay-sensitive ones are FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction 🔥. Future extensions to these messages are expected to not blow up their size in a significant way 🙈.
The rest of the document is organized like this: Section 2 defines the terminology used throughout the document 📖. Section 3 covers the scope of BFCP, meaning which tasks fall inside it and which ones are handled by different mechanisms 🧚. Section 4 gives a non-normative overview of how BFCP operates 💜. The subsequent sections contain the normative specification of BFCP, so that's where the real rules live 👑.
2. Terminology ✨
Okay bestie, let's get our vocab straight 💅. In this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14, [RFC 2119 [1]](#) 🎀 and they show the requirement levels for compliant implementations. Those capitalised words are the ones that actually matter, so watch for them 👀.
Media Participant: An entity that has access to the media resources of a conference (for example, it can receive a media stream) 🎧. In floor-controlled conferences, a media participant is usually colocated with a floor participant, but it doesn't have to be 🌸. Third-party floor requests are when a floor participant requests a floor for a media participant that isn't colocated with them 💖. The protocol between a floor participant and a media participant (when they aren't colocated) is out of scope for this document 🙅♀️.
Client: A floor participant or a floor chair that talks to 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, meaning it grants, denies, or revokes a floor 👑. An entity playing the floor chair role for one transaction can play a different role (like floor participant) for another transaction 🦋. Floor chair and floor participant roles are decided transaction by transaction. BFCP transactions are defined in Section 8 📖.
Floor Control: A mechanism that lets applications or users get safe and mutually exclusive or non-exclusive input access to a shared object or resource 🫶.
Floor Control Server: A logical entity that keeps track of the state of the floors, including which floors exist, who the floor chairs are, who holds a floor, and so on 🧠. Requests to manipulate a floor get sent to the floor control server 📬. A floor control server for one conference may take on other logical roles (like floor participant) in a different conference 🌈.
Floor Participant: A logical entity that requests floors, and possibly information about them, from a floor control server 🙋♀️. An entity playing the floor participant role for one transaction can be a floor chair for another ✨. Floor participant and floor chair roles are also decided transaction by transaction. BFCP transactions are defined in Section 8. In floor-controlled conferences, a floor participant is usually colocated with a media participant, but it doesn't have to be 💜. Third-party floor requests are when a floor participant requests a floor for a media participant that isn't colocated with them 🍓.
Participant: An entity that acts as a floor participant, as a media participant, or as both 🎀.
3. Scope 🌸
Remember how BFCP is a protocol for coordinating access to shared resources in a conference, following the requirements defined in [9]? 🧚 Floor control works alongside other functions defined in the XCON conferencing framework [10] 🫶. BFCP only specifies a way to arbitrate access to floors 🔐. The rules and constraints for floor arbitration, and the results of floor assignments, are out of scope for this document and are defined by other protocols [10] 💅.
Here's Figure 1, showing the tasks BFCP can perform 👀:
+---------+
| Floor |
| Chair |
| |
+---------+
^ |
| |
Notification | | Decision
| |
| |
Floor | v
+-------------+ Request +---------+ +-------------+
| Floor |----------->| Floor | Notification | Floor |
| Participant | | Control |------------->| Participant |
| |<-----------| Server | | |
+-------------+ Granted or +---------+ +-------------+
Denied
Figure 1: Functionality provided by BFCPBFCP gives us a way:
- 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 their decisions about floor requests 👑.
- for floor control servers to keep floor participants and floor chairs updated on the status of a given floor or a given floor request 📢.
Even though anything not on that list is out of scope, some of those out-of-scope tasks are closely tied to floor control and are essential for creating floors and setting up BFCP connections between different entities 🥺. The subsections below talk through some of these tasks and the mechanisms for doing them 🦋.
3.1. Floor Creation 🎨
Linking a floor to a resource (or a set of resources, like media streams) is out of scope for BFCP, as described in [10] 🙈. Creating and terminating floors is also out of scope. Those are handled by the conference control protocol that manipulates the conference object 💻. That means the floor control server needs to stay up to date on changes to the conference object, like when a new floor gets created 🌟.
3.2. Obtaining Information to Contact a Floor Control Server 📞
A client needs a bundle of data to set up a BFCP connection to a floor control server 🎁. That data includes the server's transport address, the conference identifier, and a user identifier 🪪.
Clients can get this info in different ways. One option is an SDP offer/answer [8] exchange, which is described in [7] 🤝. Other mechanisms are described in the XCON framework [10] (and other related documents) 📚.
3.3. Obtaining Floor-Resource Associations 🔗
Floors are associated with resources. For example, a floor that controls who gets to talk at a given time has a particular audio session as its associated resource 🎙️. Those floor-resource associations are part of the conference object 💜.
Floor participants and floor chairs need to know which resources go with which floors 🧐. They can get this info through different mechanisms, such as an SDP offer/answer [8] exchange 🌈. How to use an SDP offer/answer exchange to get these associations is described in [7] 📖.
Heads up, babe: floor participants do their SDP offer/answer exchanges with the conference focus of the conference 🫢. So the conference focus needs to know the associations between floors and resources, so it can hand that info to a floor participant during an SDP offer/answer exchange 💖.
Other mechanisms for getting this info, including how it's made available to a (SIP) Focus, are described in the XCON framework [10] (and other related documents) 🦋.
3.4. Privileges of Floor Control 👑
A participant whose floor request was granted has the right to use (in a certain way) the resource or resources linked to the requested floor ✨. For example, they may have the right to send media over a particular audio stream 🎶.
Here's the tea though 🫖: holding a floor doesn't stop others from using its associated resources at the same time, even if those others don't have the right to do so 😭. Figuring out which media participants can actually use the conference resources is covered in the XCON Framework [10] 🧩.
4. Overview of Operation 🧚♀️
This section is a non-normative overview of BFCP operations 🌷. Section 4.1 covers the interface between floor participants and floor control servers, and Section 4.2 covers the interface between floor chairs and floor control servers 💕.
BFCP messages use a TLV (Type-Length-Value) binary encoding 🔢. Each one has a common header followed by a set of attributes 📦. The common header holds, among other info, a 32-bit conference identifier 🆔. Floor participants, media participants, and floor chairs are identified by 16-bit user identifiers 🪪.
BFCP supports nested attributes, meaning attributes that contain other attributes 🪆. These are called grouped attributes 💜.
BFCP has two types of transactions: client-initiated and server-initiated 🔄. Client-initiated transactions are a message from a client to the floor control server plus a response from the floor control server back to the client 💬. The two messages are linked because they carry the same Transaction ID value in their common headers 🎀. Server-initiated transactions are a single message from the floor control server to a client, and its Transaction ID is 0 🌙.
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, which means the floor participant sending the request doesn't have to be colocated with the media participant who'll get the floor once it's granted 🥰. FloorRequest messages carry the requester's identity in the User ID field of the common header 🪪. They carry the identity of the floor's beneficiary (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 aren't media participants (so they don't handle any media) 🎧.
FloorRequest messages name 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 those floor requests as one atomic package 📦✨. That means the floor control server either grants or denies every floor in the FloorRequest message, no in-between 🙅♀️.
Floor control servers respond to FloorRequest messages with FloorRequestStatus messages, which give info about the status of the floor request 📬. The first FloorRequestStatus message is the response to the client's FloorRequest message, so it has the same Transaction ID as the FloorRequest 🔁.
That first FloorRequestStatus message also carries the Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute 🪪. Later FloorRequestStatus messages about the same floor request carry the same Floor Request ID 💜. That's how the floor participant knows which floor request each one belongs to 🧠.
Messages from the floor participant about a particular floor request also use the same Floor Request ID as the first FloorRequestStatus message from the floor control server 💖.
Figure 2 shows how a floor participant requests a floor, gets it, and later releases it 🦋. It's the best way to see how the Transaction ID and the FLOOR-REQUEST-ID attribute get used, 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 floorOkay, next up is Figure 3 🦋 It shows how a floor participant asks to be kept in the loop on what's happening with a floor. The first FloorStatus message the floor control server sends back is the response to the FloorQuery message, so it carries the exact same Transaction ID as that FloorQuery 💅
Every FloorStatus after that is server-initiated, which is why their Transaction ID is 0 🌸 Message (2) tells us there are currently two floor requests for the floor whose Floor ID is 543 ✨ Message (3) says that floor request 764 has been granted, while floor request 635 is first in the queue 👑 And message (4) says floor request 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 floorOoh, here's the tea 🫖 FloorStatus messages carry info about the floor requests inside them 💜 Take message (4): it says floor request 635 has the beneficiary (aka the participant who holds the floor once that request gets granted) as the participant with User ID 154 🙈 That request only applies to the floor with Floor ID 543. So this is not a multi-floor floor request, bestie 💀
Multi-floor requests, explained: a multi-floor floor request covers more than one floor. Think: a participant wants to talk AND write on the whiteboard at the same time 🎀 The floor control server treats a multi-floor floor request as an atomic package 📦 Meaning it either grants the request for all of the floors or denies it for all of them. No in-between, no half-granted vibes 😭🫶
4.2. Floor Chair to Floor Control Server Interface ✨
okay bestie, Figure 4 is giving chair energy 👑 It shows a floor chair telling the floor control server to grant a floor 💅
Note, however, that although the floor control server needs to take into consideration the instructions received in ChairAction messages (e.g., granting a floor), it does not necessarily need to perform them exactly as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server.
Okay so, 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 for one of those floors says "grant it," the server won't grant it until the chairs for the other floors agree to grant theirs too. Not me waiting on everyone else 💀
Another example: a floor chair can tell the server to grant a floor to a participant. But the server has to revoke the floor from whoever currently holds it before handing it over to the new participant 🔄 No stealing without a proper handoff, periodt 🙅♀️
So the floor control server is ultimately responsible for keeping a coherent floor state 💜 It takes instructions from floor chairs as input, but it's the one keeping the state consistent ✨
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 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |Reserved | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: COMMON-HEADER formatVer: the 3-bit version field MUST be set to 1 to indicate this version of BFCP 🦋
Reserved: at this point, the 5 bits in the reserved field SHOULD be set to zero by the sender of the message and MUST be ignored by the receiver 🤷♀️
Primitive: this 8-bit field identifies the main purpose of the message ✨ 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 |
+-------+--------------------+------------------+
S: Floor Control Server
P: Floor Participant
Ch: Floor Chair
Table 1: BFCP primitivesPayload Length: this 16-bit field contains the length of the message in 4-octet units, excluding the common header 📏
Conference ID: this 32-bit field identifies the conference the message belongs to 🎉
Transaction ID: this field contains a 16-bit value that lets users match a given message with its response 🔁 In server-initiated transactions, the Transaction ID value is 0 (see Section 8) 🧚
User ID: this field contains a 16-bit value that uniquely identifies a participant within a conference 🫶
The identity a participant uses in BFCP, which is carried in the User ID field, is generally mapped to the identity that same participant uses in the session establishment protocol (e.g., in SIP). The way this mapping is performed is outside the scope of this specification.
5.2. Attribute Format
BFCP attributes are encoded in TLV (Type-Length-Value) format 🌈 They're 32-bit aligned 📐
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 contains the type of the attribute 🏷️ Each attribute, identified by its type, has a particular format. The attribute formats defined are:
- Unsigned16: the contents of the attribute consist of a 16-bit unsigned integer.
- OctetString16: the contents of the attribute consist of 16 bits of arbitrary data.
- OctetString: the contents of the attribute consist of arbitrary data of variable length.
- Grouped: the contents of the attribute consist of a sequence of attributes.
Note that extension attributes defined in the future may define new attribute formats 🔮
The following attribute types are defined 💅
+------+---------------------------+---------------+
| 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: the 'M' bit, known as the Mandatory bit, indicates whether support of the attribute is required 🚨 If an unrecognized attribute with the 'M' bit set is received, the message is rejected 🙅♀️ 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 is irrelevant for these. In all other cases, an unrecognised attribute is ignored but the message is still processed 🌸
Length: this 8-bit field contains the length of the attribute in octets, excluding any padding defined for specific attributes 📏 The length of attributes that are not grouped includes the Type, 'M' bit, and Length fields. The Length in grouped attributes is the length of the grouped attribute itself (including 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
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 contains 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 format of the FLOOR-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 1 0|M|0 0 0 0 0 1 0 0| Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FLOOR-ID formatFloor ID: this field contains a 16-bit value that uniquely identifies a floor within a conference 🦋
5.2.3. FLOOR-REQUEST-ID
Here's the format of the FLOOR-REQUEST-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 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: FLOOR-REQUEST-ID formatFloor Request ID: this field contains a 16-bit value that identifies a floor request at the floor control server 🌟
5.2.4. PRIORITY 💅
okay so PRIORITY is giving tiny but mighty 🎀 this is what the format 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 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: PRIORITY formatPrio 🔥 is the 3-bit priority value, and the valid values are listed in Table 3 below. Senders SHOULD NOT use values higher than 4 in this field, but receivers MUST treat anything higher than 4 as if it were 4 (Highest) 🫶 and if the PRIORITY attribute is missing entirely, the default is 2 (Normal) ✨
+-------+----------+
| Value | Priority |
+-------+----------+
| 0 | Lowest |
| 1 | Low |
| 2 | Normal |
| 3 | High |
| 4 | Highest |
+-------+----------+
Table 3: Priority valuesReserved 🌸 the 13 bits in this reserved field SHOULD be set to zero by the sender of the message, and the receiver MUST ignore them. no drama, just vibes 💜
5.2.5. REQUEST-STATUS 🍓
REQUEST-STATUS is the attribute that tells you what's going on with a floor request, and it 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 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: REQUEST-STATUS formatRequest Status 👑 is an 8-bit field holding the status of the request, and these are the values you can get:
+-------+-----------+
| Value | Status |
+-------+-----------+
| 1 | Pending |
| 2 | Accepted |
| 3 | Granted |
| 4 | Denied |
| 5 | Cancelled |
| 6 | Released |
| 7 | Revoked |
+-------+-----------+
Table 4: Request Status valuesQueue Position 🦋 is another 8-bit field, and it shows where the floor request sits in the server's floor request queue, but only when that's relevant. If the Request Status is anything other than Accepted, or the server doesn't do a queue at all, or the server just doesn't want to share this info with the client, then all the bits here SHOULD be set to zero 🙈
A floor request is in the Pending state when the floor control server needs to reach out to a floor chair before it can accept the request, and it hasn't done that yet. Once the floor chair says yes, the request moves over to the Accepted state 💖
5.2.6. ERROR-CODE 🚨
ERROR-CODE is the attribute for when something goes wrong, and here's how it's laid out:
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 💀 is an 8-bit field with an error code from the table below. If the receiver doesn't recognise a code, the receiver MUST assume an error does exist, so the message still gets processed, even though the exact nature of the error is unclear 😭
+-------+-----------------------------------------------------------+
| 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 |
+-------+-----------------------------------------------------------+
Table 5: Error Code meaningError Specific Details 🧚 only shows up for certain error codes. In this document, it's only for Error Code 4 (Unknown Mandatory Attribute), and you can read all about that in Section 5.2.6.1 👀
Padding 🌈 is one, two, or three octets added so the ERROR-CODE contents line up on a 32-bit boundary. If the attribute is already 32-bit aligned, you don't need any padding at all ✨
The Padding bits SHOULD be set to zero by the sender, and the receiver MUST ignore them 🫶
5.2.6.1. Error-Specific Details for Error Code 4 🔍
this is the format of the Error-Specific Details field when the error code is 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 are 7-bit fields holding the Types of the attributes that were unknown to the receiver. They came from the message that triggered the Error message in the first place 🎀
R 💜 this bit is reserved for now. It SHOULD be set to zero by the sender of the message, and the receiver MUST ignore it 💅
5.2.7. ERROR-INFO ℹ️
ERROR-INFO carries extra details about an error, and it's laid out 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 0 1 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: ERROR-INFO formatText 📝 this field holds UTF-8 [6] encoded text.
Sometimes an automaton is the one generating the Text field 🤖 and if that automaton knows which language the receiver of a particular ERROR-INFO attribute prefers, it MAY use that language to write the Text 🌍
Padding 🌸 is one, two, or three octets added so the ERROR-INFO contents are 32-bit aligned. The Padding bits SHOULD 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 🦋
PARTICIPANT-PROVIDED-INFO is where a participant gets to share its own info, and 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 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: PARTICIPANT-PROVIDED-INFO formatText 💖 this field holds UTF-8 [6] encoded text.
Padding 🧁 is one, two, or three octets added so the PARTICIPANT-PROVIDED-INFO contents are 32-bit aligned. The Padding bits SHOULD 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 📣
STATUS-INFO is the attribute for status updates, and it 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 0 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: STATUS-INFO formatText 🌷 this field holds UTF-8 [6] encoded text.
Just like ERROR-INFO, the Text field may sometimes be generated by an automaton 🤖 and if that automaton knows the receiver's preferred language, it MAY use that language to generate the Text field 🌍
Padding 💜 is one, two, or three octets added so the STATUS-INFO contents are 32-bit aligned. The Padding bits SHOULD 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 ✨
okay bestie, this one is the list of attribute Types the floor control server is totally vibing with 💖 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 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 formatThe Supp. Attr. fields hold the Types of the attributes that the floor control server supports, in the format above. 🎀
R is the Reserved bit, and it's giving "don't touch me." This bit MUST be set to zero upon transmission and MUST be ignored upon reception. 🙈
Padding is two octets that get added so the SUPPORTED-ATTRIBUTES contents land on a 32-bit boundary. If the attribute is already 32-bit aligned, no padding is needed. 🧚
The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. 💅
5.2.11. SUPPORTED-PRIMITIVES 🦋
this is the format of the SUPPORTED-PRIMITIVES attribute, and it's basically the menu of BFCP message types the floor control server can handle 🍓
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 formatThe Primitive fields contain the types of the BFCP messages that the floor control server supports. Check out Table 1 for the full list of BFCP primitives 📋
Padding is one, two, or three octets added so the SUPPORTED-PRIMITIVES contents are 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed. ✨
The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. 🫶
5.2.12. USER-DISPLAY-NAME 🌸
this one carries the user's name, so it's very personal 🥹
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 is the UTF-8 encoded name of the user. 🌈
Padding is one, two, or three octets added so the USER-DISPLAY-NAME contents are 32-bit aligned. The Padding bits SHOULD 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 🔗
this is the user's contact URI, the one they used to set up the resources (like media streams) that BFCP controls 🎧
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 is the UTF-8 encoded user's contact URI. That's the URI the user used to set up the resources (for example, media streams) that BFCP controls. For example, in a conference set up by 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. This is so a client can match up the user's URI (like the SIP URI they used to join a conference) with their User ID. Main character connections only 🙌
Padding is one, two, or three octets added so the USER-URI contents are 32-bit aligned. The Padding bits SHOULD 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. It's a header (the BENEFICIARY-INFORMATION-HEADER) followed by a bunch of attributes lined up behind it 💅 here's the header:
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 is a 16-bit value that uniquely identifies a user within a conference. 🪪
Here's the ABNF (Augmented Backus-Naur Form) [2] for the BENEFICIARY-INFORMATION grouped attribute. EXTENSION-ATTRIBUTE is the spot for extension attributes that might get defined later on 🔮
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. It starts with a FLOOR-REQUEST-INFORMATION-HEADER, then a sequence of attributes follows it 🦋 the header goes 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 is a 16-bit value that identifies a floor request at the floor control server. 🎫
The ABNF of the FLOOR-REQUEST-INFORMATION grouped attribute is below. EXTENSION-ATTRIBUTE again means 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 with its own header, the REQUESTED-BY-INFORMATION-HEADER, followed by a sequence of attributes 💖
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 is a 16-bit value that uniquely identifies a user within a conference. 🙋♀️
The ABNF of the REQUESTED-BY-INFORMATION grouped attribute is here. EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future ✨
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 🌈
last one in this batch! FLOOR-REQUEST-STATUS is a grouped attribute with a FLOOR-REQUEST-STATUS-HEADER, then a sequence of attributes 🍬
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 is a 16-bit value that uniquely identifies a floor within a conference. 👑
Here's the ABNF of the FLOOR-REQUEST-STATUS grouped attribute. EXTENSION-ATTRIBUTE means 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 ✨
okay so OVERALL-REQUEST-STATUS is a grouped attribute 🎀 which basically means it's a header 💅 (called OVERALL-REQUEST-STATUS-HEADER) with a whole line of other attributes lined up right after it. here's what the header 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 1 0 0 1 0|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 29: OVERALL-REQUEST-STATUS-HEADER format
the Floor Request ID is a 16-bit value 🦋 that identifies a floor request at the floor control server. so that's how the server knows which request we're even talking about 🧚
now the ABNF for the grouped attribute 👑 (EXTENSION-ATTRIBUTE is the placeholder for extension attributes that might get defined later, so it's basically giving "future-proof" 🌈):
OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER)
[REQUEST-STATUS]
[STATUS-INFO]
*[EXTENSION-ATTRIBUTE]Figure 30: OVERALL-REQUEST-STATUS format
5.3. Message Format 💖
this section has the normative ABNF (Augmented Backus-Naur Form) [2] of the BFCP messages. anything that might be defined later as an extension attribute just shows up as EXTENSION-ATTRIBUTE in the ABNF, so keep that in mind 🫶
5.3.1. FloorRequest 🌸
floor participants ask for a floor by sending a FloorRequest message to the floor control server. here's the format:
FloorRequest = (COMMON-HEADER)
1*(FLOOR-ID)
[BENEFICIARY-ID]
[PARTICIPANT-PROVIDED-INFO]
[PRIORITY]
*[EXTENSION-ATTRIBUTE]Figure 31: FloorRequest format
5.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, which is lowkey so useful 🙈 here's the format:
FloorRelease = (COMMON-HEADER)
(FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE]Figure 32: FloorRelease format
5.3.3. FloorRequestQuery 🔥
floor participants and floor chairs ask for info about a floor request by sending a FloorRequestQuery message to the floor control server. the format:
FloorRequestQuery = (COMMON-HEADER)
(FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE]Figure 33: FloorRequestQuery format
5.3.4. FloorRequestStatus 💅
the floor control server tells floor participants and floor chairs what's going on with their floor requests by sending them FloorRequestStatus messages. the format:
FloorRequestStatus = (COMMON-HEADER)
(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE]Figure 34: FloorRequestStatus format
5.3.5. UserQuery 🎀
floor participants and floor chairs ask for info about a participant and the floor requests tied to that participant by sending a UserQuery message to the floor control server. format:
UserQuery = (COMMON-HEADER)
[BENEFICIARY-ID]
*[EXTENSION-ATTRIBUTE]Figure 35: UserQuery format
5.3.6. UserStatus 🌈
the floor control server gives out info about participants and their related floor requests to floor participants and floor chairs by sending UserStatus messages. the format:
UserStatus = (COMMON-HEADER)
[BENEFICIARY-INFORMATION]
*(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE]Figure 36: UserStatus format
5.3.7. FloorQuery 🍓
floor participants and floor chairs ask about a floor or floors by sending a FloorQuery message to the floor control server. the format (the text in this section says FloorRequest, which is what the original says too, so don't be confused 🙈):
FloorQuery = (COMMON-HEADER)
*(FLOOR-ID)
*[EXTENSION-ATTRIBUTE]Figure 37: FloorQuery format
5.3.8. FloorStatus ⭐
the floor control server tells floor participants and floor chairs about the status of a floor (like who the current holder is) by sending FloorStatus messages. format:
FloorStatus = (COMMON-HEADER)
*1(FLOOR-ID)
*[FLOOR-REQUEST-INFORMATION]
*[EXTENSION-ATTRIBUTE]Figure 38: FloorStatus format
5.3.9. ChairAction 👑
floor chairs send instructions to floor control servers by sending ChairAction messages. format:
ChairAction = (COMMON-HEADER)
(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE]Figure 39: ChairAction format
5.3.10. ChairActionAck ✨
floor control servers confirm they accepted a ChairAction message by sending a ChairActionAck message. format:
ChairActionAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]Figure 40: ChairActionAck format
5.3.11. Hello 🧚
floor participants and floor chairs check that floor control servers are alive by sending a Hello message. format:
Hello = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]Figure 41: Hello format
5.3.12. HelloAck 🫶
floor control servers confirm they're alive when they receive a Hello message, by sending a HelloAck message. format:
HelloAck = (COMMON-HEADER)
(SUPPORTED-PRIMITIVES)
(SUPPORTED-ATTRIBUTES)
*[EXTENSION-ATTRIBUTE]Figure 42: HelloAck format
5.3.13. Error 😭
floor control servers tell floor participants and floor chairs about errors they hit while processing requests, by sending Error messages. format:
Error = (COMMON-HEADER)
(ERROR-CODE)
[ERROR-INFO]
*[EXTENSION-ATTRIBUTE]Figure 43: Error format
6. Transport 🚚
BFCP entities swap BFCP messages over TCP connections. TCP gives in-order, reliable delivery of a stream of bytes, so message framing has to happen in the application layer. BFCP does its application-layer framing with TLV-encoded attributes 💖
a client MUST NOT use more than one TCP connection to talk to a given floor control server within a conference. the exception is if the same physical box handles different clients (like a floor chair and a floor participant) that have different User IDs, then a separate connection per client is allowed 🎀
if a BFCP entity (a client or a floor control server) gets data from TCP that 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, the TCP connection SHOULD be reestablished 😭
how the reconnection gets handled depends on how the client got the info it needs to reach the floor control server (for example, through an SDP offer/answer exchange [7]). once the TCP connection is back, the client MAY resend the messages it never got a response for 🔥
if a floor control server notices the TCP connection to one of the floor participants is lost, what it does with that participant's pending floor requests is up to its local policy 🤷♀️ either way, it is RECOMMENDED that the floor control server keeps the floor requests (so it doesn't cancel them) while the TCP connection is being reestablished 🌸
if a client wants to end its BFCP connection with a floor control server, it closes the TCP connection toward the floor control server (a graceful close). if a floor control server wants to end its BFCP connection with a client (say the Focus of the conference tells it the client got kicked out), the floor control server closes the TCP connection toward the client, also gracefully 👋
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 (that includes both floor participants and floor chairs) MUST support TLS [3]. any BFCP entity MAY support other security mechanisms too 🌈
BFCP entities MUST support, at a minimum, the TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA [5] 💅
which side acts as the TLS server (the client or the floor control server) depends on how the underlying TCP connection gets set up. for example, when the TCP connection is set up with an SDP offer/answer exchange [7], the answerer (which could be the client or the floor control server) always acts as the TLS server ✨
8. Protocol Transactions 🍓
BFCP has two kinds of transactions: client-initiated transactions and server-initiated transactions (notifications) 🧚 a client-initiated transaction is a request from a client to a floor control server, plus the floor control server's response back to the client. the request carries a Transaction ID in its common header, and the floor control server copies that ID into the response. clients use Transaction ID values to match responses to the requests they sent earlier 🦋
server-initiated transactions are just a single message from a floor control server to a client. since they don't trigger any response, their Transaction ID is set to 0 🙈
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 it got earlier 🎀
the client MUST set the Transaction ID value in the common header to a number that is different from 0 and that MUST NOT be reused in another message from the client until a response from the server is received for the transaction. the client uses that Transaction ID value to match this message with the response from the floor control server 🫶
8.2. Server Behavior 🌸
a floor control server sending a response within a client-initiated transaction MUST copy the Conference ID, the Transaction ID, and the User ID from the request it got from the client into the response 👑
server-initiated transactions MUST contain a Transaction ID equal to 0 ⭐
9. Authentication and Authorization ✨
okay bestie, clients SHOULD authenticate the floor control server before they send it any BFCP message or accept any BFCP message from it 🔐. And the vibe goes both ways: floor control servers SHOULD authenticate a client before they accept any BFCP message from it or send any BFCP message to it 🫶.
BFCP supports TLS-based mutual authentication between clients and floor control servers, as covered in Section 9.1 💜. This is the RECOMMENDED authentication mechanism in BFCP, so it's the one to reach for first 👑.
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 allowed to do what it's asking for. If not, the server generates an Error message, 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-Based Mutual Authentication
BFCP supports TLS-based mutual authentication between clients and floor control servers 🎀. BFCP assumes there's an integrity-protected channel between the client and the floor control server. That channel is used to swap self-signed certificates or, more commonly, just the fingerprints of those certificates 🦋. These certificates get used when the TLS connection is set up.
The implementation of such an integrity-protected channel using SIP and the SDP offer/answer model is described in [7].
BFCP messages that arrive over an authenticated TLS connection count as authenticated ✨. Now, if a floor control server gets a BFCP message over TCP with no TLS, it can ask for TLS to be used by generating an Error message, described in Section 13.8, with an Error code of 9 (Use TLS) 🔒. Clients SHOULD simply ignore unauthenticated messages, no drama 🙅♀️.
Future extensions may define additional authentication mechanisms that may not require an initial integrity-protected channel (e.g., authentication based on certificates signed by a certificate authority).
Remember Section 9? Floor control servers need to do authorization before processing any message 💅. Specifically, the floor control server SHOULD check that messages arriving over a given authenticated TLS connection use an authorized User ID. That means a User ID the user who set up that authenticated TLS connection is actually allowed to use 🌸.
10. Floor Participant Operations 🧚
This section is all about how floor participants can do things, like requesting a floor, using the protocol elements from the earlier sections 🍓. Section 11 covers the stuff that's specific to floor chairs, like telling the floor control server to grant or revoke a floor 👑. Section 12 covers operations that any client can do, whether that's a floor participant or a floor chair 🫶.
10.1. Requesting a Floor
A floor participant that wants one or more floors sends a FloorRequest message to the floor control server 💖. Easy peasy.
10.1.1. Sending a FloorRequest Message
The ABNF in Section 5.3.1 lists the attributes a FloorRequest message can contain 📜. The ABNF also spells out which of those attributes are mandatory and which are optional, so that part is normative 🔥.
The floor participant sets the Conference ID and the Transaction ID in the common header, following the rules in Section 8.1 🦋.
The floor participant sets the User ID in the common header to their own identifier 🪪. The floor control server uses this User ID to authenticate and authorize the request, so it matters a lot 💜. If the sender of the FloorRequest message (identified by the User ID) isn't the participant who'd end up getting the floor, which is a third-party floor request, the sender SHOULD add a BENEFICIARY-ID attribute to the message to identify the beneficiary of the floor 🎁.
The name space for both the User ID and the Beneficiary ID is the same. In other words, a given participant is identified by a single 16-bit value. That value can be used in the User ID in the common header and in several attributes:BENEFICIARY-ID,BENEFICIARY-INFORMATION, andREQUESTED-BY-INFORMATION.
The floor participant must put in at least one FLOOR-ID attribute in the FloorRequest message 🌈. If the client includes more than one FLOOR-ID attribute, the floor control server treats all those floor requests as an atomic package. So the server will either grant all the floors in the FloorRequest message or deny all of them, no in-between 🧨.
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 at 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 🔍. When that happens, the floor participant follows the rules in Section 9 that relate to floor control server authentication 🔐.
When the floor control server successfully processes a FloorRequest message, it generates 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 floor control server 🆔. Any later FloorRequestStatus messages about that same floor request carry the same Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute, just like the first one did. That's how the floor participant can tie the incoming FloorRequestStatus messages back to the ongoing floor request 🧵.
The floor participant gets info about the status of the floor request from the FLOOR-REQUEST-INFORMATION attribute in each FloorRequestStatus message it receives 📊. That attribute is a grouped attribute, so it holds a bunch of other attributes that describe the floor request 🗂️.
The OVERALL-REQUEST-STATUS attribute tells you the overall status of the floor request 🌟. If the Request Status value is Granted, then all the floors requested in the FloorRequest message have been granted 🥳. If it's Denied, then all of them have been denied 😬. A floor request counts as ongoing while it's in the Pending, Accepted, or Granted states 🔄. If the floor request value is unknown, the response still gets processed, but there's no meaningful value to show the user 🤷♀️.
If a STATUS-INFO attribute is present, it gives extra info that the floor participant MAY display to the user 💭.
The FLOOR-REQUEST-STATUS attributes tell you the status of the floor request as it relates to one particular floor 🎯. If a STATUS-INFO attribute is present here too, it gives extra info that the floor participant MAY display to the user 💁♀️.
The BENEFICIARY-INFORMATION attribute identifies the beneficiary of the floor request in third-party floor requests 🎁. The REQUESTED-BY-INFORMATION attribute doesn't need to show up in FloorRequestStatus messages received by the floor participant that asked for the floor, because that participant is already identified by the User ID in the common header 🙋♀️.
When the PRIORITY attribute is present, it holds the priority that was requested by whoever generated 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 says what that reason is 🚨.
10.2. Cancelling a Floor Request and Releasing a Floor
A floor participant that wants to cancel an ongoing floor request sends a FloorRelease message to the floor control server 🙅♀️. Floor participants that hold a floor and want to give it up also use the FloorRelease message 🕊️.
10.2.1. Sending a FloorRelease Message
The ABNF in Section 5.3.2 lists the attributes a FloorRelease message can contain 📋. The ABNF also says which attributes are mandatory and which are optional, normatively 🧾.
The floor participant sets the Conference ID and the Transaction ID in the common header, following the rules in Section 8.1 🦋. The floor participant also sets the User ID in the common header to their own identifier 🪪. The floor control server uses that User ID to authenticate and authorize the request 🔐.
The FloorRelease message is used to release floors that were granted and to cancel ongoing floor requests. From the protocol's point of view, both count as ongoing floor requests, so using the same message for both helps resolve the race condition that happens when a FloorRelease message and a FloorGrant message cross on the wire 🤯.
The floor participant uses the FLOOR-REQUEST-ID that it got in the response to the FloorRequest message that the FloorRelease message is cancelling 🎟️.
If the floor participant requested several floors as one atomic operation (in a single FloorRequest message), then all of those floors are released as an atomic operation too. That means they're all released 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 FloorRequest message, as described in Section 8.1 🔍. When that's the case, 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 (inside the FLOOR-REQUEST-INFORMATION grouped attribute) will be Cancelled or Released 🌷.
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 🚨.
It's possible for the FloorRelease message to cross on the wire with a FloorRequestStatus message from the server whose Request Status isn't Cancelled or Released 🔀. Either way, that FloorRequestStatus message isn't a response to the FloorRelease message, since its Transaction ID won't match the FloorRelease's Transaction ID 🙈.
11. Chair Operations 👑
This section explains how floor chairs can tell the floor control server to grant or revoke a floor, using the protocol elements from the earlier sections 💅.
Floor chairs that want to send instructions to a floor control server do it by sending a ChairAction message 📨✨.
11.1. Sending a ChairAction Message ✨
Okay so the ABNF in Section 5.3.9 is where you look up which attributes a ChairAction message can carry 📖 It also says which ones are mandatory and which are optional, so that's your source of truth 💅
The floor chair sets the Conference ID and the Transaction ID in the common header, following the rules in Section 8.1 🎀 Then the floor chair sets the User ID in the common header to the floor participant's identifier 🫶 The floor control server uses that User ID to authenticate and authorize the request, so it's a big deal 🔐
The ChairAction message carries instructions for one or more floors inside one particular floor request 🦋 The floors get picked out by the FLOOR-REQUEST-STATUS attributes, and the floor request itself is identified by the FLOOR-REQUEST-INFORMATION-HEADER. Both of these ride along in the ChairAction message 💜
For example, say a floor request has two floors that depend on different floor chairs. Each chair grants its own floor inside that request 👑 Once both have granted, the floor control server grants the whole request. But if one chair denies its floor, the server denies the whole request, no matter what the other chair decided 💀
The floor chair gives the new status of the floor request, as it relates to a particular floor, using a FLOOR-REQUEST-STATUS attribute 🌸 If the new status is Accepted, the chair MAY use the Queue Position field to provide a queue position 🍓 If the chair doesn't want to provide a queue position, all the bits of the Queue Position field SHOULD be set to zero 🙈 The chair SHOULD use the status Revoked to revoke a floor that was granted (so, Granted status) 😭 and SHOULD use the status Denied to reject floor requests in any other status, like 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 MAY use the Queue Position field to provide a queue position for the floor request 💖
Note that a particular floor control server may implement a different queue for each floor containing all the floor requests that relate to that particular floor, a general queue for all floor requests, or both. Also note that a floor request may involve several floors and that aChairActionmessage may only deal with a subset of these floors (e.g., if a single floor chair is not authorized to manage all the floors). In this case, the floor control server will combine the instructions received from the different floor chairs inFLOOR-REQUEST-STATUSattributes to come up with the overall status of the floor request.
Note that, while the action of a floor chair may communicate information in the OVERALL-REQUEST-STATUS attribute, the floor control server may override, modify, or ignore this field's content. 🙅♀️
The floor chair may use STATUS-INFO attributes to state the reason 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 happens, the floor chair follows the rules in Section 9 that relate to 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 that reason is described inside the Error message 💔
12. General Client Operations 🌈
This section specifies operations that any client can perform. They aren't specific to floor participants or floor chairs, so both can do them 🫶
12.1. Requesting Information about Floors
A client can get information about the status of a floor or floors in different ways, including using BFCP and using out-of-band mechanisms 🛰️ Clients using BFCP follow the procedures in this section 📋
Clients ask for 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 describes the attributes that a FloorQuery message can contain 📖 It also specifies 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 floor control server uses this User ID to authenticate and authorize the request 🔐
The client puts in the message all the Floor IDs it wants information about 🦋 The floor control server sends periodic information about all of these floors 💜 If the client stops wanting information about a particular floor, it sends a new FloorQuery message removing the FLOOR-ID of that floor 🙅♀️ If the client doesn't want information about any floor anymore, it sends a FloorQuery message with no FLOOR-ID attribute 😭
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 FloorRequest 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 🔐
When the floor control server receives the FloorQuery message, it responds with a FloorStatus message or with an Error message 💌 If the response is a FloorStatus message, it contains information 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 information about any floor anymore), the FloorStatus message from the floor control server won't include any FLOOR-ID attribute either 🥺
FloorStatus messages that carry information about a floor contain a FLOOR-ID attribute that identifies the floor 🧚 After that attribute, the FloorStatus message contains information about the existing floor request or requests that relate to that floor 💖 The information 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 that give information about that floor request ✨
After the first FloorStatus, the floor control server keeps sending FloorStatus messages, periodically telling the client about changes on the floors it asked about 🔔
12.2. Requesting Information about Floor Requests
A client can get information about the status of one or several floor requests in different ways, including using BFCP and using out-of-band mechanisms 🛰️ Clients using BFCP follow the procedures in this section 📋
Clients ask for the current status of a floor request by sending a FloorRequestQuery message to the floor control server 🔍
Asking about a particular floor request is useful in a bunch of situations 🙌 For example, when the floor control server gets a FloorRequest message, it might choose to return FloorRequestStatus messages only when the floor request changes state (e.g., from Accepted to Granted), but not when the floor request moves up in its queue 🐢 In that case, if the user asks for it, the floor participant can use 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 describes the attributes that a FloorRequestQuery message can contain 📖 It also specifies 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 floor control server uses this User ID to authenticate and authorize the request 🔐
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 happens, the client follows the rules in Section 9 that relate to floor control server authentication 🔐
If the response is a FloorRequestStatus message, the client gets the status of the FloorRequest it asked about from 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 that reason is described in the Error message 💔
12.3. Requesting Information about a User
A client can get information about a participant, and the floor requests related to that participant, in different ways, including using BFCP and using out-of-band mechanisms 🛰️ Clients using BFCP follow the procedures in this section 📋
Clients ask for information about a participant and the floor requests related to that participant by sending a UserQuery message to the floor control server 🔍
This is handy for floor chairs or floor participants who want the display name and the URI of a particular floor participant 🪪 A floor participant can also find it useful to ask about itself 🙈 For example, say a floor participant's connectivity drops (its TCP connection with the floor control server was down for a while and eventually re-established). It may need to ask about all the floor requests associated with 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 which ones are mandatory and which ones are optional, so go check it 💅
when you send it, set the Conference ID and the Transaction ID in the common header using the rules in Section 8.1. then set the User ID in the common header to your own client identifier 🫶 the floor control server uses that User ID to authenticate and authorize the request, so it's a big deal!!
and if the floor participant you're asking about is not the client sending the UserQuery (the one named by the User ID in the common header), you MUST insert a BENEFICIARY-ID attribute. no exceptions, bestie 😭
12.3.2. Receiving a Response
a message from the floor control server counts as a response to your 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, follow the rules in Section 9 that relate to floor control server authentication.
if the response is a UserStatus message, you'll find info about the floor participant inside a BENEFICIARY-INFORMATION grouped attribute, and the status of the floor requests tied to that participant in FLOOR-REQUEST-INFORMATION attributes. the tea is all in there ☕✨
if the response is an Error message, the floor control server couldn't process your UserQuery for some reason, and the Error message explains what happened 🙈
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. simple as that 🌈
12.4.1. Sending a Hello Message
the ABNF in Section 5.3.11 describes the attributes a Hello message can contain, and it also specifies normatively which of them are mandatory and which are optional 📜
same deal for the common header: set the Conference ID and the Transaction ID following the rules in Section 8.1, and set the User ID in the common header to the client's identifier 🎀 the floor control server uses that User ID to authenticate and authorize the request.
12.4.2. Receiving Responses
a message from the floor control server counts as a response to your Hello message if it has the same Conference ID, Transaction ID, and User ID as the Hello message, as described in Section 8.1. then you follow 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 your Hello message successfully. ✨ the SUPPORTED-PRIMITVIES and SUPPORTED-ATTRIBUTES attributes tell you which primitives and which attributes the server supports, respectively. this is the good stuff 🍓
if the response is an Error message, the floor control server could not process the Hello message for some reason, and the Error message tells you why 💀
13. Floor Control Server Operations 🌸
this section is all about how floor control servers can perform different operations, like granting a floor, using the protocol elements from the earlier sections 👑
when a message arrives 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 SHOULD send an Error message, as described in Section 13.8, with Error code 3 (Unknown Primitive). 🙅♀️
when a message arrives from a client, the floor control server MUST check whether the value of the Conference ID matches an existing conference. if it doesn't, the floor control server SHOULD send an Error message, as described in Section 13.8, with Error code 1 (Conference does not Exist). 🧚
when a message arrives from a client, the floor control server follows the rules in Section 9 that relate to the authentication of the message. 🔐
when a message arrives 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 SHOULD send an Error message, as described in Section 13.8, with Error code 2 (Authentication Failed). the Error message SHOULD list the attributes that weren't understood. 📝
13.1. Reception of a FloorRequest Message
when a FloorRequest message comes in, 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 SHOULD generate an Error response following the procedures in Section 13.8. 🛡️
BFCP lets floor participants have several ongoing floor requests for the same floor (e.g., the same floor participant can occupy more than one position in a queue at the same time). a floor control server that only supports a certain number of ongoing floor requests per floor 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 floor participant know. 🙃
13.1.1. Generating the First FloorRequestStatus Message
successfully processing a FloorRequest message means the floor control server generates one or several FloorRequestStatus messages, and the first of those SHOULD be generated as soon as possible ⏩
if the floor control server can't accept, grant, or deny the floor 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 (within the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message it generates. ⏳
the policy a floor control server uses to grant or deny floors is outside the scope of this document. one server might make those calls automatically, while another might contact a human acting as a chair every single time a decision is needed. 🤷♀️
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, the floor control server 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 that is unique within the conference to this floor request, and MUST insert it in the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. 🆔 the floor participant (or a chair or chairs) will use 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. those Floor IDs identify the floors being requested, meaning the floors tied to 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. it MAY also provide the display name and the URI of the beneficiary in that 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 PARTICIPANT-PROVIDED-INFO 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 actually assigns depends on that requested priority AND the rights the participant has under the conference policy. for example, a participant who's only allowed to use Normal priority might ask for Highest priority for a floor request. in that case, the floor control server would ignore the requested priority. 👀
the floor control server MAY copy (if present) the PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute. (yes, that one's repeated on purpose, it's in the spec 🙈)
13.1.2. Generation of Subsequent FloorRequestStatus Messages
a floor request counts as ongoing for as long as it isn't in the Cancelled, Released, or Revoked states. 🔄 if the OVERALL-REQUEST-STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message didn't indicate any of those states, the floor control server will need to send subsequent FloorRequestStatus messages.
when the status of the floor request changes, the floor control server SHOULD send new FloorRequestStatus messages with the appropriate Request Status. ✨ it MUST add a FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to the one from the first FloorRequestStatus message to any new FloorRequestStatus about the same floor request. (the Floor Request ID is how a FloorRequestStatus knows which floor request it's talking about 🧠)
the floor control server MUST set the Transaction ID of subsequent FloorRequestStatus messages to 0. 0️⃣
the rate at which the floor control server sends FloorRequestStatus messages is a matter of local policy. one server might send a new FloorRequestStatus every time the floor request moves in the queue, while another might only send one when the request is Granted or Denied. 🎢
the floor control server MAY add a STATUS-INFO attribute to any of the FloorRequestStatus messages it generates, to give extra info about its decisions on the floor request (e.g., why it was denied). 💅
floor participants and floor chairs can ask to be kept in the loop about a floor's status by following the procedures in Section 12.1. if processing a floor request changes the status of a floor (e.g., the floor request is granted and so the floor 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 info. 📣
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 info about a particular floor request once it reaches a status of Cancelled, Released, or Revoked. 🧹
13.2. Reception of a FloorRequestQuery Message
okay so when a FloorRequestQuery message lands on the floor control server, it has to run through the rules in Section 9 about client authentication and authorization 🔐. If something goes sideways while it's being processed, the server SHOULD generate an Error response, following the procedures in Section 13.8 🙈.
If everything goes right, the server ends up generating a FloorRequestStatus message, and that SHOULD happen as soon as possible ⚡. no dawdling, bestie 💅
Next, the 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, it MUST include info about the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute of the FloorRequestStatus 🧚.
The 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 🦋.
It also MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute, identifying the floors being requested. These are the floors tied to the floor request that FLOOR-REQUEST-ID points to ✨.
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 display name and the URI of that beneficiary in this BENEFICIARY-INFORMATION attribute.
The server MAY share info about who requested the floor, using a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute 👑.
The server MAY include the reason the floor participant asked for the floor, in a PARTICIPANT-PROVIDED-INFO 💜.
The server MAY also add a PRIORITY attribute, showing the Priority value requested for the floor request, plus a STATUS-INFO attribute with extra info about the request 🔥.
Then there's the big one: the server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute, with the current status of the floor request 📣. And it MAY give status info about each floor being requested, through the FLOOR-REQUEST-STATUS attributes 🌈.
13.3. Reception of a UserQuery Message
on reception of a UserQuery message, the floor control server runs the Section 9 rules for client authentication and authorization, same as always 🔐. If it hits an error while processing, it SHOULD generate an Error response, following Section 13.8 💀.
A successful UserQuery gets the server to generate a UserStatus message, and that SHOULD happen as soon as possible 🌸.
The 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 🎀. (yes, the spelling is USerStatus in the original, so we keep it exactly 🙈)
Here's the vibe check: the sender of a UserQuery wants info about every floor request linked to a given participant. That means requests where the participant is 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 💖.
If a BENEFICIARY-ID is present in the UserQuery, the server MUST copy its contents into a BENEFICIARY-INFORMATION attribute in the UserStatus message 🦋. The server MAY also add the display name and URI of that participant in this BENEFICIARY-INFORMATION attribute ✨.
The server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute to the UserStatus message for each floor request tied to that participant 👑. Basically, every request where they're the beneficiary or the requester gets its own entry 💅. For every FLOOR-REQUEST-INFORMATION attribute, the server follows these steps:
The server MUST identify which floor request the FLOOR-REQUEST-INFORMATION attribute applies to, by filling in the Floor Request ID field of that attribute 🎯.
It MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute, identifying the floors being requested. Those are the floors associated with 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 the beneficiary of the floor request 🌸. It MAY include the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute too.
It MAY provide info about the requester of the floor, in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute 🧚.
It MAY provide the reason the floor participant asked for the floor, in a PARTICIPANT-PROVIDED-INFO 💜.
It MAY also add a PRIORITY attribute to the FLOOR-REQUEST-INFORMATION grouped attribute, with the Priority value requested for the floor request 🔥.
The server MUST include the current status of the floor request in an OVERALL-REQUEST-STATUS attribute, added to the FLOOR-REQUEST-INFORMATION grouped attribute 📣. It MAY add a STATUS-INFO attribute with extra info about the floor request 🎀.
And finally, it MAY give status info about each floor being requested, in the FLOOR-REQUEST-STATUS attributes 🦋.
13.4. Reception of a FloorRelease Message
when a FloorRelease message shows up, the floor control server follows the Section 9 rules for client authentication and authorization 🔐. If it runs into an error while processing, it SHOULD generate an Error response, using the procedures in Section 13.8 💀.
A successful FloorRelease means the server generates a FloorRequestStatus message, and that SHOULD happen as soon as possible ⚡.
The server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRelease message into the FloorRequestStatus message, as described in Section 8.2 🎀.
The server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes inside that grouped attribute carry info about the floor request 🧚.
The FloorRelease message says which floor request it's talking about, using a FLOOR-REQUEST-ID. So the server MUST copy the contents of that FLOOR-REQUEST-ID attribute into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute 🦋.
The server MUST identify the floors being requested (the ones tied to the floor request that FLOOR-REQUEST-ID points to) in FLOOR-REQUEST-STATUS attributes, added to the FLOOR-REQUEST-INFORMATION grouped attribute 🌈.
The server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute 📣. Here's the tea: the Request Status value SHOULD be Released if the floor (or floors) had been granted before. If they hadn't been granted, it SHOULD be Cancelled 💅. The server MAY also add a STATUS-INFO attribute with extra info about the floor request ✨.
13.5. Reception of a FloorQuery Message
on reception of a FloorQuery message, the floor control server follows the Section 9 rules that relate to client authentication 🔐. If it hits an error while processing the FloorRelease message (yes, that's the wording in the original 🙈), it SHOULD generate an Error response, following the procedures in Section 13.8 💀.
A floor control server that gets a FloorQuery from a client SHOULD keep that client in the loop about the status of the floors identified by FLOOR-ID attributes in the FloorQuery message 👑. Floor Control Servers keep clients informed by using FloorStatus messages 💌.
Each FloorStatus message carries info about a single floor 🌸. So if a FloorQuery asks about more than one floor, the floor control server needs to send separate FloorStatus messages, one for each floor 🦋.
Also, the info a FloorQuery gets back can depend on who's asking. For example, a chair may be able to see info about pending requests, while a regular user may not be authorized to see that 🧚💜. not me being jealous of the chair rn 💅
13.5.1. Generation of the First FloorStatus Message ✨
okay so when a floor control server successfully processes a FloorQuery message, it ends up making one or several FloorStatus messages 💅. The first one SHOULD go out as soon as possible 🦋.
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorQuery message into the FloorStatus message, as described in Section 8.2 💖.
If the FloorQuery message did not have any FLOOR-ID attribute, the floor control server just sends the FloorStatus message with no extra attributes added, and it doesn't send any follow-up FloorStatus message to the floor participant 🙈.
If the FloorQuery message had one or more FLOOR-ID attributes, the floor control server picks one of them and adds that FLOOR-ID attribute to the FloorStatus message. The floor control server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request associated with the floor 🌸. Each FLOOR-REQUEST-INFORMATION grouped attribute holds a bunch of attributes that give info about that floor request. For each FLOOR-REQUEST-INFORMATION attribute, the floor control server goes through the following 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 (i.e., 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. Additionally, 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 reason part is so relatable 🥺
The floor control server MAY also add a PRIORITY attribute to the FLOOR-REQUEST-INFORMATION grouped attribute, with the Priority value requested for 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 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.5.2. Generation of Subsequent FloorStatus Messages
If the FloorQuery message carried more than one FLOOR-ID attribute, the floor control server SHOULD generate a FloorStatus message for each of them (except for the FLOOR-ID attribute chosen for the first FloorStatus message) as soon as possible. These FloorStatus messages are generated following the same rules as the first FloorStatus message (see Section 13.5.1), but their Transaction ID is 0 🦋.
After generating these messages, the floor control server sends FloorStatus messages, periodically keeping the client informed about all the floors the client asked about 🫶. The Transaction ID of these messages MUST be 0.
The rate at which the floor control server sendsFloorStatusmessages is a matter of local policy 🍓. One floor control server may choose to send a newFloorStatusmessage every time a new floor request arrives, while another may choose to only send a newFloorStatusmessage when a new floor request isGranted. Different vibes, both valid 💜.
13.6. Reception of a ChairAction Message
On reception of a ChairAction message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If, while processing the ChairAction message, the floor control server runs into an error, it SHOULD generate an Error response following the procedures described in Section 13.8 🚨.
The successful processing of a ChairAction message involves generating a ChairActionAck message, which SHOULD be generated as soon as possible ⭐.
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the ChairAction message into the ChairActionAck message, as described in Section 8.2.
This part is so important bestie 🫠 The floor control server needs to take into consideration the operation requested in the ChairAction message (e.g., granting a floor), but it does not necessarily need to perform it as requested by the floor chair. The operation the floor control server performs depends on the ChairAction message and on the internal state of the floor control server.
For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well 🔒.
So the floor control server is ultimately responsible for keeping a coherent floor state, using instructions from floor chairs as input to that state 👑.
If the new Status in the ChairAction message is Accepted and all the bits of the Queue Position field are zero, the floor chair is requesting that the floor control server assign a queue position (e.g., the last in the queue) to the floor request, based on the local policy of the floor control server. (Of course, such a request only applies if the floor control server implements a queue 🎀.)
13.7. Reception of a Hello Message
On reception of a Hello message, the floor control server follows the rules in Section 9 that relate to client authentication. If, while processing the Hello message, the floor control server encounters an error, it SHOULD generate an Error response following the procedures described in Section 13.8 🙈.
The successful processing of a Hello message involves generating a HelloAck message, which SHOULD be generated 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 message, listing all the primitives (i.e., BFCP messages) supported by the floor control server.
The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to the HelloAck message, listing all the attributes supported by the floor control server.
13.8. Error Message Generation
Error messages are always sent in response to a previous message from the client, as part of a client-initiated transaction 😭. The ABNF in Section 5.3.13 describes the attributes an Error message can contain. The ABNF also specifies normatively which of these attributes are mandatory and which ones are optional.
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the message from the client into the Error message, as described in Section 8.2 💖.
The floor control server MUST add an ERROR-CODE attribute to the Error message. The ERROR-CODE attribute contains an Error Code from Table 5. Additionally, the floor control server may add an ERROR-INFO attribute with extra information about the error ✨.
14. Security Considerations 🔐
Okay this section is SERIOUS bestie, read it fr fr BFCP uses TLS to provide mutual authentication between clients and servers. TLS also provides replay and integrity protection, and confidentiality. It is RECOMMENDED that TLS with non-null encryption always be used. BFCP entities MAY use other security mechanisms, as long as they provide similar security properties 🛡️.
The rest of this section analyzes some of the threats against BFCP and how they're addressed 👀.
An attacker may attempt to impersonate a client (a floor participant or a floor chair) in order to generate forged floor requests, or to grant or deny existing floor requests. Client impersonation is avoided by having servers only accept BFCP messages over authenticated TLS connections. The floor control server assumes that attackers cannot hijack the TLS connection and, therefore, that messages over the TLS connection come from the client that was initially authenticated 🔥.
An attacker may attempt to impersonate a floor control server. A successful attacker would be able to make clients think that they hold a particular floor, so that they would try to access a resource (e.g., sending media) without having legitimate rights to access it 💀. Floor control server impersonation is avoided by having servers only accept BFCP messages over authenticated TLS connections.
Attackers may attempt to modify messages exchanged by a client and a floor control server. The integrity protection provided by TLS connections prevents this attack 🌈.
An attacker may attempt to fetch a valid message sent by a client to a floor control server and replay it over a connection between the attacker and the floor control server. This attack is prevented by having floor control servers check that messages arriving over a given authenticated TLS connection use an authorized user ID (i.e., a user ID that the user who established the authenticated TLS connection is allowed to use) 🧐.
Attackers may attempt to pick messages from the network to get access to confidential information between the floor control server and a client (e.g., why a floor request was denied). TLS confidentiality prevents this attack. Therefore, it is RECOMMENDED that TLS be used with a non-null encryption algorithm 🔒.
15. IANA Considerations 🌷
The IANA has created a new registry for BFCP parameters called "Binary Floor Control Protocol (BFCP) Parameters". This new registry has a number of subregistries, which are described in the following sections and yes, we'll get to them 🦋.
15.1. Attribute Subregistry 🎀
okay so IANA keeps a list of BFCP attributes under the BFCP Parameters registry, and this is the part that says how it works 💅 As per the terminology in RFC 2434 [4], the registration policy for BFCP attributes shall be "Specification Required". For this subregistry, any BFCP attribute that wants IANA registration MUST be defined by a standards-track RFC. That RFC MUST specify the attribute's type, name, format, and semantics. no cap, that's a lot of paperwork, but it keeps things clean ✨
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 of this subregistry 🦋
+------+---------------------------+------------+
| Type | Attribute | Reference |
+------+---------------------------+------------+
| 1 | BENEFICIARY-ID | [RFC 4582] |
| 2 | FLOOR-ID | [RFC 4582] |
| 3 | FLOOR-REQUEST-ID | [RFC 4582] |
| 4 | PRIORITY | [RFC 4582] |
| 5 | REQUEST-STATUS | [RFC 4582] |
| 6 | ERROR-CODE | [RFC 4582] |
| 7 | ERROR-INFO | [RFC 4582] |
| 8 | PARTICIPANT-PROVIDED-INFO | [RFC 4582] |
| 9 | STATUS-INFO | [RFC 4582] |
| 10 | SUPPORTED-ATTRIBUTES | [RFC 4582] |
| 11 | SUPPORTED-PRIMITIVES | [RFC 4582] |
| 12 | USER-DISPLAY-NAME | [RFC 4582] |
| 13 | USER-URI | [RFC 4582] |
| 14 | BENEFICIARY-INFORMATION | [RFC 4582] |
| 15 | FLOOR-REQUEST-INFORMATION | [RFC 4582] |
| 16 | REQUESTED-BY-INFORMATION | [RFC 4582] |
| 17 | FLOOR-REQUEST-STATUS | [RFC 4582] |
| 18 | OVERALL-REQUEST-STATUS | [RFC 4582] |
+------+---------------------------+------------+
Table 6: Initial values of the BFCP Attribute subregistry15.2. Primitive Subregistry 🌸
next up is the Primitive subregistry, also under the BFCP Parameters registry 🧚 Same vibe as before: as per RFC 2434 [4], the registration policy for BFCP primitives shall be "Specification Required". For this subregistry, any BFCP primitive that wants IANA registration MUST be defined by a standards-track RFC, and that RFC MUST specify the primitive's value, name, format, and semantics. Bestie, it's giving consistency 👑
For each BFCP primitive, IANA registers its value, its name, and the reference to the RFC where the primitive is defined. The starting lineup is:
+-------+--------------------+------------+
| Value | Primitive | Reference |
+-------+--------------------+------------+
| 1 | FloorRequest | [RFC 4582] |
| 2 | FloorRelease | [RFC 4582] |
| 3 | FloorRequestQuery | [RFC 4582] |
| 4 | FloorRequestStatus | [RFC 4582] |
| 5 | UserQuery | [RFC 4582] |
| 6 | UserStatus | [RFC 4582] |
| 7 | FloorQuery | [RFC 4582] |
| 8 | FloorStatus | [RFC 4582] |
| 9 | ChairAction | [RFC 4582] |
| 10 | ChairActionAck | [RFC 4582] |
| 11 | Hello | [RFC 4582] |
| 12 | HelloAck | [RFC 4582] |
| 13 | Error | [RFC 4582] |
+-------+--------------------+------------+
Table 7: Initial values of the BFCP primitive subregistry15.3. Request Status Subregistry 🦋
okay this one is the Request Status subregistry, also under the BFCP Parameters registry 💖 As per the terminology in RFC 2434 [4], the registration policy for BFCP request status shall be "Specification Required". For this subregistry, any BFCP request status that wants IANA registration MUST be defined by a standards-track RFC, and that RFC MUST specify the value and the semantics of the request status. ngl the rules are super consistent, I'm obsessed 🫶
For each BFCP request status, IANA registers its value, its meaning, and the reference to the RFC where the request status is defined. Here are the initial values:
+-------+-----------+------------+
| Value | Status | Reference |
+-------+-----------+------------+
| 1 | Pending | [RFC 4582] |
| 2 | Accepted | [RFC 4582] |
| 3 | Granted | [RFC 4582] |
| 4 | Denied | [RFC 4582] |
| 5 | Cancelled | [RFC 4582] |
| 6 | Released | [RFC 4582] |
| 7 | Revoked | [RFC 4582] |
+-------+-----------+------------+
Table 8: Initial values of the Request Status subregistry15.4. Error Code Subregistry 💜
last subregistry, and it's the Error Code one, also under the BFCP Parameters registry 🌈 As per the terminology in RFC 2434 [4], the registration policy for BFCP error codes shall be "Specification Required". For this subregistry, any BFCP error code that wants IANA registration MUST be defined by a standards-track RFC. That RFC MUST specify the value and the semantics of the error code, and any Error Specific Details that apply to it. bestie this is the rule of the land 👑
For each BFCP primitive, IANA registers its value, its meaning, and the reference to the RFC where the primitive is defined. Here's the starting list of error codes:
+-------+-----------------------------------------------+------------+
| Value | Meaning | Reference |
+-------+-----------------------------------------------+------------+
| 1 | Conference does not Exist | [RFC 4582] |
| 2 | User does not Exist | [RFC 4582] |
| 3 | Unknown Primitive | [RFC 4582] |
| 4 | Unknown Mandatory Attribute | [RFC 4582] |
| 5 | Unauthorized Operation | [RFC 4582] |
| 6 | Invalid Floor ID | [RFC 4582] |
| 7 | Floor Request ID Does Not Exist | [RFC 4582] |
| 8 | You have Already Reached the Maximum Number | [RFC 4582] |
| | of Ongoing Floor Requests for this Floor | |
| 9 | Use TLS | [RFC 4582] |
+-------+-----------------------------------------------+-----------+
Table 9: Initial Values of the Error Code subregistry16. Acknowledgements 🌸
shoutout to the XCON WG chairs, Adam Roach and Alan Johnston, who dropped useful ideas for this doc ✨ Also huge thanks to Xiaotao Wu, Paul Kyzivat, Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morgan, and Oscar Novo, who gave useful comments 🫶
17. References 📚
17.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
- [3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
- [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
- [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
- [7] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.
17.2. Informational References
- [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
- [9] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, February 2006.
- [10] Barnes, M. and C. Boulton, "A Framework and Data Model for Centralized Conferencing", Work in Progress, February 2005.
Authors' Addresses 🧚
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Joerg Ott
Helsinki University of Technology
Department for Electrical and Communications Engineering
Networking Laboratory
PO Box 3000
02015 TKK
Finland
EMail: jo@netlab.hut.fi
Keith Drage
Lucent Technologies
Windmill Hill Business Park
Swindon
Wiltshire SN5 6PP
UK
EMail: drage@lucent.comFull Copyright Statement ⭐
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔥
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🍓
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc4582 2006-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms