idnits 2.17.1 draft-ietf-bfcpbis-rfc4583bis-19.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 22, 2018) is 2226 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 258 -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 710 ** 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 23, 2018 Cisco 7 March 22, 2018 9 Session Description Protocol (SDP) Format for Binary Floor Control 10 Protocol (BFCP) Streams 11 draft-ietf-bfcpbis-rfc4583bis-19 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 23, 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 . . . . . . . . . . . . . . . 11 72 13.3. Offerer Processing of the SDP Answer . . . . . . . . . . 12 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 media stream one endpoint MUST act as floor control client and 188 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 for a given 194 stream ( represented by an SDP media description). 196 The Augmented BNF syntax [2] for the attribute is: 198 floor-control-attribute = "a=floorctrl:" role *(SP role) 199 role = "c-only" / "s-only" / "c-s" 201 An endpoint includes the attribute to indicate the role(s) it would 202 be willing to perform for the stream associated with the attribute: 204 c-only: The endpoint is willing to act as floor control client. 206 s-only: The endpoint is willing to act as floor control server only. 208 c-s: The endpoint is willing to act as floor control client and 209 floor control server. 211 An offerer can indicate multiple attribute value for a given session. 212 An answerer can only indicate one attribute value. The offerer 213 indicates which floor control role(s) that it is willing to take. 214 The answerer indicates the role taken by the answerer. Based on 215 this, the floor control of the offerer is determined, as shown in 216 Table 1. 218 +---------+----------+ 219 | Offerer | Answerer | 220 +---------+----------+ 221 | c-only | s-only | 222 | s-only | c-only | 223 | c-s | c-s | 224 +---------+----------+ 226 Table 1: Roles 228 Endpoints compliant with [16] might not include the 'floorctrl' 229 attribute in offers and answerer. For a given stream, if the 230 'floorctrl' attribute is not present the offerer will act as floor 231 control client and the answerer will act as floor control server. 233 The SDP Offer/Answer procedures for the 'floorctrl' attribute are 234 defined in Section 13. 236 The following is an example of a 'floorctrl' attribute in an offer: 238 a=floorctrl:c-only s-only c-s 240 6. SDP 'confid' and 'userid' Attributes 242 This section defines the SDP 'confid' and the 'userid' media-level 243 attributes. The attributes are used by a floor control server to 244 convey the conference ID value and user ID value to the floor control 245 client, using decimal integer representation. 247 The Augmented BNF syntax [2] for the attributes is: 249 confid-attribute = "a=confid:" conference-id 250 conference-id = token 251 userid-attribute = "a=userid:" user-id 252 user-id = token 254 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 255 / %x41-5A / %x5E-7E 256 token = 1*(token-char) 258 ;token-char and token elements are defined in [RFC4566]. 260 The SDP Offer/Answer procedures for the 'confid' and 'userid' 261 attributes are defined in Section 13. 263 7. SDP 'floorid' Attribute 265 This section defines the SDP 'floorid' media-level attribute. The 266 attribute conveys a floor identifier, and optionally pointers to one 267 or more BFCP-controlled media streams. 269 The Augmented BNF syntax [2] for the attribute is: 271 floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)] 273 The floor identifier value is the integer representation of the Floor 274 ID to be used in BFCP. Each media stream pointer value is associated 275 with an SDP 'label' attribute [8] of a media stream. 277 The SDP Offer/Answer procedures for the 'floorid' attribute are 278 defined in Section 13. 280 Note: In [16] 'm-stream' was erroneously used in Section 14. 281 Although the example was non-normative, it is implemented by some 282 vendors and occurs in cases where the endpoint is willing to act 283 as an server. Therefore, it is RECOMMENDED to support parsing and 284 interpreting 'm-stream' the same way as 'mstrm' when receiving. 286 8. SDP 'bfcpver' Attribute 288 This section defines the SDP 'bfcpver' media-level attribute. The 289 attribute is used to negotiate the BFCP version. 291 The Augmented BNF syntax [2] for the attributes is: 293 bfcp-version-attribute = "a=bfcpver:" bfcp-version *(SP bfcp-version) 294 bfcp-version = token 296 An endpoint uses the 'bfcpver' attribute to convey the version(s) of 297 BFCP supported by the endpoint, using integer values. For a given 298 version, the attribute value representing the version MUST match the 299 "Version" field that would be presented in the BFCP COMMON-HEADER 300 [7]. The BFCP version that will eventually be used will be conveyed 301 with a BFCP-level Hello/HelloAck. 303 Endpoints compliant with [16] might not always include the 'bfcpver' 304 attribute in offers and answers. For a given stream, if the 305 'bfcpver' attribute is not present, the default values are inferred 306 from the transport specified in the 'm' line (Section 3) associated 307 with the stream. In accordance with definition of the Version field 308 in [7], when used over a reliable transport the default attribute 309 value is "1", and when used over an unreliable transport the default 310 attribute value is "2". 312 The SDP Offer/Answer procedures for the 'bfcpver' attribute are 313 defined in Section 13. 315 9. Multiplexing Considerations 317 [20] defines how multiplexing of multiple media streams can be 318 negotiated. This specification does not define how BFCP streams can 319 be multiplexed with other media streams. Therefore, a BFCP stream 320 MUST NOT be associated with a BUNDLE group [20]. Note that BFCP- 321 controlled media streams might be multiplexed with other media 322 streams. 324 [21] defines the mux categories for the SDP attributes defined in 325 this specification, excluding the SDP 'bfcpver' attribute. . Table 2 326 defines the mux category for the 'bfcpver' attribute: 328 +---------+------------------------+-------+--------------+ 329 | Name | Notes | Level | Mux Category | 330 +---------+------------------------+-------+--------------+ 331 | bfcpver | Needs further analysis | M | TBD | 332 +---------+------------------------+-------+--------------+ 334 Table 2: Multiplexing Attribute Analysis 336 10. BFCP Connection Management 338 BFCP streams can use TCP or UDP as the underlying transport. 339 Endpoints exchanging BFCP messages over UDP send the BFCP messages 340 towards the peer using the connection address and port provided in 341 the SDP 'c' and 'm' lines. TCP connection management is more 342 complicated and is described in the following Section. 344 Note: When using Interactive Connectivity Establishment (ICE) 345 [17], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward 346 procedures for connection management as UDP/BFCP described above 347 apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and 348 is described below. 350 10.1. TCP Connection Management 352 The management of the TCP connection used to transport BFCP messages 353 is performed using the SDP 'setup' and 'connection' attributes [6]. 354 The 'setup' attribute indicates which of the endpoints initiates the 355 TCP connection. The 'connection' attribute handles TCP connection 356 re-establishment. 358 The BFCP specification [7] describes a number of situations when the 359 TCP connection between a floor control client and the floor control 360 server needs to be re-established. However, that specification does 361 not describe the re-establishment process because this process 362 depends on how the connection was established in the first place. 363 Endpoints using the offer/answer mechanism follow the following 364 rules. 366 When the existing TCP connection is closed and re-established 367 following the rules in [7], the floor control client MUST send an 368 offer towards the floor control server in order to re-establish the 369 connection. If a TCP connection cannot deliver a BFCP message and 370 times out, the endpoint that attempted to send the message (i.e., the 371 one that detected the TCP timeout) MUST send an offer in order to re- 372 establish the TCP connection. 374 Endpoints that use the offer/answer mechanism to negotiate TCP 375 connections MUST support the 'setup' and 'connection' attributes. 377 11. Authentication 379 When a BFCP stream is negotiated using the SDP offer/answer 380 mechanism, it is assumed that the offerer and the answerer 381 authenticate each other using some mechanism. TLS/DTLS is the 382 preferred mechanism. Other mechanisms are possible, but are outside 383 the scope of this document. Once this mutual authentication takes 384 place, all the offerer and the answerer need to ensure is that the 385 entity they are receiving BFCP messages from is the same as the one 386 that generated the previous offer or answer. 388 The initial mutual authentication SHOULD take place at the signaling 389 level. Additionally, signaling can use S/MIME [5] to provide an 390 integrity-protected channel with optional confidentiality for the 391 offer/answer exchange. BFCP takes advantage of this integrity- 392 protected offer/answer exchange to perform authentication. Within 393 the offer/answer exchange, the offerer and answerer exchange the 394 fingerprints of their self-signed certificates. These self-signed 395 certificates are then used to establish the TLS/DTLS connection that 396 will carry BFCP traffic between the offerer and the answerer. 398 Endpoints follow the rules in [9] regarding certificate choice and 399 presentation. Endpoints that use the offer/answer model to establish 400 BFCP streams MUST support the 'fingerprint' attribute and MUST 401 include it in their offers and answers. 403 When TLS is used with TCP, once the underlying connection is 404 established, the answerer, which can be the floor control client or 405 the floor control server, acts as the TLS server regardless of its 406 role (passive or active) in the TCP establishment procedure. If the 407 TCP connection is lost, the active endpoint is responsible for re- 408 establishing the TCP connection. Unless a new TLS session is 409 negotiated, subsequent SDP offers and answers will not impact the 410 previously negotiated TLS roles. 412 When DTLS is used with UDP, the requirements specified in Section 5 413 of [14] MUST be followed. 415 Informational note: How to determine which endpoint initiates the 416 TLS/DTLS association depends on the selected underlying transport. 417 It was decided to keep the original semantics in [16] for TCP to 418 retain backwards compatibility. When using UDP, the procedure 419 defined in [14] was selected in order to be compatible with other 420 DTLS based protocol implementations, such as DTLS-SRTP. 421 Furthermore, the procedure defined in [14] do not overload offer/ 422 answer semantics and works for offerless INVITE in scenarios with 423 B2BUAs. 425 12. ICE Considerations 427 Generic SDP offer/answer procedures for Interactive Connectivity 428 Establishment (ICE) are defined in [18]. 430 When BFCP is used with UDP based ICE candidates [17] then the 431 procedures for UDP/TLS/BFCP are used. 433 When BFCP is used with TCP based ICE candidates [13] then the 434 procedures for TCP/DTLS/BFCP are used. 436 Based on the procedures defined in [14], endpoints treat all ICE 437 candidate pairs associated with a BFCP stream on top of a DTLS 438 association as part of the same DTLS association. Thus, there will 439 only be one BFCP handshake and one DTLS handshake even if there are 440 multiple valid candidate pairs, and if BFCF media is shifted between 441 candidate pairs (including switching between UDP to TCP candidate 442 pairs) prior to nomination. If new candidates are added, they will 443 also be part of the same DTLS association. 445 In order to maximize the likelihood of interoperability between the 446 endpoints, all ICE enabled BFCP-over-DTLS endpoints SHOULD implement 447 support for UDP/TLS/BFCP. 449 When an SDP offer or answer conveys multiple ICE candidates for a 450 BFCP stream, UDP based candidates SHOULD be included and the default 451 candidate SHOULD be chosen from one of those UDP candidates. If UDP 452 transport is used for the default candidate, then the 'm' line proto 453 value MUST be 'UDP/TLS/BFCP'. If TCP transport is used for the 454 default candidate, the 'm' line proto value MUST be 'TCP/DTLS/BFCP'. 456 Note: Usage of ICE with protocols other than UDP/TLS/BFCP and 457 TCP/DTLS/BFCP is outside of scope for this specification. 459 13. SDP Offer/Answer Procedures 461 This section defines the SDP offer/answer [4] procedures for 462 negotiating and establishing a BFCP stream. Generic procedures for 463 DTLS are defined in [14]. Generic procedures for TLS are defined in 464 [9]. 466 This section only defines the BFCP-specific procedures. The 467 procedures apply to an 'm' line describing a BFCP stream. If an 468 offer or answer contains multiple 'm' lines describing BFCP streams, 469 the procedures are applied independently to each stream. 471 If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 472 'UDP/TLS/BFCP', the offerer and answerer follow the generic 473 procedures defined in [9]. 475 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/ 476 TCP' or 'UDP/TLS/BFCP', the offerer and answerer use the SDP 'setup' 477 attribute according to the procedures in [6]. 479 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 480 'TCP/DTLS/BFCP', the offerer and anwerer use the SDP 'connection' 481 attribute according to the procedures in [6]. 483 Note: The use of source-specific SDP parameters [19] is not 484 defined to BFCP streams. 486 13.1. Generating the Initial SDP Offer 488 When the offerer creates an initial offer, the offerer: 490 o MUST associate an SDP 'floorctrl' attribute (Section 5), with the 491 'm' line; 493 o MUST associate an SDP 'confid' attribute (Section 6), with the 'm' 494 line; 496 o MUST associate an SDP 'userid' attribute (Section 6), with the 'm' 497 line; 499 o MUST associate an SDP 'floorid' attribute (Section 7), with the 500 'm' line; 502 o MUST associate an SDP 'label' attribute (Section 7), with the 'm' 503 line; and 505 o MUST associate an SDP 'bfcpver' attribute (Section 8), with the 506 'm' line. 508 13.2. Generating the SDP Answer 510 When the answerer receives an offer, which contains an 'm' line 511 describing a BFCP stream, if the answerer accepts the 'm' line it: 513 o MUST insert a corresponding 'm' line in the answer, with an 514 identical 'm' line proto value [4] 516 o MUST, if the offer contained an SDP 'floorctrl' attribute, 517 associate a 'floorctrl' attribute with the 'm' line; 519 o MUST associate an SDP 'confid' attribute with the 'm' line; 521 o MUST associate an SDP 'userid' attribute with the 'm' line; 523 o MUST associate an SDP 'floorid' attribute with the 'm' line; 525 o MUST associate an SDP 'label' attribute with the 'm' line; and 527 o MUST, if the offer contained an SDP 'bfcpver' attribute, associate 528 a 'bfcpver' attribute with the 'm' line. 530 Note: An offerer compliant with [16] might not include 'floorctrl' 531 and 'bfcpver' attributes in offers, in which cases the default 532 values apply. 534 Once the answerer has sent the answer, the answerer: 536 o MUST, if the answerer is the 'active' endpoint, and if a TCP 537 connection associated with the 'm' line is to be established (or 538 re-established), initiate the establishing of the TCP connection; 539 and 541 o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS 542 connection associated with the 'm' line is to be established (or 543 re-established), initiate the establishing of the TLS/DTLS 544 connection (by sending a ClientHello message). 546 If the answerer does not accept the 'm' line in the offer, it MUST 547 assign a zero port value to the corresponding 'm' line in the answer. 548 In addition, the answerer MUST NOT establish a TCP connection or a 549 TLS/DTLS connection associated with the 'm' line. 551 13.3. Offerer Processing of the SDP Answer 553 When the offerer receives an answer, which contains an 'm' line with 554 a non-zero port value, describing a BFCP stream, the offerer: 556 o MUST, if the offer is the 'active' endpoint, and if a TCP 557 connection associated with the 'm' line is to be established (or 558 re-established), initiate the establishing of the TCP connection; 559 and 561 o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS 562 connection associated with the 'm' line is to be established (or 563 re-established), initiate the establishing of the TLS/DTLS 564 connection (by sending a ClientHello message). 566 Note: An answerer compliant with [16] might not include 567 'floorctrl' and 'bfcpver' attributes in answers, in which cases 568 the default values apply. 570 If the 'm' line in the answer contains a zero port value, or if the 571 offerer for some other reason does not accept the answer, the offerer 572 MUST NOT establish a TCP connection or a TLS/DTLS connection 573 associated with the 'm' line. 575 13.4. Modifying the Session 577 When an offerer sends an updated offer, in order to modify a 578 previously established BFCP stream, it follows the procedures in 579 Section 13.1, with the following exceptions: 581 o If the BFCP stream is carried on top of TCP, and if the offerer 582 does not want to re-establish an existing TCP connection, the 583 offerer MUST associate an SDP connection attribute with an 584 'existing' value, with the 'm' line; and 586 o If the offerer wants to disable a previously established BFCP 587 stream, it MUST assign a zero port value to the 'm' line 588 associated with the BFCP connection, following the procedures in 589 [4]. 591 14. Examples 593 For the purpose of brevity, the main portion of the session 594 description is omitted in the examples, which only show 'm' lines and 595 their attributes. 597 The following is an example of an offer sent by a conference server 598 to a client. 600 m=application 50000 TCP/TLS/BFCP * 601 a=setup:actpass 602 a=connection:new 603 a=fingerprint:sha-256 \ 604 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 605 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 606 a=floorctrl:c-only s-only 607 a=confid:4321 608 a=userid:1234 609 a=floorid:1 mstrm:10 610 a=floorid:2 mstrm:11 611 a=bfcpver:1 612 m=audio 50002 RTP/AVP 0 613 a=label:10 614 m=video 50004 RTP/AVP 31 615 a=label:11 617 Note that due to RFC formatting conventions, this document splits SDP 618 across lines whose content would exceed 72 characters. A backslash 619 character marks where this line folding has taken place. This 620 backslash and its trailing CRLF and whitespace would not appear in 621 actual SDP content. 623 The following is the answer returned by the client. 625 m=application 9 TCP/TLS/BFCP * 626 a=setup:active 627 a=connection:new 628 a=fingerprint:sha-256 \ 629 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 630 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 631 a=floorctrl:c-only 632 a=bfcpver:1 633 m=audio 55000 RTP/AVP 0 634 m=video 55002 RTP/AVP 31 636 A similar example using unreliable transport and DTLS is shown below, 637 where the offer is sent from a client. 639 m=application 50000 UDP/TLS/BFCP * 640 a=setup:actpass 641 a=dtls-id:abc3dl 642 a=fingerprint:sha-256 \ 643 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 644 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 645 a=floorctrl:c-only s-only 646 a=confid:4321 647 a=userid:1234 648 a=floorid:1 mstrm:10 649 a=floorid:2 mstrm:11 650 a=bfcpver:2 651 m=audio 50002 RTP/AVP 0 652 a=label:10 653 m=video 50004 RTP/AVP 31 654 a=label:11 656 The following is the answer returned by the server. 658 m=application 55000 UDP/TLS/BFCP * 659 a=setup:active 660 a=dtls-id:abc3dl 661 a=fingerprint:sha-256 \ 662 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 663 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 664 a=floorctrl:s-only 665 a=confid:4321 666 a=userid:1234 667 a=floorid:1 mstrm:10 668 a=floorid:2 mstrm:11 669 a=bfcpver:2 670 m=audio 55002 RTP/AVP 0 671 m=video 55004 RTP/AVP 31 673 15. Security Considerations 675 The BFCP [7], SDP [10], and offer/answer [4] specifications discuss 676 security issues related to BFCP, SDP, and offer/answer, respectively. 677 In addition, [6] and [9] discuss security issues related to the 678 establishment of TCP and TLS connections using an offer/answer model. 679 Furthermore, when using DTLS over UDP, considerations for its use 680 with RTP and RTCP are presented in [14]. The requirements for the 681 offer/answer exchange, as listed in Section 5 of [14], MUST be 682 followed. 684 An initial integrity-protected channel is REQUIRED for BFCP to 685 exchange self-signed certificates between a client and the floor 686 control server. For session descriptions carried in SIP [3], S/MIME 687 [5] is the natural choice to provide such a channel. 689 16. IANA Considerations 691 [Editorial note: The changes in Section 16.1 instruct the IANA to 692 register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/ 693 BFCP for the SDP 'proto' field. The new section Section 16.6 694 registers a new SDP "bfcpver" attribute. The rest is unchanged 695 from [15].] 697 16.1. Registration of SDP 'proto' Values 699 The IANA has registered the following values for the SDP 'proto' 700 field under the Session Description Protocol (SDP) Parameters 701 registry: 703 +---------------+------------+ 704 | Value | Reference | 705 +---------------+------------+ 706 | TCP/BFCP | [RFC XXXX] | 707 | TCP/DTLS/BFCP | [RFC XXXX] | 708 | TCP/TLS/BFCP | [RFC XXXX] | 709 | UDP/BFCP | [RFC XXXX] | 710 | UDP/TLS/BFCP | [RFC XXXX] | 711 +---------------+------------+ 713 Table 3: Values for the SDP 'proto' field 715 16.2. Registration of the SDP 'floorctrl' Attribute 717 The IANA has registered the following SDP att-field under the Session 718 Description Protocol (SDP) Parameters registry: 720 Contact name: iesg@ietf.org 722 Attribute name: floorctrl 724 Long-form attribute name: Floor Control 726 Type of attribute: Media level 728 Subject to charset: No 730 Purpose of attribute: The 'floorctrl' attribute is used to 731 perform floor control server determination. 733 Allowed attribute values: 1*("c-only" / "s-only" / "c-s") 735 16.3. Registration of the SDP 'confid' Attribute 737 The IANA has registered the following SDP att-field under the Session 738 Description Protocol (SDP) Parameters registry: 740 Contact name: iesg@ietf.org 742 Attribute name: confid 744 Long-form attribute name: Conference Identifier 746 Type of attribute: Media level 748 Subject to charset: No 750 Purpose of attribute: The 'confid' attribute carries the 751 integer representation of a Conference ID. 753 Allowed attribute values: A token 755 16.4. Registration of the SDP 'userid' Attribute 757 The IANA has registered the following SDP att-field under the Session 758 Description Protocol (SDP) Parameters registry: 760 Contact name: iesg@ietf.org 762 Attribute name: userid 764 Long-form attribute name: User Identifier 766 Type of attribute: Media level 768 Subject to charset: No 770 Purpose of attribute: The 'userid' attribute carries the 771 integer representation of a User ID. 773 Allowed attribute values: A token 775 16.5. Registration of the SDP 'floorid' Attribute 777 The IANA has registered the following SDP att-field under the Session 778 Description Protocol (SDP) Parameters registry: 780 Contact name: iesg@ietf.org 782 Attribute name: floorid 783 Long-form attribute name: Floor Identifier 785 Type of attribute: Media level 787 Subject to charset: No 789 Purpose of attribute: The 'floorid' attribute associates a 790 floor with one or more media streams. 792 Allowed attribute values: Tokens 794 16.6. Registration of the SDP 'bfcpver' Attribute 796 The IANA has registered the following SDP att-field under the Session 797 Description Protocol (SDP) Parameters registry: 799 Contact name: iesg@ietf.org 801 Attribute name: bfcpver 803 Long-form attribute name: BFCP Version 805 Type of attribute: Media level 807 Subject to charset: No 809 Purpose of attribute: The 'bfcpver' attribute lists supported 810 BFCP versions. 812 Allowed attribute values: Tokens 814 17. Changes from RFC 4583 816 Following is the list of technical changes and other fixes from [16]. 818 Main purpose of this work was to add signaling support necessary to 819 support BFCP over unreliable transport, as described in [7], 820 resulting in the following changes: 822 1. Fields in the 'm' line (Section 3): 823 The section is re-written to remove reference to the exclusivity 824 of TCP as a transport for BFCP streams. The proto field values 825 TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added. 827 2. Authentication (Section 11): 828 In last paragraph, made clear that a TCP connection was 829 described. 831 3. Security Considerations (Section 15): 832 For the DTLS over UDP case, mention existing considerations and 833 requirements for the offer/answer exchange in [14]. 835 4. Registration of SDP 'proto' Values (Section 16.1): 836 Register the three new values TCP/DTLS/BFCP, UDP/BFCP and 837 UDP/TLS/BFCP in the SDP parameters registry. 839 5. BFCP Version Negotiation (Section 8): 840 A new 'bfcpver' SDP media-level attribute is added in order to 841 signal supported version number. 843 Clarification and bug fixes: 845 1. Errata ID: 712 (Section 4 and Section 13): 846 Language clarification. Don't use terms like an SDP attribute is 847 "used in an 'm' line", instead make clear that the attribute is a 848 media-level attribute. 850 2. Fix typo in example (Section 14): 851 Do not use 'm-stream' in the SDP example, use the correct 'mstrm' 852 as specified in Section 14. Recommend interpreting 'm-stream' if 853 it is received, since it is present in some implementations. 855 3. Assorted clarifications (Across the document): 856 Language clarifications as a result of reviews. Also, the 857 normative language where tightened where appropriate, i.e. 858 changed from SHOULD strength to MUST in a number of places. 860 18. Acknowledgements 862 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 863 Oscar Novo provided useful ideas for the original [16]. The authors 864 also acknowledge contributions to the revision of BFCP for use over 865 an unreliable transport from Geir Arne Sandbakken, Charles Eckel, 866 Alan Ford, Eoin McLeod and Mark Thompson. Useful and important final 867 reviews were done by Ali C. Begen, Mary Barnes and Charles Eckel. 868 In the final stages, Roman Shpount made a considerable effort in 869 adding proper ICE support and considerations. 871 19. References 873 19.1. Normative References 875 [1] Bradner, S., "Key words for use in RFCs to Indicate 876 Requirement Levels", BCP 14, RFC 2119, 877 DOI 10.17487/RFC2119, March 1997, 878 . 880 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 881 Specifications: ABNF", STD 68, RFC 5234, 882 DOI 10.17487/RFC5234, January 2008, 883 . 885 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 886 A., Peterson, J., Sparks, R., Handley, M., and E. 887 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 888 DOI 10.17487/RFC3261, June 2002, 889 . 891 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 892 with Session Description Protocol (SDP)", RFC 3264, 893 DOI 10.17487/RFC3264, June 2002, 894 . 896 [5] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 897 Mail Extensions (S/MIME) Version 3.2 Certificate 898 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 899 . 901 [6] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 902 the Session Description Protocol (SDP)", RFC 4145, 903 DOI 10.17487/RFC4145, September 2005, 904 . 906 [7] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 907 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 908 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 909 2015. 911 [8] Levin, O. and G. Camarillo, "The Session Description 912 Protocol (SDP) Label Attribute", RFC 4574, 913 DOI 10.17487/RFC4574, August 2006, 914 . 916 [9] Lennox, J. and C. Holmberg, "Connection-Oriented Media 917 Transport over the Transport Layer Security (TLS) Protocol 918 in the Session Description Protocol (SDP)", RFC 8122, 919 DOI 10.17487/RFC8122, March 2017, 920 . 922 [10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 923 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 924 July 2006, . 926 [11] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 927 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 928 January 2012, . 930 [12] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 931 and RTP Control Protocol (RTCP) Packets over Connection- 932 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 933 2006, . 935 [13] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 936 "TCP Candidates with Interactive Connectivity 937 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 938 March 2012, . 940 [14] Holmberg, C. and R. Shpount, "Session Description Protocol 941 (SDP) Offer/Answer Considerations for Datagram Transport 942 Layer Security (DTLS) and Transport Layer Security (TLS)", 943 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 944 2017. 946 [15] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 947 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 948 November 2006, . 950 [16] Camarillo, G., "Session Description Protocol (SDP) Format 951 for Binary Floor Control Protocol (BFCP) Streams", 952 RFC 4583, DOI 10.17487/RFC4583, November 2006, 953 . 955 [17] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 956 Connectivity Establishment (ICE): A Protocol for Network 957 Address Translator (NAT) Traversal", draft-ietf-ice- 958 rfc5245bis-20 (work in progress), March 2018. 960 [18] Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 961 "Session Description Protocol (SDP) Offer/Answer 962 procedures for Interactive Connectivity Establishment 963 (ICE)", draft-ietf-mmusic-ice-sip-sdp-16 (work in 964 progress), November 2017. 966 19.2. Informational References 968 [19] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 969 Media Attributes in the Session Description Protocol 970 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 971 . 973 [20] Holmberg, C., Alvestrand, H., and C. Jennings, 974 "Negotiating Media Multiplexing Using the Session 975 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 976 negotiation-49 (work in progress), March 2018. 978 [21] Nandakumar, S., "A Framework for SDP Attributes when 979 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 980 (work in progress), February 2018. 982 Authors' Addresses 984 Christer Holmberg 985 Ericsson 986 Hirsalantie 11 987 Jorvas 02420 988 Finland 990 Email: christer.holmberg@ericsson.com 992 Gonzalo Camarillo 993 Ericsson 994 Hirsalantie 11 995 FI-02420 Jorvas 996 Finland 998 Email: Gonzalo.Camarillo@ericsson.com 1000 Tom Kristensen 1001 Cisco 1002 Philip Pedersens vei 1 1003 NO-1366 Lysaker 1004 Norway 1006 Email: tomkrist@cisco.com, tomkri@ifi.uio.no