idnits 2.17.1 draft-ietf-bfcpbis-rfc4582bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2012) is 4297 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 3342 ** Obsolete normative reference: RFC 5226 (ref. '3') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (ref. '4') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (ref. '5') (Obsoleted by RFC 9147) == Outdated reference: A later version (-27) exists of draft-ietf-bfcpbis-rfc4583bis-02 ** 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 4582 (ref. '17') (Obsoleted by RFC 8855) -- Obsolete informational reference (is this intentional?): RFC 5405 (ref. '19') (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '21') (Obsoleted by RFC 9260) == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-media-path-middleboxes-04 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFCPbis Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Obsoletes: 4582 (if approved) K. Drage 5 Intended status: Standards Track Alcatel-Lucent 6 Expires: January 15, 2013 T. Kristensen, Ed. 7 Cisco 8 J. Ott 9 Aalto University 10 C. Eckel 11 Cisco 12 July 14, 2012 14 The Binary Floor Control Protocol (BFCP) 15 draft-ietf-bfcpbis-rfc4582bis-04 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 January 15, 2013. 50 Copyright Notice 52 Copyright (c) 2012 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 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 3.1. Floor Creation . . . . . . . . . . . . . . . . . . . . . . 9 83 3.2. Obtaining Information to Contact a Floor Control Server . 9 84 3.3. Obtaining Floor-Resource Associations . . . . . . . . . . 9 85 3.4. Privileges of Floor Control . . . . . . . . . . . . . . . 10 86 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 10 87 4.1. Floor Participant to Floor Control Server Interface . . . 10 88 4.2. Floor Chair to Floor Control Server Interface . . . . . . 15 89 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 16 90 5.1. COMMON-HEADER Format . . . . . . . . . . . . . . . . . . . 16 91 5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . . 19 92 5.2.1. BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 21 93 5.2.2. FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 21 94 5.2.3. FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 21 95 5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 22 96 5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 23 97 5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 23 98 5.2.6.1. Error-Specific Details for Error Code 4 . . . . . 25 99 5.2.7. ERROR-INFO . . . . . . . . . . . . . . . . . . . . . . 25 100 5.2.8. PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . . 26 101 5.2.9. STATUS-INFO . . . . . . . . . . . . . . . . . . . . . 27 102 5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . . 27 103 5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . . 28 104 5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 29 105 5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . . 29 106 5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 30 107 5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 31 108 5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . . 32 109 5.2.17. FLOOR-REQUEST-STATUS . . . . . . . . . . . . . . . . . 32 110 5.2.18. OVERALL-REQUEST-STATUS . . . . . . . . . . . . . . . . 33 111 5.3. Message Format . . . . . . . . . . . . . . . . . . . . . . 34 112 5.3.1. FloorRequest . . . . . . . . . . . . . . . . . . . . . 34 113 5.3.2. FloorRelease . . . . . . . . . . . . . . . . . . . . . 34 114 5.3.3. FloorRequestQuery . . . . . . . . . . . . . . . . . . 34 115 5.3.4. FloorRequestStatus . . . . . . . . . . . . . . . . . . 35 116 5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 35 117 5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . . 35 118 5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . . 36 119 5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 36 120 5.3.9. ChairAction . . . . . . . . . . . . . . . . . . . . . 36 121 5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . . 36 122 5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 37 123 5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 37 124 5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 37 125 5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 38 126 5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . . 38 127 5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38 128 5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 38 129 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 39 130 6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . . 39 131 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . 40 132 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . 41 133 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42 134 6.3. Large Message Considerations . . . . . . . . . . . . . . . 42 135 6.3.1. Fragmentation Handling . . . . . . . . . . . . . . . . 42 136 6.3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 43 137 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 43 138 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 44 139 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 44 140 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 44 141 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 45 142 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 45 143 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 45 144 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 46 145 9. Authentication and Authorization . . . . . . . . . . . . . . . 46 146 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 46 147 10. Floor Participant Operations . . . . . . . . . . . . . . . . . 47 148 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 47 149 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 47 150 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 48 151 10.1.3. Reception of a Subsequent FloorRequestStatus 152 Message . . . . . . . . . . . . . . . . . . . . . . . 50 153 10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 50 154 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 50 155 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 50 156 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 51 157 11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 51 158 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 52 159 12. General Client Operations . . . . . . . . . . . . . . . . . . 53 160 12.1. Requesting Information about Floors . . . . . . . . . . . 53 161 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 53 162 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 54 163 12.1.3. Reception of a Subsequent FloorStatus Message . . . . 54 164 12.2. Requesting Information about Floor Requests . . . . . . . 54 165 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 55 166 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 55 167 12.3. Requesting Information about a User . . . . . . . . . . . 55 168 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 56 169 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 56 170 12.4. Obtaining the Capabilities of a Floor Control Server . . . 57 171 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 57 172 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 57 174 13. Floor Control Server Operations . . . . . . . . . . . . . . . 57 175 13.1. Reception of a FloorRequest Message . . . . . . . . . . . 58 176 13.1.1. Generating the First FloorRequestStatus Message . . . 58 177 13.1.2. Generation of Subsequent FloorRequestStatus 178 Messages . . . . . . . . . . . . . . . . . . . . . . . 60 179 13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 61 180 13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 62 181 13.4. Reception of a FloorRelease Message . . . . . . . . . . . 64 182 13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 65 183 13.5.1. Generation of the First FloorStatus Message . . . . . 65 184 13.5.2. Generation of Subsequent FloorStatus Messages . . . . 67 185 13.6. Reception of a ChairAction Message . . . . . . . . . . . . 67 186 13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 68 187 13.8. Error Message Generation . . . . . . . . . . . . . . . . . 69 188 14. Security Considerations . . . . . . . . . . . . . . . . . . . 69 189 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 190 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 70 191 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 71 192 15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 72 193 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 73 194 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 74 195 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76 196 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76 197 18.1. Normative References . . . . . . . . . . . . . . . . . . . 76 198 18.2. Informational References . . . . . . . . . . . . . . . . . 77 199 Appendix A. Example Call Flows for BFCP over Unreliable 200 Transport . . . . . . . . . . . . . . . . . . . . . . 78 201 Appendix B. Motivation for Supporting Unreliable Transport . . . 82 202 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 82 203 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 83 204 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 84 205 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 84 206 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 84 207 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 85 208 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 85 209 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 85 210 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 86 211 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86 213 1. Introduction 215 Within a conference, some applications need to manage the access to a 216 set of shared resources, such as the right to send media to a 217 particular media session. Floor control enables such applications to 218 provide users with coordinated (shared or exclusive) access to these 219 resources. 221 The Requirements for Floor Control Protocol [13] list a set of 222 requirements that need to be met by floor control protocols. The 223 Binary Floor Control Protocol (BFCP), which is specified in this 224 document, meets these requirements. 226 In addition, BFCP has been designed so that it can be used in low- 227 bandwidth environments. The binary encoding used by BFCP achieves a 228 small message size (when message signatures are not used) that keeps 229 the time it takes to transmit delay-sensitive BFCP messages to a 230 minimum. Delay-sensitive BFCP messages include FloorRequest, 231 FloorRelease, FloorRequestStatus, and ChairAction. It is expected 232 that future extensions to these messages will not increase the size 233 of these messages in a significant way. 235 The remainder of this document is organized as follows: Section 2 236 defines the terminology used throughout this document, Section 3 237 discusses the scope of BFCP (i.e., which tasks fall within the scope 238 of BFCP and which ones are performed using different mechanisms), 239 Section 4 provides a non-normative overview of BFCP operation, and 240 subsequent sections provide the normative specification of BFCP. 242 2. Terminology 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 246 "OPTIONAL" in this document are to be interpreted as described in BCP 247 14, RFC 2119 [1] and indicate requirement levels for compliant 248 implementations. 250 Media Participant: An entity that has access to the media resources 251 of a conference (e.g., it can receive a media stream). In floor- 252 controlled conferences, a given media participant is typically 253 colocated with a floor participant, but it does not need to be. 254 Third-party floor requests consist of having a floor participant 255 request a floor for a media participant when they are not colocated. 256 The protocol between a floor participant and a media participant 257 (that are not colocated) is outside the scope of this document. 259 Client: A floor participant or a floor chair that communicates with a 260 floor control server using BFCP. 262 Floor: A temporary permission to access or manipulate a specific 263 shared resource or set of resources. 265 Floor Chair: A logical entity that manages one floor (grants, denies, 266 or revokes a floor). An entity that assumes the logical role of a 267 floor chair for a given transaction may assume a different role 268 (e.g., floor participant) for a different transaction. The roles of 269 floor chair and floor participant are defined on a transaction-by- 270 transaction basis. BFCP transactions are defined in Section 8. 272 Floor Control: A mechanism that enables applications or users to gain 273 safe and mutually exclusive or non-exclusive input access to the 274 shared object or resource. 276 Floor Control Server: A logical entity that maintains the state of 277 the floor(s), including which floors exists, who the floor chairs 278 are, who holds a floor, etc. Requests to manipulate a floor are 279 directed at the floor control server. The floor control server of a 280 conference may perform other logical roles (e.g., floor participant) 281 in another conference. 283 Floor Participant: A logical entity that requests floors, and 284 possibly information about them, from a floor control server. An 285 entity that assumes the logical role of a floor participant for a 286 given transaction may assume a different role (e.g., a floor chair) 287 for a different transaction. The roles of floor participant and 288 floor chair are defined on a transaction-by-transaction basis. BFCP 289 transactions are defined in Section 8. In floor-controlled 290 conferences, a given floor participant is typically colocated with a 291 media participant, but it does not need to be. Third-party floor 292 requests consist of having a floor participant request a floor for a 293 media participant when they are not colocated. 295 Participant: An entity that acts as a floor participant, as a media 296 participant, or as both. 298 3. Scope 300 As stated earlier, BFCP is a protocol to coordinate access to shared 301 resources in a conference following the requirements defined in [13]. 302 Floor control complements other functions defined in the XCON 303 conferencing framework [14]. The floor control protocol BFCP defined 304 in this document only specifies a means to arbitrate access to 305 floors. The rules and constraints for floor arbitration and the 306 results of floor assignments are outside the scope of this document 307 and are defined by other protocols [14]. 309 Figure 1 shows the tasks that BFCP can perform. 311 +---------+ 312 | Floor | 313 | Chair | 314 | | 315 +---------+ 316 ^ | 317 | | 318 Notification | | Decision 319 | | 320 | | 321 Floor | v 322 +-------------+ Request +---------+ +-------------+ 323 | Floor |----------->| Floor | Notification | Floor | 324 | Participant | | Control |------------->| Participant | 325 | |<-----------| Server | | | 326 +-------------+ Granted or +---------+ +-------------+ 327 Denied 329 Figure 1: Functionality provided by BFCP 331 BFCP provides a means: 333 o for floor participants to send floor requests to floor control 334 servers. 336 o for floor control servers to grant or deny requests to access a 337 given resource from floor participants. 339 o for floor chairs to send floor control servers decisions regarding 340 floor requests. 342 o for floor control servers to keep floor participants and floor 343 chairs informed about the status of a given floor or a given floor 344 request. 346 Even though tasks that do not belong to the previous list are outside 347 the scope of BFCP, some of these out-of-scope tasks relate to floor 348 control and are essential for creating floors and establishing BFCP 349 connections between different entities. In the following 350 subsections, we discuss some of these tasks and mechanisms to perform 351 them. 353 3.1. Floor Creation 355 The association of a given floor with a resource or a set of 356 resources (e.g., media streams) is out of the scope of BFCP as 357 described in [14]. Floor creation and termination are also outside 358 the scope of BFCP; these aspects are handled using the conference 359 control protocol for manipulating the conference object. 360 Consequently, the floor control server needs to stay up to date on 361 changes to the conference object (e.g., when a new floor is created). 363 3.2. Obtaining Information to Contact a Floor Control Server 365 A client needs a set of data in order to establish a BFCP connection 366 to a floor control server. These data include the transport address 367 of the server, the conference identifier, and a user identifier. 369 Clients can obtain this information in different ways. One is to use 370 an SDP offer/answer [12] exchange, which is described in [7]. Other 371 mechanisms are described in the XCON framework [14] (and other 372 related documents). 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 [7]. 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). 398 3.4. Privileges of Floor Control 400 A participant whose floor request is granted has the right to use (in 401 a certain way) the resource or resources associated with the floor 402 that was requested. For example, the participant may have the right 403 to send media over a particular audio stream. 405 Nevertheless, holding a floor does not imply that others will not be 406 able to use its associated resources at the same time, even if they 407 do not have the right to do so. Determination of which media 408 participants can actually use the resources in the conference is 409 discussed in the XCON Framework [14]. 411 4. Overview of Operation 413 This section provides a non-normative description of BFCP operations. 414 Section 4.1 describes the interface between floor participants and 415 floor control servers, and Section 4.2 describes the interface 416 between floor chairs and floor control servers. 418 BFCP messages, which use a TLV (Type-Length-Value) binary encoding, 419 consist of a common header followed by a set of attributes. The 420 common header contains, among other information, a 32-bit conference 421 identifier. Floor participants, media participants, and floor chairs 422 are identified by 16-bit user identifiers. 424 BFCP supports nested attributes (i.e., attributes that contain 425 attributes). These are referred to as grouped attributes. 427 There are two types of transaction in BFCP: client-initiated 428 transactions and server-initiated transactions. Client-initiated 429 transactions consist of a message from a client to the floor control 430 server and a response from the floor control server to the client. 431 Correspondingly, server-initiated transactions consist of a message 432 from the floor control server to a client and the associated 433 acknowledgement message from the client to the floor control server. 434 Both messages can be related because they carry the same Transaction 435 ID value in their common headers. 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 call flows for two sample BFCP 477 interactions when used over reliable transport. Appendix A shows the 478 same sample interactions but over 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: The 3-bit version field MUST be set to 1 when using BFCP over 718 reliable transport, i.e. as in [17]. The 3-bit version field MUST be 719 set to 2 when using BFCP over unreliable transport, with the 720 extensions specified in this document. If a Floor Control Server 721 receives a message with an unsupported version field value, the 722 receiving server MAY send an Error message with parameter value 12 723 (Unsupported Version) to indicate this. 725 R: The Transaction Responder (R) flag-bit has relevance only for use 726 of BFCP over unreliable transport. When cleared, it indicates that 727 this message is a request initiating a new transaction, and the 728 Transaction ID that follows has been generated for this transaction. 729 When set, it indicates that this message is a response to a previous 730 request, and the Transaction ID that follows is the one associated 731 with that request. When BFCP is used over reliable transports, the 732 flag has no significance and SHOULD be cleared. 734 F: The Fragmentation (F) flag-bit has relevance only for use of BFCP 735 over unreliable transport. When cleared, the message is not 736 fragmented. When set, it indicates that the message is a fragment of 737 a large fragmented BFCP message. (The optional fields Fragment 738 Offset and Fragment Length described below are present only if the F 739 flag is set). When BFCP is used over reliable transports, the flag 740 has no significance and SHOULD be cleared. 742 Res: At this point, the 3 bits in the reserved field SHOULD be set to 743 zero by the sender of the message and MUST be ignored by the 744 receiver. 746 Primitive: This 8-bit field identifies the main purpose of the 747 message. The following primitive values are defined: 749 +-------+-----------------------+--------------------+ 750 | Value | Primitive | Direction | 751 +-------+-----------------------+--------------------+ 752 | 1 | FloorRequest | P -> S | 753 | 2 | FloorRelease | P -> S | 754 | 3 | FloorRequestQuery | P -> S ; Ch -> S | 755 | 4 | FloorRequestStatus | P <- S ; Ch <- S | 756 | 5 | UserQuery | P -> S ; Ch -> S | 757 | 6 | UserStatus | P <- S ; Ch <- S | 758 | 7 | FloorQuery | P -> S ; Ch -> S | 759 | 8 | FloorStatus | P <- S ; Ch <- S | 760 | 9 | ChairAction | Ch -> S | 761 | 10 | ChairActionAck | Ch <- S | 762 | 11 | Hello | P -> S ; Ch -> S | 763 | 12 | HelloAck | P <- S ; Ch <- S | 764 | 13 | Error | P <- S ; Ch <- S | 765 | 14 | FloorRequestStatusAck | P -> S ; Ch -> S | 766 | 15 | FloorStatusAck | P -> S ; Ch -> S | 767 | 16 | Goodbye | P -> S ; Ch -> S ; | 768 | | | P <- S ; Ch <- S | 769 | 17 | GoodbyeAck | P -> S ; Ch -> S ; | 770 | | | P <- S ; Ch <- S | 771 +-------+-----------------------+--------------------+ 773 S: Floor Control Server / P: Floor Participant / Ch: Floor Chair 775 Table 1: BFCP primitives 777 Payload Length: This 16-bit field contains the length of the message 778 in 4-octet units, excluding the common header. If a Floor Control 779 Server receives a message with an incorrect payload length field 780 value, the receiving server MAY send an Error message with parameter 781 value 13 (Incorrect Message Length) to indicate this. 783 Conference ID: This 32-bit unsigned integer field identifies the 784 conference the message belongs to. 786 Transaction ID: This field contains a 16-bit value that allows users 787 to match a given message with its response (see Section 8). 789 User ID: This field contains a 16-bit unsigned integer that uniquely 790 identifies a participant within a conference. 792 The identity used by a participant in BFCP, which is carried in 793 the User ID field, is generally mapped to the identity used by the 794 same participant in the session establishment protocol (e.g., in 795 SIP). The way this mapping is performed is outside the scope of 796 this specification. 798 Fragment Offset: This optional field is present only if the F flag is 799 set and contains a 16-bit value that specifies the number of 4-octet 800 units contained in previous fragments, excluding the common header. 802 Fragment Length: This optional field is present only if the F flag is 803 set and contains a 16-bit value that specifies the number of 4-octet 804 units contained in this fragment, excluding the common header. 806 5.2. Attribute Format 808 BFCP attributes are encoded in TLV (Type-Length-Value) format. 809 Attributes are 32-bit aligned. 811 0 1 2 3 812 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 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Type |M| Length | | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 816 | | 817 / Attribute Contents / 818 / / 819 | | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 Figure 6: Attribute format 824 Type: This 7-bit field contains the type of the attribute. Each 825 attribute, identified by its type, has a particular format. The 826 attribute formats defined are: 828 Unsigned16: The contents of the attribute consist of a 16-bit 829 unsigned integer. 831 OctetString16: The contents of the attribute consist of 16 bits of 832 arbitrary data. 834 OctetString: The contents of the attribute consist of arbitrary 835 data of variable length. 837 Grouped: The contents of the attribute consist of a sequence of 838 attributes. 840 Note that extension attributes defined in the future may define 841 new attribute formats. 843 The following attribute types are defined: 845 +------+---------------------------+---------------+ 846 | Type | Attribute | Format | 847 +------+---------------------------+---------------+ 848 | 1 | BENEFICIARY-ID | Unsigned16 | 849 | 2 | FLOOR-ID | Unsigned16 | 850 | 3 | FLOOR-REQUEST-ID | Unsigned16 | 851 | 4 | PRIORITY | OctetString16 | 852 | 5 | REQUEST-STATUS | OctetString16 | 853 | 6 | ERROR-CODE | OctetString | 854 | 7 | ERROR-INFO | OctetString | 855 | 8 | PARTICIPANT-PROVIDED-INFO | OctetString | 856 | 9 | STATUS-INFO | OctetString | 857 | 10 | SUPPORTED-ATTRIBUTES | OctetString | 858 | 11 | SUPPORTED-PRIMITIVES | OctetString | 859 | 12 | USER-DISPLAY-NAME | OctetString | 860 | 13 | USER-URI | OctetString | 861 | 14 | BENEFICIARY-INFORMATION | Grouped | 862 | 15 | FLOOR-REQUEST-INFORMATION | Grouped | 863 | 16 | REQUESTED-BY-INFORMATION | Grouped | 864 | 17 | FLOOR-REQUEST-STATUS | Grouped | 865 | 18 | OVERALL-REQUEST-STATUS | Grouped | 866 +------+---------------------------+---------------+ 868 Table 2: BFCP attributes 870 M: The 'M' bit, known as the Mandatory bit, indicates whether support 871 of the attribute is required. If a Floor Control Server receives an 872 unrecognized attribute with the 'M' bit set the server MAY send an 873 Error message with parameter value 4 (Unknown Mandatory Attribute) to 874 indicate this. The 'M' bit is significant for extension attributes 875 defined in other documents only. All attributes specified in this 876 document MUST be understood by the receiver so that the setting of 877 the 'M' bit is irrelevant for these. In all other cases, the 878 unrecognized attribute is ignored but the message is processed. 880 Length: This 8-bit field contains the length of the attribute in 881 octets, excluding any padding defined for specific attributes. The 882 length of attributes that are not grouped includes the Type, 'M' bit, 883 and Length fields. The Length in grouped attributes is the length of 884 the grouped attribute itself (including Type, 'M' bit, and Length 885 fields) plus the total length (including padding) of all the included 886 attributes. 888 Attribute Contents: The contents of the different attributes are 889 defined in the following sections. 891 5.2.1. BENEFICIARY-ID 893 The following is the format of the BENEFICIARY-ID attribute. 895 0 1 2 3 896 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 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 Figure 7: BENEFICIARY-ID format 903 Beneficiary ID: This field contains a 16-bit value that uniquely 904 identifies a user within a conference. 906 Note that although the formats of the Beneficiary ID and of the 907 User ID field in the common header are similar, their semantics 908 are different. The Beneficiary ID is used in third-party floor 909 requests and to request information about a particular 910 participant. 912 5.2.2. FLOOR-ID 914 The following is the format of the FLOOR-ID attribute. 916 0 1 2 3 917 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 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 Figure 8: FLOOR-ID format 924 Floor ID: This field contains a 16-bit value that uniquely identifies 925 a floor within a conference. 927 5.2.3. FLOOR-REQUEST-ID 929 The following is the format of the FLOOR-REQUEST-ID attribute. 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 Figure 9: FLOOR-REQUEST-ID format 939 Floor Request ID: This field contains a 16-bit value that identifies 940 a floor request at the floor control server. 942 5.2.4. PRIORITY 944 The following is the format of the PRIORITY attribute. 946 0 1 2 3 947 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 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 Figure 10: PRIORITY format 954 Prio: This field contains a 3-bit priority value, as shown in 955 Table 3. Senders SHOULD NOT use values higher than 4 in this field. 956 Receivers MUST treat values higher than 4 as if the value received 957 were 4 (Highest). The default priority value when the PRIORITY 958 attribute is missing is 2 (Normal). 960 +-------+----------+ 961 | Value | Priority | 962 +-------+----------+ 963 | 0 | Lowest | 964 | 1 | Low | 965 | 2 | Normal | 966 | 3 | High | 967 | 4 | Highest | 968 +-------+----------+ 970 Table 3: Priority values 972 Reserved: At this point, the 13 bits in the reserved field SHOULD be 973 set to zero by the sender of the message and MUST be ignored by the 974 receiver. 976 5.2.5. REQUEST-STATUS 978 The following is the format of the REQUEST-STATUS attribute. 980 0 1 2 3 981 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Figure 11: REQUEST-STATUS format 988 Request Status: This 8-bit field contains the status of the request, 989 as described in the following table. 991 +-------+-----------+ 992 | Value | Status | 993 +-------+-----------+ 994 | 1 | Pending | 995 | 2 | Accepted | 996 | 3 | Granted | 997 | 4 | Denied | 998 | 5 | Cancelled | 999 | 6 | Released | 1000 | 7 | Revoked | 1001 +-------+-----------+ 1003 Table 4: Request Status values 1005 Queue Position: This 8-bit field contains, when applicable, the 1006 position of the floor request in the floor request queue at the 1007 server. If the Request Status value is different from Accepted, if 1008 the floor control server does not implement a floor request queue, or 1009 if the floor control server does not want to provide the client with 1010 this information, all the bits of this field SHOULD be set to zero. 1012 A floor request is in Pending state if the floor control server needs 1013 to contact a floor chair in order to accept the floor request, but 1014 has not done it yet. Once the floor control chair accepts the floor 1015 request, the floor request is moved to the Accepted state. 1017 5.2.6. ERROR-CODE 1019 The following is the format of the ERROR-CODE attribute. 1021 0 1 2 3 1022 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 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 |0 0 0 0 1 1 0|M| Length | Error Code | | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1026 | | 1027 | Error Specific Details | 1028 / / 1029 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | | Padding | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 Figure 12: ERROR-CODE format 1035 Error Code: This 8-bit field contains an error code from the 1036 following table. If an error code is not recognized by the receiver, 1037 then the receiver MUST assume that an error exists, and therefore 1038 that the original message that triggered the Error message to be sent 1039 is processed, but the nature of the error is unclear. 1041 +-------+-----------------------------------------------------------+ 1042 | Value | Meaning | 1043 +-------+-----------------------------------------------------------+ 1044 | 1 | Conference does not Exist | 1045 | 2 | User does not Exist | 1046 | 3 | Unknown Primitive | 1047 | 4 | Unknown Mandatory Attribute | 1048 | 5 | Unauthorized Operation | 1049 | 6 | Invalid Floor ID | 1050 | 7 | Floor Request ID Does Not Exist | 1051 | 8 | You have Already Reached the Maximum Number of Ongoing | 1052 | | Floor Requests for this Floor | 1053 | 9 | Use TLS | 1054 | 10 | Unable to Parse Message | 1055 | 11 | Use DTLS | 1056 | 12 | Unsupported Version | 1057 | 13 | Incorrect Message Length | 1058 | 14 | Generic Error | 1059 +-------+-----------------------------------------------------------+ 1061 Table 5: Error Code meaning 1063 Note: The Generic Error error code is intended being used by a 1064 BFCP entity when an error occurs and the other specific error 1065 codes do not apply. 1067 Error Specific Details: Present only for certain Error Codes. In 1068 this document, only for Error Code 4 (Unknown Mandatory Attribute). 1070 See Section 5.2.6.1 for its definition. 1072 Padding: One, two, or three octets of padding added so that the 1073 contents of the ERROR-CODE attribute is 32-bit aligned. If the 1074 attribute is already 32-bit aligned, no padding is needed. 1076 The Padding bits SHOULD be set to zero by the sender and MUST be 1077 ignored by the receiver. 1079 5.2.6.1. Error-Specific Details for Error Code 4 1081 The following is the format of the Error-Specific Details field for 1082 Error Code 4. 1084 0 1 2 3 1085 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 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | | 1090 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | | Unknown Type|R| Unknown Type|R| 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Unknown Type|R| Unknown Type|R| 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 Figure 13: Unknown attributes format 1098 Unknown Type: These 7-bit fields contain the Types of the attributes 1099 (which were present in the message that triggered the Error message) 1100 that were unknown to the receiver. 1102 R: At this point, this bit is reserved. It SHOULD be set to zero by 1103 the sender of the message and MUST be ignored by the receiver. 1105 5.2.7. ERROR-INFO 1107 The following is the format of the ERROR-INFO attribute. 1109 0 1 2 3 1110 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 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 |0 0 0 0 1 1 1|M| Length | | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1114 | | 1115 / Text / 1116 / +-+-+-+-+-+-+-+-+ 1117 | | Padding | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 Figure 14: ERROR-INFO format 1122 Text: This field contains UTF-8 [6] encoded text. 1124 In some situations, the contents of the Text field may be generated 1125 by an automaton. If this automaton has information about the 1126 preferred language of the receiver of a particular ERROR-INFO 1127 attribute, it MAY use this language to generate the Text field. 1129 Padding: One, two, or three octets of padding added so that the 1130 contents of the ERROR-INFO attribute is 32-bit aligned. The Padding 1131 bits SHOULD be set to zero by the sender and MUST be ignored by the 1132 receiver. If the attribute is already 32-bit aligned, no padding is 1133 needed. 1135 5.2.8. PARTICIPANT-PROVIDED-INFO 1137 The following is the format of the PARTICIPANT-PROVIDED-INFO 1138 attribute. 1140 0 1 2 3 1141 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 |0 0 0 1 0 0 0|M| Length | | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1145 | | 1146 / Text / 1147 / +-+-+-+-+-+-+-+-+ 1148 | | Padding | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 Figure 15: PARTICIPANT-PROVIDED-INFO format 1153 Text: This field contains UTF-8 [6] encoded text. 1155 Padding: One, two, or three octets of padding added so that the 1156 contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit 1157 aligned. The Padding bits SHOULD be set to zero by the sender and 1158 MUST be ignored by the receiver. If the attribute is already 32-bit 1159 aligned, no padding is needed. 1161 5.2.9. STATUS-INFO 1163 The following is the format of the STATUS-INFO attribute. 1165 0 1 2 3 1166 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 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 |0 0 0 1 0 0 1|M| Length | | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1170 | | 1171 / Text / 1172 / +-+-+-+-+-+-+-+-+ 1173 | | Padding | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 Figure 16: STATUS-INFO format 1178 Text: This field contains UTF-8 [6] encoded text. 1180 In some situations, the contents of the Text field may be generated 1181 by an automaton. If this automaton has information about the 1182 preferred language of the receiver of a particular STATUS-INFO 1183 attribute, it MAY use this language to generate the Text field. 1185 Padding: One, two, or three octets of padding added so that the 1186 contents of the STATUS-INFO attribute is 32-bit aligned. The Padding 1187 bits SHOULD be set to zero by the sender and MUST be ignored by the 1188 receiver. If the attribute is already 32-bit aligned, no padding is 1189 needed. 1191 5.2.10. SUPPORTED-ATTRIBUTES 1193 The following is the format of the SUPPORTED-ATTRIBUTES attribute. 1195 0 1 2 3 1196 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 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 |0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R| 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | | 1203 / / 1204 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | | Padding | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 Figure 17: SUPPORTED-ATTRIBUTES format 1210 Supp. Attr.: These fields contain the Types of the attributes that 1211 are supported by the floor control server in the following format: 1213 R: Reserved: This bit MUST be set to zero upon transmission and MUST 1214 be ignored upon reception. 1216 Padding: One, two, or three octets of padding added so that the 1217 contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If 1218 the attribute is already 32-bit aligned, no padding is needed. 1220 The Padding bits SHOULD be set to zero by the sender and MUST be 1221 ignored by the receiver. 1223 5.2.11. SUPPORTED-PRIMITIVES 1225 The following is the format of the SUPPORTED-PRIMITIVES attribute. 1227 0 1 2 3 1228 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 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 |0 0 0 1 0 1 1|M| Length | Primitive | Primitive | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Primitive | Primitive | Primitive | Primitive | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | | 1235 / / 1236 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | | Padding | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 Figure 18: SUPPORTED-PRIMITIVES format 1242 Primitive: These fields contain the types of the BFCP messages that 1243 are supported by the floor control server. See Table 1 for the list 1244 of BFCP primitives. 1246 Padding: One, two, or three octets of padding added so that the 1247 contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If 1248 the attribute is already 32-bit aligned, no padding is needed. 1250 The Padding bits SHOULD be set to zero by the sender and MUST be 1251 ignored by the receiver. 1253 5.2.12. USER-DISPLAY-NAME 1255 The following is the format of the USER-DISPLAY-NAME attribute. 1257 0 1 2 3 1258 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 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 |0 0 0 1 1 0 0|M| Length | | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1262 | | 1263 / Text / 1264 / +-+-+-+-+-+-+-+-+ 1265 | | Padding | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 Figure 19: USER-DISPLAY-NAME format 1270 Text: This field contains the UTF-8 encoded name of the user. 1272 Padding: One, two, or three octets of padding added so that the 1273 contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The 1274 Padding bits SHOULD be set to zero by the sender and MUST be ignored 1275 by the receiver. If the attribute is already 32-bit aligned, no 1276 padding is needed. 1278 5.2.13. USER-URI 1280 The following is the format of the USER-URI attribute. 1282 0 1 2 3 1283 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 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 |0 0 0 1 1 0 1|M| Length | | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1287 | | 1288 / Text / 1289 / +-+-+-+-+-+-+-+-+ 1290 | | Padding | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 Figure 20: USER-URI format 1295 Text: This field contains the UTF-8 encoded user's contact URI, that 1296 is, the URI used by the user to set up the resources (e.g., media 1297 streams) that are controlled by BFCP. For example, in the context of 1298 a conference set up by SIP, the USER-URI attribute would carry the 1299 SIP URI of the user. 1301 Messages containing a user's URI in a USER-URI attribute also 1302 contain the user's User ID. This way, a client receiving such a 1303 message can correlate the user's URI (e.g., the SIP URI the user 1304 used to join a conference) with the user's User ID. 1306 Padding: One, two, or three octets of padding added so that the 1307 contents of the USER-URI attribute is 32-bit aligned. The Padding 1308 bits SHOULD be set to zero by the sender and MUST be ignored by the 1309 receiver. If the attribute is already 32-bit aligned, no padding is 1310 needed. 1312 5.2.14. BENEFICIARY-INFORMATION 1314 The BENEFICIARY-INFORMATION attribute is a grouped attribute that 1315 consists of a header, which is referred to as BENEFICIARY- 1316 INFORMATION-HEADER, followed by a sequence of attributes. The 1317 following is the format of the BENEFICIARY-INFORMATION-HEADER: 1319 0 1 2 3 1320 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 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 |0 0 0 1 1 1 0|M| Length | Beneficiary ID | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 Figure 21: BENEFICIARY-INFORMATION-HEADER format 1327 Beneficiary ID: This field contains a 16-bit value that uniquely 1328 identifies a user within a conference. 1330 The following is the ABNF (Augmented Backus-Naur Form) [2] of the 1331 BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE 1332 refers to extension attributes that may be defined in the future.) 1334 BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) 1335 [USER-DISPLAY-NAME] 1336 [USER-URI] 1337 *(EXTENSION-ATTRIBUTE) 1339 Figure 22: BENEFICIARY-INFORMATION format 1341 5.2.15. FLOOR-REQUEST-INFORMATION 1343 The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that 1344 consists of a header, which is referred to as FLOOR-REQUEST- 1345 INFORMATION-HEADER, followed by a sequence of attributes. The 1346 following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: 1348 0 1 2 3 1349 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 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 |0 0 0 1 1 1 1|M| Length | Floor Request ID | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format 1356 Floor Request ID: This field contains a 16-bit value that identifies 1357 a floor request at the floor control server. 1359 The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped 1360 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1361 may be defined in the future.) 1363 FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) 1364 [OVERALL-REQUEST-STATUS] 1365 1*(FLOOR-REQUEST-STATUS) 1366 [BENEFICIARY-INFORMATION] 1367 [REQUESTED-BY-INFORMATION] 1368 [PRIORITY] 1369 [PARTICIPANT-PROVIDED-INFO] 1370 *(EXTENSION-ATTRIBUTE) 1372 Figure 24: FLOOR-REQUEST-INFORMATION format 1374 5.2.16. REQUESTED-BY-INFORMATION 1376 The REQUESTED-BY-INFORMATION attribute is a grouped attribute that 1377 consists of a header, which is referred to as REQUESTED-BY- 1378 INFORMATION-HEADER, followed by a sequence of attributes. The 1379 following is the format of the REQUESTED-BY-INFORMATION-HEADER: 1381 0 1 2 3 1382 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 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 |0 0 1 0 0 0 0|M| Length | Requested-by ID | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 Figure 25: REQUESTED-BY-INFORMATION-HEADER format 1389 Requested-by ID: This field contains a 16-bit value that uniquely 1390 identifies a user within a conference. 1392 The following is the ABNF of the REQUESTED-BY-INFORMATION grouped 1393 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1394 may be defined in the future.) 1396 REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER) 1397 [USER-DISPLAY-NAME] 1398 [USER-URI] 1399 *(EXTENSION-ATTRIBUTE) 1401 Figure 26: REQUESTED-BY-INFORMATION format 1403 5.2.17. FLOOR-REQUEST-STATUS 1405 The FLOOR-REQUEST-STATUS attribute is a grouped attribute that 1406 consists of a header, which is referred to as FLOOR-REQUEST-STATUS- 1407 HEADER, followed by a sequence of attributes. The following is the 1408 format of the FLOOR-REQUEST-STATUS-HEADER: 1410 0 1 2 3 1411 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 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 |0 0 1 0 0 0 1|M| Length | Floor ID | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 Figure 27: FLOOR-REQUEST-STATUS-HEADER format 1418 Floor ID: this field contains a 16-bit value that uniquely identifies 1419 a floor within a conference. 1421 The following is the ABNF of the FLOOR-REQUEST-STATUS grouped 1422 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1423 may be defined in the future.) 1425 FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) 1426 [REQUEST-STATUS] 1427 [STATUS-INFO] 1428 *(EXTENSION-ATTRIBUTE) 1430 Figure 28: FLOOR-REQUEST-STATUS format 1432 5.2.18. OVERALL-REQUEST-STATUS 1434 The OVERALL-REQUEST-STATUS attribute is a grouped attribute that 1435 consists of a header, which is referred to as OVERALL-REQUEST-STATUS- 1436 HEADER, followed by a sequence of attributes. The following is the 1437 format of the OVERALL-REQUEST-STATUS-HEADER: 1439 0 1 2 3 1440 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 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 |0 0 1 0 0 1 0|M| Length | Floor Request ID | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 Figure 29: OVERALL-REQUEST-STATUS-HEADER format 1447 Floor Request ID: this field contains a 16-bit value that identifies 1448 a floor request at the floor control server. 1450 The following is the ABNF of the OVERALL-REQUEST-STATUS grouped 1451 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1452 may be defined in the future.) 1454 OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER) 1455 [REQUEST-STATUS] 1456 [STATUS-INFO] 1457 *(EXTENSION-ATTRIBUTE) 1459 Figure 30: OVERALL-REQUEST-STATUS format 1461 5.3. Message Format 1463 This section contains the normative ABNF (Augmented Backus-Naur Form) 1464 [2] of the BFCP messages. Extension attributes that may be defined 1465 in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. 1467 5.3.1. FloorRequest 1469 Floor participants request a floor by sending a FloorRequest message 1470 to the floor control server. The following is the format of the 1471 FloorRequest message: 1473 FloorRequest = (COMMON-HEADER) 1474 1*(FLOOR-ID) 1475 [BENEFICIARY-ID] 1476 [PARTICIPANT-PROVIDED-INFO] 1477 [PRIORITY] 1478 *(EXTENSION-ATTRIBUTE) 1480 Figure 31: FloorRequest format 1482 5.3.2. FloorRelease 1484 Floor participants release a floor by sending a FloorRelease message 1485 to the floor control server. Floor participants also use the 1486 FloorRelease message to cancel pending floor requests. The following 1487 is the format of the FloorRelease message: 1489 FloorRelease = (COMMON-HEADER) 1490 (FLOOR-REQUEST-ID) 1491 *(EXTENSION-ATTRIBUTE) 1493 Figure 32: FloorRelease format 1495 5.3.3. FloorRequestQuery 1497 Floor participants and floor chairs request information about a floor 1498 request by sending a FloorRequestQuery message to the floor control 1499 server. The following is the format of the FloorRequestQuery 1500 message: 1502 FloorRequestQuery = (COMMON-HEADER) 1503 (FLOOR-REQUEST-ID) 1504 *(EXTENSION-ATTRIBUTE) 1506 Figure 33: FloorRequestQuery format 1508 5.3.4. FloorRequestStatus 1510 The floor control server informs floor participants and floor chairs 1511 about the status of their floor requests by sending them 1512 FloorRequestStatus messages. The following is the format of the 1513 FloorRequestStatus message: 1515 FloorRequestStatus = (COMMON-HEADER) 1516 (FLOOR-REQUEST-INFORMATION) 1517 *(EXTENSION-ATTRIBUTE) 1519 Figure 34: FloorRequestStatus format 1521 5.3.5. UserQuery 1523 Floor participants and floor chairs request information about a 1524 participant and the floor requests related to this participant by 1525 sending a UserQuery message to the floor control server. The 1526 following is the format of the UserQuery message: 1528 UserQuery = (COMMON-HEADER) 1529 [BENEFICIARY-ID] 1530 *(EXTENSION-ATTRIBUTE) 1532 Figure 35: UserQuery format 1534 5.3.6. UserStatus 1536 The floor control server provides information about participants and 1537 their related floor requests to floor participants and floor chairs 1538 by sending them UserStatus messages. The following is the format of 1539 the UserStatus message: 1541 UserStatus = (COMMON-HEADER) 1542 [BENEFICIARY-INFORMATION] 1543 *(FLOOR-REQUEST-INFORMATION) 1544 *(EXTENSION-ATTRIBUTE) 1546 Figure 36: UserStatus format 1548 5.3.7. FloorQuery 1550 Floor participants and floor chairs request information about a floor 1551 or floors by sending a FloorQuery message to the floor control 1552 server. The following is the format of the FloorRequest message: 1554 FloorQuery = (COMMON-HEADER) 1555 *(FLOOR-ID) 1556 *(EXTENSION-ATTRIBUTE) 1558 Figure 37: FloorQuery format 1560 5.3.8. FloorStatus 1562 The floor control server informs floor participants and floor chairs 1563 about the status (e.g., the current holder) of a floor by sending 1564 them FloorStatus messages. The following is the format of the 1565 FloorStatus message: 1567 FloorStatus = (COMMON-HEADER) 1568 [FLOOR-ID] 1569 *(FLOOR-REQUEST-INFORMATION) 1570 *(EXTENSION-ATTRIBUTE) 1572 Figure 38: FloorStatus format 1574 5.3.9. ChairAction 1576 Floor chairs send instructions to floor control servers by sending 1577 ChairAction messages. The following is the format of the ChairAction 1578 message: 1580 ChairAction = (COMMON-HEADER) 1581 (FLOOR-REQUEST-INFORMATION) 1582 *(EXTENSION-ATTRIBUTE) 1584 Figure 39: ChairAction format 1586 5.3.10. ChairActionAck 1588 Floor control servers confirm that they have accepted a ChairAction 1589 message by sending a ChairActionAck message. The following is the 1590 format of the ChairActionAck message: 1592 ChairActionAck = (COMMON-HEADER) 1593 *(EXTENSION-ATTRIBUTE) 1595 Figure 40: ChairActionAck format 1597 5.3.11. Hello 1599 Floor participants and floor chairs check the liveliness of floor 1600 control servers by sending a Hello message. The following is the 1601 format of the Hello message: 1603 Hello = (COMMON-HEADER) 1604 *(EXTENSION-ATTRIBUTE) 1606 Figure 41: Hello format 1608 5.3.12. HelloAck 1610 Floor control servers confirm that they are alive on reception of a 1611 Hello message by sending a HelloAck message. The following is the 1612 format of the HelloAck message: 1614 HelloAck = (COMMON-HEADER) 1615 (SUPPORTED-PRIMITIVES) 1616 (SUPPORTED-ATTRIBUTES) 1617 *(EXTENSION-ATTRIBUTE) 1619 Figure 42: HelloAck format 1621 5.3.13. Error 1623 Floor control servers inform floor participants and floor chairs 1624 about errors processing requests by sending them Error messages. The 1625 following is the format of the Error message: 1627 Error = (COMMON-HEADER) 1628 (ERROR-CODE) 1629 [ERROR-INFO] 1630 *(EXTENSION-ATTRIBUTE) 1632 Figure 43: Error format 1634 5.3.14. FloorRequestStatusAck 1636 Floor participants and chairs acknowledge the receipt of a subsequent 1637 FloorRequestStatus message from the floor control server when 1638 communicating over unreliable transport. The following is the format 1639 of the FloorRequestStatusAck message: 1641 FloorRequestStatusAck = (COMMON-HEADER) 1642 *(EXTENSION-ATTRIBUTE) 1644 Figure 44: FloorRequestStatusAck format 1646 5.3.15. FloorStatusAck 1648 Floor participants and chairs acknowledge the receipt of a subsequent 1649 FloorStatus message from the floor control server when communicating 1650 over unreliable transport. The following is the format of the 1651 FloorStatusAck message: 1653 FloorStatusAck = (COMMON-HEADER) 1654 *(EXTENSION-ATTRIBUTE) 1656 Figure 45: FloorStatusAck format 1658 5.3.16. Goodbye 1660 BFCP entities communicating over an unreliable transport that wish to 1661 dissociate themselves from their remote participant do so through the 1662 transmission of a Goodbye. The following is the format of the 1663 Goodbye message: 1665 Goodbye = (COMMON-HEADER) 1666 *(EXTENSION-ATTRIBUTE) 1668 Figure 46: Goodbye format 1670 5.3.17. GoodbyeAck 1672 BFCP entities communicating over an unreliable transport should 1673 acknowledge the receipt of a Goodbye message from a peer. The 1674 following is the format of the GoodbyeAck message: 1676 GoodbyeAck = (COMMON-HEADER) 1677 *(EXTENSION-ATTRIBUTE) 1679 Figure 47: GoodbyeAck format 1681 6. Transport 1683 The transport over which BFCP entities exchange messages depends on 1684 how clients obtain information to contact the floor control server 1685 (e.g. using an SDP offer/answer exchange [7]). Two transports are 1686 supported: TCP, appropriate where entities can be sure that their 1687 connectivity is not impeded by NAT devices, media relays or 1688 firewalls; and UDP for those deployments where TCP may not be 1689 applicable or appropriate. 1691 6.1. Reliable Transport 1693 BFCP entities may elect to exchange BFCP messages using TCP 1694 connections. TCP provides an in-order reliable delivery of a stream 1695 of bytes. Consequently, message framing is implemented in the 1696 application layer. BFCP implements application-layer framing using 1697 TLV-encoded attributes. 1699 A client MUST NOT use more than one TCP connection to communicate 1700 with a given floor control server within a conference. Nevertheless, 1701 if the same physical box handles different clients (e.g. a floor 1702 chair and a floor participant), which are identified by different 1703 User IDs, a separate connection per client is allowed. 1705 If a BFCP entity (a client or a floor control server) receives data 1706 that cannot be parsed, the entity MUST close the TCP connection, and 1707 the connection SHOULD be reestablished. Similarly, if a TCP 1708 connection cannot deliver a BFCP message and times out, the TCP 1709 connection SHOULD be reestablished. 1711 The way connection reestablishment is handled depends on how the 1712 client obtains information to contact the floor control server. Once 1713 the TCP connection is reestablished, the client MAY resend those 1714 messages for which it did not get a response from the floor control 1715 server. 1717 If a floor control server detects that the TCP connection towards one 1718 of the floor participants is lost, it is up to the local policy of 1719 the floor control server what to do with the pending floor requests 1720 of the floor participant. In any case, it is RECOMMENDED that the 1721 floor control server keep the floor requests (i.e., that it does not 1722 cancel them) while the TCP connection is reestablished. 1724 If a client wishes to end its BFCP connection with a floor control 1725 server, the client closes (i.e., a graceful close) the TCP connection 1726 towards the floor control server. If a floor control server wishes 1727 to end its BFCP connection with a client (e.g., the Focus of the 1728 conference informs the floor control server that the client has been 1729 kicked out from the conference), the floor control server closes 1730 (i.e., a graceful close) the TCP connection towards the client. 1732 6.2. Unreliable Transport 1734 BFCP entities may elect to exchange BFCP messages using UDP 1735 datagrams. UDP is an unreliable transport where neither delivery nor 1736 ordering is assured. Each BFCP UDP datagram MUST contain exactly one 1737 BFCP message. In the event the size of a BFCP message exceeds the 1738 MTU size, the BFCP message will be fragmented at the IP layer. 1739 Considerations related to fragmentation are covered in Section 6.3. 1740 The message format for exchange of BFCP in UDP datagrams is the same 1741 as for a TCP stream above. 1743 Clients MUST announce their presence to the floor control server by 1744 transmission of a Hello message. This Hello message MUST be 1745 responded to with a HelloAck message and only upon receipt of 1746 HelloAck can the client consider the floor control service as present 1747 and available. 1749 As described in Section 8, each request sent by a floor participant 1750 or chair shall form a client transaction that expects an 1751 acknowledgement message back from the floor control server within a 1752 retransmission window. Concordantly, messages sent by the floor 1753 control server that are not transaction-completing (e.g. FloorStatus 1754 announcements as part of a FloorQuery subscription) are server- 1755 initiated transactions that require acknowledgement messages from the 1756 floor participant and chair entities to which they were sent. 1758 If a Floor Control Server receives data that cannot be parsed, the 1759 receiving server MAY send an Error message with parameter value 10 1760 (Unable to parse message) indicating receipt of a malformed message. 1761 If the message can be parsed to the extent that it is able to discern 1762 that it was a response to an outstanding request transaction, the 1763 client MAY discard the message and await retransmission. BFCP 1764 entities receiving an Error message with value 10 SHOULD acknowledge 1765 the error and act accordingly. 1767 Transaction ID values are non-sequential and entities are at liberty 1768 to select values at random. Entities MUST only have at most one 1769 outstanding request transaction at any one time. Implicit 1770 subscriptions occur for a client-initiated request transaction whose 1771 acknowledgement is implied by the first server-initiated response for 1772 that transaction, followed by zero of more subsequent server- 1773 initiated messages corresponding to the same transaction. An example 1774 is a FloorRequest message for which there are potentially multiple 1775 responses from the floor control server as it processes intermediate 1776 states until a terminal state (e.g. Granted or Denied) is attained. 1777 The subsequent changes in state for the request are new transactions 1778 whose Transaction ID is determined by the floor control server and 1779 whose receipt by the client participant shall be acknowledged with a 1780 FloorRequestStatusAck message. 1782 By restricting entities to having at most one pending transaction 1783 open in a BFCP connection, both the out-of-order receipt of messages 1784 as well as the possibility for congestion are mitigated. Additional 1785 details regarding congestion control are provided in Section 6.2.1. 1786 A server-initiated request (e.g. a FloorStatus with an update from 1787 the floor control server) received by a participant before the 1788 initial FloorRequestStatus message that closes the client-initiated 1789 transaction that was instigated by the FloorRequest MUST be treated 1790 as superseding the information conveyed in any delinquent response. 1791 As the floor control server cannot send a second update to the 1792 implicit floor status subscription until the first is acknowledged, 1793 ordinality is maintained. 1795 If a client wishes to end its BFCP association with a floor control 1796 server, it is RECOMMENDED that the client send a Goodbye message to 1797 dissociate itself from any allocated resources. If a floor control 1798 server wishes to end its BFCP association with a client (e.g. the 1799 Focus of the conference informs the floor control server that the 1800 client has been kicked out from the conference), it is RECOMMENDED 1801 that the floor control server send a Goodbye message towards the 1802 client. 1804 6.2.1. Congestion Control 1806 BFCP may be characterized to generate "low data-volume" traffic, per 1807 the classification in [19]. Nevertheless is it necessary to ensure 1808 suitable and necessary congestion control mechanisms are used for 1809 BFCP over UDP. As described in previous paragraph, within the same 1810 BFCP connection, every entity - client or server - is only allowed to 1811 send one request at a time, and await the acknowledging response. 1812 This way at most one datagram is sent per RTT given the message is 1813 not lost during transmission. In case the message is lost, the 1814 request retransmission timer T1 specified in Section 8.3.1 will fire 1815 and the message is retransmitted up to three times, in addition to 1816 the original transmission of the message. The default initial 1817 interval is set to 500ms and the interval is doubled after each 1818 retransmission attempt, this is identical to the specification of the 1819 T1 timer in SIP as described in Section 17.1.1.2 of [16]. 1821 6.2.2. ICMP Error Handling 1823 If a BFCP entity receives an ICMP port unreachable message mid- 1824 conversation, the entity SHOULD treat the conversation as closed 1825 (e.g. an implicit Goodbye message from the peer). The entity MAY 1826 attempt to re-establish the conversation afresh. The new connection 1827 will appear as a wholly new floor participant, chair or floor control 1828 server with all state previously held about that participant lost. 1830 Note: This is because the peer entities cannot rely on IP and port 1831 tuple to uniquely identify the participant, nor would extending Hello 1832 to include an attribute that advertised what the entity previously 1833 was assigned as a User ID be acceptable due to session hijacking. 1835 In deployments where NAT appliances, firewalls or other such devices 1836 are present and affecting port reachability for each entity, one 1837 possibility is to utilize the peer connectivity checks, relay use and 1838 NAT pinhole maintenance mechanisms defined in ICE [15]. 1840 6.3. Large Message Considerations 1842 Large messages become a concern when using BFCP if the overall size 1843 of a single BFCP message exceeds that representable within the 16-bit 1844 Payload Length field of the COMMON-HEADER. When using UDP, there is 1845 the added concern that a single BFCP message can be fragmented at the 1846 IP layer if its overall size exceeds the MTU threshold of the 1847 network. 1849 6.3.1. Fragmentation Handling 1851 When transmitting a BFCP message with size greater than the MTU, the 1852 sender should fragment the message into a series of N contiguous data 1853 ranges. The sender should then create N BFCP fragment messages (one 1854 for each data range) with the same Transaction ID. The size of each 1855 of these N messages MUST be smaller than the MTU. The F flag in the 1856 COMMON-HEADER is set to indicate fragmentation of the BFCP message. 1858 For each of these fragments the Fragment Offset and Fragment Length 1859 fields are included in the COMMON-HEADER. The Fragment Offset field 1860 denotes the number of bytes contained in the previous fragments. The 1861 Fragment Length contains the length of the fragment itself. Note 1862 that the Payload Length field contains the length of the entire, 1863 unfragmented message. 1865 When a BFCP implementation receives a BFCP message fragment, it MUST 1866 buffer the fragment until it has received the entire BFCP message. 1867 The state machine should handle the BFCP message only after all the 1868 fragments for the message have been received. 1870 If a fragment of a BFCP message is lost, the sender will not receive 1871 an ACK for the message. Therefore the sender will retransmit the 1872 message with same transaction ID as specified in Section 8.3. If the 1873 ACK sent by the receiver is lost, then the entire message will be 1874 resent by the sender. The receiver MUST then retransmit the ACK. 1875 The receiver can discard an incomplete buffer utilizing the Response 1876 Retransmission Timer, starting the timer after the receipt of the 1877 first fragment. 1879 6.3.2. NAT Traversal 1881 One of the key benefits when using UDP for BFCP communication is the 1882 ability to leverage the existing NAT traversal infrastructure and 1883 strategies deployed to facilitate transport of the media associated 1884 with the video conferencing sessions. Depending on the given 1885 deployment, this infrastructure typically includes some subset of ICE 1886 [15]. 1888 In order to facilitate the initial establishment of NAT bindings, and 1889 to maintain those bindings once established, BFCP over UDP entities 1890 are RECOMMENDED to use STUN [11] for keep-alives, as described for 1891 SIP [10]. This results in each BFCP entity sending a packet, both to 1892 open the pinhole and to learn what IP/port the NAT assigned for the 1893 binding. 1895 Informational note: Since the version number is set to 2 when BFCP 1896 is used over unreliable transport, cf. the Ver field in 1897 Section 5.1, it is straight forward to distinguish between STUN 1898 and BFCP packets even without checking the STUN magic cookie [11]. 1900 In order to facilitate traversal of BFCP packets through NATs, BFCP 1901 over UDP entities are RECOMMENDED to use symmetric ports for sending 1902 and receiving BFCP packets, as recommended for RTP/RTCP [9]. 1904 7. Lower-Layer Security 1906 BFCP relies on lower-layer security mechanisms to provide replay and 1907 integrity protection and confidentiality. BFCP floor control servers 1908 and clients (which include both floor participants and floor chairs) 1909 MUST support TLS for transport over TCP [4] and MUST support DTLS [5] 1910 for transport over UDP. Any BFCP entity MAY support other security 1911 mechanisms. 1913 BFCP entities MUST support, at a minimum, the 1914 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [4]. 1916 Which party, the client or the floor control server, acts as the TLS/ 1917 DTLS server depends on how the underlying TLS/DTLS connection is 1918 established. For a TCP/TLS connection established using an SDP 1919 offer/answer exchange [7], the answerer (which may be the client or 1920 the floor control server) always acts as the TLS server. For a UDP/ 1921 DTLS connection established using the same exchange, either party can 1922 be the DTLS server depending on the setup attributes exchanged; 1923 examples can be found in [8]. 1925 8. Protocol Transactions 1927 In BFCP, there are two types of transactions: client-initiated 1928 transactions and server-initiated transactions (notifications). 1929 Client-initiated transactions consist of a request from a client to a 1930 floor control server and a response from the floor control server to 1931 the client. The request carries a Transaction ID in its common 1932 header, which the floor control server copies into the response. 1933 Clients use Transaction ID values to match responses with previously 1934 issued requests. 1936 Server-initiated transactions consist of a single message from a 1937 floor control server to a client. Since they do not trigger any 1938 response, their Transaction ID is set to 0 when used over reliable 1939 transports, but must be non-zero and unique in the context of 1940 outstanding transactions over unreliable transports. 1942 When using BFCP over unreliable transports, all requests will use 1943 retransmit timer T1 (see Section 8.3) until the transaction is 1944 completed. 1946 8.1. Client Behavior 1948 A client starting a client-initiated transaction MUST set the 1949 Conference ID in the common header of the message to the Conference 1950 ID for the conference that the client obtained previously. 1952 The client MUST set the Transaction ID value in the common header to 1953 a number that is different from 0 and that MUST NOT be reused in 1954 another message from the client until a response from the server is 1955 received for the transaction. The client uses the Transaction ID 1956 value to match this message with the response from the floor control 1957 server. 1959 8.2. Server Behavior 1961 A floor control server sending a response within a client-initiated 1962 transaction MUST copy the Conference ID, the Transaction ID, and the 1963 User ID from the request received from the client into the response. 1965 Server-initiated transactions MUST contain a Transaction ID equal to 1966 0 when BFCP is used over reliable transports. Over unreliable 1967 transport, the Transaction ID shall have the same properties as for 1968 client-initiated transactions: the server MUST set the Transaction ID 1969 value in the common header to a number that is different from 0 and 1970 that MUST NOT be reused in another message from the server until the 1971 appropriate response from the client is received for the transaction. 1972 The server uses the Transaction ID value to match this message with 1973 the response from the floor participant or floor chair. 1975 8.3. Timers 1977 When BFCP entities are communicating over an unreliable transport, 1978 two retransmission timers are employed to help mitigate against loss 1979 of datagrams. Retransmission and response caching are not required 1980 when BFCP entities communicate over reliable transports. 1982 8.3.1. Request Retransmission Timer, T1 1984 T1 is a timer that schedules retransmission of a request until an 1985 appropriate response is received or until the maximum number of 1986 retransmissions have occurred. The timer doubles on each re- 1987 transmit, failing after three unacknowledged retransmission attempts. 1989 If a valid response is not received for a client- or server-initiated 1990 transaction, the implementation MUST consider the BFCP association as 1991 failed. Implementations SHOULD follow the reestablishment procedure 1992 described in section 6 (e.g. initiate a new offer/answer [12] 1993 exchange). Alternatively, they MAY continue without BFCP and 1994 therefore not be participant in any floor control actions. 1996 8.3.2. Response Retransmission Timer, T2 1998 T2 is a timer that, when fires, signals that the BFCP entity can 1999 release knowledge of the transaction against which it is running. It 2000 is started upon the first transmission of the response to a request 2001 and is the only mechanism by which that response is released by the 2002 BFCP entity. Any subsequent retransmissions of the same request can 2003 be responded to by replaying the cached response, whilst that value 2004 is retained until the timer has fired. 2006 T2 shall be set such that it encompasses all legal retransmissions 2007 per T1 plus a factor to accommodate network latency between BFCP 2008 entities. 2010 8.3.3. Timer Values 2012 The table below defines the different timers required when BFCP 2013 entities communicate over an unreliable transport. 2015 +-------+--------------------------------------+---------+ 2016 | Timer | Description | Value/s | 2017 +-------+--------------------------------------+---------+ 2018 | T1 | Initial request retransmission timer | 0.5s | 2019 | T2 | Response retransmission timer | 10s | 2020 +-------+--------------------------------------+---------+ 2022 Table 6: Timers 2024 The default value for T1 is 500 ms, this is an estimate of the RTT 2025 for completing the transaction. T1 MAY be chosen larger, and this is 2026 RECOMMENDED if it is known in advance that the RTT is larger. 2027 Regardless of the value of T1, the exponential backoffs on 2028 retransmissions described in Section 8.3.1 MUST be used. 2030 9. Authentication and Authorization 2032 BFCP clients SHOULD authenticate the floor control server before 2033 sending any BFCP message to it or accepting any BFCP message from it. 2034 Similarly, floor control servers SHOULD authenticate a client before 2035 accepting any BFCP message from it or sending any BFCP message to it. 2037 BFCP supports TLS/DTLS mutual authentication between clients and 2038 floor control servers, as specified in Section 9.1. This is the 2039 RECOMMENDED authentication mechanism in BFCP. 2041 Note that future extensions may define additional authentication 2042 mechanisms. 2044 In addition to authenticating BFCP messages, floor control servers 2045 need to authorize them. On receiving an authenticated BFCP message, 2046 the floor control server checks whether the client sending the 2047 message is authorized. If the client is not authorized to perform 2048 the operation being requested, the floor control server generates an 2049 Error message, as described in Section 13.8, with an Error code with 2050 a value of 5 (Unauthorized Operation). Messages from a client that 2051 cannot be authorized MUST NOT be processed further. 2053 9.1. TLS/DTLS Based Mutual Authentication 2055 BFCP supports TLS/DTLS based mutual authentication between clients 2056 and floor control servers. BFCP assumes that there is an integrity- 2057 protected channel between the client and the floor control server 2058 that can be used to exchange their self-signed certificates or, more 2059 commonly, the fingerprints of these certificates. These certificates 2060 are used at TLS/DTLS establishment time. 2062 The implementation of such an integrity-protected channel using 2063 SIP and the SDP offer/answer model is described in [7]. 2065 BFCP messages received over an authenticated TLS/DTLS connection are 2066 considered authenticated. A floor control server that receives a 2067 BFCP message over TCP/UDP (no TLS/DTLS) can request the use of TLS/ 2068 DTLS by generating an Error message, as described in Section 13.8, 2069 with an Error code with a value of 9 (Use TLS) or a value of 11 (Use 2070 DTLS) respectively. Clients SHOULD simply ignore unauthenticated 2071 messages. 2073 Note that future extensions may define additional authentication 2074 mechanisms that may not require an initial integrity-protected 2075 channel (e.g., authentication based on certificates signed by a 2076 certificate authority). 2078 As described in Section 9, floor control servers need to perform 2079 authorization before processing any message. In particular, the 2080 floor control server SHOULD check that messages arriving over a given 2081 authenticated TLS/DTLS connection use an authorized User ID (i.e., a 2082 User ID that the user that established the authenticated TLS/DTLS 2083 connection is allowed to use). 2085 10. Floor Participant Operations 2087 This section specifies how floor participants can perform different 2088 operations, such as requesting a floor, using the protocol elements 2089 described in earlier sections. Section 11 specifies operations that 2090 are specific to floor chairs, such as instructing the floor control 2091 server to grant or revoke a floor, and Section 12 specifies 2092 operations that can be performed by any client (i.e., both floor 2093 participants and floor chairs). 2095 10.1. Requesting a Floor 2097 A floor participant that wishes to request one or more floors does so 2098 by sending a FloorRequest message to the floor control server. 2100 10.1.1. Sending a FloorRequest Message 2102 The ABNF in Section 5.3.1 describes the attributes that a 2103 FloorRequest message can contain. In addition, the ABNF specifies 2104 normatively which of these attributes are mandatory, and which ones 2105 are optional. 2107 The floor participant sets the Conference ID and the Transaction ID 2108 in the common header following the rules given in Section 8.1. 2110 The floor participant sets the User ID in the common header to the 2111 floor participant's identifier. This User ID will be used by the 2112 floor control server to authenticate and authorize the request. If 2113 the sender of the FloorRequest message (identified by the User ID) is 2114 not the participant that would eventually get the floor (i.e., a 2115 third-party floor request), the sender SHOULD add a BENEFICIARY-ID 2116 attribute to the message identifying the beneficiary of the floor. 2118 Note that the name space for both the User ID and the Beneficiary 2119 ID is the same. That is, a given participant is identified by a 2120 single 16-bit value that can be used in the User ID in the common 2121 header and in several attributes: BENEFICIARY-ID, BENEFICIARY- 2122 INFORMATION, and REQUESTED-BY-INFORMATION. 2124 The floor participant must insert at least one FLOOR-ID attribute in 2125 the FloorRequest message. If the client inserts more than one 2126 FLOOR-ID attribute, the floor control server will treat all the floor 2127 requests as an atomic package. That is, the floor control server 2128 will either grant or deny all the floors in the FloorRequest message. 2130 The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute 2131 to state the reason why the floor or floors are being requested. The 2132 Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for 2133 human consumption. 2135 The floor participant may request that the server handle the floor 2136 request with a certain priority using a PRIORITY attribute. 2138 10.1.2. Receiving a Response 2140 A message from the floor control server is considered a response to 2141 the FloorRequest message if the message from the floor control server 2142 has the same Conference ID, Transaction ID, and User ID as the 2143 FloorRequest message, as described in Section 8.1. On receiving such 2144 a response, the floor participant follows the rules in Section 9 that 2145 relate to floor control server authentication. 2147 The successful processing of a FloorRequest message at the floor 2148 control server involves generating one or several FloorRequestStatus 2149 messages. The floor participant obtains a Floor Request ID in the 2150 Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in 2151 the first FloorRequestStatus message from the floor control server. 2153 Subsequent FloorRequestStatus messages from the floor control server 2154 regarding the same floor request will carry the same Floor Request ID 2155 in a FLOOR-REQUEST-INFORMATION attribute as the initial 2156 FloorRequestStatus message. This way, the floor participant can 2157 associate subsequent incoming FloorRequestStatus messages with the 2158 ongoing floor request. 2160 The floor participant obtains information about the status of the 2161 floor request in the FLOOR-REQUEST-INFORMATION attribute of each of 2162 the FloorRequestStatus messages received from the floor control 2163 server. This attribute is a grouped attribute, and as such it 2164 includes a number of attributes that provide information about the 2165 floor request. 2167 The OVERALL-REQUEST-STATUS attribute provides information about the 2168 overall status of the floor request. If the Request Status value is 2169 Granted, all the floors that were requested in the FloorRequest 2170 message have been granted. If the Request Status value is Denied, 2171 all the floors that were requested in the FloorRequest message have 2172 been denied. A floor request is considered to be ongoing while it is 2173 in the Pending, Accepted, or Granted states. If the floor request 2174 value is unknown, then the response is still processed. However, no 2175 meaningful value can be reported to the user. 2177 The STATUS-INFO attribute, if present, provides extra information 2178 that the floor participant MAY display to the user. 2180 The FLOOR-REQUEST-STATUS attributes provide information about the 2181 status of the floor request as it relates to a particular floor. The 2182 STATUS-INFO attribute, if present, provides extra information that 2183 the floor participant MAY display to the user. 2185 The BENEFICIARY-INFORMATION attribute identifies the beneficiary of 2186 the floor request in third-party floor requests. The REQUESTED-BY- 2187 INFORMATION attribute need not be present in FloorRequestStatus 2188 messages received by the floor participant that requested the floor, 2189 as this floor participant is already identified by the User ID in the 2190 common header. 2192 The PRIORITY attribute, when present, contains the priority that was 2193 requested by the generator of the FloorRequest message. 2195 If the response is an Error message, the floor control server could 2196 not process the FloorRequest message for some reason, which is 2197 described in the Error message. 2199 10.1.3. Reception of a Subsequent FloorRequestStatus Message 2201 When communicating over unreliable transport and upon receiving a 2202 FloorRequestStatus message from a floor control server, the 2203 participant MUST respond with a FloorRequestStatusAck message within 2204 the transaction failure window to complete the transaction. 2206 10.2. Cancelling a Floor Request and Releasing a Floor 2208 A floor participant that wishes to cancel an ongoing floor request 2209 does so by sending a FloorRelease message to the floor control 2210 server. The FloorRelease message is also used by floor participants 2211 that hold a floor and would like to release it. 2213 10.2.1. Sending a FloorRelease Message 2215 The ABNF in Section 5.3.2 describes the attributes that a 2216 FloorRelease message can contain. In addition, the ABNF specifies 2217 normatively which of these attributes are mandatory, and which ones 2218 are optional. 2220 The floor participant sets the Conference ID and the Transaction ID 2221 in the common header following the rules given in Section 8.1. The 2222 floor participant sets the User ID in the common header to the floor 2223 participant's identifier. This User ID will be used by the floor 2224 control server to authenticate and authorize the request. 2226 Note that the FloorRelease message is used to release a floor or 2227 floors that were granted and to cancel ongoing floor requests 2228 (from the protocol perspective, both are ongoing floor requests). 2229 Using the same message in both situations helps resolve the race 2230 condition that occurs when the FloorRelease message and the 2231 FloorGrant message cross each other on the wire. 2233 The floor participant uses the FLOOR-REQUEST-ID that was received in 2234 the response to the FloorRequest message that the FloorRelease 2235 message is cancelling. 2237 Note that if the floor participant requested several floors as an 2238 atomic operation (i.e., in a single FloorRequest message), all the 2239 floors are released as an atomic operation as well (i.e., all are 2240 released at the same time). 2242 10.2.2. Receiving a Response 2244 A message from the floor control server is considered a response to 2245 the FloorRelease message if the message from the floor control server 2246 has the same Conference ID, Transaction ID, and User ID as the 2247 FloorRequest message, as described in Section 8.1. On receiving such 2248 a response, the floor participant follows the rules in Section 9 that 2249 relate to floor control server authentication. 2251 If the response is a FloorRequestStatus message, the Request Status 2252 value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR- 2253 REQUEST-INFORMATION grouped attribute) will be Cancelled or Released. 2255 If the response is an Error message, the floor control server could 2256 not process the FloorRequest message for some reason, which is 2257 described in the Error message. 2259 It is possible that the FloorRelease message crosses on the wire with 2260 a FloorRequestStatus message from the server with a Request Status 2261 different from Cancelled or Released. In any case, such a 2262 FloorRequestStatus message will not be a response to the FloorRelease 2263 message, as its Transaction ID will not match that of the 2264 FloorRelease. 2266 11. Chair Operations 2268 This section specifies how floor chairs can instruct the floor 2269 control server to grant or revoke a floor using the protocol elements 2270 described in earlier sections. 2272 Floor chairs that wish to send instructions to a floor control server 2273 do so by sending a ChairAction message. 2275 11.1. Sending a ChairAction Message 2277 The ABNF in Section 5.3.9 describes the attributes that a ChairAction 2278 message can contain. In addition, the ABNF specifies normatively 2279 which of these attributes are mandatory, and which ones are optional. 2281 The floor chair sets the Conference ID and the Transaction ID in the 2282 common header following the rules given in Section 8.1. The floor 2283 chair sets the User ID in the common header to the floor chair's 2284 identifier. This User ID will be used by the floor control server to 2285 authenticate and authorize the request. 2287 The ChairAction message contains instructions that apply to one or 2288 more floors within a particular floor request. The floor or floors 2289 are identified by the FLOOR-REQUEST-STATUS attributes and the floor 2290 request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which 2291 are carried in the ChairAction message. 2293 For example, if a floor request consists of two floors that depend on 2294 different floor chairs, each floor chair will grant its floor within 2295 the floor request. Once both chairs have granted their floor, the 2296 floor control server will grant the floor request as a whole. On the 2297 other hand, if one of the floor chairs denies its floor, the floor 2298 control server will deny the floor request as a whole, regardless of 2299 the other floor chair's decision. 2301 The floor chair provides the new status of the floor request as it 2302 relates to a particular floor using a FLOOR-REQUEST-STATUS attribute. 2303 If the new status of the floor request is Accepted, the floor chair 2304 MAY use the Queue Position field to provide a queue position for the 2305 floor request. If the floor chair does not wish to provide a queue 2306 position, all the bits of the Queue Position field SHOULD be set to 2307 zero. The floor chair SHOULD use the Status Revoked to revoke a 2308 floor that was granted (i.e., Granted status) and SHOULD use the 2309 Status Denied to reject floor requests in any other status (e.g., 2310 Pending and Accepted). 2312 The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the 2313 ChairAction message to provide a new overall status for the floor 2314 request. If the new overall status of the floor request is Accepted, 2315 the floor chair MAY use the Queue Position field to provide a queue 2316 position for the floor request. 2318 Note that a particular floor control server may implement a 2319 different queue for each floor containing all the floor requests 2320 that relate to that particular floor, a general queue for all 2321 floor requests, or both. Also note that a floor request may 2322 involve several floors and that a ChairAction message may only 2323 deal with a subset of these floors (e.g., if a single floor chair 2324 is not authorized to manage all the floors). In this case, the 2325 floor control server will combine the instructions received from 2326 the different floor chairs in FLOOR-REQUEST-STATUS attributes to 2327 come up with the overall status of the floor request. 2329 Note that, while the action of a floor chair may communicate 2330 information in the OVERALL-REQUEST-STATUS attribute, the floor 2331 control server may override, modify, or ignore this field's 2332 content. 2334 The floor chair may use STATUS-INFO attributes to state the reason 2335 why the floor or floors are being accepted, granted, or revoked. The 2336 Text in the STATUS-INFO attribute is intended for human consumption. 2338 11.2. Receiving a Response 2340 A message from the floor control server is considered a response to 2341 the ChairAction message if the message from the server has the same 2342 Conference ID, Transaction ID, and User ID as the ChairAction 2343 message, as described in Section 8.1. On receiving such a response, 2344 the floor chair follows the rules in Section 9 that relate to floor 2345 control server authentication. 2347 A ChairActionAck message from the floor control server confirms that 2348 the floor control server has accepted the ChairAction message. An 2349 Error message indicates that the floor control server could not 2350 process the ChairAction message for some reason, which is described 2351 in the Error message. 2353 12. General Client Operations 2355 This section specifies operations that can be performed by any 2356 client. That is, they are not specific to floor participants or 2357 floor chairs. They can be performed by both. 2359 12.1. Requesting Information about Floors 2361 A client can obtain information about the status of a floor or floors 2362 in different ways, which include using BFCP and using out-of-band 2363 mechanisms. Clients using BFCP to obtain such information use the 2364 procedures described in this section. 2366 Clients request information about the status of one or several floors 2367 by sending a FloorQuery message to the floor control server. 2369 12.1.1. Sending a FloorQuery Message 2371 The ABNF in Section 5.3.7 describes the attributes that a FloorQuery 2372 message can contain. In addition, the ABNF specifies normatively 2373 which of these attributes are mandatory, and which ones are optional. 2375 The client sets the Conference ID and the Transaction ID in the 2376 common header following the rules given in Section 8.1. The client 2377 sets the User ID in the common header to the client's identifier. 2378 This User ID will be used by the floor control server to authenticate 2379 and authorize the request. 2381 The client inserts in the message all the Floor IDs it wants to 2382 receive information about. The floor control server will send 2383 periodic information about all of these floors. If the client does 2384 not want to receive information about a particular floor any longer, 2385 it sends a new FloorQuery message removing the FLOOR-ID of this 2386 floor. If the client does not want to receive information about any 2387 floor any longer, it sends a FloorQuery message with no FLOOR-ID 2388 attribute. 2390 12.1.2. Receiving a Response 2392 A message from the floor control server is considered a response to 2393 the FloorQuery message if the message from the floor control server 2394 has the same Conference ID, Transaction ID, and User ID as the 2395 FloorRequest message, as described in Section 8.1. On receiving such 2396 a response, the client follows the rules in Section 9 that relate to 2397 floor control server authentication. 2399 On reception of the FloorQuery message, the floor control server will 2400 respond with a FloorStatus message or with an Error message. If the 2401 response is a FloorStatus message, it will contain information about 2402 one of the floors the client requested information about. If the 2403 client did not include any FLOOR-ID attribute in its FloorQuery 2404 message (i.e., the client does not want to receive information about 2405 any floor any longer), the FloorStatus message from the floor control 2406 server will not include any FLOOR-ID attribute either. 2408 FloorStatus messages that carry information about a floor contain a 2409 FLOOR-ID attribute that identifies the floor. After this attribute, 2410 FloorStatus messages contain information about existing (one or more) 2411 floor requests that relate to that floor. The information about each 2412 particular floor request is encoded in a FLOOR-REQUEST-INFORMATION 2413 attribute. This grouped attribute carries a Floor Request ID that 2414 identifies the floor request, followed by a set of attributes that 2415 provide information about the floor request. 2417 After the first FloorStatus, the floor control server will continue 2418 sending FloorStatus messages, periodically informing the client about 2419 changes on the floors the client requested information about. 2421 12.1.3. Reception of a Subsequent FloorStatus Message 2423 When communicating over unreliable transport and upon receiving a 2424 FloorStatus message from a floor control server, the participant MUST 2425 respond with a FloorStatusAck message within the transaction failure 2426 window to complete the transaction. 2428 12.2. Requesting Information about Floor Requests 2430 A client can obtain information about the status of one or several 2431 floor requests in different ways, which include using BFCP and using 2432 out-of-band mechanisms. Clients using BFCP to obtain such 2433 information use the procedures described in this section. 2435 Clients request information about the current status of a floor 2436 request by sending a FloorRequestQuery message to the floor control 2437 server. 2439 Requesting information about a particular floor request is useful in 2440 a number of situations. For example, on reception of a FloorRequest 2441 message, a floor control server may choose to return 2442 FloorRequestStatus messages only when the floor request changes its 2443 state (e.g., from Accepted to Granted), but not when the floor 2444 request advances in its queue. In this situation, if the user 2445 requests it, the floor participant can use a FloorRequestQuery 2446 message to poll the floor control server for the status of the floor 2447 request. 2449 12.2.1. Sending a FloorRequestQuery Message 2451 The ABNF in Section 5.3.3 describes the attributes that a 2452 FloorRequestQuery message can contain. In addition, the ABNF 2453 specifies normatively which of these attributes are mandatory, and 2454 which ones are optional. 2456 The client sets the Conference ID and the Transaction ID in the 2457 common header following the rules given in Section 8.1. The client 2458 sets the User ID in the common header to the client's identifier. 2459 This User ID will be used by the floor control server to authenticate 2460 and authorize the request. 2462 The client must insert a FLOOR-REQUEST-ID attribute that identifies 2463 the floor request at the floor control server. 2465 12.2.2. Receiving a Response 2467 A message from the floor control server is considered a response to 2468 the FloorRequestQuery message if the message from the floor control 2469 server has the same Conference ID, Transaction ID, and User ID as the 2470 FloorRequestQuery message, as described in Section 8.1. On receiving 2471 such a response, the client follows the rules in Section 9 that 2472 relate to floor control server authentication. 2474 If the response is a FloorRequestStatus message, the client obtains 2475 information about the status of the FloorRequest the client requested 2476 information about in a FLOOR-REQUEST-INFORMATION attribute. 2478 If the response is an Error message, the floor control server could 2479 not process the FloorRequestQuery message for some reason, which is 2480 described in the Error message. 2482 12.3. Requesting Information about a User 2484 A client can obtain information about a participant and the floor 2485 requests related to this participant in different ways, which include 2486 using BFCP and using out-of-band mechanisms. Clients using BFCP to 2487 obtain such information use the procedures described in this section. 2489 Clients request information about a participant and the floor 2490 requests related to this participant by sending a UserQuery message 2491 to the floor control server. 2493 This functionality may be useful for floor chairs or floor 2494 participants interested in the display name and the URI of a 2495 particular floor participant. In addition, a floor participant may 2496 find it useful to request information about itself. For example, a 2497 floor participant, after experiencing connectivity problems (e.g., 2498 its TCP connection with the floor control server was down for a while 2499 and eventually was re-established), may need to request information 2500 about all the floor requests associated to itself that still exist. 2502 12.3.1. Sending a UserQuery Message 2504 The ABNF in Section 5.3.5 describes the attributes that a UserQuery 2505 message can contain. In addition, the ABNF specifies normatively 2506 which of these attributes are mandatory, and which ones are optional. 2508 The client sets the Conference ID and the Transaction ID in the 2509 common header following the rules given in Section 8.1. The client 2510 sets the User ID in the common header to the client's identifier. 2511 This User ID will be used by the floor control server to authenticate 2512 and authorize the request. 2514 If the floor participant the client is requesting information about 2515 is not the client issuing the UserQuery message (which is identified 2516 by the User ID in the common header of the message), the client MUST 2517 insert a BENEFICIARY-ID attribute. 2519 12.3.2. Receiving a Response 2521 A message from the floor control server is considered a response to 2522 the UserQuery message if the message from the floor control server 2523 has the same Conference ID, Transaction ID, and User ID as the 2524 UserQuery message, as described in Section 8.1. On receiving such a 2525 response, the client follows the rules in Section 9 that relate to 2526 floor control server authentication. 2528 If the response is a UserStatus message, the client obtains 2529 information about the floor participant in a BENEFICIARY-INFORMATION 2530 grouped attribute and about the status of the floor requests 2531 associated with the floor participant in FLOOR-REQUEST-INFORMATION 2532 attributes. 2534 If the response is an Error message, the floor control server could 2535 not process the UserQuery message for some reason, which is described 2536 in the Error message. 2538 12.4. Obtaining the Capabilities of a Floor Control Server 2540 A client that wishes to obtain the capabilities of a floor control 2541 server does so by sending a Hello message to the floor control 2542 server. 2544 12.4.1. Sending a Hello Message 2546 The ABNF in Section 5.3.11 describes the attributes that a Hello 2547 message can contain. In addition, the ABNF specifies normatively 2548 which of these attributes are mandatory, and which ones are optional. 2550 The client sets the Conference ID and the Transaction ID in the 2551 common header following the rules given in Section 8.1. The client 2552 sets the User ID in the common header to the client's identifier. 2553 This User ID will be used by the floor control server to authenticate 2554 and authorize the request. 2556 12.4.2. Receiving Responses 2558 A message from the floor control server is considered a response to 2559 the Hello message by the client if the message from the floor control 2560 server has the same Conference ID, Transaction ID, and User ID as the 2561 Hello message, as described in Section 8.1. On receiving such a 2562 response, the client follows the rules in Section 9 that relate to 2563 floor control server authentication. 2565 If the response is a HelloAck message, the floor control server could 2566 process the Hello message successfully. The SUPPORTED-PRIMITIVES and 2567 SUPPORTED-ATTRIBUTES attributes indicate which primitives and 2568 attributes, respectively, are supported by the server. 2570 If the response is an Error message, the floor control server could 2571 not process the Hello message for some reason, which is described in 2572 the Error message. 2574 13. Floor Control Server Operations 2576 This section specifies how floor control servers can perform 2577 different operations, such as granting a floor, using the protocol 2578 elements described in earlier sections. 2580 On reception of a message from a client, the floor control server 2581 MUST check whether the value of the Primitive is supported. If it is 2582 not, the floor control server SHOULD send an Error message, as 2583 described in Section 13.8, with Error code 3 (Unknown Primitive). 2585 On reception of a message from a client, the floor control server 2586 MUST check whether the value of the Conference ID matched an existing 2587 conference. If it does not, the floor control server SHOULD send an 2588 Error message, as described in Section 13.8, with Error code 1 2589 (Conference does not Exist). 2591 On reception of a message from a client, the floor control server 2592 follows the rules in Section 9 that relate to the authentication of 2593 the message. 2595 On reception of a message from a client, the floor control server 2596 MUST check whether it understands all the mandatory ('M' bit set) 2597 attributes in the message. If the floor control server does not 2598 understand all of them, the floor control server SHOULD send an Error 2599 message, as described in Section 13.8, with Error code 4 (Unknown 2600 Mandatory Attribute). The Error message SHOULD list the attributes 2601 that were not understood. 2603 13.1. Reception of a FloorRequest Message 2605 On reception of a FloorRequest message, the floor control server 2606 follows the rules in Section 9 that relate to client authentication 2607 and authorization. If while processing the FloorRequest message, the 2608 floor control server encounters an error, it SHOULD generate an Error 2609 response following the procedures described in Section 13.8. 2611 BFCP allows floor participants to have several ongoing floor 2612 requests for the same floor (e.g., the same floor participant can 2613 occupy more than one position in a queue at the same time). A 2614 floor control server that only supports a certain number of 2615 ongoing floor requests per floor participant (e.g., one) can use 2616 Error Code 8 (You have Already Reached the Maximum Number of 2617 Ongoing Floor Requests for this Floor) to inform the floor 2618 participant. 2620 When communicating over unreliable transport and upon receiving a 2621 FloorRequest from a participant, the floor control server MUST 2622 respond with a FloorRequestStatus message within the transaction 2623 failure window to complete the transaction. 2625 13.1.1. Generating the First FloorRequestStatus Message 2627 The successful processing of a FloorRequest message by a floor 2628 control server involves generating one or several FloorRequestStatus 2629 messages, the first of which SHOULD be generated as soon as possible. 2631 If the floor control server cannot accept, grant, or deny the floor 2632 request right away (e.g., a decision from a chair is needed), it 2633 SHOULD use a Request Status value of Pending in the OVERALL-REQUEST- 2634 STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped 2635 attribute) of the first FloorRequestStatus message it generates. 2637 The policy that a floor control server follows to grant or deny 2638 floors is outside the scope of this document. A given floor 2639 control server may perform these decisions automatically while 2640 another may contact a human acting as a chair every time a 2641 decision needs to be made. 2643 The floor control server MUST copy the Conference ID, the Transaction 2644 ID, and the User ID from the FloorRequest into the 2645 FloorRequestStatus, as described in Section 8.2. Additionally, the 2646 floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 2647 attribute to the FloorRequestStatus. The attributes contained in 2648 this grouped attribute carry information about the floor request. 2650 The floor control server MUST assign an identifier that is unique 2651 within the conference to this floor request, and MUST insert it in 2652 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 2653 attribute. This identifier will be used by the floor participant (or 2654 by a chair or chairs) to refer to this specific floor request in the 2655 future. 2657 The floor control server MUST copy the Floor IDs in the FLOOR-ID 2658 attributes of the FloorRequest into the FLOOR-REQUEST-STATUS 2659 attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These 2660 Floor IDs identify the floors being requested (i.e., the floors 2661 associated with this particular floor request). 2663 The floor control server SHOULD copy (if present) the contents of the 2664 BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY- 2665 INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped 2666 attribute. Additionally, the floor control server MAY provide the 2667 display name and the URI of the beneficiary in this BENEFICIARY- 2668 INFORMATION attribute. 2670 The floor control server MAY provide information about the requester 2671 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2672 FLOOR-REQUEST-INFORMATION grouped attribute. 2674 The floor control server MAY copy (if present) the PRIORITY attribute 2675 from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped 2676 attribute. 2678 Note that this attribute carries the priority requested by the 2679 participant. The priority that the floor control server assigns 2680 to the floor request depends on the priority requested by the 2681 participant and the rights the participant has according to the 2682 policy of the conference. For example, a participant that is only 2683 allowed to use the Normal priority may request Highest priority 2684 for a floor request. In that case, the floor control server would 2685 ignore the priority requested by the participant. 2687 The floor control server MAY copy (if present) the PARTICIPANT- 2688 PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST- 2689 INFORMATION grouped attribute. 2691 13.1.2. Generation of Subsequent FloorRequestStatus Messages 2693 A floor request is considered to be ongoing as long as it is not in 2694 the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST- 2695 STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped 2696 attribute) of the first FloorRequestStatus message generated by the 2697 floor control server did not indicate any of these states, the floor 2698 control server will need to send subsequent FloorRequestStatus 2699 messages. 2701 When the status of the floor request changes, the floor control 2702 server SHOULD send new FloorRequestStatus messages with the 2703 appropriate Request Status. The floor control server MUST add a 2704 FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to 2705 the one sent in the first FloorRequestStatus message to any new 2706 FloorRequestStatus related to the same floor request. (The Floor 2707 Request ID identifies the floor request to which the 2708 FloorRequestStatus applies.) 2710 When using BFCP over reliable transports, the floor control server 2711 MUST set the Transaction ID of subsequent FloorRequestStatus messages 2712 to 0. When using BFCP over unreliable transports, the Transaction ID 2713 MUST be non-zero and unique in the context of outstanding 2714 transactions over unreliable transports as described in Section 8. 2716 The rate at which the floor control server sends 2717 FloorRequestStatus messages is a matter of local policy. A floor 2718 control server may choose to send a new FloorRequestStatus message 2719 every time the floor request moves in the floor request queue, 2720 while another may choose only to send a new FloorRequestStatus 2721 message when the floor request is Granted or Denied. 2723 The floor control server may add a STATUS-INFO attribute to any of 2724 the FloorRequestStatus messages it generates to provide extra 2725 information about its decisions regarding the floor request (e.g., 2726 why it was denied). 2728 Floor participants and floor chairs may request to be informed 2729 about the status of a floor following the procedures in 2730 Section 12.1. If the processing of a floor request changes the 2731 status of a floor (e.g., the floor request is granted and 2732 consequently the floor has a new holder), the floor control server 2733 needs to follow the procedures in Section 13.5 to inform the 2734 clients that have requested that information. 2736 The common header and the rest of the attributes are the same as in 2737 the first FloorRequestStatus message. 2739 The floor control server can discard the state information about a 2740 particular floor request when this reaches a status of Cancelled, 2741 Released, or Revoked. 2743 When communicating over unreliable transport and a 2744 FloorRequestStatusAck message is not received within the transaction 2745 failure window, the floor control server MUST retransmit the 2746 FloorRequestStatus message according to Section 6.2. 2748 13.2. Reception of a FloorRequestQuery Message 2750 On reception of a FloorRequestQuery message, the floor control server 2751 follows the rules in Section 9 that relate to client authentication 2752 and authorization. If while processing the FloorRequestQuery 2753 message, the floor control server encounters an error, it SHOULD 2754 generate an Error response following the procedures described in 2755 Section 13.8. 2757 The successful processing of a FloorRequestQuery message by a floor 2758 control server involves generating a FloorRequestStatus message, 2759 which SHOULD be generated as soon as possible. 2761 When communicating over unreliable transport and upon receiving a 2762 FloorRequestQuery from a participant, the floor control server MUST 2763 respond with a FloorRequestStatus message within the transaction 2764 failure window to complete the transaction. 2766 The floor control server MUST copy the Conference ID, the Transaction 2767 ID, and the User ID from the FloorRequestQuery message into the 2768 FloorRequestStatus message, as described in Section 8.2. 2769 Additionally, the floor control server MUST include information about 2770 the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute 2771 to the FloorRequestStatus. 2773 The floor control server MUST copy the contents of the 2774 FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into 2775 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 2776 attribute. 2778 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 2779 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2780 floors being requested (i.e., the floors associated with the floor 2781 request identified by the FLOOR-REQUEST-ID attribute). 2783 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2784 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2785 beneficiary of the floor request. Additionally, the floor control 2786 server MAY provide the display name and the URI of the beneficiary in 2787 this BENEFICIARY-INFORMATION attribute. 2789 The floor control server MAY provide information about the requester 2790 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2791 FLOOR-REQUEST-INFORMATION grouped attribute. 2793 The floor control server MAY provide the reason why the floor 2794 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2796 The floor control server MAY also add to the FLOOR-REQUEST- 2797 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2798 value requested for the floor request and a STATUS-INFO attribute 2799 with extra information about the floor request. 2801 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 2802 to the FLOOR-REQUEST-INFORMATION grouped attribute with the current 2803 status of the floor request. The floor control server MAY provide 2804 information about the status of the floor request as it relates to 2805 each of the floors being requested in the FLOOR-REQUEST-STATUS 2806 attributes. 2808 13.3. Reception of a UserQuery Message 2810 On reception of a UserQuery message, the floor control server follows 2811 the rules in Section 9 that relate to client authentication and 2812 authorization. If while processing the UserQuery message, the floor 2813 control server encounters an error, it SHOULD generate an Error 2814 response following the procedures described in Section 13.8. 2816 The successful processing of a UserQuery message by a floor control 2817 server involves generating a UserStatus message, which SHOULD be 2818 generated as soon as possible. 2820 When communicating over unreliable transport and upon receiving a 2821 UserQuery from a participant, the floor control server MUST respond 2822 with a UserStatus message within the transaction failure window to 2823 complete the transaction. 2825 The floor control server MUST copy the Conference ID, the Transaction 2826 ID, and the User ID from the UserQuery message into the USerStatus 2827 message, as described in Section 8.2. 2829 The sender of the UserQuery message is requesting information about 2830 all the floor requests associated with a given participant (i.e., the 2831 floor requests where the participant is either the beneficiary or the 2832 requester). This participant is identified by a BENEFICIARY-ID 2833 attribute or, in the absence of a BENEFICIARY-ID attribute, by a the 2834 User ID in the common header of the UserQuery message. 2836 The floor control server MUST copy, if present, the contents of the 2837 BENEFICIARY-ID attribute from the UserQuery message into a 2838 BENEFICIARY-INFORMATION attribute in the UserStatus message. 2839 Additionally, the floor control server MAY provide the display name 2840 and the URI of the participant about which the UserStatus message 2841 provides information in this BENEFICIARY-INFORMATION attribute. 2843 The floor control server SHOULD add to the UserStatus message a 2844 FLOOR-REQUEST-INFORMATION grouped attribute for each floor request 2845 related to the participant about which the message provides 2846 information (i.e., the floor requests where the participant is either 2847 the beneficiary or the requester). For each FLOOR-REQUEST- 2848 INFORMATION attribute, the floor control server follows the following 2849 steps. 2851 The floor control server MUST identify the floor request the FLOOR- 2852 REQUEST-INFORMATION attribute applies to by filling the Floor Request 2853 ID field of the FLOOR-REQUEST-INFORMATION attribute. 2855 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 2856 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2857 floors being requested (i.e., the floors associated with the floor 2858 request identified by the FLOOR-REQUEST-ID attribute). 2860 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2861 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2862 beneficiary of the floor request. Additionally, the floor control 2863 server MAY provide the display name and the URI of the beneficiary in 2864 this BENEFICIARY-INFORMATION attribute. 2866 The floor control server MAY provide information about the requester 2867 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2868 FLOOR-REQUEST-INFORMATION grouped attribute. 2870 The floor control server MAY provide the reason why the floor 2871 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2873 The floor control server MAY also add to the FLOOR-REQUEST- 2874 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2875 value requested for the floor request. 2877 The floor control server MUST include the current status of the floor 2878 request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST- 2879 INFORMATION grouped attribute. The floor control server MAY add a 2880 STATUS-INFO attribute with extra information about the floor request. 2882 The floor control server MAY provide information about the status of 2883 the floor request as it relates to each of the floors being requested 2884 in the FLOOR-REQUEST-STATUS attributes. 2886 13.4. Reception of a FloorRelease Message 2888 On reception of a FloorRelease message, the floor control server 2889 follows the rules in Section 9 that relate to client authentication 2890 and authorization. If while processing the FloorRelease message, the 2891 floor control server encounters an error, it SHOULD generate an Error 2892 response following the procedures described in Section 13.8. 2894 The successful processing of a FloorRelease message by a floor 2895 control server involves generating a FloorRequestStatus message, 2896 which SHOULD be generated as soon as possible. 2898 When communicating over unreliable transport and upon receiving a 2899 FloorRelease from a participant, the floor control server MUST 2900 respond with a FloorRequestStatus message within the transaction 2901 failure window to complete the transaction. 2903 The floor control server MUST copy the Conference ID, the Transaction 2904 ID, and the User ID from the FloorRelease message into the 2905 FloorRequestStatus message, as described in Section 8.2. 2907 The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 2908 attribute to the FloorRequestStatus. The attributes contained in 2909 this grouped attribute carry information about the floor request. 2911 The FloorRelease message identifies the floor request it applies to 2912 using a FLOOR-REQUEST-ID. The floor control server MUST copy the 2913 contents of the FLOOR-REQUEST-ID attribute from the FloorRelease 2914 message into the Floor Request ID field of the FLOOR-REQUEST- 2915 INFORMATION attribute. 2917 The floor control server MUST identify the floors being released 2918 (i.e., the floors associated with the floor request identified by the 2919 FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the 2920 FLOOR-REQUEST-INFORMATION grouped attribute. 2922 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 2923 to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request 2924 Status value SHOULD be Released, if the floor (or floors) had been 2925 previously granted, or Cancelled, if the floor (or floors) had not 2926 been previously granted. The floor control server MAY add a STATUS- 2927 INFO attribute with extra information about the floor request. 2929 13.5. Reception of a FloorQuery Message 2931 On reception of a FloorQuery message, the floor control server 2932 follows the rules in Section 9 that relate to client authentication. 2933 If while processing the FloorQuery message, the floor control server 2934 encounters an error, it SHOULD generate an Error response following 2935 the procedures described in Section 13.8. 2937 When communicating over unreliable transport and upon receiving a 2938 FloorQuery from a participant, the floor control server MUST respond 2939 with a FloorStatus message within the transaction failure window to 2940 complete the transaction. 2942 A floor control server receiving a FloorQuery message from a client 2943 SHOULD keep this client informed about the status of the floors 2944 identified by FLOOR-ID attributes in the FloorQuery message. Floor 2945 Control Servers keep clients informed by using FloorStatus messages. 2947 An individual FloorStatus message carries information about a single 2948 floor. So, when a FloorQuery message requests information about more 2949 than one floor, the floor control server needs to send separate 2950 FloorStatus messages for different floors. 2952 The information FloorQuery messages carry may depend on the user 2953 requesting the information. For example, a chair may be able to 2954 receive information about pending requests, while a regular user may 2955 not be authorized to do so. 2957 13.5.1. Generation of the First FloorStatus Message 2959 The successful processing of a FloorQuery message by a floor control 2960 server involves generating one or several FloorStatus messages, the 2961 first of which SHOULD be generated as soon as possible. 2963 The floor control server MUST copy the Conference ID, the Transaction 2964 ID, and the User ID from the FloorQuery message into the FloorStatus 2965 message, as described in Section 8.2. 2967 If the FloorQuery message did not contain any FLOOR-ID attribute, the 2968 floor control server sends the FloorStatus message without adding any 2969 additional attribute and does not send any subsequent FloorStatus 2970 message to the floor participant. 2972 If the FloorQuery message contained one or more FLOOR-ID attributes, 2973 the floor control server chooses one from among them and adds this 2974 FLOOR-ID attribute to the FloorStatus message. The floor control 2975 server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for 2976 each floor request associated to the floor. Each FLOOR-REQUEST- 2977 INFORMATION grouped attribute contains a number of attributes that 2978 provide information about the floor request. For each FLOOR-REQUEST- 2979 INFORMATION attribute, the floor control server follows the following 2980 steps. 2982 The floor control server MUST identify the floor request the FLOOR- 2983 REQUEST-INFORMATION attribute applies to by filling the Floor Request 2984 ID field of the FLOOR-REQUEST-INFORMATION attribute. 2986 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to 2987 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2988 floors being requested (i.e., the floors associated with the floor 2989 request identified by the FLOOR-REQUEST-ID attribute). 2991 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2992 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2993 beneficiary of the floor request. Additionally, the floor control 2994 server MAY provide the display name and the URI of the beneficiary in 2995 this BENEFICIARY-INFORMATION attribute. 2997 The floor control server MAY provide information about the requester 2998 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2999 FLOOR-REQUEST-INFORMATION grouped attribute. 3001 The floor control server MAY provide the reason why the floor 3002 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 3004 The floor control server MAY also add to the FLOOR-REQUEST- 3005 INFORMATION grouped attribute a PRIORITY attribute with the Priority 3006 value requested for the floor request. 3008 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute 3009 to the FLOOR-REQUEST-INFORMATION grouped attribute with the current 3010 status of the floor request. The floor control server MAY add a 3011 STATUS-INFO attribute with extra information about the floor request. 3013 The floor control server MAY provide information about the status of 3014 the floor request as it relates to each of the floors being requested 3015 in the FLOOR-REQUEST-STATUS attributes. 3017 13.5.2. Generation of Subsequent FloorStatus Messages 3019 If the FloorQuery message carried more than one FLOOR-ID attribute, 3020 the floor control server SHOULD generate a FloorStatus message for 3021 each of them (except for the FLOOR-ID attribute chosen for the first 3022 FloorStatus message) as soon as possible. These FloorStatus messages 3023 are generated following the same rules as those for the first 3024 FloorStatus message (see Section 13.5.1), but their Transaction ID is 3025 0 when using reliable transports and non-zero and unique in the 3026 context of outstanding transactions when using unreliable transports 3027 (cf. Section 8). 3029 After generating these messages, the floor control server sends 3030 FloorStatus messages, periodically keeping the client informed about 3031 all the floors for which the client requested information. The 3032 Transaction ID of these messages MUST be 0 when using reliable 3033 transports and non-zero and unique in the context of outstanding 3034 transactions when using unreliable transports (cf. Section 8). 3036 The rate at which the floor control server sends FloorStatus 3037 messages is a matter of local policy. A floor control server may 3038 choose to send a new FloorStatus message every time a new floor 3039 request arrives, while another may choose to only send a new 3040 FloorStatus message when a new floor request is Granted. 3042 When communicating over unreliable transport and a FloorStatusAck 3043 message is not received within the transaction failure window, the 3044 floor control server MUST retransmit the FloorStatus message 3045 according to Section 6.2. 3047 13.6. Reception of a ChairAction Message 3049 On reception of a ChairAction message, the floor control server 3050 follows the rules in Section 9 that relate to client authentication 3051 and authorization. If while processing the ChairAction message, the 3052 floor control server encounters an error, it SHOULD generate an Error 3053 response following the procedures described in Section 13.8. 3055 The successful processing of a ChairAction message by a floor control 3056 server involves generating a ChairActionAck message, which SHOULD be 3057 generated as soon as possible. 3059 When communicating over unreliable transport and upon receiving a 3060 ChairAction from a chair, the floor control server MUST respond with 3061 a ChairActionAck message within the transaction failure window to 3062 complete the transaction. 3064 The floor control server MUST copy the Conference ID, the Transaction 3065 ID, and the User ID from the ChairAction message into the 3066 ChairActionAck message, as described in Section 8.2. 3068 The floor control server needs to take into consideration the 3069 operation requested in the ChairAction message (e.g., granting a 3070 floor) but does not necessarily need to perform it as requested by 3071 the floor chair. The operation that the floor control server 3072 performs depends on the ChairAction message and on the internal state 3073 of the floor control server. 3075 For example, a floor chair may send a ChairAction message granting a 3076 floor that was requested as part of an atomic floor request operation 3077 that involved several floors. Even if the chair responsible for one 3078 of the floors instructs the floor control server to grant the floor, 3079 the floor control server will not grant it until the chairs 3080 responsible for the other floors agree to grant them as well. 3082 So, the floor control server is ultimately responsible for keeping a 3083 coherent floor state using instructions from floor chairs as input to 3084 this state. 3086 If the new Status in the ChairAction message is Accepted and all the 3087 bits of the Queue Position field are zero, the floor chair is 3088 requesting that the floor control server assign a queue position 3089 (e.g., the last in the queue) to the floor request based on the local 3090 policy of the floor control server. (Of course, such a request only 3091 applies if the floor control server implements a queue.) 3093 13.7. Reception of a Hello Message 3095 On reception of a Hello message, the floor control server follows the 3096 rules in Section 9 that relate to client authentication. If while 3097 processing the Hello message, the floor control server encounters an 3098 error, it SHOULD generate an Error response following the procedures 3099 described in Section 13.8. 3101 When communicating over unreliable transport and upon receiving a 3102 Hello from a participant, the floor control server MUST respond with 3103 a HelloAck message within the transaction failure window to complete 3104 the transaction. 3106 The successful processing of a Hello message by a floor control 3107 server involves generating a HelloAck message, which SHOULD be 3108 generated as soon as possible. The floor control server MUST copy 3109 the Conference ID, the Transaction ID, and the User ID from the Hello 3110 into the HelloAck, as described in Section 8.2. 3112 The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to 3113 the HelloAck message listing all the primitives (i.e., BFCP messages) 3114 supported by the floor control server. 3116 The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to 3117 the HelloAck message listing all the attributes supported by the 3118 floor control server. 3120 13.8. Error Message Generation 3122 Error messages are always sent in response to a previous message from 3123 the client as part of a client-initiated transaction. The ABNF in 3124 Section 5.3.13 describes the attributes that an Error message can 3125 contain. In addition, the ABNF specifies normatively which of these 3126 attributes are mandatory and which ones are optional. 3128 The floor control server MUST copy the Conference ID, the Transaction 3129 ID, and the User ID from the message from the client into the Error 3130 message, as described in Section 8.2. 3132 The floor control server MUST add an ERROR-CODE attribute to the 3133 Error message. The ERROR-CODE attribute contains an Error Code from 3134 Table 5. Additionally, the floor control server may add an ERROR- 3135 INFO attribute with extra information about the error. 3137 14. Security Considerations 3139 BFCP uses TLS/DTLS to provide mutual authentication between clients 3140 and servers. TLS/DTLS also provides replay and integrity protection 3141 and confidentiality. It is RECOMMENDED that TLS/DTLS with non-null 3142 encryption always be used. BFCP entities MAY use other security 3143 mechanisms as long as they provide similar security properties. 3145 The remainder of this section analyzes some of the threats against 3146 BFCP and how they are addressed. 3148 An attacker may attempt to impersonate a client (a floor participant 3149 or a floor chair) in order to generate forged floor requests or to 3150 grant or deny existing floor requests. Client impersonation is 3151 avoided by having servers only accept BFCP messages over 3152 authenticated TLS/DTLS connections. The floor control server assumes 3153 that attackers cannot highjack the TLS/DTLS connection and, 3154 therefore, that messages over the TLS/DTLS connection come from the 3155 client that was initially authenticated. 3157 An attacker may attempt to impersonate a floor control server. A 3158 successful attacker would be able to make clients think that they 3159 hold a particular floor so that they would try to access a resource 3160 (e.g., sending media) without having legitimate rights to access it. 3161 Floor control server impersonation is avoided by having servers only 3162 accept BFCP messages over authenticated TLS/DTLS connections, as well 3163 as ensuring clients only send and accept messages over authenticated 3164 TLS/DTLS connections. 3166 Attackers may attempt to modify messages exchanged by a client and a 3167 floor control server. The integrity protection provided by TLS/DTLS 3168 connections prevents this attack. 3170 An attacker may attempt to fetch a valid message sent by a client to 3171 a floor control server and replay it over a connection between the 3172 attacker and the floor control server. This attack is prevented by 3173 having floor control servers check that messages arriving over a 3174 given authenticated TLS/DTLS connection use an authorized user ID 3175 (i.e., a user ID that the user that established the authenticated 3176 TLS/DTLS connection is allowed to use). 3178 Attackers may attempt to pick messages from the network to get access 3179 to confidential information between the floor control server and a 3180 client (e.g., why a floor request was denied). TLS/DTLS 3181 confidentiality prevents this attack. Therefore, it is RECOMMENDED 3182 that TLS/DTLS be used with a non-null encryption algorithm. 3184 15. IANA Considerations 3186 [Editorial note: This section instructs the IANA to register new 3187 entries in the BFCP Primitive subregistry in Section 15.2 and for 3188 the BFCP Error Code subregistry in Section 15.4.] 3190 The IANA has created a registry for BFCP parameters called "Binary 3191 Floor Control Protocol (BFCP) Parameters". This registry has a 3192 number of subregistries, which are described in the following 3193 sections. 3195 15.1. Attribute Subregistry 3197 This section establishes the Attribute subregistry under the BFCP 3198 Parameters registry. As per the terminology in RFC 5226 [3], the 3199 registration policy for BFCP attributes shall be "Specification 3200 Required". For the purposes of this subregistry, the BFCP attributes 3201 for which IANA registration is requested MUST be defined by a 3202 standards-track RFC. Such an RFC MUST specify the attribute's type, 3203 name, format, and semantics. 3205 For each BFCP attribute, the IANA registers its type, its name, and 3206 the reference to the RFC where the attribute is defined. The 3207 following table contains the initial values of this subregistry. 3209 +------+---------------------------+------------+ 3210 | Type | Attribute | Reference | 3211 +------+---------------------------+------------+ 3212 | 1 | BENEFICIARY-ID | [RFC XXXX] | 3213 | 2 | FLOOR-ID | [RFC XXXX] | 3214 | 3 | FLOOR-REQUEST-ID | [RFC XXXX] | 3215 | 4 | PRIORITY | [RFC XXXX] | 3216 | 5 | REQUEST-STATUS | [RFC XXXX] | 3217 | 6 | ERROR-CODE | [RFC XXXX] | 3218 | 7 | ERROR-INFO | [RFC XXXX] | 3219 | 8 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] | 3220 | 9 | STATUS-INFO | [RFC XXXX] | 3221 | 10 | SUPPORTED-ATTRIBUTES | [RFC XXXX] | 3222 | 11 | SUPPORTED-PRIMITIVES | [RFC XXXX] | 3223 | 12 | USER-DISPLAY-NAME | [RFC XXXX] | 3224 | 13 | USER-URI | [RFC XXXX] | 3225 | 14 | BENEFICIARY-INFORMATION | [RFC XXXX] | 3226 | 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] | 3227 | 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] | 3228 | 17 | FLOOR-REQUEST-STATUS | [RFC XXXX] | 3229 | 18 | OVERALL-REQUEST-STATUS | [RFC XXXX] | 3230 +------+---------------------------+------------+ 3232 Table 7: Initial values of the BFCP Attribute subregistry 3234 15.2. Primitive Subregistry 3236 [Editorial note: This section instructs the IANA to register the 3237 following new values for the BFCP Primitive subregistry: 3238 FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.] 3240 This section establishes the Primitive subregistry under the BFCP 3241 Parameters registry. As per the terminology in RFC 5226 [3], the 3242 registration policy for BFCP primitives shall be "Specification 3243 Required". For the purposes of this subregistry, the BFCP primitives 3244 for which IANA registration is requested MUST be defined by a 3245 standards-track RFC. Such an RFC MUST specify the primitive's value, 3246 name, format, and semantics. 3248 For each BFCP primitive, the IANA registers its value, its name, and 3249 the reference to the RFC where the primitive is defined. The 3250 following table contains the initial values of this subregistry. 3252 +-------+-----------------------+------------+ 3253 | Value | Primitive | Reference | 3254 +-------+-----------------------+------------+ 3255 | 1 | FloorRequest | [RFC XXXX] | 3256 | 2 | FloorRelease | [RFC XXXX] | 3257 | 3 | FloorRequestQuery | [RFC XXXX] | 3258 | 4 | FloorRequestStatus | [RFC XXXX] | 3259 | 5 | UserQuery | [RFC XXXX] | 3260 | 6 | UserStatus | [RFC XXXX] | 3261 | 7 | FloorQuery | [RFC XXXX] | 3262 | 8 | FloorStatus | [RFC XXXX] | 3263 | 9 | ChairAction | [RFC XXXX] | 3264 | 10 | ChairActionAck | [RFC XXXX] | 3265 | 11 | Hello | [RFC XXXX] | 3266 | 12 | HelloAck | [RFC XXXX] | 3267 | 13 | Error | [RFC XXXX] | 3268 | 14 | FloorRequestStatusAck | [RFC XXXX] | 3269 | 15 | FloorStatusAck | [RFC XXXX] | 3270 | 16 | Goodbye | [RFC XXXX] | 3271 | 17 | GoodbyeAck | [RFC XXXX] | 3272 +-------+-----------------------+------------+ 3274 Table 8: Initial values of the BFCP primitive subregistry 3276 15.3. Request Status Subregistry 3278 This section establishes the Request Status subregistry under the 3279 BFCP Parameters registry. As per the terminology in RFC 5226 [3], 3280 the registration policy for BFCP request status shall be 3281 "Specification Required". For the purposes of this subregistry, the 3282 BFCP request status for which IANA registration is requested MUST be 3283 defined by a standards-track RFC. Such an RFC MUST specify the value 3284 and the semantics of the request status. 3286 For each BFCP request status, the IANA registers its value, its 3287 meaning, and the reference to the RFC where the request status is 3288 defined. The following table contains the initial values of this 3289 subregistry. 3291 +-------+-----------+------------+ 3292 | Value | Status | Reference | 3293 +-------+-----------+------------+ 3294 | 1 | Pending | [RFC XXXX] | 3295 | 2 | Accepted | [RFC XXXX] | 3296 | 3 | Granted | [RFC XXXX] | 3297 | 4 | Denied | [RFC XXXX] | 3298 | 5 | Cancelled | [RFC XXXX] | 3299 | 6 | Released | [RFC XXXX] | 3300 | 7 | Revoked | [RFC XXXX] | 3301 +-------+-----------+------------+ 3303 Table 9: Initial values of the Request Status subregistry 3305 15.4. Error Code Subregistry 3307 [Editorial note: This section instructs the IANA to register the 3308 following new values for the BFCP Error Code subregistry: 10, 11, 3309 12, 13 and 14.] 3311 This section establishes the Error Code subregistry under the BFCP 3312 Parameters registry. As per the terminology in RFC 5226 [3], the 3313 registration policy for BFCP error codes shall be "Specification 3314 Required". For the purposes of this subregistry, the BFCP error 3315 codes for which IANA registration is requested MUST be defined by a 3316 standards-track RFC. Such an RFC MUST specify the value and the 3317 semantics of the error code, and any Error Specific Details that 3318 apply to it. 3320 For each BFCP primitive, the IANA registers its value, its meaning, 3321 and the reference to the RFC where the primitive is defined. The 3322 following table contains the initial values of this subregistry. 3324 +-------+--------------------------------------+------------+ 3325 | Value | Meaning | Reference | 3326 +-------+--------------------------------------+------------+ 3327 | 1 | Conference does not Exist | [RFC XXXX] | 3328 | 2 | User does not Exist | [RFC XXXX] | 3329 | 3 | Unknown Primitive | [RFC XXXX] | 3330 | 4 | Unknown Mandatory Attribute | [RFC XXXX] | 3331 | 5 | Unauthorized Operation | [RFC XXXX] | 3332 | 6 | Invalid Floor ID | [RFC XXXX] | 3333 | 7 | Floor Request ID Does Not Exist | [RFC XXXX] | 3334 | 8 | You have Already Reached the Maximum | [RFC XXXX] | 3335 | | Number of Ongoing Floor Requests for | | 3336 | | this Floor | | 3337 | 9 | Use TLS | [RFC XXXX] | 3338 | 10 | Unable to parse message | [RFC XXXX] | 3339 | 11 | Use DTLS | [RFC XXXX] | 3340 | 12 | Unsupported Version | [RFC XXXX] | 3341 | 13 | Incorrect Message Length | [RFC XXXX] | 3342 | 14 | Generic Error | [RFC XXXX] | 3343 +-------+--------------------------------------+------------+ 3345 Table 10: Initial Values of the Error Code subregistry 3347 16. Changes from RFC 4582 3349 Following is the list of technical changes and other non-trivial 3350 fixes from [17]. 3352 Main purpose of this work was to revise the specification to support 3353 BFCP over unreliable transport, resulting in the following changes: 3355 Overview of Operation (Section 4): 3356 Expand the description of client-initiated and server-initiated 3357 transactions. 3359 COMMON-HEADER Format (Section 5.1): 3360 Ver(sion) field, where the value 2 is used for the extensions 3361 for unreliable transport. Added new R and F flag-bits for 3362 unreliable transport. Res(erved) field is now 3 bit. New 3363 optional Fragment Offset and Fragment Length fields. 3365 New primitives (Section 5.1): 3366 Added five new primitives: FloorRequestStatusAck, 3367 FloorStatusAck, Goodbye, and GoodbyeAck. 3369 New error codes (Section 5.2.6): 3370 Added three new error codes: "Unable to Parse Message", "Use 3371 DTLS" and "Unsupported Version". 3373 ABNF for new primitives (Section 5.3): 3374 New subsections with normative ABNF for the new primitives. 3376 Transport split in two (Section 6): 3377 Section 6 specifying the transport was split in two 3378 subsections; Section 6.1 for reliable transport and Section 6.2 3379 for unreliable transport. Where the specification for 3380 unreliable transport amongst other issues deals with 3381 reliability, congestion control, fragmentation and ICMP. 3383 Mandate DTLS (Section 7 and Section 9): 3384 Mandate DTLS support when transport over UDP is used. 3386 Transaction changes (Section 8): 3387 Server-initiated transactions over unreliable transport has 3388 non-zero and unique Transaction ID. Over unreliable transport, 3389 the retransmit timers T1 and T2 described in Section 8.3 3390 applies. 3392 Requiring timely response (Section 10.1.2, Section 10.2.2, 3393 Section 11.2, Section 12.1.2, Section 12.2.2, Section 12.3.2, 3394 Section 12.4.2, Section 10.1.3 and Section 12.1.3): 3395 Describing that a given response must be sent within the 3396 transaction failure window to complete the transaction. 3398 Updated IANA Considerations (Section 15): 3399 Added the new primitives and error codes to Section 15.2 and 3400 Section 15.4 respectively. 3402 Examples over unreliable transport (Appendix A): 3403 Added sample interactions over unreliable transport for the 3404 scenarios in Figure 2 and Figure 3 3406 Motivation for unreliable transport (Appendix B): 3407 Introduction to and motivation for extending BFCP to support 3408 unreliable transport. 3410 The clarification and bug fixes: 3412 ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>, 3413 Figure 28, Figure 30, and the ABNF figures in Section 5.3): 3414 Although formally correct in [17], the notation has changed in a 3415 number of Figures to an equivalent form for clarity, e.g. 3416 s/*1(FLOOR-ID)/[FLOOR-ID]/ in Figure 38 and s/*[XXX]/*(XXX)/ in 3417 the other figures. 3419 Typo (Section 12.4.2): 3420 Change from SUPPORTED-PRIMITIVES to SUPPORTED-PRIMITVIES in the 3421 second paragraph. 3423 Corrected attribute type (Section 13.1.1): 3424 Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in 3425 the eighth paragraph, since the note below describes priority and 3426 that the last paragraph deals with PARTICIPANT-PROVIDED-INFO. 3428 New error codes (Section 5.2.6): 3429 Added two additional error codes: "Incorrect Message Length" and 3430 "Generic Error". 3432 17. Acknowledgements 3434 The XCON WG chairs, Adam Roach and Alan Johnston, provided useful 3435 ideas for RFC 4582 [17]. Additionally, Xiaotao Wu, Paul Kyzivat, 3436 Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben 3437 Campbell, Dave Morgan, and Oscar Novo provided useful comments during 3438 the work with RFC 4582. The authors also acknowledge contributions 3439 to the revision of BFCP for use over an unreliable transport from 3440 Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad, 3441 Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, 3442 Joerg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, 3443 Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman, 3444 Vijaya Mandava and Alan Ford. In the final phase Erns Horvath did a 3445 thorough review revealing issues that needed clarification and 3446 changes. 3448 18. References 3450 18.1. Normative References 3452 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3453 Levels", BCP 14, RFC 2119, March 1997. 3455 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 3456 Specifications: ABNF", STD 68, RFC 5234, January 2008. 3458 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3459 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 3461 [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 3462 Protocol Version 1.2", RFC 5246, August 2008. 3464 [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3465 Security Version 1.2", RFC 6347, January 2012. 3467 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 3468 STD 63, RFC 3629, November 2003. 3470 [7] Camarillo, G. and T. Kristensen, Ed., "Session Description 3471 Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) 3472 Streams", draft-ietf-bfcpbis-rfc4583bis-02 (work in progress), 3473 July 2012. 3475 [8] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for 3476 Establishing a Secure Real-time Transport Protocol (SRTP) 3477 Security Context Using Datagram Transport Layer Security 3478 (DTLS)", RFC 5763, May 2010. 3480 [9] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 3481 BCP 131, RFC 4961, July 2007. 3483 [10] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 3484 Initiated Connections in the Session Initiation Protocol 3485 (SIP)", RFC 5626, October 2009. 3487 [11] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 3488 Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. 3490 18.2. Informational References 3492 [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 3493 Session Description Protocol (SDP)", RFC 3264, June 2002. 3495 [13] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, 3496 "Requirements for Floor Control Protocols", RFC 4376, 3497 February 2006. 3499 [14] Barnes, M., Boulton, C., and O. Levin, "A Framework for 3500 Centralized Conferencing", RFC 5239, June 2008. 3502 [15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 3503 Protocol for Network Address Translator (NAT) Traversal for 3504 Offer/Answer Protocols", RFC 5245, April 2010. 3506 [16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 3507 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 3508 Session Initiation Protocol", RFC 3261, June 2002. 3510 [17] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control 3511 Protocol (BFCP)", RFC 4582, November 2006. 3513 [18] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network 3514 Address Translations (NATs)", RFC 4380, February 2006. 3516 [19] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for 3517 Application Designers", BCP 145, RFC 5405, November 2008. 3519 [20] Thaler, D., "Teredo Extensions", RFC 6081, January 2011. 3521 [21] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 3522 September 2007. 3524 [22] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP 3525 Candidates with Interactive Connectivity Establishment (ICE)", 3526 RFC 6544, March 2012. 3528 [23] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling 3529 (GUT)", draft-manner-tsvwg-gut-02 (work in progress), 3530 July 2010. 3532 [24] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of 3533 Middlebox Interactions for Signaling Protocol Communication 3534 along the Media Path", 3535 draft-ietf-mmusic-media-path-middleboxes-04 (work in progress), 3536 January 2012. 3538 [25] Guha, S. and P. Francis, "Characterization and Measurement of 3539 TCP Traversal through NATs and Firewalls", 2005, 3540 . 3542 [26] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer 3543 Communication Across Network Address Translators", April 2005, 3544 . 3546 Appendix A. Example Call Flows for BFCP over Unreliable Transport 3548 With reference to Section 4.1, the following figures show 3549 representative call-flows for requesting and releasing a floor, and 3550 obtaining status information about a floor when BFCP is deployed over 3551 an unreliable transport. The figures here show a loss-less 3552 interaction. 3554 Floor Participant Floor Control 3555 Server 3556 |(1) FloorRequest | 3557 |Transaction ID: 123 | 3558 |User ID: 234 | 3559 |FLOOR-ID: 543 | 3560 |---------------------------------------------->| 3561 | | 3562 |(2) FloorRequestStatus | 3563 |Transaction ID: 123 | 3564 |User ID: 234 | 3565 |FLOOR-REQUEST-INFORMATION | 3566 | Floor Request ID: 789 | 3567 | OVERALL-REQUEST-STATUS | 3568 | Request Status: Pending | 3569 | FLOOR-REQUEST-STATUS | 3570 | Floor ID: 543 | 3571 |<----------------------------------------------| 3572 | | 3573 |(3) FloorRequestStatus | 3574 |Transaction ID: 4098 | 3575 |User ID: 234 | 3576 |FLOOR-REQUEST-INFORMATION | 3577 | Floor Request ID: 789 | 3578 | OVERALL-REQUEST-STATUS | 3579 | Request Status: Accepted | 3580 | Queue Position: 1st | 3581 | FLOOR-REQUEST-STATUS | 3582 | Floor ID: 543 | 3583 |<----------------------------------------------| 3584 | | 3585 |(4) FloorRequestStatusAck | 3586 |Transaction ID: 4098 | 3587 |User ID: 234 | 3588 |---------------------------------------------->| 3589 | | 3590 |(5) FloorRequestStatus | 3591 |Transaction ID: 4130 | 3592 |User ID: 234 | 3593 |FLOOR-REQUEST-INFORMATION | 3594 | Floor Request ID: 789 | 3595 | OVERALL-REQUEST-STATUS | 3596 | Request Status: Granted | 3597 | FLOOR-REQUEST-STATUS | 3598 | Floor ID: 543 | 3599 |<----------------------------------------------| 3600 | | 3601 |(6) FloorRequestStatusAck | 3602 |Transaction ID: 4130 | 3603 |User ID: 234 | 3604 |---------------------------------------------->| 3605 | | 3606 |(7) FloorRelease | 3607 |Transaction ID: 154 | 3608 |User ID: 234 | 3609 |FLOOR-REQUEST-ID: 789 | 3610 |---------------------------------------------->| 3611 | | 3612 |(8) FloorRequestStatus | 3613 |Transaction ID: 154 | 3614 |User ID: 234 | 3615 |FLOOR-REQUEST-INFORMATION | 3616 | Floor Request ID: 789 | 3617 | OVERALL-REQUEST-STATUS | 3618 | Request Status: Released | 3619 | FLOOR-REQUEST-STATUS | 3620 | Floor ID: 543 | 3621 |<----------------------------------------------| 3623 Figure 48: Requesting and releasing a floor 3625 Note that in Figure 48, the FloorRequestStatus message from the floor 3626 control server to the floor participant is a transaction-closing 3627 message as a response to the client-initiated transaction with 3628 Transaction ID 154. It does not and SHOULD NOT be followed by a 3629 FloorRequestStatusAck message from the floor participant to the floor 3630 control server. 3632 Floor Participant Floor Control 3633 Server 3634 |(1) FloorQuery | 3635 |Transaction ID: 257 | 3636 |User ID: 234 | 3637 |FLOOR-ID: 543 | 3638 |---------------------------------------------->| 3639 | | 3640 |(2) FloorStatus | 3641 |Transaction ID: 257 | 3642 |User ID: 234 | 3643 |FLOOR-ID:543 | 3644 |FLOOR-REQUEST-INFORMATION | 3645 | Floor Request ID: 764 | 3646 | OVERALL-REQUEST-STATUS | 3647 | Request Status: Accepted | 3648 | Queue Position: 1st | 3649 | FLOOR-REQUEST-STATUS | 3650 | Floor ID: 543 | 3651 | BENEFICIARY-INFORMATION | 3652 | Beneficiary ID: 124 | 3653 |FLOOR-REQUEST-INFORMATION | 3654 | Floor Request ID: 635 | 3655 | OVERALL-REQUEST-STATUS | 3656 | Request Status: Accepted | 3657 | Queue Position: 2nd | 3658 | FLOOR-REQUEST-STATUS | 3659 | Floor ID: 543 | 3660 | BENEFICIARY-INFORMATION | 3661 | Beneficiary ID: 154 | 3662 |<----------------------------------------------| 3663 | | 3664 |(3) FloorStatus | 3665 |Transaction ID: 4319 | 3666 |User ID: 234 | 3667 |FLOOR-ID:543 | 3668 |FLOOR-REQUEST-INFORMATION | 3669 | Floor Request ID: 764 | 3670 | OVERALL-REQUEST-STATUS | 3671 | Request Status: Granted | 3672 | FLOOR-REQUEST-STATUS | 3673 | Floor ID: 543 | 3674 | BENEFICIARY-INFORMATION | 3675 | Beneficiary ID: 124 | 3676 |FLOOR-REQUEST-INFORMATION | 3677 | Floor Request ID: 635 | 3678 | OVERALL-REQUEST-STATUS | 3679 | Request Status: Accepted | 3680 | Queue Position: 1st | 3681 | FLOOR-REQUEST-STATUS | 3682 | Floor ID: 543 | 3683 | BENEFICIARY-INFORMATION | 3684 | Beneficiary ID: 154 | 3685 |<----------------------------------------------| 3686 | | 3687 |(4) FloorStatusAck | 3688 |Transaction ID: 4319 | 3689 |User ID: 234 | 3690 |---------------------------------------------->| 3691 | | 3692 |(5) FloorStatus | 3693 |Transaction ID: 4392 | 3694 |User ID: 234 | 3695 |FLOOR-ID:543 | 3696 |FLOOR-REQUEST-INFORMATION | 3697 | Floor Request ID: 635 | 3698 | OVERALL-REQUEST-STATUS | 3699 | Request Status: Granted | 3700 | FLOOR-REQUEST-STATUS | 3701 | Floor ID: 543 | 3702 | BENEFICIARY-INFORMATION | 3703 | Beneficiary ID: 154 | 3704 |<----------------------------------------------| 3705 | | 3706 |(6) FloorStatusAck | 3707 |Transaction ID: 4392 | 3708 |User ID: 234 | 3709 |---------------------------------------------->| 3711 Figure 49: Obtaining status information about a floor 3713 Appendix B. Motivation for Supporting Unreliable Transport 3715 [Editorial note: This appendix is contained in this draft as an 3716 aid and rationale for new readers and reviewers. However, it is 3717 not yet decided whether this Appendix will be part of the final 3718 (RFC) version or not.] 3720 B.1. Motivation 3722 In existing video conferencing deployments, BFCP is used to manage 3723 the floor for the content sharing associated with the conference. 3724 For peer to peer scenarios, including business to business 3725 conferences and point to point conferences in general, it is 3726 frequently the case that one or both endpoints exists behind a NAT/ 3727 firewall. BFCP roles are negotiated in the offer/answer exchange as 3728 specified in [7], resulting in one endpoint being responsible for 3729 opening the TCP connection used for the BFCP communication. 3731 +---------+ 3732 | Network | 3733 +---------+ 3734 +-----+ / \ +-----+ 3735 | NAT |/ \| NAT | 3736 +-----+ +-----+ 3737 +----+ / \ +----+ 3738 |BFCP|/ \|BFCP| 3739 | UA | | UA | 3740 +----+ +----+ 3742 Figure 50: Use Case 3744 The communication session between the video conferencing endpoints 3745 typically consists of a number of RTP over UDP media streams, for 3746 audio and video, and a BFCP connection for floor control. Existing 3747 deployments are most common in, but not limited to, enterprise 3748 networks. In existing deployments, NAT/firewall traversal for the 3749 RTP streams works using ICE and/or other methods, including those 3750 described in [24]. 3752 When enhancing an existing SIP based video conferencing deployment 3753 with support for content sharing, the BFCP connection often poses a 3754 problem. The reasons for this fall into two general classes. First, 3755 there may be a strong preference for UDP based signaling in general. 3756 On high capacity endpoints (e.g. PSTN gateways or SIP/H.323 inter- 3757 working gateways), TCP can suffer from head of line blocking, and it 3758 uses many kernel buffers. Network operators view UDP as a way to 3759 avoid both of these. Second, establishment and traversal of the TCP 3760 connection involving ephemeral ports, as is typically the case with 3761 BFCP over TCP, can be problematic, as described in Appendix A of 3762 [22]. A broad study of NAT behavior and peer-to-peer TCP 3763 establishment for a comprehensive set of TCP NAT traversal techniques 3764 over a wide range of commercial NAT products concluded it was not 3765 possible to establish a TCP connection in 11% of the cases [25]. The 3766 results are worse when focusing on enterprise NATs. A study of hole 3767 punching as a NAT traversal technique across a wide variety of 3768 deployed NATs reported consistently higher success rates when using 3769 UDP than when using TCP [26]. 3771 It is worth noticing that BFCP over UDP were already used in real 3772 deployments, underlining the necessity to specify a common way to 3773 exchange BFCP messages where TCP is not appropriate, to avoid a 3774 situation where multiple different and non-interoperable would co- 3775 exist in the market. The purpose of this draft is to formalize and 3776 publish the extension from the standard specification to facilitate 3777 complete interoperability between implementations. 3779 B.1.1. Alternatives Considered 3781 In selecting the approach of defining UDP as an alternate transport 3782 for BFCP, several alternatives were considered and explored to some 3783 degree. Each of these is discussed briefly in the following 3784 subsections. In summary, while the not chosen alternatives work in a 3785 number of scenarios, they are not sufficient, in and of themselves, 3786 to address the use case targeted by this draft. The last 3787 alternative, presented in Appendix B.1.1.7, is the selected one and 3788 is specified in this draft. 3790 It is also worth noting that the IETF Transport Area were asked for a 3791 way to tunnel TCP over UDP, but at that point there was no consensus 3792 on how to achieve that. 3794 B.1.1.1. ICE TCP 3796 ICE TCP [22] extends ICE to TCP based media, including the ability to 3797 offer a mix of TCP and UDP based candidates for a single stream. ICE 3798 TCP has, in general, a lower success probability for enabling TCP 3799 connectivity without a relay if both of the hosts are behind a NAT 3800 (see Appendix A of [22]) than enabling UDP connectivity in the same 3801 scenarios. The happens because many of the currently deployed NATs 3802 in video conferencing networks do not support the flow of TCP hand 3803 shake packets seen in case of TCP simultaneous-open, either because 3804 they do not allow incoming TCP SYN packets from an address to which a 3805 SYN packet has been sent to recently, or because they do not properly 3806 process the subsequent SYNACK. Implementing various techniques 3807 advocated for candidate collection in [22] should increase the 3808 success probability, but many of these techniques require support 3809 from some network elements (e.g., from the NATs). Such support is 3810 not common in enterprise firewalls and NATs. 3812 B.1.1.2. Teredo 3814 Teredo [18] enables nodes located behind one or more IPv4 NATs to 3815 obtain IPv6 connectivity by tunneling packets over UDP. Teredo 3816 extensions [20] provide additional capabilities to Teredo, including 3817 support for more types of NATs and support for more efficient 3818 communication. 3820 As defined, Teredo could be used to make BFCP work for the video 3821 conferencing use cases addressed in this draft. However, running the 3822 service requires the help of "Teredo servers" and "Teredo relays" 3823 [18]. These servers and relays generally do not exist in the 3824 existing video conferencing deployments. It also requires IPv6 3825 awareness on the endpoints. It should also be noted that ICMP6, as 3826 used with Teredo to complete an initial protocol exchange and confirm 3827 that the appropriate NAT bindings have been set up, is not a 3828 conventional feature of IPv4 or even IPv6, and some currently 3829 deployed IPv6 firewalls discard ICMP messages. As these networks 3830 continue to evolve and tackle the transaction to IPv6, Teredo servers 3831 and relays may be deployed, making Teredo available as a suitable 3832 alternative to BFCP over UDP. 3834 B.1.1.3. GUT 3836 GUT [23] attempts to facilitate tunneling over UDP by encapsulating 3837 the native transport protocol and its payload (in general the whole 3838 IP payload) within a UDP packet destined to the well-known port 3839 GUT_P. Unfortunately, it requires user-space TCP, for which there is 3840 not a readily available implementation, and creating one is a large 3841 project in itself. This draft has expired and its future is still 3842 not clear as it has not yet been adopted by a working group. 3844 B.1.1.4. UPnP IGD 3846 Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on 3847 the edge of the network, providing connectivity to the Internet for 3848 computers internal to the LAN, but do not allow Internet devices to 3849 connect to computers on the internal LAN. IGDs enable a computer on 3850 an internal LAN to create port mappings on their NAT, through which 3851 hosts on the Internet can send data that will be forwarded to the 3852 computer on the internal LAN. IGDs may be self-contained hardware 3853 devices or may be software components provided within an operating 3854 system. 3856 In considering UPnP IGD, several issues exist. Not all NATs support 3857 UPnP, and many that do support it are configured with it turned off 3858 by default. NATs are often multilayered, and UPnP does not work well 3859 with such NATs. For example, a typical DSL modems acts as a NAT, and 3860 the user plugs in a wireless access point behind that, which adds 3861 another layer NAT. The client can discover the first layer of NAT 3862 using multicast but it is harder to figure out how to discover and 3863 control NATs in the next layer up. 3865 B.1.1.5. NAT PMP 3867 The NAT Port Mapping Protocol (NAT PMP) allows a computer in a 3868 private network (behind a NAT router) to automatically configure the 3869 router to allow parties outside the private network to contact it. 3870 NAT PMP runs over UDP. It essentially automates the process of port 3871 forwarding. Included in the protocol is a method for retrieving the 3872 public IP address of a NAT gateway, thus allowing a client to make 3873 this public IP address and port number known to peers that may wish 3874 to communicate with it. 3876 Many NATs do not support PMP. In those that do support it, it has 3877 similar issues with negotiation of multilayer NATs as UPnP. Video 3878 conferencing is used extensively in enterprise networks, and NAT PMP 3879 is not generally available in enterprise-class routers. 3881 B.1.1.6. SCTP 3883 It would be quite straight forward to specify a BFCP binding for SCTP 3884 [21], and then tunnel SCTP over UDP in the use case described in 3885 Appendix B.1. SCTP is gaining some momentum currently. There is 3886 ongoing discussion in the RTCWeb WG regarding this approach. 3887 However, this approach for tunneling over UDP was not mature enough 3888 when considered and not even fully specified. 3890 B.1.1.7. BFCP over UDP transport 3892 To overcome the problems with establishing TCP flows between BFCP 3893 entities, an alternative is to define UDP as an alternate transport 3894 for BFCP, leveraging the same mechanisms in place for the RTP over 3895 UDP media streams for the BFCP communication. When using UDP as the 3896 transport, it is recommended to follow the guidelines provided in 3897 [19]. 3899 Minor changes to the transaction model are introduced in that all 3900 requests now have an appropriate response to complete the 3901 transaction. The requests are sent with a retransmit timer 3902 associated with the response to achieve reliability. This 3903 alternative does not change the semantics of BFCP. It permits UDP as 3904 an alternate transport. 3906 Existing implementations, in the spirit of the approach detailed in 3907 earlier versions of this draft, have demonstrated this approach to be 3908 feasible. Initial compatibility among implementations has been 3909 achieved at previous interoperability events. The authors view this 3910 extension as a pragmatic solution to an existing deployment 3911 challenge. This is the chosen approach, and the extensions is 3912 specified in this document. 3914 Authors' Addresses 3916 Gonzalo Camarillo 3917 Ericsson 3918 Hirsalantie 11 3919 Jorvas 02420 3920 Finland 3922 Email: gonzalo.camarillo@ericsson.com 3924 Keith Drage 3925 Alcatel-Lucent 3926 Quadrant, StoneHill Green, Westlea 3927 Swindon, Wilts 3928 UK 3930 Email: drage@alcatel-lucent.com 3931 Tom Kristensen (editor) 3932 Cisco 3933 Philip Pedersens vei 22 3934 N-1366 Lysaker 3935 Norway 3937 Email: tomkrist@cisco.com, tomkri@ifi.uio.no 3939 Joerg Ott 3940 Aalto University 3941 Otakaari 5 A 3942 Espoo, FIN 02150 3943 Finland 3945 Email: jo@comnet.tkk.fi 3947 Charles Eckel 3948 Cisco 3949 170 West Tasman Drive 3950 San Jose, CA 95134 3951 United States 3953 Email: eckelcu@cisco.com