idnits 2.17.1 draft-ietf-bfcpbis-rfc4583bis-26.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 (October 2, 2018) is 2033 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 806, but not defined == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-21 ** 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: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-53 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-17 Summary: 4 errors (**), 0 flaws (~~), 5 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: April 5, 2019 C. Holmberg 7 Ericsson 8 October 2, 2018 10 Session Description Protocol (SDP) Format for Binary Floor Control 11 Protocol (BFCP) Streams 12 draft-ietf-bfcpbis-rfc4583bis-26 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 April 5, 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' Attributes . . . . . . . . . . . . . . . . . 7 64 5.3. SDP 'userid' Attribute . . . . . . . . . . . . . . . . . 8 65 5.4. SDP 'floorid' Attribute . . . . . . . . . . . . . . . . . 8 66 5.5. SDP 'bfcpver' Attribute . . . . . . . . . . . . . . . . . 9 67 6. Multiplexing Considerations . . . . . . . . . . . . . . . . . 10 68 7. BFCP Connection Management . . . . . . . . . . . . . . . . . 10 69 7.1. TCP Connection Management . . . . . . . . . . . . . . . . 11 70 8. TLS/DTLS Considerations . . . . . . . . . . . . . . . . . . . 11 71 9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 10. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 73 10.1. Generating the Initial SDP Offer . . . . . . . . . . . . 13 74 10.2. Generating the SDP Answer . . . . . . . . . . . . . . . 13 75 10.3. Offerer Processing of the SDP Answer . . . . . . . . . . 15 76 10.4. Modifying the Session . . . . . . . . . . . . . . . . . 15 77 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 13.1. Registration of SDP 'proto' Values . . . . . . . . . . . 18 81 13.2. Registration of the SDP 'floorctrl' Attribute . . . . . 18 82 13.3. Registration of the SDP 'confid' Attribute . . . . . . . 18 83 13.4. Registration of the SDP 'userid' Attribute . . . . . . . 18 84 13.5. Registration of the SDP 'floorid' Attribute . . . . . . 19 85 13.6. Registration of the SDP 'bfcpver' Attribute . . . . . . 19 86 14. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 19 87 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 16.1. Normative References . . . . . . . . . . . . . . . . . . 20 90 16.2. Informational References . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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. Typically, a client that establishes a BFCP 144 stream with a conference server will act as a floor control client, 145 while the conference server will act as a floor control server. 147 Once the roles have been determined, the roles will apply to all 148 BFCP-controlled streams associated with the BFCP stream. 150 4. Fields in the 'm' Line 152 This section describes how to generate an 'm' line for a BFCP stream. 154 According to the SDP specification [RFC4566], the 'm' line format is 155 the following: 157 m= ... 159 The media field MUST have a value of "application". 161 The port field is set depending on the value of the proto field, as 162 explained below. A port field value of zero has the standard SDP 163 meaning (i.e., rejection of the media stream) regardless of the proto 164 field. 166 When TCP is used as the transport, the port field is set following 167 the rules in [RFC4145]. Depending on the value of the 'setup' 168 attribute (discussed in Section 7.1), the port field contains the 169 port to which the remote endpoint will direct BFCP messages, or in 170 the case where the endpoint will initiate the connection towards 171 the remote endpoint, should be set to a value of 9. 173 When UDP is used as the transport, the port field contains the 174 port to which the remote endpoint will direct BFCP messages 175 regardless of the value of the 'setup' attribute. 177 This document defines five values for the proto field: TCP/BFCP, 178 TCP/DTLS/BFCP, TCP/TLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP. 180 The proto value are used as described below: 182 'TCP/BFCP' is used for TCP transport of BFCP without TLS 183 encryption, and is backward compatible with RFC 4583 compliant 184 endpoints. 186 'TCP/TLS/BFCP' is used for TCP transport of BFCP with TLS 187 encryption, and is backward compatible with RFC 4583 compliant 188 endpoints that support TLS. 190 'UDP/BFCP' is used for UDP transport of BFCP without DTLS 191 encryption [RFC6347]. 193 'UDP/TLS/BFCP' is used for UDP transport of BFCP with DTLS 194 encryption. This is one of the options when ICE is used 195 (Section 9). It can also be used without ICE when backward 196 compatibility with RFC 4583 compliant endpoints is not required. 198 'TCP/DTLS/BFCP' is used for TCP transport of BFCP with DTLS 199 encryption, running on top of TCP using the framing method defined 200 in [RFC4571], with DTLS packets being sent and received instead of 201 RTP/RTCP packets using the shim defined in RFC 4571 such that the 202 length field defined in RFC 4571 precedes each DTLS message. This 203 is one of the options when ICE is used (Section 9). It can also 204 be used without ICE when backward compatibility with RFC 4583 205 compliant endpoints is not required. 207 The fmt (format) list is not applicable to BFCP. The fmt list of 'm' 208 lines in the case of any proto field value related to BFCP MUST 209 contain a single "*" character. If the the fmt list contains any 210 other value it is ignored. 212 The following is an example of an 'm' line for a BFCP connection: 214 m=application 50000 TCP/TLS/BFCP * 216 5. SDP Attributes 218 5.1. SDP 'floorctrl' Attribute 220 This section defines the SDP 'floorctrl' media-level attribute. The 221 attribute is used to determine the floor control roles (client and 222 server) for the endpoints associated with the BFCP stream. 224 Attribute Name: floorctrl 226 Attribute Value: floor-control 228 Usage Level: media 230 Charset Dependent: No 232 Mux Category: TBD 234 The Augmented BNF syntax [RFC5234] for the attribute is: 236 floor-control = role *(SP role) 237 role = "c-only" / "s-only" / "c-s" 239 An endpoint includes the attribute to indicate the role(s) it would 240 be willing to perform for the BFCP-controlled media streams: 242 c-only: The endpoint is willing to act as floor control client. 244 s-only: The endpoint is willing to act as floor control server only. 246 When inserted in an offer, the offerer MAY indicate multiple 247 attribute values ("c-only" and "s-only"). When inserted in an 248 answer, the answerer MUST indicate only one attribute value: "c-only" 249 or "s-only". The offerer indicates which floor control role(s) that 250 it is willing to take. The answerer indicates the role taken by the 251 answerer. Based on this, the floor control role of the offerer is 252 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-only | 260 | c-s | s-only | 261 +---------+----------+ 263 Table 1: Roles 265 In [RFC4583], there was a third attribute specified, "c-s", which 266 meant that an endpoint was willing to act as both floor control 267 client and floor control server at the same time for the BFCP stream, 268 taking different roles for different BFCP-controlled media streams. 269 The feature was underspecified and implemented in different ways, in 270 particular many implementations interpreted "c-s" to mean that the 271 endpoint is willing to act as either client or server (equivalent to 272 "c-only s-only"). An implementation compliant to this specification 273 MUST NOT include the "c-s" floorctl attribute value in an offer or in 274 an answer, but MUST accept the attribute value in an offer and 275 process it as equivalent to "c-only s-only" (or "s-only c-only"). As 276 a result, each endpoint will take the same role for each BFCP- 277 controlled media stream associated with the BFCP stream. 279 Endpoints compliant with [RFC4583] might not include the 'floorctrl' 280 attribute in offers and answerer. If the 'floorctrl' attribute is 281 not present the offerer will act as floor control client, and the 282 answerer will act as floor control server. 284 The SDP Offer/Answer procedures for the 'floorctrl' attribute are 285 defined in Section 10. 287 The following is an example of a 'floorctrl' attribute in an offer: 289 a=floorctrl:c-only s-only 291 5.2. SDP 'confid' Attributes 293 This section defines the SDP 'confid' media-level attribute. The 294 attribute is used by a floor control server to convey the conference 295 ID value to the floor control client, using decimal integer 296 representation. 298 Attribute Name: confid 300 Attribute Value: conference-id 302 Usage Level: media 304 Charset Dependent: No 306 Mux Category: TBD 308 The Augmented BNF syntax [RFC5234] for the attribute is: 310 conference-id = 1*DIGIT 312 DIGIT = 314 The SDP Offer/Answer procedures for the 'confid' attribute are 315 defined in Section 10. 317 5.3. SDP 'userid' Attribute 319 This section defines the SDP userid' media-level attribute. The 320 attribute is used by a floor control server to convey the user ID 321 value to the floor control client, using decimal integer 322 representation. 324 Attribute Name: userid 326 Attribute Value: user-id 328 Usage Level: media 330 Charset Dependent: No 332 Mux Category: TBD 334 The Augmented BNF syntax [RFC5234] for the attribute is: 336 user-id = 1*DIGIT 338 DIGIT = 340 The SDP Offer/Answer procedures for the 'userid' attribute are 341 defined in Section 10. 343 5.4. SDP 'floorid' Attribute 345 This section defines the SDP 'floorid' media-level attribute. The 346 attribute conveys a floor identifier, and optionally pointers to one 347 or more BFCP-controlled media streams. 349 Attribute Name: floorid 351 Attribute Value: floor-id 353 Usage Level: media 355 Charset Dependent: No 357 Mux Category: TBD 359 The Augmented BNF syntax [RFC5234] for the attribute is: 361 floor-id = 1*DIGIT SP "mstrm:" token *(SP token) 363 DIGIT = 364 token = 366 The floor identifier value is the integer representation of the Floor 367 ID to be used in BFCP. Each media stream pointer value is associated 368 with an SDP 'label' attribute [RFC4574] of a media stream. 370 The SDP Offer/Answer procedures for the 'floorid' attribute are 371 defined in Section 10. 373 Note: In [RFC4583] 'm-stream' was erroneously used in Section 11. 374 Although the example was non-normative, it is implemented by some 375 vendors and occurs in cases where the endpoint is willing to act 376 as a server. Therefore, it is RECOMMENDED to support parsing and 377 interpreting 'm-stream' the same way as 'mstrm' when receiving. 379 5.5. SDP 'bfcpver' Attribute 381 This section defines the SDP 'bfcpver' media-level attribute. The 382 attribute is used to negotiate the BFCP version. 384 The Augmented BNF syntax [RFC5234] for the attributes is: 386 Attribute Name: bfcpver 388 Attribute Value: bfcp-version 390 Usage Level: media 392 Charset Dependent: No 394 Mux Category: TBD 396 The Augmented BNF syntax [RFC5234] for the attribute is: 398 bfcp-version = version *(SP version) 399 version = 1*DIGIT 401 DIGIT = 403 An endpoint uses the 'bfcpver' attribute to convey the version(s) of 404 BFCP supported by the endpoint, using integer values. For a given 405 version, the attribute value representing the version MUST match the 406 "Version" field that would be presented in the BFCP COMMON-HEADER 407 [I-D.ietf-bfcpbis-rfc4582bis]. The BFCP version that will eventually 408 be used will be conveyed with a BFCP-level Hello/HelloAck. 410 Endpoints compliant with [RFC4583] might not always include the 411 'bfcpver' attribute in offers and answers. The attribute value, if 412 present, MUST be in accordance with the definition of the Version 413 field in [I-D.ietf-bfcpbis-rfc4582bis]. If the attribute is not 414 present, endpoints MUST assume a default value in accordance with 415 [I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport 416 the default attribute value is "1", and when used over an unreliable 417 transport the default attribute value is "2". The value is inferred 418 from the transport specified in the 'm' line (Section 4) associated 419 with the stream. 421 The SDP Offer/Answer procedures for the 'bfcpver' attribute are 422 defined in Section 10. 424 6. Multiplexing Considerations 426 [I-D.ietf-mmusic-sdp-bundle-negotiation] defines how multiplexing of 427 multiple media streams can be negotiated. This specification does 428 not define how BFCP streams can be multiplexed with other media 429 streams. Therefore, a BFCP stream MUST NOT be associated with a 430 BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation]. Note that 431 BFCP-controlled media streams might be multiplexed with other media 432 streams. 434 [I-D.ietf-mmusic-sdp-mux-attributes] defines the mux categories for 435 the SDP attributes defined in this specification. Table 2 defines 436 the mux category for the 'bfcpver' attribute: 438 +---------+-------------------------------------+-------+-----------+ 439 | Name | Notes | Level | Mux | 440 | | | | Category | 441 +---------+-------------------------------------+-------+-----------+ 442 | bfcpver | Needs further analysis in a | M | TBD | 443 | | separate specification | | | 444 +---------+-------------------------------------+-------+-----------+ 446 Table 2: Multiplexing Attribute Analysis 448 7. BFCP Connection Management 450 BFCP streams can use TCP or UDP as the underlying transport. 451 Endpoints exchanging BFCP messages over UDP send the BFCP messages 452 towards the peer using the connection address and port provided in 453 the SDP 'c' and 'm' lines. TCP connection management is more 454 complicated and is described in the following Section. 456 Note: When using Interactive Connectivity Establishment (ICE) 457 [RFC8445], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward 458 procedures for connection management as UDP/BFCP described above 459 apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and 460 is described below. 462 7.1. TCP Connection Management 464 The management of the TCP connection used to transport BFCP messages 465 is performed using the SDP 'setup' and 'connection' attributes 466 [RFC4145]. The 'setup' attribute indicates which of the endpoints 467 initiates the TCP connection. The 'connection' attribute handles TCP 468 connection re-establishment. 470 The BFCP specification [I-D.ietf-bfcpbis-rfc4582bis] describes a 471 number of situations when the TCP connection between a floor control 472 client and the floor control server needs to be re-established. 473 However, that specification does not describe the re-establishment 474 process because this process depends on how the connection was 475 established in the first place. Endpoints using the offer/answer 476 mechanism follow the following rules. 478 When the existing TCP connection is closed and re-established 479 following the rules in [I-D.ietf-bfcpbis-rfc4582bis], the floor 480 control client MUST send an offer towards the floor control server in 481 order to re-establish the connection. If a TCP connection cannot 482 deliver a BFCP message and times out, the endpoint that attempted to 483 send the message (i.e., the one that detected the TCP timeout) MUST 484 send an offer in order to re-establish the TCP connection. 486 Endpoints that use the offer/answer mechanism to negotiate TCP 487 connections MUST support the 'setup' and 'connection' attributes. 489 8. TLS/DTLS Considerations 491 When DTLS is used with UDP, the generic procedures defined in 492 Section 5 of [I-D.ietf-mmusic-dtls-sdp] MUST be followed. 494 When TLS is used with TCP, once the underlying connection is 495 established, the answerer always acts as the TLS server. If the TCP 496 connection is lost, the active endpoint is responsible for re- 497 establishing the TCP connection. Unless a new TLS session is 498 negotiated, subsequent SDP offers and answers will not impact the 499 previously negotiated TLS roles. 501 Note: For TLS, it was decided to keep the original procedures in 502 [RFC4583] to determine which endpoint acts as the TLS server in 503 order to retain backwards compatibility. 505 9. ICE Considerations 507 Generic SDP offer/answer procedures for Interactive Connectivity 508 Establishment (ICE) are defined in [I-D.ietf-mmusic-ice-sip-sdp]. 510 When BFCP is used with UDP based ICE candidates [RFC8445] then the 511 procedures for UDP/TLS/BFCP are used. 513 When BFCP is used with TCP based ICE candidates [RFC6544] then the 514 procedures for TCP/DTLS/BFCP are used. 516 Based on the procedures defined in [I-D.ietf-mmusic-dtls-sdp], 517 endpoints treat all ICE candidate pairs associated with a BFCP stream 518 on top of a DTLS association as part of the same DTLS association. 519 Thus, there will only be one BFCP handshake and one DTLS handshake 520 even if there are multiple valid candidate pairs, and if BFCP media 521 is shifted between candidate pairs (including switching between UDP 522 to TCP candidate pairs) prior to nomination. If new candidates are 523 added, they will also be part of the same DTLS association. 525 In order to maximize the likelihood of interoperability between the 526 endpoints, all ICE enabled BFCP-over-DTLS endpoints SHOULD implement 527 support for UDP/TLS/BFCP. 529 When an SDP offer or answer conveys multiple ICE candidates for a 530 BFCP stream, UDP based candidates SHOULD be included and the default 531 candidate SHOULD be chosen from one of those UDP candidates. If UDP 532 transport is used for the default candidate, then the 'm' line proto 533 value MUST be 'UDP/TLS/BFCP'. If TCP transport is used for the 534 default candidate, the 'm' line proto value MUST be 'TCP/DTLS/BFCP'. 536 Note: Usage of ICE with protocols other than UDP/TLS/BFCP and 537 TCP/DTLS/BFCP is outside of scope for this specification. 539 10. SDP Offer/Answer Procedures 541 This section defines the SDP offer/answer [RFC3264] procedures for 542 negotiating and establishing a BFCP stream. Generic procedures for 543 DTLS are defined in [I-D.ietf-mmusic-dtls-sdp]. Generic procedures 544 for TLS are defined in [RFC8122]. 546 This section only defines the BFCP-specific procedures. Unless 547 explicitly stated otherwise, the procedures apply to an 'm' line 548 describing a BFCP stream. If an offer or answer contains multiple 549 'm' lines describing BFCP streams, the procedures are applied 550 independently to each stream. 552 Within this document, 'initial offer' refers to the first offer, 553 within an SDP session (e.g. a SIP dialog when the Session Initiation 554 Protocol (SIP) [RFC3261] is used to carry SDP), in which the offerer 555 indicates that it wants to negotiate the establishment of a BFCP 556 stream. 558 If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 559 'UDP/TLS/BFCP', the offerer and answerer follow the generic 560 procedures defined in [RFC8122]. 562 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/ 563 TCP' or 'UDP/TLS/BFCP', the offerer and answerer use the SDP 'setup' 564 attribute according to the procedures in [RFC4145]. 566 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 567 'TCP/DTLS/BFCP', the offerer and anwerer use the SDP 'connection' 568 attribute according to the procedures in [RFC4145]. 570 Note: The use of source-specific SDP parameters [RFC5576] is not 571 defined for BFCP streams. 573 10.1. Generating the Initial SDP Offer 575 When the offerer creates an initial offer, the offerer MUST associate 576 an SDP 'floorctrl' attribute (Section 5.1) and an SDP 'bfcpver' 577 attribute (Section 5.5) with the 'm' line. 579 In addition, if the offerer includes an SDP 'floorctrl' attribute 580 with 's-only' or 'c-s' attribute values in the offer, the offerer: 582 o MUST associate an SDP 'confid' attribute (Section 5.2) with the 583 'm' line; and 585 o MUST associate an SDP 'userid' attribute (Section 5.3) with the 586 'm' line; and 588 o MUST associate an SDP 'floorid' attribute (Section 5.4) with the 589 'm' line; and 591 o MUST associate an SDP 'label' attribute ([RFC4574]) with the 'm' 592 line of each BFCP-controlled media stream. 594 Note: If the offerer includes an SDP 'floorctrl' attribute with a 595 'c-s' attribute value, or both a 'c-only' and a 's-only' attribute 596 value, in the offer, the attribute values above will only be used 597 if it is determined (Section 5.1) that the offerer will act as 598 floor control server. 600 10.2. Generating the SDP Answer 602 When the answerer receives an offer that contains an 'm' line 603 describing a BFCP stream, the answerer MUST check whether it supports 604 one or more of the BFCP versions supported by the offerer 605 (Section 5.5). If the answerer does not support any of the BFCP 606 versions, it MUST NOT accept the 'm' line. Otherwise, if the 607 answerer accepts the 'm' line, it: 609 o MUST insert a corresponding 'm' line in the answer, with an 610 identical 'm' line proto value [RFC3264]; and 612 o MUST associate a 'bfcpver' attribute with the 'm' line. The 613 answerer only indicates support of BFCP versions also supported by 614 the offerer; and 616 o MUST, if the offer contained an SDP 'floorctrl' attribute, 617 associate a 'floorctrl' attribute with the 'm' line. 619 In addition, if the answerer includes an SDP 'floorctrl' attribute 620 with an 's-only' attribute value in the answer, the answerer: 622 o MUST associate an SDP 'confid' attribute with the 'm' line; and 624 o MUST associate an SDP 'userid' attribute with the 'm' line; and 626 o MUST associate an SDP 'floorid' attribute with the 'm' line; and 628 o MUST associate an SDP 'label' attribute with the 'm' line of each 629 BFCP-controlled media stream. 631 Note: An offerer compliant with [RFC4583] might not include 632 'floorctrl' and 'bfcpver' attributes in offers, in which cases the 633 default values apply. 635 Once the answerer has sent the answer, the answerer: 637 o MUST, if the answerer is the 'active' endpoint, and if a TCP 638 connection associated with the 'm' line is to be established (or 639 re-established), initiate the establishing of the TCP connection; 640 and 642 o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS 643 connection associated with the 'm' line is to be established (or 644 re-established), initiate the establishing of the TLS/DTLS 645 connection (by sending a ClientHello message). 647 If the answerer does not accept the 'm' line in the offer, it MUST 648 assign a zero port value to the corresponding 'm' line in the answer. 649 In addition, the answerer MUST NOT establish a TCP connection or a 650 TLS/DTLS connection associated with the 'm' line. 652 10.3. Offerer Processing of the SDP Answer 654 When the offerer receives an answer, which contains an 'm' line with 655 a non-zero port value, describing a BFCP stream, the offerer: 657 o MUST, if the offerer is the 'active' endpoint, and if a TCP 658 connection associated with the 'm' line is to be established (or 659 re-established), initiate the establishing of the TCP connection; 660 and 662 o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS 663 connection associated with the 'm' line is to be established (or 664 re-established), initiate the establishing of the TLS/DTLS 665 connection (by sending a ClientHello message). 667 Note: An answerer compliant with [RFC4583] might not include 668 'floorctrl' and 'bfcpver' attributes in answers, in which cases 669 the default values apply. 671 If the 'm' line in the answer contains a zero port value, or if the 672 offerer for some other reason does not accept the answer (e.g., if 673 the answerer only indicates support of BFCP versions not supported by 674 the offerer), the offerer MUST NOT establish a TCP connection or a 675 TLS/DTLS connection associated with the 'm' line. 677 10.4. Modifying the Session 679 When an offerer sends an updated offer, in order to modify a 680 previously established BFCP stream, it follows the procedures in 681 Section 10.1, with the following exceptions: 683 o If the BFCP stream is carried on top of TCP, and if the offerer 684 does not want to re-establish an existing TCP connection, the 685 offerer MUST associate an SDP 'connection' attribute with a value 686 of "existing", with the 'm' line; and 688 o If the offerer wants to disable a previously established BFCP 689 stream, it MUST assign a zero port value to the 'm' line 690 associated with the BFCP connection, following the procedures in 691 [RFC3264]. 693 11. Examples 695 For the purpose of brevity, the main portion of the session 696 description is omitted in the examples, which only show 'm' lines and 697 their attributes. 699 The following is an example of an offer sent by a conference server 700 to a client. 702 m=application 50000 TCP/TLS/BFCP * 703 a=setup:actpass 704 a=connection:new 705 a=fingerprint:sha-256 \ 706 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 707 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 708 a=floorctrl:c-only s-only 709 a=confid:4321 710 a=userid:1234 711 a=floorid:1 mstrm:10 712 a=floorid:2 mstrm:11 713 a=bfcpver:1 2 714 m=audio 50002 RTP/AVP 0 715 a=label:10 716 m=video 50004 RTP/AVP 31 717 a=label:11 719 Note that due to RFC formatting conventions, this document splits SDP 720 across lines whose content would exceed 72 characters. A backslash 721 character marks where this line folding has taken place. This 722 backslash and its trailing CRLF and whitespace would not appear in 723 actual SDP content. 725 The following is the answer returned by the client. 727 m=application 9 TCP/TLS/BFCP * 728 a=setup:active 729 a=connection:new 730 a=fingerprint:sha-256 \ 731 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 732 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 733 a=floorctrl:c-only 734 a=bfcpver:1 735 m=audio 55000 RTP/AVP 0 736 m=video 55002 RTP/AVP 31 738 A similar example using unreliable transport and DTLS is shown below, 739 where the offer is sent from a client. 741 m=application 50000 UDP/TLS/BFCP * 742 a=setup:actpass 743 a=dtls-id:abc3dl 744 a=fingerprint:sha-256 \ 745 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 746 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 747 a=floorctrl:c-only s-only 748 a=confid:4321 749 a=userid:1234 750 a=floorid:1 mstrm:10 751 a=floorid:2 mstrm:11 752 a=bfcpver:1 2 753 m=audio 50002 RTP/AVP 0 754 a=label:10 755 m=video 50004 RTP/AVP 31 756 a=label:11 758 The following is the answer returned by the server. 760 m=application 55000 UDP/TLS/BFCP * 761 a=setup:active 762 a=dtls-id:abc3dl 763 a=fingerprint:sha-256 \ 764 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 765 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 766 a=floorctrl:s-only 767 a=confid:4321 768 a=userid:1234 769 a=floorid:1 mstrm:10 770 a=floorid:2 mstrm:11 771 a=bfcpver:2 772 m=audio 55002 RTP/AVP 0 773 m=video 55004 RTP/AVP 31 775 12. Security Considerations 777 The BFCP [I-D.ietf-bfcpbis-rfc4582bis], SDP [RFC4566], and offer/ 778 answer [RFC3264] specifications discuss security issues related to 779 BFCP, SDP, and offer/answer, respectively. In addition, [RFC4145] 780 and [RFC8122] discuss security issues related to the establishment of 781 TCP and TLS connections using an offer/answer model. Furthermore, 782 when using DTLS over UDP, the generic offer/answer considerations 783 defined in [I-D.ietf-mmusic-dtls-sdp] MUST be followed. 785 13. IANA Considerations 787 [Editorial note: The changes in Section 13.1 instruct the IANA to 788 register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/ 789 BFCP for the SDP 'proto' field. The new section Section 5.5 790 registers a new SDP "bfcpver" attribute. The rest is unchanged 791 from [RFC4582].] 793 13.1. Registration of SDP 'proto' Values 795 The IANA has registered the following values for the SDP 'proto' 796 field under the Session Description Protocol (SDP) Parameters 797 registry: 799 +---------------+------------+ 800 | Value | Reference | 801 +---------------+------------+ 802 | TCP/BFCP | [RFC XXXX] | 803 | TCP/DTLS/BFCP | [RFC XXXX] | 804 | TCP/TLS/BFCP | [RFC XXXX] | 805 | UDP/BFCP | [RFC XXXX] | 806 | UDP/TLS/BFCP | [RFC XXXX] | 807 +---------------+------------+ 809 Table 3: Values for the SDP 'proto' field 811 13.2. Registration of the SDP 'floorctrl' Attribute 813 This document defines the SDP attribute,'floorctrl'. The details of 814 the attribute are defined in Section 5.1. 816 For issues regarding this attribute contact iesg@ietf.org. 818 13.3. Registration of the SDP 'confid' Attribute 820 This document defines the SDP attribute,'confid'. The details of the 821 attribute are defined in Section 5.2. 823 For issues regarding this attribute contact iesg@ietf.org. 825 13.4. Registration of the SDP 'userid' Attribute 827 This document defines the SDP attribute,'userid'. The details of the 828 attribute are defined in Section 5.3. 830 For issues regarding this attribute contact iesg@ietf.org. 832 13.5. Registration of the SDP 'floorid' Attribute 834 This document defines the SDP attribute,'floorid'. The details of 835 the attribute are defined in Section 5.4. 837 For issues regarding this attribute contact iesg@ietf.org. 839 13.6. Registration of the SDP 'bfcpver' Attribute 841 This document defines the SDP attribute,'bfcpver'. The details of 842 the attribute are defined in Section 5.5. 844 For issues regarding this attribute contact iesg@ietf.org. 846 14. Changes from RFC 4583 848 Following is the list of technical changes and other fixes from 849 [RFC4583]. 851 Main purpose of this work was to add signaling support necessary to 852 support BFCP over unreliable transport, as described in 853 [I-D.ietf-bfcpbis-rfc4582bis], resulting in the following changes: 855 1. Fields in the 'm' line (Section 4): 856 The section is re-written to remove reference to the exclusivity 857 of TCP as a transport for BFCP streams. The proto field values 858 TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added. 860 2. Authentication (Section 8): 861 In last paragraph, made clear that a TCP connection was 862 described. 864 3. Security Considerations (Section 12): 865 For the DTLS over UDP case, mention existing considerations and 866 requirements for the offer/answer exchange in 867 [I-D.ietf-mmusic-dtls-sdp]. 869 4. Registration of SDP 'proto' Values (Section 13.1): 870 Register the three new values TCP/DTLS/BFCP, UDP/BFCP and 871 UDP/TLS/BFCP in the SDP parameters registry. 873 5. BFCP Version Negotiation (Section 5.5): 874 A new 'bfcpver' SDP media-level attribute is added in order to 875 signal supported version number. 877 In addition to the changes associated with support of BFCP over 878 unreliable transport, the possibility for an endpoint to act as both 879 floor control client and floor control server at the same time has 880 been removed. An endpoint will now take the same role for all BFCP- 881 controlled streams associated with the BFCP stream. 883 Clarification and bug fixes: 885 1. Errata ID: 712 (Section 3 and Section 10): 886 Language clarification. Don't use terms like an SDP attribute is 887 "used in an 'm' line", instead make clear that the attribute is a 888 media-level attribute. 890 2. Fix typo in example (Section 11): 891 Do not use 'm-stream' in the SDP example, use the correct 'mstrm' 892 as specified in Section 11. Recommend interpreting 'm-stream' if 893 it is received, since it is present in some implementations. 895 3. Assorted clarifications (Across the document): 896 Language clarifications as a result of reviews. Also, the 897 normative language where tightened where appropriate, i.e. 898 changed from SHOULD strength to MUST in a number of places. 900 15. Acknowledgements 902 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 903 Oscar Novo provided useful ideas for the original [RFC4583]. The 904 authors also acknowledge contributions to the revision of BFCP for 905 use over an unreliable transport from Geir Arne Sandbakken, Charles 906 Eckel, Alan Ford, Eoin McLeod and Mark Thompson. Useful and 907 important final reviews were done by Ali C. Begen, Mary Barnes and 908 Charles Eckel. In the final stages, Roman Shpount made a 909 considerable effort in adding proper ICE support and considerations. 911 16. References 913 16.1. Normative References 915 [I-D.ietf-bfcpbis-rfc4582bis] 916 Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 917 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 918 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 919 2015. 921 [I-D.ietf-mmusic-dtls-sdp] 922 Holmberg, C. and R. Shpount, "Session Description Protocol 923 (SDP) Offer/Answer Considerations for Datagram Transport 924 Layer Security (DTLS) and Transport Layer Security (TLS)", 925 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 926 2017. 928 [I-D.ietf-mmusic-ice-sip-sdp] 929 Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 930 "Session Description Protocol (SDP) Offer/Answer 931 procedures for Interactive Connectivity Establishment 932 (ICE)", draft-ietf-mmusic-ice-sip-sdp-21 (work in 933 progress), June 2018. 935 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 936 Requirement Levels", BCP 14, RFC 2119, 937 DOI 10.17487/RFC2119, March 1997, . 940 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 941 A., Peterson, J., Sparks, R., Handley, M., and E. 942 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 943 DOI 10.17487/RFC3261, June 2002, . 946 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 947 with Session Description Protocol (SDP)", RFC 3264, 948 DOI 10.17487/RFC3264, June 2002, . 951 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 952 the Session Description Protocol (SDP)", RFC 4145, 953 DOI 10.17487/RFC4145, September 2005, . 956 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 957 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 958 July 2006, . 960 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 961 and RTP Control Protocol (RTCP) Packets over Connection- 962 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 963 2006, . 965 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 966 Protocol (SDP) Label Attribute", RFC 4574, 967 DOI 10.17487/RFC4574, August 2006, . 970 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 971 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 972 November 2006, . 974 [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format 975 for Binary Floor Control Protocol (BFCP) Streams", 976 RFC 4583, DOI 10.17487/RFC4583, November 2006, 977 . 979 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 980 Specifications: ABNF", STD 68, RFC 5234, 981 DOI 10.17487/RFC5234, January 2008, . 984 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 985 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 986 January 2012, . 988 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 989 "TCP Candidates with Interactive Connectivity 990 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 991 March 2012, . 993 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 994 Transport over the Transport Layer Security (TLS) Protocol 995 in the Session Description Protocol (SDP)", RFC 8122, 996 DOI 10.17487/RFC8122, March 2017, . 999 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1000 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1001 May 2017, . 1003 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1004 Connectivity Establishment (ICE): A Protocol for Network 1005 Address Translator (NAT) Traversal", RFC 8445, 1006 DOI 10.17487/RFC8445, July 2018, . 1009 16.2. Informational References 1011 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1012 Holmberg, C., Alvestrand, H., and C. Jennings, 1013 "Negotiating Media Multiplexing Using the Session 1014 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1015 negotiation-53 (work in progress), September 2018. 1017 [I-D.ietf-mmusic-sdp-mux-attributes] 1018 Nandakumar, S., "A Framework for SDP Attributes when 1019 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 1020 (work in progress), February 2018. 1022 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1023 Media Attributes in the Session Description Protocol 1024 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1025 . 1027 Authors' Addresses 1029 Gonzalo Camarillo 1030 Ericsson 1031 Hirsalantie 11 1032 FI-02420 Jorvas 1033 Finland 1035 Email: Gonzalo.Camarillo@ericsson.com 1037 Tom Kristensen 1038 Cisco 1039 Philip Pedersens vei 1 1040 NO-1366 Lysaker 1041 Norway 1043 Email: tomkrist@cisco.com, tomkri@ifi.uio.no 1045 Christer Holmberg 1046 Ericsson 1047 Hirsalantie 11 1048 Jorvas 02420 1049 Finland 1051 Email: christer.holmberg@ericsson.com