idnits 2.17.1 draft-ietf-bfcpbis-rfc4583bis-24.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 19, 2018) is 2138 days in the past. Is this intentional? 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: 'RFC5234' on line 377 -- Looks like a reference, but probably isn't: 'RFC4566' on line 340 -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 787 ** Obsolete normative reference: RFC 4566 (ref. '8') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6347 (ref. '9') (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 4582 (ref. '12') (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (ref. '13') (Obsoleted by RFC 8856) == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-20 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-51 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-17 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: 4583 (if approved) T. Kristensen 5 Intended status: Standards Track Cisco 6 Expires: December 21, 2018 C. Holmberg 7 Ericsson 8 June 19, 2018 10 Session Description Protocol (SDP) Format for Binary Floor Control 11 Protocol (BFCP) Streams 12 draft-ietf-bfcpbis-rfc4583bis-24 14 Abstract 16 This document defines the Session Description Protocol (SDP) offer/ 17 answer procedures for negotiating and establishing Binary Floor 18 Control Protocol (BFCP) streams. 20 This document obsoletes RFC 4583. Changes from RFC 4583 are 21 summarized in Section 15. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 21, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Floor Control Roles . . . . . . . . . . . . . . . . . . . . . 3 60 4. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . 4 61 5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. SDP 'floorctrl' Attribute . . . . . . . . . . . . . . . . 5 63 5.2. SDP 'confid' and 'userid' Attributes . . . . . . . . . . 6 64 5.3. SDP 'floorid' Attribute . . . . . . . . . . . . . . . . . 7 65 5.4. SDP 'bfcpver' Attribute . . . . . . . . . . . . . . . . . 8 66 6. Multiplexing Considerations . . . . . . . . . . . . . . . . . 9 67 7. BFCP Connection Management . . . . . . . . . . . . . . . . . 10 68 7.1. TCP Connection Management . . . . . . . . . . . . . . . . 10 69 8. TLS/DTLS Considerations . . . . . . . . . . . . . . . . . . . 11 70 9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 10. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 72 10.1. Generating the Initial SDP Offer . . . . . . . . . . . . 13 73 10.2. Generating the SDP Answer . . . . . . . . . . . . . . . 13 74 10.3. Offerer Processing of the SDP Answer . . . . . . . . . . 14 75 10.4. Modifying the Session . . . . . . . . . . . . . . . . . 15 76 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 13.1. Registration of SDP 'proto' Values . . . . . . . . . . . 18 80 13.2. Registration of the SDP 'floorctrl' Attribute . . . . . 18 81 13.3. Registration of the SDP 'confid' Attribute . . . . . . . 18 82 13.4. Registration of the SDP 'userid' Attribute . . . . . . . 18 83 13.5. Registration of the SDP 'floorid' Attribute . . . . . . 18 84 13.6. Registration of the SDP 'bfcpver' Attribute . . . . . . 19 85 14. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 19 86 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 87 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 16.1. Normative References . . . . . . . . . . . . . . . . . . 20 89 16.2. Informational References . . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 As discussed in the BFCP (Binary Floor Control Protocol) 95 specification [16], a given BFCP client needs a set of data in order 96 to establish a BFCP connection to a floor control server. This data 97 includes the transport address of the server, the conference 98 identifier, and the user identifier. 100 One way for clients to obtain this information is to use an SDP 101 offer/answer [4] exchange. This document specifies how to encode 102 this information in the SDP session descriptions that are part of 103 such an offer/answer exchange. 105 User agents typically use the offer/answer model to establish a 106 number of media streams of different types. Following this model, a 107 BFCP connection is described as any other media stream by using an 108 SDP 'm' line, possibly followed by a number of attributes encoded in 109 'a' lines. 111 Section 4 defines how the field values in 'm' line representing a 112 BFCP connection are set. 114 Section 5 defines SDP attributes that are used when negotiating a 115 BFCP connection. 117 Section 6 defines multiplexing considerations for a BFCP connection. 119 Section 7 defines procedures for managing a BFCP connection. 121 Section 8 defines TLS and DTLS considerations when negotiating a BFCP 122 connection. 124 Section 9 defines the Interactive Connectivity Establishment (ICE) 125 [14] considerations when negotiating a BFCP connection. 127 Section 10 defines the SDP offer/answer procedures for negotiating a 128 BFCP connection. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14, RFC 2119 [1] and indicate requirement levels for compliant 136 implementations. 138 3. Floor Control Roles 140 When two endpoints establish a BFCP stream, they need to determine 141 which of them acts as floor control client and which acts as floor 142 control server. Typically, a client that establishes a BFCP stream 143 with a conference server will act as floor control client, while the 144 conference server will act as floor control server. However, there 145 are scenarios where both endpoints would be able to act as floor 146 control server. For example, in a two-party session that involves an 147 audio stream and a shared whiteboard, the endpoints need to determine 148 which party will be act as floor control server. 150 Furthermore, there are situations where both endpoints act as both 151 floor control client and floor control server within the same 152 session. For example, in a two-party session that involves an audio 153 stream and a shared whiteboard, one endpoint acts as the floor 154 control server for the audio stream and the other endpoint acts as 155 the floor control server for the shared whiteboard. However, for a 156 given BFCP-controlled media stream one endpoint MUST act as floor 157 control client and one endpoint MUST act as floor control server. 159 4. Fields in the 'm' Line 161 This section describes how to generate an 'm' line for a BFCP stream. 163 According to the SDP specification [8], the 'm' line format is the 164 following: 166 m= ... 168 The media field MUST have a value of "application". 170 The port field is set depending on the value of the proto field, as 171 explained below. A port field value of zero has the standard SDP 172 meaning (i.e., rejection of the media stream) regardless of the proto 173 field. 175 When TCP is used as the transport, the port field is set following 176 the rules in [5]. Depending on the value of the 'setup' attribute 177 (discussed in Section 7.1), the port field contains the port to 178 which the remote endpoint will direct BFCP messages, or in the 179 case where the endpoint will initiate the connection towards the 180 remote endpoint, should be set to a value of 9. 182 When UDP is used as the transport, the port field contains the 183 port to which the remote endpoint will direct BFCP messages 184 regardless of the value of the 'setup' attribute. 186 This document defines five values for the proto field: TCP/BFCP, 187 TCP/DTLS/BFCP, TCP/TLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP. 189 TCP/BFCP is used when BFCP runs directly on top of TCP. TCP/TLS/BFCP 190 is used when BFCP runs on top of TLS, which in turn runs on top of 191 TCP. TCP/DTLS/BFCP is used when running BFCP on top of DTLS [9], as 192 described in this specification, which in turn runs on top of TCP 193 using the framing method defined in [10] with DTLS packets being sent 194 and received instead of RTP/RTCP packets using the shim defined in 195 RFC4571 such that the length field defined in RFC4571 precedes each 196 DTLS message. 198 Similarly, UDP/BFCP is used when BFCP runs directly on top of UDP, 199 and UDP/TLS/BFCP is used when BFCP runs on top of DTLS, which in turn 200 runs on top of UDP. 202 The fmt (format) list is not applicable to BFCP. The fmt list of 'm' 203 lines in the case of any proto field value related to BFCP MUST 204 contain a single "*" character. If the the fmt list contains any 205 other value it is ignored. 207 The following is an example of an 'm' line for a BFCP connection: 209 m=application 50000 TCP/TLS/BFCP * 211 5. SDP Attributes 213 5.1. SDP 'floorctrl' Attribute 215 This section defines the SDP 'floorctrl' media-level attribute. The 216 attribute is used to determine the floor control role(s) that the 217 endpoints can take for the BFCP-controlled media streams. As 218 described in Section 5.1, an endpoint can take different roles for 219 different media streams, but for a given media stream an endpoint can 220 only take one role. 222 Attribute Name: floorctrl 224 Attribute Value: floor-control 226 Usage Level: media 228 Charset Dependent: No 230 Mux Category: TBD 232 The Augmented BNF syntax [RFC5234] for the attribute is: 234 floor-control = role *(SP role) 235 role = "c-only" / "s-only" / "c-s" 237 An endpoint includes the attribute to indicate the role(s) it would 238 be willing to perform for the BFCP-controlled media streams: 240 c-only: The endpoint is willing to act as floor control client. 242 s-only: The endpoint is willing to act as floor control server only. 244 c-s: The endpoint is willing to act as floor control client and 245 floor control server. 247 When inserted in an offer, the offerer MAY indicate multiple 248 attribute values. When inserted in an answer, the answerer MUST 249 indicate only one attribute value. The offerer indicates which floor 250 control role(s) that it is willing to take. The answerer indicates 251 the role taken by the answerer. Based on this, the floor control 252 role(s) of the offerer is determined, as shown in Table 1. 254 +---------+----------+ 255 | Offerer | Answerer | 256 +---------+----------+ 257 | c-only | s-only | 258 | s-only | c-only | 259 | c-s | c-s | 260 +---------+----------+ 262 Table 1: Roles 264 Endpoints compliant with [13] might not include the 'floorctrl' 265 attribute in offers and answerer. If the 'floorctrl' attribute is 266 not present the offerer will act as floor control client, and the 267 answerer will act as floor control server, for each BFCP-controlled 268 media stream. 270 The SDP Offer/Answer procedures for the 'floorctrl' attribute are 271 defined in Section 10. 273 The following is an example of a 'floorctrl' attribute in an offer: 275 a=floorctrl:c-only s-only c-s 277 5.2. SDP 'confid' and 'userid' Attributes 279 This section defines the SDP 'confid' and the 'userid' media-level 280 attributes. The attributes are used by a floor control server to 281 convey the conference ID value and user ID value to the floor control 282 client, using decimal integer representation. 284 Attribute Name: confid 286 Attribute Value: conference-id 288 Usage Level: media 290 Charset Dependent: No 292 Mux Category: TBD 294 The Augmented BNF syntax [RFC5234] for the attribute is: 296 conference-id = 1*DIGIT 298 ;DIGIT is defined in [RFC5234] 300 Attribute Name: userid 302 Attribute Value: user-id 304 Usage Level: media 306 Charset Dependent: No 308 Mux Category: TBD 310 The Augmented BNF syntax [RFC5234] for the attribute is: 312 user-id = 1*DIGIT 314 ;DIGIT is defined in [RFC5234] 316 The SDP Offer/Answer procedures for the 'confid' and 'userid' 317 attributes are defined in Section 10. 319 5.3. SDP 'floorid' Attribute 321 This section defines the SDP 'floorid' media-level attribute. The 322 attribute conveys a floor identifier, and optionally pointers to one 323 or more BFCP-controlled media streams. 325 Attribute Name: floorid 327 Attribute Value: floor-id 329 Usage Level: media 331 Charset Dependent: No 333 Mux Category: TBD 335 The Augmented BNF syntax [RFC5234] for the attribute is: 337 floor-id = "a=floorid:" 1*DIGIT SP "mstrm:" token *(SP token) 339 ;DIGIT is defined in [RFC5234] 340 ;token is defined in [RFC4566] 342 The floor identifier value is the integer representation of the Floor 343 ID to be used in BFCP. Each media stream pointer value is associated 344 with an SDP 'label' attribute [6] of a media stream. 346 The SDP Offer/Answer procedures for the 'floorid' attribute are 347 defined in Section 10. 349 Note: In [13] 'm-stream' was erroneously used in Section 11. 350 Although the example was non-normative, it is implemented by some 351 vendors and occurs in cases where the endpoint is willing to act 352 as an server. Therefore, it is RECOMMENDED to support parsing and 353 interpreting 'm-stream' the same way as 'mstrm' when receiving. 355 5.4. SDP 'bfcpver' Attribute 357 This section defines the SDP 'bfcpver' media-level attribute. The 358 attribute is used to negotiate the BFCP version. 360 The Augmented BNF syntax [2] for the attributes is: 362 Attribute Name: bfcpver 364 Attribute Value: bfcp-version 366 Usage Level: media 368 Charset Dependent: No 370 Mux Category: TBD 372 The Augmented BNF syntax [RFC5234] for the attribute is: 374 bfcp-version = "a=bfcpver:" version *(SP version) 375 version = 1*DIGIT 377 ;DIGIT is defined in [RFC5234] 379 An endpoint uses the 'bfcpver' attribute to convey the version(s) of 380 BFCP supported by the endpoint, using integer values. For a given 381 version, the attribute value representing the version MUST match the 382 "Version" field that would be presented in the BFCP COMMON-HEADER 383 [16]. The BFCP version that will eventually be used will be conveyed 384 with a BFCP-level Hello/HelloAck. 386 Endpoints compliant with [13] might not always include the 'bfcpver' 387 attribute in offers and answers. The attribute value, if present, 388 MUST be in accordance with the definition of the Version field in 389 [16]. If the attribute is not present, endpoints MUST assume a 390 default value in accordance with [16]: when used over a reliable 391 transport the default attribute value is "1", and when used over an 392 unreliable transport the default attribute value is "2". The value 393 is inferred from the transport specified in the 'm' line (Section 4) 394 associated with the stream. 396 The SDP Offer/Answer procedures for the 'bfcpver' attribute are 397 defined in Section 10. 399 6. Multiplexing Considerations 401 [19] defines how multiplexing of multiple media streams can be 402 negotiated. This specification does not define how BFCP streams can 403 be multiplexed with other media streams. Therefore, a BFCP stream 404 MUST NOT be associated with a BUNDLE group [19]. Note that BFCP- 405 controlled media streams might be multiplexed with other media 406 streams. 408 [20] defines the mux categories for the SDP attributes defined in 409 this specification. Table 2 defines the mux category for the 410 'bfcpver' attribute: 412 +---------+-------------------------------------+-------+-----------+ 413 | Name | Notes | Level | Mux | 414 | | | | Category | 415 +---------+-------------------------------------+-------+-----------+ 416 | bfcpver | Needs further analysis in a | M | TBD | 417 | | separate specification | | | 418 +---------+-------------------------------------+-------+-----------+ 420 Table 2: Multiplexing Attribute Analysis 422 7. BFCP Connection Management 424 BFCP streams can use TCP or UDP as the underlying transport. 425 Endpoints exchanging BFCP messages over UDP send the BFCP messages 426 towards the peer using the connection address and port provided in 427 the SDP 'c' and 'm' lines. TCP connection management is more 428 complicated and is described in the following Section. 430 Note: When using Interactive Connectivity Establishment (ICE) 431 [14], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward 432 procedures for connection management as UDP/BFCP described above 433 apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and 434 is described below. 436 7.1. TCP Connection Management 438 The management of the TCP connection used to transport BFCP messages 439 is performed using the SDP 'setup' and 'connection' attributes [5]. 440 The 'setup' attribute indicates which of the endpoints initiates the 441 TCP connection. The 'connection' attribute handles TCP connection 442 re-establishment. 444 The BFCP specification [16] describes a number of situations when the 445 TCP connection between a floor control client and the floor control 446 server needs to be re-established. However, that specification does 447 not describe the re-establishment process because this process 448 depends on how the connection was established in the first place. 449 Endpoints using the offer/answer mechanism follow the following 450 rules. 452 When the existing TCP connection is closed and re-established 453 following the rules in [16], the floor control client MUST send an 454 offer towards the floor control server in order to re-establish the 455 connection. If a TCP connection cannot deliver a BFCP message and 456 times out, the endpoint that attempted to send the message (i.e., the 457 one that detected the TCP timeout) MUST send an offer in order to re- 458 establish the TCP connection. 460 Endpoints that use the offer/answer mechanism to negotiate TCP 461 connections MUST support the 'setup' and 'connection' attributes. 463 8. TLS/DTLS Considerations 465 When DTLS is used with UDP, the generic procedures defined in 466 Section 5 of [17] MUST be followed. 468 When TLS is used with TCP, once the underlying connection is 469 established, the answerer always acts as the TLS server. If the TCP 470 connection is lost, the active endpoint is responsible for re- 471 establishing the TCP connection. Unless a new TLS session is 472 negotiated, subsequent SDP offers and answers will not impact the 473 previously negotiated TLS roles. 475 Note: For TLS, it was decided to keep the original procedures in 476 [13] to determine which endpoint acts as the TLS server in order 477 to retain backwards compatibility. 479 9. ICE Considerations 481 Generic SDP offer/answer procedures for Interactive Connectivity 482 Establishment (ICE) are defined in [15]. 484 When BFCP is used with UDP based ICE candidates [14] then the 485 procedures for UDP/TLS/BFCP are used. 487 When BFCP is used with TCP based ICE candidates [11] then the 488 procedures for TCP/DTLS/BFCP are used. 490 Based on the procedures defined in [17], endpoints treat all ICE 491 candidate pairs associated with a BFCP stream on top of a DTLS 492 association as part of the same DTLS association. Thus, there will 493 only be one BFCP handshake and one DTLS handshake even if there are 494 multiple valid candidate pairs, and if BFCF media is shifted between 495 candidate pairs (including switching between UDP to TCP candidate 496 pairs) prior to nomination. If new candidates are added, they will 497 also be part of the same DTLS association. 499 In order to maximize the likelihood of interoperability between the 500 endpoints, all ICE enabled BFCP-over-DTLS endpoints SHOULD implement 501 support for UDP/TLS/BFCP. 503 When an SDP offer or answer conveys multiple ICE candidates for a 504 BFCP stream, UDP based candidates SHOULD be included and the default 505 candidate SHOULD be chosen from one of those UDP candidates. If UDP 506 transport is used for the default candidate, then the 'm' line proto 507 value MUST be 'UDP/TLS/BFCP'. If TCP transport is used for the 508 default candidate, the 'm' line proto value MUST be 'TCP/DTLS/BFCP'. 510 Note: Usage of ICE with protocols other than UDP/TLS/BFCP and 511 TCP/DTLS/BFCP is outside of scope for this specification. 513 10. SDP Offer/Answer Procedures 515 This section defines the SDP offer/answer [4] procedures for 516 negotiating and establishing a BFCP stream. Generic procedures for 517 DTLS are defined in [17]. Generic procedures for TLS are defined in 518 [7]. 520 This section only defines the BFCP-specific procedures. Unless 521 explicitly stated otherwise, the procedures apply to an 'm' line 522 describing a BFCP stream. If an offer or answer contains multiple 523 'm' lines describing BFCP streams, the procedures are applied 524 independently to each stream. 526 Within this document, 'initial offer' refers to the first offer, 527 within an SDP session (e.g. a SIP dialog when the Session Initiation 528 Protocol (SIP) [3] is used to carry SDP), in which the offerer 529 indicates that it wants to negotiate the establishment of a BFCP 530 stream. 532 If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 533 'UDP/TLS/BFCP', the offerer and answerer follow the generic 534 procedures defined in [7]. 536 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/ 537 TCP' or 'UDP/TLS/BFCP', the offerer and answerer use the SDP 'setup' 538 attribute according to the procedures in [5]. 540 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 541 'TCP/DTLS/BFCP', the offerer and anwerer use the SDP 'connection' 542 attribute according to the procedures in [5]. 544 Note: The use of source-specific SDP parameters [18] is not 545 defined to BFCP streams. 547 10.1. Generating the Initial SDP Offer 549 When the offerer creates an initial offer, the offerer MUST associate 550 an SDP 'floorctrl' attribute (Section 5.1) and an SDP 'bfcpver' 551 attribute (Section 5.4) with the 'm' line. 553 In addition, if the offerer includes an SDP 'floorctrl' attribute 554 with 's-only' or 'c-s' attribute values in the offer, the offerer: 556 o MUST associate an SDP 'confid' attribute (Section 5.2) with the 557 'm' line; and 559 o MUST associate an SDP 'userid' attribute (Section 5.2) with the 560 'm' line; and 562 o MUST associate an SDP 'floorid' attribute (Section 5.3) with the 563 'm' line; and 565 o MUST associate an SDP 'label' attribute (Section 5.3) with the 'm' 566 line of each BFCP-controlled media stream. 568 Note: If the offerer includes an SDP 'floorctrl' attribute with a 569 'c-s' attribute value, or both a 'c-only' and a 's-only' attribute 570 value, in the offer, the attribute values above will only be used 571 if it is determined (Section 5.1) that the offerer will act as 572 floor control server. If it is determined that the offerer will 573 act as both floor control server and floor control client, the 574 attribute values will be used for the BFCP-controlled media 575 streams where the offerer acts as floor control server. 577 10.2. Generating the SDP Answer 579 When the answerer receives an offer, which contains an 'm' line 580 describing a BFCP stream, the answerer MUST check whether it supports 581 one or more of the BFCP versions supported by the offerer 582 (Section 5.4). If the answerer does not support any of the BFCP 583 versions, it MUST NOT accept the 'm' line. Otherwise, if the 584 answerer accepts the 'm' line, it: 586 o MUST insert a corresponding 'm' line in the answer, with an 587 identical 'm' line proto value [4]; and 589 o MUST associate a 'bfcpver' attribute with the 'm' line. The 590 answerer only indicates support of BFCP versions also supported by 591 the offerer; and 593 o MUST, if the offer contained an SDP 'floorctrl' attribute, 594 associate a 'floorctrl' attribute with the 'm' line. 596 In addition, if the answerer includes an SDP 'floorctrl' attribute 597 with 's-only' or 'c-s' attribute values in the answer, the answerer: 599 o MUST associate an SDP 'confid' attribute with the 'm' line; and 601 o MUST associate an SDP 'userid' attribute with the 'm' line; and 603 o MUST associate an SDP 'floorid' attribute with the 'm' line; and 605 o MUST associate an SDP 'label' attribute with the 'm' line of each 606 BFCP-controlled media stream. 608 Note: If the answerer includes an SDP 'floorctrl' attribute with 609 an 'c-s' attribute value in the answer, the attribute values will 610 be used for the BFCP-controlled media streams where the answerer 611 acts as floor control server. 613 Note: An offerer compliant with [13] might not include 'floorctrl' 614 and 'bfcpver' attributes in offers, in which cases the default 615 values apply. 617 Once the answerer has sent the answer, the answerer: 619 o MUST, if the answerer is the 'active' endpoint, and if a TCP 620 connection associated with the 'm' line is to be established (or 621 re-established), initiate the establishing of the TCP connection; 622 and 624 o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS 625 connection associated with the 'm' line is to be established (or 626 re-established), initiate the establishing of the TLS/DTLS 627 connection (by sending a ClientHello message). 629 If the answerer does not accept the 'm' line in the offer, it MUST 630 assign a zero port value to the corresponding 'm' line in the answer. 631 In addition, the answerer MUST NOT establish a TCP connection or a 632 TLS/DTLS connection associated with the 'm' line. 634 10.3. Offerer Processing of the SDP Answer 636 When the offerer receives an answer, which contains an 'm' line with 637 a non-zero port value, describing a BFCP stream, the offerer: 639 o MUST, if the offerer is the 'active' endpoint, and if a TCP 640 connection associated with the 'm' line is to be established (or 641 re-established), initiate the establishing of the TCP connection; 642 and 644 o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS 645 connection associated with the 'm' line is to be established (or 646 re-established), initiate the establishing of the TLS/DTLS 647 connection (by sending a ClientHello message). 649 Note: An answerer compliant with [13] might not include 650 'floorctrl' and 'bfcpver' attributes in answers, in which cases 651 the default values apply. 653 If the 'm' line in the answer contains a zero port value, or if the 654 offerer for some other reason does not accept the answer (e.g., if 655 the answerer only indicates support of BFCP versions not supported by 656 the offerer), the offerer MUST NOT establish a TCP connection or a 657 TLS/DTLS connection associated with the 'm' line. 659 10.4. Modifying the Session 661 When an offerer sends an updated offer, in order to modify a 662 previously established BFCP stream, it follows the procedures in 663 Section 10.1, with the following exceptions: 665 o If the BFCP stream is carried on top of TCP, and if the offerer 666 does not want to re-establish an existing TCP connection, the 667 offerer MUST associate an SDP connection attribute with an 668 'existing' value, with the 'm' line; and 670 o If the offerer wants to disable a previously established BFCP 671 stream, it MUST assign a zero port value to the 'm' line 672 associated with the BFCP connection, following the procedures in 673 [4]. 675 11. Examples 677 For the purpose of brevity, the main portion of the session 678 description is omitted in the examples, which only show 'm' lines and 679 their attributes. 681 The following is an example of an offer sent by a conference server 682 to a client. 684 m=application 50000 TCP/TLS/BFCP * 685 a=setup:actpass 686 a=connection:new 687 a=fingerprint:sha-256 \ 688 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 689 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 690 a=floorctrl:c-only s-only 691 a=confid:4321 692 a=userid:1234 693 a=floorid:1 mstrm:10 694 a=floorid:2 mstrm:11 695 a=bfcpver:1 2 696 m=audio 50002 RTP/AVP 0 697 a=label:10 698 m=video 50004 RTP/AVP 31 699 a=label:11 701 Note that due to RFC formatting conventions, this document splits SDP 702 across lines whose content would exceed 72 characters. A backslash 703 character marks where this line folding has taken place. This 704 backslash and its trailing CRLF and whitespace would not appear in 705 actual SDP content. 707 The following is the answer returned by the client. 709 m=application 9 TCP/TLS/BFCP * 710 a=setup:active 711 a=connection:new 712 a=fingerprint:sha-256 \ 713 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 714 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 715 a=floorctrl:c-only 716 a=bfcpver:1 717 m=audio 55000 RTP/AVP 0 718 m=video 55002 RTP/AVP 31 720 A similar example using unreliable transport and DTLS is shown below, 721 where the offer is sent from a client. 723 m=application 50000 UDP/TLS/BFCP * 724 a=setup:actpass 725 a=dtls-id:abc3dl 726 a=fingerprint:sha-256 \ 727 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 728 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 729 a=floorctrl:c-only s-only 730 a=confid:4321 731 a=userid:1234 732 a=floorid:1 mstrm:10 733 a=floorid:2 mstrm:11 734 a=bfcpver:1 2 735 m=audio 50002 RTP/AVP 0 736 a=label:10 737 m=video 50004 RTP/AVP 31 738 a=label:11 740 The following is the answer returned by the server. 742 m=application 55000 UDP/TLS/BFCP * 743 a=setup:active 744 a=dtls-id:abc3dl 745 a=fingerprint:sha-256 \ 746 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 747 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 748 a=floorctrl:s-only 749 a=confid:4321 750 a=userid:1234 751 a=floorid:1 mstrm:10 752 a=floorid:2 mstrm:11 753 a=bfcpver:2 754 m=audio 55002 RTP/AVP 0 755 m=video 55004 RTP/AVP 31 757 12. Security Considerations 759 The BFCP [16], SDP [8], and offer/answer [4] specifications discuss 760 security issues related to BFCP, SDP, and offer/answer, respectively. 761 In addition, [5] and [7] discuss security issues related to the 762 establishment of TCP and TLS connections using an offer/answer model. 763 Furthermore, when using DTLS over UDP, the generic offer/answer 764 considerations defined in [17] MUST be followed. 766 13. IANA Considerations 768 [Editorial note: The changes in Section 13.1 instruct the IANA to 769 register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/ 770 BFCP for the SDP 'proto' field. The new section Section 5.4 771 registers a new SDP "bfcpver" attribute. The rest is unchanged 772 from [12].] 774 13.1. Registration of SDP 'proto' Values 776 The IANA has registered the following values for the SDP 'proto' 777 field under the Session Description Protocol (SDP) Parameters 778 registry: 780 +---------------+------------+ 781 | Value | Reference | 782 +---------------+------------+ 783 | TCP/BFCP | [RFC XXXX] | 784 | TCP/DTLS/BFCP | [RFC XXXX] | 785 | TCP/TLS/BFCP | [RFC XXXX] | 786 | UDP/BFCP | [RFC XXXX] | 787 | UDP/TLS/BFCP | [RFC XXXX] | 788 +---------------+------------+ 790 Table 3: Values for the SDP 'proto' field 792 13.2. Registration of the SDP 'floorctrl' Attribute 794 This document defines the SDP attribute,'floorctrl'. The details of 795 the attribute are defined in Section 5.1. 797 For issues regarding this attribute contact iesg@ietf.org. 799 13.3. Registration of the SDP 'confid' Attribute 801 This document defines the SDP attribute,'confid'. The details of the 802 attribute are defined in Section 5.2. 804 For issues regarding this attribute contact iesg@ietf.org. 806 13.4. Registration of the SDP 'userid' Attribute 808 This document defines the SDP attribute,'userid'. The details of the 809 attribute are defined in Section 5.2. 811 For issues regarding this attribute contact iesg@ietf.org. 813 13.5. Registration of the SDP 'floorid' Attribute 815 This document defines the SDP attribute,'floorid'. The details of 816 the attribute are defined in Section 5.3. 818 For issues regarding this attribute contact iesg@ietf.org. 820 13.6. Registration of the SDP 'bfcpver' Attribute 822 This document defines the SDP attribute,'bfcpver'. The details of 823 the attribute are defined in Section 5.4. 825 For issues regarding this attribute contact iesg@ietf.org. 827 14. Changes from RFC 4583 829 Following is the list of technical changes and other fixes from [13]. 831 Main purpose of this work was to add signaling support necessary to 832 support BFCP over unreliable transport, as described in [16], 833 resulting in the following changes: 835 1. Fields in the 'm' line (Section 4): 836 The section is re-written to remove reference to the exclusivity 837 of TCP as a transport for BFCP streams. The proto field values 838 TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added. 840 2. Authentication (Section 8): 841 In last paragraph, made clear that a TCP connection was 842 described. 844 3. Security Considerations (Section 12): 845 For the DTLS over UDP case, mention existing considerations and 846 requirements for the offer/answer exchange in [17]. 848 4. Registration of SDP 'proto' Values (Section 13.1): 849 Register the three new values TCP/DTLS/BFCP, UDP/BFCP and 850 UDP/TLS/BFCP in the SDP parameters registry. 852 5. BFCP Version Negotiation (Section 5.4): 853 A new 'bfcpver' SDP media-level attribute is added in order to 854 signal supported version number. 856 Clarification and bug fixes: 858 1. Errata ID: 712 (Section 3 and Section 10): 859 Language clarification. Don't use terms like an SDP attribute is 860 "used in an 'm' line", instead make clear that the attribute is a 861 media-level attribute. 863 2. Fix typo in example (Section 11): 864 Do not use 'm-stream' in the SDP example, use the correct 'mstrm' 865 as specified in Section 11. Recommend interpreting 'm-stream' if 866 it is received, since it is present in some implementations. 868 3. Assorted clarifications (Across the document): 869 Language clarifications as a result of reviews. Also, the 870 normative language where tightened where appropriate, i.e. 871 changed from SHOULD strength to MUST in a number of places. 873 15. Acknowledgements 875 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 876 Oscar Novo provided useful ideas for the original [13]. The authors 877 also acknowledge contributions to the revision of BFCP for use over 878 an unreliable transport from Geir Arne Sandbakken, Charles Eckel, 879 Alan Ford, Eoin McLeod and Mark Thompson. Useful and important final 880 reviews were done by Ali C. Begen, Mary Barnes and Charles Eckel. 881 In the final stages, Roman Shpount made a considerable effort in 882 adding proper ICE support and considerations. 884 16. References 886 16.1. Normative References 888 [1] Bradner, S., "Key words for use in RFCs to Indicate 889 Requirement Levels", BCP 14, RFC 2119, 890 DOI 10.17487/RFC2119, March 1997, . 893 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 894 Specifications: ABNF", STD 68, RFC 5234, 895 DOI 10.17487/RFC5234, January 2008, . 898 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 899 A., Peterson, J., Sparks, R., Handley, M., and E. 900 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 901 DOI 10.17487/RFC3261, June 2002, . 904 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 905 with Session Description Protocol (SDP)", RFC 3264, 906 DOI 10.17487/RFC3264, June 2002, . 909 [5] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 910 the Session Description Protocol (SDP)", RFC 4145, 911 DOI 10.17487/RFC4145, September 2005, . 914 [6] Levin, O. and G. Camarillo, "The Session Description 915 Protocol (SDP) Label Attribute", RFC 4574, 916 DOI 10.17487/RFC4574, August 2006, . 919 [7] Lennox, J. and C. Holmberg, "Connection-Oriented Media 920 Transport over the Transport Layer Security (TLS) Protocol 921 in the Session Description Protocol (SDP)", RFC 8122, 922 DOI 10.17487/RFC8122, March 2017, . 925 [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 926 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 927 July 2006, . 929 [9] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 930 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 931 January 2012, . 933 [10] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 934 and RTP Control Protocol (RTCP) Packets over Connection- 935 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 936 2006, . 938 [11] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 939 "TCP Candidates with Interactive Connectivity 940 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 941 March 2012, . 943 [12] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 944 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 945 November 2006, . 947 [13] Camarillo, G., "Session Description Protocol (SDP) Format 948 for Binary Floor Control Protocol (BFCP) Streams", 949 RFC 4583, DOI 10.17487/RFC4583, November 2006, 950 . 952 [14] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 953 Connectivity Establishment (ICE): A Protocol for Network 954 Address Translator (NAT) Traversal", draft-ietf-ice- 955 rfc5245bis-20 (work in progress), March 2018. 957 [15] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 958 "Session Description Protocol (SDP) Offer/Answer 959 procedures for Interactive Connectivity Establishment 960 (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in 961 progress), April 2018. 963 [16] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 964 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 965 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 966 2015. 968 [17] Holmberg, C. and R. Shpount, "Session Description Protocol 969 (SDP) Offer/Answer Considerations for Datagram Transport 970 Layer Security (DTLS) and Transport Layer Security (TLS)", 971 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 972 2017. 974 16.2. Informational References 976 [18] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 977 Media Attributes in the Session Description Protocol 978 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 979 . 981 [19] Holmberg, C., Alvestrand, H., and C. Jennings, 982 "Negotiating Media Multiplexing Using the Session 983 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 984 negotiation-51 (work in progress), May 2018. 986 [20] Nandakumar, S., "A Framework for SDP Attributes when 987 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 988 (work in progress), February 2018. 990 Authors' Addresses 992 Gonzalo Camarillo 993 Ericsson 994 Hirsalantie 11 995 FI-02420 Jorvas 996 Finland 998 Email: Gonzalo.Camarillo@ericsson.com 1000 Tom Kristensen 1001 Cisco 1002 Philip Pedersens vei 1 1003 NO-1366 Lysaker 1004 Norway 1006 Email: tomkrist@cisco.com, tomkri@ifi.uio.no 1007 Christer Holmberg 1008 Ericsson 1009 Hirsalantie 11 1010 Jorvas 02420 1011 Finland 1013 Email: christer.holmberg@ericsson.com