idnits 2.17.1 draft-ietf-bfcpbis-rfc4582bis-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2015) is 3085 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 3460 ** Obsolete normative reference: RFC 2988 (ref. '2') (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 4582 (ref. '3') (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 5226 (ref. '6') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (ref. '7') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (ref. '8') (Obsoleted by RFC 9147) == Outdated reference: A later version (-27) exists of draft-ietf-bfcpbis-rfc4583bis-12 ** Obsolete normative reference: RFC 5389 (ref. '12') (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5405 (ref. '13') (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 5245 (ref. '17') (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 1981 (ref. '24') (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 7525 (ref. '28') (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '31') (Obsoleted by RFC 9260) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFCPbis Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Obsoletes: 4582 (if approved) K. Drage 5 Intended status: Standards Track Alcatel-Lucent 6 Expires: May 16, 2016 T. Kristensen 7 Cisco 8 J. Ott 9 Aalto University 10 C. Eckel 11 Cisco 12 November 13, 2015 14 The Binary Floor Control Protocol (BFCP) 15 draft-ietf-bfcpbis-rfc4582bis-16 17 Abstract 19 Floor control is a means to manage joint or exclusive access to 20 shared resources in a (multiparty) conferencing environment. 21 Thereby, floor control complements other functions -- such as 22 conference and media session setup, conference policy manipulation, 23 and media control -- that are realized by other protocols. 25 This document specifies the Binary Floor Control Protocol (BFCP). 26 BFCP is used between floor participants and floor control servers, 27 and between floor chairs (i.e., moderators) and floor control 28 servers. 30 This document obsoletes RFC 4582. Changes from RFC 4582 are 31 summarized in Section 16. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 16, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1. Floor Creation . . . . . . . . . . . . . . . . . . . . . 8 71 3.2. Obtaining Information to Contact a Floor Control Server . 8 72 3.3. Obtaining Floor-Resource Associations . . . . . . . . . . 8 73 3.4. Privileges of Floor Control . . . . . . . . . . . . . . . 9 74 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 9 75 4.1. Floor Participant to Floor Control Server Interface . . . 10 76 4.2. Floor Chair to Floor Control Server Interface . . . . . . 14 77 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 15 78 5.1. COMMON-HEADER Format . . . . . . . . . . . . . . . . . . 15 79 5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . 18 80 5.2.1. BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . 21 81 5.2.2. FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . 21 82 5.2.3. FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . 21 83 5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 22 84 5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . 22 85 5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . 23 86 5.2.6.1. Error-Specific Details for Error Code 4 . . . . . 24 87 5.2.7. ERROR-INFO . . . . . . . . . . . . . . . . . . . . . 25 88 5.2.8. PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . . 26 89 5.2.9. STATUS-INFO . . . . . . . . . . . . . . . . . . . . . 26 90 5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . 27 91 5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . 27 92 5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 28 93 5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . 29 94 5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 29 95 5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 30 96 5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . 31 97 5.2.17. FLOOR-REQUEST-STATUS . . . . . . . . . . . . . . . . 31 98 5.2.18. OVERALL-REQUEST-STATUS . . . . . . . . . . . . . . . 32 99 5.3. Message Format . . . . . . . . . . . . . . . . . . . . . 33 100 5.3.1. FloorRequest . . . . . . . . . . . . . . . . . . . . 33 101 5.3.2. FloorRelease . . . . . . . . . . . . . . . . . . . . 33 102 5.3.3. FloorRequestQuery . . . . . . . . . . . . . . . . . . 33 103 5.3.4. FloorRequestStatus . . . . . . . . . . . . . . . . . 34 104 5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 34 105 5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . 34 106 5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . 35 107 5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 35 108 5.3.9. ChairAction . . . . . . . . . . . . . . . . . . . . . 35 109 5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . 35 110 5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 36 111 5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . 36 112 5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 36 113 5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 36 114 5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . 37 115 5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 37 116 5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . 37 117 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 37 118 6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . 38 119 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . 39 120 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . 40 121 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 41 122 6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . 41 123 6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 42 124 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 43 125 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 43 126 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 44 127 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 44 128 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 45 129 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . 45 130 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 45 131 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . 46 132 9. Authentication and Authorization . . . . . . . . . . . . . . 46 133 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . 47 134 10. Floor Participant Operations . . . . . . . . . . . . . . . . 48 135 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . 48 136 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . 48 137 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . 49 138 10.1.3. Reception of a Subsequent FloorRequestStatus Message 50 139 10.2. Cancelling a Floor Request and Releasing a Floor . . . . 50 140 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . 50 141 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . 51 142 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 51 143 11.1. Sending a ChairAction Message . . . . . . . . . . . . . 51 144 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . 53 145 12. General Client Operations . . . . . . . . . . . . . . . . . . 53 146 12.1. Requesting Information about Floors . . . . . . . . . . 53 147 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . 53 148 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . 54 149 12.1.3. Reception of a Subsequent FloorStatus Message . . . 55 150 12.2. Requesting Information about Floor Requests . . . . . . 55 151 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . 55 152 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . 55 153 12.3. Requesting Information about a User . . . . . . . . . . 56 154 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . 56 155 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . 57 156 12.4. Obtaining the Capabilities of a Floor Control Server . . 57 157 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . 57 158 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . 57 159 13. Floor Control Server Operations . . . . . . . . . . . . . . . 58 160 13.1. Reception of a FloorRequest Message . . . . . . . . . . 58 161 13.1.1. Generating the First FloorRequestStatus Message . . 59 162 13.1.2. Generation of Subsequent FloorRequestStatus Messages 60 163 13.2. Reception of a FloorRequestQuery Message . . . . . . . . 61 164 13.3. Reception of a UserQuery Message . . . . . . . . . . . . 63 165 13.4. Reception of a FloorRelease Message . . . . . . . . . . 64 166 13.5. Reception of a FloorQuery Message . . . . . . . . . . . 65 167 13.5.1. Generation of the First FloorStatus Message . . . . 66 168 13.5.2. Generation of Subsequent FloorStatus Messages . . . 67 169 13.6. Reception of a ChairAction Message . . . . . . . . . . . 68 170 13.7. Reception of a Hello Message . . . . . . . . . . . . . . 69 171 13.8. Error Message Generation . . . . . . . . . . . . . . . . 69 172 14. Security Considerations . . . . . . . . . . . . . . . . . . . 70 173 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 174 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . 71 175 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . 72 176 15.3. Request Status Subregistry . . . . . . . . . . . . . . . 73 177 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . 74 178 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 75 179 16.1. Extensions for an unreliable transport . . . . . . . . . 75 180 16.2. Other changes . . . . . . . . . . . . . . . . . . . . . 76 181 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77 182 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 183 18.1. Normative References . . . . . . . . . . . . . . . . . . 78 184 18.2. Informational References . . . . . . . . . . . . . . . . 79 185 Appendix A. Example Call Flows for BFCP over an Unreliable 186 Transport . . . . . . . . . . . . . . . . . . . . . 81 187 Appendix B. Motivation for Supporting an Unreliable Transport . 85 188 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 85 189 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 87 190 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 87 191 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . 87 192 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 88 193 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . 88 194 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 88 195 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . 89 196 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 89 197 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 199 1. Introduction 201 Within a conference, some applications need to manage the access to a 202 set of shared resources, such as the right to send media to a 203 particular media session. Floor control enables such applications to 204 provide users with coordinated (shared or exclusive) access to these 205 resources. 207 The Requirements for Floor Control Protocol [15] list a set of 208 requirements that need to be met by floor control protocols. The 209 Binary Floor Control Protocol (BFCP), which is specified in this 210 document, meets these requirements. 212 In addition, BFCP has been designed so that it can be used in low- 213 bandwidth environments. The binary encoding used by BFCP achieves a 214 small message size (when message signatures are not used) that keeps 215 the time it takes to transmit delay-sensitive BFCP messages to a 216 minimum. Delay-sensitive BFCP messages include FloorRequest, 217 FloorRelease, FloorRequestStatus, and ChairAction. It is expected 218 that future extensions to these messages will not increase the size 219 of these messages in a significant way. 221 The remainder of this document is organized as follows: Section 2 222 defines the terminology used throughout this document, Section 3 223 discusses the scope of BFCP (i.e., which tasks fall within the scope 224 of BFCP and which ones are performed using different mechanisms), 225 Section 4 provides a non-normative overview of BFCP operation, and 226 subsequent sections provide the normative specification of BFCP. 228 2. Terminology 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 232 "OPTIONAL" in this document are to be interpreted as described in BCP 233 14, RFC 2119 [1] and indicate requirement levels for compliant 234 implementations. 236 Media Participant: An entity that has access to the media resources 237 of a conference (e.g., it can receive a media stream). In floor- 238 controlled conferences, a given media participant is typically 239 colocated with a floor participant, but it does not need to be. 240 Third-party floor requests consist of having a floor participant 241 request a floor for a media participant when they are not colocated. 243 The protocol between a floor participant and a media participant 244 (that are not colocated) is outside the scope of this document. 246 Client: A floor participant or a floor chair that communicates with a 247 floor control server using BFCP. 249 Floor: A temporary permission to access or manipulate a specific 250 shared resource or set of resources. 252 Floor Chair: A logical entity that manages one floor (grants, denies, 253 or revokes a floor). An entity that assumes the logical role of a 254 floor chair for a given transaction may assume a different role 255 (e.g., floor participant) for a different transaction. The roles of 256 floor chair and floor participant are defined on a transaction-by- 257 transaction basis. BFCP transactions are defined in Section 8. 259 Floor Control: A mechanism that enables applications or users to gain 260 safe and mutually exclusive or non-exclusive input access to the 261 shared object or resource. 263 Floor Control Server: A logical entity that maintains the state of 264 the floor(s), including which floors exists, who the floor chairs 265 are, who holds a floor, etc. Requests to manipulate a floor are 266 directed at the floor control server. The floor control server of a 267 conference may perform other logical roles (e.g., floor participant) 268 in another conference. 270 Floor Participant: A logical entity that requests floors, and 271 possibly information about them, from a floor control server. An 272 entity that assumes the logical role of a floor participant for a 273 given transaction may assume a different role (e.g., a floor chair) 274 for a different transaction. The roles of floor participant and 275 floor chair are defined on a transaction-by-transaction basis. BFCP 276 transactions are defined in Section 8. In floor-controlled 277 conferences, a given floor participant is typically colocated with a 278 media participant, but it does not need to be. Third-party floor 279 requests consist of having a floor participant request a floor for a 280 media participant when they are not colocated. 282 Participant: An entity that acts as a floor participant, as a media 283 participant, or as both. 285 BFCP Connection: A transport association between BFCP entities, used 286 to exchange BFCP messages. 288 Transaction Failure Window: When communicating over an unreliable 289 transport, this is some period of time less than or equal to T1*2^4 290 (see Section 8.3). For reliable transports, this period of time is 291 unbounded. 293 3. Scope 295 As stated earlier, BFCP is a protocol to coordinate access to shared 296 resources in a conference following the requirements defined in [15]. 297 Floor control complements other functions defined in the XCON 298 conferencing framework [16]. The floor control protocol BFCP defined 299 in this document only specifies a means to arbitrate access to 300 floors. The rules and constraints for floor arbitration and the 301 results of floor assignments are outside the scope of this document 302 and are defined by other protocols [16]. 304 Figure 1 shows the tasks that BFCP can perform. 306 +---------+ 307 | Floor | 308 | Chair | 309 | | 310 +---------+ 311 ^ | 312 | | 313 Notification | | Decision 314 | | 315 | | 316 Floor | v 317 +-------------+ Request +---------+ +-------------+ 318 | Floor |----------->| Floor | Notification | Floor | 319 | Participant | | Control |------------->| Participant | 320 | |<-----------| Server | | | 321 +-------------+ Granted or +---------+ +-------------+ 322 Denied 324 Figure 1: Functionality provided by BFCP 326 BFCP provides a means: 328 o for floor participants to send floor requests to floor control 329 servers. 331 o for floor control servers to grant or deny requests to access a 332 given resource from floor participants. 334 o for floor chairs to send floor control servers decisions regarding 335 floor requests. 337 o for floor control servers to keep floor participants and floor 338 chairs informed about the status of a given floor or a given floor 339 request. 341 Even though tasks that do not belong to the previous list are outside 342 the scope of BFCP, some of these out-of-scope tasks relate to floor 343 control and are essential for creating floors and establishing BFCP 344 connections between different entities. In the following 345 subsections, we discuss some of these tasks and mechanisms to perform 346 them. 348 3.1. Floor Creation 350 The association of a given floor with a resource or a set of 351 resources (e.g., media streams) is out of the scope of BFCP as 352 described in [16]. Floor creation and termination are also outside 353 the scope of BFCP; these aspects are handled using the conference 354 control protocol for manipulating the conference object. 355 Consequently, the floor control server needs to stay up to date on 356 changes to the conference object (e.g., when a new floor is created). 358 Conference control clients using CCMP [21] can specify such floor- 359 related settings in the element [20] of the to-be 360 created conference object provided in the body of a CCMP confRequest/ 361 create message issued to the conference control server. 363 3.2. Obtaining Information to Contact a Floor Control Server 365 A client needs a set of data in order to establish a BFCP connection 366 to a floor control server. This data includes the transport address 367 of the server, the conference identifier, and a user identifier. 369 Clients can obtain this information in different ways. One is to use 370 an SDP offer/answer [14] exchange, which is described in [10]. How 371 to establish a connection to a BFCP floor control server outside the 372 context of an offer/answer exchange when using a reliable transport 373 is described in [4]. Other mechanisms are described in the XCON 374 framework [16] (and other related documents). For unreliable 375 transports, the use of an SDP offer/answer exchange is the only 376 specified mechanism. 378 3.3. Obtaining Floor-Resource Associations 380 Floors are associated with resources. For example, a floor that 381 controls who talks at a given time has a particular audio session as 382 its associated resource. Associations between floors and resources 383 are part of the conference object. 385 Floor participants and floor chairs need to know which resources are 386 associated with which floors. They can obtain this information by 387 using different mechanisms, such as an SDP offer/answer [14] 388 exchange. How to use an SDP offer/answer exchange to obtain these 389 associations is described in [10]. 391 Note that floor participants perform SDP offer/answer exchanges 392 with the conference focus of the conference. So, the conference 393 focus needs to obtain information about associations between 394 floors and resources in order to be able to provide this 395 information to a floor participant in an SDP offer/answer 396 exchange. 398 Other mechanisms for obtaining this information, including discussion 399 of how the information is made available to a (SIP) Focus, are 400 described in the XCON framework [16] (and other related documents). 401 According to the conferencing system policies, conference control 402 clients using CCMP [21] can modify the floor settings of a conference 403 by issuing CCMP confRequest/update messages providing the specific 404 updates to the element of the target conference 405 object. More information about CCMP and BFCP interaction can be 406 found in [22]. 408 3.4. Privileges of Floor Control 410 A participant whose floor request is granted has the right to use the 411 resource or resources associated with the floor that was requested. 412 For example, the participant may have the right to send media over a 413 particular audio stream. 415 Nevertheless, holding a floor does not imply that others will not be 416 able to use its associated resources at the same time, even if they 417 do not have the right to do so. Determination of which media 418 participants can actually use the resources in the conference is 419 discussed in the XCON Framework [16]. 421 4. Overview of Operation 423 This section provides a non-normative description of BFCP operations. 424 Section 4.1 describes the interface between floor participants and 425 floor control servers, and Section 4.2 describes the interface 426 between floor chairs and floor control servers. 428 BFCP messages, which use a TLV (Type-Length-Value) binary encoding, 429 consist of a common header followed by a set of attributes. The 430 common header contains, among other information, a 32-bit conference 431 identifier. Floor participants, media participants, and floor chairs 432 are identified by 16-bit user identifiers. 434 BFCP supports nested attributes (i.e., attributes that contain 435 attributes). These are referred to as grouped attributes. 437 There are two types of transactions in BFCP: client-initiated 438 transactions and server-initiated transactions. Section 8 describes 439 both types of transactions in detail. 441 4.1. Floor Participant to Floor Control Server Interface 443 Floor participants request a floor by sending a FloorRequest message 444 to the floor control server. BFCP supports third-party floor 445 requests. That is, the floor participant sending the floor request 446 need not be colocated with the media participant that will get the 447 floor once the floor request is granted. FloorRequest messages carry 448 the identity of the requester in the User ID field of the common 449 header, and the identity of the beneficiary of the floor (in third- 450 party floor requests) in a BENEFICIARY-ID attribute. 452 Third-party floor requests can be sent, for example, by floor 453 participants that have a BFCP connection to the floor control 454 server but that are not media participants (i.e., they do not 455 handle any media). 457 FloorRequest messages identify the floor or floors being requested by 458 carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a 459 FloorRequest message carries more than one floor identifier, the 460 floor control server treats all the floor requests as an atomic 461 package. That is, the floor control server either grants or denies 462 all the floors in the FloorRequest message. 464 Floor control servers respond to FloorRequest messages with 465 FloorRequestStatus messages, which provide information about the 466 status of the floor request. The first FloorRequestStatus message is 467 the response to the FloorRequest message from the client, and 468 therefore has the same Transaction ID as the FloorRequest. 470 Additionally, the first FloorRequestStatus message carries the Floor 471 Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent 472 FloorRequestStatus messages related to the same floor request will 473 carry the same Floor Request ID. This way, the floor participant can 474 associate them with the appropriate floor request. 476 Messages from the floor participant related to a particular floor 477 request also use the same Floor Request ID as the first 478 FloorRequestStatus Message from the floor control server. 480 Figures 2 and 3 below show examples of call flows where BFCP is used 481 over a reliable transport. Appendix A shows the same call flow 482 examples using an unreliable transport. 484 Figure 2 shows how a floor participant requests a floor, obtains it, 485 and, at a later time, releases it. This figure illustrates the use, 486 among other things, of the Transaction ID and the FLOOR-REQUEST-ID 487 attribute. 489 Floor Participant Floor Control 490 Server 491 |(1) FloorRequest | 492 |Transaction ID: 123 | 493 |User ID: 234 | 494 |FLOOR-ID: 543 | 495 |---------------------------------------------->| 496 | | 497 |(2) FloorRequestStatus | 498 |Transaction ID: 123 | 499 |User ID: 234 | 500 |FLOOR-REQUEST-INFORMATION | 501 | Floor Request ID: 789 | 502 | OVERALL-REQUEST-STATUS | 503 | Request Status: Pending | 504 | FLOOR-REQUEST-STATUS | 505 | Floor ID: 543 | 506 |<----------------------------------------------| 507 | | 508 |(3) FloorRequestStatus | 509 |Transaction ID: 0 | 510 |User ID: 234 | 511 |FLOOR-REQUEST-INFORMATION | 512 | Floor Request ID: 789 | 513 | OVERALL-REQUEST-STATUS | 514 | Request Status: Accepted | 515 | Queue Position: 1st | 516 | FLOOR-REQUEST-STATUS | 517 | Floor ID: 543 | 518 |<----------------------------------------------| 519 | | 520 |(4) FloorRequestStatus | 521 |Transaction ID: 0 | 522 |User ID: 234 | 523 |FLOOR-REQUEST-INFORMATION | 524 | Floor Request ID: 789 | 525 | OVERALL-REQUEST-STATUS | 526 | Request Status: Granted | 527 | FLOOR-REQUEST-STATUS | 528 | Floor ID: 543 | 529 |<----------------------------------------------| 530 | | 531 |(5) FloorRelease | 532 |Transaction ID: 154 | 533 |User ID: 234 | 534 |FLOOR-REQUEST-ID: 789 | 535 |---------------------------------------------->| 536 | | 537 |(6) FloorRequestStatus | 538 |Transaction ID: 154 | 539 |User ID: 234 | 540 |FLOOR-REQUEST-INFORMATION | 541 | Floor Request ID: 789 | 542 | OVERALL-REQUEST-STATUS | 543 | Request Status: Released | 544 | FLOOR-REQUEST-STATUS | 545 | Floor ID: 543 | 546 |<----------------------------------------------| 548 Figure 2: Requesting and releasing a floor 550 Figure 3 shows how a floor participant requests to be informed on the 551 status of a floor. The first FloorStatus message from the floor 552 control server is the response to the FloorQuery message and, as 553 such, has the same Transaction ID as the FloorQuery message. 555 Subsequent FloorStatus messages consist of server-initiated 556 transactions, and therefore their Transaction ID is 0 given this 557 example uses a reliable transport. FloorStatus message (2) indicates 558 that there are currently two floor requests for the floor whose Floor 559 ID is 543. FloorStatus message (3) indicates that the floor requests 560 with Floor Request ID 764 has been granted, and the floor request 561 with Floor Request ID 635 is the first in the queue. FloorStatus 562 message (4) indicates that the floor request with Floor Request ID 563 635 has been granted. 565 Floor Participant Floor Control 566 Server 567 |(1) FloorQuery | 568 |Transaction ID: 257 | 569 |User ID: 234 | 570 |FLOOR-ID: 543 | 571 |---------------------------------------------->| 572 | | 573 |(2) FloorStatus | 574 |Transaction ID: 257 | 575 |User ID: 234 | 576 |FLOOR-ID:543 | 577 |FLOOR-REQUEST-INFORMATION | 578 | Floor Request ID: 764 | 579 | OVERALL-REQUEST-STATUS | 580 | Request Status: Accepted | 581 | Queue Position: 1st | 582 | FLOOR-REQUEST-STATUS | 583 | Floor ID: 543 | 584 | BENEFICIARY-INFORMATION | 585 | Beneficiary ID: 124 | 586 |FLOOR-REQUEST-INFORMATION | 587 | Floor Request ID: 635 | 588 | OVERALL-REQUEST-STATUS | 589 | Request Status: Accepted | 590 | Queue Position: 2nd | 591 | FLOOR-REQUEST-STATUS | 592 | Floor ID: 543 | 593 | BENEFICIARY-INFORMATION | 594 | Beneficiary ID: 154 | 595 |<----------------------------------------------| 596 | | 597 |(3) FloorStatus | 598 |Transaction ID: 0 | 599 |User ID: 234 | 600 |FLOOR-ID:543 | 601 |FLOOR-REQUEST-INFORMATION | 602 | Floor Request ID: 764 | 603 | OVERALL-REQUEST-STATUS | 604 | Request Status: Granted | 605 | FLOOR-REQUEST-STATUS | 606 | Floor ID: 543 | 607 | BENEFICIARY-INFORMATION | 608 | Beneficiary ID: 124 | 609 |FLOOR-REQUEST-INFORMATION | 610 | Floor Request ID: 635 | 611 | OVERALL-REQUEST-STATUS | 612 | Request Status: Accepted | 613 | Queue Position: 1st | 614 | FLOOR-REQUEST-STATUS | 615 | Floor ID: 543 | 616 | BENEFICIARY-INFORMATION | 617 | Beneficiary ID: 154 | 618 |<----------------------------------------------| 619 | | 620 |(4) FloorStatus | 621 |Transaction ID: 0 | 622 |User ID: 234 | 623 |FLOOR-ID:543 | 624 |FLOOR-REQUEST-INFORMATION | 625 | Floor Request ID: 635 | 626 | OVERALL-REQUEST-STATUS | 627 | Request Status: Granted | 628 | FLOOR-REQUEST-STATUS | 629 | Floor ID: 543 | 630 | BENEFICIARY-INFORMATION | 631 | Beneficiary ID: 154 | 632 |<----------------------------------------------| 634 Figure 3: Obtaining status information about a floor 636 FloorStatus messages contain information about the floor requests 637 they carry. For example, FloorStatus message (4) indicates that the 638 floor request with Floor Request ID 635 has as the beneficiary (i.e., 639 the participant that holds the floor when a particular floor request 640 is granted) the participant whose User ID is 154. The floor request 641 applies only to the floor whose Floor ID is 543. That is, this is 642 not a multi-floor floor request. 644 A multi-floor floor request applies to more than one floor (e.g., 645 a participant wants to be able to speak and write on the 646 whiteboard at the same time). The floor control server treats a 647 multi-floor floor request as an atomic package. That is, the 648 floor control server either grants the request for all floors or 649 denies the request for all floors. 651 4.2. Floor Chair to Floor Control Server Interface 653 Figure 4 shows a floor chair instructing a floor control server to 654 grant a floor. 656 Note, however, that although the floor control server needs to 657 take into consideration the instructions received in ChairAction 658 messages (e.g., granting a floor), it does not necessarily need to 659 perform them exactly as requested by the floor chair. The 660 operation that the floor control server performs depends on the 661 ChairAction message and on the internal state of the floor control 662 server. 664 For example, a floor chair may send a ChairAction message granting a 665 floor that was requested as part of an atomic floor request operation 666 that involved several floors. Even if the chair responsible for one 667 of the floors instructs the floor control server to grant the floor, 668 the floor control server will not grant it until the chairs 669 responsible for the other floors agree to grant them as well. In 670 another example, a floor chair may instruct the floor control server 671 to grant a floor to a participant. The floor control server needs to 672 revoke the floor from its current holder before granting it to the 673 new participant. 675 So, the floor control server is ultimately responsible for keeping a 676 coherent floor state using instructions from floor chairs as input to 677 this state. 679 Floor Chair Floor Control 680 Server 681 |(1) ChairAction | 682 |Transaction ID: 769 | 683 |User ID: 357 | 684 |FLOOR-REQUEST-INFORMATION | 685 | Floor Request ID: 635 | 686 | FLOOR-REQUEST-STATUS | 687 | Floor ID: 543 | 688 | Request Status: Granted | 689 |---------------------------------------------->| 690 | | 691 |(2) ChairActionAck | 692 |Transaction ID: 769 | 693 |User ID: 357 | 694 |<----------------------------------------------| 696 Figure 4: Chair instructing the floor control server 698 5. Packet Format 700 BFCP packets consist of a 12-octet common header followed by 701 attributes. All the protocol values MUST be sent in network byte 702 order. 704 5.1. COMMON-HEADER Format 706 The following is the format of the common header. 708 0 1 2 3 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Ver |R|F| Res | Primitive | Payload Length | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Conference ID | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Transaction ID | User ID | 716 +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | | Fragment Offset (if F is set) | Fragment Length (if F is set) | 718 +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | 720 +---- These fragment fields are never present 721 when using reliable transports 723 Figure 5: COMMON-HEADER format 725 Ver: This 3-bit field defines the version of BFCP that this message 726 adheres to. This specification defines two versions: 1 and 2. The 727 version field MUST be set to 1 when using BFCP over a reliable 728 transport. The version field MUST be set to 2 when using BFCP over 729 an unreliable transport. If a floor control server receives a 730 message with an unsupported version field value or a message with a 731 version number that is not permitted with the transport over which it 732 was received, the server MUST indicate it does not support the 733 protocol version by sending an Error message with parameter value 12 734 (Unsupported Version). Note that BFCP entities supporting only the 735 [3] subset will not support this parameter value. 737 R: The Transaction Responder (R) flag-bit has relevance only for use 738 of BFCP over an unreliable transport. When cleared, it indicates 739 that this message is a request initiating a new transaction, and the 740 Transaction ID that follows has been generated for this transaction. 741 When set, it indicates that this message is a response to a previous 742 request, and the Transaction ID that follows is the one associated 743 with that request. When BFCP is used over a reliable transport, the 744 flag has no significance and MUST be cleared by the sender and MUST 745 be ignored by the receiver. 747 F: The Fragmentation (F) flag-bit has relevance only for use of BFCP 748 over an unreliable transport. When cleared, the message is not 749 fragmented. When set, it indicates that the message is a fragment of 750 a large fragmented BFCP message. (The optional fields Fragment 751 Offset and Fragment Length described below are present only if the F 752 flag is set). When BFCP is used over a reliable transport, the flag 753 has no significance and MUST be cleared by the sender and the flag 754 MUST be ignored by the receiver. In the latter case, the receiver 755 should also process the COMMON-HEADER as not having the Fragment 756 Offset and Fragment Length fields present. 758 Res: The 3 bits in the reserved field MUST be set to zero by the 759 sender of the message and MUST be ignored by the receiver. 761 Primitive: This 8-bit field identifies the main purpose of the 762 message. The following primitive values are defined: 764 +-------+-----------------------+--------------------------+ 765 | Value | Primitive | Direction | 766 +-------+-----------------------+--------------------------+ 767 | 1 | FloorRequest | P -> S | 768 | 2 | FloorRelease | P -> S | 769 | 3 | FloorRequestQuery | P -> S ; Ch -> S | 770 | 4 | FloorRequestStatus | P <- S ; Ch <- S | 771 | 5 | UserQuery | P -> S ; Ch -> S | 772 | 6 | UserStatus | P <- S ; Ch <- S | 773 | 7 | FloorQuery | P -> S ; Ch -> S | 774 | 8 | FloorStatus | P <- S ; Ch <- S | 775 | 9 | ChairAction | Ch -> S | 776 | 10 | ChairActionAck | Ch <- S | 777 | 11 | Hello | P -> S ; Ch -> S | 778 | 12 | HelloAck | P <- S ; Ch <- S | 779 | 13 | Error | P <- S ; Ch <- S | 780 | 14 | FloorRequestStatusAck | P -> S ; Ch -> S | 781 | 15 | FloorStatusAck | P -> S ; Ch -> S | 782 | 16 | Goodbye | P -> S ; Ch -> S ; | 783 | | | P <- S ; Ch <- S | 784 | 17 | GoodbyeAck | P -> S ; Ch -> S ; | 785 | | | P <- S ; Ch <- S | 786 +-------+-----------------------+--------------------------+ 788 S: Floor Control Server / P: Floor Participant / Ch: Floor Chair 790 Table 1: BFCP primitives 792 Payload Length: This 16-bit field contains the length of the message 793 in 4-octet units, excluding the common header. If a Floor Control 794 Server receives a message with an incorrect Payload Length field 795 value, the receiving server MUST send an Error message with parameter 796 value 13 (Incorrect Message Length) to indicate this and then discard 797 the message. Other entities that receive a message with an incorrect 798 length MUST discard the message. 800 Note: BFCP is designed to achieve small message size, as explained 801 in Section 1, and BFCP entities are required to keep the BFCP 802 message size smaller than the size limited by the 16-bit Payload 803 Length field. To convey information not strictly related to floor 804 control, other protocols should be used such as the XCON framework 805 (cf. Section 3). 807 Conference ID: This 32-bit unsigned integer field identifies the 808 conference to which the message belongs. It is RECOMMENDED that the 809 conference identifier be randomly chosen. (Note that the use of 810 predictable conference identifiers in conjunction with a non-secure 811 transport protocol makes BFCP susceptible to off-path data injection 812 attacks, where an attacker can forge a request or response message.) 814 Transaction ID: This field contains a 16-bit value that allows users 815 to match a given message with its response (see Section 8). 817 User ID: This field contains a 16-bit unsigned integer that uniquely 818 identifies a participant within a conference. 820 The identity used by a participant in BFCP, which is carried in 821 the User ID field, is generally mapped to the identity used by the 822 same participant in the session establishment protocol (e.g., in 823 SIP). The way this mapping is performed is outside the scope of 824 this specification. 826 Fragment Offset: This optional field is present only if the F flag is 827 set and contains a 16-bit value that specifies the number of 4-octet 828 units contained in previous fragments, excluding the common header. 830 Fragment Length: This optional field is present only if the F flag is 831 set and contains a 16-bit value that specifies the number of 4-octet 832 units contained in this fragment, excluding the common header. BFCP 833 entities that receive message fragments that, individually or 834 collectively, exceed the Payload Length value MUST discard the 835 message. Additionally, if the receiver is a Floor Control Server, it 836 must also send an Error message with parameter value 13 (Incorrect 837 Message Length) 839 5.2. Attribute Format 841 BFCP attributes are encoded in TLV (Type-Length-Value) format. 842 Attributes are 32-bit aligned. 844 0 1 2 3 845 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 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Type |M| Length | | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 849 | | 850 / Attribute Contents / 851 / / 852 | | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Figure 6: Attribute format 857 Type: This 7-bit field contains the type of the attribute. Each 858 attribute, identified by its type, has a particular format. The 859 attribute formats defined are: 861 Unsigned16: The contents of the attribute consist of a 16-bit 862 unsigned integer. 864 OctetString16: The contents of the attribute consist of 16 bits of 865 arbitrary data. 867 OctetString: The contents of the attribute consist of arbitrary 868 data of variable length. 870 Grouped: The contents of the attribute consist of a sequence of 871 attributes. 873 Note that extension attributes defined in the future may define 874 new attribute formats. 876 The following attribute types are defined: 878 +------+---------------------------+---------------+ 879 | Type | Attribute | Format | 880 +------+---------------------------+---------------+ 881 | 1 | BENEFICIARY-ID | Unsigned16 | 882 | 2 | FLOOR-ID | Unsigned16 | 883 | 3 | FLOOR-REQUEST-ID | Unsigned16 | 884 | 4 | PRIORITY | OctetString16 | 885 | 5 | REQUEST-STATUS | OctetString16 | 886 | 6 | ERROR-CODE | OctetString | 887 | 7 | ERROR-INFO | OctetString | 888 | 8 | PARTICIPANT-PROVIDED-INFO | OctetString | 889 | 9 | STATUS-INFO | OctetString | 890 | 10 | SUPPORTED-ATTRIBUTES | OctetString | 891 | 11 | SUPPORTED-PRIMITIVES | OctetString | 892 | 12 | USER-DISPLAY-NAME | OctetString | 893 | 13 | USER-URI | OctetString | 894 | 14 | BENEFICIARY-INFORMATION | Grouped | 895 | 15 | FLOOR-REQUEST-INFORMATION | Grouped | 896 | 16 | REQUESTED-BY-INFORMATION | Grouped | 897 | 17 | FLOOR-REQUEST-STATUS | Grouped | 898 | 18 | OVERALL-REQUEST-STATUS | Grouped | 899 +------+---------------------------+---------------+ 901 Table 2: BFCP attributes 903 M: The 'M' bit, known as the Mandatory bit, indicates whether support 904 of the attribute is required. If a Floor Control Server receives an 905 unrecognized attribute with the 'M' bit set the server MUST send an 906 Error message with parameter value 4 (Unknown Mandatory Attribute) to 907 indicate this. The 'M' bit is significant for extension attributes 908 defined in other documents only. All attributes specified in this 909 document MUST be understood by the receiver so that the setting of 910 the 'M' bit is irrelevant for these. Unrecognized attributes, such 911 as those that might be specified in future extensions, that do not 912 have the "M" bit set are ignored, but the message is processed. 914 Length: This 8-bit field contains the length of the attribute in 915 octets, excluding any padding defined for specific attributes. The 916 length of attributes that are not grouped includes the Type, 'M' bit, 917 and Length fields. The Length in grouped attributes is the length of 918 the grouped attribute itself (including Type, 'M' bit, and Length 919 fields) plus the total length (including padding) of all the included 920 attributes. 922 Attribute Contents: The contents of the different attributes are 923 defined in the following sections. 925 5.2.1. BENEFICIARY-ID 927 The following is the format of the BENEFICIARY-ID attribute. 929 0 1 2 3 930 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 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 Figure 7: BENEFICIARY-ID format 937 Beneficiary ID: This field contains a 16-bit value that uniquely 938 identifies a user within a conference. 940 Note that although the formats of the Beneficiary ID and of the 941 User ID field in the common header are similar, their semantics 942 are different. The Beneficiary ID is used in third-party floor 943 requests and to request information about a particular 944 participant. 946 5.2.2. FLOOR-ID 948 The following is the format of the FLOOR-ID attribute. 950 0 1 2 3 951 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 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 Figure 8: FLOOR-ID format 958 Floor ID: This field contains a 16-bit value that uniquely identifies 959 a floor within a conference. 961 5.2.3. FLOOR-REQUEST-ID 963 The following is the format of the FLOOR-REQUEST-ID attribute. 965 0 1 2 3 966 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 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 Figure 9: FLOOR-REQUEST-ID format 973 Floor Request ID: This field contains a 16-bit value that identifies 974 a floor request at the floor control server. 976 5.2.4. PRIORITY 978 The following is the format of the PRIORITY attribute. 980 0 1 2 3 981 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 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Figure 10: PRIORITY format 988 Prio: This field contains a 3-bit priority value, as shown in 989 Table 3. Senders SHOULD NOT use values higher than 4 in this field. 990 Receivers MUST treat values higher than 4 as if the value received 991 were 4 (Highest). The default priority value when the PRIORITY 992 attribute is missing is 2 (Normal). 994 +-------+----------+ 995 | Value | Priority | 996 +-------+----------+ 997 | 0 | Lowest | 998 | 1 | Low | 999 | 2 | Normal | 1000 | 3 | High | 1001 | 4 | Highest | 1002 +-------+----------+ 1004 Table 3: Priority values 1006 Reserved: The 13 bits in the reserved field MUST be set to zero by 1007 the sender of the message and MUST be ignored by the receiver. 1009 5.2.5. REQUEST-STATUS 1011 The following is the format of the REQUEST-STATUS attribute. 1013 0 1 2 3 1014 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 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 Figure 11: REQUEST-STATUS format 1021 Request Status: This 8-bit field contains the status of the request, 1022 as described in the following table. 1024 +-------+-----------+ 1025 | Value | Status | 1026 +-------+-----------+ 1027 | 1 | Pending | 1028 | 2 | Accepted | 1029 | 3 | Granted | 1030 | 4 | Denied | 1031 | 5 | Cancelled | 1032 | 6 | Released | 1033 | 7 | Revoked | 1034 +-------+-----------+ 1036 Table 4: Request Status values 1038 Queue Position: This 8-bit field contains, when applicable, the 1039 position of the floor request in the floor request queue at the 1040 server. If the Request Status value is different from Accepted, if 1041 the floor control server does not implement a floor request queue, or 1042 if the floor control server does not want to provide the client with 1043 this information, all the bits of this field SHOULD be set to zero. 1045 A floor request is in Pending state if the floor control server needs 1046 to contact a floor chair in order to accept the floor request, but 1047 has not done it yet. Once the floor control chair accepts the floor 1048 request, the floor request is moved to the Accepted state. 1050 5.2.6. ERROR-CODE 1052 The following is the format of the ERROR-CODE attribute. 1054 0 1 2 3 1055 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 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 |0 0 0 0 1 1 0|M| Length | Error Code | | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1059 | | 1060 | Error Specific Details | 1061 / / 1062 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | | Padding | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 Figure 12: ERROR-CODE format 1068 Error Code: This 8-bit field contains an error code from the 1069 following table. If an error code is not recognized by the receiver, 1070 then the receiver MUST assume that an error exists, and therefore 1071 that the original message that triggered the Error message to be sent 1072 is processed, but the nature of the error is unclear. 1074 +-------+-----------------------------------------------------------+ 1075 | Value | Meaning | 1076 +-------+-----------------------------------------------------------+ 1077 | 1 | Conference does not Exist | 1078 | 2 | User does not Exist | 1079 | 3 | Unknown Primitive | 1080 | 4 | Unknown Mandatory Attribute | 1081 | 5 | Unauthorized Operation | 1082 | 6 | Invalid Floor ID | 1083 | 7 | Floor Request ID Does Not Exist | 1084 | 8 | You have Already Reached the Maximum Number of Ongoing | 1085 | | Floor Requests for this Floor | 1086 | 9 | Use TLS | 1087 | 10 | Unable to Parse Message | 1088 | 11 | Use DTLS | 1089 | 12 | Unsupported Version | 1090 | 13 | Incorrect Message Length | 1091 | 14 | Generic Error | 1092 +-------+-----------------------------------------------------------+ 1094 Table 5: Error Code meaning 1096 Note: The Generic Error error code is intended to be used when an 1097 error occurs and the other specific error codes do not apply. 1099 Error Specific Details: Present only for certain Error Codes. In 1100 this document, only for Error Code 4 (Unknown Mandatory Attribute). 1101 See Section 5.2.6.1 for its definition. 1103 Padding: One, two, or three octets of padding added so that the 1104 contents of the ERROR-CODE attribute is 32-bit aligned. If the 1105 attribute is already 32-bit aligned, no padding is needed. 1107 The Padding bits MUST be set to zero by the sender and MUST be 1108 ignored by the receiver. 1110 5.2.6.1. Error-Specific Details for Error Code 4 1112 The following is the format of the Error-Specific Details field for 1113 Error Code 4. 1115 0 1 2 3 1116 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 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | | 1121 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | | Unknown Type|R| Unknown Type|R| 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Unknown Type|R| Unknown Type|R| 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 Figure 13: Unknown attributes format 1129 Unknown Type: These 7-bit fields contain the Types of the attributes 1130 (which were present in the message that triggered the Error message) 1131 that were unknown to the receiver. 1133 R: This bit is reserved. It MUST be set to zero by the sender of the 1134 message and MUST be ignored by the receiver. 1136 5.2.7. ERROR-INFO 1138 The following is the format of the ERROR-INFO attribute. 1140 0 1 2 3 1141 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 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 |0 0 0 0 1 1 1|M| Length | | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1145 | | 1146 / Text / 1147 / +-+-+-+-+-+-+-+-+ 1148 | | Padding | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 Figure 14: ERROR-INFO format 1153 Text: This field contains UTF-8 [9] encoded text. 1155 In some situations, the contents of the Text field may be generated 1156 by an automaton. If this automaton has information about the 1157 preferred language of the receiver of a particular ERROR-INFO 1158 attribute, it MAY use this language to generate the Text field. 1160 Padding: One, two, or three octets of padding added so that the 1161 contents of the ERROR-INFO attribute is 32-bit aligned. The Padding 1162 bits MUST be set to zero by the sender and MUST be ignored by the 1163 receiver. If the attribute is already 32-bit aligned, no padding is 1164 needed. 1166 5.2.8. PARTICIPANT-PROVIDED-INFO 1168 The following is the format of the PARTICIPANT-PROVIDED-INFO 1169 attribute. 1171 0 1 2 3 1172 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 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 |0 0 0 1 0 0 0|M| Length | | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1176 | | 1177 / Text / 1178 / +-+-+-+-+-+-+-+-+ 1179 | | Padding | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 Figure 15: PARTICIPANT-PROVIDED-INFO format 1184 Text: This field contains UTF-8 [9] encoded text. 1186 Padding: One, two, or three octets of padding added so that the 1187 contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit 1188 aligned. The Padding bits MUST be set to zero by the sender and MUST 1189 be ignored by the receiver. If the attribute is already 32-bit 1190 aligned, no padding is needed. 1192 5.2.9. STATUS-INFO 1194 The following is the format of the STATUS-INFO attribute. 1196 0 1 2 3 1197 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 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 |0 0 0 1 0 0 1|M| Length | | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1201 | | 1202 / Text / 1203 / +-+-+-+-+-+-+-+-+ 1204 | | Padding | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 Figure 16: STATUS-INFO format 1209 Text: This field contains UTF-8 [9] encoded text. 1211 In some situations, the contents of the Text field may be generated 1212 by an automaton. If this automaton has information about the 1213 preferred language of the receiver of a particular STATUS-INFO 1214 attribute, it MAY use this language to generate the Text field. 1216 Padding: One, two, or three octets of padding added so that the 1217 contents of the STATUS-INFO attribute is 32-bit aligned. The Padding 1218 bits MUST be set to zero by the sender and MUST be ignored by the 1219 receiver. If the attribute is already 32-bit aligned, no padding is 1220 needed. 1222 5.2.10. SUPPORTED-ATTRIBUTES 1224 The following is the format of the SUPPORTED-ATTRIBUTES attribute. 1226 0 1 2 3 1227 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 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 |0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R| 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | | 1234 / / 1235 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | | Padding | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 Figure 17: SUPPORTED-ATTRIBUTES format 1241 Supp. Attr.: These fields contain the Types of the attributes that 1242 are supported by the floor control server in the following format: 1244 R: Reserved: This bit MUST be set to zero upon transmission and MUST 1245 be ignored upon reception. 1247 Padding: One, two, or three octets of padding added so that the 1248 contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If 1249 the attribute is already 32-bit aligned, no padding is needed. 1251 The Padding bits MUST be set to zero by the sender and MUST be 1252 ignored by the receiver. 1254 5.2.11. SUPPORTED-PRIMITIVES 1256 The following is the format of the SUPPORTED-PRIMITIVES attribute. 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 |0 0 0 1 0 1 1|M| Length | Primitive | Primitive | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Primitive | Primitive | Primitive | Primitive | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | | 1266 / / 1267 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | | Padding | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 Figure 18: SUPPORTED-PRIMITIVES format 1273 Primitive: These fields contain the types of the BFCP messages that 1274 are supported by the floor control server. See Table 1 for the list 1275 of BFCP primitives. 1277 Padding: One, two, or three octets of padding added so that the 1278 contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If 1279 the attribute is already 32-bit aligned, no padding is needed. 1281 The Padding bits MUST be set to zero by the sender and MUST be 1282 ignored by the receiver. 1284 5.2.12. USER-DISPLAY-NAME 1286 The following is the format of the USER-DISPLAY-NAME attribute. 1288 0 1 2 3 1289 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 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 |0 0 0 1 1 0 0|M| Length | | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1293 | | 1294 / Text / 1295 / +-+-+-+-+-+-+-+-+ 1296 | | Padding | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 Figure 19: USER-DISPLAY-NAME format 1301 Text: This field contains the UTF-8 encoded name of the user. 1303 Padding: One, two, or three octets of padding added so that the 1304 contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The 1305 Padding bits MUST be set to zero by the sender and MUST be ignored by 1306 the receiver. If the attribute is already 32-bit aligned, no padding 1307 is needed. 1309 5.2.13. USER-URI 1311 The following is the format of the USER-URI attribute. 1313 0 1 2 3 1314 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 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 |0 0 0 1 1 0 1|M| Length | | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1318 | | 1319 / Text / 1320 / +-+-+-+-+-+-+-+-+ 1321 | | Padding | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 Figure 20: USER-URI format 1326 Text: This field contains the UTF-8 encoded user's contact URI, that 1327 is, the URI used by the user to set up the resources (e.g., media 1328 streams) that are controlled by BFCP. For example, in the context of 1329 a conference set up by SIP, the USER-URI attribute would carry the 1330 SIP URI of the user. 1332 Messages containing a user's URI in a USER-URI attribute also 1333 contain the user's User ID. This way, a client receiving such a 1334 message can correlate the user's URI (e.g., the SIP URI the user 1335 used to join a conference) with the user's User ID. 1337 Padding: One, two, or three octets of padding added so that the 1338 contents of the USER-URI attribute is 32-bit aligned. The Padding 1339 bits MUST be set to zero by the sender and MUST be ignored by the 1340 receiver. If the attribute is already 32-bit aligned, no padding is 1341 needed. 1343 5.2.14. BENEFICIARY-INFORMATION 1345 The BENEFICIARY-INFORMATION attribute is a grouped attribute that 1346 consists of a header, which is referred to as BENEFICIARY- 1347 INFORMATION-HEADER, followed by a sequence of attributes. The 1348 following is the format of the BENEFICIARY-INFORMATION-HEADER: 1350 0 1 2 3 1351 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 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 |0 0 0 1 1 1 0|M| Length | Beneficiary ID | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 Figure 21: BENEFICIARY-INFORMATION-HEADER format 1358 Beneficiary ID: This field contains a 16-bit value that uniquely 1359 identifies a user within a conference. 1361 The following is the ABNF (Augmented Backus-Naur Form) [5] of the 1362 BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE 1363 refers to extension attributes that may be defined in the future.) 1365 BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER 1366 [USER-DISPLAY-NAME] 1367 [USER-URI] 1368 *EXTENSION-ATTRIBUTE 1370 Figure 22: BENEFICIARY-INFORMATION format 1372 5.2.15. FLOOR-REQUEST-INFORMATION 1374 The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that 1375 consists of a header, which is referred to as FLOOR-REQUEST- 1376 INFORMATION-HEADER, followed by a sequence of attributes. The 1377 following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: 1379 0 1 2 3 1380 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 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 |0 0 0 1 1 1 1|M| Length | Floor Request ID | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format 1387 Floor Request ID: This field contains a 16-bit value that identifies 1388 a floor request at the floor control server. 1390 The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped 1391 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1392 may be defined in the future.) 1393 FLOOR-REQUEST-INFORMATION = FLOOR-REQUEST-INFORMATION-HEADER 1394 [OVERALL-REQUEST-STATUS] 1395 1*FLOOR-REQUEST-STATUS 1396 [BENEFICIARY-INFORMATION] 1397 [REQUESTED-BY-INFORMATION] 1398 [PRIORITY] 1399 [PARTICIPANT-PROVIDED-INFO] 1400 *EXTENSION-ATTRIBUTE 1402 Figure 24: FLOOR-REQUEST-INFORMATION format 1404 5.2.16. REQUESTED-BY-INFORMATION 1406 The REQUESTED-BY-INFORMATION attribute is a grouped attribute that 1407 consists of a header, which is referred to as REQUESTED-BY- 1408 INFORMATION-HEADER, followed by a sequence of attributes. The 1409 following is the format of the REQUESTED-BY-INFORMATION-HEADER: 1411 0 1 2 3 1412 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 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 |0 0 1 0 0 0 0|M| Length | Requested-by ID | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 Figure 25: REQUESTED-BY-INFORMATION-HEADER format 1419 Requested-by ID: This field contains a 16-bit value that uniquely 1420 identifies a user within a conference. 1422 The following is the ABNF of the REQUESTED-BY-INFORMATION grouped 1423 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1424 may be defined in the future.) 1426 REQUESTED-BY-INFORMATION = REQUESTED-BY-INFORMATION-HEADER 1427 [USER-DISPLAY-NAME] 1428 [USER-URI] 1429 *EXTENSION-ATTRIBUTE 1431 Figure 26: REQUESTED-BY-INFORMATION format 1433 5.2.17. FLOOR-REQUEST-STATUS 1435 The FLOOR-REQUEST-STATUS attribute is a grouped attribute that 1436 consists of a header, which is referred to as FLOOR-REQUEST-STATUS- 1437 HEADER, followed by a sequence of attributes. The following is the 1438 format of the FLOOR-REQUEST-STATUS-HEADER: 1440 0 1 2 3 1441 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 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 |0 0 1 0 0 0 1|M| Length | Floor ID | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 Figure 27: FLOOR-REQUEST-STATUS-HEADER format 1448 Floor ID: this field contains a 16-bit value that uniquely identifies 1449 a floor within a conference. 1451 The following is the ABNF of the FLOOR-REQUEST-STATUS grouped 1452 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1453 may be defined in the future.) 1455 FLOOR-REQUEST-STATUS = FLOOR-REQUEST-STATUS-HEADER 1456 [REQUEST-STATUS] 1457 [STATUS-INFO] 1458 *EXTENSION-ATTRIBUTE 1460 Figure 28: FLOOR-REQUEST-STATUS format 1462 5.2.18. OVERALL-REQUEST-STATUS 1464 The OVERALL-REQUEST-STATUS attribute is a grouped attribute that 1465 consists of a header, which is referred to as OVERALL-REQUEST-STATUS- 1466 HEADER, followed by a sequence of attributes. The following is the 1467 format of the OVERALL-REQUEST-STATUS-HEADER: 1469 0 1 2 3 1470 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 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 |0 0 1 0 0 1 0|M| Length | Floor Request ID | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 Figure 29: OVERALL-REQUEST-STATUS-HEADER format 1477 Floor Request ID: this field contains a 16-bit value that identifies 1478 a floor request at the floor control server. 1480 The following is the ABNF of the OVERALL-REQUEST-STATUS grouped 1481 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1482 may be defined in the future.) 1483 OVERALL-REQUEST-STATUS = OVERALL-REQUEST-STATUS-HEADER 1484 [REQUEST-STATUS] 1485 [STATUS-INFO] 1486 *EXTENSION-ATTRIBUTE 1488 Figure 30: OVERALL-REQUEST-STATUS format 1490 5.3. Message Format 1492 This section contains the normative ABNF (Augmented Backus-Naur Form) 1493 [5] of the BFCP messages. Extension attributes that may be defined 1494 in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. 1496 5.3.1. FloorRequest 1498 Floor participants request a floor by sending a FloorRequest message 1499 to the floor control server. The following is the format of the 1500 FloorRequest message: 1502 FloorRequest = COMMON-HEADER 1503 1*FLOOR-ID 1504 [BENEFICIARY-ID] 1505 [PARTICIPANT-PROVIDED-INFO] 1506 [PRIORITY] 1507 *EXTENSION-ATTRIBUTE 1509 Figure 31: FloorRequest format 1511 5.3.2. FloorRelease 1513 Floor participants release a floor by sending a FloorRelease message 1514 to the floor control server. Floor participants also use the 1515 FloorRelease message to cancel pending floor requests. The following 1516 is the format of the FloorRelease message: 1518 FloorRelease = COMMON-HEADER 1519 FLOOR-REQUEST-ID 1520 *EXTENSION-ATTRIBUTE 1522 Figure 32: FloorRelease format 1524 5.3.3. FloorRequestQuery 1526 Floor participants and floor chairs request information about a floor 1527 request by sending a FloorRequestQuery message to the floor control 1528 server. The following is the format of the FloorRequestQuery 1529 message: 1531 FloorRequestQuery = COMMON-HEADER 1532 FLOOR-REQUEST-ID 1533 *EXTENSION-ATTRIBUTE 1535 Figure 33: FloorRequestQuery format 1537 5.3.4. FloorRequestStatus 1539 The floor control server informs floor participants and floor chairs 1540 about the status of their floor requests by sending them 1541 FloorRequestStatus messages. The following is the format of the 1542 FloorRequestStatus message: 1544 FloorRequestStatus = COMMON-HEADER 1545 FLOOR-REQUEST-INFORMATION 1546 *EXTENSION-ATTRIBUTE 1548 Figure 34: FloorRequestStatus format 1550 5.3.5. UserQuery 1552 Floor participants and floor chairs request information about a 1553 participant and the floor requests related to this participant by 1554 sending a UserQuery message to the floor control server. The 1555 following is the format of the UserQuery message: 1557 UserQuery = COMMON-HEADER 1558 [BENEFICIARY-ID] 1559 *EXTENSION-ATTRIBUTE 1561 Figure 35: UserQuery format 1563 5.3.6. UserStatus 1565 The floor control server provides information about participants and 1566 their related floor requests to floor participants and floor chairs 1567 by sending them UserStatus messages. The following is the format of 1568 the UserStatus message: 1570 UserStatus = COMMON-HEADER 1571 [BENEFICIARY-INFORMATION] 1572 *FLOOR-REQUEST-INFORMATION 1573 *EXTENSION-ATTRIBUTE 1575 Figure 36: UserStatus format 1577 5.3.7. FloorQuery 1579 Floor participants and floor chairs request information about a floor 1580 or floors by sending a FloorQuery message to the floor control 1581 server. The following is the format of the FloorQuery message: 1583 FloorQuery = COMMON-HEADER 1584 *FLOOR-ID 1585 *EXTENSION-ATTRIBUTE 1587 Figure 37: FloorQuery format 1589 5.3.8. FloorStatus 1591 The floor control server informs floor participants and floor chairs 1592 about the status (e.g., the current holder) of a floor by sending 1593 them FloorStatus messages. The following is the format of the 1594 FloorStatus message: 1596 FloorStatus = COMMON-HEADER 1597 *FLOOR-ID 1598 *FLOOR-REQUEST-INFORMATION 1599 *EXTENSION-ATTRIBUTE 1601 Figure 38: FloorStatus format 1603 5.3.9. ChairAction 1605 Floor chairs send instructions to floor control servers by sending 1606 them ChairAction messages. The following is the format of the 1607 ChairAction message: 1609 ChairAction = COMMON-HEADER 1610 FLOOR-REQUEST-INFORMATION 1611 *EXTENSION-ATTRIBUTE 1613 Figure 39: ChairAction format 1615 5.3.10. ChairActionAck 1617 Floor control servers confirm that they have accepted a ChairAction 1618 message by sending a ChairActionAck message. The following is the 1619 format of the ChairActionAck message: 1621 ChairActionAck = COMMON-HEADER 1622 *EXTENSION-ATTRIBUTE 1624 Figure 40: ChairActionAck format 1626 5.3.11. Hello 1628 Floor participants and floor chairs MAY check the liveliness of floor 1629 control servers by sending a Hello message. Additionally, clients 1630 communicating with a floor control server over a an unreliable 1631 transport use the Hello message to initiate communication with the 1632 server. The following is the format of the Hello message: 1634 Hello = COMMON-HEADER 1635 *EXTENSION-ATTRIBUTE 1637 Figure 41: Hello format 1639 5.3.12. HelloAck 1641 Floor control servers confirm that they are alive on reception of a 1642 Hello message by sending a HelloAck message. The following is the 1643 format of the HelloAck message: 1645 HelloAck = COMMON-HEADER 1646 SUPPORTED-PRIMITIVES 1647 SUPPORTED-ATTRIBUTES 1648 *EXTENSION-ATTRIBUTE 1650 Figure 42: HelloAck format 1652 5.3.13. Error 1654 Floor control servers inform floor participants and floor chairs 1655 about errors processing requests by sending them Error messages. The 1656 following is the format of the Error message: 1658 Error = COMMON-HEADER 1659 ERROR-CODE 1660 [ERROR-INFO] 1661 *EXTENSION-ATTRIBUTE 1663 Figure 43: Error format 1665 5.3.14. FloorRequestStatusAck 1667 When communicating over an unreliable transport, floor participants 1668 and chairs acknowledge the receipt of a subsequent FloorRequestStatus 1669 message from the floor control server (cf. Section 13.1.2) by 1670 sending a FloorRequestStatusAck message. The following is the format 1671 of the FloorRequestStatusAck message: 1673 FloorRequestStatusAck = (COMMON-HEADER) 1674 *EXTENSION-ATTRIBUTE 1676 Figure 44: FloorRequestStatusAck format 1678 5.3.15. FloorStatusAck 1680 When communicating over an unreliable transport, floor participants 1681 and chairs acknowledge the receipt of a subsequent FloorStatus 1682 message from the floor control server (cf. Section 13.5.2) by 1683 sending a FloorStatusAck message. The following is the format of the 1684 FloorStatusAck message: 1686 FloorStatusAck = (COMMON-HEADER) 1687 *EXTENSION-ATTRIBUTE 1689 Figure 45: FloorStatusAck format 1691 5.3.16. Goodbye 1693 BFCP entities communicating over an unreliable transport that wish to 1694 dissociate themselves from their remote participant do so through the 1695 transmission of a Goodbye. The following is the format of the 1696 Goodbye message: 1698 Goodbye = (COMMON-HEADER) 1699 *EXTENSION-ATTRIBUTE 1701 Figure 46: Goodbye format 1703 5.3.17. GoodbyeAck 1705 BFCP entities communicating over an unreliable transport acknowledge 1706 the receipt of a Goodbye message from a peer. The following is the 1707 format of the GoodbyeAck message: 1709 GoodbyeAck = (COMMON-HEADER) 1710 *EXTENSION-ATTRIBUTE 1712 Figure 47: GoodbyeAck format 1714 6. Transport 1716 The transport over which BFCP entities exchange messages depends on 1717 the information the clients obtain for how to to contact the floor 1718 control server, as described in Section 3.2. Two transports are 1719 supported: TCP, appropriate where connectivity is not impeded by 1720 network elements such as NAT devices or media relays; and UDP for 1721 those deployments where TCP may not be applicable or appropriate. 1723 Informational note: In practice, products are configured to try 1724 one transport first and use the other transport as a fallback. 1725 Whether TCP or UDP is chosen as underlying transport depends on 1726 the type of product and the deployment environment. See 1727 Appendix B for additional considerations. 1729 6.1. Reliable Transport 1731 BFCP entities may elect to exchange BFCP messages using TCP 1732 connections. TCP provides an in-order reliable delivery of a stream 1733 of bytes. Consequently, message framing needs to be implemented in 1734 the application layer. BFCP implements application-layer framing 1735 using TLV-encoded attributes. 1737 A client MUST NOT use more than one TCP connection to communicate 1738 with a given floor control server within a conference. Nevertheless, 1739 if the same physical box handles different clients (e.g., a floor 1740 chair and a floor participant), which are identified by different 1741 User IDs, a separate connection per client is allowed. 1743 If a BFCP entity (a client or a floor control server) receives data 1744 that cannot be parsed, the entity MUST close the TCP connection, and 1745 the connection SHOULD be reestablished. Similarly, if a TCP 1746 connection cannot deliver a BFCP message and times out or receives an 1747 ICMP port unreachable message mid-connection, the TCP connection 1748 SHOULD be reestablished. 1750 The way connection reestablishment is handled depends on how the 1751 client obtains information to contact the floor control server. Once 1752 the TCP connection is reestablished, the client MAY resend those 1753 messages for which it did not get a response from the floor control 1754 server. 1756 If a floor control server detects that the TCP connection towards one 1757 of the floor participants is lost, it is up to the local policy of 1758 the floor control server what to do with the pending floor requests 1759 of the floor participant. In any case, it is RECOMMENDED that the 1760 floor control server keep the floor requests (i.e., that it does not 1761 cancel them) while the TCP connection is reestablished. 1763 If a client wishes to end its BFCP connection with a floor control 1764 server, the client closes (i.e., a graceful close) the TCP connection 1765 towards the floor control server. If a floor control server wishes 1766 to end its BFCP connection with a client (e.g., the Focus of the 1767 conference informs the floor control server that the client has been 1768 kicked out from the conference), the floor control server closes 1769 (i.e., a graceful close) the TCP connection towards the client. 1771 In cases where a BFCP entity reestablishes a connection due to 1772 protocol errors as described above, the entity SHOULD NOT repeatedly 1773 reestablish the connection. Rather, if the same protocol errors 1774 persist, the entity MUST cease attempts and SHOULD report the error 1775 to the human user and/or log the event. This does not preclude the 1776 entity from reestablishing a connection when facing a different set 1777 of errors. That said, entities MUST avoid overloading the server 1778 with reestablishment requests. A connection MUST NOT be 1779 reestablished too frequently. The frequency is a matter of 1780 implementation, but SHOULD NOT be attempted more than once in a 30 1781 second period of time. 1783 6.2. Unreliable Transport 1785 BFCP entities may elect to exchange BFCP messages using UDP 1786 datagrams. UDP is an unreliable transport where neither delivery nor 1787 ordering is assured. Each BFCP UDP datagram MUST contain exactly one 1788 BFCP message or message fragment. To keep large BFCP messages from 1789 being fragmented at the IP layer, the fragmentation of BFCP messages 1790 that exceed the path MTU size is performed at the BFCP level. 1791 Considerations related to fragmentation are covered in Section 6.2.3. 1792 The message format for BFCP messages is the same regardless of 1793 whether the messages are sent in UDP datagrams or over a TCP stream. 1795 Clients MUST announce their presence to the floor control server by 1796 sending a Hello message. The floor control server responds to the 1797 Hello message with a HelloAck message. The client considers the 1798 floor control service as present and available only upon receiving 1799 the HelloAck message. The behavior when timers fire, including the 1800 determination that a connection is broken, is described in 1801 Section 8.3. 1803 As described in Section 8, each request sent by a floor participant 1804 or chair forms a client transaction that expects an acknowledgement 1805 message back from the floor control server within a transaction 1806 failure window. Concordantly, messages sent by the floor control 1807 server that initiate new transactions (e.g., FloorStatus 1808 announcements as part of a FloorQuery subscription) require 1809 acknowledgement messages from the floor participant and chair 1810 entities to which they were sent. 1812 If a Floor Control Server receives data that cannot be parsed, the 1813 receiving server MUST send an Error message with parameter value 10 1814 (Unable to parse message) indicating receipt of a malformed message, 1815 given that it is possible to parse the received message to such an 1816 extent that an Error message may be built. 1818 Entities MUST have at most one outstanding request transaction per 1819 peer at any one time. Implicit subscriptions occur for a client- 1820 initiated request transaction whose acknowledgement is implied by the 1821 first server-initiated response for that transaction, followed by 1822 zero of more subsequent server-initiated messages corresponding to 1823 the same transaction. An example is a FloorRequest message for which 1824 there are potentially multiple responses from the floor control 1825 server as it processes intermediate states until a terminal state 1826 (e.g., Granted or Denied) is attained. The subsequent changes in 1827 state for the request are new transactions whose Transaction ID is 1828 determined by the floor control server and whose receipt by the 1829 client participant is acknowledged with a FloorRequestStatusAck 1830 message. 1832 By restricting entities to having at most one pending transaction 1833 open in a BFCP connection, both the out-of-order receipt of messages 1834 as well as the possibility for congestion are mitigated. Additional 1835 details regarding congestion control are provided in Section 6.2.1. 1836 A server-initiated request (e.g., a FloorStatus with an update from 1837 the floor control server) received by a participant before the 1838 initial FloorRequestStatus message that closes the client-initiated 1839 transaction that was instigated by the FloorRequest MUST be treated 1840 as superseding the information conveyed in any such late arriving 1841 response. As the floor control server cannot send a second update to 1842 the implicit floor status subscription until the first is 1843 acknowledged, ordinality is maintained. 1845 If a client wishes to end its BFCP connection with a floor control 1846 server, it is REQUIRED that the client send a Goodbye message to 1847 dissociate itself from any allocated resources. If a floor control 1848 server wishes to end its BFCP connection with a client (e.g., the 1849 Focus of the conference informs the floor control server that the 1850 client has been kicked out from the conference), it is REQUIRED that 1851 the floor control server send a Goodbye message towards the client. 1853 6.2.1. Congestion Control 1855 BFCP may be characterized to generate "low data-volume" traffic, per 1856 the classification in [13]. Nevertheless is it necessary to ensure 1857 suitable and necessary congestion control mechanisms are used for 1858 BFCP over UDP. As described in Section 6.2, within the same BFCP 1859 connection, every entity - client or server - is only allowed to send 1860 one request at a time, and await the acknowledging response. This 1861 way at most one datagram is sent per RTT given the message is not 1862 lost during transmission. In case the message is lost, the request 1863 retransmission timer T1 specified in Section 8.3.1 will fire and the 1864 message is retransmitted up to three times, in addition to the 1865 original transmission of the message. The default initial interval 1866 MUST be set to 500ms, but is adjusted dynamically as described in 1867 Section 8.3.1. The interval MUST be doubled after each 1868 retransmission attempt. This is similar to the specification of the 1869 timer A and its initial value T1 in SIP as described in 1870 Section 17.1.1.2 of [18], except that the value of T1 in this 1871 protocol is not fixed from one transaction to another. 1873 6.2.2. ICMP Error Handling 1875 ICMP is not usable when BFCP is running over an unreliable transport 1876 due to risks associated with off-path attacks. Any ICMP messages 1877 associated with BFCP running over an unreliable transport MUST be 1878 ignored. 1880 6.2.3. Fragmentation Handling 1882 When using UDP, a single BFCP message could be fragmented at the IP 1883 layer if its overall size exceeds the path MTU of the network. To 1884 avoid this happening at the IP layer, a fragmentation scheme for BFCP 1885 is defined below. 1887 BFCP is designed for achieving small message size, due to the binary 1888 encoding as described in Section 1. The fragmentation scheme is 1889 therefore deliberately kept simple and straightforward, since the 1890 probability of fragmentation of BFCP messages being required is 1891 small. By design, the fragmentation scheme does not acknowledge 1892 individual BFCP message fragments. The whole BFCP message is 1893 acknowledged if received completely. 1895 BFCP entities SHOULD consider the path MTU size available between the 1896 sender and the receiver and MAY run MTU discovery, such as 1897 [23][24][25], for this purpose. 1899 When transmitting a BFCP message with size greater than the path MTU, 1900 the sender MUST fragment the message into a series of N contiguous 1901 data ranges. The size of each of these N messages MUST be smaller 1902 than the path MTU to help prevent fragmentation overlap attacks. The 1903 value for N is defined as ceil((message size - COMMON-HEADER size) / 1904 (path MTU size - COMMON-HEADER size)), where ceil is the integer 1905 ceiling function and the COMMON-HEADER size includes the Fragment 1906 Offset and Fragment Length fields. The sender then creates N BFCP 1907 fragment messages (one for each data range) with the same Transaction 1908 ID. The size of each of these N messages, with the COMMON-HEADER 1909 included, MUST be smaller than the path MTU. The F flag in the 1910 COMMON-HEADER in all the fragments is set to indicate fragmentation 1911 of the BFCP message. 1913 For each of these fragments the Fragment Offset and Fragment Length 1914 fields are included in the COMMON-HEADER. The Fragment Offset field 1915 denotes the number of 4-octet units contained in the previous 1916 fragments, excluding the common header. The Fragment Length contains 1917 the length of the fragment itself, also excluding the common header. 1918 Note that the Payload Length field contains the length of the entire, 1919 unfragmented message. 1921 When a BFCP implementation receives a BFCP message fragment, it MUST 1922 buffer the fragment until either it has received the entire BFCP 1923 message, or until the Response Retransmission Timer expires. The 1924 state machine should handle the BFCP message only after all the 1925 fragments for the message have been received. 1927 If a fragment of a BFCP message is lost, the sender will not receive 1928 an acknowledgement for the message. Therefore the sender will 1929 retransmit the message with same transaction ID as specified in 1930 Section 8.3. If the acknowledgement message sent by the receiver is 1931 lost, then the entire message will be resent by the sender. The 1932 receiver MUST then retransmit the acknowledgement. The receiver MAY 1933 discard an incomplete buffer utilizing the Response Retransmission 1934 Timer, starting the timer after the receipt of the first fragment. 1936 A Denial of Service (DoS) attack utilizing the fragmentation 1937 scheme described above is mitigated by the fact that the Response 1938 Retransmission Timer is started after receipt of the first BFCP 1939 message fragment. In addition, the Payload Length field can be 1940 compared with the Fragment Offset and Fragment Length fields to 1941 verify the message fragments as they arrive. To make DoS attacks 1942 with spoofed IP addresses difficult, BFCP entities SHOULD use the 1943 cookie exchange mechanism in DTLS [8]. 1945 When deciding message fragment size based on path MTU, the BFCP 1946 fragmentation handling should take into account how the DTLS record 1947 framing expands the datagram size as described in Section 4.1.1.1 of 1948 [8]. 1950 6.2.4. NAT Traversal 1952 One of the key benefits when using UDP for BFCP communication is the 1953 ability to leverage the existing NAT traversal infrastructure and 1954 strategies deployed to facilitate transport of the media associated 1955 with the video conferencing sessions. Depending on the given 1956 deployment, this infrastructure typically includes some subset of ICE 1957 [17]. 1959 In order to facilitate the initial establishment of NAT bindings, and 1960 to maintain those bindings once established, BFCP entities using an 1961 unreliable transport are RECOMMENDED to use STUN [12] Binding 1962 Indication for keep-alives, as described for ICE [17]. Section 6.7 1963 of [26] provides useful recommendations for middlebox interaction 1964 when DTLS is used. 1966 Informational note: Since the version number is set to 2 when BFCP 1967 is used over an unreliable transport, cf. the Ver field in 1968 Section 5.1, it is straight forward to distinguish between STUN 1969 and BFCP packets even without checking the STUN magic cookie [12]. 1971 In order to facilitate traversal of BFCP packets through NATs, BFCP 1972 entities using an unreliable transport are RECOMMENDED to use 1973 symmetric ports for sending and receiving BFCP packets, as 1974 recommended for RTP/RTCP [11]. 1976 7. Lower-Layer Security 1978 BFCP relies on lower-layer security mechanisms to provide replay and 1979 integrity protection and confidentiality. BFCP floor control servers 1980 and clients (which include both floor participants and floor chairs) 1981 MUST support TLS for transport over TCP [7] and MUST support DTLS [8] 1982 for transport over UDP. Any BFCP entity MAY support other security 1983 mechanisms. 1985 BFCP entities MUST support, at a minimum, the 1986 TLS_RSA_WITH_AES_128_CBC_SHA cipher suite [7] for backwards 1987 compatibility with existing implementations of RFC 4582. In 1988 accordance with the recommendations and guidelines in [28], BFCP 1989 entities SHOULD support the following cipher suites: 1991 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 1993 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 1995 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 1997 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 1999 8. Protocol Transactions 2001 In BFCP, there are two types of transactions: client-initiated 2002 transactions and server-initiated transactions. 2004 Client-initiated transactions consist of a request from a client to a 2005 floor control server and a response from the floor control server to 2006 the client. 2008 Server-initiated transactions have different requirements and 2009 behavior depending on underlying transport: 2011 When using a reliable transport, server-initiated transactions 2012 consist of a single message from a floor control server to a 2013 client (notifications). They do not trigger any response. 2015 When using an unreliable transport, server-initiated transactions 2016 consist of a request from a floor control server to a client and a 2017 response from the client to the floor control server. 2019 When using BFCP over an unreliable transport, retransmission timer T1 2020 (see Section 8.3) MUST be used for all requests until the transaction 2021 is completed. Note that while T1 varies over time, it remains 2022 constant for the duration of a given transaction and is only updated 2023 at the completion of a transaction. 2025 8.1. Client Behavior 2027 A client starting a client-initiated transaction MUST set the 2028 Conference ID in the common header of the message to the Conference 2029 ID for the conference that the client obtained previously. 2031 The client MUST set the Transaction ID value in the common header to 2032 a number that is different from 0 and that MUST NOT be reused in 2033 another message from the client until a response from the server is 2034 received for the transaction. The client uses the Transaction ID 2035 value to match this message with the response from the floor control 2036 server. When using BFCP over an unreliable transport, it is 2037 important to choose a Transaction ID value that lets the receiver 2038 distinguish the reception of the next message in a sequence of BFCP 2039 messages from a retransmission of a previous message. Therefore, 2040 BFCP entities using an unreliable transport MUST use monotonically 2041 increasing Transaction ID values (except for wrap-around). 2043 A client receiving a server-initiated transaction over an unreliable 2044 transport MUST copy the Transaction ID from the request received from 2045 the server into the response. 2047 8.2. Server Behavior 2049 A floor control server sending a response within a client-initiated 2050 transaction MUST copy the Conference ID, the Transaction ID, and the 2051 User ID from the request received from the client into the response. 2053 Server-initiated transactions MUST contain a Transaction ID equal to 2054 0 when BFCP is used over a reliable transport. Over an unreliable 2055 transport, the Transaction ID shall have the same properties as for 2056 client-initiated transactions. The server uses the Transaction ID 2057 value to match this message with the response from the floor 2058 participant or floor chair. 2060 8.3. Timers 2062 When BFCP entities are communicating over an unreliable transport, 2063 two retransmission timers are employed to help mitigate against loss 2064 of datagrams. Retransmission and response caching are not required 2065 when BFCP entities communicate over a reliable transport. 2067 8.3.1. Request Retransmission Timer, T1 2069 T1 is a timer that schedules retransmission of a request until an 2070 appropriate response is received or until the maximum number of 2071 retransmissions have occurred. The timer is computed using the 2072 smoothed round-trip time algorithm defind in [2] with an initial 2073 retransmission timeout (RTO) value of 500ms and clock granularity (G) 2074 of 100ms. In contrast to step 2.4 of Section 2 of [2], if the 2075 computed value of RTO is less than 500ms, then RTO shall be set to 2076 500ms. Timer T1 MUST be adjusted with the reception of a response to 2077 each request transmitted in order to compute an accurate RTO value, 2078 which is the effective T1 value. The RTT value R is the time in 2079 milliseconds from the point when a request is transmitted to the time 2080 the initial response to that request is received. Responses to 2081 retransmitted packets MUST NOT be used to recompute the RTO value, as 2082 one cannot determine if a response is to an initial or retransmitted 2083 request. If T1 always expires on the initial transmission of a new 2084 request, this would suggest the recommended initial T1 (and RTO) 2085 value is too low and SHOULD be increased by doubling the initial 2086 values of T1 (and RTO) until T1 does not expire when sending a new 2087 request. 2089 When retransmitting a request, timer T1 is doubled with each 2090 retransmission, failing after three unacknowledged retransmission 2091 attempts. 2093 If a valid response is not received for a client- or server-initiated 2094 transaction, the implementation MUST consider the BFCP connection as 2095 broken. Implementations SHOULD follow the reestablishment procedure 2096 described in section 6. 2098 8.3.2. Response Retransmission Timer, T2 2100 T2 is a timer that, when fired, signals that the BFCP entity can 2101 release knowledge of the transaction against which it is running. It 2102 is started upon the first transmission of the response to a request 2103 and is the only mechanism by which that response is released by the 2104 BFCP entity. Any subsequent retransmissions of the same request can 2105 be responded to by replaying the cached response, whilst that value 2106 is retained until the timer has fired. Refer to Section 6.2.3 for 2107 the role this timer has in the fragmentation handling scheme. 2109 8.3.3. Timer Values 2111 The table below defines the different timers required when BFCP 2112 entities communicate over an unreliable transport. 2114 +-------+--------------------------------------+----------------+ 2115 | Timer | Description | Value/s | 2116 +-------+--------------------------------------+----------------+ 2117 | T1 | Initial request retransmission timer | 0.5s (initial) | 2118 | T2 | Response retransmission timer | (T1*2^4)*1.25 | 2119 +-------+--------------------------------------+----------------+ 2121 Table 6: Timers 2123 The initial value for T1 is 500ms, which is an estimate of the RTT 2124 for completing the transaction. Computation of this value follows 2125 the procedures described in Section 8.3.1, which includes exponential 2126 backoffs on retransmissions. 2128 T2 MUST be set such that it encompasses all legal retransmissions per 2129 T1 plus a factor to accommodate network latency between BFCP 2130 entities, processing delays, etc. 2132 9. Authentication and Authorization 2134 BFCP clients SHOULD authenticate the floor control server before 2135 sending any BFCP message to it or accepting any BFCP message from it. 2136 Similarly, floor control servers SHOULD authenticate a client before 2137 accepting any BFCP message from it or sending any BFCP message to it. 2139 If the signaling or control protocol traffic used to set up the 2140 conference is authenticated and confidentiality and integrity 2141 protected, and the extensions in this document are supported, the 2142 BFCP clients MUST authenticate the floor control server and the floor 2143 control servers MUST authenticate the client before communicating as 2144 described above. Note that BFCP entities supporting only the [3] 2145 subset may not comply with this mandatory authentication requirement. 2147 BFCP supports TLS/DTLS mutual authentication between clients and 2148 floor control servers, as specified in Section 9.1. This is the 2149 RECOMMENDED authentication mechanism in BFCP. 2151 Note that future extensions may define additional authentication 2152 mechanisms. 2154 In addition to authenticating BFCP messages, floor control servers 2155 need to authorize them. On receiving an authenticated BFCP message, 2156 the floor control server checks whether the client sending the 2157 message is authorized. If the client is not authorized to perform 2158 the operation being requested, the floor control server generates an 2159 Error message, as described in Section 13.8, with an Error code with 2160 a value of 5 (Unauthorized Operation). Messages from a client that 2161 cannot be authorized MUST NOT be processed further. 2163 9.1. TLS/DTLS Based Mutual Authentication 2165 BFCP supports TLS/DTLS based mutual authentication between clients 2166 and floor control servers. If TLS/DTLS is used, an initial 2167 integrity-protected channel is REQUIRED between the client and the 2168 floor control server that can be used to exchange their certificates 2169 (which MAY be self-signed certificates) or, more commonly, the 2170 fingerprints of these certificates. These certificates are used at 2171 TLS/DTLS establishment time. 2173 The implementation of such an integrity-protected channel using 2174 SIP and the SDP offer/answer model is described in [10]. 2176 BFCP messages received over an authenticated TLS/DTLS connection are 2177 considered authenticated. A floor control server that receives a 2178 BFCP message over TCP/UDP (no TLS/DTLS) MAY request the use of TLS/ 2179 DTLS by generating an Error message, as described in Section 13.8, 2180 with an Error code with a value of 9 (Use TLS) or a value of 11 (Use 2181 DTLS) respectively. Clients configured to require the use of TLS/ 2182 DTLS MUST ignore unauthenticated messages. 2184 Note that future extensions may define additional authentication 2185 mechanisms that may not require an initial integrity-protected 2186 channel (e.g., authentication based on certificates signed by a 2187 certificate authority). 2189 As described in Section 9, floor control servers need to perform 2190 authorization before processing any message. In particular, the 2191 floor control server MUST check that messages arriving over a given 2192 authenticated TLS/DTLS connection use an authorized User ID (i.e., a 2193 User ID that the user that established the authenticated TLS/DTLS 2194 connection is allowed to use). 2196 10. Floor Participant Operations 2198 This section specifies how floor participants can perform different 2199 operations, such as requesting a floor, using the protocol elements 2200 described in earlier sections. Section 11 specifies operations that 2201 are specific to floor chairs, such as instructing the floor control 2202 server to grant or revoke a floor, and Section 12 specifies 2203 operations that can be performed by any client (i.e., both floor 2204 participants and floor chairs). 2206 10.1. Requesting a Floor 2208 A floor participant that wishes to request one or more floors does so 2209 by sending a FloorRequest message to the floor control server. 2211 10.1.1. Sending a FloorRequest Message 2213 The ABNF in Section 5.3.1 describes the attributes that a 2214 FloorRequest message can contain. In addition, the ABNF specifies 2215 normatively which of these attributes are mandatory, and which ones 2216 are optional. 2218 The floor participant sets the Conference ID and the Transaction ID 2219 in the common header following the rules given in Section 8.1. 2221 The floor participant sets the User ID in the common header to the 2222 floor participant's identifier. If the sender of the FloorRequest 2223 message (identified by the User ID) is not the participant that would 2224 eventually get the floor (i.e., a third-party floor request), the 2225 sender SHOULD add a BENEFICIARY-ID attribute to the message 2226 identifying the beneficiary of the floor. 2228 Note that the name space for both the User ID and the Beneficiary 2229 ID is the same. That is, a given participant is identified by a 2230 single 16-bit value that can be used in the User ID in the common 2231 header and in several attributes: BENEFICIARY-ID, BENEFICIARY- 2232 INFORMATION, and REQUESTED-BY-INFORMATION. 2234 The floor participant MUST insert at least one FLOOR-ID attribute in 2235 the FloorRequest message. If the client inserts more than one FLOOR- 2236 ID attribute, the floor control server will treat all the floor 2237 requests as an atomic package. That is, the floor control server 2238 will either grant or deny all the floors in the FloorRequest message. 2240 The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute 2241 to state the reason why the floor or floors are being requested. The 2242 Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for 2243 human consumption. 2245 The floor participant may request that the server handle the floor 2246 request with a certain priority using a PRIORITY attribute. 2248 10.1.2. Receiving a Response 2250 A message from the floor control server is considered a response to 2251 the FloorRequest message if the message from the floor control server 2252 has the same Conference ID, Transaction ID, and User ID as the 2253 FloorRequest message, as described in Section 8.1. On receiving such 2254 a response, the floor participant follows the rules in Section 9 that 2255 relate to floor control server authentication. 2257 The successful processing of a FloorRequest message at the floor 2258 control server involves generating one or several FloorRequestStatus 2259 messages. The floor participant obtains a Floor Request ID in the 2260 Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in 2261 the first FloorRequestStatus message from the floor control server. 2262 Subsequent FloorRequestStatus messages from the floor control server 2263 regarding the same floor request will carry the same Floor Request ID 2264 in a FLOOR-REQUEST-INFORMATION attribute as the initial 2265 FloorRequestStatus message. This way, the floor participant can 2266 associate subsequent incoming FloorRequestStatus messages with the 2267 ongoing floor request. 2269 The floor participant obtains information about the status of the 2270 floor request in the FLOOR-REQUEST-INFORMATION attribute of each of 2271 the FloorRequestStatus messages received from the floor control 2272 server. This attribute is a grouped attribute, and as such it 2273 includes a number of attributes that provide information about the 2274 floor request. 2276 The OVERALL-REQUEST-STATUS attribute provides information about the 2277 overall status of the floor request. If the Request Status value is 2278 Granted, all the floors that were requested in the FloorRequest 2279 message have been granted. If the Request Status value is Denied, 2280 all the floors that were requested in the FloorRequest message have 2281 been denied. A floor request is considered to be ongoing while it is 2282 in the Pending, Accepted, or Granted states. If the floor request 2283 value is unknown, then the response is still processed. However, no 2284 meaningful value can be reported to the user. 2286 The STATUS-INFO attribute, if present, provides extra information 2287 that the floor participant can display to the user. 2289 The FLOOR-REQUEST-STATUS attributes provide information about the 2290 status of the floor request as it relates to a particular floor. The 2291 STATUS-INFO attribute, if present, provides extra information that 2292 the floor participant can display to the user. 2294 The BENEFICIARY-INFORMATION attribute identifies the beneficiary of 2295 the floor request in third-party floor requests. The REQUESTED-BY- 2296 INFORMATION attribute need not be present in FloorRequestStatus 2297 messages received by the floor participant that requested the floor, 2298 as this floor participant is already identified by the User ID in the 2299 common header. 2301 The PRIORITY attribute, when present, contains the priority that was 2302 requested by the generator of the FloorRequest message. 2304 If the response is an Error message, the floor control server could 2305 not process the FloorRequest message for some reason, which is 2306 described in the Error message. 2308 10.1.3. Reception of a Subsequent FloorRequestStatus Message 2310 When communicating over an unreliable transport and upon receiving a 2311 FloorRequestStatus message from a floor control server, the 2312 participant MUST respond with a FloorRequestStatusAck message within 2313 the transaction failure window to complete the transaction. 2315 10.2. Cancelling a Floor Request and Releasing a Floor 2317 A floor participant that wishes to cancel an ongoing floor request 2318 does so by sending a FloorRelease message to the floor control 2319 server. The FloorRelease message is also used by floor participants 2320 that hold a floor and would like to release it. 2322 10.2.1. Sending a FloorRelease Message 2324 The ABNF in Section 5.3.2 describes the attributes that a 2325 FloorRelease message can contain. In addition, the ABNF specifies 2326 normatively which of these attributes are mandatory, and which ones 2327 are optional. 2329 The floor participant sets the Conference ID and the Transaction ID 2330 in the common header following the rules given in Section 8.1. The 2331 floor participant sets the User ID in the common header to the floor 2332 participant's identifier. 2334 Note that the FloorRelease message is used to release a floor or 2335 floors that were granted and to cancel ongoing floor requests 2336 (from the protocol perspective, both are ongoing floor requests). 2337 Using the same message in both situations helps resolve the race 2338 condition that occurs when the FloorRelease message and the 2339 FloorGrant message cross each other on the wire. 2341 The floor participant uses the FLOOR-REQUEST-ID that was received in 2342 the response to the FloorRequest message that the FloorRelease 2343 message is cancelling. 2345 Note that if the floor participant requested several floors as an 2346 atomic operation (i.e., in a single FloorRequest message), all the 2347 floors are released as an atomic operation as well (i.e., all are 2348 released at the same time). 2350 10.2.2. Receiving a Response 2352 A message from the floor control server is considered a response to 2353 the FloorRelease message if the message from the floor control server 2354 has the same Conference ID, Transaction ID, and User ID as the 2355 FloorRelease message, as described in Section 8.1. On receiving such 2356 a response, the floor participant follows the rules in Section 9 that 2357 relate to floor control server authentication. 2359 If the response is a FloorRequestStatus message, the Request Status 2360 value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR- 2361 REQUEST-INFORMATION grouped attribute) will be Cancelled or Released. 2363 If the response is an Error message, the floor control server could 2364 not process the FloorRequest message for some reason, which is 2365 described in the Error message. 2367 It is possible that the FloorRelease message crosses on the wire with 2368 a FloorRequestStatus message from the server with a Request Status 2369 different from Cancelled or Released. In any case, such a 2370 FloorRequestStatus message will not be a response to the FloorRelease 2371 message, as its Transaction ID will not match that of the 2372 FloorRelease. 2374 11. Chair Operations 2376 This section specifies how floor chairs can instruct the floor 2377 control server to grant or revoke a floor using the protocol elements 2378 described in earlier sections. 2380 Floor chairs that wish to send instructions to a floor control server 2381 do so by sending a ChairAction message. 2383 11.1. Sending a ChairAction Message 2385 The ABNF in Section 5.3.9 describes the attributes that a ChairAction 2386 message can contain. In addition, the ABNF specifies normatively 2387 which of these attributes are mandatory, and which ones are optional. 2389 The floor chair sets the Conference ID and the Transaction ID in the 2390 common header following the rules given in Section 8.1. The floor 2391 chair sets the User ID in the common header to the floor chair's 2392 identifier. 2394 The ChairAction message contains instructions that apply to one or 2395 more floors within a particular floor request. The floor or floors 2396 are identified by the FLOOR-REQUEST-STATUS attributes and the floor 2397 request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which 2398 are carried in the ChairAction message. 2400 For example, if a floor request consists of two floors that depend on 2401 different floor chairs, each floor chair will grant its floor within 2402 the floor request. Once both chairs have granted their floor, the 2403 floor control server will grant the floor request as a whole. On the 2404 other hand, if one of the floor chairs denies its floor, the floor 2405 control server will deny the floor request as a whole, regardless of 2406 the other floor chair's decision. 2408 The floor chair provides the new status of the floor request as it 2409 relates to a particular floor using a FLOOR-REQUEST-STATUS attribute. 2410 If the new status of the floor request is Accepted, the floor chair 2411 MAY use the Queue Position field to provide a queue position for the 2412 floor request. If the floor chair does not wish to provide a queue 2413 position, all the bits of the Queue Position field MUST be set to 2414 zero. The floor chair MUST use the Status Revoked to revoke a floor 2415 that was granted (i.e., Granted status) and MUST use the Status 2416 Denied to reject floor requests in any other status (e.g., Pending 2417 and Accepted). 2419 The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the 2420 ChairAction message to provide a new overall status for the floor 2421 request. If the new overall status of the floor request is Accepted, 2422 the floor chair can use the Queue Position field to provide a queue 2423 position for the floor request. 2425 Note that a particular floor control server can implement a 2426 different queue for each floor containing all the floor requests 2427 that relate to that particular floor, a general queue for all 2428 floor requests, or both. Also note that a floor request can 2429 involve several floors and that a ChairAction message can only 2430 deal with a subset of these floors (e.g., if a single floor chair 2431 is not authorized to manage all the floors). In this case, the 2432 floor control server will combine the instructions received from 2433 the different floor chairs in FLOOR-REQUEST-STATUS attributes to 2434 come up with the overall status of the floor request. 2436 Note that, while the action of a floor chair may communicate 2437 information in the OVERALL-REQUEST-STATUS attribute, the floor 2438 control server may override, modify, or ignore this field's 2439 content. 2441 The floor chair MAY include STATUS-INFO attributes to state the 2442 reason why the floor or floors are being accepted, granted, or 2443 revoked. The Text in the STATUS-INFO attribute is intended for human 2444 consumption. 2446 11.2. Receiving a Response 2448 A message from the floor control server is considered a response to 2449 the ChairAction message if the message from the server has the same 2450 Conference ID, Transaction ID, and User ID as the ChairAction 2451 message, as described in Section 8.1. On receiving such a response, 2452 the floor chair follows the rules in Section 9 that relate to floor 2453 control server authentication. 2455 A ChairActionAck message from the floor control server confirms that 2456 the floor control server has accepted the ChairAction message. An 2457 Error message indicates that the floor control server could not 2458 process the ChairAction message for some reason, which is described 2459 in the Error message. 2461 12. General Client Operations 2463 This section specifies operations that can be performed by any 2464 client. That is, they are not specific to floor participants or 2465 floor chairs. They can be performed by both. 2467 12.1. Requesting Information about Floors 2469 A client can obtain information about the status of a floor or floors 2470 in different ways, which include using BFCP and using out-of-band 2471 mechanisms. Clients using BFCP to obtain such information use the 2472 procedures described in this section. 2474 Clients request information about the status of one or several floors 2475 by sending a FloorQuery message to the floor control server. 2477 12.1.1. Sending a FloorQuery Message 2479 The ABNF in Section 5.3.7 describes the attributes that a FloorQuery 2480 message can contain. In addition, the ABNF specifies normatively 2481 which of these attributes are mandatory, and which ones are optional. 2483 The client sets the Conference ID and the Transaction ID in the 2484 common header following the rules given in Section 8.1. The client 2485 sets the User ID in the common header to the client's identifier. 2487 The client inserts in the message all the Floor IDs it wants to 2488 receive information about. The floor control server will send 2489 periodic information about all of these floors. If the client does 2490 not want to receive information about a particular floor any longer, 2491 it sends a new FloorQuery message removing the FLOOR-ID of this 2492 floor. If the client does not want to receive information about any 2493 floor any longer, it sends a FloorQuery message with no FLOOR-ID 2494 attribute. 2496 12.1.2. Receiving a Response 2498 A message from the floor control server is considered a response to 2499 the FloorQuery message if the message from the floor control server 2500 has the same Conference ID, Transaction ID, and User ID as the 2501 FloorQuery message, as described in Section 8.1. On receiving such a 2502 response, the client follows the rules in Section 9 that relate to 2503 floor control server authentication. 2505 On reception of the FloorQuery message, the floor control server MUST 2506 respond with a FloorStatus message or with an Error message. If the 2507 response is a FloorStatus message, it will contain information about 2508 one of the floors the client requested information about. If the 2509 client did not include any FLOOR-ID attribute in its FloorQuery 2510 message (i.e., the client does not want to receive information about 2511 any floor any longer), the FloorStatus message from the floor control 2512 server will not include any FLOOR-ID attribute either. 2514 FloorStatus messages that carry information about a floor contain a 2515 FLOOR-ID attribute that identifies the floor. After this attribute, 2516 FloorStatus messages contain information about existing (one or more) 2517 floor requests that relate to that floor. The information about each 2518 particular floor request is encoded in a FLOOR-REQUEST-INFORMATION 2519 attribute. This grouped attribute carries a Floor Request ID that 2520 identifies the floor request, followed by a set of attributes that 2521 provide information about the floor request. 2523 After the first FloorStatus, the floor control server will continue 2524 sending FloorStatus messages, periodically informing the client about 2525 changes on the floors the client requested information about. 2527 12.1.3. Reception of a Subsequent FloorStatus Message 2529 When communicating over an unreliable transport and upon receiving a 2530 FloorStatus message from a floor control server, the participant MUST 2531 respond with a FloorStatusAck message within the transaction failure 2532 window to complete the transaction. 2534 12.2. Requesting Information about Floor Requests 2536 A client can obtain information about the status of one or several 2537 floor requests in different ways, which include using BFCP and using 2538 out-of-band mechanisms. Clients using BFCP to obtain such 2539 information use the procedures described in this section. 2541 Clients request information about the current status of a floor 2542 request by sending a FloorRequestQuery message to the floor control 2543 server. 2545 Requesting information about a particular floor request is useful in 2546 a number of situations. For example, on reception of a FloorRequest 2547 message, a floor control server may choose to return 2548 FloorRequestStatus messages only when the floor request changes its 2549 state (e.g., from Accepted to Granted), but not when the floor 2550 request advances in its queue. In this situation, if the user 2551 requests it, the floor participant can use a FloorRequestQuery 2552 message to poll the floor control server for the status of the floor 2553 request. 2555 12.2.1. Sending a FloorRequestQuery Message 2557 The ABNF in Section 5.3.3 describes the attributes that a 2558 FloorRequestQuery message can contain. In addition, the ABNF 2559 specifies normatively which of these attributes are mandatory, and 2560 which ones are optional. 2562 The client sets the Conference ID and the Transaction ID in the 2563 common header following the rules given in Section 8.1. The client 2564 sets the User ID in the common header to the client's identifier. 2566 The client MUST insert a FLOOR-REQUEST-ID attribute that identifies 2567 the floor request at the floor control server. 2569 12.2.2. Receiving a Response 2571 A message from the floor control server is considered a response to 2572 the FloorRequestQuery message if the message from the floor control 2573 server has the same Conference ID, Transaction ID, and User ID as the 2574 FloorRequestQuery message, as described in Section 8.1. On receiving 2575 such a response, the client follows the rules in Section 9 that 2576 relate to floor control server authentication. 2578 If the response is a FloorRequestStatus message, the client obtains 2579 information about the status of the FloorRequest the client requested 2580 information about in a FLOOR-REQUEST-INFORMATION attribute. 2582 If the response is an Error message, the floor control server could 2583 not process the FloorRequestQuery message for some reason, which is 2584 described in the Error message. 2586 12.3. Requesting Information about a User 2588 A client can obtain information about a participant and the floor 2589 requests related to this participant in different ways, which include 2590 using BFCP and using out-of-band mechanisms. Clients using BFCP to 2591 obtain such information use the procedures described in this section. 2593 Clients request information about a participant and the floor 2594 requests related to this participant by sending a UserQuery message 2595 to the floor control server. 2597 This functionality may be useful for floor chairs or floor 2598 participants interested in the display name and the URI of a 2599 particular floor participant. In addition, a floor participant may 2600 find it useful to request information about itself. For example, a 2601 floor participant, after experiencing connectivity problems (e.g., 2602 its TCP connection with the floor control server was down for a while 2603 and eventually was re-established), may need to request information 2604 about all the floor requests associated to itself that still exist. 2606 12.3.1. Sending a UserQuery Message 2608 The ABNF in Section 5.3.5 describes the attributes that a UserQuery 2609 message can contain. In addition, the ABNF specifies normatively 2610 which of these attributes are mandatory, and which ones are optional. 2612 The client sets the Conference ID and the Transaction ID in the 2613 common header following the rules given in Section 8.1. The client 2614 sets the User ID in the common header to the client's identifier. 2616 If the floor participant the client is requesting information about 2617 is not the client issuing the UserQuery message (which is identified 2618 by the User ID in the common header of the message), the client MUST 2619 insert a BENEFICIARY-ID attribute. 2621 12.3.2. Receiving a Response 2623 A message from the floor control server is considered a response to 2624 the UserQuery message if the message from the floor control server 2625 has the same Conference ID, Transaction ID, and User ID as the 2626 UserQuery message, as described in Section 8.1. On receiving such a 2627 response, the client follows the rules in Section 9 that relate to 2628 floor control server authentication. 2630 If the response is a UserStatus message, the client obtains 2631 information about the floor participant in a BENEFICIARY-INFORMATION 2632 grouped attribute and about the status of the floor requests 2633 associated with the floor participant in FLOOR-REQUEST-INFORMATION 2634 attributes. 2636 If the response is an Error message, the floor control server could 2637 not process the UserQuery message for some reason, which is described 2638 in the Error message. 2640 12.4. Obtaining the Capabilities of a Floor Control Server 2642 A client that wishes to obtain the capabilities of a floor control 2643 server does so by sending a Hello message to the floor control 2644 server. 2646 12.4.1. Sending a Hello Message 2648 The ABNF in Section 5.3.11 describes the attributes that a Hello 2649 message can contain. In addition, the ABNF specifies normatively 2650 which of these attributes are mandatory, and which ones are optional. 2652 The client sets the Conference ID and the Transaction ID in the 2653 common header following the rules given in Section 8.1. The client 2654 sets the User ID in the common header to the client's identifier. 2656 12.4.2. Receiving Responses 2658 A message from the floor control server is considered a response to 2659 the Hello message by the client if the message from the floor control 2660 server has the same Conference ID, Transaction ID, and User ID as the 2661 Hello message, as described in Section 8.1. On receiving such a 2662 response, the client follows the rules in Section 9 that relate to 2663 floor control server authentication. 2665 If the response is a HelloAck message, the floor control server could 2666 process the Hello message successfully. The SUPPORTED-PRIMITIVES and 2667 SUPPORTED-ATTRIBUTES attributes indicate which primitives and 2668 attributes, respectively, are supported by the server. 2670 If the response is an Error message, the floor control server could 2671 not process the Hello message for some reason, which is described in 2672 the Error message. 2674 13. Floor Control Server Operations 2676 This section specifies how floor control servers can perform 2677 different operations, such as granting a floor, using the protocol 2678 elements described in earlier sections. 2680 On reception of a message from a client, the floor control server 2681 MUST check whether the value of the Primitive is supported. If it is 2682 not, the floor control server MUST send an Error message, as 2683 described in Section 13.8, with Error code 3 (Unknown Primitive). 2685 On reception of a message from a client, the floor control server 2686 MUST check whether the value of the Conference ID matched an existing 2687 conference. If it does not, the floor control server MUST send an 2688 Error message, as described in Section 13.8, with Error code 1 2689 (Conference does not Exist). 2691 On reception of a message from a client, the floor control server 2692 follows the rules in Section 9 that relate to the authentication of 2693 the message. 2695 On reception of a message from a client, the floor control server 2696 MUST check whether it understands all the mandatory ('M' bit set) 2697 attributes in the message. If the floor control server does not 2698 understand all of them, the floor control server MUST send an Error 2699 message, as described in Section 13.8, with Error code 4 (Unknown 2700 Mandatory Attribute). The Error message SHOULD list the attributes 2701 that were not understood. 2703 13.1. Reception of a FloorRequest Message 2705 On reception of a FloorRequest message, the floor control server 2706 follows the rules in Section 9 that relate to client authentication 2707 and authorization. If while processing the FloorRequest message, the 2708 floor control server encounters an error, it MUST generate an Error 2709 response following the procedures described in Section 13.8. 2711 BFCP allows floor participants to have several ongoing floor 2712 requests for the same floor (e.g., the same floor participant can 2713 occupy more than one position in a queue at the same time). A 2714 floor control server that only supports a certain number of 2715 ongoing floor requests per floor participant (e.g., one) can use 2716 Error Code 8 (You have Already Reached the Maximum Number of 2717 Ongoing Floor Requests for this Floor) to inform the floor 2718 participant. 2720 When communicating over an unreliable transport and upon receiving a 2721 FloorRequest from a participant, the floor control server MUST 2722 respond with a FloorRequestStatus message within the transaction 2723 failure window to complete the transaction. 2725 13.1.1. Generating the First FloorRequestStatus Message 2727 The successful processing of a FloorRequest message by a floor 2728 control server involves generating one or several FloorRequestStatus 2729 messages, the first of which SHOULD be generated as soon as possible. 2730 If the floor control server cannot accept, grant, or deny the floor 2731 request right away (e.g., a decision from a chair is needed), it 2732 SHOULD use a Request Status value of Pending in the OVERALL-REQUEST- 2733 STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped 2734 attribute) of the first FloorRequestStatus message it generates. 2736 The policy that a floor control server follows to grant or deny 2737 floors is outside the scope of this document. A given floor 2738 control server may perform these decisions automatically while 2739 another may contact a human acting as a chair every time a 2740 decision needs to be made. 2742 The floor control server MUST copy the Conference ID, the Transaction 2743 ID, and the User ID from the FloorRequest into the 2744 FloorRequestStatus, as described in Section 8.2. Additionally, the 2745 floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 2746 attribute to the FloorRequestStatus. The attributes contained in 2747 this grouped attribute carry information about the floor request. 2749 The floor control server MUST assign an identifier that is unique 2750 within the conference to this floor request, and MUST insert it in 2751 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 2752 attribute. This identifier will be used by the floor participant (or 2753 by a chair or chairs) to refer to this specific floor request in the 2754 future. 2756 The floor control server MUST copy the Floor IDs in the FLOOR-ID 2757 attributes of the FloorRequest into the FLOOR-REQUEST-STATUS 2758 attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These 2759 Floor IDs identify the floors being requested (i.e., the floors 2760 associated with this particular floor request). 2762 The floor control server SHOULD copy (if present) the contents of the 2763 BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY- 2764 INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped 2765 attribute. Additionally, the floor control server MAY provide the 2766 display name and the URI of the beneficiary in this BENEFICIARY- 2767 INFORMATION attribute. 2769 The floor control server MAY provide information about the requester 2770 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2771 FLOOR-REQUEST-INFORMATION grouped attribute. 2773 The floor control server MAY copy (if present) the PRIORITY attribute 2774 from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped 2775 attribute. 2777 Note that this attribute carries the priority requested by the 2778 participant. The priority that the floor control server assigns 2779 to the floor request depends on the priority requested by the 2780 participant and the rights the participant has according to the 2781 policy of the conference. For example, a participant that is only 2782 allowed to use the Normal priority may request Highest priority 2783 for a floor request. In that case, the floor control server would 2784 ignore the priority requested by the participant. 2786 The floor control server MAY copy (if present) the PARTICIPANT- 2787 PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST- 2788 INFORMATION grouped attribute. 2790 13.1.2. Generation of Subsequent FloorRequestStatus Messages 2792 A floor request is considered to be ongoing as long as it is not in 2793 the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST- 2794 STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped 2795 attribute) of the first FloorRequestStatus message generated by the 2796 floor control server did not indicate any of these states, the floor 2797 control server will need to send subsequent FloorRequestStatus 2798 messages. 2800 When the status of the floor request changes, the floor control 2801 server SHOULD send new FloorRequestStatus messages with the 2802 appropriate Request Status. The floor control server MUST add a 2803 FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to 2804 the one sent in the first FloorRequestStatus message to any new 2805 FloorRequestStatus related to the same floor request. (The Floor 2806 Request ID identifies the floor request to which the 2807 FloorRequestStatus applies.) 2809 When using BFCP over a reliable transport, the floor control server 2810 MUST set the Transaction ID of subsequent FloorRequestStatus messages 2811 to 0. When using BFCP over an unreliable transport, the Transaction 2812 ID MUST be non-zero and unique in the context of outstanding 2813 transactions over an unreliable transport as described in Section 8. 2815 The rate at which the floor control server sends 2816 FloorRequestStatus messages is a matter of local policy. A floor 2817 control server may choose to send a new FloorRequestStatus message 2818 every time the floor request moves in the floor request queue, 2819 while another may choose only to send a new FloorRequestStatus 2820 message when the floor request is Granted or Denied. 2822 The floor control server may add a STATUS-INFO attribute to any of 2823 the FloorRequestStatus messages it generates to provide extra 2824 information about its decisions regarding the floor request (e.g., 2825 why it was denied). 2827 Floor participants and floor chairs may request to be informed 2828 about the status of a floor following the procedures in 2829 Section 12.1. If the processing of a floor request changes the 2830 status of a floor (e.g., the floor request is granted and 2831 consequently the floor has a new holder), the floor control server 2832 needs to follow the procedures in Section 13.5 to inform the 2833 clients that have requested that information. 2835 The common header and the rest of the attributes are the same as in 2836 the first FloorRequestStatus message. 2838 The floor control server can discard the state information about a 2839 particular floor request when this reaches a status of Cancelled, 2840 Released, or Revoked. 2842 When communicating over an unreliable transport and a 2843 FloorRequestStatusAck message is not received within the transaction 2844 failure window, the floor control server MUST retransmit the 2845 FloorRequestStatus message according to Section 6.2. 2847 13.2. Reception of a FloorRequestQuery Message 2849 On reception of a FloorRequestQuery message, the floor control server 2850 follows the rules in Section 9 that relate to client authentication 2851 and authorization. If while processing the FloorRequestQuery 2852 message, the floor control server encounters an error, it MUST 2853 generate an Error response following the procedures described in 2854 Section 13.8. 2856 The successful processing of a FloorRequestQuery message by a floor 2857 control server involves generating a FloorRequestStatus message, 2858 which SHOULD be generated as soon as possible. 2860 When communicating over an unreliable transport and upon receiving a 2861 FloorRequestQuery from a participant, the floor control server MUST 2862 respond with a FloorRequestStatus message within the transaction 2863 failure window to complete the transaction. 2865 The floor control server MUST copy the Conference ID, the Transaction 2866 ID, and the User ID from the FloorRequestQuery message into the 2867 FloorRequestStatus message, as described in Section 8.2. 2868 Additionally, the floor control server MUST include information about 2869 the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute 2870 to the FloorRequestStatus. 2872 The floor control server MUST copy the contents of the FLOOR-REQUEST- 2873 ID attribute from the FloorRequestQuery message into the Floor 2874 Request ID field of the FLOOR-REQUEST-INFORMATION attribute. 2876 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 2877 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2878 floors being requested (i.e., the floors associated with the floor 2879 request identified by the FLOOR-REQUEST-ID attribute). 2881 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2882 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2883 beneficiary of the floor request. Additionally, the floor control 2884 server MAY provide the display name and the URI of the beneficiary in 2885 this BENEFICIARY-INFORMATION attribute. 2887 The floor control server MAY provide information about the requester 2888 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2889 FLOOR-REQUEST-INFORMATION grouped attribute. 2891 The floor control server MAY provide the reason why the floor 2892 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2894 The floor control server MAY also add to the FLOOR-REQUEST- 2895 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2896 value requested for the floor request and a STATUS-INFO attribute 2897 with extra information about the floor request. 2899 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 2900 to the FLOOR-REQUEST-INFORMATION grouped attribute with the current 2901 status of the floor request. The floor control server MAY provide 2902 information about the status of the floor request as it relates to 2903 each of the floors being requested in the FLOOR-REQUEST-STATUS 2904 attributes. 2906 13.3. Reception of a UserQuery Message 2908 On reception of a UserQuery message, the floor control server follows 2909 the rules in Section 9 that relate to client authentication and 2910 authorization. If while processing the UserQuery message, the floor 2911 control server encounters an error, it MUST generate an Error 2912 response following the procedures described in Section 13.8. 2914 The successful processing of a UserQuery message by a floor control 2915 server involves generating a UserStatus message, which SHOULD be 2916 generated as soon as possible. 2918 When communicating over an unreliable transport and upon receiving a 2919 UserQuery from a participant, the floor control server MUST respond 2920 with a UserStatus message within the transaction failure window to 2921 complete the transaction. 2923 The floor control server MUST copy the Conference ID, the Transaction 2924 ID, and the User ID from the UserQuery message into the UserStatus 2925 message, as described in Section 8.2. 2927 The sender of the UserQuery message is requesting information about 2928 all the floor requests associated with a given participant (i.e., the 2929 floor requests where the participant is either the beneficiary or the 2930 requester). This participant is identified by a BENEFICIARY-ID 2931 attribute or, in the absence of a BENEFICIARY-ID attribute, by a the 2932 User ID in the common header of the UserQuery message. 2934 The floor control server MUST copy, if present, the contents of the 2935 BENEFICIARY-ID attribute from the UserQuery message into a 2936 BENEFICIARY-INFORMATION attribute in the UserStatus message. 2937 Additionally, the floor control server MAY provide the display name 2938 and the URI of the participant about which the UserStatus message 2939 provides information in this BENEFICIARY-INFORMATION attribute. 2941 The floor control server SHOULD add to the UserStatus message a 2942 FLOOR-REQUEST-INFORMATION grouped attribute for each floor request 2943 related to the participant about which the message provides 2944 information (i.e., the floor requests where the participant is either 2945 the beneficiary or the requester). For each FLOOR-REQUEST- 2946 INFORMATION attribute, the floor control server follows the following 2947 steps. 2949 The floor control server MUST identify the floor request the FLOOR- 2950 REQUEST-INFORMATION attribute applies to by filling the Floor Request 2951 ID field of the FLOOR-REQUEST-INFORMATION attribute. 2953 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 2954 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2955 floors being requested (i.e., the floors associated with the floor 2956 request identified by the FLOOR-REQUEST-ID attribute). 2958 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2959 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2960 beneficiary of the floor request. Additionally, the floor control 2961 server MAY provide the display name and the URI of the beneficiary in 2962 this BENEFICIARY-INFORMATION attribute. 2964 The floor control server MAY provide information about the requester 2965 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2966 FLOOR-REQUEST-INFORMATION grouped attribute. 2968 The floor control server MAY provide the reason why the floor 2969 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2971 The floor control server MAY also add to the FLOOR-REQUEST- 2972 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2973 value requested for the floor request. 2975 The floor control server MUST include the current status of the floor 2976 request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST- 2977 INFORMATION grouped attribute. The floor control server MAY add a 2978 STATUS-INFO attribute with extra information about the floor request. 2980 The floor control server MAY provide information about the status of 2981 the floor request as it relates to each of the floors being requested 2982 in the FLOOR-REQUEST-STATUS attributes. 2984 13.4. Reception of a FloorRelease Message 2986 On reception of a FloorRelease message, the floor control server 2987 follows the rules in Section 9 that relate to client authentication 2988 and authorization. If while processing the FloorRelease message, the 2989 floor control server encounters an error, it MUST generate an Error 2990 response following the procedures described in Section 13.8. 2992 The successful processing of a FloorRelease message by a floor 2993 control server involves generating a FloorRequestStatus message, 2994 which SHOULD be generated as soon as possible. 2996 When communicating over an unreliable transport and upon receiving a 2997 FloorRelease from a participant, the floor control server MUST 2998 respond with a FloorRequestStatus message within the transaction 2999 failure window to complete the transaction. 3001 The floor control server MUST copy the Conference ID, the Transaction 3002 ID, and the User ID from the FloorRelease message into the 3003 FloorRequestStatus message, as described in Section 8.2. 3005 The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 3006 attribute to the FloorRequestStatus. The attributes contained in 3007 this grouped attribute carry information about the floor request. 3009 The FloorRelease message identifies the floor request it applies to 3010 using a FLOOR-REQUEST-ID. The floor control server MUST copy the 3011 contents of the FLOOR-REQUEST-ID attribute from the FloorRelease 3012 message into the Floor Request ID field of the FLOOR-REQUEST- 3013 INFORMATION attribute. 3015 The floor control server MUST identify the floors being released 3016 (i.e., the floors associated with the floor request identified by the 3017 FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the 3018 FLOOR-REQUEST-INFORMATION grouped attribute. 3020 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 3021 to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request 3022 Status value SHOULD be Released, if the floor (or floors) had been 3023 previously granted, or Cancelled, if the floor (or floors) had not 3024 been previously granted. The floor control server MAY add a STATUS- 3025 INFO attribute with extra information about the floor request. 3027 13.5. Reception of a FloorQuery Message 3029 On reception of a FloorQuery message, the floor control server 3030 follows the rules in Section 9 that relate to client authentication. 3031 If while processing the FloorQuery message, the floor control server 3032 encounters an error, it MUST generate an Error response following the 3033 procedures described in Section 13.8. 3035 When communicating over an unreliable transport and upon receiving a 3036 FloorQuery from a participant, the floor control server MUST respond 3037 with a FloorStatus message within the transaction failure window to 3038 complete the transaction. 3040 A floor control server receiving a FloorQuery message from a client 3041 SHOULD keep this client informed about the status of the floors 3042 identified by FLOOR-ID attributes in the FloorQuery message. Floor 3043 Control Servers keep clients informed by using FloorStatus messages. 3045 An individual FloorStatus message carries information about a single 3046 floor. So, when a FloorQuery message requests information about more 3047 than one floor, the floor control server needs to send separate 3048 FloorStatus messages for different floors. 3050 The information FloorQuery messages carry may depend on the user 3051 requesting the information. For example, a chair may be able to 3052 receive information about pending requests, while a regular user may 3053 not be authorized to do so. 3055 13.5.1. Generation of the First FloorStatus Message 3057 The successful processing of a FloorQuery message by a floor control 3058 server involves generating one or several FloorStatus messages, the 3059 first of which SHOULD be generated as soon as possible. 3061 The floor control server MUST copy the Conference ID, the Transaction 3062 ID, and the User ID from the FloorQuery message into the FloorStatus 3063 message, as described in Section 8.2. 3065 If the FloorQuery message did not contain any FLOOR-ID attribute, the 3066 floor control server sends the FloorStatus message without adding any 3067 additional attribute and does not send any subsequent FloorStatus 3068 message to the floor participant. 3070 If the FloorQuery message contained one or more FLOOR-ID attributes, 3071 the floor control server chooses one from among them and adds this 3072 FLOOR-ID attribute to the FloorStatus message. The floor control 3073 server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for 3074 each floor request associated to the floor. Each FLOOR-REQUEST- 3075 INFORMATION grouped attribute contains a number of attributes that 3076 provide information about the floor request. For each FLOOR-REQUEST- 3077 INFORMATION attribute, the floor control server follows the following 3078 steps. 3080 The floor control server MUST identify the floor request the FLOOR- 3081 REQUEST-INFORMATION attribute applies to by filling the Floor Request 3082 ID field of the FLOOR-REQUEST-INFORMATION attribute. 3084 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 3085 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 3086 floors being requested (i.e., the floors associated with the floor 3087 request identified by the FLOOR-REQUEST-ID attribute). 3089 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 3090 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 3091 beneficiary of the floor request. Additionally, the floor control 3092 server MAY provide the display name and the URI of the beneficiary in 3093 this BENEFICIARY-INFORMATION attribute. 3095 The floor control server MAY provide information about the requester 3096 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 3097 FLOOR-REQUEST-INFORMATION grouped attribute. 3099 The floor control server MAY provide the reason why the floor 3100 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 3102 The floor control server MAY also add to the FLOOR-REQUEST- 3103 INFORMATION grouped attribute a PRIORITY attribute with the Priority 3104 value requested for the floor request. 3106 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 3107 to the FLOOR-REQUEST-INFORMATION grouped attribute with the current 3108 status of the floor request. The floor control server MAY add a 3109 STATUS-INFO attribute with extra information about the floor request. 3111 The floor control server MAY provide information about the status of 3112 the floor request as it relates to each of the floors being requested 3113 in the FLOOR-REQUEST-STATUS attributes. 3115 13.5.2. Generation of Subsequent FloorStatus Messages 3117 If the FloorQuery message carried more than one FLOOR-ID attribute, 3118 the floor control server SHOULD generate a FloorStatus message for 3119 each of them (except for the FLOOR-ID attribute chosen for the first 3120 FloorStatus message) as soon as possible. These FloorStatus messages 3121 are generated following the same rules as those for the first 3122 FloorStatus message (see Section 13.5.1), but their Transaction ID is 3123 0 when using a reliable transport and non-zero and unique in the 3124 context of outstanding transactions when using an unreliable 3125 transport (cf. Section 8). 3127 After generating these messages, the floor control server sends 3128 FloorStatus messages, periodically keeping the client informed about 3129 all the floors for which the client requested information. The 3130 Transaction ID of these messages MUST be 0 when using a reliable 3131 transport and non-zero and unique in the context of outstanding 3132 transactions when using an unreliable transport (cf. Section 8). 3134 The rate at which the floor control server sends FloorStatus 3135 messages is a matter of local policy. A floor control server may 3136 choose to send a new FloorStatus message every time a new floor 3137 request arrives, while another may choose to only send a new 3138 FloorStatus message when a new floor request is Granted. 3140 When communicating over an unreliable transport and a FloorStatusAck 3141 message is not received within the transaction failure window, the 3142 floor control server MUST retransmit the FloorStatus message 3143 according to Section 6.2. 3145 13.6. Reception of a ChairAction Message 3147 On reception of a ChairAction message, the floor control server 3148 follows the rules in Section 9 that relate to client authentication 3149 and authorization. If while processing the ChairAction message, the 3150 floor control server encounters an error, it MUST generate an Error 3151 response following the procedures described in Section 13.8. 3153 The successful processing of a ChairAction message by a floor control 3154 server involves generating a ChairActionAck message, which SHOULD be 3155 generated as soon as possible. 3157 When communicating over an unreliable transport and upon receiving a 3158 ChairAction from a chair, the floor control server MUST respond with 3159 a ChairActionAck message within the transaction failure window to 3160 complete the transaction. 3162 The floor control server MUST copy the Conference ID, the Transaction 3163 ID, and the User ID from the ChairAction message into the 3164 ChairActionAck message, as described in Section 8.2. 3166 The floor control server needs to take into consideration the 3167 operation requested in the ChairAction message (e.g., granting a 3168 floor) but does not necessarily need to perform it as requested by 3169 the floor chair. The operation that the floor control server 3170 performs depends on the ChairAction message and on the internal state 3171 of the floor control server. 3173 For example, a floor chair may send a ChairAction message granting a 3174 floor that was requested as part of an atomic floor request operation 3175 that involved several floors. Even if the chair responsible for one 3176 of the floors instructs the floor control server to grant the floor, 3177 the floor control server will not grant it until the chairs 3178 responsible for the other floors agree to grant them as well. 3180 So, the floor control server is ultimately responsible for keeping a 3181 coherent floor state using instructions from floor chairs as input to 3182 this state. 3184 If the new Status in the ChairAction message is Accepted and all the 3185 bits of the Queue Position field are zero, the floor chair is 3186 requesting that the floor control server assign a queue position 3187 (e.g., the last in the queue) to the floor request based on the local 3188 policy of the floor control server. (Of course, such a request only 3189 applies if the floor control server implements a queue.) 3191 13.7. Reception of a Hello Message 3193 On reception of a Hello message, the floor control server follows the 3194 rules in Section 9 that relate to client authentication. If while 3195 processing the Hello message, the floor control server encounters an 3196 error, it MUST generate an Error response following the procedures 3197 described in Section 13.8. 3199 If the version of BFCP specified in the Version field of the COMMON- 3200 HEADER is supported by the floor control server, it MUST respond with 3201 the same version number in the HelloAck; this defines the version for 3202 all subsequent BFCP messages within this BFCP Connection. 3204 When communicating over an unreliable transport and upon receiving a 3205 Hello from a participant, the floor control server MUST respond with 3206 a HelloAck message within the transaction failure window to complete 3207 the transaction. 3209 The successful processing of a Hello message by a floor control 3210 server involves generating a HelloAck message, which SHOULD be 3211 generated as soon as possible. The floor control server MUST copy 3212 the Conference ID, the Transaction ID, and the User ID from the Hello 3213 into the HelloAck, as described in Section 8.2. 3215 The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to 3216 the HelloAck message listing all the primitives (i.e., BFCP messages) 3217 supported by the floor control server. 3219 The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to 3220 the HelloAck message listing all the attributes supported by the 3221 floor control server. 3223 13.8. Error Message Generation 3225 Error messages are always sent in response to a previous message from 3226 the client as part of a client-initiated transaction. The ABNF in 3227 Section 5.3.13 describes the attributes that an Error message can 3228 contain. In addition, the ABNF specifies normatively which of these 3229 attributes are mandatory and which ones are optional. 3231 The floor control server MUST copy the Conference ID, the Transaction 3232 ID, and the User ID from the message from the client into the Error 3233 message, as described in Section 8.2. 3235 The floor control server MUST add an ERROR-CODE attribute to the 3236 Error message. The ERROR-CODE attribute contains an Error Code from 3237 Table 5. Additionally, the floor control server may add an ERROR- 3238 INFO attribute with extra information about the error. 3240 14. Security Considerations 3242 BFCP uses TLS/DTLS to provide mutual authentication between clients 3243 and servers. TLS/DTLS also provides replay and integrity protection 3244 and confidentiality. It is RECOMMENDED that TLS/DTLS with an 3245 encryption algorithm according to Section 7 always be used. In cases 3246 where signaling/control traffic is properly protected, as described 3247 in Section 9 it is REQUIRED to use a mandated encryption algorithm. 3248 BFCP entities MAY use other security mechanisms to interwork with 3249 legacy implementation that do not use TLS/DTLS as long as these 3250 mechanisms provide similar security properties. An example of other 3251 mechanisms is IPSec [19] to effectively secure a non-secure BFCP 3252 connection. 3254 The remainder of this section analyzes some of the threats against 3255 BFCP and how they are addressed. 3257 An attacker may attempt to impersonate a client (a floor participant 3258 or a floor chair) in order to generate forged floor requests or to 3259 grant or deny existing floor requests. Client impersonation is 3260 avoided by having servers only accept BFCP messages over 3261 authenticated TLS/DTLS connections. The floor control server assumes 3262 that attackers cannot hijack the TLS/DTLS connection and, therefore, 3263 that messages over the TLS/DTLS connection come from the client that 3264 was initially authenticated. 3266 An attacker may attempt to impersonate a floor control server. A 3267 successful attacker would be able to make clients think that they 3268 hold a particular floor so that they would try to access a resource 3269 (e.g., sending media) without having legitimate rights to access it. 3270 Floor control server impersonation is avoided by having servers only 3271 accept BFCP messages over authenticated TLS/DTLS connections, as well 3272 as ensuring clients only send and accept messages over authenticated 3273 TLS/DTLS connections. 3275 Attackers may attempt to modify messages exchanged by a client and a 3276 floor control server. The integrity protection provided by TLS/DTLS 3277 connections prevents this attack. 3279 An attacker may attempt to fetch a valid message sent by a client to 3280 a floor control server and replay it over a connection between the 3281 attacker and the floor control server. This attack is prevented by 3282 having floor control servers check that messages arriving over a 3283 given authenticated TLS/DTLS connection use an authorized user ID 3284 (i.e., a user ID that the user that established the authenticated 3285 TLS/DTLS connection is allowed to use). 3287 Attackers may attempt to pick messages from the network to get access 3288 to confidential information between the floor control server and a 3289 client (e.g., why a floor request was denied). TLS/DTLS 3290 confidentiality prevents this attack. Therefore, it is REQUIRED that 3291 TLS/DTLS be used with an encryption algorithm according to Section 7. 3293 15. IANA Considerations 3295 [Note to IANA: Much of this text exists from the previous version 3296 of this document. While the old and new additions to the 3297 registries are presented here, the items for which IANA needs to 3298 take action with respect to this draft are highlighted with "Note 3299 to IANA", as with this note and the one immediately following. 3300 Throughout this document, though, RFC XXXX needs to be replaced 3301 with this RFC and the IANA registries for BFCP should to refer 3302 only to this RFC.] 3304 [Note to IANA: This section instructs the IANA to register new 3305 entries in the BFCP Primitive subregistry in Section 15.2 and for 3306 the BFCP Error Code subregistry in Section 15.4.] 3308 The IANA has created a registry for BFCP parameters called "Binary 3309 Floor Control Protocol (BFCP) Parameters". This registry has a 3310 number of subregistries, which are described in the following 3311 sections. 3313 15.1. Attribute Subregistry 3315 This section establishes the Attribute subregistry under the BFCP 3316 Parameters registry. As per the terminology in RFC 5226 [6], the 3317 registration policy for BFCP attributes shall be "Specification 3318 Required". For the purposes of this subregistry, the BFCP attributes 3319 for which IANA registration is requested MUST be defined by a 3320 standards-track RFC. Such an RFC MUST specify the attribute's type, 3321 name, format, and semantics. 3323 For each BFCP attribute, the IANA registers its type, its name, and 3324 the reference to the RFC where the attribute is defined. The 3325 following table contains the initial values of this subregistry. 3327 +------+---------------------------+------------+ 3328 | Type | Attribute | Reference | 3329 +------+---------------------------+------------+ 3330 | 1 | BENEFICIARY-ID | [RFC XXXX] | 3331 | 2 | FLOOR-ID | [RFC XXXX] | 3332 | 3 | FLOOR-REQUEST-ID | [RFC XXXX] | 3333 | 4 | PRIORITY | [RFC XXXX] | 3334 | 5 | REQUEST-STATUS | [RFC XXXX] | 3335 | 6 | ERROR-CODE | [RFC XXXX] | 3336 | 7 | ERROR-INFO | [RFC XXXX] | 3337 | 8 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] | 3338 | 9 | STATUS-INFO | [RFC XXXX] | 3339 | 10 | SUPPORTED-ATTRIBUTES | [RFC XXXX] | 3340 | 11 | SUPPORTED-PRIMITIVES | [RFC XXXX] | 3341 | 12 | USER-DISPLAY-NAME | [RFC XXXX] | 3342 | 13 | USER-URI | [RFC XXXX] | 3343 | 14 | BENEFICIARY-INFORMATION | [RFC XXXX] | 3344 | 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] | 3345 | 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] | 3346 | 17 | FLOOR-REQUEST-STATUS | [RFC XXXX] | 3347 | 18 | OVERALL-REQUEST-STATUS | [RFC XXXX] | 3348 +------+---------------------------+------------+ 3350 Table 7: Initial values of the BFCP Attribute subregistry 3352 15.2. Primitive Subregistry 3354 [Note to IANA: This section instructs the IANA to register the 3355 following new values for the BFCP Primitive subregistry: 3356 FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.] 3358 This section establishes the Primitive subregistry under the BFCP 3359 Parameters registry. As per the terminology in RFC 5226 [6], the 3360 registration policy for BFCP primitives shall be "Specification 3361 Required". For the purposes of this subregistry, the BFCP primitives 3362 for which IANA registration is requested MUST be defined by a 3363 standards-track RFC. Such an RFC MUST specify the primitive's value, 3364 name, format, and semantics. 3366 For each BFCP primitive, the IANA registers its value, its name, and 3367 the reference to the RFC where the primitive is defined. The 3368 following table contains the initial values of this subregistry. 3370 +-------+-----------------------+------------+ 3371 | Value | Primitive | Reference | 3372 +-------+-----------------------+------------+ 3373 | 1 | FloorRequest | [RFC XXXX] | 3374 | 2 | FloorRelease | [RFC XXXX] | 3375 | 3 | FloorRequestQuery | [RFC XXXX] | 3376 | 4 | FloorRequestStatus | [RFC XXXX] | 3377 | 5 | UserQuery | [RFC XXXX] | 3378 | 6 | UserStatus | [RFC XXXX] | 3379 | 7 | FloorQuery | [RFC XXXX] | 3380 | 8 | FloorStatus | [RFC XXXX] | 3381 | 9 | ChairAction | [RFC XXXX] | 3382 | 10 | ChairActionAck | [RFC XXXX] | 3383 | 11 | Hello | [RFC XXXX] | 3384 | 12 | HelloAck | [RFC XXXX] | 3385 | 13 | Error | [RFC XXXX] | 3386 | 14 | FloorRequestStatusAck | [RFC XXXX] | 3387 | 15 | FloorStatusAck | [RFC XXXX] | 3388 | 16 | Goodbye | [RFC XXXX] | 3389 | 17 | GoodbyeAck | [RFC XXXX] | 3390 +-------+-----------------------+------------+ 3392 Table 8: Initial values of the BFCP primitive subregistry 3394 15.3. Request Status Subregistry 3396 This section establishes the Request Status subregistry under the 3397 BFCP Parameters registry. As per the terminology in RFC 5226 [6], 3398 the registration policy for BFCP request status shall be 3399 "Specification Required". For the purposes of this subregistry, the 3400 BFCP request status for which IANA registration is requested MUST be 3401 defined by a standards-track RFC. Such an RFC MUST specify the value 3402 and the semantics of the request status. 3404 For each BFCP request status, the IANA registers its value, its 3405 meaning, and the reference to the RFC where the request status is 3406 defined. The following table contains the initial values of this 3407 subregistry. 3409 +-------+-----------+------------+ 3410 | Value | Status | Reference | 3411 +-------+-----------+------------+ 3412 | 1 | Pending | [RFC XXXX] | 3413 | 2 | Accepted | [RFC XXXX] | 3414 | 3 | Granted | [RFC XXXX] | 3415 | 4 | Denied | [RFC XXXX] | 3416 | 5 | Cancelled | [RFC XXXX] | 3417 | 6 | Released | [RFC XXXX] | 3418 | 7 | Revoked | [RFC XXXX] | 3419 +-------+-----------+------------+ 3421 Table 9: Initial values of the Request Status subregistry 3423 15.4. Error Code Subregistry 3425 [Note to IANA: This section instructs the IANA to register the 3426 following new values for the BFCP Error Code subregistry: 10, 11, 3427 12, 13 and 14.] 3429 This section establishes the Error Code subregistry under the BFCP 3430 Parameters registry. As per the terminology in RFC 5226 [6], the 3431 registration policy for BFCP error codes shall be "Specification 3432 Required". For the purposes of this subregistry, the BFCP error 3433 codes for which IANA registration is requested MUST be defined by a 3434 standards-track RFC. Such an RFC MUST specify the value and the 3435 semantics of the error code, and any Error Specific Details that 3436 apply to it. 3438 For each BFCP primitive, the IANA registers its value, its meaning, 3439 and the reference to the RFC where the primitive is defined. The 3440 following table contains the initial values of this subregistry. 3442 +-------+--------------------------------------+------------+ 3443 | Value | Meaning | Reference | 3444 +-------+--------------------------------------+------------+ 3445 | 1 | Conference does not Exist | [RFC XXXX] | 3446 | 2 | User does not Exist | [RFC XXXX] | 3447 | 3 | Unknown Primitive | [RFC XXXX] | 3448 | 4 | Unknown Mandatory Attribute | [RFC XXXX] | 3449 | 5 | Unauthorized Operation | [RFC XXXX] | 3450 | 6 | Invalid Floor ID | [RFC XXXX] | 3451 | 7 | Floor Request ID Does Not Exist | [RFC XXXX] | 3452 | 8 | You have Already Reached the Maximum | [RFC XXXX] | 3453 | | Number of Ongoing Floor Requests for | | 3454 | | this Floor | | 3455 | 9 | Use TLS | [RFC XXXX] | 3456 | 10 | Unable to parse message | [RFC XXXX] | 3457 | 11 | Use DTLS | [RFC XXXX] | 3458 | 12 | Unsupported Version | [RFC XXXX] | 3459 | 13 | Incorrect Message Length | [RFC XXXX] | 3460 | 14 | Generic Error | [RFC XXXX] | 3461 +-------+--------------------------------------+------------+ 3463 Table 10: Initial Values of the Error Code subregistry 3465 16. Changes from RFC 4582 3467 Following is the list of technical changes and other non-trivial 3468 fixes from [3]. 3470 16.1. Extensions for an unreliable transport 3472 Main purpose of this work was to revise the specification to support 3473 BFCP over an unreliable transport, resulting in the following 3474 changes: 3476 1. Overview of Operation (Section 4): 3477 Changed the description of client-initiated and server-initiated 3478 transactions, referring to Section 8. 3480 2. COMMON-HEADER Format (Section 5.1): 3481 Ver(sion) field, where the value 2 is used for the extensions 3482 for an unreliable transport. Added new R and F flag-bits for an 3483 unreliable transport. Res(erved) field is now 3 bit. New 3484 optional Fragment Offset and Fragment Length fields. 3486 3. New primitives (Section 5.1): 3487 Added four new primitives: FloorRequestStatusAck, 3488 FloorStatusAck, Goodbye, and GoodbyeAck. 3490 4. New error codes (Section 5.2.6): 3491 Added three new error codes: "Unable to Parse Message", "Use 3492 DTLS" and "Unsupported Version". Note that two additional error 3493 codes were added, see Section 16.2. 3495 5. ABNF for new primitives (Section 5.3): 3496 New subsections with normative ABNF for the new primitives. 3498 6. Transport split in two (Section 6): 3499 Section 6 specifying the transport was split in two subsections; 3500 Section 6.1 for a reliable transport and Section 6.2 for an 3501 unreliable transport. Where the specification for an unreliable 3502 transport amongst other issues deals with reliability, 3503 congestion control, fragmentation and ICMP. 3505 7. Mandate DTLS (Section 7 and Section 9): 3506 Mandate DTLS support when transport over UDP is used. 3508 8. Transaction changes (Section 8): 3509 Server-initiated transactions over an unreliable transport has 3510 non-zero and unique Transaction ID. Over an unreliable 3511 transport, the retransmit timers T1 and T2 described in 3512 Section 8.3 apply. 3514 9. Requiring timely response (Section 8.3, Section 10.1.2, 3515 Section 10.2.2, Section 11.2, Section 12.1.2, Section 12.2.2, 3516 Section 12.3.2, Section 12.4.2, Section 10.1.3 and 3517 Section 12.1.3): 3518 Describing that a given response must be sent within the 3519 transaction failure window to complete the transaction. 3521 10. Updated IANA Considerations (Section 15): 3522 Added the new primitives and error codes to Section 15.2 and 3523 Section 15.4 respectively. 3525 11. Examples over an unreliable transport (Appendix A): 3526 Added sample interactions over an unreliable transport for the 3527 scenarios in Figure 2 and Figure 3 3529 12. Motivation for an unreliable transport (Appendix B): 3530 Introduction to and motivation for extending BFCP to support an 3531 unreliable transport. 3533 16.2. Other changes 3535 Clarifications and bug fixes: 3537 1. ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>, 3538 Figure 28, Figure 30, and the ABNF figures in Section 5.3): 3539 Although formally correct in [3], the notation has changed in a 3540 number of Figures to an equivalent form for clarity, e.g., 3541 s/*1(FLOOR-ID)/[FLOOR-ID]/ in Figure 38 and s/*[XXX]/*(XXX)/ in 3542 the other figures. 3544 2. Typo (Section 12.4.2): 3545 Change from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the 3546 second paragraph. 3548 3. Corrected attribute type (Section 13.1.1): 3549 Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in 3550 the eighth paragraph, since the note below describes priority and 3551 that the last paragraph deals with PARTICIPANT-PROVIDED-INFO. 3553 4. New error codes (Section 5.2.6): 3554 Added two additional error codes: "Incorrect Message Length" and 3555 "Generic Error". 3557 5. Assorted clarifications (Across the document): 3558 Language clarifications as a result of reviews. Also, the 3559 normative language where tightened where appropriate, i.e. 3560 changed from SHOULD strength to MUST in a number of places. 3562 17. Acknowledgements 3564 The XCON WG chairs, Adam Roach and Alan Johnston, provided useful 3565 ideas for RFC 4582 [3]. Additionally, Xiaotao Wu, Paul Kyzivat, 3566 Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben 3567 Campbell, Dave Morgan, and Oscar Novo provided useful comments during 3568 the work with RFC 4582. The authors also acknowledge contributions 3569 to the revision of BFCP for use over an unreliable transport from 3570 Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad, 3571 Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, 3572 Joerg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, 3573 Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman, 3574 Vijaya Mandava and Alan Ford. In the final phase Ernst Horvath did a 3575 thorough review revealing issues that needed clarification and 3576 changes. Useful and important final reviews were done by Mary 3577 Barnes. Paul Jones helped tremendously as editor for changes 3578 addressing IESG review comments. 3580 18. References 3581 18.1. Normative References 3583 [1] Bradner, S., "Key words for use in RFCs to Indicate 3584 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 3585 RFC2119, March 1997, 3586 . 3588 [2] Paxson, V. and M. Allman, "Computing TCP's Retransmission 3589 Timer", RFC 2988, DOI 10.17487/RFC2988, November 2000, 3590 . 3592 [3] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 3593 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 3594 November 2006, . 3596 [4] Camarillo, G., "Connection Establishment in the Binary 3597 Floor Control Protocol (BFCP)", RFC 5018, DOI 10.17487/ 3598 RFC5018, September 2007, 3599 . 3601 [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3602 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 3603 RFC5234, January 2008, 3604 . 3606 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3607 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3608 DOI 10.17487/RFC5226, May 2008, 3609 . 3611 [7] Dierks, T. and E. Rescorla, "The Transport Layer Security 3612 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 3613 RFC5246, August 2008, 3614 . 3616 [8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3617 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3618 January 2012, . 3620 [9] Yergeau, F., "UTF-8, a transformation format of ISO 3621 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 3622 2003, . 3624 [10] Camarillo, G., Kristensen, T., and P. Jones, "Session 3625 Description Protocol (SDP) Format for Binary Floor Control 3626 Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-12 3627 (work in progress), September 2015. 3629 [11] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 3630 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 3631 . 3633 [12] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3634 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3635 DOI 10.17487/RFC5389, October 2008, 3636 . 3638 [13] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 3639 for Application Designers", BCP 145, RFC 5405, DOI 3640 10.17487/RFC5405, November 2008, 3641 . 3643 18.2. Informational References 3645 [14] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 3646 with Session Description Protocol (SDP)", RFC 3264, DOI 3647 10.17487/RFC3264, June 2002, 3648 . 3650 [15] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, 3651 "Requirements for Floor Control Protocols", RFC 4376, DOI 3652 10.17487/RFC4376, February 2006, 3653 . 3655 [16] Barnes, M., Boulton, C., and O. Levin, "A Framework for 3656 Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239, 3657 June 2008, . 3659 [17] Rosenberg, J., "Interactive Connectivity Establishment 3660 (ICE): A Protocol for Network Address Translator (NAT) 3661 Traversal for Offer/Answer Protocols", RFC 5245, DOI 3662 10.17487/RFC5245, April 2010, 3663 . 3665 [18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3666 A., Peterson, J., Sparks, R., Handley, M., and E. 3667 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3668 DOI 10.17487/RFC3261, June 2002, 3669 . 3671 [19] Kent, S. and K. Seo, "Security Architecture for the 3672 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 3673 December 2005, . 3675 [20] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 3676 "Conference Information Data Model for Centralized 3677 Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501, 3678 March 2012, . 3680 [21] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, 3681 "Centralized Conferencing Manipulation Protocol", RFC 3682 6503, DOI 10.17487/RFC6503, March 2012, 3683 . 3685 [22] Barnes, M., Miniero, L., Presta, R., and S. Romano, 3686 "Centralized Conferencing Manipulation Protocol (CCMP) 3687 Call Flow Examples", RFC 6504, DOI 10.17487/RFC6504, March 3688 2012, . 3690 [23] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 3691 DOI 10.17487/RFC1191, November 1990, 3692 . 3694 [24] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 3695 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 3696 1996, . 3698 [25] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 3699 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 3700 . 3702 [26] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 3703 for Establishing a Secure Real-time Transport Protocol 3704 (SRTP) Security Context Using Datagram Transport Layer 3705 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 3706 2010, . 3708 [27] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 3709 Control Transmission Protocol (SCTP) Packets for End-Host 3710 to End-Host Communication", RFC 6951, DOI 10.17487/ 3711 RFC6951, May 2013, 3712 . 3714 [28] Sheffer, Y., Holz, R., and P. Saint-Andre, 3715 "Recommendations for Secure Use of Transport Layer 3716 Security (TLS) and Datagram Transport Layer Security 3717 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 3718 2015, . 3720 [29] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 3721 Network Address Translations (NATs)", RFC 4380, DOI 3722 10.17487/RFC4380, February 2006, 3723 . 3725 [30] Thaler, D., "Teredo Extensions", RFC 6081, DOI 10.17487/ 3726 RFC6081, January 2011, 3727 . 3729 [31] Stewart, R., Ed., "Stream Control Transmission Protocol", 3730 RFC 4960, DOI 10.17487/RFC4960, September 2007, 3731 . 3733 [32] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 3734 "TCP Candidates with Interactive Connectivity 3735 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 3736 March 2012, . 3738 [33] Manner, J., Varis, N., and B. Briscoe, "Generic UDP 3739 Tunnelling (GUT)", draft-manner-tsvwg-gut-02 (work in 3740 progress), July 2010. 3742 [34] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis 3743 of Middlebox Interactions for Signaling Protocol 3744 Communication along the Media Path", draft-ietf-mmusic- 3745 media-path-middleboxes-07 (work in progress), May 2013. 3747 [35] Guha, S. and P. Francis, "Characterization and Measurement 3748 of TCP Traversal through NATs and Firewalls", 2005, 3749 . 3751 [36] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer 3752 Communication Across Network Address Translators", April 3753 2005, . 3755 Appendix A. Example Call Flows for BFCP over an Unreliable Transport 3757 With reference to Section 4.1, the following figures show 3758 representative call-flows for requesting and releasing a floor, and 3759 obtaining status information about a floor when BFCP is deployed over 3760 an unreliable transport. The figures here show a loss-less 3761 interaction. 3763 Floor Participant Floor Control 3764 Server 3765 |(1) FloorRequest | 3766 |Transaction Responder: 0 | 3767 |Transaction ID: 123 | 3768 |User ID: 234 | 3769 |FLOOR-ID: 543 | 3770 |---------------------------------------------->| 3771 | | 3772 |(2) FloorRequestStatus | 3773 |Transaction Responder: 1 | 3774 |Transaction ID: 123 | 3775 |User ID: 234 | 3776 |FLOOR-REQUEST-INFORMATION | 3777 | Floor Request ID: 789 | 3778 | OVERALL-REQUEST-STATUS | 3779 | Request Status: Pending | 3780 | FLOOR-REQUEST-STATUS | 3781 | Floor ID: 543 | 3782 |<----------------------------------------------| 3783 | | 3784 |(3) FloorRequestStatus | 3785 |Transaction Responder: 0 | 3786 |Transaction ID: 124 | 3787 |User ID: 234 | 3788 |FLOOR-REQUEST-INFORMATION | 3789 | Floor Request ID: 789 | 3790 | OVERALL-REQUEST-STATUS | 3791 | Request Status: Accepted | 3792 | Queue Position: 1st | 3793 | FLOOR-REQUEST-STATUS | 3794 | Floor ID: 543 | 3795 |<----------------------------------------------| 3796 | | 3797 |(4) FloorRequestStatusAck | 3798 |Transaction Responder: 1 | 3799 |Transaction ID: 124 | 3800 |User ID: 234 | 3801 |---------------------------------------------->| 3802 | | 3803 |(5) FloorRequestStatus | 3804 |Transaction Responder: 0 | 3805 |Transaction ID: 125 | 3806 |User ID: 234 | 3807 |FLOOR-REQUEST-INFORMATION | 3808 | Floor Request ID: 789 | 3809 | OVERALL-REQUEST-STATUS | 3810 | Request Status: Granted | 3811 | FLOOR-REQUEST-STATUS | 3812 | Floor ID: 543 | 3813 |<----------------------------------------------| 3814 | | 3815 |(6) FloorRequestStatusAck | 3816 |Transaction Responder: 1 | 3817 |Transaction ID: 125 | 3818 |User ID: 234 | 3819 |---------------------------------------------->| 3820 | | 3821 |(7) FloorRelease | 3822 |Transaction Responder: 0 | 3823 |Transaction ID: 126 | 3824 |User ID: 234 | 3825 |FLOOR-REQUEST-ID: 789 | 3826 |---------------------------------------------->| 3827 | | 3828 |(8) FloorRequestStatus | 3829 |Transaction Responder: 1 | 3830 |Transaction ID: 126 | 3831 |User ID: 234 | 3832 |FLOOR-REQUEST-INFORMATION | 3833 | Floor Request ID: 789 | 3834 | OVERALL-REQUEST-STATUS | 3835 | Request Status: Released | 3836 | FLOOR-REQUEST-STATUS | 3837 | Floor ID: 543 | 3838 |<----------------------------------------------| 3840 Figure 48: Requesting and releasing a floor 3842 Note that in Figure 48, the FloorRequestStatus message from the floor 3843 control server to the floor participant is a transaction-closing 3844 message as a response to the client-initiated transaction with 3845 Transaction ID 154. As such, it is not followed by a 3846 FloorRequestStatusAck message from the floor participant to the floor 3847 control server. 3849 Floor Participant Floor Control 3850 Server 3851 |(1) FloorQuery | 3852 |Transaction Responder: 0 | 3853 |Transaction ID: 257 | 3854 |User ID: 234 | 3855 |FLOOR-ID: 543 | 3856 |---------------------------------------------->| 3857 | | 3858 |(2) FloorStatus | 3859 |Transaction Responder: 1 | 3860 |Transaction ID: 257 | 3861 |User ID: 234 | 3862 |FLOOR-ID:543 | 3863 |FLOOR-REQUEST-INFORMATION | 3864 | Floor Request ID: 764 | 3865 | OVERALL-REQUEST-STATUS | 3866 | Request Status: Accepted | 3867 | Queue Position: 1st | 3868 | FLOOR-REQUEST-STATUS | 3869 | Floor ID: 543 | 3870 | BENEFICIARY-INFORMATION | 3871 | Beneficiary ID: 124 | 3872 |FLOOR-REQUEST-INFORMATION | 3873 | Floor Request ID: 635 | 3874 | OVERALL-REQUEST-STATUS | 3875 | Request Status: Accepted | 3876 | Queue Position: 2nd | 3877 | FLOOR-REQUEST-STATUS | 3878 | Floor ID: 543 | 3879 | BENEFICIARY-INFORMATION | 3880 | Beneficiary ID: 154 | 3881 |<----------------------------------------------| 3882 | | 3883 |(3) FloorStatus | 3884 |Transaction Responder: 0 | 3885 |Transaction ID: 258 | 3886 |User ID: 234 | 3887 |FLOOR-ID:543 | 3888 |FLOOR-REQUEST-INFORMATION | 3889 | Floor Request ID: 764 | 3890 | OVERALL-REQUEST-STATUS | 3891 | Request Status: Granted | 3892 | FLOOR-REQUEST-STATUS | 3893 | Floor ID: 543 | 3894 | BENEFICIARY-INFORMATION | 3895 | Beneficiary ID: 124 | 3896 |FLOOR-REQUEST-INFORMATION | 3897 | Floor Request ID: 635 | 3898 | OVERALL-REQUEST-STATUS | 3899 | Request Status: Accepted | 3900 | Queue Position: 1st | 3901 | FLOOR-REQUEST-STATUS | 3902 | Floor ID: 543 | 3903 | BENEFICIARY-INFORMATION | 3904 | Beneficiary ID: 154 | 3905 |<----------------------------------------------| 3906 | | 3907 |(4) FloorStatusAck | 3908 |Transaction Responder: 1 | 3909 |Transaction ID: 258 | 3910 |User ID: 234 | 3911 |---------------------------------------------->| 3912 | | 3913 |(5) FloorStatus | 3914 |Transaction Responder: 0 | 3915 |Transaction ID: 259 | 3916 |User ID: 234 | 3917 |FLOOR-ID:543 | 3918 |FLOOR-REQUEST-INFORMATION | 3919 | Floor Request ID: 635 | 3920 | OVERALL-REQUEST-STATUS | 3921 | Request Status: Granted | 3922 | FLOOR-REQUEST-STATUS | 3923 | Floor ID: 543 | 3924 | BENEFICIARY-INFORMATION | 3925 | Beneficiary ID: 154 | 3926 |<----------------------------------------------| 3927 | | 3928 |(6) FloorStatusAck | 3929 |Transaction Responder: 1 | 3930 |Transaction ID: 259 | 3931 |User ID: 234 | 3932 |---------------------------------------------->| 3934 Figure 49: Obtaining status information about a floor 3936 Appendix B. Motivation for Supporting an Unreliable Transport 3938 This appendix is contained in this document as an aid to understand 3939 the background and rationale for adding support for unreliable 3940 transport. 3942 B.1. Motivation 3944 In existing video conferencing deployments, BFCP is used to manage 3945 the floor for the content sharing associated with the conference. 3946 For peer to peer scenarios, including business to business 3947 conferences and point to point conferences in general, it is 3948 frequently the case that one or both endpoints exists behind a NAT. 3949 BFCP roles are negotiated in the offer/answer exchange as specified 3950 in [10], resulting in one endpoint being responsible for opening the 3951 TCP connection used for the BFCP communication. 3953 +---------+ 3954 | Network | 3955 +---------+ 3956 +-----+ / \ +-----+ 3957 | NAT |/ \| NAT | 3958 +-----+ +-----+ 3959 +----+ / \ +----+ 3960 |BFCP|/ \|BFCP| 3961 | UA | | UA | 3962 +----+ +----+ 3964 Figure 50: Use Case 3966 The communication session between the video conferencing endpoints 3967 typically consists of a number of RTP over UDP media streams, for 3968 audio and video, and a BFCP connection for floor control. Existing 3969 deployments are most common in, but not limited to, enterprise 3970 networks. In existing deployments, NAT traversal for the RTP streams 3971 works using ICE and/or other methods, including those described in 3972 [34]. 3974 When enhancing an existing SIP based video conferencing deployment 3975 with support for content sharing, the BFCP connection often poses a 3976 problem. The reasons for this fall into two general classes. First, 3977 there may be a strong preference for UDP based signaling in general. 3978 On high capacity endpoints (e.g., PSTN gateways or SIP/H.323 inter- 3979 working gateways), TCP can suffer from head of line blocking, and it 3980 uses many kernel buffers. Network operators view UDP as a way to 3981 avoid both of these. Second, establishment and traversal of the TCP 3982 connection involving ephemeral ports, as is typically the case with 3983 BFCP over TCP, can be problematic, as described in Appendix A of 3984 [32]. A broad study of NAT behavior and peer-to-peer TCP 3985 establishment for a comprehensive set of TCP NAT traversal techniques 3986 over a wide range of commercial NAT products concluded it was not 3987 possible to establish a TCP connection in 11% of the cases [35]. The 3988 results are worse when focusing on enterprise NATs. A study of hole 3989 punching as a NAT traversal technique across a wide variety of 3990 deployed NATs reported consistently higher success rates when using 3991 UDP than when using TCP [36]. 3993 It is worth noticing that BFCP over UDP is already being used in real 3994 deployments, underlining the necessity to specify a common way to 3995 exchange BFCP messages where TCP is not appropriate, to avoid a 3996 situation where multiple different and non-interoperable 3997 implementations would co-exist in the market. The purpose of this 3998 draft is to formalize and publish the extension from the standard 3999 specification to facilitate complete interoperability between 4000 implementations. 4002 B.1.1. Alternatives Considered 4004 In selecting the approach of defining UDP as an alternate transport 4005 for BFCP, several alternatives were considered and explored to some 4006 degree. Each of these is discussed briefly in the following 4007 subsections. In summary, while the not chosen alternatives work in a 4008 number of scenarios, they are not sufficient, in and of themselves, 4009 to address the use case targeted by this draft. The last 4010 alternative, presented in Appendix B.1.1.7, is the selected one and 4011 is specified in this draft. 4013 It is also worth noting that the IETF Transport Area were asked for a 4014 way to tunnel TCP over UDP, but at that point there was no consensus 4015 on how to achieve that. 4017 B.1.1.1. ICE TCP 4019 ICE TCP [32] extends ICE to TCP based media, including the ability to 4020 offer a mix of TCP and UDP based candidates for a single stream. ICE 4021 TCP has, in general, a lower success probability for enabling TCP 4022 connectivity without a relay if both of the hosts are behind a NAT 4023 (see Appendix A of [32]) than enabling UDP connectivity in the same 4024 scenarios. The happens because many of the currently deployed NATs 4025 in video conferencing networks do not support the flow of TCP hand 4026 shake packets seen in case of TCP simultaneous-open, either because 4027 they do not allow incoming TCP SYN packets from an address to which a 4028 SYN packet has been sent to recently, or because they do not properly 4029 process the subsequent SYNACK. Implementing various techniques 4030 advocated for candidate collection in [32] should increase the 4031 success probability, but many of these techniques require support 4032 from some network elements (e.g., from the NATs). Such support is 4033 not common in enterprise NATs. 4035 B.1.1.2. Teredo 4037 Teredo [29] enables nodes located behind one or more IPv4 NATs to 4038 obtain IPv6 connectivity by tunneling packets over UDP. Teredo 4039 extensions [30] provide additional capabilities to Teredo, including 4040 support for more types of NATs and support for more efficient 4041 communication. 4043 As defined, Teredo could be used to make BFCP work for the video 4044 conferencing use cases addressed in this draft. However, running the 4045 service requires the help of "Teredo servers" and "Teredo relays" 4046 [29]. These servers and relays generally do not exist in the 4047 existing video conferencing deployments. It also requires IPv6 4048 awareness on the endpoints. It should also be noted that ICMP6, as 4049 used with Teredo to complete an initial protocol exchange and confirm 4050 that the appropriate NAT bindings have been set up, is not a 4051 conventional feature of IPv4 or even IPv6, and some currently 4052 deployed IPv6 firewalls discard ICMP messages. As these networks 4053 continue to evolve and tackle the transaction to IPv6, Teredo servers 4054 and relays may be deployed, making Teredo available as a suitable 4055 alternative to BFCP over UDP. 4057 B.1.1.3. GUT 4059 GUT [33] attempts to facilitate tunneling over UDP by encapsulating 4060 the native transport protocol and its payload (in general the whole 4061 IP payload) within a UDP packet destined to the well-known port 4062 GUT_P. Unfortunately, it requires user-space TCP, for which there is 4063 not a readily available implementation, and creating one is a large 4064 project in itself. This draft has expired and its future is still 4065 not clear as it has not yet been adopted by a working group. 4067 B.1.1.4. UPnP IGD 4069 Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on 4070 the edge of the network, providing connectivity to the Internet for 4071 computers internal to the LAN, but do not allow Internet devices to 4072 connect to computers on the internal LAN. IGDs enable a computer on 4073 an internal LAN to create port mappings on their NAT, through which 4074 hosts on the Internet can send data that will be forwarded to the 4075 computer on the internal LAN. IGDs may be self-contained hardware 4076 devices or may be software components provided within an operating 4077 system. 4079 In considering UPnP IGD, several issues exist. Not all NATs support 4080 UPnP, and many that do support it are configured with it turned off 4081 by default. NATs are often multilayered, and UPnP does not work well 4082 with such NATs. For example, a typical DSL modems acts as a NAT, and 4083 the user plugs in a wireless access point behind that, which adds 4084 another layer NAT. The client can discover the first layer of NAT 4085 using multicast but it is harder to figure out how to discover and 4086 control NATs in the next layer up. 4088 B.1.1.5. NAT PMP 4090 The NAT Port Mapping Protocol (NAT PMP) allows a computer in a 4091 private network (behind a NAT router) to automatically configure the 4092 router to allow parties outside the private network to contact it. 4093 NAT PMP runs over UDP. It essentially automates the process of port 4094 forwarding. Included in the protocol is a method for retrieving the 4095 public IP address of a NAT gateway, thus allowing a client to make 4096 this public IP address and port number known to peers that may wish 4097 to communicate with it. 4099 Many NATs do not support PMP. In those that do support it, it has 4100 similar issues with negotiation of multilayer NATs as UPnP. Video 4101 conferencing is used extensively in enterprise networks, and NAT PMP 4102 is not generally available in enterprise-class routers. 4104 B.1.1.6. SCTP 4106 It would be quite straight forward to specify a BFCP binding for SCTP 4107 [31], and then tunnel SCTP over UDP in the use case described in 4108 Appendix B.1. SCTP is gaining some momentum currently. There was 4109 ongoing discussion in the RTCWeb WG regarding this approach, which 4110 resulted in [27]. However, this approach for tunneling over UDP was 4111 not mature enough when considered and not even fully specified. 4113 B.1.1.7. BFCP over UDP transport 4115 To overcome the problems with establishing TCP flows between BFCP 4116 entities, an alternative is to define UDP as an alternate transport 4117 for BFCP, leveraging the same mechanisms in place for the RTP over 4118 UDP media streams for the BFCP communication. When using UDP as the 4119 transport, it is recommended to follow the guidelines provided in 4120 [13]. 4122 Minor changes to the transaction model are introduced in that all 4123 requests now have an appropriate response to complete the 4124 transaction. The requests are sent with a retransmit timer 4125 associated with the response to achieve reliability. This 4126 alternative does not change the semantics of BFCP. It permits UDP as 4127 an alternate transport. 4129 Existing implementations, in the spirit of the approach detailed in 4130 earlier versions of this draft, have demonstrated this approach to be 4131 feasible. Initial compatibility among implementations has been 4132 achieved at previous interoperability events. The authors view this 4133 extension as a pragmatic solution to an existing deployment 4134 challenge. This is the chosen approach, and the extensions are 4135 specified in this document. 4137 Authors' Addresses 4139 Gonzalo Camarillo 4140 Ericsson 4141 Hirsalantie 11 4142 FI-02420 Jorvas 4143 Finland 4145 Email: gonzalo.camarillo@ericsson.com 4146 Keith Drage 4147 Alcatel-Lucent 4148 Quadrant, StoneHill Green, Westlea 4149 Swindon, Wilts 4150 UK 4152 Email: drage@alcatel-lucent.com 4154 Tom Kristensen 4155 Cisco 4156 Philip Pedersens vei 1 4157 NO-1366 Lysaker 4158 Norway 4160 Email: tomkrist@cisco.com, tomkri@ifi.uio.no 4162 Joerg Ott 4163 Aalto University 4164 Otakaari 5 A 4165 FI-02150 Espoo 4166 Finland 4168 Email: jo@comnet.tkk.fi 4170 Charles Eckel 4171 Cisco 4172 707 Tasman Drive 4173 California, CA 95035 4174 United States 4176 Email: eckelcu@cisco.com