idnits 2.17.1 draft-ietf-bfcpbis-rfc4582bis-11.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2014) is 3723 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 3443 ** Obsolete normative reference: RFC 4582 (ref. '2') (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 5226 (ref. '5') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (ref. '6') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (ref. '7') (Obsoleted by RFC 9147) == Outdated reference: A later version (-27) exists of draft-ietf-bfcpbis-rfc4583bis-09 ** Obsolete normative reference: RFC 5389 (ref. '11') (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5245 (ref. '15') (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 1981 (ref. '21') (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 5405 (ref. '25') (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '27') (Obsoleted by RFC 9260) == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-media-path-middleboxes-05 Summary: 5 errors (**), 0 flaws (~~), 4 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: August 19, 2014 T. Kristensen 7 Cisco 8 J. Ott 9 Aalto University 10 C. Eckel 11 Cisco 12 February 15, 2014 14 The Binary Floor Control Protocol (BFCP) 15 draft-ietf-bfcpbis-rfc4582bis-11 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 August 19, 2014. 50 Copyright Notice 52 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1. Floor Creation . . . . . . . . . . . . . . . . . . . . . . 9 71 3.2. Obtaining Information to Contact a Floor Control Server . 9 72 3.3. Obtaining Floor-Resource Associations . . . . . . . . . . 9 73 3.4. Privileges of Floor Control . . . . . . . . . . . . . . . 10 74 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 10 75 4.1. Floor Participant to Floor Control Server Interface . . . 11 76 4.2. Floor Chair to Floor Control Server Interface . . . . . . 15 77 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 16 78 5.1. COMMON-HEADER Format . . . . . . . . . . . . . . . . . . . 16 79 5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . . 19 80 5.2.1. BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 21 81 5.2.2. FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 21 82 5.2.3. FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 22 83 5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 22 84 5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 23 85 5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 24 86 5.2.6.1. Error-Specific Details for Error Code 4 . . . . . 25 87 5.2.7. ERROR-INFO . . . . . . . . . . . . . . . . . . . . . . 25 88 5.2.8. PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . . 26 89 5.2.9. STATUS-INFO . . . . . . . . . . . . . . . . . . . . . 27 90 5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . . 27 91 5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . . 28 92 5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 29 93 5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . . 29 94 5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 30 95 5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 31 96 5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . . 32 97 5.2.17. FLOOR-REQUEST-STATUS . . . . . . . . . . . . . . . . . 32 98 5.2.18. OVERALL-REQUEST-STATUS . . . . . . . . . . . . . . . . 33 99 5.3. Message Format . . . . . . . . . . . . . . . . . . . . . . 34 100 5.3.1. FloorRequest . . . . . . . . . . . . . . . . . . . . . 34 101 5.3.2. FloorRelease . . . . . . . . . . . . . . . . . . . . . 34 102 5.3.3. FloorRequestQuery . . . . . . . . . . . . . . . . . . 34 103 5.3.4. FloorRequestStatus . . . . . . . . . . . . . . . . . . 35 104 5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 35 105 5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . . 35 106 5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . . 36 107 5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 36 108 5.3.9. ChairAction . . . . . . . . . . . . . . . . . . . . . 36 109 5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . . 36 110 5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 37 111 5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 37 112 5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 37 113 5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 38 114 5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . . 38 115 5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38 116 5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 38 117 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 39 118 6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . . 39 119 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . 40 120 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . 42 121 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42 122 6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . . 43 123 6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 44 124 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 44 125 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 45 126 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 46 127 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 46 128 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 47 129 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 47 130 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 47 131 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 47 132 9. Authentication and Authorization . . . . . . . . . . . . . . . 48 133 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 48 134 10. Floor Participant Operations . . . . . . . . . . . . . . . . . 49 135 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 49 136 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 49 137 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 50 138 10.1.3. Reception of a Subsequent FloorRequestStatus 139 Message . . . . . . . . . . . . . . . . . . . . . . . 51 140 10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 52 141 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 52 142 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 52 143 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 53 144 11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 53 145 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 54 146 12. General Client Operations . . . . . . . . . . . . . . . . . . 55 147 12.1. Requesting Information about Floors . . . . . . . . . . . 55 148 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 55 149 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 55 150 12.1.3. Reception of a Subsequent FloorStatus Message . . . . 56 151 12.2. Requesting Information about Floor Requests . . . . . . . 56 152 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 57 153 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 57 154 12.3. Requesting Information about a User . . . . . . . . . . . 57 155 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 58 156 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 58 157 12.4. Obtaining the Capabilities of a Floor Control Server . . . 59 158 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 59 159 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 59 160 13. Floor Control Server Operations . . . . . . . . . . . . . . . 59 161 13.1. Reception of a FloorRequest Message . . . . . . . . . . . 60 162 13.1.1. Generating the First FloorRequestStatus Message . . . 60 163 13.1.2. Generation of Subsequent FloorRequestStatus 164 Messages . . . . . . . . . . . . . . . . . . . . . . . 62 165 13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 63 166 13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 64 167 13.4. Reception of a FloorRelease Message . . . . . . . . . . . 66 168 13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 67 169 13.5.1. Generation of the First FloorStatus Message . . . . . 67 170 13.5.2. Generation of Subsequent FloorStatus Messages . . . . 69 171 13.6. Reception of a ChairAction Message . . . . . . . . . . . . 69 172 13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 70 173 13.8. Error Message Generation . . . . . . . . . . . . . . . . . 71 174 14. Security Considerations . . . . . . . . . . . . . . . . . . . 71 175 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 176 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 72 177 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 73 178 15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 74 179 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 75 180 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 76 181 16.1. Extensions for an unreliable transport . . . . . . . . . . 76 182 16.2. Other changes . . . . . . . . . . . . . . . . . . . . . . 77 183 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78 184 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 185 18.1. Normative References . . . . . . . . . . . . . . . . . . . 79 186 18.2. Informational References . . . . . . . . . . . . . . . . . 79 187 Appendix A. Example Call Flows for BFCP over an Unreliable 188 Transport . . . . . . . . . . . . . . . . . . . . . . 81 189 Appendix B. Motivation for Supporting an Unreliable Transport . . 84 190 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 85 191 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 86 192 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 86 193 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 87 194 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 87 195 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 87 196 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 88 197 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 88 198 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 88 199 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89 201 1. Introduction 203 Within a conference, some applications need to manage the access to a 204 set of shared resources, such as the right to send media to a 205 particular media session. Floor control enables such applications to 206 provide users with coordinated (shared or exclusive) access to these 207 resources. 209 The Requirements for Floor Control Protocol [13] list a set of 210 requirements that need to be met by floor control protocols. The 211 Binary Floor Control Protocol (BFCP), which is specified in this 212 document, meets these requirements. 214 In addition, BFCP has been designed so that it can be used in low- 215 bandwidth environments. The binary encoding used by BFCP achieves a 216 small message size (when message signatures are not used) that keeps 217 the time it takes to transmit delay-sensitive BFCP messages to a 218 minimum. Delay-sensitive BFCP messages include FloorRequest, 219 FloorRelease, FloorRequestStatus, and ChairAction. It is expected 220 that future extensions to these messages will not increase the size 221 of these messages in a significant way. 223 The remainder of this document is organized as follows: Section 2 224 defines the terminology used throughout this document, Section 3 225 discusses the scope of BFCP (i.e., which tasks fall within the scope 226 of BFCP and which ones are performed using different mechanisms), 227 Section 4 provides a non-normative overview of BFCP operation, and 228 subsequent sections provide the normative specification of BFCP. 230 2. Terminology 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 234 "OPTIONAL" in this document are to be interpreted as described in BCP 235 14, RFC 2119 [1] and indicate requirement levels for compliant 236 implementations. 238 Media Participant: An entity that has access to the media resources 239 of a conference (e.g., it can receive a media stream). In floor- 240 controlled conferences, a given media participant is typically 241 colocated with a floor participant, but it does not need to be. 242 Third-party floor requests consist of having a floor participant 243 request a floor for a media participant when they are not colocated. 244 The protocol between a floor participant and a media participant 245 (that are not colocated) is outside the scope of this document. 247 Client: A floor participant or a floor chair that communicates with a 248 floor control server using BFCP. 250 Floor: A temporary permission to access or manipulate a specific 251 shared resource or set of resources. 253 Floor Chair: A logical entity that manages one floor (grants, denies, 254 or revokes a floor). An entity that assumes the logical role of a 255 floor chair for a given transaction may assume a different role 256 (e.g., floor participant) for a different transaction. The roles of 257 floor chair and floor participant are defined on a transaction-by- 258 transaction basis. BFCP transactions are defined in Section 8. 260 Floor Control: A mechanism that enables applications or users to gain 261 safe and mutually exclusive or non-exclusive input access to the 262 shared object or resource. 264 Floor Control Server: A logical entity that maintains the state of 265 the floor(s), including which floors exists, who the floor chairs 266 are, who holds a floor, etc. Requests to manipulate a floor are 267 directed at the floor control server. The floor control server of a 268 conference may perform other logical roles (e.g., floor participant) 269 in another conference. 271 Floor Participant: A logical entity that requests floors, and 272 possibly information about them, from a floor control server. An 273 entity that assumes the logical role of a floor participant for a 274 given transaction may assume a different role (e.g., a floor chair) 275 for a different transaction. The roles of floor participant and 276 floor chair are defined on a transaction-by-transaction basis. BFCP 277 transactions are defined in Section 8. In floor-controlled 278 conferences, a given floor participant is typically colocated with a 279 media participant, but it does not need to be. Third-party floor 280 requests consist of having a floor participant request a floor for a 281 media participant when they are not colocated. 283 Participant: An entity that acts as a floor participant, as a media 284 participant, or as both. 286 BFCP Connection: A transport association between BFCP entities, used 287 to exchange BFCP messages. 289 3. Scope 291 As stated earlier, BFCP is a protocol to coordinate access to shared 292 resources in a conference following the requirements defined in [13]. 293 Floor control complements other functions defined in the XCON 294 conferencing framework [14]. The floor control protocol BFCP defined 295 in this document only specifies a means to arbitrate access to 296 floors. The rules and constraints for floor arbitration and the 297 results of floor assignments are outside the scope of this document 298 and are defined by other protocols [14]. 300 Figure 1 shows the tasks that BFCP can perform. 302 +---------+ 303 | Floor | 304 | Chair | 305 | | 306 +---------+ 307 ^ | 308 | | 309 Notification | | Decision 310 | | 311 | | 312 Floor | v 313 +-------------+ Request +---------+ +-------------+ 314 | Floor |----------->| Floor | Notification | Floor | 315 | Participant | | Control |------------->| Participant | 316 | |<-----------| Server | | | 317 +-------------+ Granted or +---------+ +-------------+ 318 Denied 320 Figure 1: Functionality provided by BFCP 322 BFCP provides a means: 324 o for floor participants to send floor requests to floor control 325 servers. 327 o for floor control servers to grant or deny requests to access a 328 given resource from floor participants. 330 o for floor chairs to send floor control servers decisions regarding 331 floor requests. 333 o for floor control servers to keep floor participants and floor 334 chairs informed about the status of a given floor or a given floor 335 request. 337 Even though tasks that do not belong to the previous list are outside 338 the scope of BFCP, some of these out-of-scope tasks relate to floor 339 control and are essential for creating floors and establishing BFCP 340 connections between different entities. In the following 341 subsections, we discuss some of these tasks and mechanisms to perform 342 them. 344 3.1. Floor Creation 346 The association of a given floor with a resource or a set of 347 resources (e.g., media streams) is out of the scope of BFCP as 348 described in [14]. Floor creation and termination are also outside 349 the scope of BFCP; these aspects are handled using the conference 350 control protocol for manipulating the conference object. 351 Consequently, the floor control server needs to stay up to date on 352 changes to the conference object (e.g., when a new floor is created). 354 Conference control clients using CCMP [18] can specify such floor- 355 related settings in the element [17] of the to-be 356 created conference object provided in the body of a CCMP confRequest/ 357 create message issued to the conference control server. 359 3.2. Obtaining Information to Contact a Floor Control Server 361 A client needs a set of data in order to establish a BFCP connection 362 to a floor control server. This data includes the transport address 363 of the server, the conference identifier, and a user identifier. 365 Clients can obtain this information in different ways. One is to use 366 an SDP offer/answer [12] exchange, which is described in [9]. How to 367 establish a connection to a BFCP floor control server outside the 368 context of an offer/answer exchange is described in [3]. Other 369 mechanisms are described in the XCON framework [14] (and other 370 related documents). 372 3.3. Obtaining Floor-Resource Associations 374 Floors are associated with resources. For example, a floor that 375 controls who talks at a given time has a particular audio session as 376 its associated resource. Associations between floors and resources 377 are part of the conference object. 379 Floor participants and floor chairs need to know which resources are 380 associated with which floors. They can obtain this information by 381 using different mechanisms, such as an SDP offer/answer [12] 382 exchange. How to use an SDP offer/answer exchange to obtain these 383 associations is described in [9]. 385 Note that floor participants perform SDP offer/answer exchanges 386 with the conference focus of the conference. So, the conference 387 focus needs to obtain information about associations between 388 floors and resources in order to be able to provide this 389 information to a floor participant in an SDP offer/answer 390 exchange. 392 Other mechanisms for obtaining this information, including discussion 393 of how the information is made available to a (SIP) Focus, are 394 described in the XCON framework [14] (and other related documents). 395 According to the conferencing system policies, conference control 396 clients using CCMP [18] can modify the floor settings of a conference 397 by issuing CCMP confRequest/update messages providing the specific 398 updates to the element of the target conference 399 object. More information about CCMP and BFCP interaction can be 400 found in [19]. 402 3.4. Privileges of Floor Control 404 A participant whose floor request is granted has the right to use the 405 resource or resources associated with the floor that was requested. 406 For example, the participant may have the right to send media over a 407 particular audio stream. 409 Nevertheless, holding a floor does not imply that others will not be 410 able to use its associated resources at the same time, even if they 411 do not have the right to do so. Determination of which media 412 participants can actually use the resources in the conference is 413 discussed in the XCON Framework [14]. 415 4. Overview of Operation 417 This section provides a non-normative description of BFCP operations. 418 Section 4.1 describes the interface between floor participants and 419 floor control servers, and Section 4.2 describes the interface 420 between floor chairs and floor control servers. 422 BFCP messages, which use a TLV (Type-Length-Value) binary encoding, 423 consist of a common header followed by a set of attributes. The 424 common header contains, among other information, a 32-bit conference 425 identifier. Floor participants, media participants, and floor chairs 426 are identified by 16-bit user identifiers. 428 BFCP supports nested attributes (i.e., attributes that contain 429 attributes). These are referred to as grouped attributes. 431 There are two types of transactions in BFCP: client-initiated 432 transactions and server-initiated transactions. Section 8 describes 433 both types of transactions in detail. 435 4.1. Floor Participant to Floor Control Server Interface 437 Floor participants request a floor by sending a FloorRequest message 438 to the floor control server. BFCP supports third-party floor 439 requests. That is, the floor participant sending the floor request 440 need not be colocated with the media participant that will get the 441 floor once the floor request is granted. FloorRequest messages carry 442 the identity of the requester in the User ID field of the common 443 header, and the identity of the beneficiary of the floor (in third- 444 party floor requests) in a BENEFICIARY-ID attribute. 446 Third-party floor requests can be sent, for example, by floor 447 participants that have a BFCP connection to the floor control 448 server but that are not media participants (i.e., they do not 449 handle any media). 451 FloorRequest messages identify the floor or floors being requested by 452 carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a 453 FloorRequest message carries more than one floor identifier, the 454 floor control server treats all the floor requests as an atomic 455 package. That is, the floor control server either grants or denies 456 all the floors in the FloorRequest message. 458 Floor control servers respond to FloorRequest messages with 459 FloorRequestStatus messages, which provide information about the 460 status of the floor request. The first FloorRequestStatus message is 461 the response to the FloorRequest message from the client, and 462 therefore has the same Transaction ID as the FloorRequest. 464 Additionally, the first FloorRequestStatus message carries the Floor 465 Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent 466 FloorRequestStatus messages related to the same floor request will 467 carry the same Floor Request ID. This way, the floor participant can 468 associate them with the appropriate floor request. 470 Messages from the floor participant related to a particular floor 471 request also use the same Floor Request ID as the first 472 FloorRequestStatus Message from the floor control server. 474 Figures 2 and 3 below show examples of call flows where BFCP is used 475 over a reliable transport. Appendix A shows the same call flow 476 examples using an unreliable transport. 478 Figure 2 shows how a floor participant requests a floor, obtains it, 479 and, at a later time, releases it. This figure illustrates the use, 480 among other things, of the Transaction ID and the FLOOR-REQUEST-ID 481 attribute. 483 Floor Participant Floor Control 484 Server 485 |(1) FloorRequest | 486 |Transaction ID: 123 | 487 |User ID: 234 | 488 |FLOOR-ID: 543 | 489 |---------------------------------------------->| 490 | | 491 |(2) FloorRequestStatus | 492 |Transaction ID: 123 | 493 |User ID: 234 | 494 |FLOOR-REQUEST-INFORMATION | 495 | Floor Request ID: 789 | 496 | OVERALL-REQUEST-STATUS | 497 | Request Status: Pending | 498 | FLOOR-REQUEST-STATUS | 499 | Floor ID: 543 | 500 |<----------------------------------------------| 501 | | 502 |(3) FloorRequestStatus | 503 |Transaction ID: 0 | 504 |User ID: 234 | 505 |FLOOR-REQUEST-INFORMATION | 506 | Floor Request ID: 789 | 507 | OVERALL-REQUEST-STATUS | 508 | Request Status: Accepted | 509 | Queue Position: 1st | 510 | FLOOR-REQUEST-STATUS | 511 | Floor ID: 543 | 512 |<----------------------------------------------| 513 | | 514 |(4) FloorRequestStatus | 515 |Transaction ID: 0 | 516 |User ID: 234 | 517 |FLOOR-REQUEST-INFORMATION | 518 | Floor Request ID: 789 | 519 | OVERALL-REQUEST-STATUS | 520 | Request Status: Granted | 521 | FLOOR-REQUEST-STATUS | 522 | Floor ID: 543 | 523 |<----------------------------------------------| 524 | | 525 |(5) FloorRelease | 526 |Transaction ID: 154 | 527 |User ID: 234 | 528 |FLOOR-REQUEST-ID: 789 | 529 |---------------------------------------------->| 530 | | 531 |(6) FloorRequestStatus | 532 |Transaction ID: 154 | 533 |User ID: 234 | 534 |FLOOR-REQUEST-INFORMATION | 535 | Floor Request ID: 789 | 536 | OVERALL-REQUEST-STATUS | 537 | Request Status: Released | 538 | FLOOR-REQUEST-STATUS | 539 | Floor ID: 543 | 540 |<----------------------------------------------| 542 Figure 2: Requesting and releasing a floor 544 Figure 3 shows how a floor participant requests to be informed on the 545 status of a floor. The first FloorStatus message from the floor 546 control server is the response to the FloorQuery message and, as 547 such, has the same Transaction ID as the FloorQuery message. 549 Subsequent FloorStatus messages consist of server-initiated 550 transactions, and therefore their Transaction ID is 0. FloorStatus 551 message (2) indicates that there are currently two floor requests for 552 the floor whose Floor ID is 543. FloorStatus message (3) indicates 553 that the floor requests with Floor Request ID 764 has been granted, 554 and the floor request with Floor Request ID 635 is the first in the 555 queue. FloorStatus message (4) indicates that the floor request with 556 Floor Request ID 635 has been granted. 558 Floor Participant Floor Control 559 Server 560 |(1) FloorQuery | 561 |Transaction ID: 257 | 562 |User ID: 234 | 563 |FLOOR-ID: 543 | 564 |---------------------------------------------->| 565 | | 566 |(2) FloorStatus | 567 |Transaction ID: 257 | 568 |User ID: 234 | 569 |FLOOR-ID:543 | 570 |FLOOR-REQUEST-INFORMATION | 571 | Floor Request ID: 764 | 572 | OVERALL-REQUEST-STATUS | 573 | Request Status: Accepted | 574 | Queue Position: 1st | 575 | FLOOR-REQUEST-STATUS | 576 | Floor ID: 543 | 577 | BENEFICIARY-INFORMATION | 578 | Beneficiary ID: 124 | 579 |FLOOR-REQUEST-INFORMATION | 580 | Floor Request ID: 635 | 581 | OVERALL-REQUEST-STATUS | 582 | Request Status: Accepted | 583 | Queue Position: 2nd | 584 | FLOOR-REQUEST-STATUS | 585 | Floor ID: 543 | 586 | BENEFICIARY-INFORMATION | 587 | Beneficiary ID: 154 | 588 |<----------------------------------------------| 589 | | 590 |(3) FloorStatus | 591 |Transaction ID: 0 | 592 |User ID: 234 | 593 |FLOOR-ID:543 | 594 |FLOOR-REQUEST-INFORMATION | 595 | Floor Request ID: 764 | 596 | OVERALL-REQUEST-STATUS | 597 | Request Status: Granted | 598 | FLOOR-REQUEST-STATUS | 599 | Floor ID: 543 | 600 | BENEFICIARY-INFORMATION | 601 | Beneficiary ID: 124 | 602 |FLOOR-REQUEST-INFORMATION | 603 | Floor Request ID: 635 | 604 | OVERALL-REQUEST-STATUS | 605 | Request Status: Accepted | 606 | Queue Position: 1st | 607 | FLOOR-REQUEST-STATUS | 608 | Floor ID: 543 | 609 | BENEFICIARY-INFORMATION | 610 | Beneficiary ID: 154 | 611 |<----------------------------------------------| 612 | | 613 |(4) FloorStatus | 614 |Transaction ID: 0 | 615 |User ID: 234 | 616 |FLOOR-ID:543 | 617 |FLOOR-REQUEST-INFORMATION | 618 | Floor Request ID: 635 | 619 | OVERALL-REQUEST-STATUS | 620 | Request Status: Granted | 621 | FLOOR-REQUEST-STATUS | 622 | Floor ID: 543 | 623 | BENEFICIARY-INFORMATION | 624 | Beneficiary ID: 154 | 625 |<----------------------------------------------| 627 Figure 3: Obtaining status information about a floor 629 FloorStatus messages contain information about the floor requests 630 they carry. For example, FloorStatus message (4) indicates that the 631 floor request with Floor Request ID 635 has as the beneficiary (i.e., 632 the participant that holds the floor when a particular floor request 633 is granted) the participant whose User ID is 154. The floor request 634 applies only to the floor whose Floor ID is 543. That is, this is 635 not a multi-floor floor request. 637 A multi-floor floor request applies to more than one floor (e.g., 638 a participant wants to be able to speak and write on the 639 whiteboard at the same time). The floor control server treats a 640 multi-floor floor request as an atomic package. That is, the 641 floor control server either grants the request for all floors or 642 denies the request for all floors. 644 4.2. Floor Chair to Floor Control Server Interface 646 Figure 4 shows a floor chair instructing a floor control server to 647 grant a floor. 649 Note, however, that although the floor control server needs to 650 take into consideration the instructions received in ChairAction 651 messages (e.g., granting a floor), it does not necessarily need to 652 perform them exactly as requested by the floor chair. The 653 operation that the floor control server performs depends on the 654 ChairAction message and on the internal state of the floor control 655 server. 657 For example, a floor chair may send a ChairAction message granting a 658 floor that was requested as part of an atomic floor request operation 659 that involved several floors. Even if the chair responsible for one 660 of the floors instructs the floor control server to grant the floor, 661 the floor control server will not grant it until the chairs 662 responsible for the other floors agree to grant them as well. In 663 another example, a floor chair may instruct the floor control server 664 to grant a floor to a participant. The floor control server needs to 665 revoke the floor from its current holder before granting it to the 666 new participant. 668 So, the floor control server is ultimately responsible for keeping a 669 coherent floor state using instructions from floor chairs as input to 670 this state. 672 Floor Chair Floor Control 673 Server 674 |(1) ChairAction | 675 |Transaction ID: 769 | 676 |User ID: 357 | 677 |FLOOR-REQUEST-INFORMATION | 678 | Floor Request ID: 635 | 679 | FLOOR-REQUEST-STATUS | 680 | Floor ID: 543 | 681 | Request Status: Granted | 682 |---------------------------------------------->| 683 | | 684 |(2) ChairActionAck | 685 |Transaction ID: 769 | 686 |User ID: 357 | 687 |<----------------------------------------------| 689 Figure 4: Chair instructing the floor control server 691 5. Packet Format 693 BFCP packets consist of a 12-octet common header followed by 694 attributes. All the protocol values MUST be sent in network byte 695 order. 697 5.1. COMMON-HEADER Format 699 The following is the format of the common header. 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Ver |R|F| Res | Primitive | Payload Length | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Conference ID | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Transaction ID | User ID | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Fragment Offset (if F is set) | Fragment Length (if F is set) | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Figure 5: COMMON-HEADER format 715 Ver: This 3-bit field defines the version of BFCP that this message 716 adheres to. This specification defines two versions: 1 and 2. The 717 version field MUST be set to 1 when using BFCP over a reliable 718 transport, i.e. as in [2]. The version field MUST be set to 2 when 719 using BFCP over an unreliable transport with the extensions specified 720 in this document. If an endpoint receives a message with an 721 unsupported version field value, the receiving server MUST send an 722 Error message with parameter value 12 (Unsupported Version) to 723 indicate this. 725 R: The Transaction Responder (R) flag-bit has relevance only for use 726 of BFCP over an unreliable transport. When cleared, it indicates 727 that this message is a request initiating a new transaction, and the 728 Transaction ID that follows has been generated for this transaction. 729 When set, it indicates that this message is a response to a previous 730 request, and the Transaction ID that follows is the one associated 731 with that request. When BFCP is used over a reliable transport, the 732 flag has no significance and MUST be cleared by the sender and MUST 733 be ignored by the receiver. 735 F: The Fragmentation (F) flag-bit has relevance only for use of BFCP 736 over an unreliable transport. When cleared, the message is not 737 fragmented. When set, it indicates that the message is a fragment of 738 a large fragmented BFCP message. (The optional fields Fragment 739 Offset and Fragment Length described below are present only if the F 740 flag is set). When BFCP is used over a reliable transport, the flag 741 has no significance and MUST be cleared by the sender and MUST be 742 ignored by the receiver. 744 Res: At this point, the 3 bits in the reserved field MUST be set to 745 zero by the sender of the message and MUST be ignored by the 746 receiver. 748 Primitive: This 8-bit field identifies the main purpose of the 749 message. The following primitive values are defined: 751 +-------+-----------------------+--------------------+ 752 | Value | Primitive | Direction | 753 +-------+-----------------------+--------------------+ 754 | 1 | FloorRequest | P -> S | 755 | 2 | FloorRelease | P -> S | 756 | 3 | FloorRequestQuery | P -> S ; Ch -> S | 757 | 4 | FloorRequestStatus | P <- S ; Ch <- S | 758 | 5 | UserQuery | P -> S ; Ch -> S | 759 | 6 | UserStatus | P <- S ; Ch <- S | 760 | 7 | FloorQuery | P -> S ; Ch -> S | 761 | 8 | FloorStatus | P <- S ; Ch <- S | 762 | 9 | ChairAction | Ch -> S | 763 | 10 | ChairActionAck | Ch <- S | 764 | 11 | Hello | P -> S ; Ch -> S | 765 | 12 | HelloAck | P <- S ; Ch <- S | 766 | 13 | Error | P <- S ; Ch <- S | 767 | 14 | FloorRequestStatusAck | P -> S ; Ch -> S | 768 | 15 | FloorStatusAck | P -> S ; Ch -> S | 769 | 16 | Goodbye | P -> S ; Ch -> S ; | 770 | | | P <- S ; Ch <- S | 771 | 17 | GoodbyeAck | P -> S ; Ch -> S ; | 772 | | | P <- S ; Ch <- S | 773 +-------+-----------------------+--------------------+ 775 S: Floor Control Server / P: Floor Participant / Ch: Floor Chair 777 Table 1: BFCP primitives 779 Payload Length: This 16-bit field contains the length of the message 780 in 4-octet units, excluding the common header. If a Floor Control 781 Server receives a message with an incorrect Payload Length field 782 value, the receiving server MUST send an Error message with parameter 783 value 13 (Incorrect Message Length) to indicate this. 785 Note: BFCP is designed to achieve small message size, as explained 786 in Section 1, and BFCP entities are REQUIRED to keep the BFCP 787 message size smaller than the size limited by the 16-bit Payload 788 Length field. To convey information not strictly related to floor 789 control, other protocols should be used such as the XCON framework 790 (cf. Section 3). 792 Conference ID: This 32-bit unsigned integer field identifies the 793 conference the message belongs to. 795 Transaction ID: This field contains a 16-bit value that allows users 796 to match a given message with its response (see Section 8). 798 User ID: This field contains a 16-bit unsigned integer that uniquely 799 identifies a participant within a conference. 801 The identity used by a participant in BFCP, which is carried in 802 the User ID field, is generally mapped to the identity used by the 803 same participant in the session establishment protocol (e.g., in 804 SIP). The way this mapping is performed is outside the scope of 805 this specification. 807 Fragment Offset: This optional field is present only if the F flag is 808 set and contains a 16-bit value that specifies the number of 4-octet 809 units contained in previous fragments, excluding the common header. 811 Fragment Length: This optional field is present only if the F flag is 812 set and contains a 16-bit value that specifies the number of 4-octet 813 units contained in this fragment, excluding the common header. 815 5.2. Attribute Format 817 BFCP attributes are encoded in TLV (Type-Length-Value) format. 818 Attributes are 32-bit aligned. 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Type |M| Length | | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 825 | | 826 / Attribute Contents / 827 / / 828 | | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 Figure 6: Attribute format 833 Type: This 7-bit field contains the type of the attribute. Each 834 attribute, identified by its type, has a particular format. The 835 attribute formats defined are: 837 Unsigned16: The contents of the attribute consist of a 16-bit 838 unsigned integer. 840 OctetString16: The contents of the attribute consist of 16 bits of 841 arbitrary data. 843 OctetString: The contents of the attribute consist of arbitrary 844 data of variable length. 846 Grouped: The contents of the attribute consist of a sequence of 847 attributes. 849 Note that extension attributes defined in the future may define 850 new attribute formats. 852 The following attribute types are defined: 854 +------+---------------------------+---------------+ 855 | Type | Attribute | Format | 856 +------+---------------------------+---------------+ 857 | 1 | BENEFICIARY-ID | Unsigned16 | 858 | 2 | FLOOR-ID | Unsigned16 | 859 | 3 | FLOOR-REQUEST-ID | Unsigned16 | 860 | 4 | PRIORITY | OctetString16 | 861 | 5 | REQUEST-STATUS | OctetString16 | 862 | 6 | ERROR-CODE | OctetString | 863 | 7 | ERROR-INFO | OctetString | 864 | 8 | PARTICIPANT-PROVIDED-INFO | OctetString | 865 | 9 | STATUS-INFO | OctetString | 866 | 10 | SUPPORTED-ATTRIBUTES | OctetString | 867 | 11 | SUPPORTED-PRIMITIVES | OctetString | 868 | 12 | USER-DISPLAY-NAME | OctetString | 869 | 13 | USER-URI | OctetString | 870 | 14 | BENEFICIARY-INFORMATION | Grouped | 871 | 15 | FLOOR-REQUEST-INFORMATION | Grouped | 872 | 16 | REQUESTED-BY-INFORMATION | Grouped | 873 | 17 | FLOOR-REQUEST-STATUS | Grouped | 874 | 18 | OVERALL-REQUEST-STATUS | Grouped | 875 +------+---------------------------+---------------+ 877 Table 2: BFCP attributes 879 M: The 'M' bit, known as the Mandatory bit, indicates whether support 880 of the attribute is required. If a Floor Control Server receives an 881 unrecognized attribute with the 'M' bit set the server MUST send an 882 Error message with parameter value 4 (Unknown Mandatory Attribute) to 883 indicate this. The 'M' bit is significant for extension attributes 884 defined in other documents only. All attributes specified in this 885 document MUST be understood by the receiver so that the setting of 886 the 'M' bit is irrelevant for these. In all other cases, the 887 unrecognized attribute is ignored but the message is processed. 889 Length: This 8-bit field contains the length of the attribute in 890 octets, excluding any padding defined for specific attributes. The 891 length of attributes that are not grouped includes the Type, 'M' bit, 892 and Length fields. The Length in grouped attributes is the length of 893 the grouped attribute itself (including Type, 'M' bit, and Length 894 fields) plus the total length (including padding) of all the included 895 attributes. 897 Attribute Contents: The contents of the different attributes are 898 defined in the following sections. 900 5.2.1. BENEFICIARY-ID 902 The following is the format of the BENEFICIARY-ID attribute. 904 0 1 2 3 905 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 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 Figure 7: BENEFICIARY-ID format 912 Beneficiary ID: This field contains a 16-bit value that uniquely 913 identifies a user within a conference. 915 Note that although the formats of the Beneficiary ID and of the 916 User ID field in the common header are similar, their semantics 917 are different. The Beneficiary ID is used in third-party floor 918 requests and to request information about a particular 919 participant. 921 5.2.2. FLOOR-ID 923 The following is the format of the FLOOR-ID attribute. 925 0 1 2 3 926 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 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Figure 8: FLOOR-ID format 933 Floor ID: This field contains a 16-bit value that uniquely identifies 934 a floor within a conference. 936 5.2.3. FLOOR-REQUEST-ID 938 The following is the format of the FLOOR-REQUEST-ID attribute. 940 0 1 2 3 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 Figure 9: FLOOR-REQUEST-ID format 948 Floor Request ID: This field contains a 16-bit value that identifies 949 a floor request at the floor control server. 951 5.2.4. PRIORITY 953 The following is the format of the PRIORITY attribute. 955 0 1 2 3 956 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 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 Figure 10: PRIORITY format 963 Prio: This field contains a 3-bit priority value, as shown in 964 Table 3. Senders SHOULD NOT use values higher than 4 in this field. 965 Receivers MUST treat values higher than 4 as if the value received 966 were 4 (Highest). The default priority value when the PRIORITY 967 attribute is missing is 2 (Normal). 969 +-------+----------+ 970 | Value | Priority | 971 +-------+----------+ 972 | 0 | Lowest | 973 | 1 | Low | 974 | 2 | Normal | 975 | 3 | High | 976 | 4 | Highest | 977 +-------+----------+ 979 Table 3: Priority values 981 Reserved: At this point, the 13 bits in the reserved field MUST be 982 set to zero by the sender of the message and MUST be ignored by the 983 receiver. 985 5.2.5. REQUEST-STATUS 987 The following is the format of the REQUEST-STATUS attribute. 989 0 1 2 3 990 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 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 Figure 11: REQUEST-STATUS format 997 Request Status: This 8-bit field contains the status of the request, 998 as described in the following table. 1000 +-------+-----------+ 1001 | Value | Status | 1002 +-------+-----------+ 1003 | 1 | Pending | 1004 | 2 | Accepted | 1005 | 3 | Granted | 1006 | 4 | Denied | 1007 | 5 | Cancelled | 1008 | 6 | Released | 1009 | 7 | Revoked | 1010 +-------+-----------+ 1012 Table 4: Request Status values 1014 Queue Position: This 8-bit field contains, when applicable, the 1015 position of the floor request in the floor request queue at the 1016 server. If the Request Status value is different from Accepted, if 1017 the floor control server does not implement a floor request queue, or 1018 if the floor control server does not want to provide the client with 1019 this information, all the bits of this field SHOULD be set to zero. 1021 A floor request is in Pending state if the floor control server needs 1022 to contact a floor chair in order to accept the floor request, but 1023 has not done it yet. Once the floor control chair accepts the floor 1024 request, the floor request is moved to the Accepted state. 1026 5.2.6. ERROR-CODE 1028 The following is the format of the ERROR-CODE attribute. 1030 0 1 2 3 1031 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 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 |0 0 0 0 1 1 0|M| Length | Error Code | | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1035 | | 1036 | Error Specific Details | 1037 / / 1038 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | | Padding | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 Figure 12: ERROR-CODE format 1044 Error Code: This 8-bit field contains an error code from the 1045 following table. If an error code is not recognized by the receiver, 1046 then the receiver MUST assume that an error exists, and therefore 1047 that the original message that triggered the Error message to be sent 1048 is processed, but the nature of the error is unclear. 1050 +-------+-----------------------------------------------------------+ 1051 | Value | Meaning | 1052 +-------+-----------------------------------------------------------+ 1053 | 1 | Conference does not Exist | 1054 | 2 | User does not Exist | 1055 | 3 | Unknown Primitive | 1056 | 4 | Unknown Mandatory Attribute | 1057 | 5 | Unauthorized Operation | 1058 | 6 | Invalid Floor ID | 1059 | 7 | Floor Request ID Does Not Exist | 1060 | 8 | You have Already Reached the Maximum Number of Ongoing | 1061 | | Floor Requests for this Floor | 1062 | 9 | Use TLS | 1063 | 10 | Unable to Parse Message | 1064 | 11 | Use DTLS | 1065 | 12 | Unsupported Version | 1066 | 13 | Incorrect Message Length | 1067 | 14 | Generic Error | 1068 +-------+-----------------------------------------------------------+ 1070 Table 5: Error Code meaning 1072 Note: The Generic Error error code is intended to be used by a 1073 BFCP entity when an error occurs and the other specific error 1074 codes do not apply. 1076 Error Specific Details: Present only for certain Error Codes. In 1077 this document, only for Error Code 4 (Unknown Mandatory Attribute). 1078 See Section 5.2.6.1 for its definition. 1080 Padding: One, two, or three octets of padding added so that the 1081 contents of the ERROR-CODE attribute is 32-bit aligned. If the 1082 attribute is already 32-bit aligned, no padding is needed. 1084 The Padding bits MUST be set to zero by the sender and MUST be 1085 ignored by the receiver. 1087 5.2.6.1. Error-Specific Details for Error Code 4 1089 The following is the format of the Error-Specific Details field for 1090 Error Code 4. 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | | 1098 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | | Unknown Type|R| Unknown Type|R| 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Unknown Type|R| Unknown Type|R| 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 Figure 13: Unknown attributes format 1106 Unknown Type: These 7-bit fields contain the Types of the attributes 1107 (which were present in the message that triggered the Error message) 1108 that were unknown to the receiver. 1110 R: At this point, this bit is reserved. It MUST be set to zero by 1111 the sender of the message and MUST be ignored by the receiver. 1113 5.2.7. ERROR-INFO 1115 The following is the format of the ERROR-INFO attribute. 1117 0 1 2 3 1118 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 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 |0 0 0 0 1 1 1|M| Length | | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1122 | | 1123 / Text / 1124 / +-+-+-+-+-+-+-+-+ 1125 | | Padding | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 Figure 14: ERROR-INFO format 1130 Text: This field contains UTF-8 [8] encoded text. 1132 In some situations, the contents of the Text field may be generated 1133 by an automaton. If this automaton has information about the 1134 preferred language of the receiver of a particular ERROR-INFO 1135 attribute, it MAY use this language to generate the Text field. 1137 Padding: One, two, or three octets of padding added so that the 1138 contents of the ERROR-INFO attribute is 32-bit aligned. The Padding 1139 bits MUST be set to zero by the sender and MUST be ignored by the 1140 receiver. If the attribute is already 32-bit aligned, no padding is 1141 needed. 1143 5.2.8. PARTICIPANT-PROVIDED-INFO 1145 The following is the format of the PARTICIPANT-PROVIDED-INFO 1146 attribute. 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 |0 0 0 1 0 0 0|M| Length | | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1153 | | 1154 / Text / 1155 / +-+-+-+-+-+-+-+-+ 1156 | | Padding | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 Figure 15: PARTICIPANT-PROVIDED-INFO format 1161 Text: This field contains UTF-8 [8] encoded text. 1163 Padding: One, two, or three octets of padding added so that the 1164 contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit 1165 aligned. The Padding bits MUST be set to zero by the sender and MUST 1166 be ignored by the receiver. If the attribute is already 32-bit 1167 aligned, no padding is needed. 1169 5.2.9. STATUS-INFO 1171 The following is the format of the STATUS-INFO attribute. 1173 0 1 2 3 1174 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 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 |0 0 0 1 0 0 1|M| Length | | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1178 | | 1179 / Text / 1180 / +-+-+-+-+-+-+-+-+ 1181 | | Padding | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 Figure 16: STATUS-INFO format 1186 Text: This field contains UTF-8 [8] encoded text. 1188 In some situations, the contents of the Text field may be generated 1189 by an automaton. If this automaton has information about the 1190 preferred language of the receiver of a particular STATUS-INFO 1191 attribute, it MAY use this language to generate the Text field. 1193 Padding: One, two, or three octets of padding added so that the 1194 contents of the STATUS-INFO attribute is 32-bit aligned. The Padding 1195 bits MUST be set to zero by the sender and MUST be ignored by the 1196 receiver. If the attribute is already 32-bit aligned, no padding is 1197 needed. 1199 5.2.10. SUPPORTED-ATTRIBUTES 1201 The following is the format of the SUPPORTED-ATTRIBUTES attribute. 1203 0 1 2 3 1204 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 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 |0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R| 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | | 1211 / / 1212 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | | Padding | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 Figure 17: SUPPORTED-ATTRIBUTES format 1218 Supp. Attr.: These fields contain the Types of the attributes that 1219 are supported by the floor control server in the following format: 1221 R: Reserved: This bit MUST be set to zero upon transmission and MUST 1222 be ignored upon reception. 1224 Padding: One, two, or three octets of padding added so that the 1225 contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If 1226 the attribute is already 32-bit aligned, no padding is needed. 1228 The Padding bits MUST be set to zero by the sender and MUST be 1229 ignored by the receiver. 1231 5.2.11. SUPPORTED-PRIMITIVES 1233 The following is the format of the SUPPORTED-PRIMITIVES attribute. 1235 0 1 2 3 1236 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 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 |0 0 0 1 0 1 1|M| Length | Primitive | Primitive | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Primitive | Primitive | Primitive | Primitive | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | | 1243 / / 1244 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | | Padding | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 Figure 18: SUPPORTED-PRIMITIVES format 1250 Primitive: These fields contain the types of the BFCP messages that 1251 are supported by the floor control server. See Table 1 for the list 1252 of BFCP primitives. 1254 Padding: One, two, or three octets of padding added so that the 1255 contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If 1256 the attribute is already 32-bit aligned, no padding is needed. 1258 The Padding bits MUST be set to zero by the sender and MUST be 1259 ignored by the receiver. 1261 5.2.12. USER-DISPLAY-NAME 1263 The following is the format of the USER-DISPLAY-NAME attribute. 1265 0 1 2 3 1266 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 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 |0 0 0 1 1 0 0|M| Length | | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1270 | | 1271 / Text / 1272 / +-+-+-+-+-+-+-+-+ 1273 | | Padding | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 Figure 19: USER-DISPLAY-NAME format 1278 Text: This field contains the UTF-8 encoded name of the user. 1280 Padding: One, two, or three octets of padding added so that the 1281 contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The 1282 Padding bits MUST be set to zero by the sender and MUST be ignored by 1283 the receiver. If the attribute is already 32-bit aligned, no padding 1284 is needed. 1286 5.2.13. USER-URI 1288 The following is the format of the USER-URI attribute. 1290 0 1 2 3 1291 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 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 |0 0 0 1 1 0 1|M| Length | | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1295 | | 1296 / Text / 1297 / +-+-+-+-+-+-+-+-+ 1298 | | Padding | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 Figure 20: USER-URI format 1303 Text: This field contains the UTF-8 encoded user's contact URI, that 1304 is, the URI used by the user to set up the resources (e.g., media 1305 streams) that are controlled by BFCP. For example, in the context of 1306 a conference set up by SIP, the USER-URI attribute would carry the 1307 SIP URI of the user. 1309 Messages containing a user's URI in a USER-URI attribute also 1310 contain the user's User ID. This way, a client receiving such a 1311 message can correlate the user's URI (e.g., the SIP URI the user 1312 used to join a conference) with the user's User ID. 1314 Padding: One, two, or three octets of padding added so that the 1315 contents of the USER-URI attribute is 32-bit aligned. The Padding 1316 bits MUST be set to zero by the sender and MUST be ignored by the 1317 receiver. If the attribute is already 32-bit aligned, no padding is 1318 needed. 1320 5.2.14. BENEFICIARY-INFORMATION 1322 The BENEFICIARY-INFORMATION attribute is a grouped attribute that 1323 consists of a header, which is referred to as BENEFICIARY- 1324 INFORMATION-HEADER, followed by a sequence of attributes. The 1325 following is the format of the BENEFICIARY-INFORMATION-HEADER: 1327 0 1 2 3 1328 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 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 |0 0 0 1 1 1 0|M| Length | Beneficiary ID | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 Figure 21: BENEFICIARY-INFORMATION-HEADER format 1335 Beneficiary ID: This field contains a 16-bit value that uniquely 1336 identifies a user within a conference. 1338 The following is the ABNF (Augmented Backus-Naur Form) [4] of the 1339 BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE 1340 refers to extension attributes that may be defined in the future.) 1342 BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) 1343 [USER-DISPLAY-NAME] 1344 [USER-URI] 1345 *(EXTENSION-ATTRIBUTE) 1347 Figure 22: BENEFICIARY-INFORMATION format 1349 5.2.15. FLOOR-REQUEST-INFORMATION 1351 The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that 1352 consists of a header, which is referred to as FLOOR-REQUEST- 1353 INFORMATION-HEADER, followed by a sequence of attributes. The 1354 following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: 1356 0 1 2 3 1357 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 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 |0 0 0 1 1 1 1|M| Length | Floor Request ID | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format 1364 Floor Request ID: This field contains a 16-bit value that identifies 1365 a floor request at the floor control server. 1367 The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped 1368 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1369 may be defined in the future.) 1371 FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) 1372 [OVERALL-REQUEST-STATUS] 1373 1*(FLOOR-REQUEST-STATUS) 1374 [BENEFICIARY-INFORMATION] 1375 [REQUESTED-BY-INFORMATION] 1376 [PRIORITY] 1377 [PARTICIPANT-PROVIDED-INFO] 1378 *(EXTENSION-ATTRIBUTE) 1380 Figure 24: FLOOR-REQUEST-INFORMATION format 1382 5.2.16. REQUESTED-BY-INFORMATION 1384 The REQUESTED-BY-INFORMATION attribute is a grouped attribute that 1385 consists of a header, which is referred to as REQUESTED-BY- 1386 INFORMATION-HEADER, followed by a sequence of attributes. The 1387 following is the format of the REQUESTED-BY-INFORMATION-HEADER: 1389 0 1 2 3 1390 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 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 |0 0 1 0 0 0 0|M| Length | Requested-by ID | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 Figure 25: REQUESTED-BY-INFORMATION-HEADER format 1397 Requested-by ID: This field contains a 16-bit value that uniquely 1398 identifies a user within a conference. 1400 The following is the ABNF of the REQUESTED-BY-INFORMATION grouped 1401 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1402 may be defined in the future.) 1404 REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER) 1405 [USER-DISPLAY-NAME] 1406 [USER-URI] 1407 *(EXTENSION-ATTRIBUTE) 1409 Figure 26: REQUESTED-BY-INFORMATION format 1411 5.2.17. FLOOR-REQUEST-STATUS 1413 The FLOOR-REQUEST-STATUS attribute is a grouped attribute that 1414 consists of a header, which is referred to as FLOOR-REQUEST-STATUS- 1415 HEADER, followed by a sequence of attributes. The following is the 1416 format of the FLOOR-REQUEST-STATUS-HEADER: 1418 0 1 2 3 1419 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 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 |0 0 1 0 0 0 1|M| Length | Floor ID | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 Figure 27: FLOOR-REQUEST-STATUS-HEADER format 1426 Floor ID: this field contains a 16-bit value that uniquely identifies 1427 a floor within a conference. 1429 The following is the ABNF of the FLOOR-REQUEST-STATUS grouped 1430 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1431 may be defined in the future.) 1433 FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) 1434 [REQUEST-STATUS] 1435 [STATUS-INFO] 1436 *(EXTENSION-ATTRIBUTE) 1438 Figure 28: FLOOR-REQUEST-STATUS format 1440 5.2.18. OVERALL-REQUEST-STATUS 1442 The OVERALL-REQUEST-STATUS attribute is a grouped attribute that 1443 consists of a header, which is referred to as OVERALL-REQUEST-STATUS- 1444 HEADER, followed by a sequence of attributes. The following is the 1445 format of the OVERALL-REQUEST-STATUS-HEADER: 1447 0 1 2 3 1448 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 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 |0 0 1 0 0 1 0|M| Length | Floor Request ID | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 Figure 29: OVERALL-REQUEST-STATUS-HEADER format 1455 Floor Request ID: this field contains a 16-bit value that identifies 1456 a floor request at the floor control server. 1458 The following is the ABNF of the OVERALL-REQUEST-STATUS grouped 1459 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1460 may be defined in the future.) 1462 OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER) 1463 [REQUEST-STATUS] 1464 [STATUS-INFO] 1465 *(EXTENSION-ATTRIBUTE) 1467 Figure 30: OVERALL-REQUEST-STATUS format 1469 5.3. Message Format 1471 This section contains the normative ABNF (Augmented Backus-Naur Form) 1472 [4] of the BFCP messages. Extension attributes that may be defined 1473 in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. 1475 5.3.1. FloorRequest 1477 Floor participants request a floor by sending a FloorRequest message 1478 to the floor control server. The following is the format of the 1479 FloorRequest message: 1481 FloorRequest = (COMMON-HEADER) 1482 1*(FLOOR-ID) 1483 [BENEFICIARY-ID] 1484 [PARTICIPANT-PROVIDED-INFO] 1485 [PRIORITY] 1486 *(EXTENSION-ATTRIBUTE) 1488 Figure 31: FloorRequest format 1490 5.3.2. FloorRelease 1492 Floor participants release a floor by sending a FloorRelease message 1493 to the floor control server. Floor participants also use the 1494 FloorRelease message to cancel pending floor requests. The following 1495 is the format of the FloorRelease message: 1497 FloorRelease = (COMMON-HEADER) 1498 (FLOOR-REQUEST-ID) 1499 *(EXTENSION-ATTRIBUTE) 1501 Figure 32: FloorRelease format 1503 5.3.3. FloorRequestQuery 1505 Floor participants and floor chairs request information about a floor 1506 request by sending a FloorRequestQuery message to the floor control 1507 server. The following is the format of the FloorRequestQuery 1508 message: 1510 FloorRequestQuery = (COMMON-HEADER) 1511 (FLOOR-REQUEST-ID) 1512 *(EXTENSION-ATTRIBUTE) 1514 Figure 33: FloorRequestQuery format 1516 5.3.4. FloorRequestStatus 1518 The floor control server informs floor participants and floor chairs 1519 about the status of their floor requests by sending them 1520 FloorRequestStatus messages. The following is the format of the 1521 FloorRequestStatus message: 1523 FloorRequestStatus = (COMMON-HEADER) 1524 (FLOOR-REQUEST-INFORMATION) 1525 *(EXTENSION-ATTRIBUTE) 1527 Figure 34: FloorRequestStatus format 1529 5.3.5. UserQuery 1531 Floor participants and floor chairs request information about a 1532 participant and the floor requests related to this participant by 1533 sending a UserQuery message to the floor control server. The 1534 following is the format of the UserQuery message: 1536 UserQuery = (COMMON-HEADER) 1537 [BENEFICIARY-ID] 1538 *(EXTENSION-ATTRIBUTE) 1540 Figure 35: UserQuery format 1542 5.3.6. UserStatus 1544 The floor control server provides information about participants and 1545 their related floor requests to floor participants and floor chairs 1546 by sending them UserStatus messages. The following is the format of 1547 the UserStatus message: 1549 UserStatus = (COMMON-HEADER) 1550 [BENEFICIARY-INFORMATION] 1551 *(FLOOR-REQUEST-INFORMATION) 1552 *(EXTENSION-ATTRIBUTE) 1554 Figure 36: UserStatus format 1556 5.3.7. FloorQuery 1558 Floor participants and floor chairs request information about a floor 1559 or floors by sending a FloorQuery message to the floor control 1560 server. The following is the format of the FloorRequest message: 1562 FloorQuery = (COMMON-HEADER) 1563 *(FLOOR-ID) 1564 *(EXTENSION-ATTRIBUTE) 1566 Figure 37: FloorQuery format 1568 5.3.8. FloorStatus 1570 The floor control server informs floor participants and floor chairs 1571 about the status (e.g., the current holder) of a floor by sending 1572 them FloorStatus messages. The following is the format of the 1573 FloorStatus message: 1575 FloorStatus = (COMMON-HEADER) 1576 [FLOOR-ID] 1577 *(FLOOR-REQUEST-INFORMATION) 1578 *(EXTENSION-ATTRIBUTE) 1580 Figure 38: FloorStatus format 1582 5.3.9. ChairAction 1584 Floor chairs send instructions to floor control servers by sending 1585 them ChairAction messages. The following is the format of the 1586 ChairAction message: 1588 ChairAction = (COMMON-HEADER) 1589 (FLOOR-REQUEST-INFORMATION) 1590 *(EXTENSION-ATTRIBUTE) 1592 Figure 39: ChairAction format 1594 5.3.10. ChairActionAck 1596 Floor control servers confirm that they have accepted a ChairAction 1597 message by sending a ChairActionAck message. The following is the 1598 format of the ChairActionAck message: 1600 ChairActionAck = (COMMON-HEADER) 1601 *(EXTENSION-ATTRIBUTE) 1603 Figure 40: ChairActionAck format 1605 5.3.11. Hello 1607 Floor participants and floor chairs check the liveliness of floor 1608 control servers by sending a Hello message. The following is the 1609 format of the Hello message: 1611 Hello = (COMMON-HEADER) 1612 *(EXTENSION-ATTRIBUTE) 1614 Figure 41: Hello format 1616 5.3.12. HelloAck 1618 Floor control servers confirm that they are alive on reception of a 1619 Hello message by sending a HelloAck message. The following is the 1620 format of the HelloAck message: 1622 HelloAck = (COMMON-HEADER) 1623 (SUPPORTED-PRIMITIVES) 1624 (SUPPORTED-ATTRIBUTES) 1625 *(EXTENSION-ATTRIBUTE) 1627 Figure 42: HelloAck format 1629 5.3.13. Error 1631 Floor control servers inform floor participants and floor chairs 1632 about errors processing requests by sending them Error messages. The 1633 following is the format of the Error message: 1635 Error = (COMMON-HEADER) 1636 (ERROR-CODE) 1637 [ERROR-INFO] 1638 *(EXTENSION-ATTRIBUTE) 1640 Figure 43: Error format 1642 5.3.14. FloorRequestStatusAck 1644 When communicating over an unreliable transport, floor participants 1645 and chairs acknowledge the receipt of a subsequent FloorRequestStatus 1646 message from the floor control server (cf. Section 13.1.2) by sending 1647 a FloorRequestStatusAck message. The following is the format of the 1648 FloorRequestStatusAck message: 1650 FloorRequestStatusAck = (COMMON-HEADER) 1651 *(EXTENSION-ATTRIBUTE) 1653 Figure 44: FloorRequestStatusAck format 1655 5.3.15. FloorStatusAck 1657 When communicating over an unreliable transport, floor participants 1658 and chairs acknowledge the receipt of a subsequent FloorStatus 1659 message from the floor control server (cf. Section 13.5.2) by sending 1660 a FloorStatusAck message. The following is the format of the 1661 FloorStatusAck message: 1663 FloorStatusAck = (COMMON-HEADER) 1664 *(EXTENSION-ATTRIBUTE) 1666 Figure 45: FloorStatusAck format 1668 5.3.16. Goodbye 1670 BFCP entities communicating over an unreliable transport that wish to 1671 dissociate themselves from their remote participant do so through the 1672 transmission of a Goodbye. The following is the format of the 1673 Goodbye message: 1675 Goodbye = (COMMON-HEADER) 1676 *(EXTENSION-ATTRIBUTE) 1678 Figure 46: Goodbye format 1680 5.3.17. GoodbyeAck 1682 BFCP entities communicating over an unreliable transport should 1683 acknowledge the receipt of a Goodbye message from a peer. The 1684 following is the format of the GoodbyeAck message: 1686 GoodbyeAck = (COMMON-HEADER) 1687 *(EXTENSION-ATTRIBUTE) 1689 Figure 47: GoodbyeAck format 1691 6. Transport 1693 The transport over which BFCP entities exchange messages depends on 1694 how clients obtain information to contact the floor control server 1695 (e.g., using an SDP offer/answer exchange [9] or the procedure 1696 specified in [3]). Two transports are supported: TCP, appropriate 1697 where connectivity is not impeded by network elements such as NAT 1698 devices or media relays; and UDP for those deployments where TCP may 1699 not be applicable or appropriate. 1701 Informational note: In practice products are configured to try one 1702 transport initially and use the other one as a fallback. Whether 1703 TCP or UDP is chosen as underlying transport depends on type of 1704 product and the nature of the environment it is deployed. Here 1705 Appendix B are important to consider. 1707 6.1. Reliable Transport 1709 BFCP entities may elect to exchange BFCP messages using TCP 1710 connections. TCP provides an in-order reliable delivery of a stream 1711 of bytes. Consequently, message framing needs to be implemented in 1712 the application layer. BFCP implements application-layer framing 1713 using TLV-encoded attributes. 1715 A client MUST NOT use more than one TCP connection to communicate 1716 with a given floor control server within a conference. Nevertheless, 1717 if the same physical box handles different clients (e.g., a floor 1718 chair and a floor participant), which are identified by different 1719 User IDs, a separate connection per client is allowed. 1721 If a BFCP entity (a client or a floor control server) receives data 1722 that cannot be parsed, the entity MUST close the TCP connection, and 1723 the connection SHOULD be reestablished. Similarly, if a TCP 1724 connection cannot deliver a BFCP message and times out or receives an 1725 ICMP port unreachable message mid-connection, the TCP connection 1726 SHOULD be reestablished. 1728 The way connection reestablishment is handled depends on how the 1729 client obtains information to contact the floor control server. Once 1730 the TCP connection is reestablished, the client MAY resend those 1731 messages for which it did not get a response from the floor control 1732 server. 1734 If a floor control server detects that the TCP connection towards one 1735 of the floor participants is lost, it is up to the local policy of 1736 the floor control server what to do with the pending floor requests 1737 of the floor participant. In any case, it is RECOMMENDED that the 1738 floor control server keep the floor requests (i.e., that it does not 1739 cancel them) while the TCP connection is reestablished. 1741 If a client wishes to end its BFCP connection with a floor control 1742 server, the client closes (i.e., a graceful close) the TCP connection 1743 towards the floor control server. If a floor control server wishes 1744 to end its BFCP connection with a client (e.g., the Focus of the 1745 conference informs the floor control server that the client has been 1746 kicked out from the conference), the floor control server closes 1747 (i.e., a graceful close) the TCP connection towards the client. 1749 6.2. Unreliable Transport 1751 BFCP entities may elect to exchange BFCP messages using UDP 1752 datagrams. UDP is an unreliable transport where neither delivery nor 1753 ordering is assured. Each BFCP UDP datagram MUST contain exactly one 1754 BFCP message or message fragment. To keep large BFCP messages from 1755 being fragmented at the IP layer, the fragmentation of BFCP messages 1756 that exceed the path MTU size is performed at the BFCP level. 1757 Considerations related to fragmentation are covered in Section 6.2.3. 1758 The message format for BFCP messages is the same regardless of 1759 whether the messages are sent in UDP datagrams or over a TCP stream. 1761 Clients MUST announce their presence to the floor control server by 1762 sending a Hello message. The floor control server responds to the 1763 Hello message with a HelloAck message. The client considers the 1764 floor control service as present and available only upon receiving 1765 the HelloAck message. Situations where the floor control service is 1766 considered to have become unavailable due to ICMP messages is 1767 described in Section 6.2.2 and the behavior when timers fire is 1768 described in Section 8.3. 1770 As described in Section 8, each request sent by a floor participant 1771 or chair forms a client transaction that expects an acknowledgement 1772 message back from the floor control server within a retransmission 1773 window. Concordantly, messages sent by the floor control server that 1774 initiate new transactions (e.g., FloorStatus announcements as part of 1775 a FloorQuery subscription) require acknowledgement messages from the 1776 floor participant and chair entities to which they were sent. 1778 If a Floor Control Server receives data that cannot be parsed, the 1779 receiving server MUST send an Error message with parameter value 10 1780 (Unable to parse message) indicating receipt of a malformed message, 1781 given that it is possible to parse the received message to such an 1782 extent that an Error message may be built. 1784 Entities MUST have at most one outstanding request transaction per 1785 peer at any one time. Implicit subscriptions occur for a client- 1786 initiated request transaction whose acknowledgement is implied by the 1787 first server-initiated response for that transaction, followed by 1788 zero of more subsequent server-initiated messages corresponding to 1789 the same transaction. An example is a FloorRequest message for which 1790 there are potentially multiple responses from the floor control 1791 server as it processes intermediate states until a terminal state 1792 (e.g., Granted or Denied) is attained. The subsequent changes in 1793 state for the request are new transactions whose Transaction ID is 1794 determined by the floor control server and whose receipt by the 1795 client participant is acknowledged with a FloorRequestStatusAck 1796 message. 1798 By restricting entities to having at most one pending transaction 1799 open in a BFCP connection, both the out-of-order receipt of messages 1800 as well as the possibility for congestion are mitigated. Additional 1801 details regarding congestion control are provided in Section 6.2.1. 1802 A server-initiated request (e.g., a FloorStatus with an update from 1803 the floor control server) received by a participant before the 1804 initial FloorRequestStatus message that closes the client-initiated 1805 transaction that was instigated by the FloorRequest MUST be treated 1806 as superseding the information conveyed in any such late arriving 1807 response. As the floor control server cannot send a second update to 1808 the implicit floor status subscription until the first is 1809 acknowledged, ordinality is maintained. 1811 If a client wishes to end its BFCP connection with a floor control 1812 server, it is REQUIRED that the client send a Goodbye message to 1813 dissociate itself from any allocated resources. If a floor control 1814 server wishes to end its BFCP connection with a client (e.g., the 1815 Focus of the conference informs the floor control server that the 1816 client has been kicked out from the conference), it is REQUIRED that 1817 the floor control server send a Goodbye message towards the client. 1819 RFC 5018 [3] specifies how to establish a TCP connection to a floor 1820 control server outside the context of an offer/answer exchange. When 1821 using UDP the same set of data is needed for a BFCP connection as 1822 listed in [3], Section 3, i.e. transport address of the server, the 1823 conference identifier, and the user identifier. The procedures and 1824 considerations for resolving a host name into an IP address also 1825 applies to BFCP over an unreliable transport. In [3], Section 4 1826 applies, but when using BFCP over an unreliable transport the floor 1827 control server that receives a BFCP message over UDP (no DTLS) SHOULD 1828 request the use of DTLS by generating an Error message with an Error 1829 code with a value of 11 (Use DTLS). A floor control server that is 1830 configured to require DTLS MUST request the use of DTLS this way. 1831 The recommendations for authentication in [3], Section 5 and the 1832 security considerations in [3], Section 6 also apply when an 1833 unreliable transport is used, both for certificate-based server 1834 authentication and for client authentication based on a pre-shared 1835 secret. 1837 6.2.1. Congestion Control 1839 BFCP may be characterized to generate "low data-volume" traffic, per 1840 the classification in [25]. Nevertheless is it necessary to ensure 1841 suitable and necessary congestion control mechanisms are used for 1842 BFCP over UDP. As described in Section 6.2, within the same BFCP 1843 connection, every entity - client or server - is only allowed to send 1844 one request at a time, and await the acknowledging response. This 1845 way at most one datagram is sent per RTT given the message is not 1846 lost during transmission. In case the message is lost, the request 1847 retransmission timer T1 specified in Section 8.3.1 will fire and the 1848 message is retransmitted up to three times, in addition to the 1849 original transmission of the message. The default initial interval 1850 MUST be set to 500ms and the interval MUST be doubled after each 1851 retransmission attempt. This is identical to the specification of 1852 the timer A and its initial value T1 in SIP as described in Section 1853 17.1.1.2 of [16]. 1855 6.2.2. ICMP Error Handling 1857 If a BFCP entity receives an ICMP port unreachable message mid- 1858 connection, the entity MUST treat the BFCP connection as closed 1859 (e.g., an implicit Goodbye message from the peer). The entity MAY 1860 attempt to re-establish the BFCP connection afresh. The new BFCP 1861 connection will appear as originating from a wholly new floor 1862 participant, chair or floor control server with all state previously 1863 held about that participant lost. 1865 Informational note: The recommendation to treat the connection as 1866 closed in this case, stems from the fact that the peer entities 1867 cannot rely on IP and port tuple to uniquely identify the 1868 participant, nor would extending Hello to include an attribute 1869 that advertised what identity the entity previously was assigned 1870 (i.e., a User ID) be acceptable due to session hijacking. 1872 In deployments where NAT appliances or other such devices are present 1873 and affecting port reachability for each entity, one possibility is 1874 to utilize the peer connectivity checks, relay use and NAT pinhole 1875 maintenance mechanisms defined in ICE [15]. 1877 6.2.3. Fragmentation Handling 1879 When using UDP, a single BFCP message could be fragmented at the IP 1880 layer if its overall size exceeds the path MTU of the network. To 1881 avoid this happening at the IP layer, a fragmentation scheme for BFCP 1882 is defined below. 1884 BFCP is designed for achieving small message size, due to the binary 1885 encoding as described in Section 1. The fragmentation scheme is 1886 therefore deliberately kept simple and straightforward, since the 1887 probability of fragmentation of BFCP messages being required is 1888 small. By design, the fragmentation scheme does not acknowledge 1889 individual BFCP message fragments. The whole BFCP message is 1890 acknowledged if received completely. 1892 BFCP entities should consider the MTU size available between the 1893 sender and the receiver and MAY run MTU discovery, such as 1894 [20][21][22], for this purpose. 1896 When transmitting a BFCP message with size greater than the path MTU, 1897 the sender MUST fragment the message into a series of N contiguous 1898 data ranges. The value for N is defined as ceil(message size / MTU 1899 size), where ceil is the integer ceiling function. The sender then 1900 creates N BFCP fragment messages (one for each data range) with the 1901 same Transaction ID. The size of each of these N messages MUST be 1902 smaller than the path MTU. The F flag in the COMMON-HEADER is set to 1903 indicate fragmentation of the BFCP message. 1905 For each of these fragments the Fragment Offset and Fragment Length 1906 fields are included in the COMMON-HEADER. The Fragment Offset field 1907 denotes the number of bytes contained in the previous fragments. The 1908 Fragment Length contains the length of the fragment itself. Note 1909 that the Payload Length field contains the length of the entire, 1910 unfragmented message. 1912 When a BFCP implementation receives a BFCP message fragment, it MUST 1913 buffer the fragment until either it has received the entire BFCP 1914 message, or until the Response Retransmission Timer expires. The 1915 state machine should handle the BFCP message only after all the 1916 fragments for the message have been received. 1918 If a fragment of a BFCP message is lost, the sender will not receive 1919 an acknowledgement for the message. Therefore the sender will 1920 retransmit the message with same transaction ID as specified in 1921 Section 8.3. If the acknowledgement message sent by the receiver is 1922 lost, then the entire message will be resent by the sender. The 1923 receiver MUST then retransmit the acknowledgement. The receiver MAY 1924 discard an incomplete buffer utilizing the Response Retransmission 1925 Timer, starting the timer after the receipt of the first fragment. 1927 A Denial of Service (DoS) attack utilizing the fragmentation 1928 scheme described above is mitigated by the fact that the Response 1929 Retransmission Timer is started after receipt of the first BFCP 1930 message fragment. In addition, the Payload Length field can be 1931 compared with the Fragment Offset and Fragment Length fields to 1932 verify the message fragments as they arrive. To make DoS attacks 1933 with spoofed IP addresses difficult, BFCP entities SHOULD use the 1934 cookie exchange mechanism in DTLS [7]. 1936 When deciding message fragment size based on path MTU, the BFCP 1937 fragmentation handling should take into account how the DTLS record 1938 framing expands the datagram size as described in Section 4.1.1.1 of 1939 [7]. 1941 6.2.4. NAT Traversal 1943 One of the key benefits when using UDP for BFCP communication is the 1944 ability to leverage the existing NAT traversal infrastructure and 1945 strategies deployed to facilitate transport of the media associated 1946 with the video conferencing sessions. Depending on the given 1947 deployment, this infrastructure typically includes some subset of ICE 1948 [15]. 1950 In order to facilitate the initial establishment of NAT bindings, and 1951 to maintain those bindings once established, BFCP entities using an 1952 unreliable transport are RECOMMENDED to use STUN [11] Binding 1953 Indication for keep-alives, as described for ICE [15]. [23], Section 1954 6.7 provides useful recommendations for middlebox interaction when 1955 DTLS is used. 1957 Informational note: Since the version number is set to 2 when BFCP 1958 is used over an unreliable transport, cf. the Ver field in 1959 Section 5.1, it is straight forward to distinguish between STUN 1960 and BFCP packets even without checking the STUN magic cookie [11]. 1962 In order to facilitate traversal of BFCP packets through NATs, BFCP 1963 entities using an unreliable transport are RECOMMENDED to use 1964 symmetric ports for sending and receiving BFCP packets, as 1965 recommended for RTP/RTCP [10]. 1967 7. Lower-Layer Security 1969 BFCP relies on lower-layer security mechanisms to provide replay and 1970 integrity protection and confidentiality. BFCP floor control servers 1971 and clients (which include both floor participants and floor chairs) 1972 MUST support TLS for transport over TCP [6] and MUST support DTLS [7] 1973 for transport over UDP. Any BFCP entity MAY support other security 1974 mechanisms. 1976 BFCP entities MUST support, at a minimum, the 1977 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. 1979 Which party, the client or the floor control server, acts as the TLS/ 1980 DTLS server depends on how the underlying TLS/DTLS connection is 1981 established. For a TCP/TLS connection established using an SDP 1982 offer/answer exchange [9], the answerer (which may be the client or 1983 the floor control server) always acts as the TLS server. If the TCP 1984 connection is lost, the active endpoint, i.e., the current TLS 1985 client, is responsible for re-establishing the TCP connection. 1986 Unless a new TLS session is negotiated, subsequent SDP offers and 1987 answers will not impact the previously negotiated TLS roles. 1989 For a UDP/DTLS connection established using the an SDP offer/answer 1990 exchange, either party can be the DTLS server depending on the setup 1991 attributes exchanged; examples can be found in [23]. 1993 8. Protocol Transactions 1995 In BFCP, there are two types of transactions: client-initiated 1996 transactions and server-initiated transactions. 1998 Client-initiated transactions consist of a request from a client to a 1999 floor control server and a response from the floor control server to 2000 the client. The request carries a Transaction ID in its common 2001 header, which the floor control server copies into the response. 2002 Clients use Transaction ID values to match responses with previously 2003 issued requests. 2005 Server-initiated transactions have different requirements and 2006 behavior depending on underlying transport: 2008 When using a reliable transport, server-initiated transactions 2009 consist of a single message from a floor control server to a 2010 client (notifications). Since they do not trigger any response, 2011 their Transaction ID is set to 0. 2013 When using an unreliable transport, server-initiated transactions 2014 consist of a request from a floor control server to a client and a 2015 response from the client to the floor control server. The 2016 Transaction ID MUST be non-zero and unique in the context of 2017 outstanding transactions over an unreliable transport. The 2018 request carries a Transaction ID in its common header, which the 2019 client copies into the response. Floor control servers use 2020 Transaction ID values to match responses with previously issued 2021 requests. 2023 When using BFCP over an unreliable transport, it is important that 2024 the initiator of a transaction choose a Transaction ID value that 2025 lets the receiver distinguish the reception of the next message in a 2026 sequence of BFCP messages from a retransmission of a previous 2027 message. Therefore, BFCP entities using an unreliable transport MUST 2028 use monotonically increasing Transaction ID values (except for wrap- 2029 around). 2031 When using BFCP over an unreliable transport, all requests will use 2032 retransmission timer T1 (see Section 8.3) until the transaction is 2033 completed. 2035 8.1. Client Behavior 2037 A client starting a client-initiated transaction MUST set the 2038 Conference ID in the common header of the message to the Conference 2039 ID for the conference that the client obtained previously. 2041 The client MUST set the Transaction ID value in the common header to 2042 a number that is different from 0 and that MUST NOT be reused in 2043 another message from the client until a response from the server is 2044 received for the transaction. The client uses the Transaction ID 2045 value to match this message with the response from the floor control 2046 server. 2048 8.2. Server Behavior 2050 A floor control server sending a response within a client-initiated 2051 transaction MUST copy the Conference ID, the Transaction ID, and the 2052 User ID from the request received from the client into the response. 2054 Server-initiated transactions MUST contain a Transaction ID equal to 2055 0 when BFCP is used over a reliable transport. Over an unreliable 2056 transport, the Transaction ID shall have the same properties as for 2057 client-initiated transactions: the server MUST set the Transaction ID 2058 value in the common header to a number that is different from 0 and 2059 that MUST NOT be reused, i.e. monotonically increasing valuse as 2060 defined in Section 8. The server uses the Transaction ID value to 2061 match this message with the response from the floor participant or 2062 floor chair. 2064 8.3. Timers 2066 When BFCP entities are communicating over an unreliable transport, 2067 two retransmission timers are employed to help mitigate against loss 2068 of datagrams. Retransmission and response caching are not required 2069 when BFCP entities communicate over a reliable transport. 2071 8.3.1. Request Retransmission Timer, T1 2073 T1 is a timer that schedules retransmission of a request until an 2074 appropriate response is received or until the maximum number of 2075 retransmissions have occurred. The timer doubles on each re- 2076 transmit, failing after three unacknowledged retransmission attempts. 2078 If a valid response is not received for a client- or server-initiated 2079 transaction, the implementation MUST consider the BFCP connection as 2080 failed. Implementations SHOULD follow the reestablishment procedure 2081 described in section 6 (e.g., initiate a new offer/answer [12] 2082 exchange). 2084 8.3.2. Response Retransmission Timer, T2 2086 T2 is a timer that, when fires, signals that the BFCP entity can 2087 release knowledge of the transaction against which it is running. It 2088 is started upon the first transmission of the response to a request 2089 and is the only mechanism by which that response is released by the 2090 BFCP entity. Any subsequent retransmissions of the same request can 2091 be responded to by replaying the cached response, whilst that value 2092 is retained until the timer has fired. Refer to Section 6.2.3 for 2093 the role this timer has in the fragmentation handling scheme. 2095 8.3.3. Timer Values 2097 The table below defines the different timers required when BFCP 2098 entities communicate over an unreliable transport. 2100 +-------+--------------------------------------+---------+ 2101 | Timer | Description | Value/s | 2102 +-------+--------------------------------------+---------+ 2103 | T1 | Initial request retransmission timer | 0.5s | 2104 | T2 | Response retransmission timer | 10s | 2105 +-------+--------------------------------------+---------+ 2107 Table 6: Timers 2109 The default value for T1 is 500 ms, this is an estimate of the RTT 2110 for completing the transaction. T1 MAY be chosen larger, and this is 2111 RECOMMENDED if it is known in advance that the RTT is larger. 2113 Regardless of the value of T1, the exponential backoffs on 2114 retransmissions described in Section 8.3.1 MUST be used. 2116 T2 SHALL be set such that it encompasses all legal retransmissions 2117 per T1 plus a factor to accommodate network latency between BFCP 2118 entities. The default value is based on the sum of the three 2119 retransmissions related to T1 using its default value (7.5s) and an 2120 extra 2.5s is added to take into account potential messages in 2121 transit due to latency. 2123 9. Authentication and Authorization 2125 BFCP clients SHOULD authenticate the floor control server before 2126 sending any BFCP message to it or accepting any BFCP message from it. 2127 Similarly, floor control servers SHOULD authenticate a client before 2128 accepting any BFCP message from it or sending any BFCP message to it. 2130 BFCP supports TLS/DTLS mutual authentication between clients and 2131 floor control servers, as specified in Section 9.1. This is the 2132 RECOMMENDED authentication mechanism in BFCP. 2134 Note that future extensions may define additional authentication 2135 mechanisms. 2137 In addition to authenticating BFCP messages, floor control servers 2138 need to authorize them. On receiving an authenticated BFCP message, 2139 the floor control server checks whether the client sending the 2140 message is authorized. If the client is not authorized to perform 2141 the operation being requested, the floor control server generates an 2142 Error message, as described in Section 13.8, with an Error code with 2143 a value of 5 (Unauthorized Operation). Messages from a client that 2144 cannot be authorized MUST NOT be processed further. 2146 9.1. TLS/DTLS Based Mutual Authentication 2148 BFCP supports TLS/DTLS based mutual authentication between clients 2149 and floor control servers. If TLS/DTLS is used, an initial 2150 integrity-protected channel is REQUIRED between the client and the 2151 floor control server that can be used to exchange their self-signed 2152 certificates or, more commonly, the fingerprints of these 2153 certificates. These certificates are used at TLS/DTLS establishment 2154 time. 2156 The implementation of such an integrity-protected channel using 2157 SIP and the SDP offer/answer model is described in [9]. 2159 BFCP messages received over an authenticated TLS/DTLS connection are 2160 considered authenticated. A floor control server that receives a 2161 BFCP message over TCP/UDP (no TLS/DTLS) MAY request the use of TLS/ 2162 DTLS by generating an Error message, as described in Section 13.8, 2163 with an Error code with a value of 9 (Use TLS) or a value of 11 (Use 2164 DTLS) respectively. Clients configured to require the use of TLS/ 2165 DTLS MUST ignore unauthenticated messages. 2167 Note that future extensions may define additional authentication 2168 mechanisms that may not require an initial integrity-protected 2169 channel (e.g., authentication based on certificates signed by a 2170 certificate authority). 2172 As described in Section 9, floor control servers need to perform 2173 authorization before processing any message. In particular, the 2174 floor control server MUST check that messages arriving over a given 2175 authenticated TLS/DTLS connection use an authorized User ID (i.e., a 2176 User ID that the user that established the authenticated TLS/DTLS 2177 connection is allowed to use). 2179 10. Floor Participant Operations 2181 This section specifies how floor participants can perform different 2182 operations, such as requesting a floor, using the protocol elements 2183 described in earlier sections. Section 11 specifies operations that 2184 are specific to floor chairs, such as instructing the floor control 2185 server to grant or revoke a floor, and Section 12 specifies 2186 operations that can be performed by any client (i.e., both floor 2187 participants and floor chairs). 2189 10.1. Requesting a Floor 2191 A floor participant that wishes to request one or more floors does so 2192 by sending a FloorRequest message to the floor control server. 2194 10.1.1. Sending a FloorRequest Message 2196 The ABNF in Section 5.3.1 describes the attributes that a 2197 FloorRequest message can contain. In addition, the ABNF specifies 2198 normatively which of these attributes are mandatory, and which ones 2199 are optional. 2201 The floor participant sets the Conference ID and the Transaction ID 2202 in the common header following the rules given in Section 8.1. 2204 The floor participant sets the User ID in the common header to the 2205 floor participant's identifier. This User ID will be used by the 2206 floor control server to authenticate and authorize the request. If 2207 the sender of the FloorRequest message (identified by the User ID) is 2208 not the participant that would eventually get the floor (i.e., a 2209 third-party floor request), the sender SHOULD add a BENEFICIARY-ID 2210 attribute to the message identifying the beneficiary of the floor. 2212 Note that the name space for both the User ID and the Beneficiary 2213 ID is the same. That is, a given participant is identified by a 2214 single 16-bit value that can be used in the User ID in the common 2215 header and in several attributes: BENEFICIARY-ID, BENEFICIARY- 2216 INFORMATION, and REQUESTED-BY-INFORMATION. 2218 The floor participant MUST insert at least one FLOOR-ID attribute in 2219 the FloorRequest message. If the client inserts more than one 2220 FLOOR-ID attribute, the floor control server will treat all the floor 2221 requests as an atomic package. That is, the floor control server 2222 will either grant or deny all the floors in the FloorRequest message. 2224 The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute 2225 to state the reason why the floor or floors are being requested. The 2226 Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for 2227 human consumption. 2229 The floor participant may request that the server handle the floor 2230 request with a certain priority using a PRIORITY attribute. 2232 10.1.2. Receiving a Response 2234 A message from the floor control server is considered a response to 2235 the FloorRequest message if the message from the floor control server 2236 has the same Conference ID, Transaction ID, and User ID as the 2237 FloorRequest message, as described in Section 8.1. On receiving such 2238 a response, the floor participant follows the rules in Section 9 that 2239 relate to floor control server authentication. 2241 The successful processing of a FloorRequest message at the floor 2242 control server involves generating one or several FloorRequestStatus 2243 messages. The floor participant obtains a Floor Request ID in the 2244 Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in 2245 the first FloorRequestStatus message from the floor control server. 2246 Subsequent FloorRequestStatus messages from the floor control server 2247 regarding the same floor request will carry the same Floor Request ID 2248 in a FLOOR-REQUEST-INFORMATION attribute as the initial 2249 FloorRequestStatus message. This way, the floor participant can 2250 associate subsequent incoming FloorRequestStatus messages with the 2251 ongoing floor request. 2253 The floor participant obtains information about the status of the 2254 floor request in the FLOOR-REQUEST-INFORMATION attribute of each of 2255 the FloorRequestStatus messages received from the floor control 2256 server. This attribute is a grouped attribute, and as such it 2257 includes a number of attributes that provide information about the 2258 floor request. 2260 The OVERALL-REQUEST-STATUS attribute provides information about the 2261 overall status of the floor request. If the Request Status value is 2262 Granted, all the floors that were requested in the FloorRequest 2263 message have been granted. If the Request Status value is Denied, 2264 all the floors that were requested in the FloorRequest message have 2265 been denied. A floor request is considered to be ongoing while it is 2266 in the Pending, Accepted, or Granted states. If the floor request 2267 value is unknown, then the response is still processed. However, no 2268 meaningful value can be reported to the user. 2270 The STATUS-INFO attribute, if present, provides extra information 2271 that the floor participant can display to the user. 2273 The FLOOR-REQUEST-STATUS attributes provide information about the 2274 status of the floor request as it relates to a particular floor. The 2275 STATUS-INFO attribute, if present, provides extra information that 2276 the floor participant can display to the user. 2278 The BENEFICIARY-INFORMATION attribute identifies the beneficiary of 2279 the floor request in third-party floor requests. The REQUESTED-BY- 2280 INFORMATION attribute need not be present in FloorRequestStatus 2281 messages received by the floor participant that requested the floor, 2282 as this floor participant is already identified by the User ID in the 2283 common header. 2285 The PRIORITY attribute, when present, contains the priority that was 2286 requested by the generator of the FloorRequest message. 2288 If the response is an Error message, the floor control server could 2289 not process the FloorRequest message for some reason, which is 2290 described in the Error message. 2292 10.1.3. Reception of a Subsequent FloorRequestStatus Message 2294 When communicating over an unreliable transport and upon receiving a 2295 FloorRequestStatus message from a floor control server, the 2296 participant MUST respond with a FloorRequestStatusAck message within 2297 the transaction failure window to complete the transaction. 2299 10.2. Cancelling a Floor Request and Releasing a Floor 2301 A floor participant that wishes to cancel an ongoing floor request 2302 does so by sending a FloorRelease message to the floor control 2303 server. The FloorRelease message is also used by floor participants 2304 that hold a floor and would like to release it. 2306 10.2.1. Sending a FloorRelease Message 2308 The ABNF in Section 5.3.2 describes the attributes that a 2309 FloorRelease message can contain. In addition, the ABNF specifies 2310 normatively which of these attributes are mandatory, and which ones 2311 are optional. 2313 The floor participant sets the Conference ID and the Transaction ID 2314 in the common header following the rules given in Section 8.1. The 2315 floor participant sets the User ID in the common header to the floor 2316 participant's identifier. This User ID will be used by the floor 2317 control server to authenticate and authorize the request. 2319 Note that the FloorRelease message is used to release a floor or 2320 floors that were granted and to cancel ongoing floor requests 2321 (from the protocol perspective, both are ongoing floor requests). 2322 Using the same message in both situations helps resolve the race 2323 condition that occurs when the FloorRelease message and the 2324 FloorGrant message cross each other on the wire. 2326 The floor participant uses the FLOOR-REQUEST-ID that was received in 2327 the response to the FloorRequest message that the FloorRelease 2328 message is cancelling. 2330 Note that if the floor participant requested several floors as an 2331 atomic operation (i.e., in a single FloorRequest message), all the 2332 floors are released as an atomic operation as well (i.e., all are 2333 released at the same time). 2335 10.2.2. Receiving a Response 2337 A message from the floor control server is considered a response to 2338 the FloorRelease message if the message from the floor control server 2339 has the same Conference ID, Transaction ID, and User ID as the 2340 FloorRequest message, as described in Section 8.1. On receiving such 2341 a response, the floor participant follows the rules in Section 9 that 2342 relate to floor control server authentication. 2344 If the response is a FloorRequestStatus message, the Request Status 2345 value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR- 2346 REQUEST-INFORMATION grouped attribute) will be Cancelled or Released. 2348 If the response is an Error message, the floor control server could 2349 not process the FloorRequest message for some reason, which is 2350 described in the Error message. 2352 It is possible that the FloorRelease message crosses on the wire with 2353 a FloorRequestStatus message from the server with a Request Status 2354 different from Cancelled or Released. In any case, such a 2355 FloorRequestStatus message will not be a response to the FloorRelease 2356 message, as its Transaction ID will not match that of the 2357 FloorRelease. 2359 11. Chair Operations 2361 This section specifies how floor chairs can instruct the floor 2362 control server to grant or revoke a floor using the protocol elements 2363 described in earlier sections. 2365 Floor chairs that wish to send instructions to a floor control server 2366 do so by sending a ChairAction message. 2368 11.1. Sending a ChairAction Message 2370 The ABNF in Section 5.3.9 describes the attributes that a ChairAction 2371 message can contain. In addition, the ABNF specifies normatively 2372 which of these attributes are mandatory, and which ones are optional. 2374 The floor chair sets the Conference ID and the Transaction ID in the 2375 common header following the rules given in Section 8.1. The floor 2376 chair sets the User ID in the common header to the floor chair's 2377 identifier. This User ID will be used by the floor control server to 2378 authenticate and authorize the request. 2380 The ChairAction message contains instructions that apply to one or 2381 more floors within a particular floor request. The floor or floors 2382 are identified by the FLOOR-REQUEST-STATUS attributes and the floor 2383 request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which 2384 are carried in the ChairAction message. 2386 For example, if a floor request consists of two floors that depend on 2387 different floor chairs, each floor chair will grant its floor within 2388 the floor request. Once both chairs have granted their floor, the 2389 floor control server will grant the floor request as a whole. On the 2390 other hand, if one of the floor chairs denies its floor, the floor 2391 control server will deny the floor request as a whole, regardless of 2392 the other floor chair's decision. 2394 The floor chair provides the new status of the floor request as it 2395 relates to a particular floor using a FLOOR-REQUEST-STATUS attribute. 2396 If the new status of the floor request is Accepted, the floor chair 2397 MAY use the Queue Position field to provide a queue position for the 2398 floor request. If the floor chair does not wish to provide a queue 2399 position, all the bits of the Queue Position field MUST be set to 2400 zero. The floor chair MUST use the Status Revoked to revoke a floor 2401 that was granted (i.e., Granted status) and MUST use the Status 2402 Denied to reject floor requests in any other status (e.g., Pending 2403 and Accepted). 2405 The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the 2406 ChairAction message to provide a new overall status for the floor 2407 request. If the new overall status of the floor request is Accepted, 2408 the floor chair can use the Queue Position field to provide a queue 2409 position for the floor request. 2411 Note that a particular floor control server can implement a 2412 different queue for each floor containing all the floor requests 2413 that relate to that particular floor, a general queue for all 2414 floor requests, or both. Also note that a floor request can 2415 involve several floors and that a ChairAction message can only 2416 deal with a subset of these floors (e.g., if a single floor chair 2417 is not authorized to manage all the floors). In this case, the 2418 floor control server will combine the instructions received from 2419 the different floor chairs in FLOOR-REQUEST-STATUS attributes to 2420 come up with the overall status of the floor request. 2422 Note that, while the action of a floor chair may communicate 2423 information in the OVERALL-REQUEST-STATUS attribute, the floor 2424 control server may override, modify, or ignore this field's 2425 content. 2427 The floor chair MAY include STATUS-INFO attributes to state the 2428 reason why the floor or floors are being accepted, granted, or 2429 revoked. The Text in the STATUS-INFO attribute is intended for human 2430 consumption. 2432 11.2. Receiving a Response 2434 A message from the floor control server is considered a response to 2435 the ChairAction message if the message from the server has the same 2436 Conference ID, Transaction ID, and User ID as the ChairAction 2437 message, as described in Section 8.1. On receiving such a response, 2438 the floor chair follows the rules in Section 9 that relate to floor 2439 control server authentication. 2441 A ChairActionAck message from the floor control server confirms that 2442 the floor control server has accepted the ChairAction message. An 2443 Error message indicates that the floor control server could not 2444 process the ChairAction message for some reason, which is described 2445 in the Error message. 2447 12. General Client Operations 2449 This section specifies operations that can be performed by any 2450 client. That is, they are not specific to floor participants or 2451 floor chairs. They can be performed by both. 2453 12.1. Requesting Information about Floors 2455 A client can obtain information about the status of a floor or floors 2456 in different ways, which include using BFCP and using out-of-band 2457 mechanisms. Clients using BFCP to obtain such information use the 2458 procedures described in this section. 2460 Clients request information about the status of one or several floors 2461 by sending a FloorQuery message to the floor control server. 2463 12.1.1. Sending a FloorQuery Message 2465 The ABNF in Section 5.3.7 describes the attributes that a FloorQuery 2466 message can contain. In addition, the ABNF specifies normatively 2467 which of these attributes are mandatory, and which ones are optional. 2469 The client sets the Conference ID and the Transaction ID in the 2470 common header following the rules given in Section 8.1. The client 2471 sets the User ID in the common header to the client's identifier. 2472 This User ID will be used by the floor control server to authenticate 2473 and authorize the request. 2475 The client inserts in the message all the Floor IDs it wants to 2476 receive information about. The floor control server will send 2477 periodic information about all of these floors. If the client does 2478 not want to receive information about a particular floor any longer, 2479 it sends a new FloorQuery message removing the FLOOR-ID of this 2480 floor. If the client does not want to receive information about any 2481 floor any longer, it sends a FloorQuery message with no FLOOR-ID 2482 attribute. 2484 12.1.2. Receiving a Response 2486 A message from the floor control server is considered a response to 2487 the FloorQuery message if the message from the floor control server 2488 has the same Conference ID, Transaction ID, and User ID as the 2489 FloorRequest message, as described in Section 8.1. On receiving such 2490 a response, the client follows the rules in Section 9 that relate to 2491 floor control server authentication. 2493 On reception of the FloorQuery message, the floor control server MUST 2494 respond with a FloorStatus message or with an Error message. If the 2495 response is a FloorStatus message, it will contain information about 2496 one of the floors the client requested information about. If the 2497 client did not include any FLOOR-ID attribute in its FloorQuery 2498 message (i.e., the client does not want to receive information about 2499 any floor any longer), the FloorStatus message from the floor control 2500 server will not include any FLOOR-ID attribute either. 2502 FloorStatus messages that carry information about a floor contain a 2503 FLOOR-ID attribute that identifies the floor. After this attribute, 2504 FloorStatus messages contain information about existing (one or more) 2505 floor requests that relate to that floor. The information about each 2506 particular floor request is encoded in a FLOOR-REQUEST-INFORMATION 2507 attribute. This grouped attribute carries a Floor Request ID that 2508 identifies the floor request, followed by a set of attributes that 2509 provide information about the floor request. 2511 After the first FloorStatus, the floor control server will continue 2512 sending FloorStatus messages, periodically informing the client about 2513 changes on the floors the client requested information about. 2515 12.1.3. Reception of a Subsequent FloorStatus Message 2517 When communicating over an unreliable transport and upon receiving a 2518 FloorStatus message from a floor control server, the participant MUST 2519 respond with a FloorStatusAck message within the transaction failure 2520 window to complete the transaction. 2522 12.2. Requesting Information about Floor Requests 2524 A client can obtain information about the status of one or several 2525 floor requests in different ways, which include using BFCP and using 2526 out-of-band mechanisms. Clients using BFCP to obtain such 2527 information use the procedures described in this section. 2529 Clients request information about the current status of a floor 2530 request by sending a FloorRequestQuery message to the floor control 2531 server. 2533 Requesting information about a particular floor request is useful in 2534 a number of situations. For example, on reception of a FloorRequest 2535 message, a floor control server may choose to return 2536 FloorRequestStatus messages only when the floor request changes its 2537 state (e.g., from Accepted to Granted), but not when the floor 2538 request advances in its queue. In this situation, if the user 2539 requests it, the floor participant can use a FloorRequestQuery 2540 message to poll the floor control server for the status of the floor 2541 request. 2543 12.2.1. Sending a FloorRequestQuery Message 2545 The ABNF in Section 5.3.3 describes the attributes that a 2546 FloorRequestQuery message can contain. In addition, the ABNF 2547 specifies normatively which of these attributes are mandatory, and 2548 which ones are optional. 2550 The client sets the Conference ID and the Transaction ID in the 2551 common header following the rules given in Section 8.1. The client 2552 sets the User ID in the common header to the client's identifier. 2553 This User ID will be used by the floor control server to authenticate 2554 and authorize the request. 2556 The client MUST insert a FLOOR-REQUEST-ID attribute that identifies 2557 the floor request at the floor control server. 2559 12.2.2. Receiving a Response 2561 A message from the floor control server is considered a response to 2562 the FloorRequestQuery message if the message from the floor control 2563 server has the same Conference ID, Transaction ID, and User ID as the 2564 FloorRequestQuery message, as described in Section 8.1. On receiving 2565 such a response, the client follows the rules in Section 9 that 2566 relate to floor control server authentication. 2568 If the response is a FloorRequestStatus message, the client obtains 2569 information about the status of the FloorRequest the client requested 2570 information about in a FLOOR-REQUEST-INFORMATION attribute. 2572 If the response is an Error message, the floor control server could 2573 not process the FloorRequestQuery message for some reason, which is 2574 described in the Error message. 2576 12.3. Requesting Information about a User 2578 A client can obtain information about a participant and the floor 2579 requests related to this participant in different ways, which include 2580 using BFCP and using out-of-band mechanisms. Clients using BFCP to 2581 obtain such information use the procedures described in this section. 2583 Clients request information about a participant and the floor 2584 requests related to this participant by sending a UserQuery message 2585 to the floor control server. 2587 This functionality may be useful for floor chairs or floor 2588 participants interested in the display name and the URI of a 2589 particular floor participant. In addition, a floor participant may 2590 find it useful to request information about itself. For example, a 2591 floor participant, after experiencing connectivity problems (e.g., 2592 its TCP connection with the floor control server was down for a while 2593 and eventually was re-established), may need to request information 2594 about all the floor requests associated to itself that still exist. 2596 12.3.1. Sending a UserQuery Message 2598 The ABNF in Section 5.3.5 describes the attributes that a UserQuery 2599 message can contain. In addition, the ABNF specifies normatively 2600 which of these attributes are mandatory, and which ones are optional. 2602 The client sets the Conference ID and the Transaction ID in the 2603 common header following the rules given in Section 8.1. The client 2604 sets the User ID in the common header to the client's identifier. 2605 This User ID will be used by the floor control server to authenticate 2606 and authorize the request. 2608 If the floor participant the client is requesting information about 2609 is not the client issuing the UserQuery message (which is identified 2610 by the User ID in the common header of the message), the client MUST 2611 insert a BENEFICIARY-ID attribute. 2613 12.3.2. Receiving a Response 2615 A message from the floor control server is considered a response to 2616 the UserQuery message if the message from the floor control server 2617 has the same Conference ID, Transaction ID, and User ID as the 2618 UserQuery message, as described in Section 8.1. On receiving such a 2619 response, the client follows the rules in Section 9 that relate to 2620 floor control server authentication. 2622 If the response is a UserStatus message, the client obtains 2623 information about the floor participant in a BENEFICIARY-INFORMATION 2624 grouped attribute and about the status of the floor requests 2625 associated with the floor participant in FLOOR-REQUEST-INFORMATION 2626 attributes. 2628 If the response is an Error message, the floor control server could 2629 not process the UserQuery message for some reason, which is described 2630 in the Error message. 2632 12.4. Obtaining the Capabilities of a Floor Control Server 2634 A client that wishes to obtain the capabilities of a floor control 2635 server does so by sending a Hello message to the floor control 2636 server. 2638 12.4.1. Sending a Hello Message 2640 The ABNF in Section 5.3.11 describes the attributes that a Hello 2641 message can contain. In addition, the ABNF specifies normatively 2642 which of these attributes are mandatory, and which ones are optional. 2644 The client sets the Conference ID and the Transaction ID in the 2645 common header following the rules given in Section 8.1. The client 2646 sets the User ID in the common header to the client's identifier. 2647 This User ID will be used by the floor control server to authenticate 2648 and authorize the request. 2650 12.4.2. Receiving Responses 2652 A message from the floor control server is considered a response to 2653 the Hello message by the client if the message from the floor control 2654 server has the same Conference ID, Transaction ID, and User ID as the 2655 Hello message, as described in Section 8.1. On receiving such a 2656 response, the client follows the rules in Section 9 that relate to 2657 floor control server authentication. 2659 If the response is a HelloAck message, the floor control server could 2660 process the Hello message successfully. The SUPPORTED-PRIMITIVES and 2661 SUPPORTED-ATTRIBUTES attributes indicate which primitives and 2662 attributes, respectively, are supported by the server. 2664 If the response is an Error message, the floor control server could 2665 not process the Hello message for some reason, which is described in 2666 the Error message. 2668 13. Floor Control Server Operations 2670 This section specifies how floor control servers can perform 2671 different operations, such as granting a floor, using the protocol 2672 elements described in earlier sections. 2674 On reception of a message from a client, the floor control server 2675 MUST check whether the value of the Primitive is supported. If it is 2676 not, the floor control server MUST send an Error message, as 2677 described in Section 13.8, with Error code 3 (Unknown Primitive). 2679 On reception of a message from a client, the floor control server 2680 MUST check whether the value of the Conference ID matched an existing 2681 conference. If it does not, the floor control server MUST send an 2682 Error message, as described in Section 13.8, with Error code 1 2683 (Conference does not Exist). 2685 On reception of a message from a client, the floor control server 2686 follows the rules in Section 9 that relate to the authentication of 2687 the message. 2689 On reception of a message from a client, the floor control server 2690 MUST check whether it understands all the mandatory ('M' bit set) 2691 attributes in the message. If the floor control server does not 2692 understand all of them, the floor control server MUST send an Error 2693 message, as described in Section 13.8, with Error code 4 (Unknown 2694 Mandatory Attribute). The Error message SHOULD list the attributes 2695 that were not understood. 2697 13.1. Reception of a FloorRequest Message 2699 On reception of a FloorRequest message, the floor control server 2700 follows the rules in Section 9 that relate to client authentication 2701 and authorization. If while processing the FloorRequest message, the 2702 floor control server encounters an error, it MUST generate an Error 2703 response following the procedures described in Section 13.8. 2705 BFCP allows floor participants to have several ongoing floor 2706 requests for the same floor (e.g., the same floor participant can 2707 occupy more than one position in a queue at the same time). A 2708 floor control server that only supports a certain number of 2709 ongoing floor requests per floor participant (e.g., one) can use 2710 Error Code 8 (You have Already Reached the Maximum Number of 2711 Ongoing Floor Requests for this Floor) to inform the floor 2712 participant. 2714 When communicating over an unreliable transport and upon receiving a 2715 FloorRequest from a participant, the floor control server MUST 2716 respond with a FloorRequestStatus message within the transaction 2717 failure window to complete the transaction. 2719 13.1.1. Generating the First FloorRequestStatus Message 2721 The successful processing of a FloorRequest message by a floor 2722 control server involves generating one or several FloorRequestStatus 2723 messages, the first of which SHOULD be generated as soon as possible. 2724 If the floor control server cannot accept, grant, or deny the floor 2725 request right away (e.g., a decision from a chair is needed), it 2726 SHOULD use a Request Status value of Pending in the OVERALL-REQUEST- 2727 STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped 2728 attribute) of the first FloorRequestStatus message it generates. 2730 The policy that a floor control server follows to grant or deny 2731 floors is outside the scope of this document. A given floor 2732 control server may perform these decisions automatically while 2733 another may contact a human acting as a chair every time a 2734 decision needs to be made. 2736 The floor control server MUST copy the Conference ID, the Transaction 2737 ID, and the User ID from the FloorRequest into the 2738 FloorRequestStatus, as described in Section 8.2. Additionally, the 2739 floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 2740 attribute to the FloorRequestStatus. The attributes contained in 2741 this grouped attribute carry information about the floor request. 2743 The floor control server MUST assign an identifier that is unique 2744 within the conference to this floor request, and MUST insert it in 2745 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 2746 attribute. This identifier will be used by the floor participant (or 2747 by a chair or chairs) to refer to this specific floor request in the 2748 future. 2750 The floor control server MUST copy the Floor IDs in the FLOOR-ID 2751 attributes of the FloorRequest into the FLOOR-REQUEST-STATUS 2752 attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These 2753 Floor IDs identify the floors being requested (i.e., the floors 2754 associated with this particular floor request). 2756 The floor control server SHOULD copy (if present) the contents of the 2757 BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY- 2758 INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped 2759 attribute. Additionally, the floor control server MAY provide the 2760 display name and the URI of the beneficiary in this BENEFICIARY- 2761 INFORMATION attribute. 2763 The floor control server MAY provide information about the requester 2764 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2765 FLOOR-REQUEST-INFORMATION grouped attribute. 2767 The floor control server MAY copy (if present) the PRIORITY attribute 2768 from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped 2769 attribute. 2771 Note that this attribute carries the priority requested by the 2772 participant. The priority that the floor control server assigns 2773 to the floor request depends on the priority requested by the 2774 participant and the rights the participant has according to the 2775 policy of the conference. For example, a participant that is only 2776 allowed to use the Normal priority may request Highest priority 2777 for a floor request. In that case, the floor control server would 2778 ignore the priority requested by the participant. 2780 The floor control server MAY copy (if present) the PARTICIPANT- 2781 PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST- 2782 INFORMATION grouped attribute. 2784 13.1.2. Generation of Subsequent FloorRequestStatus Messages 2786 A floor request is considered to be ongoing as long as it is not in 2787 the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST- 2788 STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped 2789 attribute) of the first FloorRequestStatus message generated by the 2790 floor control server did not indicate any of these states, the floor 2791 control server will need to send subsequent FloorRequestStatus 2792 messages. 2794 When the status of the floor request changes, the floor control 2795 server SHOULD send new FloorRequestStatus messages with the 2796 appropriate Request Status. The floor control server MUST add a 2797 FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to 2798 the one sent in the first FloorRequestStatus message to any new 2799 FloorRequestStatus related to the same floor request. (The Floor 2800 Request ID identifies the floor request to which the 2801 FloorRequestStatus applies.) 2803 When using BFCP over a reliable transport, the floor control server 2804 MUST set the Transaction ID of subsequent FloorRequestStatus messages 2805 to 0. When using BFCP over an unreliable transport, the Transaction 2806 ID MUST be non-zero and unique in the context of outstanding 2807 transactions over an unreliable transport as described in Section 8. 2809 The rate at which the floor control server sends 2810 FloorRequestStatus messages is a matter of local policy. A floor 2811 control server may choose to send a new FloorRequestStatus message 2812 every time the floor request moves in the floor request queue, 2813 while another may choose only to send a new FloorRequestStatus 2814 message when the floor request is Granted or Denied. 2816 The floor control server may add a STATUS-INFO attribute to any of 2817 the FloorRequestStatus messages it generates to provide extra 2818 information about its decisions regarding the floor request (e.g., 2819 why it was denied). 2821 Floor participants and floor chairs may request to be informed 2822 about the status of a floor following the procedures in 2823 Section 12.1. If the processing of a floor request changes the 2824 status of a floor (e.g., the floor request is granted and 2825 consequently the floor has a new holder), the floor control server 2826 needs to follow the procedures in Section 13.5 to inform the 2827 clients that have requested that information. 2829 The common header and the rest of the attributes are the same as in 2830 the first FloorRequestStatus message. 2832 The floor control server can discard the state information about a 2833 particular floor request when this reaches a status of Cancelled, 2834 Released, or Revoked. 2836 When communicating over an unreliable transport and a 2837 FloorRequestStatusAck message is not received within the transaction 2838 failure window, the floor control server MUST retransmit the 2839 FloorRequestStatus message according to Section 6.2. 2841 13.2. Reception of a FloorRequestQuery Message 2843 On reception of a FloorRequestQuery message, the floor control server 2844 follows the rules in Section 9 that relate to client authentication 2845 and authorization. If while processing the FloorRequestQuery 2846 message, the floor control server encounters an error, it MUST 2847 generate an Error response following the procedures described in 2848 Section 13.8. 2850 The successful processing of a FloorRequestQuery message by a floor 2851 control server involves generating a FloorRequestStatus message, 2852 which SHOULD be generated as soon as possible. 2854 When communicating over an unreliable transport and upon receiving a 2855 FloorRequestQuery from a participant, the floor control server MUST 2856 respond with a FloorRequestStatus message within the transaction 2857 failure window to complete the transaction. 2859 The floor control server MUST copy the Conference ID, the Transaction 2860 ID, and the User ID from the FloorRequestQuery message into the 2861 FloorRequestStatus message, as described in Section 8.2. 2862 Additionally, the floor control server MUST include information about 2863 the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute 2864 to the FloorRequestStatus. 2866 The floor control server MUST copy the contents of the 2867 FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into 2868 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 2869 attribute. 2871 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 2872 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2873 floors being requested (i.e., the floors associated with the floor 2874 request identified by the FLOOR-REQUEST-ID attribute). 2876 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2877 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2878 beneficiary of the floor request. Additionally, the floor control 2879 server MAY provide the display name and the URI of the beneficiary in 2880 this BENEFICIARY-INFORMATION attribute. 2882 The floor control server MAY provide information about the requester 2883 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2884 FLOOR-REQUEST-INFORMATION grouped attribute. 2886 The floor control server MAY provide the reason why the floor 2887 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2889 The floor control server MAY also add to the FLOOR-REQUEST- 2890 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2891 value requested for the floor request and a STATUS-INFO attribute 2892 with extra information about the floor request. 2894 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 2895 to the FLOOR-REQUEST-INFORMATION grouped attribute with the current 2896 status of the floor request. The floor control server MAY provide 2897 information about the status of the floor request as it relates to 2898 each of the floors being requested in the FLOOR-REQUEST-STATUS 2899 attributes. 2901 13.3. Reception of a UserQuery Message 2903 On reception of a UserQuery message, the floor control server follows 2904 the rules in Section 9 that relate to client authentication and 2905 authorization. If while processing the UserQuery message, the floor 2906 control server encounters an error, it MUST generate an Error 2907 response following the procedures described in Section 13.8. 2909 The successful processing of a UserQuery message by a floor control 2910 server involves generating a UserStatus message, which SHOULD be 2911 generated as soon as possible. 2913 When communicating over an unreliable transport and upon receiving a 2914 UserQuery from a participant, the floor control server MUST respond 2915 with a UserStatus message within the transaction failure window to 2916 complete the transaction. 2918 The floor control server MUST copy the Conference ID, the Transaction 2919 ID, and the User ID from the UserQuery message into the USerStatus 2920 message, as described in Section 8.2. 2922 The sender of the UserQuery message is requesting information about 2923 all the floor requests associated with a given participant (i.e., the 2924 floor requests where the participant is either the beneficiary or the 2925 requester). This participant is identified by a BENEFICIARY-ID 2926 attribute or, in the absence of a BENEFICIARY-ID attribute, by a the 2927 User ID in the common header of the UserQuery message. 2929 The floor control server MUST copy, if present, the contents of the 2930 BENEFICIARY-ID attribute from the UserQuery message into a 2931 BENEFICIARY-INFORMATION attribute in the UserStatus message. 2932 Additionally, the floor control server MAY provide the display name 2933 and the URI of the participant about which the UserStatus message 2934 provides information in this BENEFICIARY-INFORMATION attribute. 2936 The floor control server SHOULD add to the UserStatus message a 2937 FLOOR-REQUEST-INFORMATION grouped attribute for each floor request 2938 related to the participant about which the message provides 2939 information (i.e., the floor requests where the participant is either 2940 the beneficiary or the requester). For each FLOOR-REQUEST- 2941 INFORMATION attribute, the floor control server follows the following 2942 steps. 2944 The floor control server MUST identify the floor request the FLOOR- 2945 REQUEST-INFORMATION attribute applies to by filling the Floor Request 2946 ID field of the FLOOR-REQUEST-INFORMATION attribute. 2948 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 2949 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2950 floors being requested (i.e., the floors associated with the floor 2951 request identified by the FLOOR-REQUEST-ID attribute). 2953 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2954 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2955 beneficiary of the floor request. Additionally, the floor control 2956 server MAY provide the display name and the URI of the beneficiary in 2957 this BENEFICIARY-INFORMATION attribute. 2959 The floor control server MAY provide information about the requester 2960 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2961 FLOOR-REQUEST-INFORMATION grouped attribute. 2963 The floor control server MAY provide the reason why the floor 2964 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2966 The floor control server MAY also add to the FLOOR-REQUEST- 2967 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2968 value requested for the floor request. 2970 The floor control server MUST include the current status of the floor 2971 request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST- 2972 INFORMATION grouped attribute. The floor control server MAY add a 2973 STATUS-INFO attribute with extra information about the floor request. 2975 The floor control server MAY provide information about the status of 2976 the floor request as it relates to each of the floors being requested 2977 in the FLOOR-REQUEST-STATUS attributes. 2979 13.4. Reception of a FloorRelease Message 2981 On reception of a FloorRelease message, the floor control server 2982 follows the rules in Section 9 that relate to client authentication 2983 and authorization. If while processing the FloorRelease message, the 2984 floor control server encounters an error, it MUST generate an Error 2985 response following the procedures described in Section 13.8. 2987 The successful processing of a FloorRelease message by a floor 2988 control server involves generating a FloorRequestStatus message, 2989 which SHOULD be generated as soon as possible. 2991 When communicating over an unreliable transport and upon receiving a 2992 FloorRelease from a participant, the floor control server MUST 2993 respond with a FloorRequestStatus message within the transaction 2994 failure window to complete the transaction. 2996 The floor control server MUST copy the Conference ID, the Transaction 2997 ID, and the User ID from the FloorRelease message into the 2998 FloorRequestStatus message, as described in Section 8.2. 3000 The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 3001 attribute to the FloorRequestStatus. The attributes contained in 3002 this grouped attribute carry information about the floor request. 3004 The FloorRelease message identifies the floor request it applies to 3005 using a FLOOR-REQUEST-ID. The floor control server MUST copy the 3006 contents of the FLOOR-REQUEST-ID attribute from the FloorRelease 3007 message into the Floor Request ID field of the FLOOR-REQUEST- 3008 INFORMATION attribute. 3010 The floor control server MUST identify the floors being released 3011 (i.e., the floors associated with the floor request identified by the 3012 FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the 3013 FLOOR-REQUEST-INFORMATION grouped attribute. 3015 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 3016 to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request 3017 Status value SHOULD be Released, if the floor (or floors) had been 3018 previously granted, or Cancelled, if the floor (or floors) had not 3019 been previously granted. The floor control server MAY add a STATUS- 3020 INFO attribute with extra information about the floor request. 3022 13.5. Reception of a FloorQuery Message 3024 On reception of a FloorQuery message, the floor control server 3025 follows the rules in Section 9 that relate to client authentication. 3026 If while processing the FloorQuery message, the floor control server 3027 encounters an error, it MUST generate an Error response following the 3028 procedures described in Section 13.8. 3030 When communicating over an unreliable transport and upon receiving a 3031 FloorQuery from a participant, the floor control server MUST respond 3032 with a FloorStatus message within the transaction failure window to 3033 complete the transaction. 3035 A floor control server receiving a FloorQuery message from a client 3036 SHOULD keep this client informed about the status of the floors 3037 identified by FLOOR-ID attributes in the FloorQuery message. Floor 3038 Control Servers keep clients informed by using FloorStatus messages. 3040 An individual FloorStatus message carries information about a single 3041 floor. So, when a FloorQuery message requests information about more 3042 than one floor, the floor control server needs to send separate 3043 FloorStatus messages for different floors. 3045 The information FloorQuery messages carry may depend on the user 3046 requesting the information. For example, a chair may be able to 3047 receive information about pending requests, while a regular user may 3048 not be authorized to do so. 3050 13.5.1. Generation of the First FloorStatus Message 3052 The successful processing of a FloorQuery message by a floor control 3053 server involves generating one or several FloorStatus messages, the 3054 first of which SHOULD be generated as soon as possible. 3056 The floor control server MUST copy the Conference ID, the Transaction 3057 ID, and the User ID from the FloorQuery message into the FloorStatus 3058 message, as described in Section 8.2. 3060 If the FloorQuery message did not contain any FLOOR-ID attribute, the 3061 floor control server sends the FloorStatus message without adding any 3062 additional attribute and does not send any subsequent FloorStatus 3063 message to the floor participant. 3065 If the FloorQuery message contained one or more FLOOR-ID attributes, 3066 the floor control server chooses one from among them and adds this 3067 FLOOR-ID attribute to the FloorStatus message. The floor control 3068 server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for 3069 each floor request associated to the floor. Each FLOOR-REQUEST- 3070 INFORMATION grouped attribute contains a number of attributes that 3071 provide information about the floor request. For each FLOOR-REQUEST- 3072 INFORMATION attribute, the floor control server follows the following 3073 steps. 3075 The floor control server MUST identify the floor request the FLOOR- 3076 REQUEST-INFORMATION attribute applies to by filling the Floor Request 3077 ID field of the FLOOR-REQUEST-INFORMATION attribute. 3079 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 3080 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 3081 floors being requested (i.e., the floors associated with the floor 3082 request identified by the FLOOR-REQUEST-ID attribute). 3084 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 3085 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 3086 beneficiary of the floor request. Additionally, the floor control 3087 server MAY provide the display name and the URI of the beneficiary in 3088 this BENEFICIARY-INFORMATION attribute. 3090 The floor control server MAY provide information about the requester 3091 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 3092 FLOOR-REQUEST-INFORMATION grouped attribute. 3094 The floor control server MAY provide the reason why the floor 3095 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 3097 The floor control server MAY also add to the FLOOR-REQUEST- 3098 INFORMATION grouped attribute a PRIORITY attribute with the Priority 3099 value requested for the floor request. 3101 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 3102 to the FLOOR-REQUEST-INFORMATION grouped attribute with the current 3103 status of the floor request. The floor control server MAY add a 3104 STATUS-INFO attribute with extra information about the floor request. 3106 The floor control server MAY provide information about the status of 3107 the floor request as it relates to each of the floors being requested 3108 in the FLOOR-REQUEST-STATUS attributes. 3110 13.5.2. Generation of Subsequent FloorStatus Messages 3112 If the FloorQuery message carried more than one FLOOR-ID attribute, 3113 the floor control server SHOULD generate a FloorStatus message for 3114 each of them (except for the FLOOR-ID attribute chosen for the first 3115 FloorStatus message) as soon as possible. These FloorStatus messages 3116 are generated following the same rules as those for the first 3117 FloorStatus message (see Section 13.5.1), but their Transaction ID is 3118 0 when using a reliable transport and non-zero and unique in the 3119 context of outstanding transactions when using an unreliable 3120 transport (cf. Section 8). 3122 After generating these messages, the floor control server sends 3123 FloorStatus messages, periodically keeping the client informed about 3124 all the floors for which the client requested information. The 3125 Transaction ID of these messages MUST be 0 when using a reliable 3126 transport and non-zero and unique in the context of outstanding 3127 transactions when using an unreliable transport (cf. Section 8). 3129 The rate at which the floor control server sends FloorStatus 3130 messages is a matter of local policy. A floor control server may 3131 choose to send a new FloorStatus message every time a new floor 3132 request arrives, while another may choose to only send a new 3133 FloorStatus message when a new floor request is Granted. 3135 When communicating over an unreliable transport and a FloorStatusAck 3136 message is not received within the transaction failure window, the 3137 floor control server MUST retransmit the FloorStatus message 3138 according to Section 6.2. 3140 13.6. Reception of a ChairAction Message 3142 On reception of a ChairAction message, the floor control server 3143 follows the rules in Section 9 that relate to client authentication 3144 and authorization. If while processing the ChairAction message, the 3145 floor control server encounters an error, it MUST generate an Error 3146 response following the procedures described in Section 13.8. 3148 The successful processing of a ChairAction message by a floor control 3149 server involves generating a ChairActionAck message, which SHOULD be 3150 generated as soon as possible. 3152 When communicating over an unreliable transport and upon receiving a 3153 ChairAction from a chair, the floor control server MUST respond with 3154 a ChairActionAck message within the transaction failure window to 3155 complete the transaction. 3157 The floor control server MUST copy the Conference ID, the Transaction 3158 ID, and the User ID from the ChairAction message into the 3159 ChairActionAck message, as described in Section 8.2. 3161 The floor control server needs to take into consideration the 3162 operation requested in the ChairAction message (e.g., granting a 3163 floor) but does not necessarily need to perform it as requested by 3164 the floor chair. The operation that the floor control server 3165 performs depends on the ChairAction message and on the internal state 3166 of the floor control server. 3168 For example, a floor chair may send a ChairAction message granting a 3169 floor that was requested as part of an atomic floor request operation 3170 that involved several floors. Even if the chair responsible for one 3171 of the floors instructs the floor control server to grant the floor, 3172 the floor control server will not grant it until the chairs 3173 responsible for the other floors agree to grant them as well. 3175 So, the floor control server is ultimately responsible for keeping a 3176 coherent floor state using instructions from floor chairs as input to 3177 this state. 3179 If the new Status in the ChairAction message is Accepted and all the 3180 bits of the Queue Position field are zero, the floor chair is 3181 requesting that the floor control server assign a queue position 3182 (e.g., the last in the queue) to the floor request based on the local 3183 policy of the floor control server. (Of course, such a request only 3184 applies if the floor control server implements a queue.) 3186 13.7. Reception of a Hello Message 3188 On reception of a Hello message, the floor control server follows the 3189 rules in Section 9 that relate to client authentication. If while 3190 processing the Hello message, the floor control server encounters an 3191 error, it MUST generate an Error response following the procedures 3192 described in Section 13.8. 3194 If the version of BFCP specified in the Version field of the COMMON- 3195 HEADER is supported by the floor control server, it MUST respond with 3196 the same version number in the HelloAck; this defines the version for 3197 all subsequent BFCP messages within this BFCP Connection. If the 3198 version given in the Hello message is not supported, the receiving 3199 server MUST instead send an Error message with parameter value 12 3200 (Unsupported Version). 3202 When communicating over an unreliable transport and upon receiving a 3203 Hello from a participant, the floor control server MUST respond with 3204 a HelloAck message within the transaction failure window to complete 3205 the transaction. 3207 The successful processing of a Hello message by a floor control 3208 server involves generating a HelloAck message, which SHOULD be 3209 generated as soon as possible. The floor control server MUST copy 3210 the Conference ID, the Transaction ID, and the User ID from the Hello 3211 into the HelloAck, as described in Section 8.2. 3213 The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to 3214 the HelloAck message listing all the primitives (i.e., BFCP messages) 3215 supported by the floor control server. 3217 The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to 3218 the HelloAck message listing all the attributes supported by the 3219 floor control server. 3221 13.8. Error Message Generation 3223 Error messages are always sent in response to a previous message from 3224 the client as part of a client-initiated transaction. The ABNF in 3225 Section 5.3.13 describes the attributes that an Error message can 3226 contain. In addition, the ABNF specifies normatively which of these 3227 attributes are mandatory and which ones are optional. 3229 The floor control server MUST copy the Conference ID, the Transaction 3230 ID, and the User ID from the message from the client into the Error 3231 message, as described in Section 8.2. 3233 The floor control server MUST add an ERROR-CODE attribute to the 3234 Error message. The ERROR-CODE attribute contains an Error Code from 3235 Table 5. Additionally, the floor control server may add an ERROR- 3236 INFO attribute with extra information about the error. 3238 14. Security Considerations 3240 BFCP uses TLS/DTLS to provide mutual authentication between clients 3241 and servers. TLS/DTLS also provides replay and integrity protection 3242 and confidentiality. It is RECOMMENDED that TLS/DTLS with non-null 3243 encryption always be used. BFCP entities MAY use other security 3244 mechanisms as long as they provide similar security properties. 3246 The remainder of this section analyzes some of the threats against 3247 BFCP and how they are addressed. 3249 An attacker may attempt to impersonate a client (a floor participant 3250 or a floor chair) in order to generate forged floor requests or to 3251 grant or deny existing floor requests. Client impersonation is 3252 avoided by having servers only accept BFCP messages over 3253 authenticated TLS/DTLS connections. The floor control server assumes 3254 that attackers cannot high-jack the TLS/DTLS connection and, 3255 therefore, that messages over the TLS/DTLS connection come from the 3256 client that was initially authenticated. 3258 An attacker may attempt to impersonate a floor control server. A 3259 successful attacker would be able to make clients think that they 3260 hold a particular floor so that they would try to access a resource 3261 (e.g., sending media) without having legitimate rights to access it. 3262 Floor control server impersonation is avoided by having servers only 3263 accept BFCP messages over authenticated TLS/DTLS connections, as well 3264 as ensuring clients only send and accept messages over authenticated 3265 TLS/DTLS connections. 3267 Attackers may attempt to modify messages exchanged by a client and a 3268 floor control server. The integrity protection provided by TLS/DTLS 3269 connections prevents this attack. 3271 An attacker may attempt to fetch a valid message sent by a client to 3272 a floor control server and replay it over a connection between the 3273 attacker and the floor control server. This attack is prevented by 3274 having floor control servers check that messages arriving over a 3275 given authenticated TLS/DTLS connection use an authorized user ID 3276 (i.e., a user ID that the user that established the authenticated 3277 TLS/DTLS connection is allowed to use). 3279 Attackers may attempt to pick messages from the network to get access 3280 to confidential information between the floor control server and a 3281 client (e.g., why a floor request was denied). TLS/DTLS 3282 confidentiality prevents this attack. Therefore, it is RECOMMENDED 3283 that TLS/DTLS be used with a non-null encryption algorithm. 3285 15. IANA Considerations 3287 [Editorial note: This section instructs the IANA to register new 3288 entries in the BFCP Primitive subregistry in Section 15.2 and for 3289 the BFCP Error Code subregistry in Section 15.4.] 3291 The IANA has created a registry for BFCP parameters called "Binary 3292 Floor Control Protocol (BFCP) Parameters". This registry has a 3293 number of subregistries, which are described in the following 3294 sections. 3296 15.1. Attribute Subregistry 3298 This section establishes the Attribute subregistry under the BFCP 3299 Parameters registry. As per the terminology in RFC 5226 [5], the 3300 registration policy for BFCP attributes shall be "Specification 3301 Required". For the purposes of this subregistry, the BFCP attributes 3302 for which IANA registration is requested MUST be defined by a 3303 standards-track RFC. Such an RFC MUST specify the attribute's type, 3304 name, format, and semantics. 3306 For each BFCP attribute, the IANA registers its type, its name, and 3307 the reference to the RFC where the attribute is defined. The 3308 following table contains the initial values of this subregistry. 3310 +------+---------------------------+------------+ 3311 | Type | Attribute | Reference | 3312 +------+---------------------------+------------+ 3313 | 1 | BENEFICIARY-ID | [RFC XXXX] | 3314 | 2 | FLOOR-ID | [RFC XXXX] | 3315 | 3 | FLOOR-REQUEST-ID | [RFC XXXX] | 3316 | 4 | PRIORITY | [RFC XXXX] | 3317 | 5 | REQUEST-STATUS | [RFC XXXX] | 3318 | 6 | ERROR-CODE | [RFC XXXX] | 3319 | 7 | ERROR-INFO | [RFC XXXX] | 3320 | 8 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] | 3321 | 9 | STATUS-INFO | [RFC XXXX] | 3322 | 10 | SUPPORTED-ATTRIBUTES | [RFC XXXX] | 3323 | 11 | SUPPORTED-PRIMITIVES | [RFC XXXX] | 3324 | 12 | USER-DISPLAY-NAME | [RFC XXXX] | 3325 | 13 | USER-URI | [RFC XXXX] | 3326 | 14 | BENEFICIARY-INFORMATION | [RFC XXXX] | 3327 | 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] | 3328 | 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] | 3329 | 17 | FLOOR-REQUEST-STATUS | [RFC XXXX] | 3330 | 18 | OVERALL-REQUEST-STATUS | [RFC XXXX] | 3331 +------+---------------------------+------------+ 3333 Table 7: Initial values of the BFCP Attribute subregistry 3335 15.2. Primitive Subregistry 3337 [Editorial note: This section instructs the IANA to register the 3338 following new values for the BFCP Primitive subregistry: 3339 FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.] 3341 This section establishes the Primitive subregistry under the BFCP 3342 Parameters registry. As per the terminology in RFC 5226 [5], the 3343 registration policy for BFCP primitives shall be "Specification 3344 Required". For the purposes of this subregistry, the BFCP primitives 3345 for which IANA registration is requested MUST be defined by a 3346 standards-track RFC. Such an RFC MUST specify the primitive's value, 3347 name, format, and semantics. 3349 For each BFCP primitive, the IANA registers its value, its name, and 3350 the reference to the RFC where the primitive is defined. The 3351 following table contains the initial values of this subregistry. 3353 +-------+-----------------------+------------+ 3354 | Value | Primitive | Reference | 3355 +-------+-----------------------+------------+ 3356 | 1 | FloorRequest | [RFC XXXX] | 3357 | 2 | FloorRelease | [RFC XXXX] | 3358 | 3 | FloorRequestQuery | [RFC XXXX] | 3359 | 4 | FloorRequestStatus | [RFC XXXX] | 3360 | 5 | UserQuery | [RFC XXXX] | 3361 | 6 | UserStatus | [RFC XXXX] | 3362 | 7 | FloorQuery | [RFC XXXX] | 3363 | 8 | FloorStatus | [RFC XXXX] | 3364 | 9 | ChairAction | [RFC XXXX] | 3365 | 10 | ChairActionAck | [RFC XXXX] | 3366 | 11 | Hello | [RFC XXXX] | 3367 | 12 | HelloAck | [RFC XXXX] | 3368 | 13 | Error | [RFC XXXX] | 3369 | 14 | FloorRequestStatusAck | [RFC XXXX] | 3370 | 15 | FloorStatusAck | [RFC XXXX] | 3371 | 16 | Goodbye | [RFC XXXX] | 3372 | 17 | GoodbyeAck | [RFC XXXX] | 3373 +-------+-----------------------+------------+ 3375 Table 8: Initial values of the BFCP primitive subregistry 3377 15.3. Request Status Subregistry 3379 This section establishes the Request Status subregistry under the 3380 BFCP Parameters registry. As per the terminology in RFC 5226 [5], 3381 the registration policy for BFCP request status shall be 3382 "Specification Required". For the purposes of this subregistry, the 3383 BFCP request status for which IANA registration is requested MUST be 3384 defined by a standards-track RFC. Such an RFC MUST specify the value 3385 and the semantics of the request status. 3387 For each BFCP request status, the IANA registers its value, its 3388 meaning, and the reference to the RFC where the request status is 3389 defined. The following table contains the initial values of this 3390 subregistry. 3392 +-------+-----------+------------+ 3393 | Value | Status | Reference | 3394 +-------+-----------+------------+ 3395 | 1 | Pending | [RFC XXXX] | 3396 | 2 | Accepted | [RFC XXXX] | 3397 | 3 | Granted | [RFC XXXX] | 3398 | 4 | Denied | [RFC XXXX] | 3399 | 5 | Cancelled | [RFC XXXX] | 3400 | 6 | Released | [RFC XXXX] | 3401 | 7 | Revoked | [RFC XXXX] | 3402 +-------+-----------+------------+ 3404 Table 9: Initial values of the Request Status subregistry 3406 15.4. Error Code Subregistry 3408 [Editorial note: This section instructs the IANA to register the 3409 following new values for the BFCP Error Code subregistry: 10, 11, 3410 12, 13 and 14.] 3412 This section establishes the Error Code subregistry under the BFCP 3413 Parameters registry. As per the terminology in RFC 5226 [5], the 3414 registration policy for BFCP error codes shall be "Specification 3415 Required". For the purposes of this subregistry, the BFCP error 3416 codes for which IANA registration is requested MUST be defined by a 3417 standards-track RFC. Such an RFC MUST specify the value and the 3418 semantics of the error code, and any Error Specific Details that 3419 apply to it. 3421 For each BFCP primitive, the IANA registers its value, its meaning, 3422 and the reference to the RFC where the primitive is defined. The 3423 following table contains the initial values of this subregistry. 3425 +-------+--------------------------------------+------------+ 3426 | Value | Meaning | Reference | 3427 +-------+--------------------------------------+------------+ 3428 | 1 | Conference does not Exist | [RFC XXXX] | 3429 | 2 | User does not Exist | [RFC XXXX] | 3430 | 3 | Unknown Primitive | [RFC XXXX] | 3431 | 4 | Unknown Mandatory Attribute | [RFC XXXX] | 3432 | 5 | Unauthorized Operation | [RFC XXXX] | 3433 | 6 | Invalid Floor ID | [RFC XXXX] | 3434 | 7 | Floor Request ID Does Not Exist | [RFC XXXX] | 3435 | 8 | You have Already Reached the Maximum | [RFC XXXX] | 3436 | | Number of Ongoing Floor Requests for | | 3437 | | this Floor | | 3438 | 9 | Use TLS | [RFC XXXX] | 3439 | 10 | Unable to parse message | [RFC XXXX] | 3440 | 11 | Use DTLS | [RFC XXXX] | 3441 | 12 | Unsupported Version | [RFC XXXX] | 3442 | 13 | Incorrect Message Length | [RFC XXXX] | 3443 | 14 | Generic Error | [RFC XXXX] | 3444 +-------+--------------------------------------+------------+ 3446 Table 10: Initial Values of the Error Code subregistry 3448 16. Changes from RFC 4582 3450 Following is the list of technical changes and other non-trivial 3451 fixes from [2]. 3453 16.1. Extensions for an unreliable transport 3455 Main purpose of this work was to revise the specification to support 3456 BFCP over an unreliable transport, resulting in the following 3457 changes: 3459 1. Overview of Operation (Section 4): 3460 Changed the description of client-initiated and server-initiated 3461 transactions, referring to Section 8. 3463 2. COMMON-HEADER Format (Section 5.1): 3464 Ver(sion) field, where the value 2 is used for the extensions 3465 for an unreliable transport. Added new R and F flag-bits for an 3466 unreliable transport. Res(erved) field is now 3 bit. New 3467 optional Fragment Offset and Fragment Length fields. 3469 3. New primitives (Section 5.1): 3470 Added four new primitives: FloorRequestStatusAck, 3471 FloorStatusAck, Goodbye, and GoodbyeAck. 3473 4. New error codes (Section 5.2.6): 3474 Added three new error codes: "Unable to Parse Message", "Use 3475 DTLS" and "Unsupported Version". Note that two additional error 3476 codes were added, see Section 16.2. 3478 5. ABNF for new primitives (Section 5.3): 3479 New subsections with normative ABNF for the new primitives. 3481 6. Transport split in two (Section 6): 3482 Section 6 specifying the transport was split in two subsections; 3483 Section 6.1 for a reliable transport and Section 6.2 for an 3484 unreliable transport. Where the specification for an unreliable 3485 transport amongst other issues deals with reliability, 3486 congestion control, fragmentation and ICMP. 3488 7. Mandate DTLS (Section 7 and Section 9): 3489 Mandate DTLS support when transport over UDP is used. 3491 8. Transaction changes (Section 8): 3492 Server-initiated transactions over an unreliable transport has 3493 non-zero and unique Transaction ID. Over an unreliable 3494 transport, the retransmit timers T1 and T2 described in 3495 Section 8.3 apply. 3497 9. Requiring timely response (Section 8.3, Section 10.1.2, 3498 Section 10.2.2, Section 11.2, Section 12.1.2, Section 12.2.2, 3499 Section 12.3.2, Section 12.4.2, Section 10.1.3 and 3500 Section 12.1.3): 3501 Describing that a given response must be sent within the 3502 transaction failure window to complete the transaction. 3504 10. Updated IANA Considerations (Section 15): 3505 Added the new primitives and error codes to Section 15.2 and 3506 Section 15.4 respectively. 3508 11. Examples over an unreliable transport (Appendix A): 3509 Added sample interactions over an unreliable transport for the 3510 scenarios in Figure 2 and Figure 3 3512 12. Motivation for an unreliable transport (Appendix B): 3513 Introduction to and motivation for extending BFCP to support an 3514 unreliable transport. 3516 16.2. Other changes 3518 The clarification and bug fixes: 3520 1. ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>, 3521 Figure 28, Figure 30, and the ABNF figures in Section 5.3): 3522 Although formally correct in [2], the notation has changed in a 3523 number of Figures to an equivalent form for clarity, e.g., 3524 s/*1(FLOOR-ID)/[FLOOR-ID]/ in Figure 38 and s/*[XXX]/*(XXX)/ in 3525 the other figures. 3527 2. Typo (Section 12.4.2): 3528 Change from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the 3529 second paragraph. 3531 3. Corrected attribute type (Section 13.1.1): 3532 Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in 3533 the eighth paragraph, since the note below describes priority and 3534 that the last paragraph deals with PARTICIPANT-PROVIDED-INFO. 3536 4. New error codes (Section 5.2.6): 3537 Added two additional error codes: "Incorrect Message Length" and 3538 "Generic Error". 3540 5. Assorted clarifications (Across the document): 3541 Non-functional language clarifications and some corrections in 3542 the normative language as a result of reviews. 3544 17. Acknowledgements 3546 The XCON WG chairs, Adam Roach and Alan Johnston, provided useful 3547 ideas for RFC 4582 [2]. Additionally, Xiaotao Wu, Paul Kyzivat, 3548 Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben 3549 Campbell, Dave Morgan, and Oscar Novo provided useful comments during 3550 the work with RFC 4582. The authors also acknowledge contributions 3551 to the revision of BFCP for use over an unreliable transport from 3552 Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad, 3553 Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, 3554 Joerg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, 3555 Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman, 3556 Vijaya Mandava and Alan Ford. In the final phase Ernst Horvath did a 3557 thorough review revealing issues that needed clarification and 3558 changes. Useful and important final reviews were done by Mary 3559 Barnes. 3561 18. References 3562 18.1. Normative References 3564 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3565 Levels", BCP 14, RFC 2119, March 1997. 3567 [2] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control 3568 Protocol (BFCP)", RFC 4582, November 2006. 3570 [3] Camarillo, G., "Connection Establishment in the Binary Floor 3571 Control Protocol (BFCP)", RFC 5018, September 2007. 3573 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 3574 Specifications: ABNF", STD 68, RFC 5234, January 2008. 3576 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3577 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 3579 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 3580 Protocol Version 1.2", RFC 5246, August 2008. 3582 [7] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3583 Security Version 1.2", RFC 6347, January 2012. 3585 [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 3586 STD 63, RFC 3629, November 2003. 3588 [9] Camarillo, G. and T. Kristensen, "Session Description Protocol 3589 (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", 3590 draft-ietf-bfcpbis-rfc4583bis-09 (work in progress), 3591 February 2014. 3593 [10] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 3594 BCP 131, RFC 4961, July 2007. 3596 [11] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 3597 Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. 3599 18.2. Informational References 3601 [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 3602 Session Description Protocol (SDP)", RFC 3264, June 2002. 3604 [13] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, 3605 "Requirements for Floor Control Protocols", RFC 4376, 3606 February 2006. 3608 [14] Barnes, M., Boulton, C., and O. Levin, "A Framework for 3609 Centralized Conferencing", RFC 5239, June 2008. 3611 [15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 3612 Protocol for Network Address Translator (NAT) Traversal for 3613 Offer/Answer Protocols", RFC 5245, April 2010. 3615 [16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 3616 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 3617 Session Initiation Protocol", RFC 3261, June 2002. 3619 [17] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 3620 "Conference Information Data Model for Centralized Conferencing 3621 (XCON)", RFC 6501, March 2012. 3623 [18] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, 3624 "Centralized Conferencing Manipulation Protocol", RFC 6503, 3625 March 2012. 3627 [19] Barnes, M., Miniero, L., Presta, R., and SP. Romano, 3628 "Centralized Conferencing Manipulation Protocol (CCMP) Call 3629 Flow Examples", RFC 6504, March 2012. 3631 [20] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 3632 November 1990. 3634 [21] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for 3635 IP version 6", RFC 1981, August 1996. 3637 [22] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 3638 Discovery", RFC 4821, March 2007. 3640 [23] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for 3641 Establishing a Secure Real-time Transport Protocol (SRTP) 3642 Security Context Using Datagram Transport Layer Security 3643 (DTLS)", RFC 5763, May 2010. 3645 [24] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network 3646 Address Translations (NATs)", RFC 4380, February 2006. 3648 [25] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for 3649 Application Designers", BCP 145, RFC 5405, November 2008. 3651 [26] Thaler, D., "Teredo Extensions", RFC 6081, January 2011. 3653 [27] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 3654 September 2007. 3656 [28] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP 3657 Candidates with Interactive Connectivity Establishment (ICE)", 3658 RFC 6544, March 2012. 3660 [29] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling 3661 (GUT)", draft-manner-tsvwg-gut-02 (work in progress), 3662 July 2010. 3664 [30] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of 3665 Middlebox Interactions for Signaling Protocol Communication 3666 along the Media Path", 3667 draft-ietf-mmusic-media-path-middleboxes-05 (work in progress), 3668 July 2012. 3670 [31] Guha, S. and P. Francis, "Characterization and Measurement of 3671 TCP Traversal through NATs and Firewalls", 2005, 3672 . 3674 [32] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer 3675 Communication Across Network Address Translators", April 2005, 3676 . 3678 Appendix A. Example Call Flows for BFCP over an Unreliable Transport 3680 With reference to Section 4.1, the following figures show 3681 representative call-flows for requesting and releasing a floor, and 3682 obtaining status information about a floor when BFCP is deployed over 3683 an unreliable transport. The figures here show a loss-less 3684 interaction. 3686 Floor Participant Floor Control 3687 Server 3688 |(1) FloorRequest | 3689 |Transaction ID: 123 | 3690 |User ID: 234 | 3691 |FLOOR-ID: 543 | 3692 |---------------------------------------------->| 3693 | | 3694 |(2) FloorRequestStatus | 3695 |Transaction ID: 123 | 3696 |User ID: 234 | 3697 |FLOOR-REQUEST-INFORMATION | 3698 | Floor Request ID: 789 | 3699 | OVERALL-REQUEST-STATUS | 3700 | Request Status: Pending | 3701 | FLOOR-REQUEST-STATUS | 3702 | Floor ID: 543 | 3703 |<----------------------------------------------| 3704 | | 3705 |(3) FloorRequestStatus | 3706 |Transaction ID: 124 | 3707 |User ID: 234 | 3708 |FLOOR-REQUEST-INFORMATION | 3709 | Floor Request ID: 789 | 3710 | OVERALL-REQUEST-STATUS | 3711 | Request Status: Accepted | 3712 | Queue Position: 1st | 3713 | FLOOR-REQUEST-STATUS | 3714 | Floor ID: 543 | 3715 |<----------------------------------------------| 3716 | | 3717 |(4) FloorRequestStatusAck | 3718 |Transaction ID: 124 | 3719 |User ID: 234 | 3720 |---------------------------------------------->| 3721 | | 3722 |(5) FloorRequestStatus | 3723 |Transaction ID: 125 | 3724 |User ID: 234 | 3725 |FLOOR-REQUEST-INFORMATION | 3726 | Floor Request ID: 789 | 3727 | OVERALL-REQUEST-STATUS | 3728 | Request Status: Granted | 3729 | FLOOR-REQUEST-STATUS | 3730 | Floor ID: 543 | 3731 |<----------------------------------------------| 3732 | | 3733 |(6) FloorRequestStatusAck | 3734 |Transaction ID: 125 | 3735 |User ID: 234 | 3736 |---------------------------------------------->| 3737 | | 3738 |(7) FloorRelease | 3739 |Transaction ID: 126 | 3740 |User ID: 234 | 3741 |FLOOR-REQUEST-ID: 789 | 3742 |---------------------------------------------->| 3743 | | 3744 |(8) FloorRequestStatus | 3745 |Transaction ID: 126 | 3746 |User ID: 234 | 3747 |FLOOR-REQUEST-INFORMATION | 3748 | Floor Request ID: 789 | 3749 | OVERALL-REQUEST-STATUS | 3750 | Request Status: Released | 3751 | FLOOR-REQUEST-STATUS | 3752 | Floor ID: 543 | 3753 |<----------------------------------------------| 3755 Figure 48: Requesting and releasing a floor 3757 Note that in Figure 48, the FloorRequestStatus message from the floor 3758 control server to the floor participant is a transaction-closing 3759 message as a response to the client-initiated transaction with 3760 Transaction ID 154. It does not and SHOULD NOT be followed by a 3761 FloorRequestStatusAck message from the floor participant to the floor 3762 control server. 3764 Floor Participant Floor Control 3765 Server 3766 |(1) FloorQuery | 3767 |Transaction ID: 257 | 3768 |User ID: 234 | 3769 |FLOOR-ID: 543 | 3770 |---------------------------------------------->| 3771 | | 3772 |(2) FloorStatus | 3773 |Transaction ID: 257 | 3774 |User ID: 234 | 3775 |FLOOR-ID:543 | 3776 |FLOOR-REQUEST-INFORMATION | 3777 | Floor Request ID: 764 | 3778 | OVERALL-REQUEST-STATUS | 3779 | Request Status: Accepted | 3780 | Queue Position: 1st | 3781 | FLOOR-REQUEST-STATUS | 3782 | Floor ID: 543 | 3783 | BENEFICIARY-INFORMATION | 3784 | Beneficiary ID: 124 | 3785 |FLOOR-REQUEST-INFORMATION | 3786 | Floor Request ID: 635 | 3787 | OVERALL-REQUEST-STATUS | 3788 | Request Status: Accepted | 3789 | Queue Position: 2nd | 3790 | FLOOR-REQUEST-STATUS | 3791 | Floor ID: 543 | 3792 | BENEFICIARY-INFORMATION | 3793 | Beneficiary ID: 154 | 3794 |<----------------------------------------------| 3795 | | 3796 |(3) FloorStatus | 3797 |Transaction ID: 258 | 3798 |User ID: 234 | 3799 |FLOOR-ID:543 | 3800 |FLOOR-REQUEST-INFORMATION | 3801 | Floor Request ID: 764 | 3802 | OVERALL-REQUEST-STATUS | 3803 | Request Status: Granted | 3804 | FLOOR-REQUEST-STATUS | 3805 | Floor ID: 543 | 3806 | BENEFICIARY-INFORMATION | 3807 | Beneficiary ID: 124 | 3808 |FLOOR-REQUEST-INFORMATION | 3809 | Floor Request ID: 635 | 3810 | OVERALL-REQUEST-STATUS | 3811 | Request Status: Accepted | 3812 | Queue Position: 1st | 3813 | FLOOR-REQUEST-STATUS | 3814 | Floor ID: 543 | 3815 | BENEFICIARY-INFORMATION | 3816 | Beneficiary ID: 154 | 3817 |<----------------------------------------------| 3818 | | 3819 |(4) FloorStatusAck | 3820 |Transaction ID: 258 | 3821 |User ID: 234 | 3822 |---------------------------------------------->| 3823 | | 3824 |(5) FloorStatus | 3825 |Transaction ID: 259 | 3826 |User ID: 234 | 3827 |FLOOR-ID:543 | 3828 |FLOOR-REQUEST-INFORMATION | 3829 | Floor Request ID: 635 | 3830 | OVERALL-REQUEST-STATUS | 3831 | Request Status: Granted | 3832 | FLOOR-REQUEST-STATUS | 3833 | Floor ID: 543 | 3834 | BENEFICIARY-INFORMATION | 3835 | Beneficiary ID: 154 | 3836 |<----------------------------------------------| 3837 | | 3838 |(6) FloorStatusAck | 3839 |Transaction ID: 259 | 3840 |User ID: 234 | 3841 |---------------------------------------------->| 3843 Figure 49: Obtaining status information about a floor 3845 Appendix B. Motivation for Supporting an Unreliable Transport 3847 This appendix is contained in this document as an aid to understand 3848 the background and rationale for adding support for unreliable 3849 transport. 3851 B.1. Motivation 3853 In existing video conferencing deployments, BFCP is used to manage 3854 the floor for the content sharing associated with the conference. 3855 For peer to peer scenarios, including business to business 3856 conferences and point to point conferences in general, it is 3857 frequently the case that one or both endpoints exists behind a NAT. 3858 BFCP roles are negotiated in the offer/answer exchange as specified 3859 in [9], resulting in one endpoint being responsible for opening the 3860 TCP connection used for the BFCP communication. 3862 +---------+ 3863 | Network | 3864 +---------+ 3865 +-----+ / \ +-----+ 3866 | NAT |/ \| NAT | 3867 +-----+ +-----+ 3868 +----+ / \ +----+ 3869 |BFCP|/ \|BFCP| 3870 | UA | | UA | 3871 +----+ +----+ 3873 Figure 50: Use Case 3875 The communication session between the video conferencing endpoints 3876 typically consists of a number of RTP over UDP media streams, for 3877 audio and video, and a BFCP connection for floor control. Existing 3878 deployments are most common in, but not limited to, enterprise 3879 networks. In existing deployments, NAT traversal for the RTP streams 3880 works using ICE and/or other methods, including those described in 3881 [30]. 3883 When enhancing an existing SIP based video conferencing deployment 3884 with support for content sharing, the BFCP connection often poses a 3885 problem. The reasons for this fall into two general classes. First, 3886 there may be a strong preference for UDP based signaling in general. 3887 On high capacity endpoints (e.g., PSTN gateways or SIP/H.323 inter- 3888 working gateways), TCP can suffer from head of line blocking, and it 3889 uses many kernel buffers. Network operators view UDP as a way to 3890 avoid both of these. Second, establishment and traversal of the TCP 3891 connection involving ephemeral ports, as is typically the case with 3892 BFCP over TCP, can be problematic, as described in Appendix A of 3893 [28]. A broad study of NAT behavior and peer-to-peer TCP 3894 establishment for a comprehensive set of TCP NAT traversal techniques 3895 over a wide range of commercial NAT products concluded it was not 3896 possible to establish a TCP connection in 11% of the cases [31]. The 3897 results are worse when focusing on enterprise NATs. A study of hole 3898 punching as a NAT traversal technique across a wide variety of 3899 deployed NATs reported consistently higher success rates when using 3900 UDP than when using TCP [32]. 3902 It is worth noticing that BFCP over UDP were already used in real 3903 deployments, underlining the necessity to specify a common way to 3904 exchange BFCP messages where TCP is not appropriate, to avoid a 3905 situation where multiple different and non-interoperable would co- 3906 exist in the market. The purpose of this draft is to formalize and 3907 publish the extension from the standard specification to facilitate 3908 complete interoperability between implementations. 3910 B.1.1. Alternatives Considered 3912 In selecting the approach of defining UDP as an alternate transport 3913 for BFCP, several alternatives were considered and explored to some 3914 degree. Each of these is discussed briefly in the following 3915 subsections. In summary, while the not chosen alternatives work in a 3916 number of scenarios, they are not sufficient, in and of themselves, 3917 to address the use case targeted by this draft. The last 3918 alternative, presented in Appendix B.1.1.7, is the selected one and 3919 is specified in this draft. 3921 It is also worth noting that the IETF Transport Area were asked for a 3922 way to tunnel TCP over UDP, but at that point there was no consensus 3923 on how to achieve that. 3925 B.1.1.1. ICE TCP 3927 ICE TCP [28] extends ICE to TCP based media, including the ability to 3928 offer a mix of TCP and UDP based candidates for a single stream. ICE 3929 TCP has, in general, a lower success probability for enabling TCP 3930 connectivity without a relay if both of the hosts are behind a NAT 3931 (see Appendix A of [28]) than enabling UDP connectivity in the same 3932 scenarios. The happens because many of the currently deployed NATs 3933 in video conferencing networks do not support the flow of TCP hand 3934 shake packets seen in case of TCP simultaneous-open, either because 3935 they do not allow incoming TCP SYN packets from an address to which a 3936 SYN packet has been sent to recently, or because they do not properly 3937 process the subsequent SYNACK. Implementing various techniques 3938 advocated for candidate collection in [28] should increase the 3939 success probability, but many of these techniques require support 3940 from some network elements (e.g., from the NATs). Such support is 3941 not common in enterprise NATs. 3943 B.1.1.2. Teredo 3945 Teredo [24] enables nodes located behind one or more IPv4 NATs to 3946 obtain IPv6 connectivity by tunneling packets over UDP. Teredo 3947 extensions [26] provide additional capabilities to Teredo, including 3948 support for more types of NATs and support for more efficient 3949 communication. 3951 As defined, Teredo could be used to make BFCP work for the video 3952 conferencing use cases addressed in this draft. However, running the 3953 service requires the help of "Teredo servers" and "Teredo relays" 3954 [24]. These servers and relays generally do not exist in the 3955 existing video conferencing deployments. It also requires IPv6 3956 awareness on the endpoints. It should also be noted that ICMP6, as 3957 used with Teredo to complete an initial protocol exchange and confirm 3958 that the appropriate NAT bindings have been set up, is not a 3959 conventional feature of IPv4 or even IPv6, and some currently 3960 deployed IPv6 firewalls discard ICMP messages. As these networks 3961 continue to evolve and tackle the transaction to IPv6, Teredo servers 3962 and relays may be deployed, making Teredo available as a suitable 3963 alternative to BFCP over UDP. 3965 B.1.1.3. GUT 3967 GUT [29] attempts to facilitate tunneling over UDP by encapsulating 3968 the native transport protocol and its payload (in general the whole 3969 IP payload) within a UDP packet destined to the well-known port 3970 GUT_P. Unfortunately, it requires user-space TCP, for which there is 3971 not a readily available implementation, and creating one is a large 3972 project in itself. This draft has expired and its future is still 3973 not clear as it has not yet been adopted by a working group. 3975 B.1.1.4. UPnP IGD 3977 Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on 3978 the edge of the network, providing connectivity to the Internet for 3979 computers internal to the LAN, but do not allow Internet devices to 3980 connect to computers on the internal LAN. IGDs enable a computer on 3981 an internal LAN to create port mappings on their NAT, through which 3982 hosts on the Internet can send data that will be forwarded to the 3983 computer on the internal LAN. IGDs may be self-contained hardware 3984 devices or may be software components provided within an operating 3985 system. 3987 In considering UPnP IGD, several issues exist. Not all NATs support 3988 UPnP, and many that do support it are configured with it turned off 3989 by default. NATs are often multilayered, and UPnP does not work well 3990 with such NATs. For example, a typical DSL modems acts as a NAT, and 3991 the user plugs in a wireless access point behind that, which adds 3992 another layer NAT. The client can discover the first layer of NAT 3993 using multicast but it is harder to figure out how to discover and 3994 control NATs in the next layer up. 3996 B.1.1.5. NAT PMP 3998 The NAT Port Mapping Protocol (NAT PMP) allows a computer in a 3999 private network (behind a NAT router) to automatically configure the 4000 router to allow parties outside the private network to contact it. 4001 NAT PMP runs over UDP. It essentially automates the process of port 4002 forwarding. Included in the protocol is a method for retrieving the 4003 public IP address of a NAT gateway, thus allowing a client to make 4004 this public IP address and port number known to peers that may wish 4005 to communicate with it. 4007 Many NATs do not support PMP. In those that do support it, it has 4008 similar issues with negotiation of multilayer NATs as UPnP. Video 4009 conferencing is used extensively in enterprise networks, and NAT PMP 4010 is not generally available in enterprise-class routers. 4012 B.1.1.6. SCTP 4014 It would be quite straight forward to specify a BFCP binding for SCTP 4015 [27], and then tunnel SCTP over UDP in the use case described in 4016 Appendix B.1. SCTP is gaining some momentum currently. There is 4017 ongoing discussion in the RTCWeb WG regarding this approach. 4018 However, this approach for tunneling over UDP was not mature enough 4019 when considered and not even fully specified. 4021 B.1.1.7. BFCP over UDP transport 4023 To overcome the problems with establishing TCP flows between BFCP 4024 entities, an alternative is to define UDP as an alternate transport 4025 for BFCP, leveraging the same mechanisms in place for the RTP over 4026 UDP media streams for the BFCP communication. When using UDP as the 4027 transport, it is recommended to follow the guidelines provided in 4028 [25]. 4030 Minor changes to the transaction model are introduced in that all 4031 requests now have an appropriate response to complete the 4032 transaction. The requests are sent with a retransmit timer 4033 associated with the response to achieve reliability. This 4034 alternative does not change the semantics of BFCP. It permits UDP as 4035 an alternate transport. 4037 Existing implementations, in the spirit of the approach detailed in 4038 earlier versions of this draft, have demonstrated this approach to be 4039 feasible. Initial compatibility among implementations has been 4040 achieved at previous interoperability events. The authors view this 4041 extension as a pragmatic solution to an existing deployment 4042 challenge. This is the chosen approach, and the extensions is 4043 specified in this document. 4045 Authors' Addresses 4047 Gonzalo Camarillo 4048 Ericsson 4049 Hirsalantie 11 4050 Jorvas 02420 4051 Finland 4053 Email: gonzalo.camarillo@ericsson.com 4055 Keith Drage 4056 Alcatel-Lucent 4057 Quadrant, StoneHill Green, Westlea 4058 Swindon, Wilts 4059 UK 4061 Email: drage@alcatel-lucent.com 4063 Tom Kristensen 4064 Cisco 4065 Philip Pedersens vei 22 4066 N-1366 Lysaker 4067 Norway 4069 Email: tomkrist@cisco.com, tomkri@ifi.uio.no 4071 Joerg Ott 4072 Aalto University 4073 Otakaari 5 A 4074 Espoo, FIN 02150 4075 Finland 4077 Email: jo@comnet.tkk.fi 4078 Charles Eckel 4079 Cisco 4080 707 Tasman Drive 4081 California, CA 95035 4082 United States 4084 Email: eckelcu@cisco.com