idnits 2.17.1 draft-ietf-bfcpbis-rfc4583bis-25.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 (September 26, 2018) is 2039 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 794, 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: March 30, 2019 C. Holmberg 7 Ericsson 8 September 26, 2018 10 Session Description Protocol (SDP) Format for Binary Floor Control 11 Protocol (BFCP) Streams 12 draft-ietf-bfcpbis-rfc4583bis-25 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 March 30, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . 7 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 . . . . . . . . . . . 17 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 . . . . . . 18 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 [I-D.ietf-bfcpbis-rfc4582bis], a given BFCP client 96 needs a set of data in order to establish a BFCP connection to a 97 floor control server. This data includes the transport address of 98 the server, the conference identifier, and the user identifier. 100 One way for clients to obtain this information is to use an SDP 101 offer/answer [RFC3264] exchange. This document specifies how to 102 encode this information in the SDP session descriptions that are part 103 of 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 SDP lines that also 109 apply to the BFCP connection. 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 [RFC8445] considerations when negotiating a BFCP connection. 127 Section 10 defines the SDP offer/answer procedures for negotiating a 128 BFCP connection. 130 2. Conventions 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 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 3. Floor Control Roles 140 When two endpoints establish a BFCP stream, they need to determine 141 which of them acts as a floor control client and which acts as a 142 floor control server. Typically, a client that establishes a BFCP 143 stream with a conference server will act as a floor control client, 144 while the conference server will act as a floor control server. 146 Once the roles have been determines, the roles will apply to all 147 BFCP-controlled streams associated with the BFCP stream. 149 4. Fields in the 'm' Line 151 This section describes how to generate an 'm' line for a BFCP stream. 153 According to the SDP specification [RFC4566], the 'm' line format is 154 the following: 156 m= ... 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 interoperability with RFC 4583 187 compliant 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 is 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 offerer indicates which floor control role(s) that 249 it is willing to take. The answerer indicates the role taken by the 250 answerer. Based on this, the floor control role of the offerer is 251 determined, as shown in Table 1. 253 +---------+----------+ 254 | Offerer | Answerer | 255 +---------+----------+ 256 | c-only | s-only | 257 | s-only | c-only | 258 | c-s | c-only | 259 | c-s | s-only | 260 +---------+----------+ 262 Table 1: Roles 264 In [RFC4583], there was a third attribute specified, "c-s", which 265 meant that an endpoint was willing to act as both floor control 266 client and floor control server at the same time for the BFCP stream, 267 taking different roles for different BFCP-controlled media streams. 268 The feature was underspecified and implemented in different ways, in 269 particular many implementations interpreted "c-s" to mean that the 270 endpoint is willing to act as either client or server (equivalent to 271 "c-only s-only"). An implementation compliant to this specification 272 MUST NOT include the "c-s" floorctl attribute value in an offer or or 273 answer, but MUST accept the attribute value in offer and process it 274 as equivalent to "c-only s-only" (or "s-only c-only"). As as a 275 result, each endpoint will take the same role for each BFCP- 276 controlled media stream assocaited with the BFCP stream. 278 Endpoints compliant with [RFC4583] might not include the 'floorctrl' 279 attribute in offers and answerer. If the 'floorctrl' attribute is 280 not present the offerer will act as floor control client, and the 281 answerer will act as floor control server. 283 The SDP Offer/Answer procedures for the 'floorctrl' attribute are 284 defined in Section 10. 286 The following is an example of a 'floorctrl' attribute in an offer: 288 a=floorctrl:c-only s-only 290 5.2. SDP 'confid' and 'userid' Attributes 292 This section defines the SDP 'confid' and the 'userid' media-level 293 attributes. The attributes are used by a floor control server to 294 convey the conference ID value and user ID value to the floor control 295 client, using decimal integer representation. 297 Attribute Name: confid 299 Attribute Value: conference-id 301 Usage Level: media 303 Charset Dependent: No 305 Mux Category: TBD 307 The Augmented BNF syntax [RFC5234] for the attribute is: 309 conference-id = 1*DIGIT 311 ;DIGIT is defined in [RFC5234] 313 Attribute Name: userid 315 Attribute Value: user-id 317 Usage Level: media 319 Charset Dependent: No 321 Mux Category: TBD 323 The Augmented BNF syntax [RFC5234] for the attribute is: 325 user-id = 1*DIGIT 327 ;DIGIT is defined in [RFC5234] 329 The SDP Offer/Answer procedures for the 'confid' and 'userid' 330 attributes are defined in Section 10. 332 5.3. SDP 'floorid' Attribute 334 This section defines the SDP 'floorid' media-level attribute. The 335 attribute conveys a floor identifier, and optionally pointers to one 336 or more BFCP-controlled media streams. 338 Attribute Name: floorid 340 Attribute Value: floor-id 342 Usage Level: media 344 Charset Dependent: No 346 Mux Category: TBD 348 The Augmented BNF syntax [RFC5234] for the attribute is: 350 floor-id = "a=floorid:" 1*DIGIT SP "mstrm:" token *(SP token) 352 ;DIGIT is defined in [RFC5234] 353 ;token is defined in [RFC4566] 355 The floor identifier value is the integer representation of the Floor 356 ID to be used in BFCP. Each media stream pointer value is associated 357 with an SDP 'label' attribute [RFC4574] of a media stream. 359 The SDP Offer/Answer procedures for the 'floorid' attribute are 360 defined in Section 10. 362 Note: In [RFC4583] 'm-stream' was erroneously used in Section 11. 363 Although the example was non-normative, it is implemented by some 364 vendors and occurs in cases where the endpoint is willing to act 365 as a server. Therefore, it is RECOMMENDED to support parsing and 366 interpreting 'm-stream' the same way as 'mstrm' when receiving. 368 5.4. SDP 'bfcpver' Attribute 370 This section defines the SDP 'bfcpver' media-level attribute. The 371 attribute is used to negotiate the BFCP version. 373 The Augmented BNF syntax [RFC5234] for the attributes is: 375 Attribute Name: bfcpver 377 Attribute Value: bfcp-version 379 Usage Level: media 381 Charset Dependent: No 383 Mux Category: TBD 385 The Augmented BNF syntax [RFC5234] for the attribute is: 387 bfcp-version = "a=bfcpver:" version *(SP version) 388 version = 1*DIGIT 390 ;DIGIT is defined in [RFC5234] 392 An endpoint uses the 'bfcpver' attribute to convey the version(s) of 393 BFCP supported by the endpoint, using integer values. For a given 394 version, the attribute value representing the version MUST match the 395 "Version" field that would be presented in the BFCP COMMON-HEADER 396 [I-D.ietf-bfcpbis-rfc4582bis]. The BFCP version that will eventually 397 be used will be conveyed with a BFCP-level Hello/HelloAck. 399 Endpoints compliant with [RFC4583] might not always include the 400 'bfcpver' attribute in offers and answers. The attribute value, if 401 present, MUST be in accordance with the definition of the Version 402 field in [I-D.ietf-bfcpbis-rfc4582bis]. If the attribute is not 403 present, endpoints MUST assume a default value in accordance with 404 [I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport 405 the default attribute value is "1", and when used over an unreliable 406 transport the default attribute value is "2". The value is inferred 407 from the transport specified in the 'm' line (Section 4) associated 408 with the stream. 410 The SDP Offer/Answer procedures for the 'bfcpver' attribute are 411 defined in Section 10. 413 6. Multiplexing Considerations 415 [I-D.ietf-mmusic-sdp-bundle-negotiation] defines how multiplexing of 416 multiple media streams can be negotiated. This specification does 417 not define how BFCP streams can be multiplexed with other media 418 streams. Therefore, a BFCP stream MUST NOT be associated with a 419 BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation]. Note that 420 BFCP-controlled media streams might be multiplexed with other media 421 streams. 423 [I-D.ietf-mmusic-sdp-mux-attributes] defines the mux categories for 424 the SDP attributes defined in this specification. Table 2 defines 425 the mux category for the 'bfcpver' attribute: 427 +---------+-------------------------------------+-------+-----------+ 428 | Name | Notes | Level | Mux | 429 | | | | Category | 430 +---------+-------------------------------------+-------+-----------+ 431 | bfcpver | Needs further analysis in a | M | TBD | 432 | | separate specification | | | 433 +---------+-------------------------------------+-------+-----------+ 435 Table 2: Multiplexing Attribute Analysis 437 7. BFCP Connection Management 439 BFCP streams can use TCP or UDP as the underlying transport. 440 Endpoints exchanging BFCP messages over UDP send the BFCP messages 441 towards the peer using the connection address and port provided in 442 the SDP 'c' and 'm' lines. TCP connection management is more 443 complicated and is described in the following Section. 445 Note: When using Interactive Connectivity Establishment (ICE) 446 [RFC8445], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward 447 procedures for connection management as UDP/BFCP described above 448 apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and 449 is described below. 451 7.1. TCP Connection Management 453 The management of the TCP connection used to transport BFCP messages 454 is performed using the SDP 'setup' and 'connection' attributes 455 [RFC4145]. The 'setup' attribute indicates which of the endpoints 456 initiates the TCP connection. The 'connection' attribute handles TCP 457 connection re-establishment. 459 The BFCP specification [I-D.ietf-bfcpbis-rfc4582bis] describes a 460 number of situations when the TCP connection between a floor control 461 client and the floor control server needs to be re-established. 462 However, that specification does not describe the re-establishment 463 process because this process depends on how the connection was 464 established in the first place. Endpoints using the offer/answer 465 mechanism follow the following rules. 467 When the existing TCP connection is closed and re-established 468 following the rules in [I-D.ietf-bfcpbis-rfc4582bis], the floor 469 control client MUST send an offer towards the floor control server in 470 order to re-establish the connection. If a TCP connection cannot 471 deliver a BFCP message and times out, the endpoint that attempted to 472 send the message (i.e., the one that detected the TCP timeout) MUST 473 send an offer in order to re-establish the TCP connection. 475 Endpoints that use the offer/answer mechanism to negotiate TCP 476 connections MUST support the 'setup' and 'connection' attributes. 478 8. TLS/DTLS Considerations 480 When DTLS is used with UDP, the generic procedures defined in 481 Section 5 of [I-D.ietf-mmusic-dtls-sdp] MUST be followed. 483 When TLS is used with TCP, once the underlying connection is 484 established, the answerer always acts as the TLS server. If the TCP 485 connection is lost, the active endpoint is responsible for re- 486 establishing the TCP connection. Unless a new TLS session is 487 negotiated, subsequent SDP offers and answers will not impact the 488 previously negotiated TLS roles. 490 Note: For TLS, it was decided to keep the original procedures in 491 [RFC4583] to determine which endpoint acts as the TLS server in 492 order to retain backwards compatibility. 494 9. ICE Considerations 496 Generic SDP offer/answer procedures for Interactive Connectivity 497 Establishment (ICE) are defined in [I-D.ietf-mmusic-ice-sip-sdp]. 499 When BFCP is used with UDP based ICE candidates [RFC8445] then the 500 procedures for UDP/TLS/BFCP are used. 502 When BFCP is used with TCP based ICE candidates [RFC6544] then the 503 procedures for TCP/DTLS/BFCP are used. 505 Based on the procedures defined in [I-D.ietf-mmusic-dtls-sdp], 506 endpoints treat all ICE candidate pairs associated with a BFCP stream 507 on top of a DTLS association as part of the same DTLS association. 508 Thus, there will only be one BFCP handshake and one DTLS handshake 509 even if there are multiple valid candidate pairs, and if BFCP media 510 is shifted between candidate pairs (including switching between UDP 511 to TCP candidate pairs) prior to nomination. If new candidates are 512 added, they will also be part of the same DTLS association. 514 In order to maximize the likelihood of interoperability between the 515 endpoints, all ICE enabled BFCP-over-DTLS endpoints SHOULD implement 516 support for UDP/TLS/BFCP. 518 When an SDP offer or answer conveys multiple ICE candidates for a 519 BFCP stream, UDP based candidates SHOULD be included and the default 520 candidate SHOULD be chosen from one of those UDP candidates. If UDP 521 transport is used for the default candidate, then the 'm' line proto 522 value MUST be 'UDP/TLS/BFCP'. If TCP transport is used for the 523 default candidate, the 'm' line proto value MUST be 'TCP/DTLS/BFCP'. 525 Note: Usage of ICE with protocols other than UDP/TLS/BFCP and 526 TCP/DTLS/BFCP is outside of scope for this specification. 528 10. SDP Offer/Answer Procedures 530 This section defines the SDP offer/answer [RFC3264] procedures for 531 negotiating and establishing a BFCP stream. Generic procedures for 532 DTLS are defined in [I-D.ietf-mmusic-dtls-sdp]. Generic procedures 533 for TLS are defined in [RFC8122]. 535 This section only defines the BFCP-specific procedures. Unless 536 explicitly stated otherwise, the procedures apply to an 'm' line 537 describing a BFCP stream. If an offer or answer contains multiple 538 'm' lines describing BFCP streams, the procedures are applied 539 independently to each stream. 541 Within this document, 'initial offer' refers to the first offer, 542 within an SDP session (e.g. a SIP dialog when the Session Initiation 543 Protocol (SIP) [RFC3261] is used to carry SDP), in which the offerer 544 indicates that it wants to negotiate the establishment of a BFCP 545 stream. 547 If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 548 'UDP/TLS/BFCP', the offerer and answerer follow the generic 549 procedures defined in [RFC8122]. 551 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/ 552 TCP' or 'UDP/TLS/BFCP', the offerer and answerer use the SDP 'setup' 553 attribute according to the procedures in [RFC4145]. 555 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 556 'TCP/DTLS/BFCP', the offerer and anwerer use the SDP 'connection' 557 attribute according to the procedures in [RFC4145]. 559 Note: The use of source-specific SDP parameters [RFC5576] is not 560 defined for BFCP streams. 562 10.1. Generating the Initial SDP Offer 564 When the offerer creates an initial offer, the offerer MUST associate 565 an SDP 'floorctrl' attribute (Section 5.1) and an SDP 'bfcpver' 566 attribute (Section 5.4) with the 'm' line. 568 In addition, if the offerer includes an SDP 'floorctrl' attribute 569 with 's-only' or 'c-s' attribute values in the offer, the offerer: 571 o MUST associate an SDP 'confid' attribute (Section 5.2) with the 572 'm' line; and 574 o MUST associate an SDP 'userid' attribute (Section 5.2) with the 575 'm' line; and 577 o MUST associate an SDP 'floorid' attribute (Section 5.3) with the 578 'm' line; and 580 o MUST associate an SDP 'label' attribute ([RFC4574]) with the 'm' 581 line of each BFCP-controlled media stream. 583 Note: If the offerer includes an SDP 'floorctrl' attribute with a 584 'c-s' attribute value, or both a 'c-only' and a 's-only' attribute 585 value, in the offer, the attribute values above will only be used 586 if it is determined (Section 5.1) that the offerer will act as 587 floor control server. 589 10.2. Generating the SDP Answer 591 When the answerer receives an offer that contains an 'm' line 592 describing a BFCP stream, the answerer MUST check whether it supports 593 one or more of the BFCP versions supported by the offerer 594 (Section 5.4). If the answerer does not support any of the BFCP 595 versions, it MUST NOT accept the 'm' line. Otherwise, if the 596 answerer accepts the 'm' line, it: 598 o MUST insert a corresponding 'm' line in the answer, with an 599 identical 'm' line proto value [RFC3264]; and 601 o MUST associate a 'bfcpver' attribute with the 'm' line. The 602 answerer only indicates support of BFCP versions also supported by 603 the offerer; and 605 o MUST, if the offer contained an SDP 'floorctrl' attribute, 606 associate a 'floorctrl' attribute with the 'm' line. 608 In addition, if the answerer includes an SDP 'floorctrl' attribute 609 with an 's-only' attribute value in the answer, the answerer: 611 o MUST associate an SDP 'confid' attribute with the 'm' line; and 613 o MUST associate an SDP 'userid' attribute with the 'm' line; and 615 o MUST associate an SDP 'floorid' attribute with the 'm' line; and 617 o MUST associate an SDP 'label' attribute with the 'm' line of each 618 BFCP-controlled media stream. 620 Note: An offerer compliant with [RFC4583] might not include 621 'floorctrl' and 'bfcpver' attributes in offers, in which cases the 622 default values apply. 624 Once the answerer has sent the answer, the answerer: 626 o MUST, if the answerer is the 'active' endpoint, and if a TCP 627 connection associated with the 'm' line is to be established (or 628 re-established), initiate the establishing of the TCP connection; 629 and 631 o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS 632 connection associated with the 'm' line is to be established (or 633 re-established), initiate the establishing of the TLS/DTLS 634 connection (by sending a ClientHello message). 636 If the answerer does not accept the 'm' line in the offer, it MUST 637 assign a zero port value to the corresponding 'm' line in the answer. 638 In addition, the answerer MUST NOT establish a TCP connection or a 639 TLS/DTLS connection associated with the 'm' line. 641 10.3. Offerer Processing of the SDP Answer 643 When the offerer receives an answer, which contains an 'm' line with 644 a non-zero port value, describing a BFCP stream, the offerer: 646 o MUST, if the offerer is the 'active' endpoint, and if a TCP 647 connection associated with the 'm' line is to be established (or 648 re-established), initiate the establishing of the TCP connection; 649 and 651 o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS 652 connection associated with the 'm' line is to be established (or 653 re-established), initiate the establishing of the TLS/DTLS 654 connection (by sending a ClientHello message). 656 Note: An answerer compliant with [RFC4583] might not include 657 'floorctrl' and 'bfcpver' attributes in answers, in which cases 658 the default values apply. 660 If the 'm' line in the answer contains a zero port value, or if the 661 offerer for some other reason does not accept the answer (e.g., if 662 the answerer only indicates support of BFCP versions not supported by 663 the offerer), the offerer MUST NOT establish a TCP connection or a 664 TLS/DTLS connection associated with the 'm' line. 666 10.4. Modifying the Session 668 When an offerer sends an updated offer, in order to modify a 669 previously established BFCP stream, it follows the procedures in 670 Section 10.1, with the following exceptions: 672 o If the BFCP stream is carried on top of TCP, and if the offerer 673 does not want to re-establish an existing TCP connection, the 674 offerer MUST associate an SDP 'connection' attribute with a value 675 of "existing", with the 'm' line; and 677 o If the offerer wants to disable a previously established BFCP 678 stream, it MUST assign a zero port value to the 'm' line 679 associated with the BFCP connection, following the procedures in 680 [RFC3264]. 682 11. Examples 684 For the purpose of brevity, the main portion of the session 685 description is omitted in the examples, which only show 'm' lines and 686 their attributes. 688 The following is an example of an offer sent by a conference server 689 to a client. 691 m=application 50000 TCP/TLS/BFCP * 692 a=setup:actpass 693 a=connection:new 694 a=fingerprint:sha-256 \ 695 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 696 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 697 a=floorctrl:c-only s-only 698 a=confid:4321 699 a=userid:1234 700 a=floorid:1 mstrm:10 701 a=floorid:2 mstrm:11 702 a=bfcpver:1 2 703 m=audio 50002 RTP/AVP 0 704 a=label:10 705 m=video 50004 RTP/AVP 31 706 a=label:11 707 Note that due to RFC formatting conventions, this document splits SDP 708 across lines whose content would exceed 72 characters. A backslash 709 character marks where this line folding has taken place. This 710 backslash and its trailing CRLF and whitespace would not appear in 711 actual SDP content. 713 The following is the answer returned by the client. 715 m=application 9 TCP/TLS/BFCP * 716 a=setup:active 717 a=connection:new 718 a=fingerprint:sha-256 \ 719 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 720 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 721 a=floorctrl:c-only 722 a=bfcpver:1 723 m=audio 55000 RTP/AVP 0 724 m=video 55002 RTP/AVP 31 726 A similar example using unreliable transport and DTLS is shown below, 727 where the offer is sent from a client. 729 m=application 50000 UDP/TLS/BFCP * 730 a=setup:actpass 731 a=dtls-id:abc3dl 732 a=fingerprint:sha-256 \ 733 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 734 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 735 a=floorctrl:c-only s-only 736 a=confid:4321 737 a=userid:1234 738 a=floorid:1 mstrm:10 739 a=floorid:2 mstrm:11 740 a=bfcpver:1 2 741 m=audio 50002 RTP/AVP 0 742 a=label:10 743 m=video 50004 RTP/AVP 31 744 a=label:11 746 The following is the answer returned by the server. 748 m=application 55000 UDP/TLS/BFCP * 749 a=setup:active 750 a=dtls-id:abc3dl 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:s-only 755 a=confid:4321 756 a=userid:1234 757 a=floorid:1 mstrm:10 758 a=floorid:2 mstrm:11 759 a=bfcpver:2 760 m=audio 55002 RTP/AVP 0 761 m=video 55004 RTP/AVP 31 763 12. Security Considerations 765 The BFCP [I-D.ietf-bfcpbis-rfc4582bis], SDP [RFC4566], and offer/ 766 answer [RFC3264] specifications discuss security issues related to 767 BFCP, SDP, and offer/answer, respectively. In addition, [RFC4145] 768 and [RFC8122] discuss security issues related to the establishment of 769 TCP and TLS connections using an offer/answer model. Furthermore, 770 when using DTLS over UDP, the generic offer/answer considerations 771 defined in [I-D.ietf-mmusic-dtls-sdp] MUST be followed. 773 13. IANA Considerations 775 [Editorial note: The changes in Section 13.1 instruct the IANA to 776 register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/ 777 BFCP for the SDP 'proto' field. The new section Section 5.4 778 registers a new SDP "bfcpver" attribute. The rest is unchanged 779 from [RFC4582].] 781 13.1. Registration of SDP 'proto' Values 783 The IANA has registered the following values for the SDP 'proto' 784 field under the Session Description Protocol (SDP) Parameters 785 registry: 787 +---------------+------------+ 788 | Value | Reference | 789 +---------------+------------+ 790 | TCP/BFCP | [RFC XXXX] | 791 | TCP/DTLS/BFCP | [RFC XXXX] | 792 | TCP/TLS/BFCP | [RFC XXXX] | 793 | UDP/BFCP | [RFC XXXX] | 794 | UDP/TLS/BFCP | [RFC XXXX] | 795 +---------------+------------+ 797 Table 3: Values for the SDP 'proto' field 799 13.2. Registration of the SDP 'floorctrl' Attribute 801 This document defines the SDP attribute,'floorctrl'. The details of 802 the attribute are defined in Section 5.1. 804 For issues regarding this attribute contact iesg@ietf.org. 806 13.3. Registration of the SDP 'confid' Attribute 808 This document defines the SDP attribute,'confid'. The details of the 809 attribute are defined in Section 5.2. 811 For issues regarding this attribute contact iesg@ietf.org. 813 13.4. Registration of the SDP 'userid' Attribute 815 This document defines the SDP attribute,'userid'. The details of the 816 attribute are defined in Section 5.2. 818 For issues regarding this attribute contact iesg@ietf.org. 820 13.5. Registration of the SDP 'floorid' Attribute 822 This document defines the SDP attribute,'floorid'. The details of 823 the attribute are defined in Section 5.3. 825 For issues regarding this attribute contact iesg@ietf.org. 827 13.6. Registration of the SDP 'bfcpver' Attribute 829 This document defines the SDP attribute,'bfcpver'. The details of 830 the attribute are defined in Section 5.4. 832 For issues regarding this attribute contact iesg@ietf.org. 834 14. Changes from RFC 4583 836 Following is the list of technical changes and other fixes from 837 [RFC4583]. 839 Main purpose of this work was to add signaling support necessary to 840 support BFCP over unreliable transport, as described in 841 [I-D.ietf-bfcpbis-rfc4582bis], resulting in the following changes: 843 1. Fields in the 'm' line (Section 4): 844 The section is re-written to remove reference to the exclusivity 845 of TCP as a transport for BFCP streams. The proto field values 846 TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added. 848 2. Authentication (Section 8): 849 In last paragraph, made clear that a TCP connection was 850 described. 852 3. Security Considerations (Section 12): 853 For the DTLS over UDP case, mention existing considerations and 854 requirements for the offer/answer exchange in 855 [I-D.ietf-mmusic-dtls-sdp]. 857 4. Registration of SDP 'proto' Values (Section 13.1): 858 Register the three new values TCP/DTLS/BFCP, UDP/BFCP and 859 UDP/TLS/BFCP in the SDP parameters registry. 861 5. BFCP Version Negotiation (Section 5.4): 862 A new 'bfcpver' SDP media-level attribute is added in order to 863 signal supported version number. 865 In addition to the changes associated with support BFCP over 866 unreliable transport, the possibility for an endpoint to act as both 867 floor control client and floor control server at the same time has 868 been removed. An endpoint will now take the same role for all BFCP- 869 controlled streams associated with the BFCP stream. 871 Clarification and bug fixes: 873 1. Errata ID: 712 (Section 3 and Section 10): 874 Language clarification. Don't use terms like an SDP attribute is 875 "used in an 'm' line", instead make clear that the attribute is a 876 media-level attribute. 878 2. Fix typo in example (Section 11): 879 Do not use 'm-stream' in the SDP example, use the correct 'mstrm' 880 as specified in Section 11. Recommend interpreting 'm-stream' if 881 it is received, since it is present in some implementations. 883 3. Assorted clarifications (Across the document): 884 Language clarifications as a result of reviews. Also, the 885 normative language where tightened where appropriate, i.e. 886 changed from SHOULD strength to MUST in a number of places. 888 15. Acknowledgements 890 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 891 Oscar Novo provided useful ideas for the original [RFC4583]. The 892 authors also acknowledge contributions to the revision of BFCP for 893 use over an unreliable transport from Geir Arne Sandbakken, Charles 894 Eckel, Alan Ford, Eoin McLeod and Mark Thompson. Useful and 895 important final reviews were done by Ali C. Begen, Mary Barnes and 896 Charles Eckel. In the final stages, Roman Shpount made a 897 considerable effort in adding proper ICE support and considerations. 899 16. References 901 16.1. Normative References 903 [I-D.ietf-bfcpbis-rfc4582bis] 904 Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 905 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 906 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 907 2015. 909 [I-D.ietf-mmusic-dtls-sdp] 910 Holmberg, C. and R. Shpount, "Session Description Protocol 911 (SDP) Offer/Answer Considerations for Datagram Transport 912 Layer Security (DTLS) and Transport Layer Security (TLS)", 913 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 914 2017. 916 [I-D.ietf-mmusic-ice-sip-sdp] 917 Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 918 "Session Description Protocol (SDP) Offer/Answer 919 procedures for Interactive Connectivity Establishment 920 (ICE)", draft-ietf-mmusic-ice-sip-sdp-21 (work in 921 progress), June 2018. 923 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 924 Requirement Levels", BCP 14, RFC 2119, 925 DOI 10.17487/RFC2119, March 1997, . 928 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 929 A., Peterson, J., Sparks, R., Handley, M., and E. 930 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 931 DOI 10.17487/RFC3261, June 2002, . 934 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 935 with Session Description Protocol (SDP)", RFC 3264, 936 DOI 10.17487/RFC3264, June 2002, . 939 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 940 the Session Description Protocol (SDP)", RFC 4145, 941 DOI 10.17487/RFC4145, September 2005, . 944 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 945 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 946 July 2006, . 948 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 949 and RTP Control Protocol (RTCP) Packets over Connection- 950 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 951 2006, . 953 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 954 Protocol (SDP) Label Attribute", RFC 4574, 955 DOI 10.17487/RFC4574, August 2006, . 958 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 959 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 960 November 2006, . 962 [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format 963 for Binary Floor Control Protocol (BFCP) Streams", 964 RFC 4583, DOI 10.17487/RFC4583, November 2006, 965 . 967 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 968 Specifications: ABNF", STD 68, RFC 5234, 969 DOI 10.17487/RFC5234, January 2008, . 972 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 973 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 974 January 2012, . 976 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 977 "TCP Candidates with Interactive Connectivity 978 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 979 March 2012, . 981 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 982 Transport over the Transport Layer Security (TLS) Protocol 983 in the Session Description Protocol (SDP)", RFC 8122, 984 DOI 10.17487/RFC8122, March 2017, . 987 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 988 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 989 May 2017, . 991 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 992 Connectivity Establishment (ICE): A Protocol for Network 993 Address Translator (NAT) Traversal", RFC 8445, 994 DOI 10.17487/RFC8445, July 2018, . 997 16.2. Informational References 999 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1000 Holmberg, C., Alvestrand, H., and C. Jennings, 1001 "Negotiating Media Multiplexing Using the Session 1002 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1003 negotiation-53 (work in progress), September 2018. 1005 [I-D.ietf-mmusic-sdp-mux-attributes] 1006 Nandakumar, S., "A Framework for SDP Attributes when 1007 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 1008 (work in progress), February 2018. 1010 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1011 Media Attributes in the Session Description Protocol 1012 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1013 . 1015 Authors' Addresses 1017 Gonzalo Camarillo 1018 Ericsson 1019 Hirsalantie 11 1020 FI-02420 Jorvas 1021 Finland 1023 Email: Gonzalo.Camarillo@ericsson.com 1024 Tom Kristensen 1025 Cisco 1026 Philip Pedersens vei 1 1027 NO-1366 Lysaker 1028 Norway 1030 Email: tomkrist@cisco.com, tomkri@ifi.uio.no 1032 Christer Holmberg 1033 Ericsson 1034 Hirsalantie 11 1035 Jorvas 02420 1036 Finland 1038 Email: christer.holmberg@ericsson.com