idnits 2.17.1 draft-ietf-bfcpbis-rfc4583bis-23.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 (May 21, 2018) is 2166 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC5234' on line 354 -- Looks like a reference, but probably isn't: 'RFC4566' on line 317 -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 800 ** Obsolete normative reference: RFC 5750 (ref. '5') (Obsoleted by RFC 8550) ** Obsolete normative reference: RFC 4566 (ref. '9') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6347 (ref. '10') (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 4582 (ref. '13') (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (ref. '14') (Obsoleted by RFC 8856) == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-20 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-51 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-17 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFCPbis Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Obsoletes: 4583 (if approved) T. Kristensen 5 Intended status: Standards Track Cisco 6 Expires: November 22, 2018 C. Holmberg 7 Ericsson 8 May 21, 2018 10 Session Description Protocol (SDP) Format for Binary Floor Control 11 Protocol (BFCP) Streams 12 draft-ietf-bfcpbis-rfc4583bis-23 14 Abstract 16 This document defines the Session Description Protocol (SDP) offer/ 17 answer procedures for negotiating and establishing Binary Floor 18 Control Protocol (BFCP) streams. 20 This document obsoletes RFC 4583. Changes from RFC 4583 are 21 summarized in Section 15. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://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 November 22, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . 3 60 4. Floor Control Roles . . . . . . . . . . . . . . . . . . . . . 4 61 5. SDP 'floorctrl' Attribute . . . . . . . . . . . . . . . . . . 5 62 6. SDP 'confid' and 'userid' Attributes . . . . . . . . . . . . 6 63 7. SDP 'floorid' Attribute . . . . . . . . . . . . . . . . . . . 7 64 8. SDP 'bfcpver' Attribute . . . . . . . . . . . . . . . . . . . 8 65 9. Multiplexing Considerations . . . . . . . . . . . . . . . . . 9 66 10. BFCP Connection Management . . . . . . . . . . . . . . . . . 9 67 10.1. TCP Connection Management . . . . . . . . . . . . . . . 9 68 11. Authentication . . . . . . . . . . . . . . . . . . . . . . . 10 69 12. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 13. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 71 13.1. Generating the Initial SDP Offer . . . . . . . . . . . . 12 72 13.2. Generating the SDP Answer . . . . . . . . . . . . . . . 13 73 13.3. Offerer Processing of the SDP Answer . . . . . . . . . . 14 74 13.4. Modifying the Session . . . . . . . . . . . . . . . . . 15 75 14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 15. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 16.1. Registration of SDP 'proto' Values . . . . . . . . . . . 17 79 16.2. Registration of the SDP 'floorctrl' Attribute . . . . . 18 80 16.3. Registration of the SDP 'confid' Attribute . . . . . . . 18 81 16.4. Registration of the SDP 'userid' Attribute . . . . . . . 18 82 16.5. Registration of the SDP 'floorid' Attribute . . . . . . 18 83 16.6. Registration of the SDP 'bfcpver' Attribute . . . . . . 18 84 17. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 19 85 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 86 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 19.1. Normative References . . . . . . . . . . . . . . . . . . 20 88 19.2. Informational References . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 As discussed in the BFCP (Binary Floor Control Protocol) 94 specification [17], a given BFCP client needs a set of data in order 95 to establish a BFCP connection to a floor control server. This data 96 includes the transport address of the server, the conference 97 identifier, and the user identifier. 99 One way for clients to obtain this information is to use an SDP 100 offer/answer [4] exchange. This document specifies how to encode 101 this information in the SDP session descriptions that are part of 102 such an offer/answer exchange. 104 User agents typically use the offer/answer model to establish a 105 number of media streams of different types. Following this model, a 106 BFCP connection is described as any other media stream by using an 107 SDP 'm' line, possibly followed by a number of attributes encoded in 108 'a' lines. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14, RFC 2119 [1] and indicate requirement levels for compliant 116 implementations. 118 3. Fields in the 'm' Line 120 This section describes how to generate an 'm' line for a BFCP stream. 122 According to the SDP specification [9], the 'm' line format is the 123 following: 125 m= ... 127 The media field MUST have a value of "application". 129 The port field is set depending on the value of the proto field, as 130 explained below. A port field value of zero has the standard SDP 131 meaning (i.e., rejection of the media stream) regardless of the proto 132 field. 134 When TCP is used as the transport, the port field is set following 135 the rules in [6]. Depending on the value of the 'setup' attribute 136 (discussed in Section 10.1), the port field contains the port to 137 which the remote endpoint will direct BFCP messages, or in the 138 case where the endpoint will initiate the connection towards the 139 remote endpoint, should be set to a value of 9. 141 When UDP is used as the transport, the port field contains the 142 port to which the remote endpoint will direct BFCP messages 143 regardless of the value of the 'setup' attribute. 145 This document defines five values for the proto field: TCP/BFCP, 146 TCP/DTLS/BFCP, TCP/TLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP. 148 TCP/BFCP is used when BFCP runs directly on top of TCP. TCP/TLS/BFCP 149 is used when BFCP runs on top of TLS, which in turn runs on top of 150 TCP. TCP/DTLS/BFCP is used when running BFCP on top of DTLS [10], as 151 described in this specification, which in turn runs on top of TCP 152 using the framing method defined in [11] with DTLS packets being sent 153 and received instead of RTP/RTCP packets using the shim defined in 154 RFC4571 such that the length field defined in RFC4571 precedes each 155 DTLS message. 157 Similarly, UDP/BFCP is used when BFCP runs directly on top of UDP, 158 and UDP/TLS/BFCP is used when BFCP runs on top of DTLS, which in turn 159 runs on top of UDP. 161 The fmt (format) list is not applicable to BFCP. The fmt list of 'm' 162 lines in the case of any proto field value related to BFCP MUST 163 contain a single "*" character. If the the fmt list contains any 164 other value it is ignored. 166 The following is an example of an 'm' line for a BFCP connection: 168 m=application 50000 TCP/TLS/BFCP * 170 4. Floor Control Roles 172 When two endpoints establish a BFCP stream, they need to determine 173 which of them acts as floor control client and which acts as floor 174 control server. Typically, a client that establishes a BFCP stream 175 with a conference server will act as floor control client, while the 176 conference server will act as floor control server. However, there 177 are scenarios where both endpoints would be able to act as floor 178 control server. For example, in a two-party session that involves an 179 audio stream and a shared whiteboard, the endpoints need to determine 180 which party will be act as floor control server. 182 Furthermore, there are situations where both endpoints act as both 183 floor control client and floor control server within the same 184 session. For example, in a two-party session that involves an audio 185 stream and a shared whiteboard, one endpoint acts as the floor 186 control server for the audio stream and the other endpoint acts as 187 the floor control server for the shared whiteboard. However, for a 188 given BFCP-controlled media stream one endpoint MUST act as floor 189 control client and one endpoint MUST act as floor control server. 191 5. SDP 'floorctrl' Attribute 193 This section defines the SDP 'floorctrl' media-level attribute. The 194 attribute is used to determine the floor control role(s) that the 195 endpoints can take for the BFCP-controlled media streams. As 196 described in Section 5, an endpoint can take different roles for 197 different media streams, but for a given media stream an endpoint can 198 only take one role. 200 Attribute Name: floorctrl 202 Attribute Value: floor-control 204 Usage Level: media 206 Charset Dependent: No 208 Mux Category: TBD 210 The Augmented BNF syntax [RFC5234] for the attribute is: 212 floor-control = role *(SP role) 213 role = "c-only" / "s-only" / "c-s" 215 An endpoint includes the attribute to indicate the role(s) it would 216 be willing to perform for the BFCP-controlled media streams: 218 c-only: The endpoint is willing to act as floor control client. 220 s-only: The endpoint is willing to act as floor control server only. 222 c-s: The endpoint is willing to act as floor control client and 223 floor control server. 225 When inserted in an offer, the offerer MAY indicate multiple 226 attribute values. When inserted in an answer, the answerer MUST 227 indicate only one attribute value. The offerer indicates which floor 228 control role(s) that it is willing to take. The answerer indicates 229 the role taken by the answerer. Based on this, the floor control 230 role(s) of the offerer is determined, as shown in Table 1. 232 +---------+----------+ 233 | Offerer | Answerer | 234 +---------+----------+ 235 | c-only | s-only | 236 | s-only | c-only | 237 | c-s | c-s | 238 +---------+----------+ 240 Table 1: Roles 242 Endpoints compliant with [14] might not include the 'floorctrl' 243 attribute in offers and answerer. If the 'floorctrl' attribute is 244 not present the offerer will act as floor control client, and the 245 answerer will act as floor control server, for each BFCP-controlled 246 media stream. 248 The SDP Offer/Answer procedures for the 'floorctrl' attribute are 249 defined in Section 13. 251 The following is an example of a 'floorctrl' attribute in an offer: 253 a=floorctrl:c-only s-only c-s 255 6. SDP 'confid' and 'userid' Attributes 257 This section defines the SDP 'confid' and the 'userid' media-level 258 attributes. The attributes are used by a floor control server to 259 convey the conference ID value and user ID value to the floor control 260 client, using decimal integer representation. 262 Attribute Name: confid 264 Attribute Value: conference-id 266 Usage Level: media 268 Charset Dependent: No 270 Mux Category: TBD 272 The Augmented BNF syntax [RFC5234] for the attribute is: 274 conference-id = 1*DIGIT 276 ;DIGIT is defined in [RFC5234] 277 Attribute Name: userid 279 Attribute Value: user-id 281 Usage Level: media 283 Charset Dependent: No 285 Mux Category: TBD 287 The Augmented BNF syntax [RFC5234] for the attribute is: 289 user-id = 1*DIGIT 291 ;DIGIT is defined in [RFC5234] 293 The SDP Offer/Answer procedures for the 'confid' and 'userid' 294 attributes are defined in Section 13. 296 7. SDP 'floorid' Attribute 298 This section defines the SDP 'floorid' media-level attribute. The 299 attribute conveys a floor identifier, and optionally pointers to one 300 or more BFCP-controlled media streams. 302 Attribute Name: floorid 304 Attribute Value: floor-id 306 Usage Level: media 308 Charset Dependent: No 310 Mux Category: TBD 312 The Augmented BNF syntax [RFC5234] for the attribute is: 314 floor-id = "a=floorid:" 1*DIGIT SP "mstrm:" token *(SP token) 316 ;DIGIT is defined in [RFC5234] 317 ;token is defined in [RFC4566] 319 The floor identifier value is the integer representation of the Floor 320 ID to be used in BFCP. Each media stream pointer value is associated 321 with an SDP 'label' attribute [7] of a media stream. 323 The SDP Offer/Answer procedures for the 'floorid' attribute are 324 defined in Section 13. 326 Note: In [14] 'm-stream' was erroneously used in Section 14. 327 Although the example was non-normative, it is implemented by some 328 vendors and occurs in cases where the endpoint is willing to act 329 as an server. Therefore, it is RECOMMENDED to support parsing and 330 interpreting 'm-stream' the same way as 'mstrm' when receiving. 332 8. SDP 'bfcpver' Attribute 334 This section defines the SDP 'bfcpver' media-level attribute. The 335 attribute is used to negotiate the BFCP version. 337 The Augmented BNF syntax [2] for the attributes is: 339 Attribute Name: bfcpver 341 Attribute Value: bfcp-version 343 Usage Level: media 345 Charset Dependent: No 347 Mux Category: TBD 349 The Augmented BNF syntax [RFC5234] for the attribute is: 351 bfcp-version = "a=bfcpver:" version *(SP version) 352 version = 1*DIGIT 354 ;DIGIT is defined in [RFC5234] 356 An endpoint uses the 'bfcpver' attribute to convey the version(s) of 357 BFCP supported by the endpoint, using integer values. For a given 358 version, the attribute value representing the version MUST match the 359 "Version" field that would be presented in the BFCP COMMON-HEADER 360 [17]. The BFCP version that will eventually be used will be conveyed 361 with a BFCP-level Hello/HelloAck. 363 Endpoints compliant with [14] might not always include the 'bfcpver' 364 attribute in offers and answers. If the 'bfcpver' attribute is not 365 present, the default values are inferred from the transport specified 366 in the 'm' line (Section 3) associated with the stream. In 367 accordance with definition of the Version field in [17], when used 368 over a reliable transport the default attribute value is "1", and 369 when used over an unreliable transport the default attribute value is 370 "2". 372 The SDP Offer/Answer procedures for the 'bfcpver' attribute are 373 defined in Section 13. 375 9. Multiplexing Considerations 377 [20] defines how multiplexing of multiple media streams can be 378 negotiated. This specification does not define how BFCP streams can 379 be multiplexed with other media streams. Therefore, a BFCP stream 380 MUST NOT be associated with a BUNDLE group [20]. Note that BFCP- 381 controlled media streams might be multiplexed with other media 382 streams. 384 [21] defines the mux categories for the SDP attributes defined in 385 this specification, excluding the SDP 'bfcpver' attribute. . Table 2 386 defines the mux category for the 'bfcpver' attribute: 388 +---------+------------------------+-------+--------------+ 389 | Name | Notes | Level | Mux Category | 390 +---------+------------------------+-------+--------------+ 391 | bfcpver | Needs further analysis | M | TBD | 392 +---------+------------------------+-------+--------------+ 394 Table 2: Multiplexing Attribute Analysis 396 10. BFCP Connection Management 398 BFCP streams can use TCP or UDP as the underlying transport. 399 Endpoints exchanging BFCP messages over UDP send the BFCP messages 400 towards the peer using the connection address and port provided in 401 the SDP 'c' and 'm' lines. TCP connection management is more 402 complicated and is described in the following Section. 404 Note: When using Interactive Connectivity Establishment (ICE) 405 [15], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward 406 procedures for connection management as UDP/BFCP described above 407 apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and 408 is described below. 410 10.1. TCP Connection Management 412 The management of the TCP connection used to transport BFCP messages 413 is performed using the SDP 'setup' and 'connection' attributes [6]. 414 The 'setup' attribute indicates which of the endpoints initiates the 415 TCP connection. The 'connection' attribute handles TCP connection 416 re-establishment. 418 The BFCP specification [17] describes a number of situations when the 419 TCP connection between a floor control client and the floor control 420 server needs to be re-established. However, that specification does 421 not describe the re-establishment process because this process 422 depends on how the connection was established in the first place. 424 Endpoints using the offer/answer mechanism follow the following 425 rules. 427 When the existing TCP connection is closed and re-established 428 following the rules in [17], the floor control client MUST send an 429 offer towards the floor control server in order to re-establish the 430 connection. If a TCP connection cannot deliver a BFCP message and 431 times out, the endpoint that attempted to send the message (i.e., the 432 one that detected the TCP timeout) MUST send an offer in order to re- 433 establish the TCP connection. 435 Endpoints that use the offer/answer mechanism to negotiate TCP 436 connections MUST support the 'setup' and 'connection' attributes. 438 11. Authentication 440 When a BFCP stream is negotiated using the SDP offer/answer 441 mechanism, it is assumed that the offerer and the answerer 442 authenticate each other using some mechanism. TLS/DTLS is the 443 preferred mechanism. Other mechanisms are possible, but are outside 444 the scope of this document. Once this mutual authentication takes 445 place, all the offerer and the answerer need to ensure is that the 446 entity they are receiving BFCP messages from is the same as the one 447 that generated the previous offer or answer. 449 The initial mutual authentication SHOULD take place at the signaling 450 level. Additionally, signaling can use S/MIME [5] to provide an 451 integrity-protected channel with optional confidentiality for the 452 offer/answer exchange. BFCP takes advantage of this integrity- 453 protected offer/answer exchange to perform authentication. Within 454 the offer/answer exchange, the offerer and answerer exchange the 455 fingerprints of their self-signed certificates. These self-signed 456 certificates are then used to establish the TLS/DTLS connection that 457 will carry BFCP traffic between the offerer and the answerer. 459 Endpoints follow the rules in [8] regarding certificate choice and 460 presentation. Endpoints that use the offer/answer model to establish 461 BFCP streams MUST support the 'fingerprint' attribute and MUST 462 include it in their offers and answers. 464 When TLS is used with TCP, once the underlying connection is 465 established, the answerer, which can be the floor control client or 466 the floor control server, acts as the TLS server regardless of its 467 role (passive or active) in the TCP establishment procedure. If the 468 TCP connection is lost, the active endpoint is responsible for re- 469 establishing the TCP connection. Unless a new TLS session is 470 negotiated, subsequent SDP offers and answers will not impact the 471 previously negotiated TLS roles. 473 When DTLS is used with UDP, the requirements specified in Section 5 474 of [18] MUST be followed. 476 Note: How to determine which endpoint initiates the TLS/DTLS 477 association depends on the selected underlying transport. It was 478 decided to keep the original semantics in [14] for TCP to retain 479 backwards compatibility. When using UDP, the procedure defined in 480 [18] was selected in order to be compatible with other DTLS based 481 protocol implementations, such as DTLS-SRTP. Furthermore, the 482 procedure defined in [18] do not overload offer/answer semantics 483 and works for offerless INVITE in scenarios with B2BUAs. 485 12. ICE Considerations 487 Generic SDP offer/answer procedures for Interactive Connectivity 488 Establishment (ICE) are defined in [16]. 490 When BFCP is used with UDP based ICE candidates [15] then the 491 procedures for UDP/TLS/BFCP are used. 493 When BFCP is used with TCP based ICE candidates [12] then the 494 procedures for TCP/DTLS/BFCP are used. 496 Based on the procedures defined in [18], endpoints treat all ICE 497 candidate pairs associated with a BFCP stream on top of a DTLS 498 association as part of the same DTLS association. Thus, there will 499 only be one BFCP handshake and one DTLS handshake even if there are 500 multiple valid candidate pairs, and if BFCF media is shifted between 501 candidate pairs (including switching between UDP to TCP candidate 502 pairs) prior to nomination. If new candidates are added, they will 503 also be part of the same DTLS association. 505 In order to maximize the likelihood of interoperability between the 506 endpoints, all ICE enabled BFCP-over-DTLS endpoints SHOULD implement 507 support for UDP/TLS/BFCP. 509 When an SDP offer or answer conveys multiple ICE candidates for a 510 BFCP stream, UDP based candidates SHOULD be included and the default 511 candidate SHOULD be chosen from one of those UDP candidates. If UDP 512 transport is used for the default candidate, then the 'm' line proto 513 value MUST be 'UDP/TLS/BFCP'. If TCP transport is used for the 514 default candidate, the 'm' line proto value MUST be 'TCP/DTLS/BFCP'. 516 Note: Usage of ICE with protocols other than UDP/TLS/BFCP and 517 TCP/DTLS/BFCP is outside of scope for this specification. 519 13. SDP Offer/Answer Procedures 521 This section defines the SDP offer/answer [4] procedures for 522 negotiating and establishing a BFCP stream. Generic procedures for 523 DTLS are defined in [18]. Generic procedures for TLS are defined in 524 [8]. 526 This section only defines the BFCP-specific procedures. Unless 527 explicitly stated otherwise, the procedures apply to an 'm' line 528 describing a BFCP stream. If an offer or answer contains multiple 529 'm' lines describing BFCP streams, the procedures are applied 530 independently to each stream. 532 Within this document, 'initial offer' refers to the first offer, 533 within an SDP session (e.g. a SIP dialog when the Session Initiation 534 Protocol (SIP) [3] is used to carry SDP), in which the offerer 535 indicates that it wants to negotiate the establishment of a BFCP 536 stream. 538 If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 539 'UDP/TLS/BFCP', the offerer and answerer follow the generic 540 procedures defined in [8]. 542 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/ 543 TCP' or 'UDP/TLS/BFCP', the offerer and answerer use the SDP 'setup' 544 attribute according to the procedures in [6]. 546 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 547 'TCP/DTLS/BFCP', the offerer and anwerer use the SDP 'connection' 548 attribute according to the procedures in [6]. 550 Note: The use of source-specific SDP parameters [19] is not 551 defined to BFCP streams. 553 13.1. Generating the Initial SDP Offer 555 When the offerer creates an initial offer, the offerer MUST associate 556 an SDP 'floorctrl' attribute (Section 5) and an SDP 'bfcpver' 557 attribute (Section 8) with the 'm' line. 559 In addition, if the offerer includes an SDP 'floorctrl' attribute 560 with 's-only' or 'c-s' attribute values in the offer, the offerer: 562 o MUST associate an SDP 'confid' attribute (Section 6) with the 'm' 563 line; and 565 o MUST associate an SDP 'userid' attribute (Section 6) with the 'm' 566 line; and 568 o MUST associate an SDP 'floorid' attribute (Section 7) with the 'm' 569 line; and 571 o MUST associate an SDP 'label' attribute (Section 7) with the 'm' 572 line of each BFCP-controlled media stream. 574 Note: If the offerer includes an SDP 'floorctrl' attribute with a 575 'c-s' attribute value, or both a 'c-only' and a 's-only' attribute 576 value, in the offer, the attribute values above will only be used 577 if it is determined (Section 5) that the offerer will act as floor 578 control server. If it is determined that the offerer will act as 579 both floor control server and floor control client, the attribute 580 values will be used for the BFCP-controlled media streams where 581 the offerer acts as floor control server. 583 13.2. Generating the SDP Answer 585 When the answerer receives an offer, which contains an 'm' line 586 describing a BFCP stream, the answerer MUST check whether it supports 587 one or more of the BFCP versions supported by the offerer 588 (Section 8). If the answerer does not support any of the BFCP 589 versions, it MUST NOT accept the 'm' line. Otherwise, if the 590 answerer accepts the 'm' line, it: 592 o MUST insert a corresponding 'm' line in the answer, with an 593 identical 'm' line proto value [4]; and 595 o MUST associate a 'bfcpver' attribute with the 'm' line. The 596 answerer only indicates support of BFCP versions also supported by 597 the offerer; and 599 o MUST, if the offer contained an SDP 'floorctrl' attribute, 600 associate a 'floorctrl' attribute with the 'm' line. 602 In addition, if the answerer includes an SDP 'floorctrl' attribute 603 with 's-only' or 'c-s' attribute values in the answer, the answerer: 605 o MUST associate an SDP 'confid' attribute with the 'm' line; and 607 o MUST associate an SDP 'userid' attribute with the 'm' line; and 609 o MUST associate an SDP 'floorid' attribute with the 'm' line; and 611 o MUST associate an SDP 'label' attribute with the 'm' line of each 612 BFCP-controlled media stream. 614 Note: If the answerer includes an SDP 'floorctrl' attribute with 615 an 'c-s' attribute value in the answer, the attribute values will 616 be used for the BFCP-controlled media streams where the answerer 617 acts as floor control server. 619 Note: An offerer compliant with [14] might not include 'floorctrl' 620 and 'bfcpver' attributes in offers, in which cases the default 621 values apply. 623 Once the answerer has sent the answer, the answerer: 625 o MUST, if the answerer is the 'active' endpoint, and if a TCP 626 connection associated with the 'm' line is to be established (or 627 re-established), initiate the establishing of the TCP connection; 628 and 630 o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS 631 connection associated with the 'm' line is to be established (or 632 re-established), initiate the establishing of the TLS/DTLS 633 connection (by sending a ClientHello message). 635 If the answerer does not accept the 'm' line in the offer, it MUST 636 assign a zero port value to the corresponding 'm' line in the answer. 637 In addition, the answerer MUST NOT establish a TCP connection or a 638 TLS/DTLS connection associated with the 'm' line. 640 13.3. Offerer Processing of the SDP Answer 642 When the offerer receives an answer, which contains an 'm' line with 643 a non-zero port value, describing a BFCP stream, the offerer: 645 o MUST, if the offerer is the 'active' endpoint, and if a TCP 646 connection associated with the 'm' line is to be established (or 647 re-established), initiate the establishing of the TCP connection; 648 and 650 o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS 651 connection associated with the 'm' line is to be established (or 652 re-established), initiate the establishing of the TLS/DTLS 653 connection (by sending a ClientHello message). 655 Note: An answerer compliant with [14] might not include 656 'floorctrl' and 'bfcpver' attributes in answers, in which cases 657 the default values apply. 659 If the 'm' line in the answer contains a zero port value, or if the 660 offerer for some other reason does not accept the answer (e.g., if 661 the answerer only indicates support of BFCP versions not supported by 662 the offerer), the offerer MUST NOT establish a TCP connection or a 663 TLS/DTLS connection associated with the 'm' line. 665 13.4. Modifying the Session 667 When an offerer sends an updated offer, in order to modify a 668 previously established BFCP stream, it follows the procedures in 669 Section 13.1, with the following exceptions: 671 o If the BFCP stream is carried on top of TCP, and if the offerer 672 does not want to re-establish an existing TCP connection, the 673 offerer MUST associate an SDP connection attribute with an 674 'existing' value, with the 'm' line; and 676 o If the offerer wants to disable a previously established BFCP 677 stream, it MUST assign a zero port value to the 'm' line 678 associated with the BFCP connection, following the procedures in 679 [4]. 681 14. Examples 683 For the purpose of brevity, the main portion of the session 684 description is omitted in the examples, which only show 'm' lines and 685 their attributes. 687 The following is an example of an offer sent by a conference server 688 to a client. 690 m=application 50000 TCP/TLS/BFCP * 691 a=setup:actpass 692 a=connection:new 693 a=fingerprint:sha-256 \ 694 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 695 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 696 a=floorctrl:c-only s-only 697 a=confid:4321 698 a=userid:1234 699 a=floorid:1 mstrm:10 700 a=floorid:2 mstrm:11 701 a=bfcpver:1 2 702 m=audio 50002 RTP/AVP 0 703 a=label:10 704 m=video 50004 RTP/AVP 31 705 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 15. Security Considerations 765 The BFCP [17], SDP [9], and offer/answer [4] specifications discuss 766 security issues related to BFCP, SDP, and offer/answer, respectively. 767 In addition, [6] and [8] discuss security issues related to the 768 establishment of TCP and TLS connections using an offer/answer model. 769 Furthermore, when using DTLS over UDP, considerations for its use 770 with RTP and RTCP are presented in [18]. The requirements for the 771 offer/answer exchange, as listed in Section 5 of [18], MUST be 772 followed. 774 An initial integrity-protected channel is REQUIRED for BFCP to 775 exchange self-signed certificates between a client and the floor 776 control server. For session descriptions carried in SIP [3], S/MIME 777 [5] is the natural choice to provide such a channel. 779 16. IANA Considerations 781 [Editorial note: The changes in Section 16.1 instruct the IANA to 782 register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/ 783 BFCP for the SDP 'proto' field. The new section Section 8 784 registers a new SDP "bfcpver" attribute. The rest is unchanged 785 from [13].] 787 16.1. Registration of SDP 'proto' Values 789 The IANA has registered the following values for the SDP 'proto' 790 field under the Session Description Protocol (SDP) Parameters 791 registry: 793 +---------------+------------+ 794 | Value | Reference | 795 +---------------+------------+ 796 | TCP/BFCP | [RFC XXXX] | 797 | TCP/DTLS/BFCP | [RFC XXXX] | 798 | TCP/TLS/BFCP | [RFC XXXX] | 799 | UDP/BFCP | [RFC XXXX] | 800 | UDP/TLS/BFCP | [RFC XXXX] | 801 +---------------+------------+ 803 Table 3: Values for the SDP 'proto' field 805 16.2. Registration of the SDP 'floorctrl' Attribute 807 This document defines the SDP attribute,'floorctrl'. The details of 808 the attribute are defined in Section 5. 810 For issues regarding this attribute contact iesg@ietf.org. 812 16.3. Registration of the SDP 'confid' Attribute 814 This document defines the SDP attribute,'confid'. The details of the 815 attribute are defined in Section 6. 817 For issues regarding this attribute contact iesg@ietf.org. 819 16.4. Registration of the SDP 'userid' Attribute 821 This document defines the SDP attribute,'userid'. The details of the 822 attribute are defined in Section 6. 824 For issues regarding this attribute contact iesg@ietf.org. 826 16.5. Registration of the SDP 'floorid' Attribute 828 This document defines the SDP attribute,'floorid'. The details of 829 the attribute are defined in Section 7. 831 For issues regarding this attribute contact iesg@ietf.org. 833 16.6. Registration of the SDP 'bfcpver' Attribute 835 This document defines the SDP attribute,'bfcpver'. The details of 836 the attribute are defined in Section 8. 838 For issues regarding this attribute contact iesg@ietf.org. 840 17. Changes from RFC 4583 842 Following is the list of technical changes and other fixes from [14]. 844 Main purpose of this work was to add signaling support necessary to 845 support BFCP over unreliable transport, as described in [17], 846 resulting in the following changes: 848 1. Fields in the 'm' line (Section 3): 849 The section is re-written to remove reference to the exclusivity 850 of TCP as a transport for BFCP streams. The proto field values 851 TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added. 853 2. Authentication (Section 11): 854 In last paragraph, made clear that a TCP connection was 855 described. 857 3. Security Considerations (Section 15): 858 For the DTLS over UDP case, mention existing considerations and 859 requirements for the offer/answer exchange in [18]. 861 4. Registration of SDP 'proto' Values (Section 16.1): 862 Register the three new values TCP/DTLS/BFCP, UDP/BFCP and 863 UDP/TLS/BFCP in the SDP parameters registry. 865 5. BFCP Version Negotiation (Section 8): 866 A new 'bfcpver' SDP media-level attribute is added in order to 867 signal supported version number. 869 Clarification and bug fixes: 871 1. Errata ID: 712 (Section 4 and Section 13): 872 Language clarification. Don't use terms like an SDP attribute is 873 "used in an 'm' line", instead make clear that the attribute is a 874 media-level attribute. 876 2. Fix typo in example (Section 14): 877 Do not use 'm-stream' in the SDP example, use the correct 'mstrm' 878 as specified in Section 14. Recommend interpreting 'm-stream' if 879 it is received, since it is present in some implementations. 881 3. Assorted clarifications (Across the document): 882 Language clarifications as a result of reviews. Also, the 883 normative language where tightened where appropriate, i.e. 884 changed from SHOULD strength to MUST in a number of places. 886 18. Acknowledgements 888 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 889 Oscar Novo provided useful ideas for the original [14]. The authors 890 also acknowledge contributions to the revision of BFCP for use over 891 an unreliable transport from Geir Arne Sandbakken, Charles Eckel, 892 Alan Ford, Eoin McLeod and Mark Thompson. Useful and important final 893 reviews were done by Ali C. Begen, Mary Barnes and Charles Eckel. 894 In the final stages, Roman Shpount made a considerable effort in 895 adding proper ICE support and considerations. 897 19. References 899 19.1. Normative References 901 [1] Bradner, S., "Key words for use in RFCs to Indicate 902 Requirement Levels", BCP 14, RFC 2119, 903 DOI 10.17487/RFC2119, March 1997, 904 . 906 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 907 Specifications: ABNF", STD 68, RFC 5234, 908 DOI 10.17487/RFC5234, January 2008, 909 . 911 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 912 A., Peterson, J., Sparks, R., Handley, M., and E. 913 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 914 DOI 10.17487/RFC3261, June 2002, 915 . 917 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 918 with Session Description Protocol (SDP)", RFC 3264, 919 DOI 10.17487/RFC3264, June 2002, 920 . 922 [5] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 923 Mail Extensions (S/MIME) Version 3.2 Certificate 924 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 925 . 927 [6] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 928 the Session Description Protocol (SDP)", RFC 4145, 929 DOI 10.17487/RFC4145, September 2005, 930 . 932 [7] Levin, O. and G. Camarillo, "The Session Description 933 Protocol (SDP) Label Attribute", RFC 4574, 934 DOI 10.17487/RFC4574, August 2006, 935 . 937 [8] Lennox, J. and C. Holmberg, "Connection-Oriented Media 938 Transport over the Transport Layer Security (TLS) Protocol 939 in the Session Description Protocol (SDP)", RFC 8122, 940 DOI 10.17487/RFC8122, March 2017, 941 . 943 [9] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 944 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 945 July 2006, . 947 [10] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 948 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 949 January 2012, . 951 [11] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 952 and RTP Control Protocol (RTCP) Packets over Connection- 953 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 954 2006, . 956 [12] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 957 "TCP Candidates with Interactive Connectivity 958 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 959 March 2012, . 961 [13] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 962 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 963 November 2006, . 965 [14] Camarillo, G., "Session Description Protocol (SDP) Format 966 for Binary Floor Control Protocol (BFCP) Streams", 967 RFC 4583, DOI 10.17487/RFC4583, November 2006, 968 . 970 [15] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 971 Connectivity Establishment (ICE): A Protocol for Network 972 Address Translator (NAT) Traversal", draft-ietf-ice- 973 rfc5245bis-20 (work in progress), March 2018. 975 [16] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 976 "Session Description Protocol (SDP) Offer/Answer 977 procedures for Interactive Connectivity Establishment 978 (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in 979 progress), April 2018. 981 [17] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 982 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 983 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 984 2015. 986 [18] Holmberg, C. and R. Shpount, "Session Description Protocol 987 (SDP) Offer/Answer Considerations for Datagram Transport 988 Layer Security (DTLS) and Transport Layer Security (TLS)", 989 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 990 2017. 992 19.2. Informational References 994 [19] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 995 Media Attributes in the Session Description Protocol 996 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 997 . 999 [20] Holmberg, C., Alvestrand, H., and C. Jennings, 1000 "Negotiating Media Multiplexing Using the Session 1001 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1002 negotiation-51 (work in progress), May 2018. 1004 [21] Nandakumar, S., "A Framework for SDP Attributes when 1005 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 1006 (work in progress), February 2018. 1008 Authors' Addresses 1010 Gonzalo Camarillo 1011 Ericsson 1012 Hirsalantie 11 1013 FI-02420 Jorvas 1014 Finland 1016 Email: Gonzalo.Camarillo@ericsson.com 1018 Tom Kristensen 1019 Cisco 1020 Philip Pedersens vei 1 1021 NO-1366 Lysaker 1022 Norway 1024 Email: tomkrist@cisco.com, tomkri@ifi.uio.no 1025 Christer Holmberg 1026 Ericsson 1027 Hirsalantie 11 1028 Jorvas 02420 1029 Finland 1031 Email: christer.holmberg@ericsson.com