Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4582

The Binary Floor Control Protocol (BFCP)

Pages: 65
Obsoleted by:  8855
Updated by:  8996
Part 1 of 3 – Pages 1 to 14
None   None   Next

Top   ToC   RFC4582 - Page 1
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
Top   ToC   RFC4582 - Page 2
   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
Top   ToC   RFC4582 - Page 3
           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
Top   ToC   RFC4582 - Page 4

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.
Top   ToC   RFC4582 - Page 5
   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].
Top   ToC   RFC4582 - Page 6
   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.
Top   ToC   RFC4582 - Page 7

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).
Top   ToC   RFC4582 - Page 8

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.
Top   ToC   RFC4582 - Page 9
      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.
Top   ToC   RFC4582 - Page 10
      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                          |
              |---------------------------------------------->|
Top   ToC   RFC4582 - Page 11
              |                                               |
              |(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                                  |
              |---------------------------------------------->|
Top   ToC   RFC4582 - Page 12
              |                                               |
              |(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          |
              |<----------------------------------------------|
Top   ToC   RFC4582 - Page 13
              |                                               |
              |(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.
Top   ToC   RFC4582 - Page 14
   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



(page 14 continued on part 2)

Next Section