idnits 2.17.00 (12 Aug 2021) /tmp/idnits53227/draft-ietf-bfcpbis-rfc4583bis-27.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 (December 8, 2018) is 1253 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) == Missing Reference: 'RFC XXXX' is mentioned on line 838, but not defined == Outdated reference: draft-ietf-bfcpbis-rfc4582bis has been published as RFC 8855 == Outdated reference: draft-ietf-mmusic-dtls-sdp has been published as RFC 8842 == Outdated reference: draft-ietf-mmusic-ice-sip-sdp has been published as RFC 8839 == Outdated reference: draft-ietf-mmusic-sdp-mux-attributes has been published as RFC 8859 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4582 (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (Obsoleted by RFC 8856) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: draft-ietf-mmusic-sdp-bundle-negotiation has been published as RFC 8843 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: June 11, 2019 C. Holmberg 7 Ericsson 8 December 8, 2018 10 Session Description Protocol (SDP) Format for Binary Floor Control 11 Protocol (BFCP) Streams 12 draft-ietf-bfcpbis-rfc4583bis-27 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 14. 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 June 11, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Floor Control Roles . . . . . . . . . . . . . . . . . . . . . 4 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' Attribute . . . . . . . . . . . . . . . . . 7 64 5.3. SDP 'userid' Attribute . . . . . . . . . . . . . . . . . 8 65 5.4. SDP 'floorid' Attribute . . . . . . . . . . . . . . . . . 9 66 5.5. SDP 'bfcpver' Attribute . . . . . . . . . . . . . . . . . 10 67 6. Multiplexing Considerations . . . . . . . . . . . . . . . . . 11 68 7. BFCP Connection Management . . . . . . . . . . . . . . . . . 12 69 7.1. TCP Connection Management . . . . . . . . . . . . . . . . 12 70 8. TLS/DTLS Considerations . . . . . . . . . . . . . . . . . . . 13 71 9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 10. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 14 73 10.1. Generating the Initial SDP Offer . . . . . . . . . . . . 15 74 10.2. Generating the SDP Answer . . . . . . . . . . . . . . . 15 75 10.3. Offerer Processing of the SDP Answer . . . . . . . . . . 16 76 10.4. Modifying the Session . . . . . . . . . . . . . . . . . 17 77 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 80 13.1. Registration of SDP 'proto' Values . . . . . . . . . . . 20 81 13.2. Registration of the SDP 'floorctrl' Attribute . . . . . 20 82 13.3. Registration of the SDP 'confid' Attribute . . . . . . . 20 83 13.4. Registration of the SDP 'userid' Attribute . . . . . . . 20 84 13.5. Registration of the SDP 'floorid' Attribute . . . . . . 21 85 13.6. Registration of the SDP 'bfcpver' Attribute . . . . . . 21 86 14. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 21 87 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 16.1. Normative References . . . . . . . . . . . . . . . . . . 22 90 16.2. Informational References . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 93 1. Introduction 95 As discussed in the BFCP (Binary Floor Control Protocol) 96 specification [I-D.ietf-bfcpbis-rfc4582bis], a given BFCP client 97 needs a set of data in order to establish a BFCP connection to a 98 floor control server. This data includes the transport address of 99 the server, the conference identifier, and the user identifier. 101 One way for clients to obtain this information is to use an SDP 102 offer/answer [RFC3264] exchange. This document specifies how to 103 encode this information in the SDP session descriptions that are part 104 of such an offer/answer exchange. 106 User agents typically use the offer/answer model to establish a 107 number of media streams of different types. Following this model, a 108 BFCP connection is described as any other media stream by using an 109 SDP 'm' line, possibly followed by a number of SDP lines that also 110 apply to the BFCP connection. 112 Section 4 defines how the field values in 'm' line representing a 113 BFCP connection are set. 115 Section 5 defines SDP attributes that are used when negotiating a 116 BFCP connection. 118 Section 6 defines multiplexing considerations for a BFCP connection. 120 Section 7 defines procedures for managing a BFCP connection. 122 Section 8 defines TLS and DTLS considerations when negotiating a BFCP 123 connection. 125 Section 9 defines the Interactive Connectivity Establishment (ICE) 126 [RFC8445] considerations when negotiating a BFCP connection. 128 Section 10 defines the SDP offer/answer procedures for negotiating a 129 BFCP connection. 131 2. Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 3. Floor Control Roles 141 When two endpoints establish a BFCP stream, they need to determine 142 which of them acts as a floor control client and which acts as a 143 floor control server. 145 Once the roles have been determined, the roles will apply to all 146 BFCP-controlled streams associated with the BFCP stream. 148 4. Fields in the 'm' Line 150 According to the SDP specification [RFC4566], the 'm' line format is 151 the following: 153 m= ... 155 This section describes how to generate an 'm' line of an SDP Media 156 Description ('m' section) describing a BFCP stream. 158 The media field MUST have a value of "application". 160 The port field is set depending on the value of the proto field, as 161 explained below. A port field value of zero has the standard SDP 162 meaning (i.e., rejection of the media stream) regardless of the proto 163 field. 165 When TCP is used as the transport, the port field is set following 166 the rules in [RFC4145]. Depending on the value of the 'setup' 167 attribute (discussed in Section 7.1), the port field contains the 168 port to which the remote endpoint will direct BFCP messages, or in 169 the case where the endpoint will initiate the connection towards 170 the remote endpoint, should be set to a value of 9. 172 When UDP is used as the transport, the port field contains the 173 port to which the remote endpoint will direct BFCP messages 174 regardless of the value of the 'setup' attribute. 176 This document defines five values for the proto field: TCP/BFCP, 177 TCP/DTLS/BFCP, TCP/TLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP. 179 The proto value are used as described below: 181 'TCP/BFCP' is used for TCP transport of BFCP without TLS 182 encryption, and is backward compatible with RFC 4583 compliant 183 endpoints. 185 'TCP/TLS/BFCP' is used for TCP transport of BFCP with TLS 186 encryption, and is backward compatible with RFC 4583 compliant 187 endpoints that support TLS. 189 'UDP/BFCP' is used for UDP transport of BFCP without DTLS 190 encryption [RFC6347]. 192 'UDP/TLS/BFCP' is used for UDP transport of BFCP with DTLS 193 encryption. This is one of the options when ICE is used 194 (Section 9). It can also be used without ICE when backward 195 compatibility with RFC 4583 compliant endpoints is not required. 197 'TCP/DTLS/BFCP' is used for TCP transport of BFCP with DTLS 198 encryption, running on top of TCP using the framing method defined 199 in [RFC4571], with DTLS packets being sent and received instead of 200 RTP/RTCP packets using the shim defined in RFC 4571 such that the 201 length field defined in RFC 4571 precedes each DTLS message. This 202 is one of the options when ICE is used (Section 9). It can also 203 be used without ICE when backward compatibility with RFC 4583 204 compliant endpoints is not required. 206 The fmt (format) list is not applicable to BFCP. The fmt list of 'm' 207 lines in the case of any proto field value related to BFCP MUST 208 contain a single "*" character. If the the fmt list contains any 209 other value it MUST be ignored. 211 The following is an example of an 'm' line for a BFCP connection: 213 m=application 50000 TCP/TLS/BFCP * 215 5. SDP Attributes 217 5.1. SDP 'floorctrl' Attribute 219 This section defines the SDP 'floorctrl' media-level attribute. The 220 attribute is used to determine the floor control roles (client and 221 server) for the endpoints associated with the BFCP stream. 223 Attribute Name: floorctrl 225 Attribute Value: floor-control 227 Usage Level: media 229 Charset Dependent: No 231 Mux Category: TBD 233 The Augmented BNF syntax [RFC5234] for the attribute is: 235 floor-control = role *(SP role) 236 role = "c-only" / "s-only" / "c-s" 238 An endpoint includes the attribute to indicate the role(s) it would 239 be willing to perform for the BFCP-controlled media streams: 241 c-only: The endpoint is willing to act as floor control client. 243 s-only: The endpoint is willing to act as floor control server only. 245 When inserted in an offer, the offerer MAY indicate multiple 246 attribute values ("c-only" and "s-only"). When inserted in an 247 answer, the answerer MUST indicate only one attribute value: "c-only" 248 or "s-only". The answerer indicates the role taken by the answerer. 249 The offerer will then take the opposite role. 251 In [RFC4583], there was a third attribute specified, "c-s", which 252 meant that an endpoint was willing to act as both floor control 253 client and floor control server at the same time for the BFCP stream, 254 taking different roles for different BFCP-controlled media streams. 255 The feature was underspecified and implemented in different ways, in 256 particular many implementations interpreted "c-s" to mean that the 257 endpoint is willing to act as either client or server (equivalent to 258 "c-only s-only"). An implementation compliant to this specification 259 MUST NOT include the "c-s" floorctl attribute value in an offer or in 260 an answer, but MUST accept the attribute value in an offer and 261 process it as equivalent to "c-only s-only" (or "s-only c-only"). 262 Also, as an implementation compliant to this specification is only 263 allowed to include one role, either 'c-only' or 's-conly', in an 264 answer, each endpoint will only take one role, and as a result the 265 endpoint will take the same role for each BFCP-controlled media 266 stream associated with the BFCP stream. 268 Table 1 shows the roles that the answerer is allowed to take, based 269 on what roles the offerer has indicated that it is willing to take. 271 +---------+----------+ 272 | Offerer | Answerer | 273 +---------+----------+ 274 | c-only | s-only | 275 | s-only | c-only | 276 | c-s | c-only | 277 | c-s | s-only | 278 +---------+----------+ 280 Table 1: Roles 282 Endpoints compliant with [RFC4583] might not include the 'floorctrl' 283 attribute in offers and answerer. If the 'floorctrl' attribute is 284 not present, in order to be interoperable with such endpoints, the 285 offerer will act as floor control client and the answerer will act as 286 floor control server. 288 The SDP Offer/Answer procedures for the 'floorctrl' attribute are 289 defined in Section 10. 291 The following is an example of a 'floorctrl' attribute in an offer: 293 a=floorctrl:c-only s-only 295 5.2. SDP 'confid' Attribute 297 This section defines the SDP 'confid' media-level attribute. The 298 attribute is used by a floor control server to convey the conference 299 ID value to the floor control client, using decimal integer 300 representation. 302 Attribute Name: confid 304 Attribute Value: conference-id 306 Usage Level: media 308 Charset Dependent: No 310 Mux Category: TBD 312 The Augmented BNF syntax [RFC5234] for the attribute is: 314 conference-id = 1*DIGIT 316 DIGIT = 318 The maximum value of the attribute is determined by the 319 COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis]. 321 The SDP Offer/Answer procedures for the 'confid' attribute are 322 defined in Section 10. 324 5.3. SDP 'userid' Attribute 326 This section defines the SDP userid' media-level attribute. The 327 attribute is used by a floor control server to convey the user ID 328 value to the floor control client, using decimal integer 329 representation. 331 Attribute Name: userid 333 Attribute Value: user-id 335 Usage Level: media 337 Charset Dependent: No 339 Mux Category: TBD 341 The Augmented BNF syntax [RFC5234] for the attribute is: 343 user-id = 1*DIGIT 345 DIGIT = 347 The maximum value of the attribute is determined by the 348 COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis]. 350 The SDP Offer/Answer procedures for the 'userid' attribute are 351 defined in Section 10. 353 5.4. SDP 'floorid' Attribute 355 This section defines the SDP 'floorid' media-level attribute. The 356 attribute conveys a floor identifier, using decimal integer 357 representation, and optionally pointers to one or more BFCP- 358 controlled media streams. 360 Attribute Name: floorid 362 Attribute Value: floor-id 364 Usage Level: media 366 Charset Dependent: No 368 Mux Category: TBD 370 The Augmented BNF syntax [RFC5234] for the attribute is: 372 floor-id = 1*DIGIT SP "mstrm:" token *(SP token) 374 DIGIT = 375 token = 377 The maximum value of the attribute is determined by the 378 FLOOR-ID format [I-D.ietf-bfcpbis-rfc4582bis]. 380 The floor identifier value is the integer representation of the Floor 381 ID to be used in BFCP. Each media stream pointer value is associated 382 with an SDP 'label' attribute [RFC4574] of a media stream. 384 The SDP Offer/Answer procedures for the 'floorid' attribute are 385 defined in Section 10. 387 Note: In [RFC4583] 'm-stream' was erroneously used in Section 11. 388 Although the example was non-normative, it is implemented by some 389 vendors and occurs in cases where the endpoint is willing to act 390 as a server. Therefore, it is RECOMMENDED to support parsing and 391 interpreting 'm-stream' the same way as 'mstrm' when receiving. 393 5.5. SDP 'bfcpver' Attribute 395 This section defines the SDP 'bfcpver' media-level attribute. The 396 attribute is used to negotiate the BFCP version, using decimal 397 integer representation. 399 The Augmented BNF syntax [RFC5234] for the attributes is: 401 Attribute Name: bfcpver 403 Attribute Value: bfcp-version 405 Usage Level: media 407 Charset Dependent: No 409 Mux Category: TBD 411 The Augmented BNF syntax [RFC5234] for the attribute is: 413 bfcp-version = version *(SP version) 414 version = 1*DIGIT 416 DIGIT = 418 The maximum value of the attribute is determined by the 419 COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis]. 421 An endpoint uses the 'bfcpver' attribute to convey the version(s) of 422 BFCP supported by the endpoint, using integer values. For a given 423 version, the attribute value representing the version MUST match the 424 "Version" field that would be presented in the BFCP COMMON-HEADER 425 [I-D.ietf-bfcpbis-rfc4582bis]. The BFCP version that will eventually 426 be used will be conveyed with a BFCP-level Hello/HelloAck. 428 Endpoints compliant with [RFC4583] might not always include the 429 'bfcpver' attribute in offers and answers. The attribute value, if 430 present, MUST be in accordance with the definition of the Version 431 field in [I-D.ietf-bfcpbis-rfc4582bis]. If the attribute is not 432 present, endpoints MUST assume a default value in accordance with 433 [I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport 434 the default attribute value is "1", and when used over an unreliable 435 transport the default attribute value is "2". The value is inferred 436 from the transport specified in the 'm' line (Section 4) of the 'm' 437 section associated with the stream. 439 The SDP Offer/Answer procedures for the 'bfcpver' attribute are 440 defined in Section 10. 442 6. Multiplexing Considerations 444 [I-D.ietf-mmusic-sdp-bundle-negotiation] defines how multiplexing of 445 multiple media streams can be negotiated. This specification does 446 not define how BFCP streams can be multiplexed with other media 447 streams. Therefore, a BFCP stream MUST NOT be associated with a 448 BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation]. Note that 449 BFCP-controlled media streams might be multiplexed with other media 450 streams. 452 [I-D.ietf-mmusic-sdp-mux-attributes] defines the mux categories for 453 the SDP attributes defined in this specification, except for the 454 'bfcpver' attribute. Table 2 defines the mux category for the 455 'bfcpver' attribute: 457 +---------+-------------------------------------+-------+-----------+ 458 | Name | Notes | Level | Mux | 459 | | | | Category | 460 +---------+-------------------------------------+-------+-----------+ 461 | bfcpver | Needs further analysis in a | M | TBD | 462 | | separate specification | | | 463 +---------+-------------------------------------+-------+-----------+ 465 Table 2: Multiplexing Attribute Analysis 467 7. BFCP Connection Management 469 BFCP streams can use TCP or UDP as the underlying transport. 470 Endpoints exchanging BFCP messages over UDP send the BFCP messages 471 towards the peer using the connection address and port provided in 472 the SDP 'c' and 'm' lines. TCP connection management is more 473 complicated and is described in the following Section. 475 Note: When using Interactive Connectivity Establishment (ICE) 476 [RFC8445], TCP/DTLS/BFCP, or UDP/TLS/BFCP, the straight-forward 477 procedures for connection management as UDP/BFCP described above 478 apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and 479 is described below. 481 7.1. TCP Connection Management 483 The management of the TCP connection used to transport BFCP messages 484 is performed using the SDP 'setup' and 'connection' attributes 485 [RFC4145]. The 'setup' attribute indicates which of the endpoints 486 initiates the TCP connection. The 'connection' attribute handles TCP 487 connection re-establishment. 489 The BFCP specification [I-D.ietf-bfcpbis-rfc4582bis] describes a 490 number of situations when the TCP connection between a floor control 491 client and the floor control server needs to be re-established. 492 However, that specification does not describe the re-establishment 493 process because this process depends on how the connection was 494 established in the first place. Endpoints using the offer/answer 495 mechanism follow the following rules. 497 When the existing TCP connection is closed and re-established 498 following the rules in [I-D.ietf-bfcpbis-rfc4582bis], the floor 499 control client MUST send an offer towards the floor control server in 500 order to re-establish the connection. If a TCP connection cannot 501 deliver a BFCP message and times out, the endpoint that attempted to 502 send the message (i.e., the one that detected the TCP timeout) MUST 503 send an offer in order to re-establish the TCP connection. 505 Endpoints that use the offer/answer mechanism to negotiate TCP 506 connections MUST support the 'setup' and 'connection' attributes. 508 8. TLS/DTLS Considerations 510 When DTLS is used with UDP, the generic procedures defined in 511 Section 5 of [I-D.ietf-mmusic-dtls-sdp] MUST be followed. 513 When TLS is used with TCP, once the underlying connection is 514 established, the answerer always acts as the TLS server. If the TCP 515 connection is lost, the active endpoint [RFC4583] is responsible for 516 re-establishing the TCP connection. Unless a new TLS connection is 517 negotiated, subsequent SDP offers and answers will not impact the 518 previously negotiated TLS roles. 520 Note: For TLS, it was decided to keep the original procedures in 521 [RFC4583] to determine which endpoint acts as the TLS server in 522 order to retain backwards compatibility. 524 9. ICE Considerations 526 Generic SDP offer/answer procedures for Interactive Connectivity 527 Establishment (ICE) are defined in [I-D.ietf-mmusic-ice-sip-sdp]. 529 When BFCP is used with UDP based ICE candidates [RFC8445] then the 530 procedures for UDP/TLS/BFCP are used. 532 When BFCP is used with TCP based ICE candidates [RFC6544] then the 533 procedures for TCP/DTLS/BFCP are used. 535 Based on the procedures defined in [I-D.ietf-mmusic-dtls-sdp], 536 endpoints treat all ICE candidate pairs associated with a BFCP stream 537 on top of a DTLS association as part of the same DTLS association. 538 Thus, there will only be one BFCP handshake and one DTLS handshake 539 even if there are multiple valid candidate pairs, and if BFCP media 540 is shifted between candidate pairs (including switching between UDP 541 to TCP candidate pairs) prior to nomination. If new candidates are 542 added, they will also be part of the same DTLS association. 544 In order to maximize the likelihood of interoperability between the 545 endpoints, all ICE enabled BFCP-over-DTLS endpoints SHOULD implement 546 support for UDP/TLS/BFCP. 548 When an SDP offer or answer conveys multiple ICE candidates for a 549 BFCP stream, UDP based candidates SHOULD be included and the default 550 candidate SHOULD be chosen from one of those UDP candidates. If UDP 551 transport is used for the default candidate, then the 'm' line proto 552 value MUST be 'UDP/TLS/BFCP'. If TCP transport is used for the 553 default candidate, the 'm' line proto value MUST be 'TCP/DTLS/BFCP'. 555 Note: Usage of ICE with protocols other than UDP/TLS/BFCP and 556 TCP/DTLS/BFCP is outside of scope for this specification. 558 10. SDP Offer/Answer Procedures 560 This section defines the SDP offer/answer [RFC3264] procedures for 561 negotiating and establishing a BFCP stream. Generic procedures for 562 DTLS are defined in [I-D.ietf-mmusic-dtls-sdp]. Generic procedures 563 for TLS are defined in [RFC8122]. 565 This section only defines the BFCP-specific procedures. Unless 566 explicitly stated otherwise, the procedures apply to an 'm' section 567 describing a BFCP stream. If an offer or answer contains multiple 568 'm' sections describing BFCP streams, the procedures are applied 569 independently to each stream. 571 Within this document, 'initial offer' refers to the first offer, 572 within an SDP session (e.g. a SIP dialog when the Session Initiation 573 Protocol (SIP) [RFC3261] is used to carry SDP) in which the offerer 574 indicates that it wants to negotiate the establishment of a BFCP 575 stream. 577 If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 578 'UDP/TLS/BFCP', the offerer and answerer follow the generic 579 procedures defined in [RFC8122]. 581 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/ 582 TCP' or 'UDP/TLS/BFCP', the offerer and answerer use the SDP 'setup' 583 attribute according to the procedures in [RFC4145]. 585 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 586 'TCP/DTLS/BFCP', the offerer and anwerer use the SDP 'connection' 587 attribute according to the procedures in [RFC4145]. 589 Note: The use of source-specific SDP parameters [RFC5576] is not 590 defined for BFCP streams. 592 10.1. Generating the Initial SDP Offer 594 When the offerer creates an initial offer, the offerer MUST include 595 an SDP 'floorctrl' attribute (Section 5.1) and an SDP 'bfcpver' 596 attribute (Section 5.5) in the 'm' section. 598 In addition, if the offerer includes an SDP 'floorctrl' attribute 599 with 's-only' or 'c-s' attribute values in the offer, the offerer: 601 o MUST include an SDP 'confid' attribute (Section 5.2) in the 'm' 602 section; and 604 o MUST include an SDP 'userid' attribute (Section 5.3) in the 'm' 605 section; and 607 o MUST include an SDP 'floorid' attribute (Section 5.4) in the 'm' 608 section; and 610 o MUST include an SDP 'label' attribute ([RFC4574]) with the 'm' 611 section of each BFCP-controlled media stream. 613 Note: If the offerer includes an SDP 'floorctrl' attribute with a 614 'c-s' attribute value, or both a 'c-only' and a 's-only' attribute 615 value in the offer, the attribute values above will only be used 616 if it is determined (Section 5.1) that the offerer will act as 617 floor control server. 619 10.2. Generating the SDP Answer 621 When the answerer receives an offer that contains an 'm' section 622 describing a BFCP stream, the answerer MUST check whether it supports 623 one or more of the BFCP versions supported by the offerer 624 (Section 5.5). If the answerer does not support any of the BFCP 625 versions, it MUST NOT accept the 'm' section. Otherwise, if the 626 answerer accepts the 'm' section, it: 628 o MUST insert a corresponding 'm' section in the answer, with an 629 identical 'm' line proto value [RFC3264]; and 631 o MUST include a 'bfcpver' attribute in the 'm' section. The 632 versions indicated by the answer MUST be the same or a subset of 633 the versions indicated by the offerer in the corresponding offer; 634 and 636 o MUST, if the offer contained an SDP 'floorctrl' attribute, include 637 a 'floorctrl' attribute in the 'm' section. 639 In addition, if the answerer includes an SDP 'floorctrl' attribute 640 with an 's-only' attribute value in the answer, the answerer: 642 o MUST include an SDP 'confid' attribute in the 'm' section; and 644 o MUST include an SDP 'userid' attribute in the 'm' section; and 646 o MUST include an SDP 'floorid' attribute in the 'm' section; and 648 o MUST include an SDP 'label' attribute in the 'm' section of each 649 BFCP-controlled media stream. 651 Note: An offerer compliant with [RFC4583] might not include 652 'floorctrl' and 'bfcpver' attributes in offers, in which cases the 653 default values apply. 655 Once the answerer has sent the answer, the answerer: 657 o MUST, if the answerer is the active endpoint, and if a TCP 658 connection associated with the 'm' section is to be established 659 (or re-established), initiate the establishing of the TCP 660 connection; and 662 o MUST, if the answerer is the active endpoint, and if an TLS/DTLS 663 connection associated with the 'm' section is to be established 664 (or re-established), initiate the establishing of the TLS/DTLS 665 connection (by sending a ClientHello message). 667 If the answerer does not accept the 'm' section in the offer, it MUST 668 assign a zero port value to the 'm' line of the corresponding 'm' 669 section in the answer. In addition, the answerer MUST NOT establish 670 a TCP connection or a TLS/DTLS connection associated with the 'm' 671 section. 673 10.3. Offerer Processing of the SDP Answer 675 When the offerer receives an answer that contains an 'm' section with 676 a non-zero port value, describing a BFCP stream, the offerer: 678 o MUST, if the offerer is the active endpoint, and if a TCP 679 connection associated with the 'm' section is to be established 680 (or re-established), initiate the establishing of the TCP 681 connection; and 683 o MUST, if the offerer is the active endpoint, and if an TLS/DTLS 684 connection associated with the 'm' section is to be established 685 (or re-established), initiate the establishing of the TLS/DTLS 686 connection (by sending a ClientHello message). 688 Note: An answerer compliant with [RFC4583] might not include 689 'floorctrl' and 'bfcpver' attributes in answers, in which cases the 690 default values apply. 692 If the 'm' line in the answer contains a zero port value, or if the 693 offerer for some other reason does not accept the answer (e.g., if 694 the answerer only indicates support of BFCP versions not supported by 695 the offerer), the offerer MUST NOT establish a TCP connection or a 696 TLS/DTLS connection associated with the 'm' section. 698 10.4. Modifying the Session 700 When an offerer sends an updated offer, in order to modify a 701 previously established BFCP stream, it follows the procedures in 702 Section 10.1, with the following exceptions: 704 o If the BFCP stream is carried on top of TCP, and if the offerer 705 does not want to re-establish an existing TCP connection, the 706 offerer MUST include an SDP 'connection' attribute with a value of 707 "existing", in the 'm' section; and 709 o If the offerer wants to disable a previously established BFCP 710 stream, it MUST assign a zero port value to the 'm' line 711 associated with the BFCP connection, following the procedures in 712 [RFC3264]. 714 11. Examples 716 For the purpose of brevity, the main portion of the session 717 description is omitted in the examples, which only show 'm' sections 718 and their 'm' lines and attributes. 720 The following is an example of an offer sent by a conference server 721 to a client. 723 m=application 50000 TCP/TLS/BFCP * 724 a=setup:actpass 725 a=connection:new 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 Note that due to RFC formatting conventions, this document splits SDP 741 across lines whose content would exceed 72 characters. A backslash 742 character marks where this line folding has taken place. This 743 backslash and its trailing CRLF and whitespace would not appear in 744 actual SDP content. 746 The following is the answer returned by the client. 748 m=application 9 TCP/TLS/BFCP * 749 a=setup:active 750 a=connection:new 751 a=fingerprint:sha-256 \ 752 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 753 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 754 a=floorctrl:c-only 755 a=bfcpver:1 756 m=audio 55000 RTP/AVP 0 757 m=video 55002 RTP/AVP 31 759 A similar example using unreliable transport and DTLS is shown below, 760 where the offer is sent from a client. 762 m=application 50000 UDP/TLS/BFCP * 763 a=setup:actpass 764 a=dtls-id:abc3dl 765 a=fingerprint:sha-256 \ 766 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 767 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 768 a=floorctrl:c-only s-only 769 a=confid:4321 770 a=userid:1234 771 a=floorid:1 mstrm:10 772 a=floorid:2 mstrm:11 773 a=bfcpver:1 2 774 m=audio 50002 RTP/AVP 0 775 a=label:10 776 m=video 50004 RTP/AVP 31 777 a=label:11 779 The following is the answer returned by the server. 781 m=application 55000 UDP/TLS/BFCP * 782 a=setup:active 783 a=dtls-id:abc3dl 784 a=fingerprint:sha-256 \ 785 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 786 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 787 a=floorctrl:s-only 788 a=confid:4321 789 a=userid:1234 790 a=floorid:1 mstrm:10 791 a=floorid:2 mstrm:11 792 a=bfcpver:2 793 m=audio 55002 RTP/AVP 0 794 m=video 55004 RTP/AVP 31 796 12. Security Considerations 798 The BFCP [I-D.ietf-bfcpbis-rfc4582bis], SDP [RFC4566], and offer/ 799 answer [RFC3264] specifications discuss security issues related to 800 BFCP, SDP, and offer/answer, respectively. In addition, [RFC4145] 801 and [RFC8122] discuss security issues related to the establishment of 802 TCP and TLS connections using an offer/answer model. Furthermore, 803 when using DTLS over UDP, the generic offer/answer considerations 804 defined in [I-D.ietf-mmusic-dtls-sdp] MUST be followed. 806 The usage of certain proto values in the SDP offer/answer negotiation 807 will result in a BFCP stream that is not protected by TLS or DTLS. 808 Operators will need to provide integrity protection and 809 confidentiality protection of the BFCP stream using other means. 811 The generic security considerations associated with SDP attributes 812 are defined in [RFC3264]. While the attributes defined in this 813 specification do not reveal information about the content of 814 individual BFCP controlled media streams, they do reveal which media 815 streams will be BFCP controlled. 817 13. IANA Considerations 819 [Editorial note: The changes in Section 13.1 instruct the IANA to 820 register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/ 821 BFCP for the SDP 'proto' field. The new section Section 5.5 822 registers a new SDP "bfcpver" attribute. The rest is unchanged 823 from [RFC4582].] 825 13.1. Registration of SDP 'proto' Values 827 The IANA is requested to register the following values for the SDP 828 'proto' field under the Session Description Protocol (SDP) Parameters 829 registry: 831 +---------------+------------+ 832 | Value | Reference | 833 +---------------+------------+ 834 | TCP/BFCP | [RFC XXXX] | 835 | TCP/DTLS/BFCP | [RFC XXXX] | 836 | TCP/TLS/BFCP | [RFC XXXX] | 837 | UDP/BFCP | [RFC XXXX] | 838 | UDP/TLS/BFCP | [RFC XXXX] | 839 +---------------+------------+ 841 Table 3: Values for the SDP 'proto' field 843 13.2. Registration of the SDP 'floorctrl' Attribute 845 This document defines the SDP attribute,'floorctrl'. The details of 846 the attribute are defined in Section 5.1. 848 13.3. Registration of the SDP 'confid' Attribute 850 This document defines the SDP attribute,'confid'. The details of the 851 attribute are defined in Section 5.2. 853 13.4. Registration of the SDP 'userid' Attribute 855 This document defines the SDP attribute,'userid'. The details of the 856 attribute are defined in Section 5.3. 858 13.5. Registration of the SDP 'floorid' Attribute 860 This document defines the SDP attribute,'floorid'. The details of 861 the attribute are defined in Section 5.4. 863 13.6. Registration of the SDP 'bfcpver' Attribute 865 This document defines the SDP attribute,'bfcpver'. The details of 866 the attribute are defined in Section 5.5. 868 14. Changes from RFC 4583 870 Following is the list of technical changes and other fixes from 871 [RFC4583]. 873 Main purpose of this work was to add signaling support necessary to 874 support BFCP over unreliable transport, as described in 875 [I-D.ietf-bfcpbis-rfc4582bis], resulting in the following changes: 877 1. Fields in the 'm' line (Section 4): 878 The section is re-written to remove reference to the exclusivity 879 of TCP as a transport for BFCP streams. The proto field values 880 TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added. 882 2. Security Considerations (Section 12): 883 For the DTLS over UDP case, mention existing considerations and 884 requirements for the offer/answer exchange in 885 [I-D.ietf-mmusic-dtls-sdp]. 887 3. Registration of SDP 'proto' Values (Section 13.1): 888 Register the three new values TCP/DTLS/BFCP, UDP/BFCP and 889 UDP/TLS/BFCP in the SDP parameters registry. 891 4. BFCP Version Negotiation (Section 5.5): 892 A new 'bfcpver' SDP media-level attribute is added in order to 893 signal supported version number. 895 In addition to the changes associated with support of BFCP over 896 unreliable transport, the possibility for an endpoint to act as both 897 floor control client and floor control server at the same time has 898 been removed. An endpoint will now take the same role for all BFCP- 899 controlled streams associated with the BFCP stream. 901 Clarification and bug fixes: 903 1. Errata ID: 712 (Section 3 and Section 10): 905 Language clarification. Don't use terms like an SDP attribute is 906 "used in an 'm' line", instead make clear that the attribute is a 907 media-level attribute. 909 2. Fix typo in example (Section 11): 910 Do not use 'm-stream' in the SDP example, use the correct 'mstrm' 911 as specified in Section 11. Recommend interpreting 'm-stream' if 912 it is received, since it is present in some implementations. 914 3. Assorted clarifications (Across the document): 915 Language clarifications as a result of reviews. Also, the 916 normative language where tightened where appropriate, i.e. 917 changed from SHOULD strength to MUST in a number of places. 919 15. Acknowledgements 921 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 922 Oscar Novo provided useful ideas for the original [RFC4583]. The 923 authors also acknowledge contributions to the revision of BFCP for 924 use over an unreliable transport from Geir Arne Sandbakken, Charles 925 Eckel, Alan Ford, Eoin McLeod and Mark Thompson. Useful and 926 important final reviews were done by Ali C. Begen, Mary Barnes and 927 Charles Eckel. In the final stages, Roman Shpount made a 928 considerable effort in adding proper ICE support and considerations. 930 16. References 932 16.1. Normative References 934 [I-D.ietf-bfcpbis-rfc4582bis] 935 Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 936 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 937 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 938 2015. 940 [I-D.ietf-mmusic-dtls-sdp] 941 Holmberg, C. and R. Shpount, "Session Description Protocol 942 (SDP) Offer/Answer Considerations for Datagram Transport 943 Layer Security (DTLS) and Transport Layer Security (TLS)", 944 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 945 2017. 947 [I-D.ietf-mmusic-ice-sip-sdp] 948 Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 949 "Session Description Protocol (SDP) Offer/Answer 950 procedures for Interactive Connectivity Establishment 951 (ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in 952 progress), November 2018. 954 [I-D.ietf-mmusic-sdp-mux-attributes] 955 Nandakumar, S., "A Framework for SDP Attributes when 956 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 957 (work in progress), February 2018. 959 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 960 Requirement Levels", BCP 14, RFC 2119, 961 DOI 10.17487/RFC2119, March 1997, . 964 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 965 A., Peterson, J., Sparks, R., Handley, M., and E. 966 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 967 DOI 10.17487/RFC3261, June 2002, . 970 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 971 with Session Description Protocol (SDP)", RFC 3264, 972 DOI 10.17487/RFC3264, June 2002, . 975 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 976 the Session Description Protocol (SDP)", RFC 4145, 977 DOI 10.17487/RFC4145, September 2005, . 980 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 981 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 982 July 2006, . 984 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 985 and RTP Control Protocol (RTCP) Packets over Connection- 986 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 987 2006, . 989 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 990 Protocol (SDP) Label Attribute", RFC 4574, 991 DOI 10.17487/RFC4574, August 2006, . 994 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 995 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 996 November 2006, . 998 [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format 999 for Binary Floor Control Protocol (BFCP) Streams", 1000 RFC 4583, DOI 10.17487/RFC4583, November 2006, 1001 . 1003 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1004 Specifications: ABNF", STD 68, RFC 5234, 1005 DOI 10.17487/RFC5234, January 2008, . 1008 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1009 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1010 January 2012, . 1012 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 1013 "TCP Candidates with Interactive Connectivity 1014 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 1015 March 2012, . 1017 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 1018 Transport over the Transport Layer Security (TLS) Protocol 1019 in the Session Description Protocol (SDP)", RFC 8122, 1020 DOI 10.17487/RFC8122, March 2017, . 1023 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1024 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1025 May 2017, . 1027 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1028 Connectivity Establishment (ICE): A Protocol for Network 1029 Address Translator (NAT) Traversal", RFC 8445, 1030 DOI 10.17487/RFC8445, July 2018, . 1033 16.2. Informational References 1035 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1036 Holmberg, C., Alvestrand, H., and C. Jennings, 1037 "Negotiating Media Multiplexing Using the Session 1038 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1039 negotiation-53 (work in progress), September 2018. 1041 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1042 Media Attributes in the Session Description Protocol 1043 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1044 . 1046 Authors' Addresses 1047 Gonzalo Camarillo 1048 Ericsson 1049 Hirsalantie 11 1050 FI-02420 Jorvas 1051 Finland 1053 Email: Gonzalo.Camarillo@ericsson.com 1055 Tom Kristensen 1056 Cisco 1057 Philip Pedersens vei 1 1058 NO-1366 Lysaker 1059 Norway 1061 Email: tomkrist@cisco.com, tomkri@ifi.uio.no 1063 Christer Holmberg 1064 Ericsson 1065 Hirsalantie 11 1066 Jorvas 02420 1067 Finland 1069 Email: christer.holmberg@ericsson.com