draft-ietf-xcon-bfcp-00.txt   draft-ietf-xcon-bfcp-01.txt 
XCON Working Group G. Camarillo XCON Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: January 4, 2005 J. Ott Expires: February 17, 2005 J. Ott
Universitaet Bremen Universitaet Bremen
K. Drage K. Drage
Lucent Technologies Lucent Technologies
July 6, 2004 August 19, 2004
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-xcon-bfcp-00.txt draft-ietf-xcon-bfcp-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with 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 become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
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 January 4, 2005. This Internet-Draft will expire on February 17, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
Floor control is a means to manage joint or exclusive access to
shared resource in a (multiparty) conferencing environment. Thereby,
floor control complements other functions -- such as conference and
media session setup, conference policy manipulation, and media
control -- that are realized by other protocols.
This document specicies the Binary Floor Control Protocol (BFCP). This document specicies the Binary Floor Control Protocol (BFCP).
BFCP is used between conference participants and floor control BFCP is used between conference participants and floor control
servers, and between floor chairs (i.e., moderators) and floor servers, and between floor chairs (i.e., moderators) and floor
control servers. control servers.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Obtaining Information to Contact a BFCP Floor Server . . . 6 3.2 Obtaining Information to Contact a BFCP Floor Server . . . 7
3.3 Generating a Shared Secret . . . . . . . . . . . . . . . . 6 3.3 Generating a Shared Secret . . . . . . . . . . . . . . . . 7
3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 7 3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 7
3.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . 7 3.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . 8
4. Overview of Operation . . . . . . . . . . . . . . . . . . . 8 4. Overview of Operation . . . . . . . . . . . . . . . . . . . 8
4.1 User - Floor Control Server Interface . . . . . . . . . . 8 4.1 User - Floor Control Server Interface . . . . . . . . . . 9
4.2 Floor Chair - Floor Control Server Interface . . . . . . . 10 4.2 Floor Chair - Floor Control Server Interface . . . . . . . 11
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 11 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 11 5.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 12
5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 12 5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 13
5.2.1 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.1 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.2 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.2 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.3 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 13 5.2.3 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 14
5.2.4 REQUEST-ID . . . . . . . . . . . . . . . . . . . . . . 13 5.2.4 TRANSACTION-ID . . . . . . . . . . . . . . . . . . . . 15
5.2.5 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 14 5.2.5 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 15
5.2.6 HUMAN-READABLE-INFO . . . . . . . . . . . . . . . . . 14 5.2.6 HUMAN-READABLE-INFO . . . . . . . . . . . . . . . . . 15
5.2.7 INTEGRITY . . . . . . . . . . . . . . . . . . . . . . 14 5.2.7 INTEGRITY . . . . . . . . . . . . . . . . . . . . . . 16
5.2.8 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 15 5.2.8 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 16
5.2.9 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 16 5.2.9 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 17
5.2.10 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 17 5.2.10 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 19
5.2.11 USER-URI . . . . . . . . . . . . . . . . . . . . . . 17 5.2.11 USER-URI . . . . . . . . . . . . . . . . . . . . . . 19
5.2.12 PRIORITY . . . . . . . . . . . . . . . . . . . . . . 18 5.2.12 PRIORITY . . . . . . . . . . . . . . . . . . . . . . 19
5.2.13 PRIVACY . . . . . . . . . . . . . . . . . . . . . . 18 6. Message Format . . . . . . . . . . . . . . . . . . . . . . . 19
6. Message Format . . . . . . . . . . . . . . . . . . . . . . . 18 6.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . . . 19
6.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . . . 18 6.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . . . 19 6.3 FloorRequestInfo . . . . . . . . . . . . . . . . . . . . . 20
6.3 FloorRequestInfo . . . . . . . . . . . . . . . . . . . . . 19 6.4 FloorRequestStatus . . . . . . . . . . . . . . . . . . . . 20
6.4 FloorRequestStatus . . . . . . . . . . . . . . . . . . . . 19 6.5 FloorInfo . . . . . . . . . . . . . . . . . . . . . . . . 21
6.5 FloorInfo . . . . . . . . . . . . . . . . . . . . . . . . 20 6.6 FloorStatus . . . . . . . . . . . . . . . . . . . . . . . 21
6.6 FloorStatus . . . . . . . . . . . . . . . . . . . . . . . 20 6.7 ChairAction . . . . . . . . . . . . . . . . . . . . . . . 22
6.7 ChairAction . . . . . . . . . . . . . . . . . . . . . . . 21 6.8 ChairActionAck . . . . . . . . . . . . . . . . . . . . . . 22
6.8 ChairActionAck . . . . . . . . . . . . . . . . . . . . . . 21 6.9 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.9 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.10 PingAck . . . . . . . . . . . . . . . . . . . . . . . . 22
6.10 PingAck . . . . . . . . . . . . . . . . . . . . . . . . 21 6.11 Error . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.11 Error . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 23
8. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 22 9. Protocol Transactions . . . . . . . . . . . . . . . . . . . 23
9. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 24
10. Protocol Transactions . . . . . . . . . . . . . . . . . . . 23 9.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 24
10.1 Client Behavior . . . . . . . . . . . . . . . . . . . . 23 10. Authentication . . . . . . . . . . . . . . . . . . . . . . . 24
10.2 Server Behavior . . . . . . . . . . . . . . . . . . . . 23 10.1 Client Behavior . . . . . . . . . . . . . . . . . . . . 24
11. Authentication . . . . . . . . . . . . . . . . . . . . . . . 24 10.2 Server Behavior . . . . . . . . . . . . . . . . . . . . 25
11.1 Client Behavior . . . . . . . . . . . . . . . . . . . . 24 11. Client Operations . . . . . . . . . . . . . . . . . . . . . 25
11.2 Server Behavior . . . . . . . . . . . . . . . . . . . . 24 11.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 25
12. Client Operations . . . . . . . . . . . . . . . . . . . . . 25 11.1.1 Receiving a Response . . . . . . . . . . . . . . . . 26
12.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 25 12. Requesting Information about Floor Requests . . . . . . . . 27
12.1.1 Receiving a Response . . . . . . . . . . . . . . . . 26 12.1 Receiving a Response . . . . . . . . . . . . . . . . . . 27
12.2 Modifying a Floor Request . . . . . . . . . . . . . . . 26 13. Cancelling a Floor Request and Releasing a Floor . . . . . . 28
12.2.1 Receiving a Response . . . . . . . . . . . . . . . . 27 13.1 Receiving a Response . . . . . . . . . . . . . . . . . . 28
12.3 Requesting Information about Floor Requests . . . . . . 27 14. Requesting Information about Floors . . . . . . . . . . . . 28
12.3.1 Receiving a Response . . . . . . . . . . . . . . . . 28 14.1 Receiving a Response . . . . . . . . . . . . . . . . . . 29
12.4 Cancelling a Floor Request and Releasing a Floor . . . . 28 15. Checking the Liveness of a Server . . . . . . . . . . . . . 29
12.4.1 Receiving a Response . . . . . . . . . . . . . . . . 28 15.1 Receiving Responses . . . . . . . . . . . . . . . . . . 30
12.5 Requesting Information about Floors . . . . . . . . . . 29 16. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 30
12.5.1 Receiving a Response . . . . . . . . . . . . . . . . 29 16.1 Obtaining Information about Floor Requests . . . . . . . 30
12.6 Checking the Liveness of a Server . . . . . . . . . . . 30 16.2 Instructing the Floor Control Server . . . . . . . . . . 30
12.6.1 Receiving Responses . . . . . . . . . . . . . . . . 30 16.2.1 Receiving a Response . . . . . . . . . . . . . . . . 31
13. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 30 17. Server Operations . . . . . . . . . . . . . . . . . . . . . 32
13.1 Obtaining Information about Floor Requests . . . . . . . 30 17.1 Reception of a FloorRequest Message . . . . . . . . . . 32
13.2 Instructing the Floor Control Server . . . . . . . . . . 30 17.2 Reception of a FloorRequestInfo Message . . . . . . . . 33
13.2.1 Receiving a Response . . . . . . . . . . . . . . . . 32 17.3 Reception of a FloorRelease Message . . . . . . . . . . 33
14. Server Operations . . . . . . . . . . . . . . . . . . . . . 32 17.4 Reception of a FloorInfo Message . . . . . . . . . . . . 34
14.1 Reception of a FloorRequest Message . . . . . . . . . . 32 17.5 Reception of a ChairAction Message . . . . . . . . . . . 35
14.1.1 Floor Request Modification . . . . . . . . . . . . . 33 17.6 Reception of a Ping Message . . . . . . . . . . . . . . 35
14.2 Reception of a FloorRequestInfo Message . . . . . . . . 33 17.7 Error Message Generation . . . . . . . . . . . . . . . . 36
14.3 Reception of a FloorRelease Message . . . . . . . . . . 34 18. BFCP and the Offer/Answer Model . . . . . . . . . . . . . . 36
14.4 Reception of a FloorInfo Message . . . . . . . . . . . . 34 18.1 Fields in the m Line . . . . . . . . . . . . . . . . . . 36
14.5 Reception of a ChairAction Message . . . . . . . . . . . 35 18.2 The confid and userid SDP Parameters . . . . . . . . . . 37
14.6 Reception of a Ping Message . . . . . . . . . . . . . . 36 18.3 The k line . . . . . . . . . . . . . . . . . . . . . . . 37
14.7 Error Message Generation . . . . . . . . . . . . . . . . 36 18.4 TCP Connection Management . . . . . . . . . . . . . . . 37
15. BFCP and the Offer/Answer Model . . . . . . . . . . . . . . 36 18.5 Association between Streams and Floors . . . . . . . . . 38
15.1 Fields in the m Line . . . . . . . . . . . . . . . . . . 37 18.6 Example . . . . . . . . . . . . . . . . . . . . . . . . 38
15.2 The confid and userid SDP Parameters . . . . . . . . . . 37 19. Security Considerations . . . . . . . . . . . . . . . . . . 39
15.3 The k line . . . . . . . . . . . . . . . . . . . . . . . 38 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39
15.4 TCP Connection Management . . . . . . . . . . . . . . . 38 20.1 SDP Attributes Registration . . . . . . . . . . . . . . 39
15.5 Association between Streams and Floors . . . . . . . . . 38 21. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 39
15.6 Example . . . . . . . . . . . . . . . . . . . . . . . . 39 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
16. Security Considerations . . . . . . . . . . . . . . . . . . 39 22.1 Normative References . . . . . . . . . . . . . . . . . . . 39
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39 22.2 Informational References . . . . . . . . . . . . . . . . . 40
17.1 SDP Attributes Registration . . . . . . . . . . . . . . 39
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 40
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
19.1 Normative References . . . . . . . . . . . . . . . . . . . 40
19.2 Informational References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . 42
1. Introduction 1. Introduction
Some applications (e.g., conference applications) need to manage the Within a (multimedia) conference, some applications (e.g., conference
access to a set of shared resources, such as the right to send media applications) need to manage the access to a set of shared resources,
over a particular media stream. Floor control enables such such as the right to send media over a particular media stream.
applications to provide users with safe access to these resources. Floor control enables such applications to provide users with
coordinated (shared or exclusive) access to these resources.
The Requirements for Floor Control Protocol [15] list a set of The Requirements for Floor Control Protocol [15] 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 Section 2 defines the terminology used throughout this document and
Section 3 discusses the scope of BFCP (i.e., which tasks fall within Section 3 discusses the scope of BFCP (i.e., which tasks fall within
the scope of BFCP and which ones are performed using different the scope of BFCP and which ones are performed using different
mechanisms). Section 4 provides a non-normative overview of BFCP mechanisms). Section 4 provides a non-normative overview of BFCP
skipping to change at page 5, line 18 skipping to change at page 5, line 19
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 participants receive media from which other participants, and the
ways in which that media is combined for each participant. In the ways in which that media is combined for each participant. In the
case of audio, these rules can include the relative volumes at which case of audio, these rules can include the relative volumes at which
each participant is mixed. In the case of video, these rules can each participant is mixed. In the case of video, these rules can
indicate whether the video is tiled, whether the video indicates the indicate whether the video is tiled, whether the video indicates the
loudest speaker, and so on. loudest speaker, and so on.
EDITOR'S NOTE: we may want to reference the definitions in the
conferencing framework. If we decide to copy them here, we need to
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
shared resources in a conference setting following the requirements
defined in [15]. Floor control complements other functions defined
in the conference framework, such as conference policy and media
policy. In particular, it is the conference policy that defines
which media streams and applications are floor-controlled, who is/are
the respective floor chair(s), and how access to the floor is
managed. Furthermore, it is up to the media policy to define which
(if any) impact on media stream handling (e.g. switching or mixing)
assignment of a floor to a participant has.
The floor control protocol BFCP defined in this document only
specifies a means to arbitrate access to floors. The rules and
constraints for floor arbitration and the results of floor
assignments are outside the scope of this document and defined by the
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
skipping to change at page 6, line 8 skipping to change at page 6, line 38
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 users.
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 users and floor chairs informed
about the status of a given floor. about the status of a given floor.
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 sections, we connections between different entities. In the following
discuss some of these tasks and mechanisms to perform them. subsections, we discuss some of these tasks and mechanisms to perform
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 to each of the conference and the resource or resources associated with each
floor. For example, a conference may have two floors: one controlling floor. For example, a conference may have two floors: one
who can talk at a particular time and another controlling who can controlling who can talk at a particular time and another controlling
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 [16]. Consequently, floor creation and termination is handled by
CPCP. In addition, CPCP also handles the association of a given floor CPCP. In addition, CPCP also handles the association of a given
with a resource or a set of resources (e.g., media streams). 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 XCAP event package
[19] to keep itself up to date. [19] to keep itself up to date.
3.2 Obtaining Information to Contact a BFCP Floor Server 3.2 Obtaining Information to Contact a BFCP Floor Server
A user or a floor chair needs a set of data in order to establish a A user or a floor chair needs a set of data in order to establish a
BFCP connection to a floor control server. These data include the BFCP connection to a floor control server. These data include the
transport address of the server, the conference identifier, and the transport address of the server, the conference identifier, and the
user identifier. user identifier.
Users can obtain this information in different ways. Two Users 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 the offer/answer [11] exchange
which is used to establish media streams between the user and the which is used to establish media streams between the user and the
conference server. Section 15 discusses how to use an SDP [5] offer/ conference server. Section 18 discusses how to use an SDP [5] offer/
answer [11] exchange to obtain this information. 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 and integrity protection in BFCP are based on a shared
secret between the user or floor chair, and the floor control server. secret between the user or floor chair, and the floor control server.
So, there is a need for a mechanism to generate such a shared secret. So, there is a need for a mechanism to generate such a shared secret.
When the user or the floor control chair obtains a the information When the user or the floor control chair obtains a the information
needed to contact the BFCP floor server over a secure channel (e.g., needed to contact the BFCP floor server over a secure channel (e.g.,
an offer/answer exchange using SIP [10] protected using S/MIME), they an offer/answer exchange using SIP [10] protected using S/MIME), they
can get the shared secret using the same channel. 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 answerer to be used. For example, MIKEY [18] allows an offerer and an
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
here.
3.4 Obtaining Floor-Resource Associations 3.4 Obtaining Floor-Resource Associations
Floors are associated to 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 to Users and floor chairs need to know which resources are associated
which floors. They can obtain this information using different with which floors. They can obtain this information using different
mechanisms, such as CPCP or an offer/answer [11] exchange. Section 15 mechanisms, such as CPCP or an offer/answer [11] exchange. Section
describes how to use an offer/answer exchange to obtain these 18 describes how to use an offer/answer exchange to obtain these
associations. associations.
Note that users perform offer/answer exchanges with the SIP focus Note that users perform offer/answer exchanges with the SIP focus
of the conference. So, the SIP focus needs to obtain information of the conference. So, the SIP focus needs to obtain information
about associations between floors and resources using a mechanism about associations between floors and resources using a mechanism
such as CPCP in order to be able to provide this information to a such as CPCP in order to be able to provide this information to a
user in an offer/answer exchange. user 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 user whose floor request is granted has the right to use in a
certain way the resource or resources associated to the floor that certain way the resource or resources associated with the floor that
was requested. For example, the user may have the right to talk was requested. For example, the user may have the right to talk
(i.e., send media over a particular audio stream). (i.e., 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 users can actually use the resources in the
conference. 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 another ways to enforce floor control Nevertheless, there are other ways to enforce floor control policies,
policies, such as having a floor control chair manipulate the media such as having a floor control chair manipulate the media policy
policy (using CPCP) only if there are misbehaving users trying to use (using CPCP) only if there are misbehaving users trying to use a
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 users and floor control
servers and Section 4.2 describes the interface between floor chairs servers and Section 4.2 describes the interface between floor chairs
and floor control servers 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,
which consist of a common header followed by a set of TLVs. The consist of a common header followed by a set of TLVs. The common
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. Users and floor chairs are identified by a 16-bit user
identifier, which is carried in a TLV. identifier, which is carried in a TLV.
4.1 User - Floor Control Server Interface 4.1 User - Floor Control Server Interface
Users request a floor by sending a FloorRequest message to the floor Users request a floor by sending a FloorRequest message to the floor
control server. BFCP supports third party floor requests. That is, control server. BFCP supports third party floor requests. That is,
the user sending the floor request need not be the same as the user 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. who will get the floor once the floor request is granted.
FloorRequest messages carry the identity of the requester in a FloorRequest messages carry the identity of the requester in a
USER-ID TLV, and the identity of the beneficiary of the floor, in 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, in a BENEFICIARY-ID TLV.
Third party floor requests can be sent by users that have a BFCP Third party floor requests can be sent by users that have a BFCP
connection to the floor control server, but who are not conference connection to the floor control server, but who are not conference
participants (i.e., they do not handle any media). participants (i.e., they do not handle any media).
XXX: Users need a means to authorize 3rd parties to request floors
on their behalf. CPCP?
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.
Users can request privacy by including a PRIVACY TLV in their EDITOR'S NOTE: we need to explain in this paragraph that if a user is
FloorRequest messages. In this case, the floor control server does anonymous, the floor control server does not disclose the identity of
not disclose the identity of the requester of the floor to the rest the requester of the floor to the rest of the users and floor chairs.
of the users and floor chairs.
Floor control servers respond to FloorRequest messages with Floor control servers respond to FloorRequest messages with
FloorStatus messages. FloorStatus messages.
Editor's note: This section will be finished when we have agreed on Editor's note: This section will be finished when we have agreed on
what it is specified in the rest of this document. For the time what it is specified in the rest of this document. For the time
being, below there are two typical call flows: a client requesting a being, below there are two typical call flows: a client requesting a
floor and a client requesting information about a floor. floor and a client requesting information about a floor.
Client Floor Control Client Floor Control
skipping to change at page 9, line 42 skipping to change at page 10, line 29
| FLOOR-REQUEST-ID: 345 | | FLOOR-REQUEST-ID: 345 |
|----------------------------->| |----------------------------->|
| | | |
| FloorRequestStatus | | FloorRequestStatus |
| TRANSACTION-ID: 124 | | TRANSACTION-ID: 124 |
| FLOOR-REQUEST-ID: 345 | | FLOOR-REQUEST-ID: 345 |
| REQUEST-STATUS: Released | | REQUEST-STATUS: Released |
|<-----------------------------| |<-----------------------------|
| | | |
Figure 2: Requesting and releasing a floor
Client or Floor Control Client or Floor Control
Chair Server Chair Server
| FloorInfo | | FloorInfo |
| TRANSACTION-ID: 123 | | TRANSACTION-ID: 123 |
| FLOOR-ID: 15 | | FLOOR-ID: 15 |
|----------------------------->| |----------------------------->|
| | | |
|FloorStatus | |FloorStatus |
| TRANSACTION-ID: 123 | | TRANSACTION-ID: 123 |
skipping to change at page 10, line 26 skipping to change at page 11, line 32
| FLOOR-ID: 15 | | FLOOR-ID: 15 |
| FLOOR-REQUEST-ID: 348 | | FLOOR-REQUEST-ID: 348 |
| REQUEST-STATUS: Granted | | REQUEST-STATUS: Granted |
|<-----------------------------| |<-----------------------------|
| | | |
|FloorStatus | |FloorStatus |
| FLOOR-ID: 15 | | FLOOR-ID: 15 |
|<-----------------------------| |<-----------------------------|
| | | |
Figure 3: Obtaining status information about a floor
4.2 Floor Chair - Floor Control Server Interface 4.2 Floor Chair - Floor Control Server Interface
TBD. For the time being, below there is the typical call flow for TBD. For the time being, below there is the typical call flow for
this interface. this interface.
Chair Floor Control Chair Floor Control
Server Server
| ChairAction | | ChairAction |
| TRANSACTION-ID: 123 | | TRANSACTION-ID: 123 |
| FLOOR-ID: 15 | | FLOOR-ID: 15 |
| FLOOR-REQUEST-ID: 345 | | FLOOR-REQUEST-ID: 345 |
| REQUEST-STATUS: Granted | | REQUEST-STATUS: Granted |
|----------------------------->| |----------------------------->|
| | | |
| ChairActionAck | | ChairActionAck |
| TRANSACTION-ID: 123 | | TRANSACTION-ID: 123 |
|<-----------------------------| |<-----------------------------|
| | | |
Figure 4: Chair invoking an action at 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.
skipping to change at page 13, line 34 skipping to change at page 15, line 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 = 2 |M| Length | Beneficiary ID | | Type = 2 |M| Length | Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 REQUEST-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 contents of the TRANSACTION-ID
attribute, whose attribute type is 3. 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 | | Type = 3 |M| Length | Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 34 skipping to change at page 16, line 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 = 4 |M| Length | | | Type = 4 |M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Text: this field contains UTF-8 [13] encoded text. Text: this field contains UTF-8 [13] 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 automata. If such automata has information about the preferred by an automaton. If such automaton has information about the
language of the receiver of a particular HUMAN-READABLE-INFO TLV, it preferred language of the receiver of a particular
may use this language to generate the Text field. HUMAN-READABLE-INFO TLV, it MAY use this language to generate the
Text field.
Padding: one, two, or three bytes of padding added so that the 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 INTEGRITY
The following is the format of the contents of the INTEGRITY The following is the format of the contents of the INTEGRITY
skipping to change at page 15, line 23 skipping to change at page 16, line 40
| | | |
+ HMAC-SHA1 + + HMAC-SHA1 +
| | | |
+ + + +
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 11. message. Its calculation is described in Section 10.
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 contents of the REQUEST-STATUS
attribute, whose attribute type is 7. attribute, whose attribute type is 7.
skipping to change at page 16, line 49 skipping to change at page 18, line 17
| Error Specific Details | | Error Specific Details |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 0 Conference does not Exist
1 Authentication Failed 1 Authentication Failed
2 Unknown Mandatory TLV 2 Unknown Mandatory TLV
3 Floor Request ID Does Not Exist 3 Floor Request ID Does Not Exist
4 Unauthorized Operation 4 Unauthorized Operation
5 User does not Exist 5 User does not Exist
6 Invalid Request-ID 6 Invalid Request-ID
7 INTEGRITY TLV Required 7 INTEGRITY TLV Required
Error Specific Details: Present only for certain Error Codes. In this Error Specific Details: Present only for certain Error Codes. In
document, only for Error Code 2 (Unknown Mandatory TLV). For Error this document, only for Error Code 2 (Unknown Mandatory TLV). For
Code 2, this field contains the Types of the TLVs (which were present Error Code 2, this field contains the Types of the TLVs (which were
in the message that triggered the Error message) that were unknown to present in the message that triggered the Error message) that were
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 24 skipping to change at page 19, line 39
| Type = 7 |M| Length | Priority | Reserved | | Type = 7 |M| Length | Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
5.2.13 PRIVACY
The following is the format of the contents of the PRIVACY attribute,
whose attribute type is 12.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 |M| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: at this point, the 16 bits in the reserved field SHOULD be
set to zero by the sender of the message and MUST be ignored by the
receiver.
6. Message Format 6. Message Format
This section contains the ABNF [3] of the BFCP messages. This section contains the ABNF [3] of the BFCP messages.
6.1 FloorRequest 6.1 FloorRequest
Clients request a floor by sending a FloorRequest message to the Clients request a floor by sending a FloorRequest message to the
floor control server. In addition, the FloorRequest message is also floor control server. In addition, the FloorRequest message is also
used to modify existing floor requests. The following is the format used to modify existing floor requests. The following is the format
of the FloorRequest message: of the FloorRequest message:
FloorRequest = (FIXED-HEADER) FloorRequest = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
[BENEFICIARY-ID] [BENEFICIARY-ID]
[PRIVACY]
[FLOOR-REQUEST-ID] [FLOOR-REQUEST-ID]
*(FLOOR-ID) *(FLOOR-ID)
[HUMAN-READABLE-INFO] [HUMAN-READABLE-INFO]
[PRIORITY] [PRIORITY]
[INTEGRITY] [INTEGRITY]
6.2 FloorRelease 6.2 FloorRelease
Clients release a floor by sending a FloorRelease message to the Clients release a floor by sending a FloorRelease message to the
floor control server. Clients also use the FloorRelease message to floor control server. Clients also use the FloorRelease message to
skipping to change at page 20, line 32 skipping to change at page 21, line 32
format of the FloorRequest message: format of the FloorRequest message:
FloorInfo = (FIXED-HEADER) FloorInfo = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
*(FLOOR-ID) *(FLOOR-ID)
[INTEGRITY] [INTEGRITY]
6.6 FloorStatus 6.6 FloorStatus
The floor control server informs clients about the holder of a floor The floor control server informs clients about the status, e.g., the
by sending them FloorStatus messages. The following is the format of current holder(s), of a floor by sending them FloorStatus messages.
the FloorStatus message: The following is the format of the FloorStatus message:
FloorStatus = (FIXED-HEADER) FloorStatus = (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)
skipping to change at page 21, line 45 skipping to change at page 22, line 45
message: message:
Ping = (FIXED-HEADER) Ping = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
[INTEGRITY] [INTEGRITY]
6.10 PingAck 6.10 PingAck
Servers confirm that they are alive on reception of a Ping message by Servers confirm that they are alive on reception of a Ping message by
sending a PingAck message. The following is the format of the PingAck sending a PingAck message. The following is the format of the
message: PingAck message:
PingAck = (FIXED-HEADER) PingAck = (FIXED-HEADER)
(TRANSACTION-ID) (TRANSACTION-ID)
(USER-ID) (USER-ID)
[INTEGRITY] [INTEGRITY]
6.11 Error 6.11 Error
The floor control server informs clients about errors processing The floor control server informs clients about errors processing
requests by sending them Error messages. The following is the format requests by sending them Error messages. The following is the format
skipping to change at page 22, line 30 skipping to change at page 23, line 30
[HUMAN-READABLE-INFO] [HUMAN-READABLE-INFO]
[INTEGRITY] [INTEGRITY]
7. Transport 7. 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
(e.g., that the TCP connection will be re-established in this case
using O/A as described further below).
8. Lower-Layer Security 8. Lower-Layer Security
BFCP relies on lower-layer security mechanisms to provide replay BFCP relies on lower-layer security mechanisms to provide replay
protection, and confidentiality. BFCP servers MUST support TLS [4], protection, and confidentiality. BFCP servers MUST support TLS [4],
and clients SHOULD support TLS. Clients and servers MAY support other and clients SHOULD support TLS. Clients and servers MAY support
security mechanisms. other security mechanisms.
OPEN ISSUE: do we want to implement replay-protection in the protocol OPEN ISSUE: do we want to implement replay-protection in the protocol
instead of relying on TLS? instead of relying on TLS?
Servers and clients that implement TLS MUST support XXX (cypher and Servers and clients that implement TLS MUST support TBD. (cypher and
hash algorithm). hash algorithm).
9. Privacy 9. Protocol Transactions
Clients may not want to disclose their identity to other users when
they request a floor. Clients can request privacy by adding a PRIVACY
TLV to their FloorRequest messages. This way, a client can request
privacy for a particular floor request, and not request it for
another one.
Floor control servers do not disclose the identity of the user
requesting a floor when privacy is requested (e.g., their
FloorRequestStatus messages do not contain a BENEFICIARY-ID TLV).
Nevertheless, if an attacker can get access to a given FloorRequest
message, it will be able to discover the ID of the user requesting
the floor, even if the message contains a PRIVACY TLV.
So, clients that want to avoid this attack need to implement
confidentiality underneath BFCP, as described in Section 8.
OPEN ISSUE: shall we define the PRIVACY TLV as a simple flag, or do
we want to have more options. For example, the floor control can
disclose the user's identity to the chair, but not to the rest of the
users.
10. 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. Client-initiated transactions and server-initiated transactions (notifications).
transactions consist of a request from a client to a server and a Client-initiated transactions consist of a request from a client to a
response from the server to the client. The request carries a server and a response from the server to the client. The request
TRANSACTION-ID TLV which the server copies into the response. Clients carries a TRANSACTION-ID TLV which the server copies into the
use Transaction ID values to match responses with previously-issued response. Clients use Transaction ID values to match responses with
requests. 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 server to a client. Consequently, 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 to them. associated with them.
10.1 Client Behavior 9.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. The client uses
the Transaction ID value to match this FloorRequest message with the the Transaction ID value to match this FloorRequest message with the
response from the floor control server. response from the floor control server.
10.2 Server Behavior 9.2 Server Behavior
A server sending a response within a client-initiated transaction A server sending a response within a client-initiated transaction
MUST copy the Conference ID and the TRANSACTION-ID TLV from the MUST copy the Conference ID and the TRANSACTION-ID TLV from the
request received from the client into the response. Server-initiated request received from the client into the response. Server-initiated
transactions MUST NOT contain a TRANSACTION-ID TLV. transactions MUST NOT contain a TRANSACTION-ID TLV.
11. Authentication 10. Authentication
BFCP uses the INTEGRITY TLV to provide client and server BFCP uses the INTEGRITY TLV to provide client and server
authentication, and message integrity. The INTEGRITY TLV contains an authentication, and message integrity. The INTEGRITY TLV contains an
HMAC-SHA1 [1] of the BFCP message. The use of SHA1 implies that the HMAC-SHA1 [1] of the BFCP message. The use of SHA1 implies that the
length of the HMAC is 20 bytes. The text used as input to HMAC is the length of the HMAC is 20 bytes. The text used as input to HMAC is
BFCP message, including the FIXED-HEADER, up to and including the TLV the BFCP message, including the FIXED-HEADER, up to and including the
preceding the INTEGRITY TLV. This text is then padded with zeroes so TLV preceding the INTEGRITY TLV. This text is then padded with
as to be a multiple of 64 bytes. As a result, the INTEGRITY TLV MUST zeroes so as to be a multiple of 64 bytes. As a result, the
be the last attribute in any BFCP message. The key used as input to INTEGRITY TLV MUST be the last attribute in any BFCP message. The
HMAC is the secret shared between the server and the user identified key used as input to HMAC is the secret shared between the server and
by the USER-ID TLV in the message. the user identified by the USER-ID TLV in the message.
11.1 Client Behavior 10.1 Client Behavior
Clients SHOULD add an INTEGRITY TLV to all their messages. Clients SHOULD add an INTEGRITY TLV to all their messages.
Furthermore, if a client generates a message without this TLV and Furthermore, if a client generates a message without this TLV and
receives an Error response with Error Code 7 (INTEGRITY TLV receives an Error response with Error Code 7 (INTEGRITY TLV
Required), the client SHOULD NOT send more messages without the Required), the client SHOULD NOT send more messages without the
INTEGRITY TLV to the same server within the same conference. INTEGRITY TLV to the same server within the same conference.
When a client receives a BFCP message with an INTEGRITY TLV, it When a client receives a BFCP message with an INTEGRITY TLV, it
calculates the HMAC-SHA1 [1] of the message excluding the INTEGRITY calculates the HMAC-SHA1 [1] of the message excluding the INTEGRITY
TLV. The key used as input to HMAC is the secret shared between the 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 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, the resulting value is the same as the one in the INTEGRITY TLV,
authentication is considered successful. If the resulting value is authentication is considered successful. If the resulting value is
different than the one in the INTEGRITY TLV, authentication is different than the one in the INTEGRITY TLV, authentication is
considered to have failed and the message MUST NOT be processed considered to have failed and the message MUST NOT be processed
further. further.
11.2 Server Behavior 10.2 Server Behavior
Servers SHOULD add an INTEGRITY TLV to all their messages. Servers SHOULD add an INTEGRITY TLV to all their messages.
Furthermore, if a client sends messages with this TLV to a server, Furthermore, if a client sends messages with this TLV to a server,
the server MUST include it as well in its messages to this client. the server MUST include it as well in its messages to this client.
If a client does not add an INTEGRITY TLV to a message, the server If a client does not add an INTEGRITY TLV to a message, the server
MAY request its addition by returning an Error message with Error MAY request its addition by returning an Error message with Error
Code 7 (INTEGRITY TLV Required). Code 7 (INTEGRITY TLV Required).
When a server receives a BFCP message with an INTEGRITY TLV, it When a server receives a BFCP message with an INTEGRITY TLV, it
skipping to change at page 25, line 11 skipping to change at page 25, line 41
server and the user identified by the USER-ID TLV in the message. If 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, the resulting value is the same as the one in the INTEGRITY TLV,
authentication is considered successful. authentication is considered successful.
If the resulting value is different than the one in the INTEGRITY If the resulting value is different than the one in the INTEGRITY
TLV, authentication is considered to have failed, in which case the TLV, authentication is considered to have failed, in which case the
server SHOULD return an Error message with Error Code 1 server SHOULD return an Error message with Error Code 1
(Authentication Failed). Messages that cannot be authenticated MUST (Authentication Failed). Messages that cannot be authenticated MUST
NOT be processed further. NOT be processed further.
12. Client Operations 11. Client Operations
This section specifies how clients can perform different operations, This section specifies how clients can perform different operations,
such as requesting a floor, using the protocol elements described in such as requesting a floor, using the protocol elements described in
earlier sections. Chair operations, such as instructing the floor earlier sections. Chair operations, such as instructing the floor
server to grant or revoke a floor, are described in Section 13. server to grant or revoke a floor, are described in Section 16.
12.1 Requesting a Floor 11.1 Requesting a Floor
A client that wishes to request one or more floors does so by sending A client that wishes to request one or more floors does so by sending
a FloorRequest message to the floor control server. The ABNF in a FloorRequest message to the floor control server. The ABNF in
Section 6.1 describes the TLVs that a FloorRequest message can Section 6.1 describes the TLVs that a FloorRequest message can
contain. In addition, the ABNF specifies which of these TLVs are contain. In addition, the ABNF specifies which of these TLVs are
mandatory, and which ones are optional. 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 10.1. TRANSACTION-ID TLV following the rules given in Section 9.1.
Additionally, the client follows the rules in Section 11.1 which Additionally, the client follows the rules in Section 10.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 message (i.e., to the INTEGRITY TLV).
The client must insert a USER-ID TLV, which will be used by the The client must insert a USER-ID TLV, which will be used by the
server to authenticate and authorize the request. If the user sending server to authenticate and authorize the request. If the user
the FloorRequest message (identified by the USER-ID TLV) is not the sending the FloorRequest message (identified by the USER-ID TLV) is
same as the user requesting the floor (i.e., a third party floor not the same as the user requesting the floor (i.e., a third party
request), the client SHOULD add a BENEFICIARY-ID TLV to the message floor request), the client SHOULD add a BENEFICIARY-ID TLV to the
identifying the beneficiary of the floor. message identifying the beneficiary of the floor.
The client must insert at least one FLOOR-ID TLV in the FloorRequest The client must insert at least one FLOOR-ID TLV in the FloorRequest
message. If the client inserts more than one FLOOR-ID TLVs, the message. If the client inserts more than one FLOOR-ID TLVs, the
server will treat all the floor requests as an atomic package. That 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 is, the floor control server will either grant or deny all the floors
in the FloorRequest message. in the FloorRequest message.
The client may use a HUMAN-READABLE-INFO TLV to state the reason why The client may use a HUMAN-READABLE-INFO TLV to state the reason why
the floor or floors are being requested. The Text field in the the floor or floors are being requested. The Text field in the
HUMAN-READABLE-INFO TLV is intended for human consumption. HUMAN-READABLE-INFO TLV is intended for human consumption.
The client may request the server to handle the floor request with a The client may request the server to handle the floor request with a
certain priority using a PRIORITY TLV. certain priority using a PRIORITY TLV.
12.1.1 Receiving a Response 11.1.1 Receiving a Response
A message from the server is considered to be a response to the A message from the server is considered to be a response to the
FloorRequest message if the message from the server has the same FloorRequest message if the message from the server has the same
Conference ID and Transaction ID as the FloorRequest message, as Conference ID and Transaction ID as the FloorRequest message, as
described in Section 10.1. described in Section 9.1.
If the response is a FloorRequestStatus message, the client obtains If the response is a FloorRequestStatus message, the client obtains
information about the status of the FloorRequest in a REQUEST-STATUS information about the status of the FloorRequest in a REQUEST-STATUS
TLV. If the Request Status value is Granted, the client has been TLV. If the Request Status value is Granted, the client has been
granted all the floors that were requested in the FloorRequest granted all the floors that were requested in the FloorRequest
message. If the Request Status value is Denied, the client has been message. If the Request Status value is Denied, the client has been
denied all the floors that were requested in the FloorRequest denied all the floors that were requested in the FloorRequest
message. The HUMAN-READABLE-INFO TLV, if present, provides extra message. The HUMAN-READABLE-INFO TLV, if present, provides extra
information which the client MAY display to the user. information which the client MAY display to the user.
A floor request is considered to be ongoing while it is in the A floor request is considered to be ongoing while it is in the
Pending, Accepted, or Granted states. FloorRequestStatus messages Pending, Accepted, or Granted states. FloorRequestStatus messages
carrying any of these states will contain a FLOOR-REQUEST-ID TLV. The carrying any of these states will contain a FLOOR-REQUEST-ID TLV.
value of this TLV is used to match subsequent messages received at The value of this TLV is used to match subsequent messages received
the client side (e.g., further FloorRequestStatus messages) or at the at the client side (e.g., further FloorRequestStatus messages) or at
server side (e.g., a FloorRelease message) with this floor request. 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 If the response is an Error message, the server could not process the
FloorRequest message for some reason, which is described in the Error FloorRequest message for some reason, which is described in the Error
message. message.
12.2 Modifying a Floor Request 12. Requesting Information about Floor Requests
Clients modify the HUMAN-READABLE-INFO and the PRIORITY attributes of
ongoing floor requests by sending a FloorRequest message. The ABNF in
Section 6.1 describes the TLVs that a FloorRequest 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
TRANSACTION-ID TLV following the rules given in Section 10.1.
Additionally, the client follows the rules in Section 11.1 which
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.
FloorRequest messages sent to modify an existing floor request MUST
NOT contain any BENEFICIARY or FLOOR-ID TLV. Instead, the client MUST
insert a FLOOR-REQUEST-ID TLV identifying the floor request to be
modified.
Clients modifying a floor request can provide new HUMAN-READABLE
INFO and PRIORITY TLVs but cannot modify the beneficiary of the
floor request or the floors being requested.
The client may use a HUMAN-READABLE-INFO TLV to state the reason why
the floor or floors are being requested. The Text field in the
HUMAN-READABLE-INFO TLV is intended for human consumption.
The client may request the server to handle the floor request with a
certain priority using a PRIORITY TLV.
12.2.1 Receiving a Response
After sending the FloorRequest message, the client follows the steps
described in Section 12.1.1. Effectively, the client has issued a new
floor request and asked the server to substitute an existing floor
request with this new one. So, the FloorRequestStatus response to the
new FloorRequest message will carry a different FLOOR-REQUEST-ID
value than the old floor request.
If the modification is authorized by the server, the client will
receive a FloorRequestStatus message with a Status Code 7 (Replaced)
indicating that the old floor request has been replaced.
12.3 Requesting Information about Floor Requests
Clients request information about the current status of one or Clients request information about the current status of one or
several floor request by sending a FloorRequestInfo message to the several floor request by sending a FloorRequestInfo message to the
floor control server. floor control server.
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 10.1. TRANSACTION-ID TLV following the rules given in Section 9.1.
Additionally, the client follows the rules in Section 11.1 which Additionally, the client follows the rules in Section 10.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 INTEGRITY 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 server to authenticate and
authorize the request. authorize the request.
If the client wants to request the status of a single floor request, If the client wants to request the status of a single floor request,
it MUST insert a FLOOR-REQUEST-ID TLV that identifies the floor it MUST insert a FLOOR-REQUEST-ID TLV that identifies the floor
request at the server. request at the server.
The client can also request information about all the ongoing floor The client can also request information about all the ongoing floor
requests associated with a particular user. In this case, the client requests associated with a particular user. In this case, the client
MUST NOT insert a FLOOR-REQUEST-ID TLV. If the beneficiary of the MUST NOT insert a FLOOR-REQUEST-ID TLV. If the beneficiary of the
floor requests the client is requesting information about is not the floor requests the client is requesting information about is not the
client issuing the FloorRequestInfo message (which is identified by client issuing the FloorRequestInfo message (which is identified by
the USER-ID TLV in the message) the client SHOULD insert a the USER-ID TLV in the message) the client SHOULD insert a
BENEFICIARY-ID TLV. BENEFICIARY-ID TLV.
12.3.1 Receiving a Response 12.1 Receiving a Response
On reception of the FloorRequestInfo message, the server will respond On reception of the FloorRequestInfo message, the server will respond
with a FloorRequestStatus message or with an error message. That is, with a FloorRequestStatus message or with an error message. That is,
the server will respond using the same message types as when it the server will respond using the same message types as when it
receives a FloorRequest message. Consequently, after sending the receives a FloorRequest message. Consequently, after sending the
FloorRequestInfo message, the client follows the steps described in FloorRequestInfo message, the client follows the steps described in
Section 12.1.1. Section 11.1.1.
If the FloorRequestInfo message requested information about several If the FloorRequestInfo message requested information about several
floor requests, the FloorRequestStatus message will contain floor requests, the FloorRequestStatus message will contain
information about all of them. information about all of them.
12.4 Cancelling a Floor Request and Releasing a Floor 13. Cancelling a Floor Request and Releasing a Floor
A client that wishes to cancel an ongoing floor request does so by A client that wishes to cancel an ongoing floor request does so by
sending a FloorRelease message to the floor control server. The ABNF sending a FloorRelease message to the floor control server. The ABNF
in Section 6.2 describes the TLVs that a FloorRelease message can in Section 6.2 describes the TLVs that a FloorRelease message can
contain. In addition, the ABNF specifies which of these TLVs are contain. In addition, the ABNF specifies which of these TLVs are
mandatory, and which ones are optional. 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 10.1. TRANSACTION-ID TLV following the rules given in Section 9.1.
Additionally, the client follows the rules in Section 11.1 which Additionally, the client follows the rules in Section 10.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 INTEGRITY 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 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 also used to release a floor
or floors that were granted to the client (from the protocol or floors that were granted to the client (from the protocol
perspective both are ongoing floor requests). Using the same perspective both are ongoing floor requests). Using the same
message in both situations helps resolve the race condition that message in both situations helps resolve the race condition that
occurs when the FloorRelease message and the FloorGrant message occurs when the FloorRelease message and the FloorGrant message
cross each other on the wire. cross each other on the wire.
The client uses the FLOOR-REQUEST-ID that was received in the The client uses the FLOOR-REQUEST-ID that was received in the
response to the FloorRequest message that the FloorRelease message is response to the FloorRequest message that the FloorRelease message is
cancelling. cancelling.
12.4.1 Receiving a Response 13.1 Receiving a Response
On reception of the FloorRelease message, the server will respond as On reception of the FloorRelease message, the server will respond as
with a FloorRequestStatus message or with an error message. That is, with a FloorRequestStatus message or with an error message. That is,
the server will respond using the same message types as when it the server will respond using the same message types as when it
receives a FloorRequest message. Consequently, after sending the receives a FloorRequest message. Consequently, after sending the
FloorRelease message, the client follows the steps described in FloorRelease message, the client follows the steps described in
Section 12.1.1. Section 11.1.1.
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 FloorRequestStatus message from the server with a Request Status
different from Cancelled. In any case, such a FloorRequestStatus different from Cancelled. In any case, such a FloorRequestStatus
message will not be a response to the FloorRelease message, because message will not be a response to the FloorRelease message, because
its Transaction ID will not match that of the FloorRelease. its Transaction ID will not match that of the FloorRelease.
12.5 Requesting Information about Floors 14. Requesting Information about Floors
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 FloorInfo message to the floor control server.
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 10.1. TRANSACTION-ID TLV following the rules given in Section 9.1.
Additionally, the client follows the rules in Section 11.1 which Additionally, the client follows the rules in Section 10.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 INTEGRITY 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 server to authenticate and
authorize the request. 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 server will send periodic information
about all these floors. If the client does not want to receive about all these floors. If the client does not want to receive
information about a particular floor any longer, it sends a new information about a particular floor any longer, it sends a new
FloorInfo message removing the FLOOR-ID of this floor. If the client FloorInfo message removing the FLOOR-ID of this floor. If the client
does not want to receive information about any floor, it sends a does not want to receive information about any floor, it sends a
FloorInfo message with no FLOOR-ID TLV. FloorInfo message with no FLOOR-ID TLV.
12.5.1 Receiving a Response 14.1 Receiving a Response
A message from the server is considered to be a response to the A message from the server is considered to be a response to the
FloorInfo message if the message from the server has the same FloorInfo message if the message from the server has the same
Conference ID and Transaction ID as the FloorRequest message, as Conference ID and Transaction ID as the FloorRequest message, as
described in Section 10.1. described in Section 9.1.
On reception of the FloorInfo message, the server will respond with a On reception of the FloorInfo message, the server will respond with a
FloorStatus message or with an Error message. If the response is a FloorStatus message or with an Error message. If the response is a
FloorStatus message, it will contain information about one of the FloorStatus message, it will contain information about one of the
floors the client requested information about. If the client did not floors the client requested information about. If the client did not
include any FLOOR-ID in its FloorInfo message, the FloorStatus include any FLOOR-ID in its FloorInfo message, the FloorStatus
message form the sever will not include any either. message from the server will not include any either.
After the first FloorStatus, the server will continue sending After the first FloorStatus, the server will continue sending
FloorStatus messages periodically informing the client about changes FloorStatus messages periodically informing the client about changes
on the floors the client requested information about. on the floors the client requested information about.
12.6 Checking the Liveness of a Server 15. Checking the Liveness of a Server
A client that wishes to check the liveness of a server does so by A client that wishes to check the liveness of a server does so by
sending a Ping message to the floor control server. The ABNF in 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 Section 6.9 describes the TLVs that a Ping message can contain. In
addition, the ABNF specifies which of these TLVs are mandatory, and addition, the ABNF specifies which of these TLVs are mandatory, and
which ones are optional. which ones are optional.
The client sets the Conference ID in the FIXED-HEADER and the The client sets the Conference ID in the FIXED-HEADER and the
TRANSACTION-ID TLV following the rules given in Section 10.1. TRANSACTION-ID TLV following the rules given in Section 9.1.
Additionally, the client follows the rules in Section 11.1 which Additionally, the client follows the rules in Section 10.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 message (i.e., to the INTEGRITY TLV).
12.6.1 Receiving Responses 15.1 Receiving Responses
A message from the server is considered a response to the Ping A message from the server is considered a response to the Ping
message by the client if the message from the server has the same message by the client if the message from the server has the same
Conference ID and Transaction ID as the Ping message, as described in Conference ID and Transaction ID as the Ping message, as described in
Section 10.1. Section 9.1.
If the response is a PingAck message, the server is alive and the If the response is a PingAck message, the server is alive and the
user identified by the User ID was authenticated successfully. user identified by the User ID was authenticated successfully.
If the response is an Error message, the server could not process the If the response is an Error message, the server could not process the
Ping message for some reason, which is described in the Error Ping message for some reason, which is described in the Error
message. message.
13. Chair Operations 16. Chair Operations
This section specifies how clients acting as chairs can perform This section specifies how clients acting as chairs can perform
different operations, such as instructing the floor server to grant different operations, such as instructing the floor server to grant
or revoke a floor, using the protocol elements described in earlier or revoke a floor, using the protocol elements described in earlier
sections. sections.
13.1 Obtaining Information about Floor Requests 16.1 Obtaining Information about Floor Requests
A chair can obtain information about the floor requests that the A chair can obtain information about the floor requests that the
floor control server receives in different ways, which include using floor control server receives in different ways, which include using
out-of-band mechanisms. Chairs using BFCP to obtain such information out-of-band mechanisms. Chairs using BFCP to obtain such information
use the procedures described in Section 12.5. As a result, they use the procedures described in Section 14. As a result, they
receive information about floor requests that relate to specific receive information about floor requests that relate to specific
floors in FloorStatus messages from the floor control server. floors in FloorStatus messages from the floor control server.
13.2 Instructing the Floor Control Server 16.2 Instructing the Floor Control Server
Chairs that wish to send instructions to a floor control server does Chairs that wish to send instructions to a floor control server does
so by sending a ChairAction message. The ABNF in Section 6.7 so by sending a ChairAction message. The ABNF in Section 6.7
describes the TLVs that a ChairAction message can contain. In describes the TLVs that a ChairAction message can contain. In
addition, the ABNF specifies which of these TLVs are mandatory, and addition, the ABNF specifies which of these TLVs are mandatory, and
which ones are optional. which ones are optional.
The chair sets the Conference ID in the FIXED-HEADER and the The chair sets the Conference ID in the FIXED-HEADER and the
TRANSACTION-ID TLV following the rules given in Section 10.1. TRANSACTION-ID TLV following the rules given in Section 9.1.
Additionally, the chair follows the rules in Section 11.1 which Additionally, the chair follows the rules in Section 10.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 INTEGRITY 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 server to authenticate and
authorize the request. authorize the request.
The ChairAction message contains instructions that apply to one or The ChairAction message contains instructions that apply to one or
more floors within a particular floor request. The floor or floors more floors within a particular floor request. The floor or floors
are identified by FLOOR-ID TLVs and the floor request is identified are identified by FLOOR-ID TLVs and the floor request is identified
by a FLOOR-REQUEST-ID TLV, which are carries in the ChairAction by a FLOOR-REQUEST-ID TLV, which are carries in the ChairAction
message. message.
skipping to change at page 31, line 35 skipping to change at page 31, line 21
control server will grant the floor request as a whole. On the control server will grant the floor request as a whole. On the
other hand, if one of the chairs denies its floor, the floor other hand, if one of the chairs denies its floor, the floor
control server will deny the floor request as a whole, regardless control server will deny the floor request as a whole, regardless
of the other chair's decision. of the other chair's decision.
The chair provides the new status for one or more floors within the The chair provides the new status for one or more floors within the
floor request using a REQUEST-STATUS TLV. If the new status of the floor request using a REQUEST-STATUS TLV. If the new status of the
floor request is Accepted, the chair MAY use the Queue Position field 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 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 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 Position field SHOULD be set to zero. The chair SHOULD use the
Revoked to revoke a floor that was granted (i.e., Granted status) and Status Revoked to revoke a floor that was granted (i.e., Granted
to reject floor requests in any other status (e.g., Pending and status) and to reject floor requests in any other status (e.g.,
Accepted). Pending and Accepted).
Note a floor request may involve several floors and that a Note a floor request may involve several floors and that a
ChairAction message could only deal with a subset of these floors ChairAction message could only deal with a subset of these floors
(e.g., if a single chair is not authorized to manage all the (e.g., if a single chair is not authorized to manage all the
floors). In this case, the REQUEST-STATUS that the chair provides floors). In this case, the REQUEST-STATUS that the chair provides
in the ChairAction message might not be the actual status that the in the ChairAction message might not be the actual status that the
floor request gets at the server. The floor control server will floor request gets at the server. The floor control server will
combine the instructions received from the different chairs to combine the instructions received from the different chairs to
come up with the actual status of the floor request. 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 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 the floor or floors are being accepted, granted, or revoked. The
in the HUMAN-READABLE-INFO TLV is intended for human consumption. Text in the HUMAN-READABLE-INFO TLV is intended for human
consumption.
13.2.1 Receiving a Response 16.2.1 Receiving a Response
A message from the server is considered to be a response to the A message from the server is considered to be a response to the
ChairAction message if the message from the server has the same ChairAction message if the message from the server has the same
Conference ID and Transaction ID as the ChairAction message, as Conference ID and Transaction ID as the ChairAction message, as
described in Section 10.1. described in Section 9.1.
A ChairActionAck message from the server confirms that the server has A ChairActionAck message from the server confirms that the server has
accepted the ChairAction message. An Error message indicates that the accepted the ChairAction message. An Error message indicates that
server could not process the ChairAction message for some reason, the server could not process the ChairAction message for some reason,
which is described in the Error message. which is described in the Error message.
14. Server Operations 17. Server Operations
This section specifies how servers can perform different operations, This section specifies how servers can perform different operations,
such as granting a floor, using the protocol elements described in such as granting a floor, using the protocol elements described in
earlier sections. 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 server SHOULD send an
Error message, as described in Section 14.7, with Error code 0 Error message, as described in Section 17.7, with Error code 0
(Conference does not Exist). (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 11.2, which relate to the authentication follows the rules in Section 10.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 server does not understand all of
them, the floor server SHOULD send an Error message, as described in them, the floor server SHOULD send an Error message, as described in
Section 14.7, with Error code 2 (Authentication Failed). The Error Section 17.7, with Error code 2 (Authentication Failed). The Error
message SHOULD list the TLVs that were not understood. message SHOULD list the TLVs that were not understood.
OPEN ISSUE: can servers use new new mandatory TLVs in their messages? OPEN ISSUE: can servers use new mandatory TLVs in their messages?
Right now we do not have a way for clients to complain about Right now we do not have a way for clients to complain about
unsupported TLVs received from the server. unsupported TLVs received from the server.
14.1 Reception of a FloorRequest Message 17.1 Reception of a FloorRequest Message
The processing of a FloorRequest message by a server involves The processing of a FloorRequest message by a server involves
generating a FloorRequestStatus message. The floor control server generating a FloorRequestStatus message. The floor control server
SHOULD generate a FloorRequestStatus message as soon as possible. If SHOULD generate a FloorRequestStatus message as soon as possible. If
the floor server cannot accept, grant, or deny the floor request 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 right away (e.g., a decision from a chair is needed), it SHOULD use a
Request Status value of Pending. Request Status value of Pending.
The server copies the Conference ID and the TRANSACTION-ID TLV from The server copies the Conference ID and the TRANSACTION-ID TLV from
the FloorRequest into the FloorRequestStatus, as described in Section the FloorRequest into the FloorRequestStatus, as described in Section
10.2. Additionally, the server MUST assign an identitifier that is 9.2. Additionally, the server MUST assign an identitifier that is
unique within the conference to this floor request, and insert it in unique within the conference to this floor request, and insert it in
a FLOOR-REQUEST-ID TLV into the FloorRequestStatus message. This a FLOOR-REQUEST-ID TLV into the FloorRequestStatus message. This
indentifier will be used by the client to refer to this specific indentifier will be used by the client to refer to this specific
floor request in the future. floor request in the future.
The server follows the rules in Section 11.2 which relate to The server follows the rules in Section 10.2 which relate to
authentication and the use of the INTEGRITY TLV. authentication and the use of the INTEGRITY TLV.
At later time, when the status of the floor request changes, the At later time, when the status of the floor request changes, the
floor control server SHOULD send a new FloorRequestStatus message floor control server SHOULD send a new FloorRequestStatus message
with the appropriate Request Status. This FloorRequestStatus message with the appropriate Request Status. This FloorRequestStatus message
MUST contain a FLOOR-REQUEST-ID TLV identifying the floor request, MUST contain a FLOOR-REQUEST-ID TLV identifying the floor request,
but MUST NOT contain any TRANSACTION-ID TLV. The server may add a but MUST NOT contain any TRANSACTION-ID TLV. The server may add a
HUMAN-READABLE-INFO TLV to provide extra information to the user HUMAN-READABLE-INFO TLV to provide extra information to the user
about its decision. about its decision.
The rate at which the floor control server sends The rate at which the floor control server sends
FloorRequestStatus messages is a matter of local policy. A server FloorRequestStatus messages is a matter of local policy. A server
may choose to send a new FloorRequestStatus message every time the may choose to send a new FloorRequestStatus message every time the
floor request moves in the floor request queue while another may floor request moves in the floor request queue while another may
choose to only send a new FloorRequestStatus message when the choose to only send a new FloorRequestStatus message when the
floor request is Granted or Denied. floor request is Granted or Denied.
Clients and chairs that request so need to be informed about changes Clients and chairs that request so need to be informed about changes
in the status of a floor (e.g., a new floor request arrives). To in the status of a floor (e.g., a new floor request arrives). To
accomplish this, the floor control server follows the rules in accomplish this, the floor control server follows the rules in
Section 14.4. Section 17.4.
14.1.1 Floor Request Modification
If the FloorRequest message contains a FLOOR-REQUEST-ID TLV, it means
that the client is requesting a floor control to be modified. In
addition to the actions described in Section 14.1, if the
modification is authorized, the floor control server SHOULD send a
FloorRequestStatus message with Request Status 7 (Replaced) for the
original floor request.
If the FloorRequest message contains an invalid FLOOR-REQUEST-ID, the
floor control server SHOULD respond with an Error response with Error
Code 3 (Floor Request ID Does Not Exist).
14.2 Reception of a FloorRequestInfo Message 17.2 Reception of a FloorRequestInfo Message
The processing of a FloorRequestInfo message by a server involves The processing of a FloorRequestInfo message by a server involves
generating a FloorRequestStatus message. The FloorRequestInfo message generating a FloorRequestStatus message. The FloorRequestInfo
can apply to a single floor request, identified by a message can apply to a single floor request, identified by a
FLOOR-REQUEST-ID, or to all the floor requests from a given user, the FLOOR-REQUEST-ID, or to all the floor requests from a given user, the
FloorRequestInfo does not carry a FLOOR-REQUEST-ID. The user is FloorRequestInfo does not carry a FLOOR-REQUEST-ID. The user is
identified by a BENEFICIARY-ID TLV, or if this is not present, by a identified by a BENEFICIARY-ID TLV, or if this is not present, by a
USER-ID TLV. USER-ID TLV.
If the FloorRequestInfo message contains an invalid FLOOR-REQUEST-ID, If the FloorRequestInfo message contains an invalid FLOOR-REQUEST-ID,
the floor control server SHOULD respond with an Error response with the floor control server SHOULD respond with an Error response with
Error Code 3 (Floor Request ID Does Not Exist). Error Code 3 (Floor Request ID Does Not Exist).
On reception of a FloorRequestInfo message, the floor control server On reception of a FloorRequestInfo message, the floor control server
SHOULD generate a FloorRequestStatus message as soon as possible. SHOULD generate a FloorRequestStatus message as soon as possible.
The server copies the Conference ID and the TRANSACTION-ID TLV from The server copies the Conference ID and the TRANSACTION-ID TLV from
the FloorRequestInfo message into the FloorRequestStatus, as the FloorRequestInfo message into the FloorRequestStatus, as
described in Section 10.2. described in Section 9.2.
The server follows the rules in Section 11.2 which relate to The server follows the rules in Section 10.2 which relate to
authentication and the use of the INTEGRITY TLV. authentication and the use of the INTEGRITY TLV.
14.3 Reception of a FloorRelease Message 17.3 Reception of a FloorRelease Message
The processing of a FloorRelease message by a server involves The processing of a FloorRelease message by a server involves
generating a FloorRequestStatus message. The FloorRelease message generating a FloorRequestStatus message. The FloorRelease message
identifies the floor request it applies to using a FLOOR-REQUEST-ID. identifies the floor request it applies to using a FLOOR-REQUEST-ID.
If the FloorRelease message contains an invalid FLOOR-REQUEST-ID, the If the FloorRelease message contains an invalid FLOOR-REQUEST-ID, the
floor control server SHOULD respond with an Error response with Error floor control server SHOULD respond with an Error response with Error
Code 3 (Floor Request ID Does Not Exist). Code 3 (Floor Request ID Does Not Exist).
On reception of a FloorRelease message with a valid FLOOR-REQUEST-ID, On reception of a FloorRelease message with a valid FLOOR-REQUEST-ID,
the floor control server SHOULD generate a FloorRequestStatus message the floor control server SHOULD generate a FloorRequestStatus message
as soon as possible. If the floor server can authorize the release as soon as possible. If the floor server can authorize the release
operation right away, it SHOULD use a Request Status value of operation right away, it SHOULD use a Request Status value of
Released, if the floor had been previously granted, or of Cancelled, 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 if it had not. The server may add a HUMAN-READABLE-INFO TLV to
skipping to change at page 34, line 43 skipping to change at page 34, line 19
On reception of a FloorRelease message with a valid FLOOR-REQUEST-ID, On reception of a FloorRelease message with a valid FLOOR-REQUEST-ID,
the floor control server SHOULD generate a FloorRequestStatus message the floor control server SHOULD generate a FloorRequestStatus message
as soon as possible. If the floor server can authorize the release as soon as possible. If the floor server can authorize the release
operation right away, it SHOULD use a Request Status value of operation right away, it SHOULD use a Request Status value of
Released, if the floor had been previously granted, or of Cancelled, 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 if it had not. The server may add a HUMAN-READABLE-INFO TLV to
provide extra information to the user about its decision. provide extra information to the user about its decision.
The server copies the Conference ID and the TRANSACTION-ID TLV from The server copies the Conference ID and the TRANSACTION-ID TLV from
the FloorRelease into the FloorRequestStatus, as described in Section the FloorRelease into the FloorRequestStatus, as described in Section
10.2. 9.2.
The server follows the rules in Section 11.2 which relate to The server follows the rules in Section 10.2 which relate to
authentication and the use of the INTEGRITY TLV. authentication and the use of the INTEGRITY TLV.
14.4 Reception of a FloorInfo Message 17.4 Reception of a FloorInfo Message
A server receiving a FloorInfo message from a client SHOULD keep this A server receiving a FloorInfo message from a client SHOULD keep this
client informed about the status of the floors identified by client informed about the status of the floors identified by
FLOOR-IDs in the FloorInfo message. Servers keep clients informed by FLOOR-IDs in the FloorInfo message. Servers keep clients informed by
using FloorStatus messages. using FloorStatus messages.
The information FloorInfo messages carry may depend on the user The information FloorInfo messages carry may depend on the user
requesting the information. For example, a chair may be able to requesting the information. For example, a chair may be able to
receive information about pending requests while a regular user may receive information about pending requests while a regular user may
not be authorized to do so. not be authorized to do so.
skipping to change at page 35, line 23 skipping to change at page 34, line 47
in a single FloorInfo message. For each floor request, the server in a single FloorInfo message. For each floor request, the server
provides its FLOOR-REQUEST-ID and its REQUEST-STATUS, and may provide provides its FLOOR-REQUEST-ID and its REQUEST-STATUS, and may provide
further information such as its BENEFICIARY-ID. further information such as its BENEFICIARY-ID.
On reception of a FloorInfo message with one or more FLOOR-ID TLVs, On reception of a FloorInfo message with one or more FLOOR-ID TLVs,
the server generates a FloorStatus message for one of the floors the server generates a FloorStatus message for one of the floors
identified in the FloorInfo message. identified in the FloorInfo message.
The server copies the Conference ID and the TRANSACTION-ID TLV from The server copies the Conference ID and the TRANSACTION-ID TLV from
the FloorInfo message into the FloorStatus message, as described in the FloorInfo message into the FloorStatus message, as described in
Section 10.2. Section 9.2.
The server follows the rules in Section 11.2 which relate to The server follows the rules in Section 10.2 which relate to
authentication and the use of the INTEGRITY TLV. authentication and the use of the INTEGRITY TLV.
After sending this message, the server SHOULD continue sending After sending this message, the server SHOULD continue sending
FloorStatus messages about all the floors the client requested FloorStatus messages about all the floors the client requested
information about. These messages MUST NOT carry a TRANSACTION-ID information about. These messages MUST NOT carry a TRANSACTION-ID
TLV. TLV.
The rate at which the floor control server sends FloorStatus The rate at which the floor control server sends FloorStatus
messages is a matter of local policy. A server may choose to send messages is a matter of local policy. A server may choose to send
a new FloorRequestStatus message every time a new floor request a new FloorRequestStatus message every time a new floor request
arrives while another may choose to only send a new FloorStatus arrives while another may choose to only send a new FloorStatus
message when a new floor request is Granted. message when a new floor request is Granted.
14.5 Reception of a ChairAction Message 17.5 Reception of a ChairAction Message
On reception of a ChairAction message, the floor control server On reception of a ChairAction message, the floor control server
checks whether the chair that send the message is authorized to checks whether the chair that send the message is authorized to
perform the operation being requested. If the chair is authorized, perform the operation being requested. If the chair is authorized,
the floor control server performs the operation and sends a the floor control server performs the operation and sends a
ChairActionAck message to the client. If the new Status in the ChairActionAck message to the client. If the new Status in the
ChairAction message is Accepted and all the bits of the Queue ChairAction message is Accepted and all the bits of the Queue
Position field are zero, the server assigns a queue position (e.g., 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 the last in the queue) to the floor request based on local policy (in
case the server implements a queue). case the server implements a queue).
The server copies the Conference ID and the TRANSACTION-ID TLV from The server copies the Conference ID and the TRANSACTION-ID TLV from
the ChairAction message into the ChairActionAck message, as described the ChairAction message into the ChairActionAck message, as described
in Section 10.2. in Section 9.2.
The server follows the rules in Section 11.2 which relate to The server follows the rules in Section 10.2 which relate to
authentication and the use of the INTEGRITY TLV. authentication and the use of the INTEGRITY TLV.
If the floor control server cannot find a floor request that matches If the floor control server cannot find a floor request that matches
the FLOOR-REQUEST-ID TLV in the ChairAction message the floor control the FLOOR-REQUEST-ID TLV in the ChairAction message the floor control
server generates an Error message, as described in Section 14.7, with server generates an Error message, as described in Section 17.7, with
an Error code with a value of 3 (Floor Request ID Does Not Exist). an Error code with a value of 3 (Floor Request ID Does Not Exist).
If the chair is not authorized to perform the operation being If the chair is not authorized to perform the operation being
requested, the floor control server generates an Error message, as requested, the floor control server generates an Error message, as
described in Section 14.7, with an Error code with a value of 4 described in Section 17.7, with an Error code with a value of 4
(Unauthorized Operation). (Unauthorized Operation).
14.6 Reception of a Ping Message 17.6 Reception of a Ping Message
The processing of a Ping message by a server involves generating a The processing of a Ping message by a server involves generating a
PingAck message. On reception of a Ping message, the floor control PingAck message. On reception of a Ping message, the floor control
server SHOULD generate a PingAck message as soon as possible. The server SHOULD generate a PingAck message as soon as possible. The
server copies the Conference ID and the TRANSACTION-ID TLV from the server copies the Conference ID and the TRANSACTION-ID TLV from the
Ping into the PingAck, as described in Section 10.2. Ping into the PingAck, as described in Section 9.2.
The server follows the rules in Section 11.2 which relate to The server follows the rules in Section 10.2 which relate to
authentication and the use of the INTEGRITY TLV. authentication and the use of the INTEGRITY TLV.
14.7 Error Message Generation 17.7 Error Message Generation
Error messages are always sent in response to a previous message from Error messages are always sent in response to a previous message from
the client as part of a client-initiated transaction. The ABNF in the client as part of a client-initiated transaction. The ABNF in
Section 6.11 describes the TLVs that an Error message can contain. In Section 6.11 describes the TLVs that an Error message can contain.
addition, the ABNF specifies which of these TLVs are mandatory, and In addition, the ABNF specifies which of these TLVs are mandatory,
which ones are optional. and which ones are optional.
Servers copy the Conference ID and the TRANSACTION-ID TLV from the Servers copy the Conference ID and the TRANSACTION-ID TLV from the
message from the client into the Error message, as described in message from the client into the Error message, as described in
Section 10.2. Section 9.2.
The server follows the rules in Section 11.2 which relate to The server follows the rules in Section 10.2 which relate to
authentication and the use of the INTEGRITY TLV. authentication and the use of the INTEGRITY TLV.
15. BFCP and the Offer/Answer Model 18. BFCP and the Offer/Answer Model
The way a client obtains a the information needed to contact a BFCP The way a client obtains a the information needed to contact a BFCP
floor control server is outside the scope of BCFP. Nevertheless, this floor control server is outside the scope of BCFP. Nevertheless,
section describes how to obtain such an information using an SDP [5] this section describes how to obtain such an information using an SDP
offer/answer [11] exchange. [5] offer/answer [11] exchange.
User agents typically use the offer/answer model to establish a User agents typically use the offer/answer model to establish a
number of media streams of different types. Following this model, a number of media streams of different types. Following this model, a
BFCP connection is described as any other media stream by using an BFCP connection is described as any other media stream by using an
SDP m line. SDP m line.
15.1 Fields in the m Line 18.1 Fields in the m Line
According to RFC 2327 [5], the m-line format is the following: According to RFC 2327 [5], the m-line format is the following:
m=<media> <port> <transport> <fmt list> m=<media> <port> <transport> <fmt list>
The media field MUST have a value of "application". The port field is The media field MUST have a value of "application". The port field
not used by BFCP, and MAY be set to any value chosen by the endpoint. is not used by BFCP, and MAY be set to any value chosen by the
A port field value of zero has the standard SDP meaning (i.e., endpoint. A port field value of zero has the standard SDP meaning
rejection of the media stream). (i.e., rejection of the media stream).
The port field is set following the rules in [14]. Depending on the The port field is set following the rules in [14]. Depending on the
value of the setup attribute (disccused in Section 15.4), the port value of the setup attribute (disccused in Section 18.4), the port
field contains the port the remote endpoint will initiate its TCP field contains the port the remote endpoint will initiate its TCP
connection to, or is irrelevant (i.e., the endpoint will initiate the connection to, or is irrelevant (i.e., the endpoint will initiate the
connection towards the remote endpoint) and should be set to a value 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, of 9, which is the discard port. Since BFCP only runs on top of TCP,
the port is always a TCP port. the port is always a TCP port.
We define two new values for the transport field: TCP/BFCP and TCP/ We define two new values for the transport field: TCP/BFCP and TCP/
TLS/BFCP. TLS/BFCP.
The fmt (format) list is ignored for BFCP. The fmt list of BFCP m The fmt (format) list is ignored for BFCP. The fmt list of BFCP m
lines SHOULD contain a single "*" character. lines SHOULD contain a single "*" character.
The following is an example of an m line for a BFCP connection: The following is an example of an m line for a BFCP connection:
m=application 20000 TCP/BFCP * m=application 20000 TCP/BFCP *
15.2 The confid and userid SDP Parameters 18.2 The confid and userid SDP Parameters
We define the confid and the userid SDP media-level attributes. Their We define the confid and the userid SDP media-level attributes.
syntax is: Their syntax is:
confid-attribute = "a=confid: " conference-id confid-attribute = "a=confid: " conference-id
conference-id = token conference-id = token
userid-attribute = "a=userid: " user-id userid-attribute = "a=userid: " user-id
user-id = token user-id = token
The confid and the userid attributes carry the integer representation The confid and the userid attributes carry the integer representation
of a conference ID and a user ID respectively. of a conference ID and a user ID respectively.
Endpoints which use the offer/answer model to establish BFCP Endpoints which use the offer/answer model to establish BFCP
connections MUST support the confid and the userid attributes. A connections MUST support the confid and the userid attributes. A
floor control server acting as an offerer or as an answerers SHOULD floor control server acting as an offerer or as an answerers SHOULD
include these attributes in its session descriptions. include these attributes in its session descriptions.
15.3 The k line 18.3 The k line
If the offer/answer exchange is encrypted and integrity protected, If the offer/answer exchange is encrypted and integrity protected,
the offerer MAY use an SDP k line to provide the answerer with a 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 shared secret to be used to calculate the value of the INTEGRITY
TLVs. The following is an example of a k line: TLVs. The following is an example of a k line:
k=base64:c2hhcmVkLXNlY3JldA== k=base64:c2hhcmVkLXNlY3JldA==
15.4 TCP Connection Management 18.4 TCP Connection Management
The management of the TCP connection used to transport BFCP is The management of the TCP connection used to transport BFCP is
performed using the setup and connid attributes as defined in [14]. performed using the setup and connid attributes as defined in [14].
The setup attribute indicates which of the endpoints (client or floor The setup attribute indicates which of the endpoints (client or floor
control server) initiates the TCP connection. The connid attribute control server) initiates the TCP connection. The connid attribute
handles TCP connection reestablishment. handles TCP connection reestablishment.
15.5 Association between Streams and Floors Editor's note: need to address loss and re-establishment of TCP
connections.
18.5 Association between Streams and Floors
EDITOR'S NOTE: We need a way for clients that don't support CPCP to EDITOR'S NOTE: We need a way for clients that don't support CPCP to
at a minimum learn enough information about floors to use the floor at a minimum learn enough information about floors to use the floor
control protocol. This section will need to be harmonized with the control protocol. This section will need to be harmonized with the
media policy work. media policy work.
We define the floorid SDP media-level attribute. Its syntax is: We define the floorid SDP media-level attribute. Its syntax is:
floor-id-attribute = "a=floorid:" token " mstream:" 1*(token) floor-id-attribute = "a=floorid:" token " mstream:" 1*(token)
skipping to change at page 39, line 10 skipping to change at page 38, line 35
integer representation of the 16-bit floorid to be used in BFCP. The integer representation of the 16-bit floorid to be used in BFCP. The
token representing the media stream is a pointer to the media stream, token representing the media stream is a pointer to the media stream,
which is identified by an SDP label attribute which is identified by an SDP label attribute
[draft-levin-mmmusic-sdp-media-label-00.txt]. [draft-levin-mmmusic-sdp-media-label-00.txt].
Endpoints which use the offer/answer model to establish BFCP Endpoints which use the offer/answer model to establish BFCP
connections MUST support the floorid and the label attributes. A connections MUST support the floorid and the label attributes. A
floor control server acting as an offerer or as an answerers SHOULD floor control server acting as an offerer or as an answerers SHOULD
include these attributes in its session descriptions. include these attributes in its session descriptions.
15.6 Example 18.6 Example
The following is an example of an offer sent by a conference server The following is an example of an offer sent by a conference server
to a user. For the purpose of brevity, the main portion of the to a user. For the purpose of brevity, the main portion of the
session description is omitted in the examples, which only show m= session description is omitted in the examples, which only show m=
lines and their attributes. lines and their attributes.
m=application 20000 TCP/BFCP * m=application 20000 TCP/BFCP *
k=base64:c2hhcmVkLXNlY3JldA== k=base64:c2hhcmVkLXNlY3JldA==
a=setup:passive a=setup:passive
a=connid:1 a=connid:1
skipping to change at page 39, line 38 skipping to change at page 39, line 17
a=label:11 a=label:11
The following is the answer returned by the user. The following is the answer returned by the user.
m=application 9 TCP/BFCP * m=application 9 TCP/BFCP *
a=setup:active a=setup:active
a=connid:1 a=connid:1
m=audio 25000 RTP/AVP 0 m=audio 25000 RTP/AVP 0
m=video 35000 RTP/AVP 31 m=video 35000 RTP/AVP 31
16. Security Considerations 19. Security Considerations
TBD. TBD.
17. IANA Considerations 20. IANA Considerations
TBD TBD
17.1 SDP Attributes Registration 20.1 SDP Attributes Registration
TBD: TBD:
18. Acknowledgments 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.
19. References 22. References
19.1 Normative References 22.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.
skipping to change at page 41, line 10 skipping to change at page 40, line 37
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [11] 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 [12] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403, Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002. October 2002.
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD [13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003. 63, RFC 3629, November 2003.
[14] Yon, D., "Connection-Oriented Media Transport in SDP", [14] Yon, D., "Connection-Oriented Media Transport in the Session
draft-ietf-mmusic-sdp-comedia-05 (work in progress), March Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-08
2003. (work in progress), July 2004.
19.2 Informational References 22.2 Informational References
[15] Schulzrinne, H., "Requirements for Floor Control Protocol", [15] Schulzrinne, H., "Requirements for Floor Control Protocol",
draft-ietf-xcon-floor-control-req-00 (work in progress), draft-ietf-xcon-floor-control-req-01 (work in progress), July
January 2004. 2004.
[16] Koskelainen, P. and H. Khartabil, "An Extensible Markup [16] 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 [17] 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-03 (work in progress), draft-ietf-sipping-conference-package-05 (work in progress),
February 2004. July 2004.
[18] Arkko, J., "MIKEY: Multimedia Internet KEYing", [18] 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., "A Session Initiation Protocol (SIP) Event [19] Rosenberg, J., "An Extensible Markup Language (XML) Document
Package for Modification Events for the Extensible Markup Format for Indicating Changes in XML Configuration Access
Language (XML) Configuration Access Protocol (XCAP) Managed Protocol (XCAP) Resources", draft-ietf-simple-xcap-package-02
Documents", draft-ietf-simple-xcap-package-01 (work in (work in progress), July 2004.
progress), February 2004.
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
skipping to change at page 43, line 13 skipping to change at page 42, line 13
EMail: drage@lucent.com EMail: drage@lucent.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
 End of changes. 

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