XCON Working Group G. Camarillo Internet-Draft Ericsson Expires: February 17, 2005 J. Ott Universitaet Bremen K. Drage Lucent Technologies August 19, 2004 The Binary Floor Control Protocol (BFCP) draft-ietf-xcon-bfcp-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). 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 Camarillo, et al. Expires February 17, 2005 [Page 1] Internet-Draft BFCP August 2004 control -- that are realized by other protocols. This document specicies the Binary Floor Control Protocol (BFCP). BFCP is used between conference participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Obtaining Information to Contact a BFCP Floor Server . . . 7 3.3 Generating a Shared Secret . . . . . . . . . . . . . . . . 7 3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 7 3.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . 8 4. Overview of Operation . . . . . . . . . . . . . . . . . . . 8 4.1 User - Floor Control Server Interface . . . . . . . . . . 9 4.2 Floor Chair - Floor Control Server Interface . . . . . . . 11 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 12 5.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 12 5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 13 5.2.1 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.2 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.3 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 14 5.2.4 TRANSACTION-ID . . . . . . . . . . . . . . . . . . . . 15 5.2.5 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 15 5.2.6 HUMAN-READABLE-INFO . . . . . . . . . . . . . . . . . 15 5.2.7 INTEGRITY . . . . . . . . . . . . . . . . . . . . . . 16 5.2.8 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 16 5.2.9 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 17 5.2.10 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 19 5.2.11 USER-URI . . . . . . . . . . . . . . . . . . . . . . 19 5.2.12 PRIORITY . . . . . . . . . . . . . . . . . . . . . . 19 6. Message Format . . . . . . . . . . . . . . . . . . . . . . . 19 6.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . . . 19 6.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . . . 20 6.3 FloorRequestInfo . . . . . . . . . . . . . . . . . . . . . 20 6.4 FloorRequestStatus . . . . . . . . . . . . . . . . . . . . 20 6.5 FloorInfo . . . . . . . . . . . . . . . . . . . . . . . . 21 6.6 FloorStatus . . . . . . . . . . . . . . . . . . . . . . . 21 6.7 ChairAction . . . . . . . . . . . . . . . . . . . . . . . 22 6.8 ChairActionAck . . . . . . . . . . . . . . . . . . . . . . 22 6.9 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.10 PingAck . . . . . . . . . . . . . . . . . . . . . . . . 22 6.11 Error . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 23 Camarillo, et al. Expires February 17, 2005 [Page 2] Internet-Draft BFCP August 2004 8. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 23 9. Protocol Transactions . . . . . . . . . . . . . . . . . . . 23 9.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 24 9.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 24 10. Authentication . . . . . . . . . . . . . . . . . . . . . . . 24 10.1 Client Behavior . . . . . . . . . . . . . . . . . . . . 24 10.2 Server Behavior . . . . . . . . . . . . . . . . . . . . 25 11. Client Operations . . . . . . . . . . . . . . . . . . . . . 25 11.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 25 11.1.1 Receiving a Response . . . . . . . . . . . . . . . . 26 12. Requesting Information about Floor Requests . . . . . . . . 27 12.1 Receiving a Response . . . . . . . . . . . . . . . . . . 27 13. Cancelling a Floor Request and Releasing a Floor . . . . . . 28 13.1 Receiving a Response . . . . . . . . . . . . . . . . . . 28 14. Requesting Information about Floors . . . . . . . . . . . . 28 14.1 Receiving a Response . . . . . . . . . . . . . . . . . . 29 15. Checking the Liveness of a Server . . . . . . . . . . . . . 29 15.1 Receiving Responses . . . . . . . . . . . . . . . . . . 30 16. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 30 16.1 Obtaining Information about Floor Requests . . . . . . . 30 16.2 Instructing the Floor Control Server . . . . . . . . . . 30 16.2.1 Receiving a Response . . . . . . . . . . . . . . . . 31 17. Server Operations . . . . . . . . . . . . . . . . . . . . . 32 17.1 Reception of a FloorRequest Message . . . . . . . . . . 32 17.2 Reception of a FloorRequestInfo Message . . . . . . . . 33 17.3 Reception of a FloorRelease Message . . . . . . . . . . 33 17.4 Reception of a FloorInfo Message . . . . . . . . . . . . 34 17.5 Reception of a ChairAction Message . . . . . . . . . . . 35 17.6 Reception of a Ping Message . . . . . . . . . . . . . . 35 17.7 Error Message Generation . . . . . . . . . . . . . . . . 36 18. BFCP and the Offer/Answer Model . . . . . . . . . . . . . . 36 18.1 Fields in the m Line . . . . . . . . . . . . . . . . . . 36 18.2 The confid and userid SDP Parameters . . . . . . . . . . 37 18.3 The k line . . . . . . . . . . . . . . . . . . . . . . . 37 18.4 TCP Connection Management . . . . . . . . . . . . . . . 37 18.5 Association between Streams and Floors . . . . . . . . . 38 18.6 Example . . . . . . . . . . . . . . . . . . . . . . . . 38 19. Security Considerations . . . . . . . . . . . . . . . . . . 39 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39 20.1 SDP Attributes Registration . . . . . . . . . . . . . . 39 21. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 39 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 22.1 Normative References . . . . . . . . . . . . . . . . . . . 39 22.2 Informational References . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . 42 Camarillo, et al. Expires February 17, 2005 [Page 3] Internet-Draft BFCP August 2004 1. Introduction Within a (multimedia) conference, some applications (e.g., conference applications) need to manage the access to a set of shared resources, such as the right to send media over a particular media stream. 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 requirements that need to be met by floor control protocols. The Binary Floor Control Protocol (BFCP), which is specified in this document, meets these requirements. Section 2 defines the terminology used throughout this document and Section 3 discusses the scope of BFCP (i.e., which tasks fall within the scope of BFCP and which ones are performed using different mechanisms). Section 4 provides a non-normative overview of BFCP operation and subsequent sections provide the normative specification of BFCP. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant implementations. Conference Policy: The complete set of rules for a particular conference manipulated by the conference policy server. It includes the membership policy and the media policy. There is an instance of conference policy for each conference. Conference Policy Control Protocol (CPCP): The protocol used by clients to manipulate the conference policy. Floor: A permission to temporarily access or manipulate a specific shared resource or set of resources. Floor chair: A user (or an entity) who manages one floor (grants, denies, or revokes a floor). The floor chair does not have to be a member in a conference. Floor control: A mechanism that enables applications or users to gain safe and mutually exclusive or non-exclusive input access to the shared object or resource. Floor control server: A logical entity that maintains the state of Camarillo, et al. Expires February 17, 2005 [Page 4] Internet-Draft BFCP August 2004 the floor(s) including which floors exists, who the floor chairs are, who holds a floor, etc. Requests to manipulate a floor are directed at the floor control server. Media Policy: A set of rules manipulated by the conference policy server regarding the media composition of the conference. The media policy is used by the focus to determine the mixing characteristics for the conference. The media policy includes rules about which participants receive media from which other participants, and 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 each participant is mixed. In the case of video, these rules can indicate whether the video is tiled, whether the video indicates the 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 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. Camarillo, et al. Expires February 17, 2005 [Page 5] Internet-Draft BFCP August 2004 +---------+ | Floor | | Chair | | | +---------+ ^ | | | Notification | | Decision | | | | Floor | v +---------+ Request +---------+ +---------+ | |----------->| Floor | Notification | | | User | | Control |------------->| User | | |<-----------| Server | | | +---------+ Granted or +---------+ +---------+ Denied Figure 1: Functionality provided by BFCP BFCP provides a means: o for users to send floor requests to floor control servers. o for floor control servers to grant or deny requests to access a given resource from users. o for floor chairs to send floor control servers decisions regarding floor requests. o for floor control servers to keep users and floor chairs informed about the status of a given floor. Even though tasks that do not belong to the previous list are outside the scope of BFCP, some of these out-of-scope tasks relate to floor control and are essential to create floors and to establish BFCP connections between different entities. In the following subsections, we discuss some of these tasks and mechanisms to perform them. 3.1 Floor Creation The conference policy for a particular conference contains the floors of the conference and the resource or resources associated with each floor. For example, a conference may have two floors: one controlling who can talk at a particular time and another controlling who can write on a shared whiteboard. According to the definitions in Section 2, the conference policy is manipulated using a Conference Policy Control Protocol (CPCP), such as [16]. Consequently, floor creation and termination is handled by Camarillo, et al. Expires February 17, 2005 [Page 6] Internet-Draft BFCP August 2004 CPCP. In addition, CPCP also handles the association of a given floor with a resource or a set of resources (e.g., media streams). Additionally, the floor control server needs to stay up to date on 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 [19] to keep itself up to date. 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 BFCP connection to a floor control server. These data include the transport address of the server, the conference identifier, and the user identifier. Users can obtain this information in different ways. Two possibilities are using CPCP and using the offer/answer [11] exchange which is used to establish media streams between the user and the conference server. Section 18 discusses how to use an SDP [5] offer/ answer [11] exchange to obtain this information. 3.3 Generating a Shared Secret Authentication and integrity protection in BFCP are based on a shared 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. 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., an offer/answer exchange using SIP [10] protected using S/MIME), they can get the shared secret using the same channel. 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 perform a Diffie-Hellman key exchange. Editor's note: Probably need to mention TLS as another mechanism here. 3.4 Obtaining Floor-Resource Associations Floors are associated with resources. For example, a floor that controls who talks at a given time has a particular audio stream as its associated resource. Associations between floors and resources are part of the conference policy, which is manipulated using CPCP. Users and floor chairs need to know which resources are associated with which floors. They can obtain this information using different Camarillo, et al. Expires February 17, 2005 [Page 7] Internet-Draft BFCP August 2004 mechanisms, such as CPCP or an offer/answer [11] exchange. Section 18 describes how to use an offer/answer exchange to obtain these associations. Note that users perform offer/answer exchanges with the SIP focus of the conference. So, the SIP focus needs to obtain information about associations between floors and resources using a mechanism such as CPCP in order to be able to provide this information to a user in an offer/answer exchange. 3.5 Policy Enforcement A user whose floor request is granted has the right to use in a certain way the resource or resources associated with the floor that was requested. For example, the user may have the right to talk (i.e., send media over a particular audio stream). Nevertheless, holding a floor does not imply that others will not be able to use its associated resources at the same time, even if they do not have the right to do so. According to the definition in Section 2, the media policy of a conference is the one that determines which users can actually use the resources in the conference. So, if the policy of a conference is to enforce floor control decisions, every change in the status of any floor needs to be reflected in the media policy of the conference. For example, the 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 have the floor control server manipulate the media policy using CPCP. Nevertheless, there are other ways to enforce floor control policies, such as having a floor control chair manipulate the media policy (using CPCP) only if there are misbehaving users trying to use a resource without holding its associated floor. 4. Overview of Operation This section provides a non-normative description of BFCP operations. Section 4.1 describes the interface between users and floor control servers and Section 4.2 describes the interface between floor chairs and floor control servers BFCP messages, which use a TLV (Type-Length-Value) binary encoding, consist of a common header followed by a set of TLVs. The common header contains, among other information, a 32-bit conference identifier. Users and floor chairs are identified by a 16-bit user identifier, which is carried in a TLV. Camarillo, et al. Expires February 17, 2005 [Page 8] Internet-Draft BFCP August 2004 4.1 User - Floor Control Server Interface Users request a floor by sending a FloorRequest message to the floor control server. BFCP supports third party floor requests. That is, the user sending the floor request need not be the same as the user who will get the floor once the floor request is granted. FloorRequest messages carry the identity of the requester in a USER-ID TLV, and the identity of the beneficiary of the floor, in third party floor requests, in a BENEFICIARY-ID TLV. Third party floor requests can be sent by users that have a BFCP connection to the floor control server, but who are not conference participants (i.e., they do not handle any media). FloorRequest messages identify the floor or floors being requested by carrying their 16-bit floor identifiers in FLOOR-ID TLVs. If a FloorRequest message carries more than one floor identifier, the floor control server treats all the floor requests as an atomic package. That is, the floor control server either grants or denies all the floors in the FloorRequest message. EDITOR'S NOTE: we need to explain in this paragraph that if a user is anonymous, the floor control server does not disclose the identity of the requester of the floor to the rest of the users and floor chairs. Floor control servers respond to FloorRequest messages with FloorStatus messages. 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 being, below there are two typical call flows: a client requesting a floor and a client requesting information about a floor. Client Floor Control Server | FloorRequest | | TRANSACTION-ID: 123 | |----------------------------->| | | | FloorRequestStatus | | TRANSACTION-ID: 123 | | FLOOR-REQUEST-ID: 345 | | REQUEST-STATUS: Pending | |<-----------------------------| Camarillo, et al. Expires February 17, 2005 [Page 9] Internet-Draft BFCP August 2004 | | | FloorRequestStatus | | FLOOR-REQUEST-ID: 345 | | REQUEST-STATUS: Accepted | |<-----------------------------| | | | | | FloorRequestStatus | | FLOOR-REQUEST-ID: 345 | | REQUEST-STATUS: Granted | |<-----------------------------| | | | | | FloorRelease | | TRANSACTION-ID: 124 | | FLOOR-REQUEST-ID: 345 | |----------------------------->| | | | FloorRequestStatus | | TRANSACTION-ID: 124 | | FLOOR-REQUEST-ID: 345 | | REQUEST-STATUS: Released | |<-----------------------------| | | Figure 2: Requesting and releasing a floor Camarillo, et al. Expires February 17, 2005 [Page 10] Internet-Draft BFCP August 2004 Client or Floor Control Chair Server | FloorInfo | | TRANSACTION-ID: 123 | | FLOOR-ID: 15 | |----------------------------->| | | |FloorStatus | | TRANSACTION-ID: 123 | | FLOOR-ID: 15 | | FLOOR-REQUEST-ID: 345 | | REQUEST-STATUS: Granted | | FLOOR-REQUEST-ID: 348 | | REQUEST-STATUS: 1st in queue| |<-----------------------------| | | |FloorStatus | | FLOOR-ID: 15 | | FLOOR-REQUEST-ID: 348 | | REQUEST-STATUS: Granted | |<-----------------------------| | | |FloorStatus | | FLOOR-ID: 15 | |<-----------------------------| | | Figure 3: Obtaining status information about a floor 4.2 Floor Chair - Floor Control Server Interface TBD. For the time being, below there is the typical call flow for this interface. Camarillo, et al. Expires February 17, 2005 [Page 11] Internet-Draft BFCP August 2004 Chair Floor Control Server | ChairAction | | TRANSACTION-ID: 123 | | FLOOR-ID: 15 | | FLOOR-REQUEST-ID: 345 | | REQUEST-STATUS: Granted | |----------------------------->| | | | ChairActionAck | | TRANSACTION-ID: 123 | |<-----------------------------| | | Figure 4: Chair invoking an action at the floor control server 5. Packet Format BFCP packets consist of an 8-byte fixed header followed by attributes. All the protocol values MUST be sent in network byte order. 5.1 FIXED-HEADER Format The following is the FIXED-HEADER format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |Reserved | Primitive | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Conference ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver: the 3-bit version field MUST be set to 1 to indicate this version of BFCP. Reserved: at this point, the 5 bits in the reserved field SHOULD be set to zero by the sender of the message and MUST be ignored by the receiver. Primitive: this 8-bit field identifies the main purpose of the message. The following primitive values are defined: Camarillo, et al. Expires February 17, 2005 [Page 12] Internet-Draft BFCP August 2004 Value Primitive Direction _________________________________________________________ 0 FloorRequest C -> S 1 FloorRelease C -> S 2 FloorRequestInfo S -> C ; Ch -> S 3 FloorRequestStatus S -> C 4 FloorInfo C -> S ; Ch -> S 5 FloorStatus S -> C ; S -> Ch 6 ChairAction Ch -> S 7 ChairActionAck S -> Ch 8 Ping C -> S ; Ch <-> S 9 PingAck S -> C ; Ch <-> S 10 Error S -> C ; S -> Ch S: Server C: Client Ch: Chair Payload Length: this 16-bit field contains length of the message in 4-byte units excluding the fixed header. Conference ID: this 32-bit identifies the conference the message belongs to. 5.2 Attribute Format BFCP attributes are encoded in TLV (Type-Length-Value) format. TLVs are 32-bit aligned. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Attribute Contents / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: this 7-bit field contains the code for the attribute. M: the 'M' bit, known as the Mandatory bit, indicates whether support of the attribute is required. If an unrecognized attribute with the 'M' bit set is received, the message is rejected. Length: this 8-bit field contains the length of the attribute in bytes, excluding any padding defined for specific attributes. The Camarillo, et al. Expires February 17, 2005 [Page 13] Internet-Draft BFCP August 2004 Type, 'M' bit, and Length fields are included. Attribute Contents: the contents of the different TLVs are defined in the following sections. 5.2.1 FLOOR-ID The following is the format of the contents of the FLOOR-ID attribute, whose attribute type is 1. 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 = 1 |M| Length | Floor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Floor ID: this field contains a 16-bit value that uniquely identifies a floor within a conference. 5.2.2 USER-ID The following is the format of the contents of the USER-ID attribute, whose attribute type is 2. 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 = 2 |M| Length | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ User ID: this field contains a 16-bit value that uniquely identifies a user within a conference. 5.2.3 BENEFICIARY-ID The following is the format of the contents of the BENEFICIARY-ID attribute, whose attribute type is 2. 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 = 2 |M| Length | Beneficiary ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Beneficiary ID: this field contains a 16-bit value that uniquely Camarillo, et al. Expires February 17, 2005 [Page 14] Internet-Draft BFCP August 2004 identifies a user within a conference. 5.2.4 TRANSACTION-ID The following is the format of the contents of the TRANSACTION-ID attribute, whose attribute type is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 |M| Length | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transaction ID: this field contains a 16-bit value that allows users to match a given message with its response. 5.2.5 FLOOR-REQUEST-ID The following is the format of the contents of the FLOOR-REQUEST-ID attribute, whose attribute type is 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 |M| Length | Floor Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Floor Request ID: this field contains a 16-bit value that indentifies a floor request at the floor control server. 5.2.6 HUMAN-READABLE-INFO The following is the format of the contents of the HUMAN-READABLE-INFO attribute, whose attribute type is 5. 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 = 4 |M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Camarillo, et al. Expires February 17, 2005 [Page 15] Internet-Draft BFCP August 2004 Text: this field contains UTF-8 [13] encoded text. In some situations, the contents of the Text field may be generated by an automaton. If such automaton has information about the preferred language of the receiver of a particular 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 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 by the receiver. If the TLV is already 32-bit aligned, no padding is needed. 5.2.7 INTEGRITY The following is the format of the contents of the INTEGRITY attribute, whose attribute type is 6. 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 = 5 |M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | | + HMAC-SHA1 + | | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HMAC-SHA1: this 20-byte field contains an HMAC-SHA1 [1] of the BFCP message. Its calculation is described in Section 10. 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 zero by the sender and MUST be ignored by the receiver. 5.2.8 REQUEST-STATUS The following is the format of the contents of the REQUEST-STATUS attribute, whose attribute type is 7. Camarillo, et al. Expires February 17, 2005 [Page 16] Internet-Draft BFCP August 2004 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 = 6 |M| Length | Request Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue Position | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Request Status: this 16-bit field contains the status of the request, as described in the following table. Value Status ______________________________ 0 Pending 1 Accepted 2 Granted 3 Denied 4 Cancelled 5 Released 6 Revoked 7 Replaced Queue Position: this 16-bit field contains, when applicable, the position of the floor request in the floor request queue at the server. If the Request Status value is different from Accepted, the floor control server does not implement a floor request queue, or the floor control server does not want to provide the client with this information, all the bits of this field SHOULD be set to zero. A floor request is in Pending state if the floor control server needs to contact a floor chair in order to accept the floor request, but has not done it yet. Once the floor control chair accepts the floor request, the floor request is moved to the Accepted state. Padding: two bytes of padding added so that the contents of the REQUEST-STATUS TLV is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. 5.2.9 ERROR-CODE The following is the format of the contents of the ERROR-CODE attribute, whose attribute type is 8. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Camarillo, et al. Expires February 17, 2005 [Page 17] Internet-Draft BFCP August 2004 | Type = 7 |M| Length | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Error Specific Details | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code: this 16-bit field contains an error code from the following table. Value Meaning __________________________________________________________ 0 Conference does not Exist 1 Authentication Failed 2 Unknown Mandatory TLV 3 Floor Request ID Does Not Exist 4 Unauthorized Operation 5 User does not Exist 6 Invalid Request-ID 7 INTEGRITY TLV Required Error Specific Details: Present only for certain Error Codes. In this document, only for Error Code 2 (Unknown Mandatory TLV). For Error Code 2, this field contains the Types of the TLVs (which were present in the message that triggered the Error message) that were unknown to the receiver, encoded as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unknown TLV Type | Unknown TLV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Unknown TLV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unknown TLV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding: one, two, or three bytes of padding added so that the contents of the ERROR-CODE TLV is 32-bit aligned. If the TLV is already 32-bit aligned, no padding is needed. The Padding bits SHOULD be set to zero by the sender and MUST be Camarillo, et al. Expires February 17, 2005 [Page 18] Internet-Draft BFCP August 2004 ignored by the receiver. Note all the Error Codes defined in this document but Error Code 2, result in a TLV which is already 32-bit aligned (i.e., no need of padding). Error Code 2 results in a TLV that may need 2 bytes of padding. 5.2.10 USER-DISPLAY-NAME The USER-DISPLAY-NAME attribute type is 9 and its format is the same as the HUMAN-READABLE-INFO attribute. The Text field in the USER-DISPLAY-NAME attribute contains the name of the user. 5.2.11 USER-URI The USER-URI attribute type is 10 and its format is the same as the HUMAN-READABLE-INFO attribute. The Text field in the USER-URI attribute contains the URI of the user. 5.2.12 PRIORITY The following is the format of the contents of the PRIORITY attribute, whose attribute type is 11. 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 | Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Priority: the higher the 8-bit value, the more priority is requested for a given floor request. 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 receiver. 6. Message Format This section contains the ABNF [3] of the BFCP messages. 6.1 FloorRequest Clients request a floor by sending a FloorRequest message to the floor control server. In addition, the FloorRequest message is also used to modify existing floor requests. The following is the format of the FloorRequest message: Camarillo, et al. Expires February 17, 2005 [Page 19] Internet-Draft BFCP August 2004 FloorRequest = (FIXED-HEADER) (TRANSACTION-ID) (USER-ID) [BENEFICIARY-ID] [FLOOR-REQUEST-ID] *(FLOOR-ID) [HUMAN-READABLE-INFO] [PRIORITY] [INTEGRITY] 6.2 FloorRelease Clients release a floor by sending a FloorRelease message to the floor control server. Clients also use the FloorRelease message to cancel pending floor requests. The following is the format of the FloorRelease message: FloorRelease = (FIXED-HEADER) (TRANSACTION-ID) (USER-ID) (FLOOR-REQUEST-ID) [INTEGRITY] 6.3 FloorRequestInfo Clients request information about a floor request by sending a FloorRequestInfo message to the floor control server. The following is the format of the FloorRequest message: FloorRequestInfo = (FIXED-HEADER) (TRANSACTION-ID) (USER-ID) [BENEFICIARY-ID] [FLOOR-REQUEST-ID] [INTEGRITY] 6.4 FloorRequestStatus The floor control server informs clients about the status of their floor requests by sending them FloorRequestStatus messages. The following is the format of the FloorRequestStatus message: Camarillo, et al. Expires February 17, 2005 [Page 20] Internet-Draft BFCP August 2004 FloorRequestStatus = (FIXED-HEADER) (TRANSACTION-ID) (USER-ID) [BENEFICIARY-ID] [USER-DISPLAY-NAME] [USER-URI] 1*( (FLOOR-REQUEST-ID) 1*(FLOOR-ID) [HUMAN-READABLE-INFO] [PRIORITY] (REQUEST-STATUS) ) [INTEGRITY] 6.5 FloorInfo Clients request information about a floor or floors by sending a FloorInfo message to the floor control server. The following is the format of the FloorRequest message: FloorInfo = (FIXED-HEADER) (TRANSACTION-ID) (USER-ID) *(FLOOR-ID) [INTEGRITY] 6.6 FloorStatus The floor control server informs clients about the status, e.g., the current holder(s), of a floor by sending them FloorStatus messages. The following is the format of the FloorStatus message: FloorStatus = (FIXED-HEADER) [TRANSACTION-ID] (USER-ID) [FLOOR-ID] *( (FLOOR-REQUEST-ID) [BENEFICIARY-ID] [USER-DISPLAY-NAME] [USER-URI] *(FLOOR-ID) [HUMAN-READABLE-INFO] [PRIORITY] (REQUEST-STATUS) ) [INTEGRITY] Camarillo, et al. Expires February 17, 2005 [Page 21] Internet-Draft BFCP August 2004 6.7 ChairAction Chairs send instructions to floor control servers by sending ChairAction messages. The following is the format of the ChairAction message: ChairAction = (FIXED-HEADER) (TRANSACTION-ID) (USER-ID) 1*(FLOOR-ID) (FLOOR-REQUEST-ID) (REQUEST-STATUS) [HUMAN-READABLE-INFO] [INTEGRITY] 6.8 ChairActionAck Floor control servers condirm that they have accepted a ChairAction message by sending a ChairActionAck message. The following is the format of the ChairActionAck message: ChairActionAck = (FIXED-HEADER) (TRANSACTION-ID) (USER-ID) [INTEGRITY] 6.9 Ping Clients check the liveness of servers, and servers of clients, by sending a Ping message. The following is the format of the Ping message: Ping = (FIXED-HEADER) (TRANSACTION-ID) (USER-ID) [INTEGRITY] 6.10 PingAck 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 message: Camarillo, et al. Expires February 17, 2005 [Page 22] Internet-Draft BFCP August 2004 PingAck = (FIXED-HEADER) (TRANSACTION-ID) (USER-ID) [INTEGRITY] 6.11 Error The floor control server informs clients about errors processing requests by sending them Error messages. The following is the format of the Error message: Error = (FIXED-HEADER) (TRANSACTION-ID) (USER-ID) (ERROR-CODE) [HUMAN-READABLE-INFO] [INTEGRITY] 7. Transport BFCP entities exchange BFCP messages using TCP connections. TCP provides an in-order reliable delivery of a stream of bytes. Consequently, message framing is implemented in the application layer. BFCP implements application-layer framing using 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 BFCP relies on lower-layer security mechanisms to provide replay protection, and confidentiality. BFCP servers MUST support TLS [4], and clients SHOULD support TLS. Clients and servers MAY support other security mechanisms. OPEN ISSUE: do we want to implement replay-protection in the protocol instead of relying on TLS? Servers and clients that implement TLS MUST support TBD. (cypher and hash algorithm). 9. Protocol Transactions In BFCP, there are two types of transactions: client-initiated Camarillo, et al. Expires February 17, 2005 [Page 23] Internet-Draft BFCP August 2004 transactions and server-initiated transactions (notifications). Client-initiated transactions consist of a request from a client to a server and a response from the server to the client. The request carries a TRANSACTION-ID TLV which the server copies into the response. Clients use Transaction ID values to match responses with previously-issued requests. Server-initiated transactions consist of a single message from a server to a client. Consequently, since they do not trigger any response, server-initiated transactions do not have Transaction IDs associated with them. 9.1 Client Behavior A client starting a client-initiated transaction MUST set the Conference ID in the FIXED-HEADER of the message to the Conference ID for the conference that the client obtained previously. The client MUST set the Transaction ID value in the TRANSACTION-ID 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 the Transaction ID value to match this FloorRequest message with the response from the floor control server. 9.2 Server Behavior A server sending a response within a client-initiated transaction MUST copy the Conference ID and the TRANSACTION-ID TLV from the request received from the client into the response. Server-initiated transactions MUST NOT contain a TRANSACTION-ID TLV. 10. Authentication BFCP uses the INTEGRITY TLV to provide client and server authentication, and message integrity. The INTEGRITY TLV contains an 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 BFCP message, including the FIXED-HEADER, up to and including the TLV preceding the INTEGRITY TLV. This text is then padded with zeroes so as to be a multiple of 64 bytes. As a result, the INTEGRITY TLV MUST be the last attribute in any BFCP message. The key used as input to HMAC is the secret shared between the server and the user identified by the USER-ID TLV in the message. 10.1 Client Behavior Clients SHOULD add an INTEGRITY TLV to all their messages. Furthermore, if a client generates a message without this TLV and Camarillo, et al. Expires February 17, 2005 [Page 24] Internet-Draft BFCP August 2004 receives an Error response with Error Code 7 (INTEGRITY TLV Required), the client SHOULD NOT send more messages without the INTEGRITY TLV to the same server within the same conference. When a client receives a BFCP message with an INTEGRITY TLV, it 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 server and the user identified by the USER-ID TLV in the message. If the resulting value is the same as the one in the INTEGRITY TLV, authentication is considered successful. If the resulting value is different than the one in the INTEGRITY TLV, authentication is considered to have failed and the message MUST NOT be processed further. 10.2 Server Behavior Servers SHOULD add an INTEGRITY TLV to all their messages. 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. 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 Code 7 (INTEGRITY TLV Required). When a server receives a BFCP message with an INTEGRITY TLV, it 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 server and the user identified by the USER-ID TLV in the message. If the resulting value is the same as the one in the INTEGRITY TLV, authentication is considered successful. If the resulting value is different than the one in the INTEGRITY TLV, authentication is considered to have failed, in which case the server SHOULD return an Error message with Error Code 1 (Authentication Failed). Messages that cannot be authenticated MUST NOT be processed further. 11. Client Operations This section specifies how clients can perform different operations, such as requesting a floor, using the protocol elements described in earlier sections. Chair operations, such as instructing the floor server to grant or revoke a floor, are described in Section 16. 11.1 Requesting a Floor 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 Camarillo, et al. Expires February 17, 2005 [Page 25] Internet-Draft BFCP August 2004 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 9.1. Additionally, the client follows the rules in Section 10.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. If the user sending the FloorRequest message (identified by the USER-ID TLV) is not the same as the user requesting the floor (i.e., a third party floor request), the client SHOULD add a BENEFICIARY-ID TLV to the message identifying the beneficiary of the floor. 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 server will treat all the floor requests as an atomic package. That is, the floor control server will either grant or deny all the floors in the FloorRequest message. The client may use a HUMAN-READABLE-INFO TLV to state the reason why 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. 11.1.1 Receiving a Response A message from the server is considered to be a response to the FloorRequest message if the message from the server has the same Conference ID and Transaction ID as the FloorRequest message, as described in Section 9.1. If the response is a FloorRequestStatus message, the client obtains information about the status of the FloorRequest in a REQUEST-STATUS TLV. If the Request Status value is Granted, the client has been granted all the floors that were requested in the FloorRequest message. If the Request Status value is Denied, the client has been denied all the floors that were requested in the FloorRequest message. The HUMAN-READABLE-INFO TLV, if present, provides extra information which the client MAY display to the user. A floor request is considered to be ongoing while it is in the Pending, Accepted, or Granted states. FloorRequestStatus messages Camarillo, et al. Expires February 17, 2005 [Page 26] Internet-Draft BFCP August 2004 carrying any of these states will contain a FLOOR-REQUEST-ID TLV. The value of this TLV is used to match subsequent messages received at the client side (e.g., further FloorRequestStatus messages) or at 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 FloorRequest message for some reason, which is described in the Error message. 12. Requesting Information about Floor Requests Clients request information about the current status of one or several floor request by sending a FloorRequestInfo message to the floor control server. The client sets the Conference ID in the FIXED-HEADER and the TRANSACTION-ID TLV following the rules given in Section 9.1. Additionally, the client follows the rules in Section 10.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. If the client wants to request the status of a single floor request, it MUST insert a FLOOR-REQUEST-ID TLV that identifies the floor request at the server. The client can also request information about all the ongoing floor requests associated with a particular user. In this case, the client MUST NOT insert a FLOOR-REQUEST-ID TLV. If the beneficiary of the floor requests the client is requesting information about is not the client issuing the FloorRequestInfo message (which is identified by the USER-ID TLV in the message) the client SHOULD insert a BENEFICIARY-ID TLV. 12.1 Receiving a Response On reception of the FloorRequestInfo message, the server will respond with a FloorRequestStatus message or with an error message. That is, the server will respond using the same message types as when it receives a FloorRequest message. Consequently, after sending the FloorRequestInfo message, the client follows the steps described in Section 11.1.1. If the FloorRequestInfo message requested information about several floor requests, the FloorRequestStatus message will contain information about all of them. Camarillo, et al. Expires February 17, 2005 [Page 27] Internet-Draft BFCP August 2004 13. Cancelling a Floor Request and Releasing a Floor A client that wishes to cancel an ongoing floor request does so by sending a FloorRelease message to the floor control server. The ABNF in Section 6.2 describes the TLVs that a FloorRelease 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 9.1. Additionally, the client follows the rules in Section 10.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. Note that the FloorRelease message is also used to release a floor or floors that were granted to the client (from the protocol perspective both are ongoing floor requests). Using the same message in both situations helps resolve the race condition that occurs when the FloorRelease message and the FloorGrant message cross each other on the wire. The client uses the FLOOR-REQUEST-ID that was received in the response to the FloorRequest message that the FloorRelease message is cancelling. 13.1 Receiving a Response On reception of the FloorRelease message, the server will respond as with a FloorRequestStatus message or with an error message. That is, the server will respond using the same message types as when it receives a FloorRequest message. Consequently, after sending the FloorRelease message, the client follows the steps described in Section 11.1.1. It is possible that the FloorRelease message crosses on the wire with a FloorRequestStatus message from the server with a Request Status different from Cancelled. In any case, such a FloorRequestStatus message will not be a response to the FloorRelease message, because its Transaction ID will not match that of the FloorRelease. 14. Requesting Information about Floors Clients request information about the status of one or several floors by sending a FloorInfo message to the floor control server. The client sets the Conference ID in the FIXED-HEADER and the Camarillo, et al. Expires February 17, 2005 [Page 28] Internet-Draft BFCP August 2004 TRANSACTION-ID TLV following the rules given in Section 9.1. Additionally, the client follows the rules in Section 10.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. The client inserts in the message all the FLOOR-IDs it wants to receive information about. The server will send periodic information about all these floors. If the client does not want to receive information about a particular floor any longer, it sends a new FloorInfo message removing the FLOOR-ID of this floor. If the client does not want to receive information about any floor, it sends a FloorInfo message with no FLOOR-ID TLV. 14.1 Receiving a Response A message from the server is considered to be a response to the FloorInfo message if the message from the server has the same Conference ID and Transaction ID as the FloorRequest message, as described in Section 9.1. 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, it will contain information about one of the floors the client requested information about. If the client did not include any FLOOR-ID in its FloorInfo message, the FloorStatus message from the server will not include any either. After the first FloorStatus, the server will continue sending FloorStatus messages periodically informing the client about changes on the floors the client requested information about. 15. Checking the Liveness of a Server 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 Section 6.9 describes the TLVs that a Ping message can contain. In addition, the ABNF specifies which of these TLVs are mandatory, and which ones are optional. The client sets the Conference ID in the FIXED-HEADER and the TRANSACTION-ID TLV following the rules given in Section 9.1. Additionally, the client follows the rules in Section 10.1 which relate to the authentication and the protection of the integrity of the message (i.e., to the INTEGRITY TLV). Camarillo, et al. Expires February 17, 2005 [Page 29] Internet-Draft BFCP August 2004 15.1 Receiving Responses 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 Conference ID and Transaction ID as the Ping message, as described in Section 9.1. If the response is a PingAck message, the server is alive and the user identified by the User ID was authenticated successfully. If the response is an Error message, the server could not process the Ping message for some reason, which is described in the Error message. 16. Chair Operations This section specifies how clients acting as chairs can perform different operations, such as instructing the floor server to grant or revoke a floor, using the protocol elements described in earlier sections. 16.1 Obtaining Information about Floor Requests A chair can obtain information about the floor requests that the floor control server receives in different ways, which include using out-of-band mechanisms. Chairs using BFCP to obtain such information use the procedures described in Section 14. As a result, they receive information about floor requests that relate to specific floors in FloorStatus messages from the floor control server. 16.2 Instructing the Floor Control Server Chairs that wish to send instructions to a floor control server does so by sending a ChairAction message. The ABNF in Section 6.7 describes the TLVs that a ChairAction message can contain. In addition, the ABNF specifies which of these TLVs are mandatory, and which ones are optional. The chair sets the Conference ID in the FIXED-HEADER and the TRANSACTION-ID TLV following the rules given in Section 9.1. Additionally, the chair follows the rules in Section 10.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. The ChairAction message contains instructions that apply to one or more floors within a particular floor request. The floor or floors Camarillo, et al. Expires February 17, 2005 [Page 30] Internet-Draft BFCP August 2004 are identified by FLOOR-ID TLVs and the floor request is identified by a FLOOR-REQUEST-ID TLV, which are carries in the ChairAction message. For example, if a floor request consists of two floors that depend on different chairs, each chair will grant its floor within the floor request. Once both chairs have grant their floor, the floor control server will grant the floor request as a whole. On the other hand, if one of the chairs denies its floor, the floor control server will deny the floor request as a whole, regardless of the other chair's decision. The chair provides the new status for one or more floors within the floor request using a REQUEST-STATUS TLV. If the new status of the floor request is Accepted, the chair MAY use the Queue Position field to provide a queue position for the floor request. If the chair does not wish to provide a queue position, all the bits of the Queue Position field SHOULD be set to zero. The chair SHOULD use the Status Revoked to revoke a floor that was granted (i.e., Granted status) and to reject floor requests in any other status (e.g., Pending and Accepted). Note a floor request may involve several floors and that a ChairAction message could only deal with a subset of these floors (e.g., if a single chair is not authorized to manage all the floors). In this case, the REQUEST-STATUS that the chair provides in the ChairAction message might not be the actual status that the floor request gets at the server. The floor control server will combine the instructions received from the different chairs to come up with the actual status of the floor request. The chair may use a HUMAN-READABLE-INFO TLV to state the reason why the floor or floors are being accepted, granted, or revoked. The Text in the HUMAN-READABLE-INFO TLV is intended for human consumption. 16.2.1 Receiving a Response A message from the server is considered to be a response to the ChairAction message if the message from the server has the same Conference ID and Transaction ID as the ChairAction message, as described in Section 9.1. A ChairActionAck message from the server confirms that the server has accepted the ChairAction message. An Error message indicates that the server could not process the ChairAction message for some reason, which is described in the Error message. Camarillo, et al. Expires February 17, 2005 [Page 31] Internet-Draft BFCP August 2004 17. Server Operations This section specifies how servers can perform different operations, such as granting a floor, using the protocol elements described in earlier sections. On reception of a message from a client, the floor control server 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 Error message, as described in Section 17.7, with Error code 0 (Conference does not Exist). On reception of a message from a client, the floor control server follows the rules in Section 10.2, which relate to the authentication of the message. On reception of a message from a client, the floor control server 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 them, the floor server SHOULD send an Error message, as described in Section 17.7, with Error code 2 (Authentication Failed). The Error message SHOULD list the TLVs that were not understood. OPEN ISSUE: can servers use new mandatory TLVs in their messages? Right now we do not have a way for clients to complain about unsupported TLVs received from the server. 17.1 Reception of a FloorRequest Message The processing of a FloorRequest message by a server involves generating a FloorRequestStatus message. The floor control server SHOULD generate a FloorRequestStatus message as soon as possible. If the floor server cannot accept, grant, or deny the floor request right away (e.g., a decision from a chair is needed), it SHOULD use a Request Status value of Pending. The server copies the Conference ID and the TRANSACTION-ID TLV from the FloorRequest into the FloorRequestStatus, as described in Section 9.2. Additionally, the server MUST assign an identitifier that is unique within the conference to this floor request, and insert it in a FLOOR-REQUEST-ID TLV into the FloorRequestStatus message. This indentifier will be used by the client to refer to this specific floor request in the future. The server follows the rules in Section 10.2 which relate to authentication and the use of the INTEGRITY TLV. At later time, when the status of the floor request changes, the Camarillo, et al. Expires February 17, 2005 [Page 32] Internet-Draft BFCP August 2004 floor control server SHOULD send a new FloorRequestStatus message with the appropriate Request Status. This FloorRequestStatus message MUST contain a FLOOR-REQUEST-ID TLV identifying the floor request, but MUST NOT contain any TRANSACTION-ID TLV. The server may add a HUMAN-READABLE-INFO TLV to provide extra information to the user about its decision. The rate at which the floor control server sends FloorRequestStatus messages is a matter of local policy. A server may choose to send a new FloorRequestStatus message every time the floor request moves in the floor request queue while another may choose to only send a new FloorRequestStatus message when the floor request is Granted or Denied. 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 accomplish this, the floor control server follows the rules in Section 17.4. 17.2 Reception of a FloorRequestInfo Message The processing of a FloorRequestInfo message by a server involves generating a FloorRequestStatus message. The FloorRequestInfo 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 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 USER-ID TLV. If the FloorRequestInfo 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). On reception of a FloorRequestInfo message, the floor control server SHOULD generate a FloorRequestStatus message as soon as possible. The server copies the Conference ID and the TRANSACTION-ID TLV from the FloorRequestInfo message into the FloorRequestStatus, as described in Section 9.2. The server follows the rules in Section 10.2 which relate to authentication and the use of the INTEGRITY TLV. 17.3 Reception of a FloorRelease Message The processing of a FloorRelease message by a server involves generating a FloorRequestStatus message. The FloorRelease message identifies the floor request it applies to using a FLOOR-REQUEST-ID. Camarillo, et al. Expires February 17, 2005 [Page 33] Internet-Draft BFCP August 2004 If the FloorRelease 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). On reception of a FloorRelease message with a valid FLOOR-REQUEST-ID, the floor control server SHOULD generate a FloorRequestStatus message as soon as possible. If the floor server can authorize the release operation right away, it SHOULD use a Request Status value of Released, if the floor had been previously granted, or of Cancelled, if it had not. The server may add a HUMAN-READABLE-INFO TLV to provide extra information to the user about its decision. The server copies the Conference ID and the TRANSACTION-ID TLV from the FloorRelease into the FloorRequestStatus, as described in Section 9.2. The server follows the rules in Section 10.2 which relate to authentication and the use of the INTEGRITY TLV. 17.4 Reception of a FloorInfo Message A server receiving a FloorInfo message from a client SHOULD keep this client informed about the status of the floors identified by FLOOR-IDs in the FloorInfo message. Servers keep clients informed by using FloorStatus messages. The information FloorInfo messages carry may depend on the user requesting the information. For example, a chair may be able to receive information about pending requests while a regular user may not be authorized to do so. The server may provide information about a number of floor requests in a single FloorInfo message. For each floor request, the server provides its FLOOR-REQUEST-ID and its REQUEST-STATUS, and may provide further information such as its BENEFICIARY-ID. On reception of a FloorInfo message with one or more FLOOR-ID TLVs, the server generates a FloorStatus message for one of the floors identified in the FloorInfo message. The server copies the Conference ID and the TRANSACTION-ID TLV from the FloorInfo message into the FloorStatus message, as described in Section 9.2. The server follows the rules in Section 10.2 which relate to authentication and the use of the INTEGRITY TLV. After sending this message, the server SHOULD continue sending Camarillo, et al. Expires February 17, 2005 [Page 34] Internet-Draft BFCP August 2004 FloorStatus messages about all the floors the client requested information about. These messages MUST NOT carry a TRANSACTION-ID TLV. The rate at which the floor control server sends FloorStatus messages is a matter of local policy. A server may choose to send a new FloorRequestStatus message every time a new floor request arrives while another may choose to only send a new FloorStatus message when a new floor request is Granted. 17.5 Reception of a ChairAction Message On reception of a ChairAction message, the floor control server checks whether the chair that send the message is authorized to perform the operation being requested. If the chair is authorized, the floor control server performs the operation and sends a ChairActionAck message to the client. If the new Status in the ChairAction message is Accepted and all the bits of the Queue Position field are zero, the server assigns a queue position (e.g., the last in the queue) to the floor request based on local policy (in case the server implements a queue). The server copies the Conference ID and the TRANSACTION-ID TLV from the ChairAction message into the ChairActionAck message, as described in Section 9.2. The server follows the rules in Section 10.2 which relate to authentication and the use of the INTEGRITY TLV. If the floor control server cannot find a floor request that matches the FLOOR-REQUEST-ID TLV in the ChairAction message the floor control 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). If the chair is not authorized to perform the operation being requested, the floor control server generates an Error message, as described in Section 17.7, with an Error code with a value of 4 (Unauthorized Operation). 17.6 Reception of a Ping Message The processing of a Ping message by a server involves generating a PingAck message. On reception of a Ping message, the floor control server SHOULD generate a PingAck message as soon as possible. The server copies the Conference ID and the TRANSACTION-ID TLV from the Ping into the PingAck, as described in Section 9.2. The server follows the rules in Section 10.2 which relate to Camarillo, et al. Expires February 17, 2005 [Page 35] Internet-Draft BFCP August 2004 authentication and the use of the INTEGRITY TLV. 17.7 Error Message Generation Error messages are always sent in response to a previous message from 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 addition, the ABNF specifies which of these TLVs are mandatory, and which ones are optional. Servers copy the Conference ID and the TRANSACTION-ID TLV from the message from the client into the Error message, as described in Section 9.2. The server follows the rules in Section 10.2 which relate to authentication and the use of the INTEGRITY TLV. 18. BFCP and the Offer/Answer Model The way a client obtains a the information needed to contact a BFCP floor control server is outside the scope of BCFP. Nevertheless, this section describes how to obtain such an information using an SDP [5] offer/answer [11] exchange. User agents typically use the offer/answer model to establish a number of media streams of different types. Following this model, a BFCP connection is described as any other media stream by using an SDP m line. 18.1 Fields in the m Line According to RFC 2327 [5], the m-line format is the following: m= The media field MUST have a value of "application". The port field is not used by BFCP, and MAY be set to any value chosen by the endpoint. A port field value of zero has the standard SDP meaning (i.e., rejection of the media stream). The port field is set following the rules in [14]. Depending on the value of the setup attribute (disccused in Section 18.4), the port field contains the port the remote endpoint will initiate its TCP connection to, or is irrelevant (i.e., the endpoint will initiate the connection towards the remote endpoint) and should be set to a value of 9, which is the discard port. Since BFCP only runs on top of TCP, the port is always a TCP port. Camarillo, et al. Expires February 17, 2005 [Page 36] Internet-Draft BFCP August 2004 We define two new values for the transport field: TCP/BFCP and TCP/ TLS/BFCP. The fmt (format) list is ignored for BFCP. The fmt list of BFCP m lines SHOULD contain a single "*" character. The following is an example of an m line for a BFCP connection: m=application 20000 TCP/BFCP * 18.2 The confid and userid SDP Parameters We define the confid and the userid SDP media-level attributes. Their syntax is: confid-attribute = "a=confid: " conference-id conference-id = token userid-attribute = "a=userid: " user-id user-id = token The confid and the userid attributes carry the integer representation of a conference ID and a user ID respectively. Endpoints which use the offer/answer model to establish BFCP connections MUST support the confid and the userid attributes. A floor control server acting as an offerer or as an answerers SHOULD include these attributes in its session descriptions. 18.3 The k line If the offer/answer exchange is encrypted and integrity protected, the offerer MAY use an SDP k line to provide the answerer with a shared secret to be used to calculate the value of the INTEGRITY TLVs. The following is an example of a k line: k=base64:c2hhcmVkLXNlY3JldA== 18.4 TCP Connection Management The management of the TCP connection used to transport BFCP is performed using the setup and connid attributes as defined in [14]. Camarillo, et al. Expires February 17, 2005 [Page 37] Internet-Draft BFCP August 2004 The setup attribute indicates which of the endpoints (client or floor control server) initiates the TCP connection. The connid attribute handles TCP connection reestablishment. 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 at a minimum learn enough information about floors to use the floor control protocol. This section will need to be harmonized with the media policy work. We define the floorid SDP media-level attribute. Its syntax is: floor-id-attribute = "a=floorid:" token " mstream:" 1*(token) The floorid attribute is used in BFCP m lines and associates a floor ID with a media stream. The token representing the floor ID is 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, which is identified by an SDP label attribute [draft-levin-mmmusic-sdp-media-label-00.txt]. Endpoints which use the offer/answer model to establish BFCP connections MUST support the floorid and the label attributes. A floor control server acting as an offerer or as an answerers SHOULD include these attributes in its session descriptions. 18.6 Example 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 session description is omitted in the examples, which only show m= lines and their attributes. m=application 20000 TCP/BFCP * k=base64:c2hhcmVkLXNlY3JldA== a=setup:passive a=connid:1 a=confid:4321 a=userid:1234 a=floorid:1 m-stream:10 a=floorid:2 m-stream:11 Camarillo, et al. Expires February 17, 2005 [Page 38] Internet-Draft BFCP August 2004 m=audio 20000 RTP/AVP 0 a=label:10 m=video 30000 RTP/AVP 31 a=label:11 The following is the answer returned by the user. m=application 9 TCP/BFCP * a=setup:active a=connid:1 m=audio 25000 RTP/AVP 0 m=video 35000 RTP/AVP 31 19. Security Considerations TBD. 20. IANA Considerations TBD 20.1 SDP Attributes Registration TBD: 21. Acknowledgments The XCON WG chairs, Adam Roach and Alan Johnston, provided useful ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat, Jonathan Rosenberg, and Miguel A. Garcia-Martin provided useful comments. 22. References 22.1 Normative References [1] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC Camarillo, et al. Expires February 17, 2005 [Page 39] Internet-Draft BFCP August 2004 2246, January 1999. [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [7] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999. [8] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999. [9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [12] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [14] Yon, D., "Connection-Oriented Media Transport in the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-08 (work in progress), July 2004. 22.2 Informational References [15] Schulzrinne, H., "Requirements for Floor Control Protocol", draft-ietf-xcon-floor-control-req-01 (work in progress), July 2004. [16] Koskelainen, P. and H. Khartabil, "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Conference Policy Manipulation", draft-koskelainen-xcon-xcap-cpcp-usage-02 (work in progress), February 2004. Camarillo, et al. Expires February 17, 2005 [Page 40] Internet-Draft BFCP August 2004 [17] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-05 (work in progress), July 2004. [18] Arkko, J., "MIKEY: Multimedia Internet KEYing", draft-ietf-msec-mikey-08 (work in progress), December 2003. [19] Rosenberg, J., "An Extensible Markup Language (XML) Document Format for Indicating Changes in XML Configuration Access Protocol (XCAP) Resources", draft-ietf-simple-xcap-package-02 (work in progress), July 2004. Authors' Addresses Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Joerg Ott Universitaet Bremen MZH 5180 Bibliothekstr. 1 Bremen D-28359 Germany EMail: jo@tzi.org Keith Drage Lucent Technologies Windmill Hill Business Park Swindon Wiltshire SN5 6PP UK EMail: drage@lucent.com Camarillo, et al. Expires February 17, 2005 [Page 41] Internet-Draft BFCP August 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any 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 such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Camarillo, et al. Expires February 17, 2005 [Page 42]