|
|
|
|
|
|
IETF RFC 8855
Last modified on Tuesday, January 19th, 2021
 Permanent link to RFC 8855
 Search GitHub Wiki for RFC 8855
 Show other RFCs mentioning RFC 8855
Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 8855 Ericsson
Obsoletes: 4582 K. Drage
Category: Standards Track
ISSN: 2070-1721 T. Kristensen
Jotron
J. Ott
Technical University Munich
C. Eckel
Cisco
January 2021
The Binary Floor Control Protocol (BFCP)
 Abstract
Floor control is a means to manage joint or exclusive access to
shared resources in a (multiparty) conferencing environment.
Thereby, floor control complements other functions -- such as
conference and media session setup, conference policy manipulation,
and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP).
BFCP is used between floor participants and floor control servers,
and between floor chairs (i.e., moderators) and floor control
servers.
This document obsoletes RFC 4582.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/RFC 8855.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
2. Terminology
3. Scope
3.1. Floor Creation
3.2. Obtaining Information to Contact a Floor Control Server
3.3. Obtaining Floor-Resource Associations
3.4. Privileges of Floor Control
4. Overview of Operation
4.1. Floor Participant to Floor Control Server Interface
4.2. Floor Chair to Floor Control Server Interface
5. Packet Format
5.1. COMMON-HEADER Format
5.2. Attribute Format
5.2.1. BENEFICIARY-ID
5.2.2. FLOOR-ID
5.2.3. FLOOR-REQUEST-ID
5.2.4. PRIORITY
5.2.5. REQUEST-STATUS
5.2.6. ERROR-CODE
5.2.6.1. Error Specific Details for Error Code 4
5.2.7. ERROR-INFO
5.2.8. PARTICIPANT-PROVIDED-INFO
5.2.9. STATUS-INFO
5.2.10. SUPPORTED-ATTRIBUTES
5.2.11. SUPPORTED-PRIMITIVES
5.2.12. USER-DISPLAY-NAME
5.2.13. USER-URI
5.2.14. BENEFICIARY-INFORMATION
5.2.15. FLOOR-REQUEST-INFORMATION
5.2.16. REQUESTED-BY-INFORMATION
5.2.17. FLOOR-REQUEST-STATUS
5.2.18. OVERALL-REQUEST-STATUS
5.3. Message Format
5.3.1. FloorRequest
5.3.2. FloorRelease
5.3.3. FloorRequestQuery
5.3.4. FloorRequestStatus
5.3.5. UserQuery
5.3.6. UserStatus
5.3.7. FloorQuery
5.3.8. FloorStatus
5.3.9. ChairAction
5.3.10. ChairActionAck
5.3.11. Hello
5.3.12. HelloAck
5.3.13. Error
5.3.14. FloorRequestStatusAck
5.3.15. FloorStatusAck
5.3.16. Goodbye
5.3.17. GoodbyeAck
6. Transport
6.1. Reliable Transport
6.2. Unreliable Transport
6.2.1. Congestion Control
6.2.2. ICMP Error Handling
6.2.3. Fragmentation Handling
6.2.4. NAT Traversal
7. Lower-Layer Security
8. Protocol Transactions
8.1. Client Behavior
8.2. Server Behavior
8.3. Timers
8.3.1. Request Retransmission Timer, T1
8.3.2. Response Retransmission Timer, T2
8.3.3. Timer Values
9. Authentication and Authorization
9.1. TLS/DTLS Based Mutual Authentication
10. Floor Participant Operations
10.1. Requesting a Floor
10.1.1. Sending a FloorRequest Message
10.1.2. Receiving a Response
10.1.3. Reception of a Subsequent FloorRequestStatus Message
10.2. Cancelling a Floor Request and Releasing a Floor
10.2.1. Sending a FloorRelease Message
10.2.2. Receiving a Response
11. Chair Operations
11.1. Sending a ChairAction Message
11.2. Receiving a Response
12. General Client Operations
12.1. Requesting Information about Floors
12.1.1. Sending a FloorQuery Message
12.1.2. Receiving a Response
12.1.3. Reception of a Subsequent FloorStatus Message
12.2. Requesting Information about Floor Requests
12.2.1. Sending a FloorRequestQuery Message
12.2.2. Receiving a Response
12.3. Requesting Information about a User
12.3.1. Sending a UserQuery Message
12.3.2. Receiving a Response
12.4. Obtaining the Capabilities of a Floor Control Server
12.4.1. Sending a Hello Message
12.4.2. Receiving Responses
13. Floor Control Server Operations
13.1. Reception of a FloorRequest Message
13.1.1. Generating the First FloorRequestStatus Message
13.1.2. Generation of Subsequent FloorRequestStatus Messages
13.2. Reception of a FloorRequestQuery Message
13.3. Reception of a UserQuery Message
13.4. Reception of a FloorRelease Message
13.5. Reception of a FloorQuery Message
13.5.1. Generation of the First FloorStatus Message
13.5.2. Generation of Subsequent FloorStatus Messages
13.6. Reception of a ChairAction Message
13.7. Reception of a Hello Message
13.8. Error Message Generation
14. Security Considerations
15. IANA Considerations
15.1. Attributes Subregistry
15.2. Primitives Subregistry
15.3. Request Statuses Subregistry
15.4. Error Codes Subregistry
16. Changes from RFC 4582
16.1. Extensions for an Unreliable Transport
16.2. Other Changes
17. References
17.1. Normative References
17.2. Informative References
Appendix A. Example Call Flows for BFCP over an Unreliable
Transport
Appendix B. Motivation for Supporting an Unreliable Transport
B.1. Motivation
B.1.1. Alternatives Considered
B.1.1.1. ICE TCP
B.1.1.2. Teredo
B.1.1.3. GUT
B.1.1.4. UPnP IGD
B.1.1.5. NAT PMP
B.1.1.6. SCTP
B.1.1.7. BFCP over UDP Transport
Acknowledgements
Authors' Addresses
1. Introduction
Within a conference, some applications need to manage the access to a
set of shared resources, such as the right to send media to a
particular media session. Floor control enables such applications to
provide users with coordinated (shared or exclusive) access to these
resources.
The Requirements for Floor Control Protocol [18] list a set of
requirements that need to be met by floor control protocols. The
Binary Floor Control Protocol (BFCP), which is specified in this
document, meets these requirements.
In addition, BFCP has been designed so that it can be used in low-
bandwidth environments. The binary encoding used by BFCP achieves a
small message size (when message signatures are not used) that keeps
the time it takes to transmit delay-sensitive BFCP messages to a
minimum. Delay-sensitive BFCP messages include FloorRequest,
FloorRelease, FloorRequestStatus, and ChairAction. It is expected
that future extensions to these messages will not increase the size
of these messages in a significant way.
The remainder of this document is organized as follows: Section 2
defines the terminology used throughout this document, Section 3
discusses the scope of BFCP (i.e., which tasks fall within the scope
of BFCP and which ones are performed using different mechanisms),
Section 4 provides a non-normative overview of BFCP operation. The
subsequent sections provide the normative specification of BFCP.
Section 16 summarizes changes from RFC 4582 [3].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [1] [10] when, and only when, they appear in all capitals, as
shown here.
Media Participant: An entity that has access to the media resources
of a conference (e.g., it can receive a media stream). In floor-
controlled conferences, a given media participant is typically co-
located with a floor participant, but it does not need to be.
Third-party floor requests consist of having a floor participant
request a floor for a media participant when they are not co-
located. The protocol between a floor participant and a media
participant (that are not co-located) is outside the scope of this
document.
Client: A floor participant or a floor chair that communicates with
a floor control server using BFCP.
Floor: A temporary permission to access or manipulate a specific
shared resource or set of resources.
Floor Chair: A logical entity that manages one floor (grants,
denies, or revokes a floor). An entity that assumes the logical
role of a floor chair for a given transaction may assume a
different role (e.g., floor participant) for a different
transaction. The roles of floor chair and floor participant are
defined on a transaction-by-transaction basis. BFCP transactions
are defined in Section 8.
Floor Control: A mechanism that enables applications or users to
gain safe and mutually exclusive or non-exclusive input access to
the shared object or resource.
Floor Control Server: A logical entity that maintains the state of
the floor(s), including which floors exists, who the floor chairs
are, who holds a floor, etc. Requests to manipulate a floor are
directed at the floor control server. The floor control server of
a conference may perform other logical roles (e.g., floor
participant) in another conference.
Floor Participant: A logical entity that requests floors, and
possibly information about them, from a floor control server. An
entity that assumes the logical role of a floor participant for a
given transaction may assume a different role (e.g., a floor
chair) for a different transaction. The roles of floor
participant and floor chair are defined on a transaction-by-
transaction basis. BFCP transactions are defined in Section 8.
In floor-controlled conferences, a given floor participant is
typically co-located with a media participant, but it does not
need to be. Third-party floor requests consist of having a floor
participant request a floor for a media participant when they are
not co-located.
Participant: An entity that acts as a floor participant, as a media
participant, or as both.
BFCP Connection: A transport association between BFCP entities, used
to exchange BFCP messages.
Transaction Failure Window: When communicating over an unreliable
transport, this is some period of time less than or equal to
T1*2^(4) (see Section 8.3). For reliable transports, this period
of time is unbounded.
3. Scope
As stated earlier, BFCP is a protocol to coordinate access to shared
resources in a conference following the requirements defined in [18].
Floor control complements other functions defined in the Centralized
Conferencing (XCON) Framework [19]. The floor control protocol BFCP
defined in this document only specifies a means to arbitrate access
to floors. The rules and constraints for floor arbitration and the
results of floor assignments are outside the scope of this document
and are defined by other protocols [19].
Figure 1 shows the tasks that BFCP can perform.
+---------+
| Floor |
| Chair |
| |
+---------+
^ |
| |
Notification | | Decision
| |
| |
Floor | v
+-------------+ Request +---------+ +-------------+
| Floor |----------->| Floor | Notification | Floor |
| Participant | | Control |------------->| Participant |
| |<-----------| Server | | |
+-------------+ Granted or +---------+ +-------------+
Denied
Figure 1: Functionality provided by BFCP
BFCP provides a means:
* for floor participants to send floor requests to floor control
servers.
* for floor control servers to grant or deny requests to access a
given resource from floor participants.
* for floor chairs to send floor control servers decisions regarding
floor requests.
* for floor control servers to keep floor participants and floor
chairs informed about the status of a given floor or a given floor
request.
Even though tasks that do not belong to the previous list are outside
the scope of BFCP, some of these out-of-scope tasks relate to floor
control and are essential for creating floors and establishing BFCP
connections between different entities. In the following
subsections, we discuss some of these tasks and mechanisms to perform
them.
3.1. Floor Creation
The association of a given floor with a resource or a set of
resources (e.g., media streams) is out of the scope of BFCP as
described in [19]. Floor creation and termination are also outside
the scope of BFCP; these aspects are handled using the conference
control protocol for manipulating the conference object.
Consequently, the floor control server needs to stay up to date on
changes to the conference object (e.g., when a new floor is created).
Conference control clients using Centralized Conferencing
Manipulation Protocol (CCMP) [23] can specify such floor-related
settings in the <floor-information> element [22] of the to-be created
conference object provided in the body of a CCMP confRequest/create
message issued to the conference control server.
3.2. Obtaining Information to Contact a Floor Control Server
A client needs a set of data in order to establish a BFCP connection
to a floor control server. These data include the transport address
of the server, the conference identifier, and a user identifier.
Clients can obtain this information in different ways. One is to use
a Session Description Protocol (SDP) offer/answer [17] exchange,
which is described in [12]. How to establish a connection to a BFCP
floor control server is outside the context of an offer/answer
exchange when using a reliable transport is described in [4]. Other
mechanisms are described in the XCON Framework [19] (and other
related documents). For unreliable transports, the use of an SDP
offer/answer exchange is the only specified mechanism.
3.3. Obtaining Floor-Resource Associations
Floors are associated with resources. For example, a floor that
controls who talks at a given time has a particular audio session as
its associated resource. Associations between floors and resources
are part of the conference object.
Floor participants and floor chairs need to know which resources are
associated with which floors. They can obtain this information by
using different mechanisms, such as an SDP offer/answer [17]
exchange. How to use an SDP offer/answer exchange to obtain these
associations is described in [12].
| Note that floor participants perform SDP offer/answer exchanges
| with the conference focus of the conference. So, the
| conference focus needs to obtain information about associations
| between floors and resources in order to be able to provide
| this information to a floor participant in an SDP offer/answer
| exchange.
Other mechanisms for obtaining this information, including discussion
of how the information is made available to a (SIP) focus, are
described in the XCON Framework [19] (and other related documents).
According to the conferencing system policies, conference control
clients using CCMP [23] can modify the floor settings of a conference
by issuing CCMP confRequest/update messages providing the specific
updates to the <floor-information> element of the target conference
object. More information about CCMP and BFCP interaction can be
found in [24].
3.4. Privileges of Floor Control
A participant whose floor request is granted has the right to use the
resource or resources associated with the floor that was requested.
For example, the participant may have the right to send media over a
particular audio stream.
Nevertheless, holding a floor does not imply that others will not be
able to use its associated resources at the same time, even if they
do not have the right to do so. Determination of which media
participants can actually use the resources in the conference is
discussed in the XCON Framework [19].
4. Overview of Operation
This section provides a non-normative description of BFCP operations.
Section 4.1 describes the interface between floor participants and
floor control servers, and Section 4.2 describes the interface
between floor chairs and floor control servers.
BFCP messages, which use a TLV (Type-Length-Value) binary encoding,
consist of a COMMON-HEADER followed by a set of attributes. The
COMMON-HEADER contains, among other information, a 32-bit conference
identifier. Floor participants, media participants, and floor chairs
are identified by 16-bit user identifiers.
BFCP supports nested attributes (i.e., attributes that contain
attributes). These are referred to as grouped attributes.
There are two types of transactions in BFCP: client-initiated
transactions and server-initiated transactions. Section 8 describes
both types of transactions in detail.
4.1. Floor Participant to Floor Control Server Interface
Floor participants request a floor by sending a FloorRequest message
to the floor control server. BFCP supports third-party floor
requests. That is, the floor participant sending the floor request
need not be co-located with the media participant that will get the
floor once the floor request is granted. FloorRequest messages carry
the identity of the requester in the User ID field of the COMMON-
HEADER, and the identity of the beneficiary of the floor (in third-
party floor requests) in a BENEFICIARY-ID attribute.
| Third-party floor requests can be sent, for example, by floor
| participants that have a BFCP connection to the floor control
| server but that are not media participants (i.e., they do not
| handle any media).
FloorRequest messages identify the floor or floors being requested by
carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a
FloorRequest message carries more than one floor identifier, the
floor control server treats all the floor requests as an atomic
package. That is, the floor control server either grants or denies
all the floors in the FloorRequest message.
Floor control servers respond to FloorRequest messages with
FloorRequestStatus messages, which provide information about the
status of the floor request. The first FloorRequestStatus message is
the response to the FloorRequest message from the client, and
therefore has the same Transaction ID as the FloorRequest.
Additionally, the first FloorRequestStatus message carries the Floor
Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent
FloorRequestStatus messages related to the same floor request will
carry the same Floor Request ID. This way, the floor participant can
associate them with the appropriate floor request.
Messages from the floor participant related to a particular floor
request also use the same Floor Request ID as the first
FloorRequestStatus message from the floor control server.
Figure 2 and Figure 3 show examples of call flows where BFCP is used
over a reliable transport. Appendix A shows the same call flow
examples using an unreliable transport.
Figure 2 shows how a floor participant requests a floor, obtains it,
and, at a later time, releases it. This figure illustrates the use,
among other things, of the Transaction ID and the FLOOR-REQUEST-ID
attribute.
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 floor
Figure 3 shows how a floor participant requests to be informed on the
status of a floor. The first FloorStatus message from the floor
control server is the response to the FloorQuery message and, as
such, has the same Transaction ID as the FloorQuery message.
Subsequent FloorStatus messages consist of server-initiated
transactions, and therefore their Transaction ID is 0 given this
example uses a reliable transport. FloorStatus message (2) indicates
that there are currently two floor requests for the floor whose Floor
ID is 543. FloorStatus message (3) indicates that the floor requests
with Floor Request ID 764 has been granted, and the floor request
with Floor Request ID 635 is the first in the queue. FloorStatus
message (4) indicates that the floor request with Floor Request ID
635 has been granted.
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 floor
FloorStatus messages contain information about the floor requests
they carry. For example, FloorStatus message (4) indicates that the
floor request with Floor Request ID 635 has as the beneficiary (i.e.,
the participant that holds the floor when a particular floor request
is granted) the participant whose User ID is 154. The floor request
applies only to the floor whose Floor ID is 543. That is, this is
not a multi-floor floor request.
| A multi-floor floor request applies to more than one floor
| (e.g., a participant wants to be able to speak and write on the
| whiteboard at the same time). The floor control server treats
| a multi-floor floor request as an atomic package. That is, the
| floor control server either grants the request for all floors
| or denies the request for all floors.
4.2. Floor Chair to Floor Control Server Interface
Figure 4 shows a floor chair instructing a 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.
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. In
another example, a floor chair may instruct the floor control server
to grant a floor to a participant. The floor control server needs to
revoke the floor from its current holder before granting it to the
new participant.
So, the floor control server is ultimately responsible for keeping a
coherent floor state using instructions from floor chairs as input to
this state.
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 server
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 |R|F| Res | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID |
+> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Fragment Offset (if F is set) | Fragment Length (if F is set) |
+> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+---- These fragment fields are never present
when using reliable transports
Figure 5: COMMON-HEADER format
Ver: This 3-bit field defines the version of BFCP to which this
message adheres. This specification defines two versions: 1 and
2. The version field MUST be set to 1 when using BFCP over a
reliable transport. The version field MUST be set to 2 when using
BFCP over an unreliable transport. If a floor control server
receives a message with an unsupported version field value or a
message with a version number that is not permitted with the
transport over which it was received, the server MUST indicate it
does not support the protocol version by sending an Error message
with parameter value 12 (Unsupported Version). Note that BFCP
entities supporting only the [3] subset will not support this
parameter value.
R: The Transaction Responder (R) flag bit has relevance only for use
of BFCP over an unreliable transport. When cleared, it indicates
that this message is a request initiating a new transaction, and
the Transaction ID that follows has been generated for this
transaction. When set, it indicates that this message is a
response to a previous request, and the Transaction ID that
follows is the one associated with that request. When BFCP is
used over a reliable transport, the flag has no significance and
MUST be cleared by the sender and MUST be ignored by the receiver.
F: The Fragmentation (F) flag bit has relevance only for use of BFCP
over an unreliable transport. When cleared, the message is not
fragmented. When set, it indicates that the message is a fragment
of a large, fragmented BFCP message. (The optional fields
Fragment Offset and Fragment Length described below are present
only if the F flag is set). When BFCP is used over a reliable
transport, the flag has no significance and MUST be cleared by the
sender, and the flag MUST be ignored by the receiver. In the
latter case, the receiver should also ignore the Fragment Offset
and Fragment Length fields when processing the COMMON-HEADER.
Res: The 3 bits in the reserved field MUST 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 |
+-------+-----------------------+--------------------+
| 14 | FloorRequestStatusAck | P -> S ; Ch -> S |
+-------+-----------------------+--------------------+
| 15 | FloorStatusAck | P -> S ; Ch -> S |
+-------+-----------------------+--------------------+
| 16 | Goodbye | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+
| 17 | GoodbyeAck | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+
| S: Floor Control Server |
| P: Floor Participant |
| Ch: Floor Chair |
+----------------------------------------------------+
Table 1: BFCP primitives
Payload Length: This 16-bit field contains the length of the message
in 4-octet units, excluding the COMMON-HEADER. If a floor control
server receives a message with an incorrect Payload Length field
value, the receiving server MUST send an Error message with
parameter value 13 (Incorrect Message Length) to indicate this and
then discard the message. Other entities that receive a message
with an incorrect length MUST discard the message.
| Note: BFCP is designed to achieve small message size, as
| explained in Section 1, and BFCP entities are REQUIRED to keep
| the BFCP message size smaller than the size limited by the
| 16-bit Payload Length field. To convey information not
| strictly related to floor control, other protocols should be
| used, such as the XCON Framework (cf. Section 3).
Conference ID: This 32-bit unsigned integer field identifies the
conference to which the message belongs. It is RECOMMENDED that
the conference identifier be randomly chosen. (Note that the use
of predictable conference identifiers in conjunction with a
nonsecure transport protocol makes BFCP susceptible to off-path
data injection attacks, where an attacker can forge a request or
response message.)
Transaction ID: This field contains a 16-bit value that allows users
to match a given message with its response (see Section 8).
User ID: This field contains a 16-bit unsigned integer 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.
Fragment Offset: This optional field is present only if the F flag
is set and contains a 16-bit value that specifies the number of
4-octet units contained in previous fragments, excluding the
COMMON-HEADER.
Fragment Length: This optional field is present only if the F flag
is set and contains a 16-bit value that specifies the number of
4-octet units contained in this fragment, excluding the COMMON-
HEADER. BFCP entities that receive message fragments that,
individually or collectively, exceed the Payload Length value MUST
discard the message. Additionally, if the receiver is a floor
control server, it MUST also send an Error message with parameter
value 13 (Incorrect Message Length)
5.2. Attribute Format
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 a floor control server
receives an unrecognized attribute with the 'M' bit set, the
server MUST send an Error message with parameter value 4 (Unknown
Mandatory Attribute) to indicate this. 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. Unrecognized attributes, such as those that might be
specified in future extensions, that do not have the 'M' bit set
are 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: The 13 bits in the reserved field MUST 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 recognized by the
receiver, then the receiver MUST assume that an error exists, and
therefore that the original message that triggered the Error
message to be sent 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 |
+-------+---------------------------------------------+
| 10 | Unable to Parse Message |
+-------+---------------------------------------------+
| 11 | Use DTLS |
+-------+---------------------------------------------+
| 12 | Unsupported Version |
+-------+---------------------------------------------+
| 13 | Incorrect Message Length |
+-------+---------------------------------------------+
| 14 | Generic Error |
+-------+---------------------------------------------+
Table 5: Error Code meaning
| Note: The Generic Error error code is intended to be used when
| an error occurs and the other specific error codes do not
| apply.
Error Specific Details: Present only for certain error codes. In
this document, this field is present 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 MUST be set to zero by the sender and MUST be
ignored by the receiver.
5.2.6.1. Error Specific Details for Error Code 4
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.
Reserved (R): This bit is reserved. It MUST be set to zero by the
sender of the message and MUST be ignored by the receiver.
5.2.7. ERROR-INFO
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 encoded text [9].
In some situations, the contents of the Text field may be
generated by an automaton. If this automaton has information
about the preferred language of the receiver of a particular
ERROR-INFO attribute, it MAY use this language to generate the
Text field.
Padding: One, two, or three octets of padding added so that the
contents of the ERROR-INFO attribute is 32-bit aligned. The
Padding bits MUST be set to zero by the sender and MUST be ignored
by the receiver. If the attribute is already 32-bit aligned, no
padding is needed.
5.2.8. PARTICIPANT-PROVIDED-INFO
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 encoded text [9].
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 MUST be set to zero by the sender and
MUST be ignored by the receiver. If the attribute is already
32-bit aligned, no padding is needed.
5.2.9. STATUS-INFO
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 encoded text [9].
In some situations, the contents of the Text field may be
generated by an automaton. If this automaton has information
about the preferred language of the receiver of a particular
STATUS-INFO attribute, it MAY use this language to generate the
Text field.
Padding: One, two, or three octets of padding added so that the
contents of the STATUS-INFO attribute is 32-bit aligned. The
Padding bits MUST be set to zero by the sender and MUST be ignored
by the receiver. If the attribute is already 32-bit aligned, no
padding is needed.
5.2.10. SUPPORTED-ATTRIBUTES
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 BFCP attribute types that are
supported by the floor control server. See Table 2 for the list
of BFCP attributes.
Reserved (R): This bit MUST be set to zero upon transmission and
MUST be ignored upon reception.
Padding: One, two, or three octets of padding added so 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 MUST 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 MUST 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 MUST be set to zero by the sender and MUST be
ignored by the receiver. If the attribute is already 32-bit
aligned, no padding is needed.
5.2.13. USER-URI
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 MUST be set to zero by the sender and MUST be ignored by the
receiver. If the attribute is already 32-bit aligned, no padding
is needed.
5.2.14. BENEFICIARY-INFORMATION
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) [5] 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 format
5.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 format
5.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 format
5.3. Message Format
This section contains the normative ABNF (Augmented Backus-Naur Form)
[5] 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 format
5.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 format
5.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 format
5.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 format
5.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 format
5.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 format
5.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 FloorQuery 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
*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
them ChairAction messages. The following is the format of the
ChairAction message:
ChairAction = COMMON-HEADER
FLOOR-REQUEST-INFORMATION
*EXTENSION-ATTRIBUTE
Figure 39: ChairAction format
5.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 format
5.3.11. Hello
Floor participants and floor chairs MAY check the liveness of floor
control servers by sending a Hello message. Additionally, clients
communicating with a floor control server over an unreliable
transport use the Hello message to initiate communication with the
server. 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 format
5.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 format
5.3.14. FloorRequestStatusAck
When communicating over an unreliable transport, floor participants
and chairs acknowledge the receipt of a subsequent FloorRequestStatus
message from the floor control server (cf. Section 13.1.2) by sending
a FloorRequestStatusAck message. The following is the format of the
FloorRequestStatusAck message:
FloorRequestStatusAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE
Figure 44: FloorRequestStatusAck format
5.3.15. FloorStatusAck
When communicating over an unreliable transport, floor participants
and chairs acknowledge the receipt of a subsequent FloorStatus
message from the floor control server (cf. Section 13.5.2) by sending
a FloorStatusAck message. The following is the format of the
FloorStatusAck message:
FloorStatusAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE
Figure 45: FloorStatusAck format
5.3.16. Goodbye
BFCP entities communicating over an unreliable transport that wish to
dissociate themselves from their remote participant do so through the
transmission of a Goodbye. The following is the format of the
Goodbye message:
Goodbye = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE
Figure 46: Goodbye format
5.3.17. GoodbyeAck
BFCP entities communicating over an unreliable transport acknowledge
the receipt of a Goodbye message from a peer. The following is the
format of the GoodbyeAck message:
GoodbyeAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE
Figure 47: GoodbyeAck format
6. Transport
The transport over which BFCP entities exchange messages depends on
the information the clients obtain for contacting the floor control
server, as described in Section 3.2. Two transports are supported:
TCP, which is appropriate where connectivity is not impeded by
network elements such as NAT devices or media relays; and UDP for
those deployments where TCP may not be applicable or appropriate.
| Note: In practice, products are configured to try one transport
| first and then use the other transport as a fallback. Whether
| TCP or UDP is chosen as underlying transport depends on the
| type of product and the deployment environment. See Appendix B
| for additional considerations.
6.1. Reliable Transport
BFCP entities may elect to exchange BFCP messages using TCP
connections. TCP provides an in-order reliable delivery of a stream
of bytes. Consequently, message framing needs to be 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
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 or receives an
ICMP port unreachable message mid-connection, 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. 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 of the conference), the floor control server closes (i.e.,
a graceful close) the TCP connection towards the client.
In cases where a BFCP entity reestablishes a connection due to
protocol errors as described above, the entity SHOULD NOT repeatedly
reestablish the connection. Rather, if the same protocol errors
persist, the entity MUST cease attempts and SHOULD report the error
to the human user and/or log the event. This does not preclude the
entity from reestablishing a connection when facing a different set
of errors. That said, entities MUST avoid overloading the server
with reestablishment requests. A connection MUST NOT be
reestablished too frequently. The frequency is a matter of
implementation, but SHOULD NOT be attempted more than once in a 30
second period of time.
6.2. Unreliable Transport
BFCP entities may elect to exchange BFCP messages using UDP
datagrams. UDP is an unreliable transport where neither delivery nor
ordering is assured. Each BFCP UDP datagram MUST contain exactly one
BFCP message or message fragment. To keep large BFCP messages from
being fragmented at the IP layer, the fragmentation of BFCP messages
that exceed the path MTU size is performed at the BFCP level.
Considerations related to fragmentation are covered in Section 6.2.3.
The message format for BFCP messages is the same regardless of
whether the messages are sent in UDP datagrams or over a TCP stream.
Clients MUST announce their presence to the floor control server by
sending a Hello message. The floor control server responds to the
Hello message with a HelloAck message. The client considers the
floor control server as present and available only upon receiving the
HelloAck message. The behavior when timers fire, including the
determination that a connection is broken, is described in
Section 8.3.
As described in Section 8, each request sent by a floor participant
or chair forms a client transaction that expects an acknowledgement
message from the floor control server within a transaction failure
window. Concordantly, messages sent by the floor control server that
initiate new transactions (e.g., FloorStatus announcements as part of
a FloorQuery subscription) require acknowledgement messages from the
floor participant and chair entities to which they were sent.
If a floor control server receives data that cannot be parsed, the
receiving server MUST send an Error message with parameter value 10
(Unable to Parse Message) indicating receipt of a malformed message,
given that it is possible to parse the received message to such an
extent that an Error message may be built.
Entities MUST have at most one outstanding request transaction per
peer at any one time. Implicit subscriptions occur for a client-
initiated request transaction whose acknowledgement is implied by the
first server-initiated response for that transaction, followed by
zero of more subsequent server-initiated messages corresponding to
the same transaction. An example is a FloorRequest message for which
there are potentially multiple responses from the floor control
server as it processes intermediate states until a terminal state
(e.g., Granted or Denied) is attained. The subsequent changes in
state for the request are new transactions whose Transaction ID is
determined by the floor control server and whose receipt by the
client participant is acknowledged with a FloorRequestStatusAck
message.
By restricting entities to having at most one pending transaction
open in a BFCP connection, both the out-of-order receipt of messages
as well as the possibility for congestion are mitigated. Additional
details regarding congestion control are provided in Section 6.2.1.
If a participant receives a server-initiated request (e.g., a
FloorStatus from the floor control server) while waiting for a
response to a client-initiated transaction (e.g., the participant
sent a FloorRequest and is waiting for a FloorRequestStatus
response), then the participant MUST treat the server-initiated
request as superseding any response to its client-initiated
transaction. As the floor control server cannot send a second update
to the implicit floor status subscription until the first is
acknowledged, ordinality is maintained.
If a client wishes to end its BFCP connection with a floor control
server, it is REQUIRED that the client send a Goodbye message to
dissociate itself from any allocated resources. 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), it is REQUIRED that
the floor control server send a Goodbye message towards the client.
6.2.1. Congestion Control
BFCP may be characterized as generating "low data-volume" traffic,
per the classification in [15]. Nevertheless, it is necessary to
ensure that suitable and necessary congestion control mechanisms are
used for BFCP over UDP. As described in Section 6.2, within the same
BFCP connection, every entity -- client or server -- is only allowed
to send one request at a time, and await the acknowledging response.
This way, at most one datagram is sent per RTT given the message is
not lost during transmission. If the message is lost, the request
retransmission timer T1 specified in Section 8.3.1 will fire, and the
message is retransmitted up to three times, in addition to the
original transmission of the message. The default initial interval
MUST be set to 500 ms, but is adjusted dynamically as described in
Section 8.3.1. The interval MUST be doubled after each
retransmission attempt. This is similar to the specification of the
timer A and its initial value T1 in SIP as described in
Section 17.1.1.2 of [20], except that the value of T1 in this
protocol is not fixed from one transaction to another.
6.2.2. ICMP Error Handling
ICMP is not usable when BFCP is running over an unreliable transport
due to risks associated with off-path attacks. Any ICMP messages
associated with BFCP running over an unreliable transport MUST be
ignored.
6.2.3. Fragmentation Handling
When using UDP, a single BFCP message could be fragmented at the IP
layer if its overall size exceeds the path MTU of the network. To
avoid this happening at the IP layer, a fragmentation scheme for BFCP
is defined below.
BFCP is designed for achieving small message size, due to the binary
encoding as described in Section 1. The fragmentation scheme is
therefore deliberately kept simple and straightforward, since the
probability of fragmentation of BFCP messages is small. By design,
the fragmentation scheme does not acknowledge individual BFCP message
fragments. The whole BFCP message is acknowledged if received
completely.
BFCP entities SHOULD consider the path MTU size available between the
sender and the receiver and MAY run MTU discovery, such as described
in [25], [26], and [27], for this purpose.
When transmitting a BFCP message with a size greater than the path
MTU, the sender MUST fragment the message into a series of N
contiguous data ranges. The size of each of these N messages MUST be
smaller than the path MTU to help prevent fragmentation overlap
attacks. The value for N is defined as ceil((message size -- COMMON-
HEADER size) / (path MTU size -- COMMON-HEADER size)), where ceil is
the integer ceiling function, and the COMMON-HEADER size includes the
Fragment Offset and Fragment Length fields. The sender then creates
N BFCP fragment messages (one for each data range) with the same
Transaction ID. The size of each of these N messages, with the
COMMON-HEADER included, MUST be smaller than the path MTU. The F
flag in the COMMON-HEADER in all the fragments is set to indicate
fragmentation of the BFCP message.
For each of these fragments, the Fragment Offset and Fragment Length
fields are included in the COMMON-HEADER. The Fragment Offset field
denotes the number of 4-octet units contained in the previous
fragments, excluding the COMMON-HEADER. The Fragment Length contains
the length of the fragment itself, also excluding the COMMON-HEADER.
Note that the Payload Length field contains the length of the entire,
unfragmented message.
When a BFCP implementation receives a BFCP message fragment, it MUST
buffer the fragment until either it has received the entire BFCP
message, or until the Response Retransmission Timer expires. The
state machine should handle the BFCP message only after all the
fragments of the message have been received.
If a fragment of a BFCP message is lost, the sender will not receive
an acknowledgement for the message. Therefore the sender will
retransmit the message with same transaction ID as specified in
Section 8.3. If the acknowledgement message sent by the receiver is
lost, then the entire message will be resent by the sender. The
receiver MUST then retransmit the acknowledgement. The receiver MAY
discard an incomplete buffer utilizing the Response Retransmission
Timer, starting the timer after the receipt of the first fragment.
| A Denial of Service (DoS) attack utilizing the fragmentation
| scheme described above is mitigated by the fact that the
| Response Retransmission Timer is started after receipt of the
| first BFCP message fragment. In addition, the Payload Length
| field can be compared with the Fragment Offset and Fragment
| Length fields to verify the message fragments as they arrive.
| To make DoS attacks with spoofed IP addresses difficult, BFCP
| entities SHOULD use the cookie exchange mechanism in DTLS [8].
When deciding the size of the message fragment based on path MTU, the
BFCP fragmentation handling should take into account how the DTLS
record framing expands the datagram size as described in
Section 4.1.1.1 of [8].
6.2.4. NAT Traversal
One of the key benefits of using UDP for BFCP communication is the
ability to leverage the existing NAT traversal infrastructure and
strategies deployed to facilitate transport of the media associated
with the video conferencing sessions. Depending on the given
deployment, this infrastructure typically includes some subset of
Interactive Connectivity Establishment (ICE) [16].
In order to facilitate the initial establishment of NAT bindings, and
to maintain those bindings once established, BFCP entities using an
unreliable transport are RECOMMENDED to use STUN [14] Binding
Indication for keepalives, as described for ICE [16]. Section 6.7 of
[28] provides useful recommendations for middlebox interaction when
DTLS is used.
| Note: Since the version number is set to 2 when BFCP is used
| over an unreliable transport, cf. the Ver field in Section 5.1,
| it is straightforward to distinguish between STUN and BFCP
| packets even without checking the STUN magic cookie [14].
In order to facilitate traversal of BFCP packets through NATs, BFCP
entities using an unreliable transport are RECOMMENDED to use
symmetric ports for sending and receiving BFCP packets, as
recommended for RTP/RTP Control Protocol (RTCP) [13].
7. Lower-Layer Security
BFCP 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 for transport over TCP [11] and MUST support DTLS
[8] for transport over UDP. Any BFCP entity MAY support other
security mechanisms.
BFCP entities MUST support, at a minimum, the
TLS_RSA_WITH_AES_128_CBC_SHA cipher suite [7] for backwards
compatibility with existing implementations of RFC 4582. In
accordance with the recommendations and guidelines in [30], BFCP
entities SHOULD support the following cipher suites:
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
8. Protocol Transactions
In BFCP, there are two types of transactions: client-initiated
transactions and server-initiated transactions.
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.
Server-initiated transactions have different requirements and
behavior depending on underlying transport:
When using a reliable transport, server-initiated transactions
consist of a single message from a floor control server to a
client (notifications). They do not trigger any response.
When using an unreliable transport, server-initiated transactions
consist of a request from a floor control server to a client and a
response from the client to the floor control server.
When using BFCP over an unreliable transport, retransmission timer T1
(see Section 8.3) MUST be used for all requests until the transaction
is completed. Note that while T1 varies over time, it remains
constant for the duration of a given transaction and is only updated
at the completion of a transaction.
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. When using BFCP over an unreliable transport, it is
important to choose a Transaction ID value that lets the receiver
distinguish the reception of the next message in a sequence of BFCP
messages from a retransmission of a previous message. Therefore,
BFCP entities using an unreliable transport MUST use monotonically
increasing Transaction ID values (except for wrap-around).
A client receiving a server-initiated transaction over an unreliable
transport MUST copy the Transaction ID from the request received from
the server into the response.
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
zero when BFCP is used over a reliable transport. Over an unreliable
transport, the Transaction ID shall have the same properties as for
client-initiated transactions. The server uses the Transaction ID
value to match this message with the response from the floor
participant or floor chair.
8.3. Timers
When BFCP entities are communicating over an unreliable transport,
two retransmission timers are employed to help mitigate the loss of
datagrams. Retransmission and response caching are not required when
BFCP entities communicate over a reliable transport.
8.3.1. Request Retransmission Timer, T1
T1 is a timer that schedules retransmission of a request until an
appropriate response is received or until the maximum number of
retransmissions has occurred. The timer is computed using the
smoothed round-trip time algorithm defined in [2] with an initial
retransmission timeout (RTO) value of 500 ms and clock granularity
(G) of 100 ms. In contrast to step 2.4 of Section 2 of [2], if the
computed value of RTO is less than 500 ms, then RTO shall be set to
500 ms. Timer T1 MUST be adjusted with the reception of a response
to each request transmitted in order to compute an accurate RTO
value, which is the effective T1 value. The RTT value R is the time
in milliseconds from the time when a request is transmitted to the
time the initial response to that request is received. Responses to
retransmitted packets MUST NOT be used to recompute the RTO value, as
one cannot determine if a response is to an initial or retransmitted
request. If T1 always expires on the initial transmission of a new
request, this would suggest the recommended initial T1 (and RTO)
value is too low and SHOULD be increased by doubling the initial
values of T1 (and RTO) until T1 does not expire when sending a new
request.
When retransmitting a request, timer T1 is doubled with each
retransmission, failing after three unacknowledged retransmission
attempts.
If a valid response is not received for a client- or server-initiated
transaction, the implementation MUST consider the BFCP connection as
broken. Implementations SHOULD follow the reestablishment procedure
described in Section 6.
8.3.2. Response Retransmission Timer, T2
T2 is a timer that, when fired, signals that the BFCP entity can
release knowledge of the transaction against which it is running. It
is started upon the first transmission of the response to a request
and is the only mechanism by which that response is released by the
BFCP entity. Any subsequent retransmissions of the same request can
be responded to by replaying the cached response, while that value is
retained until the timer has fired. Refer to Section 6.2.3 for this
timer's role in the fragmentation handling scheme.
8.3.3. Timer Values
The table below defines the different timers required when BFCP
entities communicate over an unreliable transport.
+=======+======================================+=================+
| Timer | Description | Value/s |
+=======+======================================+=================+
| T1 | Initial request retransmission timer | 0.5 s (initial) |
+-------+--------------------------------------+-----------------+
| T2 | Response retransmission timer | (T1*2^(4))*1.25 |
+-------+--------------------------------------+-----------------+
Table 6: Timers
The initial value for T1 is 500 ms, which is an estimate of the RTT
for completing the transaction. Computation of this value follows
the procedures described in Section 8.3.1, which includes exponential
backoffs on retransmissions.
T2 MUST be set such that it encompasses all legal retransmissions per
T1 plus a factor to accommodate network latency between BFCP
entities, processing delays, etc.
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.
If the signaling or control protocol traffic used to set up the
conference is authenticated and confidentiality and integrity
protected, and the extensions in this document are supported, the
BFCP clients MUST authenticate the floor control server, and the
floor control servers MUST authenticate the client before
communicating as described above. Note that BFCP entities supporting
only the [3] subset may not comply with this mandatory authentication
requirement.
BFCP supports TLS/DTLS mutual authentication between clients and
floor control servers, as specified in Section 9.1. This is the
RECOMMENDED authentication mechanism in BFCP.
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/DTLS Based Mutual Authentication
BFCP supports TLS/DTLS based mutual authentication between clients
and floor control servers. If TLS/DTLS is used, an initial
integrity-protected channel is REQUIRED between the client and the
floor control server that can be used to exchange their certificates
(which MAY be self-signed certificates) or, more commonly, the
fingerprints of these certificates. These certificates are used at
TLS/DTLS establishment time.
| The implementation of such an integrity-protected channel using
| SIP and the SDP offer/answer model is described in [12].
BFCP messages received over an authenticated TLS/DTLS connection are
considered authenticated. A floor control server that receives a
BFCP message over TCP/UDP (no TLS/DTLS) MAY request the use of TLS/
DTLS by generating an Error message, as described in Section 13.8,
with an error code with a value of 9 (Use TLS) or a value of 11 (Use
DTLS) respectively. Clients configured to require the use of TLS/
DTLS MUST 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 MUST check that messages arriving over a given
authenticated TLS/DTLS connection use an authorized User ID (i.e., a
User ID that the user that established the authenticated TLS/DTLS
connection is allowed to use).
10. Floor Participant Operations
This section specifies how floor participants can perform different
operations, such as requesting a floor, using the protocol elements
described in earlier sections. Section 11 specifies operations that
are specific to floor chairs, such as instructing the floor control
server to grant or revoke a floor, and Section 12 specifies
operations that can be performed by any client (i.e., both floor
participants and floor chairs).
10.1. Requesting a Floor
A floor participant that wishes to request one or more floors does so
by sending a FloorRequest message to the floor control server.
10.1.1. Sending a FloorRequest Message
The ABNF in Section 5.3.1 describes the attributes that a
FloorRequest message can contain. In addition, the ABNF specifies
normatively which of these attributes are mandatory, and which ones
are optional.
The floor participant sets the Conference ID and the Transaction ID
in the COMMON-HEADER following the rules given in Section 8.1.
The floor participant sets the User ID in the COMMON-HEADER to the
floor participant's identifier. If the sender of the FloorRequest
message (identified by the User ID) is not the participant that would
eventually get the floor (i.e., a third-party floor request), the
sender SHOULD add a BENEFICIARY-ID attribute to the message
identifying the beneficiary of the floor.
| Note that the namespace for both the User ID and the
| Beneficiary ID is the same. That is, a given participant is
| identified by a single 16-bit value that can be used in the
| User ID in the COMMON-HEADER and in several attributes:
| BENEFICIARY-ID, BENEFICIARY-INFORMATION, and REQUESTED-BY-
| INFORMATION.
The floor participant MUST insert at least one FLOOR-ID attribute in
the FloorRequest message. If the client inserts more than one FLOOR-
ID attribute, the floor control server will treat all the floor
requests as an atomic package. That is, the floor control server
will either grant or deny all the floors in the FloorRequest message.
The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute
to state the reason why the floor or floors are being requested. The
Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for
human consumption.
The floor participant may request that the server handle the floor
request with a certain priority using a PRIORITY attribute.
10.1.2. Receiving a Response
A message from the floor control server is considered a response to
the FloorRequest message if the message from the floor control server
has the same Conference ID, Transaction ID, and User ID as the
FloorRequest message, as described in Section 8.1. On receiving such
a response, the floor participant follows the rules in Section 9 that
relate to floor control server authentication.
The successful processing of a FloorRequest message at the floor
control server involves generating one or several FloorRequestStatus
messages. The floor participant obtains a Floor Request ID in the
Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in
the first FloorRequestStatus message from the floor control server.
Subsequent FloorRequestStatus messages from the floor control server
regarding the same floor request will carry the same Floor Request ID
in a FLOOR-REQUEST-INFORMATION attribute as the initial
FloorRequestStatus message. This way, the floor participant can
associate subsequent incoming FloorRequestStatus messages with the
ongoing floor request.
The floor participant obtains information about the status of the
floor request in the FLOOR-REQUEST-INFORMATION attribute of each of
the FloorRequestStatus messages received from the floor control
server. This attribute is a grouped attribute, and as such it
includes a number of attributes that provide information about the
floor request.
The OVERALL-REQUEST-STATUS attribute provides information about the
overall status of the floor request. If the Request Status value is
Granted, all the floors that were requested in the FloorRequest
message have been granted. If the Request Status value is Denied,
all the floors that were requested in the FloorRequest message have
been denied. A floor request is considered to be ongoing while it is
in the Pending, Accepted, or Granted states. If the floor request
value is unknown, then the response is still processed. However, no
meaningful value can be reported to the user.
The STATUS-INFO attribute, if present, provides extra information
that the floor participant can display to the user.
The FLOOR-REQUEST-STATUS attributes provide information about the
status of the floor request as it relates to a particular floor. The
STATUS-INFO attribute, if present, provides extra information that
the floor participant can 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 need not be present in FloorRequestStatus
messages received by the floor participant that requested the floor,
as this floor participant is already identified by the User ID in the
COMMON-HEADER.
The PRIORITY attribute, when present, contains the priority that was
requested by the generator of the FloorRequest message.
If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is
described in the Error message.
10.1.3. Reception of a Subsequent FloorRequestStatus Message
When communicating over an unreliable transport and upon receiving a
FloorRequestStatus message from a floor control server, the
participant MUST respond with a FloorRequestStatusAck message within
the transaction failure window to complete the transaction.
10.2. Cancelling a Floor Request and Releasing a Floor
A floor participant that wishes to cancel an ongoing floor request
does so by sending a FloorRelease message to the floor control
server. The FloorRelease message is also used by floor participants
that hold a floor and would like to release it.
10.2.1. Sending a FloorRelease Message
The ABNF in Section 5.3.2 describes the attributes that a
FloorRelease message can contain. In addition, the ABNF specifies
normatively which of these attributes are mandatory, and which ones
are optional.
The floor participant sets the Conference ID and the Transaction ID
in the COMMON-HEADER following the rules given in Section 8.1. The
floor participant sets the User ID in the COMMON-HEADER to the floor
participant's identifier.
| Note that the FloorRelease message is used to release a floor
| or floors that were granted and to cancel ongoing floor
| requests (from the protocol perspective, both are ongoing floor
| requests). Using the same message in both situations helps
| resolve the race condition that occurs when the FloorRelease
| message and the FloorGrant message cross each other on the
| wire.
The floor participant uses the FLOOR-REQUEST-ID that was received in
the response to the FloorRequest message that the FloorRelease
message is cancelling.
| Note that if the floor participant requested several floors as
| an atomic operation (i.e., in a single FloorRequest message),
| all the floors are released as an atomic operation as well
| (i.e., all are released at the same time).
10.2.2. Receiving a Response
A message from the floor control server is considered a response to
the FloorRelease message if the message from the floor control server
has the same Conference ID, Transaction ID, and User ID as the
FloorRelease message, as described in Section 8.1. On receiving such
a response, the floor participant follows the rules in Section 9 that
relate to floor control server authentication.
If the response is a FloorRequestStatus message, the Request Status
value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-
REQUEST-INFORMATION grouped attribute) will be Cancelled or Released.
If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is
described in the Error message.
It is possible that the FloorRelease message crosses on the wire with
a FloorRequestStatus message from the server with a Request Status
different from Cancelled or Released. In any case, such a
FloorRequestStatus message will not be a response to the FloorRelease
message, as its Transaction ID will not match that of the
FloorRelease.
11. Chair Operations
This section specifies how floor chairs can instruct the floor
control server to grant or revoke a floor using the protocol elements
described in earlier sections.
Floor chairs that wish to send instructions to a floor control server
do so by sending a ChairAction message.
11.1. Sending a ChairAction Message
The ABNF in Section 5.3.9 describes the attributes that a ChairAction
message can contain. In addition, the ABNF specifies normatively
which of these attributes are mandatory, and which ones are optional.
The floor chair sets the Conference ID and the Transaction ID in the
COMMON-HEADER following the rules given in Section 8.1. The floor
chair sets the User ID in the COMMON-HEADER to the floor chair's
identifier.
The ChairAction message contains instructions that apply to one or
more floors within a particular floor request. The floor or floors
are identified by the FLOOR-REQUEST-STATUS attributes and the floor
request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which
are carried in the ChairAction message.
For example, if a floor request consists of two floors that depend on
different floor chairs, each floor chair will grant its floor within
the floor request. Once both chairs have granted their floor, the
floor control server will grant the floor request as a whole. On the
other hand, if one of the floor chairs denies its floor, the floor
control server will deny the floor request as a whole, regardless of
the other floor chair's decision.
The floor chair provides the new status of the floor request as it
relates to a particular floor using a FLOOR-REQUEST-STATUS attribute.
If the new status of the floor request is Accepted, the floor chair
MAY use the Queue Position field to provide a queue position for the
floor request. If the floor chair does not wish to provide a queue
position, all the bits of the Queue Position field MUST be set to
zero. The floor chair MUST use the Status Revoked to revoke a floor
that was granted (i.e., Granted status) and MUST use the Status
Denied to reject floor requests in any other status (e.g., Pending
and Accepted).
The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the
ChairAction message to provide a new overall status for the floor
request. If the new overall status of the floor request is Accepted,
the floor chair can use the Queue Position field to provide a queue
position for the floor request.
| Note that a particular floor control server can 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 can involve several floors and that a ChairAction
| message can 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 in FLOOR-
| REQUEST-STATUS attributes 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 include 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 intended for human
consumption.
11.2. Receiving a Response
A message from the floor control server is considered a response to
the ChairAction message if the message from the server has the same
Conference ID, Transaction ID, and User ID as the ChairAction
message, as described in Section 8.1. On receiving such a response,
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 floor control server has accepted the ChairAction message. An
Error message indicates that the floor control server could not
process the ChairAction message for some reason, which is described
in the Error message.
12. General Client Operations
This section specifies operations that can be performed by any
client. That is, they are not specific to floor participants or
floor chairs. They can be performed by both.
12.1. Requesting Information about Floors
A client can obtain information about the status of a floor or floors
in different ways, which include using BFCP and using out-of-band
mechanisms. Clients using BFCP to obtain such information use the
procedures described in this section.
Clients request information about the status of one or several floors
by sending a FloorQuery message to the floor control server.
12.1.1. Sending a FloorQuery Message
The ABNF in Section 5.3.7 describes the attributes that a FloorQuery
message can contain. In addition, the ABNF specifies normatively
which of these attributes are mandatory, and which ones are optional.
The client sets the Conference ID and the Transaction ID in the
COMMON-HEADER following the rules given in Section 8.1. The client
sets the User ID in the COMMON-HEADER to the client's identifier.
The client inserts in the message all the Floor IDs it wants to
receive information about. The floor control server will send
periodic information about all of these floors. If the client does
not want to receive information about a particular floor any longer,
it sends a new FloorQuery message removing the FLOOR-ID of this
floor. If the client does not want to receive information about any
floor any longer, it sends a FloorQuery message with no FLOOR-ID
attribute.
12.1.2. Receiving a Response
A message from the floor control server is considered a response to
the FloorQuery message if the message from the floor control server
has the same Conference ID, Transaction ID, and User ID as the
FloorQuery message, as described in Section 8.1. On receiving such a
response, the client follows the rules in Section 9 that relate to
floor control server authentication.
On reception of the FloorQuery message, the floor control server MUST
respond with a FloorStatus message or with an Error message. If the
response is a FloorStatus message, it will contain information about
one of the floors the client requested information about. If the
client did not include any FLOOR-ID attribute in its FloorQuery
message (i.e., the client does not want to receive information about
any floor any longer), the FloorStatus message from the floor control
server will not include any FLOOR-ID attribute either.
FloorStatus messages that carry information about a floor contain a
FLOOR-ID attribute that identifies the floor. After this attribute,
FloorStatus messages contain information about existing (one or more)
floor requests that relate to that floor. The information about each
particular 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
provide information about the floor request.
After the first FloorStatus, the floor control server will continue
sending FloorStatus messages, periodically informing the client about
changes on the floors the client requested information about.
12.1.3. Reception of a Subsequent FloorStatus Message
When communicating over an unreliable transport and upon receiving a
FloorStatus message from a floor control server, the participant MUST
respond with a FloorStatusAck message within the transaction failure
window to complete the transaction.
12.2. Requesting Information about Floor Requests
A client can obtain information about the status of one or several
floor requests in different ways, which include using BFCP and using
out-of-band mechanisms. Clients using BFCP to obtain such
information use the procedures described in this section.
Clients request information about the current status of a floor
request by sending a FloorRequestQuery message to the floor control
server.
Requesting information about a particular floor request is useful in
a number of situations. For example, on reception of a FloorRequest
message, a floor control server may choose to return
FloorRequestStatus messages only when the floor request changes its
state (e.g., from Accepted to Granted), but not when the floor
request advances in its queue. In this situation, if the user
requests 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. In addition, the ABNF
specifies normatively which of these attributes are mandatory, and
which ones are optional.
The client sets the Conference ID and the Transaction ID in the
COMMON-HEADER following the rules given in Section 8.1. The client
sets the User ID in the COMMON-HEADER to the client's identifier.
The client MUST insert a FLOOR-REQUEST-ID attribute that identifies
the floor request at the floor control server.
12.2.2. Receiving a Response
A message from the floor control server is considered a response to
the FloorRequestQuery message if the message from the floor control
server has the same Conference ID, Transaction ID, and User ID as the
FloorRequestQuery message, as described in Section 8.1. On receiving
such a response, the client follows the rules in Section 9 that
relate to floor control server authentication.
If the response is a FloorRequestStatus message, the client obtains
information about the status of the FloorRequest the client requested
information about in a FLOOR-REQUEST-INFORMATION attribute.
If the response is an Error message, the floor control server could
not process the FloorRequestQuery message for some reason, which is
described in the Error message.
12.3. Requesting Information about a User
A client can obtain information about a participant and the floor
requests related to this participant in different ways, which include
using BFCP and using out-of-band mechanisms. Clients using BFCP to
obtain such information use the procedures described in this section.
Clients request information about a participant and the floor
requests related to this participant by sending a UserQuery message
to the floor control server.
This functionality may be useful for floor chairs or floor
participants interested in the display name and the URI of a
particular floor participant. In addition, a floor participant may
find it useful to request information about itself. For example, a
floor participant, after experiencing connectivity problems (e.g.,
its TCP connection with the floor control server was down for a while
and eventually was re-established), may need to request information
about all the floor requests associated to itself that still exist.
12.3.1. Sending a UserQuery Message
The ABNF in Section 5.3.5 describes the attributes that a UserQuery
message can contain. In addition, the ABNF specifies normatively
which of these attributes are mandatory, and which ones are optional.
The client sets the Conference ID and the Transaction ID in the
COMMON-HEADER following the rules given in Section 8.1. The client
sets the User ID in the COMMON-HEADER to the client's identifier.
If the floor participant the client is requesting information about
is not the client issuing the UserQuery message (which is identified
by the User ID in the COMMON-HEADER of the message), the client MUST
insert a BENEFICIARY-ID attribute.
12.3.2. Receiving a Response
A message from the floor control server is considered a response to
the UserQuery message if the message from the floor control server
has the same Conference ID, Transaction ID, and User ID as the
UserQuery message, as described in Section 8.1. On receiving such a
response, the client follows the rules in Section 9 that relate to
floor control server authentication.
If the response is a UserStatus message, the client obtains
information about the floor participant in a BENEFICIARY-INFORMATION
grouped attribute and about the status of the floor requests
associated with the floor participant in FLOOR-REQUEST-INFORMATION
attributes.
If the response is an Error message, the floor control server could
not process the UserQuery message for some reason, which is described
in the Error message.
12.4. Obtaining the Capabilities of a Floor Control Server
A client that wishes to obtain the capabilities of a floor control
server does so by sending a Hello message to the floor control
server.
12.4.1. Sending a Hello Message
The ABNF in Section 5.3.11 describes the attributes that a Hello
message can contain. In addition, the ABNF specifies normatively
which of these attributes are mandatory, and which ones are optional.
The client sets the Conference ID and the Transaction ID in the
COMMON-HEADER following the rules given in Section 8.1. The client
sets the User ID in the COMMON-HEADER to the client's identifier.
12.4.2. Receiving Responses
A message from the floor control server is considered a response to
the Hello message by the client if the message from the floor control
server has the same Conference ID, Transaction ID, and User ID as the
Hello message, as described in Section 8.1. On receiving such a
response, the client follows the rules in Section 9 that relate to
floor control server authentication.
If the response is a HelloAck message, the floor control server could
process the Hello message successfully. The SUPPORTED-PRIMITIVES and
SUPPORTED-ATTRIBUTES attributes indicate which primitives and
attributes, respectively, are supported by the server.
If the response is an Error message, the floor control server could
not process the Hello message for some reason, which is described in
the Error message.
13. Floor Control Server Operations
This section specifies how floor control servers can perform
different operations, such as granting a floor, using the protocol
elements described in earlier sections.
On reception of a message from a client, the floor control server
MUST check whether the value of the primitive is supported. If it is
not, the floor control server MUST send an Error message, as
described in Section 13.8, with Error Code 3 (Unknown Primitive).
On reception of a message from a client, the floor control server
MUST check whether the value of the Conference ID matched an existing
conference. If it does not, the floor control server MUST send an
Error message, as described in Section 13.8, with Error Code 1
(Conference Does Not Exist).
On reception of a message from a client, the floor control server
follows the rules in Section 9 that relate to the authentication of
the message.
On reception of a message from a client, the floor control server
MUST check whether it understands all the mandatory ('M' bit set)
attributes in the message. If the floor control server does not
understand all of them, the floor control server MUST send an Error
message, as described in Section 13.8, with Error Code 4 (Unknown
Mandatory Attribute). The Error message SHOULD list the attributes
that were not understood.
13.1. Reception of a FloorRequest Message
On reception of a FloorRequest message, the floor control server
follows the rules in Section 9 that relate to client authentication
and authorization. If while processing the FloorRequest message, the
floor control server encounters an error, it MUST generate an Error
response following the procedures described in Section 13.8.
| BFCP allows floor participants to 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 inform the floor
| participant.
When communicating over an unreliable transport and upon receiving a
FloorRequest from a participant, the floor control server MUST
respond with a FloorRequestStatus message within the transaction
failure window to complete the transaction.
13.1.1. Generating the First FloorRequestStatus Message
The successful processing of a FloorRequest message by a floor
control server involves generating one or several FloorRequestStatus
messages, the first of which SHOULD be generated as soon as possible.
If the floor control server cannot 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 that a floor control server follows to grant or deny
| floors is outside the scope of this document. A given floor
| control server may perform these decisions automatically while
| another may contact a human acting as a chair every time a
| decision needs to be made.
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. Additionally, the
floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
attribute to the FloorRequestStatus. The attributes contained in
this grouped attribute carry information 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. This identifier will be used by the floor participant (or
by a chair or chairs) to refer to this specific floor request in the
future.
The floor control server MUST copy the Floor IDs in the FLOOR-ID
attributes of the FloorRequest into the FLOOR-REQUEST-STATUS
attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These
Floor IDs identify the floors being requested (i.e., the floors
associated with this particular floor request).
The floor control server SHOULD copy (if present) the contents of the
BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY-
INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped
attribute. 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 copy (if present) the PRIORITY attribute
from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped
attribute.
| Note that this attribute carries the priority requested by the
| participant. The priority that the floor control server
| assigns to the floor request depends on the priority requested
| by the participant and the rights the participant has according
| to the policy of the conference. For example, a participant
| that is only allowed to use the Normal priority may request
| Highest priority for a floor request. In that case, the floor
| control server would ignore the priority requested by the
| participant.
The floor control server MAY copy (if present) the PARTICIPANT-
PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-
INFORMATION grouped attribute.
13.1.2. Generation of Subsequent FloorRequestStatus Messages
A floor request is considered to be ongoing as long as it is not in
the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST-
STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped
attribute) of the first FloorRequestStatus message generated by the
floor control server did not indicate any of these 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. The floor control server MUST add a
FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to
the one sent in the first FloorRequestStatus message to any new
FloorRequestStatus related to the same floor request. (The Floor
Request ID identifies the floor request to which the
FloorRequestStatus applies.)
When using BFCP over a reliable transport, the floor control server
MUST set the Transaction ID of subsequent FloorRequestStatus messages
to zero. When using BFCP over an unreliable transport, the
Transaction ID MUST be non-zero and unique in the context of
outstanding transactions over an unreliable transport as described in
Section 8.
| The rate at which the floor control server sends
| FloorRequestStatus messages is a matter of local policy. A
| floor control server may choose to send a new
| FloorRequestStatus message every time the floor request moves
| in the floor request queue, while another may choose only to
| send a new FloorRequestStatus message when the floor request is
| Granted or Denied.
The floor control server may add a STATUS-INFO attribute to any of
the FloorRequestStatus messages it generates to provide extra
information about its decisions regarding the floor request (e.g.,
why it was denied).
| Floor participants and floor chairs may request to be informed
| about the status of a floor following the procedures in
| Section 12.1. If the processing of a floor request changes the
| status of a floor (e.g., the floor request is granted and
| consequently the floor has a new holder), the floor control
| server needs to follow the procedures in Section 13.5 to inform
| the clients that have requested that information.
The COMMON-HEADER and the rest of the attributes are the same as in
the first FloorRequestStatus message.
The floor control server can discard the state information about a
particular floor request when this reaches a status of Cancelled,
Released, or Revoked.
When communicating over an unreliable transport and a
FloorRequestStatusAck message is not received within the transaction
failure window, the floor control server MUST retransmit the
FloorRequestStatus message according to Section 6.2.
13.2. Reception of a FloorRequestQuery Message
On reception of a FloorRequestQuery message, the floor control server
follows the rules in Section 9 that relate to client authentication
and authorization. If while processing the FloorRequestQuery
message, the floor control server encounters an error, it MUST
generate an Error response following the procedures described in
Section 13.8.
The successful processing of a FloorRequestQuery message by a floor
control server involves generating a FloorRequestStatus message,
which SHOULD be generated as soon as possible.
When communicating over an unreliable transport and upon receiving a
FloorRequestQuery from a participant, the floor control server MUST
respond with a FloorRequestStatus message within the transaction
failure window to complete the transaction.
The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the FloorRequestQuery message into the
FloorRequestStatus message, as described in Section 8.2.
Additionally, the floor control server MUST include information about
the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute
to the FloorRequestStatus.
The floor control server MUST copy the contents of the FLOOR-REQUEST-
ID attribute from the FloorRequestQuery message into the Floor
Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to
the FLOOR-REQUEST-INFORMATION grouped attribute identifying the
floors being requested (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 floor control server MAY also add to the FLOOR-REQUEST-
INFORMATION grouped attribute a PRIORITY attribute with the Priority
value requested for the floor request and a STATUS-INFO attribute
with extra information about the floor request.
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute
to the FLOOR-REQUEST-INFORMATION grouped attribute with the current
status of the floor request. The floor control server MAY provide
information about the status of the floor request as it relates to
each of the floors being requested in the FLOOR-REQUEST-STATUS
attributes.
13.3. Reception of a UserQuery Message
On reception of a UserQuery message, the floor control server follows
the rules in Section 9 that relate to client authentication and
authorization. If while processing the UserQuery message, the floor
control server encounters an error, it MUST generate an Error
response following the procedures described in Section 13.8.
The successful processing of a UserQuery message by a floor control
server involves generating a UserStatus message, which SHOULD be
generated as soon as possible.
When communicating over an unreliable transport and upon receiving a
UserQuery from a participant, the floor control server MUST respond
with a UserStatus message within the transaction failure window to
complete the transaction.
The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the UserQuery message into the UserStatus
message, as described in Section 8.2.
The sender of the UserQuery message is requesting information about
all the floor requests associated with a given participant (i.e., the
floor requests where the participant is either the beneficiary or the
requester). This participant is identified by a BENEFICIARY-ID
attribute or, in the absence of a BENEFICIARY-ID attribute, by a the
User ID in the COMMON-HEADER of the UserQuery message.
The floor control server MUST copy, if present, the contents of the
BENEFICIARY-ID attribute from the UserQuery message into a
BENEFICIARY-INFORMATION attribute in the UserStatus message.
Additionally, the floor control server MAY provide the display name
and the URI of the participant about which the UserStatus message
provides information in this BENEFICIARY-INFORMATION attribute.
The floor control server SHOULD add to the UserStatus message a
FLOOR-REQUEST-INFORMATION grouped attribute for each floor request
related to the participant about which the message provides
information (i.e., the floor requests where the participant is either
the beneficiary or the requester). For each FLOOR-REQUEST-
INFORMATION attribute, the floor control server follows the following
steps.
The floor control server MUST identify the floor request the FLOOR-
REQUEST-INFORMATION attribute applies to by filling 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 floor control server MAY also add to the FLOOR-REQUEST-
INFORMATION grouped attribute a PRIORITY attribute with the Priority
value requested for the floor request.
The floor control server MUST include the current status of the floor
request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-
INFORMATION grouped attribute. The floor control server MAY add a
STATUS-INFO attribute with extra information about the floor request.
The floor control server MAY provide information about the status of
the floor request as it relates to each of the floors being requested
in the FLOOR-REQUEST-STATUS attributes.
13.4. Reception of a FloorRelease Message
On reception of a FloorRelease message, the floor control server
follows the rules in Section 9 that relate to client authentication
and authorization. If while processing the FloorRelease message, the
floor control server encounters an error, it MUST generate an Error
response following the procedures described in Section 13.8.
The successful processing of a FloorRelease message by a floor
control server involves generating a FloorRequestStatus message,
which SHOULD be generated as soon as possible.
When communicating over an unreliable transport and upon receiving a
FloorRelease from a participant, the floor control server MUST
respond with a FloorRequestStatus message within the transaction
failure window to complete the transaction.
The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the FloorRelease message into the
FloorRequestStatus message, as described in Section 8.2.
The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
attribute to the FloorRequestStatus. The attributes contained in
this grouped attribute carry information about the floor request.
The FloorRelease message identifies the floor request it applies to
using a FLOOR-REQUEST-ID. The floor control server MUST copy the
contents of the FLOOR-REQUEST-ID attribute from the FloorRelease
message into the Floor Request ID field of the FLOOR-REQUEST-
INFORMATION attribute.
The floor control server MUST identify the floors being released
(i.e., the floors associated with the floor request identified by the
FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the
FLOOR-REQUEST-INFORMATION grouped attribute.
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute
to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request
Status value SHOULD be Released, if the floor (or floors) had been
previously granted, or Cancelled, if the floor (or floors) had not
been previously granted. The floor control server MAY add a STATUS-
INFO attribute with extra information about the floor request.
13.5. Reception of a FloorQuery Message
On reception of a FloorQuery message, the floor control server
follows the rules in Section 9 that relate to client authentication.
If while processing the FloorQuery message, the floor control server
encounters an error, it MUST generate an Error response following the
procedures described in Section 13.8.
When communicating over an unreliable transport and upon receiving a
FloorQuery from a participant, the floor control server MUST respond
with a FloorStatus message within the transaction failure window to
complete the transaction.
A floor control server receiving a FloorQuery message from a client
SHOULD keep this client informed 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.
An individual FloorStatus message carries information about a single
floor. So, when a FloorQuery message requests information about more
than one floor, the floor control server needs to send separate
FloorStatus messages for different floors.
The information FloorQuery messages carry may depend on the user
requesting the information. For example, a chair may be able to
receive information about pending requests, while a regular user may
not be authorized to do so.
13.5.1. Generation of the First FloorStatus Message
The successful processing of a FloorQuery message by a floor control
server involves generating one or several FloorStatus messages, the
first of 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 FloorQuery message into the FloorStatus
message, as described in Section 8.2.
If the FloorQuery message did not contain any FLOOR-ID attribute, the
floor control server sends the FloorStatus message without adding any
additional attribute and does not send any subsequent FloorStatus
message to the floor participant.
If the FloorQuery message contained one or more FLOOR-ID attributes,
the floor control server chooses one from among them and adds this
FLOOR-ID attribute to the FloorStatus message. The floor control
server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for
each floor request associated to the floor. Each FLOOR-REQUEST-
INFORMATION grouped attribute contains a number of attributes that
provide information about the floor request. For each FLOOR-REQUEST-
INFORMATION attribute, the floor control server follows the following
steps.
The floor control server MUST identify the floor request the FLOOR-
REQUEST-INFORMATION attribute applies to by filling 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 floor control server MAY also add to the FLOOR-REQUEST-
INFORMATION grouped attribute a PRIORITY attribute with the Priority
value requested for the floor request.
The floor control server MUST 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 those for the first
FloorStatus message (see Section 13.5.1), but their Transaction ID is
0 when using a reliable transport and non-zero and unique in the
context of outstanding transactions when using an unreliable
transport (cf. Section 8).
After generating these messages, the floor control server sends
FloorStatus messages, periodically keeping the client informed about
all the floors for which the client requested information. The
Transaction ID of these messages MUST be 0 when using a reliable
transport and non-zero and unique in the context of outstanding
transactions when using an unreliable transport (cf. Section 8).
| The rate at which the floor control server sends FloorStatus
| messages is a matter of local policy. A floor control server
| may choose to send a new FloorStatus message every time a new
| floor request arrives, while another may choose to only send a
| new FloorStatus message when a new floor request is Granted.
When communicating over an unreliable transport and a FloorStatusAck
message is not received within the transaction failure window, the
floor control server MUST retransmit the FloorStatus message
according to Section 6.2.
13.6. Reception of a ChairAction Message
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 encounters an error, it MUST generate an Error
response following the procedures described in Section 13.8.
The successful processing of a ChairAction message by a floor control
server involves generating a ChairActionAck message, which SHOULD be
generated as soon as possible.
When communicating over an unreliable transport and upon receiving a
ChairAction from a chair, the floor control server MUST respond with
a ChairActionAck message within the transaction failure window to
complete the transaction.
The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the ChairAction message into the
ChairActionAck message, as described in Section 8.2.
The floor control server needs to take into consideration the
operation requested in the ChairAction message (e.g., granting a
floor) but does not necessarily need to perform it 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.
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
this 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 MUST generate an Error response following the procedures
described in Section 13.8.
If the version of BFCP specified in the version field of the COMMON-
HEADER is supported by the floor control server, it MUST respond with
the same version number in the HelloAck; this defines the version for
all subsequent BFCP messages within this BFCP Connection.
When communicating over an unreliable transport and upon receiving a
Hello from a participant, the floor control server MUST respond with
a HelloAck message within the transaction failure window to complete
the transaction.
The successful processing of a Hello message by a floor control
server 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 that an Error message can
contain. In addition, the ABNF 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
BFCP uses TLS/DTLS to provide mutual authentication between clients
and servers. TLS/DTLS also provides replay and integrity protection
and confidentiality. It is RECOMMENDED that TLS/DTLS with an
encryption algorithm according to Section 7 always be used. In cases
where signaling/control traffic is properly protected, as described
in Section 9, it is REQUIRED to use a mandated encryption algorithm.
BFCP entities MAY use other security mechanisms to interwork with
legacy implementation that do not use TLS/DTLS as long as these
mechanisms provide similar security properties. An example of other
mechanisms to effectively secure a nonsecure BFCP connection is IPsec
[21].
The remainder of this section analyzes some of the threats against
BFCP and how they are 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/DTLS connections. The floor control server assumes
that attackers cannot hijack the TLS/DTLS connection and, therefore,
that messages over the TLS/DTLS 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/DTLS connections, as well
as ensuring clients only send and accept messages over authenticated
TLS/DTLS connections.
Attackers may attempt to modify messages exchanged by a client and a
floor control server. The integrity protection provided by TLS/DTLS
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/DTLS connection use an authorized user ID
(i.e., a user ID that the user that established the authenticated
TLS/DTLS 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/DTLS
confidentiality prevents this attack. Therefore, it is REQUIRED that
TLS/DTLS be used with an encryption algorithm according to Section 7.
15. IANA Considerations
The IANA has created a registry for BFCP parameters called "The
Binary Floor Control Protocol (BFCP) Parameters". This registry has
a number of subregistries, which are described in the following
sections.
15.1. Attributes Subregistry
This section establishes the "Attributes" subregistry under the BFCP
Parameters registry. As per the terminology in RFC 8126 [6], the
registration policy for BFCP attributes is "Specification Required".
For the purposes of this subregistry, the BFCP attributes for which
IANA registration is requested MUST be defined by a Standards Track
RFC. Such an RFC MUST specify the attribute's type, name, format,
and semantics.
For each BFCP attribute, the IANA registers its type, its name, and
the reference to the RFC where the attribute is defined. The
following table contains the initial values of this subregistry.
+======+===========================+===========+
| Type | Attribute | Reference |
+======+===========================+===========+
| 1 | BENEFICIARY-ID | RFC 8855 |
+------+---------------------------+-----------+
| 2 | FLOOR-ID | RFC 8855 |
+------+---------------------------+-----------+
| 3 | FLOOR-REQUEST-ID | RFC 8855 |
+------+---------------------------+-----------+
| 4 | PRIORITY | RFC 8855 |
+------+---------------------------+-----------+
| 5 | REQUEST-STATUS | RFC 8855 |
+------+---------------------------+-----------+
| 6 | ERROR-CODE | RFC 8855 |
+------+---------------------------+-----------+
| 7 | ERROR-INFO | RFC 8855 |
+------+---------------------------+-----------+
| 8 | PARTICIPANT-PROVIDED-INFO | RFC 8855 |
+------+---------------------------+-----------+
| 9 | STATUS-INFO | RFC 8855 |
+------+---------------------------+-----------+
| 10 | SUPPORTED-ATTRIBUTES | RFC 8855 |
+------+---------------------------+-----------+
| 11 | SUPPORTED-PRIMITIVES | RFC 8855 |
+------+---------------------------+-----------+
| 12 | USER-DISPLAY-NAME | RFC 8855 |
+------+---------------------------+-----------+
| 13 | USER-URI | RFC 8855 |
+------+---------------------------+-----------+
| 14 | BENEFICIARY-INFORMATION | RFC 8855 |
+------+---------------------------+-----------+
| 15 | FLOOR-REQUEST-INFORMATION | RFC 8855 |
+------+---------------------------+-----------+
| 16 | REQUESTED-BY-INFORMATION | RFC 8855 |
+------+---------------------------+-----------+
| 17 | FLOOR-REQUEST-STATUS | RFC 8855 |
+------+---------------------------+-----------+
| 18 | OVERALL-REQUEST-STATUS | RFC 8855 |
+------+---------------------------+-----------+
Table 7: Initial values of the BFCP
Attributes subregistry
15.2. Primitives Subregistry
This section establishes the "Primitives" subregistry under the BFCP
Parameters registry. As per the terminology in RFC 8126 [6], the
registration policy for BFCP primitives is "Specification Required".
For the purposes of this subregistry, the BFCP primitives for which
IANA registration is requested MUST be defined by a Standards Track
RFC. Such an RFC MUST specify the primitive's value, name, format,
and semantics.
For each BFCP primitive, the IANA registers its value, its name, and
the reference to the RFC where the primitive is defined. The
following table contains the initial values of this subregistry.
+=======+=======================+===========+
| Value | Primitive | Reference |
+=======+=======================+===========+
| 1 | FloorRequest | RFC 8855 |
+-------+-----------------------+-----------+
| 2 | FloorRelease | RFC 8855 |
+-------+-----------------------+-----------+
| 3 | FloorRequestQuery | RFC 8855 |
+-------+-----------------------+-----------+
| 4 | FloorRequestStatus | RFC 8855 |
+-------+-----------------------+-----------+
| 5 | UserQuery | RFC 8855 |
+-------+-----------------------+-----------+
| 6 | UserStatus | RFC 8855 |
+-------+-----------------------+-----------+
| 7 | FloorQuery | RFC 8855 |
+-------+-----------------------+-----------+
| 8 | FloorStatus | RFC 8855 |
+-------+-----------------------+-----------+
| 9 | ChairAction | RFC 8855 |
+-------+-----------------------+-----------+
| 10 | ChairActionAck | RFC 8855 |
+-------+-----------------------+-----------+
| 11 | Hello | RFC 8855 |
+-------+-----------------------+-----------+
| 12 | HelloAck | RFC 8855 |
+-------+-----------------------+-----------+
| 13 | Error | RFC 8855 |
+-------+-----------------------+-----------+
| 14 | FloorRequestStatusAck | RFC 8855 |
+-------+-----------------------+-----------+
| 15 | FloorStatusAck | RFC 8855 |
+-------+-----------------------+-----------+
| 16 | Goodbye | RFC 8855 |
+-------+-----------------------+-----------+
| 17 | GoodbyeAck | RFC 8855 |
+-------+-----------------------+-----------+
Table 8: Initial values of the BFCP
Primitives subregistry
15.3. Request Statuses Subregistry
This section establishes the "Request Statuses" subregistry under the
BFCP Parameters registry. As per the terminology in RFC 8126 [6],
the registration policy for BFCP request statuses is "Specification
Required". For the purposes of this subregistry, the BFCP request
statuses for which IANA registration is requested MUST be defined by
a Standards Track RFC. Such an RFC MUST specify the value and the
semantics of the request status.
For each BFCP request status, the IANA registers its value, its
meaning, and the reference to the RFC where the request status is
defined. The following table contains the initial values of this
subregistry.
+=======+===========+===========+
| Value | Status | Reference |
+=======+===========+===========+
| 1 | Pending | RFC 8855 |
+-------+-----------+-----------+
| 2 | Accepted | RFC 8855 |
+-------+-----------+-----------+
| 3 | Granted | RFC 8855 |
+-------+-----------+-----------+
| 4 | Denied | RFC 8855 |
+-------+-----------+-----------+
| 5 | Cancelled | RFC 8855 |
+-------+-----------+-----------+
| 6 | Released | RFC 8855 |
+-------+-----------+-----------+
| 7 | Revoked | RFC 8855 |
+-------+-----------+-----------+
Table 9: Initial values of
the Request Statuses
subregistry
15.4. Error Codes Subregistry
This section establishes the "Error Codes" subregistry under the BFCP
Parameters registry. As per the terminology in RFC 8126 [6], the
registration policy for BFCP error codes is "Specification Required".
For the purposes of this subregistry, the BFCP error codes for which
IANA registration is requested MUST be defined by a Standards Track
RFC. Such an RFC MUST specify the value and the semantics of the
error code, and any Error Specific Details that apply to it.
For each BFCP primitive, the IANA registers its value, its meaning,
and the reference to the RFC where the primitive is defined. The
following table contains the initial values of this subregistry.
+=======+=============================================+===========+
| Value | Meaning | Reference |
+=======+=============================================+===========+
| 1 | Conference Does Not Exist | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 2 | User Does Not Exist | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 3 | Unknown Primitive | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 4 | Unknown Mandatory Attribute | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 5 | Unauthorized Operation | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 6 | Invalid Floor ID | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 7 | Floor Request ID Does Not Exist | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 8 | You have Already Reached the Maximum Number | RFC 8855 |
| | of Ongoing Floor Requests for This Floor | |
+-------+---------------------------------------------+-----------+
| 9 | Use TLS | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 10 | Unable to Parse Message | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 11 | Use DTLS | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 12 | Unsupported Version | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 13 | Incorrect Message Length | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 14 | Generic Error | RFC 8855 |
+-------+---------------------------------------------+-----------+
Table 10: Initial values of the Error Codes subregistry
16. Changes from RFC 4582
The following is the list of technical changes and other non-trivial
fixes from [3].
16.1. Extensions for an Unreliable Transport
The main purpose of this work was to revise the specification to
support BFCP over an unreliable transport, resulting in the following
changes:
1. Overview of Operation (Section 4):
Changed the description of client-initiated and server-initiated
transactions, referring to Section 8.
2. COMMON-HEADER Format (Section 5.1):
Ver(sion) field, where the value 2 is used for the extensions
for an unreliable transport. Added new R and F flag bits for an
unreliable transport. Res(erved) field is now 3 bit. New
optional Fragment Offset and Fragment Length fields.
3. New primitives (Section 5.1):
Added four new primitives: FloorRequestStatusAck,
FloorStatusAck, Goodbye, and GoodbyeAck.
4. New error codes (Section 5.2.6):
Added three new error codes: "Unable to Parse Message", "Use
DTLS" and "Unsupported Version". Note that two additional error
codes were added, see Section 16.2.
5. ABNF for new primitives (Section 5.3):
Added new subsections with normative ABNF for the new
primitives.
6. Transport split in two (Section 6):
Section 6 specifying the transport was split in two subsections;
Section 6.1 for a reliable transport and Section 6.2 for an
unreliable transport. The specification for an unreliable
transport, among other issues, deals with reliability,
congestion control, fragmentation and ICMP.
7. Mandated DTLS (Section 7 and Section 9):
Mandated DTLS support when transport over UDP is used.
8. Transaction changes (Section 8):
Server-initiated transactions over an unreliable transport have
non-zero and unique Transaction IDs. Over an unreliable
transport, the retransmit timers T1 and T2 described in
Section 8.3 apply.
9. Timely response required (Section 8.3, Section 10.1.2,
Section 10.2.2, Section 11.2, Section 12.1.2, Section 12.2.2,
Section 12.3.2, Section 12.4.2, Section 10.1.3 and
Section 12.1.3):
Described that a given response must be sent within the
transaction failure window to complete the transaction.
10. Updated IANA Considerations (Section 15):
Added the new primitives and error codes to Section 15.2 and
Section 15.4 respectively.
11. Examples over an unreliable transport (Appendix A):
Added sample interactions over an unreliable transport for the
scenarios in Figure 2 and Figure 3
12. Motivation for an unreliable transport (Appendix B):
Added introduction to and motivation for extending BFCP to
support an unreliable transport.
16.2. Other Changes
Clarifications and bug fixes:
1. ABNF fixes (Figure 22, Figure 24, Figure 26, Figure 28,
Figure 30, and the ABNF figures in Section 5.3):
Although formally correct in [3], the notation has changed in a
number of figures to an equivalent form for clarity, e.g.,
"s/*1(FLOOR-ID)/[FLOOR-ID]/" in Figure 38 and "s/*[XXX]/*(XXX)/"
in the other figures.
2. Typo (Section 12.4.2):
Changed from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the
second paragraph.
3. Corrected attribute type (Section 13.1.1):
Changed from PARTICIPANT-PROVIDED-INFO to PRIORITY attribute in
the eighth paragraph, since the note below describes priority and
that the last paragraph deals with PARTICIPANT-PROVIDED-INFO.
4. New error codes (Section 5.2.6):
Added two additional error codes: "Incorrect Message Length" and
"Generic Error".
5. New cipher suites (Section 7)
Additional cipher suites are now specified which should be
supported.
6. Assorted clarifications (Across the document):
Language clarifications as a result of reviews. Also, the
normative language was tightened where appropriate, i.e. changed
from SHOULD strength to MUST in a number of places.
17. References
17.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC 2119, March 1997,
<https://www.rfc-editor.org/info/RFC 2119>.
[2] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC 6298, June 2011,
<https://www.rfc-editor.org/info/RFC 6298>.
[3] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC 4582,
November 2006, <https://www.rfc-editor.org/info/RFC 4582>.
[4] Camarillo, G., "Connection Establishment in the Binary
Floor Control Protocol (BFCP)", RFC 5018,
DOI 10.17487/RFC 5018, September 2007,
<https://www.rfc-editor.org/info/RFC 5018>.
[5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC 5234, January 2008,
<https://www.rfc-editor.org/info/RFC 5234>.
[6] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC 8126, June 2017,
<https://www.rfc-editor.org/info/RFC 8126>.
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC 5246, August 2008,
<https://www.rfc-editor.org/info/RFC 5246>.
[8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC 6347,
January 2012, <https://www.rfc-editor.org/info/RFC 6347>.
[9] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC 3629, November
2003, <https://www.rfc-editor.org/info/RFC 3629>.
[10] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC 8174,
May 2017, <https://www.rfc-editor.org/info/RFC 8174>.
[11] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC 8446, August 2018,
<https://www.rfc-editor.org/info/RFC 8446>.
[12] Camarillo, G., Kristensen, T., and C. Holmberg, "Session
Description Protocol (SDP) Format for Binary Floor Control
Protocol (BFCP) Streams", RFC 8856, DOI 10.17487/RFC 8856,
January 2021, <https://www.rfc-editor.org/info/RFC 8856>.
[13] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, DOI 10.17487/RFC 4961, July 2007,
<https://www.rfc-editor.org/info/RFC 4961>.
[14] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC 5389, October 2008,
<https://www.rfc-editor.org/info/RFC 5389>.
[15] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC 8085,
March 2017, <https://www.rfc-editor.org/info/RFC 8085>.
[16] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC 8445, July 2018,
<https://www.rfc-editor.org/info/RFC 8445>.
17.2. Informative References
[17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC 3264, June 2002,
<https://www.rfc-editor.org/info/RFC 3264>.
[18] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
"Requirements for Floor Control Protocols", RFC 4376,
DOI 10.17487/RFC 4376, February 2006,
<https://www.rfc-editor.org/info/RFC 4376>.
[19] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, DOI 10.17487/RFC 5239,
June 2008, <https://www.rfc-editor.org/info/RFC 5239>.
[20] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC 3261, June 2002,
<https://www.rfc-editor.org/info/RFC 3261>.
[21] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC 4301,
December 2005, <https://www.rfc-editor.org/info/RFC 4301>.
[22] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized
Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC 6501,
March 2012, <https://www.rfc-editor.org/info/RFC 6501>.
[23] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
"Centralized Conferencing Manipulation Protocol",
RFC 6503, DOI 10.17487/RFC 6503, March 2012,
<https://www.rfc-editor.org/info/RFC 6503>.
[24] Barnes, M., Miniero, L., Presta, R., and S P. Romano,
"Centralized Conferencing Manipulation Protocol (CCMP)
Call Flow Examples", RFC 6504, DOI 10.17487/RFC 6504, March
2012, <https://www.rfc-editor.org/info/RFC 6504>.
[25] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC 1191, November 1990,
<https://www.rfc-editor.org/info/RFC 1191>.
[26] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC 8201, July 2017,
<https://www.rfc-editor.org/info/RFC 8201>.
[27] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC 4821, March 2007,
<https://www.rfc-editor.org/info/RFC 4821>.
[28] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC 5763, May
2010, <https://www.rfc-editor.org/info/RFC 5763>.
[29] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
Control Transmission Protocol (SCTP) Packets for End-Host
to End-Host Communication", RFC 6951,
DOI 10.17487/RFC 6951, May 2013,
<https://www.rfc-editor.org/info/RFC 6951>.
[30] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC 7525, May
2015, <https://www.rfc-editor.org/info/RFC 7525>.
[31] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC 4380, February 2006,
<https://www.rfc-editor.org/info/RFC 4380>.
[32] Thaler, D., "Teredo Extensions", RFC 6081,
DOI 10.17487/RFC 6081, January 2011,
<https://www.rfc-editor.org/info/RFC 6081>.
[33] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC 4960, September 2007,
<https://www.rfc-editor.org/info/RFC 4960>.
[34] Rosenberg, J., Keranen, A., Lowekamp, B. B., and A. B.
Roach, "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, DOI 10.17487/RFC 6544,
March 2012, <https://www.rfc-editor.org/info/RFC 6544>.
[35] Manner, J., Varis, N., and B. Briscoe, "Generic UDP
Tunnelling (GUT)", Work in Progress, Internet-Draft,
draft-manner-tsvwg-gut-02, 12 July 2010,
<https://tools.ietf.org/html/draft-manner-tsvwg-gut-02>.
[36] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis
of Middlebox Interactions for Signaling Protocol
Communication along the Media Path", Work in Progress,
Internet-Draft, draft-ietf-mmusic-media-path-middleboxes-
07, 30 May 2013, <https://tools.ietf.org/html/draft-ietf-
mmusic-media-path-middleboxes-07>.
[37] Guha, S. and P. Francis, "Characterization and Measurement
of TCP Traversal through NATs and Firewalls", 2005,
<https://www.usenix.org/legacy/event/imc05/tech/
full_papers/guha/guha.pdf>.
[38] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer
Communication Across Network Address Translators", April
2005, <https://www.usenix.org/legacy/events/usenix05/tech/
general/full_papers/ford/ford.pdf>.
Appendix A. Example Call Flows for BFCP over an Unreliable Transport
With reference to Section 4.1, the following figures show
representative call flows for requesting and releasing a floor, and
obtaining status information about a floor when BFCP is deployed over
an unreliable transport. The figures here show a lossless
interaction.
Floor Participant Floor Control
Server
|(1) FloorRequest |
|Transaction Responder: 0 |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorRequestStatus |
|Transaction Responder: 1 |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Pending |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(3) FloorRequestStatus |
|Transaction Responder: 0 |
|Transaction ID: 124 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(4) FloorRequestStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 124 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(5) FloorRequestStatus |
|Transaction Responder: 0 |
|Transaction ID: 125 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(6) FloorRequestStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 125 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(7) FloorRelease |
|Transaction Responder: 0 |
|Transaction ID: 126 |
|User ID: 234 |
|FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->|
| |
|(8) FloorRequestStatus |
|Transaction Responder: 1 |
|Transaction ID: 126 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Released |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
Figure 48: Requesting and releasing a floor
Note that in Figure 48, the FloorRequestStatus message from the floor
control server to the floor participant is a transaction-closing
message as a response to the client-initiated transaction with
Transaction ID 126. As such, it is not followed by a
FloorRequestStatusAck message from the floor participant to the floor
control server.
Floor Participant Floor Control
Server
|(1) FloorQuery |
|Transaction Responder: 0 |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorStatus |
|Transaction Responder: 1 |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 2nd |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(3) FloorStatus |
|Transaction Responder: 0 |
|Transaction ID: 258 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(4) FloorStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 258 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(5) FloorStatus |
|Transaction Responder: 0 |
|Transaction ID: 259 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(6) FloorStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 259 |
|User ID: 234 |
|---------------------------------------------->|
Figure 49: Obtaining status information about a floor
Appendix B. Motivation for Supporting an Unreliable Transport
This appendix is provided as an aid to understand the background and
rationale for adding support for unreliable transport.
B.1. Motivation
In existing video conferencing deployments, BFCP is used to manage
the floor for the content sharing associated with the conference.
For peer-to-peer scenarios, including business-to-business
conferences and point-to-point conferences in general, it is
frequently the case that one or both endpoints exist behind a NAT.
BFCP roles are negotiated in the offer/answer exchange as specified
in [12], resulting in one endpoint being responsible for opening the
TCP connection used for the BFCP communication.
+---------+
| Network |
+---------+
+-----+ / \ +-----+
| NAT |/ \| NAT |
+-----+ +-----+
+----+ / \ +----+
|BFCP|/ \|BFCP|
| UA | | UA |
+----+ +----+
Figure 50: Use case
The communication session between the video conferencing endpoints
typically consists of a number of RTP over UDP media streams for
audio and video and a BFCP connection for floor control. Existing
deployments are most common in, but not limited to, enterprise
networks. In existing deployments, NAT traversal for the RTP streams
works using ICE and/or other methods, including those described in
[36].
When enhancing an existing SIP-based video conferencing deployment
with support for content sharing, the BFCP connection often poses a
problem. The reasons for this fall into two general classes. First,
there may be a strong preference for UDP-based signaling in general.
On high-capacity endpoints (e.g., Public Switched Telephone Network
(PSTN) gateways or SIP/H.323 inter-working gateways), TCP can suffer
from head-of-line blocking, and it uses many kernel buffers. Network
operators view UDP as a way to avoid both of these. Second, the
establishment and traversal of the TCP connection involving ephemeral
ports, as is typically the case with BFCP over TCP, can be
problematic, as described in Appendix A of [34]. A broad study of
NAT behavior and peer-to-peer TCP establishment for a comprehensive
set of TCP NAT traversal techniques over a wide range of commercial
NAT products concluded that it was not possible to establish a TCP
connection in 11% of the cases [37]. The results are worse when
focusing on enterprise NATs. A study of hole-punching as a NAT
traversal technique across a wide variety of deployed NATs reported
consistently higher success rates when using UDP than when using TCP
[38].
It is worth noting that BFCP over UDP is already being used in real
deployments, underlining the necessity to specify a common way to
exchange BFCP messages where TCP is not appropriate, to avoid a
situation where multiple different and non-interoperable
implementations would coexist in the market. The purpose of this
document is to extend the standard specification to support
unreliable transport in order to facilitate complete interoperability
between implementations.
B.1.1. Alternatives Considered
In selecting the approach of defining UDP as an alternate transport
for BFCP, several alternatives were considered and explored to some
degree. Each of these is discussed briefly in the following
subsections. In summary, while the alternatives that were not chosen
work in a number of scenarios, they are not sufficient, in and of
themselves, to address the use case targeted by this document. The
last alternative, presented in Appendix B.1.1.7, was selected and is
specified in this document.
It is also worth noting that the IETF Transport Area was asked for a
way to tunnel TCP over UDP, but at that point there was no consensus
on how to achieve that.
B.1.1.1. ICE TCP
ICE TCP [34] extends ICE to TCP-based media, including the ability to
offer a mix of TCP- and UDP-based candidates for a single stream.
ICE TCP has, in general, a lower success probability for enabling TCP
connectivity without a relay if both of the hosts are behind a NAT
(see Appendix A of [34]) than enabling UDP connectivity in the same
scenarios. The happens because many of the currently deployed NATs
in video conferencing networks do not support the flow of TCP
handshake packets seen in the case of TCP simultaneous-open, either
because they do not allow incoming TCP SYN packets from an address to
which a SYN packet has been sent recently, or because they do not
properly process the subsequent SYNACK. Implementing various
techniques advocated for candidate collection in [34] should increase
the success probability, but many of these techniques require support
from some network elements (e.g., from the NATs). Such support is
not common in enterprise NATs.
B.1.1.2. Teredo
Teredo [31] enables nodes located behind one or more IPv4 NATs to
obtain IPv6 connectivity by tunneling packets over UDP. Teredo
extensions [32] provide additional capabilities to Teredo, including
support for more types of NATs and support for more efficient
communication.
As defined, Teredo could be used to make BFCP work for the video
conferencing use cases addressed in this document. However, running
the service requires the help of "Teredo servers" and "Teredo relays"
[31]. These servers and relays generally do not exist in current
video conferencing deployments. It also requires IPv6 awareness on
the endpoints. It should also be noted that ICMP6, as used with
Teredo to complete an initial protocol exchange and confirm that the
appropriate NAT bindings have been set up, is not a conventional
feature of IPv4 or even IPv6, and some currently deployed IPv6
firewalls discard ICMP messages. As these networks continue to
evolve and tackle the transaction to IPv6, Teredo servers and relays
may be deployed, making Teredo available as a suitable alternative to
BFCP over UDP.
B.1.1.3. GUT
GUT [35] attempts to facilitate tunneling over UDP by encapsulating
the native transport protocol and its payload (in general the whole
IP payload) within a UDP packet destined to the well-known port
GUT_P. Unfortunately, it requires user-space TCP, for which there is
not a readily available implementation, and creating one is a large
project in itself. This document has expired, and its future is
still unclear as it has not yet been adopted by a working group.
B.1.1.4. UPnP IGD
Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on
the edge of the network, providing connectivity to the Internet for
computers internal to the LAN, but do not allow Internet devices to
connect to computers on the internal LAN. IGDs enable a computer on
an internal LAN to create port mappings on their NAT, through which
hosts on the Internet can send data that will be forwarded to the
computer on the internal LAN. IGDs may be self-contained hardware
devices or may be software components provided within an operating
system.
In considering UPnP IGD, several issues exist. Not all NATs support
UPnP, and many that do support it are configured with it turned off
by default. NATs are often multilayered, and UPnP does not work well
with such NATs. For example, a typical DSL modem acts as a NAT, and
the user plugs in a wireless access point behind that, which adds
another layer of NAT. The client can discover the first layer of NAT
using multicast, but it is harder to figure out how to discover and
control NATs in the next layer up.
B.1.1.5. NAT PMP
The NAT Port Mapping Protocol (NAT PMP) allows a computer in a
private network (behind a NAT router) to automatically configure the
router to allow parties outside the private network to contact it.
NAT PMP runs over UDP. It essentially automates the process of port
forwarding. Included in the protocol is a method for retrieving the
public IP address of a NAT gateway, thus allowing a client to make
this public IP address and port number known to peers that may wish
to communicate with it.
Many NATs do not support PMP. In those that do support it, it has
similar issues with negotiation of multilayer NATs as UPnP. Video
conferencing is used extensively in enterprise networks, and NAT PMP
is not generally available in enterprise-class routers.
B.1.1.6. SCTP
It would be quite straightforward to specify a BFCP binding for
Stream Control Transmission Protocol (SCTP) [33], and then tunnel
SCTP over UDP in the use case described in Appendix B.1. SCTP is
gaining some momentum currently. There was ongoing discussion in the
RTCWeb Working Group regarding this approach, which resulted in [29].
However, this approach to tunneling over UDP was not mature enough
when considered and was not even fully specified.
B.1.1.7. BFCP over UDP Transport
To overcome the problems with establishing TCP flows between BFCP
entities, an alternative is to define UDP as an alternate transport
for BFCP, leveraging the same mechanisms in place for the RTP over
UDP media streams for the BFCP communication. When using UDP as the
transport, following the guidelines provided in [15] is recommended.
Minor changes to the transaction model have been introduced in that
all requests now have an appropriate response to complete the
transaction. The requests are sent with a retransmission timer
associated with the response to achieve reliability. This
alternative does not change the semantics of BFCP. It permits UDP as
an alternate transport.
Existing implementations, in the spirit of the approach detailed in
earlier draft versions of this document, have demonstrated that this
approach is feasible. Initial compatibility among implementations
has been achieved at previous interoperability events. The authors
view this extension as a pragmatic solution to an existing deployment
challenge. This is the chosen approach, and the extensions are
specified in this document.
Acknowledgements
The XCON Working Group chairs, Adam Roach and Alan Johnston, provided
useful ideas for RFC 4582 [3]. Additionally, Xiaotao Wu, Paul
Kyzivat, Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes,
Ben Campbell, Dave Morgan, and Oscar Novo provided useful comments
during the work with RFC 4582. The authors also acknowledge
contributions to the revision of BFCP for use over an unreliable
transport from Geir Arne Sandbakken who had the initial idea, Alfred
E. Heggestad, Trond G. Andersen, Gonzalo Camarillo, Roni Even,
Lorenzo Miniero, Jörg Ott, Eoin McLeod, Mark K. Thompson, Hadriel
Kaplan, Dan Wing, Cullen Jennings, David Benham, Nivedita Melinkeri,
Woo Johnman, Vijaya Mandava, and Alan Ford. In the final phase,
Ernst Horvath did a thorough review, revealing issues that needed
clarification and changes. Useful and important final reviews were
done by Mary Barnes. Paul Jones helped tremendously as editor for
changes addressing IESG review comments.
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
FI-02420 Jorvas
Finland
Email: gonzalo.camarillo@ericsson.com
Keith Drage
Email: drageke@ntlworld.com
Tom Kristensen
Jotron AS
Ringdalskogen 8
3270 Larvik
Norway
Email: tom.kristensen@jotron.com, tomkri@ifi.uio.no
Jörg Ott
Technical University Munich
Boltzmannstrasse 3
85748 Garching
Germany
Email: ott@in.tum.de
Charles Eckel
Cisco
707 Tasman Drive
Milpitas, California 95035
United States of America
Email: eckelcu@cisco.com
RFC TOTAL SIZE: 214560 bytes
PUBLICATION DATE: Tuesday, January 19th, 2021
LEGAL RIGHTS: The IETF Trust (see BCP 78)
|
