idnits 2.17.1 draft-ietf-bfcpbis-rfc4582bis-13.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 19, 2015) is 3355 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 3421 ** 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-11 ** 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) == Outdated reference: A later version (-11) exists of draft-ietf-uta-tls-bcp-09 -- Obsolete informational reference (is this intentional?): RFC 5405 (ref. '26') (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '28') (Obsoleted by RFC 9260) == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-media-path-middleboxes-05 Summary: 5 errors (**), 0 flaws (~~), 5 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 23, 2015 T. Kristensen 7 Cisco 8 J. Ott 9 Aalto University 10 C. Eckel 11 Cisco 12 February 19, 2015 14 The Binary Floor Control Protocol (BFCP) 15 draft-ietf-bfcpbis-rfc4582bis-13 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 23, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 41 121 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42 122 6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . . 42 123 6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 44 124 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 44 125 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 45 126 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 45 127 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 46 128 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 46 129 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 46 130 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 46 131 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 46 132 9. Authentication and Authorization . . . . . . . . . . . . . . . 47 133 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 48 134 10. Floor Participant Operations . . . . . . . . . . . . . . . . . 48 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 . . . . . 51 141 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 51 142 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 52 143 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 52 144 11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 52 145 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 54 146 12. General Client Operations . . . . . . . . . . . . . . . . . . 54 147 12.1. Requesting Information about Floors . . . . . . . . . . . 54 148 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 54 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 . . . . . . . . . 56 153 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 56 154 12.3. Requesting Information about a User . . . . . . . . . . . 57 155 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 57 156 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 58 157 12.4. Obtaining the Capabilities of a Floor Control Server . . . 58 158 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 58 159 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 58 160 13. Floor Control Server Operations . . . . . . . . . . . . . . . 59 161 13.1. Reception of a FloorRequest Message . . . . . . . . . . . 59 162 13.1.1. Generating the First FloorRequestStatus Message . . . 60 163 13.1.2. Generation of Subsequent FloorRequestStatus 164 Messages . . . . . . . . . . . . . . . . . . . . . . . 61 165 13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 62 166 13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 64 167 13.4. Reception of a FloorRelease Message . . . . . . . . . . . 65 168 13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 66 169 13.5.1. Generation of the First FloorStatus Message . . . . . 67 170 13.5.2. Generation of Subsequent FloorStatus Messages . . . . 68 171 13.6. Reception of a ChairAction Message . . . . . . . . . . . . 69 172 13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 70 173 13.8. Error Message Generation . . . . . . . . . . . . . . . . . 70 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 . . 85 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 when using a reliable transport 369 is described in [3]. Other mechanisms are described in the XCON 370 framework [14] (and other related documents). For unreliable 371 transports, the use of an SDP offer/answer exchange is the only 372 specified mechanism. 374 3.3. Obtaining Floor-Resource Associations 376 Floors are associated with resources. For example, a floor that 377 controls who talks at a given time has a particular audio session as 378 its associated resource. Associations between floors and resources 379 are part of the conference object. 381 Floor participants and floor chairs need to know which resources are 382 associated with which floors. They can obtain this information by 383 using different mechanisms, such as an SDP offer/answer [12] 384 exchange. How to use an SDP offer/answer exchange to obtain these 385 associations is described in [9]. 387 Note that floor participants perform SDP offer/answer exchanges 388 with the conference focus of the conference. So, the conference 389 focus needs to obtain information about associations between 390 floors and resources in order to be able to provide this 391 information to a floor participant in an SDP offer/answer 392 exchange. 394 Other mechanisms for obtaining this information, including discussion 395 of how the information is made available to a (SIP) Focus, are 396 described in the XCON framework [14] (and other related documents). 397 According to the conferencing system policies, conference control 398 clients using CCMP [18] can modify the floor settings of a conference 399 by issuing CCMP confRequest/update messages providing the specific 400 updates to the element of the target conference 401 object. More information about CCMP and BFCP interaction can be 402 found in [19]. 404 3.4. Privileges of Floor Control 406 A participant whose floor request is granted has the right to use the 407 resource or resources associated with the floor that was requested. 408 For example, the participant may have the right to send media over a 409 particular audio stream. 411 Nevertheless, holding a floor does not imply that others will not be 412 able to use its associated resources at the same time, even if they 413 do not have the right to do so. Determination of which media 414 participants can actually use the resources in the conference is 415 discussed in the XCON Framework [14]. 417 4. Overview of Operation 419 This section provides a non-normative description of BFCP operations. 420 Section 4.1 describes the interface between floor participants and 421 floor control servers, and Section 4.2 describes the interface 422 between floor chairs and floor control servers. 424 BFCP messages, which use a TLV (Type-Length-Value) binary encoding, 425 consist of a common header followed by a set of attributes. The 426 common header contains, among other information, a 32-bit conference 427 identifier. Floor participants, media participants, and floor chairs 428 are identified by 16-bit user identifiers. 430 BFCP supports nested attributes (i.e., attributes that contain 431 attributes). These are referred to as grouped attributes. 433 There are two types of transactions in BFCP: client-initiated 434 transactions and server-initiated transactions. Section 8 describes 435 both types of transactions in detail. 437 4.1. Floor Participant to Floor Control Server Interface 439 Floor participants request a floor by sending a FloorRequest message 440 to the floor control server. BFCP supports third-party floor 441 requests. That is, the floor participant sending the floor request 442 need not be colocated with the media participant that will get the 443 floor once the floor request is granted. FloorRequest messages carry 444 the identity of the requester in the User ID field of the common 445 header, and the identity of the beneficiary of the floor (in third- 446 party floor requests) in a BENEFICIARY-ID attribute. 448 Third-party floor requests can be sent, for example, by floor 449 participants that have a BFCP connection to the floor control 450 server but that are not media participants (i.e., they do not 451 handle any media). 453 FloorRequest messages identify the floor or floors being requested by 454 carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a 455 FloorRequest message carries more than one floor identifier, the 456 floor control server treats all the floor requests as an atomic 457 package. That is, the floor control server either grants or denies 458 all the floors in the FloorRequest message. 460 Floor control servers respond to FloorRequest messages with 461 FloorRequestStatus messages, which provide information about the 462 status of the floor request. The first FloorRequestStatus message is 463 the response to the FloorRequest message from the client, and 464 therefore has the same Transaction ID as the FloorRequest. 466 Additionally, the first FloorRequestStatus message carries the Floor 467 Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent 468 FloorRequestStatus messages related to the same floor request will 469 carry the same Floor Request ID. This way, the floor participant can 470 associate them with the appropriate floor request. 472 Messages from the floor participant related to a particular floor 473 request also use the same Floor Request ID as the first 474 FloorRequestStatus Message from the floor control server. 476 Figures 2 and 3 below show examples of call flows where BFCP is used 477 over a reliable transport. Appendix A shows the same call flow 478 examples using an unreliable transport. 480 Figure 2 shows how a floor participant requests a floor, obtains it, 481 and, at a later time, releases it. This figure illustrates the use, 482 among other things, of the Transaction ID and the FLOOR-REQUEST-ID 483 attribute. 485 Floor Participant Floor Control 486 Server 487 |(1) FloorRequest | 488 |Transaction ID: 123 | 489 |User ID: 234 | 490 |FLOOR-ID: 543 | 491 |---------------------------------------------->| 492 | | 493 |(2) FloorRequestStatus | 494 |Transaction ID: 123 | 495 |User ID: 234 | 496 |FLOOR-REQUEST-INFORMATION | 497 | Floor Request ID: 789 | 498 | OVERALL-REQUEST-STATUS | 499 | Request Status: Pending | 500 | FLOOR-REQUEST-STATUS | 501 | Floor ID: 543 | 502 |<----------------------------------------------| 503 | | 504 |(3) FloorRequestStatus | 505 |Transaction ID: 0 | 506 |User ID: 234 | 507 |FLOOR-REQUEST-INFORMATION | 508 | Floor Request ID: 789 | 509 | OVERALL-REQUEST-STATUS | 510 | Request Status: Accepted | 511 | Queue Position: 1st | 512 | FLOOR-REQUEST-STATUS | 513 | Floor ID: 543 | 514 |<----------------------------------------------| 515 | | 516 |(4) FloorRequestStatus | 517 |Transaction ID: 0 | 518 |User ID: 234 | 519 |FLOOR-REQUEST-INFORMATION | 520 | Floor Request ID: 789 | 521 | OVERALL-REQUEST-STATUS | 522 | Request Status: Granted | 523 | FLOOR-REQUEST-STATUS | 524 | Floor ID: 543 | 525 |<----------------------------------------------| 526 | | 527 |(5) FloorRelease | 528 |Transaction ID: 154 | 529 |User ID: 234 | 530 |FLOOR-REQUEST-ID: 789 | 531 |---------------------------------------------->| 532 | | 533 |(6) FloorRequestStatus | 534 |Transaction ID: 154 | 535 |User ID: 234 | 536 |FLOOR-REQUEST-INFORMATION | 537 | Floor Request ID: 789 | 538 | OVERALL-REQUEST-STATUS | 539 | Request Status: Released | 540 | FLOOR-REQUEST-STATUS | 541 | Floor ID: 543 | 542 |<----------------------------------------------| 544 Figure 2: Requesting and releasing a floor 546 Figure 3 shows how a floor participant requests to be informed on the 547 status of a floor. The first FloorStatus message from the floor 548 control server is the response to the FloorQuery message and, as 549 such, has the same Transaction ID as the FloorQuery message. 551 Subsequent FloorStatus messages consist of server-initiated 552 transactions, and therefore their Transaction ID is 0. FloorStatus 553 message (2) indicates that there are currently two floor requests for 554 the floor whose Floor ID is 543. FloorStatus message (3) indicates 555 that the floor requests with Floor Request ID 764 has been granted, 556 and the floor request with Floor Request ID 635 is the first in the 557 queue. FloorStatus message (4) indicates that the floor request with 558 Floor Request ID 635 has been granted. 560 Floor Participant Floor Control 561 Server 562 |(1) FloorQuery | 563 |Transaction ID: 257 | 564 |User ID: 234 | 565 |FLOOR-ID: 543 | 566 |---------------------------------------------->| 567 | | 568 |(2) FloorStatus | 569 |Transaction ID: 257 | 570 |User ID: 234 | 571 |FLOOR-ID:543 | 572 |FLOOR-REQUEST-INFORMATION | 573 | Floor Request ID: 764 | 574 | OVERALL-REQUEST-STATUS | 575 | Request Status: Accepted | 576 | Queue Position: 1st | 577 | FLOOR-REQUEST-STATUS | 578 | Floor ID: 543 | 579 | BENEFICIARY-INFORMATION | 580 | Beneficiary ID: 124 | 581 |FLOOR-REQUEST-INFORMATION | 582 | Floor Request ID: 635 | 583 | OVERALL-REQUEST-STATUS | 584 | Request Status: Accepted | 585 | Queue Position: 2nd | 586 | FLOOR-REQUEST-STATUS | 587 | Floor ID: 543 | 588 | BENEFICIARY-INFORMATION | 589 | Beneficiary ID: 154 | 590 |<----------------------------------------------| 591 | | 592 |(3) FloorStatus | 593 |Transaction ID: 0 | 594 |User ID: 234 | 595 |FLOOR-ID:543 | 596 |FLOOR-REQUEST-INFORMATION | 597 | Floor Request ID: 764 | 598 | OVERALL-REQUEST-STATUS | 599 | Request Status: Granted | 600 | FLOOR-REQUEST-STATUS | 601 | Floor ID: 543 | 602 | BENEFICIARY-INFORMATION | 603 | Beneficiary ID: 124 | 604 |FLOOR-REQUEST-INFORMATION | 605 | Floor Request ID: 635 | 606 | OVERALL-REQUEST-STATUS | 607 | Request Status: Accepted | 608 | Queue Position: 1st | 609 | FLOOR-REQUEST-STATUS | 610 | Floor ID: 543 | 611 | BENEFICIARY-INFORMATION | 612 | Beneficiary ID: 154 | 613 |<----------------------------------------------| 614 | | 615 |(4) FloorStatus | 616 |Transaction ID: 0 | 617 |User ID: 234 | 618 |FLOOR-ID:543 | 619 |FLOOR-REQUEST-INFORMATION | 620 | Floor Request ID: 635 | 621 | OVERALL-REQUEST-STATUS | 622 | Request Status: Granted | 623 | FLOOR-REQUEST-STATUS | 624 | Floor ID: 543 | 625 | BENEFICIARY-INFORMATION | 626 | Beneficiary ID: 154 | 627 |<----------------------------------------------| 629 Figure 3: Obtaining status information about a floor 631 FloorStatus messages contain information about the floor requests 632 they carry. For example, FloorStatus message (4) indicates that the 633 floor request with Floor Request ID 635 has as the beneficiary (i.e., 634 the participant that holds the floor when a particular floor request 635 is granted) the participant whose User ID is 154. The floor request 636 applies only to the floor whose Floor ID is 543. That is, this is 637 not a multi-floor floor request. 639 A multi-floor floor request applies to more than one floor (e.g., 640 a participant wants to be able to speak and write on the 641 whiteboard at the same time). The floor control server treats a 642 multi-floor floor request as an atomic package. That is, the 643 floor control server either grants the request for all floors or 644 denies the request for all floors. 646 4.2. Floor Chair to Floor Control Server Interface 648 Figure 4 shows a floor chair instructing a floor control server to 649 grant a floor. 651 Note, however, that although the floor control server needs to 652 take into consideration the instructions received in ChairAction 653 messages (e.g., granting a floor), it does not necessarily need to 654 perform them exactly as requested by the floor chair. The 655 operation that the floor control server performs depends on the 656 ChairAction message and on the internal state of the floor control 657 server. 659 For example, a floor chair may send a ChairAction message granting a 660 floor that was requested as part of an atomic floor request operation 661 that involved several floors. Even if the chair responsible for one 662 of the floors instructs the floor control server to grant the floor, 663 the floor control server will not grant it until the chairs 664 responsible for the other floors agree to grant them as well. In 665 another example, a floor chair may instruct the floor control server 666 to grant a floor to a participant. The floor control server needs to 667 revoke the floor from its current holder before granting it to the 668 new participant. 670 So, the floor control server is ultimately responsible for keeping a 671 coherent floor state using instructions from floor chairs as input to 672 this state. 674 Floor Chair Floor Control 675 Server 676 |(1) ChairAction | 677 |Transaction ID: 769 | 678 |User ID: 357 | 679 |FLOOR-REQUEST-INFORMATION | 680 | Floor Request ID: 635 | 681 | FLOOR-REQUEST-STATUS | 682 | Floor ID: 543 | 683 | Request Status: Granted | 684 |---------------------------------------------->| 685 | | 686 |(2) ChairActionAck | 687 |Transaction ID: 769 | 688 |User ID: 357 | 689 |<----------------------------------------------| 691 Figure 4: Chair instructing the floor control server 693 5. Packet Format 695 BFCP packets consist of a 12-octet common header followed by 696 attributes. All the protocol values MUST be sent in network byte 697 order. 699 5.1. COMMON-HEADER Format 701 The following is the format of the common header. 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Ver |R|F| Res | Primitive | Payload Length | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Conference ID | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Transaction ID | User ID | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Fragment Offset (if F is set) | Fragment Length (if F is set) | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Figure 5: COMMON-HEADER format 717 Ver: This 3-bit field defines the version of BFCP that this message 718 adheres to. This specification defines two versions: 1 and 2. The 719 version field MUST be set to 1 when using BFCP over a reliable 720 transport. The version field MUST be set to 2 when using BFCP over 721 an unreliable transport. If a floor control server receives a 722 message with an unsupported version field value, and the extensions 723 in this document is supported, the receiving server MUST send an 724 Error message with parameter value 12 (Unsupported Version) to 725 indicate this. Note that endpoints supporting only the RFC 4582 726 subset will not support this parameter value. 728 R: The Transaction Responder (R) flag-bit has relevance only for use 729 of BFCP over an unreliable transport. When cleared, it indicates 730 that this message is a request initiating a new transaction, and the 731 Transaction ID that follows has been generated for this transaction. 732 When set, it indicates that this message is a response to a previous 733 request, and the Transaction ID that follows is the one associated 734 with that request. When BFCP is used over a reliable transport, the 735 flag has no significance and MUST be cleared by the sender and MUST 736 be ignored by the receiver. 738 F: The Fragmentation (F) flag-bit has relevance only for use of BFCP 739 over an unreliable transport. When cleared, the message is not 740 fragmented. When set, it indicates that the message is a fragment of 741 a large fragmented BFCP message. (The optional fields Fragment 742 Offset and Fragment Length described below are present only if the F 743 flag is set). When BFCP is used over a reliable transport, the flag 744 has no significance and MUST be cleared by the sender and MUST be 745 ignored by the receiver. 747 Res: At this point, the 3 bits in the reserved field MUST be set to 748 zero by the sender of the message and MUST be ignored by the 749 receiver. 751 Primitive: This 8-bit field identifies the main purpose of the 752 message. The following primitive values are defined: 754 +-------+-----------------------+--------------------+ 755 | Value | Primitive | Direction | 756 +-------+-----------------------+--------------------+ 757 | 1 | FloorRequest | P -> S | 758 | 2 | FloorRelease | P -> S | 759 | 3 | FloorRequestQuery | P -> S ; Ch -> S | 760 | 4 | FloorRequestStatus | P <- S ; Ch <- S | 761 | 5 | UserQuery | P -> S ; Ch -> S | 762 | 6 | UserStatus | P <- S ; Ch <- S | 763 | 7 | FloorQuery | P -> S ; Ch -> S | 764 | 8 | FloorStatus | P <- S ; Ch <- S | 765 | 9 | ChairAction | Ch -> S | 766 | 10 | ChairActionAck | Ch <- S | 767 | 11 | Hello | P -> S ; Ch -> S | 768 | 12 | HelloAck | P <- S ; Ch <- S | 769 | 13 | Error | P <- S ; Ch <- S | 770 | 14 | FloorRequestStatusAck | P -> S ; Ch -> S | 771 | 15 | FloorStatusAck | P -> S ; Ch -> S | 772 | 16 | Goodbye | P -> S ; Ch -> S ; | 773 | | | P <- S ; Ch <- S | 774 | 17 | GoodbyeAck | P -> S ; Ch -> S ; | 775 | | | P <- S ; Ch <- S | 776 +-------+-----------------------+--------------------+ 778 S: Floor Control Server / P: Floor Participant / Ch: Floor Chair 780 Table 1: BFCP primitives 782 Payload Length: This 16-bit field contains the length of the message 783 in 4-octet units, excluding the common header. If a Floor Control 784 Server receives a message with an incorrect Payload Length field 785 value, the receiving server MUST send an Error message with parameter 786 value 13 (Incorrect Message Length) to indicate this. 788 Note: BFCP is designed to achieve small message size, as explained 789 in Section 1, and BFCP entities are REQUIRED to keep the BFCP 790 message size smaller than the size limited by the 16-bit Payload 791 Length field. To convey information not strictly related to floor 792 control, other protocols should be used such as the XCON framework 793 (cf. Section 3). 795 Conference ID: This 32-bit unsigned integer field identifies the 796 conference the message belongs to. 798 Transaction ID: This field contains a 16-bit value that allows users 799 to match a given message with its response (see Section 8). 801 User ID: This field contains a 16-bit unsigned integer that uniquely 802 identifies a participant within a conference. 804 The identity used by a participant in BFCP, which is carried in 805 the User ID field, is generally mapped to the identity used by the 806 same participant in the session establishment protocol (e.g., in 807 SIP). The way this mapping is performed is outside the scope of 808 this specification. 810 Fragment Offset: This optional field is present only if the F flag is 811 set and contains a 16-bit value that specifies the number of 4-octet 812 units contained in previous fragments, excluding the common header. 814 Fragment Length: This optional field is present only if the F flag is 815 set and contains a 16-bit value that specifies the number of 4-octet 816 units contained in this fragment, excluding the common header. 818 5.2. Attribute Format 820 BFCP attributes are encoded in TLV (Type-Length-Value) format. 821 Attributes are 32-bit aligned. 823 0 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Type |M| Length | | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 828 | | 829 / Attribute Contents / 830 / / 831 | | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 Figure 6: Attribute format 836 Type: This 7-bit field contains the type of the attribute. Each 837 attribute, identified by its type, has a particular format. The 838 attribute formats defined are: 840 Unsigned16: The contents of the attribute consist of a 16-bit 841 unsigned integer. 843 OctetString16: The contents of the attribute consist of 16 bits of 844 arbitrary data. 846 OctetString: The contents of the attribute consist of arbitrary 847 data of variable length. 849 Grouped: The contents of the attribute consist of a sequence of 850 attributes. 852 Note that extension attributes defined in the future may define 853 new attribute formats. 855 The following attribute types are defined: 857 +------+---------------------------+---------------+ 858 | Type | Attribute | Format | 859 +------+---------------------------+---------------+ 860 | 1 | BENEFICIARY-ID | Unsigned16 | 861 | 2 | FLOOR-ID | Unsigned16 | 862 | 3 | FLOOR-REQUEST-ID | Unsigned16 | 863 | 4 | PRIORITY | OctetString16 | 864 | 5 | REQUEST-STATUS | OctetString16 | 865 | 6 | ERROR-CODE | OctetString | 866 | 7 | ERROR-INFO | OctetString | 867 | 8 | PARTICIPANT-PROVIDED-INFO | OctetString | 868 | 9 | STATUS-INFO | OctetString | 869 | 10 | SUPPORTED-ATTRIBUTES | OctetString | 870 | 11 | SUPPORTED-PRIMITIVES | OctetString | 871 | 12 | USER-DISPLAY-NAME | OctetString | 872 | 13 | USER-URI | OctetString | 873 | 14 | BENEFICIARY-INFORMATION | Grouped | 874 | 15 | FLOOR-REQUEST-INFORMATION | Grouped | 875 | 16 | REQUESTED-BY-INFORMATION | Grouped | 876 | 17 | FLOOR-REQUEST-STATUS | Grouped | 877 | 18 | OVERALL-REQUEST-STATUS | Grouped | 878 +------+---------------------------+---------------+ 880 Table 2: BFCP attributes 882 M: The 'M' bit, known as the Mandatory bit, indicates whether support 883 of the attribute is required. If a Floor Control Server receives an 884 unrecognized attribute with the 'M' bit set the server MUST send an 885 Error message with parameter value 4 (Unknown Mandatory Attribute) to 886 indicate this. The 'M' bit is significant for extension attributes 887 defined in other documents only. All attributes specified in this 888 document MUST be understood by the receiver so that the setting of 889 the 'M' bit is irrelevant for these. In all other cases, the 890 unrecognized attribute is ignored but the message is processed. 892 Length: This 8-bit field contains the length of the attribute in 893 octets, excluding any padding defined for specific attributes. The 894 length of attributes that are not grouped includes the Type, 'M' bit, 895 and Length fields. The Length in grouped attributes is the length of 896 the grouped attribute itself (including Type, 'M' bit, and Length 897 fields) plus the total length (including padding) of all the included 898 attributes. 900 Attribute Contents: The contents of the different attributes are 901 defined in the following sections. 903 5.2.1. BENEFICIARY-ID 905 The following is the format of the BENEFICIARY-ID attribute. 907 0 1 2 3 908 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 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 Figure 7: BENEFICIARY-ID format 915 Beneficiary ID: This field contains a 16-bit value that uniquely 916 identifies a user within a conference. 918 Note that although the formats of the Beneficiary ID and of the 919 User ID field in the common header are similar, their semantics 920 are different. The Beneficiary ID is used in third-party floor 921 requests and to request information about a particular 922 participant. 924 5.2.2. FLOOR-ID 926 The following is the format of the FLOOR-ID attribute. 928 0 1 2 3 929 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 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 Figure 8: FLOOR-ID format 936 Floor ID: This field contains a 16-bit value that uniquely identifies 937 a floor within a conference. 939 5.2.3. FLOOR-REQUEST-ID 941 The following is the format of the FLOOR-REQUEST-ID attribute. 943 0 1 2 3 944 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 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 Figure 9: FLOOR-REQUEST-ID format 951 Floor Request ID: This field contains a 16-bit value that identifies 952 a floor request at the floor control server. 954 5.2.4. PRIORITY 956 The following is the format of the PRIORITY attribute. 958 0 1 2 3 959 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 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 Figure 10: PRIORITY format 966 Prio: This field contains a 3-bit priority value, as shown in 967 Table 3. Senders SHOULD NOT use values higher than 4 in this field. 968 Receivers MUST treat values higher than 4 as if the value received 969 were 4 (Highest). The default priority value when the PRIORITY 970 attribute is missing is 2 (Normal). 972 +-------+----------+ 973 | Value | Priority | 974 +-------+----------+ 975 | 0 | Lowest | 976 | 1 | Low | 977 | 2 | Normal | 978 | 3 | High | 979 | 4 | Highest | 980 +-------+----------+ 982 Table 3: Priority values 984 Reserved: At this point, the 13 bits in the reserved field MUST be 985 set to zero by the sender of the message and MUST be ignored by the 986 receiver. 988 5.2.5. REQUEST-STATUS 990 The following is the format of the REQUEST-STATUS attribute. 992 0 1 2 3 993 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 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 Figure 11: REQUEST-STATUS format 1000 Request Status: This 8-bit field contains the status of the request, 1001 as described in the following table. 1003 +-------+-----------+ 1004 | Value | Status | 1005 +-------+-----------+ 1006 | 1 | Pending | 1007 | 2 | Accepted | 1008 | 3 | Granted | 1009 | 4 | Denied | 1010 | 5 | Cancelled | 1011 | 6 | Released | 1012 | 7 | Revoked | 1013 +-------+-----------+ 1015 Table 4: Request Status values 1017 Queue Position: This 8-bit field contains, when applicable, the 1018 position of the floor request in the floor request queue at the 1019 server. If the Request Status value is different from Accepted, if 1020 the floor control server does not implement a floor request queue, or 1021 if the floor control server does not want to provide the client with 1022 this information, all the bits of this field SHOULD be set to zero. 1024 A floor request is in Pending state if the floor control server needs 1025 to contact a floor chair in order to accept the floor request, but 1026 has not done it yet. Once the floor control chair accepts the floor 1027 request, the floor request is moved to the Accepted state. 1029 5.2.6. ERROR-CODE 1031 The following is the format of the ERROR-CODE attribute. 1033 0 1 2 3 1034 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 |0 0 0 0 1 1 0|M| Length | Error Code | | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1038 | | 1039 | Error Specific Details | 1040 / / 1041 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | | Padding | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 Figure 12: ERROR-CODE format 1047 Error Code: This 8-bit field contains an error code from the 1048 following table. If an error code is not recognized by the receiver, 1049 then the receiver MUST assume that an error exists, and therefore 1050 that the original message that triggered the Error message to be sent 1051 is processed, but the nature of the error is unclear. 1053 +-------+-----------------------------------------------------------+ 1054 | Value | Meaning | 1055 +-------+-----------------------------------------------------------+ 1056 | 1 | Conference does not Exist | 1057 | 2 | User does not Exist | 1058 | 3 | Unknown Primitive | 1059 | 4 | Unknown Mandatory Attribute | 1060 | 5 | Unauthorized Operation | 1061 | 6 | Invalid Floor ID | 1062 | 7 | Floor Request ID Does Not Exist | 1063 | 8 | You have Already Reached the Maximum Number of Ongoing | 1064 | | Floor Requests for this Floor | 1065 | 9 | Use TLS | 1066 | 10 | Unable to Parse Message | 1067 | 11 | Use DTLS | 1068 | 12 | Unsupported Version | 1069 | 13 | Incorrect Message Length | 1070 | 14 | Generic Error | 1071 +-------+-----------------------------------------------------------+ 1073 Table 5: Error Code meaning 1075 Note: The Generic Error error code is intended to be used when an 1076 error occurs and the other specific error codes do not apply. 1078 Error Specific Details: Present only for certain Error Codes. In 1079 this document, only for Error Code 4 (Unknown Mandatory Attribute). 1080 See Section 5.2.6.1 for its definition. 1082 Padding: One, two, or three octets of padding added so that the 1083 contents of the ERROR-CODE attribute is 32-bit aligned. If the 1084 attribute is already 32-bit aligned, no padding is needed. 1086 The Padding bits MUST be set to zero by the sender and MUST be 1087 ignored by the receiver. 1089 5.2.6.1. Error-Specific Details for Error Code 4 1091 The following is the format of the Error-Specific Details field for 1092 Error Code 4. 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | | 1100 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | | Unknown Type|R| Unknown Type|R| 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Unknown Type|R| Unknown Type|R| 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 Figure 13: Unknown attributes format 1108 Unknown Type: These 7-bit fields contain the Types of the attributes 1109 (which were present in the message that triggered the Error message) 1110 that were unknown to the receiver. 1112 R: At this point, this bit is reserved. It MUST be set to zero by 1113 the sender of the message and MUST be ignored by the receiver. 1115 5.2.7. ERROR-INFO 1117 The following is the format of the ERROR-INFO attribute. 1119 0 1 2 3 1120 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 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 |0 0 0 0 1 1 1|M| Length | | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1124 | | 1125 / Text / 1126 / +-+-+-+-+-+-+-+-+ 1127 | | Padding | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 Figure 14: ERROR-INFO format 1132 Text: This field contains UTF-8 [8] encoded text. 1134 In some situations, the contents of the Text field may be generated 1135 by an automaton. If this automaton has information about the 1136 preferred language of the receiver of a particular ERROR-INFO 1137 attribute, it MAY use this language to generate the Text field. 1139 Padding: One, two, or three octets of padding added so that the 1140 contents of the ERROR-INFO attribute is 32-bit aligned. The Padding 1141 bits MUST be set to zero by the sender and MUST be ignored by the 1142 receiver. If the attribute is already 32-bit aligned, no padding is 1143 needed. 1145 5.2.8. PARTICIPANT-PROVIDED-INFO 1147 The following is the format of the PARTICIPANT-PROVIDED-INFO 1148 attribute. 1150 0 1 2 3 1151 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 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 |0 0 0 1 0 0 0|M| Length | | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1155 | | 1156 / Text / 1157 / +-+-+-+-+-+-+-+-+ 1158 | | Padding | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 Figure 15: PARTICIPANT-PROVIDED-INFO format 1163 Text: This field contains UTF-8 [8] encoded text. 1165 Padding: One, two, or three octets of padding added so that the 1166 contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit 1167 aligned. The Padding bits MUST be set to zero by the sender and MUST 1168 be ignored by the receiver. If the attribute is already 32-bit 1169 aligned, no padding is needed. 1171 5.2.9. STATUS-INFO 1173 The following is the format of the STATUS-INFO attribute. 1175 0 1 2 3 1176 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 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 |0 0 0 1 0 0 1|M| Length | | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1180 | | 1181 / Text / 1182 / +-+-+-+-+-+-+-+-+ 1183 | | Padding | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 Figure 16: STATUS-INFO format 1188 Text: This field contains UTF-8 [8] encoded text. 1190 In some situations, the contents of the Text field may be generated 1191 by an automaton. If this automaton has information about the 1192 preferred language of the receiver of a particular STATUS-INFO 1193 attribute, it MAY use this language to generate the Text field. 1195 Padding: One, two, or three octets of padding added so that the 1196 contents of the STATUS-INFO attribute is 32-bit aligned. The Padding 1197 bits MUST be set to zero by the sender and MUST be ignored by the 1198 receiver. If the attribute is already 32-bit aligned, no padding is 1199 needed. 1201 5.2.10. SUPPORTED-ATTRIBUTES 1203 The following is the format of the SUPPORTED-ATTRIBUTES attribute. 1205 0 1 2 3 1206 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 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 |0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R| 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | | 1213 / / 1214 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | | Padding | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 Figure 17: SUPPORTED-ATTRIBUTES format 1220 Supp. Attr.: These fields contain the Types of the attributes that 1221 are supported by the floor control server in the following format: 1223 R: Reserved: This bit MUST be set to zero upon transmission and MUST 1224 be ignored upon reception. 1226 Padding: One, two, or three octets of padding added so that the 1227 contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If 1228 the attribute is already 32-bit aligned, no padding is needed. 1230 The Padding bits MUST be set to zero by the sender and MUST be 1231 ignored by the receiver. 1233 5.2.11. SUPPORTED-PRIMITIVES 1235 The following is the format of the SUPPORTED-PRIMITIVES attribute. 1237 0 1 2 3 1238 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 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 |0 0 0 1 0 1 1|M| Length | Primitive | Primitive | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | Primitive | Primitive | Primitive | Primitive | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | | 1245 / / 1246 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | | Padding | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 Figure 18: SUPPORTED-PRIMITIVES format 1252 Primitive: These fields contain the types of the BFCP messages that 1253 are supported by the floor control server. See Table 1 for the list 1254 of BFCP primitives. 1256 Padding: One, two, or three octets of padding added so that the 1257 contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If 1258 the attribute is already 32-bit aligned, no padding is needed. 1260 The Padding bits MUST be set to zero by the sender and MUST be 1261 ignored by the receiver. 1263 5.2.12. USER-DISPLAY-NAME 1265 The following is the format of the USER-DISPLAY-NAME attribute. 1267 0 1 2 3 1268 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 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 |0 0 0 1 1 0 0|M| Length | | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1272 | | 1273 / Text / 1274 / +-+-+-+-+-+-+-+-+ 1275 | | Padding | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 Figure 19: USER-DISPLAY-NAME format 1280 Text: This field contains the UTF-8 encoded name of the user. 1282 Padding: One, two, or three octets of padding added so that the 1283 contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The 1284 Padding bits MUST be set to zero by the sender and MUST be ignored by 1285 the receiver. If the attribute is already 32-bit aligned, no padding 1286 is needed. 1288 5.2.13. USER-URI 1290 The following is the format of the USER-URI attribute. 1292 0 1 2 3 1293 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 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 |0 0 0 1 1 0 1|M| Length | | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1297 | | 1298 / Text / 1299 / +-+-+-+-+-+-+-+-+ 1300 | | Padding | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 Figure 20: USER-URI format 1305 Text: This field contains the UTF-8 encoded user's contact URI, that 1306 is, the URI used by the user to set up the resources (e.g., media 1307 streams) that are controlled by BFCP. For example, in the context of 1308 a conference set up by SIP, the USER-URI attribute would carry the 1309 SIP URI of the user. 1311 Messages containing a user's URI in a USER-URI attribute also 1312 contain the user's User ID. This way, a client receiving such a 1313 message can correlate the user's URI (e.g., the SIP URI the user 1314 used to join a conference) with the user's User ID. 1316 Padding: One, two, or three octets of padding added so that the 1317 contents of the USER-URI attribute is 32-bit aligned. The Padding 1318 bits MUST be set to zero by the sender and MUST be ignored by the 1319 receiver. If the attribute is already 32-bit aligned, no padding is 1320 needed. 1322 5.2.14. BENEFICIARY-INFORMATION 1324 The BENEFICIARY-INFORMATION attribute is a grouped attribute that 1325 consists of a header, which is referred to as BENEFICIARY- 1326 INFORMATION-HEADER, followed by a sequence of attributes. The 1327 following is the format of the BENEFICIARY-INFORMATION-HEADER: 1329 0 1 2 3 1330 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 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 |0 0 0 1 1 1 0|M| Length | Beneficiary ID | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 Figure 21: BENEFICIARY-INFORMATION-HEADER format 1337 Beneficiary ID: This field contains a 16-bit value that uniquely 1338 identifies a user within a conference. 1340 The following is the ABNF (Augmented Backus-Naur Form) [4] of the 1341 BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE 1342 refers to extension attributes that may be defined in the future.) 1344 BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) 1345 [USER-DISPLAY-NAME] 1346 [USER-URI] 1347 *(EXTENSION-ATTRIBUTE) 1349 Figure 22: BENEFICIARY-INFORMATION format 1351 5.2.15. FLOOR-REQUEST-INFORMATION 1353 The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that 1354 consists of a header, which is referred to as FLOOR-REQUEST- 1355 INFORMATION-HEADER, followed by a sequence of attributes. The 1356 following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: 1358 0 1 2 3 1359 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 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 |0 0 0 1 1 1 1|M| Length | Floor Request ID | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format 1366 Floor Request ID: This field contains a 16-bit value that identifies 1367 a floor request at the floor control server. 1369 The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped 1370 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1371 may be defined in the future.) 1373 FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) 1374 [OVERALL-REQUEST-STATUS] 1375 1*(FLOOR-REQUEST-STATUS) 1376 [BENEFICIARY-INFORMATION] 1377 [REQUESTED-BY-INFORMATION] 1378 [PRIORITY] 1379 [PARTICIPANT-PROVIDED-INFO] 1380 *(EXTENSION-ATTRIBUTE) 1382 Figure 24: FLOOR-REQUEST-INFORMATION format 1384 5.2.16. REQUESTED-BY-INFORMATION 1386 The REQUESTED-BY-INFORMATION attribute is a grouped attribute that 1387 consists of a header, which is referred to as REQUESTED-BY- 1388 INFORMATION-HEADER, followed by a sequence of attributes. The 1389 following is the format of the REQUESTED-BY-INFORMATION-HEADER: 1391 0 1 2 3 1392 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 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 |0 0 1 0 0 0 0|M| Length | Requested-by ID | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 Figure 25: REQUESTED-BY-INFORMATION-HEADER format 1399 Requested-by ID: This field contains a 16-bit value that uniquely 1400 identifies a user within a conference. 1402 The following is the ABNF of the REQUESTED-BY-INFORMATION grouped 1403 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1404 may be defined in the future.) 1406 REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER) 1407 [USER-DISPLAY-NAME] 1408 [USER-URI] 1409 *(EXTENSION-ATTRIBUTE) 1411 Figure 26: REQUESTED-BY-INFORMATION format 1413 5.2.17. FLOOR-REQUEST-STATUS 1415 The FLOOR-REQUEST-STATUS attribute is a grouped attribute that 1416 consists of a header, which is referred to as FLOOR-REQUEST-STATUS- 1417 HEADER, followed by a sequence of attributes. The following is the 1418 format of the FLOOR-REQUEST-STATUS-HEADER: 1420 0 1 2 3 1421 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 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 |0 0 1 0 0 0 1|M| Length | Floor ID | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 Figure 27: FLOOR-REQUEST-STATUS-HEADER format 1428 Floor ID: this field contains a 16-bit value that uniquely identifies 1429 a floor within a conference. 1431 The following is the ABNF of the FLOOR-REQUEST-STATUS grouped 1432 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1433 may be defined in the future.) 1435 FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) 1436 [REQUEST-STATUS] 1437 [STATUS-INFO] 1438 *(EXTENSION-ATTRIBUTE) 1440 Figure 28: FLOOR-REQUEST-STATUS format 1442 5.2.18. OVERALL-REQUEST-STATUS 1444 The OVERALL-REQUEST-STATUS attribute is a grouped attribute that 1445 consists of a header, which is referred to as OVERALL-REQUEST-STATUS- 1446 HEADER, followed by a sequence of attributes. The following is the 1447 format of the OVERALL-REQUEST-STATUS-HEADER: 1449 0 1 2 3 1450 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 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 |0 0 1 0 0 1 0|M| Length | Floor Request ID | 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 Figure 29: OVERALL-REQUEST-STATUS-HEADER format 1457 Floor Request ID: this field contains a 16-bit value that identifies 1458 a floor request at the floor control server. 1460 The following is the ABNF of the OVERALL-REQUEST-STATUS grouped 1461 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1462 may be defined in the future.) 1464 OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER) 1465 [REQUEST-STATUS] 1466 [STATUS-INFO] 1467 *(EXTENSION-ATTRIBUTE) 1469 Figure 30: OVERALL-REQUEST-STATUS format 1471 5.3. Message Format 1473 This section contains the normative ABNF (Augmented Backus-Naur Form) 1474 [4] of the BFCP messages. Extension attributes that may be defined 1475 in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. 1477 5.3.1. FloorRequest 1479 Floor participants request a floor by sending a FloorRequest message 1480 to the floor control server. The following is the format of the 1481 FloorRequest message: 1483 FloorRequest = (COMMON-HEADER) 1484 1*(FLOOR-ID) 1485 [BENEFICIARY-ID] 1486 [PARTICIPANT-PROVIDED-INFO] 1487 [PRIORITY] 1488 *(EXTENSION-ATTRIBUTE) 1490 Figure 31: FloorRequest format 1492 5.3.2. FloorRelease 1494 Floor participants release a floor by sending a FloorRelease message 1495 to the floor control server. Floor participants also use the 1496 FloorRelease message to cancel pending floor requests. The following 1497 is the format of the FloorRelease message: 1499 FloorRelease = (COMMON-HEADER) 1500 (FLOOR-REQUEST-ID) 1501 *(EXTENSION-ATTRIBUTE) 1503 Figure 32: FloorRelease format 1505 5.3.3. FloorRequestQuery 1507 Floor participants and floor chairs request information about a floor 1508 request by sending a FloorRequestQuery message to the floor control 1509 server. The following is the format of the FloorRequestQuery 1510 message: 1512 FloorRequestQuery = (COMMON-HEADER) 1513 (FLOOR-REQUEST-ID) 1514 *(EXTENSION-ATTRIBUTE) 1516 Figure 33: FloorRequestQuery format 1518 5.3.4. FloorRequestStatus 1520 The floor control server informs floor participants and floor chairs 1521 about the status of their floor requests by sending them 1522 FloorRequestStatus messages. The following is the format of the 1523 FloorRequestStatus message: 1525 FloorRequestStatus = (COMMON-HEADER) 1526 (FLOOR-REQUEST-INFORMATION) 1527 *(EXTENSION-ATTRIBUTE) 1529 Figure 34: FloorRequestStatus format 1531 5.3.5. UserQuery 1533 Floor participants and floor chairs request information about a 1534 participant and the floor requests related to this participant by 1535 sending a UserQuery message to the floor control server. The 1536 following is the format of the UserQuery message: 1538 UserQuery = (COMMON-HEADER) 1539 [BENEFICIARY-ID] 1540 *(EXTENSION-ATTRIBUTE) 1542 Figure 35: UserQuery format 1544 5.3.6. UserStatus 1546 The floor control server provides information about participants and 1547 their related floor requests to floor participants and floor chairs 1548 by sending them UserStatus messages. The following is the format of 1549 the UserStatus message: 1551 UserStatus = (COMMON-HEADER) 1552 [BENEFICIARY-INFORMATION] 1553 *(FLOOR-REQUEST-INFORMATION) 1554 *(EXTENSION-ATTRIBUTE) 1556 Figure 36: UserStatus format 1558 5.3.7. FloorQuery 1560 Floor participants and floor chairs request information about a floor 1561 or floors by sending a FloorQuery message to the floor control 1562 server. The following is the format of the FloorRequest message: 1564 FloorQuery = (COMMON-HEADER) 1565 *(FLOOR-ID) 1566 *(EXTENSION-ATTRIBUTE) 1568 Figure 37: FloorQuery format 1570 5.3.8. FloorStatus 1572 The floor control server informs floor participants and floor chairs 1573 about the status (e.g., the current holder) of a floor by sending 1574 them FloorStatus messages. The following is the format of the 1575 FloorStatus message: 1577 FloorStatus = (COMMON-HEADER) 1578 [FLOOR-ID] 1579 *(FLOOR-REQUEST-INFORMATION) 1580 *(EXTENSION-ATTRIBUTE) 1582 Figure 38: FloorStatus format 1584 5.3.9. ChairAction 1586 Floor chairs send instructions to floor control servers by sending 1587 them ChairAction messages. The following is the format of the 1588 ChairAction message: 1590 ChairAction = (COMMON-HEADER) 1591 (FLOOR-REQUEST-INFORMATION) 1592 *(EXTENSION-ATTRIBUTE) 1594 Figure 39: ChairAction format 1596 5.3.10. ChairActionAck 1598 Floor control servers confirm that they have accepted a ChairAction 1599 message by sending a ChairActionAck message. The following is the 1600 format of the ChairActionAck message: 1602 ChairActionAck = (COMMON-HEADER) 1603 *(EXTENSION-ATTRIBUTE) 1605 Figure 40: ChairActionAck format 1607 5.3.11. Hello 1609 Floor participants and floor chairs check the liveliness of floor 1610 control servers by sending a Hello message. The following is the 1611 format of the Hello message: 1613 Hello = (COMMON-HEADER) 1614 *(EXTENSION-ATTRIBUTE) 1616 Figure 41: Hello format 1618 5.3.12. HelloAck 1620 Floor control servers confirm that they are alive on reception of a 1621 Hello message by sending a HelloAck message. The following is the 1622 format of the HelloAck message: 1624 HelloAck = (COMMON-HEADER) 1625 (SUPPORTED-PRIMITIVES) 1626 (SUPPORTED-ATTRIBUTES) 1627 *(EXTENSION-ATTRIBUTE) 1629 Figure 42: HelloAck format 1631 5.3.13. Error 1633 Floor control servers inform floor participants and floor chairs 1634 about errors processing requests by sending them Error messages. The 1635 following is the format of the Error message: 1637 Error = (COMMON-HEADER) 1638 (ERROR-CODE) 1639 [ERROR-INFO] 1640 *(EXTENSION-ATTRIBUTE) 1642 Figure 43: Error format 1644 5.3.14. FloorRequestStatusAck 1646 When communicating over an unreliable transport, floor participants 1647 and chairs acknowledge the receipt of a subsequent FloorRequestStatus 1648 message from the floor control server (cf. Section 13.1.2) by sending 1649 a FloorRequestStatusAck message. The following is the format of the 1650 FloorRequestStatusAck message: 1652 FloorRequestStatusAck = (COMMON-HEADER) 1653 *(EXTENSION-ATTRIBUTE) 1655 Figure 44: FloorRequestStatusAck format 1657 5.3.15. FloorStatusAck 1659 When communicating over an unreliable transport, floor participants 1660 and chairs acknowledge the receipt of a subsequent FloorStatus 1661 message from the floor control server (cf. Section 13.5.2) by sending 1662 a FloorStatusAck message. The following is the format of the 1663 FloorStatusAck message: 1665 FloorStatusAck = (COMMON-HEADER) 1666 *(EXTENSION-ATTRIBUTE) 1668 Figure 45: FloorStatusAck format 1670 5.3.16. Goodbye 1672 BFCP entities communicating over an unreliable transport that wish to 1673 dissociate themselves from their remote participant do so through the 1674 transmission of a Goodbye. The following is the format of the 1675 Goodbye message: 1677 Goodbye = (COMMON-HEADER) 1678 *(EXTENSION-ATTRIBUTE) 1680 Figure 46: Goodbye format 1682 5.3.17. GoodbyeAck 1684 BFCP entities communicating over an unreliable transport acknowledge 1685 the receipt of a Goodbye message from a peer. The following is the 1686 format of the GoodbyeAck message: 1688 GoodbyeAck = (COMMON-HEADER) 1689 *(EXTENSION-ATTRIBUTE) 1691 Figure 47: GoodbyeAck format 1693 6. Transport 1695 The transport over which BFCP entities exchange messages depends on 1696 the information the clients obtain for how to to contact the floor 1697 control server, as described in Section 3.2. Two transports are 1698 supported: TCP, appropriate where connectivity is not impeded by 1699 network elements such as NAT devices or media relays; and UDP for 1700 those deployments where TCP may not be applicable or appropriate. 1702 Informational note: In practice, products are configured to try 1703 one transport first and use the other transport as a fallback. 1704 Whether TCP or UDP is chosen as underlying transport depends on 1705 the type of product and the deployment environment. See 1706 Appendix B for additional considerations. 1708 6.1. Reliable Transport 1710 BFCP entities may elect to exchange BFCP messages using TCP 1711 connections. TCP provides an in-order reliable delivery of a stream 1712 of bytes. Consequently, message framing needs to be implemented in 1713 the application layer. BFCP implements application-layer framing 1714 using TLV-encoded attributes. 1716 A client MUST NOT use more than one TCP connection to communicate 1717 with a given floor control server within a conference. Nevertheless, 1718 if the same physical box handles different clients (e.g., a floor 1719 chair and a floor participant), which are identified by different 1720 User IDs, a separate connection per client is allowed. 1722 If a BFCP entity (a client or a floor control server) receives data 1723 that cannot be parsed, the entity MUST close the TCP connection, and 1724 the connection SHOULD be reestablished. Similarly, if a TCP 1725 connection cannot deliver a BFCP message and times out or receives an 1726 ICMP port unreachable message mid-connection, the TCP connection 1727 SHOULD be reestablished. 1729 The way connection reestablishment is handled depends on how the 1730 client obtains information to contact the floor control server. Once 1731 the TCP connection is reestablished, the client MAY resend those 1732 messages for which it did not get a response from the floor control 1733 server. 1735 If a floor control server detects that the TCP connection towards one 1736 of the floor participants is lost, it is up to the local policy of 1737 the floor control server what to do with the pending floor requests 1738 of the floor participant. In any case, it is RECOMMENDED that the 1739 floor control server keep the floor requests (i.e., that it does not 1740 cancel them) while the TCP connection is reestablished. 1742 If a client wishes to end its BFCP connection with a floor control 1743 server, the client closes (i.e., a graceful close) the TCP connection 1744 towards the floor control server. If a floor control server wishes 1745 to end its BFCP connection with a client (e.g., the Focus of the 1746 conference informs the floor control server that the client has been 1747 kicked out from the conference), the floor control server closes 1748 (i.e., a graceful close) the TCP connection towards the client. 1750 6.2. Unreliable Transport 1752 BFCP entities may elect to exchange BFCP messages using UDP 1753 datagrams. UDP is an unreliable transport where neither delivery nor 1754 ordering is assured. Each BFCP UDP datagram MUST contain exactly one 1755 BFCP message or message fragment. To keep large BFCP messages from 1756 being fragmented at the IP layer, the fragmentation of BFCP messages 1757 that exceed the path MTU size is performed at the BFCP level. 1758 Considerations related to fragmentation are covered in Section 6.2.3. 1759 The message format for BFCP messages is the same regardless of 1760 whether the messages are sent in UDP datagrams or over a TCP stream. 1762 Clients MUST announce their presence to the floor control server by 1763 sending a Hello message. The floor control server responds to the 1764 Hello message with a HelloAck message. The client considers the 1765 floor control service as present and available only upon receiving 1766 the HelloAck message. Situations where the floor control service is 1767 considered to have become unavailable due to ICMP messages are 1768 described in Section 6.2.2 and the behavior when timers fire is 1769 described in Section 8.3. 1771 As described in Section 8, each request sent by a floor participant 1772 or chair forms a client transaction that expects an acknowledgement 1773 message back from the floor control server within a retransmission 1774 window. Concordantly, messages sent by the floor control server that 1775 initiate new transactions (e.g., FloorStatus announcements as part of 1776 a FloorQuery subscription) require acknowledgement messages from the 1777 floor participant and chair entities to which they were sent. 1779 If a Floor Control Server receives data that cannot be parsed, the 1780 receiving server MUST send an Error message with parameter value 10 1781 (Unable to parse message) indicating receipt of a malformed message, 1782 given that it is possible to parse the received message to such an 1783 extent that an Error message may be built. 1785 Entities MUST have at most one outstanding request transaction per 1786 peer at any one time. Implicit subscriptions occur for a client- 1787 initiated request transaction whose acknowledgement is implied by the 1788 first server-initiated response for that transaction, followed by 1789 zero of more subsequent server-initiated messages corresponding to 1790 the same transaction. An example is a FloorRequest message for which 1791 there are potentially multiple responses from the floor control 1792 server as it processes intermediate states until a terminal state 1793 (e.g., Granted or Denied) is attained. The subsequent changes in 1794 state for the request are new transactions whose Transaction ID is 1795 determined by the floor control server and whose receipt by the 1796 client participant is acknowledged with a FloorRequestStatusAck 1797 message. 1799 By restricting entities to having at most one pending transaction 1800 open in a BFCP connection, both the out-of-order receipt of messages 1801 as well as the possibility for congestion are mitigated. Additional 1802 details regarding congestion control are provided in Section 6.2.1. 1803 A server-initiated request (e.g., a FloorStatus with an update from 1804 the floor control server) received by a participant before the 1805 initial FloorRequestStatus message that closes the client-initiated 1806 transaction that was instigated by the FloorRequest MUST be treated 1807 as superseding the information conveyed in any such late arriving 1808 response. As the floor control server cannot send a second update to 1809 the implicit floor status subscription until the first is 1810 acknowledged, ordinality is maintained. 1812 If a client wishes to end its BFCP connection with a floor control 1813 server, it is REQUIRED that the client send a Goodbye message to 1814 dissociate itself from any allocated resources. If a floor control 1815 server wishes to end its BFCP connection with a client (e.g., the 1816 Focus of the conference informs the floor control server that the 1817 client has been kicked out from the conference), it is REQUIRED that 1818 the floor control server send a Goodbye message towards the client. 1820 6.2.1. Congestion Control 1822 BFCP may be characterized to generate "low data-volume" traffic, per 1823 the classification in [26]. Nevertheless is it necessary to ensure 1824 suitable and necessary congestion control mechanisms are used for 1825 BFCP over UDP. As described in Section 6.2, within the same BFCP 1826 connection, every entity - client or server - is only allowed to send 1827 one request at a time, and await the acknowledging response. This 1828 way at most one datagram is sent per RTT given the message is not 1829 lost during transmission. In case the message is lost, the request 1830 retransmission timer T1 specified in Section 8.3.1 will fire and the 1831 message is retransmitted up to three times, in addition to the 1832 original transmission of the message. The default initial interval 1833 MUST be set to 500ms and the interval MUST be doubled after each 1834 retransmission attempt. This is identical to the specification of 1835 the timer A and its initial value T1 in SIP as described in Section 1836 17.1.1.2 of [16]. 1838 6.2.2. ICMP Error Handling 1840 If a BFCP entity receives an ICMP port unreachable message mid- 1841 connection, the entity MUST treat the BFCP connection as closed 1842 (e.g., an implicit Goodbye message from the peer). The entity MAY 1843 attempt to re-establish the BFCP connection afresh. The new BFCP 1844 connection will appear as originating from a wholly new floor 1845 participant, chair or floor control server with all state previously 1846 held about that participant lost. 1848 Informational note: The recommendation to treat the connection as 1849 closed in this case, stems from the fact that the peer entities 1850 cannot rely on IP and port tuple to uniquely identify the 1851 participant, nor would extending Hello to include an attribute 1852 that advertised what identity the entity previously was assigned 1853 (i.e., a User ID) be acceptable due to session hijacking. 1855 In deployments where NAT appliances or other such devices are present 1856 and affecting port reachability for each entity, one possibility is 1857 to utilize the peer connectivity checks, relay use and NAT pinhole 1858 maintenance mechanisms defined in ICE [15]. 1860 6.2.3. Fragmentation Handling 1862 When using UDP, a single BFCP message could be fragmented at the IP 1863 layer if its overall size exceeds the path MTU of the network. To 1864 avoid this happening at the IP layer, a fragmentation scheme for BFCP 1865 is defined below. 1867 BFCP is designed for achieving small message size, due to the binary 1868 encoding as described in Section 1. The fragmentation scheme is 1869 therefore deliberately kept simple and straightforward, since the 1870 probability of fragmentation of BFCP messages being required is 1871 small. By design, the fragmentation scheme does not acknowledge 1872 individual BFCP message fragments. The whole BFCP message is 1873 acknowledged if received completely. 1875 BFCP entities should consider the MTU size available between the 1876 sender and the receiver and MAY run MTU discovery, such as 1877 [20][21][22], for this purpose. 1879 When transmitting a BFCP message with size greater than the path MTU, 1880 the sender MUST fragment the message into a series of N contiguous 1881 data ranges. The value for N is defined as ceil(message size / MTU 1882 size), where ceil is the integer ceiling function. The sender then 1883 creates N BFCP fragment messages (one for each data range) with the 1884 same Transaction ID. The size of each of these N messages MUST be 1885 smaller than the path MTU. The F flag in the COMMON-HEADER is set to 1886 indicate fragmentation of the BFCP message. 1888 For each of these fragments the Fragment Offset and Fragment Length 1889 fields are included in the COMMON-HEADER. The Fragment Offset field 1890 denotes the number of bytes contained in the previous fragments. The 1891 Fragment Length contains the length of the fragment itself. Note 1892 that the Payload Length field contains the length of the entire, 1893 unfragmented message. 1895 When a BFCP implementation receives a BFCP message fragment, it MUST 1896 buffer the fragment until either it has received the entire BFCP 1897 message, or until the Response Retransmission Timer expires. The 1898 state machine should handle the BFCP message only after all the 1899 fragments for the message have been received. 1901 If a fragment of a BFCP message is lost, the sender will not receive 1902 an acknowledgement for the message. Therefore the sender will 1903 retransmit the message with same transaction ID as specified in 1904 Section 8.3. If the acknowledgement message sent by the receiver is 1905 lost, then the entire message will be resent by the sender. The 1906 receiver MUST then retransmit the acknowledgement. The receiver MAY 1907 discard an incomplete buffer utilizing the Response Retransmission 1908 Timer, starting the timer after the receipt of the first fragment. 1910 A Denial of Service (DoS) attack utilizing the fragmentation 1911 scheme described above is mitigated by the fact that the Response 1912 Retransmission Timer is started after receipt of the first BFCP 1913 message fragment. In addition, the Payload Length field can be 1914 compared with the Fragment Offset and Fragment Length fields to 1915 verify the message fragments as they arrive. To make DoS attacks 1916 with spoofed IP addresses difficult, BFCP entities SHOULD use the 1917 cookie exchange mechanism in DTLS [7]. 1919 When deciding message fragment size based on path MTU, the BFCP 1920 fragmentation handling should take into account how the DTLS record 1921 framing expands the datagram size as described in Section 4.1.1.1 of 1922 [7]. 1924 6.2.4. NAT Traversal 1926 One of the key benefits when using UDP for BFCP communication is the 1927 ability to leverage the existing NAT traversal infrastructure and 1928 strategies deployed to facilitate transport of the media associated 1929 with the video conferencing sessions. Depending on the given 1930 deployment, this infrastructure typically includes some subset of ICE 1931 [15]. 1933 In order to facilitate the initial establishment of NAT bindings, and 1934 to maintain those bindings once established, BFCP entities using an 1935 unreliable transport are RECOMMENDED to use STUN [11] Binding 1936 Indication for keep-alives, as described for ICE [15]. Section 6.7 1937 of [23] provides useful recommendations for middlebox interaction 1938 when DTLS is used. 1940 Informational note: Since the version number is set to 2 when BFCP 1941 is used over an unreliable transport, cf. the Ver field in 1942 Section 5.1, it is straight forward to distinguish between STUN 1943 and BFCP packets even without checking the STUN magic cookie [11]. 1945 In order to facilitate traversal of BFCP packets through NATs, BFCP 1946 entities using an unreliable transport are RECOMMENDED to use 1947 symmetric ports for sending and receiving BFCP packets, as 1948 recommended for RTP/RTCP [10]. 1950 7. Lower-Layer Security 1952 BFCP relies on lower-layer security mechanisms to provide replay and 1953 integrity protection and confidentiality. BFCP floor control servers 1954 and clients (which include both floor participants and floor chairs) 1955 MUST support TLS for transport over TCP [6] and MUST support DTLS [7] 1956 for transport over UDP. Any BFCP entity MAY support other security 1957 mechanisms. 1959 BFCP entities MUST support, at a minimum, the 1960 TLS_RSA_WITH_AES_128_CBC_SHA cipher suite [6] for backwards 1961 compatibility with existing implementations of RFC 4582. In 1962 accordance with the recommendations and guidelines in [24], BFCP 1963 entities SHOULD support the following cipher suites: 1965 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 1967 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 1969 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 1970 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 1972 8. Protocol Transactions 1974 In BFCP, there are two types of transactions: client-initiated 1975 transactions and server-initiated transactions. 1977 Client-initiated transactions consist of a request from a client to a 1978 floor control server and a response from the floor control server to 1979 the client. 1981 Server-initiated transactions have different requirements and 1982 behavior depending on underlying transport: 1984 When using a reliable transport, server-initiated transactions 1985 consist of a single message from a floor control server to a 1986 client (notifications). They do not trigger any response. 1988 When using an unreliable transport, server-initiated transactions 1989 consist of a request from a floor control server to a client and a 1990 response from the client to the floor control server. 1992 When using BFCP over an unreliable transport, retransmission timer T1 1993 (see Section 8.3) MUST be used for all requests until the transaction 1994 is completed. 1996 8.1. Client Behavior 1998 A client starting a client-initiated transaction MUST set the 1999 Conference ID in the common header of the message to the Conference 2000 ID for the conference that the client obtained previously. 2002 The client MUST set the Transaction ID value in the common header to 2003 a number that is different from 0 and that MUST NOT be reused in 2004 another message from the client until a response from the server is 2005 received for the transaction. The client uses the Transaction ID 2006 value to match this message with the response from the floor control 2007 server. When using BFCP over an unreliable transport, it is 2008 important to choose a Transaction ID value that lets the receiver 2009 distinguish the reception of the next message in a sequence of BFCP 2010 messages from a retransmission of a previous message. Therefore, 2011 BFCP entities using an unreliable transport MUST use monotonically 2012 increasing Transaction ID values (except for wrap-around). 2014 A client receiving a server-initiated transaction over an unreliable 2015 transport MUST copy the Transaction ID from the request received from 2016 the server into the response. 2018 8.2. Server Behavior 2020 A floor control server sending a response within a client-initiated 2021 transaction MUST copy the Conference ID, the Transaction ID, and the 2022 User ID from the request received from the client into the response. 2024 Server-initiated transactions MUST contain a Transaction ID equal to 2025 0 when BFCP is used over a reliable transport. Over an unreliable 2026 transport, the Transaction ID shall have the same properties as for 2027 client-initiated transactions. The server uses the Transaction ID 2028 value to match this message with the response from the floor 2029 participant or floor chair. 2031 8.3. Timers 2033 When BFCP entities are communicating over an unreliable transport, 2034 two retransmission timers are employed to help mitigate against loss 2035 of datagrams. Retransmission and response caching are not required 2036 when BFCP entities communicate over a reliable transport. 2038 8.3.1. Request Retransmission Timer, T1 2040 T1 is a timer that schedules retransmission of a request until an 2041 appropriate response is received or until the maximum number of 2042 retransmissions have occurred. The timer doubles on each re- 2043 transmit, failing after three unacknowledged retransmission attempts. 2045 If a valid response is not received for a client- or server-initiated 2046 transaction, the implementation MUST consider the BFCP connection as 2047 failed. Implementations SHOULD follow the reestablishment procedure 2048 described in section 6. 2050 8.3.2. Response Retransmission Timer, T2 2052 T2 is a timer that, when fired, signals that the BFCP entity can 2053 release knowledge of the transaction against which it is running. It 2054 is started upon the first transmission of the response to a request 2055 and is the only mechanism by which that response is released by the 2056 BFCP entity. Any subsequent retransmissions of the same request can 2057 be responded to by replaying the cached response, whilst that value 2058 is retained until the timer has fired. Refer to Section 6.2.3 for 2059 the role this timer has in the fragmentation handling scheme. 2061 8.3.3. Timer Values 2063 The table below defines the different timers required when BFCP 2064 entities communicate over an unreliable transport. 2066 +-------+--------------------------------------+---------+ 2067 | Timer | Description | Value/s | 2068 +-------+--------------------------------------+---------+ 2069 | T1 | Initial request retransmission timer | 0.5s | 2070 | T2 | Response retransmission timer | 10s | 2071 +-------+--------------------------------------+---------+ 2073 Table 6: Timers 2075 The default value for T1 is 500 ms, this is an estimate of the RTT 2076 for completing the transaction. T1 MAY be chosen larger, and this is 2077 RECOMMENDED if it is known in advance that the RTT is larger. 2078 Regardless of the value of T1, the exponential backoffs on 2079 retransmissions described in Section 8.3.1 MUST be used. 2081 T2 SHALL be set such that it encompasses all legal retransmissions 2082 per T1 plus a factor to accommodate network latency between BFCP 2083 entities. The default value is based on the sum of the three 2084 retransmissions related to T1 using its default value (7.5s) and an 2085 extra 2.5s is added to take into account potential messages in 2086 transit due to latency. 2088 9. Authentication and Authorization 2090 BFCP clients SHOULD authenticate the floor control server before 2091 sending any BFCP message to it or accepting any BFCP message from it. 2092 Similarly, floor control servers SHOULD authenticate a client before 2093 accepting any BFCP message from it or sending any BFCP message to it. 2095 If the signaling or control protocol traffic used to set up the 2096 conference is authenticated and confidentiality and integrity 2097 protected, and the extensions in this document is supported, the BFCP 2098 clients MUST authenticate the floor control server and the floor 2099 control servers MUST authenticate a client before communicating as 2100 described above. Note that endpoints supporting only the RFC 4582 2101 subset may not comply with this mandatory authentication requirement. 2103 BFCP supports TLS/DTLS mutual authentication between clients and 2104 floor control servers, as specified in Section 9.1. This is the 2105 RECOMMENDED authentication mechanism in BFCP. 2107 Note that future extensions may define additional authentication 2108 mechanisms. 2110 In addition to authenticating BFCP messages, floor control servers 2111 need to authorize them. On receiving an authenticated BFCP message, 2112 the floor control server checks whether the client sending the 2113 message is authorized. If the client is not authorized to perform 2114 the operation being requested, the floor control server generates an 2115 Error message, as described in Section 13.8, with an Error code with 2116 a value of 5 (Unauthorized Operation). Messages from a client that 2117 cannot be authorized MUST NOT be processed further. 2119 9.1. TLS/DTLS Based Mutual Authentication 2121 BFCP supports TLS/DTLS based mutual authentication between clients 2122 and floor control servers. If TLS/DTLS is used, an initial 2123 integrity-protected channel is REQUIRED between the client and the 2124 floor control server that can be used to exchange their self-signed 2125 certificates or, more commonly, the fingerprints of these 2126 certificates. These certificates are used at TLS/DTLS establishment 2127 time. 2129 The implementation of such an integrity-protected channel using 2130 SIP and the SDP offer/answer model is described in [9]. 2132 BFCP messages received over an authenticated TLS/DTLS connection are 2133 considered authenticated. A floor control server that receives a 2134 BFCP message over TCP/UDP (no TLS/DTLS) MAY request the use of TLS/ 2135 DTLS by generating an Error message, as described in Section 13.8, 2136 with an Error code with a value of 9 (Use TLS) or a value of 11 (Use 2137 DTLS) respectively. Clients configured to require the use of TLS/ 2138 DTLS MUST ignore unauthenticated messages. 2140 Note that future extensions may define additional authentication 2141 mechanisms that may not require an initial integrity-protected 2142 channel (e.g., authentication based on certificates signed by a 2143 certificate authority). 2145 As described in Section 9, floor control servers need to perform 2146 authorization before processing any message. In particular, the 2147 floor control server MUST check that messages arriving over a given 2148 authenticated TLS/DTLS connection use an authorized User ID (i.e., a 2149 User ID that the user that established the authenticated TLS/DTLS 2150 connection is allowed to use). 2152 10. Floor Participant Operations 2154 This section specifies how floor participants can perform different 2155 operations, such as requesting a floor, using the protocol elements 2156 described in earlier sections. Section 11 specifies operations that 2157 are specific to floor chairs, such as instructing the floor control 2158 server to grant or revoke a floor, and Section 12 specifies 2159 operations that can be performed by any client (i.e., both floor 2160 participants and floor chairs). 2162 10.1. Requesting a Floor 2164 A floor participant that wishes to request one or more floors does so 2165 by sending a FloorRequest message to the floor control server. 2167 10.1.1. Sending a FloorRequest Message 2169 The ABNF in Section 5.3.1 describes the attributes that a 2170 FloorRequest message can contain. In addition, the ABNF specifies 2171 normatively which of these attributes are mandatory, and which ones 2172 are optional. 2174 The floor participant sets the Conference ID and the Transaction ID 2175 in the common header following the rules given in Section 8.1. 2177 The floor participant sets the User ID in the common header to the 2178 floor participant's identifier. This User ID will be used by the 2179 floor control server to authenticate and authorize the request. If 2180 the sender of the FloorRequest message (identified by the User ID) is 2181 not the participant that would eventually get the floor (i.e., a 2182 third-party floor request), the sender SHOULD add a BENEFICIARY-ID 2183 attribute to the message identifying the beneficiary of the floor. 2185 Note that the name space for both the User ID and the Beneficiary 2186 ID is the same. That is, a given participant is identified by a 2187 single 16-bit value that can be used in the User ID in the common 2188 header and in several attributes: BENEFICIARY-ID, BENEFICIARY- 2189 INFORMATION, and REQUESTED-BY-INFORMATION. 2191 The floor participant MUST insert at least one FLOOR-ID attribute in 2192 the FloorRequest message. If the client inserts more than one 2193 FLOOR-ID attribute, the floor control server will treat all the floor 2194 requests as an atomic package. That is, the floor control server 2195 will either grant or deny all the floors in the FloorRequest message. 2197 The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute 2198 to state the reason why the floor or floors are being requested. The 2199 Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for 2200 human consumption. 2202 The floor participant may request that the server handle the floor 2203 request with a certain priority using a PRIORITY attribute. 2205 10.1.2. Receiving a Response 2207 A message from the floor control server is considered a response to 2208 the FloorRequest message if the message from the floor control server 2209 has the same Conference ID, Transaction ID, and User ID as the 2210 FloorRequest message, as described in Section 8.1. On receiving such 2211 a response, the floor participant follows the rules in Section 9 that 2212 relate to floor control server authentication. 2214 The successful processing of a FloorRequest message at the floor 2215 control server involves generating one or several FloorRequestStatus 2216 messages. The floor participant obtains a Floor Request ID in the 2217 Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in 2218 the first FloorRequestStatus message from the floor control server. 2219 Subsequent FloorRequestStatus messages from the floor control server 2220 regarding the same floor request will carry the same Floor Request ID 2221 in a FLOOR-REQUEST-INFORMATION attribute as the initial 2222 FloorRequestStatus message. This way, the floor participant can 2223 associate subsequent incoming FloorRequestStatus messages with the 2224 ongoing floor request. 2226 The floor participant obtains information about the status of the 2227 floor request in the FLOOR-REQUEST-INFORMATION attribute of each of 2228 the FloorRequestStatus messages received from the floor control 2229 server. This attribute is a grouped attribute, and as such it 2230 includes a number of attributes that provide information about the 2231 floor request. 2233 The OVERALL-REQUEST-STATUS attribute provides information about the 2234 overall status of the floor request. If the Request Status value is 2235 Granted, all the floors that were requested in the FloorRequest 2236 message have been granted. If the Request Status value is Denied, 2237 all the floors that were requested in the FloorRequest message have 2238 been denied. A floor request is considered to be ongoing while it is 2239 in the Pending, Accepted, or Granted states. If the floor request 2240 value is unknown, then the response is still processed. However, no 2241 meaningful value can be reported to the user. 2243 The STATUS-INFO attribute, if present, provides extra information 2244 that the floor participant can display to the user. 2246 The FLOOR-REQUEST-STATUS attributes provide information about the 2247 status of the floor request as it relates to a particular floor. The 2248 STATUS-INFO attribute, if present, provides extra information that 2249 the floor participant can display to the user. 2251 The BENEFICIARY-INFORMATION attribute identifies the beneficiary of 2252 the floor request in third-party floor requests. The REQUESTED-BY- 2253 INFORMATION attribute need not be present in FloorRequestStatus 2254 messages received by the floor participant that requested the floor, 2255 as this floor participant is already identified by the User ID in the 2256 common header. 2258 The PRIORITY attribute, when present, contains the priority that was 2259 requested by the generator of the FloorRequest message. 2261 If the response is an Error message, the floor control server could 2262 not process the FloorRequest message for some reason, which is 2263 described in the Error message. 2265 10.1.3. Reception of a Subsequent FloorRequestStatus Message 2267 When communicating over an unreliable transport and upon receiving a 2268 FloorRequestStatus message from a floor control server, the 2269 participant MUST respond with a FloorRequestStatusAck message within 2270 the transaction failure window to complete the transaction. 2272 10.2. Cancelling a Floor Request and Releasing a Floor 2274 A floor participant that wishes to cancel an ongoing floor request 2275 does so by sending a FloorRelease message to the floor control 2276 server. The FloorRelease message is also used by floor participants 2277 that hold a floor and would like to release it. 2279 10.2.1. Sending a FloorRelease Message 2281 The ABNF in Section 5.3.2 describes the attributes that a 2282 FloorRelease message can contain. In addition, the ABNF specifies 2283 normatively which of these attributes are mandatory, and which ones 2284 are optional. 2286 The floor participant sets the Conference ID and the Transaction ID 2287 in the common header following the rules given in Section 8.1. The 2288 floor participant sets the User ID in the common header to the floor 2289 participant's identifier. This User ID will be used by the floor 2290 control server to authenticate and authorize the request. 2292 Note that the FloorRelease message is used to release a floor or 2293 floors that were granted and to cancel ongoing floor requests 2294 (from the protocol perspective, both are ongoing floor requests). 2295 Using the same message in both situations helps resolve the race 2296 condition that occurs when the FloorRelease message and the 2297 FloorGrant message cross each other on the wire. 2299 The floor participant uses the FLOOR-REQUEST-ID that was received in 2300 the response to the FloorRequest message that the FloorRelease 2301 message is cancelling. 2303 Note that if the floor participant requested several floors as an 2304 atomic operation (i.e., in a single FloorRequest message), all the 2305 floors are released as an atomic operation as well (i.e., all are 2306 released at the same time). 2308 10.2.2. Receiving a Response 2310 A message from the floor control server is considered a response to 2311 the FloorRelease message if the message from the floor control server 2312 has the same Conference ID, Transaction ID, and User ID as the 2313 FloorRequest message, as described in Section 8.1. On receiving such 2314 a response, the floor participant follows the rules in Section 9 that 2315 relate to floor control server authentication. 2317 If the response is a FloorRequestStatus message, the Request Status 2318 value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR- 2319 REQUEST-INFORMATION grouped attribute) will be Cancelled or Released. 2321 If the response is an Error message, the floor control server could 2322 not process the FloorRequest message for some reason, which is 2323 described in the Error message. 2325 It is possible that the FloorRelease message crosses on the wire with 2326 a FloorRequestStatus message from the server with a Request Status 2327 different from Cancelled or Released. In any case, such a 2328 FloorRequestStatus message will not be a response to the FloorRelease 2329 message, as its Transaction ID will not match that of the 2330 FloorRelease. 2332 11. Chair Operations 2334 This section specifies how floor chairs can instruct the floor 2335 control server to grant or revoke a floor using the protocol elements 2336 described in earlier sections. 2338 Floor chairs that wish to send instructions to a floor control server 2339 do so by sending a ChairAction message. 2341 11.1. Sending a ChairAction Message 2343 The ABNF in Section 5.3.9 describes the attributes that a ChairAction 2344 message can contain. In addition, the ABNF specifies normatively 2345 which of these attributes are mandatory, and which ones are optional. 2347 The floor chair sets the Conference ID and the Transaction ID in the 2348 common header following the rules given in Section 8.1. The floor 2349 chair sets the User ID in the common header to the floor chair's 2350 identifier. This User ID will be used by the floor control server to 2351 authenticate and authorize the request. 2353 The ChairAction message contains instructions that apply to one or 2354 more floors within a particular floor request. The floor or floors 2355 are identified by the FLOOR-REQUEST-STATUS attributes and the floor 2356 request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which 2357 are carried in the ChairAction message. 2359 For example, if a floor request consists of two floors that depend on 2360 different floor chairs, each floor chair will grant its floor within 2361 the floor request. Once both chairs have granted their floor, the 2362 floor control server will grant the floor request as a whole. On the 2363 other hand, if one of the floor chairs denies its floor, the floor 2364 control server will deny the floor request as a whole, regardless of 2365 the other floor chair's decision. 2367 The floor chair provides the new status of the floor request as it 2368 relates to a particular floor using a FLOOR-REQUEST-STATUS attribute. 2369 If the new status of the floor request is Accepted, the floor chair 2370 MAY use the Queue Position field to provide a queue position for the 2371 floor request. If the floor chair does not wish to provide a queue 2372 position, all the bits of the Queue Position field MUST be set to 2373 zero. The floor chair MUST use the Status Revoked to revoke a floor 2374 that was granted (i.e., Granted status) and MUST use the Status 2375 Denied to reject floor requests in any other status (e.g., Pending 2376 and Accepted). 2378 The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the 2379 ChairAction message to provide a new overall status for the floor 2380 request. If the new overall status of the floor request is Accepted, 2381 the floor chair can use the Queue Position field to provide a queue 2382 position for the floor request. 2384 Note that a particular floor control server can implement a 2385 different queue for each floor containing all the floor requests 2386 that relate to that particular floor, a general queue for all 2387 floor requests, or both. Also note that a floor request can 2388 involve several floors and that a ChairAction message can only 2389 deal with a subset of these floors (e.g., if a single floor chair 2390 is not authorized to manage all the floors). In this case, the 2391 floor control server will combine the instructions received from 2392 the different floor chairs in FLOOR-REQUEST-STATUS attributes to 2393 come up with the overall status of the floor request. 2395 Note that, while the action of a floor chair may communicate 2396 information in the OVERALL-REQUEST-STATUS attribute, the floor 2397 control server may override, modify, or ignore this field's 2398 content. 2400 The floor chair MAY include STATUS-INFO attributes to state the 2401 reason why the floor or floors are being accepted, granted, or 2402 revoked. The Text in the STATUS-INFO attribute is intended for human 2403 consumption. 2405 11.2. Receiving a Response 2407 A message from the floor control server is considered a response to 2408 the ChairAction message if the message from the server has the same 2409 Conference ID, Transaction ID, and User ID as the ChairAction 2410 message, as described in Section 8.1. On receiving such a response, 2411 the floor chair follows the rules in Section 9 that relate to floor 2412 control server authentication. 2414 A ChairActionAck message from the floor control server confirms that 2415 the floor control server has accepted the ChairAction message. An 2416 Error message indicates that the floor control server could not 2417 process the ChairAction message for some reason, which is described 2418 in the Error message. 2420 12. General Client Operations 2422 This section specifies operations that can be performed by any 2423 client. That is, they are not specific to floor participants or 2424 floor chairs. They can be performed by both. 2426 12.1. Requesting Information about Floors 2428 A client can obtain information about the status of a floor or floors 2429 in different ways, which include using BFCP and using out-of-band 2430 mechanisms. Clients using BFCP to obtain such information use the 2431 procedures described in this section. 2433 Clients request information about the status of one or several floors 2434 by sending a FloorQuery message to the floor control server. 2436 12.1.1. Sending a FloorQuery Message 2438 The ABNF in Section 5.3.7 describes the attributes that a FloorQuery 2439 message can contain. In addition, the ABNF specifies normatively 2440 which of these attributes are mandatory, and which ones are optional. 2442 The client sets the Conference ID and the Transaction ID in the 2443 common header following the rules given in Section 8.1. The client 2444 sets the User ID in the common header to the client's identifier. 2445 This User ID will be used by the floor control server to authenticate 2446 and authorize the request. 2448 The client inserts in the message all the Floor IDs it wants to 2449 receive information about. The floor control server will send 2450 periodic information about all of these floors. If the client does 2451 not want to receive information about a particular floor any longer, 2452 it sends a new FloorQuery message removing the FLOOR-ID of this 2453 floor. If the client does not want to receive information about any 2454 floor any longer, it sends a FloorQuery message with no FLOOR-ID 2455 attribute. 2457 12.1.2. Receiving a Response 2459 A message from the floor control server is considered a response to 2460 the FloorQuery message if the message from the floor control server 2461 has the same Conference ID, Transaction ID, and User ID as the 2462 FloorRequest message, as described in Section 8.1. On receiving such 2463 a response, the client follows the rules in Section 9 that relate to 2464 floor control server authentication. 2466 On reception of the FloorQuery message, the floor control server MUST 2467 respond with a FloorStatus message or with an Error message. If the 2468 response is a FloorStatus message, it will contain information about 2469 one of the floors the client requested information about. If the 2470 client did not include any FLOOR-ID attribute in its FloorQuery 2471 message (i.e., the client does not want to receive information about 2472 any floor any longer), the FloorStatus message from the floor control 2473 server will not include any FLOOR-ID attribute either. 2475 FloorStatus messages that carry information about a floor contain a 2476 FLOOR-ID attribute that identifies the floor. After this attribute, 2477 FloorStatus messages contain information about existing (one or more) 2478 floor requests that relate to that floor. The information about each 2479 particular floor request is encoded in a FLOOR-REQUEST-INFORMATION 2480 attribute. This grouped attribute carries a Floor Request ID that 2481 identifies the floor request, followed by a set of attributes that 2482 provide information about the floor request. 2484 After the first FloorStatus, the floor control server will continue 2485 sending FloorStatus messages, periodically informing the client about 2486 changes on the floors the client requested information about. 2488 12.1.3. Reception of a Subsequent FloorStatus Message 2490 When communicating over an unreliable transport and upon receiving a 2491 FloorStatus message from a floor control server, the participant MUST 2492 respond with a FloorStatusAck message within the transaction failure 2493 window to complete the transaction. 2495 12.2. Requesting Information about Floor Requests 2497 A client can obtain information about the status of one or several 2498 floor requests in different ways, which include using BFCP and using 2499 out-of-band mechanisms. Clients using BFCP to obtain such 2500 information use the procedures described in this section. 2502 Clients request information about the current status of a floor 2503 request by sending a FloorRequestQuery message to the floor control 2504 server. 2506 Requesting information about a particular floor request is useful in 2507 a number of situations. For example, on reception of a FloorRequest 2508 message, a floor control server may choose to return 2509 FloorRequestStatus messages only when the floor request changes its 2510 state (e.g., from Accepted to Granted), but not when the floor 2511 request advances in its queue. In this situation, if the user 2512 requests it, the floor participant can use a FloorRequestQuery 2513 message to poll the floor control server for the status of the floor 2514 request. 2516 12.2.1. Sending a FloorRequestQuery Message 2518 The ABNF in Section 5.3.3 describes the attributes that a 2519 FloorRequestQuery message can contain. In addition, the ABNF 2520 specifies normatively which of these attributes are mandatory, and 2521 which ones are optional. 2523 The client sets the Conference ID and the Transaction ID in the 2524 common header following the rules given in Section 8.1. The client 2525 sets the User ID in the common header to the client's identifier. 2526 This User ID will be used by the floor control server to authenticate 2527 and authorize the request. 2529 The client MUST insert a FLOOR-REQUEST-ID attribute that identifies 2530 the floor request at the floor control server. 2532 12.2.2. Receiving a Response 2534 A message from the floor control server is considered a response to 2535 the FloorRequestQuery message if the message from the floor control 2536 server has the same Conference ID, Transaction ID, and User ID as the 2537 FloorRequestQuery message, as described in Section 8.1. On receiving 2538 such a response, the client follows the rules in Section 9 that 2539 relate to floor control server authentication. 2541 If the response is a FloorRequestStatus message, the client obtains 2542 information about the status of the FloorRequest the client requested 2543 information about in a FLOOR-REQUEST-INFORMATION attribute. 2545 If the response is an Error message, the floor control server could 2546 not process the FloorRequestQuery message for some reason, which is 2547 described in the Error message. 2549 12.3. Requesting Information about a User 2551 A client can obtain information about a participant and the floor 2552 requests related to this participant in different ways, which include 2553 using BFCP and using out-of-band mechanisms. Clients using BFCP to 2554 obtain such information use the procedures described in this section. 2556 Clients request information about a participant and the floor 2557 requests related to this participant by sending a UserQuery message 2558 to the floor control server. 2560 This functionality may be useful for floor chairs or floor 2561 participants interested in the display name and the URI of a 2562 particular floor participant. In addition, a floor participant may 2563 find it useful to request information about itself. For example, a 2564 floor participant, after experiencing connectivity problems (e.g., 2565 its TCP connection with the floor control server was down for a while 2566 and eventually was re-established), may need to request information 2567 about all the floor requests associated to itself that still exist. 2569 12.3.1. Sending a UserQuery Message 2571 The ABNF in Section 5.3.5 describes the attributes that a UserQuery 2572 message can contain. In addition, the ABNF specifies normatively 2573 which of these attributes are mandatory, and which ones are optional. 2575 The client sets the Conference ID and the Transaction ID in the 2576 common header following the rules given in Section 8.1. The client 2577 sets the User ID in the common header to the client's identifier. 2578 This User ID will be used by the floor control server to authenticate 2579 and authorize the request. 2581 If the floor participant the client is requesting information about 2582 is not the client issuing the UserQuery message (which is identified 2583 by the User ID in the common header of the message), the client MUST 2584 insert a BENEFICIARY-ID attribute. 2586 12.3.2. Receiving a Response 2588 A message from the floor control server is considered a response to 2589 the UserQuery message if the message from the floor control server 2590 has the same Conference ID, Transaction ID, and User ID as the 2591 UserQuery message, as described in Section 8.1. On receiving such a 2592 response, the client follows the rules in Section 9 that relate to 2593 floor control server authentication. 2595 If the response is a UserStatus message, the client obtains 2596 information about the floor participant in a BENEFICIARY-INFORMATION 2597 grouped attribute and about the status of the floor requests 2598 associated with the floor participant in FLOOR-REQUEST-INFORMATION 2599 attributes. 2601 If the response is an Error message, the floor control server could 2602 not process the UserQuery message for some reason, which is described 2603 in the Error message. 2605 12.4. Obtaining the Capabilities of a Floor Control Server 2607 A client that wishes to obtain the capabilities of a floor control 2608 server does so by sending a Hello message to the floor control 2609 server. 2611 12.4.1. Sending a Hello Message 2613 The ABNF in Section 5.3.11 describes the attributes that a Hello 2614 message can contain. In addition, the ABNF specifies normatively 2615 which of these attributes are mandatory, and which ones are optional. 2617 The client sets the Conference ID and the Transaction ID in the 2618 common header following the rules given in Section 8.1. The client 2619 sets the User ID in the common header to the client's identifier. 2620 This User ID will be used by the floor control server to authenticate 2621 and authorize the request. 2623 12.4.2. Receiving Responses 2625 A message from the floor control server is considered a response to 2626 the Hello message by the client if the message from the floor control 2627 server has the same Conference ID, Transaction ID, and User ID as the 2628 Hello message, as described in Section 8.1. On receiving such a 2629 response, the client follows the rules in Section 9 that relate to 2630 floor control server authentication. 2632 If the response is a HelloAck message, the floor control server could 2633 process the Hello message successfully. The SUPPORTED-PRIMITIVES and 2634 SUPPORTED-ATTRIBUTES attributes indicate which primitives and 2635 attributes, respectively, are supported by the server. 2637 If the response is an Error message, the floor control server could 2638 not process the Hello message for some reason, which is described in 2639 the Error message. 2641 13. Floor Control Server Operations 2643 This section specifies how floor control servers can perform 2644 different operations, such as granting a floor, using the protocol 2645 elements described in earlier sections. 2647 On reception of a message from a client, the floor control server 2648 MUST check whether the value of the Primitive is supported. If it is 2649 not, the floor control server MUST send an Error message, as 2650 described in Section 13.8, with Error code 3 (Unknown Primitive). 2652 On reception of a message from a client, the floor control server 2653 MUST check whether the value of the Conference ID matched an existing 2654 conference. If it does not, the floor control server MUST send an 2655 Error message, as described in Section 13.8, with Error code 1 2656 (Conference does not Exist). 2658 On reception of a message from a client, the floor control server 2659 follows the rules in Section 9 that relate to the authentication of 2660 the message. 2662 On reception of a message from a client, the floor control server 2663 MUST check whether it understands all the mandatory ('M' bit set) 2664 attributes in the message. If the floor control server does not 2665 understand all of them, the floor control server MUST send an Error 2666 message, as described in Section 13.8, with Error code 4 (Unknown 2667 Mandatory Attribute). The Error message SHOULD list the attributes 2668 that were not understood. 2670 13.1. Reception of a FloorRequest Message 2672 On reception of a FloorRequest message, the floor control server 2673 follows the rules in Section 9 that relate to client authentication 2674 and authorization. If while processing the FloorRequest message, the 2675 floor control server encounters an error, it MUST generate an Error 2676 response following the procedures described in Section 13.8. 2678 BFCP allows floor participants to have several ongoing floor 2679 requests for the same floor (e.g., the same floor participant can 2680 occupy more than one position in a queue at the same time). A 2681 floor control server that only supports a certain number of 2682 ongoing floor requests per floor participant (e.g., one) can use 2683 Error Code 8 (You have Already Reached the Maximum Number of 2684 Ongoing Floor Requests for this Floor) to inform the floor 2685 participant. 2687 When communicating over an unreliable transport and upon receiving a 2688 FloorRequest from a participant, the floor control server MUST 2689 respond with a FloorRequestStatus message within the transaction 2690 failure window to complete the transaction. 2692 13.1.1. Generating the First FloorRequestStatus Message 2694 The successful processing of a FloorRequest message by a floor 2695 control server involves generating one or several FloorRequestStatus 2696 messages, the first of which SHOULD be generated as soon as possible. 2697 If the floor control server cannot accept, grant, or deny the floor 2698 request right away (e.g., a decision from a chair is needed), it 2699 SHOULD use a Request Status value of Pending in the OVERALL-REQUEST- 2700 STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped 2701 attribute) of the first FloorRequestStatus message it generates. 2703 The policy that a floor control server follows to grant or deny 2704 floors is outside the scope of this document. A given floor 2705 control server may perform these decisions automatically while 2706 another may contact a human acting as a chair every time a 2707 decision needs to be made. 2709 The floor control server MUST copy the Conference ID, the Transaction 2710 ID, and the User ID from the FloorRequest into the 2711 FloorRequestStatus, as described in Section 8.2. Additionally, the 2712 floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 2713 attribute to the FloorRequestStatus. The attributes contained in 2714 this grouped attribute carry information about the floor request. 2716 The floor control server MUST assign an identifier that is unique 2717 within the conference to this floor request, and MUST insert it in 2718 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 2719 attribute. This identifier will be used by the floor participant (or 2720 by a chair or chairs) to refer to this specific floor request in the 2721 future. 2723 The floor control server MUST copy the Floor IDs in the FLOOR-ID 2724 attributes of the FloorRequest into the FLOOR-REQUEST-STATUS 2725 attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These 2726 Floor IDs identify the floors being requested (i.e., the floors 2727 associated with this particular floor request). 2729 The floor control server SHOULD copy (if present) the contents of the 2730 BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY- 2731 INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped 2732 attribute. Additionally, the floor control server MAY provide the 2733 display name and the URI of the beneficiary in this BENEFICIARY- 2734 INFORMATION attribute. 2736 The floor control server MAY provide information about the requester 2737 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2738 FLOOR-REQUEST-INFORMATION grouped attribute. 2740 The floor control server MAY copy (if present) the PRIORITY attribute 2741 from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped 2742 attribute. 2744 Note that this attribute carries the priority requested by the 2745 participant. The priority that the floor control server assigns 2746 to the floor request depends on the priority requested by the 2747 participant and the rights the participant has according to the 2748 policy of the conference. For example, a participant that is only 2749 allowed to use the Normal priority may request Highest priority 2750 for a floor request. In that case, the floor control server would 2751 ignore the priority requested by the participant. 2753 The floor control server MAY copy (if present) the PARTICIPANT- 2754 PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST- 2755 INFORMATION grouped attribute. 2757 13.1.2. Generation of Subsequent FloorRequestStatus Messages 2759 A floor request is considered to be ongoing as long as it is not in 2760 the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST- 2761 STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped 2762 attribute) of the first FloorRequestStatus message generated by the 2763 floor control server did not indicate any of these states, the floor 2764 control server will need to send subsequent FloorRequestStatus 2765 messages. 2767 When the status of the floor request changes, the floor control 2768 server SHOULD send new FloorRequestStatus messages with the 2769 appropriate Request Status. The floor control server MUST add a 2770 FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to 2771 the one sent in the first FloorRequestStatus message to any new 2772 FloorRequestStatus related to the same floor request. (The Floor 2773 Request ID identifies the floor request to which the 2774 FloorRequestStatus applies.) 2776 When using BFCP over a reliable transport, the floor control server 2777 MUST set the Transaction ID of subsequent FloorRequestStatus messages 2778 to 0. When using BFCP over an unreliable transport, the Transaction 2779 ID MUST be non-zero and unique in the context of outstanding 2780 transactions over an unreliable transport as described in Section 8. 2782 The rate at which the floor control server sends 2783 FloorRequestStatus messages is a matter of local policy. A floor 2784 control server may choose to send a new FloorRequestStatus message 2785 every time the floor request moves in the floor request queue, 2786 while another may choose only to send a new FloorRequestStatus 2787 message when the floor request is Granted or Denied. 2789 The floor control server may add a STATUS-INFO attribute to any of 2790 the FloorRequestStatus messages it generates to provide extra 2791 information about its decisions regarding the floor request (e.g., 2792 why it was denied). 2794 Floor participants and floor chairs may request to be informed 2795 about the status of a floor following the procedures in 2796 Section 12.1. If the processing of a floor request changes the 2797 status of a floor (e.g., the floor request is granted and 2798 consequently the floor has a new holder), the floor control server 2799 needs to follow the procedures in Section 13.5 to inform the 2800 clients that have requested that information. 2802 The common header and the rest of the attributes are the same as in 2803 the first FloorRequestStatus message. 2805 The floor control server can discard the state information about a 2806 particular floor request when this reaches a status of Cancelled, 2807 Released, or Revoked. 2809 When communicating over an unreliable transport and a 2810 FloorRequestStatusAck message is not received within the transaction 2811 failure window, the floor control server MUST retransmit the 2812 FloorRequestStatus message according to Section 6.2. 2814 13.2. Reception of a FloorRequestQuery Message 2816 On reception of a FloorRequestQuery message, the floor control server 2817 follows the rules in Section 9 that relate to client authentication 2818 and authorization. If while processing the FloorRequestQuery 2819 message, the floor control server encounters an error, it MUST 2820 generate an Error response following the procedures described in 2821 Section 13.8. 2823 The successful processing of a FloorRequestQuery message by a floor 2824 control server involves generating a FloorRequestStatus message, 2825 which SHOULD be generated as soon as possible. 2827 When communicating over an unreliable transport and upon receiving a 2828 FloorRequestQuery from a participant, the floor control server MUST 2829 respond with a FloorRequestStatus message within the transaction 2830 failure window to complete the transaction. 2832 The floor control server MUST copy the Conference ID, the Transaction 2833 ID, and the User ID from the FloorRequestQuery message into the 2834 FloorRequestStatus message, as described in Section 8.2. 2835 Additionally, the floor control server MUST include information about 2836 the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute 2837 to the FloorRequestStatus. 2839 The floor control server MUST copy the contents of the 2840 FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into 2841 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 2842 attribute. 2844 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 2845 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2846 floors being requested (i.e., the floors associated with the floor 2847 request identified by the FLOOR-REQUEST-ID attribute). 2849 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2850 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2851 beneficiary of the floor request. Additionally, the floor control 2852 server MAY provide the display name and the URI of the beneficiary in 2853 this BENEFICIARY-INFORMATION attribute. 2855 The floor control server MAY provide information about the requester 2856 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2857 FLOOR-REQUEST-INFORMATION grouped attribute. 2859 The floor control server MAY provide the reason why the floor 2860 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2862 The floor control server MAY also add to the FLOOR-REQUEST- 2863 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2864 value requested for the floor request and a STATUS-INFO attribute 2865 with extra information about the floor request. 2867 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 2868 to the FLOOR-REQUEST-INFORMATION grouped attribute with the current 2869 status of the floor request. The floor control server MAY provide 2870 information about the status of the floor request as it relates to 2871 each of the floors being requested in the FLOOR-REQUEST-STATUS 2872 attributes. 2874 13.3. Reception of a UserQuery Message 2876 On reception of a UserQuery message, the floor control server follows 2877 the rules in Section 9 that relate to client authentication and 2878 authorization. If while processing the UserQuery message, the floor 2879 control server encounters an error, it MUST generate an Error 2880 response following the procedures described in Section 13.8. 2882 The successful processing of a UserQuery message by a floor control 2883 server involves generating a UserStatus message, which SHOULD be 2884 generated as soon as possible. 2886 When communicating over an unreliable transport and upon receiving a 2887 UserQuery from a participant, the floor control server MUST respond 2888 with a UserStatus message within the transaction failure window to 2889 complete the transaction. 2891 The floor control server MUST copy the Conference ID, the Transaction 2892 ID, and the User ID from the UserQuery message into the USerStatus 2893 message, as described in Section 8.2. 2895 The sender of the UserQuery message is requesting information about 2896 all the floor requests associated with a given participant (i.e., the 2897 floor requests where the participant is either the beneficiary or the 2898 requester). This participant is identified by a BENEFICIARY-ID 2899 attribute or, in the absence of a BENEFICIARY-ID attribute, by a the 2900 User ID in the common header of the UserQuery message. 2902 The floor control server MUST copy, if present, the contents of the 2903 BENEFICIARY-ID attribute from the UserQuery message into a 2904 BENEFICIARY-INFORMATION attribute in the UserStatus message. 2905 Additionally, the floor control server MAY provide the display name 2906 and the URI of the participant about which the UserStatus message 2907 provides information in this BENEFICIARY-INFORMATION attribute. 2909 The floor control server SHOULD add to the UserStatus message a 2910 FLOOR-REQUEST-INFORMATION grouped attribute for each floor request 2911 related to the participant about which the message provides 2912 information (i.e., the floor requests where the participant is either 2913 the beneficiary or the requester). For each FLOOR-REQUEST- 2914 INFORMATION attribute, the floor control server follows the following 2915 steps. 2917 The floor control server MUST identify the floor request the FLOOR- 2918 REQUEST-INFORMATION attribute applies to by filling the Floor Request 2919 ID field of the FLOOR-REQUEST-INFORMATION attribute. 2921 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 2922 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2923 floors being requested (i.e., the floors associated with the floor 2924 request identified by the FLOOR-REQUEST-ID attribute). 2926 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2927 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2928 beneficiary of the floor request. Additionally, the floor control 2929 server MAY provide the display name and the URI of the beneficiary in 2930 this BENEFICIARY-INFORMATION attribute. 2932 The floor control server MAY provide information about the requester 2933 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2934 FLOOR-REQUEST-INFORMATION grouped attribute. 2936 The floor control server MAY provide the reason why the floor 2937 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2939 The floor control server MAY also add to the FLOOR-REQUEST- 2940 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2941 value requested for the floor request. 2943 The floor control server MUST include the current status of the floor 2944 request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST- 2945 INFORMATION grouped attribute. The floor control server MAY add a 2946 STATUS-INFO attribute with extra information about the floor request. 2948 The floor control server MAY provide information about the status of 2949 the floor request as it relates to each of the floors being requested 2950 in the FLOOR-REQUEST-STATUS attributes. 2952 13.4. Reception of a FloorRelease Message 2954 On reception of a FloorRelease message, the floor control server 2955 follows the rules in Section 9 that relate to client authentication 2956 and authorization. If while processing the FloorRelease message, the 2957 floor control server encounters an error, it MUST generate an Error 2958 response following the procedures described in Section 13.8. 2960 The successful processing of a FloorRelease message by a floor 2961 control server involves generating a FloorRequestStatus message, 2962 which SHOULD be generated as soon as possible. 2964 When communicating over an unreliable transport and upon receiving a 2965 FloorRelease from a participant, the floor control server MUST 2966 respond with a FloorRequestStatus message within the transaction 2967 failure window to complete the transaction. 2969 The floor control server MUST copy the Conference ID, the Transaction 2970 ID, and the User ID from the FloorRelease message into the 2971 FloorRequestStatus message, as described in Section 8.2. 2973 The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 2974 attribute to the FloorRequestStatus. The attributes contained in 2975 this grouped attribute carry information about the floor request. 2977 The FloorRelease message identifies the floor request it applies to 2978 using a FLOOR-REQUEST-ID. The floor control server MUST copy the 2979 contents of the FLOOR-REQUEST-ID attribute from the FloorRelease 2980 message into the Floor Request ID field of the FLOOR-REQUEST- 2981 INFORMATION attribute. 2983 The floor control server MUST identify the floors being released 2984 (i.e., the floors associated with the floor request identified by the 2985 FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the 2986 FLOOR-REQUEST-INFORMATION grouped attribute. 2988 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 2989 to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request 2990 Status value SHOULD be Released, if the floor (or floors) had been 2991 previously granted, or Cancelled, if the floor (or floors) had not 2992 been previously granted. The floor control server MAY add a STATUS- 2993 INFO attribute with extra information about the floor request. 2995 13.5. Reception of a FloorQuery Message 2997 On reception of a FloorQuery message, the floor control server 2998 follows the rules in Section 9 that relate to client authentication. 2999 If while processing the FloorQuery message, the floor control server 3000 encounters an error, it MUST generate an Error response following the 3001 procedures described in Section 13.8. 3003 When communicating over an unreliable transport and upon receiving a 3004 FloorQuery from a participant, the floor control server MUST respond 3005 with a FloorStatus message within the transaction failure window to 3006 complete the transaction. 3008 A floor control server receiving a FloorQuery message from a client 3009 SHOULD keep this client informed about the status of the floors 3010 identified by FLOOR-ID attributes in the FloorQuery message. Floor 3011 Control Servers keep clients informed by using FloorStatus messages. 3013 An individual FloorStatus message carries information about a single 3014 floor. So, when a FloorQuery message requests information about more 3015 than one floor, the floor control server needs to send separate 3016 FloorStatus messages for different floors. 3018 The information FloorQuery messages carry may depend on the user 3019 requesting the information. For example, a chair may be able to 3020 receive information about pending requests, while a regular user may 3021 not be authorized to do so. 3023 13.5.1. Generation of the First FloorStatus Message 3025 The successful processing of a FloorQuery message by a floor control 3026 server involves generating one or several FloorStatus messages, the 3027 first of which SHOULD be generated as soon as possible. 3029 The floor control server MUST copy the Conference ID, the Transaction 3030 ID, and the User ID from the FloorQuery message into the FloorStatus 3031 message, as described in Section 8.2. 3033 If the FloorQuery message did not contain any FLOOR-ID attribute, the 3034 floor control server sends the FloorStatus message without adding any 3035 additional attribute and does not send any subsequent FloorStatus 3036 message to the floor participant. 3038 If the FloorQuery message contained one or more FLOOR-ID attributes, 3039 the floor control server chooses one from among them and adds this 3040 FLOOR-ID attribute to the FloorStatus message. The floor control 3041 server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for 3042 each floor request associated to the floor. Each FLOOR-REQUEST- 3043 INFORMATION grouped attribute contains a number of attributes that 3044 provide information about the floor request. For each FLOOR-REQUEST- 3045 INFORMATION attribute, the floor control server follows the following 3046 steps. 3048 The floor control server MUST identify the floor request the FLOOR- 3049 REQUEST-INFORMATION attribute applies to by filling the Floor Request 3050 ID field of the FLOOR-REQUEST-INFORMATION attribute. 3052 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 3053 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 3054 floors being requested (i.e., the floors associated with the floor 3055 request identified by the FLOOR-REQUEST-ID attribute). 3057 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 3058 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 3059 beneficiary of the floor request. Additionally, the floor control 3060 server MAY provide the display name and the URI of the beneficiary in 3061 this BENEFICIARY-INFORMATION attribute. 3063 The floor control server MAY provide information about the requester 3064 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 3065 FLOOR-REQUEST-INFORMATION grouped attribute. 3067 The floor control server MAY provide the reason why the floor 3068 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 3070 The floor control server MAY also add to the FLOOR-REQUEST- 3071 INFORMATION grouped attribute a PRIORITY attribute with the Priority 3072 value requested for the floor request. 3074 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 3075 to the FLOOR-REQUEST-INFORMATION grouped attribute with the current 3076 status of the floor request. The floor control server MAY add a 3077 STATUS-INFO attribute with extra information about the floor request. 3079 The floor control server MAY provide information about the status of 3080 the floor request as it relates to each of the floors being requested 3081 in the FLOOR-REQUEST-STATUS attributes. 3083 13.5.2. Generation of Subsequent FloorStatus Messages 3085 If the FloorQuery message carried more than one FLOOR-ID attribute, 3086 the floor control server SHOULD generate a FloorStatus message for 3087 each of them (except for the FLOOR-ID attribute chosen for the first 3088 FloorStatus message) as soon as possible. These FloorStatus messages 3089 are generated following the same rules as those for the first 3090 FloorStatus message (see Section 13.5.1), but their Transaction ID is 3091 0 when using a reliable transport and non-zero and unique in the 3092 context of outstanding transactions when using an unreliable 3093 transport (cf. Section 8). 3095 After generating these messages, the floor control server sends 3096 FloorStatus messages, periodically keeping the client informed about 3097 all the floors for which the client requested information. The 3098 Transaction ID of these messages MUST be 0 when using a reliable 3099 transport and non-zero and unique in the context of outstanding 3100 transactions when using an unreliable transport (cf. Section 8). 3102 The rate at which the floor control server sends FloorStatus 3103 messages is a matter of local policy. A floor control server may 3104 choose to send a new FloorStatus message every time a new floor 3105 request arrives, while another may choose to only send a new 3106 FloorStatus message when a new floor request is Granted. 3108 When communicating over an unreliable transport and a FloorStatusAck 3109 message is not received within the transaction failure window, the 3110 floor control server MUST retransmit the FloorStatus message 3111 according to Section 6.2. 3113 13.6. Reception of a ChairAction Message 3115 On reception of a ChairAction message, the floor control server 3116 follows the rules in Section 9 that relate to client authentication 3117 and authorization. If while processing the ChairAction message, the 3118 floor control server encounters an error, it MUST generate an Error 3119 response following the procedures described in Section 13.8. 3121 The successful processing of a ChairAction message by a floor control 3122 server involves generating a ChairActionAck message, which SHOULD be 3123 generated as soon as possible. 3125 When communicating over an unreliable transport and upon receiving a 3126 ChairAction from a chair, the floor control server MUST respond with 3127 a ChairActionAck message within the transaction failure window to 3128 complete the transaction. 3130 The floor control server MUST copy the Conference ID, the Transaction 3131 ID, and the User ID from the ChairAction message into the 3132 ChairActionAck message, as described in Section 8.2. 3134 The floor control server needs to take into consideration the 3135 operation requested in the ChairAction message (e.g., granting a 3136 floor) but does not necessarily need to perform it as requested by 3137 the floor chair. The operation that the floor control server 3138 performs depends on the ChairAction message and on the internal state 3139 of the floor control server. 3141 For example, a floor chair may send a ChairAction message granting a 3142 floor that was requested as part of an atomic floor request operation 3143 that involved several floors. Even if the chair responsible for one 3144 of the floors instructs the floor control server to grant the floor, 3145 the floor control server will not grant it until the chairs 3146 responsible for the other floors agree to grant them as well. 3148 So, the floor control server is ultimately responsible for keeping a 3149 coherent floor state using instructions from floor chairs as input to 3150 this state. 3152 If the new Status in the ChairAction message is Accepted and all the 3153 bits of the Queue Position field are zero, the floor chair is 3154 requesting that the floor control server assign a queue position 3155 (e.g., the last in the queue) to the floor request based on the local 3156 policy of the floor control server. (Of course, such a request only 3157 applies if the floor control server implements a queue.) 3159 13.7. Reception of a Hello Message 3161 On reception of a Hello message, the floor control server follows the 3162 rules in Section 9 that relate to client authentication. If while 3163 processing the Hello message, the floor control server encounters an 3164 error, it MUST generate an Error response following the procedures 3165 described in Section 13.8. 3167 If the version of BFCP specified in the Version field of the COMMON- 3168 HEADER is supported by the floor control server, it MUST respond with 3169 the same version number in the HelloAck; this defines the version for 3170 all subsequent BFCP messages within this BFCP Connection. If the 3171 version given in the Hello message is not supported, and the 3172 extensions in this document is supported, the receiving server MUST 3173 instead send an Error message with parameter value 12 (Unsupported 3174 Version). Note that endpoints supporting only the RFC 4582 subset 3175 will not support this parameter value. 3177 When communicating over an unreliable transport and upon receiving a 3178 Hello from a participant, the floor control server MUST respond with 3179 a HelloAck message within the transaction failure window to complete 3180 the transaction. 3182 The successful processing of a Hello message by a floor control 3183 server involves generating a HelloAck message, which SHOULD be 3184 generated as soon as possible. The floor control server MUST copy 3185 the Conference ID, the Transaction ID, and the User ID from the Hello 3186 into the HelloAck, as described in Section 8.2. 3188 The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to 3189 the HelloAck message listing all the primitives (i.e., BFCP messages) 3190 supported by the floor control server. 3192 The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to 3193 the HelloAck message listing all the attributes supported by the 3194 floor control server. 3196 13.8. Error Message Generation 3198 Error messages are always sent in response to a previous message from 3199 the client as part of a client-initiated transaction. The ABNF in 3200 Section 5.3.13 describes the attributes that an Error message can 3201 contain. In addition, the ABNF specifies normatively which of these 3202 attributes are mandatory and which ones are optional. 3204 The floor control server MUST copy the Conference ID, the Transaction 3205 ID, and the User ID from the message from the client into the Error 3206 message, as described in Section 8.2. 3208 The floor control server MUST add an ERROR-CODE attribute to the 3209 Error message. The ERROR-CODE attribute contains an Error Code from 3210 Table 5. Additionally, the floor control server may add an ERROR- 3211 INFO attribute with extra information about the error. 3213 14. Security Considerations 3215 BFCP uses TLS/DTLS to provide mutual authentication between clients 3216 and servers. TLS/DTLS also provides replay and integrity protection 3217 and confidentiality. It is RECOMMENDED that TLS/DTLS with an 3218 encryption algorithm according to Section 7 always be used and in 3219 cases where signaling/control traffic is properly protected, as 3220 described in Section 9 it is REQUIRED to use a mandated encryption 3221 algorithm. BFCP entities MAY use other security mechanisms as long 3222 as they provide similar security properties. 3224 The remainder of this section analyzes some of the threats against 3225 BFCP and how they are addressed. 3227 An attacker may attempt to impersonate a client (a floor participant 3228 or a floor chair) in order to generate forged floor requests or to 3229 grant or deny existing floor requests. Client impersonation is 3230 avoided by having servers only accept BFCP messages over 3231 authenticated TLS/DTLS connections. The floor control server assumes 3232 that attackers cannot hijack the TLS/DTLS connection and, therefore, 3233 that messages over the TLS/DTLS connection come from the client that 3234 was initially authenticated. 3236 An attacker may attempt to impersonate a floor control server. A 3237 successful attacker would be able to make clients think that they 3238 hold a particular floor so that they would try to access a resource 3239 (e.g., sending media) without having legitimate rights to access it. 3240 Floor control server impersonation is avoided by having servers only 3241 accept BFCP messages over authenticated TLS/DTLS connections, as well 3242 as ensuring clients only send and accept messages over authenticated 3243 TLS/DTLS connections. 3245 Attackers may attempt to modify messages exchanged by a client and a 3246 floor control server. The integrity protection provided by TLS/DTLS 3247 connections prevents this attack. 3249 An attacker may attempt to fetch a valid message sent by a client to 3250 a floor control server and replay it over a connection between the 3251 attacker and the floor control server. This attack is prevented by 3252 having floor control servers check that messages arriving over a 3253 given authenticated TLS/DTLS connection use an authorized user ID 3254 (i.e., a user ID that the user that established the authenticated 3255 TLS/DTLS connection is allowed to use). 3257 Attackers may attempt to pick messages from the network to get access 3258 to confidential information between the floor control server and a 3259 client (e.g., why a floor request was denied). TLS/DTLS 3260 confidentiality prevents this attack. Therefore, it is REQUIRED that 3261 TLS/DTLS be used with an encryption algorithm according to Section 7. 3263 15. IANA Considerations 3265 [Editorial note: This section instructs the IANA to register new 3266 entries in the BFCP Primitive subregistry in Section 15.2 and for 3267 the BFCP Error Code subregistry in Section 15.4.] 3269 The IANA has created a registry for BFCP parameters called "Binary 3270 Floor Control Protocol (BFCP) Parameters". This registry has a 3271 number of subregistries, which are described in the following 3272 sections. 3274 15.1. Attribute Subregistry 3276 This section establishes the Attribute subregistry under the BFCP 3277 Parameters registry. As per the terminology in RFC 5226 [5], the 3278 registration policy for BFCP attributes shall be "Specification 3279 Required". For the purposes of this subregistry, the BFCP attributes 3280 for which IANA registration is requested MUST be defined by a 3281 standards-track RFC. Such an RFC MUST specify the attribute's type, 3282 name, format, and semantics. 3284 For each BFCP attribute, the IANA registers its type, its name, and 3285 the reference to the RFC where the attribute is defined. The 3286 following table contains the initial values of this subregistry. 3288 +------+---------------------------+------------+ 3289 | Type | Attribute | Reference | 3290 +------+---------------------------+------------+ 3291 | 1 | BENEFICIARY-ID | [RFC XXXX] | 3292 | 2 | FLOOR-ID | [RFC XXXX] | 3293 | 3 | FLOOR-REQUEST-ID | [RFC XXXX] | 3294 | 4 | PRIORITY | [RFC XXXX] | 3295 | 5 | REQUEST-STATUS | [RFC XXXX] | 3296 | 6 | ERROR-CODE | [RFC XXXX] | 3297 | 7 | ERROR-INFO | [RFC XXXX] | 3298 | 8 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] | 3299 | 9 | STATUS-INFO | [RFC XXXX] | 3300 | 10 | SUPPORTED-ATTRIBUTES | [RFC XXXX] | 3301 | 11 | SUPPORTED-PRIMITIVES | [RFC XXXX] | 3302 | 12 | USER-DISPLAY-NAME | [RFC XXXX] | 3303 | 13 | USER-URI | [RFC XXXX] | 3304 | 14 | BENEFICIARY-INFORMATION | [RFC XXXX] | 3305 | 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] | 3306 | 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] | 3307 | 17 | FLOOR-REQUEST-STATUS | [RFC XXXX] | 3308 | 18 | OVERALL-REQUEST-STATUS | [RFC XXXX] | 3309 +------+---------------------------+------------+ 3311 Table 7: Initial values of the BFCP Attribute subregistry 3313 15.2. Primitive Subregistry 3315 [Editorial note: This section instructs the IANA to register the 3316 following new values for the BFCP Primitive subregistry: 3317 FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.] 3319 This section establishes the Primitive subregistry under the BFCP 3320 Parameters registry. As per the terminology in RFC 5226 [5], the 3321 registration policy for BFCP primitives shall be "Specification 3322 Required". For the purposes of this subregistry, the BFCP primitives 3323 for which IANA registration is requested MUST be defined by a 3324 standards-track RFC. Such an RFC MUST specify the primitive's value, 3325 name, format, and semantics. 3327 For each BFCP primitive, the IANA registers its value, its name, and 3328 the reference to the RFC where the primitive is defined. The 3329 following table contains the initial values of this subregistry. 3331 +-------+-----------------------+------------+ 3332 | Value | Primitive | Reference | 3333 +-------+-----------------------+------------+ 3334 | 1 | FloorRequest | [RFC XXXX] | 3335 | 2 | FloorRelease | [RFC XXXX] | 3336 | 3 | FloorRequestQuery | [RFC XXXX] | 3337 | 4 | FloorRequestStatus | [RFC XXXX] | 3338 | 5 | UserQuery | [RFC XXXX] | 3339 | 6 | UserStatus | [RFC XXXX] | 3340 | 7 | FloorQuery | [RFC XXXX] | 3341 | 8 | FloorStatus | [RFC XXXX] | 3342 | 9 | ChairAction | [RFC XXXX] | 3343 | 10 | ChairActionAck | [RFC XXXX] | 3344 | 11 | Hello | [RFC XXXX] | 3345 | 12 | HelloAck | [RFC XXXX] | 3346 | 13 | Error | [RFC XXXX] | 3347 | 14 | FloorRequestStatusAck | [RFC XXXX] | 3348 | 15 | FloorStatusAck | [RFC XXXX] | 3349 | 16 | Goodbye | [RFC XXXX] | 3350 | 17 | GoodbyeAck | [RFC XXXX] | 3351 +-------+-----------------------+------------+ 3353 Table 8: Initial values of the BFCP primitive subregistry 3355 15.3. Request Status Subregistry 3357 This section establishes the Request Status subregistry under the 3358 BFCP Parameters registry. As per the terminology in RFC 5226 [5], 3359 the registration policy for BFCP request status shall be 3360 "Specification Required". For the purposes of this subregistry, the 3361 BFCP request status for which IANA registration is requested MUST be 3362 defined by a standards-track RFC. Such an RFC MUST specify the value 3363 and the semantics of the request status. 3365 For each BFCP request status, the IANA registers its value, its 3366 meaning, and the reference to the RFC where the request status is 3367 defined. The following table contains the initial values of this 3368 subregistry. 3370 +-------+-----------+------------+ 3371 | Value | Status | Reference | 3372 +-------+-----------+------------+ 3373 | 1 | Pending | [RFC XXXX] | 3374 | 2 | Accepted | [RFC XXXX] | 3375 | 3 | Granted | [RFC XXXX] | 3376 | 4 | Denied | [RFC XXXX] | 3377 | 5 | Cancelled | [RFC XXXX] | 3378 | 6 | Released | [RFC XXXX] | 3379 | 7 | Revoked | [RFC XXXX] | 3380 +-------+-----------+------------+ 3382 Table 9: Initial values of the Request Status subregistry 3384 15.4. Error Code Subregistry 3386 [Editorial note: This section instructs the IANA to register the 3387 following new values for the BFCP Error Code subregistry: 10, 11, 3388 12, 13 and 14.] 3390 This section establishes the Error Code subregistry under the BFCP 3391 Parameters registry. As per the terminology in RFC 5226 [5], the 3392 registration policy for BFCP error codes shall be "Specification 3393 Required". For the purposes of this subregistry, the BFCP error 3394 codes for which IANA registration is requested MUST be defined by a 3395 standards-track RFC. Such an RFC MUST specify the value and the 3396 semantics of the error code, and any Error Specific Details that 3397 apply to it. 3399 For each BFCP primitive, the IANA registers its value, its meaning, 3400 and the reference to the RFC where the primitive is defined. The 3401 following table contains the initial values of this subregistry. 3403 +-------+--------------------------------------+------------+ 3404 | Value | Meaning | Reference | 3405 +-------+--------------------------------------+------------+ 3406 | 1 | Conference does not Exist | [RFC XXXX] | 3407 | 2 | User does not Exist | [RFC XXXX] | 3408 | 3 | Unknown Primitive | [RFC XXXX] | 3409 | 4 | Unknown Mandatory Attribute | [RFC XXXX] | 3410 | 5 | Unauthorized Operation | [RFC XXXX] | 3411 | 6 | Invalid Floor ID | [RFC XXXX] | 3412 | 7 | Floor Request ID Does Not Exist | [RFC XXXX] | 3413 | 8 | You have Already Reached the Maximum | [RFC XXXX] | 3414 | | Number of Ongoing Floor Requests for | | 3415 | | this Floor | | 3416 | 9 | Use TLS | [RFC XXXX] | 3417 | 10 | Unable to parse message | [RFC XXXX] | 3418 | 11 | Use DTLS | [RFC XXXX] | 3419 | 12 | Unsupported Version | [RFC XXXX] | 3420 | 13 | Incorrect Message Length | [RFC XXXX] | 3421 | 14 | Generic Error | [RFC XXXX] | 3422 +-------+--------------------------------------+------------+ 3424 Table 10: Initial Values of the Error Code subregistry 3426 16. Changes from RFC 4582 3428 Following is the list of technical changes and other non-trivial 3429 fixes from [2]. 3431 16.1. Extensions for an unreliable transport 3433 Main purpose of this work was to revise the specification to support 3434 BFCP over an unreliable transport, resulting in the following 3435 changes: 3437 1. Overview of Operation (Section 4): 3438 Changed the description of client-initiated and server-initiated 3439 transactions, referring to Section 8. 3441 2. COMMON-HEADER Format (Section 5.1): 3442 Ver(sion) field, where the value 2 is used for the extensions 3443 for an unreliable transport. Added new R and F flag-bits for an 3444 unreliable transport. Res(erved) field is now 3 bit. New 3445 optional Fragment Offset and Fragment Length fields. 3447 3. New primitives (Section 5.1): 3448 Added four new primitives: FloorRequestStatusAck, 3449 FloorStatusAck, Goodbye, and GoodbyeAck. 3451 4. New error codes (Section 5.2.6): 3452 Added three new error codes: "Unable to Parse Message", "Use 3453 DTLS" and "Unsupported Version". Note that two additional error 3454 codes were added, see Section 16.2. 3456 5. ABNF for new primitives (Section 5.3): 3457 New subsections with normative ABNF for the new primitives. 3459 6. Transport split in two (Section 6): 3460 Section 6 specifying the transport was split in two subsections; 3461 Section 6.1 for a reliable transport and Section 6.2 for an 3462 unreliable transport. Where the specification for an unreliable 3463 transport amongst other issues deals with reliability, 3464 congestion control, fragmentation and ICMP. 3466 7. Mandate DTLS (Section 7 and Section 9): 3467 Mandate DTLS support when transport over UDP is used. 3469 8. Transaction changes (Section 8): 3470 Server-initiated transactions over an unreliable transport has 3471 non-zero and unique Transaction ID. Over an unreliable 3472 transport, the retransmit timers T1 and T2 described in 3473 Section 8.3 apply. 3475 9. Requiring timely response (Section 8.3, Section 10.1.2, 3476 Section 10.2.2, Section 11.2, Section 12.1.2, Section 12.2.2, 3477 Section 12.3.2, Section 12.4.2, Section 10.1.3 and 3478 Section 12.1.3): 3479 Describing that a given response must be sent within the 3480 transaction failure window to complete the transaction. 3482 10. Updated IANA Considerations (Section 15): 3483 Added the new primitives and error codes to Section 15.2 and 3484 Section 15.4 respectively. 3486 11. Examples over an unreliable transport (Appendix A): 3487 Added sample interactions over an unreliable transport for the 3488 scenarios in Figure 2 and Figure 3 3490 12. Motivation for an unreliable transport (Appendix B): 3491 Introduction to and motivation for extending BFCP to support an 3492 unreliable transport. 3494 16.2. Other changes 3496 Clarifications and bug fixes: 3498 1. ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>, 3499 Figure 28, Figure 30, and the ABNF figures in Section 5.3): 3500 Although formally correct in [2], the notation has changed in a 3501 number of Figures to an equivalent form for clarity, e.g., 3502 s/*1(FLOOR-ID)/[FLOOR-ID]/ in Figure 38 and s/*[XXX]/*(XXX)/ in 3503 the other figures. 3505 2. Typo (Section 12.4.2): 3506 Change from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the 3507 second paragraph. 3509 3. Corrected attribute type (Section 13.1.1): 3510 Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in 3511 the eighth paragraph, since the note below describes priority and 3512 that the last paragraph deals with PARTICIPANT-PROVIDED-INFO. 3514 4. New error codes (Section 5.2.6): 3515 Added two additional error codes: "Incorrect Message Length" and 3516 "Generic Error". 3518 5. Assorted clarifications (Across the document): 3519 Language clarifications as a result of reviews. Also, the 3520 normative language where tightened where appropriate, i.e. 3521 changed from SHOULD strength to MUST in a number of places. 3523 17. Acknowledgements 3525 The XCON WG chairs, Adam Roach and Alan Johnston, provided useful 3526 ideas for RFC 4582 [2]. Additionally, Xiaotao Wu, Paul Kyzivat, 3527 Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben 3528 Campbell, Dave Morgan, and Oscar Novo provided useful comments during 3529 the work with RFC 4582. The authors also acknowledge contributions 3530 to the revision of BFCP for use over an unreliable transport from 3531 Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad, 3532 Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, 3533 Joerg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, 3534 Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman, 3535 Vijaya Mandava and Alan Ford. In the final phase Ernst Horvath did a 3536 thorough review revealing issues that needed clarification and 3537 changes. Useful and important final reviews were done by Mary 3538 Barnes. 3540 18. References 3541 18.1. Normative References 3543 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3544 Levels", BCP 14, RFC 2119, March 1997. 3546 [2] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control 3547 Protocol (BFCP)", RFC 4582, November 2006. 3549 [3] Camarillo, G., "Connection Establishment in the Binary Floor 3550 Control Protocol (BFCP)", RFC 5018, September 2007. 3552 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 3553 Specifications: ABNF", STD 68, RFC 5234, January 2008. 3555 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3556 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 3558 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 3559 Protocol Version 1.2", RFC 5246, August 2008. 3561 [7] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3562 Security Version 1.2", RFC 6347, January 2012. 3564 [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 3565 STD 63, RFC 3629, November 2003. 3567 [9] Camarillo, G. and T. Kristensen, "Session Description Protocol 3568 (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", 3569 draft-ietf-bfcpbis-rfc4583bis-11 (work in progress), 3570 February 2015. 3572 [10] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 3573 BCP 131, RFC 4961, July 2007. 3575 [11] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 3576 Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. 3578 18.2. Informational References 3580 [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 3581 Session Description Protocol (SDP)", RFC 3264, June 2002. 3583 [13] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, 3584 "Requirements for Floor Control Protocols", RFC 4376, 3585 February 2006. 3587 [14] Barnes, M., Boulton, C., and O. Levin, "A Framework for 3588 Centralized Conferencing", RFC 5239, June 2008. 3590 [15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 3591 Protocol for Network Address Translator (NAT) Traversal for 3592 Offer/Answer Protocols", RFC 5245, April 2010. 3594 [16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 3595 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 3596 Session Initiation Protocol", RFC 3261, June 2002. 3598 [17] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 3599 "Conference Information Data Model for Centralized Conferencing 3600 (XCON)", RFC 6501, March 2012. 3602 [18] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, 3603 "Centralized Conferencing Manipulation Protocol", RFC 6503, 3604 March 2012. 3606 [19] Barnes, M., Miniero, L., Presta, R., and SP. Romano, 3607 "Centralized Conferencing Manipulation Protocol (CCMP) Call 3608 Flow Examples", RFC 6504, March 2012. 3610 [20] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 3611 November 1990. 3613 [21] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for 3614 IP version 6", RFC 1981, August 1996. 3616 [22] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 3617 Discovery", RFC 4821, March 2007. 3619 [23] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for 3620 Establishing a Secure Real-time Transport Protocol (SRTP) 3621 Security Context Using Datagram Transport Layer Security 3622 (DTLS)", RFC 5763, May 2010. 3624 [24] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for 3625 Secure Use of TLS and DTLS", draft-ietf-uta-tls-bcp-09 (work in 3626 progress), February 2015. 3628 [25] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network 3629 Address Translations (NATs)", RFC 4380, February 2006. 3631 [26] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for 3632 Application Designers", BCP 145, RFC 5405, November 2008. 3634 [27] Thaler, D., "Teredo Extensions", RFC 6081, January 2011. 3636 [28] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 3637 September 2007. 3639 [29] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP 3640 Candidates with Interactive Connectivity Establishment (ICE)", 3641 RFC 6544, March 2012. 3643 [30] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling 3644 (GUT)", draft-manner-tsvwg-gut-02 (work in progress), 3645 July 2010. 3647 [31] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of 3648 Middlebox Interactions for Signaling Protocol Communication 3649 along the Media Path", 3650 draft-ietf-mmusic-media-path-middleboxes-05 (work in progress), 3651 July 2012. 3653 [32] Guha, S. and P. Francis, "Characterization and Measurement of 3654 TCP Traversal through NATs and Firewalls", 2005, 3655 . 3657 [33] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer 3658 Communication Across Network Address Translators", April 2005, 3659 . 3661 Appendix A. Example Call Flows for BFCP over an Unreliable Transport 3663 With reference to Section 4.1, the following figures show 3664 representative call-flows for requesting and releasing a floor, and 3665 obtaining status information about a floor when BFCP is deployed over 3666 an unreliable transport. The figures here show a loss-less 3667 interaction. 3669 Floor Participant Floor Control 3670 Server 3671 |(1) FloorRequest | 3672 |Transaction ID: 123 | 3673 |User ID: 234 | 3674 |FLOOR-ID: 543 | 3675 |---------------------------------------------->| 3676 | | 3677 |(2) FloorRequestStatus | 3678 |Transaction ID: 123 | 3679 |User ID: 234 | 3680 |FLOOR-REQUEST-INFORMATION | 3681 | Floor Request ID: 789 | 3682 | OVERALL-REQUEST-STATUS | 3683 | Request Status: Pending | 3684 | FLOOR-REQUEST-STATUS | 3685 | Floor ID: 543 | 3686 |<----------------------------------------------| 3687 | | 3688 |(3) FloorRequestStatus | 3689 |Transaction ID: 124 | 3690 |User ID: 234 | 3691 |FLOOR-REQUEST-INFORMATION | 3692 | Floor Request ID: 789 | 3693 | OVERALL-REQUEST-STATUS | 3694 | Request Status: Accepted | 3695 | Queue Position: 1st | 3696 | FLOOR-REQUEST-STATUS | 3697 | Floor ID: 543 | 3698 |<----------------------------------------------| 3699 | | 3700 |(4) FloorRequestStatusAck | 3701 |Transaction ID: 124 | 3702 |User ID: 234 | 3703 |---------------------------------------------->| 3704 | | 3705 |(5) FloorRequestStatus | 3706 |Transaction ID: 125 | 3707 |User ID: 234 | 3708 |FLOOR-REQUEST-INFORMATION | 3709 | Floor Request ID: 789 | 3710 | OVERALL-REQUEST-STATUS | 3711 | Request Status: Granted | 3712 | FLOOR-REQUEST-STATUS | 3713 | Floor ID: 543 | 3714 |<----------------------------------------------| 3715 | | 3716 |(6) FloorRequestStatusAck | 3717 |Transaction ID: 125 | 3718 |User ID: 234 | 3719 |---------------------------------------------->| 3720 | | 3721 |(7) FloorRelease | 3722 |Transaction ID: 126 | 3723 |User ID: 234 | 3724 |FLOOR-REQUEST-ID: 789 | 3725 |---------------------------------------------->| 3726 | | 3727 |(8) FloorRequestStatus | 3728 |Transaction ID: 126 | 3729 |User ID: 234 | 3730 |FLOOR-REQUEST-INFORMATION | 3731 | Floor Request ID: 789 | 3732 | OVERALL-REQUEST-STATUS | 3733 | Request Status: Released | 3734 | FLOOR-REQUEST-STATUS | 3735 | Floor ID: 543 | 3736 |<----------------------------------------------| 3738 Figure 48: Requesting and releasing a floor 3740 Note that in Figure 48, the FloorRequestStatus message from the floor 3741 control server to the floor participant is a transaction-closing 3742 message as a response to the client-initiated transaction with 3743 Transaction ID 154. It does not and SHOULD NOT be followed by a 3744 FloorRequestStatusAck message from the floor participant to the floor 3745 control server. 3747 Floor Participant Floor Control 3748 Server 3749 |(1) FloorQuery | 3750 |Transaction ID: 257 | 3751 |User ID: 234 | 3752 |FLOOR-ID: 543 | 3753 |---------------------------------------------->| 3754 | | 3755 |(2) FloorStatus | 3756 |Transaction ID: 257 | 3757 |User ID: 234 | 3758 |FLOOR-ID:543 | 3759 |FLOOR-REQUEST-INFORMATION | 3760 | Floor Request ID: 764 | 3761 | OVERALL-REQUEST-STATUS | 3762 | Request Status: Accepted | 3763 | Queue Position: 1st | 3764 | FLOOR-REQUEST-STATUS | 3765 | Floor ID: 543 | 3766 | BENEFICIARY-INFORMATION | 3767 | Beneficiary ID: 124 | 3768 |FLOOR-REQUEST-INFORMATION | 3769 | Floor Request ID: 635 | 3770 | OVERALL-REQUEST-STATUS | 3771 | Request Status: Accepted | 3772 | Queue Position: 2nd | 3773 | FLOOR-REQUEST-STATUS | 3774 | Floor ID: 543 | 3775 | BENEFICIARY-INFORMATION | 3776 | Beneficiary ID: 154 | 3777 |<----------------------------------------------| 3778 | | 3779 |(3) FloorStatus | 3780 |Transaction ID: 258 | 3781 |User ID: 234 | 3782 |FLOOR-ID:543 | 3783 |FLOOR-REQUEST-INFORMATION | 3784 | Floor Request ID: 764 | 3785 | OVERALL-REQUEST-STATUS | 3786 | Request Status: Granted | 3787 | FLOOR-REQUEST-STATUS | 3788 | Floor ID: 543 | 3789 | BENEFICIARY-INFORMATION | 3790 | Beneficiary ID: 124 | 3791 |FLOOR-REQUEST-INFORMATION | 3792 | Floor Request ID: 635 | 3793 | OVERALL-REQUEST-STATUS | 3794 | Request Status: Accepted | 3795 | Queue Position: 1st | 3796 | FLOOR-REQUEST-STATUS | 3797 | Floor ID: 543 | 3798 | BENEFICIARY-INFORMATION | 3799 | Beneficiary ID: 154 | 3800 |<----------------------------------------------| 3801 | | 3802 |(4) FloorStatusAck | 3803 |Transaction ID: 258 | 3804 |User ID: 234 | 3805 |---------------------------------------------->| 3806 | | 3807 |(5) FloorStatus | 3808 |Transaction ID: 259 | 3809 |User ID: 234 | 3810 |FLOOR-ID:543 | 3811 |FLOOR-REQUEST-INFORMATION | 3812 | Floor Request ID: 635 | 3813 | OVERALL-REQUEST-STATUS | 3814 | Request Status: Granted | 3815 | FLOOR-REQUEST-STATUS | 3816 | Floor ID: 543 | 3817 | BENEFICIARY-INFORMATION | 3818 | Beneficiary ID: 154 | 3819 |<----------------------------------------------| 3820 | | 3821 |(6) FloorStatusAck | 3822 |Transaction ID: 259 | 3823 |User ID: 234 | 3824 |---------------------------------------------->| 3826 Figure 49: Obtaining status information about a floor 3828 Appendix B. Motivation for Supporting an Unreliable Transport 3830 This appendix is contained in this document as an aid to understand 3831 the background and rationale for adding support for unreliable 3832 transport. 3834 B.1. Motivation 3836 In existing video conferencing deployments, BFCP is used to manage 3837 the floor for the content sharing associated with the conference. 3838 For peer to peer scenarios, including business to business 3839 conferences and point to point conferences in general, it is 3840 frequently the case that one or both endpoints exists behind a NAT. 3841 BFCP roles are negotiated in the offer/answer exchange as specified 3842 in [9], resulting in one endpoint being responsible for opening the 3843 TCP connection used for the BFCP communication. 3845 +---------+ 3846 | Network | 3847 +---------+ 3848 +-----+ / \ +-----+ 3849 | NAT |/ \| NAT | 3850 +-----+ +-----+ 3851 +----+ / \ +----+ 3852 |BFCP|/ \|BFCP| 3853 | UA | | UA | 3854 +----+ +----+ 3856 Figure 50: Use Case 3858 The communication session between the video conferencing endpoints 3859 typically consists of a number of RTP over UDP media streams, for 3860 audio and video, and a BFCP connection for floor control. Existing 3861 deployments are most common in, but not limited to, enterprise 3862 networks. In existing deployments, NAT traversal for the RTP streams 3863 works using ICE and/or other methods, including those described in 3864 [31]. 3866 When enhancing an existing SIP based video conferencing deployment 3867 with support for content sharing, the BFCP connection often poses a 3868 problem. The reasons for this fall into two general classes. First, 3869 there may be a strong preference for UDP based signaling in general. 3870 On high capacity endpoints (e.g., PSTN gateways or SIP/H.323 inter- 3871 working gateways), TCP can suffer from head of line blocking, and it 3872 uses many kernel buffers. Network operators view UDP as a way to 3873 avoid both of these. Second, establishment and traversal of the TCP 3874 connection involving ephemeral ports, as is typically the case with 3875 BFCP over TCP, can be problematic, as described in Appendix A of 3876 [29]. A broad study of NAT behavior and peer-to-peer TCP 3877 establishment for a comprehensive set of TCP NAT traversal techniques 3878 over a wide range of commercial NAT products concluded it was not 3879 possible to establish a TCP connection in 11% of the cases [32]. The 3880 results are worse when focusing on enterprise NATs. A study of hole 3881 punching as a NAT traversal technique across a wide variety of 3882 deployed NATs reported consistently higher success rates when using 3883 UDP than when using TCP [33]. 3885 It is worth noticing that BFCP over UDP is already being used in real 3886 deployments, underlining the necessity to specify a common way to 3887 exchange BFCP messages where TCP is not appropriate, to avoid a 3888 situation where multiple different and non-interoperable 3889 implementations would co-exist in the market. The purpose of this 3890 draft is to formalize and publish the extension from the standard 3891 specification to facilitate complete interoperability between 3892 implementations. 3894 B.1.1. Alternatives Considered 3896 In selecting the approach of defining UDP as an alternate transport 3897 for BFCP, several alternatives were considered and explored to some 3898 degree. Each of these is discussed briefly in the following 3899 subsections. In summary, while the not chosen alternatives work in a 3900 number of scenarios, they are not sufficient, in and of themselves, 3901 to address the use case targeted by this draft. The last 3902 alternative, presented in Appendix B.1.1.7, is the selected one and 3903 is specified in this draft. 3905 It is also worth noting that the IETF Transport Area were asked for a 3906 way to tunnel TCP over UDP, but at that point there was no consensus 3907 on how to achieve that. 3909 B.1.1.1. ICE TCP 3911 ICE TCP [29] extends ICE to TCP based media, including the ability to 3912 offer a mix of TCP and UDP based candidates for a single stream. ICE 3913 TCP has, in general, a lower success probability for enabling TCP 3914 connectivity without a relay if both of the hosts are behind a NAT 3915 (see Appendix A of [29]) than enabling UDP connectivity in the same 3916 scenarios. The happens because many of the currently deployed NATs 3917 in video conferencing networks do not support the flow of TCP hand 3918 shake packets seen in case of TCP simultaneous-open, either because 3919 they do not allow incoming TCP SYN packets from an address to which a 3920 SYN packet has been sent to recently, or because they do not properly 3921 process the subsequent SYNACK. Implementing various techniques 3922 advocated for candidate collection in [29] should increase the 3923 success probability, but many of these techniques require support 3924 from some network elements (e.g., from the NATs). Such support is 3925 not common in enterprise NATs. 3927 B.1.1.2. Teredo 3929 Teredo [25] enables nodes located behind one or more IPv4 NATs to 3930 obtain IPv6 connectivity by tunneling packets over UDP. Teredo 3931 extensions [27] provide additional capabilities to Teredo, including 3932 support for more types of NATs and support for more efficient 3933 communication. 3935 As defined, Teredo could be used to make BFCP work for the video 3936 conferencing use cases addressed in this draft. However, running the 3937 service requires the help of "Teredo servers" and "Teredo relays" 3938 [25]. These servers and relays generally do not exist in the 3939 existing video conferencing deployments. It also requires IPv6 3940 awareness on the endpoints. It should also be noted that ICMP6, as 3941 used with Teredo to complete an initial protocol exchange and confirm 3942 that the appropriate NAT bindings have been set up, is not a 3943 conventional feature of IPv4 or even IPv6, and some currently 3944 deployed IPv6 firewalls discard ICMP messages. As these networks 3945 continue to evolve and tackle the transaction to IPv6, Teredo servers 3946 and relays may be deployed, making Teredo available as a suitable 3947 alternative to BFCP over UDP. 3949 B.1.1.3. GUT 3951 GUT [30] attempts to facilitate tunneling over UDP by encapsulating 3952 the native transport protocol and its payload (in general the whole 3953 IP payload) within a UDP packet destined to the well-known port 3954 GUT_P. Unfortunately, it requires user-space TCP, for which there is 3955 not a readily available implementation, and creating one is a large 3956 project in itself. This draft has expired and its future is still 3957 not clear as it has not yet been adopted by a working group. 3959 B.1.1.4. UPnP IGD 3961 Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on 3962 the edge of the network, providing connectivity to the Internet for 3963 computers internal to the LAN, but do not allow Internet devices to 3964 connect to computers on the internal LAN. IGDs enable a computer on 3965 an internal LAN to create port mappings on their NAT, through which 3966 hosts on the Internet can send data that will be forwarded to the 3967 computer on the internal LAN. IGDs may be self-contained hardware 3968 devices or may be software components provided within an operating 3969 system. 3971 In considering UPnP IGD, several issues exist. Not all NATs support 3972 UPnP, and many that do support it are configured with it turned off 3973 by default. NATs are often multilayered, and UPnP does not work well 3974 with such NATs. For example, a typical DSL modems acts as a NAT, and 3975 the user plugs in a wireless access point behind that, which adds 3976 another layer NAT. The client can discover the first layer of NAT 3977 using multicast but it is harder to figure out how to discover and 3978 control NATs in the next layer up. 3980 B.1.1.5. NAT PMP 3982 The NAT Port Mapping Protocol (NAT PMP) allows a computer in a 3983 private network (behind a NAT router) to automatically configure the 3984 router to allow parties outside the private network to contact it. 3985 NAT PMP runs over UDP. It essentially automates the process of port 3986 forwarding. Included in the protocol is a method for retrieving the 3987 public IP address of a NAT gateway, thus allowing a client to make 3988 this public IP address and port number known to peers that may wish 3989 to communicate with it. 3991 Many NATs do not support PMP. In those that do support it, it has 3992 similar issues with negotiation of multilayer NATs as UPnP. Video 3993 conferencing is used extensively in enterprise networks, and NAT PMP 3994 is not generally available in enterprise-class routers. 3996 B.1.1.6. SCTP 3998 It would be quite straight forward to specify a BFCP binding for SCTP 3999 [28], and then tunnel SCTP over UDP in the use case described in 4000 Appendix B.1. SCTP is gaining some momentum currently. There is 4001 ongoing discussion in the RTCWeb WG regarding this approach. 4002 However, this approach for tunneling over UDP was not mature enough 4003 when considered and not even fully specified. 4005 B.1.1.7. BFCP over UDP transport 4007 To overcome the problems with establishing TCP flows between BFCP 4008 entities, an alternative is to define UDP as an alternate transport 4009 for BFCP, leveraging the same mechanisms in place for the RTP over 4010 UDP media streams for the BFCP communication. When using UDP as the 4011 transport, it is recommended to follow the guidelines provided in 4012 [26]. 4014 Minor changes to the transaction model are introduced in that all 4015 requests now have an appropriate response to complete the 4016 transaction. The requests are sent with a retransmit timer 4017 associated with the response to achieve reliability. This 4018 alternative does not change the semantics of BFCP. It permits UDP as 4019 an alternate transport. 4021 Existing implementations, in the spirit of the approach detailed in 4022 earlier versions of this draft, have demonstrated this approach to be 4023 feasible. Initial compatibility among implementations has been 4024 achieved at previous interoperability events. The authors view this 4025 extension as a pragmatic solution to an existing deployment 4026 challenge. This is the chosen approach, and the extensions is 4027 specified in this document. 4029 Authors' Addresses 4031 Gonzalo Camarillo 4032 Ericsson 4033 Hirsalantie 11 4034 FI-02420 Jorvas 4035 Finland 4037 Email: gonzalo.camarillo@ericsson.com 4039 Keith Drage 4040 Alcatel-Lucent 4041 Quadrant, StoneHill Green, Westlea 4042 Swindon, Wilts 4043 UK 4045 Email: drage@alcatel-lucent.com 4047 Tom Kristensen 4048 Cisco 4049 Philip Pedersens vei 1 4050 NO-1366 Lysaker 4051 Norway 4053 Email: tomkrist@cisco.com, tomkri@ifi.uio.no 4055 Joerg Ott 4056 Aalto University 4057 Otakaari 5 A 4058 FI-02150 Espoo 4059 Finland 4061 Email: jo@comnet.tkk.fi 4062 Charles Eckel 4063 Cisco 4064 707 Tasman Drive 4065 California, CA 95035 4066 United States 4068 Email: eckelcu@cisco.com