BFCPbis Working Group G. Camarillo Internet-Draft Ericsson Obsoletes: 4582 (if approved) K. Drage Intended status: Standards Track Alcatel-Lucent Expires: August 19, 2014 T. Kristensen Cisco J. Ott Aalto University C. Eckel Cisco February 15, 2014 The Binary Floor Control Protocol (BFCP) draft-ietf-bfcpbis-rfc4582bis-11 Abstract Floor control is a means to manage joint or exclusive access to shared resources 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 specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 19, 2014. Camarillo, et al. Expires August 19, 2014 [Page 1] Internet-Draft BFCP February 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Floor Creation . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Obtaining Information to Contact a Floor Control Server . 9 3.3. Obtaining Floor-Resource Associations . . . . . . . . . . 9 3.4. Privileges of Floor Control . . . . . . . . . . . . . . . 10 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 10 4.1. Floor Participant to Floor Control Server Interface . . . 11 4.2. Floor Chair to Floor Control Server Interface . . . . . . 15 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. COMMON-HEADER Format . . . . . . . . . . . . . . . . . . . 16 5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . . 19 5.2.1. BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 21 5.2.2. FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.3. FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 22 5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 23 5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 24 5.2.6.1. Error-Specific Details for Error Code 4 . . . . . 25 5.2.7. ERROR-INFO . . . . . . . . . . . . . . . . . . . . . . 25 5.2.8. PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . . 26 5.2.9. STATUS-INFO . . . . . . . . . . . . . . . . . . . . . 27 5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . . 27 5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . . 28 5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 29 5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . . 29 5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 30 5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 31 5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . . 32 Camarillo, et al. Expires August 19, 2014 [Page 2] Internet-Draft BFCP February 2014 5.2.17. FLOOR-REQUEST-STATUS . . . . . . . . . . . . . . . . . 32 5.2.18. OVERALL-REQUEST-STATUS . . . . . . . . . . . . . . . . 33 5.3. Message Format . . . . . . . . . . . . . . . . . . . . . . 34 5.3.1. FloorRequest . . . . . . . . . . . . . . . . . . . . . 34 5.3.2. FloorRelease . . . . . . . . . . . . . . . . . . . . . 34 5.3.3. FloorRequestQuery . . . . . . . . . . . . . . . . . . 34 5.3.4. FloorRequestStatus . . . . . . . . . . . . . . . . . . 35 5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 35 5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . . 35 5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . . 36 5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 36 5.3.9. ChairAction . . . . . . . . . . . . . . . . . . . . . 36 5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . . 36 5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 38 5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . . 38 5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38 5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 38 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . . 39 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . 40 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . 42 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42 6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . . 43 6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 44 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 44 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 45 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 46 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 46 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 47 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 47 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 47 9. Authentication and Authorization . . . . . . . . . . . . . . . 48 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 48 10. Floor Participant Operations . . . . . . . . . . . . . . . . . 49 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 49 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 49 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 50 10.1.3. Reception of a Subsequent FloorRequestStatus Message . . . . . . . . . . . . . . . . . . . . . . . 51 10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 52 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 52 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 52 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 53 11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 53 Camarillo, et al. Expires August 19, 2014 [Page 3] Internet-Draft BFCP February 2014 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 54 12. General Client Operations . . . . . . . . . . . . . . . . . . 55 12.1. Requesting Information about Floors . . . . . . . . . . . 55 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 55 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 55 12.1.3. Reception of a Subsequent FloorStatus Message . . . . 56 12.2. Requesting Information about Floor Requests . . . . . . . 56 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 57 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 57 12.3. Requesting Information about a User . . . . . . . . . . . 57 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 58 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 58 12.4. Obtaining the Capabilities of a Floor Control Server . . . 59 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 59 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 59 13. Floor Control Server Operations . . . . . . . . . . . . . . . 59 13.1. Reception of a FloorRequest Message . . . . . . . . . . . 60 13.1.1. Generating the First FloorRequestStatus Message . . . 60 13.1.2. Generation of Subsequent FloorRequestStatus Messages . . . . . . . . . . . . . . . . . . . . . . . 62 13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 63 13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 64 13.4. Reception of a FloorRelease Message . . . . . . . . . . . 66 13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 67 13.5.1. Generation of the First FloorStatus Message . . . . . 67 13.5.2. Generation of Subsequent FloorStatus Messages . . . . 69 13.6. Reception of a ChairAction Message . . . . . . . . . . . . 69 13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 70 13.8. Error Message Generation . . . . . . . . . . . . . . . . . 71 14. Security Considerations . . . . . . . . . . . . . . . . . . . 71 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 72 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 73 15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 74 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 75 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 76 16.1. Extensions for an unreliable transport . . . . . . . . . . 76 16.2. Other changes . . . . . . . . . . . . . . . . . . . . . . 77 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 18.1. Normative References . . . . . . . . . . . . . . . . . . . 79 18.2. Informational References . . . . . . . . . . . . . . . . . 79 Appendix A. Example Call Flows for BFCP over an Unreliable Transport . . . . . . . . . . . . . . . . . . . . . . 81 Appendix B. Motivation for Supporting an Unreliable Transport . . 84 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 85 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 86 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 86 Camarillo, et al. Expires August 19, 2014 [Page 4] Internet-Draft BFCP February 2014 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 88 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 88 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89 Camarillo, et al. Expires August 19, 2014 [Page 5] Internet-Draft BFCP February 2014 1. Introduction Within a conference, some applications need to manage the access to a set of shared resources, such as the right to send media to a particular media session. Floor control enables such applications to provide users with coordinated (shared or exclusive) access to these resources. The Requirements for Floor Control Protocol [13] 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. In addition, BFCP has been designed so that it can be used in low- bandwidth environments. The binary encoding used by BFCP achieves a small message size (when message signatures are not used) that keeps the time it takes to transmit delay-sensitive BFCP messages to a minimum. Delay-sensitive BFCP messages include FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It is expected that future extensions to these messages will not increase the size of these messages in a significant way. The remainder of this document is organized as follows: Section 2 defines the terminology used throughout this document, 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. Media Participant: An entity that has access to the media resources of a conference (e.g., it can receive a media stream). In floor- controlled conferences, a given media participant is typically colocated with a floor participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are not colocated. The protocol between a floor participant and a media participant (that are not colocated) is outside the scope of this document. Client: A floor participant or a floor chair that communicates with a Camarillo, et al. Expires August 19, 2014 [Page 6] Internet-Draft BFCP February 2014 floor control server using BFCP. Floor: A temporary permission to access or manipulate a specific shared resource or set of resources. Floor Chair: A logical entity that manages one floor (grants, denies, or revokes a floor). An entity that assumes the logical role of a floor chair for a given transaction may assume a different role (e.g., floor participant) for a different transaction. The roles of floor chair and floor participant are defined on a transaction-by- transaction basis. BFCP transactions are defined in Section 8. 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 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. The floor control server of a conference may perform other logical roles (e.g., floor participant) in another conference. Floor Participant: A logical entity that requests floors, and possibly information about them, from a floor control server. An entity that assumes the logical role of a floor participant for a given transaction may assume a different role (e.g., a floor chair) for a different transaction. The roles of floor participant and floor chair are defined on a transaction-by-transaction basis. BFCP transactions are defined in Section 8. In floor-controlled conferences, a given floor participant is typically colocated with a media participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are not colocated. Participant: An entity that acts as a floor participant, as a media participant, or as both. BFCP Connection: A transport association between BFCP entities, used to exchange BFCP messages. 3. Scope As stated earlier, BFCP is a protocol to coordinate access to shared resources in a conference following the requirements defined in [13]. Floor control complements other functions defined in the XCON conferencing framework [14]. The floor control protocol BFCP defined Camarillo, et al. Expires August 19, 2014 [Page 7] Internet-Draft BFCP February 2014 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 are defined by other protocols [14]. Figure 1 shows the tasks that BFCP can perform. +---------+ | Floor | | Chair | | | +---------+ ^ | | | Notification | | Decision | | | | Floor | v +-------------+ Request +---------+ +-------------+ | Floor |----------->| Floor | Notification | Floor | | Participant | | Control |------------->| Participant | | |<-----------| Server | | | +-------------+ Granted or +---------+ +-------------+ Denied Figure 1: Functionality provided by BFCP BFCP provides a means: o for floor participants to send floor requests to floor control servers. o for floor control servers to grant or deny requests to access a given resource from floor participants. o for floor chairs to send floor control servers decisions regarding floor requests. o for floor control servers to keep floor participants and floor chairs informed about the status of a given floor or a given floor request. Even though tasks that do not belong to the previous list are outside the scope of BFCP, some of these out-of-scope tasks relate to floor control and are essential for creating floors and establishing BFCP connections between different entities. In the following subsections, we discuss some of these tasks and mechanisms to perform Camarillo, et al. Expires August 19, 2014 [Page 8] Internet-Draft BFCP February 2014 them. 3.1. Floor Creation The association of a given floor with a resource or a set of resources (e.g., media streams) is out of the scope of BFCP as described in [14]. Floor creation and termination are also outside the scope of BFCP; these aspects are handled using the conference control protocol for manipulating the conference object. Consequently, the floor control server needs to stay up to date on changes to the conference object (e.g., when a new floor is created). Conference control clients using CCMP [18] can specify such floor- related settings in the element [17] of the to-be created conference object provided in the body of a CCMP confRequest/ create message issued to the conference control server. 3.2. Obtaining Information to Contact a Floor Control Server A client needs a set of data in order to establish a BFCP connection to a floor control server. This data includes the transport address of the server, the conference identifier, and a user identifier. Clients can obtain this information in different ways. One is to use an SDP offer/answer [12] exchange, which is described in [9]. How to establish a connection to a BFCP floor control server outside the context of an offer/answer exchange is described in [3]. Other mechanisms are described in the XCON framework [14] (and other related documents). 3.3. 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 session as its associated resource. Associations between floors and resources are part of the conference object. Floor participants and floor chairs need to know which resources are associated with which floors. They can obtain this information by using different mechanisms, such as an SDP offer/answer [12] exchange. How to use an SDP offer/answer exchange to obtain these associations is described in [9]. Note that floor participants perform SDP offer/answer exchanges with the conference focus of the conference. So, the conference focus needs to obtain information about associations between floors and resources in order to be able to provide this information to a floor participant in an SDP offer/answer Camarillo, et al. Expires August 19, 2014 [Page 9] Internet-Draft BFCP February 2014 exchange. Other mechanisms for obtaining this information, including discussion of how the information is made available to a (SIP) Focus, are described in the XCON framework [14] (and other related documents). According to the conferencing system policies, conference control clients using CCMP [18] can modify the floor settings of a conference by issuing CCMP confRequest/update messages providing the specific updates to the element of the target conference object. More information about CCMP and BFCP interaction can be found in [19]. 3.4. Privileges of Floor Control A participant whose floor request is granted has the right to use the resource or resources associated with the floor that was requested. For example, the participant may have the right to 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. Determination of which media participants can actually use the resources in the conference is discussed in the XCON Framework [14]. 4. Overview of Operation This section provides a non-normative description of BFCP operations. Section 4.1 describes the interface between floor participants 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 attributes. The common header contains, among other information, a 32-bit conference identifier. Floor participants, media participants, and floor chairs are identified by 16-bit user identifiers. BFCP supports nested attributes (i.e., attributes that contain attributes). These are referred to as grouped attributes. There are two types of transactions in BFCP: client-initiated transactions and server-initiated transactions. Section 8 describes both types of transactions in detail. Camarillo, et al. Expires August 19, 2014 [Page 10] Internet-Draft BFCP February 2014 4.1. Floor Participant to Floor Control Server Interface Floor participants request a floor by sending a FloorRequest message to the floor control server. BFCP supports third-party floor requests. That is, the floor participant sending the floor request need not be colocated with the media participant that will get the floor once the floor request is granted. FloorRequest messages carry the identity of the requester in the User ID field of the common header, and the identity of the beneficiary of the floor (in third- party floor requests) in a BENEFICIARY-ID attribute. Third-party floor requests can be sent, for example, by floor participants that have a BFCP connection to the floor control server but that are not media participants (i.e., they do not handle any media). FloorRequest messages identify the floor or floors being requested by carrying their 16-bit floor identifiers in FLOOR-ID attributes. 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. Floor control servers respond to FloorRequest messages with FloorRequestStatus messages, which provide information about the status of the floor request. The first FloorRequestStatus message is the response to the FloorRequest message from the client, and therefore has the same Transaction ID as the FloorRequest. Additionally, the first FloorRequestStatus message carries the Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent FloorRequestStatus messages related to the same floor request will carry the same Floor Request ID. This way, the floor participant can associate them with the appropriate floor request. Messages from the floor participant related to a particular floor request also use the same Floor Request ID as the first FloorRequestStatus Message from the floor control server. Figures 2 and 3 below show examples of call flows where BFCP is used over a reliable transport. Appendix A shows the same call flow examples using an unreliable transport. Figure 2 shows how a floor participant requests a floor, obtains it, and, at a later time, releases it. This figure illustrates the use, among other things, of the Transaction ID and the FLOOR-REQUEST-ID attribute. Camarillo, et al. Expires August 19, 2014 [Page 11] Internet-Draft BFCP February 2014 Floor Participant Floor Control Server |(1) FloorRequest | |Transaction ID: 123 | |User ID: 234 | |FLOOR-ID: 543 | |---------------------------------------------->| | | |(2) FloorRequestStatus | |Transaction ID: 123 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Pending | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(3) FloorRequestStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(4) FloorRequestStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(5) FloorRelease | |Transaction ID: 154 | |User ID: 234 | |FLOOR-REQUEST-ID: 789 | |---------------------------------------------->| | | Camarillo, et al. Expires August 19, 2014 [Page 12] Internet-Draft BFCP February 2014 |(6) FloorRequestStatus | |Transaction ID: 154 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Released | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| Figure 2: Requesting and releasing a floor Figure 3 shows how a floor participant requests to be informed on the status of a floor. The first FloorStatus message from the floor control server is the response to the FloorQuery message and, as such, has the same Transaction ID as the FloorQuery message. Subsequent FloorStatus messages consist of server-initiated transactions, and therefore their Transaction ID is 0. FloorStatus message (2) indicates that there are currently two floor requests for the floor whose Floor ID is 543. FloorStatus message (3) indicates that the floor requests with Floor Request ID 764 has been granted, and the floor request with Floor Request ID 635 is the first in the queue. FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has been granted. Floor Participant Floor Control Server |(1) FloorQuery | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID: 543 | |---------------------------------------------->| | | |(2) FloorStatus | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | Camarillo, et al. Expires August 19, 2014 [Page 13] Internet-Draft BFCP February 2014 | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 2nd | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(3) FloorStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(4) FloorStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | Camarillo, et al. Expires August 19, 2014 [Page 14] Internet-Draft BFCP February 2014 |<----------------------------------------------| Figure 3: Obtaining status information about a floor FloorStatus messages contain information about the floor requests they carry. For example, FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has as the beneficiary (i.e., the participant that holds the floor when a particular floor request is granted) the participant whose User ID is 154. The floor request applies only to the floor whose Floor ID is 543. That is, this is not a multi-floor floor request. A multi-floor floor request applies to more than one floor (e.g., a participant wants to be able to speak and write on the whiteboard at the same time). The floor control server treats a multi-floor floor request as an atomic package. That is, the floor control server either grants the request for all floors or denies the request for all floors. 4.2. Floor Chair to Floor Control Server Interface Figure 4 shows a floor chair instructing a floor control server to grant a floor. Note, however, that although the floor control server needs to take into consideration the instructions received in ChairAction messages (e.g., granting a floor), it does not necessarily need to perform them exactly as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server. For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well. In another example, a floor chair may instruct the floor control server to grant a floor to a participant. The floor control server needs to revoke the floor from its current holder before granting it to the new participant. So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state. Camarillo, et al. Expires August 19, 2014 [Page 15] Internet-Draft BFCP February 2014 Floor Chair Floor Control Server |(1) ChairAction | |Transaction ID: 769 | |User ID: 357 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | Request Status: Granted | |---------------------------------------------->| | | |(2) ChairActionAck | |Transaction ID: 769 | |User ID: 357 | |<----------------------------------------------| Figure 4: Chair instructing the floor control server 5. Packet Format BFCP packets consist of a 12-octet common header followed by attributes. All the protocol values MUST be sent in network byte order. 5.1. COMMON-HEADER Format The following is the format of the common header. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |R|F| Res | Primitive | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Conference ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Offset (if F is set) | Fragment Length (if F is set) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: COMMON-HEADER format Ver: This 3-bit field defines the version of BFCP that this message adheres to. This specification defines two versions: 1 and 2. The version field MUST be set to 1 when using BFCP over a reliable Camarillo, et al. Expires August 19, 2014 [Page 16] Internet-Draft BFCP February 2014 transport, i.e. as in [2]. The version field MUST be set to 2 when using BFCP over an unreliable transport with the extensions specified in this document. If an endpoint receives a message with an unsupported version field value, the receiving server MUST send an Error message with parameter value 12 (Unsupported Version) to indicate this. R: The Transaction Responder (R) flag-bit has relevance only for use of BFCP over an unreliable transport. When cleared, it indicates that this message is a request initiating a new transaction, and the Transaction ID that follows has been generated for this transaction. When set, it indicates that this message is a response to a previous request, and the Transaction ID that follows is the one associated with that request. When BFCP is used over a reliable transport, the flag has no significance and MUST be cleared by the sender and MUST be ignored by the receiver. F: The Fragmentation (F) flag-bit has relevance only for use of BFCP over an unreliable transport. When cleared, the message is not fragmented. When set, it indicates that the message is a fragment of a large fragmented BFCP message. (The optional fields Fragment Offset and Fragment Length described below are present only if the F flag is set). When BFCP is used over a reliable transport, the flag has no significance and MUST be cleared by the sender and MUST be ignored by the receiver. Res: At this point, the 3 bits in the reserved field MUST 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 August 19, 2014 [Page 17] Internet-Draft BFCP February 2014 +-------+-----------------------+--------------------+ | Value | Primitive | Direction | +-------+-----------------------+--------------------+ | 1 | FloorRequest | P -> S | | 2 | FloorRelease | P -> S | | 3 | FloorRequestQuery | P -> S ; Ch -> S | | 4 | FloorRequestStatus | P <- S ; Ch <- S | | 5 | UserQuery | P -> S ; Ch -> S | | 6 | UserStatus | P <- S ; Ch <- S | | 7 | FloorQuery | P -> S ; Ch -> S | | 8 | FloorStatus | P <- S ; Ch <- S | | 9 | ChairAction | Ch -> S | | 10 | ChairActionAck | Ch <- S | | 11 | Hello | P -> S ; Ch -> S | | 12 | HelloAck | P <- S ; Ch <- S | | 13 | Error | P <- S ; Ch <- S | | 14 | FloorRequestStatusAck | P -> S ; Ch -> S | | 15 | FloorStatusAck | P -> S ; Ch -> S | | 16 | Goodbye | P -> S ; Ch -> S ; | | | | P <- S ; Ch <- S | | 17 | GoodbyeAck | P -> S ; Ch -> S ; | | | | P <- S ; Ch <- S | +-------+-----------------------+--------------------+ S: Floor Control Server / P: Floor Participant / Ch: Floor Chair Table 1: BFCP primitives Payload Length: This 16-bit field contains the length of the message in 4-octet units, excluding the common header. If a Floor Control Server receives a message with an incorrect Payload Length field value, the receiving server MUST send an Error message with parameter value 13 (Incorrect Message Length) to indicate this. Note: BFCP is designed to achieve small message size, as explained in Section 1, and BFCP entities are REQUIRED to keep the BFCP message size smaller than the size limited by the 16-bit Payload Length field. To convey information not strictly related to floor control, other protocols should be used such as the XCON framework (cf. Section 3). Conference ID: This 32-bit unsigned integer field identifies the conference the message belongs to. Transaction ID: This field contains a 16-bit value that allows users to match a given message with its response (see Section 8). User ID: This field contains a 16-bit unsigned integer that uniquely Camarillo, et al. Expires August 19, 2014 [Page 18] Internet-Draft BFCP February 2014 identifies a participant within a conference. The identity used by a participant in BFCP, which is carried in the User ID field, is generally mapped to the identity used by the same participant in the session establishment protocol (e.g., in SIP). The way this mapping is performed is outside the scope of this specification. Fragment Offset: This optional field is present only if the F flag is set and contains a 16-bit value that specifies the number of 4-octet units contained in previous fragments, excluding the common header. Fragment Length: This optional field is present only if the F flag is set and contains a 16-bit value that specifies the number of 4-octet units contained in this fragment, excluding the common header. 5.2. Attribute Format BFCP attributes are encoded in TLV (Type-Length-Value) format. Attributes are 32-bit aligned. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Attribute Contents / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Attribute format Type: This 7-bit field contains the type of the attribute. Each attribute, identified by its type, has a particular format. The attribute formats defined are: Unsigned16: The contents of the attribute consist of a 16-bit unsigned integer. OctetString16: The contents of the attribute consist of 16 bits of arbitrary data. Camarillo, et al. Expires August 19, 2014 [Page 19] Internet-Draft BFCP February 2014 OctetString: The contents of the attribute consist of arbitrary data of variable length. Grouped: The contents of the attribute consist of a sequence of attributes. Note that extension attributes defined in the future may define new attribute formats. The following attribute types are defined: +------+---------------------------+---------------+ | Type | Attribute | Format | +------+---------------------------+---------------+ | 1 | BENEFICIARY-ID | Unsigned16 | | 2 | FLOOR-ID | Unsigned16 | | 3 | FLOOR-REQUEST-ID | Unsigned16 | | 4 | PRIORITY | OctetString16 | | 5 | REQUEST-STATUS | OctetString16 | | 6 | ERROR-CODE | OctetString | | 7 | ERROR-INFO | OctetString | | 8 | PARTICIPANT-PROVIDED-INFO | OctetString | | 9 | STATUS-INFO | OctetString | | 10 | SUPPORTED-ATTRIBUTES | OctetString | | 11 | SUPPORTED-PRIMITIVES | OctetString | | 12 | USER-DISPLAY-NAME | OctetString | | 13 | USER-URI | OctetString | | 14 | BENEFICIARY-INFORMATION | Grouped | | 15 | FLOOR-REQUEST-INFORMATION | Grouped | | 16 | REQUESTED-BY-INFORMATION | Grouped | | 17 | FLOOR-REQUEST-STATUS | Grouped | | 18 | OVERALL-REQUEST-STATUS | Grouped | +------+---------------------------+---------------+ Table 2: BFCP attributes M: The 'M' bit, known as the Mandatory bit, indicates whether support of the attribute is required. If a Floor Control Server receives an unrecognized attribute with the 'M' bit set the server MUST send an Error message with parameter value 4 (Unknown Mandatory Attribute) to indicate this. The 'M' bit is significant for extension attributes defined in other documents only. All attributes specified in this document MUST be understood by the receiver so that the setting of the 'M' bit is irrelevant for these. In all other cases, the unrecognized attribute is ignored but the message is processed. Length: This 8-bit field contains the length of the attribute in octets, excluding any padding defined for specific attributes. The Camarillo, et al. Expires August 19, 2014 [Page 20] Internet-Draft BFCP February 2014 length of attributes that are not grouped includes the Type, 'M' bit, and Length fields. The Length in grouped attributes is the length of the grouped attribute itself (including Type, 'M' bit, and Length fields) plus the total length (including padding) of all the included attributes. Attribute Contents: The contents of the different attributes are defined in the following sections. 5.2.1. BENEFICIARY-ID The following is the format of the BENEFICIARY-ID attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: BENEFICIARY-ID format Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference. Note that although the formats of the Beneficiary ID and of the User ID field in the common header are similar, their semantics are different. The Beneficiary ID is used in third-party floor requests and to request information about a particular participant. 5.2.2. FLOOR-ID The following is the format of the FLOOR-ID attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: FLOOR-ID format Floor ID: This field contains a 16-bit value that uniquely identifies a floor within a conference. Camarillo, et al. Expires August 19, 2014 [Page 21] Internet-Draft BFCP February 2014 5.2.3. FLOOR-REQUEST-ID The following is the format of the FLOOR-REQUEST-ID attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: FLOOR-REQUEST-ID format Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server. 5.2.4. PRIORITY The following is the format of the PRIORITY attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: PRIORITY format Prio: This field contains a 3-bit priority value, as shown in Table 3. Senders SHOULD NOT use values higher than 4 in this field. Receivers MUST treat values higher than 4 as if the value received were 4 (Highest). The default priority value when the PRIORITY attribute is missing is 2 (Normal). +-------+----------+ | Value | Priority | +-------+----------+ | 0 | Lowest | | 1 | Low | | 2 | Normal | | 3 | High | | 4 | Highest | +-------+----------+ Table 3: Priority values Reserved: At this point, the 13 bits in the reserved field MUST be Camarillo, et al. Expires August 19, 2014 [Page 22] Internet-Draft BFCP February 2014 set to zero by the sender of the message and MUST be ignored by the receiver. 5.2.5. REQUEST-STATUS The following is the format of the REQUEST-STATUS attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: REQUEST-STATUS format Request Status: This 8-bit field contains the status of the request, as described in the following table. +-------+-----------+ | Value | Status | +-------+-----------+ | 1 | Pending | | 2 | Accepted | | 3 | Granted | | 4 | Denied | | 5 | Cancelled | | 6 | Released | | 7 | Revoked | +-------+-----------+ Table 4: Request Status values Queue Position: This 8-bit field contains, when applicable, the position of the floor request in the floor request queue at the server. If the Request Status value is different from Accepted, if the floor control server does not implement a floor request queue, or if the floor control server does not want to provide the client with this information, all the bits of this field SHOULD be set to zero. A floor request is in Pending state if the floor control server needs to contact a floor chair in order to accept the floor request, but has not done it yet. Once the floor control chair accepts the floor request, the floor request is moved to the Accepted state. Camarillo, et al. Expires August 19, 2014 [Page 23] Internet-Draft BFCP February 2014 5.2.6. ERROR-CODE The following is the format of the ERROR-CODE attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 0|M| Length | Error Code | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Error Specific Details | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: ERROR-CODE format Error Code: This 8-bit field contains an error code from the following table. If an error code is not recognized by the receiver, then the receiver MUST assume that an error exists, and therefore that the original message that triggered the Error message to be sent is processed, but the nature of the error is unclear. +-------+-----------------------------------------------------------+ | Value | Meaning | +-------+-----------------------------------------------------------+ | 1 | Conference does not Exist | | 2 | User does not Exist | | 3 | Unknown Primitive | | 4 | Unknown Mandatory Attribute | | 5 | Unauthorized Operation | | 6 | Invalid Floor ID | | 7 | Floor Request ID Does Not Exist | | 8 | You have Already Reached the Maximum Number of Ongoing | | | Floor Requests for this Floor | | 9 | Use TLS | | 10 | Unable to Parse Message | | 11 | Use DTLS | | 12 | Unsupported Version | | 13 | Incorrect Message Length | | 14 | Generic Error | +-------+-----------------------------------------------------------+ Table 5: Error Code meaning Camarillo, et al. Expires August 19, 2014 [Page 24] Internet-Draft BFCP February 2014 Note: The Generic Error error code is intended to be used by a BFCP entity when an error occurs and the other specific error codes do not apply. Error Specific Details: Present only for certain Error Codes. In this document, only for Error Code 4 (Unknown Mandatory Attribute). See Section 5.2.6.1 for its definition. Padding: One, two, or three octets of padding added so that the contents of the ERROR-CODE attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. 5.2.6.1. Error-Specific Details for Error Code 4 The following is the format of the Error-Specific Details field for Error Code 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Unknown Type|R| Unknown Type|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unknown Type|R| Unknown Type|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Unknown attributes format Unknown Type: These 7-bit fields contain the Types of the attributes (which were present in the message that triggered the Error message) that were unknown to the receiver. R: At this point, this bit is reserved. It MUST be set to zero by the sender of the message and MUST be ignored by the receiver. 5.2.7. ERROR-INFO The following is the format of the ERROR-INFO attribute. Camarillo, et al. Expires August 19, 2014 [Page 25] Internet-Draft BFCP February 2014 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: ERROR-INFO format Text: This field contains UTF-8 [8] encoded text. In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular ERROR-INFO attribute, it MAY use this language to generate the Text field. Padding: One, two, or three octets of padding added so that the contents of the ERROR-INFO attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.8. PARTICIPANT-PROVIDED-INFO The following is the format of the PARTICIPANT-PROVIDED-INFO attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 0|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: PARTICIPANT-PROVIDED-INFO format Text: This field contains UTF-8 [8] encoded text. Padding: One, two, or three octets of padding added so that the Camarillo, et al. Expires August 19, 2014 [Page 26] Internet-Draft BFCP February 2014 contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.9. STATUS-INFO The following is the format of the STATUS-INFO attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: STATUS-INFO format Text: This field contains UTF-8 [8] encoded text. In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular STATUS-INFO attribute, it MAY use this language to generate the Text field. Padding: One, two, or three octets of padding added so that the contents of the STATUS-INFO attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.10. SUPPORTED-ATTRIBUTES The following is the format of the SUPPORTED-ATTRIBUTES attribute. Camarillo, et al. Expires August 19, 2014 [Page 27] Internet-Draft BFCP February 2014 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: SUPPORTED-ATTRIBUTES format Supp. Attr.: These fields contain the Types of the attributes that are supported by the floor control server in the following format: R: Reserved: This bit MUST be set to zero upon transmission and MUST be ignored upon reception. Padding: One, two, or three octets of padding added so that the contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. 5.2.11. SUPPORTED-PRIMITIVES The following is the format of the SUPPORTED-PRIMITIVES attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 1 1|M| Length | Primitive | Primitive | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primitive | Primitive | Primitive | Primitive | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: SUPPORTED-PRIMITIVES format Camarillo, et al. Expires August 19, 2014 [Page 28] Internet-Draft BFCP February 2014 Primitive: These fields contain the types of the BFCP messages that are supported by the floor control server. See Table 1 for the list of BFCP primitives. Padding: One, two, or three octets of padding added so that the contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. 5.2.12. USER-DISPLAY-NAME The following is the format of the USER-DISPLAY-NAME attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 0 0|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: USER-DISPLAY-NAME format Text: This field contains the UTF-8 encoded name of the user. Padding: One, two, or three octets of padding added so that the contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.13. USER-URI The following is the format of the USER-URI attribute. Camarillo, et al. Expires August 19, 2014 [Page 29] Internet-Draft BFCP February 2014 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 0 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: USER-URI format Text: This field contains the UTF-8 encoded user's contact URI, that is, the URI used by the user to set up the resources (e.g., media streams) that are controlled by BFCP. For example, in the context of a conference set up by SIP, the USER-URI attribute would carry the SIP URI of the user. Messages containing a user's URI in a USER-URI attribute also contain the user's User ID. This way, a client receiving such a message can correlate the user's URI (e.g., the SIP URI the user used to join a conference) with the user's User ID. Padding: One, two, or three octets of padding added so that the contents of the USER-URI attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.14. BENEFICIARY-INFORMATION The BENEFICIARY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as BENEFICIARY- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the BENEFICIARY-INFORMATION-HEADER: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 1 0|M| Length | Beneficiary ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21: BENEFICIARY-INFORMATION-HEADER format Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference. Camarillo, et al. Expires August 19, 2014 [Page 30] Internet-Draft BFCP February 2014 The following is the ABNF (Augmented Backus-Naur Form) [4] of the BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) [USER-DISPLAY-NAME] [USER-URI] *(EXTENSION-ATTRIBUTE) Figure 22: BENEFICIARY-INFORMATION format 5.2.15. FLOOR-REQUEST-INFORMATION The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 1 1|M| Length | Floor Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server. The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) [OVERALL-REQUEST-STATUS] 1*(FLOOR-REQUEST-STATUS) [BENEFICIARY-INFORMATION] [REQUESTED-BY-INFORMATION] [PRIORITY] [PARTICIPANT-PROVIDED-INFO] *(EXTENSION-ATTRIBUTE) Figure 24: FLOOR-REQUEST-INFORMATION format Camarillo, et al. Expires August 19, 2014 [Page 31] Internet-Draft BFCP February 2014 5.2.16. REQUESTED-BY-INFORMATION The REQUESTED-BY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as REQUESTED-BY- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the REQUESTED-BY-INFORMATION-HEADER: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 0 0 0|M| Length | Requested-by ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: REQUESTED-BY-INFORMATION-HEADER format Requested-by ID: This field contains a 16-bit value that uniquely identifies a user within a conference. The following is the ABNF of the REQUESTED-BY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER) [USER-DISPLAY-NAME] [USER-URI] *(EXTENSION-ATTRIBUTE) Figure 26: REQUESTED-BY-INFORMATION format 5.2.17. FLOOR-REQUEST-STATUS The FLOOR-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST-STATUS- HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-STATUS-HEADER: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 0 0 1|M| Length | Floor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27: FLOOR-REQUEST-STATUS-HEADER format Floor ID: this field contains a 16-bit value that uniquely identifies Camarillo, et al. Expires August 19, 2014 [Page 32] Internet-Draft BFCP February 2014 a floor within a conference. The following is the ABNF of the FLOOR-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) [REQUEST-STATUS] [STATUS-INFO] *(EXTENSION-ATTRIBUTE) Figure 28: FLOOR-REQUEST-STATUS format 5.2.18. OVERALL-REQUEST-STATUS The OVERALL-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as OVERALL-REQUEST-STATUS- HEADER, followed by a sequence of attributes. The following is the format of the OVERALL-REQUEST-STATUS-HEADER: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 0 1 0|M| Length | Floor Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 29: OVERALL-REQUEST-STATUS-HEADER format Floor Request ID: this field contains a 16-bit value that identifies a floor request at the floor control server. The following is the ABNF of the OVERALL-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER) [REQUEST-STATUS] [STATUS-INFO] *(EXTENSION-ATTRIBUTE) Figure 30: OVERALL-REQUEST-STATUS format Camarillo, et al. Expires August 19, 2014 [Page 33] Internet-Draft BFCP February 2014 5.3. Message Format This section contains the normative ABNF (Augmented Backus-Naur Form) [4] of the BFCP messages. Extension attributes that may be defined in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. 5.3.1. FloorRequest Floor participants request a floor by sending a FloorRequest message to the floor control server. The following is the format of the FloorRequest message: FloorRequest = (COMMON-HEADER) 1*(FLOOR-ID) [BENEFICIARY-ID] [PARTICIPANT-PROVIDED-INFO] [PRIORITY] *(EXTENSION-ATTRIBUTE) Figure 31: FloorRequest format 5.3.2. FloorRelease Floor participants release a floor by sending a FloorRelease message to the floor control server. Floor participants also use the FloorRelease message to cancel pending floor requests. The following is the format of the FloorRelease message: FloorRelease = (COMMON-HEADER) (FLOOR-REQUEST-ID) *(EXTENSION-ATTRIBUTE) Figure 32: FloorRelease format 5.3.3. FloorRequestQuery Floor participants and floor chairs request information about a floor request by sending a FloorRequestQuery message to the floor control server. The following is the format of the FloorRequestQuery message: FloorRequestQuery = (COMMON-HEADER) (FLOOR-REQUEST-ID) *(EXTENSION-ATTRIBUTE) Camarillo, et al. Expires August 19, 2014 [Page 34] Internet-Draft BFCP February 2014 Figure 33: FloorRequestQuery format 5.3.4. FloorRequestStatus The floor control server informs floor participants and floor chairs about the status of their floor requests by sending them FloorRequestStatus messages. The following is the format of the FloorRequestStatus message: FloorRequestStatus = (COMMON-HEADER) (FLOOR-REQUEST-INFORMATION) *(EXTENSION-ATTRIBUTE) Figure 34: FloorRequestStatus format 5.3.5. UserQuery Floor participants and floor chairs request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server. The following is the format of the UserQuery message: UserQuery = (COMMON-HEADER) [BENEFICIARY-ID] *(EXTENSION-ATTRIBUTE) Figure 35: UserQuery format 5.3.6. UserStatus The floor control server provides information about participants and their related floor requests to floor participants and floor chairs by sending them UserStatus messages. The following is the format of the UserStatus message: UserStatus = (COMMON-HEADER) [BENEFICIARY-INFORMATION] *(FLOOR-REQUEST-INFORMATION) *(EXTENSION-ATTRIBUTE) Figure 36: UserStatus format Camarillo, et al. Expires August 19, 2014 [Page 35] Internet-Draft BFCP February 2014 5.3.7. FloorQuery Floor participants and floor chairs request information about a floor or floors by sending a FloorQuery message to the floor control server. The following is the format of the FloorRequest message: FloorQuery = (COMMON-HEADER) *(FLOOR-ID) *(EXTENSION-ATTRIBUTE) Figure 37: FloorQuery format 5.3.8. FloorStatus The floor control server informs floor participants and floor chairs about the status (e.g., the current holder) of a floor by sending them FloorStatus messages. The following is the format of the FloorStatus message: FloorStatus = (COMMON-HEADER) [FLOOR-ID] *(FLOOR-REQUEST-INFORMATION) *(EXTENSION-ATTRIBUTE) Figure 38: FloorStatus format 5.3.9. ChairAction Floor chairs send instructions to floor control servers by sending them ChairAction messages. The following is the format of the ChairAction message: ChairAction = (COMMON-HEADER) (FLOOR-REQUEST-INFORMATION) *(EXTENSION-ATTRIBUTE) Figure 39: ChairAction format 5.3.10. ChairActionAck Floor control servers confirm that they have accepted a ChairAction message by sending a ChairActionAck message. The following is the format of the ChairActionAck message: Camarillo, et al. Expires August 19, 2014 [Page 36] Internet-Draft BFCP February 2014 ChairActionAck = (COMMON-HEADER) *(EXTENSION-ATTRIBUTE) Figure 40: ChairActionAck format 5.3.11. Hello Floor participants and floor chairs check the liveliness of floor control servers by sending a Hello message. The following is the format of the Hello message: Hello = (COMMON-HEADER) *(EXTENSION-ATTRIBUTE) Figure 41: Hello format 5.3.12. HelloAck Floor control servers confirm that they are alive on reception of a Hello message by sending a HelloAck message. The following is the format of the HelloAck message: HelloAck = (COMMON-HEADER) (SUPPORTED-PRIMITIVES) (SUPPORTED-ATTRIBUTES) *(EXTENSION-ATTRIBUTE) Figure 42: HelloAck format 5.3.13. Error Floor control servers inform floor participants and floor chairs about errors processing requests by sending them Error messages. The following is the format of the Error message: Error = (COMMON-HEADER) (ERROR-CODE) [ERROR-INFO] *(EXTENSION-ATTRIBUTE) Figure 43: Error format Camarillo, et al. Expires August 19, 2014 [Page 37] Internet-Draft BFCP February 2014 5.3.14. FloorRequestStatusAck When communicating over an unreliable transport, floor participants and chairs acknowledge the receipt of a subsequent FloorRequestStatus message from the floor control server (cf. Section 13.1.2) by sending a FloorRequestStatusAck message. The following is the format of the FloorRequestStatusAck message: FloorRequestStatusAck = (COMMON-HEADER) *(EXTENSION-ATTRIBUTE) Figure 44: FloorRequestStatusAck format 5.3.15. FloorStatusAck When communicating over an unreliable transport, floor participants and chairs acknowledge the receipt of a subsequent FloorStatus message from the floor control server (cf. Section 13.5.2) by sending a FloorStatusAck message. The following is the format of the FloorStatusAck message: FloorStatusAck = (COMMON-HEADER) *(EXTENSION-ATTRIBUTE) Figure 45: FloorStatusAck format 5.3.16. Goodbye BFCP entities communicating over an unreliable transport that wish to dissociate themselves from their remote participant do so through the transmission of a Goodbye. The following is the format of the Goodbye message: Goodbye = (COMMON-HEADER) *(EXTENSION-ATTRIBUTE) Figure 46: Goodbye format 5.3.17. GoodbyeAck BFCP entities communicating over an unreliable transport should acknowledge the receipt of a Goodbye message from a peer. The following is the format of the GoodbyeAck message: Camarillo, et al. Expires August 19, 2014 [Page 38] Internet-Draft BFCP February 2014 GoodbyeAck = (COMMON-HEADER) *(EXTENSION-ATTRIBUTE) Figure 47: GoodbyeAck format 6. Transport The transport over which BFCP entities exchange messages depends on how clients obtain information to contact the floor control server (e.g., using an SDP offer/answer exchange [9] or the procedure specified in [3]). Two transports are supported: TCP, appropriate where connectivity is not impeded by network elements such as NAT devices or media relays; and UDP for those deployments where TCP may not be applicable or appropriate. Informational note: In practice products are configured to try one transport initially and use the other one as a fallback. Whether TCP or UDP is chosen as underlying transport depends on type of product and the nature of the environment it is deployed. Here Appendix B are important to consider. 6.1. Reliable Transport BFCP entities may elect to exchange BFCP messages using TCP connections. TCP provides an in-order reliable delivery of a stream of bytes. Consequently, message framing needs to be implemented in the application layer. BFCP implements application-layer framing using TLV-encoded attributes. A client MUST NOT use more than one TCP connection to communicate with a given floor control server within a conference. Nevertheless, if the same physical box handles different clients (e.g., a floor chair and a floor participant), which are identified by different User IDs, a separate connection per client is allowed. If a BFCP entity (a client or a floor control server) receives data that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished. Similarly, if a TCP connection cannot deliver a BFCP message and times out or receives an ICMP port unreachable message mid-connection, the TCP connection SHOULD be reestablished. The way connection reestablishment is handled depends on how the client obtains information to contact the floor control server. Once the TCP connection is reestablished, the client MAY resend those messages for which it did not get a response from the floor control server. Camarillo, et al. Expires August 19, 2014 [Page 39] Internet-Draft BFCP February 2014 If a floor control server detects that the TCP connection towards one of the floor participants is lost, it is up to the local policy of the floor control server what to do with the pending floor requests of the floor participant. In any case, it is RECOMMENDED that the floor control server keep the floor requests (i.e., that it does not cancel them) while the TCP connection is reestablished. If a client wishes to end its BFCP connection with a floor control server, the client closes (i.e., a graceful close) the TCP connection towards the floor control server. If a floor control server wishes to end its BFCP connection with a client (e.g., the Focus of the conference informs the floor control server that the client has been kicked out from the conference), the floor control server closes (i.e., a graceful close) the TCP connection towards the client. 6.2. Unreliable Transport BFCP entities may elect to exchange BFCP messages using UDP datagrams. UDP is an unreliable transport where neither delivery nor ordering is assured. Each BFCP UDP datagram MUST contain exactly one BFCP message or message fragment. To keep large BFCP messages from being fragmented at the IP layer, the fragmentation of BFCP messages that exceed the path MTU size is performed at the BFCP level. Considerations related to fragmentation are covered in Section 6.2.3. The message format for BFCP messages is the same regardless of whether the messages are sent in UDP datagrams or over a TCP stream. Clients MUST announce their presence to the floor control server by sending a Hello message. The floor control server responds to the Hello message with a HelloAck message. The client considers the floor control service as present and available only upon receiving the HelloAck message. Situations where the floor control service is considered to have become unavailable due to ICMP messages is described in Section 6.2.2 and the behavior when timers fire is described in Section 8.3. As described in Section 8, each request sent by a floor participant or chair forms a client transaction that expects an acknowledgement message back from the floor control server within a retransmission window. Concordantly, messages sent by the floor control server that initiate new transactions (e.g., FloorStatus announcements as part of a FloorQuery subscription) require acknowledgement messages from the floor participant and chair entities to which they were sent. If a Floor Control Server receives data that cannot be parsed, the receiving server MUST send an Error message with parameter value 10 (Unable to parse message) indicating receipt of a malformed message, given that it is possible to parse the received message to such an Camarillo, et al. Expires August 19, 2014 [Page 40] Internet-Draft BFCP February 2014 extent that an Error message may be built. Entities MUST have at most one outstanding request transaction per peer at any one time. Implicit subscriptions occur for a client- initiated request transaction whose acknowledgement is implied by the first server-initiated response for that transaction, followed by zero of more subsequent server-initiated messages corresponding to the same transaction. An example is a FloorRequest message for which there are potentially multiple responses from the floor control server as it processes intermediate states until a terminal state (e.g., Granted or Denied) is attained. The subsequent changes in state for the request are new transactions whose Transaction ID is determined by the floor control server and whose receipt by the client participant is acknowledged with a FloorRequestStatusAck message. By restricting entities to having at most one pending transaction open in a BFCP connection, both the out-of-order receipt of messages as well as the possibility for congestion are mitigated. Additional details regarding congestion control are provided in Section 6.2.1. A server-initiated request (e.g., a FloorStatus with an update from the floor control server) received by a participant before the initial FloorRequestStatus message that closes the client-initiated transaction that was instigated by the FloorRequest MUST be treated as superseding the information conveyed in any such late arriving response. As the floor control server cannot send a second update to the implicit floor status subscription until the first is acknowledged, ordinality is maintained. If a client wishes to end its BFCP connection with a floor control server, it is REQUIRED that the client send a Goodbye message to dissociate itself from any allocated resources. If a floor control server wishes to end its BFCP connection with a client (e.g., the Focus of the conference informs the floor control server that the client has been kicked out from the conference), it is REQUIRED that the floor control server send a Goodbye message towards the client. RFC 5018 [3] specifies how to establish a TCP connection to a floor control server outside the context of an offer/answer exchange. When using UDP the same set of data is needed for a BFCP connection as listed in [3], Section 3, i.e. transport address of the server, the conference identifier, and the user identifier. The procedures and considerations for resolving a host name into an IP address also applies to BFCP over an unreliable transport. In [3], Section 4 applies, but when using BFCP over an unreliable transport the floor control server that receives a BFCP message over UDP (no DTLS) SHOULD request the use of DTLS by generating an Error message with an Error code with a value of 11 (Use DTLS). A floor control server that is Camarillo, et al. Expires August 19, 2014 [Page 41] Internet-Draft BFCP February 2014 configured to require DTLS MUST request the use of DTLS this way. The recommendations for authentication in [3], Section 5 and the security considerations in [3], Section 6 also apply when an unreliable transport is used, both for certificate-based server authentication and for client authentication based on a pre-shared secret. 6.2.1. Congestion Control BFCP may be characterized to generate "low data-volume" traffic, per the classification in [25]. Nevertheless is it necessary to ensure suitable and necessary congestion control mechanisms are used for BFCP over UDP. As described in Section 6.2, within the same BFCP connection, every entity - client or server - is only allowed to send one request at a time, and await the acknowledging response. This way at most one datagram is sent per RTT given the message is not lost during transmission. In case the message is lost, the request retransmission timer T1 specified in Section 8.3.1 will fire and the message is retransmitted up to three times, in addition to the original transmission of the message. The default initial interval MUST be set to 500ms and the interval MUST be doubled after each retransmission attempt. This is identical to the specification of the timer A and its initial value T1 in SIP as described in Section 17.1.1.2 of [16]. 6.2.2. ICMP Error Handling If a BFCP entity receives an ICMP port unreachable message mid- connection, the entity MUST treat the BFCP connection as closed (e.g., an implicit Goodbye message from the peer). The entity MAY attempt to re-establish the BFCP connection afresh. The new BFCP connection will appear as originating from a wholly new floor participant, chair or floor control server with all state previously held about that participant lost. Informational note: The recommendation to treat the connection as closed in this case, stems from the fact that the peer entities cannot rely on IP and port tuple to uniquely identify the participant, nor would extending Hello to include an attribute that advertised what identity the entity previously was assigned (i.e., a User ID) be acceptable due to session hijacking. In deployments where NAT appliances or other such devices are present and affecting port reachability for each entity, one possibility is to utilize the peer connectivity checks, relay use and NAT pinhole maintenance mechanisms defined in ICE [15]. Camarillo, et al. Expires August 19, 2014 [Page 42] Internet-Draft BFCP February 2014 6.2.3. Fragmentation Handling When using UDP, a single BFCP message could be fragmented at the IP layer if its overall size exceeds the path MTU of the network. To avoid this happening at the IP layer, a fragmentation scheme for BFCP is defined below. BFCP is designed for achieving small message size, due to the binary encoding as described in Section 1. The fragmentation scheme is therefore deliberately kept simple and straightforward, since the probability of fragmentation of BFCP messages being required is small. By design, the fragmentation scheme does not acknowledge individual BFCP message fragments. The whole BFCP message is acknowledged if received completely. BFCP entities should consider the MTU size available between the sender and the receiver and MAY run MTU discovery, such as [20][21][22], for this purpose. When transmitting a BFCP message with size greater than the path MTU, the sender MUST fragment the message into a series of N contiguous data ranges. The value for N is defined as ceil(message size / MTU size), where ceil is the integer ceiling function. The sender then creates N BFCP fragment messages (one for each data range) with the same Transaction ID. The size of each of these N messages MUST be smaller than the path MTU. The F flag in the COMMON-HEADER is set to indicate fragmentation of the BFCP message. For each of these fragments the Fragment Offset and Fragment Length fields are included in the COMMON-HEADER. The Fragment Offset field denotes the number of bytes contained in the previous fragments. The Fragment Length contains the length of the fragment itself. Note that the Payload Length field contains the length of the entire, unfragmented message. When a BFCP implementation receives a BFCP message fragment, it MUST buffer the fragment until either it has received the entire BFCP message, or until the Response Retransmission Timer expires. The state machine should handle the BFCP message only after all the fragments for the message have been received. If a fragment of a BFCP message is lost, the sender will not receive an acknowledgement for the message. Therefore the sender will retransmit the message with same transaction ID as specified in Section 8.3. If the acknowledgement message sent by the receiver is lost, then the entire message will be resent by the sender. The receiver MUST then retransmit the acknowledgement. The receiver MAY discard an incomplete buffer utilizing the Response Retransmission Camarillo, et al. Expires August 19, 2014 [Page 43] Internet-Draft BFCP February 2014 Timer, starting the timer after the receipt of the first fragment. A Denial of Service (DoS) attack utilizing the fragmentation scheme described above is mitigated by the fact that the Response Retransmission Timer is started after receipt of the first BFCP message fragment. In addition, the Payload Length field can be compared with the Fragment Offset and Fragment Length fields to verify the message fragments as they arrive. To make DoS attacks with spoofed IP addresses difficult, BFCP entities SHOULD use the cookie exchange mechanism in DTLS [7]. When deciding message fragment size based on path MTU, the BFCP fragmentation handling should take into account how the DTLS record framing expands the datagram size as described in Section 4.1.1.1 of [7]. 6.2.4. NAT Traversal One of the key benefits when using UDP for BFCP communication is the ability to leverage the existing NAT traversal infrastructure and strategies deployed to facilitate transport of the media associated with the video conferencing sessions. Depending on the given deployment, this infrastructure typically includes some subset of ICE [15]. In order to facilitate the initial establishment of NAT bindings, and to maintain those bindings once established, BFCP entities using an unreliable transport are RECOMMENDED to use STUN [11] Binding Indication for keep-alives, as described for ICE [15]. [23], Section 6.7 provides useful recommendations for middlebox interaction when DTLS is used. Informational note: Since the version number is set to 2 when BFCP is used over an unreliable transport, cf. the Ver field in Section 5.1, it is straight forward to distinguish between STUN and BFCP packets even without checking the STUN magic cookie [11]. In order to facilitate traversal of BFCP packets through NATs, BFCP entities using an unreliable transport are RECOMMENDED to use symmetric ports for sending and receiving BFCP packets, as recommended for RTP/RTCP [10]. 7. Lower-Layer Security BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs) Camarillo, et al. Expires August 19, 2014 [Page 44] Internet-Draft BFCP February 2014 MUST support TLS for transport over TCP [6] and MUST support DTLS [7] for transport over UDP. Any BFCP entity MAY support other security mechanisms. BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. Which party, the client or the floor control server, acts as the TLS/ DTLS server depends on how the underlying TLS/DTLS connection is established. For a TCP/TLS connection established using an SDP offer/answer exchange [9], the answerer (which may be the client or the floor control server) always acts as the TLS server. If the TCP connection is lost, the active endpoint, i.e., the current TLS client, is responsible for re-establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles. For a UDP/DTLS connection established using the an SDP offer/answer exchange, either party can be the DTLS server depending on the setup attributes exchanged; examples can be found in [23]. 8. Protocol Transactions In BFCP, there are two types of transactions: client-initiated transactions and server-initiated transactions. Client-initiated transactions consist of a request from a client to a floor control server and a response from the floor control server to the client. The request carries a Transaction ID in its common header, which the floor control server copies into the response. Clients use Transaction ID values to match responses with previously issued requests. Server-initiated transactions have different requirements and behavior depending on underlying transport: When using a reliable transport, server-initiated transactions consist of a single message from a floor control server to a client (notifications). Since they do not trigger any response, their Transaction ID is set to 0. When using an unreliable transport, server-initiated transactions consist of a request from a floor control server to a client and a response from the client to the floor control server. The Transaction ID MUST be non-zero and unique in the context of outstanding transactions over an unreliable transport. The request carries a Transaction ID in its common header, which the Camarillo, et al. Expires August 19, 2014 [Page 45] Internet-Draft BFCP February 2014 client copies into the response. Floor control servers use Transaction ID values to match responses with previously issued requests. When using BFCP over an unreliable transport, it is important that the initiator of a transaction choose a Transaction ID value that lets the receiver distinguish the reception of the next message in a sequence of BFCP messages from a retransmission of a previous message. Therefore, BFCP entities using an unreliable transport MUST use monotonically increasing Transaction ID values (except for wrap- around). When using BFCP over an unreliable transport, all requests will use retransmission timer T1 (see Section 8.3) until the transaction is completed. 8.1. Client Behavior A client starting a client-initiated transaction MUST set the Conference ID in the common header of the message to the Conference ID for the conference that the client obtained previously. The client MUST set the Transaction ID value in the common header to a number that is different from 0 and that MUST NOT be reused in another message from the client until a response from the server is received for the transaction. The client uses the Transaction ID value to match this message with the response from the floor control server. 8.2. Server Behavior A floor control server sending a response within a client-initiated transaction MUST copy the Conference ID, the Transaction ID, and the User ID from the request received from the client into the response. Server-initiated transactions MUST contain a Transaction ID equal to 0 when BFCP is used over a reliable transport. Over an unreliable transport, the Transaction ID shall have the same properties as for client-initiated transactions: the server MUST set the Transaction ID value in the common header to a number that is different from 0 and that MUST NOT be reused, i.e. monotonically increasing valuse as defined in Section 8. The server uses the Transaction ID value to match this message with the response from the floor participant or floor chair. Camarillo, et al. Expires August 19, 2014 [Page 46] Internet-Draft BFCP February 2014 8.3. Timers When BFCP entities are communicating over an unreliable transport, two retransmission timers are employed to help mitigate against loss of datagrams. Retransmission and response caching are not required when BFCP entities communicate over a reliable transport. 8.3.1. Request Retransmission Timer, T1 T1 is a timer that schedules retransmission of a request until an appropriate response is received or until the maximum number of retransmissions have occurred. The timer doubles on each re- transmit, failing after three unacknowledged retransmission attempts. If a valid response is not received for a client- or server-initiated transaction, the implementation MUST consider the BFCP connection as failed. Implementations SHOULD follow the reestablishment procedure described in section 6 (e.g., initiate a new offer/answer [12] exchange). 8.3.2. Response Retransmission Timer, T2 T2 is a timer that, when fires, signals that the BFCP entity can release knowledge of the transaction against which it is running. It is started upon the first transmission of the response to a request and is the only mechanism by which that response is released by the BFCP entity. Any subsequent retransmissions of the same request can be responded to by replaying the cached response, whilst that value is retained until the timer has fired. Refer to Section 6.2.3 for the role this timer has in the fragmentation handling scheme. 8.3.3. Timer Values The table below defines the different timers required when BFCP entities communicate over an unreliable transport. +-------+--------------------------------------+---------+ | Timer | Description | Value/s | +-------+--------------------------------------+---------+ | T1 | Initial request retransmission timer | 0.5s | | T2 | Response retransmission timer | 10s | +-------+--------------------------------------+---------+ Table 6: Timers The default value for T1 is 500 ms, this is an estimate of the RTT for completing the transaction. T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance that the RTT is larger. Camarillo, et al. Expires August 19, 2014 [Page 47] Internet-Draft BFCP February 2014 Regardless of the value of T1, the exponential backoffs on retransmissions described in Section 8.3.1 MUST be used. T2 SHALL be set such that it encompasses all legal retransmissions per T1 plus a factor to accommodate network latency between BFCP entities. The default value is based on the sum of the three retransmissions related to T1 using its default value (7.5s) and an extra 2.5s is added to take into account potential messages in transit due to latency. 9. Authentication and Authorization BFCP clients SHOULD authenticate the floor control server before sending any BFCP message to it or accepting any BFCP message from it. Similarly, floor control servers SHOULD authenticate a client before accepting any BFCP message from it or sending any BFCP message to it. BFCP supports TLS/DTLS mutual authentication between clients and floor control servers, as specified in Section 9.1. This is the RECOMMENDED authentication mechanism in BFCP. Note that future extensions may define additional authentication mechanisms. In addition to authenticating BFCP messages, floor control servers need to authorize them. On receiving an authenticated BFCP message, the floor control server checks whether the client sending the message is authorized. If the client is not authorized to perform the operation being requested, the floor control server generates an Error message, as described in Section 13.8, with an Error code with a value of 5 (Unauthorized Operation). Messages from a client that cannot be authorized MUST NOT be processed further. 9.1. TLS/DTLS Based Mutual Authentication BFCP supports TLS/DTLS based mutual authentication between clients and floor control servers. If TLS/DTLS is used, an initial integrity-protected channel is REQUIRED between the client and the floor control server that can be used to exchange their self-signed certificates or, more commonly, the fingerprints of these certificates. These certificates are used at TLS/DTLS establishment time. Camarillo, et al. Expires August 19, 2014 [Page 48] Internet-Draft BFCP February 2014 The implementation of such an integrity-protected channel using SIP and the SDP offer/answer model is described in [9]. BFCP messages received over an authenticated TLS/DTLS connection are considered authenticated. A floor control server that receives a BFCP message over TCP/UDP (no TLS/DTLS) MAY request the use of TLS/ DTLS by generating an Error message, as described in Section 13.8, with an Error code with a value of 9 (Use TLS) or a value of 11 (Use DTLS) respectively. Clients configured to require the use of TLS/ DTLS MUST ignore unauthenticated messages. Note that future extensions may define additional authentication mechanisms that may not require an initial integrity-protected channel (e.g., authentication based on certificates signed by a certificate authority). As described in Section 9, floor control servers need to perform authorization before processing any message. In particular, the floor control server MUST check that messages arriving over a given authenticated TLS/DTLS connection use an authorized User ID (i.e., a User ID that the user that established the authenticated TLS/DTLS connection is allowed to use). 10. Floor Participant Operations This section specifies how floor participants can perform different operations, such as requesting a floor, using the protocol elements described in earlier sections. Section 11 specifies operations that are specific to floor chairs, such as instructing the floor control server to grant or revoke a floor, and Section 12 specifies operations that can be performed by any client (i.e., both floor participants and floor chairs). 10.1. Requesting a Floor A floor participant that wishes to request one or more floors does so by sending a FloorRequest message to the floor control server. 10.1.1. Sending a FloorRequest Message The ABNF in Section 5.3.1 describes the attributes that a FloorRequest message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. Camarillo, et al. Expires August 19, 2014 [Page 49] Internet-Draft BFCP February 2014 The floor participant sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. If the sender of the FloorRequest message (identified by the User ID) is not the participant that would eventually get the floor (i.e., a third-party floor request), the sender SHOULD add a BENEFICIARY-ID attribute to the message identifying the beneficiary of the floor. Note that the name space for both the User ID and the Beneficiary ID is the same. That is, a given participant is identified by a single 16-bit value that can be used in the User ID in the common header and in several attributes: BENEFICIARY-ID, BENEFICIARY- INFORMATION, and REQUESTED-BY-INFORMATION. The floor participant MUST insert at least one FLOOR-ID attribute in the FloorRequest message. If the client inserts more than one FLOOR-ID attribute, the floor control server will treat all the floor requests as an atomic package. That is, the floor control server will either grant or deny all the floors in the FloorRequest message. The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute to state the reason why the floor or floors are being requested. The Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for human consumption. The floor participant may request that the server handle the floor request with a certain priority using a PRIORITY attribute. 10.1.2. Receiving a Response A message from the floor control server is considered a response to the FloorRequest message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication. The successful processing of a FloorRequest message at the floor control server involves generating one or several FloorRequestStatus messages. The floor participant obtains a Floor Request ID in the Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in the first FloorRequestStatus message from the floor control server. Subsequent FloorRequestStatus messages from the floor control server regarding the same floor request will carry the same Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute as the initial FloorRequestStatus message. This way, the floor participant can associate subsequent incoming FloorRequestStatus messages with the ongoing floor request. Camarillo, et al. Expires August 19, 2014 [Page 50] Internet-Draft BFCP February 2014 The floor participant obtains information about the status of the floor request in the FLOOR-REQUEST-INFORMATION attribute of each of the FloorRequestStatus messages received from the floor control server. This attribute is a grouped attribute, and as such it includes a number of attributes that provide information about the floor request. The OVERALL-REQUEST-STATUS attribute provides information about the overall status of the floor request. If the Request Status value is Granted, all the floors that were requested in the FloorRequest message have been granted. If the Request Status value is Denied, all the floors that were requested in the FloorRequest message have been denied. A floor request is considered to be ongoing while it is in the Pending, Accepted, or Granted states. If the floor request value is unknown, then the response is still processed. However, no meaningful value can be reported to the user. The STATUS-INFO attribute, if present, provides extra information that the floor participant can display to the user. The FLOOR-REQUEST-STATUS attributes provide information about the status of the floor request as it relates to a particular floor. The STATUS-INFO attribute, if present, provides extra information that the floor participant can display to the user. The BENEFICIARY-INFORMATION attribute identifies the beneficiary of the floor request in third-party floor requests. The REQUESTED-BY- INFORMATION attribute need not be present in FloorRequestStatus messages received by the floor participant that requested the floor, as this floor participant is already identified by the User ID in the common header. The PRIORITY attribute, when present, contains the priority that was requested by the generator of the FloorRequest message. If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message. 10.1.3. Reception of a Subsequent FloorRequestStatus Message When communicating over an unreliable transport and upon receiving a FloorRequestStatus message from a floor control server, the participant MUST respond with a FloorRequestStatusAck message within the transaction failure window to complete the transaction. Camarillo, et al. Expires August 19, 2014 [Page 51] Internet-Draft BFCP February 2014 10.2. Cancelling a Floor Request and Releasing a Floor A floor participant that wishes to cancel an ongoing floor request does so by sending a FloorRelease message to the floor control server. The FloorRelease message is also used by floor participants that hold a floor and would like to release it. 10.2.1. Sending a FloorRelease Message The ABNF in Section 5.3.2 describes the attributes that a FloorRelease message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor participant sets the User ID in the common header to the floor participant's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. Note that the FloorRelease message is used to release a floor or floors that were granted and to cancel ongoing floor requests (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 floor participant uses the FLOOR-REQUEST-ID that was received in the response to the FloorRequest message that the FloorRelease message is cancelling. Note that if the floor participant requested several floors as an atomic operation (i.e., in a single FloorRequest message), all the floors are released as an atomic operation as well (i.e., all are released at the same time). 10.2.2. Receiving a Response A message from the floor control server is considered a response to the FloorRelease message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication. If the response is a FloorRequestStatus message, the Request Status value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR- REQUEST-INFORMATION grouped attribute) will be Cancelled or Released. Camarillo, et al. Expires August 19, 2014 [Page 52] Internet-Draft BFCP February 2014 If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message. It is possible that the FloorRelease message crosses on the wire with a FloorRequestStatus message from the server with a Request Status different from Cancelled or Released. In any case, such a FloorRequestStatus message will not be a response to the FloorRelease message, as its Transaction ID will not match that of the FloorRelease. 11. Chair Operations This section specifies how floor chairs can instruct the floor control server to grant or revoke a floor using the protocol elements described in earlier sections. Floor chairs that wish to send instructions to a floor control server do so by sending a ChairAction message. 11.1. Sending a ChairAction Message The ABNF in Section 5.3.9 describes the attributes that a ChairAction message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The floor chair sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor chair sets the User ID in the common header to the floor chair's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. The ChairAction message contains instructions that apply to one or more floors within a particular floor request. The floor or floors are identified by the FLOOR-REQUEST-STATUS attributes and the floor request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which are carried in the ChairAction message. For example, if a floor request consists of two floors that depend on different floor chairs, each floor chair will grant its floor within the floor request. Once both chairs have granted their floor, the floor control server will grant the floor request as a whole. On the other hand, if one of the floor chairs denies its floor, the floor control server will deny the floor request as a whole, regardless of the other floor chair's decision. The floor chair provides the new status of the floor request as it Camarillo, et al. Expires August 19, 2014 [Page 53] Internet-Draft BFCP February 2014 relates to a particular floor using a FLOOR-REQUEST-STATUS attribute. If the new status of the floor request is Accepted, the floor chair MAY use the Queue Position field to provide a queue position for the floor request. If the floor chair does not wish to provide a queue position, all the bits of the Queue Position field MUST be set to zero. The floor chair MUST use the Status Revoked to revoke a floor that was granted (i.e., Granted status) and MUST use the Status Denied to reject floor requests in any other status (e.g., Pending and Accepted). The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the ChairAction message to provide a new overall status for the floor request. If the new overall status of the floor request is Accepted, the floor chair can use the Queue Position field to provide a queue position for the floor request. Note that a particular floor control server can implement a different queue for each floor containing all the floor requests that relate to that particular floor, a general queue for all floor requests, or both. Also note that a floor request can involve several floors and that a ChairAction message can only deal with a subset of these floors (e.g., if a single floor chair is not authorized to manage all the floors). In this case, the floor control server will combine the instructions received from the different floor chairs in FLOOR-REQUEST-STATUS attributes to come up with the overall status of the floor request. Note that, while the action of a floor chair may communicate information in the OVERALL-REQUEST-STATUS attribute, the floor control server may override, modify, or ignore this field's content. The floor chair MAY include STATUS-INFO attributes to state the reason why the floor or floors are being accepted, granted, or revoked. The Text in the STATUS-INFO attribute is intended for human consumption. 11.2. Receiving a Response A message from the floor control server is considered a response to the ChairAction message if the message from the server has the same Conference ID, Transaction ID, and User ID as the ChairAction message, as described in Section 8.1. On receiving such a response, the floor chair follows the rules in Section 9 that relate to floor control server authentication. A ChairActionAck message from the floor control server confirms that the floor control server has accepted the ChairAction message. An Camarillo, et al. Expires August 19, 2014 [Page 54] Internet-Draft BFCP February 2014 Error message indicates that the floor control server could not process the ChairAction message for some reason, which is described in the Error message. 12. General Client Operations This section specifies operations that can be performed by any client. That is, they are not specific to floor participants or floor chairs. They can be performed by both. 12.1. Requesting Information about Floors A client can obtain information about the status of a floor or floors in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. Clients request information about the status of one or several floors by sending a FloorQuery message to the floor control server. 12.1.1. Sending a FloorQuery Message The ABNF in Section 5.3.7 describes the attributes that a FloorQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. The client inserts in the message all the Floor IDs it wants to receive information about. The floor control server will send periodic information about all of these floors. If the client does not want to receive information about a particular floor any longer, it sends a new FloorQuery message removing the FLOOR-ID of this floor. If the client does not want to receive information about any floor any longer, it sends a FloorQuery message with no FLOOR-ID attribute. 12.1.2. Receiving a Response A message from the floor control server is considered a response to the FloorQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such Camarillo, et al. Expires August 19, 2014 [Page 55] Internet-Draft BFCP February 2014 a response, the client follows the rules in Section 9 that relate to floor control server authentication. On reception of the FloorQuery message, the floor control server MUST 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 attribute in its FloorQuery message (i.e., the client does not want to receive information about any floor any longer), the FloorStatus message from the floor control server will not include any FLOOR-ID attribute either. FloorStatus messages that carry information about a floor contain a FLOOR-ID attribute that identifies the floor. After this attribute, FloorStatus messages contain information about existing (one or more) floor requests that relate to that floor. The information about each particular floor request is encoded in a FLOOR-REQUEST-INFORMATION attribute. This grouped attribute carries a Floor Request ID that identifies the floor request, followed by a set of attributes that provide information about the floor request. After the first FloorStatus, the floor control server will continue sending FloorStatus messages, periodically informing the client about changes on the floors the client requested information about. 12.1.3. Reception of a Subsequent FloorStatus Message When communicating over an unreliable transport and upon receiving a FloorStatus message from a floor control server, the participant MUST respond with a FloorStatusAck message within the transaction failure window to complete the transaction. 12.2. Requesting Information about Floor Requests A client can obtain information about the status of one or several floor requests in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. Clients request information about the current status of a floor request by sending a FloorRequestQuery message to the floor control server. Requesting information about a particular floor request is useful in a number of situations. For example, on reception of a FloorRequest message, a floor control server may choose to return FloorRequestStatus messages only when the floor request changes its state (e.g., from Accepted to Granted), but not when the floor Camarillo, et al. Expires August 19, 2014 [Page 56] Internet-Draft BFCP February 2014 request advances in its queue. In this situation, if the user requests it, the floor participant can use a FloorRequestQuery message to poll the floor control server for the status of the floor request. 12.2.1. Sending a FloorRequestQuery Message The ABNF in Section 5.3.3 describes the attributes that a FloorRequestQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. The client MUST insert a FLOOR-REQUEST-ID attribute that identifies the floor request at the floor control server. 12.2.2. Receiving a Response A message from the floor control server is considered a response to the FloorRequestQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequestQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication. If the response is a FloorRequestStatus message, the client obtains information about the status of the FloorRequest the client requested information about in a FLOOR-REQUEST-INFORMATION attribute. If the response is an Error message, the floor control server could not process the FloorRequestQuery message for some reason, which is described in the Error message. 12.3. Requesting Information about a User A client can obtain information about a participant and the floor requests related to this participant in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. Clients request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server. Camarillo, et al. Expires August 19, 2014 [Page 57] Internet-Draft BFCP February 2014 This functionality may be useful for floor chairs or floor participants interested in the display name and the URI of a particular floor participant. In addition, a floor participant may find it useful to request information about itself. For example, a floor participant, after experiencing connectivity problems (e.g., its TCP connection with the floor control server was down for a while and eventually was re-established), may need to request information about all the floor requests associated to itself that still exist. 12.3.1. Sending a UserQuery Message The ABNF in Section 5.3.5 describes the attributes that a UserQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. If the floor participant the client is requesting information about is not the client issuing the UserQuery message (which is identified by the User ID in the common header of the message), the client MUST insert a BENEFICIARY-ID attribute. 12.3.2. Receiving a Response A message from the floor control server is considered a response to the UserQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the UserQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication. If the response is a UserStatus message, the client obtains information about the floor participant in a BENEFICIARY-INFORMATION grouped attribute and about the status of the floor requests associated with the floor participant in FLOOR-REQUEST-INFORMATION attributes. If the response is an Error message, the floor control server could not process the UserQuery message for some reason, which is described in the Error message. Camarillo, et al. Expires August 19, 2014 [Page 58] Internet-Draft BFCP February 2014 12.4. Obtaining the Capabilities of a Floor Control Server A client that wishes to obtain the capabilities of a floor control server does so by sending a Hello message to the floor control server. 12.4.1. Sending a Hello Message The ABNF in Section 5.3.11 describes the attributes that a Hello message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. This User ID will be used by the floor control server to authenticate and authorize the request. 12.4.2. Receiving Responses A message from the floor control server is considered a response to the Hello message by the client if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the Hello message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication. If the response is a HelloAck message, the floor control server could process the Hello message successfully. The SUPPORTED-PRIMITIVES and SUPPORTED-ATTRIBUTES attributes indicate which primitives and attributes, respectively, are supported by the server. If the response is an Error message, the floor control server could not process the Hello message for some reason, which is described in the Error message. 13. Floor Control Server Operations This section specifies how floor control servers can perform different operations, such as granting a floor, using the protocol elements described in earlier sections. On reception of a message from a client, the floor control server MUST check whether the value of the Primitive is supported. If it is not, the floor control server MUST send an Error message, as described in Section 13.8, with Error code 3 (Unknown Primitive). Camarillo, et al. Expires August 19, 2014 [Page 59] Internet-Draft BFCP February 2014 On reception of a message from a client, the floor control server MUST check whether the value of the Conference ID matched an existing conference. If it does not, the floor control server MUST send an Error message, as described in Section 13.8, with Error code 1 (Conference does not Exist). On reception of a message from a client, the floor control server follows the rules in Section 9 that relate to the authentication of the message. On reception of a message from a client, the floor control server MUST check whether it understands all the mandatory ('M' bit set) attributes in the message. If the floor control server does not understand all of them, the floor control server MUST send an Error message, as described in Section 13.8, with Error code 4 (Unknown Mandatory Attribute). The Error message SHOULD list the attributes that were not understood. 13.1. Reception of a FloorRequest Message On reception of a FloorRequest message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequest message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. BFCP allows floor participants to have several ongoing floor requests for the same floor (e.g., the same floor participant can occupy more than one position in a queue at the same time). A floor control server that only supports a certain number of ongoing floor requests per floor participant (e.g., one) can use Error Code 8 (You have Already Reached the Maximum Number of Ongoing Floor Requests for this Floor) to inform the floor participant. When communicating over an unreliable transport and upon receiving a FloorRequest from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction. 13.1.1. Generating the First FloorRequestStatus Message The successful processing of a FloorRequest message by a floor control server involves generating one or several FloorRequestStatus messages, the first of which SHOULD be generated as soon as possible. If the floor control server cannot accept, grant, or deny the floor request right away (e.g., a decision from a chair is needed), it SHOULD use a Request Status value of Pending in the OVERALL-REQUEST- Camarillo, et al. Expires August 19, 2014 [Page 60] Internet-Draft BFCP February 2014 STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message it generates. The policy that a floor control server follows to grant or deny floors is outside the scope of this document. A given floor control server may perform these decisions automatically while another may contact a human acting as a chair every time a decision needs to be made. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequest into the FloorRequestStatus, as described in Section 8.2. Additionally, the floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request. The floor control server MUST assign an identifier that is unique within the conference to this floor request, and MUST insert it in the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. This identifier will be used by the floor participant (or by a chair or chairs) to refer to this specific floor request in the future. The floor control server MUST copy the Floor IDs in the FLOOR-ID attributes of the FloorRequest into the FLOOR-REQUEST-STATUS attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These Floor IDs identify the floors being requested (i.e., the floors associated with this particular floor request). The floor control server SHOULD copy (if present) the contents of the BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY- INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY- INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY copy (if present) the PRIORITY attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute. Note that this attribute carries the priority requested by the participant. The priority that the floor control server assigns to the floor request depends on the priority requested by the participant and the rights the participant has according to the Camarillo, et al. Expires August 19, 2014 [Page 61] Internet-Draft BFCP February 2014 policy of the conference. For example, a participant that is only allowed to use the Normal priority may request Highest priority for a floor request. In that case, the floor control server would ignore the priority requested by the participant. The floor control server MAY copy (if present) the PARTICIPANT- PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST- INFORMATION grouped attribute. 13.1.2. Generation of Subsequent FloorRequestStatus Messages A floor request is considered to be ongoing as long as it is not in the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST- STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message generated by the floor control server did not indicate any of these states, the floor control server will need to send subsequent FloorRequestStatus messages. When the status of the floor request changes, the floor control server SHOULD send new FloorRequestStatus messages with the appropriate Request Status. The floor control server MUST add a FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to the one sent in the first FloorRequestStatus message to any new FloorRequestStatus related to the same floor request. (The Floor Request ID identifies the floor request to which the FloorRequestStatus applies.) When using BFCP over a reliable transport, the floor control server MUST set the Transaction ID of subsequent FloorRequestStatus messages to 0. When using BFCP over an unreliable transport, the Transaction ID MUST be non-zero and unique in the context of outstanding transactions over an unreliable transport as described in Section 8. The rate at which the floor control server sends FloorRequestStatus messages is a matter of local policy. A floor control server may choose to send a new FloorRequestStatus message every time the floor request moves in the floor request queue, while another may choose only to send a new FloorRequestStatus message when the floor request is Granted or Denied. The floor control server may add a STATUS-INFO attribute to any of the FloorRequestStatus messages it generates to provide extra information about its decisions regarding the floor request (e.g., why it was denied). Camarillo, et al. Expires August 19, 2014 [Page 62] Internet-Draft BFCP February 2014 Floor participants and floor chairs may request to be informed about the status of a floor following the procedures in Section 12.1. If the processing of a floor request changes the status of a floor (e.g., the floor request is granted and consequently the floor has a new holder), the floor control server needs to follow the procedures in Section 13.5 to inform the clients that have requested that information. The common header and the rest of the attributes are the same as in the first FloorRequestStatus message. The floor control server can discard the state information about a particular floor request when this reaches a status of Cancelled, Released, or Revoked. When communicating over an unreliable transport and a FloorRequestStatusAck message is not received within the transaction failure window, the floor control server MUST retransmit the FloorRequestStatus message according to Section 6.2. 13.2. Reception of a FloorRequestQuery Message On reception of a FloorRequestQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequestQuery message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. The successful processing of a FloorRequestQuery message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible. When communicating over an unreliable transport and upon receiving a FloorRequestQuery from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequestQuery message into the FloorRequestStatus message, as described in Section 8.2. Additionally, the floor control server MUST include information about the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The floor control server MUST copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION Camarillo, et al. Expires August 19, 2014 [Page 63] Internet-Draft BFCP February 2014 attribute. The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute). The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO. The floor control server MAY also add to the FLOOR-REQUEST- INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request and a STATUS-INFO attribute with extra information about the floor request. The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes. 13.3. Reception of a UserQuery Message On reception of a UserQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the UserQuery message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. The successful processing of a UserQuery message by a floor control server involves generating a UserStatus message, which SHOULD be generated as soon as possible. When communicating over an unreliable transport and upon receiving a UserQuery from a participant, the floor control server MUST respond with a UserStatus message within the transaction failure window to complete the transaction. Camarillo, et al. Expires August 19, 2014 [Page 64] Internet-Draft BFCP February 2014 The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the UserQuery message into the USerStatus message, as described in Section 8.2. The sender of the UserQuery message is requesting information about all the floor requests associated with a given participant (i.e., the floor requests where the participant is either the beneficiary or the requester). This participant is identified by a BENEFICIARY-ID attribute or, in the absence of a BENEFICIARY-ID attribute, by a the User ID in the common header of the UserQuery message. The floor control server MUST copy, if present, the contents of the BENEFICIARY-ID attribute from the UserQuery message into a BENEFICIARY-INFORMATION attribute in the UserStatus message. Additionally, the floor control server MAY provide the display name and the URI of the participant about which the UserStatus message provides information in this BENEFICIARY-INFORMATION attribute. The floor control server SHOULD add to the UserStatus message a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request related to the participant about which the message provides information (i.e., the floor requests where the participant is either the beneficiary or the requester). For each FLOOR-REQUEST- INFORMATION attribute, the floor control server follows the following steps. The floor control server MUST identify the floor request the FLOOR- REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute). The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO. Camarillo, et al. Expires August 19, 2014 [Page 65] Internet-Draft BFCP February 2014 The floor control server MAY also add to the FLOOR-REQUEST- INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request. The floor control server MUST include the current status of the floor request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST- INFORMATION grouped attribute. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes. 13.4. Reception of a FloorRelease Message On reception of a FloorRelease message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRelease message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. The successful processing of a FloorRelease message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible. When communicating over an unreliable transport and upon receiving a FloorRelease from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRelease message into the FloorRequestStatus message, as described in Section 8.2. The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request. The FloorRelease message identifies the floor request it applies to using a FLOOR-REQUEST-ID. The floor control server MUST copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRelease message into the Floor Request ID field of the FLOOR-REQUEST- INFORMATION attribute. The floor control server MUST identify the floors being released (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute. Camarillo, et al. Expires August 19, 2014 [Page 66] Internet-Draft BFCP February 2014 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status value SHOULD be Released, if the floor (or floors) had been previously granted, or Cancelled, if the floor (or floors) had not been previously granted. The floor control server MAY add a STATUS- INFO attribute with extra information about the floor request. 13.5. Reception of a FloorQuery Message On reception of a FloorQuery message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the FloorQuery message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. When communicating over an unreliable transport and upon receiving a FloorQuery from a participant, the floor control server MUST respond with a FloorStatus message within the transaction failure window to complete the transaction. A floor control server receiving a FloorQuery message from a client SHOULD keep this client informed about the status of the floors identified by FLOOR-ID attributes in the FloorQuery message. Floor Control Servers keep clients informed by using FloorStatus messages. An individual FloorStatus message carries information about a single floor. So, when a FloorQuery message requests information about more than one floor, the floor control server needs to send separate FloorStatus messages for different floors. The information FloorQuery 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. 13.5.1. Generation of the First FloorStatus Message The successful processing of a FloorQuery message by a floor control server involves generating one or several FloorStatus messages, the first of which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorQuery message into the FloorStatus message, as described in Section 8.2. If the FloorQuery message did not contain any FLOOR-ID attribute, the floor control server sends the FloorStatus message without adding any additional attribute and does not send any subsequent FloorStatus Camarillo, et al. Expires August 19, 2014 [Page 67] Internet-Draft BFCP February 2014 message to the floor participant. If the FloorQuery message contained one or more FLOOR-ID attributes, the floor control server chooses one from among them and adds this FLOOR-ID attribute to the FloorStatus message. The floor control server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request associated to the floor. Each FLOOR-REQUEST- INFORMATION grouped attribute contains a number of attributes that provide information about the floor request. For each FLOOR-REQUEST- INFORMATION attribute, the floor control server follows the following steps. The floor control server MUST identify the floor request the FLOOR- REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute). The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO. The floor control server MAY also add to the FLOOR-REQUEST- INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request. The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes. Camarillo, et al. Expires August 19, 2014 [Page 68] Internet-Draft BFCP February 2014 13.5.2. Generation of Subsequent FloorStatus Messages If the FloorQuery message carried more than one FLOOR-ID attribute, the floor control server SHOULD generate a FloorStatus message for each of them (except for the FLOOR-ID attribute chosen for the first FloorStatus message) as soon as possible. These FloorStatus messages are generated following the same rules as those for the first FloorStatus message (see Section 13.5.1), but their Transaction ID is 0 when using a reliable transport and non-zero and unique in the context of outstanding transactions when using an unreliable transport (cf. Section 8). After generating these messages, the floor control server sends FloorStatus messages, periodically keeping the client informed about all the floors for which the client requested information. The Transaction ID of these messages MUST be 0 when using a reliable transport and non-zero and unique in the context of outstanding transactions when using an unreliable transport (cf. Section 8). The rate at which the floor control server sends FloorStatus messages is a matter of local policy. A floor control server may choose to send a new FloorStatus 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. When communicating over an unreliable transport and a FloorStatusAck message is not received within the transaction failure window, the floor control server MUST retransmit the FloorStatus message according to Section 6.2. 13.6. Reception of a ChairAction Message On reception of a ChairAction message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the ChairAction message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. The successful processing of a ChairAction message by a floor control server involves generating a ChairActionAck message, which SHOULD be generated as soon as possible. When communicating over an unreliable transport and upon receiving a ChairAction from a chair, the floor control server MUST respond with a ChairActionAck message within the transaction failure window to complete the transaction. The floor control server MUST copy the Conference ID, the Transaction Camarillo, et al. Expires August 19, 2014 [Page 69] Internet-Draft BFCP February 2014 ID, and the User ID from the ChairAction message into the ChairActionAck message, as described in Section 8.2. The floor control server needs to take into consideration the operation requested in the ChairAction message (e.g., granting a floor) but does not necessarily need to perform it as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server. For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well. So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state. If the new Status in the ChairAction message is Accepted and all the bits of the Queue Position field are zero, the floor chair is requesting that the floor control server assign a queue position (e.g., the last in the queue) to the floor request based on the local policy of the floor control server. (Of course, such a request only applies if the floor control server implements a queue.) 13.7. Reception of a Hello Message On reception of a Hello message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the Hello message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. If the version of BFCP specified in the Version field of the COMMON- HEADER is supported by the floor control server, it MUST respond with the same version number in the HelloAck; this defines the version for all subsequent BFCP messages within this BFCP Connection. If the version given in the Hello message is not supported, the receiving server MUST instead send an Error message with parameter value 12 (Unsupported Version). When communicating over an unreliable transport and upon receiving a Hello from a participant, the floor control server MUST respond with a HelloAck message within the transaction failure window to complete the transaction. Camarillo, et al. Expires August 19, 2014 [Page 70] Internet-Draft BFCP February 2014 The successful processing of a Hello message by a floor control server involves generating a HelloAck message, which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the Hello into the HelloAck, as described in Section 8.2. The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to the HelloAck message listing all the primitives (i.e., BFCP messages) supported by the floor control server. The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to the HelloAck message listing all the attributes supported by the floor control server. 13.8. Error Message Generation Error messages are always sent in response to a previous message from the client as part of a client-initiated transaction. The ABNF in Section 5.3.13 describes the attributes that an Error message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory and which ones are optional. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the message from the client into the Error message, as described in Section 8.2. The floor control server MUST add an ERROR-CODE attribute to the Error message. The ERROR-CODE attribute contains an Error Code from Table 5. Additionally, the floor control server may add an ERROR- INFO attribute with extra information about the error. 14. Security Considerations BFCP uses TLS/DTLS to provide mutual authentication between clients and servers. TLS/DTLS also provides replay and integrity protection and confidentiality. It is RECOMMENDED that TLS/DTLS with non-null encryption always be used. BFCP entities MAY use other security mechanisms as long as they provide similar security properties. The remainder of this section analyzes some of the threats against BFCP and how they are addressed. An attacker may attempt to impersonate a client (a floor participant or a floor chair) in order to generate forged floor requests or to grant or deny existing floor requests. Client impersonation is avoided by having servers only accept BFCP messages over authenticated TLS/DTLS connections. The floor control server assumes Camarillo, et al. Expires August 19, 2014 [Page 71] Internet-Draft BFCP February 2014 that attackers cannot high-jack the TLS/DTLS connection and, therefore, that messages over the TLS/DTLS connection come from the client that was initially authenticated. An attacker may attempt to impersonate a floor control server. A successful attacker would be able to make clients think that they hold a particular floor so that they would try to access a resource (e.g., sending media) without having legitimate rights to access it. Floor control server impersonation is avoided by having servers only accept BFCP messages over authenticated TLS/DTLS connections, as well as ensuring clients only send and accept messages over authenticated TLS/DTLS connections. Attackers may attempt to modify messages exchanged by a client and a floor control server. The integrity protection provided by TLS/DTLS connections prevents this attack. An attacker may attempt to fetch a valid message sent by a client to a floor control server and replay it over a connection between the attacker and the floor control server. This attack is prevented by having floor control servers check that messages arriving over a given authenticated TLS/DTLS connection use an authorized user ID (i.e., a user ID that the user that established the authenticated TLS/DTLS connection is allowed to use). Attackers may attempt to pick messages from the network to get access to confidential information between the floor control server and a client (e.g., why a floor request was denied). TLS/DTLS confidentiality prevents this attack. Therefore, it is RECOMMENDED that TLS/DTLS be used with a non-null encryption algorithm. 15. IANA Considerations [Editorial note: This section instructs the IANA to register new entries in the BFCP Primitive subregistry in Section 15.2 and for the BFCP Error Code subregistry in Section 15.4.] The IANA has created a registry for BFCP parameters called "Binary Floor Control Protocol (BFCP) Parameters". This registry has a number of subregistries, which are described in the following sections. 15.1. Attribute Subregistry This section establishes the Attribute subregistry under the BFCP Parameters registry. As per the terminology in RFC 5226 [5], the registration policy for BFCP attributes shall be "Specification Camarillo, et al. Expires August 19, 2014 [Page 72] Internet-Draft BFCP February 2014 Required". For the purposes of this subregistry, the BFCP attributes for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the attribute's type, name, format, and semantics. For each BFCP attribute, the IANA registers its type, its name, and the reference to the RFC where the attribute is defined. The following table contains the initial values of this subregistry. +------+---------------------------+------------+ | Type | Attribute | Reference | +------+---------------------------+------------+ | 1 | BENEFICIARY-ID | [RFC XXXX] | | 2 | FLOOR-ID | [RFC XXXX] | | 3 | FLOOR-REQUEST-ID | [RFC XXXX] | | 4 | PRIORITY | [RFC XXXX] | | 5 | REQUEST-STATUS | [RFC XXXX] | | 6 | ERROR-CODE | [RFC XXXX] | | 7 | ERROR-INFO | [RFC XXXX] | | 8 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] | | 9 | STATUS-INFO | [RFC XXXX] | | 10 | SUPPORTED-ATTRIBUTES | [RFC XXXX] | | 11 | SUPPORTED-PRIMITIVES | [RFC XXXX] | | 12 | USER-DISPLAY-NAME | [RFC XXXX] | | 13 | USER-URI | [RFC XXXX] | | 14 | BENEFICIARY-INFORMATION | [RFC XXXX] | | 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] | | 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] | | 17 | FLOOR-REQUEST-STATUS | [RFC XXXX] | | 18 | OVERALL-REQUEST-STATUS | [RFC XXXX] | +------+---------------------------+------------+ Table 7: Initial values of the BFCP Attribute subregistry 15.2. Primitive Subregistry [Editorial note: This section instructs the IANA to register the following new values for the BFCP Primitive subregistry: FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.] This section establishes the Primitive subregistry under the BFCP Parameters registry. As per the terminology in RFC 5226 [5], the registration policy for BFCP primitives shall be "Specification Required". For the purposes of this subregistry, the BFCP primitives for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the primitive's value, name, format, and semantics. Camarillo, et al. Expires August 19, 2014 [Page 73] Internet-Draft BFCP February 2014 For each BFCP primitive, the IANA registers its value, its name, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry. +-------+-----------------------+------------+ | Value | Primitive | Reference | +-------+-----------------------+------------+ | 1 | FloorRequest | [RFC XXXX] | | 2 | FloorRelease | [RFC XXXX] | | 3 | FloorRequestQuery | [RFC XXXX] | | 4 | FloorRequestStatus | [RFC XXXX] | | 5 | UserQuery | [RFC XXXX] | | 6 | UserStatus | [RFC XXXX] | | 7 | FloorQuery | [RFC XXXX] | | 8 | FloorStatus | [RFC XXXX] | | 9 | ChairAction | [RFC XXXX] | | 10 | ChairActionAck | [RFC XXXX] | | 11 | Hello | [RFC XXXX] | | 12 | HelloAck | [RFC XXXX] | | 13 | Error | [RFC XXXX] | | 14 | FloorRequestStatusAck | [RFC XXXX] | | 15 | FloorStatusAck | [RFC XXXX] | | 16 | Goodbye | [RFC XXXX] | | 17 | GoodbyeAck | [RFC XXXX] | +-------+-----------------------+------------+ Table 8: Initial values of the BFCP primitive subregistry 15.3. Request Status Subregistry This section establishes the Request Status subregistry under the BFCP Parameters registry. As per the terminology in RFC 5226 [5], the registration policy for BFCP request status shall be "Specification Required". For the purposes of this subregistry, the BFCP request status for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the value and the semantics of the request status. For each BFCP request status, the IANA registers its value, its meaning, and the reference to the RFC where the request status is defined. The following table contains the initial values of this subregistry. Camarillo, et al. Expires August 19, 2014 [Page 74] Internet-Draft BFCP February 2014 +-------+-----------+------------+ | Value | Status | Reference | +-------+-----------+------------+ | 1 | Pending | [RFC XXXX] | | 2 | Accepted | [RFC XXXX] | | 3 | Granted | [RFC XXXX] | | 4 | Denied | [RFC XXXX] | | 5 | Cancelled | [RFC XXXX] | | 6 | Released | [RFC XXXX] | | 7 | Revoked | [RFC XXXX] | +-------+-----------+------------+ Table 9: Initial values of the Request Status subregistry 15.4. Error Code Subregistry [Editorial note: This section instructs the IANA to register the following new values for the BFCP Error Code subregistry: 10, 11, 12, 13 and 14.] This section establishes the Error Code subregistry under the BFCP Parameters registry. As per the terminology in RFC 5226 [5], the registration policy for BFCP error codes shall be "Specification Required". For the purposes of this subregistry, the BFCP error codes for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the value and the semantics of the error code, and any Error Specific Details that apply to it. For each BFCP primitive, the IANA registers its value, its meaning, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry. Camarillo, et al. Expires August 19, 2014 [Page 75] Internet-Draft BFCP February 2014 +-------+--------------------------------------+------------+ | Value | Meaning | Reference | +-------+--------------------------------------+------------+ | 1 | Conference does not Exist | [RFC XXXX] | | 2 | User does not Exist | [RFC XXXX] | | 3 | Unknown Primitive | [RFC XXXX] | | 4 | Unknown Mandatory Attribute | [RFC XXXX] | | 5 | Unauthorized Operation | [RFC XXXX] | | 6 | Invalid Floor ID | [RFC XXXX] | | 7 | Floor Request ID Does Not Exist | [RFC XXXX] | | 8 | You have Already Reached the Maximum | [RFC XXXX] | | | Number of Ongoing Floor Requests for | | | | this Floor | | | 9 | Use TLS | [RFC XXXX] | | 10 | Unable to parse message | [RFC XXXX] | | 11 | Use DTLS | [RFC XXXX] | | 12 | Unsupported Version | [RFC XXXX] | | 13 | Incorrect Message Length | [RFC XXXX] | | 14 | Generic Error | [RFC XXXX] | +-------+--------------------------------------+------------+ Table 10: Initial Values of the Error Code subregistry 16. Changes from RFC 4582 Following is the list of technical changes and other non-trivial fixes from [2]. 16.1. Extensions for an unreliable transport Main purpose of this work was to revise the specification to support BFCP over an unreliable transport, resulting in the following changes: 1. Overview of Operation (Section 4): Changed the description of client-initiated and server-initiated transactions, referring to Section 8. 2. COMMON-HEADER Format (Section 5.1): Ver(sion) field, where the value 2 is used for the extensions for an unreliable transport. Added new R and F flag-bits for an unreliable transport. Res(erved) field is now 3 bit. New optional Fragment Offset and Fragment Length fields. 3. New primitives (Section 5.1): Added four new primitives: FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck. Camarillo, et al. Expires August 19, 2014 [Page 76] Internet-Draft BFCP February 2014 4. New error codes (Section 5.2.6): Added three new error codes: "Unable to Parse Message", "Use DTLS" and "Unsupported Version". Note that two additional error codes were added, see Section 16.2. 5. ABNF for new primitives (Section 5.3): New subsections with normative ABNF for the new primitives. 6. Transport split in two (Section 6): Section 6 specifying the transport was split in two subsections; Section 6.1 for a reliable transport and Section 6.2 for an unreliable transport. Where the specification for an unreliable transport amongst other issues deals with reliability, congestion control, fragmentation and ICMP. 7. Mandate DTLS (Section 7 and Section 9): Mandate DTLS support when transport over UDP is used. 8. Transaction changes (Section 8): Server-initiated transactions over an unreliable transport has non-zero and unique Transaction ID. Over an unreliable transport, the retransmit timers T1 and T2 described in Section 8.3 apply. 9. Requiring timely response (Section 8.3, Section 10.1.2, Section 10.2.2, Section 11.2, Section 12.1.2, Section 12.2.2, Section 12.3.2, Section 12.4.2, Section 10.1.3 and Section 12.1.3): Describing that a given response must be sent within the transaction failure window to complete the transaction. 10. Updated IANA Considerations (Section 15): Added the new primitives and error codes to Section 15.2 and Section 15.4 respectively. 11. Examples over an unreliable transport (Appendix A): Added sample interactions over an unreliable transport for the scenarios in Figure 2 and Figure 3 12. Motivation for an unreliable transport (Appendix B): Introduction to and motivation for extending BFCP to support an unreliable transport. 16.2. Other changes The clarification and bug fixes: Camarillo, et al. Expires August 19, 2014 [Page 77] Internet-Draft BFCP February 2014 1. ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>, Figure 28, Figure 30, and the ABNF figures in Section 5.3): Although formally correct in [2], the notation has changed in a number of Figures to an equivalent form for clarity, e.g., s/*1(FLOOR-ID)/[FLOOR-ID]/ in Figure 38 and s/*[XXX]/*(XXX)/ in the other figures. 2. Typo (Section 12.4.2): Change from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the second paragraph. 3. Corrected attribute type (Section 13.1.1): Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in the eighth paragraph, since the note below describes priority and that the last paragraph deals with PARTICIPANT-PROVIDED-INFO. 4. New error codes (Section 5.2.6): Added two additional error codes: "Incorrect Message Length" and "Generic Error". 5. Assorted clarifications (Across the document): Non-functional language clarifications and some corrections in the normative language as a result of reviews. 17. Acknowledgements The XCON WG chairs, Adam Roach and Alan Johnston, provided useful ideas for RFC 4582 [2]. Additionally, Xiaotao Wu, Paul Kyzivat, Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morgan, and Oscar Novo provided useful comments during the work with RFC 4582. The authors also acknowledge contributions to the revision of BFCP for use over an unreliable transport from Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad, Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, Joerg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman, Vijaya Mandava and Alan Ford. In the final phase Ernst Horvath did a thorough review revealing issues that needed clarification and changes. Useful and important final reviews were done by Mary Barnes. 18. References Camarillo, et al. Expires August 19, 2014 [Page 78] Internet-Draft BFCP February 2014 18.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006. [3] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, September 2007. [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [7] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [9] Camarillo, G. and T. Kristensen, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-09 (work in progress), February 2014. [10] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007. [11] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. 18.2. Informational References [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [13] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, February 2006. [14] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008. Camarillo, et al. Expires August 19, 2014 [Page 79] Internet-Draft BFCP February 2014 [15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [16] 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. [17] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012. [18] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, March 2012. [19] Barnes, M., Miniero, L., Presta, R., and SP. Romano, "Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples", RFC 6504, March 2012. [20] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [21] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [22] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. [23] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010. [24] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [25] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. [26] Thaler, D., "Teredo Extensions", RFC 6081, January 2011. [27] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [28] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, March 2012. Camarillo, et al. Expires August 19, 2014 [Page 80] Internet-Draft BFCP February 2014 [29] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling (GUT)", draft-manner-tsvwg-gut-02 (work in progress), July 2010. [30] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", draft-ietf-mmusic-media-path-middleboxes-05 (work in progress), July 2012. [31] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", 2005, . [32] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer Communication Across Network Address Translators", April 2005, . Appendix A. Example Call Flows for BFCP over an Unreliable Transport With reference to Section 4.1, the following figures show representative call-flows for requesting and releasing a floor, and obtaining status information about a floor when BFCP is deployed over an unreliable transport. The figures here show a loss-less interaction. Floor Participant Floor Control Server |(1) FloorRequest | |Transaction ID: 123 | |User ID: 234 | |FLOOR-ID: 543 | |---------------------------------------------->| | | |(2) FloorRequestStatus | |Transaction ID: 123 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Pending | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(3) FloorRequestStatus | Camarillo, et al. Expires August 19, 2014 [Page 81] Internet-Draft BFCP February 2014 |Transaction ID: 124 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(4) FloorRequestStatusAck | |Transaction ID: 124 | |User ID: 234 | |---------------------------------------------->| | | |(5) FloorRequestStatus | |Transaction ID: 125 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(6) FloorRequestStatusAck | |Transaction ID: 125 | |User ID: 234 | |---------------------------------------------->| | | |(7) FloorRelease | |Transaction ID: 126 | |User ID: 234 | |FLOOR-REQUEST-ID: 789 | |---------------------------------------------->| | | |(8) FloorRequestStatus | |Transaction ID: 126 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Released | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| Camarillo, et al. Expires August 19, 2014 [Page 82] Internet-Draft BFCP February 2014 Figure 48: Requesting and releasing a floor Note that in Figure 48, the FloorRequestStatus message from the floor control server to the floor participant is a transaction-closing message as a response to the client-initiated transaction with Transaction ID 154. It does not and SHOULD NOT be followed by a FloorRequestStatusAck message from the floor participant to the floor control server. Floor Participant Floor Control Server |(1) FloorQuery | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID: 543 | |---------------------------------------------->| | | |(2) FloorStatus | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 2nd | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(3) FloorStatus | |Transaction ID: 258 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | Camarillo, et al. Expires August 19, 2014 [Page 83] Internet-Draft BFCP February 2014 | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(4) FloorStatusAck | |Transaction ID: 258 | |User ID: 234 | |---------------------------------------------->| | | |(5) FloorStatus | |Transaction ID: 259 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(6) FloorStatusAck | |Transaction ID: 259 | |User ID: 234 | |---------------------------------------------->| Figure 49: Obtaining status information about a floor Appendix B. Motivation for Supporting an Unreliable Transport This appendix is contained in this document as an aid to understand the background and rationale for adding support for unreliable Camarillo, et al. Expires August 19, 2014 [Page 84] Internet-Draft BFCP February 2014 transport. B.1. Motivation In existing video conferencing deployments, BFCP is used to manage the floor for the content sharing associated with the conference. For peer to peer scenarios, including business to business conferences and point to point conferences in general, it is frequently the case that one or both endpoints exists behind a NAT. BFCP roles are negotiated in the offer/answer exchange as specified in [9], resulting in one endpoint being responsible for opening the TCP connection used for the BFCP communication. +---------+ | Network | +---------+ +-----+ / \ +-----+ | NAT |/ \| NAT | +-----+ +-----+ +----+ / \ +----+ |BFCP|/ \|BFCP| | UA | | UA | +----+ +----+ Figure 50: Use Case The communication session between the video conferencing endpoints typically consists of a number of RTP over UDP media streams, for audio and video, and a BFCP connection for floor control. Existing deployments are most common in, but not limited to, enterprise networks. In existing deployments, NAT traversal for the RTP streams works using ICE and/or other methods, including those described in [30]. When enhancing an existing SIP based video conferencing deployment with support for content sharing, the BFCP connection often poses a problem. The reasons for this fall into two general classes. First, there may be a strong preference for UDP based signaling in general. On high capacity endpoints (e.g., PSTN gateways or SIP/H.323 inter- working gateways), TCP can suffer from head of line blocking, and it uses many kernel buffers. Network operators view UDP as a way to avoid both of these. Second, establishment and traversal of the TCP connection involving ephemeral ports, as is typically the case with BFCP over TCP, can be problematic, as described in Appendix A of [28]. A broad study of NAT behavior and peer-to-peer TCP establishment for a comprehensive set of TCP NAT traversal techniques over a wide range of commercial NAT products concluded it was not Camarillo, et al. Expires August 19, 2014 [Page 85] Internet-Draft BFCP February 2014 possible to establish a TCP connection in 11% of the cases [31]. The results are worse when focusing on enterprise NATs. A study of hole punching as a NAT traversal technique across a wide variety of deployed NATs reported consistently higher success rates when using UDP than when using TCP [32]. It is worth noticing that BFCP over UDP were already used in real deployments, underlining the necessity to specify a common way to exchange BFCP messages where TCP is not appropriate, to avoid a situation where multiple different and non-interoperable would co- exist in the market. The purpose of this draft is to formalize and publish the extension from the standard specification to facilitate complete interoperability between implementations. B.1.1. Alternatives Considered In selecting the approach of defining UDP as an alternate transport for BFCP, several alternatives were considered and explored to some degree. Each of these is discussed briefly in the following subsections. In summary, while the not chosen alternatives work in a number of scenarios, they are not sufficient, in and of themselves, to address the use case targeted by this draft. The last alternative, presented in Appendix B.1.1.7, is the selected one and is specified in this draft. It is also worth noting that the IETF Transport Area were asked for a way to tunnel TCP over UDP, but at that point there was no consensus on how to achieve that. B.1.1.1. ICE TCP ICE TCP [28] extends ICE to TCP based media, including the ability to offer a mix of TCP and UDP based candidates for a single stream. ICE TCP has, in general, a lower success probability for enabling TCP connectivity without a relay if both of the hosts are behind a NAT (see Appendix A of [28]) than enabling UDP connectivity in the same scenarios. The happens because many of the currently deployed NATs in video conferencing networks do not support the flow of TCP hand shake packets seen in case of TCP simultaneous-open, either because they do not allow incoming TCP SYN packets from an address to which a SYN packet has been sent to recently, or because they do not properly process the subsequent SYNACK. Implementing various techniques advocated for candidate collection in [28] should increase the success probability, but many of these techniques require support from some network elements (e.g., from the NATs). Such support is not common in enterprise NATs. Camarillo, et al. Expires August 19, 2014 [Page 86] Internet-Draft BFCP February 2014 B.1.1.2. Teredo Teredo [24] enables nodes located behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP. Teredo extensions [26] provide additional capabilities to Teredo, including support for more types of NATs and support for more efficient communication. As defined, Teredo could be used to make BFCP work for the video conferencing use cases addressed in this draft. However, running the service requires the help of "Teredo servers" and "Teredo relays" [24]. These servers and relays generally do not exist in the existing video conferencing deployments. It also requires IPv6 awareness on the endpoints. It should also be noted that ICMP6, as used with Teredo to complete an initial protocol exchange and confirm that the appropriate NAT bindings have been set up, is not a conventional feature of IPv4 or even IPv6, and some currently deployed IPv6 firewalls discard ICMP messages. As these networks continue to evolve and tackle the transaction to IPv6, Teredo servers and relays may be deployed, making Teredo available as a suitable alternative to BFCP over UDP. B.1.1.3. GUT GUT [29] attempts to facilitate tunneling over UDP by encapsulating the native transport protocol and its payload (in general the whole IP payload) within a UDP packet destined to the well-known port GUT_P. Unfortunately, it requires user-space TCP, for which there is not a readily available implementation, and creating one is a large project in itself. This draft has expired and its future is still not clear as it has not yet been adopted by a working group. B.1.1.4. UPnP IGD Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on the edge of the network, providing connectivity to the Internet for computers internal to the LAN, but do not allow Internet devices to connect to computers on the internal LAN. IGDs enable a computer on an internal LAN to create port mappings on their NAT, through which hosts on the Internet can send data that will be forwarded to the computer on the internal LAN. IGDs may be self-contained hardware devices or may be software components provided within an operating system. In considering UPnP IGD, several issues exist. Not all NATs support UPnP, and many that do support it are configured with it turned off by default. NATs are often multilayered, and UPnP does not work well with such NATs. For example, a typical DSL modems acts as a NAT, and Camarillo, et al. Expires August 19, 2014 [Page 87] Internet-Draft BFCP February 2014 the user plugs in a wireless access point behind that, which adds another layer NAT. The client can discover the first layer of NAT using multicast but it is harder to figure out how to discover and control NATs in the next layer up. B.1.1.5. NAT PMP The NAT Port Mapping Protocol (NAT PMP) allows a computer in a private network (behind a NAT router) to automatically configure the router to allow parties outside the private network to contact it. NAT PMP runs over UDP. It essentially automates the process of port forwarding. Included in the protocol is a method for retrieving the public IP address of a NAT gateway, thus allowing a client to make this public IP address and port number known to peers that may wish to communicate with it. Many NATs do not support PMP. In those that do support it, it has similar issues with negotiation of multilayer NATs as UPnP. Video conferencing is used extensively in enterprise networks, and NAT PMP is not generally available in enterprise-class routers. B.1.1.6. SCTP It would be quite straight forward to specify a BFCP binding for SCTP [27], and then tunnel SCTP over UDP in the use case described in Appendix B.1. SCTP is gaining some momentum currently. There is ongoing discussion in the RTCWeb WG regarding this approach. However, this approach for tunneling over UDP was not mature enough when considered and not even fully specified. B.1.1.7. BFCP over UDP transport To overcome the problems with establishing TCP flows between BFCP entities, an alternative is to define UDP as an alternate transport for BFCP, leveraging the same mechanisms in place for the RTP over UDP media streams for the BFCP communication. When using UDP as the transport, it is recommended to follow the guidelines provided in [25]. Minor changes to the transaction model are introduced in that all requests now have an appropriate response to complete the transaction. The requests are sent with a retransmit timer associated with the response to achieve reliability. This alternative does not change the semantics of BFCP. It permits UDP as an alternate transport. Existing implementations, in the spirit of the approach detailed in earlier versions of this draft, have demonstrated this approach to be Camarillo, et al. Expires August 19, 2014 [Page 88] Internet-Draft BFCP February 2014 feasible. Initial compatibility among implementations has been achieved at previous interoperability events. The authors view this extension as a pragmatic solution to an existing deployment challenge. This is the chosen approach, and the extensions is specified in this document. Authors' Addresses Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: gonzalo.camarillo@ericsson.com Keith Drage Alcatel-Lucent Quadrant, StoneHill Green, Westlea Swindon, Wilts UK Email: drage@alcatel-lucent.com Tom Kristensen Cisco Philip Pedersens vei 22 N-1366 Lysaker Norway Email: tomkrist@cisco.com, tomkri@ifi.uio.no Joerg Ott Aalto University Otakaari 5 A Espoo, FIN 02150 Finland Email: jo@comnet.tkk.fi Camarillo, et al. Expires August 19, 2014 [Page 89] Internet-Draft BFCP February 2014 Charles Eckel Cisco 707 Tasman Drive California, CA 95035 United States Email: eckelcu@cisco.com Camarillo, et al. Expires August 19, 2014 [Page 90]