idnits 2.17.1 draft-ietf-bfcpbis-rfc4583bis-21.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 (March 26, 2018) is 2216 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: 'RFC4566' on line 262 -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 732 ** Obsolete normative reference: RFC 5750 (ref. '5') (Obsoleted by RFC 8550) ** Obsolete normative reference: RFC 4566 (ref. '10') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6347 (ref. '11') (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 4582 (ref. '15') (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (ref. '16') (Obsoleted by RFC 8856) == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-16 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-49 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-17 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFCPbis Working Group C. Holmberg 3 Internet-Draft G. Camarillo 4 Obsoletes: 4583 (if approved) Ericsson 5 Intended status: Standards Track T. Kristensen 6 Expires: September 27, 2018 Cisco 7 March 26, 2018 9 Session Description Protocol (SDP) Format for Binary Floor Control 10 Protocol (BFCP) Streams 11 draft-ietf-bfcpbis-rfc4583bis-21 13 Abstract 15 This document defines the Session Description Protocol (SDP) offer/ 16 answer procedures for negotiating and establishing Binary Floor 17 Control Protocol (BFCP) streams. 19 This document obsoletes RFC 4583. Changes from RFC 4583 are 20 summarized in Section 15. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 27, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . 3 59 4. Floor Control Roles . . . . . . . . . . . . . . . . . . . . . 4 60 5. SDP 'floorctrl' Attribute . . . . . . . . . . . . . . . . . . 4 61 6. SDP 'confid' and 'userid' Attributes . . . . . . . . . . . . 6 62 7. SDP 'floorid' Attribute . . . . . . . . . . . . . . . . . . . 6 63 8. SDP 'bfcpver' Attribute . . . . . . . . . . . . . . . . . . . 7 64 9. Multiplexing Considerations . . . . . . . . . . . . . . . . . 7 65 10. BFCP Connection Management . . . . . . . . . . . . . . . . . 8 66 10.1. TCP Connection Management . . . . . . . . . . . . . . . 8 67 11. Authentication . . . . . . . . . . . . . . . . . . . . . . . 9 68 12. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 13. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 70 13.1. Generating the Initial SDP Offer . . . . . . . . . . . . 11 71 13.2. Generating the SDP Answer . . . . . . . . . . . . . . . 12 72 13.3. Offerer Processing of the SDP Answer . . . . . . . . . . 13 73 13.4. Modifying the Session . . . . . . . . . . . . . . . . . 13 74 14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 15. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 16.1. Registration of SDP 'proto' Values . . . . . . . . . . . 16 78 16.2. Registration of the SDP 'floorctrl' Attribute . . . . . 16 79 16.3. Registration of the SDP 'confid' Attribute . . . . . . . 17 80 16.4. Registration of the SDP 'userid' Attribute . . . . . . . 17 81 16.5. Registration of the SDP 'floorid' Attribute . . . . . . 17 82 16.6. Registration of the SDP 'bfcpver' Attribute . . . . . . 18 83 17. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 18 84 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 85 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 19.1. Normative References . . . . . . . . . . . . . . . . . . 19 87 19.2. Informational References . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 As discussed in the BFCP (Binary Floor Control Protocol) 93 specification [7], a given BFCP client needs a set of data in order 94 to establish a BFCP connection to a floor control server. This data 95 includes the transport address of the server, the conference 96 identifier, and the user identifier. 98 One way for clients to obtain this information is to use an SDP 99 offer/answer [4] exchange. This document specifies how to encode 100 this information in the SDP session descriptions that are part of 101 such an offer/answer exchange. 103 User agents typically use the offer/answer model to establish a 104 number of media streams of different types. Following this model, a 105 BFCP connection is described as any other media stream by using an 106 SDP 'm' line, possibly followed by a number of attributes encoded in 107 'a' lines. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14, RFC 2119 [1] and indicate requirement levels for compliant 115 implementations. 117 3. Fields in the 'm' Line 119 This section describes how to generate an 'm' line for a BFCP stream. 121 According to the SDP specification [10], the 'm' line format is the 122 following: 124 m= ... 126 The media field MUST have a value of "application". 128 The port field is set depending on the value of the proto field, as 129 explained below. A port field value of zero has the standard SDP 130 meaning (i.e., rejection of the media stream) regardless of the proto 131 field. 133 When TCP is used as the transport, the port field is set following 134 the rules in [6]. Depending on the value of the 'setup' attribute 135 (discussed in Section 10.1), the port field contains the port to 136 which the remote endpoint will direct BFCP messages, or in the 137 case where the endpoint will initiate the connection towards the 138 remote endpoint, should be set to a value of 9. 140 When UDP is used as the transport, the port field contains the 141 port to which the remote endpoint will direct BFCP messages 142 regardless of the value of the 'setup' attribute. 144 This document defines five values for the proto field: TCP/BFCP, 145 TCP/DTLS/BFCP, TCP/TLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP. 147 TCP/BFCP is used when BFCP runs directly on top of TCP. TCP/TLS/BFCP 148 is used when BFCP runs on top of TLS, which in turn runs on top of 149 TCP. TCP/DTLS/BFCP is used when running BFCP on top of DTLS [11], as 150 described in this specification, which in turn runs on top of TCP 151 using the framing method defined in [12] with DTLS packets being sent 152 and received instead of RTP/RTCP packets using the shim defined in 153 RFC4571 such that the length field defined in RFC4571 precedes each 154 DTLS message. 156 Similarly, UDP/BFCP is used when BFCP runs directly on top of UDP, 157 and UDP/TLS/BFCP is used when BFCP runs on top of DTLS, which in turn 158 runs on top of UDP. 160 The fmt (format) list is not applicable to BFCP. The fmt list of 'm' 161 lines in the case of any proto field value related to BFCP MUST 162 contain a single "*" character. If the the fmt list contains any 163 other value it is ignored. 165 The following is an example of an 'm' line for a BFCP connection: 167 m=application 50000 TCP/TLS/BFCP * 169 4. Floor Control Roles 171 When two endpoints establish a BFCP stream, they need to determine 172 which of them acts as floor control client and which acts as floor 173 control server. Typically, a client that establishes a BFCP stream 174 with a conference server will act as floor control client, while the 175 conference server will act as floor control server. However, there 176 are scenarios where both endpoints would be able to act as floor 177 control server. For example, in a two-party session that involves an 178 audio stream and a shared whiteboard, the endpoints need to determine 179 which party will be act as floor control server. 181 Furthermore, there are situations where both endpoints act as both 182 floor control client and floor control server within the same 183 session. For example, in a two-party session that involves an audio 184 stream and a shared whiteboard, one endpoint acts as the floor 185 control server for the audio stream and the other endpoint acts as 186 the floor control server for the shared whiteboard. However, for a 187 given BFCP-controlled media stream one endpoint MUST act as floor 188 control client and one endpoint MUST act as floor control server. 190 5. SDP 'floorctrl' Attribute 192 This section defines the SDP 'floorctrl' media-level attribute. The 193 attribute is used to determine the floor control role(s) that the 194 endpoints can take for the BFCP-controlled media streams. As 195 described in Section 5, an endpoint can take different roles for 196 different media streams, but for a given media stream an endpoint can 197 only take one role. 199 The Augmented BNF syntax [2] for the attribute is: 201 floor-control-attribute = "a=floorctrl:" role *(SP role) 202 role = "c-only" / "s-only" / "c-s" 204 An endpoint includes the attribute to indicate the role(s) it would 205 be willing to perform for the BFCP-controlled media streams: 207 c-only: The endpoint is willing to act as floor control client. 209 s-only: The endpoint is willing to act as floor control server only. 211 c-s: The endpoint is willing to act as floor control client and 212 floor control server. 214 When inserted in an offer, the offerer MAY indicate multiple 215 attribute values. When inserted in an answer, the answerer MUST 216 indicate only one attribute value. The offerer indicates which floor 217 control role(s) that it is willing to take. The answerer indicates 218 the role taken by the answerer. Based on this, the floor control 219 role(s) of the offerer is determined, as shown in Table 1. 221 +---------+----------+ 222 | Offerer | Answerer | 223 +---------+----------+ 224 | c-only | s-only | 225 | s-only | c-only | 226 | c-s | c-s | 227 +---------+----------+ 229 Table 1: Roles 231 Endpoints compliant with [16] might not include the 'floorctrl' 232 attribute in offers and answerer. If the 'floorctrl' attribute is 233 not present the offerer will act as floor control client, and the 234 answerer will act as floor control server, for each BFCP-controlled 235 media stream. 237 The SDP Offer/Answer procedures for the 'floorctrl' attribute are 238 defined in Section 13. 240 The following is an example of a 'floorctrl' attribute in an offer: 242 a=floorctrl:c-only s-only c-s 244 6. SDP 'confid' and 'userid' Attributes 246 This section defines the SDP 'confid' and the 'userid' media-level 247 attributes. The attributes are used by a floor control server to 248 convey the conference ID value and user ID value to the floor control 249 client, using decimal integer representation. 251 The Augmented BNF syntax [2] for the attributes is: 253 confid-attribute = "a=confid:" conference-id 254 conference-id = token 255 userid-attribute = "a=userid:" user-id 256 user-id = token 258 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 259 / %x41-5A / %x5E-7E 260 token = 1*(token-char) 262 ;token-char and token elements are defined in [RFC4566]. 264 The SDP Offer/Answer procedures for the 'confid' and 'userid' 265 attributes are defined in Section 13. 267 7. SDP 'floorid' Attribute 269 This section defines the SDP 'floorid' media-level attribute. The 270 attribute conveys a floor identifier, and optionally pointers to one 271 or more BFCP-controlled media streams. 273 The Augmented BNF syntax [2] for the attribute is: 275 floor-id-attribute = "a=floorid:" token SP "mstrm:" token *(SP token) 277 The floor identifier value is the integer representation of the Floor 278 ID to be used in BFCP. Each media stream pointer value is associated 279 with an SDP 'label' attribute [8] of a media stream. 281 The SDP Offer/Answer procedures for the 'floorid' attribute are 282 defined in Section 13. 284 Note: In [16] 'm-stream' was erroneously used in Section 14. 285 Although the example was non-normative, it is implemented by some 286 vendors and occurs in cases where the endpoint is willing to act 287 as an server. Therefore, it is RECOMMENDED to support parsing and 288 interpreting 'm-stream' the same way as 'mstrm' when receiving. 290 8. SDP 'bfcpver' Attribute 292 This section defines the SDP 'bfcpver' media-level attribute. The 293 attribute is used to negotiate the BFCP version. 295 The Augmented BNF syntax [2] for the attributes is: 297 bfcp-version-attribute = "a=bfcpver:" bfcp-version *(SP bfcp-version) 298 bfcp-version = token 300 An endpoint uses the 'bfcpver' attribute to convey the version(s) of 301 BFCP supported by the endpoint, using integer values. For a given 302 version, the attribute value representing the version MUST match the 303 "Version" field that would be presented in the BFCP COMMON-HEADER 304 [7]. The BFCP version that will eventually be used will be conveyed 305 with a BFCP-level Hello/HelloAck. 307 Endpoints compliant with [16] might not always include the 'bfcpver' 308 attribute in offers and answers. If the 'bfcpver' attribute is not 309 present, the default values are inferred from the transport specified 310 in the 'm' line (Section 3) associated with the stream. In 311 accordance with definition of the Version field in [7], when used 312 over a reliable transport the default attribute value is "1", and 313 when used over an unreliable transport the default attribute value is 314 "2". 316 The SDP Offer/Answer procedures for the 'bfcpver' attribute are 317 defined in Section 13. 319 9. Multiplexing Considerations 321 [20] defines how multiplexing of multiple media streams can be 322 negotiated. This specification does not define how BFCP streams can 323 be multiplexed with other media streams. Therefore, a BFCP stream 324 MUST NOT be associated with a BUNDLE group [20]. Note that BFCP- 325 controlled media streams might be multiplexed with other media 326 streams. 328 [21] defines the mux categories for the SDP attributes defined in 329 this specification, excluding the SDP 'bfcpver' attribute. . Table 2 330 defines the mux category for the 'bfcpver' attribute: 332 +---------+------------------------+-------+--------------+ 333 | Name | Notes | Level | Mux Category | 334 +---------+------------------------+-------+--------------+ 335 | bfcpver | Needs further analysis | M | TBD | 336 +---------+------------------------+-------+--------------+ 338 Table 2: Multiplexing Attribute Analysis 340 10. BFCP Connection Management 342 BFCP streams can use TCP or UDP as the underlying transport. 343 Endpoints exchanging BFCP messages over UDP send the BFCP messages 344 towards the peer using the connection address and port provided in 345 the SDP 'c' and 'm' lines. TCP connection management is more 346 complicated and is described in the following Section. 348 Note: When using Interactive Connectivity Establishment (ICE) 349 [17], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward 350 procedures for connection management as UDP/BFCP described above 351 apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and 352 is described below. 354 10.1. TCP Connection Management 356 The management of the TCP connection used to transport BFCP messages 357 is performed using the SDP 'setup' and 'connection' attributes [6]. 358 The 'setup' attribute indicates which of the endpoints initiates the 359 TCP connection. The 'connection' attribute handles TCP connection 360 re-establishment. 362 The BFCP specification [7] describes a number of situations when the 363 TCP connection between a floor control client and the floor control 364 server needs to be re-established. However, that specification does 365 not describe the re-establishment process because this process 366 depends on how the connection was established in the first place. 367 Endpoints using the offer/answer mechanism follow the following 368 rules. 370 When the existing TCP connection is closed and re-established 371 following the rules in [7], the floor control client MUST send an 372 offer towards the floor control server in order to re-establish the 373 connection. If a TCP connection cannot deliver a BFCP message and 374 times out, the endpoint that attempted to send the message (i.e., the 375 one that detected the TCP timeout) MUST send an offer in order to re- 376 establish the TCP connection. 378 Endpoints that use the offer/answer mechanism to negotiate TCP 379 connections MUST support the 'setup' and 'connection' attributes. 381 11. Authentication 383 When a BFCP stream is negotiated using the SDP offer/answer 384 mechanism, it is assumed that the offerer and the answerer 385 authenticate each other using some mechanism. TLS/DTLS is the 386 preferred mechanism. Other mechanisms are possible, but are outside 387 the scope of this document. Once this mutual authentication takes 388 place, all the offerer and the answerer need to ensure is that the 389 entity they are receiving BFCP messages from is the same as the one 390 that generated the previous offer or answer. 392 The initial mutual authentication SHOULD take place at the signaling 393 level. Additionally, signaling can use S/MIME [5] to provide an 394 integrity-protected channel with optional confidentiality for the 395 offer/answer exchange. BFCP takes advantage of this integrity- 396 protected offer/answer exchange to perform authentication. Within 397 the offer/answer exchange, the offerer and answerer exchange the 398 fingerprints of their self-signed certificates. These self-signed 399 certificates are then used to establish the TLS/DTLS connection that 400 will carry BFCP traffic between the offerer and the answerer. 402 Endpoints follow the rules in [9] regarding certificate choice and 403 presentation. Endpoints that use the offer/answer model to establish 404 BFCP streams MUST support the 'fingerprint' attribute and MUST 405 include it in their offers and answers. 407 When TLS is used with TCP, once the underlying connection is 408 established, the answerer, which can be the floor control client or 409 the floor control server, acts as the TLS server regardless of its 410 role (passive or active) in the TCP establishment procedure. If the 411 TCP connection is lost, the active endpoint is responsible for re- 412 establishing the TCP connection. Unless a new TLS session is 413 negotiated, subsequent SDP offers and answers will not impact the 414 previously negotiated TLS roles. 416 When DTLS is used with UDP, the requirements specified in Section 5 417 of [14] MUST be followed. 419 Note: How to determine which endpoint initiates the TLS/DTLS 420 association depends on the selected underlying transport. It was 421 decided to keep the original semantics in [16] for TCP to retain 422 backwards compatibility. When using UDP, the procedure defined in 423 [14] was selected in order to be compatible with other DTLS based 424 protocol implementations, such as DTLS-SRTP. Furthermore, the 425 procedure defined in [14] do not overload offer/answer semantics 426 and works for offerless INVITE in scenarios with B2BUAs. 428 12. ICE Considerations 430 Generic SDP offer/answer procedures for Interactive Connectivity 431 Establishment (ICE) are defined in [18]. 433 When BFCP is used with UDP based ICE candidates [17] then the 434 procedures for UDP/TLS/BFCP are used. 436 When BFCP is used with TCP based ICE candidates [13] then the 437 procedures for TCP/DTLS/BFCP are used. 439 Based on the procedures defined in [14], endpoints treat all ICE 440 candidate pairs associated with a BFCP stream on top of a DTLS 441 association as part of the same DTLS association. Thus, there will 442 only be one BFCP handshake and one DTLS handshake even if there are 443 multiple valid candidate pairs, and if BFCF media is shifted between 444 candidate pairs (including switching between UDP to TCP candidate 445 pairs) prior to nomination. If new candidates are added, they will 446 also be part of the same DTLS association. 448 In order to maximize the likelihood of interoperability between the 449 endpoints, all ICE enabled BFCP-over-DTLS endpoints SHOULD implement 450 support for UDP/TLS/BFCP. 452 When an SDP offer or answer conveys multiple ICE candidates for a 453 BFCP stream, UDP based candidates SHOULD be included and the default 454 candidate SHOULD be chosen from one of those UDP candidates. If UDP 455 transport is used for the default candidate, then the 'm' line proto 456 value MUST be 'UDP/TLS/BFCP'. If TCP transport is used for the 457 default candidate, the 'm' line proto value MUST be 'TCP/DTLS/BFCP'. 459 Note: Usage of ICE with protocols other than UDP/TLS/BFCP and 460 TCP/DTLS/BFCP is outside of scope for this specification. 462 13. SDP Offer/Answer Procedures 464 This section defines the SDP offer/answer [4] procedures for 465 negotiating and establishing a BFCP stream. Generic procedures for 466 DTLS are defined in [14]. Generic procedures for TLS are defined in 467 [9]. 469 This section only defines the BFCP-specific procedures. Unless 470 explicitly stated otherwise, the procedures apply to an 'm' line 471 describing a BFCP stream. If an offer or answer contains multiple 472 'm' lines describing BFCP streams, the procedures are applied 473 independently to each stream. 475 If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 476 'UDP/TLS/BFCP', the offerer and answerer follow the generic 477 procedures defined in [9]. 479 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/ 480 TCP' or 'UDP/TLS/BFCP', the offerer and answerer use the SDP 'setup' 481 attribute according to the procedures in [6]. 483 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 484 'TCP/DTLS/BFCP', the offerer and anwerer use the SDP 'connection' 485 attribute according to the procedures in [6]. 487 Note: The use of source-specific SDP parameters [19] is not 488 defined to BFCP streams. 490 13.1. Generating the Initial SDP Offer 492 When the offerer creates an initial offer, the offerer MUST associate 493 an SDP 'floorctrl' attribute (Section 5) with the 'm' line. 495 In addition, if the offerer includes an SDP 'floorctrl' attribute 496 with 's-only' or 'c-s' attribute values in the offer, the offerer: 498 o MUST associate an SDP 'confid' attribute (Section 6) with the 'm' 499 line; 501 o MUST associate an SDP 'userid' attribute (Section 6) with the 'm' 502 line; 504 o MUST associate an SDP 'floorid' attribute (Section 7) with the 'm' 505 line; 507 o MUST associate an SDP 'label' attribute (Section 7) with the 'm' 508 line of each BFCP-controlled media stream; and 510 o MUST associate an SDP 'bfcpver' attribute (Section 8) with the 'm' 511 line. 513 Note: If the offerer includes an SDP 'floorctrl' attribute with a 514 'c-s' attribute value, or both a 'c-only' and a 's-only' attribute 515 value, in the offer, the attribute values above will only be used 516 if it is determined (Section 5) that the offerer will act as floor 517 control server. If it is determined that the offerer will act as 518 both floor control server and floor control client, the attribute 519 values will be used for the BFCP-controlled media streams where 520 the offerer acts as floor control server. 522 13.2. Generating the SDP Answer 524 When the answerer receives an offer, which contains an 'm' line 525 describing a BFCP stream, if the answerer accepts the 'm' line it: 527 o MUST insert a corresponding 'm' line in the answer, with an 528 identical 'm' line proto value [4] 530 o MUST, if the offer contained an SDP 'floorctrl' attribute, 531 associate a 'floorctrl' attribute with the 'm' line; 533 In addition, if the answerer includes an SDP 'floorctrl' attribute 534 with 's-only' or 'c-s' attribute values in the answer, the answerer: 536 o MUST associate an SDP 'confid' attribute with the 'm' line; 538 o MUST associate an SDP 'userid' attribute with the 'm' line; 540 o MUST associate an SDP 'floorid' attribute with the 'm' line; 542 o MUST associate an SDP 'label' attribute with the 'm' line of each 543 BFCP-controlled media stream; and 545 o MUST associate a 'bfcpver' attribute with the 'm' line. 547 Note: If the answerer includes an SDP 'floorctrl' attribute with 548 an 'c-s' attribute value in the answer, the attribute values will 549 be used for the BFCP-controlled media streams where the answerer 550 acts as floor control server. 552 Note: An offerer compliant with [16] might not include 'floorctrl' 553 and 'bfcpver' attributes in offers, in which cases the default 554 values apply. 556 Once the answerer has sent the answer, the answerer: 558 o MUST, if the answerer is the 'active' endpoint, and if a TCP 559 connection associated with the 'm' line is to be established (or 560 re-established), initiate the establishing of the TCP connection; 561 and 563 o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS 564 connection associated with the 'm' line is to be established (or 565 re-established), initiate the establishing of the TLS/DTLS 566 connection (by sending a ClientHello message). 568 If the answerer does not accept the 'm' line in the offer, it MUST 569 assign a zero port value to the corresponding 'm' line in the answer. 571 In addition, the answerer MUST NOT establish a TCP connection or a 572 TLS/DTLS connection associated with the 'm' line. 574 13.3. Offerer Processing of the SDP Answer 576 When the offerer receives an answer, which contains an 'm' line with 577 a non-zero port value, describing a BFCP stream, the offerer: 579 o MUST, if the offer is the 'active' endpoint, and if a TCP 580 connection associated with the 'm' line is to be established (or 581 re-established), initiate the establishing of the TCP connection; 582 and 584 o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS 585 connection associated with the 'm' line is to be established (or 586 re-established), initiate the establishing of the TLS/DTLS 587 connection (by sending a ClientHello message). 589 Note: An answerer compliant with [16] might not include 590 'floorctrl' and 'bfcpver' attributes in answers, in which cases 591 the default values apply. 593 If the 'm' line in the answer contains a zero port value, or if the 594 offerer for some other reason does not accept the answer, the offerer 595 MUST NOT establish a TCP connection or a TLS/DTLS connection 596 associated with the 'm' line. 598 13.4. Modifying the Session 600 When an offerer sends an updated offer, in order to modify a 601 previously established BFCP stream, it follows the procedures in 602 Section 13.1, with the following exceptions: 604 o If the BFCP stream is carried on top of TCP, and if the offerer 605 does not want to re-establish an existing TCP connection, the 606 offerer MUST associate an SDP connection attribute with an 607 'existing' value, with the 'm' line; and 609 o If the offerer wants to disable a previously established BFCP 610 stream, it MUST assign a zero port value to the 'm' line 611 associated with the BFCP connection, following the procedures in 612 [4]. 614 14. Examples 616 For the purpose of brevity, the main portion of the session 617 description is omitted in the examples, which only show 'm' lines and 618 their attributes. 620 The following is an example of an offer sent by a conference server 621 to a client. 623 m=application 50000 TCP/TLS/BFCP * 624 a=setup:actpass 625 a=connection:new 626 a=fingerprint:sha-256 \ 627 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 628 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 629 a=floorctrl:c-only s-only 630 a=confid:4321 631 a=userid:1234 632 a=floorid:1 mstrm:10 633 a=floorid:2 mstrm:11 634 a=bfcpver:1 635 m=audio 50002 RTP/AVP 0 636 a=label:10 637 m=video 50004 RTP/AVP 31 638 a=label:11 640 Note that due to RFC formatting conventions, this document splits SDP 641 across lines whose content would exceed 72 characters. A backslash 642 character marks where this line folding has taken place. This 643 backslash and its trailing CRLF and whitespace would not appear in 644 actual SDP content. 646 The following is the answer returned by the client. 648 m=application 9 TCP/TLS/BFCP * 649 a=setup:active 650 a=connection:new 651 a=fingerprint:sha-256 \ 652 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 653 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 654 a=floorctrl:c-only 655 m=audio 55000 RTP/AVP 0 656 m=video 55002 RTP/AVP 31 658 A similar example using unreliable transport and DTLS is shown below, 659 where the offer is sent from a client. 661 m=application 50000 UDP/TLS/BFCP * 662 a=setup:actpass 663 a=dtls-id:abc3dl 664 a=fingerprint:sha-256 \ 665 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 666 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 667 a=floorctrl:c-only s-only 668 a=confid:4321 669 a=userid:1234 670 a=floorid:1 mstrm:10 671 a=floorid:2 mstrm:11 672 a=bfcpver:2 673 m=audio 50002 RTP/AVP 0 674 a=label:10 675 m=video 50004 RTP/AVP 31 676 a=label:11 678 The following is the answer returned by the server. 680 m=application 55000 UDP/TLS/BFCP * 681 a=setup:active 682 a=dtls-id:abc3dl 683 a=fingerprint:sha-256 \ 684 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 685 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 686 a=floorctrl:s-only 687 a=confid:4321 688 a=userid:1234 689 a=floorid:1 mstrm:10 690 a=floorid:2 mstrm:11 691 a=bfcpver:2 692 m=audio 55002 RTP/AVP 0 693 m=video 55004 RTP/AVP 31 695 15. Security Considerations 697 The BFCP [7], SDP [10], and offer/answer [4] specifications discuss 698 security issues related to BFCP, SDP, and offer/answer, respectively. 699 In addition, [6] and [9] discuss security issues related to the 700 establishment of TCP and TLS connections using an offer/answer model. 701 Furthermore, when using DTLS over UDP, considerations for its use 702 with RTP and RTCP are presented in [14]. The requirements for the 703 offer/answer exchange, as listed in Section 5 of [14], MUST be 704 followed. 706 An initial integrity-protected channel is REQUIRED for BFCP to 707 exchange self-signed certificates between a client and the floor 708 control server. For session descriptions carried in SIP [3], S/MIME 709 [5] is the natural choice to provide such a channel. 711 16. IANA Considerations 713 [Editorial note: The changes in Section 16.1 instruct the IANA to 714 register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/ 715 BFCP for the SDP 'proto' field. The new section Section 16.6 716 registers a new SDP "bfcpver" attribute. The rest is unchanged 717 from [15].] 719 16.1. Registration of SDP 'proto' Values 721 The IANA has registered the following values for the SDP 'proto' 722 field under the Session Description Protocol (SDP) Parameters 723 registry: 725 +---------------+------------+ 726 | Value | Reference | 727 +---------------+------------+ 728 | TCP/BFCP | [RFC XXXX] | 729 | TCP/DTLS/BFCP | [RFC XXXX] | 730 | TCP/TLS/BFCP | [RFC XXXX] | 731 | UDP/BFCP | [RFC XXXX] | 732 | UDP/TLS/BFCP | [RFC XXXX] | 733 +---------------+------------+ 735 Table 3: Values for the SDP 'proto' field 737 16.2. Registration of the SDP 'floorctrl' Attribute 739 The IANA has registered the following SDP att-field under the Session 740 Description Protocol (SDP) Parameters registry: 742 Contact name: iesg@ietf.org 744 Attribute name: floorctrl 746 Long-form attribute name: Floor Control 748 Type of attribute: Media level 750 Subject to charset: No 752 Purpose of attribute: The 'floorctrl' attribute is used to 753 perform floor control server determination. 755 Allowed attribute values: 1*("c-only" / "s-only" / "c-s") 757 16.3. Registration of the SDP 'confid' Attribute 759 The IANA has registered the following SDP att-field under the Session 760 Description Protocol (SDP) Parameters registry: 762 Contact name: iesg@ietf.org 764 Attribute name: confid 766 Long-form attribute name: Conference Identifier 768 Type of attribute: Media level 770 Subject to charset: No 772 Purpose of attribute: The 'confid' attribute carries the 773 integer representation of a Conference ID. 775 Allowed attribute values: A token 777 16.4. Registration of the SDP 'userid' Attribute 779 The IANA has registered the following SDP att-field under the Session 780 Description Protocol (SDP) Parameters registry: 782 Contact name: iesg@ietf.org 784 Attribute name: userid 786 Long-form attribute name: User Identifier 788 Type of attribute: Media level 790 Subject to charset: No 792 Purpose of attribute: The 'userid' attribute carries the 793 integer representation of a User ID. 795 Allowed attribute values: A token 797 16.5. Registration of the SDP 'floorid' Attribute 799 The IANA has registered the following SDP att-field under the Session 800 Description Protocol (SDP) Parameters registry: 802 Contact name: iesg@ietf.org 804 Attribute name: floorid 805 Long-form attribute name: Floor Identifier 807 Type of attribute: Media level 809 Subject to charset: No 811 Purpose of attribute: The 'floorid' attribute associates a 812 floor with one or more media streams. 814 Allowed attribute values: Tokens 816 16.6. Registration of the SDP 'bfcpver' Attribute 818 The IANA has registered the following SDP att-field under the Session 819 Description Protocol (SDP) Parameters registry: 821 Contact name: iesg@ietf.org 823 Attribute name: bfcpver 825 Long-form attribute name: BFCP Version 827 Type of attribute: Media level 829 Subject to charset: No 831 Purpose of attribute: The 'bfcpver' attribute lists supported 832 BFCP versions. 834 Allowed attribute values: Tokens 836 17. Changes from RFC 4583 838 Following is the list of technical changes and other fixes from [16]. 840 Main purpose of this work was to add signaling support necessary to 841 support BFCP over unreliable transport, as described in [7], 842 resulting in the following changes: 844 1. Fields in the 'm' line (Section 3): 845 The section is re-written to remove reference to the exclusivity 846 of TCP as a transport for BFCP streams. The proto field values 847 TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added. 849 2. Authentication (Section 11): 850 In last paragraph, made clear that a TCP connection was 851 described. 853 3. Security Considerations (Section 15): 854 For the DTLS over UDP case, mention existing considerations and 855 requirements for the offer/answer exchange in [14]. 857 4. Registration of SDP 'proto' Values (Section 16.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 8): 862 A new 'bfcpver' SDP media-level attribute is added in order to 863 signal supported version number. 865 Clarification and bug fixes: 867 1. Errata ID: 712 (Section 4 and Section 13): 868 Language clarification. Don't use terms like an SDP attribute is 869 "used in an 'm' line", instead make clear that the attribute is a 870 media-level attribute. 872 2. Fix typo in example (Section 14): 873 Do not use 'm-stream' in the SDP example, use the correct 'mstrm' 874 as specified in Section 14. Recommend interpreting 'm-stream' if 875 it is received, since it is present in some implementations. 877 3. Assorted clarifications (Across the document): 878 Language clarifications as a result of reviews. Also, the 879 normative language where tightened where appropriate, i.e. 880 changed from SHOULD strength to MUST in a number of places. 882 18. Acknowledgements 884 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 885 Oscar Novo provided useful ideas for the original [16]. The authors 886 also acknowledge contributions to the revision of BFCP for use over 887 an unreliable transport from Geir Arne Sandbakken, Charles Eckel, 888 Alan Ford, Eoin McLeod and Mark Thompson. Useful and important final 889 reviews were done by Ali C. Begen, Mary Barnes and Charles Eckel. 890 In the final stages, Roman Shpount made a considerable effort in 891 adding proper ICE support and considerations. 893 19. References 895 19.1. Normative References 897 [1] Bradner, S., "Key words for use in RFCs to Indicate 898 Requirement Levels", BCP 14, RFC 2119, 899 DOI 10.17487/RFC2119, March 1997, 900 . 902 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 903 Specifications: ABNF", STD 68, RFC 5234, 904 DOI 10.17487/RFC5234, January 2008, 905 . 907 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 908 A., Peterson, J., Sparks, R., Handley, M., and E. 909 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 910 DOI 10.17487/RFC3261, June 2002, 911 . 913 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 914 with Session Description Protocol (SDP)", RFC 3264, 915 DOI 10.17487/RFC3264, June 2002, 916 . 918 [5] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 919 Mail Extensions (S/MIME) Version 3.2 Certificate 920 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 921 . 923 [6] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 924 the Session Description Protocol (SDP)", RFC 4145, 925 DOI 10.17487/RFC4145, September 2005, 926 . 928 [7] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 929 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 930 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 931 2015. 933 [8] Levin, O. and G. Camarillo, "The Session Description 934 Protocol (SDP) Label Attribute", RFC 4574, 935 DOI 10.17487/RFC4574, August 2006, 936 . 938 [9] Lennox, J. and C. Holmberg, "Connection-Oriented Media 939 Transport over the Transport Layer Security (TLS) Protocol 940 in the Session Description Protocol (SDP)", RFC 8122, 941 DOI 10.17487/RFC8122, March 2017, 942 . 944 [10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 945 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 946 July 2006, . 948 [11] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 949 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 950 January 2012, . 952 [12] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 953 and RTP Control Protocol (RTCP) Packets over Connection- 954 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 955 2006, . 957 [13] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 958 "TCP Candidates with Interactive Connectivity 959 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 960 March 2012, . 962 [14] Holmberg, C. and R. Shpount, "Session Description Protocol 963 (SDP) Offer/Answer Considerations for Datagram Transport 964 Layer Security (DTLS) and Transport Layer Security (TLS)", 965 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 966 2017. 968 [15] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 969 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 970 November 2006, . 972 [16] Camarillo, G., "Session Description Protocol (SDP) Format 973 for Binary Floor Control Protocol (BFCP) Streams", 974 RFC 4583, DOI 10.17487/RFC4583, November 2006, 975 . 977 [17] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 978 Connectivity Establishment (ICE): A Protocol for Network 979 Address Translator (NAT) Traversal", draft-ietf-ice- 980 rfc5245bis-20 (work in progress), March 2018. 982 [18] Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 983 "Session Description Protocol (SDP) Offer/Answer 984 procedures for Interactive Connectivity Establishment 985 (ICE)", draft-ietf-mmusic-ice-sip-sdp-16 (work in 986 progress), November 2017. 988 19.2. Informational References 990 [19] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 991 Media Attributes in the Session Description Protocol 992 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 993 . 995 [20] Holmberg, C., Alvestrand, H., and C. Jennings, 996 "Negotiating Media Multiplexing Using the Session 997 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 998 negotiation-49 (work in progress), March 2018. 1000 [21] Nandakumar, S., "A Framework for SDP Attributes when 1001 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 1002 (work in progress), February 2018. 1004 Authors' Addresses 1006 Christer Holmberg 1007 Ericsson 1008 Hirsalantie 11 1009 Jorvas 02420 1010 Finland 1012 Email: christer.holmberg@ericsson.com 1014 Gonzalo Camarillo 1015 Ericsson 1016 Hirsalantie 11 1017 FI-02420 Jorvas 1018 Finland 1020 Email: Gonzalo.Camarillo@ericsson.com 1022 Tom Kristensen 1023 Cisco 1024 Philip Pedersens vei 1 1025 NO-1366 Lysaker 1026 Norway 1028 Email: tomkrist@cisco.com, tomkri@ifi.uio.no