tech-invite   World Map     

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

RFC 4582

 
 
 

The Binary Floor Control Protocol (BFCP)

Part 2 of 3, p. 14 to 37
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 14 
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.

Top      Up      ToC       Page 15 
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

Top      Up      ToC       Page 16 
   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.

Top      Up      ToC       Page 17 
      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,

Top      Up      ToC       Page 18 
   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.

Top      Up      ToC       Page 19 
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.

Top      Up      ToC       Page 20 
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.

Top      Up      ToC       Page 21 
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.

Top      Up      ToC       Page 22 
   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.

Top      Up      ToC       Page 23 
   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.

Top      Up      ToC       Page 24 
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

Top      Up      ToC       Page 25 
   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.

Top      Up      ToC       Page 26 
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.

Top      Up      ToC       Page 27 
      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:

Top      Up      ToC       Page 28 
      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.)

Top      Up      ToC       Page 29 
   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

Top      Up      ToC       Page 30 
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.

Top      Up      ToC       Page 31 
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:

Top      Up      ToC       Page 32 
   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

Top      Up      ToC       Page 33 
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

Top      Up      ToC       Page 34 
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.

Top      Up      ToC       Page 35 
   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.

Top      Up      ToC       Page 36 
   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.

Top      Up      ToC       Page 37 
9.1.  TLS-Based Mutual Authentication

   BFCP supports TLS-based mutual authentication between clients and
   floor control servers.  BFCP assumes that there is an integrity-
   protected channel between the client and the floor control server
   that can be used to exchange their self-signed certificates or, more
   commonly, the fingerprints of these certificates.  These certificates
   are used at TLS establishment time.

      The implementation of such an integrity-protected channel using
      SIP and the SDP offer/answer model is described in [7].

   BFCP messages received over an authenticated TLS connection are
   considered authenticated.  A floor control server that receives a
   BFCP message over TCP (no TLS) can request the use of TLS by
   generating an Error message, as described in Section 13.8, with an
   Error code with a value of 9 (Use TLS).  Clients SHOULD simply ignore
   unauthenticated messages.

      Note that future extensions may define additional authentication
      mechanisms that may not require an initial integrity-protected
      channel (e.g., authentication based on certificates signed by a
      certificate authority).

   As described in Section 9, floor control servers need to perform
   authorization before processing any message.  In particular, the
   floor control server SHOULD check that messages arriving over a given
   authenticated TLS connection use an authorized User ID (i.e., a User
   ID that the user that established the authenticated TLS connection is
   allowed to use).



(page 37 continued on part 3)

Next RFC Part