idnits 2.17.1 draft-ietf-bfcpbis-rfc4583bis-17.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 (July 3, 2017) is 2490 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: 'RFC XXXX' on line 781 ** Obsolete normative reference: RFC 5750 (ref. '6') (Obsoleted by RFC 8550) ** Obsolete normative reference: RFC 4566 (ref. '11') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6347 (ref. '12') (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 5245 (ref. '14') (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-32) exists of draft-ietf-mmusic-dtls-sdp-26 ** Obsolete normative reference: RFC 4582 (ref. '17') (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (ref. '18') (Obsoleted by RFC 8856) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-38 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 P. Jones 6 Expires: January 4, 2018 Cisco 7 July 3, 2017 9 Session Description Protocol (SDP) Format for Binary Floor Control 10 Protocol (BFCP) Streams 11 draft-ietf-bfcpbis-rfc4583bis-17 13 Abstract 15 This document specifies how to describe Binary Floor Control Protocol 16 (BFCP) streams in Session Description Protocol (SDP) descriptions. 17 User agents using the offer/answer model to establish BFCP streams 18 use this format in their offers and answers. 20 This document obsoletes RFC 4583. Changes from RFC 4583 are 21 summarized in Section 14. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 4, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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 Server Determination . . . . . . . . . . . . . 4 61 4.1. SDP 'floorctrl' Attribute . . . . . . . . . . . . . . . . 5 62 5. SDP 'confid' and 'userid' Attributes . . . . . . . . . . . . 6 63 6. SDP 'floorid' Attribute . . . . . . . . . . . . . . . . . . . 7 64 7. SDP 'bfcpver' Attribute . . . . . . . . . . . . . . . . . . . 7 65 8. BFCP Connection Management . . . . . . . . . . . . . . . . . 8 66 8.1. TCP Connection Management . . . . . . . . . . . . . . . . 8 67 9. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8 68 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 11. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 11 70 11.1. Generating the Initial SDP Offer . . . . . . . . . . . . 12 71 11.2. Generating the SDP Answer . . . . . . . . . . . . . . . 13 72 11.3. Offerer Processing of the SDP Answer . . . . . . . . . . 14 73 11.4. Modifying the Session . . . . . . . . . . . . . . . . . 14 74 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 77 14.1. Registration of SDP 'proto' Values . . . . . . . . . . . 17 78 14.2. Registration of the SDP 'floorctrl' Attribute . . . . . 17 79 14.3. Registration of the SDP 'confid' Attribute . . . . . . . 18 80 14.4. Registration of the SDP 'userid' Attribute . . . . . . . 18 81 14.5. Registration of the SDP 'floorid' Attribute . . . . . . 18 82 14.6. Registration of the SDP 'bfcpver' Attribute . . . . . . 19 83 15. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 19 84 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 85 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 17.1. Normative References . . . . . . . . . . . . . . . . . . 20 87 17.2. Informational References . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Introduction 92 As discussed in the BFCP (Binary Floor Control Protocol) 93 specification [8], 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 [11], 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 [7]. Depending on the value of the 'setup' attribute 135 (discussed in Section 8.1), the port field contains the port to 136 which the remote endpoint will direct BFCP messages or is 137 irrelevant (i.e., the endpoint will initiate the connection 138 towards the remote endpoint) and should be set to a value of 9, 139 which is the discard port. 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 [12], as 151 described in this specification, which in turn runs on top of TCP 152 using the framing method defined in [13] 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 SHOULD 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 Server Determination 172 When two endpoints establish a BFCP stream, they need to determine 173 which of them acts as a floor control server. In the most common 174 scenario, a client establishes a BFCP stream with a conference server 175 that acts as the floor control server. Floor control server 176 determination is straight forward because one endpoint can only act 177 as a client and the other can only act as a floor control server. 179 However, there are scenarios where both endpoints could act as a 180 floor control server. For example, in a two-party session that 181 involves an audio stream and a shared whiteboard, the endpoints need 182 to decide which party will be acting as the floor control server. 184 Furthermore, there are situations where both the offerer and the 185 answerer act as both clients and floor control servers in the same 186 session. For example, in a two-party session that involves an audio 187 stream and a shared whiteboard, one party acts as the floor control 188 server for the audio stream and the other acts as the floor control 189 server for the shared whiteboard. 191 4.1. SDP 'floorctrl' Attribute 193 This document defines the 'floorctrl' SDP media-level attribute to 194 perform floor control server determination. Its Augmented BNF syntax 195 [2] is: 197 floor-control-attribute = "a=floorctrl:" role *(SP role) 198 role = "c-only" / "s-only" / "c-s" 200 The offerer includes this attribute to state all the roles it would 201 be willing to perform: 203 c-only: The offerer would be willing to act as a floor control 204 client only. 206 s-only: The offerer would be willing to act as a floor control 207 server only. 209 c-s: The offerer would be willing to act both as a floor control 210 client and as a floor control server. 212 If an SDP media description in an offer contains a 'floorctrl' 213 attribute, the answerer accepting that media MUST include a 214 'floorctrl' attribute in the corresponding media description of the 215 answer. The answerer includes this attribute to state which role the 216 answerer will perform. That is, the answerer chooses one of the 217 roles the offerer is willing to perform and generates an answer with 218 the corresponding role for the answerer. Table 1 shows the 219 corresponding roles for an answerer, depending on the offerer's role. 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 The following are the descriptions of the roles when they are chosen 232 by an answerer: 234 c-only: The answerer will act as a floor control client. 235 Consequently, the offerer will act as a floor control server. 237 s-only: The answerer will act as a floor control server. 238 Consequently, the offerer will act as a floor control client. 240 c-s: The answerer will act both as a floor control client and as a 241 floor control server. Consequently, the offerer will also act 242 both as a floor control client and as a floor control server. 244 Endpoints that use the offer/answer model to establish BFCP 245 connections MUST support the 'floorctrl' attribute. A floor control 246 server acting as an offerer or as an answerer SHOULD include this 247 attribute in its session descriptions. 249 If the 'floorctrl' attribute is not used in an offer/answer exchange, 250 by default the offerer and the answerer will act as a floor control 251 client and as a floor control server, respectively. 253 The following is an example of a 'floorctrl' attribute in an offer. 254 When this attribute appears in an answer, it only carries one role: 256 a=floorctrl:c-only s-only c-s 258 5. SDP 'confid' and 'userid' Attributes 260 This document defines the 'confid' and the 'userid' SDP media-level 261 attributes. These attributes are used by a floor control server to 262 provide a client with a conference ID and a user ID, respectively. 263 Their Augmented BNF syntax [2] is: 265 confid-attribute = "a=confid:" conference-id 266 conference-id = token 267 userid-attribute = "a=userid:" user-id 268 user-id = token 270 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 271 / %x41-5A / %x5E-7E 272 token = 1*(token-char) 274 The 'confid' and the 'userid' attributes carry the decimal integer 275 representation of a conference ID and a user ID, respectively. 277 The token-char and token elements are defined in [11] but included 278 here to provide support for the implementor of this SDP feature. 280 Endpoints that use the offer/answer model to establish BFCP 281 connections MUST support the 'confid' and the 'userid' attributes. A 282 floor control server acting as an offerer or as an answerer MUST 283 include these attributes in its session descriptions. 285 6. SDP 'floorid' Attribute 287 This document defines the 'floorid' SDP media-level attribute. This 288 attribute is used to provide an association between media streams and 289 floors. Its Augmented BNF syntax [2] is: 291 floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)] 293 The 'floorid' attribute is used in the SDP media description for BFCP 294 media. It defines a floor identifier and, possibly, associates it 295 with one or more media streams. The token representing the floor ID 296 is the integer representation of the Floor ID to be used in BFCP. 297 The token representing the media stream is a pointer to the media 298 stream, which is identified by an SDP label attribute [9]. 300 Endpoints that use the offer/answer model to establish BFCP 301 connections MUST support the 'floorid' and the 'label' attributes. A 302 floor control server acting as an offerer or as an answerer MUST 303 include these attributes in its session descriptions. 305 Note: In [18] 'm-stream' was erroneously used in Section 12. 306 Although the example was non-normative, it is implemented by some 307 vendors and occurs in cases where the endpoint is willing to act 308 as an server. Therefore, it is RECOMMENDED to support parsing and 309 interpreting 'm-stream' the same way as 'mstrm' when receiving. 311 7. SDP 'bfcpver' Attribute 313 This document defines the 'bfcpver' SDP media-level attribute. This 314 attribute is used for BFCP version negotiation. Its Augmented BNF 315 syntax [2] is: 317 bfcp-version-attribute = "a=bfcpver:" bfcp-version *(SP bfcp-version) 318 bfcp-version = token 320 The 'bfcpver' attribute defines the list of the versions of BFCP 321 supported by the endpoint. Tokens representing versions MUST be 322 integers matching the "Version" field that would be presented in the 323 BFCP COMMON-HEADER [8]. The version of BFCP to be used will then be 324 confirmed with a BFCP-level Hello/HelloAck. 326 Endpoints that use the offer/answer model to establish BFCP 327 connections SHOULD support the 'bfcpver' attribute. A floor control 328 server acting as an offerer or as an answerer SHOULD include this 329 attribute in its session descriptions. However, endpoints that 330 support RFC XXXX, and not only the [18] subset, are REQUIRED to 331 support and, when acting as a floor control server, to use the 332 'bfcpver' attribute. 334 If a 'bfcpver' attribute is not present, default values are inferred 335 from the transport specified in the 'm' line (Section 3). In 336 accordance with definition of the Version field in [8], when used 337 over a reliable transport the default value is "1", and when used 338 over an unreliable transport the default value is "2". 340 8. BFCP Connection Management 342 BFCP connections can use TCP or UDP as the underlying transport. 343 BFCP entities exchanging BFCP messages over UDP direct the BFCP 344 messages to the peer side connection address and port provided in the 345 SDP 'm' line. TCP connection management is more complicated and is 346 described below. 348 8.1. TCP Connection Management 350 The management of the TCP connection used to transport BFCP is 351 performed using the 'setup' and 'connection' attributes, as defined 352 in [7]. 354 The 'setup' attribute indicates which of the endpoints (client or 355 floor control server) initiates the TCP connection. The 'connection' 356 attribute handles TCP connection reestablishment. 358 The BFCP specification [8] describes a number of situations when the 359 TCP connection between a client and the floor control server needs to 360 be reestablished. However, that specification does not describe the 361 reestablishment process because this process depends on how the 362 connection was established in the first place. BFCP entities using 363 the offer/answer model follow the following rules. 365 When the existing TCP connection is closed and reestablished 366 following the rules in [8], the client MUST generate an offer towards 367 the floor control server in order to reestablish the connection. If 368 a TCP connection cannot deliver a BFCP message and times out, the 369 entity that attempted to send the message (i.e., the one that 370 detected the TCP timeout) MUST generate an offer in order to 371 reestablish the TCP connection. 373 Endpoints that use the offer/answer model to establish TCP 374 connections MUST support the 'setup' and 'connection' attributes. 376 9. Authentication 378 When a BFCP connection is established using the offer/answer model, 379 it is assumed that the offerer and the answerer authenticate each 380 other using some mechanism. TLS/DTLS is the preferred mechanism, but 381 other mechanisms are possible and outside the scope of this document. 383 Once this mutual authentication takes place, all the offerer and the 384 answerer need to ensure is that the entity they are receiving BFCP 385 messages from is the same as the one that generated the previous 386 offer or answer. 388 When SDP is used to perform an offer/answer exchange, the initial 389 mutual authentication takes place at the SIP level. Additionally, 390 SIP uses S/MIME [6] to provide an integrity-protected channel with 391 optional confidentiality for the offer/answer exchange. BFCP takes 392 advantage of this integrity-protected offer/answer exchange to 393 perform authentication. Within the offer/answer exchange, the 394 offerer and answerer exchange the fingerprints of their self-signed 395 certificates. These self-signed certificates are then used to 396 establish the TLS/DTLS connection that will carry BFCP traffic 397 between the offerer and the answerer. 399 BFCP clients and floor control servers follow the rules in [10] 400 regarding certificate choice and presentation. This implies that 401 unless a 'fingerprint' attribute is included in the session 402 description, the certificate provided at the TLS-/DTLS-level MUST 403 either be directly signed by one of the other party's trust anchors 404 or be validated using a certification path that terminates at one of 405 the other party's trust anchors [5]. Endpoints that use the offer/ 406 answer model to establish BFCP connections MUST support the 407 'fingerprint' attribute and MUST include it in their session 408 descriptions. 410 When TLS is used with TCP, once the underlying connection is 411 established, the answerer which may be the client or the floor 412 control server acts as the TLS server regardless of its role (passive 413 or active) in the TCP establishment procedure. If the TCP connection 414 is lost, the active endpoint is responsible for re-establishing the 415 TCP connection. Unless a new TLS session is negotiated, subsequent 416 SDP offers and answers will not impact the previously negotiated TLS 417 roles. 419 When DTLS is used with UDP, the requirements specified in Section 5 420 of [16] MUST be followed. 422 Informational note: How to determine which endpoint initiates the 423 TLS/DTLS association depends on the selected underlying transport. 424 It was decided to keep the original semantics in [18] for TCP to 425 retain backwards compatibility. When using UDP, the procedure 426 above was preferred since it adheres to [16] as used for DTLS- 427 SRTP, it does not overload offer/answer semantics, and it works 428 for offerless INVITE in scenarios with B2BUAs. 430 10. ICE Considerations 432 When BFCP is used with UDP based ICE candidates [14] then the 433 procedures for UDP/TLS/BFCP are used. 435 When BFCP is used with TCP based ICE candidates [15] then the 436 procedures for TCP/DTLS/BFCP are used. 438 In ICE environments, during the nomination process, endpoints go 439 through multiple ICE candidate pairs, until the most preferred 440 candidate pair is found. During the nomination process, data can be 441 sent as soon as the first working candidate pair is found, but the 442 nomination process still continues and selected candidate pairs can 443 still change while data is sent. 445 Furthermore, if endpoints roam between networks, for instance when 446 mobile endpoint switches from mobile connection to WiFi, endpoints 447 will initiate an ICE restart, which will trigger a new nomination 448 process between the new set of candidates and likely result in the 449 new nominated candidate pair. 451 Implementations MUST treat all ICE candidate pairs associated with an 452 BFCP session on top of a DTLS association as part of the same DTLS 453 association. Thus, there will only be one BFCP session setup and one 454 DTLS handshake even if there are multiple valid candidate pairs, and 455 shifting from one candidate pair to another, including switching 456 between UDP to TCP candidate pairs, will not impact the BFCP session 457 or DTLS associations. If new candidates are added, they will also be 458 part of the same BFCP session and DTLS associations. When 459 transitioning between candidate pairs, different candidate pairs can 460 be currently active in different directions and implementations MUST 461 be ready to receive data on any of the candidates, even if this means 462 sending and receiving data using UDP/TLS/BFCP and TCP/DTLS/BFCP at 463 the same time in different directions. 465 In order to maximize the likelihood of interoperability between the 466 endpoints, all ICE enabled BFCP endpoints SHOULD implement support 467 for UDP/TLS/BFCP. 469 When an SDP offer or answer is sent with multiple ICE candidates 470 during initial connection negotiation or after ICE restart, UDP based 471 candidates SHOULD be included and default candidate SHOULD be chosen 472 from one of those UDP candidates. The proto value MUST match the 473 transport protocol associated with the default candidate. If UDP 474 transport is used for the default candidate, then 'UDP/TLS/BFCP' 475 proto value MUST be used. If TCP transport is used for the default 476 candidate, then 'TCP/DTLS/BFCP' proto value MUST be used. Note that 477 under normal circumstances the proto value for offers and answers 478 sent during ICE nomination SHOULD be 'UDP/TLS/BFCP'. 480 When a subsequent SDP offer or answer is sent after ICE nomination is 481 complete and does not initiate ICE restart, it will contain only the 482 currently negotiated ICE candidate pair. In this case, the proto 483 value MUST match the transport protocol associated with the currently 484 negotiated ICE candidate pair. If UDP transport is used for the 485 currently negotiated pair, then 'UDP/TLS/BFCP' proto value MUST be 486 used. If TCP transport is used for the currently negotiated pair, 487 then 'TCP/DTLS/BFCP' proto value MUST be used. Please note that if 488 an endpoint switches between TCP-based and UDP-based candidates 489 during the nomination process the endpoint is not required to send an 490 SDP offer for the sole purpose of keeping the proto value of the 491 associated 'm' line in sync. 493 Note: The text in the paragraph above only applies when the usage 494 of ICE has been negotiated. If ICE is not used, the proto value 495 MUST always reflect the transport protocol used at any given time. 497 Note: Using ICE with protocols other then UDP/TLS/BFCP and 498 TCP/DTLS/BFCP is outside of scope for this specification. 500 11. SDP Offer/Answer Procedures 502 This section defines the SDP offer/answer [4] procedures for 503 negotiating and establishing a BFCP connection. The generic 504 procedures for DTLS are defined in [16], the specific BFCP parts are 505 specified here. 507 If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 508 'UDP/TLS/BFCP', each endpoint MUST provide a certificate fingerprint, 509 using the SDP 'fingerprint' attribute [7], if the endpoint supports, 510 and is willing to use, a cipher suite with an associated certificate. 512 The authentication certificates are interpreted and validated as 513 defined in [10]. Self-signed certificates can be used securely, 514 provided that the integrity of the SDP description is assured as 515 defined in [10]. 517 Note: The procedures apply to a specific 'm' line describing a 518 BFCP connection. If an offer or answer contains multiple 'm' 519 lines describing BFCP connections, the procedures are applied 520 separately to each 'm' line. 522 Informational note: The use of source-specific parameters in SDP, 523 as defined in [19], is not applicable to BFCP. 525 Multiplexing of BFCP 'm' lines, as defined in BUNDLE [20], is not 526 defined by this specification and MUST NOT be included in a BUNDLE 527 group. An analysis of the SDP attributes defined in [18], with 528 regards to multiplexing of 'm' lines, is presented in Section 5.27 of 529 [21]. The analysis for the 'bfcpver' SDP attribute, defined in this 530 document is provided in Table 2. 532 +---------+------------------------+-------+--------------+ 533 | Name | Notes | Level | Mux Category | 534 +---------+------------------------+-------+--------------+ 535 | bfcpver | Needs further analysis | M | TBD | 536 +---------+------------------------+-------+--------------+ 538 Table 2: Multiplexing Attribute Analysis 540 11.1. Generating the Initial SDP Offer 542 When the offerer creates an initial offer, the offerer: 544 o MUST, if the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 545 'TCP/DTLS/TCP' or 'UDP/TLS/BFCP', associate an SDP setup 546 attribute, with an 'actpass' value, with the 'm' line; 548 o MUST, if the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 549 'TCP/DTLS/BFCP', associate an SDP 'connection' attribute, with a 550 'new' value, with the 'm' line; and 552 In addition, if the offerer acts as the floor control server, the 553 offerer: 555 o SHOULD associate an SDP 'floorctrl' attribute defined in 556 Section 4.1, with the 'm' line; 558 o MUST associate an SDP 'confid' attribute defined in Section 5, 559 with the 'm' line; 561 o MUST associate an SDP 'userid' attribute defined in Section 5, 562 with the 'm' line; 564 o MUST associate an SDP 'floorid' attribute defined in Section 6, 565 with the 'm' line; 567 o MUST associate an SDP 'label' attribute as described in Section 6, 568 with the 'm' line; and 570 o SHOULD, if it supports only the RFC 4583 subset and MUST, if it 571 supports RFC XXXX associate an SDP 'bfcpver' attribute defined in 572 Section 7, with the 'm' line. 574 11.2. Generating the SDP Answer 576 When the answerer receives an offer, which contains an 'm' line 577 describing a BFCP connection, if the answerer accepts the 'm' line 578 it: 580 o MUST insert a corresponding 'm' line in the answer, with an 581 identical 'm' line proto value [4]; and 583 o MUST, if the 'm' line proto value is 'TCP/BFCP', 'TCP/DTLS/BFCP', 584 'TCP/TLS/BFCP' or 'UDP/TLS/BFCP', associate an SDP setup 585 attribute, with an 'active' or 'passive' value, with the 'm' line; 587 In addition, if the answerer acts as the floor control server, the 588 answerer: 590 o MUST, if the offer contains a 'floorctrl' attribute or else it 591 SHOULD associate an SDP 'floorctrl' attribute defined in 592 Section 4.1, with the 'm' line; 594 o MUST associate an SDP 'confid' attribute defined in Section 5, 595 with the 'm' line; 597 o MUST associate an SDP 'userid' attribute defined in Section 5, 598 with the 'm' line; 600 o MUST associate an SDP 'floorid' attribute defined in Section 6, 601 with the 'm' line; and 603 o MUST associate an SDP 'label' attribute as described in Section 6, 604 with the 'm' line. 606 o SHOULD, if it supports only the RFC 4583 subset and MUST, if it 607 supports RFC XXXX associate an SDP 'bfcpver' attribute defined in 608 Section 7, with the 'm' line. 610 Once the answerer has sent the answer, the answerer: 612 o MUST, if the answerer is the 'active' endpoint, and if a TCP 613 connection associated with the 'm' line is to be established (or 614 re-established), initiate the establishing of the TCP connection; 615 and 617 o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS 618 connection associated with the 'm' line is to be established (or 619 re-established), initiate the establishing of the TLS/DTLS 620 connection (by sending a ClientHello message). 622 If the answerer does not accept the 'm' line in the offer, it MUST 623 assign a zero port value to the corresponding 'm' line in the answer. 624 In addition, the answerer MUST NOT establish a TCP connection or a 625 TLS/DTLS connection associated with the 'm' line. 627 11.3. Offerer Processing of the SDP Answer 629 When the offerer receives an answer, which contains an 'm' line with 630 a non-zero port value, describing a BFCP connection, the offerer: 632 o MUST, if the offer is the 'active' endpoint, and if a TCP 633 connection associated with the 'm' line is to be established (or 634 re-established), initiate the establishing of the TCP connection; 635 and 637 o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS 638 connection associated with the 'm' line is to be established (or 639 re-established), initiate the establishing of the TLS/DTLS 640 connection (by sending a ClientHello message). 642 If the 'm' line in the answer contains a zero port value, the offerer 643 MUST NOT establish a TCP connection or a TLS/DTLS connection 644 associated with the 'm' line. 646 11.4. Modifying the Session 648 When an offerer sends an updated offer, in order to modify a 649 previously established BFCP connection, it follows the procedures in 650 Section 11.1, with the following exceptions: 652 o If the BFCP connection is carried on top of TCP, and unless the 653 offerer wants to re-establish an existing TCP connection, the 654 offerer MUST associate an SDP connection attribute, with an 655 'existing' value, with the 'm' line; and 657 o If the offerer wants to disable a previously established BFCP 658 connection, it MUST assign a zero port value to the 'm' line 659 associated with the BFCP connection, following the procedures in 660 [4]. 662 12. Examples 664 For the purpose of brevity, the main portion of the session 665 description is omitted in the examples, which only show 'm' lines and 666 their attributes. 668 The following is an example of an offer sent by a conference server 669 to a client. 671 m=application 50000 TCP/TLS/BFCP * 672 a=setup:passive 673 a=connection:new 674 a=fingerprint:sha-256 \ 675 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 676 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 677 a=floorctrl:s-only 678 a=confid:4321 679 a=userid:1234 680 a=floorid:1 mstrm:10 681 a=floorid:2 mstrm:11 682 a=bfcpver:1 683 m=audio 50002 RTP/AVP 0 684 a=label:10 685 m=video 50004 RTP/AVP 31 686 a=label:11 688 Note that due to RFC formatting conventions, this document splits SDP 689 across lines whose content would exceed 72 characters. A backslash 690 character marks where this line folding has taken place. This 691 backslash and its trailing CRLF and whitespace would not appear in 692 actual SDP content. 694 The following is the answer returned by the client. 696 m=application 9 TCP/TLS/BFCP * 697 a=setup:active 698 a=connection:new 699 a=fingerprint:sha-256 \ 700 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 701 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 702 a=floorctrl:c-only 703 a=bfcpver:1 704 m=audio 55000 RTP/AVP 0 705 m=video 55002 RTP/AVP 31 707 A similar example using unreliable transport and DTLS is shown below, 708 where the offer is sent from a client. 710 m=application 50000 UDP/TLS/BFCP * 711 a=setup:actpass 712 a=dtls-id:abc3dl 713 a=fingerprint:sha-256 \ 714 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 715 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 716 a=floorctrl:c-only s-only 717 a=confid:4321 718 a=userid:1234 719 a=floorid:1 mstrm:10 720 a=floorid:2 mstrm:11 721 a=bfcpver:2 722 m=audio 50002 RTP/AVP 0 723 a=label:10 724 m=video 50004 RTP/AVP 31 725 a=label:11 727 The following is the answer returned by the server. 729 m=application 55000 UDP/TLS/BFCP * 730 a=setup:active 731 a=dtls-id:abc3dl 732 a=fingerprint:sha-256 \ 733 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ 734 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 735 a=floorctrl:s-only 736 a=confid:4321 737 a=userid:1234 738 a=floorid:1 mstrm:10 739 a=floorid:2 mstrm:11 740 a=bfcpver:2 741 m=audio 55002 RTP/AVP 0 742 m=video 55004 RTP/AVP 31 744 13. Security Considerations 746 The BFCP [8], SDP [11], and offer/answer [4] specifications discuss 747 security issues related to BFCP, SDP, and offer/answer, respectively. 748 In addition, [7] and [10] discuss security issues related to the 749 establishment of TCP and TLS connections using an offer/answer model. 750 Furthermore, when using DTLS over UDP, considerations for its use 751 with RTP and RTCP are presented in [16]. The requirements for the 752 offer/answer exchange, as listed in Section 5 of [16], MUST be 753 followed. 755 An initial integrity-protected channel is REQUIRED for BFCP to 756 exchange self-signed certificates between a client and the floor 757 control server. For session descriptions carried in SIP [3], S/MIME 758 [6] is the natural choice to provide such a channel. 760 14. IANA Considerations 762 [Editorial note: The changes in Section 14.1 instruct the IANA to 763 register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/ 764 BFCP for the SDP 'proto' field. The new section Section 14.6 765 registers a new SDP "bfcpver" attribute. The rest is unchanged 766 from [17].] 768 14.1. Registration of SDP 'proto' Values 770 The IANA has registered the following values for the SDP 'proto' 771 field under the Session Description Protocol (SDP) Parameters 772 registry: 774 +---------------+------------+ 775 | Value | Reference | 776 +---------------+------------+ 777 | TCP/BFCP | [RFC XXXX] | 778 | TCP/DTLS/BFCP | [RFC XXXX] | 779 | TCP/TLS/BFCP | [RFC XXXX] | 780 | UDP/BFCP | [RFC XXXX] | 781 | UDP/TLS/BFCP | [RFC XXXX] | 782 +---------------+------------+ 784 Table 3: Values for the SDP 'proto' field 786 14.2. Registration of the SDP 'floorctrl' Attribute 788 The IANA has registered the following SDP att-field under the Session 789 Description Protocol (SDP) Parameters registry: 791 Contact name: Gonzalo.Camarillo@ericsson.com 793 Attribute name: floorctrl 795 Long-form attribute name: Floor Control 797 Type of attribute: Media level 799 Subject to charset: No 801 Purpose of attribute: The 'floorctrl' attribute is used to 802 perform floor control server determination. 804 Allowed attribute values: 1*("c-only" / "s-only" / "c-s") 806 14.3. Registration of the SDP 'confid' Attribute 808 The IANA has registered the following SDP att-field under the Session 809 Description Protocol (SDP) Parameters registry: 811 Contact name: Gonzalo.Camarillo@ericsson.com 813 Attribute name: confid 815 Long-form attribute name: Conference Identifier 817 Type of attribute: Media level 819 Subject to charset: No 821 Purpose of attribute: The 'confid' attribute carries the 822 integer representation of a Conference ID. 824 Allowed attribute values: A token 826 14.4. Registration of the SDP 'userid' Attribute 828 The IANA has registered the following SDP att-field under the Session 829 Description Protocol (SDP) Parameters registry: 831 Contact name: Gonzalo.Camarillo@ericsson.com 833 Attribute name: userid 835 Long-form attribute name: User Identifier 837 Type of attribute: Media level 839 Subject to charset: No 841 Purpose of attribute: The 'userid' attribute carries the 842 integer representation of a User ID. 844 Allowed attribute values: A token 846 14.5. Registration of the SDP 'floorid' Attribute 848 The IANA has registered the following SDP att-field under the Session 849 Description Protocol (SDP) Parameters registry: 851 Contact name: Gonzalo.Camarillo@ericsson.com 853 Attribute name: floorid 854 Long-form attribute name: Floor Identifier 856 Type of attribute: Media level 858 Subject to charset: No 860 Purpose of attribute: The 'floorid' attribute associates a 861 floor with one or more media streams. 863 Allowed attribute values: Tokens 865 14.6. Registration of the SDP 'bfcpver' Attribute 867 The IANA has registered the following SDP att-field under the Session 868 Description Protocol (SDP) Parameters registry: 870 Contact name: Gonzalo.Camarillo@ericsson.com 872 Attribute name: bfcpver 874 Long-form attribute name: BFCP Version 876 Type of attribute: Media level 878 Subject to charset: No 880 Purpose of attribute: The 'bfcpver' attribute lists supported 881 BFCP versions. 883 Allowed attribute values: Tokens 885 15. Changes from RFC 4583 887 Following is the list of technical changes and other fixes from [18]. 889 Main purpose of this work was to add signaling support necessary to 890 support BFCP over unreliable transport, as described in [8], 891 resulting in the following changes: 893 1. Fields in the 'm' line (Section 3): 894 The section is re-written to remove reference to the exclusivity 895 of TCP as a transport for BFCP streams. The proto field values 896 TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added. 898 2. Authentication (Section 9): 899 In last paragraph, made clear that a TCP connection was 900 described. 902 3. Security Considerations (Section 13): 903 For the DTLS over UDP case, mention existing considerations and 904 requirements for the offer/answer exchange in [16]. 906 4. Registration of SDP 'proto' Values (Section 14.1): 907 Register the three new values TCP/DTLS/BFCP, UDP/BFCP and 908 UDP/TLS/BFCP in the SDP parameters registry. 910 5. BFCP Version Negotiation (Section 7): 911 A new 'bfcpver' SDP media-level attribute is added in order to 912 signal supported version number. 914 Clarification and bug fixes: 916 1. Errata ID: 712 (Section 4 and Section 6): 917 Language clarification. Don't use terms like an SDP attribute is 918 "used in an 'm' line", instead make clear that the attribute is a 919 media-level attribute. 921 2. Fix typo in example (Section 12): 922 Do not use 'm-stream' in the SDP example, use the correct 'mstrm' 923 as specified in Section 12. Recommend interpreting 'm-stream' if 924 it is received, since it is present in some implementations. 926 3. Assorted clarifications (Across the document): 927 Language clarifications as a result of reviews. Also, the 928 normative language where tightened where appropriate, i.e. 929 changed from SHOULD strength to MUST in a number of places. 931 16. Acknowledgements 933 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 934 Oscar Novo provided useful ideas for the original [18]. The authors 935 also acknowledge contributions to the revision of BFCP for use over 936 an unreliable transport from Geir Arne Sandbakken, Charles Eckel, 937 Alan Ford, Eoin McLeod and Mark Thompson. Useful and important final 938 reviews were done by Ali C. Begen, Mary Barnes and Charles Eckel. 939 In the final stages, Roman Shpount made a considerable effort in 940 adding proper ICE support and considerations. 942 17. References 944 17.1. Normative References 946 [1] Bradner, S., "Key words for use in RFCs to Indicate 947 Requirement Levels", BCP 14, RFC 2119, 948 DOI 10.17487/RFC2119, March 1997, 949 . 951 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 952 Specifications: ABNF", STD 68, RFC 5234, 953 DOI 10.17487/RFC5234, January 2008, 954 . 956 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 957 A., Peterson, J., Sparks, R., Handley, M., and E. 958 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 959 DOI 10.17487/RFC3261, June 2002, 960 . 962 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 963 with Session Description Protocol (SDP)", RFC 3264, 964 DOI 10.17487/RFC3264, June 2002, 965 . 967 [5] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 968 Housley, R., and W. Polk, "Internet X.509 Public Key 969 Infrastructure Certificate and Certificate Revocation List 970 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 971 . 973 [6] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 974 Mail Extensions (S/MIME) Version 3.2 Certificate 975 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 976 . 978 [7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 979 the Session Description Protocol (SDP)", RFC 4145, 980 DOI 10.17487/RFC4145, September 2005, 981 . 983 [8] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 984 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 985 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 986 2015. 988 [9] Levin, O. and G. Camarillo, "The Session Description 989 Protocol (SDP) Label Attribute", RFC 4574, 990 DOI 10.17487/RFC4574, August 2006, 991 . 993 [10] Lennox, J. and C. Holmberg, "Connection-Oriented Media 994 Transport over the Transport Layer Security (TLS) Protocol 995 in the Session Description Protocol (SDP)", RFC 8122, 996 DOI 10.17487/RFC8122, March 2017, 997 . 999 [11] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1000 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1001 July 2006, . 1003 [12] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1004 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1005 January 2012, . 1007 [13] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1008 and RTP Control Protocol (RTCP) Packets over Connection- 1009 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 1010 2006, . 1012 [14] Rosenberg, J., "Interactive Connectivity Establishment 1013 (ICE): A Protocol for Network Address Translator (NAT) 1014 Traversal for Offer/Answer Protocols", RFC 5245, 1015 DOI 10.17487/RFC5245, April 2010, 1016 . 1018 [15] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 1019 "TCP Candidates with Interactive Connectivity 1020 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 1021 March 2012, . 1023 [16] Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer 1024 Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-26 (work 1025 in progress), June 2017. 1027 [17] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 1028 Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, 1029 November 2006, . 1031 [18] Camarillo, G., "Session Description Protocol (SDP) Format 1032 for Binary Floor Control Protocol (BFCP) Streams", 1033 RFC 4583, DOI 10.17487/RFC4583, November 2006, 1034 . 1036 17.2. Informational References 1038 [19] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1039 Media Attributes in the Session Description Protocol 1040 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1041 . 1043 [20] Holmberg, C., Alvestrand, H., and C. Jennings, 1044 "Negotiating Media Multiplexing Using the Session 1045 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1046 negotiation-38 (work in progress), April 2017. 1048 [21] Nandakumar, S., "A Framework for SDP Attributes when 1049 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1050 (work in progress), December 2016. 1052 Authors' Addresses 1054 Gonzalo Camarillo 1055 Ericsson 1056 Hirsalantie 11 1057 FI-02420 Jorvas 1058 Finland 1060 Email: Gonzalo.Camarillo@ericsson.com 1062 Tom Kristensen 1063 Cisco 1064 Philip Pedersens vei 1 1065 NO-1366 Lysaker 1066 Norway 1068 Email: tomkrist@cisco.com, tomkri@ifi.uio.no 1070 Paul E. Jones 1071 Cisco 1072 7025 Kit Creek Rd. 1073 Research Triangle Park, NC 27709 1074 USA 1076 Email: paulej@packetizer.com