draft-ietf-xcon-bfcp-03.txt   draft-ietf-xcon-bfcp-04.txt 
XCON Working Group G. Camarillo XCON Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: July 1, 2005 J. Ott Expires: November 5, 2005 J. Ott
Universitaet Bremen Helsinki University of Technology
K. Drage K. Drage
Lucent Technologies Lucent Technologies
December 31, 2004 May 4, 2005
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-xcon-bfcp-03.txt draft-ietf-xcon-bfcp-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 1, 2005. This Internet-Draft will expire on November 5, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
Floor control is a means to manage joint or exclusive access to Floor control is a means to manage joint or exclusive access to
shared resources in a (multiparty) conferencing environment. shared resources in a (multiparty) conferencing environment.
Thereby, floor control complements other functions -- such as Thereby, floor control complements other functions -- such as
conference and media session setup, conference policy manipulation, conference and media session setup, conference policy manipulation,
and media control -- that are realized by other protocols. and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP). This document specifies the Binary Floor Control Protocol (BFCP).
BFCP is used between floor participants and floor control servers, BFCP is used between floor participants and floor control servers,
and between floor chairs (i.e., moderators) and floor control and between floor chairs (i.e., moderators) and floor control
servers. servers.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Obtaining Information to Contact a Floor Control Server . 8 3.2 Obtaining Information to Contact a Floor Control Server . 8
3.3 Generating a Shared Secret . . . . . . . . . . . . . . . . 8 3.3 Generating a Shared Secret . . . . . . . . . . . . . . . . 8
3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 8 3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 8
3.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . 9 3.5 Privileges of Floor Control . . . . . . . . . . . . . . . 9
4. Overview of Operation . . . . . . . . . . . . . . . . . . . 9 4. Overview of Operation . . . . . . . . . . . . . . . . . . . 9
4.1 Floor Participant to Floor Control Server Interface . . . 10 4.1 Floor Participant to Floor Control Server Interface . . . 10
4.2 Floor Chair to Floor Control Server Interface . . . . . . 13 4.2 Floor Chair to Floor Control Server Interface . . . . . . 13
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 14 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 14 5.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 15
5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 15 5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 16
5.2.1 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.1 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 17
5.2.2 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.2 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.3 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 17 5.2.3 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 18
5.2.4 TRANSACTION-ID . . . . . . . . . . . . . . . . . . . . 18 5.2.4 NONCE . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.5 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 18 5.2.5 TRANSACTION-ID . . . . . . . . . . . . . . . . . . . . 19
5.2.6 HUMAN-READABLE-INFO . . . . . . . . . . . . . . . . . 18 5.2.6 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.7 DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.7 PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.8 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 20 5.2.8 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 20
5.2.9 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 21 5.2.9 DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.10 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 23 5.2.10 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . 23
5.2.11 USER-URI . . . . . . . . . . . . . . . . . . . . . . 23 5.2.11 ERROR-INFO . . . . . . . . . . . . . . . . . . . . . 25
5.2.12 PRIORITY . . . . . . . . . . . . . . . . . . . . . . 23 5.2.12 PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . 25
5.2.13 NONCE . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.13 STATUS-INFO . . . . . . . . . . . . . . . . . . . . 26
5.2.14 SUPPORTED-TLVS . . . . . . . . . . . . . . . . . . . 24 5.2.14 SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . 27
5.3 Message Format . . . . . . . . . . . . . . . . . . . . . . 24 5.2.15 SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . 27
5.3.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . 24 5.2.16 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 28
5.3.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . 25 5.2.17 USER-URI . . . . . . . . . . . . . . . . . . . . . . 29
5.3.3 FloorRequestInfoWanted . . . . . . . . . . . . . . . . 25 5.2.18 BENEFICIARY-INFORMATION . . . . . . . . . . . . . . 29
5.3.4 FloorRequestInfo . . . . . . . . . . . . . . . . . . . 26 5.2.19 FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . 30
5.3.5 FloorInfoWanted . . . . . . . . . . . . . . . . . . . 26 5.2.20 REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . 31
5.3.6 FloorInfo . . . . . . . . . . . . . . . . . . . . . . 27 5.3 Message Format . . . . . . . . . . . . . . . . . . . . . . 31
5.3.7 ChairAction . . . . . . . . . . . . . . . . . . . . . 27 5.3.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . 31
5.3.8 ChairActionAck . . . . . . . . . . . . . . . . . . . . 28 5.3.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . 32
5.3.9 Hello . . . . . . . . . . . . . . . . . . . . . . . . 28 5.3.3 FloorRequestInfoWanted . . . . . . . . . . . . . . . . 32
5.3.10 HelloAck . . . . . . . . . . . . . . . . . . . . . . 28 5.3.4 FloorRequestInfo . . . . . . . . . . . . . . . . . . . 33
5.3.11 Error . . . . . . . . . . . . . . . . . . . . . . . 29 5.3.5 UserInfoWanted . . . . . . . . . . . . . . . . . . . . 33
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.3.6 UserInfo . . . . . . . . . . . . . . . . . . . . . . . 34
7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 30 5.3.7 FloorInfoWanted . . . . . . . . . . . . . . . . . . . 34
8. Protocol Transactions . . . . . . . . . . . . . . . . . . . 30 5.3.8 FloorInfo . . . . . . . . . . . . . . . . . . . . . . 34
8.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 5.3.9 ChairAction . . . . . . . . . . . . . . . . . . . . . 35
8.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 31 5.3.10 ChairActionAck . . . . . . . . . . . . . . . . . . . 35
9. Authentication and Authorization . . . . . . . . . . . . . . 31 5.3.11 Hello . . . . . . . . . . . . . . . . . . . . . . . 36
9.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 5.3.12 HelloAck . . . . . . . . . . . . . . . . . . . . . . 36
9.2 Floor Control Server Behavior . . . . . . . . . . . . . . 32 5.3.13 Error . . . . . . . . . . . . . . . . . . . . . . . 36
10. Floor Participant Operations . . . . . . . . . . . . . . . . 33 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 33 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 38
10.1.1 Sending a FloorRequest Message . . . . . . . . . . . 33 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . 38
10.1.2 Receiving a Response . . . . . . . . . . . . . . . . 34 8.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 38
10.2 Cancelling a Floor Request and Releasing a Floor . . . . 35 8.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 38
10.2.1 Sending a FloorRelease Message . . . . . . . . . . . 35 9. Authentication and Authorization . . . . . . . . . . . . . . 39
10.2.2 Receiving a Response . . . . . . . . . . . . . . . . 36 9.1 TLS-based Mutual Authentication . . . . . . . . . . . . . 39
11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 36 9.2 Digest-based Client Authentication . . . . . . . . . . . . 39
11.1 Sending a ChairAction Message . . . . . . . . . . . . . 36 9.2.1 Client Behavior . . . . . . . . . . . . . . . . . . . 40
11.2 Receiving a Response . . . . . . . . . . . . . . . . . . 37 9.2.2 Floor Control Server Behavior . . . . . . . . . . . . 41
12. General Client Operations . . . . . . . . . . . . . . . . . 38 10. Floor Participant Operations . . . . . . . . . . . . . . . . 42
12.1 Requesting Information about Floors . . . . . . . . . . 38 10.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 42
12.1.1 Sending a FloorInfoWanted Message . . . . . . . . . 38 10.1.1 Sending a FloorRequest Message . . . . . . . . . . . 43
12.1.2 Receiving a Response . . . . . . . . . . . . . . . . 38 10.1.2 Receiving a Response . . . . . . . . . . . . . . . . 43
12.2 Requesting Information about Floor Requests . . . . . . 39 10.2 Cancelling a Floor Request and Releasing a Floor . . . . 44
12.2.1 Sending a FloorRequestInfoWanted Message . . . . . . 40 10.2.1 Sending a FloorRelease Message . . . . . . . . . . . 45
12.2.2 Receiving a Response . . . . . . . . . . . . . . . . 40 10.2.2 Receiving a Response . . . . . . . . . . . . . . . . 45
12.3 Obtaining the Capabilities of a Floor Control Server . . 41 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 46
12.3.1 Sending a Hello Message . . . . . . . . . . . . . . 41 11.1 Sending a ChairAction Message . . . . . . . . . . . . . 46
12.3.2 Receiving Responses . . . . . . . . . . . . . . . . 41 11.2 Receiving a Response . . . . . . . . . . . . . . . . . . 47
13. Floor Control Server Operations . . . . . . . . . . . . . . 41 12. General Client Operations . . . . . . . . . . . . . . . . . 47
13.1 Reception of a FloorRequest Message . . . . . . . . . . 42 12.1 Requesting Information about Floors . . . . . . . . . . 47
13.1.1 Generating the First FloorRequestInfo Message . . . 42 12.1.1 Sending a FloorInfoWanted Message . . . . . . . . . 48
13.1.2 Generation of Subsequent FloorRequestInfo Messages . 43 12.1.2 Receiving a Response . . . . . . . . . . . . . . . . 48
13.2 Reception of a FloorRequestInfoWanted Message . . . . . 44 12.2 Requesting Information about Floor Requests . . . . . . 49
13.2.1 Information on a Single Floor Request . . . . . . . 44 12.2.1 Sending a FloorRequestInfoWanted Message . . . . . . 49
13.2.2 Information on the Floor Requests Associated to a 12.2.2 Receiving a Response . . . . . . . . . . . . . . . . 50
Participant . . . . . . . . . . . . . . . . . . . . 45 12.3 Requesting Information about a User . . . . . . . . . . 50
13.3 Reception of a FloorRelease Message . . . . . . . . . . 45 12.3.1 Sending a UserInfoWanted Message . . . . . . . . . . 50
13.4 Reception of a FloorInfoWanted Message . . . . . . . . . 46 12.3.2 Receiving a Response . . . . . . . . . . . . . . . . 51
13.4.1 Generation of the First FloorInfo Message . . . . . 47 12.4 Obtaining the Capabilities of a Floor Control Server . . 51
13.4.2 Generation of Subsequent FloorInfo Messages . . . . 47 12.4.1 Sending a Hello Message . . . . . . . . . . . . . . 51
13.5 Reception of a ChairAction Message . . . . . . . . . . . 48 12.4.2 Receiving Responses . . . . . . . . . . . . . . . . 51
13.6 Reception of a Hello Message . . . . . . . . . . . . . . 49 13. Floor Control Server Operations . . . . . . . . . . . . . . 52
13.7 Error Message Generation . . . . . . . . . . . . . . . . 49 13.1 Reception of a FloorRequest Message . . . . . . . . . . 52
14. Security Considerations . . . . . . . . . . . . . . . . . . 49 13.1.1 Generating the First FloorRequestInfo Message . . . 53
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 51 13.1.2 Generation of Subsequent FloorRequestInfo Messages . 54
15.1 Attribute Subregistry . . . . . . . . . . . . . . . . . 51 13.2 Reception of a FloorRequestInfoWanted Message . . . . . 55
15.2 Primitive Subregistry . . . . . . . . . . . . . . . . . 51 13.3 Reception of a UserInfoWanted Message . . . . . . . . . 56
15.3 Request Status Subregistry . . . . . . . . . . . . . . . 52 13.4 Reception of a FloorRelease Message . . . . . . . . . . 57
15.4 Error Code Subregistry . . . . . . . . . . . . . . . . . 53 13.5 Reception of a FloorInfoWanted Message . . . . . . . . . 59
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 54 13.5.1 Generation of the First FloorInfo Message . . . . . 59
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 13.5.2 Generation of Subsequent FloorInfo Messages . . . . 60
17.1 Normative References . . . . . . . . . . . . . . . . . . . 54 13.6 Reception of a ChairAction Message . . . . . . . . . . . 61
17.2 Informational References . . . . . . . . . . . . . . . . . 55 13.7 Reception of a Hello Message . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56 13.8 Error Message Generation . . . . . . . . . . . . . . . . 62
Intellectual Property and Copyright Statements . . . . . . . 57 14. Security Considerations . . . . . . . . . . . . . . . . . . 62
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 64
15.1 Attribute Subregistry . . . . . . . . . . . . . . . . . 64
15.2 Primitive Subregistry . . . . . . . . . . . . . . . . . 65
15.3 Request Status Subregistry . . . . . . . . . . . . . . . 65
15.4 Error Code Subregistry . . . . . . . . . . . . . . . . . 66
15.5 Digest Algorithm Subregistry . . . . . . . . . . . . . . 67
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 67
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 68
17.1 Normative References . . . . . . . . . . . . . . . . . . 68
17.2 Informational References . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 69
Intellectual Property and Copyright Statements . . . . . . . 70
1. Introduction 1. Introduction
Within a conference, some applications need to manage the access to a Within a conference, some applications need to manage the access to a
set of shared resources, such as the right to send media over a set of shared resources, such as the right to send media over a
particular media stream. Floor control enables such applications to particular media stream. Floor control enables such applications to
provide users with coordinated (shared or exclusive) access to these provide users with coordinated (shared or exclusive) access to these
resources. resources.
The Requirements for Floor Control Protocol [11] list a set of The Requirements for Floor Control Protocol [10] list a set of
requirements that need to be met by floor control protocols. The requirements that need to be met by floor control protocols. The
Binary Floor Control Protocol (BFCP), which is specified in this Binary Floor Control Protocol (BFCP), which is specified in this
document, meets these requirements. document, meets these requirements.
In addition, BFCP has been designed so that it can be used in In addition, BFCP has been designed so that it can be used in low-
low-bandwidth environments. The binary encoding used by BFCP bandwidth environments. The binary encoding used by BFCP achieves a
achieves a small message size (when message signatures are not used) small message size (when message signatures are not used) that keeps
that keeps the time it takes to transmit delay-sensitive BFCP the time it takes to transmit delay-sensitive BFCP messages at
messages at minimum. Delay-sensitive BFCP messages include minimum. Delay-sensitive BFCP messages include FloorRequest,
FloorRequest, FloorRelease, FloorRequestInfo, and ChairAction. It is FloorRelease, FloorRequestInfo, and ChairAction. It is expected that
expected that future extensions to these messages do not increase the future extensions to these messages do not increase the size of these
size of these messages in a significant way. messages in a significant way.
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows: Section 2
defines the terminology used throughout this document and Section 3 defines the terminology used throughout this document, Section 3
discusses the scope of BFCP (i.e., which tasks fall within the scope discusses the scope of BFCP (i.e., which tasks fall within the scope
of BFCP and which ones are performed using different mechanisms). of BFCP and which ones are performed using different mechanisms),
Section 4 provides a non-normative overview of BFCP operation and Section 4 provides a non-normative overview of BFCP operation, and
subsequent sections provide the normative specification of BFCP. subsequent sections provide the normative specification of BFCP.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [2] and indicate requirement levels for described in BCP 14, RFC 2119 [2] and indicate requirement levels for
compliant implementations. compliant implementations.
Media Participant: An entity that has access to the media resources Media Participant: An entity that has access to the media resources
of a conference (e.g., it can receive a media stream). In of a conference (e.g., it can receive a media stream). In floor-
floor-controlled conferences, a given media participant is typically controlled conferences, a given media participant is typically co-
co-located with a floor participant, but does not need to. located with a floor participant, but does not need to. Third-party
Third-party floor requests consist of having a floor participant floor requests consist of having a floor participant request a floor
request a floor for a media participant when they are not colocated. for a media participant when they are not colocated. The protocol
The protocol between a floor participant and a media participant between a floor participant and a media participant (that are not
(that are not colocated) is outside the scope of this document. colocated) is outside the scope of this document.
Client: a floor participant or a floor chair that communicate with a Client: a floor participant or a floor chair that communicate with a
floor control server using BFCP. floor control server using BFCP.
Conference Policy: The complete set of rules for a particular
conference. It includes the membership policy, the media policy, and
policies related to floors and the use of floor control protocols.
There is an instance of conference policy for each conference.
Floor: A permission to temporarily access or manipulate a specific Floor: A permission to temporarily access or manipulate a specific
shared resource or set of resources. shared resource or set of resources.
Floor Chair: A logical entity that manages one floor (grants, denies, Floor Chair: A logical entity that manages one floor (grants, denies,
or revokes a floor). An entity that assumes the logical role of a or revokes a floor). An entity that assumes the logical role of a
floor chair for a given transaction may assume a different role floor chair for a given transaction may assume a different role
(e.g., floor participant) for a different transaction. The roles of (e.g., floor participant) for a different transaction. The roles of
floor chair and floor participant are defined on a floor chair and floor participant are defined on a transaction-by-
transaction-by-transaction basis. BFCP transactions are defined in transaction basis. BFCP transactions are defined in Section 8.
Section 8.
Floor Control: A mechanism that enables applications or users to gain Floor Control: A mechanism that enables applications or users to gain
safe and mutually exclusive or non-exclusive input access to the safe and mutually exclusive or non-exclusive input access to the
shared object or resource. shared object or resource.
Floor Control Server: A logical entity that maintains the state of Floor Control Server: A logical entity that maintains the state of
the floor(s) including which floors exists, who the floor chairs are, the floor(s) including which floors exists, who the floor chairs are,
who holds a floor, etc. Requests to manipulate a floor are directed who holds a floor, etc. Requests to manipulate a floor are directed
at the floor control server. The floor control server of a at the floor control server. The floor control server of a
conference may perform other logical roles (e.g., floor participant) conference may perform other logical roles (e.g., floor participant)
skipping to change at page 6, line 50 skipping to change at page 6, line 44
media participant, but does not need to. Third-party floor requests media participant, but does not need to. Third-party floor requests
consist of having a floor participant request a floor for a media consist of having a floor participant request a floor for a media
participant when they are not co-located. participant when they are not co-located.
Participant: An entity that acts as a floor participant, as a media Participant: An entity that acts as a floor participant, as a media
participant, or as both. participant, or as both.
3. Scope 3. Scope
As stated earlier, BFCP is a protocol to coordinate access to shared As stated earlier, BFCP is a protocol to coordinate access to shared
resources in a conference following the requirements defined in [11]. resources in a conference following the requirements defined in [10].
Floor control complements other functions defined in the conferencing Floor control complements other functions defined in the XCON
framework [12]. In particular, it is the conference policy that conferencing framework [12] and is compatible with the SIPPING
defines which media streams and applications are floor-controlled, conferencing framework [11]. The floor control protocol BFCP defined
who is/are the respective floor chair(s), and how access to the floor in this document only specifies a means to arbitrate access to
is managed. Furthermore, it is up to the media policy to define floors. The rules and constraints for floor arbitration and the
which (if any) impact on media stream handling (e.g. switching or results of floor assignments are outside the scope of this document
mixing) assignment of a floor to a media participant has. and defined by other protocols [12].
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 defined by
other protocols [13].
Figure 1 shows the tasks that BFCP can perform. Figure 1 shows the tasks that BFCP can perform.
+---------+ +---------+
| Floor | | Floor |
| Chair | | Chair |
| | | |
+---------+ +---------+
^ | ^ |
| | | |
skipping to change at page 8, line 14 skipping to change at page 7, line 50
the scope of BFCP, some of these out-of-scope tasks relate to floor the scope of BFCP, some of these out-of-scope tasks relate to floor
control and are essential to create floors and to establish BFCP control and are essential to create floors and to establish BFCP
connections between different entities. In the following connections between different entities. In the following
subsections, we discuss some of these tasks and mechanisms to perform subsections, we discuss some of these tasks and mechanisms to perform
them. them.
3.1 Floor Creation 3.1 Floor Creation
The association of a given floor with a resource or a set of 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 resources (e.g., media streams) is out of the scope of BFCP as
described in [13]. The conference policy for a particular conference described in [12]. Floor creation and termination are also outside
contains the floors of the conference and the resource or resources the scope of BFCP; these aspects are handled using the conference
associated with each floor. For example, a conference may have two control protocol for manipulating the conference object.
floors: one controlling who can talk at a particular time and another Consequently, the floor control server needs to stay up to date on
controlling who can write on a shared whiteboard. changes to the conference object (e.g., when a new floor is created).
Floor creation and termination are also outside the scope of BFCP and
are aspects of the conference policy as well. Consequently, the
floor control server needs to stay up to date on changes on the
conference policy (e.g., when a new floor is created).
3.2 Obtaining Information to Contact a Floor Control Server 3.2 Obtaining Information to Contact a Floor Control Server
A client needs a set of data in order to establish a BFCP connection 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 to a floor control server. These data include the transport address
of the server, the conference identifier, and the user identifier. of the server, the conference identifier, and the user identifier.
Clients can obtain this information in different ways. One is to use Clients can obtain this information in different ways. One is to use
an offer/answer [10] exchange. How to use an SDP [8] offer/answer an offer/answer [9] exchange, which is described in [13]. Other
[10] exchange to obtain this information is described in [14]. mechanisms are also described in the XCON framework (and other
related documents).
3.3 Generating a Shared Secret 3.3 Generating a Shared Secret
Authentication in BFCP is based on a shared secret between the client Authentication in BFCP is based on a shared secret between the client
and the floor control server. So, there is a need for a mechanism to and the floor control server. So, there is a need for a mechanism to
generate such a shared secret. However, such mechanism is outside generate such a shared secret. However, such mechanism is outside
the scope of BFCP. the scope of BFCP.
Shared secrets can also be generated and exchanged using out-of-band Shared secrets can also be generated and exchanged using out-of-band
means. For example, when the floor participant or the floor chair means. For example, when the floor participant or the floor chair
obtains the information needed to contact the BFCP floor control obtains the information needed to contact the BFCP floor control
server over a secure channel (e.g., an offer/answer [10] exchange server over a secure channel (e.g., an offer/answer [9] exchange
using SIP [9] protected using S/MIME), they can get the shared secret using SIP [8] protected using S/MIME), they can get the shared secret
using the same channel. using the same channel.
3.4 Obtaining Floor-Resource Associations 3.4 Obtaining Floor-Resource Associations
Floors are associated with resources. For example, a floor that Floors are associated with resources. For example, a floor that
controls who talks at a given time has a particular audio stream as controls who talks at a given time has a particular audio stream as
its associated resource. Associations between floors and resources its associated resource. Associations between floors and resources
are part of the conference policy. are part of the conference object.
Floor participants and floor chairs need to know which resources are Floor participants and floor chairs need to know which resources are
associated with which floors. They can obtain this information using associated with which floors. They can obtain this information using
different mechanisms, such as an offer/answer [10] exchange. How to different mechanisms, such as an offer/answer [9] exchange. How to
use an offer/answer exchange to obtain these associations is use an offer/answer exchange to obtain these associations is
described in [14]. described in [13].
Note that floor participants perform offer/answer exchanges with Note that floor participants perform offer/answer exchanges with
the SIP focus of the conference. So, the SIP focus needs to the SIP Focus of the conference. So, the SIP Focus needs to
obtain information about associations between floors and resources obtain information about associations between floors and resources
in order to be able to provide this information to a floor in order to be able to provide this information to a floor
participant in an offer/answer exchange. participant in an offer/answer exchange.
3.5 Policy Enforcement 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 (and other related documents).
3.5 Privileges of Floor Control
A participant whose floor request is granted has the right to use (in A participant whose floor request is granted has the right to use (in
a certain way) the resource or resources associated with the floor a certain way) the resource or resources associated with the floor
that was requested. For example, the participant may have the right that was requested. For example, the participant may have the right
to send media over a particular audio stream. to send media over a particular audio stream.
Nevertheless, holding a floor does not imply that others will not be 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 able to use its associated resources at the same time, even if they
do not have the right to do so. According to the definition in do not have the right to do so. Determination of which media
Section 2, the conference policy determines which media participants participants can actually use the resources in the conference is
can actually use the resources in the conference. discussed in the XCON Framework.
So, if the policy of a conference is to enforce floor control
decisions, every change in the status of any floor needs to be
reflected in the conference policy of the conference. For example,
the mixer only accepts media from the user who holds the floor.
4. Overview of Operation 4. Overview of Operation
This section provides a non-normative description of BFCP operations. This section provides a non-normative description of BFCP operations.
Section 4.1 describes the interface between floor participants and Section 4.1 describes the interface between floor participants and
floor control servers and Section 4.2 describes the interface between floor control servers and Section 4.2 describes the interface between
floor chairs and floor control servers floor chairs and floor control servers
BFCP messages, which use a TLV (Type-Length-Value) binary encoding, BFCP messages, which use a TLV (Type-Length-Value) binary encoding,
consist of a common header followed by a set of TLVs. The common consist of a common header followed by a set of attributes. The
header contains, among other information, a 32-bit conference common header contains, among other information, a 32-bit conference
identifier. Floor participants, media participants, and floor chairs identifier. Floor participants, media participants, and floor chairs
are identified by a 16-bit user identifier, which is carried in a are identified by a 16-bit user identifier, which is carried in an
TLV. attribute.
Participant authentication in BFCP is based on shared secrets. The
floor control server of a conference shares a secret with each of the
participants in the conference and can request them to sign their
messages using that shared secret.
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 There are two types of transactions in BFCP: client-initiated
transactions and server-initiated transactions. Client-initiated transactions and server-initiated transactions. Client-initiated
transactions consist of a message from a client to the floor control transactions consist of a message from a client to the floor control
server and a response from the floor control server to the client. server and a response from the floor control server to the client.
Both messages can be related because they carry the same Both messages can be related because they carry the same
TRANSACTION-ID TLV. Server-initiated transactions consist of a TRANSACTION-ID attribute. Server-initiated transactions consist of a
single message, which has no TRANSACTION-ID TLV, from the floor single message, which has no TRANSACTION-ID attribute, from the floor
control server to a client. control server to a client.
4.1 Floor Participant to Floor Control Server Interface 4.1 Floor Participant to Floor Control Server Interface
Floor participants request a floor by sending a FloorRequest message Floor participants request a floor by sending a FloorRequest message
to the floor control server. BFCP supports third-party floor to the floor control server. BFCP supports third-party floor
requests. That is, the floor participant sending the floor request requests. That is, the floor participant sending the floor request
need not be co-located with the media participant that will get the need not be co-located with the media participant that will get the
floor once the floor request is granted. FloorRequest messages carry floor once the floor request is granted. FloorRequest messages carry
the identity of the requester in a USER-ID TLV, and the identity of the identity of the requester in a USER-ID attribute, and the
the beneficiary of the floor, in third party floor requests, in a identity of the beneficiary of the floor, in third party floor
BENEFICIARY-ID TLV. requests, in a BENEFICIARY-ID attribute.
Third party floor requests can be sent, for example, by floor Third party floor requests can be sent, for example, by floor
participants that have a BFCP connection to the floor control participants that have a BFCP connection to the floor control
server but that are not media participants (i.e., they do not server but that are not media participants (i.e., they do not
handle any media). handle any media).
FloorRequest messages identify the floor or floors being requested by FloorRequest messages identify the floor or floors being requested by
carrying their 16-bit floor identifiers in FLOOR-ID TLVs. If a carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a
FloorRequest message carries more than one floor identifier, the FloorRequest message carries more than one floor identifier, the
floor control server treats all the floor requests as an atomic floor control server treats all the floor requests as an atomic
package. That is, the floor control server either grants or denies package. That is, the floor control server either grants or denies
all the floors in the FloorRequest message. all the floors in the FloorRequest message.
Floor control servers respond to FloorRequest messages with Floor control servers respond to FloorRequest messages with
FloorRequestInfo messages, which provide information about the status FloorRequestInfo messages, which provide information about the status
of the floor request. The first FloorRequestInfo message is the of the floor request. The first FloorRequestInfo message is the
response to the FloorRequest message from the client, and therefore response to the FloorRequest message from the client, and therefore
carries the same TRANSACTION-ID TLV as the FloorRequest. carries the same TRANSACTION-ID attribute as the FloorRequest.
Additionally, the first FloorRequestInfo message carries a Additionally, the first FloorRequestInfo message carries the Floor
FLOOR-REQUEST-ID TLV. Subsequent FloorRequestInfo messages related Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent
to the same floor request will carry the same FLOOR-REQUEST-ID TLV. FloorRequestInfo messages related to the same floor request will
This way, the floor participant can associate them with the carry the same Floor Request ID. This way, the floor participant can
appropriate floor request. associate them with the appropriate floor request.
Messages from the floor participant related to a particular floor Messages from the floor participant related to a particular floor
request also use the same FLOOR-REQUEST-ID TLV as the first request also use the same Floor Request ID as the first
FloorRequestInfo Message from the floor control server. FloorRequestInfo Message from the floor control server.
Figure 2 shows how a floor participant requests a floor, obtains it, Figure 2 shows how a floor participant requests a floor, obtains it,
and, at a later time, releases it. This figure illustrates the use, and, at a later time, releases it. This figure illustrates the use,
among other TLVs, of the TRANSACTION-ID and the FLOOR-REQUEST-ID among other attributes, of the TRANSACTION-ID and the
TLVs. FLOOR-REQUEST-ID attributes.
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorRequest | |(1) FloorRequest |
|TRANSACTION-ID: 123 |
|USER-ID: 234 | |USER-ID: 234 |
|TRANSACTION-ID: 123 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| |
|(2) FloorRequestInfo | |(2) FloorRequestInfo |
|TRANSACTION-ID: 123 |
|USER-ID: 234 | |USER-ID: 234 |
|FLOOR-REQUEST-ID: 789 | |TRANSACTION-ID: 123 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|REQUEST-STATUS: Pending | |REQUEST-STATUS: Pending |
|<----------------------------------------------| |<----------------------------------------------|
| |
|(3) FloorRequestInfo | |(3) FloorRequestInfo |
|USER-ID: 234 | |USER-ID: 234 |
|FLOOR-REQUEST-ID: 789 | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|REQUEST-STATUS: Accepted (1st in Queue) | |REQUEST-STATUS: Accepted (1st in Queue) |
|<----------------------------------------------| |<----------------------------------------------|
| |
|(4) FloorRequestInfo | |(4) FloorRequestInfo |
|USER-ID: 234 | |USER-ID: 234 |
|FLOOR-REQUEST-ID: 789 | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|REQUEST-STATUS: Granted | |REQUEST-STATUS: Granted |
|<----------------------------------------------| |<----------------------------------------------|
| |
|(5) FloorRelease | |(5) FloorRelease |
|TRANSACTION-ID: 154 |
|USER-ID: 234 | |USER-ID: 234 |
|TRANSACTION-ID: 154 |
|FLOOR-REQUEST-ID: 789 | |FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->| |---------------------------------------------->|
| |
|(6) FloorRequestInfo | |(6) FloorRequestInfo |
|TRANSACTION-ID: 154 |
|USER-ID: 234 | |USER-ID: 234 |
|FLOOR-REQUEST-ID: 789 | |TRANSACTION-ID: 154 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|REQUEST-STATUS: Released | |REQUEST-STATUS: Released |
|<----------------------------------------------| |<----------------------------------------------|
Figure 2: Requesting and releasing a floor Figure 2: Requesting and releasing a floor
Figure 2 shows how a floor participant requests to be informed on the
Figure 3 shows how a floor participant requests to be informed on the
status of a floor. The first FloorInfo message from the floor status of a floor. The first FloorInfo message from the floor
control server is the response to the FloorInfoWanted message, and as control server is the response to the FloorInfoWanted message, and as
such, carries the same TRANSACTION-ID TLV as the FloorInfoWanted such, carries the same TRANSACTION-ID attribute as the
message. FloorInfoWanted message.
Subsequent FloorInfo messages consist of server-initiated Subsequent FloorInfo messages consist of server-initiated
transactions, and therefore carry no TRANSACTION-ID TLV. FloorInfo transactions, and therefore carry no TRANSACTION-ID attribute.
message (2) indicates that there are currently two floor requests for FloorInfo message (2) indicates that there are currently two floor
the floor whose Floor ID is 543. FloorInfo message (3) indicates requests for the floor whose Floor ID is 543. FloorInfo message (3)
that the floor requests with Floor Request ID 764 has been granted, indicates that the floor requests with Floor Request ID 764 has been
while the floor request with Floor Request ID 635 is the first in the granted, while the floor request with Floor Request ID 635 is the
queue. FloorInfo message (4) indicates that the floor request with first in the queue. FloorInfo message (4) indicates that the floor
Floor Request ID 635 has been granted. request with Floor Request ID 635 has been granted.
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorInfoWanted | |(1) FloorInfoWanted |
|TRANSACTION-ID: 257 |
|USER-ID: 234 | |USER-ID: 234 |
|TRANSACTION-ID: 257 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| |
|(2) FloorInfo | |(2) FloorInfo |
|TRANSACTION-ID: 257 |
|USER-ID: 234 | |USER-ID: 234 |
|TRANSACTION-ID: 257 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-ID: 764 | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|BENEFICIARY-ID: 124 | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|REQUEST-STATUS: Accepted (1st in Queue) | |REQUEST-STATUS: Accepted (1st in Queue) |
|FLOOR-REQUEST-ID: 635 | |FLOOR-REQUEST-INFORMATION |
|BENEFICIARY-ID: 154 | | Floor Request ID: 635 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|REQUEST-STATUS: Accepted (2nd in Queue) | |REQUEST-STATUS: Accepted (2nd in Queue) |
|<----------------------------------------------| |<----------------------------------------------|
| |
|(3) FloorInfo | |(3) FloorInfo |
|USER-ID: 234 | |USER-ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-ID: 764 | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|BENEFICIARY-ID: 124 | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|REQUEST-STATUS: Granted | |REQUEST-STATUS: Granted |
|FLOOR-REQUEST-ID: 635 | |FLOOR-REQUEST-INFORMATION |
|BENEFICIARY-ID: 154 | | Floor Request ID: 635 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|REQUEST-STATUS: Accepted (1st in Queue) | |REQUEST-STATUS: Accepted (1st in Queue) |
|<----------------------------------------------| |<----------------------------------------------|
| |
|(4) FloorInfo | |(4) FloorInfo |
|USER-ID: 234 | |USER-ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-ID: 635 | |FLOOR-REQUEST-INFORMATION |
|BENEFICIARY-ID: 154 | | Floor Request ID: 635 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|REQUEST-STATUS: Granted | |REQUEST-STATUS: Granted |
|<----------------------------------------------| |<----------------------------------------------|
Figure 3: Obtaining status information about a floor Figure 3: Obtaining status information about a floor
FloorInfo messages contain information about the floor requests they FloorInfo messages contain information about the floor requests they
carry. For example, FloorInfo message (4) indicates that the floor carry. For example, FloorInfo message (4) indicates that the floor
request with Floor Request ID 635 has as the beneficiary (i.e., the request with Floor Request ID 635 has as the beneficiary (i.e., the
participant that holds the floor when a particular floor request is participant that holds the floor when a particular floor request is
granted) the participant whose User ID is 154. The floor request 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 applies only to the floor whose Floor ID is 543. That is, this is
not a multi-floor floor request. 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 the floors.
4.2 Floor Chair to Floor Control Server Interface 4.2 Floor Chair to Floor Control Server Interface
Figure 4 shows a floor chair instructing a floor control server to Figure 4 shows a floor chair instructing a floor control server to
grant a floor. Note, however, that although the floor control server grant a floor. Note, however, that although the floor control server
needs to take into consideration the instructions received in needs to take into consideration the instructions received in
ChairAction messages (e.g., granting a floor), it does not ChairAction messages (e.g., granting a floor), it does not
necessarily need to perform them exactly as requested by the floor necessarily need to perform them exactly as requested by the floor
chair. The operation that the floor control server performs depends chair. The operation that the floor control server performs depends
on the ChairAction message and on the internal state of the floor on the ChairAction message and on the internal state of the floor
control server. control server.
skipping to change at page 14, line 8 skipping to change at page 14, line 28
server needs to revoke the floor from its current holder before server needs to revoke the floor from its current holder before
granting it to the new participant. granting it to the new participant.
So, the floor control server is ultimately responsible to keep a So, the floor control server is ultimately responsible to keep a
coherent floor state using instructions from floor chairs as input to coherent floor state using instructions from floor chairs as input to
this state. this state.
Floor Chair Floor Control Floor Chair Floor Control
Server Server
|(1) ChairAction | |(1) ChairAction |
|TRANSACTION-ID: 769 |
|USER-ID: 357 | |USER-ID: 357 |
|TRANSACTION-ID: 769 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|FLOOR-REQUEST-ID: 635 | |FLOOR-REQUEST-ID: 635 |
|REQUEST-STATUS: Granted | |REQUEST-STATUS: Granted |
|---------------------------------------------->| |---------------------------------------------->|
| |
|(2) ChairActionAck | |(2) ChairActionAck |
|TRANSACTION-ID: 769 |
|USER-ID: 357 | |USER-ID: 357 |
|TRANSACTION-ID: 769 |
|<----------------------------------------------| |<----------------------------------------------|
Figure 4: Chair instructing the floor control server Figure 4: Chair instructing the floor control server
5. Packet Format 5. Packet Format
BFCP packets consist of an 8-byte fixed header followed by BFCP packets consist of an 8-byte fixed header followed by
attributes. All the protocol values MUST be sent in network byte attributes. All the protocol values MUST be sent in network byte
order. order.
skipping to change at page 15, line 8 skipping to change at page 15, line 32
Reserved: at this point, the 5 bits in the reserved field SHOULD be 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 set to zero by the sender of the message and MUST be ignored by the
receiver. receiver.
Primitive: this 8-bit field identifies the main purpose of the Primitive: this 8-bit field identifies the main purpose of the
message. The following primitive values are defined: message. The following primitive values are defined:
+-------+------------------------+-----------------------+ +-------+------------------------+-----------------------+
| Value | Primitive | Direction | | Value | Primitive | Direction |
+-------+------------------------+-----------------------+ +-------+------------------------+-----------------------+
| 0 | FloorRequest | P -> S | | 1 | FloorRequest | P -> S |
| 1 | FloorRelease | P -> S | | 2 | FloorRelease | P -> S |
| 2 | FloorRequestInfoWanted | P -> S ; Ch -> S | | 3 | FloorRequestInfoWanted | P -> S ; Ch -> S |
| 3 | FloorRequestInfo | P <- S ; Ch <- S | | 4 | FloorRequestInfo | P <- S ; Ch <- S |
| 4 | FloorInfoWanted | P -> S ; Ch -> S | | 5 | UserInfoWanted | P -> S ; Ch -> S |
| 5 | FloorInfo | P <- S ; Ch <- S | | 6 | UserInfo | P <- S ; Ch <- S |
| 6 | ChairAction | Ch -> S | | 7 | FloorInfoWanted | P -> S ; Ch -> S |
| 7 | ChairActionAck | Ch <- S | | 8 | FloorInfo | P <- S ; Ch <- S |
| 8 | Hello | P -> S ; Ch -> S | | 9 | ChairAction | Ch -> S |
| 9 | HelloAck | P <- S ; Ch <- S | | 10 | ChairActionAck | Ch <- S |
| 10 | Error | P <- S ; Ch <- S | | 11 | Hello | P -> S ; Ch -> S |
| 12 | HelloAck | P <- S ; Ch <- S |
| 13 | Error | P <- S ; Ch <- S |
+-------+------------------------+-----------------------+ +-------+------------------------+-----------------------+
S: Floor Control Server S: Floor Control Server
P: Floor Participant P: Floor Participant
Ch: Floor Chair Ch: Floor Chair
Table 1: BFCP primitives Table 1: BFCP primitives
Payload Length: this 16-bit field contains length of the message in Payload Length: this 16-bit field contains length of the message in
4-byte units excluding the fixed header. 4-byte units excluding the fixed header.
Conference ID: this 32-bit identifies the conference the message Conference ID: this 32-bit field identifies the conference the
belongs to. message belongs to.
5.2 Attribute Format 5.2 Attribute Format
BFCP attributes are encoded in TLV (Type-Length-Value) format. TLVs BFCP attributes are encoded in TLV (Type-Length-Value) format.
are 32-bit aligned. Attributes are 32-bit aligned.
0 1 2 3 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 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 | | | Type |M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Attribute Contents / / Attribute Contents /
/ / / /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TLV format Figure 6: Attribute format
Type: this 7-bit field contains the type of the attribute. The Type: this 7-bit field contains the type of the attribute. Each
following attribute types are defined: 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
| Type | Attribute | unsigned integer.
+------+---------------------+
| 0 | FLOOR-ID | OctetString16: the contents of the attribute consist of 16 bits of
| 1 | USER-ID | arbitrary data.
| 2 | BENEFICIARY-ID |
| 3 | TRANSACTION-ID | OctetString: the contents of the attribute consist of arbitrary
| 4 | FLOOR-REQUEST-ID | data of variable length.
| 5 | HUMAN-READABLE-INFO |
| 6 | DIGEST | Grouped: the contents of the attribute consist of a sequence of
| 7 | REQUEST-STATUS | attributes.
| 8 | ERROR-CODE |
| 9 | USER-DISPLAY-NAME | Note that extension attributes defined in the future may define new
| 10 | USER-URI | attribute formats.
| 11 | PRIORITY |
| 12 | NONCE | The following attribute types are defined:
| 13 | SUPPORTED-TLVS |
+------+---------------------+ +------+---------------------------+---------------+
| Type | Attribute | Format |
+------+---------------------------+---------------+
| 1 | BENEFICIARY-ID | Unsigned16 |
| 2 | FLOOR-ID | Unsigned16 |
| 3 | FLOOR-REQUEST-ID | Unsigned16 |
| 4 | NONCE | Unsigned16 |
| 5 | TRANSACTION-ID | Unsigned16 |
| 6 | USER-ID | Unsigned16 |
| 7 | PRIORITY | OctetString16 |
| 8 | REQUEST-STATUS | OctetString16 |
| 9 | DIGEST | OctetString |
| 10 | ERROR-CODE | OctetString |
| 11 | ERROR-INFO | OctetString |
| 12 | PARTICIPANT-PROVIDED-INFO | OctetString |
| 13 | STATUS-INFO | OctetString |
| 14 | SUPPORTED-ATTRIBUTES | OctetString |
| 15 | SUPPORTED-PRIMITIVES | OctetString |
| 16 | USER-DISPLAY-NAME | OctetString |
| 17 | USER-URI | OctetString |
| 18 | BENEFICIARY-INFORMATION | Grouped |
| 19 | FLOOR-REQUEST-INFORMATION | Grouped |
| 20 | REQUESTED-BY-INFORMATION | Grouped |
+------+---------------------------+---------------+
Table 2: BFCP attributes Table 2: BFCP attributes
M: the 'M' bit, known as the Mandatory bit, indicates whether support M: the 'M' bit, known as the Mandatory bit, indicates whether support
of the attribute is required. If an unrecognized attribute with the of the attribute is required. If an unrecognized attribute with the
'M' bit set is received, the message is rejected. 'M' bit set is received, the message is rejected.
Length: this 8-bit field contains the length of the attribute in Length: this 8-bit field contains the length of the attribute in
bytes, excluding any padding defined for specific attributes. The bytes, excluding any padding defined for specific attributes. The
Type, 'M' bit, and Length fields are included. Type, 'M' bit, and Length fields are included. 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 TLVs are defined in Attribute Contents: the contents of the different attributes are
the following sections. defined in the following sections.
5.2.1 FLOOR-ID 5.2.1 BENEFICIARY-ID
The following is the format of the FLOOR-ID attribute. The following is the format of the BENEFICIARY-ID attribute.
0 1 2 3 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 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 0|M|0 0 0 0 0 1 0 0| Floor ID | |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FLOOR-ID format Figure 7: BENEFICIARY-ID format
Floor ID: this field contains a 16-bit value that uniquely identifies Beneficiary ID: this field contains a 16-bit value that uniquely
a floor within a conference. identifies a user within a conference.
5.2.2 USER-ID Note that although the formats of the BENEFICIARY-ID attribute and of
the USER-ID attribute (see Figure 12) are similar, their semantics
are different. The BENEFICIARY-ID attribute is used in third-party
floor requests and to request information about a particular
participant.
The following is the format of the USER-ID attribute. 5.2.2 FLOOR-ID
The following is the format of the FLOOR-ID attribute.
0 1 2 3 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 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| User ID | |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: USER-ID format Figure 8: FLOOR-ID format
User ID: this field contains a 16-bit value that uniquely identifies Floor ID: this field contains a 16-bit value that uniquely identifies
a user within a conference. a floor within a conference.
5.2.3 BENEFICIARY-ID 5.2.3 FLOOR-REQUEST-ID
The following is the format of the BENEFICIARY-ID attribute. The following is the format of the FLOOR-REQUEST-ID attribute.
0 1 2 3 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 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| Beneficiary ID | |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: BENEFICIARY-ID format Figure 9: FLOOR-REQUEST-ID format
Beneficiary ID: this field contains a 16-bit value that uniquely Floor Request ID: this field contains a 16-bit value that indentifies
identifies a user within a conference. a floor request at the floor control server.
5.2.4 TRANSACTION-ID 5.2.4 NONCE
The following is the format of the TRANSACTION-ID attribute. The following is the format of the NONCE attribute.
0 1 2 3 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 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| Transaction ID | |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0| Nonce Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TRANSACTION-ID format Figure 10: NONCE format
Transaction ID: this field contains a 16-bit value that allows users Nonce Value: this 16-bit field contains a nonce.
to match a given message with its response.
5.2.5 FLOOR-REQUEST-ID 5.2.5 TRANSACTION-ID
The following is the format of the FLOOR-REQUEST-ID attribute. The following is the format of the TRANSACTION-ID attribute.
0 1 2 3 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 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| Floor Request ID | |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: FLOOR-REQUEST-ID format Figure 11: TRANSACTION-ID format
Floor Request ID: this field contains a 16-bit value that indentifies Transaction ID: this field contains a 16-bit value that allows users
a floor request at the floor control server. to match a given message with its response.
5.2.6 HUMAN-READABLE-INFO 5.2.6 USER-ID
The following is the format of the HUMAN-READABLE-INFO attribute. The following is the format of the USER-ID attribute.
0 1 2 3 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 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| Length | | |0 0 0 0 1 1 0|M|0 0 0 0 0 1 0 0| User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: HUMAN-READABLE-INFO format Figure 12: USER-ID format
Text: this field contains UTF-8 [7] encoded text.
In some situations, the contents of the Text field may be generated User ID: this field contains a 16-bit value that uniquely identifies
by an automaton. If such automaton has information about the a participant within a conference.
preferred language of the receiver of a particular
HUMAN-READABLE-INFO TLV, it MAY use this language to generate the
Text field.
Padding: one, two, or three bytes of padding added so that the The identify used by a participant in BFCP, which is carried in the
contents of the HUMAN-READABLE-INFO TLV is 32-bit aligned. The User ID field, is generally mapped to the identity used by the same
Padding bits SHOULD be set to zero by the sender and MUST be ignored participant in the session establishment protocol (e.g., in SIP).
by the receiver. If the TLV is already 32-bit aligned, no padding is The way this mapping is performed is outside the scope of this
needed. specification.
5.2.7 DIGEST 5.2.7 PRIORITY
The following is the format of the DIGEST attribute. The following is the format of the PRIORITY attribute.
0 1 2 3 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 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|0 0 0 1 1 0 0 0| | |0 0 0 0 1 1 1|M|0 0 0 0 0 1 0 0|Prio | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ HMAC-SHA1 +
| |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: DIGEST format Figure 13: PRIORITY format
HMAC-SHA1: this 20-byte field contains an HMAC-SHA1 [1] of the BFCP Prio: this field contains a 3-bit priority value as shown in Table 3.
message. Its calculation is described in Section 9. Senders SHOULD NOT use values higher than 4 in this field. Receivers
MUST treat values higher than 4 as if the value received had been 4
(Highest). The default priority value when the PRIORITY attribute is
missing is 2 (Normal).
Padding: two bytes of padding added so that the contents of the +-------+----------+
HMAC-SHA1 TLV is 32-bit aligned. The Padding bits SHOULD be set to | Value | Priority |
zero by the sender and MUST be ignored by the receiver. +-------+----------+
| 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.
5.2.8 REQUEST-STATUS 5.2.8 REQUEST-STATUS
The following is the format of the REQUEST-STATUS attribute. The following is the format of the REQUEST-STATUS attribute.
0 1 2 3 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 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|0 0 0 0 0 1 0 0|Request Status |Queue Position | |0 0 0 1 0 0 0|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: REQUEST-STATUS format Figure 14: REQUEST-STATUS format
Request Status: this 8-bit field contains the status of the request, Request Status: this 8-bit field contains the status of the request,
as described in the following table. as described in the following table.
+-------+-----------+ +-------+-----------+
| Value | Status | | Value | Status |
+-------+-----------+ +-------+-----------+
| 0 | Pending | | 1 | Pending |
| 1 | Accepted | | 2 | Accepted |
| 2 | Granted | | 3 | Granted |
| 3 | Denied | | 4 | Denied |
| 4 | Cancelled | | 5 | Cancelled |
| 5 | Released | | 6 | Released |
| 6 | Revoked | | 7 | Revoked |
+-------+-----------+ +-------+-----------+
Table 3: Request Status values Table 4: Request Status values
Queue Position: this 8-bit field contains, when applicable, the Queue Position: this 8-bit field contains, when applicable, the
position of the floor request in the floor request queue at the position of the floor request in the floor request queue at the
server. If the Request Status value is different from Accepted, the server. If the Request Status value is different from Accepted, the
floor control server does not implement a floor request queue, or the floor control server does not implement a floor request queue, or the
floor control server does not want to provide the client with this floor control server does not want to provide the client with this
information, all the bits of this field SHOULD be set to zero. 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 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 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 has not done it yet. Once the floor control chair accepts the floor
request, the floor request is moved to the Accepted state. request, the floor request is moved to the Accepted state.
5.2.9 ERROR-CODE 5.2.9 DIGEST
The following is the format of the ERROR-CODE attribute. The following is the format of the DIGEST attribute.
0 1 2 3 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 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 | Error Code | |0 0 0 1 0 0 1|M|0 0 0 1 1 0 0 0| Algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ Digest +
| |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: DIGEST format
Algorithm: this 8-bit field contains the identifier of the algorithm
used to calculate the keyed digest. The following are the algorithm
identifiers defined:
+------------+-----------+---------------+--------------+
| Identifier | Algorithm | Digest Length | Reference |
+------------+-----------+---------------+--------------+
| 0 | HMAC-SHA1 | 20 bytes | RFC 2104 [1] |
+------------+-----------+---------------+--------------+
Table 5: Digest algorithms
The text used as input to the digest algorithm is the BFCP
message, including the FIXED-HEADER, up to and including the
attribute preceding the DIGEST attribute. Depending on the
algorithm, this text may need to be padded with zeroes. When
HMAC-SHA1 is used, the input text needs to be padded so as to be a
multiple of 64 bytes.
The key used as input to the keyed digest is the secret shared
between the server and the user identified by the USER-ID
attribute in the message.
Digest: this field contains a keyed digest of the BFCP message. Its
calculation is described in Section 9.
Padding: padding added so that the contents of the DIGEST attribute
is 32-bit aligned. The Padding bits SHOULD be set to zero by the
sender and MUST be ignored by the receiver.
5.2.10 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 1 0 1 0|M| Length | Error Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Error Specific Details | | Error Specific Details |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ERROR-CODE format Figure 16: ERROR-CODE format
Error Code: this 16-bit field contains an error code from the Error Code: this 8-bit field contains an error code from the
following table. following table.
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| Value | Meaning | | Value | Meaning |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| 0 | Conference does not Exist | | 1 | Conference does not Exist |
| 1 | Authentication Failed | | 2 | User does not Exist |
| 2 | Unknown Mandatory TLV | | 3 | DIGEST Attribute Required |
| 3 | Floor Request ID Does Not Exist | | 4 | Invalid Nonce |
| 4 | Unauthorized Operation | | 5 | Authentication Failed |
| 5 | User does not Exist | | 6 | Unknown Primitive |
| 6 | Invalid Nonce | | 7 | Unknown Mandatory Attribute |
| 7 | DIGEST TLV Required | | 8 | Unauthorized Operation |
| 8 | Invalid Floor ID | | 9 | Invalid Floor ID |
| 9 | You have Already Reached the | | 10 | Floor Request ID Does Not Exist |
| 11 | You have Already Reached the |
| | Maximum Number of Ongoing Floor | | | Maximum Number of Ongoing Floor |
| | Requests for this Floor | | | Requests for this Floor |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
Table 4: Error Code meaning Table 6: Error Code meaning
Error Specific Details: Present only for certain Error Codes. In Error Specific Details: Present only for certain Error Codes. In
this document, only for Error Code 2 (Unknown Mandatory TLV). For this document, only for Error Code 3 (DIGEST Attribute Needed) and
Error Code 2, this field contains the Types of the TLVs (which were Error Code 7 (Unknown Mandatory Attribute). See Section 5.2.10.1 and
present in the message that triggered the Error message) that were Section 5.2.10.2 for their respective definitions.
unknown to the receiver, encoded as follows.
Padding: one, two, or three bytes of padding added so that the
contents of the ERROR-CODE attribute is 32-bit aligned. If the
attribute is already 32-bit aligned, no padding is needed.
The Padding bits SHOULD be set to zero by the sender and MUST be
ignored by the receiver.
5.2.10.1 Error Specific Details for Error Code 3
The following is the format of the Error Specific Details field for
Error Code 3.
0 1 2 3 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 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 TLV Type | Unknown TLV Type | | Algorithm ID | Algorithm ID | Algorithm ID | Algorithm ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Unknown TLV Type | | | Algorithm ID | Algorithm ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown TLV Type | | Algorithm ID | Algorithm ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Unknown TLVs format Figure 17: Digest algorithms format
Padding: one, two, or three bytes of padding added so that the Algorithm ID: these 8-bit fields contain the identifiers of the
contents of the ERROR-CODE TLV is 32-bit aligned. If the TLV is digest algorithms supported by the floor control server in order of
already 32-bit aligned, no padding is needed. preference (i.e., the first algorithm is the most preferred).
The Padding bits SHOULD be set to zero by the sender and MUST be 5.2.10.2 Error Specific Details for Error Code 7
ignored by the receiver. Note all the Error Codes defined in this
document but Error Code 2, result in a TLV which is already 32-bit
aligned (i.e., no need of padding). Error Code 2 results in a TLV
that may need 2 bytes of padding.
5.2.10 USER-DISPLAY-NAME The following is the format of the Error Specific Details field for
Error Code 7.
The format of the USER-DISPLAY-NAME attribute is the same as the 0 1 2 3
HUMAN-READABLE-INFO attribute (still, they have different attribute 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
types). The Text field in the USER-DISPLAY-NAME attribute contains +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
the name of the user. | 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 18: Unknown attributes format
5.2.11 USER-URI 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
The format of the USER-URI attribute is the same as the R: at this point, this bit is reserved. It SHOULD be set to zero by
HUMAN-READABLE-INFO attribute (still, they have different attribute the sender of the message and MUST be ignored by the receiver.
types). The Text field in the USER-URI attribute contains the URI of
the user.
5.2.12 PRIORITY 5.2.11 ERROR-INFO
The following is the format of the PRIORITY attribute. The following is the format of the ERROR-INFO attribute.
0 1 2 3 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 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|0 0 0 0 0 1 0 0| Priority | Reserved | |0 0 0 1 0 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: PRIORITY format Figure 19: ERROR-INFO format
Priority: the higher the 8-bit value, the more priority is requested Text: this field contains UTF-8 [7] encoded text.
for a given floor request.
Reserved: at this point, the 8 bits in the reserved field SHOULD be In some situations, the contents of the Text field may be generated
set to zero by the sender of the message and MUST be ignored by the by an automaton. If such automaton has information about the
receiver. preferred language of the receiver of a particular ERROR-INFO
attribute, it MAY use this language to generate the Text field.
5.2.13 NONCE Padding: one, two, or three bytes 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.
The following is the format of the NONCE attribute. 5.2.12 PARTICIPANT-PROVIDED-INFO
The following is the format of the PARTICIPANT-PROVIDED-INFO
attribute.
0 1 2 3 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 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 | Nonce Value | |0 0 0 1 1 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: NONCE format Figure 20: PARTICIPANT-PROVIDED-INFO format
Nonce Value: this 16-bit field contains a nonce. Text: this field contains UTF-8 [7] encoded text.
5.2.14 SUPPORTED-TLVS Padding: one, two, or three bytes 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.
The following is the format of the SUPPORTED-TLVS attribute. 5.2.13 STATUS-INFO
The following is the format of the STATUS-INFO attribute.
0 1 2 3 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 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 | Supported TLV | |0 0 0 1 1 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported TLV | Supported TLV |
Figure 21: STATUS-INFO format
Text: this field contains UTF-8 [7] encoded text.
In some situations, the contents of the Text field may be generated
by an automaton. If such 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 bytes 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.14 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 1 1 0|M| Length | Supported Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Attribute | Supported Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: SUPPORTED-TLVS format Figure 22: SUPPORTED-ATTRIBUTES format
Supported TLV: these fields contain the Types of the TLVs that are Supported Attribute: these fields contain the Types of the attributes
supported by the floor control server. that are supported by the floor control server.
Padding: two bytes of padding added so that the contents of the Padding: two bytes of padding added so that the contents of the
SUPPORTED-TLVS TLV is 32-bit aligned. If the TLV is already 32-bit SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute
aligned, no padding is needed. 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.15 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 1 1 1|M| Length | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primitive | Primitive | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: 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 bytes 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 The Padding bits SHOULD be set to zero by the sender and MUST be
ignored by the receiver. ignored by the receiver.
5.2.16 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 1 0 0 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: USER-DISPLAY-NAME format
Text: this field contains the UTF-8 encoded name of the user.
Padding: one, two, or three bytes 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.17 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 1 0 0 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: USER-URI format
Text: this field contains the UTF-8 encoded URI of the user.
Padding: one, two, or three bytes 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.18 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 1 0 0 1 0|M| Length | Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: 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) [3] 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 27: BENEFICIARY-INFORMATION format
5.2.19 FLOOR-REQUEST-INFORMATION
The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as FLOOR-REQUEST-
INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the FLOOR-REQUEST-INFORMATION-HEADER:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 1 1|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: FLOOR-REQUEST-INFORMATION-HEADER format
Floor Request ID: this field contains a 16-bit value that indentifies
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)
(REQUEST-STATUS)
1*(FLOOR-ID)
[BENEFICIARY-INFORMATION]
[REQUESTED-BY-INFORMATION]
[PRIORITY]
[PARTICIPANT-PROVIDED-INFO]
[STATUS-INFO]
*[EXTENSION-ATTRIBUTE]
Figure 29: FLOOR-REQUEST-INFORMATION format
5.2.20 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 1 0 0|M| Length | Requested-by ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: REQUESTED-BY-INFORMATION-HEADER format
Requested-by ID: this field contains a 16-bit value that uniquely
identifies a user within a conference.
The following is the ABNF of the REQUESTED-BY-INFORMATION grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.)
REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER)
[USER-DISPLAY-NAME]
[USER-URI]
*[EXTENSION-ATTRIBUTE]
Figure 31: REQUESTED-BY-INFORMATION format
5.3 Message Format 5.3 Message Format
This section contains the normative ABNF [3] of the BFCP messages. This section contains the normative ABNF (Augmented Backus-Naur Form)
[3] of the BFCP messages. Extension attributes that may be defined
in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.
5.3.1 FloorRequest 5.3.1 FloorRequest
Floor participants request a floor by sending a FloorRequest message Floor participants request a floor by sending a FloorRequest message
to the floor control server. The following is the format of the to the floor control server. The following is the format of the
FloorRequest message: FloorRequest message:
FloorRequest = (FIXED-HEADER) FloorRequest = (FIXED-HEADER)
(TRANSACTION-ID)
(USER-ID) (USER-ID)
[BENEFICIARY-ID] (TRANSACTION-ID)
*(FLOOR-ID) *(FLOOR-ID)
[HUMAN-READABLE-INFO] [BENEFICIARY-ID]
[PARTICIPANT-PROVIDED-INFO]
[PRIORITY] [PRIORITY]
*[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 20: FloorRequest format Figure 32: FloorRequest format
5.3.2 FloorRelease 5.3.2 FloorRelease
Floor participants release a floor by sending a FloorRelease message Floor participants release a floor by sending a FloorRelease message
to the floor control server. Floor participants also use the to the floor control server. Floor participants also use the
FloorRelease message to cancel pending floor requests. The following FloorRelease message to cancel pending floor requests. The following
is the format of the FloorRelease message: is the format of the FloorRelease message:
FloorRelease = (FIXED-HEADER) FloorRelease = (FIXED-HEADER)
(TRANSACTION-ID)
(USER-ID) (USER-ID)
(TRANSACTION-ID)
(FLOOR-REQUEST-ID) (FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 21: FloorRelease format Figure 33: FloorRelease format
5.3.3 FloorRequestInfoWanted 5.3.3 FloorRequestInfoWanted
Floor participants and floor chairs request information about a floor Floor participants and floor chairs request information about a floor
request by sending a FloorRequestInfoWanted message to the floor request by sending a FloorRequestInfoWanted message to the floor
control server. The following is the format of the control server. The following is the format of the
FloorRequestInfoWanted message: FloorRequestInfoWanted message:
FloorRequestInfoWanted = (FIXED-HEADER) FloorRequestInfoWanted = (FIXED-HEADER)
(TRANSACTION-ID)
(USER-ID) (USER-ID)
[BENEFICIARY-ID] (TRANSACTION-ID)
[FLOOR-REQUEST-ID] (FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 22: FloorRequestInfoWanted format Figure 34: FloorRequestInfoWanted format
5.3.4 FloorRequestInfo 5.3.4 FloorRequestInfo
The floor control server informs floor participants and floor chairs The floor control server informs floor participants and floor chairs
about the status of their floor requests by sending them about the status of their floor requests by sending them
FloorRequestInfo messages. The following is the format of the FloorRequestInfo messages. The following is the format of the
FloorRequestInfo message: FloorRequestInfo message:
FloorRequestInfo = (FIXED-HEADER) FloorRequestInfo = (FIXED-HEADER)
(USER-ID)
[TRANSACTION-ID]
(FLOOR-REQUEST-INFORMATION)
[NONCE]
*[EXTENSION-ATTRIBUTE]
Figure 35: FloorRequestInfo format
5.3.5 UserInfoWanted
Floor participants and floor chairs request information about a
participant and the floor requests related to this participant by
sending a UserInfoWanted message to the floor control server. The
following is the format of the UserInfoWanted message:
UserInfoWanted = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
[BENEFICIARY-ID] [BENEFICIARY-ID]
[USER-DISPLAY-NAME] *[EXTENSION-ATTRIBUTE]
[USER-URI]
1*( (FLOOR-REQUEST-ID)
1*(FLOOR-ID)
[HUMAN-READABLE-INFO]
[PRIORITY]
(REQUEST-STATUS) )
[NONCE] [NONCE]
[DIGEST]
Figure 23: FloorRequestInfo format Figure 36: UserInfoWanted format
5.3.5 FloorInfoWanted 5.3.6 UserInfo
The floor control server provide information about participants and
their related floor requests to floor participants and floor chairs
by sending them UserInfo messages. The following is the format of
the UserInfo message:
UserInfo = (FIXED-HEADER)
(TRANSACTION-ID)
(USER-ID)
[BENEFICIARY-INFORMATION]
1*(FLOOR-REQUEST-INFORMATION)
[NONCE]
*[EXTENSION-ATTRIBUTE]
Figure 37: UserInfo format
5.3.7 FloorInfoWanted
Floor participants and floor chairs request information about a floor Floor participants and floor chairs request information about a floor
or floors by sending a FloorInfoWanted message to the floor control or floors by sending a FloorInfoWanted message to the floor control
server. The following is the format of the FloorRequest message: server. The following is the format of the FloorRequest message:
FloorInfoWanted = (FIXED-HEADER) FloorInfoWanted = (FIXED-HEADER)
(TRANSACTION-ID)
(USER-ID) (USER-ID)
(TRANSACTION-ID)
*(FLOOR-ID) *(FLOOR-ID)
*[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 24: FloorInfoWanted format Figure 38: FloorInfoWanted format
5.3.6 FloorInfo 5.3.8 FloorInfo
The floor control server informs floor participants and floor chairs The floor control server informs floor participants and floor chairs
about the status (e.g., the current holder) of a floor by sending about the status (e.g., the current holder) of a floor by sending
them FloorInfo messages. The following is the format of the them FloorInfo messages. The following is the format of the
FloorInfo message: FloorInfo message:
FloorInfo = (FIXED-HEADER) FloorInfo = (FIXED-HEADER)
[TRANSACTION-ID]
(USER-ID) (USER-ID)
[FLOOR-ID] [TRANSACTION-ID]
*( (FLOOR-REQUEST-ID) (FLOOR-ID)
[BENEFICIARY-ID] *[FLOOR-REQUEST-INFORMATION]
[USER-DISPLAY-NAME]
[USER-URI]
*(FLOOR-ID)
[HUMAN-READABLE-INFO]
[PRIORITY]
(REQUEST-STATUS) )
[NONCE] [NONCE]
*[EXTENSION-ATTRIBUTE]
Figure 25: FloorInfo format Figure 39: FloorInfo format
5.3.7 ChairAction 5.3.9 ChairAction
Floor chairs send instructions to floor control servers by sending Floor chairs send instructions to floor control servers by sending
ChairAction messages. The following is the format of the ChairAction ChairAction messages. The following is the format of the ChairAction
message: message:
ChairAction = (FIXED-HEADER) ChairAction = (FIXED-HEADER)
(TRANSACTION-ID)
(USER-ID) (USER-ID)
(TRANSACTION-ID)
1*(FLOOR-ID) 1*(FLOOR-ID)
(FLOOR-REQUEST-ID) (FLOOR-REQUEST-ID)
(REQUEST-STATUS) (REQUEST-STATUS)
[HUMAN-READABLE-INFO] [STATUS-INFO]
*[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 26: ChairAction format Figure 40: ChairAction format
5.3.8 ChairActionAck 5.3.10 ChairActionAck
Floor control servers confirm that they have accepted a ChairAction Floor control servers confirm that they have accepted a ChairAction
message by sending a ChairActionAck message. The following is the message by sending a ChairActionAck message. The following is the
format of the ChairActionAck message: format of the ChairActionAck message:
ChairActionAck = (FIXED-HEADER) ChairActionAck = (FIXED-HEADER)
(TRANSACTION-ID)
(USER-ID) (USER-ID)
(TRANSACTION-ID)
[NONCE] [NONCE]
*[EXTENSION-ATTRIBUTE]
Figure 27: ChairActionAck format Figure 41: ChairActionAck format
5.3.9 Hello 5.3.11 Hello
Floor participants and floor chairs check the liveness of floor Floor participants and floor chairs check the liveness of floor
control servers by sending a Hello message. The following is the control servers by sending a Hello message. The following is the
format of the Hello message: format of the Hello message:
Hello = (FIXED-HEADER) Hello = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
*[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 28: Hello format Figure 42: Hello format
5.3.10 HelloAck 5.3.12 HelloAck
Floor control servers confirm that they are alive on reception of a Floor control servers confirm that they are alive on reception of a
Hello message by sending a HelloAck message. The following is the Hello message by sending a HelloAck message. The following is the
format of the HelloAck message: format of the HelloAck message:
HelloAck = (FIXED-HEADER) HelloAck = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
(SUPPORTED-TLVS) (SUPPORTED-PRIMITIVES)
(SUPPORTED-ATTRIBUTES)
[NONCE] [NONCE]
*[EXTENSION-ATTRIBUTE]
Figure 29: HelloAck format Figure 43: HelloAck format
5.3.11 Error 5.3.13 Error
Floor control servers inform floor participants and floor chairs Floor control servers inform floor participants and floor chairs
about errors processing requests by sending them Error messages. The about errors processing requests by sending them Error messages. The
following is the format of the Error message: following is the format of the Error message:
Error = (FIXED-HEADER) Error = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
(ERROR-CODE) (ERROR-CODE)
[NONCE] [NONCE]
[HUMAN-READABLE-INFO] [ERROR-INFO]
*[EXTENSION-ATTRIBUTE]
Figure 30: Error format Figure 44: Error format
6. Transport 6. Transport
BFCP entities exchange BFCP messages using TCP connections. TCP BFCP entities exchange BFCP messages using TCP connections. TCP
provides an in-order reliable delivery of a stream of bytes. provides an in-order reliable delivery of a stream of bytes.
Consequently, message framing is implemented in the application Consequently, message framing is implemented in the application
layer. BFCP implements application-layer framing using TLVs. layer. BFCP implements application-layer framing using TLV-encoded
attributes.
A client MUST NOT use more than one TCP connection to communicate A client MUST NOT use more than one TCP connection to communicate
with a given floor control server within a conference. Nevertheless, with a given floor control server within a conference. Nevertheless,
if the same physical box handles different clients (e.g., a floor if the same physical box handles different clients (e.g., a floor
chair and a floor participant), which are identified by different chair and a floor participant), which are identified by different
User IDs, a separate connection per client is allowed. User IDs, a separate connection per client is allowed.
If a BFCP entity (a client or a floor control server) receives data 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 from TCP that cannot be parsed the entity MUST close the TCP
connection using a RESET call (send a TCP RST bit) and the connection connection using a RESET call (send a TCP RST bit) and the connection
SHOULD be reestablished. Similarly, if a TCP connection cannot SHOULD be reestablished. Similarly, if a TCP connection cannot
deliver a BFCP message and times out, the TCP connection SHOULD be deliver a BFCP message and times out, the TCP connection SHOULD be
reestablished. reestablished.
The way connection reestablishment is handled depends on how the The way connection reestablishment is handled depends on how the
client obtains information to contact the floor control server (e.g., client obtains information to contact the floor control server (e.g.,
using an offer/answer exchange [14]). Once the TCP connection is using an offer/answer exchange [13]). Once the TCP connection is
reestablished, the client MAY resend those message it did not get a reestablished, the client MAY resend those message it did not get a
response for from the floor control server. response for from the floor control server.
If a floor control server detects that the TCP connection towards one 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 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 the floor control server what to do with the pending floor requests
of the floor participant. In any case, it is RECOMMENDED that the of the floor participant. In any case, it is RECOMMENDED that the
floor control server keeps the floor requests (i.e., does not cancel floor control server keeps the floor requests (i.e., does not cancel
them) while the TCP connection is reestablished. them) while the TCP connection is reestablished.
If a client wishes to end its BFCP connection with a floor control 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 server, the client closes (i.e., a graceful close) the TCP connection
towards the floor control server. If a floor control server wishes 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 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 conference informs the floor control server that the client has been
kicked out from the conference), the floor control server closes kicked out from the conference), the floor control server closes
(i.e., a graceful close) the TCP connection towards the client. (i.e., a graceful close) the TCP connection towards the client.
7. Lower-Layer Security 7. Lower-Layer Security
BFCP relies on lower-layer security mechanisms to provide replay and BFCP relies on lower-layer security mechanisms to provide replay and
integrity protection, and confidentiality. BFCP floor control integrity protection, and confidentiality. BFCP floor control
servers MUST support TLS [4], and BFCP clients (which include both servers MUST support TLS [4], and BFCP clients (which include both
floor participants and floor chairs) SHOULD support TLS. Any BFCP floor participants and floor chairs) SHOULD support TLS. Any BFCP
skipping to change at page 30, line 44 skipping to change at page 38, line 27
BFCP entities that implement TLS MUST support, at a minimum, the TLS BFCP entities that implement TLS MUST support, at a minimum, the TLS
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].
8. Protocol Transactions 8. Protocol Transactions
In BFCP, there are two types of transactions: client-initiated In BFCP, there are two types of transactions: client-initiated
transactions and server-initiated transactions (notifications). transactions and server-initiated transactions (notifications).
Client-initiated transactions consist of a request from a client to a Client-initiated transactions consist of a request from a client to a
floor control server and a response from the floor control server to floor control server and a response from the floor control server to
the client. The request carries a TRANSACTION-ID TLV which the floor the client. The request carries a TRANSACTION-ID attribute which the
control server copies into the response. Clients use Transaction ID floor control server copies into the response. Clients use
values to match responses with previously-issued requests. Transaction ID values to match responses with previously-issued
requests.
Server-initiated transactions consist of a single message from a Server-initiated transactions consist of a single message from a
floor control server to a client. Since they do not trigger any floor control server to a client. Since they do not trigger any
response, server-initiated transactions do not have Transaction IDs response, server-initiated transactions do not have Transaction IDs
associated with them. associated with them.
8.1 Client Behavior 8.1 Client Behavior
A client starting a client-initiated transaction MUST set the A client starting a client-initiated transaction MUST set the
Conference ID in the FIXED-HEADER of the message to the Conference ID Conference ID in the FIXED-HEADER of the message to the Conference ID
for the conference that the client obtained previously. for the conference that the client obtained previously.
The client MUST set the Transaction ID value in the TRANSACTION-ID The client MUST set the Transaction ID value in the TRANSACTION-ID
TLV to a number which MUST NOT be reused in another message from the attribute to a number which MUST NOT be reused in another message
client until a response from the server is received for the from the client until a response from the server is received for the
transaction. The client uses the Transaction ID value to match this transaction. The client uses the Transaction ID value to match this
message with the response from the floor control server. message with the response from the floor control server.
8.2 Server Behavior 8.2 Server Behavior
A floor control server sending a response within a client-initiated A floor control server sending a response within a client-initiated
transaction MUST copy the Conference ID, the TRANSACTION-ID TLV, and transaction MUST copy the Conference ID, the TRANSACTION-ID
the USER-ID TLV from the request received from the client into the attribute, and the USER-ID attribute from the request received from
response. Server-initiated transactions MUST NOT contain a the client into the response. Server-initiated transactions MUST NOT
TRANSACTION-ID TLV. contain a TRANSACTION-ID attribute.
9. Authentication and Authorization 9. Authentication and Authorization
BFCP uses the DIGEST TLV to provide client authentication. The BFCP clients SHOULD authenticate the floor control server before
DIGEST TLV contains an HMAC-SHA1 [1] of the BFCP message. The use of sending any BFCP message to it. Similarly, floor control servers
SHA1 implies that the length of the HMAC is 20 bytes. The text used SHOULD authenticate a client before accepting any BFCP message from
as input to HMAC is the BFCP message, including the FIXED-HEADER, up it.
to and including the TLV preceding the DIGEST TLV. This text is then
padded with zeroes so as to be a multiple of 64 bytes. As a result,
the DIGEST TLV MUST be the last attribute in any BFCP message. The
key used as input to HMAC is the secret shared between the server and
the user identified by the USER-ID TLV in the message.
9.1 Client Behavior 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.
Clients can authenticate floor control servers by checking the floor Additionally, BFCP also provides a digest mechanism based on a shared
control server's certificate when the TLS connection is established secret to provide client authentication in situations where TLS is
between them. not used for some reason. This mechanism is described in
Section 9.2.
9.1 TLS-based Mutual Authentication
BFCP supports TLS-based mutual authentication between clients and
floor control servers. Authentication based on both, certificates
signed by a certificate authority and self-signed certificates is
supported.
If a client and a floor control server have certificates signed by a
certificate authority known to both, they can use these certificates
to authenticate each other at TLS establishment time. Otherwise,
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 offer/answer model is described in [13].
9.2 Digest-based Client Authentication
BFCP supports digest-based client authentication based on a shared
secret between a client and the floor control server. It is assumed
that an encrypted and integrity-protected channel exists between the
client and the floor control server. This channel is used to
generate a shared secret between them.
The implementation of such an encrypted and integrity-protected
channel using SIP and the offer/answer model is described in [13].
Digest-based client authentication in BFCP is based on the DIGEST
attribute. This attribute contains an algorithm identifier and a
keyed digest of the of the BFCP message using that algorithm. The
text used as input to the digest algorithm is the BFCP message,
including the FIXED-HEADER, up to and including the attribute
preceding the DIGEST attribute. Depending on the algorithm, this
text may need to be padded with zeroes. Section 5.2.9 lists the
algorithms specified in BFCP.
The key used as input to the keyed digest is the secret shared
between the server and the user identified by the USER-ID attribute
in the message.
Section 9.2.1 and Section 9.2.2 discuss how to achieve client
authentication using the DIGEST attribute.
9.2.1 Client Behavior
To achieve client authentication, a client needs to prove to the To achieve client authentication, a client needs to prove to the
floor control server that the client can produce a DIGEST TLV for a floor control server that the client can produce a DIGEST attribute
message using their shared secret and that the message is fresh (to for a message using their shared secret and that the message is fresh
avoid replay attacks). Clients prove the freshness of a message by (to avoid replay attacks). Clients prove the freshness of a message
including a NONCE TLV in the message. The NONCE TLV is the second to by including a NONCE attribute in the message. The NONCE attribute
last TLV in the message (the last one is the DIGEST TLV). is the second to last attribute in the message (the last one is the
DIGEST attribute).
The nonce to be places in the NONCE TLV by the client is typically Clients can obtain the digest algorithms supported by the floor
provided by the floor control server in an Error response -- control server in an Error response from the floor control server
typically with Error Code 7 (DIGEST TLV Required) or 6 (Invalid with Error Code 3 (DIGEST Attribute Required). A client SHOULD use
Nonce). Additionally, as an optimization, the floor control server the first digest algorithm in the list that it supports.
can provide a client with a NONCE to be used in the first message
generated by the client using an out-of-band mechanism (e.g., using Additionally, as an optimization, the floor control server and the
an offer/answer exchange as described in [14]). This way, the client client can agree on the algorithm to be used using an out-of-band
does not need to generate an initial BFCP message only to have it mechanism (e.g., using an offer/answer exchange as described in
rejected by the floor control server with an Error response [13]). This way, the client does not need to generate an initial
BFCP message only to have it rejected by the floor control server
with an Error response containing a list with its supported
algorithms.
If after sending a message with a DIGEST attribute, a client receives
an Error response with Error Code 3 (DIGEST Attribute Required) with
a list of digest algorithms, the client SHOULD re-send the message
using the first digest algorithm in the list that it supports.
The nonce to be placed in the NONCE attribute by the client is
typically provided by the floor control server in an Error response
-- typically with Error Code 3 (DIGEST Attribute Required) or 6
(Invalid Nonce). Additionally, as an optimization, the floor control
server can provide a client with a NONCE to be used in the first
message generated by the client using an out-of-band mechanism (e.g.,
using an offer/answer exchange as described in [13]). This way, the
client does not need to generate an initial BFCP message only to have
it rejected by the floor control server with an Error response
containing a nonce. containing a nonce.
A client that obtains a nonce out-of-band SHOULD add a NONCE TLV and A client that obtains a nonce out-of-band SHOULD add a NONCE
a DIGEST TLV to the first message it sends to the floor control attribute and a DIGEST attribute to the first message it sends to the
server. Furthermore, if any client generates a message without a floor control server. Furthermore, if any client generates a message
DIGEST TLV and receives an Error response with Error Code 7 (DIGEST without a DIGEST attribute and receives an Error response with Error
TLV Required), the client SHOULD re-send the message with a DIGEST Code 3 (DIGEST Attribute Required), the client SHOULD re-send the
TLV and a NONCE TLV with the nonce received in the Error response. message with a DIGEST attribute and a NONCE attribute with the nonce
received in the Error response.
If after sending a message with a DIGEST TLV, a client receives an If after sending a message with a DIGEST attribute, a client receives
Error response with Error Code 6 (Invalid Nonce), the client SHOULD an Error response with Error Code 4 (Invalid Nonce), the client
re-send the message using the new nonce received in the Error SHOULD re-send the message using the new nonce received in the Error
response. If the Error Code is 1 (Authentication Failed) instead, response. If the Error Code is 5 (Authentication Failed) instead,
the client MUST NOT send further messages to the floor control server the client MUST NOT send further messages to the floor control server
until it has obtained a different (hopefully valid) shared secret until it has obtained a different (hopefully valid) shared secret
than the one used in the original message. than the one used in the original message.
If a client receives a nonce in a message from the floor control If a client receives a nonce in a message from the floor control
server, the client SHOULD add a NONCE TLV with this nonce and a server, the client SHOULD add a NONCE attribute with this nonce and a
DIGEST TLV to its next message to the floor control server. DIGEST attribute to its next message to the floor control server.
9.2 Floor Control Server Behavior 9.2.2 Floor Control Server Behavior
Before accepting any BFCP message, the floor control server SHOULD If the floor control server receives a message without DIGEST
authenticate the client. If the floor control server receives a attribute from an unauthenticated client, the floor control server
message without DIGEST TLV from an unauthenticated client, the floor responds with an Error message with Error Code 3 (DIGEST Attribute
control server responds with an Error message with Error Code 7 Required). The floor control message MUST include a list with the
(DIGEST TLV Required). The floor control message MUST include a digest algorithms supported by the floor control server in order of
NONCE TLV with a nonce value that is unguessable by attackers. preference (i.e., the first algorithm is the most preferred) and a
NONCE attribute with a nonce value that is unguessable by attackers.
When a floor control server receives a BFCP message with a DIGEST When a floor control server receives a BFCP message with a DIGEST
TLV, it checks whether the NONCE TLV carries a nonce which was attribute, it checks whether the Algorithm identifier in the DIGEST
generated by the floor control server for this client and which still attribute corresponds to an algorithm that is supported by the floor
has not expired. If the nonce is not valid, authentication is control server. If it does not, the floor control server SHOULD
considered to have failed, in which case the floor control server return an Error message with Error Code 3 (DIGEST Attribute Required)
SHOULD return an Error message with Error Code 6 (Invalid Nonce) with with a list with the digest algorithms supported by the floor control
a new nonce in a NONCE TLV. server.
If the nonce is valid, the floor control server calculates the If the algorithm identifier is valid, the floor control server checks
HMAC-SHA1 [1] of the message excluding the DIGEST TLV. The key used whether the NONCE attribute carries a nonce which was generated by
as input to HMAC is the secret shared between the server and the user the floor control server for this client and which still has not
identified by the USER-ID TLV in the message. If the resulting value expired. If the nonce is not valid, authentication is considered to
is the same as the one in the DIGEST TLV, authentication is have failed, in which case the floor control server SHOULD return an
considered successful. Error message with Error Code 4 (Invalid Nonce) with a new nonce in a
NONCE attribute.
If the resulting value is different than the one in the DIGEST TLV, If the nonce is valid, the floor control server calculates the keyed
authentication is considered to have failed, in which case the server digest of the message using the algorithm identified by the DIGEST
SHOULD return an Error message, as described in Section 13.7, with attribute. The key used as input to the keyed digest is the secret
Error Code 1 (Authentication Failed). Messages from a client that shared between the server and the user identified by the USER-ID
cannot be authenticated MUST NOT be processed further. attribute in the message. If the resulting value is the same as the
one in the DIGEST attribute, authentication is considered successful.
Floor control servers may include a NONCE TLV in their responses to If the resulting value is different than the one in the DIGEST
provide the nonce to be used in the next message by the client. attribute, authentication is considered to have failed, in which case
However, when TLS is used, floor control servers typically the server SHOULD return an Error message, as described in
Section 13.8, with Error Code 5 (Authentication Failed). Messages
from a client that cannot be authenticated MUST NOT be processed
further.
Floor control servers MAY include a NONCE attribute in their
responses to provide the nonce to be used in the next message by the
client. However, when TLS is used, floor control servers typically
authenticate only the first message sent over the TLS connection. authenticate only the first message sent over the TLS connection.
After authenticating a BCFP message, the floor control server checks After authenticating a BFCP message, the floor control server checks
whether or not the client is authorized to perform the operation it whether or not the client is authorized to perform the operation it
is requesting. If the client is not authorized to perform the is requesting. If the client is not authorized to perform the
operation being requested, the floor control server generates an operation being requested, the floor control server generates an
Error message, as described in Section 13.7, with an Error code with Error message, as described in Section 13.8, with an Error code with
a value of 4 (Unauthorized Operation). Messages from a client that a value of 8 (Unauthorized Operation). Messages from a client that
cannot be authorized MUST NOT be processed further. cannot be authorized MUST NOT be processed further.
10. Floor Participant Operations 10. Floor Participant Operations
This section specifies how floor participants can perform different This section specifies how floor participants can perform different
operations, such as requesting a floor, using the protocol elements operations, such as requesting a floor, using the protocol elements
described in earlier sections. Section 11 specifies operations that described in earlier sections. Section 11 specifies operations that
are specific to floor chairs, such as instructing the floor control are specific to floor chairs, such as instructing the floor control
server to grant or revoke a floor, and Section 12 specifies server to grant or revoke a floor, and Section 12 specifies
operations that can be performed by any client (i.e., both floor operations that can be performed by any client (i.e., both floor
participants and floor chairs). participants and floor chairs).
10.1 Requesting a Floor 10.1 Requesting a Floor
A floor participant that wishes to request one or more floors does so A floor participant that wishes to request one or more floors does so
by sending a FloorRequest message to the floor control server. by sending a FloorRequest message to the floor control server.
10.1.1 Sending a FloorRequest Message 10.1.1 Sending a FloorRequest Message
The ABNF in Section 5.3.1 describes the TLVs that a FloorRequest The ABNF in Section 5.3.1 describes the attributes that a
message can contain. In addition, the ABNF specifies normatively FloorRequest message can contain. In addition, the ABNF specifies
which of these TLVs are mandatory, and which ones are optional. normatively which of these attributes are mandatory, and which ones
are optional.
The floor participant sets the Conference ID in the FIXED-HEADER and The floor participant sets the Conference ID in the FIXED-HEADER and
the TRANSACTION-ID TLV following the rules given in Section 8.1. the TRANSACTION-ID attribute following the rules given in
Additionally, the floor participant follows the rules in Section 9.1 Section 8.1. Additionally, the floor participant follows the rules
which relate to the authentication of the message (i.e., to the in Section 9 which relate to the authentication of the message.
DIGEST TLV).
The floor participant must insert a USER-ID TLV, which will be used The floor participant must insert a USER-ID attribute, which will be
by the floor control server to authenticate and authorize the used by the floor control server to authenticate and authorize the
request. If the sender of the FloorRequest message (identified by request. If the sender of the FloorRequest message (identified by
the USER-ID TLV) is not the participant that would eventually get the the USER-ID attribute) is not the participant that would eventually
floor (i.e., a third party floor request), the sender SHOULD add a get the floor (i.e., a third party floor request), the sender SHOULD
BENEFICIARY-ID TLV to the message identifying the beneficiary of the add a BENEFICIARY-ID attribute to the message identifying the
floor. beneficiary of the floor.
Note that the name space for both the User ID and the Beneficiary Note that the name space for both the User ID and the Beneficiary
ID is the same. That is, a given participant is identified by a ID is the same. That is, a given participant is identified by a
single 16-bit value that can be used in USER-ID and in single 16-bit value that can be used in several attributes:
BENEFICIARY-ID TLVs. USER-ID, BENEFICIARY-ID, BENEFICIARY-INFORMATION, and REQUESTED-
BY-INFORMATION.
The floor participant must insert at least one FLOOR-ID TLV in the The floor participant must insert at least one FLOOR-ID attribute in
FloorRequest message. If the client inserts more than one FLOOR-ID the FloorRequest message. If the client inserts more than one
TLVs, the floor control server will treat all the floor requests as FLOOR-ID attributes, the floor control server will treat all the
an atomic package. That is, the floor control server will either floor requests as an atomic package. That is, the floor control
grant or deny all the floors in the FloorRequest message. server will either grant or deny all the floors in the FloorRequest
message.
The floor participant may use a HUMAN-READABLE-INFO TLV to state the The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute
reason why the floor or floors are being requested. The Text field to state the reason why the floor or floors are being requested. The
in the HUMAN-READABLE-INFO TLV is intended for human consumption. Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for
human consumption.
The floor participant may request the server to handle the floor The floor participant may request the server to handle the floor
request with a certain priority using a PRIORITY TLV. request with a certain priority using a PRIORITY attribute.
10.1.2 Receiving a Response 10.1.2 Receiving a Response
A message from the floor control server is considered to be a A message from the floor control server is considered to be a
response to the FloorRequest message if the message from the floor response to the FloorRequest message if the message from the floor
control server has the same Conference ID, Transaction ID, and User control server has the same Conference ID, Transaction ID, and User
ID as the FloorRequest message, as described in Section 8.1. ID as the FloorRequest message, as described in Section 8.1.
The successful processing of a FloorRequest message at the floor The successful processing of a FloorRequest message at the floor
control server involves generating one or several FloorRequestInfo control server involves generating one or several FloorRequestInfo
messages. The floor participant obtains a Floor Request ID in a messages. The floor participant obtains a Floor Request ID in the
FLOOR-REQUEST-ID TLV in the first FloorRequestInfo message from the Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in
floor control server. Subsequent FloorRequestInfo messages from the the first FloorRequestInfo message from the floor control server.
floor control server regarding the same floor request will carry the Subsequent FloorRequestInfo messages from the floor control server
same Floor Request ID as the initial FloorRequestInfo message. This regarding the same floor request will carry the same Floor Request ID
way, the floor participant can associate subsequent incoming in a FLOOR-REQUEST-INFORMATION attribute as the initial
FloorRequestInfo messages with the ongoing floor request. FloorRequestInfo message. This way, the floor participant can
associate subsequent incoming FloorRequestInfo messages with the
ongoing floor request.
The floor participant obtains information about the status of the The floor participant obtains information about the status of the
floor request in the REQUEST-STATUS TLV of each of the floor request in the FLOOR-REQUEST-INFORMATION attribute of each of
FloorRequestInfo messages received from the floor control server. If the FloorRequestInfo messages received from the floor control server.
the Request Status value is Granted, all the floors that were This attribute is a grouped attribute and, as such, it includes a
requested in the FloorRequest message have been granted. If the number of attributes that provide information about the floor
Request Status value is Denied, all the floors that were requested in request.
the FloorRequest message have been denied. The HUMAN-READABLE-INFO
TLV, if present, provides extra information which the floor
participant MAY display to the user.
A floor request is considered to be ongoing while it is in the The REQUEST-STATUS attribute. If the Request Status value is
Pending, Accepted, or Granted states. Granted, all the floors that were requested in the FloorRequest
message have been granted. If the Request Status value is Denied,
all the floors that were requested in the FloorRequest message have
been denied. A floor request is considered to be ongoing while it is
in the Pending, Accepted, or Granted states.
The STATUS-INFO attribute, if present, provides extra information
which the floor participant MAY display to the user.
The BENEFICIARY-INFORMATION attribute identifies the beneficiary of
the floor request in third-party floor requests. The REQUESTED-BY-
INFORMATION attribute may be not be present in FloorRequestInfo
messages received by the floor participant that requested the floor
because this floor participant is already identified by the USER-ID
attribute.
The PRIORITY attribute, when present, contains the priority that was
requested by the generator of the FloorRequest message.
If the response is an Error message, the floor control server could If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is not process the FloorRequest message for some reason, which is
described in the Error message. described in the Error message.
10.2 Cancelling a Floor Request and Releasing a Floor 10.2 Cancelling a Floor Request and Releasing a Floor
A floor participant that wishes to cancel an ongoing floor request A floor participant that wishes to cancel an ongoing floor request
does so by sending a FloorRelease message to the floor control does so by sending a FloorRelease message to the floor control
server. The FloorRelease message is also used by floor participants server. The FloorRelease message is also used by floor participants
that hold a floor and would like to release it. that hold a floor and would like to release it.
10.2.1 Sending a FloorRelease Message 10.2.1 Sending a FloorRelease Message
The ABNF in Section 5.3.2 describes the TLVs that a FloorRelease The ABNF in Section 5.3.2 describes the attributes that a
message can contain. In addition, the ABNF specifies normatively FloorRelease message can contain. In addition, the ABNF specifies
which of these TLVs are mandatory, and which ones are optional. normatively which of these attributes are mandatory, and which ones
are optional.
The floor participant sets the Conference ID in the FIXED-HEADER and The floor participant sets the Conference ID in the FIXED-HEADER and
the TRANSACTION-ID TLV following the rules given in Section 8.1. the TRANSACTION-ID attribute following the rules given in
Additionally, the floor participant follows the rules in Section 9.1 Section 8.1. Additionally, the floor participant follows the rules
which relate to the authentication of the message (i.e., to the in Section 9 which relate to the authentication of the message. The
DIGEST TLV). The floor participant must insert a USER-ID TLV, which floor participant must insert a USER-ID attribute, which will be used
will be used by the floor control server to authenticate and by the floor control server to authenticate and authorize the
authorize the request. request.
Note that the FloorRelease message is used to release a floor or Note that the FloorRelease message is used to release a floor or
floors that were granted and to cancel ongoing floor requests floors that were granted and to cancel ongoing floor requests
(from the protocol perspective both are ongoing floor requests). (from the protocol perspective both are ongoing floor requests).
Using the same message in both situations helps resolve the race Using the same message in both situations helps resolve the race
condition that occurs when the FloorRelease message and the condition that occurs when the FloorRelease message and the
FloorGrant message cross each other on the wire. FloorGrant message cross each other on the wire.
The floor participant uses the FLOOR-REQUEST-ID that was received in The floor participant uses the FLOOR-REQUEST-ID that was received in
the response to the FloorRequest message that the FloorRelease the response to the FloorRequest message that the FloorRelease
skipping to change at page 36, line 13 skipping to change at page 45, line 47
released at the same time). released at the same time).
10.2.2 Receiving a Response 10.2.2 Receiving a Response
A message from the floor control server is considered to be a A message from the floor control server is considered to be a
response to the FloorRelease message if the message from the floor response to the FloorRelease message if the message from the floor
control server has the same Conference ID, Transaction ID, and User control server has the same Conference ID, Transaction ID, and User
ID as the FloorRequest message, as described in Section 8.1. ID as the FloorRequest message, as described in Section 8.1.
If the response is a FloorRequestInfo message, the Request Status If the response is a FloorRequestInfo message, the Request Status
value in the REQUEST-STATUS-TLV will be Cancelled or Released. value in the REQUEST-STATUS attribute (within the FLOOR-REQUEST-
INFORMATION grouped attribute) will be Cancelled or Released.
If the response is an Error message, the floor control server could If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is not process the FloorRequest message for some reason, which is
described in the Error message. described in the Error message.
It is possible that the FloorRelease message crosses on the wire with It is possible that the FloorRelease message crosses on the wire with
a FloorRequestInfo message from the server with a Request Status a FloorRequestInfo message from the server with a Request Status
different from Cancelled or Released. In any case, such a different from Cancelled or Released. In any case, such a
FloorRequestInfo message will not be a response to the FloorRelease FloorRequestInfo message will not be a response to the FloorRelease
message, because its Transaction ID will not match that of the message, because its Transaction ID will not match that of the
skipping to change at page 36, line 37 skipping to change at page 46, line 24
This section specifies how floor chairs can instruct the floor This section specifies how floor chairs can instruct the floor
control server to grant or revoke a floor using the protocol elements control server to grant or revoke a floor using the protocol elements
described in earlier sections. described in earlier sections.
Floor chairs that wish to send instructions to a floor control server Floor chairs that wish to send instructions to a floor control server
do so by sending a ChairAction message. do so by sending a ChairAction message.
11.1 Sending a ChairAction Message 11.1 Sending a ChairAction Message
The ABNF in Section 5.3.7 describes the TLVs that a ChairAction The ABNF in Section 5.3.9 describes the attributes that a ChairAction
message can contain. In addition, the ABNF specifies normatively message can contain. In addition, the ABNF specifies normatively
which of these TLVs are mandatory, and which ones are optional. which of these attributes are mandatory, and which ones are optional.
The floor chair sets the Conference ID in the FIXED-HEADER and the The floor chair sets the Conference ID in the FIXED-HEADER and the
TRANSACTION-ID TLV following the rules given in Section 8.1. TRANSACTION-ID attribute following the rules given in Section 8.1.
Additionally, the floor chair follows the rules in Section 9.1 which Additionally, the floor chair follows the rules in Section 9 which
relate to the authentication of the message (i.e., to the DIGEST relate to the authentication of the message. The floor chair must
TLV). The floor chair must insert a USER-ID TLV, which will be used insert a USER-ID attribute, which will be used by the floor control
by the floor control server to authenticate and authorize the server to authenticate and authorize the request.
request.
The ChairAction message contains instructions that apply to one or The ChairAction message contains instructions that apply to one or
more floors within a particular floor request. The floor or floors more floors within a particular floor request. The floor or floors
are identified by FLOOR-ID TLVs and the floor request is identified are identified by FLOOR-ID attributes and the floor request is
by a FLOOR-REQUEST-ID TLV, which are carried in the ChairAction identified by a FLOOR-REQUEST-ID attribute, which are carried in the
message. ChairAction message.
For example, if a floor request consists of two floors that depend For example, if a floor request consists of two floors that depend
on different floor chairs, each floor chair will grant its floor on different floor chairs, each floor chair will grant its floor
within the floor request. Once both chairs have granted their within the floor request. Once both chairs have granted their
floor, the floor control server will grant the floor request as a floor, the floor control server will grant the floor request as a
whole. On the other hand, if one of the floor chairs denies its whole. On the other hand, if one of the floor chairs denies its
floor, the floor control server will deny the floor request as a floor, the floor control server will deny the floor request as a
whole, regardless of the other floor chair's decision. whole, regardless of the other floor chair's decision.
The floor chair provides the new status for one or more floors within The floor chair provides the new status for one or more floors within
the floor request using a REQUEST-STATUS TLV. If the new status of the floor request using a REQUEST-STATUS attribute. If the new
the floor request is Accepted, the floor chair MAY use the Queue status of the floor request is Accepted, the floor chair MAY use the
Position field to provide a queue position for the floor request. If Queue Position field to provide a queue position for the floor
the floor chair does not wish to provide a queue position, all the request. If the floor chair does not wish to provide a queue
bits of the Queue Position field SHOULD be set to zero. The floor position, all the bits of the Queue Position field SHOULD be set to
chair SHOULD use the Status Revoked to revoke a floor that was zero. The floor chair SHOULD use the Status Revoked to revoke a
granted (i.e., Granted status) and the Status Denied to reject floor floor that was granted (i.e., Granted status) and the Status Denied
requests in any other status (e.g., Pending and Accepted). to reject floor requests in any other status (e.g., Pending and
Accepted).
Note that a floor request may involve several floors and that a Note that a floor request may involve several floors and that a
ChairAction message may only deal with a subset of these floors ChairAction message may only deal with a subset of these floors
(e.g., if a single floor chair is not authorized to manage all the (e.g., if a single floor chair is not authorized to manage all the
floors). In this case, the REQUEST-STATUS that the floor chair floors). In this case, the REQUEST-STATUS that the floor chair
provides in the ChairAction message might not be the actual status provides in the ChairAction message might not be the actual status
that the floor request gets at the server. The floor control that the floor request gets at the server. The floor control
server will combine the instructions received from the different server will combine the instructions received from the different
floor chairs to come up with the actual status of the floor floor chairs to come up with the actual status of the floor
request. request.
The floor chair may use a HUMAN-READABLE-INFO TLV to state the reason The floor chair may use a STATUS-INFO attribute to state the reason
why the floor or floors are being accepted, granted, or revoked. The why the floor or floors are being accepted, granted, or revoked. The
Text in the HUMAN-READABLE-INFO TLV is intended for human Text in the STATUS-INFO attribute is intended for human consumption.
consumption.
11.2 Receiving a Response 11.2 Receiving a Response
A message from the floor control server is considered to be a A message from the floor control server is considered to be a
response to the ChairAction message if the message from the server response to the ChairAction message if the message from the server
has the same Conference ID, Transaction ID, and User ID as the has the same Conference ID, Transaction ID, and User ID as the
ChairAction message, as described in Section 8.1. ChairAction message, as described in Section 8.1.
A ChairActionAck message from the floor control server confirms that A ChairActionAck message from the floor control server confirms that
the floor control server has accepted the ChairAction message. An the floor control server has accepted the ChairAction message. An
skipping to change at page 38, line 23 skipping to change at page 48, line 10
A client can obtain information about the status of a floor or floors A client can obtain information about the status of a floor or floors
in different ways, which include using BFCP and using out-of-band in different ways, which include using BFCP and using out-of-band
mechanisms. Clients using BFCP to obtain such information use the mechanisms. Clients using BFCP to obtain such information use the
procedures described in this section. procedures described in this section.
Clients request information about the status of one or several floors Clients request information about the status of one or several floors
by sending a FloorInfoWanted message to the floor control server. by sending a FloorInfoWanted message to the floor control server.
12.1.1 Sending a FloorInfoWanted Message 12.1.1 Sending a FloorInfoWanted Message
The ABNF in Section 5.3.5 describes the TLVs that a FloorInfoWanted The ABNF in Section 5.3.7 describes the attributes that a
message can contain. In addition, the ABNF specifies normatively FloorInfoWanted message can contain. In addition, the ABNF specifies
which of these TLVs are mandatory, and which ones are optional. normatively which of these attributes are mandatory, and which ones
are optional.
The client sets the Conference ID in the FIXED-HEADER and the The client sets the Conference ID in the FIXED-HEADER and the
TRANSACTION-ID TLV following the rules given in Section 8.1. TRANSACTION-ID attribute following the rules given in Section 8.1.
Additionally, the client follows the rules in Section 9.1 which Additionally, the client follows the rules in Section 9 which relate
relate to the authentication and the protection of the integrity of to the authentication and the protection of the integrity of the
the message (i.e., to the DIGEST TLV). The client must insert a message. The client must insert a USER-ID attribute, which will be
USER-ID TLV, which will be used by the floor control server to used by the floor control server to authenticate and authorize the
authenticate and authorize the request. request.
The client inserts in the message all the Floor IDs it wants to The client inserts in the message all the Floor IDs it wants to
receive information about. The floor control server will send receive information about. The floor control server will send
periodic information about all these floors. If the client does not periodic information about all these floors. If the client does not
want to receive information about a particular floor any longer, it want to receive information about a particular floor any longer, it
sends a new FloorInfoWanted message removing the FLOOR-ID of this sends a new FloorInfoWanted message removing the FLOOR-ID of this
floor. If the client does not want to receive information about any floor. If the client does not want to receive information about any
floor any longer, it sends a FloorInfoWanted message with no FLOOR-ID floor any longer, it sends a FloorInfoWanted message with no FLOOR-ID
TLV. attribute.
12.1.2 Receiving a Response 12.1.2 Receiving a Response
A message from the floor control server is considered to be a A message from the floor control server is considered to be a
response to the FloorInfoWanted message if the message from the floor response to the FloorInfoWanted message if the message from the floor
control server has the same Conference ID, Transaction ID, and User control server has the same Conference ID, Transaction ID, and User
ID as the FloorRequest message, as described in Section 8.1. ID as the FloorRequest message, as described in Section 8.1.
On reception of the FloorInfoWanted message, the floor control server On reception of the FloorInfoWanted message, the floor control server
will respond with a FloorInfo message or with an Error message. If will respond with a FloorInfo message or with an Error message. If
the response is a FloorInfo message, it will contain information the response is a FloorInfo message, it will contain information
about one of the floors the client requested information about. If about one of the floors the client requested information about. If
the client did not include any FLOOR-ID TLV in its FloorInfoWanted the client did not include any FLOOR-ID attribute in its
message, the FloorInfo message from the floor control server will not FloorInfoWanted message (i.e., the client does not want to receive
include any either. information about any floor any longer), the FloorInfo message from
the floor control server will not include any FLOOR-ID attribute
either.
FloorInfo messages which carry information about a floor contain a FloorInfo messages which carry information about a floor contain a
FLOOR-ID TLV that identifies the floor. After this TLV, FloorInfo FLOOR-ID attribute that identifies the floor. After this attribute,
messages contain information about existing (one or more) floor FloorInfo messages contain information about existing (one or more)
request that relate to that floor. The information about each floor request that relate to that floor. The information about each
particular floor request consist of a FLOOR-REQUEST-ID TLV that particular floor request is encoded in a FLOOR-REQUEST-INFORMATION
identifies the floor request followed by a set of TLVs that provide attribute. This grouped attribute carries a Floor Request ID that
information about the floor request. identifies the floor request followed by a set of attributes that
provide information about the floor request.
After the first FloorInfo, the floor control server will continue After the first FloorInfo, the floor control server will continue
sending FloorInfo messages periodically informing the client about sending FloorInfo messages periodically informing the client about
changes on the floors the client requested information about. changes on the floors the client requested information about.
12.2 Requesting Information about Floor Requests 12.2 Requesting Information about Floor Requests
A client can obtain information about the status of one or several A client can obtain information about the status of one or several
floor requests in different ways, which include using BFCP and using floor requests in different ways, which include using BFCP and using
out-of-band mechanisms. Clients using BFCP to obtain such out-of-band mechanisms. Clients using BFCP to obtain such
information use the procedures described in this section. information use the procedures described in this section.
Clients request information about the current status of one or Clients request information about the current status of a floor
several floor requests by sending a FloorRequestInfoWanted message to requests by sending a FloorRequestInfoWanted message to the floor
the floor control server. control server.
Requesting information about a particular floor request is useful Requesting information about a particular floor request is useful in
in a number of situations. For example, on reception of a a number of situations. For example, on reception of a FloorRequest
FloorRequest message, a floor control server may choose to return message, a floor control server may choose to return FloorRequestInfo
FloorRequestInfo messages only when the floor request changes its messages only when the floor request changes its state (e.g., from
state (e.g., from Accepted to Granted), but not when the floor Accepted to Granted), but not when the floor request advances in its
request advances in its queue. In this situation, if the user queue. In this situation, if the user requests it, the floor
requests it, the floor participant can use a participant can use a FloorRequestInfoWanted message to poll the
FloorRequestInfoWanted message to poll the floor control server floor control server for the status of the floor request.
for the status of the floor request.
FloorRequestInfoWanted messages can also be used to request
information on all the floor requests associated with a floor
participant. For example, a floor participant, after experiencing
connectivity problems (e.g., its TCP connection with the floor
control server was down for a while and eventually was
re-established), may need to request information about all the
still existing floor requests associated to the floor participant.
12.2.1 Sending a FloorRequestInfoWanted Message 12.2.1 Sending a FloorRequestInfoWanted Message
The ABNF in Section 5.3.3 describes the TLVs that a The ABNF in Section 5.3.3 describes the attributes that a
FloorRequestInfoWanted message can contain. In addition, the ABNF FloorRequestInfoWanted message can contain. In addition, the ABNF
specifies normatively which of these TLVs are mandatory, and which specifies normatively which of these attributes are mandatory, and
ones are optional. which ones are optional.
The client sets the Conference ID in the FIXED-HEADER and the The client sets the Conference ID in the FIXED-HEADER and the
TRANSACTION-ID TLV following the rules given in Section 8.1. TRANSACTION-ID attribute following the rules given in Section 8.1.
Additionally, the client follows the rules in Section 9.1 which Additionally, the client follows the rules in Section 9 which relate
relate to the authentication of the message (i.e., to the DIGEST to the authentication of the message. The client must insert a
TLV). The client must insert a USER-ID TLV, which will be used by USER-ID attribute, which will be used by the floor control server to
the floor control server to authenticate and authorize the request. authenticate and authorize the request.
If the client wants to request the status of a single floor request,
it MUST insert a FLOOR-REQUEST-ID TLV that identifies the floor
request at the floor control server.
The client can also request information about all the ongoing floor The client must insert a FLOOR-REQUEST-ID attribute that identifies
requests associated with a particular participant. In this case, the the floor request at the floor control server.
client MUST NOT insert a FLOOR-REQUEST-ID TLV. If the beneficiary of
the floor requests the client is requesting information about is not
the client issuing the FloorRequestInfoWanted message (which is
identified by the USER-ID TLV in the message) the client MUST insert
a BENEFICIARY-ID TLV.
12.2.2 Receiving a Response 12.2.2 Receiving a Response
A message from the floor control server is considered to be a A message from the floor control server is considered to be a
response to the FloorRequestInfoWanted message if the message from response to the FloorRequestInfoWanted message if the message from
the floor control server has the same Conference ID, Transaction ID,a the floor control server has the same Conference ID, Transaction ID,a
nd User ID as the FloorRequestInfoWanted message, as described in nd User ID as the FloorRequestInfoWanted message, as described in
Section 8.1. Section 8.1.
If the response is a FloorRequestInfo message, the client obtains If the response is a FloorRequestInfo message, the client obtains
information about the status of the FloorRequest the client requested information about the status of the FloorRequest the client requested
information about in a REQUEST-STATUS TLVs. If the client requested information about in a FLOOR-REQUEST-INFORMATION attribute.
information about several floor requests, the FloorRequestInfo
message will carry several FLOOR-REQUEST-ID TLVs. Each
FLOOR-REQUEST-ID TLV will be followed by TLVs (which will include a
REQUEST-STATUS TLV) providing information about the floor request
identified by the FLOOR-REQUEST-ID TLV.
If the response is an Error message, the floor control server could If the response is an Error message, the floor control server could
not process the FloorRequestInfoWanted message for some reason, which not process the FloorRequestInfoWanted message for some reason, which
is described in the Error message. is described in the Error message.
12.3 Obtaining the Capabilities of a Floor Control Server 12.3 Requesting Information about a User
A client can obtain information about a participant and the floor
requests related to this participant in different ways, which include
using BFCP and using out-of-band mechanisms. Clients using BFCP to
obtain such information use the procedures described in this section.
Clients request information about a participant and the floor
requests related to this participant by sending a UserInfoWanted
message to the floor control server.
This functionality may be useful for floor chairs or floor
participants interested in the display name and the URI of a
particular floor participant. In addition, a floor participant may
find it useful to request information about itself. For example, a
floor participant, after experiencing connectivity problems (e.g.,
its TCP connection with the floor control server was down for a while
and eventually was re-established), may need to request information
about all the still existing floor requests associated to itself.
12.3.1 Sending a UserInfoWanted Message
The ABNF in Section 5.3.5 describes the attributes that a
UserInfoWanted message can contain. In addition, the ABNF specifies
normatively which of these attributes are mandatory, and which ones
are optional.
The client sets the Conference ID in the FIXED-HEADER and the
TRANSACTION-ID attribute following the rules given in Section 8.1.
Additionally, the client follows the rules in Section 9 which relate
to the authentication of the message. The client must insert a
USER-ID attribute, which will be used by the floor control server to
authenticate and authorize the request.
If the floor participant the client is requesting information about
is not the client issuing the UserInfoWanted message (which is
identified by the USER-ID attribute in the message) the client MUST
insert a BENEFICIARY-ID attribute.
12.3.2 Receiving a Response
A message from the floor control server is considered to be a
response to the UserInfoWanted message if the message from the floor
control server has the same Conference ID, Transaction ID, and User
ID as the UserInfoWanted message, as described in Section 8.1.
If the response is a UserInfo message, the client obtains information
about the floor participant in a BENEFICIARY-INFORMATION grouped
attribute and about the status of the floor requests associated with
the floor participant in FLOOR-REQUEST-INFORMATION attributes.
If the response is an Error message, the floor control server could
not process the UserInfoWanted message for some reason, which is
described in the Error message.
12.4 Obtaining the Capabilities of a Floor Control Server
A client that wishes to obtain the capabilities of a floor control A client that wishes to obtain the capabilities of a floor control
server does so by sending a Hello message to the floor control server does so by sending a Hello message to the floor control
server. server.
12.3.1 Sending a Hello Message 12.4.1 Sending a Hello Message
The ABNF in Section 5.3.9 describes the TLVs that a Hello message can The ABNF in Section 5.3.11 describes the attributes that a Hello
contain. In addition, the ABNF specifies normatively which of these message can contain. In addition, the ABNF specifies normatively
TLVs are mandatory, and which ones are optional. which of these attributes are mandatory, and which ones are optional.
The client sets the Conference ID in the FIXED-HEADER and the The client sets the Conference ID in the FIXED-HEADER and the
TRANSACTION-ID TLV following the rules given in Section 8.1. TRANSACTION-ID attribute following the rules given in Section 8.1.
Additionally, the client follows the rules in Section 9.1 which Additionally, the client follows the rules in Section 9 which relate
relate to the authentication and the protection of the integrity of to the authentication and the protection of the integrity of the
the message (i.e., to the DIGEST TLV). The client must insert a message. The client must insert a USER-ID attribute, which will be
USER-ID TLV, which will be used by the floor control server to used by the floor control server to authenticate and authorize the
authenticate and authorize the request. request.
12.3.2 Receiving Responses 12.4.2 Receiving Responses
A message from the floor control server is considered a response to A message from the floor control server is considered a response to
the Hello message by the client if the message from the floor control the Hello message by the client if the message from the floor control
server has the same Conference ID, Transaction ID, and User ID as the server has the same Conference ID, Transaction ID, and User ID as the
Hello message, as described in Section 8.1. Hello message, as described in Section 8.1.
If the response is a HelloAck message, the floor control server could If the response is a HelloAck message, the floor control server could
process successfully the Hello message. The SUPPORTED-TLVS TLV process successfully the Hello message. The SUPPORTED-ATTRIBUTES
indicates which TLVs are supported by the server. attribute indicates which attributes are supported by the server.
If the response is an Error message, the floor control server could If the response is an Error message, the floor control server could
not process the Hello message for some reason, which is described in not process the Hello message for some reason, which is described in
the Error message. the Error message.
13. Floor Control Server Operations 13. Floor Control Server Operations
This section specifies how floor control servers can perform This section specifies how floor control servers can perform
different operations, such as granting a floor, using the protocol different operations, such as granting a floor, using the protocol
elements described in earlier sections. elements described in earlier sections.
On reception of a message from a client, the floor control server On reception of a message from a client, the floor control server
MUST check whether or not the value of the Conference ID matched an MUST check whether or not the value of the Conference ID matched an
existing conference. If it does not, the floor control server SHOULD existing conference. If it does not, the floor control server SHOULD
send an Error message, as described in Section 13.7, with Error code send an Error message, as described in Section 13.8, with Error code
0 (Conference does not Exist). 1 (Conference does not Exist).
On reception of a message from a client, the floor control server On reception of a message from a client, the floor control server
follows the rules in Section 9.2, which relate to the authentication follows the rules in Section 9, which relate to the authentication of
of the message. the message.
On reception of a message from a client, the floor control server On reception of a message from a client, the floor control server
MUST check whether or not it understands all the mandatory ( 'M' bit MUST check whether or not it understands all the mandatory ( 'M' bit
set) TLVs in the message. If the floor control server does not set) attributes in the message. If the floor control server does not
understand all of them, the floor control server SHOULD send an Error understand all of them, the floor control server SHOULD send an Error
message, as described in Section 13.7, with Error code 2 message, as described in Section 13.8, with Error code 2
(Authentication Failed). The Error message SHOULD list the TLVs that (Authentication Failed). The Error message SHOULD list the
were not understood. attributes that were not understood.
13.1 Reception of a FloorRequest Message 13.1 Reception of a FloorRequest Message
On reception of a FloorRequest message, the floor control server On reception of a FloorRequest message, the floor control server
follows the rules in Section 9.2 which relate to client follows the rules in Section 9 which relate to client authentication
authentication and authorization. If while processing the and authorization. If while processing the FloorRequest message, the
FloorRequest message, the floor control server encounters an error, floor control server encounters an error, it SHOULD generate an Error
it SHOULD generate an Error response following the procedures response following the procedures described in Section 13.8
described in Section 13.7
BFCP allows floor participants to have several ongoing floor BFCP allows floor participants to have several ongoing floor
requests for the same floor (e.g., the same floor participant can requests for the same floor (e.g., the same floor participant can
occupy more than one position in a queue at the same time). A occupy more than one position in a queue at the same time). A
floor control server that only supports a certain number of floor control server that only supports a certain number of
ongoing floor requests per floor participant (e.g., one) can use ongoing floor requests per floor participant (e.g., one) can use
Error Code 9 (You have Already Reached the Maximum Number of Error Code 11 (You have Already Reached the Maximum Number of
Ongoing Floor Requests for this Floor) to inform the floor Ongoing Floor Requests for this Floor) to inform the floor
participant. participant.
13.1.1 Generating the First FloorRequestInfo Message 13.1.1 Generating the First FloorRequestInfo Message
The successful processing of a FloorRequest message by a floor The successful processing of a FloorRequest message by a floor
control server involves generating one or several FloorRequestInfo control server involves generating one or several FloorRequestInfo
messages, the first of which SHOULD be generated as soon as possible. messages, the first of which SHOULD be generated as soon as possible.
If the floor control server cannot accept, grant, or deny the floor If the floor control server cannot accept, grant, or deny the floor
request right away (e.g., a decision from a chair is needed), it request right away (e.g., a decision from a chair is needed), it
SHOULD use a Request Status value of Pending in the REQUEST-STATUS SHOULD use a Request Status value of Pending in the REQUEST-STATUS
TLV of the first FloorRequestInfo message it generates. attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of
the first FloorRequestInfo message it generates.
The policy a floor control server follows to grant or deny floors The policy a floor control server follows to grant or deny floors
is outside the scope of this document. A given floor control is outside the scope of this document. A given floor control
server may perform these decisions automatically while another may server may perform these decisions automatically while another may
contact a human acting as a chair everytime a decision needs to be contact a human acting as a chair everytime a decision needs to be
made. made.
The floor control server copies the Conference ID, the The floor control server MUST copy the Conference ID, the
TRANSACTION-ID, and the USER-ID TLVs from the FloorRequest into the TRANSACTION-ID, and the USER-ID attributes from the FloorRequest into
FloorRequestInfo, as described in Section 8.2. Additionally, the the FloorRequestInfo, as described in Section 8.2. Additionally, the
floor control server copies (if present) the BENEFICIARY-ID TLV from floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
the FloorRequest into the FloorRequestInfo. attribute to the FloorRequestInfo. The attributes contained in this
grouped attribute carry information about the floor request.
The floor control server MUST assign an identitifier that is unique The floor control server MUST assign an identitifier that is unique
within the conference to this floor request, and insert it in a within the conference to this floor request, and MUST insert it in
FLOOR-REQUEST-ID TLV into the FloorRequestInfo message. This the Floor Request ID field of the FLOOR-REQUEST-INFORMATION
indentifier will be used by the floor participant (or by a chair or attribute. This indentifier will be used by the floor participant
chairs) to refer to this specific floor request in the future. (or by a chair or chairs) to refer to this specific floor request in
the future.
The floor control server copies the FLOOR-ID TLVs from the The floor control server MUST copy the FLOOR-ID attributes from the
FloorRequest into the FloorRequestInfo. These FLOOR-ID TLVs identify FloorRequest into the FLOOR-REQUEST-INFORMATION attribute. These
the floors being requested (i.e., the floors associated with this FLOOR-ID attributes identify the floors being requested (i.e., the
particular floor request). floors associated with this particular floor request).
The floor control server also copies (if present) the PRIORITY TLV The floor control server SHOULD copy (if present) the contents of the
from the FloorRequest into the FloorRequestInfo. The Priority value BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY-
requested by the floor participant is only a hint, and does not INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped
necessarily need to be taken into consideration to decide whether to attribute. Additionally, the floor control server MAY provide the
grant or not the floor request. display name and the URI of the beneficiary in this BENEFICIARY-
INFORMATION attribute.
The floor control server MAY provide information about the requester
of the floor in a REQUESTED-BY-INFORMATION attribute inside the
FLOOR-REQUEST-INFORMATION grouped attribute.
The floor control server MAY copy (if present) the PRIORITY attribute
from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped
attribute. Note that this attribute carries the priority requested
by the participant. The priority the floor control server assigns to
the floor request depends on the priority requested by the
participant and the rights the participant has according to the
policy of the conference. For example, a participant that is only
allowed to use the Normal priority may request Highest priority for a
floor request. In that case, the floor control server would ignore
the priority requested by the participant.
The floor control server MAY copy (if present) the PARTICIPANT-
PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-
INFO grouped attribute.
13.1.2 Generation of Subsequent FloorRequestInfo Messages 13.1.2 Generation of Subsequent FloorRequestInfo Messages
A floor request is considered to be ongoing as long as it is not in A floor request is considered to be ongoing as long as it is not in
the Cancelled, Released, or Revoked states. If the REQUEST-STATUS the Cancelled, Released, or Revoked states. If the REQUEST-STATUS
TLV of the first FloorRequestInfo message generated by the floor attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of
control server did not indicate any of these states, the floor the first FloorRequestInfo message generated by the floor control
control server will need to send subsequent FloorRequestInfo server did not indicate any of these states, the floor control server
messages. will need to send subsequent FloorRequestInfo messages.
When the status of the floor request changes, the floor control floor When the status of the floor request changes, the floor control
control server SHOULD send new FloorRequestInfo messages with the server SHOULD send new FloorRequestInfo messages with the appropriate
appropriate Request Status. These FloorRequestInfo messages MUST Request Status. The floor control server MUST add a FLOOR-REQUEST-
contain a FLOOR-REQUEST-ID TLV equal to the one sent in the first INFORMATION attribute with a Floor Request ID equal to the one sent
FloorRequestInfo message, but MUST NOT contain any TRANSACTION-ID in the first FloorRequestInfo message to any new FloorRequestInfo
TLV. (The Floor Request ID identifies the floor request the related to the same floor request. (The Floor Request ID identifies
FloorRequestInfo applies to.) the floor request the FloorRequestInfo applies to.)
The FIXED-HEADER and the rest of the TLVs (except for the The floor control server MUST NOT add any TRANSACTION-ID attribute to
HUMAN-READABLE-INFO TLV) are the same as in the first subsequent FloorRequestInfo messages.
FloorRequestInfo message.
The rate at which the floor control server sends FloorRequestInfo The rate at which the floor control server sends FloorRequestInfo
messages is a matter of local policy. A floor control server may messages is a matter of local policy. A floor control server may
choose to send a new FloorRequestInfo message every time the floor choose to send a new FloorRequestInfo message every time the floor
request moves in the floor request queue while another may choose request moves in the floor request queue while another may choose
to only send a new FloorRequestInfo message when the floor request to only send a new FloorRequestInfo message when the floor request
is Granted or Denied. is Granted or Denied.
The floor control server may add a HUMAN-READABLE-INFO TLV to any of The floor control server may add a STATUS-INFO attribute to any of
the FloorRequestInfo messages it generates to provide extra the FloorRequestInfo messages it generates to provide extra
information about its decisions regarding the floor request (e.g., information about its decisions regarding the floor request (e.g.,
why it was denied). why it was denied).
Floor participants and floor chairs may request to be informed Floor participants and floor chairs may request to be informed
about the status of a floor following the procedures in Section about the status of a floor following the procedures in
12.1. If the processing of a floor request changes the status of Section 12.1. If the processing of a floor request changes the
a floor (e.g., the floor request is granted and consequently the status of a floor (e.g., the floor request is granted and
floor has a new holder), the floor control server needs to follow consequently the floor has a new holder), the floor control server
the procedures in Section 13.4 to inform the clients that have needs to follow the procedures in Section 13.5 to inform the
requested that information clients that have requested that information
The FIXED-HEADER and the rest of the attributes are the same as in
the first FloorRequestInfo message.
The floor control server can discard the state information about a The floor control server can discard the state information about a
particular floor request when this reaches a status of Cancelled, particular floor request when this reaches a status of Cancelled,
Released, or Revoked. Released, or Revoked.
13.2 Reception of a FloorRequestInfoWanted Message 13.2 Reception of a FloorRequestInfoWanted Message
On reception of a FloorRequestInfoWanted message, the floor control On reception of a FloorRequestInfoWanted message, the floor control
server follows the rules in Section 9.2 which relate to client server follows the rules in Section 9 which relate to client
authentication and authorization. If while processing the authentication and authorization. If while processing the
FloorRequestInfoWanted message, the floor control server encounters FloorRequestInfoWanted message, the floor control server encounters
an error, it SHOULD generate an Error response following the an error, it SHOULD generate an Error response following the
procedures described in Section 13.7 procedures described in Section 13.8
The successful processing of a FloorRequestInfoWanted message by a The successful processing of a FloorRequestInfoWanted message by a
floor control server involves generating a FloorRequestInfo message, floor control server involves generating a FloorRequestInfo message,
which SHOULD be generated as soon as possible. which SHOULD be generated as soon as possible.
The floor control server copies the Conference ID, the The floor control server MUST copy the Conference ID, the
TRANSACTION-ID, and the USER-ID TLVs from the FloorRequestInfoWanted TRANSACTION-ID, and the USER-ID attributes from the
message into the FloorRequestInfo message, as described in Section FloorRequestInfoWanted message into the FloorRequestInfo message, as
8.2. described in Section 8.2. Additionally, the floor control server
MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the
FloorRequestInfo. The attributes contained in this grouped attribute
carry information about the floor request.
13.2.1 Information on a Single Floor Request The floor control server MUST copy the contents of the
FLOOR-REQUEST-ID attribute from the FloorRequestInfoWanted message
into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION
attribute.
If the FloorRequestInfoWanted message carries a FLOOR-REQUEST-ID, the The floor control server MUST add FLOOR-ID attributes to the FLOOR-
sender of the message is requesting information about the floor REQUEST-INFORMATION grouped attribute identifying the floors being
request identified by the FLOOR-REQUEST-ID TLV. The floor control requested (i.e., the floors associated with the floor request
server copies the FLOOR-REQUEST-ID TLV from the identified by the FLOOR-REQUEST-ID attribute).
FloorRequestInfoWanted message into the FloorRequestInfo message.
The floor control server adds FLOOR-ID TLVs to the FloorRequestInfo The floor control server SHOULD add a BENEFICIARY-ID attribute to the
message identifying the floors being requested (i.e., the floors FLOOR-REQUEST-INFORMATION grouped attribute identifying the
associated with the floor request identified by the FLOOR-REQUEST-ID beneficiary of the floor request. Additionally, the floor control
TLV). server MAY provide the display name and the URI of the beneficiary in
this BENEFICIARY-INFORMATION attribute.
The floor control server may also add a PRIORITY TLV with the The floor control server MAY provide information about the requester
Priority value requested for the floor request and a of the floor in a REQUESTED-BY-INFORMATION attribute inside the
HUMAN-READABLE-INFO TLV with extra information about the floor FLOOR-REQUEST-INFORMATION grouped attribute.
request.
The floor control server adds a REQUEST-STATUS TLV with the current The floor control server MAY provide the reason why the floor
status of the floor request. participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
13.2.2 Information on the Floor Requests Associated to a Participant The floor control server MAY also add to the FLOOR-REQUEST-
INFORMATION grouped attribute a PRIORITY attribute with the Priority
value requested for the floor request and a STATUS-INFO attribute
with extra information about the floor request.
If the FloorRequestInfoWanted message does not carry a The floor control server adds a REQUEST-STATUS attribute to the
FLOOR-REQUEST-ID TLV, the sender of the message is requesting FLOOR-REQUEST-INFORMATION grouped attribute with the current status
information about all the floor requests from a given participant. of the floor request.
This participant is identified by a BENEFICIARY-ID TLV or, in the
absence of a BENEFICIARY-ID TLV, by a USER-ID TLV.
The floor control server copies (if present) the BENEFICIARY-ID TLV 13.3 Reception of a UserInfoWanted Message
from the FloorRequestInfoWanted message into the FloorRequestInfo
message. Additionally, the floor control server may provide extra
information about the participant by adding a USER-DISPLAY-NAME TLV,
a USER-URI TLV, or both to the FloorRequestInfo message.
The floor control server adds a FLOOR-REQUEST-ID TLV for each floor On reception of a UserInfoWanted message, the floor control server
request associated to the participant. Each FLOOR-REQUEST-ID TLV is follows the rules in Section 9 which relate to client authentication
followed by a number of TLVs which provide information about the and authorization. If while processing the UserInfoWanted message,
floor request. The floor control server generates the TLVs that the floor control server encounters an error, it SHOULD generate an
follow each FLOOR-REQUEST-ID following the rules in Section 13.2.1 Error response following the procedures described in Section 13.8
13.3 Reception of a FloorRelease Message The successful processing of a UserInfoWanted message by a floor
control server involves generating a UserInfo message, which SHOULD
be generated as soon as possible.
On reception of a FloorRelease message, the floor control server The floor control server MUST copy the Conference ID, the
follows the rules in Section 9.2 which relate to client TRANSACTION-ID, and the USER-ID attributes from the UserInfoWanted
authentication and authorization. If while processing the message into the USerInfo message, as described in Section 8.2.
FloorRelease message, the floor control server encounters an error,
it SHOULD generate an Error response following the procedures
described in Section 13.7
The sender of the UserInfoWanted message is requesting information
about all the floor requests associated to a given participant (i.e.,
the floor requests where the participant is either the beneficiary or
the requester). This participant is identified by a BENEFICIARY-ID
attribute or, in the absence of a BENEFICIARY-ID attribute, by a
USER-ID attribute in the UserInfoWanted message.
The floor control server MUST copy, if present, the contents of the
BENEFICIARY-ID attribute from the UserInfoWanted message into a
BENEFICIARY-INFORMATION attribute in the UserInfo message.
Additionally, the floor control server MAY provide the display name
and the URI of the participant the UserInfo message provides
information on in this BENEFICIARY-INFORMATION attribute.
The floor control server SHOULD add to the UserInfo message a FLOOR-
REQUEST-INFORMATION grouped attribute for each floor request related
to the participant the message provides information on (i.e., the
floor requests where the participant is either the beneficiary or the
requester). For each FLOOR-REQUEST-INFORMATION attribute, the floor
control server follows the following steps.
The floor control server MUST identity the floor request the FLOOR-
REQUEST-INFORMATION attribute applies to by filling the Floor Request
ID field of the FLOOR-REQUEST-INFORMATION attribute.
The floor control server MUST add FLOOR-ID attributes to the FLOOR-
REQUEST-INFORMATION grouped attribute identifying the floors being
requested (i.e., the floors associated with the floor request
identified by the FLOOR-REQUEST-ID attribute).
The floor control server SHOULD add a BENEFICIARY-ID attribute to the
FLOOR-REQUEST-INFORMATION grouped attribute identifying the
beneficiary of the floor request. Additionally, the floor control
server MAY provide the display name and the URI of the beneficiary in
this BENEFICIARY-INFORMATION attribute.
The floor control server MAY provide information about the requester
of the floor in a REQUESTED-BY-INFORMATION attribute inside the
FLOOR-REQUEST-INFORMATION grouped attribute.
The floor control server MAY provide the reason why the floor
participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
The floor control server MAY also add to the FLOOR-REQUEST-
INFORMATION grouped attribute a PRIORITY attribute with the Priority
value requested for the floor request and a STATUS-INFO attribute
with extra information about the floor request.
The floor control server MUST add a REQUEST-STATUS attribute to the
FLOOR-REQUEST-INFORMATION grouped attribute with the current status
of the floor request.
13.4 Reception of a FloorRelease Message
On reception of a FloorRelease message, the floor control server
follows the rules in Section 9 which relate to client authentication
and authorization. If while processing the FloorRelease message, the
floor control server encounters an error, it SHOULD generate an Error
response following the procedures described in Section 13.8
The successful processing of a FloorRelease message by a floor The successful processing of a FloorRelease message by a floor
control server involves generating a FloorRequestInfo message, which control server involves generating a FloorRequestInfo message, which
SHOULD be generated as soon as possible. SHOULD be generated as soon as possible.
The floor control server copies the Conference ID, the The floor control server MUST copy the Conference ID, the
TRANSACTION-ID, and the USER-ID TLVs from the FloorRelease message TRANSACTION-ID, and the USER-ID attributes from the FloorRelease
into the FloorRequestInfo message, as described in Section 8.2. message into the FloorRequestInfo message, as described in
Section 8.2.
The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
attribute to the FloorRequestInfo. The attributes contained in this
grouped attribute carry information about the floor request.
The FloorRelease message identifies the floor request it applies to The FloorRelease message identifies the floor request it applies to
using a FLOOR-REQUEST-ID. If the beneficiary of the floor request is using a FLOOR-REQUEST-ID. The floor control server MUST copy the
not the participant identified by the USER-ID TLV in the FloorRelease contents of the FLOOR-REQUEST-ID attribute from the FloorRelease
message, the floor control server adds a BENEFICIARY-ID TLV to the message into the Floor Request ID field of the FLOOR-REQUEST-
FloorRequestInfo message identifying the beneficiary of the floor INFORMATION attribute.
request. Additionally, the floor control server may provide extra
information about the beneficiary of the floor request by adding a
USER-DISPLAY-NAME TLV, a USER-URI TLV, or both to the
FloorRequestInfo message.
The floor control server copies the FLOOR-REQUEST-ID TLV from the The floor control server MUST add FLOOR-ID attributes to the FLOOR-
FloorRelease message into the FloorRequestInfo message. REQUEST-INFORMATION grouped attribute identifying the floors being
requested (i.e., the floors associated with the floor request
identified by the FLOOR-REQUEST-ID attribute).
The floor control server adds FLOOR-ID TLVs to the FloorRequestInfo The floor control server SHOULD add a BENEFICIARY-ID attribute to the
message identifying the floors being requested (i.e., the floors FLOOR-REQUEST-INFORMATION grouped attribute identifying the
associated with the floor request identified by the FLOOR-REQUEST-ID beneficiary of the floor request. Additionally, the floor control
TLV). server MAY provide the display name and the URI of the beneficiary in
this BENEFICIARY-INFORMATION attribute.
The floor control server may also add a PRIORITY TLV with the The floor control server MAY provide information about the requester
Priority value requested for the floor request and a of the floor in a REQUESTED-BY-INFORMATION attribute inside the
HUMAN-READABLE-INFO TLV with extra information about the floor FLOOR-REQUEST-INFORMATION grouped attribute.
request.
The floor control server adds a REQUEST-STATUS TLV to the The floor control server MAY provide the reason why the floor
FloorRequestInfo message. The Request Status value SHOULD be participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
Released, if the floor (or floors) had been previously granted, or of
Cancelled, if the floor (or floors) had not been previously granted.
13.4 Reception of a FloorInfoWanted Message The floor control server MAY also add to the FLOOR-REQUEST-
INFORMATION grouped attribute a PRIORITY attribute with the Priority
value requested for the floor request and a STATUS-INFO attribute
with extra information about the floor request.
The floor control server MUST add a REQUEST-STATUS attribute to the
FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status
value SHOULD be Released, if the floor (or floors) had been
previously granted, or Cancelled, if the floor (or floors) had not
been previously granted.
13.5 Reception of a FloorInfoWanted Message
On reception of a FloorInfoWanted message, the floor control server On reception of a FloorInfoWanted message, the floor control server
follows the rules in Section 9.2 which relate to client follows the rules in Section 9 which relate to client authentication.
authentication. If while processing the FloorRelease message, the If while processing the FloorRelease message, the floor control
floor control server encounters an error, it SHOULD generate an Error server encounters an error, it SHOULD generate an Error response
response following the procedures described in Section 13.7 following the procedures described in Section 13.8
A floor control server receiving a FloorInfoWanted message from a A floor control server receiving a FloorInfoWanted message from a
client SHOULD keep this client informed about the status of the client SHOULD keep this client informed about the status of the
floors identified by FLOOR-ID TLVs in the FloorInfoWanted message. floors identified by FLOOR-ID attributes in the FloorInfoWanted
Floor Control Servers keep clients informed by using FloorInfo message. Floor Control Servers keep clients informed by using
messages. FloorInfo messages.
An individual FloorInfo message carries information about a single An individual FloorInfo message carries information about a single
floor. So, when a FloorInfoWanted message requests information about floor. So, when a FloorInfoWanted message requests information about
more than one floor, the floor control server needs to send separate more than one floor, the floor control server needs to send separate
FloorInfo messages for different floors. FloorInfo messages for different floors.
The information FloorInfoWanted messages carry may depend on the user The information FloorInfoWanted messages carry may depend on the user
requesting the information. For example, a chair may be able to requesting the information. For example, a chair may be able to
receive information about pending requests while a regular user may receive information about pending requests while a regular user may
not be authorized to do so. not be authorized to do so.
13.4.1 Generation of the First FloorInfo Message 13.5.1 Generation of the First FloorInfo Message
The successful processing of a FloorInfoWanted message by a floor The successful processing of a FloorInfoWanted message by a floor
control server involves generating one or several FloorInfo messages, control server involves generating one or several FloorInfo messages,
the first of which SHOULD be generated as soon as possible. the first of which SHOULD be generated as soon as possible.
The floor control server copies the Conference ID, the The floor control server MUST copy the Conference ID, the
TRANSACTION-ID, and the USER-ID TLVs from the FloorInfoWanted message TRANSACTION-ID, and the USER-ID attributes from the FloorInfoWanted
into the FloorInfo message, as described in Section 8.2. message into the FloorInfo message, as described in Section 8.2.
If the FloorInfoWanted message did not contain any FLOOR-ID TLV, the If the FloorInfoWanted message did not contain any FLOOR-ID
floor control server sends the FloorInfo message without adding any attribute, the floor control server sends the FloorInfo message
additional TLV and does not send any subsequent FloorInfo message to without adding any additional attribute and does not send any
the floor participant. subsequent FloorInfo message to the floor participant.
If the FloorInfoWanted message contained one or more FLOOR-ID TLVs, If the FloorInfoWanted message contained one or more FLOOR-ID
the floor control server chooses one among them and adds this attributes, the floor control server chooses one among them and adds
FLOOR-ID TLV to the FloorInfo message. The floor control server adds this FLOOR-ID attribute to the FloorInfo message. The floor control
a FLOOR-REQUEST-ID TLV for each floor request associated to the server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for
floor. Each FLOOR-REQUEST-ID TLV is followed by a number of TLVs each floor request associated to the floor. Each FLOOR-REQUEST-
which provide information about the floor request. INFORMATION grouped attribute contains a number of attributes which
provide information about the floor request. For each FLOOR-REQUEST-
INFORMATION attribute, the floor control server follows the following
steps.
For each FLOOR-REQUEST-ID TLV, the floor control server may add a The floor control server MUST identity the floor request the FLOOR-
BENEFICIARY-ID TLV identifying the requester of the floor and a REQUEST-INFORMATION attribute applies to by filling the Floor Request
USER-DISPLAY-NAME TLV, a USER-URI TLV, or both providing information ID field of the FLOOR-REQUEST-INFORMATION attribute.
about the requester. Additionally, the floor control server adds
FLOOR-ID TLVs to the FloorInfo message identifying the floors being The floor control server MUST add FLOOR-ID attributes to the FLOOR-
REQUEST-INFORMATION grouped attribute identifying the floors being
requested (i.e., the floors associated with the floor request requested (i.e., the floors associated with the floor request
identified by the FLOOR-REQUEST-ID TLV). identified by the FLOOR-REQUEST-ID attribute).
The floor control server may also add a PRIORITY TLV with the The floor control server SHOULD add a BENEFICIARY-ID attribute to the
Priority value requested for the floor request and a FLOOR-REQUEST-INFORMATION grouped attribute identifying the
HUMAN-READABLE-INFO TLV with extra information about the floor beneficiary of the floor request. Additionally, the floor control
request. server MAY provide the display name and the URI of the beneficiary in
this BENEFICIARY-INFORMATION attribute.
The floor control server adds a REQUEST-STATUS TLV with the current The floor control server MAY provide information about the requester
status of the floor request. of the floor in a REQUESTED-BY-INFORMATION attribute inside the
FLOOR-REQUEST-INFORMATION grouped attribute.
13.4.2 Generation of Subsequent FloorInfo Messages The floor control server MAY provide the reason why the floor
participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
If the FloorInfoWanted message carried more than one FLOOR-ID TLV, The floor control server MAY also add to the FLOOR-REQUEST-
the floor control server SHOULD generate a FloorInfo message for each INFORMATION grouped attribute a PRIORITY attribute with the Priority
of them (except for the FLOOR-ID TLV chosen for the first FloorInfo value requested for the floor request and a STATUS-INFO attribute
message) as soon as possible. These FloorInfo messages are generated with extra information about the floor request.
following the same rules as for the first FloorInfo message (see
Section 13.4.1, but without adding a TRANSACTION TLV. The floor control server MUST add a REQUEST-STATUS attribute to the
FLOOR-REQUEST-INFORMATION grouped attribute with the current status
of the floor request.
13.5.2 Generation of Subsequent FloorInfo Messages
If the FloorInfoWanted message carried more than one FLOOR-ID
attribute, the floor control server SHOULD generate a FloorInfo
message for each of them (except for the FLOOR-ID attribute chosen
for the first FloorInfo message) as soon as possible. These
FloorInfo messages are generated following the same rules as for the
first FloorInfo message (see Section 13.5.1, but without adding a
TRANSACTION attribute.
After generating these messages, the floor control server sends After generating these messages, the floor control server sends
FloorInfo messages periodically keeping the client informed about all FloorInfo messages periodically keeping the client informed about all
the floors the client requested information about. These messages the floors the client requested information about. These messages
MUST NOT carry a TRANSACTION-ID TLV. MUST NOT carry a TRANSACTION-ID attribute.
The rate at which the floor control server sends FloorInfo The rate at which the floor control server sends FloorInfo
messages is a matter of local policy. A floor control server may messages is a matter of local policy. A floor control server may
choose to send a new FloorInfo message every time a new floor choose to send a new FloorInfo message every time a new floor
request arrives while another may choose to only send a new request arrives while another may choose to only send a new
FloorInfo message when a new floor request is Granted. FloorInfo message when a new floor request is Granted.
13.5 Reception of a ChairAction Message 13.6 Reception of a ChairAction Message
On reception of a ChairAction message, the floor control server On reception of a ChairAction message, the floor control server
follows the rules in Section 9.2 which relate to client follows the rules in Section 9 which relate to client authentication
authentication and authorization. If while processing the and authorization. If while processing the ChairAction message, the
ChairAction message, the floor control server encounters an error, it floor control server encounters an error, it SHOULD generate an Error
SHOULD generate an Error response following the procedures described response following the procedures described in Section 13.8
in Section 13.7
The successful processing of a ChairAction message by a floor control The successful processing of a ChairAction message by a floor control
server involves generating a ChairActionAck message, which SHOULD be server involves generating a ChairActionAck message, which SHOULD be
generated as soon as possible. generated as soon as possible.
The floor control server copies the Conference ID, the The floor control server MUST copy the Conference ID, the
TRANSACTION-ID, and the USER-ID TLVs from the ChairAction message TRANSACTION-ID, and the USER-ID attributes from the ChairAction
into the ChairActionAck message, as described in Section 8.2. message into the ChairActionAck message, as described in Section 8.2.
The floor control server needs to take into consideration the The floor control server needs to take into consideration the
operation requested in the ChairAction message (e.g., granting a operation requested in the ChairAction message (e.g., granting a
floor), but does not necessarily need to perform it as requested by floor), but does not necessarily need to perform it as requested by
the floor chair. The operation that the floor control server the floor chair. The operation that the floor control server
performs depends on the ChairAction message and on the internal state performs depends on the ChairAction message and on the internal state
of the floor control server. of the floor control server.
For example, a floor chair may send a ChairAction message granting a For example, a floor chair may send a ChairAction message granting a
floor which was requested as part of an atomic floor request floor which was requested as part of an atomic floor request
skipping to change at page 49, line 9 skipping to change at page 62, line 5
coherent floor state using instructions from floor chairs as input to coherent floor state using instructions from floor chairs as input to
this state. this state.
If the new Status in the ChairAction message is Accepted and all the If the new Status in the ChairAction message is Accepted and all the
bits of the Queue Position field are zero, the floor chair is bits of the Queue Position field are zero, the floor chair is
requesting the floor control server to assign a queue position (e.g., requesting the floor control server to assign a queue position (e.g.,
the last in the queue) to the floor request based on the local policy the last in the queue) to the floor request based on the local policy
of the floor control server. (Of course, such a request only applies of the floor control server. (Of course, such a request only applies
in case the floor control server implements a queue.) in case the floor control server implements a queue.)
13.6 Reception of a Hello Message 13.7 Reception of a Hello Message
On reception of a Hello message, the floor control server follows the On reception of a Hello message, the floor control server follows the
rules in Section 9.2 which relate to client authentication. If while rules in Section 9 which relate to client authentication. If while
processing the Hello message, the floor control server encounters an processing the Hello message, the floor control server encounters an
error, it SHOULD generate an Error response following the procedures error, it SHOULD generate an Error response following the procedures
described in Section 13.7 described in Section 13.8
The successful processing of a Hello message by a floor control The successful processing of a Hello message by a floor control
server involves generating a HelloAck message, which SHOULD be server involves generating a HelloAck message, which SHOULD be
generated as soon as possible. The floor control server copies the generated as soon as possible. The floor control server MUST copy
Conference ID, the TRANSACTION-ID, and the USER-ID TLVs from the the Conference ID, the TRANSACTION-ID, and the USER-ID attributes
Hello into the HelloAck, as described in Section 8.2. from the Hello into the HelloAck, as described in Section 8.2.
The floor control server adds a SUPPORTED-TLVS TLV to the HelloAck The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to
message listing all the TLVs supported by the floor control server. the HelloAck message listing all the primitives (i.e., BFCP messages)
supported by the floor control server.
13.7 Error Message Generation The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to
the HelloAck message listing all the attributes supported by the
floor control server.
13.8 Error Message Generation
Error messages are always sent in response to a previous message from Error messages are always sent in response to a previous message from
the client as part of a client-initiated transaction. The ABNF in the client as part of a client-initiated transaction. The ABNF in
Section 5.3.11 describes the TLVs that an Error message can contain. Section 5.3.13 describes the attributes that an Error message can
In addition, the ABNF specifies normatively which of these TLVs are contain. In addition, the ABNF specifies normatively which of these
mandatory, and which ones are optional. attributes are mandatory, and which ones are optional.
The floor control server copies the Conference ID, the The floor control server MUST copy the Conference ID, the
TRANSACTION-ID, and the USER-ID TLVs from the message from the client TRANSACTION-ID, and the USER-ID attributes from the message from the
into the Error message, as described in Section 8.2. client into the Error message, as described in Section 8.2.
The floor control server adds an ERROR-CODE TLV to the Error message. The floor control server MUST add an ERROR-CODE attribute to the
The ERROR-CODE TLV contains an Error Code from Table 4. Error message. The ERROR-CODE attribute contains an Error Code from
Additionally, the floor control server may add a HUMAN-READABLE-INFO Table 6. Additionally, the floor control server may add a ERROR-INFO
TLV with extra information about the error. attribute with extra information about the error.
14. Security Considerations 14. Security Considerations
BFCP uses message signatures to provide client authentication and TLS BFCP can use TLS or message signatures to provide client
to provide floor control server authentication, replay and integrity authentication. Floor control server authentication is based on TLS,
protection, and confidentiality. It is RECOMMENDED that TLS with which also provides replay and integrity protection, and
non-null encryption is always used and that the first message from a confidentiality. It is RECOMMENDED that TLS with non-null encryption
client over a given TLS connection is signed using the DIGEST TLV. is always used and that the first message from an unauthenticated
In any case, clients and floor control servers MAY use other security client over a given TLS connection is signed using the DIGEST
attribute. Clients and floor control servers MAY use other security
mechanisms as long as they provide similar security properties. mechanisms as long as they provide similar security properties.
The remainder of this Section analyzes some of the threats against The remainder of this Section analyzes some of the threats against
BFCP and how they are addressed. BFCP and how they are addressed.
An attacker may attempt to impersonate a client (a floor participant An attacker may attempt to impersonate a client (a floor participant
or a floor chair) in order to generate forged floor requests or to or a floor chair) in order to generate forged floor requests or to
grant or deny existing floor requests. Client impersonation is grant or deny existing floor requests. Client impersonation is
avoided by having clients sign their messages. A nonce is included avoided by having clients sign their messages. A nonce is included
in the signature to ensure the freshness of the message. If the in the signature to ensure the freshness of the message. If the
client is using a TLS connection to communicate with the floor client is using a TLS connection to communicate with the floor
control server, it is enough that the client signs its first message control server, it is enough that the client signs its first message
over the TLS connection. The floor control server assumes that over the TLS connection. The floor control server assumes that
attackers cannot hickjack the TLS connection and, therefore, that attackers cannot hickjack the TLS connection and, therefore, that
subsequent messages over the TLS connection come from the client that subsequent messages over the TLS connection come from the client that
was initially authenticated. was initially authenticated. If TLS-based client authentication is
used, there is not need for the client to sign BFCP messages over the
connection.
An attacker may attempt to impersonate a floor control server. A An attacker may attempt to impersonate a floor control server. A
successful attacker would be able to make clients think that they successful attacker would be able to make clients think that they
hold a particular floor so that they would try to access a resource hold a particular floor so that they would try to access a resource
(e.g., sending media) without having legitimate rights to access it. (e.g., sending media) without having legitimate rights to access it.
Floor control server impersonation is avoided by having floor control Floor control server impersonation is avoided by having floor control
servers present their server certificates at TLS connection servers present their server certificates or prove that they have a
establishment time. shared secret with the client at TLS connection establishment time.
Attackers may attempt to modify messages exchanged by a client and a Attackers may attempt to modify messages exchanged by a client and a
floor control server. The integrity protection provided by TLS floor control server. The integrity protection provided by TLS
connections prevents this attack. connections prevents this attack.
An attacker may attempt to fetch a valid message sent by a client to An attacker may attempt to fetch a valid message sent by a client to
a floor control server and replay it at a later point. If the a floor control server and replay it at a later point. If the
attacker attempts to replay it over the TLS connection between the message was signed, the attacker may attempt to establish a new TLS
client and the floor control server, TLS mechanisms discard it at the connection with the floor control server and replay the message over
receiver side. Still, if the message was signed, the attacker may the new connection. Using TLS confidentiality prevents this attack
attempt to establish a new TLS connection with the floor control because the attacker cannot access the contents of the message in the
server and replay the message over the new connection. Using TLS first place. Additionally, TLS provides replay protection for a
confidentiality prevents this attack because the attacker cannot given connection. Therefore, it is strongly RECOMMENDED that TLS is
access the contents of the message in the first place. Additionally, used with a non-null encryption algorithm.
if the attacker attempts to replay the encrypted message over the new
connection, TLS mechanisms would discard it at the receiver side.
Therefore, it is strongly RECOMMENDED that TLS is used with a
non-null encryption algorithm.
Attackers may attempt to pick messages from the network to get access Attackers may attempt to pick messages from the network to get access
to confidential information between the floor control server and a to confidential information between the floor control server and a
client (e.g., why a floor request was denied). TLS confidentiality client (e.g., why a floor request was denied). TLS confidentiality
prevents this attack. prevents this attack.
15. IANA Considerations 15. IANA Considerations
This document instructs the IANA to create a new registry for BFCP This document instructs the IANA to create a new registry for BFCP
parameters called "Binary Floor Control Protocol (BFCP) Parameters". parameters called "Binary Floor Control Protocol (BFCP) Parameters".
skipping to change at page 51, line 26 skipping to change at page 64, line 26
registration policy for BFCP attributes shall be "Specification registration policy for BFCP attributes shall be "Specification
Required". For the purposes of this subregistry, the BFCP attributes Required". For the purposes of this subregistry, the BFCP attributes
for which IANA registration is requested MUST be defined by a for which IANA registration is requested MUST be defined by a
standards-track RFC. Such RFC MUST specify the attribute's type, standards-track RFC. Such RFC MUST specify the attribute's type,
name, format, and semantics. name, format, and semantics.
For each BFCP attribute, the IANA registers its type, its name, and For each BFCP attribute, the IANA registers its type, its name, and
the reference to the RFC where the attribute is defined. The the reference to the RFC where the attribute is defined. The
following table contains the initial values of this subregistry. following table contains the initial values of this subregistry.
+------+---------------------+------------+ +------+---------------------------+------------+
| Type | Attribute | Reference | | Type | Attribute | Reference |
+------+---------------------+------------+ +------+---------------------------+------------+
| 0 | FLOOR-ID | [RFC XXXX] | | 1 | BENEFICIARY-ID | [RFC XXXX] |
| 1 | USER-ID | [RFC XXXX] | | 2 | FLOOR-ID | [RFC XXXX] |
| 2 | BENEFICIARY-ID | [RFC XXXX] | | 3 | FLOOR-REQUEST-ID | [RFC XXXX] |
| 3 | TRANSACTION-ID | [RFC XXXX] | | 4 | NONCE | [RFC XXXX] |
| 4 | FLOOR-REQUEST-ID | [RFC XXXX] | | 5 | TRANSACTION-ID | [RFC XXXX] |
| 5 | HUMAN-READABLE-INFO | [RFC XXXX] | | 6 | USER-ID | [RFC XXXX] |
| 6 | DIGEST | [RFC XXXX] | | 7 | PRIORITY | [RFC XXXX] |
| 7 | REQUEST-STATUS | [RFC XXXX] | | 8 | REQUEST-STATUS | [RFC XXXX] |
| 8 | ERROR-CODE | [RFC XXXX] | | 9 | DIGEST | [RFC XXXX] |
| 9 | USER-DISPLAY-NAME | [RFC XXXX] | | 10 | ERROR-CODE | [RFC XXXX] |
| 10 | USER-URI | [RFC XXXX] | | 11 | ERROR-INFO | [RFC XXXX] |
| 11 | PRIORITY | [RFC XXXX] | | 12 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] |
| 12 | NONCE | [RFC XXXX] | | 13 | STATUS-INFO | [RFC XXXX] |
| 13 | SUPPORTED-TLVS | [RFC XXXX] | | 14 | SUPPORTED-ATTRIBUTES | [RFC XXXX] |
+------+---------------------+------------+ | 15 | SUPPORTED-PRIMITIVES | [RFC XXXX] |
| 16 | USER-DISPLAY-NAME | [RFC XXXX] |
| 17 | USER-URI | [RFC XXXX] |
| 18 | BENEFICIARY-INFORMATION | [RFC XXXX] |
| 19 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] |
| 20 | REQUESTED-BY-INFORMATION | [RFC XXXX] |
+------+---------------------------+------------+
Table 5: Initial values of the BFCP Attribute subregistry Table 7: Initial values of the BFCP Attribute subregistry
15.2 Primitive Subregistry 15.2 Primitive Subregistry
This Section establishes the Primitive subregistry under the BFCP This Section establishes the Primitive subregistry under the BFCP
Parameters registry. As per the terminology in RFC 2434 [5], the Parameters registry. As per the terminology in RFC 2434 [5], the
registration policy for BFCP primitives shall be "Specification registration policy for BFCP primitives shall be "Specification
Required". For the purposes of this subregistry, the BFCP primitives Required". For the purposes of this subregistry, the BFCP primitives
for which IANA registration is requested MUST be defined by a for which IANA registration is requested MUST be defined by a
standards-track RFC. Such RFC MUST specify the primitive's value, standards-track RFC. Such RFC MUST specify the primitive's value,
name, format, and semantics. name, format, and semantics.
For each BFCP primitive, the IANA registers its value, its name, and For each BFCP primitive, the IANA registers its value, its name, and
the reference to the RFC where the primitive is defined. The the reference to the RFC where the primitive is defined. The
following table contains the initial values of this subregistry. following table contains the initial values of this subregistry.
+-------+------------------------+------------+ +-------+------------------------+------------+
| Value | Primitive | Reference | | Value | Primitive | Reference |
+-------+------------------------+------------+ +-------+------------------------+------------+
| 0 | FloorRequest | [RFC XXXX] | | 1 | FloorRequest | [RFC XXXX] |
| 1 | FloorRelease | [RFC XXXX] | | 2 | FloorRelease | [RFC XXXX] |
| 2 | FloorRequestInfoWanted | [RFC XXXX] | | 3 | FloorRequestInfoWanted | [RFC XXXX] |
| 3 | FloorRequestInfo | [RFC XXXX] | | 4 | FloorRequestInfo | [RFC XXXX] |
| 4 | FloorInfoWanted | [RFC XXXX] | | 5 | UserInfoWanted | [RFC XXXX] |
| 5 | FloorInfo | [RFC XXXX] | | 6 | UserInfo | [RFC XXXX] |
| 6 | ChairAction | [RFC XXXX] | | 7 | FloorInfoWanted | [RFC XXXX] |
| 7 | ChairActionAck | [RFC XXXX] | | 8 | FloorInfo | [RFC XXXX] |
| 8 | Hello | [RFC XXXX] | | 9 | ChairAction | [RFC XXXX] |
| 9 | HelloAck | [RFC XXXX] | | 10 | ChairActionAck | [RFC XXXX] |
| 10 | Error | [RFC XXXX] | | 11 | Hello | [RFC XXXX] |
| 12 | HelloAck | [RFC XXXX] |
| 13 | Error | [RFC XXXX] |
+-------+------------------------+------------+ +-------+------------------------+------------+
Table 6: Initial values of the BFCP primitive subregistry Table 8: Initial values of the BFCP primitive subregistry
15.3 Request Status Subregistry 15.3 Request Status Subregistry
This Section establishes the Request Status subregistry under the This Section establishes the Request Status subregistry under the
BFCP Parameters registry. As per the terminology in RFC 2434 [5], BFCP Parameters registry. As per the terminology in RFC 2434 [5],
the registration policy for BFCP request status shall be the registration policy for BFCP request status shall be
"Specification Required". For the purposes of this subregistry, the "Specification Required". For the purposes of this subregistry, the
BFCP request status for which IANA registration is requested MUST be BFCP request status for which IANA registration is requested MUST be
defined by a standards-track RFC. Such RFC MUST specify the value defined by a standards-track RFC. Such RFC MUST specify the value
and the semantics of the request status. and the semantics of the request status.
For each BFCP request status, the IANA registers its value, its For each BFCP request status, the IANA registers its value, its
meaning, and the reference to the RFC where the request status is meaning, and the reference to the RFC where the request status is
defined. The following table contains the initial values of this defined. The following table contains the initial values of this
subregistry. subregistry.
+-------+-----------+------------+ +-------+-----------+------------+
| Value | Status | Reference | | Value | Status | Reference |
+-------+-----------+------------+ +-------+-----------+------------+
| 0 | Pending | [RFC XXXX] | | 1 | Pending | [RFC XXXX] |
| 1 | Accepted | [RFC XXXX] | | 2 | Accepted | [RFC XXXX] |
| 2 | Granted | [RFC XXXX] | | 3 | Granted | [RFC XXXX] |
| 3 | Denied | [RFC XXXX] | | 4 | Denied | [RFC XXXX] |
| 4 | Cancelled | [RFC XXXX] | | 5 | Cancelled | [RFC XXXX] |
| 5 | Released | [RFC XXXX] | | 6 | Released | [RFC XXXX] |
| 6 | Revoked | [RFC XXXX] | | 7 | Revoked | [RFC XXXX] |
+-------+-----------+------------+ +-------+-----------+------------+
Table 7: Initial values of the Request Status subregistry Table 9: Initial values of the Request Status subregistry
15.4 Error Code Subregistry 15.4 Error Code Subregistry
This Section establishes the Error Code subregistry under the BFCP This Section establishes the Error Code subregistry under the BFCP
Parameters registry. As per the terminology in RFC 2434 [5], the Parameters registry. As per the terminology in RFC 2434 [5], the
registration policy for BFCP error codes shall be "Specification registration policy for BFCP error codes shall be "Specification
Required". For the purposes of this subregistry, the BFCP error Required". For the purposes of this subregistry, the BFCP error
codes for which IANA registration is requested MUST be defined by a codes for which IANA registration is requested MUST be defined by a
standards-track RFC. Such RFC MUST specify the value and the standards-track RFC. Such RFC MUST specify the value and the
semantics of the error code, and any Error Specific Details that semantics of the error code, and any Error Specific Details that
apply to it. apply to it.
For each BFCP primitive, the IANA registers its value, its meaning, For each BFCP primitive, the IANA registers its value, its meaning,
and the reference to the RFC where the primitive is defined. The and the reference to the RFC where the primitive is defined. The
following table contains the initial values of this subregistry. following table contains the initial values of this subregistry.
+----------------------+----------------------+---------------------+ +----------------------+----------------------+---------------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+----------------------+----------------------+---------------------+ +----------------------+----------------------+---------------------+
| 0 | Conference does not | [RFC XXXX] | | 1 | Conference does not | [RFC XXXX] |
| | Exist | | | | Exist | |
| 1 | Authentication | [RFC XXXX] | | 2 | User does not Exist | [RFC XXXX] |
| 3 | DIGEST Attribute | [RFC XXXX] |
| | Required | |
| 4 | Invalid Nonce | [RFC XXXX] |
| 5 | Authentication | [RFC XXXX] |
| | Failed | | | | Failed | |
| 2 | Unknown Mandatory | [RFC XXXX] | | 6 | Unknown Primitive | [RFC XXXX] |
| | TLV | | | 7 | Unknown Mandatory | [RFC XXXX] |
| 3 | Floor Request ID | [RFC XXXX] | | | Attribute | |
| | Does Not Exist | | | 8 | Unauthorized | [RFC XXXX] |
| 4 | Unauthorized | [RFC XXXX] |
| | Operation | | | | Operation | |
| 5 | User does not Exist | [RFC XXXX] | | 9 | Invalid Floor ID | [RFC XXXX] |
| 6 | Invalid Nonce | [RFC XXXX] | | 10 | Floor Request ID | [RFC XXXX] |
| 7 | DIGEST TLV Required | [RFC XXXX] | | | Does Not Exist | |
| 8 | Invalid Floor ID | [RFC XXXX] | | 11 | You have Already | [RFC XXXX] |
| 9 | You have Already | [RFC XXXX] |
| | Reached the Maximum | | | | Reached the Maximum | |
| | Number of Ongoing | | | | Number of Ongoing | |
| | Floor Requests for | | | | Floor Requests for | |
| | this Floor | | | | this Floor | |
+----------------------+----------------------+---------------------+ +----------------------+----------------------+---------------------+
Table 8: Initial Values of the Error Code subregistry Table 10: Initial Values of the Error Code subregistry
15.5 Digest Algorithm Subregistry
This Section establishes the Digest Algorithm subregistry under the
BFCP Parameters registry. As per the terminology in RFC 2434 [5],
the registration policy for BFCP digest algorithms shall be
"Specification Required". For the purposes of this subregistry, the
BFCP error codes for which IANA registration is requested MUST be
defined by a standards-track RFC. Such RFC MUST specify the value
and the semantics of the error code, and any Error Specific Details
that apply to it.
For each BFCP digest algorithm, the IANA registers its numeric
identifier, its name, and the reference to the RFC where the
algorithm is defined. The following table contains the initial
values of this subregistry.
+------------+-----------+-----------+
| Identifier | Algorithm | Reference |
+------------+-----------+-----------+
| 0 | HMAC-SHA1 | RFC 2104 |
+------------+-----------+-----------+
Table 11: Initial values of the Digest Algorithms subregistry
16. Acknowledgments 16. Acknowledgments
The XCON WG chairs, Adam Roach and Alan Johnston, provided useful The XCON WG chairs, Adam Roach and Alan Johnston, provided useful
ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat, ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat,
Jonathan Rosenberg, and Miguel A. Garcia-Martin provided useful Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben
comments. Campbell, and Dave Morgan provided useful comments.
17. References 17. References
17.1 Normative References 17.1 Normative References
[1] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing [1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
2246, January 1999. RFC 2246, January 1999.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002. Transport Layer Security (TLS)", RFC 3268, June 2002.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
17.2 Informational References 17.2 Informational References
[8] Handley, M. and V. Jacobson, "SDP: Session Description [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Protocol", RFC 2327, April 1998. Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[11] Schulzrinne, H., "Requirements for Floor Control Protocol", [10] Schulzrinne, H., "Requirements for Floor Control Protocol",
draft-ietf-xcon-floor-control-req-02 (work in progress), draft-ietf-xcon-floor-control-req-03 (work in progress),
October 2004. January 2005.
[12] Rosenberg, J., "A Framework for Conferencing with the Session [11] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-03 (work in draft-ietf-sipping-conferencing-framework-04 (work in
progress), October 2004. progress), February 2005.
[13] Barnes, M. and C. Boulton, "A Framework for Centralized [12] Barnes, M. and C. Boulton, "A Framework and Data Model for
Conferencing", draft-barnes-xcon-framework-00 (work in Centralized Conferencing", draft-barnes-xcon-framework-02 (work
progress), October 2004. in progress), February 2005.
[14] Camarillo, G., "Session Description Protocol (SDP) Format for [13] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", Binary Floor Control Protocol (BFCP) Streams",
draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), April draft-ietf-mmusic-sdp-bfcp-00 (work in progress), January 2005.
2005.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Joerg Ott Joerg Ott
Universitaet Bremen Helsinki University of Technology
MZH 5180 Department for Electrical and Communications Engineering
Bibliothekstr. 1 Networking Laboratory
Bremen D-28359 Helsinki
Germany Finland
EMail: jo@tzi.org Email: jo@netlab.hut.fi
Keith Drage Keith Drage
Lucent Technologies Lucent Technologies
Windmill Hill Business Park Windmill Hill Business Park
Swindon Swindon
Wiltshire SN5 6PP Wiltshire SN5 6PP
UK UK
EMail: drage@lucent.com Email: drage@lucent.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 57, line 41 skipping to change at page 70, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/