idnits 2.17.1 draft-ietf-bfcpbis-rfc4583bis-22.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 (April 10, 2018) is 2207 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 263 -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 733 ** 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-20 == 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 G. Camarillo 3 Internet-Draft Ericsson 4 Obsoletes: 4583 (if approved) T. Kristensen 5 Intended status: Standards Track Cisco 6 Expires: October 12, 2018 C. Holmberg 7 Ericsson 8 April 10, 2018 10 Session Description Protocol (SDP) Format for Binary Floor Control 11 Protocol (BFCP) Streams 12 draft-ietf-bfcpbis-rfc4583bis-22 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 http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 12, 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 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. 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 . . . . . . . . . . . . . . . . . . . 6 64 8. SDP 'bfcpver' Attribute . . . . . . . . . . . . . . . . . . . 7 65 9. Multiplexing Considerations . . . . . . . . . . . . . . . . . 7 66 10. BFCP Connection Management . . . . . . . . . . . . . . . . . 8 67 10.1. TCP Connection Management . . . . . . . . . . . . . . . 8 68 11. Authentication . . . . . . . . . . . . . . . . . . . . . . . 9 69 12. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 13. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 71 13.1. Generating the Initial SDP Offer . . . . . . . . . . . . 11 72 13.2. Generating the SDP Answer . . . . . . . . . . . . . . . 12 73 13.3. Offerer Processing of the SDP Answer . . . . . . . . . . 13 74 13.4. Modifying the Session . . . . . . . . . . . . . . . . . 13 75 14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 15. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 16.1. Registration of SDP 'proto' Values . . . . . . . . . . . 16 79 16.2. Registration of the SDP 'floorctrl' Attribute . . . . . 16 80 16.3. Registration of the SDP 'confid' Attribute . . . . . . . 17 81 16.4. Registration of the SDP 'userid' Attribute . . . . . . . 17 82 16.5. Registration of the SDP 'floorid' Attribute . . . . . . 17 83 16.6. Registration of the SDP 'bfcpver' Attribute . . . . . . 18 84 17. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 18 85 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 86 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 19.1. Normative References . . . . . . . . . . . . . . . . . . 19 88 19.2. Informational References . . . . . . . . . . . . . . . . 21 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 As discussed in the BFCP (Binary Floor Control Protocol) 94 specification [7], 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 [10], 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 [11], as 151 described in this specification, which in turn runs on top of TCP 152 using the framing method defined in [12] 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 The Augmented BNF syntax [2] for the attribute is: 202 floor-control-attribute = "a=floorctrl:" role *(SP role) 203 role = "c-only" / "s-only" / "c-s" 205 An endpoint includes the attribute to indicate the role(s) it would 206 be willing to perform for the BFCP-controlled media streams: 208 c-only: The endpoint is willing to act as floor control client. 210 s-only: The endpoint is willing to act as floor control server only. 212 c-s: The endpoint is willing to act as floor control client and 213 floor control server. 215 When inserted in an offer, the offerer MAY indicate multiple 216 attribute values. When inserted in an answer, the answerer MUST 217 indicate only one attribute value. The offerer indicates which floor 218 control role(s) that it is willing to take. The answerer indicates 219 the role taken by the answerer. Based on this, the floor control 220 role(s) of the offerer is determined, as shown in Table 1. 222 +---------+----------+ 223 | Offerer | Answerer | 224 +---------+----------+ 225 | c-only | s-only | 226 | s-only | c-only | 227 | c-s | c-s | 228 +---------+----------+ 230 Table 1: Roles 232 Endpoints compliant with [16] might not include the 'floorctrl' 233 attribute in offers and answerer. If the 'floorctrl' attribute is 234 not present the offerer will act as floor control client, and the 235 answerer will act as floor control server, for each BFCP-controlled 236 media stream. 238 The SDP Offer/Answer procedures for the 'floorctrl' attribute are 239 defined in Section 13. 241 The following is an example of a 'floorctrl' attribute in an offer: 243 a=floorctrl:c-only s-only c-s 245 6. SDP 'confid' and 'userid' Attributes 247 This section defines the SDP 'confid' and the 'userid' media-level 248 attributes. The attributes are used by a floor control server to 249 convey the conference ID value and user ID value to the floor control 250 client, using decimal integer representation. 252 The Augmented BNF syntax [2] for the attributes is: 254 confid-attribute = "a=confid:" conference-id 255 conference-id = token 256 userid-attribute = "a=userid:" user-id 257 user-id = token 259 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 260 / %x41-5A / %x5E-7E 261 token = 1*(token-char) 263 ;token-char and token elements are defined in [RFC4566]. 265 The SDP Offer/Answer procedures for the 'confid' and 'userid' 266 attributes are defined in Section 13. 268 7. SDP 'floorid' Attribute 270 This section defines the SDP 'floorid' media-level attribute. The 271 attribute conveys a floor identifier, and optionally pointers to one 272 or more BFCP-controlled media streams. 274 The Augmented BNF syntax [2] for the attribute is: 276 floor-id-attribute = "a=floorid:" token SP "mstrm:" token *(SP token) 278 The floor identifier value is the integer representation of the Floor 279 ID to be used in BFCP. Each media stream pointer value is associated 280 with an SDP 'label' attribute [8] of a media stream. 282 The SDP Offer/Answer procedures for the 'floorid' attribute are 283 defined in Section 13. 285 Note: In [16] 'm-stream' was erroneously used in Section 14. 286 Although the example was non-normative, it is implemented by some 287 vendors and occurs in cases where the endpoint is willing to act 288 as an server. Therefore, it is RECOMMENDED to support parsing and 289 interpreting 'm-stream' the same way as 'mstrm' when receiving. 291 8. SDP 'bfcpver' Attribute 293 This section defines the SDP 'bfcpver' media-level attribute. The 294 attribute is used to negotiate the BFCP version. 296 The Augmented BNF syntax [2] for the attributes is: 298 bfcp-version-attribute = "a=bfcpver:" bfcp-version *(SP bfcp-version) 299 bfcp-version = token 301 An endpoint uses the 'bfcpver' attribute to convey the version(s) of 302 BFCP supported by the endpoint, using integer values. For a given 303 version, the attribute value representing the version MUST match the 304 "Version" field that would be presented in the BFCP COMMON-HEADER 305 [7]. The BFCP version that will eventually be used will be conveyed 306 with a BFCP-level Hello/HelloAck. 308 Endpoints compliant with [16] might not always include the 'bfcpver' 309 attribute in offers and answers. If the 'bfcpver' attribute is not 310 present, the default values are inferred from the transport specified 311 in the 'm' line (Section 3) associated with the stream. In 312 accordance with definition of the Version field in [7], when used 313 over a reliable transport the default attribute value is "1", and 314 when used over an unreliable transport the default attribute value is 315 "2". 317 The SDP Offer/Answer procedures for the 'bfcpver' attribute are 318 defined in Section 13. 320 9. Multiplexing Considerations 322 [20] defines how multiplexing of multiple media streams can be 323 negotiated. This specification does not define how BFCP streams can 324 be multiplexed with other media streams. Therefore, a BFCP stream 325 MUST NOT be associated with a BUNDLE group [20]. Note that BFCP- 326 controlled media streams might be multiplexed with other media 327 streams. 329 [21] defines the mux categories for the SDP attributes defined in 330 this specification, excluding the SDP 'bfcpver' attribute. . Table 2 331 defines the mux category for the 'bfcpver' attribute: 333 +---------+------------------------+-------+--------------+ 334 | Name | Notes | Level | Mux Category | 335 +---------+------------------------+-------+--------------+ 336 | bfcpver | Needs further analysis | M | TBD | 337 +---------+------------------------+-------+--------------+ 339 Table 2: Multiplexing Attribute Analysis 341 10. BFCP Connection Management 343 BFCP streams can use TCP or UDP as the underlying transport. 344 Endpoints exchanging BFCP messages over UDP send the BFCP messages 345 towards the peer using the connection address and port provided in 346 the SDP 'c' and 'm' lines. TCP connection management is more 347 complicated and is described in the following Section. 349 Note: When using Interactive Connectivity Establishment (ICE) 350 [17], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward 351 procedures for connection management as UDP/BFCP described above 352 apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and 353 is described below. 355 10.1. TCP Connection Management 357 The management of the TCP connection used to transport BFCP messages 358 is performed using the SDP 'setup' and 'connection' attributes [6]. 359 The 'setup' attribute indicates which of the endpoints initiates the 360 TCP connection. The 'connection' attribute handles TCP connection 361 re-establishment. 363 The BFCP specification [7] describes a number of situations when the 364 TCP connection between a floor control client and the floor control 365 server needs to be re-established. However, that specification does 366 not describe the re-establishment process because this process 367 depends on how the connection was established in the first place. 368 Endpoints using the offer/answer mechanism follow the following 369 rules. 371 When the existing TCP connection is closed and re-established 372 following the rules in [7], the floor control client MUST send an 373 offer towards the floor control server in order to re-establish the 374 connection. If a TCP connection cannot deliver a BFCP message and 375 times out, the endpoint that attempted to send the message (i.e., the 376 one that detected the TCP timeout) MUST send an offer in order to re- 377 establish the TCP connection. 379 Endpoints that use the offer/answer mechanism to negotiate TCP 380 connections MUST support the 'setup' and 'connection' attributes. 382 11. Authentication 384 When a BFCP stream is negotiated using the SDP offer/answer 385 mechanism, it is assumed that the offerer and the answerer 386 authenticate each other using some mechanism. TLS/DTLS is the 387 preferred mechanism. Other mechanisms are possible, but are outside 388 the scope of this document. Once this mutual authentication takes 389 place, all the offerer and the answerer need to ensure is that the 390 entity they are receiving BFCP messages from is the same as the one 391 that generated the previous offer or answer. 393 The initial mutual authentication SHOULD take place at the signaling 394 level. Additionally, signaling can use S/MIME [5] to provide an 395 integrity-protected channel with optional confidentiality for the 396 offer/answer exchange. BFCP takes advantage of this integrity- 397 protected offer/answer exchange to perform authentication. Within 398 the offer/answer exchange, the offerer and answerer exchange the 399 fingerprints of their self-signed certificates. These self-signed 400 certificates are then used to establish the TLS/DTLS connection that 401 will carry BFCP traffic between the offerer and the answerer. 403 Endpoints follow the rules in [9] regarding certificate choice and 404 presentation. Endpoints that use the offer/answer model to establish 405 BFCP streams MUST support the 'fingerprint' attribute and MUST 406 include it in their offers and answers. 408 When TLS is used with TCP, once the underlying connection is 409 established, the answerer, which can be the floor control client or 410 the floor control server, acts as the TLS server regardless of its 411 role (passive or active) in the TCP establishment procedure. If the 412 TCP connection is lost, the active endpoint is responsible for re- 413 establishing the TCP connection. Unless a new TLS session is 414 negotiated, subsequent SDP offers and answers will not impact the 415 previously negotiated TLS roles. 417 When DTLS is used with UDP, the requirements specified in Section 5 418 of [14] MUST be followed. 420 Note: How to determine which endpoint initiates the TLS/DTLS 421 association depends on the selected underlying transport. It was 422 decided to keep the original semantics in [16] for TCP to retain 423 backwards compatibility. When using UDP, the procedure defined in 424 [14] was selected in order to be compatible with other DTLS based 425 protocol implementations, such as DTLS-SRTP. Furthermore, the 426 procedure defined in [14] do not overload offer/answer semantics 427 and works for offerless INVITE in scenarios with B2BUAs. 429 12. ICE Considerations 431 Generic SDP offer/answer procedures for Interactive Connectivity 432 Establishment (ICE) are defined in [18]. 434 When BFCP is used with UDP based ICE candidates [17] then the 435 procedures for UDP/TLS/BFCP are used. 437 When BFCP is used with TCP based ICE candidates [13] then the 438 procedures for TCP/DTLS/BFCP are used. 440 Based on the procedures defined in [14], endpoints treat all ICE 441 candidate pairs associated with a BFCP stream on top of a DTLS 442 association as part of the same DTLS association. Thus, there will 443 only be one BFCP handshake and one DTLS handshake even if there are 444 multiple valid candidate pairs, and if BFCF media is shifted between 445 candidate pairs (including switching between UDP to TCP candidate 446 pairs) prior to nomination. If new candidates are added, they will 447 also be part of the same DTLS association. 449 In order to maximize the likelihood of interoperability between the 450 endpoints, all ICE enabled BFCP-over-DTLS endpoints SHOULD implement 451 support for UDP/TLS/BFCP. 453 When an SDP offer or answer conveys multiple ICE candidates for a 454 BFCP stream, UDP based candidates SHOULD be included and the default 455 candidate SHOULD be chosen from one of those UDP candidates. If UDP 456 transport is used for the default candidate, then the 'm' line proto 457 value MUST be 'UDP/TLS/BFCP'. If TCP transport is used for the 458 default candidate, the 'm' line proto value MUST be 'TCP/DTLS/BFCP'. 460 Note: Usage of ICE with protocols other than UDP/TLS/BFCP and 461 TCP/DTLS/BFCP is outside of scope for this specification. 463 13. SDP Offer/Answer Procedures 465 This section defines the SDP offer/answer [4] procedures for 466 negotiating and establishing a BFCP stream. Generic procedures for 467 DTLS are defined in [14]. Generic procedures for TLS are defined in 468 [9]. 470 This section only defines the BFCP-specific procedures. Unless 471 explicitly stated otherwise, the procedures apply to an 'm' line 472 describing a BFCP stream. If an offer or answer contains multiple 473 'm' lines describing BFCP streams, the procedures are applied 474 independently to each stream. 476 If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 477 'UDP/TLS/BFCP', the offerer and answerer follow the generic 478 procedures defined in [9]. 480 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/ 481 TCP' or 'UDP/TLS/BFCP', the offerer and answerer use the SDP 'setup' 482 attribute according to the procedures in [6]. 484 If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 485 'TCP/DTLS/BFCP', the offerer and anwerer use the SDP 'connection' 486 attribute according to the procedures in [6]. 488 Note: The use of source-specific SDP parameters [19] is not 489 defined to BFCP streams. 491 13.1. Generating the Initial SDP Offer 493 When the offerer creates an initial offer, the offerer MUST associate 494 an SDP 'floorctrl' attribute (Section 5) with the 'm' line. 496 In addition, if the offerer includes an SDP 'floorctrl' attribute 497 with 's-only' or 'c-s' attribute values in the offer, the offerer: 499 o MUST associate an SDP 'confid' attribute (Section 6) with the 'm' 500 line; 502 o MUST associate an SDP 'userid' attribute (Section 6) with the 'm' 503 line; 505 o MUST associate an SDP 'floorid' attribute (Section 7) with the 'm' 506 line; 508 o MUST associate an SDP 'label' attribute (Section 7) with the 'm' 509 line of each BFCP-controlled media stream; and 511 o MUST associate an SDP 'bfcpver' attribute (Section 8) with the 'm' 512 line. 514 Note: If the offerer includes an SDP 'floorctrl' attribute with a 515 'c-s' attribute value, or both a 'c-only' and a 's-only' attribute 516 value, in the offer, the attribute values above will only be used 517 if it is determined (Section 5) that the offerer will act as floor 518 control server. If it is determined that the offerer will act as 519 both floor control server and floor control client, the attribute 520 values will be used for the BFCP-controlled media streams where 521 the offerer acts as floor control server. 523 13.2. Generating the SDP Answer 525 When the answerer receives an offer, which contains an 'm' line 526 describing a BFCP stream, if the answerer accepts the 'm' line it: 528 o MUST insert a corresponding 'm' line in the answer, with an 529 identical 'm' line proto value [4] 531 o MUST, if the offer contained an SDP 'floorctrl' attribute, 532 associate a 'floorctrl' attribute with the 'm' line; 534 In addition, if the answerer includes an SDP 'floorctrl' attribute 535 with 's-only' or 'c-s' attribute values in the answer, the answerer: 537 o MUST associate an SDP 'confid' attribute with the 'm' line; 539 o MUST associate an SDP 'userid' attribute with the 'm' line; 541 o MUST associate an SDP 'floorid' attribute with the 'm' line; 543 o MUST associate an SDP 'label' attribute with the 'm' line of each 544 BFCP-controlled media stream; and 546 o MUST associate a 'bfcpver' attribute with the 'm' line. 548 Note: If the answerer includes an SDP 'floorctrl' attribute with 549 an 'c-s' attribute value in the answer, the attribute values will 550 be used for the BFCP-controlled media streams where the answerer 551 acts as floor control server. 553 Note: An offerer compliant with [16] might not include 'floorctrl' 554 and 'bfcpver' attributes in offers, in which cases the default 555 values apply. 557 Once the answerer has sent the answer, the answerer: 559 o MUST, if the answerer is the 'active' endpoint, and if a TCP 560 connection associated with the 'm' line is to be established (or 561 re-established), initiate the establishing of the TCP connection; 562 and 564 o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS 565 connection associated with the 'm' line is to be established (or 566 re-established), initiate the establishing of the TLS/DTLS 567 connection (by sending a ClientHello message). 569 If the answerer does not accept the 'm' line in the offer, it MUST 570 assign a zero port value to the corresponding 'm' line in the answer. 572 In addition, the answerer MUST NOT establish a TCP connection or a 573 TLS/DTLS connection associated with the 'm' line. 575 13.3. Offerer Processing of the SDP Answer 577 When the offerer receives an answer, which contains an 'm' line with 578 a non-zero port value, describing a BFCP stream, the offerer: 580 o MUST, if the offer is the 'active' endpoint, and if a TCP 581 connection associated with the 'm' line is to be established (or 582 re-established), initiate the establishing of the TCP connection; 583 and 585 o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS 586 connection associated with the 'm' line is to be established (or 587 re-established), initiate the establishing of the TLS/DTLS 588 connection (by sending a ClientHello message). 590 Note: An answerer compliant with [16] might not include 591 'floorctrl' and 'bfcpver' attributes in answers, in which cases 592 the default values apply. 594 If the 'm' line in the answer contains a zero port value, or if the 595 offerer for some other reason does not accept the answer, the offerer 596 MUST NOT establish a TCP connection or a TLS/DTLS connection 597 associated with the 'm' line. 599 13.4. Modifying the Session 601 When an offerer sends an updated offer, in order to modify a 602 previously established BFCP stream, it follows the procedures in 603 Section 13.1, with the following exceptions: 605 o If the BFCP stream is carried on top of TCP, and if the offerer 606 does not want to re-establish an existing TCP connection, the 607 offerer MUST associate an SDP connection attribute with an 608 'existing' value, with the 'm' line; and 610 o If the offerer wants to disable a previously established BFCP 611 stream, it MUST assign a zero port value to the 'm' line 612 associated with the BFCP connection, following the procedures in 613 [4]. 615 14. Examples 617 For the purpose of brevity, the main portion of the session 618 description is omitted in the examples, which only show 'm' lines and 619 their attributes. 621 The following is an example of an offer sent by a conference server 622 to a client. 624 m=application 50000 TCP/TLS/BFCP * 625 a=setup:actpass 626 a=connection:new 627 a=fingerprint:sha-256 \ 628 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 629 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 630 a=floorctrl:c-only s-only 631 a=confid:4321 632 a=userid:1234 633 a=floorid:1 mstrm:10 634 a=floorid:2 mstrm:11 635 a=bfcpver:1 636 m=audio 50002 RTP/AVP 0 637 a=label:10 638 m=video 50004 RTP/AVP 31 639 a=label:11 641 Note that due to RFC formatting conventions, this document splits SDP 642 across lines whose content would exceed 72 characters. A backslash 643 character marks where this line folding has taken place. This 644 backslash and its trailing CRLF and whitespace would not appear in 645 actual SDP content. 647 The following is the answer returned by the client. 649 m=application 9 TCP/TLS/BFCP * 650 a=setup:active 651 a=connection:new 652 a=fingerprint:sha-256 \ 653 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 654 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 655 a=floorctrl:c-only 656 m=audio 55000 RTP/AVP 0 657 m=video 55002 RTP/AVP 31 659 A similar example using unreliable transport and DTLS is shown below, 660 where the offer is sent from a client. 662 m=application 50000 UDP/TLS/BFCP * 663 a=setup:actpass 664 a=dtls-id:abc3dl 665 a=fingerprint:sha-256 \ 666 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 667 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 668 a=floorctrl:c-only s-only 669 a=confid:4321 670 a=userid:1234 671 a=floorid:1 mstrm:10 672 a=floorid:2 mstrm:11 673 a=bfcpver:2 674 m=audio 50002 RTP/AVP 0 675 a=label:10 676 m=video 50004 RTP/AVP 31 677 a=label:11 679 The following is the answer returned by the server. 681 m=application 55000 UDP/TLS/BFCP * 682 a=setup:active 683 a=dtls-id:abc3dl 684 a=fingerprint:sha-256 \ 685 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 686 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 687 a=floorctrl:s-only 688 a=confid:4321 689 a=userid:1234 690 a=floorid:1 mstrm:10 691 a=floorid:2 mstrm:11 692 a=bfcpver:2 693 m=audio 55002 RTP/AVP 0 694 m=video 55004 RTP/AVP 31 696 15. Security Considerations 698 The BFCP [7], SDP [10], and offer/answer [4] specifications discuss 699 security issues related to BFCP, SDP, and offer/answer, respectively. 700 In addition, [6] and [9] discuss security issues related to the 701 establishment of TCP and TLS connections using an offer/answer model. 702 Furthermore, when using DTLS over UDP, considerations for its use 703 with RTP and RTCP are presented in [14]. The requirements for the 704 offer/answer exchange, as listed in Section 5 of [14], MUST be 705 followed. 707 An initial integrity-protected channel is REQUIRED for BFCP to 708 exchange self-signed certificates between a client and the floor 709 control server. For session descriptions carried in SIP [3], S/MIME 710 [5] is the natural choice to provide such a channel. 712 16. IANA Considerations 714 [Editorial note: The changes in Section 16.1 instruct the IANA to 715 register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/ 716 BFCP for the SDP 'proto' field. The new section Section 16.6 717 registers a new SDP "bfcpver" attribute. The rest is unchanged 718 from [15].] 720 16.1. Registration of SDP 'proto' Values 722 The IANA has registered the following values for the SDP 'proto' 723 field under the Session Description Protocol (SDP) Parameters 724 registry: 726 +---------------+------------+ 727 | Value | Reference | 728 +---------------+------------+ 729 | TCP/BFCP | [RFC XXXX] | 730 | TCP/DTLS/BFCP | [RFC XXXX] | 731 | TCP/TLS/BFCP | [RFC XXXX] | 732 | UDP/BFCP | [RFC XXXX] | 733 | UDP/TLS/BFCP | [RFC XXXX] | 734 +---------------+------------+ 736 Table 3: Values for the SDP 'proto' field 738 16.2. Registration of the SDP 'floorctrl' Attribute 740 The IANA has registered the following SDP att-field under the Session 741 Description Protocol (SDP) Parameters registry: 743 Contact name: iesg@ietf.org 745 Attribute name: floorctrl 747 Long-form attribute name: Floor Control 749 Type of attribute: Media level 751 Subject to charset: No 753 Purpose of attribute: The 'floorctrl' attribute is used to 754 perform floor control server determination. 756 Allowed attribute values: 1*("c-only" / "s-only" / "c-s") 758 16.3. Registration of the SDP 'confid' Attribute 760 The IANA has registered the following SDP att-field under the Session 761 Description Protocol (SDP) Parameters registry: 763 Contact name: iesg@ietf.org 765 Attribute name: confid 767 Long-form attribute name: Conference Identifier 769 Type of attribute: Media level 771 Subject to charset: No 773 Purpose of attribute: The 'confid' attribute carries the 774 integer representation of a Conference ID. 776 Allowed attribute values: A token 778 16.4. Registration of the SDP 'userid' Attribute 780 The IANA has registered the following SDP att-field under the Session 781 Description Protocol (SDP) Parameters registry: 783 Contact name: iesg@ietf.org 785 Attribute name: userid 787 Long-form attribute name: User Identifier 789 Type of attribute: Media level 791 Subject to charset: No 793 Purpose of attribute: The 'userid' attribute carries the 794 integer representation of a User ID. 796 Allowed attribute values: A token 798 16.5. Registration of the SDP 'floorid' Attribute 800 The IANA has registered the following SDP att-field under the Session 801 Description Protocol (SDP) Parameters registry: 803 Contact name: iesg@ietf.org 805 Attribute name: floorid 806 Long-form attribute name: Floor Identifier 808 Type of attribute: Media level 810 Subject to charset: No 812 Purpose of attribute: The 'floorid' attribute associates a 813 floor with one or more media streams. 815 Allowed attribute values: Tokens 817 16.6. Registration of the SDP 'bfcpver' Attribute 819 The IANA has registered the following SDP att-field under the Session 820 Description Protocol (SDP) Parameters registry: 822 Contact name: iesg@ietf.org 824 Attribute name: bfcpver 826 Long-form attribute name: BFCP Version 828 Type of attribute: Media level 830 Subject to charset: No 832 Purpose of attribute: The 'bfcpver' attribute lists supported 833 BFCP versions. 835 Allowed attribute values: Tokens 837 17. Changes from RFC 4583 839 Following is the list of technical changes and other fixes from [16]. 841 Main purpose of this work was to add signaling support necessary to 842 support BFCP over unreliable transport, as described in [7], 843 resulting in the following changes: 845 1. Fields in the 'm' line (Section 3): 846 The section is re-written to remove reference to the exclusivity 847 of TCP as a transport for BFCP streams. The proto field values 848 TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added. 850 2. Authentication (Section 11): 851 In last paragraph, made clear that a TCP connection was 852 described. 854 3. Security Considerations (Section 15): 855 For the DTLS over UDP case, mention existing considerations and 856 requirements for the offer/answer exchange in [14]. 858 4. Registration of SDP 'proto' Values (Section 16.1): 859 Register the three new values TCP/DTLS/BFCP, UDP/BFCP and 860 UDP/TLS/BFCP in the SDP parameters registry. 862 5. BFCP Version Negotiation (Section 8): 863 A new 'bfcpver' SDP media-level attribute is added in order to 864 signal supported version number. 866 Clarification and bug fixes: 868 1. Errata ID: 712 (Section 4 and Section 13): 869 Language clarification. Don't use terms like an SDP attribute is 870 "used in an 'm' line", instead make clear that the attribute is a 871 media-level attribute. 873 2. Fix typo in example (Section 14): 874 Do not use 'm-stream' in the SDP example, use the correct 'mstrm' 875 as specified in Section 14. Recommend interpreting 'm-stream' if 876 it is received, since it is present in some implementations. 878 3. Assorted clarifications (Across the document): 879 Language clarifications as a result of reviews. Also, the 880 normative language where tightened where appropriate, i.e. 881 changed from SHOULD strength to MUST in a number of places. 883 18. Acknowledgements 885 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 886 Oscar Novo provided useful ideas for the original [16]. The authors 887 also acknowledge contributions to the revision of BFCP for use over 888 an unreliable transport from Geir Arne Sandbakken, Charles Eckel, 889 Alan Ford, Eoin McLeod and Mark Thompson. Useful and important final 890 reviews were done by Ali C. Begen, Mary Barnes and Charles Eckel. 891 In the final stages, Roman Shpount made a considerable effort in 892 adding proper ICE support and considerations. 894 19. References 896 19.1. Normative References 898 [1] Bradner, S., "Key words for use in RFCs to Indicate 899 Requirement Levels", BCP 14, RFC 2119, 900 DOI 10.17487/RFC2119, March 1997, . 903 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 904 Specifications: ABNF", STD 68, RFC 5234, 905 DOI 10.17487/RFC5234, January 2008, . 908 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 909 A., Peterson, J., Sparks, R., Handley, M., and E. 910 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 911 DOI 10.17487/RFC3261, June 2002, . 914 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 915 with Session Description Protocol (SDP)", RFC 3264, 916 DOI 10.17487/RFC3264, June 2002, . 919 [5] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 920 Mail Extensions (S/MIME) Version 3.2 Certificate 921 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 922 . 924 [6] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 925 the Session Description Protocol (SDP)", RFC 4145, 926 DOI 10.17487/RFC4145, September 2005, . 929 [7] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 930 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 931 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 932 2015. 934 [8] Levin, O. and G. Camarillo, "The Session Description 935 Protocol (SDP) Label Attribute", RFC 4574, 936 DOI 10.17487/RFC4574, August 2006, . 939 [9] Lennox, J. and C. Holmberg, "Connection-Oriented Media 940 Transport over the Transport Layer Security (TLS) Protocol 941 in the Session Description Protocol (SDP)", RFC 8122, 942 DOI 10.17487/RFC8122, March 2017, . 945 [10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 946 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 947 July 2006, . 949 [11] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 950 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 951 January 2012, . 953 [12] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 954 and RTP Control Protocol (RTCP) Packets over Connection- 955 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 956 2006, . 958 [13] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 959 "TCP Candidates with Interactive Connectivity 960 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 961 March 2012, . 963 [14] Holmberg, C. and R. Shpount, "Session Description Protocol 964 (SDP) Offer/Answer Considerations for Datagram Transport 965 Layer Security (DTLS) and Transport Layer Security (TLS)", 966 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 967 2017. 969 [15] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 970 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 971 November 2006, . 973 [16] Camarillo, G., "Session Description Protocol (SDP) Format 974 for Binary Floor Control Protocol (BFCP) Streams", 975 RFC 4583, DOI 10.17487/RFC4583, November 2006, 976 . 978 [17] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 979 Connectivity Establishment (ICE): A Protocol for Network 980 Address Translator (NAT) Traversal", draft-ietf-ice- 981 rfc5245bis-20 (work in progress), March 2018. 983 [18] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 984 "Session Description Protocol (SDP) Offer/Answer 985 procedures for Interactive Connectivity Establishment 986 (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in 987 progress), April 2018. 989 19.2. Informational References 991 [19] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 992 Media Attributes in the Session Description Protocol 993 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 994 . 996 [20] Holmberg, C., Alvestrand, H., and C. Jennings, 997 "Negotiating Media Multiplexing Using the Session 998 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 999 negotiation-49 (work in progress), March 2018. 1001 [21] Nandakumar, S., "A Framework for SDP Attributes when 1002 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 1003 (work in progress), February 2018. 1005 Authors' Addresses 1007 Gonzalo Camarillo 1008 Ericsson 1009 Hirsalantie 11 1010 FI-02420 Jorvas 1011 Finland 1013 Email: Gonzalo.Camarillo@ericsson.com 1015 Tom Kristensen 1016 Cisco 1017 Philip Pedersens vei 1 1018 NO-1366 Lysaker 1019 Norway 1021 Email: tomkrist@cisco.com, tomkri@ifi.uio.no 1023 Christer Holmberg 1024 Ericsson 1025 Hirsalantie 11 1026 Jorvas 02420 1027 Finland 1029 Email: christer.holmberg@ericsson.com