tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4582

Proposed STD
Pages: 65
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: XCON

The Binary Floor Control Protocol (BFCP)

Part 1 of 3, p. 1 to 14
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part