summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4582.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc4582.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc4582.txt')
-rw-r--r--doc/rfc/rfc4582.txt3643
1 files changed, 3643 insertions, 0 deletions
diff --git a/doc/rfc/rfc4582.txt b/doc/rfc/rfc4582.txt
new file mode 100644
index 0000000..a48333f
--- /dev/null
+++ b/doc/rfc/rfc4582.txt
@@ -0,0 +1,3643 @@
+
+
+
+
+
+
+Network Working Group G. Camarillo
+Request for Comments: 4582 Ericsson
+Category: Standards Track J. Ott
+ Helsinki University of Technology
+ K. Drage
+ Lucent Technologies
+ November 2006
+
+
+ The Binary Floor Control Protocol (BFCP)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2006).
+
+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.
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Terminology .....................................................4
+ 3. Scope ...........................................................5
+ 3.1. Floor Creation .............................................7
+ 3.2. Obtaining Information to Contact a Floor Control Server ....7
+ 3.3. Obtaining Floor-Resource Associations ......................7
+ 3.4. Privileges of Floor Control ................................8
+ 4. Overview of Operation ...........................................8
+ 4.1. Floor Participant to Floor Control Server Interface ........8
+ 4.2. Floor Chair to Floor Control Server Interface .............13
+
+
+
+Camarillo, et al. Standards Track [Page 1]
+
+RFC 4582 BFCP November 2006
+
+
+ 5. Packet Format ..................................................14
+ 5.1. COMMON-HEADER Format ......................................15
+ 5.2. Attribute Format ..........................................16
+ 5.2.1. BENEFICIARY-ID .....................................18
+ 5.2.2. FLOOR-ID ...........................................18
+ 5.2.3. FLOOR-REQUEST-ID ...................................19
+ 5.2.4. PRIORITY ...........................................19
+ 5.2.5. REQUEST-STATUS .....................................20
+ 5.2.6. ERROR-CODE .........................................21
+ 5.2.6.1. Error-Specific Details for Error Code 4 ...22
+ 5.2.7. ERROR-INFO .........................................22
+ 5.2.8. PARTICIPANT-PROVIDED-INFO ..........................23
+ 5.2.9. STATUS-INFO ........................................24
+ 5.2.10. SUPPORTED-ATTRIBUTES ..............................24
+ 5.2.11. SUPPORTED-PRIMITIVES ..............................25
+ 5.2.12. USER-DISPLAY-NAME .................................26
+ 5.2.13. USER-URI ..........................................26
+ 5.2.14. BENEFICIARY-INFORMATION ...........................27
+ 5.2.15. FLOOR-REQUEST-INFORMATION .........................27
+ 5.2.16. REQUESTED-BY-INFORMATION ..........................28
+ 5.2.17. FLOOR-REQUEST-STATUS .............................29
+ 5.2.18. OVERALL-REQUEST-STATUS ...........................30
+ 5.3. Message Format ............................................30
+ 5.3.1. FloorRequest .......................................31
+ 5.3.2. FloorRelease .......................................31
+ 5.3.3. FloorRequestQuery ..................................31
+ 5.3.4. FloorRequestStatus .................................31
+ 5.3.5. UserQuery ..........................................32
+ 5.3.6. UserStatus .........................................32
+ 5.3.7. FloorQuery .........................................32
+ 5.3.8. FloorStatus ........................................33
+ 5.3.9. ChairAction ........................................33
+ 5.3.10. ChairActionAck ....................................33
+ 5.3.11. Hello .............................................33
+ 5.3.12. HelloAck ..........................................34
+ 5.3.13. Error .............................................34
+ 6. Transport ......................................................34
+ 7. Lower-Layer Security ...........................................35
+ 8. Protocol Transactions ..........................................35
+ 8.1. Client Behavior ...........................................36
+ 8.2. Server Behavior ...........................................36
+ 9. Authentication and Authorization ...............................36
+ 9.1. TLS-Based Mutual Authentication ...........................37
+ 10. Floor Participant Operations ..................................37
+ 10.1. Requesting a Floor .......................................37
+ 10.1.1. Sending a FloorRequest Message ....................38
+ 10.1.2. Receiving a Response ..............................38
+ 10.2. Cancelling a Floor Request and Releasing a Floor .........40
+
+
+
+Camarillo, et al. Standards Track [Page 2]
+
+RFC 4582 BFCP November 2006
+
+
+ 10.2.1. Sending a FloorRelease Message ....................40
+ 10.2.2. Receiving a Response ..............................40
+ 11. Chair Operations ..............................................41
+ 11.1. Sending a ChairAction Message ............................41
+ 11.2. Receiving a Response .....................................42
+ 12. General Client Operations .....................................43
+ 12.1. Requesting Information about Floors ......................43
+ 12.1.1. Sending a FloorQuery Message ......................43
+ 12.1.2. Receiving a Response ..............................43
+ 12.2. Requesting Information about Floor Requests ..............44
+ 12.2.1. Sending a FloorRequestQuery Message ...............45
+ 12.2.2. Receiving a Response ..............................45
+ 12.3. Requesting Information about a User ......................45
+ 12.3.1. Sending a UserQuery Message .......................46
+ 12.3.2. Receiving a Response ..............................46
+ 12.4. Obtaining the Capabilities of a Floor Control Server .....46
+ 12.4.1. Sending a Hello Message ...........................47
+ 12.4.2. Receiving Responses ...............................47
+ 13. Floor Control Server Operations ...............................47
+ 13.1. Reception of a FloorRequest Message ......................48
+ 13.1.1. Generating the First FloorRequestStatus Message ...48
+ 13.1.2. Generation of Subsequent
+ FloorRequestStatus Messages .......................50
+ 13.2. Reception of a FloorRequestQuery Message .................51
+ 13.3. Reception of a UserQuery Message .........................52
+ 13.4. Reception of a FloorRelease Message ......................53
+ 13.5. Reception of a FloorQuery Message ........................54
+ 13.5.1. Generation of the First FloorStatus Message .......55
+ 13.5.2. Generation of Subsequent FloorStatus Messages .....56
+ 13.6. Reception of a ChairAction Message .......................56
+ 13.7. Reception of a Hello Message .............................57
+ 13.8. Error Message Generation .................................58
+ 14. Security Considerations .......................................58
+ 15. IANA Considerations ...........................................59
+ 15.1. Attribute Subregistry ....................................59
+ 15.2. Primitive Subregistry ....................................60
+ 15.3. Request Status Subregistry ...............................61
+ 15.4. Error Code Subregistry ...................................62
+ 16. Acknowledgements ..............................................62
+ 17. References ....................................................63
+ 17.1. Normative References .....................................63
+ 17.2. Informational References .................................63
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 3]
+
+RFC 4582 BFCP November 2006
+
+
+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 [9] 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, and
+ subsequent sections provide the normative specification of BFCP.
+
+2. Terminology
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
+ RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
+ described in BCP 14, RFC 2119 [1] and indicate requirement levels for
+ compliant implementations.
+
+ 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
+ colocated 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 colocated.
+ The protocol between a floor participant and a media participant
+ (that are not colocated) is outside the scope of this document.
+
+ Client: A floor participant or a floor chair that communicates with a
+ floor control server using BFCP.
+
+
+
+Camarillo, et al. Standards Track [Page 4]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 colocated 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 colocated.
+
+ Participant: An entity that acts as a floor participant, as a media
+ participant, or as both.
+
+3. Scope
+
+ As stated earlier, BFCP is a protocol to coordinate access to shared
+ resources in a conference following the requirements defined in [9].
+ Floor control complements other functions defined in the XCON
+ conferencing framework [10]. 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 [10].
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 5]
+
+RFC 4582 BFCP November 2006
+
+
+ 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:
+
+ o for floor participants to send floor requests to floor control
+ servers.
+
+ o for floor control servers to grant or deny requests to access a
+ given resource from floor participants.
+
+ o for floor chairs to send floor control servers decisions regarding
+ floor requests.
+
+ o 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.
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 6]
+
+RFC 4582 BFCP November 2006
+
+
+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 [10]. 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).
+
+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
+ an SDP offer/answer [8] exchange, which is described in [7]. Other
+ mechanisms are described in the XCON framework [10] (and other
+ related documents).
+
+3.3. Obtaining Floor-Resource Associations
+
+ Floors are associated with resources. For example, a floor that
+ controls who 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 [8] exchange.
+ How to use an SDP offer/answer exchange to obtain these associations
+ is described in [7].
+
+ 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 [10] (and other related documents).
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 7]
+
+RFC 4582 BFCP November 2006
+
+
+3.4. Privileges of Floor Control
+
+ A participant whose floor request is granted has the right to use (in
+ a certain way) 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 [10].
+
+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. Client-initiated
+ transactions consist of a message from a client to the floor control
+ server and a response from the floor control server to the client.
+ Both messages can be related because they carry the same Transaction
+ ID value in their common headers. Server-initiated transactions
+ consist of a single message, whose Transaction ID is 0, from the
+ floor control server to a client.
+
+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 colocated 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.
+
+
+
+Camarillo, et al. Standards Track [Page 8]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 9]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 |
+ |---------------------------------------------->|
+
+
+
+
+Camarillo, et al. Standards Track [Page 10]
+
+RFC 4582 BFCP November 2006
+
+
+ | |
+ |(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. 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 |
+ |---------------------------------------------->|
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 11]
+
+RFC 4582 BFCP November 2006
+
+
+ | |
+ |(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 |
+ |<----------------------------------------------|
+
+
+
+
+Camarillo, et al. Standards Track [Page 12]
+
+RFC 4582 BFCP November 2006
+
+
+ | |
+ |(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.
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 13]
+
+RFC 4582 BFCP November 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 14]
+
+RFC 4582 BFCP November 2006
+
+
+5.1. COMMON-HEADER Format
+
+ The following is the format of the common header.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ver |Reserved | Primitive | Payload Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Conference ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Transaction ID | User ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 5: COMMON-HEADER format
+
+ Ver: The 3-bit version field MUST be set to 1 to indicate this
+ version of BFCP.
+
+ Reserved: At this point, the 5 bits in the reserved field SHOULD be
+ set to zero by the sender of the message and MUST be ignored by the
+ receiver.
+
+ Primitive: This 8-bit field identifies the main purpose of the
+ message. The following primitive values are defined:
+
+ +-------+--------------------+------------------+
+ | Value | Primitive | Direction |
+ +-------+--------------------+------------------+
+ | 1 | FloorRequest | P -> S |
+ | 2 | FloorRelease | P -> S |
+ | 3 | FloorRequestQuery | P -> S ; Ch -> S |
+ | 4 | FloorRequestStatus | P <- S ; Ch <- S |
+ | 5 | UserQuery | P -> S ; Ch -> S |
+ | 6 | UserStatus | P <- S ; Ch <- S |
+ | 7 | FloorQuery | P -> S ; Ch -> S |
+ | 8 | FloorStatus | P <- S ; Ch <- S |
+ | 9 | ChairAction | Ch -> S |
+ | 10 | ChairActionAck | Ch <- S |
+ | 11 | Hello | P -> S ; Ch -> S |
+ | 12 | HelloAck | P <- S ; Ch <- S |
+ | 13 | Error | P <- S ; Ch <- S |
+ +-------+--------------------+------------------+
+ S: Floor Control Server
+ P: Floor Participant
+ Ch: Floor Chair
+
+ Table 1: BFCP primitives
+
+
+
+Camarillo, et al. Standards Track [Page 15]
+
+RFC 4582 BFCP November 2006
+
+
+ Payload Length: This 16-bit field contains the length of the message
+ in 4-octet units, excluding the common header.
+
+ Conference ID: This 32-bit field identifies the conference the
+ message belongs to.
+
+ Transaction ID: This field contains a 16-bit value that allows users
+ to match a given message with its response. The value of the
+ Transaction ID in server-initiated transactions is 0 (see Section 8).
+
+ User ID: This field contains a 16-bit value that uniquely identifies
+ a participant within a conference.
+
+ The identity used by a participant in BFCP, which is carried in
+ the User ID field, is generally mapped to the identity used by the
+ same participant in the session establishment protocol (e.g., in
+ SIP). The way this mapping is performed is outside the scope of
+ this specification.
+
+5.2. Attribute Format
+
+ BFCP attributes are encoded in TLV (Type-Length-Value) format.
+ Attributes are 32-bit aligned.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type |M| Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+ | |
+ / Attribute Contents /
+ / /
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 6: Attribute format
+
+ Type: This 7-bit field contains the type of the attribute. Each
+ attribute, identified by its type, has a particular format. The
+ attribute formats defined are:
+
+ Unsigned16: The contents of the attribute consist of a 16-bit
+ unsigned integer.
+
+ OctetString16: The contents of the attribute consist of 16 bits of
+ arbitrary data.
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 16]
+
+RFC 4582 BFCP November 2006
+
+
+ OctetString: The contents of the attribute consist of arbitrary
+ data of variable length.
+
+ Grouped: The contents of the attribute consist of a sequence of
+ attributes.
+
+ Note that extension attributes defined in the future may define
+ new attribute formats.
+
+ The following attribute types are defined:
+
+ +------+---------------------------+---------------+
+ | Type | Attribute | Format |
+ +------+---------------------------+---------------+
+ | 1 | BENEFICIARY-ID | Unsigned16 |
+ | 2 | FLOOR-ID | Unsigned16 |
+ | 3 | FLOOR-REQUEST-ID | Unsigned16 |
+ | 4 | PRIORITY | OctetString16 |
+ | 5 | REQUEST-STATUS | OctetString16 |
+ | 6 | ERROR-CODE | OctetString |
+ | 7 | ERROR-INFO | OctetString |
+ | 8 | PARTICIPANT-PROVIDED-INFO | OctetString |
+ | 9 | STATUS-INFO | OctetString |
+ | 10 | SUPPORTED-ATTRIBUTES | OctetString |
+ | 11 | SUPPORTED-PRIMITIVES | OctetString |
+ | 12 | USER-DISPLAY-NAME | OctetString |
+ | 13 | USER-URI | OctetString |
+ | 14 | BENEFICIARY-INFORMATION | Grouped |
+ | 15 | FLOOR-REQUEST-INFORMATION | Grouped |
+ | 16 | REQUESTED-BY-INFORMATION | Grouped |
+ | 17 | FLOOR-REQUEST-STATUS | Grouped |
+ | 18 | OVERALL-REQUEST-STATUS | Grouped |
+ +------+---------------------------+---------------+
+
+ Table 2: BFCP attributes
+
+ M: The 'M' bit, known as the Mandatory bit, indicates whether support
+ of the attribute is required. If an unrecognized attribute with the
+ 'M' bit set is received, the message is rejected. The 'M' bit is
+ significant for extension attributes defined in other documents only.
+ All attributes specified in this document MUST be understood by the
+ receiver so that the setting of the 'M' bit is irrelevant for these.
+ In all other cases, the unrecognised attribute is ignored but the
+ message is processed.
+
+ Length: This 8-bit field contains the length of the attribute in
+ octets, excluding any padding defined for specific attributes. The
+ length of attributes that are not grouped includes the Type, 'M' bit,
+
+
+
+Camarillo, et al. Standards Track [Page 17]
+
+RFC 4582 BFCP November 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 18]
+
+RFC 4582 BFCP November 2006
+
+
+5.2.3. FLOOR-REQUEST-ID
+
+ The following is the format of the FLOOR-REQUEST-ID attribute.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 9: FLOOR-REQUEST-ID format
+
+ Floor Request ID: This field contains a 16-bit value that identifies
+ a floor request at the floor control server.
+
+5.2.4. PRIORITY
+
+ The following is the format of the PRIORITY attribute.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 10: PRIORITY format
+
+ Prio: This field contains a 3-bit priority value, as shown in
+ Table 3. Senders SHOULD NOT use values higher than 4 in this field.
+ Receivers MUST treat values higher than 4 as if the value received
+ were 4 (Highest). The default priority value when the PRIORITY
+ attribute is missing is 2 (Normal).
+
+ +-------+----------+
+ | Value | Priority |
+ +-------+----------+
+ | 0 | Lowest |
+ | 1 | Low |
+ | 2 | Normal |
+ | 3 | High |
+ | 4 | Highest |
+ +-------+----------+
+
+ Table 3: Priority values
+
+ Reserved: At this point, the 13 bits in the reserved field SHOULD be
+ set to zero by the sender of the message and MUST be ignored by the
+ receiver.
+
+
+
+Camarillo, et al. Standards Track [Page 19]
+
+RFC 4582 BFCP November 2006
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 20]
+
+RFC 4582 BFCP November 2006
+
+
+5.2.6. ERROR-CODE
+
+ The following is the format of the ERROR-CODE attribute.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 0 1 1 0|M| Length | Error Code | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+ | |
+ | Error Specific Details |
+ / /
+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 12: ERROR-CODE format
+
+ Error Code: This 8-bit field contains an error code from the
+ following table. If an error code is not recognised by the receiver,
+ then the receiver MUST assume that an error exists, and therefore
+ that the message is processed, but the nature of the error is
+ unclear.
+
+ +-------+-----------------------------------------------------------+
+ | Value | Meaning |
+ +-------+-----------------------------------------------------------+
+ | 1 | Conference does not Exist |
+ | 2 | User does not Exist |
+ | 3 | Unknown Primitive |
+ | 4 | Unknown Mandatory Attribute |
+ | 5 | Unauthorized Operation |
+ | 6 | Invalid Floor ID |
+ | 7 | Floor Request ID Does Not Exist |
+ | 8 | You have Already Reached the Maximum Number of Ongoing |
+ | | Floor Requests for this Floor |
+ | 9 | Use TLS |
+ +-------+-----------------------------------------------------------+
+
+ Table 5: Error Code meaning
+
+ Error Specific Details: Present only for certain Error Codes. In
+ this document, only for Error Code 4 (Unknown Mandatory Attribute).
+ See Section 5.2.6.1 for its definition.
+
+ Padding: One, two, or three octets of padding added so that the
+ contents of the ERROR-CODE attribute is 32-bit aligned. If the
+ attribute is already 32-bit aligned, no padding is needed.
+
+
+
+Camarillo, et al. Standards Track [Page 21]
+
+RFC 4582 BFCP November 2006
+
+
+ The Padding bits SHOULD be set to zero by the sender and MUST be
+ ignored by the receiver.
+
+5.2.6.1. Error-Specific Details for Error Code 4
+
+ The following is the format of the Error-Specific Details field for
+ Error Code 4.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | Unknown Type|R| Unknown Type|R|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Unknown Type|R| Unknown Type|R|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 13: Unknown attributes format
+
+ Unknown Type: These 7-bit fields contain the Types of the attributes
+ (which were present in the message that triggered the Error message)
+ that were unknown to the receiver.
+
+ R: At this point, this bit is reserved. It SHOULD be set to zero by
+ the sender of the message and MUST be ignored by the receiver.
+
+5.2.7. ERROR-INFO
+
+ The following is the format of the ERROR-INFO attribute.
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 0 1 1 1|M| Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+ | |
+ / Text /
+ / +-+-+-+-+-+-+-+-+
+ | | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 14: ERROR-INFO format
+
+ Text: This field contains UTF-8 [6] encoded text.
+
+
+
+Camarillo, et al. Standards Track [Page 22]
+
+RFC 4582 BFCP November 2006
+
+
+ In some situations, the contents of the Text field may be generated
+ by an automaton. If this automaton has information about the
+ preferred language of the receiver of a particular ERROR-INFO
+ attribute, it MAY use this language to generate the Text field.
+
+ Padding: One, two, or three octets of padding added so that the
+ contents of the ERROR-INFO attribute is 32-bit aligned. The Padding
+ bits SHOULD be set to zero by the sender and MUST be ignored by the
+ receiver. If the attribute is already 32-bit aligned, no padding is
+ needed.
+
+5.2.8. PARTICIPANT-PROVIDED-INFO
+
+ The following is the format of the PARTICIPANT-PROVIDED-INFO
+ attribute.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 1 0 0 0|M| Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+ | |
+ / Text /
+ / +-+-+-+-+-+-+-+-+
+ | | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 15: PARTICIPANT-PROVIDED-INFO format
+
+ Text: This field contains UTF-8 [6] encoded text.
+
+ Padding: One, two, or three octets of padding added so that the
+ contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit
+ aligned. The Padding bits SHOULD be set to zero by the sender and
+ MUST be ignored by the receiver. If the attribute is already 32-bit
+ aligned, no padding is needed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 23]
+
+RFC 4582 BFCP November 2006
+
+
+5.2.9. STATUS-INFO
+
+ The following is the format of the STATUS-INFO attribute.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 1 0 0 1|M| Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+ | |
+ / Text /
+ / +-+-+-+-+-+-+-+-+
+ | | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 16: STATUS-INFO format
+
+ Text: This field contains UTF-8 [6] encoded text.
+
+ In some situations, the contents of the Text field may be generated
+ by an automaton. If this automaton has information about the
+ preferred language of the receiver of a particular STATUS-INFO
+ attribute, it MAY use this language to generate the Text field.
+
+ Padding: One, two, or three octets of padding added so that the
+ contents of the STATUS-INFO attribute is 32-bit aligned. The Padding
+ bits SHOULD be set to zero by the sender and MUST be ignored by the
+ receiver. If the attribute is already 32-bit aligned, no padding is
+ needed.
+
+5.2.10. SUPPORTED-ATTRIBUTES
+
+ The following is the format of the SUPPORTED-ATTRIBUTES attribute.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ / /
+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 17: SUPPORTED-ATTRIBUTES format
+
+
+
+Camarillo, et al. Standards Track [Page 24]
+
+RFC 4582 BFCP November 2006
+
+
+ Supp. Attr.: These fields contain the Types of the attributes that
+ are supported by the floor control server in the following format:
+
+ R: Reserved: This bit MUST be set to zero upon transmission and MUST
+ be ignored upon reception.
+
+ Padding: Two octets of padding added so that the contents of the
+ SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute
+ is already 32-bit aligned, no padding is needed.
+
+ The Padding bits SHOULD be set to zero by the sender and MUST be
+ ignored by the receiver.
+
+5.2.11. SUPPORTED-PRIMITIVES
+
+ The following is the format of the SUPPORTED-PRIMITIVES attribute.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 1 0 1 1|M| Length | Primitive | Primitive |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Primitive | Primitive | Primitive | Primitive |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ / /
+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 18: SUPPORTED-PRIMITIVES format
+
+ Primitive: These fields contain the types of the BFCP messages that
+ are supported by the floor control server. See Table 1 for the list
+ of BFCP primitives.
+
+ Padding: One, two, or three octets of padding added so that the
+ contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If
+ the attribute is already 32-bit aligned, no padding is needed.
+
+ The Padding bits SHOULD be set to zero by the sender and MUST be
+ ignored by the receiver.
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 25]
+
+RFC 4582 BFCP November 2006
+
+
+5.2.12. USER-DISPLAY-NAME
+
+ The following is the format of the USER-DISPLAY-NAME attribute.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 1 1 0 0|M| Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+ | |
+ / Text /
+ / +-+-+-+-+-+-+-+-+
+ | | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 19: USER-DISPLAY-NAME format
+
+ Text: This field contains the UTF-8 encoded name of the user.
+
+ Padding: One, two, or three octets of padding added so that the
+ contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The
+ Padding bits SHOULD be set to zero by the sender and MUST be ignored
+ by the receiver. If the attribute is already 32-bit aligned, no
+ padding is needed.
+
+5.2.13. USER-URI
+
+ The following is the format of the USER-URI attribute.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 1 1 0 1|M| Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+ | |
+ / Text /
+ / +-+-+-+-+-+-+-+-+
+ | | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 20: USER-URI format
+
+ Text: This field contains the UTF-8 encoded user's contact URI, that
+ is, the URI used by the user to set up the resources (e.g., media
+ streams) that are controlled by BFCP. For example, in the context of
+ a conference set up by SIP, the USER-URI attribute would carry the
+ SIP URI of the user.
+
+
+
+
+Camarillo, et al. Standards Track [Page 26]
+
+RFC 4582 BFCP November 2006
+
+
+ Messages containing a user's URI in a USER-URI attribute also
+ contain the user's User ID. This way, a client receiving such a
+ message can correlate the user's URI (e.g., the SIP URI the user
+ used to join a conference) with the user's User ID.
+
+ Padding: One, two, or three octets of padding added so that the
+ contents of the USER-URI attribute is 32-bit aligned. The Padding
+ bits SHOULD be set to zero by the sender and MUST be ignored by the
+ receiver. If the attribute is already 32-bit aligned, no padding is
+ needed.
+
+5.2.14. BENEFICIARY-INFORMATION
+
+ The BENEFICIARY-INFORMATION attribute is a grouped attribute that
+ consists of a header, which is referred to as BENEFICIARY-
+ INFORMATION-HEADER, followed by a sequence of attributes. The
+ following is the format of the BENEFICIARY-INFORMATION-HEADER:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 1 1 1 0|M| Length | Beneficiary ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 21: BENEFICIARY-INFORMATION-HEADER format
+
+ Beneficiary ID: This field contains a 16-bit value that uniquely
+ identifies a user within a conference.
+
+ The following is the ABNF (Augmented Backus-Naur Form) [2] of the
+ BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE
+ refers to extension attributes that may be defined in the future.)
+
+ BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER)
+ [USER-DISPLAY-NAME]
+ [USER-URI]
+ *[EXTENSION-ATTRIBUTE]
+
+ Figure 22: BENEFICIARY-INFORMATION format
+
+5.2.15. FLOOR-REQUEST-INFORMATION
+
+ The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that
+ consists of a header, which is referred to as FLOOR-REQUEST-
+ INFORMATION-HEADER, followed by a sequence of attributes. The
+ following is the format of the FLOOR-REQUEST-INFORMATION-HEADER:
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 27]
+
+RFC 4582 BFCP November 2006
+
+
+ 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.)
+
+
+
+
+Camarillo, et al. Standards Track [Page 28]
+
+RFC 4582 BFCP November 2006
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 29]
+
+RFC 4582 BFCP November 2006
+
+
+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)
+ [2] of the BFCP messages. Extension attributes that may be defined
+ in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 30]
+
+RFC 4582 BFCP November 2006
+
+
+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:
+
+
+
+
+Camarillo, et al. Standards Track [Page 31]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 FloorRequest message:
+
+ FloorQuery = (COMMON-HEADER)
+ *(FLOOR-ID)
+ *[EXTENSION-ATTRIBUTE]
+
+ Figure 37: FloorQuery format
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 32]
+
+RFC 4582 BFCP November 2006
+
+
+5.3.8. FloorStatus
+
+ The floor control server informs floor participants and floor chairs
+ about the status (e.g., the current holder) of a floor by sending
+ them FloorStatus messages. The following is the format of the
+ FloorStatus message:
+
+ FloorStatus = (COMMON-HEADER)
+ *1(FLOOR-ID)
+ *[FLOOR-REQUEST-INFORMATION]
+ *[EXTENSION-ATTRIBUTE]
+
+ Figure 38: FloorStatus format
+
+5.3.9. ChairAction
+
+ Floor chairs send instructions to floor control servers by sending
+ ChairAction messages. The following is the format of the ChairAction
+ message:
+
+ ChairAction = (COMMON-HEADER)
+ (FLOOR-REQUEST-INFORMATION)
+ *[EXTENSION-ATTRIBUTE]
+
+ Figure 39: ChairAction 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 check the liveliness of floor
+ control servers by sending a Hello message. The following is the
+ format of the Hello message:
+
+
+ Hello = (COMMON-HEADER)
+ *[EXTENSION-ATTRIBUTE]
+
+ Figure 41: Hello format
+
+
+
+Camarillo, et al. Standards Track [Page 33]
+
+RFC 4582 BFCP November 2006
+
+
+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
+
+6. Transport
+
+ BFCP entities exchange BFCP messages using TCP connections. TCP
+ provides an in-order reliable delivery of a stream of bytes.
+ Consequently, message framing is implemented in the application
+ layer. BFCP implements application-layer framing using TLV-encoded
+ attributes.
+
+ A client MUST NOT use more than one TCP connection to communicate
+ with a given floor control server within a conference. Nevertheless,
+ if the same physical box handles different clients (e.g., a floor
+ chair and a floor participant), which are identified by different
+ User IDs, a separate connection per client is allowed.
+
+ If a BFCP entity (a client or a floor control server) receives data
+ from TCP that cannot be parsed, the entity MUST close the TCP
+ connection, and the connection SHOULD be reestablished. Similarly,
+ if a TCP connection cannot deliver a BFCP message and times out, the
+ TCP connection SHOULD be reestablished.
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 34]
+
+RFC 4582 BFCP November 2006
+
+
+ The way connection reestablishment is handled depends on how the
+ client obtains information to contact the floor control server (e.g.,
+ using an SDP offer/answer exchange [7]). Once the TCP connection is
+ reestablished, the client MAY resend those messages for which it did
+ not get a response from the floor control server.
+
+ If a floor control server detects that the TCP connection towards one
+ of the floor participants is lost, it is up to the local policy of
+ the floor control server what to do with the pending floor requests
+ of the floor participant. In any case, it is RECOMMENDED that the
+ floor control server keep the floor requests (i.e., that it does not
+ cancel them) while the TCP connection is reestablished.
+
+ If a client wishes to end its BFCP connection with a floor control
+ server, the client closes (i.e., a graceful close) the TCP connection
+ towards the floor control server. If a floor control server wishes
+ to end its BFCP connection with a client (e.g., the Focus of the
+ conference informs the floor control server that the client has been
+ kicked out from the conference), the floor control server closes
+ (i.e., a graceful close) the TCP connection towards the client.
+
+7. Lower-Layer Security
+
+ BFCP relies on lower-layer security mechanisms to provide replay and
+ integrity protection and confidentiality. BFCP floor control servers
+ and clients (which include both floor participants and floor chairs)
+ MUST support TLS [3]. Any BFCP entity MAY support other security
+ mechanisms.
+
+ BFCP entities MUST support, at a minimum, the TLS
+ TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [5].
+
+ Which party, the client or the floor control server, acts as the TLS
+ server depends on how the underlying TCP connection is established.
+ For example, when the TCP connection is established using an SDP
+ offer/answer exchange [7], the answerer (which may be the client or
+ the floor control server) always acts as the TLS server.
+
+8. Protocol Transactions
+
+ In BFCP, there are two types of transactions: client-initiated
+ transactions and server-initiated transactions (notifications).
+ Client-initiated transactions consist of a request from a client to a
+ floor control server and a response from the floor control server to
+ the client. The request carries a Transaction ID in its common
+ header, which the floor control server copies into the response.
+ Clients use Transaction ID values to match responses with previously
+ issued requests.
+
+
+
+Camarillo, et al. Standards Track [Page 35]
+
+RFC 4582 BFCP November 2006
+
+
+ Server-initiated transactions consist of a single message from a
+ floor control server to a client. Since they do not trigger any
+ response, their Transaction ID is set to 0.
+
+8.1. Client Behavior
+
+ A client starting a client-initiated transaction MUST set the
+ Conference ID in the common header of the message to the Conference
+ ID for the conference that the client obtained previously.
+
+ The client MUST set the Transaction ID value in the common header to
+ a number that is different from 0 and that MUST NOT be reused in
+ another message from the client until a response from the server is
+ received for the transaction. The client uses the Transaction ID
+ value to match this message with the response from the floor control
+ server.
+
+8.2. Server Behavior
+
+ A floor control server sending a response within a client-initiated
+ transaction MUST copy the Conference ID, the Transaction ID, and the
+ User ID from the request received from the client into the response.
+ Server-initiated transactions MUST contain a Transaction ID equal to
+ 0.
+
+9. Authentication and Authorization
+
+ BFCP clients SHOULD authenticate the floor control server before
+ sending any BFCP message to it or accepting any BFCP message from it.
+ Similarly, floor control servers SHOULD authenticate a client before
+ accepting any BFCP message from it or sending any BFCP message to it.
+
+ BFCP supports TLS-based mutual authentication between clients and
+ floor control servers, as specified in Section 9.1. This is the
+ RECOMMENDED authentication mechanism in BFCP.
+
+ Note that future extensions may define additional authentication
+ mechanisms.
+
+ In addition to authenticating BFCP messages, floor control servers
+ need to authorize them. On receiving an authenticated BFCP message,
+ the floor control server checks whether the client sending the
+ message is authorized. If the client is not authorized to perform
+ the operation being requested, the floor control server generates an
+ Error message, as described in Section 13.8, with an Error code with
+ a value of 5 (Unauthorized Operation). Messages from a client that
+ cannot be authorized MUST NOT be processed further.
+
+
+
+
+Camarillo, et al. Standards Track [Page 36]
+
+RFC 4582 BFCP November 2006
+
+
+9.1. TLS-Based Mutual Authentication
+
+ BFCP supports TLS-based mutual authentication between clients and
+ floor control servers. BFCP assumes that there is an integrity-
+ protected channel between the client and the floor control server
+ that can be used to exchange their self-signed certificates or, more
+ commonly, the fingerprints of these certificates. These certificates
+ are used at TLS establishment time.
+
+ The implementation of such an integrity-protected channel using
+ SIP and the SDP offer/answer model is described in [7].
+
+ BFCP messages received over an authenticated TLS connection are
+ considered authenticated. A floor control server that receives a
+ BFCP message over TCP (no TLS) can request the use of TLS by
+ generating an Error message, as described in Section 13.8, with an
+ Error code with a value of 9 (Use TLS). Clients SHOULD simply ignore
+ unauthenticated messages.
+
+ Note that future extensions may define additional authentication
+ mechanisms that may not require an initial integrity-protected
+ channel (e.g., authentication based on certificates signed by a
+ certificate authority).
+
+ As described in Section 9, floor control servers need to perform
+ authorization before processing any message. In particular, the
+ floor control server SHOULD check that messages arriving over a given
+ authenticated TLS connection use an authorized User ID (i.e., a User
+ ID that the user that established the authenticated TLS connection is
+ allowed to use).
+
+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.
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 37]
+
+RFC 4582 BFCP November 2006
+
+
+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. This User ID will be used by the
+ floor control server to authenticate and authorize the request. 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 name space 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.
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 38]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 MAY 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 MAY display to the user.
+
+ The BENEFICIARY-INFORMATION attribute identifies the beneficiary of
+ the floor request in third-party floor requests. The
+ REQUESTED-BY-INFORMATION attribute 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.
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 39]
+
+RFC 4582 BFCP November 2006
+
+
+ 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.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. This User ID will be used by the floor
+ control server to authenticate and authorize the request.
+
+ 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
+ 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.
+
+
+
+Camarillo, et al. Standards Track [Page 40]
+
+RFC 4582 BFCP November 2006
+
+
+ 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
+ participant's identifier. This User ID will be used by the floor
+ control server to authenticate and authorize the request.
+
+ 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
+
+
+
+
+Camarillo, et al. Standards Track [Page 41]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 SHOULD be set to
+ zero. The floor chair SHOULD use the Status Revoked to revoke a
+ floor that was granted (i.e., Granted status) and SHOULD 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 MAY use the Queue Position field to provide a queue
+ position for the floor request.
+
+ Note that a particular floor control server may implement a
+ different queue for each floor containing all the floor requests
+ that relate to that particular floor, a general queue for all
+ floor requests, or both. Also note that a floor request may
+ involve several floors and that a ChairAction message may only
+ deal with a subset of these floors (e.g., if a single floor chair
+ is not authorized to manage all the floors). In this case, the
+ floor control server will combine the instructions received from
+ the different floor chairs 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 use STATUS-INFO attributes to state the reason
+ why the floor or floors are being accepted, granted, or revoked. The
+ Text in the STATUS-INFO attribute is 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.
+
+
+
+Camarillo, et al. Standards Track [Page 42]
+
+RFC 4582 BFCP November 2006
+
+
+ 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.
+ This User ID will be used by the floor control server to authenticate
+ and authorize the request.
+
+ 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
+
+
+
+Camarillo, et al. Standards Track [Page 43]
+
+RFC 4582 BFCP November 2006
+
+
+ FloorRequest 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 will
+ 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.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.
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 44]
+
+RFC 4582 BFCP November 2006
+
+
+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.
+ This User ID will be used by the floor control server to authenticate
+ and authorize the request.
+
+ The client must insert a FLOOR-REQUEST-ID attribute that identifies
+ the floor request at the floor control server.
+
+12.2.2. Receiving a Response
+
+ A message from the floor control server 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
+
+
+
+Camarillo, et al. Standards Track [Page 45]
+
+RFC 4582 BFCP November 2006
+
+
+ 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.
+ This User ID will be used by the floor control server to authenticate
+ and authorize the request.
+
+ 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.
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 46]
+
+RFC 4582 BFCP November 2006
+
+
+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.
+ This User ID will be used by the floor control server to authenticate
+ and authorize the request.
+
+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-PRIMITVIES 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
+ does not, the floor control server SHOULD 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 SHOULD send an
+ Error message, as described in Section 13.8, with Error code 1
+ (Conference does not Exist).
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 47]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 SHOULD send an Error
+ message, as described in Section 13.8, with Error code 2
+ (Authentication Failed). The Error message SHOULD list the
+ attributes that 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 SHOULD 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.
+
+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
+
+
+
+Camarillo, et al. Standards Track [Page 48]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 PARTICIPANT-
+ PROVIDED-INFO 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.
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 49]
+
+RFC 4582 BFCP November 2006
+
+
+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.)
+
+ The floor control server MUST set the Transaction ID of subsequent
+ FloorRequestStatus messages to 0.
+
+ 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.
+
+
+
+Camarillo, et al. Standards Track [Page 50]
+
+RFC 4582 BFCP November 2006
+
+
+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 SHOULD
+ 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.
+
+ 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.
+
+
+
+
+Camarillo, et al. Standards Track [Page 51]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 SHOULD 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.
+
+ 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.
+
+
+
+Camarillo, et al. Standards Track [Page 52]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 SHOULD 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.
+
+ 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.
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 53]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 requested
+ (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 FloorRelease message, the floor control
+ server encounters an error, it SHOULD generate an Error response
+ following the procedures described in Section 13.8.
+
+ 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.
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 54]
+
+RFC 4582 BFCP November 2006
+
+
+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.
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 55]
+
+RFC 4582 BFCP November 2006
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+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 SHOULD 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.
+
+
+
+Camarillo, et al. Standards Track [Page 56]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 SHOULD generate an Error response following the procedures
+ described in Section 13.8.
+
+ 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.
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 57]
+
+RFC 4582 BFCP November 2006
+
+
+ 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 to provide mutual authentication between clients and
+ servers. TLS also provides replay and integrity protection and
+ confidentiality. It is RECOMMENDED that TLS with non-null encryption
+ always be used. BFCP entities MAY use other security mechanisms as
+ long as they provide similar security properties.
+
+ The 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 connections. The floor control server assumes that
+ attackers cannot highjack the TLS connection and, therefore, that
+ messages over the TLS connection come from the client that was
+ initially authenticated.
+
+ An attacker may attempt to impersonate a floor control server. A
+ successful attacker would be able to make clients think that they
+ hold a particular floor so that they would try to access a resource
+ (e.g., sending media) without having legitimate rights to access it.
+ Floor control server impersonation is avoided by having servers only
+ accept BFCP messages over authenticated TLS connections.
+
+
+
+
+Camarillo, et al. Standards Track [Page 58]
+
+RFC 4582 BFCP November 2006
+
+
+ Attackers may attempt to modify messages exchanged by a client and a
+ floor control server. The integrity protection provided by TLS
+ connections prevents this attack.
+
+ An attacker may attempt to fetch a valid message sent by a client to
+ a floor control server and replay it over a connection between the
+ attacker and the floor control server. This attack is prevented by
+ having floor control servers check that messages arriving over a
+ given authenticated TLS connection use an authorized user ID (i.e., a
+ user ID that the user that established the authenticated TLS
+ connection is allowed to use).
+
+ Attackers may attempt to pick messages from the network to get access
+ to confidential information between the floor control server and a
+ client (e.g., why a floor request was denied). TLS confidentiality
+ prevents this attack. Therefore, it is RECOMMENDED that TLS be used
+ with a non-null encryption algorithm.
+
+15. IANA Considerations
+
+ The IANA has created a new registry for BFCP parameters called
+ "Binary Floor Control Protocol (BFCP) Parameters". This new registry
+ has a number of subregistries, which are described in the following
+ sections.
+
+15.1. Attribute Subregistry
+
+ This section establishes the Attribute subregistry under the BFCP
+ Parameters registry. As per the terminology in RFC 2434 [4], the
+ registration policy for BFCP attributes shall be "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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 59]
+
+RFC 4582 BFCP November 2006
+
+
+ +------+---------------------------+------------+
+ | Type | Attribute | Reference |
+ +------+---------------------------+------------+
+ | 1 | BENEFICIARY-ID | [RFC 4582] |
+ | 2 | FLOOR-ID | [RFC 4582] |
+ | 3 | FLOOR-REQUEST-ID | [RFC 4582] |
+ | 4 | PRIORITY | [RFC 4582] |
+ | 5 | REQUEST-STATUS | [RFC 4582] |
+ | 6 | ERROR-CODE | [RFC 4582] |
+ | 7 | ERROR-INFO | [RFC 4582] |
+ | 8 | PARTICIPANT-PROVIDED-INFO | [RFC 4582] |
+ | 9 | STATUS-INFO | [RFC 4582] |
+ | 10 | SUPPORTED-ATTRIBUTES | [RFC 4582] |
+ | 11 | SUPPORTED-PRIMITIVES | [RFC 4582] |
+ | 12 | USER-DISPLAY-NAME | [RFC 4582] |
+ | 13 | USER-URI | [RFC 4582] |
+ | 14 | BENEFICIARY-INFORMATION | [RFC 4582] |
+ | 15 | FLOOR-REQUEST-INFORMATION | [RFC 4582] |
+ | 16 | REQUESTED-BY-INFORMATION | [RFC 4582] |
+ | 17 | FLOOR-REQUEST-STATUS | [RFC 4582] |
+ | 18 | OVERALL-REQUEST-STATUS | [RFC 4582] |
+ +------+---------------------------+------------+
+
+ Table 6: Initial values of the BFCP Attribute subregistry
+
+15.2. Primitive Subregistry
+
+ This section establishes the Primitive subregistry under the BFCP
+ Parameters registry. As per the terminology in RFC 2434 [4], the
+ registration policy for BFCP primitives shall be "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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 60]
+
+RFC 4582 BFCP November 2006
+
+
+ +-------+--------------------+------------+
+ | Value | Primitive | Reference |
+ +-------+--------------------+------------+
+ | 1 | FloorRequest | [RFC 4582] |
+ | 2 | FloorRelease | [RFC 4582] |
+ | 3 | FloorRequestQuery | [RFC 4582] |
+ | 4 | FloorRequestStatus | [RFC 4582] |
+ | 5 | UserQuery | [RFC 4582] |
+ | 6 | UserStatus | [RFC 4582] |
+ | 7 | FloorQuery | [RFC 4582] |
+ | 8 | FloorStatus | [RFC 4582] |
+ | 9 | ChairAction | [RFC 4582] |
+ | 10 | ChairActionAck | [RFC 4582] |
+ | 11 | Hello | [RFC 4582] |
+ | 12 | HelloAck | [RFC 4582] |
+ | 13 | Error | [RFC 4582] |
+ +-------+--------------------+------------+
+
+ Table 7: Initial values of the BFCP primitive subregistry
+
+15.3. Request Status Subregistry
+
+ This section establishes the Request Status subregistry under the
+ BFCP Parameters registry. As per the terminology in RFC 2434 [4],
+ the registration policy for BFCP request status shall be
+ "Specification Required". For the purposes of this subregistry, the
+ BFCP request status 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 4582] |
+ | 2 | Accepted | [RFC 4582] |
+ | 3 | Granted | [RFC 4582] |
+ | 4 | Denied | [RFC 4582] |
+ | 5 | Cancelled | [RFC 4582] |
+ | 6 | Released | [RFC 4582] |
+ | 7 | Revoked | [RFC 4582] |
+ +-------+-----------+------------+
+
+ Table 8: Initial values of the Request Status subregistry
+
+
+
+Camarillo, et al. Standards Track [Page 61]
+
+RFC 4582 BFCP November 2006
+
+
+15.4. Error Code Subregistry
+
+ This section establishes the Error Code subregistry under the BFCP
+ Parameters registry. As per the terminology in RFC 2434 [4], the
+ registration policy for BFCP error codes shall be "Specification
+ Required". For 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 4582] |
+ | 2 | User does not Exist | [RFC 4582] |
+ | 3 | Unknown Primitive | [RFC 4582] |
+ | 4 | Unknown Mandatory Attribute | [RFC 4582] |
+ | 5 | Unauthorized Operation | [RFC 4582] |
+ | 6 | Invalid Floor ID | [RFC 4582] |
+ | 7 | Floor Request ID Does Not Exist | [RFC 4582] |
+ | 8 | You have Already Reached the Maximum Number | [RFC 4582] |
+ | | of Ongoing Floor Requests for this Floor | |
+ | 9 | Use TLS | [RFC 4582] |
+ +-------+-----------------------------------------------+-----------+
+
+ Table 9: Initial Values of the Error Code subregistry
+
+16. Acknowledgements
+
+ The XCON WG chairs, Adam Roach and Alan Johnston, provided useful
+ ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat,
+ Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben
+ Campbell, Dave Morgan, and Oscar Novo provided useful comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 62]
+
+RFC 4582 BFCP November 2006
+
+
+17. References
+
+17.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+ Protocol Version 1.1", RFC 4346, April 2006.
+
+ [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+ [5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
+ Transport Layer Security (TLS)", RFC 3268, June 2002.
+
+ [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
+ 63, RFC 3629, November 2003.
+
+ [7] Camarillo, G., "Session Description Protocol (SDP) Format for
+ Binary Floor Control Protocol (BFCP) Streams", RFC 4583,
+ November 2006.
+
+17.2. Informational References
+
+ [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+ Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+ [9] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
+ "Requirements for Floor Control Protocols", RFC 4376, February
+ 2006.
+
+ [10] Barnes, M. and C. Boulton, "A Framework and Data Model for
+ Centralized Conferencing", Work in Progress, February 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 63]
+
+RFC 4582 BFCP November 2006
+
+
+Authors' Addresses
+
+ Gonzalo Camarillo
+ Ericsson
+ Hirsalantie 11
+ Jorvas 02420
+ Finland
+
+ EMail: Gonzalo.Camarillo@ericsson.com
+
+
+ Joerg Ott
+ Helsinki University of Technology
+ Department for Electrical and Communications Engineering
+ Networking Laboratory
+ PO Box 3000
+ 02015 TKK
+ Finland
+
+ EMail: jo@netlab.hut.fi
+
+
+ Keith Drage
+ Lucent Technologies
+ Windmill Hill Business Park
+ Swindon
+ Wiltshire SN5 6PP
+ UK
+
+ EMail: drage@lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 64]
+
+RFC 4582 BFCP November 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
+ AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
+ THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
+ IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
+ PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 65]
+