draft-ietf-xcon-bfcp-01.txt   draft-ietf-xcon-bfcp-02.txt 
XCON Working Group G. Camarillo XCON Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: February 17, 2005 J. Ott Expires: April 25, 2005 J. Ott
Universitaet Bremen Universitaet Bremen
K. Drage K. Drage
Lucent Technologies Lucent Technologies
August 19, 2004 October 25, 2004
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-xcon-bfcp-01.txt draft-ietf-xcon-bfcp-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 February 17, 2005. This Internet-Draft will expire on April 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
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 resource in a (multiparty) conferencing environment. Thereby, shared resources in a (multiparty) conferencing environment.
floor control complements other functions -- such as conference and Thereby, floor control complements other functions -- such as
media session setup, conference policy manipulation, and media conference and media session setup, conference policy manipulation,
control -- that are realized by other protocols. and media control -- that are realized by other protocols.
This document specicies the Binary Floor Control Protocol (BFCP). This document specifies the Binary Floor Control Protocol (BFCP).
BFCP is used between conference participants and floor control BFCP is used between floor participants and floor control servers,
servers, and between floor chairs (i.e., moderators) and floor and between floor chairs (i.e., moderators) and floor control
control servers. servers.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Obtaining Information to Contact a BFCP Floor Server . . . 7 3.2 Obtaining Information to Contact a Floor Control Server . 8
3.3 Generating a Shared Secret . . . . . . . . . . . . . . . . 7 3.3 Generating a Shared Secret . . . . . . . . . . . . . . . . 8
3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 7 3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 9
3.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . 8 3.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . 9
4. Overview of Operation . . . . . . . . . . . . . . . . . . . 8 4. Overview of Operation . . . . . . . . . . . . . . . . . . . 10
4.1 User - Floor Control Server Interface . . . . . . . . . . 9 4.1 Floor Participant to Floor Control Server Interface . . . 10
4.2 Floor Chair - Floor Control Server Interface . . . . . . . 11 4.2 Floor Chair to Floor Control Server Interface . . . . . . 13
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 12 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 12 5.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 14
5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 13 5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 16
5.2.1 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.1 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.2 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.2 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.3 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 14 5.2.3 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 17
5.2.4 TRANSACTION-ID . . . . . . . . . . . . . . . . . . . . 15 5.2.4 TRANSACTION-ID . . . . . . . . . . . . . . . . . . . . 18
5.2.5 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 15 5.2.5 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 18
5.2.6 HUMAN-READABLE-INFO . . . . . . . . . . . . . . . . . 15 5.2.6 HUMAN-READABLE-INFO . . . . . . . . . . . . . . . . . 18
5.2.7 INTEGRITY . . . . . . . . . . . . . . . . . . . . . . 16 5.2.7 DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.8 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 16 5.2.8 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 20
5.2.9 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 17 5.2.9 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 21
5.2.10 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 19 5.2.10 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 23
5.2.11 USER-URI . . . . . . . . . . . . . . . . . . . . . . 19 5.2.11 USER-URI . . . . . . . . . . . . . . . . . . . . . . 23
5.2.12 PRIORITY . . . . . . . . . . . . . . . . . . . . . . 19 5.2.12 PRIORITY . . . . . . . . . . . . . . . . . . . . . . 23
6. Message Format . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.13 NONCE . . . . . . . . . . . . . . . . . . . . . . . 23
6.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.14 SUPPORTED-TLVS . . . . . . . . . . . . . . . . . . . 24
6.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . . . 20 5.3 Message Format . . . . . . . . . . . . . . . . . . . . . . 24
6.3 FloorRequestInfo . . . . . . . . . . . . . . . . . . . . . 20 5.3.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . 24
6.4 FloorRequestStatus . . . . . . . . . . . . . . . . . . . . 20 5.3.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . 25
6.5 FloorInfo . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.3 FloorRequestInfoWanted . . . . . . . . . . . . . . . . 25
6.6 FloorStatus . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.4 FloorRequestInfo . . . . . . . . . . . . . . . . . . . 26
6.7 ChairAction . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.5 FloorInfoWanted . . . . . . . . . . . . . . . . . . . 26
6.8 ChairActionAck . . . . . . . . . . . . . . . . . . . . . . 22 5.3.6 FloorInfo . . . . . . . . . . . . . . . . . . . . . . 27
6.9 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.7 ChairAction . . . . . . . . . . . . . . . . . . . . . 27
6.10 PingAck . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.8 ChairActionAck . . . . . . . . . . . . . . . . . . . . 28
6.11 Error . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3.9 Hello . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3.10 HelloAck . . . . . . . . . . . . . . . . . . . . . . 28
8. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 23 5.3.11 Error . . . . . . . . . . . . . . . . . . . . . . . 29
9. Protocol Transactions . . . . . . . . . . . . . . . . . . . 23 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 24 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 30
9.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 24 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . 30
10. Authentication . . . . . . . . . . . . . . . . . . . . . . . 24 8.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 30
10.1 Client Behavior . . . . . . . . . . . . . . . . . . . . 24 8.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 30
10.2 Server Behavior . . . . . . . . . . . . . . . . . . . . 25 9. Authentication and Authorization . . . . . . . . . . . . . . 31
11. Client Operations . . . . . . . . . . . . . . . . . . . . . 25 9.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 31
11.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 25 9.2 Floor Control Server Behavior . . . . . . . . . . . . . . 32
11.1.1 Receiving a Response . . . . . . . . . . . . . . . . 26 10. Floor Participant Operations . . . . . . . . . . . . . . . . 32
12. Requesting Information about Floor Requests . . . . . . . . 27 10.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 33
12.1 Receiving a Response . . . . . . . . . . . . . . . . . . 27 10.1.1 Sending a FloorRequest Message . . . . . . . . . . . 33
13. Cancelling a Floor Request and Releasing a Floor . . . . . . 28 10.1.2 Receiving a Response . . . . . . . . . . . . . . . . 34
13.1 Receiving a Response . . . . . . . . . . . . . . . . . . 28 10.2 Cancelling a Floor Request and Releasing a Floor . . . . 34
14. Requesting Information about Floors . . . . . . . . . . . . 28 10.2.1 Sending a FloorRelease Message . . . . . . . . . . . 34
14.1 Receiving a Response . . . . . . . . . . . . . . . . . . 29 10.2.2 Receiving a Response . . . . . . . . . . . . . . . . 35
15. Checking the Liveness of a Server . . . . . . . . . . . . . 29 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 35
15.1 Receiving Responses . . . . . . . . . . . . . . . . . . 30 11.1 Sending a ChairAction Message . . . . . . . . . . . . . 36
16. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 30 11.2 Receiving a Response . . . . . . . . . . . . . . . . . . 37
16.1 Obtaining Information about Floor Requests . . . . . . . 30 12. General Client Operations . . . . . . . . . . . . . . . . . 37
16.2 Instructing the Floor Control Server . . . . . . . . . . 30 12.1 Requesting Information about Floors . . . . . . . . . . 37
16.2.1 Receiving a Response . . . . . . . . . . . . . . . . 31 12.1.1 Sending a FloorInfoWanted Message . . . . . . . . . 37
17. Server Operations . . . . . . . . . . . . . . . . . . . . . 32 12.1.2 Receiving a Response . . . . . . . . . . . . . . . . 38
17.1 Reception of a FloorRequest Message . . . . . . . . . . 32 12.2 Requesting Information about Floor Requests . . . . . . 38
17.2 Reception of a FloorRequestInfo Message . . . . . . . . 33 12.2.1 Sending a FloorRequestInfoWanted Message . . . . . . 39
17.3 Reception of a FloorRelease Message . . . . . . . . . . 33 12.2.2 Receiving a Response . . . . . . . . . . . . . . . . 40
17.4 Reception of a FloorInfo Message . . . . . . . . . . . . 34 12.3 Obtaining the Capabilities of a Floor Control Server . . 40
17.5 Reception of a ChairAction Message . . . . . . . . . . . 35 12.3.1 Sending a Hello Message . . . . . . . . . . . . . . 40
17.6 Reception of a Ping Message . . . . . . . . . . . . . . 35 12.3.2 Receiving Responses . . . . . . . . . . . . . . . . 40
17.7 Error Message Generation . . . . . . . . . . . . . . . . 36 13. Floor Control Server Operations . . . . . . . . . . . . . . 41
18. BFCP and the Offer/Answer Model . . . . . . . . . . . . . . 36 13.1 Reception of a FloorRequest Message . . . . . . . . . . 41
18.1 Fields in the m Line . . . . . . . . . . . . . . . . . . 36 13.1.1 Generating the First FloorRequestInfo Message . . . 42
18.2 The confid and userid SDP Parameters . . . . . . . . . . 37 13.1.2 Generation of Subsequent FloorRequestInfo Messages . 42
18.3 The k line . . . . . . . . . . . . . . . . . . . . . . . 37 13.2 Reception of a FloorRequestInfoWanted Message . . . . . 43
18.4 TCP Connection Management . . . . . . . . . . . . . . . 37 13.2.1 Information on a Single Floor Request . . . . . . . 44
18.5 Association between Streams and Floors . . . . . . . . . 38 13.2.2 Information on the Floor Requests Associated to a
18.6 Example . . . . . . . . . . . . . . . . . . . . . . . . 38 Participant . . . . . . . . . . . . . . . . . . . . 44
19. Security Considerations . . . . . . . . . . . . . . . . . . 39 13.3 Reception of a FloorRelease Message . . . . . . . . . . 45
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39 13.4 Reception of a FloorInfoWanted Message . . . . . . . . . 45
20.1 SDP Attributes Registration . . . . . . . . . . . . . . 39 13.4.1 Generation of the First FloorInfo Message . . . . . 46
21. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 39 13.4.2 Generation of Subsequent FloorInfo Messages . . . . 47
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 13.5 Reception of a ChairAction Message . . . . . . . . . . . 47
22.1 Normative References . . . . . . . . . . . . . . . . . . . 39 13.6 Reception of a Hello Message . . . . . . . . . . . . . . 48
22.2 Informational References . . . . . . . . . . . . . . . . . 40 13.7 Error Message Generation . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 14. Security Considerations . . . . . . . . . . . . . . . . . . 49
Intellectual Property and Copyright Statements . . . . . . . 42 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 49
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
17.1 Normative References . . . . . . . . . . . . . . . . . . . 49
17.2 Informational References . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 51
Intellectual Property and Copyright Statements . . . . . . . 52
1. Introduction 1. Introduction
Within a (multimedia) conference, some applications (e.g., conference Within a conference, some applications need to manage the access to a
applications) need to manage the access to a set of shared resources, set of shared resources, such as the right to send media over a
such as the right to send media over a particular media stream. particular media stream. Floor control enables such applications to
Floor control enables such applications to provide users with provide users with coordinated (shared or exclusive) access to these
coordinated (shared or exclusive) access to these resources. resources.
The Requirements for Floor Control Protocol [15] list a set of The Requirements for Floor Control Protocol [9] 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.
Section 2 defines the terminology used throughout this document and The remainder of this document is organized as follows. Section 2
Section 3 discusses the scope of BFCP (i.e., which tasks fall within defines the terminology used throughout this document and Section 3
the scope of BFCP and which ones are performed using different discusses the scope of BFCP (i.e., which tasks fall within the scope
mechanisms). Section 4 provides a non-normative overview of BFCP of BFCP and which ones are performed using different mechanisms).
operation and subsequent sections provide the normative specification Section 4 provides a non-normative overview of BFCP operation and
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
of a conference (e.g., it can receive a media stream). In
floor-controlled conferences, a given media participant is typically
co-located with a floor participant, but does not need to.
Third-party floor requests consist of having a floor participant
request a floor for a media participant when they are not co-located.
Client: a floor participant or a floor chair that communicate with a
floor control server using BFCP.
Conference Policy: The complete set of rules for a particular Conference Policy: The complete set of rules for a particular
conference manipulated by the conference policy server. It includes conference manipulated by the conference policy server. It includes
the membership policy and the media policy. There is an instance of the membership policy and the media policy. There is an instance of
conference policy for each conference. conference policy for each conference.
Conference Policy Control Protocol (CPCP): The protocol used by Conference Policy Control Protocol (CPCP): The protocol used by
clients to manipulate the conference policy. clients to manipulate the conference policy.
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 user (or an entity) who manages one floor (grants, Floor Chair: A logical entity that manages one floor (grants, denies,
denies, or revokes a floor). The floor chair does not have to be a or revokes a floor). An entity that assumes the logical role of a
member in a conference. floor chair for a given transaction may assume a different role
(e.g., floor participant) for a different transaction. The roles of
floor chair and floor participant are defined on a
transaction-by-transaction basis.
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. at the floor control server. The floor control server of a
conference may perform other logical roles (e.g., floor participant)
in another conference.
Floor Participant: A logical entity that requests floors, and
possibly information about them, from a floor control server. An
entity that assumes the logical role of a floor participant for a
given transaction may assume a different role (e.g., a floor chair)
for a different transaction. The roles of floor participant and
floor chair are defined on a transaction-by-transaction basis. In
floor-controlled conferences, a given floor participant is typically
co-located with a media participant, but does not need to.
Third-party floor requests consist of having a floor participant
request a floor for a media participant when they are not co-located.
Media Policy: A set of rules manipulated by the conference policy Media Policy: A set of rules manipulated by the conference policy
server regarding the media composition of the conference. The media server regarding the media composition of the conference. The media
policy is used by the focus to determine the mixing characteristics policy is used by the focus to determine the mixing characteristics
for the conference. The media policy includes rules about which for the conference. The media policy includes rules about which
participants receive media from which other participants, and the conference participants receive media from which other participants,
ways in which that media is combined for each participant. In the and the ways in which that media is combined for each conference
case of audio, these rules can include the relative volumes at which participant. In the case of audio, these rules can include the
each participant is mixed. In the case of video, these rules can relative volumes at which each conference participant is mixed. In
indicate whether the video is tiled, whether the video indicates the the case of video, these rules can indicate whether the video is
loudest speaker, and so on. tiled, whether the video indicates the loudest speaker, and so on.
EDITOR'S NOTE: we may want to reference the definitions in the Participant: An entity that acts as a floor participant, as a media
conferencing framework. If we decide to copy them here, we need to participant, or as both.
make sure that we copy all the definitions we use in this document.
3. Scope 3. Scope
As stated above, the BFCP is a protocol to coordinate access to As stated earlier, the BFCP is a protocol to coordinate access to
shared resources in a conference setting following the requirements shared resources in a conference following the requirements defined
defined in [15]. Floor control complements other functions defined in [9]. Floor control complements other functions defined in the
in the conference framework, such as conference policy and media conferencing framework [14], such as conference policy and media
policy. In particular, it is the conference policy that defines policy. In particular, it is the conference policy that defines
which media streams and applications are floor-controlled, who is/are which media streams and applications are floor-controlled, who is/are
the respective floor chair(s), and how access to the floor is the respective floor chair(s), and how access to the floor is
managed. Furthermore, it is up to the media policy to define which managed. Furthermore, it is up to the media policy to define which
(if any) impact on media stream handling (e.g. switching or mixing) (if any) impact on media stream handling (e.g. switching or mixing)
assignment of a floor to a participant has. assignment of a floor to a media participant has.
The floor control protocol BFCP defined in this document only The floor control protocol BFCP defined in this document only
specifies a means to arbitrate access to floors. The rules and specifies a means to arbitrate access to floors. The rules and
constraints for floor arbitration and the results of floor constraints for floor arbitration and the results of floor
assignments are outside the scope of this document and defined by the assignments are outside the scope of this document and defined by the
conference and media policy, respectively. conference and media policy, respectively.
Figure 1 shows the tasks that BFCP can perform. Figure 1 shows the tasks that BFCP can perform.
+---------+ +---------+
| Floor | | Floor |
| Chair | | Chair |
| | | |
+---------+ +---------+
^ | ^ |
| | | |
Notification | | Decision Notification | | Decision
| | | |
| | | |
Floor | v Floor | v
+---------+ Request +---------+ +---------+ +-------------+ Request +---------+ +-------------+
| |----------->| Floor | Notification | | | Floor |----------->| Floor | Notification | Floor |
| User | | Control |------------->| User | | Participant | | Control |------------->| Participant |
| |<-----------| Server | | | | |<-----------| Server | | |
+---------+ Granted or +---------+ +---------+ +-------------+ Granted or +---------+ +-------------+
Denied Denied
Figure 1: Functionality provided by BFCP Figure 1: Functionality provided by BFCP
BFCP provides a means: BFCP provides a means:
o for users to send floor requests to floor control servers. o for floor participants to send floor requests to floor control
servers.
o for floor control servers to grant or deny requests to access a o for floor control servers to grant or deny requests to access a
given resource from users. given resource from floor participants.
o for floor chairs to send floor control servers decisions regarding o for floor chairs to send floor control servers decisions regarding
floor requests. floor requests.
o for floor control servers to keep users and floor chairs informed o for floor control servers to keep floor participants and floor
about the status of a given floor. chairs informed about the status of a given floor or a given floor
request.
Even though tasks that do not belong to the previous list are outside Even though tasks that do not belong to the previous list are outside
the scope of BFCP, some of these out-of-scope tasks relate to floor 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 conference policy for a particular conference contains the floors The conference policy for a particular conference contains the floors
of the conference and the resource or resources associated with each of the conference and the resource or resources associated with each
floor. For example, a conference may have two floors: one floor. For example, a conference may have two floors: one
controlling who can talk at a particular time and another controlling controlling who can talk at a particular time and another controlling
who can write on a shared whiteboard. who can write on a shared whiteboard.
According to the definitions in Section 2, the conference policy is According to the definitions in Section 2, the conference policy is
manipulated using a Conference Policy Control Protocol (CPCP), such manipulated using a Conference Policy Control Protocol (CPCP), such
as [16]. Consequently, floor creation and termination is handled by as the one defined in [10]. Consequently, floor creation and
CPCP. In addition, CPCP also handles the association of a given termination is handled by CPCP. In addition, CPCP also handles the
floor with a resource or a set of resources (e.g., media streams). association of a given floor with a resource or a set of resources
(e.g., media streams).
Additionally, the floor control server needs to stay up to date on Additionally, the floor control server needs to stay up to date on
changes on the conference policy (e.g., when a new floor is created). changes on the conference policy (e.g., when a new floor is created).
The floor control may use a mechanism such as the XCAP event package The floor control may use a mechanism such as the one defined in [13]
[19] to keep itself up to date. to keep itself up to date.
3.2 Obtaining Information to Contact a BFCP Floor Server 3.2 Obtaining Information to Contact a Floor Control Server
A user or a floor chair needs a set of data in order to establish a A client needs a set of data in order to establish a BFCP connection
BFCP connection to a floor control server. These data include the to a floor control server. These data include the transport address
transport address of the server, the conference identifier, and the of the server, the conference identifier, and the user identifier.
user identifier.
Users can obtain this information in different ways. Two Clients can obtain this information in different ways. Two
possibilities are using CPCP and using the offer/answer [11] exchange possibilities are using CPCP and using an offer/answer [8] exchange.
which is used to establish media streams between the user and the How to use an SDP [6] offer/answer [8] exchange to obtain this
conference server. Section 18 discusses how to use an SDP [5] offer/ information is described in [15].
answer [11] exchange to obtain this information.
3.3 Generating a Shared Secret 3.3 Generating a Shared Secret
Authentication and integrity protection in BFCP are based on a shared Authentication in BFCP is based on a shared secret between the client
secret between the user or floor chair, and the floor control server. and the floor control server. So, there is a need for a mechanism to
So, there is a need for a mechanism to generate such a shared secret. generate such a shared secret.
When the user or the floor control chair obtains a the information When the floor participant or the floor chair obtains the information
needed to contact the BFCP floor server over a secure channel (e.g., needed to contact the BFCP floor control server over a secure channel
an offer/answer exchange using SIP [10] protected using S/MIME), they (e.g., an offer/answer [8] exchange using SIP [7] protected using S/
can get the shared secret using the same channel. MIME), they can get the shared secret using the same channel.
If there is no secure channel available, a different mechanism needs If there is no secure channel available, a different mechanism needs
to be used. For example, MIKEY [18] allows an offerer and an to be used. For example, MIKEY [12] allows an offerer and an
answerer to perform a Diffie-Hellman key exchange. answerer to perform a Diffie-Hellman key exchange.
Editor's note: Probably need to mention TLS as another mechanism Shared secrets can also be generated and exchanged using out-of-band
here. means.
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, which is manipulated using CPCP. are part of the conference policy, which is manipulated using CPCP.
Users and floor chairs need to know which resources are associated Floor participants and floor chairs need to know which resources are
with which floors. They can obtain this information using different associated with which floors. They can obtain this information using
mechanisms, such as CPCP or an offer/answer [11] exchange. Section different mechanisms, such as CPCP or an offer/answer [8] exchange.
18 describes how to use an offer/answer exchange to obtain these How to use an offer/answer exchange to obtain these associations is
associations. described in [15].
Note that users perform offer/answer exchanges with the SIP focus Note that floor participants perform offer/answer exchanges with
of the conference. So, the SIP focus needs to obtain information the SIP focus of the conference. So, the SIP focus needs to
about associations between floors and resources using a mechanism obtain information about associations between floors and resources
such as CPCP in order to be able to provide this information to a using a mechanism such as CPCP in order to be able to provide this
user in an offer/answer exchange. information to a floor participant in an offer/answer exchange.
3.5 Policy Enforcement 3.5 Policy Enforcement
A user whose floor request is granted has the right to use in a A participant whose floor request is granted has the right to use (in
certain way the resource or resources associated with the floor that a certain way) the resource or resources associated with the floor
was requested. For example, the user may have the right to talk that was requested. For example, the participant may have the right
(i.e., 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. According to the definition in
Section 2, the media policy of a conference is the one that Section 2, the media policy of a conference is the one that
determines which users can actually use the resources in the determines which media participants can actually use the resources in
conference. the conference.
So, if the policy of a conference is to enforce floor control So, if the policy of a conference is to enforce floor control
decisions, every change in the status of any floor needs to be decisions, every change in the status of any floor needs to be
reflected in the media policy of the conference. For example, the reflected in the media policy of the conference. For example, the
mixer only accepts media from the user who holds the floor. mixer only accepts media from the user who holds the floor.
A way to reflect the status of the floors in the media policy is to A way to reflect the status of the floors in the media policy is to
have the floor control server manipulate the media policy using CPCP. have the floor control server manipulate the media policy using CPCP.
Nevertheless, there are other ways to enforce floor control policies, Nevertheless, there are other ways to enforce floor control policies,
such as having a floor control chair manipulate the media policy such as having a floor control chair manipulate the media policy
(using CPCP) only if there are misbehaving users trying to use a (using CPCP) only if there are misbehaving users trying to use a
resource without holding its associated floor. resource without holding its associated 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 users and floor control Section 4.1 describes the interface between floor participants and
servers and Section 4.2 describes the interface between floor chairs floor control servers and Section 4.2 describes the interface between
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 TLVs. The common
header contains, among other information, a 32-bit conference header contains, among other information, a 32-bit conference
identifier. Users and floor chairs are identified by a 16-bit user identifier. Floor participants, media participants, and floor chairs
identifier, which is carried in a TLV. are identified by a 16-bit user identifier, which is carried in a
TLV.
4.1 User - Floor Control Server Interface There are two types of transactions in BFCP: client-initiated
transactions and server-initiated transactions. Client-initiated
transactions consist of a message from a client to the floor control
server and a response from the floor control server to the client.
Both messages can be related because they carry the same
TRANSACTION-ID TLV. Server-initiated transactions consist of a
single message, which has no TRANSACTION-ID TLV, from the floor
control server to a client.
Users request a floor by sending a FloorRequest message to the floor 4.1 Floor Participant to Floor Control Server Interface
control server. BFCP supports third party floor requests. That is,
the user sending the floor request need not be the same as the user
who will get the 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 beneficiary of the floor, in
third party floor requests, in a BENEFICIARY-ID TLV.
Third party floor requests can be sent by users that have a BFCP Floor participants request a floor by sending a FloorRequest message
connection to the floor control server, but who are not conference to the floor control server. BFCP supports third-party floor
participants (i.e., they do not handle any media). requests. That is, the floor participant sending the floor request
need not be co-located with the media participant that will get the
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 beneficiary of the floor, in third party floor requests, in a
BENEFICIARY-ID TLV.
Third party floor requests can be sent, for example, by floor
participants that have a BFCP connection to the floor control
server but that are not media participants (i.e., they do not
handle any media).
FloorRequest messages identify the floor or floors being requested by 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 TLVs. 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.
EDITOR'S NOTE: we need to explain in this paragraph that if a user is
anonymous, the floor control server does not disclose the identity of
the requester of the floor to the rest of the users and floor chairs.
Floor control servers respond to FloorRequest messages with Floor control servers respond to FloorRequest messages with
FloorStatus messages. FloorRequestInfo messages, which provide information about the status
of the floor request. The first FloorRequestInfo message is the
response to the FloorRequest message from the client, and therefore
carries the same TRANSACTION-ID TLV as the FloorRequest.
Editor's note: This section will be finished when we have agreed on Additionally, the first FloorRequestInfo message carries a
what it is specified in the rest of this document. For the time FLOOR-REQUEST-ID TLV. Subsequent FloorRequestInfo messages related
being, below there are two typical call flows: a client requesting a to the same floor request will carry the same FLOOR-REQUEST-ID TLV.
floor and a client requesting information about a floor. This way, the floor participant can associate them with the
appropriate floor request.
Client Floor Control Messages from the floor participant related to a particular floor
Server request also use the same FLOOR-REQUEST-ID TLV as the first
FloorRequestInfo Message from the floor control server.
| FloorRequest | Figure 2 shows how a floor participant requests a floor, obtains it,
and, at a later time, releases it. This figure illustrates the use,
among other TLVs, of the TRANSACTION-ID and the FLOOR-REQUEST-ID
TLVs.
Floor Participant Floor Control
Server
|(1) FloorRequest |
| TRANSACTION-ID: 123 | | TRANSACTION-ID: 123 |
|----------------------------->| |USER-ID: 234 |
| | |FLOOR-ID: 543 |
| FloorRequestStatus | |---------------------------------------------->|
|(2) FloorRequestInfo |
| TRANSACTION-ID: 123 | | TRANSACTION-ID: 123 |
| FLOOR-REQUEST-ID: 345 | |USER-ID: 234 |
|FLOOR-REQUEST-ID: 789 |
|FLOOR-ID: 543 |
| REQUEST-STATUS: Pending | | REQUEST-STATUS: Pending |
|<-----------------------------| |<----------------------------------------------|
| | |(3) FloorRequestInfo |
| FloorRequestStatus | |USER-ID: 234 |
| FLOOR-REQUEST-ID: 345 | |FLOOR-REQUEST-ID: 789 |
| REQUEST-STATUS: Accepted | |FLOOR-ID: 543 |
|<-----------------------------| |REQUEST-STATUS: Accepted (1st in Queue) |
| | |<----------------------------------------------|
| | |(4) FloorRequestInfo |
| FloorRequestStatus | |USER-ID: 234 |
| FLOOR-REQUEST-ID: 345 | |FLOOR-REQUEST-ID: 789 |
|FLOOR-ID: 543 |
| REQUEST-STATUS: Granted | | REQUEST-STATUS: Granted |
|<-----------------------------| |<----------------------------------------------|
| | |(5) FloorRelease |
| | |TRANSACTION-ID: 154 |
| FloorRelease | |USER-ID: 234 |
| TRANSACTION-ID: 124 | |FLOOR-REQUEST-ID: 789 |
| FLOOR-REQUEST-ID: 345 | |---------------------------------------------->|
|----------------------------->| |(6) FloorRequestInfo |
| | |TRANSACTION-ID: 154 |
| FloorRequestStatus | |USER-ID: 234 |
| TRANSACTION-ID: 124 | |FLOOR-REQUEST-ID: 789 |
| FLOOR-REQUEST-ID: 345 | |FLOOR-ID: 543 |
| REQUEST-STATUS: Released | | REQUEST-STATUS: Released |
|<-----------------------------| |<----------------------------------------------|
| |
Figure 2: Requesting and releasing a floor Figure 2: Requesting and releasing a floor
Client or Floor Control
Chair Server
| FloorInfo | Figure 2 shows how a floor participant requests to be informed on the
| TRANSACTION-ID: 123 | status of a floor. The first FloorInfo message from the floor
| FLOOR-ID: 15 | control server is the response to the FloorInfoWanted message, and as
|----------------------------->| such, carries the same TRANSACTION-ID TLV as the FloorInfoWanted
| | message.
|FloorStatus |
| TRANSACTION-ID: 123 | Subsequent FloorInfo messages consist of server-initiated
| FLOOR-ID: 15 | transactions, and therefore carry no TRANSACTION-ID TLV. FloorInfo
| FLOOR-REQUEST-ID: 345 | message (2) indicates that there are currently two floor requests for
the floor whose Floor ID is 543. FloorInfo message (3) indicates
that the floor requests with Floor Request ID 764 has been granted,
while the floor request with Floor Request ID 635 is the first in the
queue. FloorInfo message (4) indicates that the floor request with
Floor Request ID 635 has been granted.
Floor Participant Floor Control
Server
|(1) FloorInfoWanted |
|TRANSACTION-ID: 257 |
|USER-ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
|(2) FloorInfo |
|TRANSACTION-ID: 257 |
|USER-ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-ID: 764 |
|FLOOR-ID: 543 |
|BENEFICIARY-ID: 124 |
|REQUEST-STATUS: Accepted (1st in Queue) |
|FLOOR-REQUEST-ID: 635 |
|BENEFICIARY-ID: 154 |
|FLOOR-ID: 543 |
|REQUEST-STATUS: Accepted (2nd in Queue) |
|<----------------------------------------------|
|(3) FloorInfo |
|USER-ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-ID: 764 |
|FLOOR-ID: 543 |
|BENEFICIARY-ID: 124 |
| REQUEST-STATUS: Granted | | REQUEST-STATUS: Granted |
| FLOOR-REQUEST-ID: 348 | |FLOOR-REQUEST-ID: 635 |
| REQUEST-STATUS: 1st in queue| |BENEFICIARY-ID: 154 |
|<-----------------------------| |FLOOR-ID: 543 |
| | |REQUEST-STATUS: Accepted (1st in Queue) |
|FloorStatus | |<----------------------------------------------|
| FLOOR-ID: 15 | |(4) FloorInfo |
| FLOOR-REQUEST-ID: 348 | |USER-ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-ID: 635 |
|BENEFICIARY-ID: 154 |
|FLOOR-ID: 543 |
| REQUEST-STATUS: Granted | | REQUEST-STATUS: Granted |
|<-----------------------------| |<----------------------------------------------|
| |
|FloorStatus |
| FLOOR-ID: 15 |
|<-----------------------------|
| |
Figure 3: Obtaining status information about a floor Figure 3: Obtaining status information about a floor
4.2 Floor Chair - Floor Control Server Interface FloorInfo messages contain information about the floor requests they
carry. For example, FloorInfo message (4) indicates that the floor
request with Floor Request ID 635 has as the beneficiary (i.e., the
participant that holds the floor when a particular floor request is
granted) the participant whose User ID is 154. The floor request
applies only to the floor whose Floor ID is 543. That is, this is
not a multi-floor floor request.
TBD. For the time being, below there is the typical call flow for 4.2 Floor Chair to Floor Control Server Interface
this interface.
Chair Floor Control Figure 4 shows a floor chair instructing a floor control server to
Server grant a floor. Note, however, that although the floor control server
needs to take into consideration the instructions received in
ChairAction messages (e.g., granting a floor), it does not
necessarily need to perform them exactly as requested by the floor
chair. The operation that the floor control server performs depends
on the ChairAction message and on the internal state of the floor
control server.
| ChairAction | For example, a floor chair may send a ChairAction message granting a
| TRANSACTION-ID: 123 | floor which was requested as part of an atomic floor request
| FLOOR-ID: 15 | operation that involved several floors. Even if the chair
| FLOOR-REQUEST-ID: 345 | responsible for one of the floors instructs the floor control server
to grant the floor, the floor control server will not grant it until
the chairs responsible for the other floors agree to grant them as
well. In another example, a floor chair may instruct the floor
control server to grant a floor to a participant. The floor control
server needs to revoke the floor from its current holder before
granting it to the new participant.
So, the floor control server is ultimately responsible to keep a
coherent floor state using instructions from floor chairs as input to
this state.
Floor Chair Floor Control
Server
|(1) ChairAction |
|TRANSACTION-ID: 769 |
|USER-ID: 357 |
|FLOOR-ID: 543 |
|FLOOR-REQUEST-ID: 635 |
| REQUEST-STATUS: Granted | | REQUEST-STATUS: Granted |
|----------------------------->| |---------------------------------------------->|
| | |(2) ChairActionAck |
| ChairActionAck | |TRANSACTION-ID: 769 |
| TRANSACTION-ID: 123 | |USER-ID: 357 |
|<-----------------------------| |<----------------------------------------------|
| |
Figure 4: Chair invoking an action at 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.
5.1 FIXED-HEADER Format 5.1 FIXED-HEADER Format
The following is the FIXED-HEADER format. The following is the FIXED-HEADER format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |Reserved | Primitive | Payload Length | | Ver |Reserved | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID | | Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: FIXED-HEADER format
Ver: the 3-bit version field MUST be set to 1 to indicate this Ver: the 3-bit version field MUST be set to 1 to indicate this
version of BFCP. version of BFCP.
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 C -> S +-------+------------------------+-----------------------+
1 FloorRelease C -> S | 0 | FloorRequest | P -> S |
2 FloorRequestInfo S -> C ; Ch -> S | 1 | FloorRelease | P -> S |
3 FloorRequestStatus S -> C | 2 | FloorRequestInfoWanted | P -> S ; Ch -> S |
4 FloorInfo C -> S ; Ch -> S | 3 | FloorRequestInfo | P <- S ; Ch <- S |
5 FloorStatus S -> C ; S -> Ch | 4 | FloorInfoWanted | P -> S ; Ch -> S |
6 ChairAction Ch -> S | 5 | FloorInfo | P <- S ; Ch <- S |
7 ChairActionAck S -> Ch | 6 | ChairAction | Ch -> S |
8 Ping C -> S ; Ch <-> S | 7 | ChairActionAck | Ch <- S |
9 PingAck S -> C ; Ch <-> S | 8 | Hello | P -> S ; Ch -> S |
10 Error S -> C ; S -> Ch | 9 | HelloAck | P <- S ; Ch <- S |
| 10 | Error | P <- S ; Ch <- S |
+-------+------------------------+-----------------------+
S: Server C: Client Ch: Chair S: Floor Control Server
P: Floor Participant
Ch: Floor Chair
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 identifies the conference the message
belongs to. 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. TLVs
skipping to change at page 13, line 43 skipping to change at page 16, line 21
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 /
/ / / /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: this 7-bit field contains the code for the attribute. Figure 6: TLV format
Type: this 7-bit field contains the type of the attribute. The
following attribute types are defined:
+------+---------------------+
| Type | Attribute |
+------+---------------------+
| 0 | FLOOR-ID |
| 1 | USER-ID |
| 2 | BENEFICIARY-ID |
| 3 | TRANSACTION-ID |
| 4 | FLOOR-REQUEST-ID |
| 5 | HUMAN-READABLE-INFO |
| 6 | DIGEST |
| 7 | REQUEST-STATUS |
| 8 | ERROR-CODE |
| 9 | USER-DISPLAY-NAME |
| 10 | USER-URI |
| 11 | PRIORITY |
| 12 | NONCE |
| 13 | SUPPORTED-TLVS |
+------+---------------------+
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.
Attribute Contents: the contents of the different TLVs are defined in Attribute Contents: the contents of the different TLVs are defined in
the following sections. the following sections.
5.2.1 FLOOR-ID 5.2.1 FLOOR-ID
The following is the format of the contents of the FLOOR-ID The following is the format of the FLOOR-ID attribute.
attribute, whose attribute type is 1.
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 = 1 |M| Length | Floor ID | |0 0 0 0 0 0 0|M|0 0 0 0 0 1 0 0| Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FLOOR-ID format
Floor ID: this field contains a 16-bit value that uniquely identifies Floor ID: this field contains a 16-bit value that uniquely identifies
a floor within a conference. a floor within a conference.
5.2.2 USER-ID 5.2.2 USER-ID
The following is the format of the contents of the USER-ID attribute, The following is the format of the USER-ID attribute.
whose attribute type is 2.
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 = 2 |M| Length | User ID | |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: USER-ID format
User ID: this field contains a 16-bit value that uniquely identifies User ID: this field contains a 16-bit value that uniquely identifies
a user within a conference. a user within a conference.
5.2.3 BENEFICIARY-ID 5.2.3 BENEFICIARY-ID
The following is the format of the contents of the BENEFICIARY-ID The following is the format of the BENEFICIARY-ID attribute.
attribute, whose attribute type is 2.
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 = 2 |M| Length | Beneficiary ID | |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: BENEFICIARY-ID format
Beneficiary ID: this field contains a 16-bit value that uniquely Beneficiary ID: this field contains a 16-bit value that uniquely
identifies a user within a conference. identifies a user within a conference.
5.2.4 TRANSACTION-ID 5.2.4 TRANSACTION-ID
The following is the format of the contents of the TRANSACTION-ID The following is the format of the TRANSACTION-ID attribute.
attribute, whose attribute type is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 |M| Length | Transaction ID | |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TRANSACTION-ID format
Transaction ID: this field contains a 16-bit value that allows users Transaction ID: this field contains a 16-bit value that allows users
to match a given message with its response. to match a given message with its response.
5.2.5 FLOOR-REQUEST-ID 5.2.5 FLOOR-REQUEST-ID
The following is the format of the contents of the FLOOR-REQUEST-ID The following is the format of the FLOOR-REQUEST-ID attribute.
attribute, whose attribute type is 4.
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 = 3 |M| Length | Floor Request ID | |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0| Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: FLOOR-REQUEST-ID format
Floor Request ID: this field contains a 16-bit value that indentifies Floor Request ID: this field contains a 16-bit value that indentifies
a floor request at the floor control server. a floor request at the floor control server.
5.2.6 HUMAN-READABLE-INFO 5.2.6 HUMAN-READABLE-INFO
The following is the format of the contents of the The following is the format of the HUMAN-READABLE-INFO attribute.
HUMAN-READABLE-INFO attribute, whose attribute type is 5.
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 = 4 |M| Length | | |0 0 0 0 1 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Text: this field contains UTF-8 [13] encoded text.
Figure 12: HUMAN-READABLE-INFO format
Text: this field contains UTF-8 [5] encoded text.
In some situations, the contents of the Text field may be generated In some situations, the contents of the Text field may be generated
by an automaton. If such automaton has information about the by an automaton. If such automaton has information about the
preferred language of the receiver of a particular preferred language of the receiver of a particular
HUMAN-READABLE-INFO TLV, it MAY use this language to generate the HUMAN-READABLE-INFO TLV, it MAY use this language to generate the
Text field. Text field.
Padding: one, two, or three bytes of padding added so that the Padding: one, two, or three bytes of padding added so that the
contents of the HUMAN-READABLE-INFO TLV is 32-bit aligned. The contents of the HUMAN-READABLE-INFO TLV is 32-bit aligned. The
Padding bits SHOULD be set to zero by the sender and MUST be ignored Padding bits SHOULD be set to zero by the sender and MUST be ignored
by the receiver. If the TLV is already 32-bit aligned, no padding is by the receiver. If the TLV is already 32-bit aligned, no padding is
needed. needed.
5.2.7 INTEGRITY 5.2.7 DIGEST
The following is the format of the contents of the INTEGRITY The following is the format of the DIGEST attribute.
attribute, whose attribute type is 6.
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 = 5 |M| Length | | |0 0 0 0 1 1 0|M|0 0 0 1 1 0 0 0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
+ + + +
| | | |
+ HMAC-SHA1 + + HMAC-SHA1 +
| | | |
+ + + +
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: DIGEST format
HMAC-SHA1: this 20-byte field contains an HMAC-SHA1 [1] of the BFCP HMAC-SHA1: this 20-byte field contains an HMAC-SHA1 [1] of the BFCP
message. Its calculation is described in Section 10. message. Its calculation is described in Section 9.
Padding: two bytes of padding added so that the contents of the 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 HMAC-SHA1 TLV is 32-bit aligned. The Padding bits SHOULD be set to
zero by the sender and MUST be ignored by the receiver. zero by the sender and MUST be ignored by the receiver.
5.2.8 REQUEST-STATUS 5.2.8 REQUEST-STATUS
The following is the format of the contents of the REQUEST-STATUS The following is the format of the REQUEST-STATUS attribute.
attribute, whose attribute type is 7.
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 = 6 |M| Length | Request Status | |0 0 0 0 1 1 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Queue Position | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request Status: this 16-bit field contains the status of the request, Figure 14: REQUEST-STATUS format
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 Accepted | 0 | Pending |
2 Granted | 1 | Accepted |
3 Denied | 2 | Granted |
4 Cancelled | 3 | Denied |
5 Released | 4 | Cancelled |
6 Revoked | 5 | Released |
7 Replaced | 6 | Revoked |
+-------+-----------+
Queue Position: this 16-bit field contains, when applicable, the Table 3: Request Status values
Queue Position: this 8-bit field contains, when applicable, the
position of the floor request in the floor request queue at the 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.
Padding: two bytes of padding added so that the contents of the
REQUEST-STATUS TLV is 32-bit aligned. The Padding bits SHOULD be set
to zero by the sender and MUST be ignored by the receiver.
5.2.9 ERROR-CODE 5.2.9 ERROR-CODE
The following is the format of the contents of the ERROR-CODE The following is the format of the ERROR-CODE attribute.
attribute, whose attribute type is 8.
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 = 7 |M| Length | Error Code | |0 0 0 1 0 0 0|M| Length | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Error Specific Details | | Error Specific Details |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ERROR-CODE format
Error Code: this 16-bit field contains an error code from the Error Code: this 16-bit field contains an error code from the
following table. following table.
Value Meaning +---------------------------------+---------------------------------+
__________________________________________________________ | Value | Meaning |
0 Conference does not Exist +---------------------------------+---------------------------------+
1 Authentication Failed | 0 | Conference does not Exist |
2 Unknown Mandatory TLV | 1 | Authentication Failed |
3 Floor Request ID Does Not Exist | 2 | Unknown Mandatory TLV |
4 Unauthorized Operation | 3 | Floor Request ID Does Not Exist |
5 User does not Exist | 4 | Unauthorized Operation |
6 Invalid Request-ID | 5 | User does not Exist |
7 INTEGRITY TLV Required | 6 | Invalid Nonce |
| 7 | DIGEST TLV Required |
| 8 | Invalid Floor ID |
| 9 | You have Already Reached the |
| | Maximum Number of Ongoing Floor |
| | Requests for this Floor |
+---------------------------------+---------------------------------+
Table 4: 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 2 (Unknown Mandatory TLV). For
Error Code 2, this field contains the Types of the TLVs (which were Error Code 2, this field contains the Types of the TLVs (which were
present in the message that triggered the Error message) that were present in the message that triggered the Error message) that were
unknown to the receiver, encoded as follows. unknown to the receiver, encoded as follows.
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 | | Unknown TLV Type | Unknown TLV Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Unknown TLV Type | | | Unknown TLV Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown TLV Type | | Unknown TLV Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Unknown TLVs format
Padding: one, two, or three bytes of padding added so that the Padding: one, two, or three bytes of padding added so that the
contents of the ERROR-CODE TLV is 32-bit aligned. If the TLV is contents of the ERROR-CODE TLV is 32-bit aligned. If the TLV is
already 32-bit aligned, no padding is needed. 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. Note all the Error Codes defined in this 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 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 aligned (i.e., no need of padding). Error Code 2 results in a TLV
that may need 2 bytes of padding. that may need 2 bytes of padding.
5.2.10 USER-DISPLAY-NAME 5.2.10 USER-DISPLAY-NAME
The USER-DISPLAY-NAME attribute type is 9 and its format is the same The format of the USER-DISPLAY-NAME attribute is the same as the
as the HUMAN-READABLE-INFO attribute. The Text field in the HUMAN-READABLE-INFO attribute (still, they have different attribute
USER-DISPLAY-NAME attribute contains the name of the user. types). The Text field in the USER-DISPLAY-NAME attribute contains
the name of the user.
5.2.11 USER-URI 5.2.11 USER-URI
The USER-URI attribute type is 10 and its format is the same as the The format of the USER-URI attribute is the same as the
HUMAN-READABLE-INFO attribute. The Text field in the USER-URI HUMAN-READABLE-INFO attribute (still, they have different attribute
attribute contains the URI of the user. types). The Text field in the USER-URI attribute contains the URI of
the user.
5.2.12 PRIORITY 5.2.12 PRIORITY
The following is the format of the contents of the PRIORITY The following is the format of the PRIORITY attribute.
attribute, whose attribute type is 11.
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 = 7 |M| Length | Priority | Reserved | |0 0 0 1 0 1 1|M|0 0 0 0 0 1 0 0| Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: PRIORITY format
Priority: the higher the 8-bit value, the more priority is requested Priority: the higher the 8-bit value, the more priority is requested
for a given floor request. for a given floor request.
Reserved: at this point, the 8 bits in the reserved field SHOULD be Reserved: at this point, the 8 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.
6. Message Format 5.2.13 NONCE
This section contains the ABNF [3] of the BFCP messages. The following is the format of the NONCE attribute.
6.1 FloorRequest 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 0|M| Length | Nonce Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Clients request a floor by sending a FloorRequest message to the Figure 18: NONCE format
floor control server. In addition, the FloorRequest message is also
used to modify existing floor requests. The following is the format Nonce Value: this 16-bit field contains a nonce.
of the FloorRequest message:
5.2.14 SUPPORTED-TLVS
The following is the format of the SUPPORTED-TLVS attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 1|M| Length | Supported TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported TLV | Supported TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: SUPPORTED-TLVS format
Supported TLV: these fields contain the Types of the TLVs that are
supported by the floor control server.
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
aligned, no padding is needed.
The Padding bits SHOULD be set to zero by the sender and MUST be
ignored by the receiver.
5.3 Message Format
This section contains the normative ABNF [3] of the BFCP messages.
5.3.1 FloorRequest
Floor participants request a floor by sending a FloorRequest message
to the floor control server. The following is the format of the
FloorRequest message:
FloorRequest = (FIXED-HEADER) FloorRequest = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
[BENEFICIARY-ID] [BENEFICIARY-ID]
[FLOOR-REQUEST-ID]
*(FLOOR-ID) *(FLOOR-ID)
[HUMAN-READABLE-INFO] [HUMAN-READABLE-INFO]
[PRIORITY] [PRIORITY]
[INTEGRITY] [NONCE]
[DIGEST]
6.2 FloorRelease Figure 20: FloorRequest format
Clients release a floor by sending a FloorRelease message to the 5.3.2 FloorRelease
floor control server. Clients also use the FloorRelease message to
cancel pending floor requests. The following is the format of the Floor participants release a floor by sending a FloorRelease message
FloorRelease message: to the floor control server. Floor participants also use the
FloorRelease message to cancel pending floor requests. The following
is the format of the FloorRelease message:
FloorRelease = (FIXED-HEADER) FloorRelease = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
(FLOOR-REQUEST-ID) (FLOOR-REQUEST-ID)
[INTEGRITY] [NONCE]
[DIGEST]
6.3 FloorRequestInfo Figure 21: FloorRelease format
Clients request information about a floor request by sending a 5.3.3 FloorRequestInfoWanted
FloorRequestInfo message to the floor control server. The following
is the format of the FloorRequest message:
FloorRequestInfo = (FIXED-HEADER) Floor participants and floor chairs request information about a floor
request by sending a FloorRequestInfoWanted message to the floor
control server. The following is the format of the
FloorRequestInfoWanted message:
FloorRequestInfoWanted = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
[BENEFICIARY-ID] [BENEFICIARY-ID]
[FLOOR-REQUEST-ID] [FLOOR-REQUEST-ID]
[INTEGRITY] [NONCE]
[DIGEST]
6.4 FloorRequestStatus Figure 22: FloorRequestInfoWanted format
The floor control server informs clients about the status of their 5.3.4 FloorRequestInfo
floor requests by sending them FloorRequestStatus messages. The
following is the format of the FloorRequestStatus message:
FloorRequestStatus = (FIXED-HEADER) The floor control server informs floor participants and floor chairs
about the status of their floor requests by sending them
FloorRequestInfo messages. The following is the format of the
FloorRequestInfo message:
FloorRequestInfo = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
[BENEFICIARY-ID] [BENEFICIARY-ID]
[USER-DISPLAY-NAME] [USER-DISPLAY-NAME]
[USER-URI] [USER-URI]
1*( (FLOOR-REQUEST-ID) 1*( (FLOOR-REQUEST-ID)
1*(FLOOR-ID) 1*(FLOOR-ID)
[HUMAN-READABLE-INFO] [HUMAN-READABLE-INFO]
[PRIORITY] [PRIORITY]
(REQUEST-STATUS) ) (REQUEST-STATUS) )
[INTEGRITY] [NONCE]
6.5 FloorInfo Figure 23: FloorRequestInfo format
Clients request information about a floor or floors by sending a 5.3.5 FloorInfoWanted
FloorInfo message to the floor control server. The following is the
format of the FloorRequest message:
FloorInfo = (FIXED-HEADER) Floor participants and floor chairs request information about a floor
or floors by sending a FloorInfoWanted message to the floor control
server. The following is the format of the FloorRequest message:
FloorInfoWanted = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
*(FLOOR-ID) *(FLOOR-ID)
[INTEGRITY] [NONCE]
[DIGEST]
6.6 FloorStatus Figure 24: FloorInfoWanted format
The floor control server informs clients about the status, e.g., the 5.3.6 FloorInfo
current holder(s), of a floor by sending them FloorStatus messages.
The following is the format of the FloorStatus message:
FloorStatus = (FIXED-HEADER) The floor control server informs floor participants and floor chairs
about the status (e.g., the current holder) of a floor by sending
them FloorInfo messages. The following is the format of the
FloorInfo message:
FloorInfo = (FIXED-HEADER)
[TRANSACTION-ID] [TRANSACTION-ID]
(USER-ID) (USER-ID)
[FLOOR-ID] [FLOOR-ID]
*( (FLOOR-REQUEST-ID) *( (FLOOR-REQUEST-ID)
[BENEFICIARY-ID] [BENEFICIARY-ID]
[USER-DISPLAY-NAME] [USER-DISPLAY-NAME]
[USER-URI] [USER-URI]
*(FLOOR-ID) *(FLOOR-ID)
[HUMAN-READABLE-INFO] [HUMAN-READABLE-INFO]
[PRIORITY] [PRIORITY]
(REQUEST-STATUS) ) (REQUEST-STATUS) )
[INTEGRITY] [NONCE]
6.7 ChairAction Figure 25: FloorInfo format
Chairs send instructions to floor control servers by sending 5.3.7 ChairAction
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) (TRANSACTION-ID)
(USER-ID) (USER-ID)
1*(FLOOR-ID) 1*(FLOOR-ID)
(FLOOR-REQUEST-ID) (FLOOR-REQUEST-ID)
(REQUEST-STATUS) (REQUEST-STATUS)
[HUMAN-READABLE-INFO] [HUMAN-READABLE-INFO]
[INTEGRITY] [NONCE]
[DIGEST]
6.8 ChairActionAck Figure 26: ChairAction format
Floor control servers condirm that they have accepted a ChairAction 5.3.8 ChairActionAck
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) (TRANSACTION-ID)
(USER-ID) (USER-ID)
[INTEGRITY] [NONCE]
6.9 Ping Figure 27: ChairActionAck format
Clients check the liveness of servers, and servers of clients, by 5.3.9 Hello
sending a Ping message. The following is the format of the Ping
message:
Ping = (FIXED-HEADER) Floor participants and floor chairs check the liveness of floor
control servers by sending a Hello message. The following is the
format of the Hello message:
Hello = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
[INTEGRITY] [NONCE]
[DIGEST]
6.10 PingAck Figure 28: Hello format
Servers confirm that they are alive on reception of a Ping message by 5.3.10 HelloAck
sending a PingAck message. The following is the format of the
PingAck message:
PingAck = (FIXED-HEADER) Floor control servers confirm that they are alive on reception of a
Hello message by sending a HelloAck message. The following is the
format of the HelloAck message:
HelloAck = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
[INTEGRITY] (SUPPORTED-TLVS)
[NONCE]
6.11 Error Figure 29: HelloAck format
The floor control server informs clients about errors processing 5.3.11 Error
requests by sending them Error messages. The following is the format
of the Error message: Floor control servers inform floor participants and floor chairs
about errors processing requests by sending them Error messages. The
following is the format of the Error message:
Error = (FIXED-HEADER) Error = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
(ERROR-CODE) (ERROR-CODE)
[NONCE]
[HUMAN-READABLE-INFO] [HUMAN-READABLE-INFO]
[INTEGRITY]
7. Transport Figure 30: Error format
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 TLVs.
Editor's note: We need to address how to handle lost TCP connections If a floor control server detects that the TCP connection towards one
(e.g., that the TCP connection will be re-established in this case of the floor participants is lost, it is up to the local policy of
using O/A as described further below). the floor control server what to do with the pending floor requests
of the floor participant. The floor control server MAY cancel all
8. Lower-Layer Security the floor participant's floor requests or it MAY keep them while the
TCP connection is re-established. Connection re-establishment is
handled in different ways depending on how the client obtains
information to contact the floor control server (as described in
Section 3.2, two possibilities are CPCP and an offer/answer
exchange).
BFCP relies on lower-layer security mechanisms to provide replay 7. Lower-Layer Security
protection, and confidentiality. BFCP servers MUST support TLS [4],
and clients SHOULD support TLS. Clients and servers MAY support
other security mechanisms.
OPEN ISSUE: do we want to implement replay-protection in the protocol BFCP relies on lower-layer security mechanisms to provide replay and
instead of relying on TLS? integrity protection, and confidentiality. BFCP floor control
servers MUST support TLS [4], and BFCP clients (which include both
floor participants and floor chairs) SHOULD support TLS. Any BFCP
entity MAY support other security mechanisms.
Servers and clients that implement TLS MUST support TBD. (cypher and BFCP entities that implement TLS MUST support, at a minimum, the TLS
hash algorithm). TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite .
9. 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
server and a response from the server to the client. The request floor control server and a response from the floor control server to
carries a TRANSACTION-ID TLV which the server copies into the the client. The request carries a TRANSACTION-ID TLV which the floor
response. Clients use Transaction ID values to match responses with control server copies into the response. Clients use Transaction ID
previously-issued requests. 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
server to a client. Consequently, 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.
9.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 TLV to a number which MUST NOT be reused in another message from the
client until a response from the server is received. The client uses client until a response from the server is received for the
the Transaction ID value to match this FloorRequest message with the transaction. The client uses the Transaction ID value to match this
response from the floor control server. message with the response from the floor control server.
9.2 Server Behavior 8.2 Server Behavior
A server sending a response within a client-initiated transaction A floor control server sending a response within a client-initiated
MUST copy the Conference ID and the TRANSACTION-ID TLV from the transaction MUST copy the Conference ID, the TRANSACTION-ID TLV, and
request received from the client into the response. Server-initiated the USER-ID TLV from the request received from the client into the
transactions MUST NOT contain a TRANSACTION-ID TLV. response. Server-initiated transactions MUST NOT contain a
TRANSACTION-ID TLV.
10. Authentication 9. Authentication and Authorization
BFCP uses the INTEGRITY TLV to provide client and server BFCP uses the DIGEST TLV to provide client authentication. The
authentication, and message integrity. The INTEGRITY TLV contains an DIGEST TLV contains an HMAC-SHA1 [1] of the BFCP message. The use of
HMAC-SHA1 [1] of the BFCP message. The use of SHA1 implies that the SHA1 implies that the length of the HMAC is 20 bytes. The text used
length of the HMAC is 20 bytes. The text used as input to HMAC is as input to HMAC is the BFCP message, including the FIXED-HEADER, up
the BFCP message, including the FIXED-HEADER, up to and including the to and including the TLV preceding the DIGEST TLV. This text is then
TLV preceding the INTEGRITY TLV. This text is then padded with padded with zeroes so as to be a multiple of 64 bytes. As a result,
zeroes so as to be a multiple of 64 bytes. As a result, the the DIGEST TLV MUST be the last attribute in any BFCP message. The
INTEGRITY 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 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. the user identified by the USER-ID TLV in the message.
10.1 Client Behavior 9.1 Client Behavior
Clients SHOULD add an INTEGRITY TLV to all their messages. Clients can authenticate floor control servers by checking the floor
Furthermore, if a client generates a message without this TLV and control server's certificate when the TLS connection is established
receives an Error response with Error Code 7 (INTEGRITY TLV between them.
Required), the client SHOULD NOT send more messages without the
INTEGRITY TLV to the same server within the same conference.
When a client receives a BFCP message with an INTEGRITY TLV, it To achieve client authentication, a client needs to prove to the
calculates the HMAC-SHA1 [1] of the message excluding the INTEGRITY floor control server that the client can produce a DIGEST TLV for a
TLV. The key used as input to HMAC is the secret shared between the message using their shared secret and that the message is fresh (to
server and the user identified by the USER-ID TLV in the message. If avoid replay attacks). Clients prove the freshness of a message by
the resulting value is the same as the one in the INTEGRITY TLV, including a NONCE TLV in the message. The NONCE TLV is the second to
authentication is considered successful. If the resulting value is last TLV in the message (the last one is the DIGEST TLV).
different than the one in the INTEGRITY TLV, authentication is
considered to have failed and the message MUST NOT be processed
further.
10.2 Server Behavior The nonce in the NONCE TLV is provided by the floor control server
using an out-of-band mechanism (e.g., using an offer/answer exchange
as described in [15]), or in an Error response -- typically with
Error Code 7 (DIGEST TLV Required) or 6 (Invalid Nonce).
Servers SHOULD add an INTEGRITY TLV to all their messages. A client that obtains a nonce out-of-band SHOULD add a NONCE TLV and
Furthermore, if a client sends messages with this TLV to a server, a DIGEST TLV to the first message it sends to the floor control
the server MUST include it as well in its messages to this client. server. Furthermore, if a client generates a message without this
TLV and receives an Error response with Error Code 7 (DIGEST TLV
Required), the client SHOULD re-send the message with a DIGEST TLV
and a NONCE TLV with the nonce received in the Error response.
If a client does not add an INTEGRITY TLV to a message, the server If after sending a message with a DIGEST TLV, a client receives an
MAY request its addition by returning an Error message with Error Error response with Error Code 6 (Invalid Nonce), the client SHOULD
Code 7 (INTEGRITY TLV Required). re-send the message using the new nonce received in the Error
response. If the Error Code is 1 (Authentication Failed) instead,
the client MUST NOT send further messages to the floor control server
until it has obtained a different (hopefully valid) shared secret
than the one used in the original message.
When a server receives a BFCP message with an INTEGRITY TLV, it If a client receives a nonce in a message from the floor control
calculates the HMAC-SHA1 [1] of the message excluding the INTEGRITY server, the client SHOULD add a NONCE TLV with this nonce and a
TLV. The key used as input to HMAC is the secret shared between the DIGEST TLV to its next message to the floor control server.
server and the user identified by the USER-ID TLV in the message. If
the resulting value is the same as the one in the INTEGRITY TLV,
authentication is considered successful.
If the resulting value is different than the one in the INTEGRITY 9.2 Floor Control Server Behavior
TLV, authentication is considered to have failed, in which case the
server SHOULD return an Error message with Error Code 1
(Authentication Failed). Messages that cannot be authenticated MUST
NOT be processed further.
11. Client Operations Before accepting any BFCP message, the floor control server SHOULD
authenticate the client. If the floor control server receives a
message without DIGEST TLV from an unauthenticated client, the floor
control server responds with an Error message with Error Code 7
(DIGEST TLV Required). The floor control message MUST include a
NONCE TLV with a nonce value that is unguessable by attackers.
This section specifies how clients can perform different operations, When a floor control server receives a BFCP message with a DIGEST
such as requesting a floor, using the protocol elements described in TLV, it checks whether the NONCE TLV carries a nonce which was
earlier sections. Chair operations, such as instructing the floor generated by the floor control server for this client and which still
server to grant or revoke a floor, are described in Section 16. has not expired. If the nonce is not valid, authentication is
considered to have failed, in which case the floor control server
SHOULD return an Error message with Error Code 6 (Invalid Nonce) with
a new nonce in a NONCE TLV.
11.1 Requesting a Floor If the nonce is valid, the floor control server calculates the
HMAC-SHA1 [1] of the message excluding the DIGEST TLV. 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. If the resulting value
is the same as the one in the DIGEST TLV, authentication is
considered successful.
A client that wishes to request one or more floors does so by sending If the resulting value is different than the one in the DIGEST TLV,
a FloorRequest message to the floor control server. The ABNF in authentication is considered to have failed, in which case the server
Section 6.1 describes the TLVs that a FloorRequest message can SHOULD return an Error message, as described in Section 13.7, with
contain. In addition, the ABNF specifies which of these TLVs are Error Code 1 (Authentication Failed). Messages from a client that
mandatory, and which ones are optional. cannot be authenticated MUST NOT be processed further.
The client sets the Conference ID in the FIXED-HEADER and the Floor control servers may include a NONCE TLV in their responses to
TRANSACTION-ID TLV following the rules given in Section 9.1. provide the nonce to be used in the next message by the client.
Additionally, the client follows the rules in Section 10.1 which However, when TLS is used, floor control servers typically
relate to the authentication and the protection of the integrity of authenticate only the first message sent over the TLS connection.
the message (i.e., to the INTEGRITY TLV).
The client must insert a USER-ID TLV, which will be used by the After authenticating a BCFP message, the floor control server checks
server to authenticate and authorize the request. If the user whether or not the client is authorized to perform the operation it
sending the FloorRequest message (identified by the USER-ID TLV) is is requesting. If the client is not authorized to perform the
not the same as the user requesting the floor (i.e., a third party operation being requested, the floor control server generates an
floor request), the client SHOULD add a BENEFICIARY-ID TLV to the Error message, as described in Section 13.7, with an Error code with
message identifying the beneficiary of the floor. a value of 4 (Unauthorized Operation). Messages from a client that
cannot be authorized MUST NOT be processed further.
The client must insert at least one FLOOR-ID TLV in the FloorRequest 10. Floor Participant Operations
message. If the client inserts more than one FLOOR-ID TLVs, the
server will treat all the floor requests as an atomic package. That
is, the floor control server will either grant or deny all the floors
in the FloorRequest message.
The client may use a HUMAN-READABLE-INFO TLV to state the reason why This section specifies how floor participants can perform different
the floor or floors are being requested. The Text field in the operations, such as requesting a floor, using the protocol elements
HUMAN-READABLE-INFO TLV is intended for human consumption. described in earlier sections. Section 11 specifies operations that
are specific to floor chairs, such as instructing the floor control
server to grant or revoke a floor, and Section 12 specifies
operations that can be performed by any client (i.e., both floor
participants and floor chairs).
The client may request the server to handle the floor request with a 10.1 Requesting a Floor
certain priority using a PRIORITY TLV.
11.1.1 Receiving a Response A floor participant that wishes to request one or more floors does so
by sending a FloorRequest message to the floor control server.
A message from the server is considered to be a response to the 10.1.1 Sending a FloorRequest Message
FloorRequest message if the message from the server has the same
Conference ID and Transaction ID as the FloorRequest message, as
described in Section 9.1.
If the response is a FloorRequestStatus message, the client obtains The ABNF in Section 5.3.1 describes the TLVs that a FloorRequest
information about the status of the FloorRequest in a REQUEST-STATUS message can contain. In addition, the ABNF specifies normatively
TLV. If the Request Status value is Granted, the client has been which of these TLVs are mandatory, and which ones are optional.
granted all the floors that were requested in the FloorRequest
message. If the Request Status value is Denied, the client has been
denied all the floors that were requested in the FloorRequest
message. The HUMAN-READABLE-INFO TLV, if present, provides extra
information which the client MAY display to the user.
A floor request is considered to be ongoing while it is in the The floor participant sets the Conference ID in the FIXED-HEADER and
Pending, Accepted, or Granted states. FloorRequestStatus messages the TRANSACTION-ID TLV following the rules given in Section 8.1.
carrying any of these states will contain a FLOOR-REQUEST-ID TLV. Additionally, the floor participant follows the rules in Section 9.1
The value of this TLV is used to match subsequent messages received which relate to the authentication of the message (i.e., to the
at the client side (e.g., further FloorRequestStatus messages) or at DIGEST TLV).
the server side (e.g., a FloorRelease message) with this floor
request.
If the response is an Error message, the server could not process the The floor participant must insert a USER-ID TLV, which will be used
FloorRequest message for some reason, which is described in the Error by the floor control server to authenticate and authorize the
message. request. If the sender of the FloorRequest message (identified by
the USER-ID TLV) is not the participant that would eventually get the
floor (i.e., a third party floor request), the sender SHOULD add a
BENEFICIARY-ID TLV to the message identifying the beneficiary of the
floor.
12. Requesting Information about Floor Requests Note that the name space for both the User ID and the Beneficiary
ID is the same. That is, a given participant is identified by a
single 16-bit value that can be used in USER-ID and in
BENEFICIARY-ID TLVs.
Clients request information about the current status of one or The floor participant must insert at least one FLOOR-ID TLV in the
several floor request by sending a FloorRequestInfo message to the FloorRequest message. If the client inserts more than one FLOOR-ID
floor control server. TLVs, the floor control server will treat all the floor requests as
an atomic package. That is, the floor control server will either
grant or deny all the floors in the FloorRequest message.
The client sets the Conference ID in the FIXED-HEADER and the The floor participant may use a HUMAN-READABLE-INFO TLV to state the
TRANSACTION-ID TLV following the rules given in Section 9.1. reason why the floor or floors are being requested. The Text field
Additionally, the client follows the rules in Section 10.1 which in the HUMAN-READABLE-INFO TLV is intended for human consumption.
relate to the authentication and the protection of the integrity of
the message (i.e., to the INTEGRITY TLV). The client must insert a
USER-ID TLV, which will be used by the server to authenticate and
authorize the request.
If the client wants to request the status of a single floor request, The floor participant may request the server to handle the floor
it MUST insert a FLOOR-REQUEST-ID TLV that identifies the floor request with a certain priority using a PRIORITY TLV.
request at the server.
The client can also request information about all the ongoing floor 10.1.2 Receiving a Response
requests associated with a particular user. In this case, the 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 FloorRequestInfo message (which is identified by
the USER-ID TLV in the message) the client SHOULD insert a
BENEFICIARY-ID TLV.
12.1 Receiving a Response A message from the floor control server is considered to be a
response to the FloorRequest message if the message from the floor
control server has the same Conference ID, Transaction ID, and User
ID as the FloorRequest message, as described in Section 8.1.
On reception of the FloorRequestInfo message, the server will respond The successful processing of a FloorRequest message at the floor
with a FloorRequestStatus message or with an error message. That is, control server involves generating one or several FloorRequestInfo
the server will respond using the same message types as when it messages. The floor participant obtains a Floor Request ID in a
receives a FloorRequest message. Consequently, after sending the FLOOR-REQUEST-ID TLV in the first FloorRequestInfo message from the
FloorRequestInfo message, the client follows the steps described in floor control server. Subsequent FloorRequestInfo messages from the
Section 11.1.1. floor control server regarding the same floor request will carry the
same Floor Request ID as the initial FloorRequestInfo message. This
way, the floor participant can associate subsequent incoming
FloorRequestInfo messages with the ongoing floor request.
If the FloorRequestInfo message requested information about several The floor participant obtains information about the status of the
floor requests, the FloorRequestStatus message will contain floor request in the REQUEST-STATUS TLV of each of the
information about all of them. FloorRequestInfo messages received from the floor control server. If
the Request Status value is Granted, all the floors that were
requested in the FloorRequest message have been granted. If the
Request Status value is Denied, all the floors that were requested in
the FloorRequest message have been denied. The HUMAN-READABLE-INFO
TLV, if present, provides extra information which the floor
participant MAY display to the user.
13. Cancelling a Floor Request and Releasing a Floor A floor request is considered to be ongoing while it is in the
Pending, Accepted, or Granted states.
A client that wishes to cancel an ongoing floor request does so by If the response is an Error message, the floor control server could
sending a FloorRelease message to the floor control server. The ABNF not process the FloorRequest message for some reason, which is
in Section 6.2 describes the TLVs that a FloorRelease message can described in the Error message.
contain. In addition, the ABNF specifies which of these TLVs are
mandatory, and which ones are optional.
The client sets the Conference ID in the FIXED-HEADER and the 10.2 Cancelling a Floor Request and Releasing a Floor
TRANSACTION-ID TLV following the rules given in Section 9.1.
Additionally, the client follows the rules in Section 10.1 which A floor participant that wishes to cancel an ongoing floor request
relate to the authentication and the protection of the integrity of does so by sending a FloorRelease message to the floor control
the message (i.e., to the INTEGRITY TLV). The client must insert a server. The FloorRelease message is also used by floor participants
USER-ID TLV, which will be used by the server to authenticate and that hold a floor and would like to release it.
10.2.1 Sending a FloorRelease Message
The ABNF in Section 5.3.2 describes the TLVs that a FloorRelease
message can contain. In addition, the ABNF specifies normatively
which of these TLVs are mandatory, and which ones are optional.
The floor participant sets the Conference ID in the FIXED-HEADER and
the TRANSACTION-ID TLV following the rules given in Section 8.1.
Additionally, the floor participant follows the rules in Section 9.1
which relate to the authentication of the message (i.e., to the
DIGEST TLV). The floor participant must insert a USER-ID TLV, which
will be used by the floor control server to authenticate and
authorize the request. authorize the request.
Note that the FloorRelease message is also used to release a floor Note that the FloorRelease message is used to release a floor or
or floors that were granted to the client (from the protocol floors that were granted and to cancel ongoing floor requests
perspective both are ongoing floor requests). Using the same (from the protocol perspective both are ongoing floor requests).
message in both situations helps resolve the race condition that Using the same message in both situations helps resolve the race
occurs when the FloorRelease message and the FloorGrant message condition that occurs when the FloorRelease message and the
cross each other on the wire. FloorGrant message cross each other on the wire.
The client uses the FLOOR-REQUEST-ID that was received in the The floor participant uses the FLOOR-REQUEST-ID that was received in
response to the FloorRequest message that the FloorRelease message is the response to the FloorRequest message that the FloorRelease
cancelling. message is cancelling.
13.1 Receiving a Response Note that if the floor participant requested several floors as an
atomic operation (i.e., in a single FloorRequest message), all the
floors are released as an atomic operation as well (i.e., all are
released at the same time).
On reception of the FloorRelease message, the server will respond as 10.2.2 Receiving a Response
with a FloorRequestStatus message or with an error message. That is,
the server will respond using the same message types as when it A message from the floor control server is considered to be a
receives a FloorRequest message. Consequently, after sending the response to the FloorRelease message if the message from the floor
FloorRelease message, the client follows the steps described in control server has the same Conference ID, Transaction ID, and User
Section 11.1.1. ID as the FloorRequest message, as described in Section 8.1.
If the response is a FloorRequestInfo message, the Request Status
value in the REQUEST-STATUS-TLV will be Cancelled or Released.
If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is
described in the Error message.
It is possible that the FloorRelease message crosses on the wire with It is possible that the FloorRelease message crosses on the wire with
a FloorRequestStatus message from the server with a Request Status a FloorRequestInfo message from the server with a Request Status
different from Cancelled. In any case, such a FloorRequestStatus different from Cancelled or Released. In any case, such a
message will not be a response to the FloorRelease message, because FloorRequestInfo message will not be a response to the FloorRelease
its Transaction ID will not match that of the FloorRelease. message, because its Transaction ID will not match that of the
FloorRelease.
14. Requesting Information about Floors 11. Chair Operations
This section specifies how floor chairs can instruct the floor
control server to grant or revoke a floor using the protocol elements
described in earlier sections.
Floor chairs that wish to send instructions to a floor control server
do so by sending a ChairAction message.
11.1 Sending a ChairAction Message
The ABNF in Section 5.3.7 describes the TLVs that a ChairAction
message can contain. In addition, the ABNF specifies normatively
which of these TLVs are mandatory, and which ones are optional.
The floor chair sets the Conference ID in the FIXED-HEADER and the
TRANSACTION-ID TLV following the rules given in Section 8.1.
Additionally, the floor chair follows the rules in Section 9.1 which
relate to the authentication of the message (i.e., to the DIGEST
TLV). The floor chair must insert a USER-ID TLV, which will be used
by the floor control server to authenticate and authorize the
request.
The ChairAction message contains instructions that apply to one or
more floors within a particular floor request. The floor or floors
are identified by FLOOR-ID TLVs and the floor request is identified
by a FLOOR-REQUEST-ID TLV, which are carried in the ChairAction
message.
For example, if a floor request consists of two floors that depend
on different floor chairs, each floor chair will grant its floor
within the floor request. Once both chairs have granted their
floor, the floor control server will grant the floor request as a
whole. On the other hand, if one of the floor chairs denies its
floor, the floor control server will deny the floor request as a
whole, regardless of the other floor chair's decision.
The floor chair provides the new status for one or more floors within
the floor request using a REQUEST-STATUS TLV. If the new status of
the floor request is Accepted, the floor chair MAY use the Queue
Position field to provide a queue position for the floor request. If
the floor chair does not wish to provide a queue position, all the
bits of the Queue Position field SHOULD be set to zero. The floor
chair SHOULD use the Status Revoked to revoke a floor that was
granted (i.e., Granted status) and the Status Denied 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
ChairAction message may only deal with a subset of these floors
(e.g., if a single floor chair is not authorized to manage all the
floors). In this case, the REQUEST-STATUS that the floor chair
provides in the ChairAction message might not be the actual status
that the floor request gets at the server. The floor control
server will combine the instructions received from the different
floor chairs to come up with the actual status of the floor
request.
The floor chair may use a HUMAN-READABLE-INFO TLV to state the reason
why the floor or floors are being accepted, granted, or revoked. The
Text in the HUMAN-READABLE-INFO TLV is intended for human
consumption.
11.2 Receiving a Response
A message from the floor control server is considered to be a
response to the ChairAction message if the message from the server
has the same Conference ID, Transaction ID, and User ID as the
ChairAction message, as described in Section 8.1.
A ChairActionAck message from the floor control server confirms that
the floor control server has accepted the ChairAction message. An
Error message indicates that the floor control server could not
process the ChairAction message for some reason, which is described
in the Error message.
12. General Client Operations
This section specifies operations that can be performed by any
client. That is, they are not specific to floor participants or
floor chairs. They can be performed by both.
12.1 Requesting Information about Floors
A client can obtain information about the status of a floor or floors
in different ways, which include using BFCP and using out-of-band
mechanisms. Clients using BFCP to obtain such information use the
procedures described in this section.
Clients request information about the status of one or several floors Clients request information about the status of one or several floors
by sending a FloorInfo message to the floor control server. by sending a FloorInfoWanted message to the floor control server.
12.1.1 Sending a FloorInfoWanted Message
The ABNF in Section 5.3.5 describes the TLVs that a FloorInfoWanted
message can contain. In addition, the ABNF specifies normatively
which of these TLVs 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 9.1. TRANSACTION-ID TLV following the rules given in Section 8.1.
Additionally, the client follows the rules in Section 10.1 which Additionally, the client follows the rules in Section 9.1 which
relate to the authentication and the protection of the integrity of relate to the authentication and the protection of the integrity of
the message (i.e., to the INTEGRITY TLV). The client must insert a the message (i.e., to the DIGEST TLV). The client must insert a
USER-ID TLV, which will be used by the server to authenticate and USER-ID TLV, which will be used by the floor control server to
authorize the request. authenticate and authorize the 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 server will send periodic information receive information about. The floor control server will send
about all these floors. If the client does not want to receive periodic information about all these floors. If the client does not
information about a particular floor any longer, it sends a new want to receive information about a particular floor any longer, it
FloorInfo message removing the FLOOR-ID of this floor. If the client sends a new FloorInfoWanted message removing the FLOOR-ID of this
does not want to receive information about any floor, it sends a floor. If the client does not want to receive information about any
FloorInfo message with no FLOOR-ID TLV. floor any longer, it sends a FloorInfoWanted message with no FLOOR-ID
TLV.
14.1 Receiving a Response 12.1.2 Receiving a Response
A message from the server is considered to be a response to the A message from the floor control server is considered to be a
FloorInfo message if the message from the server has the same response to the FloorInfoWanted message if the message from the floor
Conference ID and Transaction ID as the FloorRequest message, as control server has the same Conference ID, Transaction ID, and User
described in Section 9.1. ID as the FloorRequest message, as described in Section 8.1.
On reception of the FloorInfo message, the server will respond with a On reception of the FloorInfoWanted message, the floor control server
FloorStatus message or with an Error message. If the response is a will respond with a FloorInfo message or with an Error message. If
FloorStatus message, it will contain information about one of the the response is a FloorInfo message, it will contain information
floors the client requested information about. If the client did not about one of the floors the client requested information about. If
include any FLOOR-ID in its FloorInfo message, the FloorStatus the client did not include any FLOOR-ID TLV in its FloorInfoWanted
message from the server will not include any either. message, the FloorInfo message from the floor control server will not
include any either.
After the first FloorStatus, the server will continue sending FloorInfo messages which carry information about a floor contain a
FloorStatus messages periodically informing the client about changes FLOOR-ID TLV that identifies the floor. After this TLV, FloorInfo
on the floors the client requested information about. messages contain information about existing (one or more) floor
request that relate to that floor. The information about each
particular floor request consist of a FLOOR-REQUEST-ID TLV that
identifies the floor request followed by a set of TLVs that provide
information about the floor request.
15. Checking the Liveness of a Server After the first FloorInfo, the floor control server will continue
sending FloorInfo messages periodically informing the client about
changes on the floors the client requested information about.
A client that wishes to check the liveness of a server does so by 12.2 Requesting Information about Floor Requests
sending a Ping message to the floor control server. The ABNF in
Section 6.9 describes the TLVs that a Ping message can contain. In
addition, the ABNF specifies which of these TLVs are mandatory, and
which ones are optional.
The client sets the Conference ID in the FIXED-HEADER and the A client can obtain information about the status of one or several
TRANSACTION-ID TLV following the rules given in Section 9.1. floor requests in different ways, which include using BFCP and using
Additionally, the client follows the rules in Section 10.1 which out-of-band mechanisms. Clients using BFCP to obtain such
relate to the authentication and the protection of the integrity of information use the procedures described in this section.
the message (i.e., to the INTEGRITY TLV).
15.1 Receiving Responses Clients request information about the current status of one or
several floor requests by sending a FloorRequestInfoWanted message to
the floor control server.
A message from the server is considered a response to the Ping Requesting information about a particular floor request is useful
message by the client if the message from the server has the same in a number of situations. For example, on reception of a
Conference ID and Transaction ID as the Ping message, as described in FloorRequest message, a floor control server may choose to return
Section 9.1. FloorRequestInfo messages only when the floor request changes its
state (e.g., from Accepted to Granted), but not when the floor
request advances in its queue. In this situation, if the user
requests it, the floor participant can use a
FloorRequestInfoWanted message to poll the floor control server
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.
If the response is a PingAck message, the server is alive and the 12.2.1 Sending a FloorRequestInfoWanted Message
user identified by the User ID was authenticated successfully.
If the response is an Error message, the server could not process the The ABNF in Section 5.3.3 describes the TLVs that a
Ping message for some reason, which is described in the Error FloorRequestInfoWanted message can contain. In addition, the ABNF
message. specifies normatively which of these TLVs are mandatory, and which
ones are optional.
16. Chair Operations The client sets the Conference ID in the FIXED-HEADER and the
TRANSACTION-ID TLV following the rules given in Section 8.1.
Additionally, the client follows the rules in Section 9.1 which
relate to the authentication of the message (i.e., to the DIGEST
TLV). The client must insert a USER-ID TLV, which will be used by
the floor control server to authenticate and authorize the request.
This section specifies how clients acting as chairs can perform If the client wants to request the status of a single floor request,
different operations, such as instructing the floor server to grant it MUST insert a FLOOR-REQUEST-ID TLV that identifies the floor
or revoke a floor, using the protocol elements described in earlier request at the floor control server.
sections.
16.1 Obtaining Information about Floor Requests The client can also request information about all the ongoing floor
requests associated with a particular participant. In this case, the
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.
A chair can obtain information about the floor requests that the 12.2.2 Receiving a Response
floor control server receives in different ways, which include using
out-of-band mechanisms. Chairs using BFCP to obtain such information
use the procedures described in Section 14. As a result, they
receive information about floor requests that relate to specific
floors in FloorStatus messages from the floor control server.
16.2 Instructing the Floor Control Server A message from the floor control server is considered to be a
response to the FloorRequestInfoWanted message if the message from
the floor control server has the same Conference ID, Transaction ID,a
nd User ID as the FloorRequestInfoWanted message, as described in
Section 8.1.
Chairs that wish to send instructions to a floor control server does If the response is a FloorRequestInfo message, the client obtains
so by sending a ChairAction message. The ABNF in Section 6.7 information about the status of the FloorRequest the client requested
describes the TLVs that a ChairAction message can contain. In information about in a REQUEST-STATUS TLVs. If the client requested
addition, the ABNF specifies which of these TLVs are mandatory, and information about several floor requests, the FloorRequestInfo
which ones are optional. 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.
The chair sets the Conference ID in the FIXED-HEADER and the If the response is an Error message, the floor control server could
TRANSACTION-ID TLV following the rules given in Section 9.1. not process the FloorRequestInfoWanted message for some reason, which
Additionally, the chair follows the rules in Section 10.1 which is described in the Error message.
relate to the authentication and the protection of the integrity of
the message (i.e., to the INTEGRITY TLV). The client must insert a
USER-ID TLV, which will be used by the server to authenticate and
authorize the request.
The ChairAction message contains instructions that apply to one or 12.3 Obtaining the Capabilities of a Floor Control Server
more floors within a particular floor request. The floor or floors
are identified by FLOOR-ID TLVs and the floor request is identified
by a FLOOR-REQUEST-ID TLV, which are carries in the ChairAction
message.
For example, if a floor request consists of two floors that depend A client that wishes to obtain the capabilities of a floor control
on different chairs, each chair will grant its floor within the server does so by sending a Hello message to the floor control
floor request. Once both chairs have grant their floor, the floor server.
control server will grant the floor request as a whole. On the
other hand, if one of the chairs denies its floor, the floor
control server will deny the floor request as a whole, regardless
of the other chair's decision.
The chair provides the new status for one or more floors within the 12.3.1 Sending a Hello Message
floor request using a REQUEST-STATUS TLV. If the new status of the
floor request is Accepted, the chair MAY use the Queue Position field
to provide a queue position for the floor request. If the chair does
not wish to provide a queue position, all the bits of the Queue
Position field SHOULD be set to zero. The chair SHOULD use the
Status Revoked to revoke a floor that was granted (i.e., Granted
status) and to reject floor requests in any other status (e.g.,
Pending and Accepted).
Note a floor request may involve several floors and that a The ABNF in Section 5.3.9 describes the TLVs that a Hello message can
ChairAction message could only deal with a subset of these floors contain. In addition, the ABNF specifies normatively which of these
(e.g., if a single chair is not authorized to manage all the TLVs are mandatory, and which ones are optional.
floors). In this case, the REQUEST-STATUS that the chair provides
in the ChairAction message might not be the actual status that the
floor request gets at the server. The floor control server will
combine the instructions received from the different chairs to
come up with the actual status of the floor request.
The chair may use a HUMAN-READABLE-INFO TLV to state the reason why The client sets the Conference ID in the FIXED-HEADER and the
the floor or floors are being accepted, granted, or revoked. The TRANSACTION-ID TLV following the rules given in Section 8.1.
Text in the HUMAN-READABLE-INFO TLV is intended for human Additionally, the client follows the rules in Section 9.1 which
consumption. relate to the authentication and the protection of the integrity of
the message (i.e., to the DIGEST TLV). The client must insert a
USER-ID TLV, which will be used by the floor control server to
authenticate and authorize the request.
16.2.1 Receiving a Response 12.3.2 Receiving Responses
A message from the server is considered to be a response to the A message from the floor control server is considered a response to
ChairAction message if the message from the server has the same the Hello message by the client if the message from the floor control
Conference ID and Transaction ID as the ChairAction message, as server has the same Conference ID, Transaction ID, and User ID as the
described in Section 9.1. Hello message, as described in Section 8.1.
A ChairActionAck message from the server confirms that the server has If the response is a HelloAck message, the floor control server could
accepted the ChairAction message. An Error message indicates that process successfully the Hello message. The SUPPORTED-TLVS TLV
the server could not process the ChairAction message for some reason, indicates which TLVs are supported by the server.
which is described in the Error message.
17. Server Operations If the response is an Error message, the floor control server could
not process the Hello message for some reason, which is described in
the Error message.
This section specifies how servers can perform different operations, 13. Floor Control Server Operations
such as granting a floor, using the protocol elements described in
earlier sections. This section specifies how floor control servers can perform
different operations, such as granting a floor, using the protocol
elements described in earlier sections.
On reception of a message from a client, the floor control server 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 server SHOULD send an existing conference. If it does not, the floor control server SHOULD
Error message, as described in Section 17.7, with Error code 0 send an Error message, as described in Section 13.7, with Error code
(Conference does not Exist). 0 (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 10.2, which relate to the authentication follows the rules in Section 9.2, which relate to the authentication
of the message. of 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 server does not understand all of set) TLVs in the message. If the floor control server does not
them, the floor server SHOULD send an Error message, as described in understand all of them, the floor control server SHOULD send an Error
Section 17.7, with Error code 2 (Authentication Failed). The Error message, as described in Section 13.7, with Error code 2
message SHOULD list the TLVs that were not understood. (Authentication Failed). The Error message SHOULD list the TLVs that
were not understood.
OPEN ISSUE: can servers use new mandatory TLVs in their messages?
Right now we do not have a way for clients to complain about
unsupported TLVs received from the server.
17.1 Reception of a FloorRequest Message
The processing of a FloorRequest message by a server involves
generating a FloorRequestStatus message. The floor control server
SHOULD generate a FloorRequestStatus message as soon as possible. If
the floor server cannot accept, grant, or deny the floor request
right away (e.g., a decision from a chair is needed), it SHOULD use a
Request Status value of Pending.
The server copies the Conference ID and the TRANSACTION-ID TLV from
the FloorRequest into the FloorRequestStatus, as described in Section
9.2. Additionally, the server MUST assign an identitifier that is
unique within the conference to this floor request, and insert it in
a FLOOR-REQUEST-ID TLV into the FloorRequestStatus message. This
indentifier will be used by the client to refer to this specific
floor request in the future.
The server follows the rules in Section 10.2 which relate to 13.1 Reception of a FloorRequest Message
authentication and the use of the INTEGRITY TLV.
At later time, when the status of the floor request changes, the On reception of a FloorRequest message, the floor control server
floor control server SHOULD send a new FloorRequestStatus message follows the rules in Section 9.2 which relate to client
with the appropriate Request Status. This FloorRequestStatus message authentication and authorization. If while processing the
MUST contain a FLOOR-REQUEST-ID TLV identifying the floor request, FloorRequest message, the floor control server encounters an error,
but MUST NOT contain any TRANSACTION-ID TLV. The server may add a it SHOULD generate an Error response following the procedures
HUMAN-READABLE-INFO TLV to provide extra information to the user described in Section 13.7
about its decision.
The rate at which the floor control server sends BFCP allows floor participants to have several ongoing floor
FloorRequestStatus messages is a matter of local policy. A server requests for the same floor (e.g., the same floor participant can
may choose to send a new FloorRequestStatus message every time the occupy more than one position in a queue at the same time). A
floor request moves in the floor request queue while another may floor control server that only supports a certain number of
choose to only send a new FloorRequestStatus message when the ongoing floor requests per floor participant (e.g., one) can use
floor request is Granted or Denied. Error Code 9 (You have Already Reached the Maximum Number of
Ongoing Floor Requests for this Floor) to inform the floor
participant.
Clients and chairs that request so need to be informed about changes 13.1.1 Generating the First FloorRequestInfo Message
in the status of a floor (e.g., a new floor request arrives). To
accomplish this, the floor control server follows the rules in
Section 17.4.
17.2 Reception of a FloorRequestInfo Message The successful processing of a FloorRequest message by a floor
control server involves generating one or several FloorRequestInfo
messages, the first of which SHOULD be generated as soon as possible.
If the floor control server cannot accept, grant, or deny the floor
request right away (e.g., a decision from a chair is needed), it
SHOULD use a Request Status value of Pending in the REQUEST-STATUS
TLV of the first FloorRequestInfo message it generates.
The processing of a FloorRequestInfo message by a server involves The policy a floor control server follows to grant or deny floors
generating a FloorRequestStatus message. The FloorRequestInfo is outside the scope of this document. A given floor control
message can apply to a single floor request, identified by a server may perform these decisions automatically while another may
FLOOR-REQUEST-ID, or to all the floor requests from a given user, the contact a human acting as a chair everytime a decision needs to be
FloorRequestInfo does not carry a FLOOR-REQUEST-ID. The user is made.
identified by a BENEFICIARY-ID TLV, or if this is not present, by a
USER-ID TLV.
If the FloorRequestInfo message contains an invalid FLOOR-REQUEST-ID, The floor control server copies the Conference ID, the
the floor control server SHOULD respond with an Error response with TRANSACTION-ID, and the USER-ID TLVs from the FloorRequest into the
Error Code 3 (Floor Request ID Does Not Exist). FloorRequestInfo, as described in Section 8.2. Additionally, the
floor control server copies (if present) the BENEFICIARY-ID TLV from
the FloorRequest into the FloorRequestInfo.
On reception of a FloorRequestInfo message, the floor control server The floor control server MUST assign an identitifier that is unique
SHOULD generate a FloorRequestStatus message as soon as possible. within the conference to this floor request, and insert it in a
FLOOR-REQUEST-ID TLV into the FloorRequestInfo message. This
indentifier will be used by the floor participant (or by a chair or
chairs) to refer to this specific floor request in the future.
The server copies the Conference ID and the TRANSACTION-ID TLV from The floor control server copies the FLOOR-ID TLVs from the
the FloorRequestInfo message into the FloorRequestStatus, as FloorRequest into the FloorRequestInfo. These FLOOR-ID TLVs identify
described in Section 9.2. the floors being requested (i.e., the floors associated with this
particular floor request).
The server follows the rules in Section 10.2 which relate to The floor control server also copies (if present) the PRIORITY TLV
authentication and the use of the INTEGRITY TLV. from the FloorRequest into the FloorRequestInfo. The Priority value
requested by the floor participant is only a hint, and does not
necessarily need to be taken into consideration to decide whether to
grant or not the floor request.
17.3 Reception of a FloorRelease Message 13.1.2 Generation of Subsequent FloorRequestInfo Messages
The processing of a FloorRelease message by a server involves A floor request is considered to be ongoing as long as it is not in
generating a FloorRequestStatus message. The FloorRelease message the Cancelled, Released, or Revoked states. If the REQUEST-STATUS
identifies the floor request it applies to using a FLOOR-REQUEST-ID. TLV of the first FloorRequestInfo message generated by the floor
control server did not indicate any of these states, the floor
control server will need to send subsequent FloorRequestInfo
messages.
If the FloorRelease message contains an invalid FLOOR-REQUEST-ID, the When the status of the floor request changes, the floor control floor
floor control server SHOULD respond with an Error response with Error control server SHOULD send new FloorRequestInfo messages with the
Code 3 (Floor Request ID Does Not Exist). appropriate Request Status. These FloorRequestInfo messages MUST
contain a FLOOR-REQUEST-ID TLV equal to the one sent in the first
FloorRequestInfo message, but MUST NOT contain any TRANSACTION-ID
TLV. (The Floor Request ID identifies the floor request the
FloorRequestInfo applies to.)
On reception of a FloorRelease message with a valid FLOOR-REQUEST-ID, The FIXED-HEADER and the rest of the TLVs (expect for the
the floor control server SHOULD generate a FloorRequestStatus message HUMAN-READABLE-INFO TLV) are the same as in the first
as soon as possible. If the floor server can authorize the release FloorRequestInfo message.
operation right away, it SHOULD use a Request Status value of
Released, if the floor had been previously granted, or of Cancelled,
if it had not. The server may add a HUMAN-READABLE-INFO TLV to
provide extra information to the user about its decision.
The server copies the Conference ID and the TRANSACTION-ID TLV from The rate at which the floor control server sends FloorRequestInfo
the FloorRelease into the FloorRequestStatus, as described in Section messages is a matter of local policy. A floor control server may
9.2. choose to send a new FloorRequestInfo message every time the floor
request moves in the floor request queue while another may choose
to only send a new FloorRequestInfo message when the floor request
is Granted or Denied.
The server follows the rules in Section 10.2 which relate to The floor control server may add a HUMAN-READABLE-INFO TLV to any of
authentication and the use of the INTEGRITY TLV. the FloorRequestInfo messages it generates to provide extra
information about its decisions regarding the floor request (e.g.,
why it was denied).
17.4 Reception of a FloorInfo Message Floor participants and floor chairs may request to be informed
about the status of a floor following the procedures in Section
12.1. If the processing of a floor request changes the status of
a floor (e.g., the floor request is granted and consequently the
floor has a new holder), the floor control server needs to follow
the procedures in Section 13.4 to inform the clients that have
requested that information
A server receiving a FloorInfo message from a client SHOULD keep this The floor control server can discard the state information about a
client informed about the status of the floors identified by particular floor request when this reaches a status of Cancelled,
FLOOR-IDs in the FloorInfo message. Servers keep clients informed by Released, or Revoked.
using FloorStatus messages.
The information FloorInfo messages carry may depend on the user 13.2 Reception of a FloorRequestInfoWanted Message
requesting the information. For example, a chair may be able to
receive information about pending requests while a regular user may
not be authorized to do so.
The server may provide information about a number of floor requests On reception of a FloorRequestInfoWanted message, the floor control
in a single FloorInfo message. For each floor request, the server server follows the rules in Section 9.2 which relate to client
provides its FLOOR-REQUEST-ID and its REQUEST-STATUS, and may provide authentication and authorization. If while processing the
further information such as its BENEFICIARY-ID. FloorRequestInfoWanted message, the floor control server encounters
an error, it SHOULD generate an Error response following the
procedures described in Section 13.7
On reception of a FloorInfo message with one or more FLOOR-ID TLVs, The successful processing of a FloorRequestInfoWanted message by a
the server generates a FloorStatus message for one of the floors floor control server involves generating a FloorRequestInfo message,
identified in the FloorInfo message. which SHOULD be generated as soon as possible.
The server copies the Conference ID and the TRANSACTION-ID TLV from The floor control server copies the Conference ID, the
the FloorInfo message into the FloorStatus message, as described in TRANSACTION-ID, and the USER-ID TLVs from the FloorRequestInfoWanted
Section 9.2. message into the FloorRequestInfo message, as described in Section
8.2.
The server follows the rules in Section 10.2 which relate to 13.2.1 Information on a Single Floor Request
authentication and the use of the INTEGRITY TLV.
After sending this message, the server SHOULD continue sending If the FloorRequestInfoWanted message carries a FLOOR-REQUEST-ID, the
FloorStatus messages about all the floors the client requested sender of the message is requesting information about the floor
information about. These messages MUST NOT carry a TRANSACTION-ID request identified by the FLOOR-REQUEST-ID TLV. The floor control
TLV. servre copies the FLOOR-REQUEST-ID TLV from the
FloorRequestInfoWanted message into the FloorRequestInfo message.
The rate at which the floor control server sends FloorStatus The floor control server adds FLOOR-ID TLVs to the FloorRequestInfo
messages is a matter of local policy. A server may choose to send message identifying the floors being requested (i.e., the floors
a new FloorRequestStatus message every time a new floor request associated with the floor request identified by the FLOOR-REQUEST-ID
arrives while another may choose to only send a new FloorStatus TLV).
message when a new floor request is Granted.
17.5 Reception of a ChairAction Message The floor control server may also add a PRIORITY TLV with the
Priority value requested for the floor request and a
HUMAN-READABLE-INFO TLV with extra information about the floor
request.
On reception of a ChairAction message, the floor control server The floor control server adds a REQUEST-STATUS TLV with the current
checks whether the chair that send the message is authorized to status of the floor request.
perform the operation being requested. If the chair is authorized,
the floor control server performs the operation and sends a
ChairActionAck message to the client. If the new Status in the
ChairAction message is Accepted and all the bits of the Queue
Position field are zero, the server assigns a queue position (e.g.,
the last in the queue) to the floor request based on local policy (in
case the server implements a queue).
The server copies the Conference ID and the TRANSACTION-ID TLV from 13.2.2 Information on the Floor Requests Associated to a Participant
the ChairAction message into the ChairActionAck message, as described
in Section 9.2.
The server follows the rules in Section 10.2 which relate to If the FloorRequestInfoWanted message does not carry a
authentication and the use of the INTEGRITY TLV. FLOOR-REQUEST-ID TLV, the sender of the message is requesting
information about all the floor requests from a given participant.
This participant is identified by a BENEFICIARY-ID TLV or, in the
absence of a BENEFICIARY-ID TLV, by a USER-ID TLV.
If the floor control server cannot find a floor request that matches The floor control server copies (if present) the BENEFICIARY-ID TLV
the FLOOR-REQUEST-ID TLV in the ChairAction message the floor control from the FloorRequestInfoWanted message into the FloorRequestInfo
server generates an Error message, as described in Section 17.7, with message. Additionally, the floor control server may provide extra
an Error code with a value of 3 (Floor Request ID Does Not Exist). information about the participant by adding a USER-DISPLAY-NAME TLV,
a USER-URI TLV, or both to the FloorRequestInfo message.
If the chair is not authorized to perform the operation being The floor control server adds a FLOOR-REQUEST-ID TLV for each floor
requested, the floor control server generates an Error message, as request associated to the participant. Each FLOOR-REQUEST-ID TLV is
described in Section 17.7, with an Error code with a value of 4 followed by a number of TLVs which provide information about the
(Unauthorized Operation). floor request. The floor control server generates the TLVs that
follow each FLOOR-REQUEST-ID following the rules in Section 13.2.1
17.6 Reception of a Ping Message 13.3 Reception of a FloorRelease Message
The processing of a Ping message by a server involves generating a On reception of a FloorRelease message, the floor control server
PingAck message. On reception of a Ping message, the floor control follows the rules in Section 9.2 which relate to client
server SHOULD generate a PingAck message as soon as possible. The authentication and authorization. If while processing the
server copies the Conference ID and the TRANSACTION-ID TLV from the FloorRelease message, the floor control server encounters an error,
Ping into the PingAck, as described in Section 9.2. it SHOULD generate an Error response following the procedures
described in Section 13.7
The server follows the rules in Section 10.2 which relate to The successful processing of a FloorRelease message by a floor
authentication and the use of the INTEGRITY TLV. control server involves generating a FloorRequestInfo message, which
SHOULD be generated as soon as possible.
17.7 Error Message Generation The floor control server copies the Conference ID, the
TRANSACTION-ID, and the USER-ID TLVs from the FloorRelease message
into the FloorRequestInfo message, as described in Section 8.2.
Error messages are always sent in response to a previous message from The FloorRelease message identifies the floor request it applies to
the client as part of a client-initiated transaction. The ABNF in using a FLOOR-REQUEST-ID. If the beneficiary of the floor request is
Section 6.11 describes the TLVs that an Error message can contain. not the participant identified by the USER-ID TLV in the FloorRelease
In addition, the ABNF specifies which of these TLVs are mandatory, message, the floor control server adds a BENEFICIARY-ID TLV to the
and which ones are optional. FloorRequestInfo message identifying the beneficiary of the floor
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.
Servers copy the Conference ID and the TRANSACTION-ID TLV from the The floor control server copies the FLOOR-REQUEST-ID TLV from the
message from the client into the Error message, as described in FloorRelease message into the FloorRequestInfo message.
Section 9.2.
The server follows the rules in Section 10.2 which relate to The floor control server adds FLOOR-ID TLVs to the FloorRequestInfo
authentication and the use of the INTEGRITY TLV. message identifying the floors being requested (i.e., the floors
associated with the floor request identified by the FLOOR-REQUEST-ID
TLV).
18. BFCP and the Offer/Answer Model The floor control server may also add a PRIORITY TLV with the
Priority value requested for the floor request and a
HUMAN-READABLE-INFO TLV with extra information about the floor
request.
The way a client obtains a the information needed to contact a BFCP The floor control server adds a REQUEST-STATUS TLV to the
floor control server is outside the scope of BCFP. Nevertheless, FloorRequestInfo message. The Request Status value SHOULD be
this section describes how to obtain such an information using an SDP Released, if the floor (or floors) had been previously granted, or of
[5] offer/answer [11] exchange. Cancelled, if the floor (or floors) had not been previously granted.
User agents typically use the offer/answer model to establish a 13.4 Reception of a FloorInfoWanted Message
number of media streams of different types. Following this model, a
BFCP connection is described as any other media stream by using an
SDP m line.
18.1 Fields in the m Line On reception of a FloorInfoWanted message, the floor control server
follows the rules in Section 9.2 which relate to client
authentication. If while processing the FloorRelease message, the
floor control server encounters an error, it SHOULD generate an Error
response following the procedures described in Section 13.7
According to RFC 2327 [5], the m-line format is the following: A floor control server receiving a FloorInfoWanted message from a
client SHOULD keep this client informed about the status of the
floors identified by FLOOR-ID TLVs in the FloorInfoWanted message.
Floor Control Servers keep clients informed by using FloorInfo
messages.
m=<media> <port> <transport> <fmt list> An individual FloorInfo message carries information about a single
floor. So, when a FloorInfoWanted message requests information about
more than one floors, the floor control server needs to send separate
FloorInfo messages for different floors.
The media field MUST have a value of "application". The port field The information FloorInfoWanted messages carry may depend on the user
is not used by BFCP, and MAY be set to any value chosen by the requesting the information. For example, a chair may be able to
endpoint. A port field value of zero has the standard SDP meaning receive information about pending requests while a regular user may
(i.e., rejection of the media stream). not be authorized to do so.
The port field is set following the rules in [14]. Depending on the 13.4.1 Generation of the First FloorInfo Message
value of the setup attribute (disccused in Section 18.4), the port
field contains the port the remote endpoint will initiate its TCP
connection to, or is irrelevant (i.e., the endpoint will initiate the
connection towards the remote endpoint) and should be set to a value
of 9, which is the discard port. Since BFCP only runs on top of TCP,
the port is always a TCP port.
We define two new values for the transport field: TCP/BFCP and TCP/ The successful processing of a FloorInfoWanted message by a floor
TLS/BFCP. control server involves generating one or several FloorInfo messages,
the first of which SHOULD be generated as soon as possible.
The fmt (format) list is ignored for BFCP. The fmt list of BFCP m The floor control server copies the Conference ID, the
lines SHOULD contain a single "*" character. TRANSACTION-ID, and the USER-ID TLVs from the FloorInfoWanted message
into the FloorInfo message, as described in Section 8.2.
The following is an example of an m line for a BFCP connection: If the FloorInfoWanted message did not contain any FLOOR-ID TLV, the
floor control server sends the FloorInfo message without adding any
additional TLV and does not send any subsequent FloorInfo message to
the floor participant.
m=application 20000 TCP/BFCP * If the FloorInfoWanted message contained one or more FLOOR-ID TLVs,
the floor control server chooses one among them and adds this
FLOOR-ID TLV to the FloorInfo message. The floor control server adds
a FLOOR-REQUEST-ID TLV for each floor request associated to the
floor. Each FLOOR-REQUEST-ID TLV is followed by a number of TLVs
which provide information about the floor request.
18.2 The confid and userid SDP Parameters For each FLOOR-REQUEST-ID TLV, the floor control server may add a
BENEFICIARY-ID TLV identifying the requester of the floor and a
USER-DISPLAY-NAME TLV, a USER-URI TLV, or both providing information
about the requester. Additionally, the floor control server adds
FLOOR-ID TLVs to the FloorInfo message identifying the floors being
requested (i.e., the floors associated with the floor request
identified by the FLOOR-REQUEST-ID TLV).
We define the confid and the userid SDP media-level attributes. The floor control server may also add a PRIORITY TLV with the
Their syntax is: Priority value requested for the floor request and a
HUMAN-READABLE-INFO TLV with extra information about the floor
request.
confid-attribute = "a=confid: " conference-id The floor control server adds a REQUEST-STATUS TLV with the current
conference-id = token status of the floor request.
userid-attribute = "a=userid: " user-id 13.4.2 Generation of Subsequent FloorInfo Messages
user-id = token
The confid and the userid attributes carry the integer representation If the FloorInfoWanted message carried more than one FLOOR-ID TLV,
of a conference ID and a user ID respectively. the floor control server SHOULD generate a FloorInfo message for each
of them (except for the FLOOR-ID TLV 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.4.1, but without adding a TRANSACTION TLV.
Endpoints which use the offer/answer model to establish BFCP After generating these messages, the floor control server sends
connections MUST support the confid and the userid attributes. A FloorInfo messages periodically keeping the client informed about all
floor control server acting as an offerer or as an answerers SHOULD the floors the client requested information about. These messages
include these attributes in its session descriptions. MUST NOT carry a TRANSACTION-ID TLV.
18.3 The k line The rate at which the floor control server sends FloorInfo
messages is a matter of local policy. A floor control server may
choose to send a new FloorInfo message every time a new floor
request arrives while another may choose to only send a new
FloorInfo message when a new floor request is Granted.
If the offer/answer exchange is encrypted and integrity protected, 13.5 Reception of a ChairAction Message
the offerer MAY use an SDP k line to provide the answerer with a
shared secret to be used to calculate the value of the INTEGRITY
TLVs. The following is an example of a k line:
k=base64:c2hhcmVkLXNlY3JldA== On reception of a ChairAction message, the floor control server
follows the rules in Section 9.2 which relate to client
authentication and authorization. If while processing the
ChairAction message, the floor control server encounters an error, it
SHOULD generate an Error response following the procedures described
in Section 13.7
18.4 TCP Connection Management The successful processing of a ChairAction message by a floor control
server involves generating a ChairActionAck message, which SHOULD be
generated as soon as possible.
The management of the TCP connection used to transport BFCP is The floor control server copies the Conference ID, the
performed using the setup and connid attributes as defined in [14]. TRANSACTION-ID, and the USER-ID TLVs from the ChairAction message
into the ChairActionAck message, as described in Section 8.2.
The setup attribute indicates which of the endpoints (client or floor The floor control server needs to take into consideration the
control server) initiates the TCP connection. The connid attribute operation requested in the ChairAction message (e.g., granting a
handles TCP connection reestablishment. floor), but does not necessarily need to perform it as requested by
the floor chair. The operation that the floor control server
performs depends on the ChairAction message and on the internal state
of the floor control server.
Editor's note: need to address loss and re-establishment of TCP For example, a floor chair may send a ChairAction message granting a
connections. floor which was requested as part of an atomic floor request
operation that involved several floors. Even if the chair
responsible for one of the floors instructs the floor control server
to grant the floor, the floor control server will not grant it until
the chairs responsible for the other floors agree to grant them as
well.
18.5 Association between Streams and Floors So, the floor control server is ultimately responsible to keep a
coherent floor state using instructions from floor chairs as input to
this state.
EDITOR'S NOTE: We need a way for clients that don't support CPCP to If the new Status in the ChairAction message is Accepted and all the
at a minimum learn enough information about floors to use the floor bits of the Queue Position field are zero, the floor participant is
control protocol. This section will need to be harmonized with the requesting the floor control server to assign a queue position (e.g.,
media policy work. the last in the queue) to the floor request based on the local policy
of the floor control server. (Of course, such as request only
applies in case the floor control server implements a queue.)
We define the floorid SDP media-level attribute. Its syntax is: 13.6 Reception of a Hello Message
floor-id-attribute = "a=floorid:" token " mstream:" 1*(token) On reception of a Hello message, the floor control server follows the
rules in Section 9.2 which relate to client authentication. If while
processing the Hello message, the floor control server encounters an
error, it SHOULD generate an Error response following the procedures
described in Section 13.7
The floorid attribute is used in BFCP m lines and associates a floor The successful processing of a Hello message by a floor control
ID with a media stream. The token representing the floor ID is the server involves generating a HelloAck message, which SHOULD be
integer representation of the 16-bit floorid to be used in BFCP. The generated as soon as possible. The floor control server copies the
token representing the media stream is a pointer to the media stream, Conference ID, the TRANSACTION-ID, and the USER-ID TLVs from the
which is identified by an SDP label attribute Hello into the HelloAck, as described in Section 8.2.
[draft-levin-mmmusic-sdp-media-label-00.txt].
Endpoints which use the offer/answer model to establish BFCP The floor control server adds a SUPPORTED-TLVS TLV to the HelloAck
connections MUST support the floorid and the label attributes. A message listing all the TLVs supported by the floor control server.
floor control server acting as an offerer or as an answerers SHOULD
include these attributes in its session descriptions.
18.6 Example 13.7 Error Message Generation
The following is an example of an offer sent by a conference server Error messages are always sent in response to a previous message from
to a user. For the purpose of brevity, the main portion of the the client as part of a client-initiated transaction. The ABNF in
session description is omitted in the examples, which only show m= Section 5.3.11 describes the TLVs that an Error message can contain.
lines and their attributes.
m=application 20000 TCP/BFCP * In addition, the ABNF specifies normatively which of these TLVs are
k=base64:c2hhcmVkLXNlY3JldA== mandatory, and which ones are optional.
a=setup:passive
a=connid:1
a=confid:4321
a=userid:1234
a=floorid:1 m-stream:10
a=floorid:2 m-stream:11
m=audio 20000 RTP/AVP 0
a=label:10
m=video 30000 RTP/AVP 31
a=label:11
The following is the answer returned by the user. The floor control server copies the Conference ID, the
TRANSACTION-ID, and the USER-ID TLVs from the message from the client
into the Error message, as described in Section 8.2.
m=application 9 TCP/BFCP * The floor control server adds an ERROR-CODE TLV to the Error message.
a=setup:active The ERROR-CODE TLV contains an Error Code from Table 4.
a=connid:1 Additionally, the floor control server may add a HUMAN-READABLE-INFO
m=audio 25000 RTP/AVP 0 TLV with extra information about the error.
m=video 35000 RTP/AVP 31
19. Security Considerations 14. Security Considerations
TBD. TBD.
20. IANA Considerations 15. IANA Considerations
TBD TBD
20.1 SDP Attributes Registration 16. Acknowledgments
TBD:
21. 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, and Miguel A. Garcia-Martin provided useful
comments. comments.
22. References 17. References
22.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. 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", RFC
2246, January 1999. 2246, January 1999.
[5] Handley, M. and V. Jacobson, "SDP: Session Description [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
Protocol", RFC 2327, April 1998. 63, RFC 3629, November 2003.
[6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[7] Petke, R. and I. King, "Registration Procedures for URL Scheme
Names", BCP 35, RFC 2717, November 1999.
[8] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal 17.2 Informational References
IPv6 Addresses in URL's", RFC 2732, December 1999.
[9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [6] Handley, M. and V. Jacobson, "SDP: Session Description
specifying the location of services (DNS SRV)", RFC 2782, Protocol", RFC 2327, April 1998.
February 2000.
[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [8] 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.
[12] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [9] Schulzrinne, H., "Requirements for Floor Control Protocol",
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[14] Yon, D., "Connection-Oriented Media Transport in the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-08
(work in progress), July 2004.
22.2 Informational References
[15] Schulzrinne, H., "Requirements for Floor Control Protocol",
draft-ietf-xcon-floor-control-req-01 (work in progress), July draft-ietf-xcon-floor-control-req-01 (work in progress), July
2004. 2004.
[16] Koskelainen, P. and H. Khartabil, "An Extensible Markup [10] Koskelainen, P. and H. Khartabil, "An Extensible Markup
Language (XML) Configuration Access Protocol (XCAP) Usage for Language (XML) Configuration Access Protocol (XCAP) Usage for
Conference Policy Manipulation", Conference Policy Manipulation",
draft-koskelainen-xcon-xcap-cpcp-usage-02 (work in progress), draft-koskelainen-xcon-xcap-cpcp-usage-02 (work in progress),
February 2004. February 2004.
[17] Rosenberg, J. and H. Schulzrinne, "A Session Initiation [11] Rosenberg, J. and H. Schulzrinne, "A Session Initiation
Protocol (SIP) Event Package for Conference State", Protocol (SIP) Event Package for Conference State",
draft-ietf-sipping-conference-package-05 (work in progress), draft-ietf-sipping-conference-package-05 (work in progress),
July 2004. July 2004.
[18] Arkko, J., "MIKEY: Multimedia Internet KEYing", [12] Arkko, J., "MIKEY: Multimedia Internet KEYing",
draft-ietf-msec-mikey-08 (work in progress), December 2003. draft-ietf-msec-mikey-08 (work in progress), December 2003.
[19] Rosenberg, J., "An Extensible Markup Language (XML) Document [13] Rosenberg, J., "An Extensible Markup Language (XML) Document
Format for Indicating Changes in XML Configuration Access Format for Indicating Changes in XML Configuration Access
Protocol (XCAP) Resources", draft-ietf-simple-xcap-package-02 Protocol (XCAP) Resources", draft-ietf-simple-xcap-package-02
(work in progress), July 2004. (work in progress), July 2004.
[14] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-02 (work in
progress), June 2004.
[15] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams",
draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), April
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
 End of changes. 

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