RFC 4582
The Binary Floor Control Protocol (BFCP)
5. Packet Format
BFCP packets consist of a 12-octet common header followed by attributes. All the protocol values MUST be sent in network byte order.
5.1. COMMON-HEADER Format
The following is the format of the common 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |Reserved | Primitive | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Conference ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: COMMON-HEADER format Ver: 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. The following primitive values 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 primitives
Payload 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 allows users to match a given message with its response. The value of the Transaction ID in server-initiated transactions is 0 (see Section 8). User ID: This field contains a 16-bit value that uniquely identifies a participant within a conference. The identity used by a participant in BFCP, which is carried in the User ID field, is generally mapped to the identity used by the same participant 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. Attributes are 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 format Type: 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 attributes
M: 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 is
significant for extension attributes defined in other documents only.
All attributes specified in this document MUST be understood by the
receiver so that the setting of the 'M' bit is irrelevant for these.
In all other cases, the unrecognised attribute is ignored but the
message is 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
The following is 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 format Beneficiary 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
The following is 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 format Floor ID: This field contains a 16-bit value that uniquely identifies a floor within a conference.
5.2.3. FLOOR-REQUEST-ID
The following is 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 format Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server.5.2.4. PRIORITY
The following is the format of the PRIORITY attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: PRIORITY format Prio: This field contains a 3-bit priority value, as shown in Table 3. Senders SHOULD NOT use values higher than 4 in this field. Receivers MUST treat values higher than 4 as if the value received were 4 (Highest). The default priority value when the PRIORITY attribute is missing is 2 (Normal). +-------+----------+ | Value | Priority | +-------+----------+ | 0 | Lowest | | 1 | Low | | 2 | Normal | | 3 | High | | 4 | Highest | +-------+----------+ Table 3: Priority values Reserved: At this point, the 13 bits in the reserved field SHOULD be set to zero by the sender of the message and MUST be ignored by the receiver.
5.2.5. REQUEST-STATUS
The following is the format of the REQUEST-STATUS attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: REQUEST-STATUS format Request Status: This 8-bit field contains the status of the request, as described in the following table. +-------+-----------+ | Value | Status | +-------+-----------+ | 1 | Pending | | 2 | Accepted | | 3 | Granted | | 4 | Denied | | 5 | Cancelled | | 6 | Released | | 7 | Revoked | +-------+-----------+ Table 4: Request Status values Queue Position: This 8-bit field contains, when applicable, the position of the floor request in the floor request queue at the server. If the Request Status value is different from Accepted, if the floor control server does not implement a floor request queue, or if the floor control server does not want to provide the client with this information, all the bits of this field SHOULD be set to zero. A floor request is in Pending state if the floor control server needs to contact a floor chair in order to accept the floor request, but has not done it yet. Once the floor control chair accepts the floor request, the floor request is moved to the Accepted state.
5.2.6. ERROR-CODE
The following is the format of the ERROR-CODE attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 0|M| Length | Error Code | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Error Specific Details | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: ERROR-CODE format Error Code: This 8-bit field contains an error code from the following table. If an error code is not recognised by the receiver, then the receiver MUST assume that an error exists, and therefore that the message is processed, but the 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 meaning Error Specific Details: Present only for certain Error Codes. In this document, only for Error Code 4 (Unknown Mandatory Attribute). See Section 5.2.6.1 for its definition. Padding: One, two, or three octets of padding added so that the contents of the ERROR-CODE attribute is 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.6.1. Error-Specific Details for Error Code 4
The following is the format of the Error-Specific Details field for Error Code 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Unknown Type|R| Unknown Type|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unknown Type|R| Unknown Type|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Unknown attributes format Unknown Type: These 7-bit fields contain the Types of the attributes (which were present in the message that triggered the Error message) that were unknown to the receiver. R: At this point, this bit is reserved. It SHOULD be set to zero by the sender of the message and MUST be ignored by the receiver.5.2.7. ERROR-INFO
The following is the format of the ERROR-INFO attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: ERROR-INFO format Text: This field contains UTF-8 [6] encoded text.
In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular ERROR-INFO attribute, it MAY use this language to generate the Text field. Padding: One, two, or three octets of padding added so that the contents of the ERROR-INFO attribute is 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
The following is the format of the PARTICIPANT-PROVIDED-INFO attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 0|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: PARTICIPANT-PROVIDED-INFO format Text: This field contains UTF-8 [6] encoded text. Padding: One, two, or three octets of padding added so that the contents of the PARTICIPANT-PROVIDED-INFO attribute is 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
The following is the format of the STATUS-INFO attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: STATUS-INFO format Text: This field contains UTF-8 [6] encoded text. In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular STATUS-INFO attribute, it MAY use this language to generate the Text field. Padding: One, two, or three octets of padding added so that the contents of the STATUS-INFO attribute is 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
The following is the format of the SUPPORTED-ATTRIBUTES attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: SUPPORTED-ATTRIBUTES format
Supp. Attr.: These fields contain the Types of the attributes that are supported by the floor control server in the following format: R: Reserved: This bit MUST be set to zero upon transmission and MUST be ignored upon reception. Padding: Two octets of padding added so that the contents of the SUPPORTED-ATTRIBUTES attribute is 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.11. SUPPORTED-PRIMITIVES
The following is the format of the SUPPORTED-PRIMITIVES attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 1 1|M| Length | Primitive | Primitive | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primitive | Primitive | Primitive | Primitive | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: SUPPORTED-PRIMITIVES format Primitive: These fields contain the types of the BFCP messages that are supported by the floor control server. See Table 1 for the list of BFCP primitives. Padding: One, two, or three octets of padding added so that the contents of the SUPPORTED-PRIMITIVES attribute is 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
The following is the format of the USER-DISPLAY-NAME attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 0 0|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: USER-DISPLAY-NAME format Text: This field contains the UTF-8 encoded name of the user. Padding: One, two, or three octets of padding added so that the contents of the USER-DISPLAY-NAME attribute is 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
The following is the format of the USER-URI attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 0 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: USER-URI format Text: This field contains the UTF-8 encoded user's contact URI, that is, the URI used by the user to set up the resources (e.g., media streams) that are controlled by BFCP. For example, in the context of a conference set up by SIP, the USER-URI attribute would carry the SIP URI of the user.
Messages containing a user's URI in a USER-URI attribute also
contain the user's User ID. This way, a client receiving such a
message can correlate the user's URI (e.g., the SIP URI the user
used to join a conference) with the user's User ID.
Padding: One, two, or three octets of padding added so that the
contents of the USER-URI attribute is 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
The BENEFICIARY-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as BENEFICIARY-
INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the BENEFICIARY-INFORMATION-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 format
Beneficiary ID: This field contains a 16-bit value that uniquely
identifies a user within a conference.
The following is the ABNF (Augmented Backus-Naur Form) [2] of the
BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE
refers to extension attributes that may be defined in the future.)
BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER)
[USER-DISPLAY-NAME]
[USER-URI]
*[EXTENSION-ATTRIBUTE]
Figure 22: BENEFICIARY-INFORMATION format
5.2.15. FLOOR-REQUEST-INFORMATION
The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as FLOOR-REQUEST-
INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the FLOOR-REQUEST-INFORMATION-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 1|M| Length | Floor Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server. The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to 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
The REQUESTED-BY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as REQUESTED-BY- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the REQUESTED-BY-INFORMATION-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 1 0 0 0 0|M| Length | Requested-by ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: REQUESTED-BY-INFORMATION-HEADER format Requested-by ID: This field contains a 16-bit value that uniquely identifies a user within a conference. The following is the ABNF of the REQUESTED-BY-INFORMATION grouped attribute. (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
The FLOOR-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST-STATUS-HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-STATUS-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 1 0 0 0 1|M| Length | Floor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27: FLOOR-REQUEST-STATUS-HEADER format Floor ID: this field contains a 16-bit value that uniquely identifies a floor within a conference. The following is the ABNF of the FLOOR-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to 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 format
5.2.18. OVERALL-REQUEST-STATUS
The OVERALL-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as OVERALL-REQUEST-STATUS-HEADER, followed by a sequence of attributes. The following is the format of the OVERALL-REQUEST-STATUS-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 1 0 0 1 0|M| Length | Floor Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 29: OVERALL-REQUEST-STATUS-HEADER format Floor Request ID: this field contains a 16-bit value that identifies a floor request at the floor control server. The following is the ABNF of the OVERALL-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER) [REQUEST-STATUS] [STATUS-INFO] *[EXTENSION-ATTRIBUTE] Figure 30: OVERALL-REQUEST-STATUS format5.3. Message Format
This section contains the normative ABNF (Augmented Backus-Naur Form) [2] of the BFCP messages. Extension attributes that may be defined in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.
5.3.1. FloorRequest
Floor participants request a floor by sending a FloorRequest message to the floor control server. The following is the format of the FloorRequest message: FloorRequest = (COMMON-HEADER) 1*(FLOOR-ID) [BENEFICIARY-ID] [PARTICIPANT-PROVIDED-INFO] [PRIORITY] *[EXTENSION-ATTRIBUTE] Figure 31: FloorRequest format5.3.2. FloorRelease
Floor participants release a floor by sending a FloorRelease message to the floor control server. Floor participants also use the FloorRelease message to cancel pending floor requests. The following is the format of the FloorRelease message: FloorRelease = (COMMON-HEADER) (FLOOR-REQUEST-ID) *[EXTENSION-ATTRIBUTE] Figure 32: FloorRelease format5.3.3. FloorRequestQuery
Floor participants and floor chairs request information about a floor request by sending a FloorRequestQuery message to the floor control server. The following is the format of the FloorRequestQuery message: FloorRequestQuery = (COMMON-HEADER) (FLOOR-REQUEST-ID) *[EXTENSION-ATTRIBUTE] Figure 33: FloorRequestQuery format5.3.4. FloorRequestStatus
The floor control server informs floor participants and floor chairs about the status of their floor requests by sending them FloorRequestStatus messages. The following is the format of the FloorRequestStatus message:
FloorRequestStatus = (COMMON-HEADER) (FLOOR-REQUEST-INFORMATION) *[EXTENSION-ATTRIBUTE] Figure 34: FloorRequestStatus format5.3.5. UserQuery
Floor participants and floor chairs request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server. The following is the format of the UserQuery message: UserQuery = (COMMON-HEADER) [BENEFICIARY-ID] *[EXTENSION-ATTRIBUTE] Figure 35: UserQuery format5.3.6. UserStatus
The floor control server provides information about participants and their related floor requests to floor participants and floor chairs by sending them UserStatus messages. The following is the format of the UserStatus message: UserStatus = (COMMON-HEADER) [BENEFICIARY-INFORMATION] *(FLOOR-REQUEST-INFORMATION) *[EXTENSION-ATTRIBUTE] Figure 36: UserStatus format5.3.7. FloorQuery
Floor participants and floor chairs request information about a floor or floors by sending a FloorQuery message to the floor control server. The following is the format of the FloorRequest message: FloorQuery = (COMMON-HEADER) *(FLOOR-ID) *[EXTENSION-ATTRIBUTE] Figure 37: FloorQuery format
5.3.8. FloorStatus
The floor control server informs floor participants and floor chairs about the status (e.g., the current holder) of a floor by sending them FloorStatus messages. The following is the format of the FloorStatus message: FloorStatus = (COMMON-HEADER) *1(FLOOR-ID) *[FLOOR-REQUEST-INFORMATION] *[EXTENSION-ATTRIBUTE] Figure 38: FloorStatus format5.3.9. ChairAction
Floor chairs send instructions to floor control servers by sending ChairAction messages. The following is the format of the ChairAction message: ChairAction = (COMMON-HEADER) (FLOOR-REQUEST-INFORMATION) *[EXTENSION-ATTRIBUTE] Figure 39: ChairAction format5.3.10. ChairActionAck
Floor control servers confirm that they have accepted a ChairAction message by sending a ChairActionAck message. The following is the format of the ChairActionAck message: ChairActionAck = (COMMON-HEADER) *[EXTENSION-ATTRIBUTE] Figure 40: ChairActionAck format5.3.11. Hello
Floor participants and floor chairs check the liveliness of floor control servers by sending a Hello message. The following is the format of the Hello message: Hello = (COMMON-HEADER) *[EXTENSION-ATTRIBUTE] Figure 41: Hello format
5.3.12. HelloAck
Floor control servers confirm that they are alive on reception of a Hello message by sending a HelloAck message. The following is the format of the HelloAck message: HelloAck = (COMMON-HEADER) (SUPPORTED-PRIMITIVES) (SUPPORTED-ATTRIBUTES) *[EXTENSION-ATTRIBUTE] Figure 42: HelloAck format5.3.13. Error
Floor control servers inform floor participants and floor chairs about errors processing requests by sending them Error messages. The following is the format of the Error message: Error = (COMMON-HEADER) (ERROR-CODE) [ERROR-INFO] *[EXTENSION-ATTRIBUTE] Figure 43: Error format6. Transport
BFCP entities exchange BFCP messages using TCP connections. TCP provides an in-order reliable delivery of a stream of bytes. Consequently, message framing is implemented in the application layer. BFCP implements application-layer framing using TLV-encoded attributes. A client MUST NOT use more than one TCP connection to communicate with a given floor control server within a conference. Nevertheless, if the same physical box handles different clients (e.g., a floor chair and a floor participant), which are identified by different User IDs, a separate connection per client is allowed. If a BFCP entity (a client or a floor control server) receives data from TCP that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished. Similarly, if a TCP connection cannot deliver a BFCP message and times out, the TCP connection SHOULD be reestablished.
The way connection reestablishment is handled depends on how the client obtains information to contact the floor control server (e.g., using an SDP offer/answer exchange [7]). Once the TCP connection is reestablished, the client MAY resend those messages for which it did not get a response from the floor control server. If a floor control server detects that the TCP connection towards one of the floor participants is lost, it is up to the local policy of the floor control server what to do with the pending floor requests of the floor participant. In any case, it is RECOMMENDED that the floor control server keep the floor requests (i.e., that it does not cancel them) while the TCP connection is reestablished. If a client wishes to end its BFCP connection with a floor control server, the client closes (i.e., a graceful close) the TCP connection towards the floor control server. If a floor control server wishes to end its BFCP connection with a client (e.g., the Focus of the conference informs the floor control server that the client has been kicked out from the conference), the floor control server closes (i.e., a graceful close) the TCP connection towards the client.7. Lower-Layer Security
BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs) MUST support TLS [3]. Any BFCP entity MAY support other security mechanisms. BFCP entities MUST support, at a minimum, the TLS TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [5]. Which party, the client or the floor control server, acts as the TLS server depends on how the underlying TCP connection is established. For example, when the TCP connection is established using an SDP offer/answer exchange [7], the answerer (which may be the client or the floor control server) always acts as the TLS server.8. Protocol Transactions
In BFCP, there are two types of transactions: client-initiated transactions and server-initiated transactions (notifications). Client-initiated transactions consist of a request from a client to a floor control server and a response from the floor control server to the client. The request carries a Transaction ID in its common header, which the floor control server copies into the response. Clients use Transaction ID values to match responses with previously issued requests.
Server-initiated transactions consist of a single message from a floor control server to a client. Since they do not 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 that the client obtained previously. 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 the 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 received from the client into the response. Server-initiated transactions MUST contain a Transaction ID equal to 0.9. Authentication and Authorization
BFCP clients SHOULD authenticate the floor control server before sending any BFCP message to it or accepting any BFCP message from it. Similarly, floor control servers SHOULD authenticate a client before accepting any BFCP message from it or sending any BFCP message to it. BFCP supports TLS-based mutual authentication between clients and floor control servers, as specified in Section 9.1. This is the RECOMMENDED authentication mechanism in BFCP. Note that future extensions may define additional authentication mechanisms. In addition to authenticating BFCP messages, floor control servers need to authorize them. On receiving an authenticated BFCP message, the floor control server checks whether the client sending the message is authorized. If the client is not authorized to perform the operation being requested, the floor control server generates an Error message, as described in Section 13.8, with an Error code with a value of 5 (Unauthorized Operation). Messages from a client that cannot be authorized MUST NOT be processed further.
9.1. TLS-Based Mutual Authentication
BFCP supports TLS-based mutual authentication between clients and floor control servers. BFCP assumes that there is an integrity- protected channel between the client and the floor control server that can be used to exchange their self-signed certificates or, more commonly, the fingerprints of these certificates. These certificates are used at TLS establishment time. The implementation of such an integrity-protected channel using SIP and the SDP offer/answer model is described in [7]. BFCP messages received over an authenticated TLS connection are considered authenticated. A floor control server that receives a BFCP message over TCP (no TLS) can request the use of TLS by generating an Error message, as described in Section 13.8, with an Error code with a value of 9 (Use TLS). Clients SHOULD simply ignore unauthenticated messages. Note that 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). As described in Section 9, floor control servers need to perform authorization before processing any message. In particular, the floor control server SHOULD check that messages arriving over a given authenticated TLS connection use an authorized User ID (i.e., a User ID that the user that established the authenticated TLS connection is allowed to use).
(page 37 continued on part 3)
