idnits 2.17.1 draft-ietf-bfcpbis-rfc4583bis-11.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 (February 20, 2015) is 3353 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 699 ** Obsolete normative reference: RFC 5750 (ref. '6') (Obsoleted by RFC 8550) == Outdated reference: A later version (-16) exists of draft-ietf-bfcpbis-rfc4582bis-13 ** Obsolete normative reference: RFC 4572 (ref. '10') (Obsoleted by RFC 8122) ** 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 4582 (ref. '14') (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (ref. '15') (Obsoleted by RFC 8856) Summary: 6 errors (**), 0 flaws (~~), 2 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 Cisco 6 Expires: August 24, 2015 February 20, 2015 8 Session Description Protocol (SDP) Format for Binary Floor Control 9 Protocol (BFCP) Streams 10 draft-ietf-bfcpbis-rfc4583bis-11 12 Abstract 14 This document specifies how to describe Binary Floor Control Protocol 15 (BFCP) streams in Session Description Protocol (SDP) descriptions. 16 User agents using the offer/answer model to establish BFCP streams 17 use this format in their offers and answers. 19 This document obsoletes RFC 4583. Changes from RFC 4583 are 20 summarized in Section 14. 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 http://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 August 24, 2015. 39 Copyright Notice 41 Copyright (c) 2015 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . . 3 59 4. Floor Control Server Determination . . . . . . . . . . . . . . 4 60 4.1. SDP 'floorctrl' Attribute . . . . . . . . . . . . . . . . 5 61 5. SDP 'confid' and 'userid' Attributes . . . . . . . . . . . . . 6 62 6. SDP 'floorid' Attribute . . . . . . . . . . . . . . . . . . . 7 63 7. SDP 'bfcpver' Attribute . . . . . . . . . . . . . . . . . . . 7 64 8. BFCP Connection Management . . . . . . . . . . . . . . . . . . 8 65 8.1. TCP Connection Management . . . . . . . . . . . . . . . . 8 66 9. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 9 67 10. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 68 10.1. Generating the Initial SDP Offer . . . . . . . . . . . . . 10 69 10.2. Generating the SDP Answer . . . . . . . . . . . . . . . . 11 70 10.3. Offerer Processing of the SDP Answer . . . . . . . . . . . 12 71 10.4. Modifying the Session . . . . . . . . . . . . . . . . . . 12 72 10.5. DTLS Role Determination . . . . . . . . . . . . . . . . . 13 73 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 13.1. Registration of SDP 'proto' Values . . . . . . . . . . . . 16 77 13.2. Registration of the SDP 'floorctrl' Attribute . . . . . . 16 78 13.3. Registration of the SDP 'confid' Attribute . . . . . . . . 17 79 13.4. Registration of the SDP 'userid' Attribute . . . . . . . . 17 80 13.5. Registration of the SDP 'floorid' Attribute . . . . . . . 17 81 13.6. Registration of the SDP 'bfcpver' Attribute . . . . . . . 18 82 14. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 18 83 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 84 16. Normative References . . . . . . . . . . . . . . . . . . . . . 19 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 As discussed in the BFCP (Binary Floor Control Protocol) 90 specification [8], a given BFCP client needs a set of data in order 91 to establish a BFCP connection to a floor control server. This data 92 includes the transport address of the server, the conference 93 identifier, and the user identifier. 95 One way for clients to obtain this information is to use an SDP 96 offer/answer [4] exchange. This document specifies how to encode 97 this information in the SDP session descriptions that are part of 98 such an offer/answer exchange. 100 User agents typically use the offer/answer model to establish a 101 number of media streams of different types. Following this model, a 102 BFCP connection is described as any other media stream by using an 103 SDP 'm' line, possibly followed by a number of attributes encoded in 104 'a' lines. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14, RFC 2119 [1] and indicate requirement levels for compliant 112 implementations. 114 3. Fields in the 'm' Line 116 This section describes how to generate an 'm' line for a BFCP stream. 118 According to the SDP specification [11], the 'm' line format is the 119 following: 121 m= ... 123 The media field MUST have a value of "application". 125 The port field is set depending on the value of the proto field, as 126 explained below. A port field value of zero has the standard SDP 127 meaning (i.e., rejection of the media stream) regardless of the proto 128 field. 130 When TCP is used as the transport, the port field is set following 131 the rules in [7]. Depending on the value of the 'setup' attribute 132 (discussed in Section 8.1), the port field contains the port to 133 which the remote endpoint will direct BFCP messages or is 134 irrelevant (i.e., the endpoint will initiate the connection 135 towards the remote endpoint) and should be set to a value of 9, 136 which is the discard port. 138 When UDP is used as the transport, the port field contains the 139 port to which the remote endpoint will direct BFCP messages 140 regardless of the value of the 'setup' attribute. 142 This document defines four values for the proto field: TCP/BFCP, TCP/ 143 TLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP. TCP/BFCP is used when BFCP 144 runs directly on top of TCP, TCP/TLS/BFCP is used when BFCP runs on 145 top of TLS, which in turn runs on top of TCP. Similarly, UDP/BFCP is 146 used when BFCP runs directly on top of UDP, and UDP/TLS/BFCP is used 147 when BFCP runs on top of DTLS [12], which in turn runs on top of UDP. 149 The fmt (format) list is not applicable to BFCP. The fmt list of 'm' 150 lines in the case of any proto field value related to BFCP SHOULD 151 contain a single "*" character. If the the fmt list contains any 152 other value it is ignored. 154 The following is an example of an 'm' line for a BFCP connection: 156 m=application 50000 TCP/TLS/BFCP * 158 4. Floor Control Server Determination 160 When two endpoints establish a BFCP stream, they need to determine 161 which of them acts as a floor control server. In the most common 162 scenario, a client establishes a BFCP stream with a conference server 163 that acts as the floor control server. Floor control server 164 determination is straight forward because one endpoint can only act 165 as a client and the other can only act as a floor control server. 167 However, there are scenarios where both endpoints could act as a 168 floor control server. For example, in a two-party session that 169 involves an audio stream and a shared whiteboard, the endpoints need 170 to decide which party will be acting as the floor control server. 172 Furthermore, there are situations where both the offerer and the 173 answerer act as both clients and floor control servers in the same 174 session. For example, in a two-party session that involves an audio 175 stream and a shared whiteboard, one party acts as the floor control 176 server for the audio stream and the other acts as the floor control 177 server for the shared whiteboard. 179 4.1. SDP 'floorctrl' Attribute 181 This document defines the 'floorctrl' SDP media-level attribute to 182 perform floor control server determination. Its Augmented BNF syntax 183 [2] is: 185 floor-control-attribute = "a=floorctrl:" role *(SP role) 186 role = "c-only" / "s-only" / "c-s" 188 The offerer includes this attribute to state all the roles it would 189 be willing to perform: 191 c-only: The offerer would be willing to act as a floor control 192 client only. 194 s-only: The offerer would be willing to act as a floor control 195 server only. 197 c-s: The offerer would be willing to act both as a floor control 198 client and as a floor control server. 200 If an SDP media description in an offer contains a 'floorctrl' 201 attribute, the answerer accepting that media MUST include a 202 'floorctrl' attribute in the corresponding media description of the 203 answer. The answerer includes this attribute to state which role the 204 answerer will perform. That is, the answerer chooses one of the 205 roles the offerer is willing to perform and generates an answer with 206 the corresponding role for the answerer. Table 1 shows the 207 corresponding roles for an answerer, depending on the offerer's role. 209 +---------+----------+ 210 | Offerer | Answerer | 211 +---------+----------+ 212 | c-only | s-only | 213 | s-only | c-only | 214 | c-s | c-s | 215 +---------+----------+ 217 Table 1: Roles 219 The following are the descriptions of the roles when they are chosen 220 by an answerer: 222 c-only: The answerer will act as a floor control client. 223 Consequently, the offerer will act as a floor control server. 225 s-only: The answerer will act as a floor control server. 226 Consequently, the offerer will act as a floor control client. 228 c-s: The answerer will act both as a floor control client and as a 229 floor control server. Consequently, the offerer will also act 230 both as a floor control client and as a floor control server. 232 Endpoints that use the offer/answer model to establish BFCP 233 connections MUST support the 'floorctrl' attribute. A floor control 234 server acting as an offerer or as an answerer SHOULD include this 235 attribute in its session descriptions. 237 If the 'floorctrl' attribute is not used in an offer/answer exchange, 238 by default the offerer and the answerer will act as a floor control 239 client and as a floor control server, respectively. 241 The following is an example of a 'floorctrl' attribute in an offer. 242 When this attribute appears in an answer, it only carries one role: 244 a=floorctrl:c-only s-only c-s 246 5. SDP 'confid' and 'userid' Attributes 248 This document defines the 'confid' and the 'userid' SDP media-level 249 attributes. These attributes are used by a floor control server to 250 provide a client with a conference ID and a user ID, respectively. 251 Their Augmented BNF syntax [2] is: 253 confid-attribute = "a=confid:" conference-id 254 conference-id = token 255 userid-attribute = "a=userid:" user-id 256 user-id = token 258 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 259 / %x41-5A / %x5E-7E 260 token = 1*(token-char) 262 The 'confid' and the 'userid' attributes carry the decimal integer 263 representation of a conference ID and a user ID, respectively. 265 The token-char and token elements are defined in [11] but included 266 here to provide support for the implementor of this SDP feature. 268 Endpoints that use the offer/answer model to establish BFCP 269 connections MUST support the 'confid' and the 'userid' attributes. A 270 floor control server acting as an offerer or as an answerer MUST 271 include these attributes in its session descriptions. 273 6. SDP 'floorid' Attribute 275 This document defines the 'floorid' SDP media-level attribute. This 276 attribute is used to provide an association between media streams and 277 floors. Its Augmented BNF syntax [2] is: 279 floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)] 281 The 'floorid' attribute is used in the SDP media description for BFCP 282 media. It defines a floor identifier and, possibly, associates it 283 with one or more media streams. The token representing the floor ID 284 is the integer representation of the Floor ID to be used in BFCP. 285 The token representing the media stream is a pointer to the media 286 stream, which is identified by an SDP label attribute [9]. 288 Endpoints that use the offer/answer model to establish BFCP 289 connections MUST support the 'floorid' and the 'label' attributes. A 290 floor control server acting as an offerer or as an answerer MUST 291 include these attributes in its session descriptions. 293 Note: In [15] 'm-stream' was erroneously used in Section 11. 294 Although the example was non-normative, it is implemented by some 295 vendors and occurs in cases where the endpoint is willing to act 296 as an server. Therefore, it is RECOMMENDED to support parsing and 297 interpreting 'm-stream' the same way as 'mstrm' when receiving. 299 7. SDP 'bfcpver' Attribute 301 This document defines the 'bfcpver' SDP media-level attribute. This 302 attribute is used for BFCP version negotiation. Its Augmented BNF 303 syntax [2] is: 305 bfcp-version-attribute = "a=bfcpver:" bfcp-version *(SP bfcp-version) 306 bfcp-version = token 308 The 'bfcpver' attribute defines the list of the versions of BFCP 309 supported by the endpoint. Tokens representing versions MUST be 310 integers matching the "Version" field that would be presented in the 311 BFCP COMMON-HEADER [8]. The version of BFCP to be used will then be 312 confirmed with a BFCP-level Hello/HelloAck. 314 Endpoints that use the offer/answer model to establish BFCP 315 connections SHOULD support the 'bfcpver' attribute. A floor control 316 server acting as an offerer or as an answerer SHOULD include this 317 attribute in its session descriptions. However, endpoints that 318 support RFC XXXX, and not only the [15] subset, are REQUIRED to 319 support and, when acting as a floor control server, to use the 320 'bfcpver' attribute. 322 If a 'bfcpver' attribute is not present, default values are inferred 323 from the transport specified in the 'm' line (Section 3). In 324 accordance with definition of the Version field in [8], when used 325 over a reliable transport the default value is "1", and when used 326 over an unreliable transport the default value is "2". 328 8. BFCP Connection Management 330 BFCP connections can use TCP or UDP as the underlying transport. 331 BFCP entities exchanging BFCP messages over UDP direct the BFCP 332 messages to the peer side connection address and port provided in the 333 SDP 'm' line. TCP connection management is more complicated and is 334 described below. 336 8.1. TCP Connection Management 338 The management of the TCP connection used to transport BFCP is 339 performed using the 'setup' and 'connection' attributes, as defined 340 in [7]. 342 The 'setup' attribute indicates which of the endpoints (client or 343 floor control server) initiates the TCP connection. The 'connection' 344 attribute handles TCP connection reestablishment. 346 The BFCP specification [8] describes a number of situations when the 347 TCP connection between a client and the floor control server needs to 348 be reestablished. However, that specification does not describe the 349 reestablishment process because this process depends on how the 350 connection was established in the first place. BFCP entities using 351 the offer/answer model follow the following rules. 353 When the existing TCP connection is closed and reestablished 354 following the rules in [8], the client MUST generate an offer towards 355 the floor control server in order to reestablish the connection. If 356 a TCP connection cannot deliver a BFCP message and times out, the 357 entity that attempted to send the message (i.e., the one that 358 detected the TCP timeout) MUST generate an offer in order to 359 reestablish the TCP connection. 361 Endpoints that use the offer/answer model to establish TCP 362 connections MUST support the 'setup' and 'connection' attributes. 364 9. Authentication 366 When a BFCP connection is established using the offer/answer model, 367 it is assumed that the offerer and the answerer authenticate each 368 other using some mechanism. TLS/DTLS is the preferred mechanism, but 369 other mechanisms are possible and outside the scope of this document. 370 Once this mutual authentication takes place, all the offerer and the 371 answerer need to ensure is that the entity they are receiving BFCP 372 messages from is the same as the one that generated the previous 373 offer or answer. 375 When SIP is used to perform an offer/answer exchange, the initial 376 mutual authentication takes place at the SIP level. Additionally, 377 SIP uses S/MIME [6] to provide an integrity-protected channel with 378 optional confidentiality for the offer/answer exchange. BFCP takes 379 advantage of this integrity-protected offer/answer exchange to 380 perform authentication. Within the offer/answer exchange, the 381 offerer and answerer exchange the fingerprints of their self-signed 382 certificates. These self-signed certificates are then used to 383 establish the TLS/DTLS connection that will carry BFCP traffic 384 between the offerer and the answerer. 386 BFCP clients and floor control servers follow the rules in [10] 387 regarding certificate choice and presentation. This implies that 388 unless a 'fingerprint' attribute is included in the session 389 description, the certificate provided at the TLS-/DTLS-level MUST 390 either be directly signed by one of the other party's trust anchors 391 or be validated using a certification path that terminates at one of 392 the other party's trust anchors [5]. Endpoints that use the offer/ 393 answer model to establish BFCP connections MUST support the 394 'fingerprint' attribute and MUST include it in their session 395 descriptions. 397 When TLS is used with TCP, once the underlying connection is 398 established, the answerer which may be the client or the floor 399 control server acts as the TLS server regardless of its role (passive 400 or active) in the TCP establishment procedure. If the TCP connection 401 is lost, the active endpoint is responsible for re-establishing the 402 TCP connection. Unless a new TLS session is negotiated, subsequent 403 SDP offers and answers will not impact the previously negotiated TLS 404 roles. 406 Endpoints that use the offer/answer model to establish a DTLS 407 association MUST support the 'setup' attribute, as defined in [7]. 408 When DTLS is used with UDP, the 'setup' attribute indicates which of 409 the endpoints (client or floor control server) initiates the DTLS 410 association setup. The requirements for the offer/answer exchange 411 specified in [13], Section 5 of [13] MUST be followed when using 412 DTLS. Offer/answer considerations are described in Section 10.5. 414 Informational note: How to determine which endpoint initiates the 415 TLS/DTLS association depends on the selected underlying transport. 416 It was decided to keep the original semantics in [15] for TCP to 417 retain backwards compatibility. When using UDP, the procedure 418 above was preferred since it adheres to [13] as used for DTLS- 419 SRTP, it does not overload offer/answer semantics, and it works 420 for offerless INVITE in scenarios with B2BUAs. 422 10. SDP Offer/Answer Procedures 424 This section defines the SDP offer/answer [4] procedures for 425 negotiating and establishing a BFCP connection. 427 If the 'm' line 'proto' value is 'TCP/TLS/BFCP' or 'UDP/TLS/BFCP', 428 each endpoint MUST provide a certificate fingerprint, using the SDP 429 'fingerprint' attribute [7], if the endpoint supports, and is willing 430 to use, a cipher suite with an associated certificate. 432 The authentication certificates are interpreted and validated as 433 defined in [10]. Self-signed certificates can be used securely, 434 provided that the integrity of the SDP description is assured as 435 defined in [10]. 437 Note: The procedures apply to a specific 'm' line describing a 438 BFCP connection. If an offer or answer contains multiple 'm' 439 lines describing BFCP connections, the procedures are applied 440 separately to each 'm' line. 442 10.1. Generating the Initial SDP Offer 444 When the offerer creates an initial offer, the offerer: 446 o MUST, if the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 447 'UDP/TLS/BFCP', associate an SDP setup attribute, with an 448 'actpass' value, with the 'm' line; 450 o MUST, if the 'm' line proto value is 'TCP/BFCP' or 'TCP/TLS/BFCP', 451 associate an SDP 'connection' attribute, with a 'new' value, with 452 the 'm' line; and 454 In addition, if the offerer acts as the floor control server, the 455 offerer: 457 o SHOULD associate an SDP 'floorctrl' attribute defined in 458 Section 4.1, with the 'm' line; 460 o MUST associate an SDP 'confid' attribute defined in Section 5, 461 with the 'm' line; 463 o MUST associate an SDP 'userid' attribute defined in Section 5, 464 with the 'm' line; 466 o MUST associate an SDP 'floorid' attribute defined in Section 6, 467 with the 'm' line; 469 o MUST associate an SDP 'label' attribute as described in Section 6, 470 with the 'm' line; and 472 o SHOULD, if it supports only the RFC 4583 subset and MUST, if it 473 supports RFC XXXX associate an SDP 'bfcpver' attribute defined in 474 Section 7, with the 'm' line. 476 10.2. Generating the SDP Answer 478 When the answerer receives an offer, which contains an 'm' line 479 describing a BFCP connection, if the answerer accepts the 'm' line 480 it: 482 o MUST insert a corresponding 'm' line in the answer, with an 483 identical 'm' line proto value [4]; and 485 o MUST, if the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 486 'UDP/TLS/BFCP', associate an SDP setup attribute, with an 'active' 487 or 'passive' value, with the 'm' line; 489 In addition, if the answerer acts as the floor control server, the 490 answerer: 492 o MUST, if the offer contains a 'floorctrl' attribute or else it 493 SHOULD associate an SDP 'floorctrl' attribute defined in 494 Section 4.1, with the 'm' line; 496 o MUST associate an SDP 'confid' attribute defined in Section 5, 497 with the 'm' line; 499 o MUST associate an SDP 'userid' attribute defined in Section 5, 500 with the 'm' line; 502 o MUST associate an SDP 'floorid' attribute defined in Section 6, 503 with the 'm' line; and 505 o MUST associate an SDP 'label' attribute as described in Section 6, 506 with the 'm' line. 508 o SHOULD, if it supports only the RFC 4583 subset and MUST, if it 509 supports RFC XXXX associate an SDP 'bfcpver' attribute defined in 510 Section 7, with the 'm' line. 512 Once the answerer has sent the answer, the answerer: 514 o MUST, if the answerer is the 'active' endpoint, and if a TCP 515 connection associated with the 'm' line is to be established (or 516 re-established), initiate the establishing of the TCP connection; 517 and 519 o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS 520 connection associated with the 'm' line is to be established (or 521 re-established), initiate the establishing of the TLS/DTLS 522 connection (by sending a ClientHello message). 524 If the answerer does not accept the 'm' line in the offer, it MUST 525 assign a zero port value to the corresponding 'm' line in the answer. 526 In addition, the answerer MUST NOT establish a TCP connection or a 527 TLS/DTLS connection associated with the 'm' line. 529 10.3. Offerer Processing of the SDP Answer 531 When the offerer receives an answer, which contains an 'm' line with 532 a non-zero port value, describing a BFCP connection, the offerer: 534 o MUST, if the offer is the 'active' endpoint, and if a TCP 535 connection associated with the 'm' line is to be established (or 536 re-established), initiate the establishing of the TCP connection; 537 and 539 o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS 540 connection associated with the 'm' line is to be established (or 541 re-established), initiate the establishing of the TLS/DTLS 542 connection (by sending a ClientHello message). 544 If the 'm' line in the answer contains a zero port value, the offerer 545 MUST NOT establish a TCP connection or a TLS/DTLS connection 546 associated with the 'm' line. 548 10.4. Modifying the Session 550 When an offerer sends an updated offer, in order to modify a 551 previously established BFCP connection, it follows the procedures in 552 Section 10.1, with the following exceptions: 554 o If the BFCP connection is carried on top of TCP, and unless the 555 offerer wants to re-establish an existing TCP connection, the 556 offerer MUST associate an SDP connection attribute, with an 557 'existing' value, with the 'm' line; and 559 o If the offerer wants to disable a previously established BFCP 560 connection, it MUST assign a zero port value to the 'm' line 561 associated with the BFCP connection, following the procedures in 562 [4]. 564 10.5. DTLS Role Determination 566 If the 'm' line proto value is 'UDP/TLS/BFCP', the 'active/passive' 567 status is used to determine the TLS roles. Following the procedures 568 in [10], the 'active' endpoint will take the TLS client role. 570 Once a DTLS connection has been established, if the 'active/passive' 571 status of the endpoints change during a session, a new DTLS 572 connection MUST be established. Therefore, endpoints SHOULD NOT 573 change the 'active/passive' status in subsequent offers and answers, 574 unless they want to establish a new DTLS connection. 576 If the transport parameters or the key fingerprints change, the 577 endpoints MUST establish a new DTLS connection. In such case the 578 'active/passive' status of the endpoints will again be determined 579 following the procedures in [7], and the new status will be used to 580 determine the TLS roles associated with the new DTLS connection. 582 Informational note: The procedure above is identical to the one 583 defined for DTLS-SRTP in [13]. 585 Note: A new DTLS connection needs to be established if the 586 transport parameters or the key fingerprints change. 588 11. Examples 590 For the purpose of brevity, the main portion of the session 591 description is omitted in the examples, which only show 'm' lines and 592 their attributes. 594 The following is an example of an offer sent by a conference server 595 to a client. 597 m=application 50000 TCP/TLS/BFCP * 598 a=setup:passive 599 a=connection:new 600 a=fingerprint:SHA-1 \ 601 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 602 a=floorctrl:s-only 603 a=confid:4321 604 a=userid:1234 605 a=floorid:1 mstrm:10 606 a=floorid:2 mstrm:11 607 a=bfcpver:1 608 m=audio 50002 RTP/AVP 0 609 a=label:10 610 m=video 50004 RTP/AVP 31 611 a=label:11 613 Note that due to RFC formatting conventions, this document splits SDP 614 across lines whose content would exceed 72 characters. A backslash 615 character marks where this line folding has taken place. This 616 backslash and its trailing CRLF and whitespace would not appear in 617 actual SDP content. 619 The following is the answer returned by the client. 621 m=application 9 TCP/TLS/BFCP * 622 a=setup:active 623 a=connection:new 624 a=fingerprint:SHA-1 \ 625 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 626 a=floorctrl:c-only 627 a=bfcpver:1 628 m=audio 55000 RTP/AVP 0 629 m=video 55002 RTP/AVP 31 631 A similar example using unreliable transport and DTLS is shown below, 632 where the offer is sent from a client. 634 m=application 50000 UDP/TLS/BFCP * 635 a=setup:actpass 636 a=fingerprint:SHA-1 \ 637 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 638 a=floorctrl:c-only s-only 639 a=confid:4321 640 a=userid:1234 641 a=floorid:1 mstrm:10 642 a=floorid:2 mstrm:11 643 a=bfcpver:2 644 m=audio 50002 RTP/AVP 0 645 a=label:10 646 m=video 50004 RTP/AVP 31 647 a=label:11 649 The following is the answer returned by the server. 651 m=application 55000 UDP/TLS/BFCP * 652 a=setup:active 653 a=fingerprint:SHA-1 \ 654 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 655 a=floorctrl:s-only 656 a=confid:4321 657 a=userid:1234 658 a=floorid:1 mstrm:10 659 a=floorid:2 mstrm:11 660 a=bfcpver:2 661 m=audio 55002 RTP/AVP 0 662 m=video 55004 RTP/AVP 31 664 12. Security Considerations 666 The BFCP [8], SDP [11], and offer/answer [4] specifications discuss 667 security issues related to BFCP, SDP, and offer/answer, respectively. 668 In addition, [7] and [10] discuss security issues related to the 669 establishment of TCP and TLS connections using an offer/answer model. 670 Furthermore, when using DTLS over UDP, considerations for its use 671 with RTP and RTCP are presented in [13]. The requirements for the 672 offer/answer exchange, as listed in Section 5 of [13], MUST be 673 followed. 675 An initial integrity-protected channel is REQUIRED for BFCP to 676 exchange self-signed certificates between a client and the floor 677 control server. For session descriptions carried in SIP [3], S/MIME 678 [6] is the natural choice to provide such a channel. 680 13. IANA Considerations 682 [Editorial note: The changes in Section 13.1 instruct the IANA to 683 register the two new values UDP/BFCP and UDP/TLS/BFCP for the SDP 684 'proto' field. The new section Section 13.6 registers a new SDP 685 "bfcpver" attribute. The rest is unchanged from [14].] 687 13.1. Registration of SDP 'proto' Values 689 The IANA has registered the following values for the SDP 'proto' 690 field under the Session Description Protocol (SDP) Parameters 691 registry: 693 +--------------+------------+ 694 | Value | Reference | 695 +--------------+------------+ 696 | TCP/BFCP | [RFC XXXX] | 697 | TCP/TLS/BFCP | [RFC XXXX] | 698 | UDP/BFCP | [RFC XXXX] | 699 | UDP/TLS/BFCP | [RFC XXXX] | 700 +--------------+------------+ 702 Table 2: Values for the SDP 'proto' field 704 13.2. Registration of the SDP 'floorctrl' Attribute 706 The IANA has registered the following SDP att-field under the Session 707 Description Protocol (SDP) Parameters registry: 709 Contact name: Gonzalo.Camarillo@ericsson.com 711 Attribute name: floorctrl 713 Long-form attribute name: Floor Control 715 Type of attribute: Media level 717 Subject to charset: No 719 Purpose of attribute: The 'floorctrl' attribute is used to perform 720 floor control server determination. 722 Allowed attribute values: 1*("c-only" / "s-only" / "c-s") 724 13.3. Registration of the SDP 'confid' Attribute 726 The IANA has registered the following SDP att-field under the Session 727 Description Protocol (SDP) Parameters registry: 729 Contact name: Gonzalo.Camarillo@ericsson.com 731 Attribute name: confid 733 Long-form attribute name: Conference Identifier 735 Type of attribute: Media level 737 Subject to charset: No 739 Purpose of attribute: The 'confid' attribute carries the integer 740 representation of a Conference ID. 742 Allowed attribute values: A token 744 13.4. Registration of the SDP 'userid' Attribute 746 The IANA has registered the following SDP att-field under the Session 747 Description Protocol (SDP) Parameters registry: 749 Contact name: Gonzalo.Camarillo@ericsson.com 751 Attribute name: userid 753 Long-form attribute name: User Identifier 755 Type of attribute: Media level 757 Subject to charset: No 759 Purpose of attribute: The 'userid' attribute carries the integer 760 representation of a User ID. 762 Allowed attribute values: A token 764 13.5. Registration of the SDP 'floorid' Attribute 766 The IANA has registered the following SDP att-field under the Session 767 Description Protocol (SDP) Parameters registry: 769 Contact name: Gonzalo.Camarillo@ericsson.com 771 Attribute name: floorid 773 Long-form attribute name: Floor Identifier 775 Type of attribute: Media level 777 Subject to charset: No 779 Purpose of attribute: The 'floorid' attribute associates a floor 780 with one or more media streams. 782 Allowed attribute values: Tokens 784 13.6. Registration of the SDP 'bfcpver' Attribute 786 The IANA has registered the following SDP att-field under the Session 787 Description Protocol (SDP) Parameters registry: 789 Contact name: Gonzalo.Camarillo@ericsson.com 791 Attribute name: bfcpver 793 Long-form attribute name: BFCP Version 795 Type of attribute: Media level 797 Subject to charset: No 799 Purpose of attribute: The 'bfcpver' attribute lists supported BFCP 800 versions. 802 Allowed attribute values: Tokens 804 14. Changes from RFC 4583 806 Following is the list of technical changes and other fixes from [15]. 808 Main purpose of this work was to add signaling support necessary to 809 support BFCP over unreliable transport, as described in [8], 810 resulting in the following changes: 812 1. Fields in the 'm' line (Section 3): 813 The section is re-written to remove reference to the exclusivity 814 of TCP as a transport for BFCP streams. The proto field values 815 UDP/BFCP and UDP/TLS/BFCP added. 817 2. Authentication (Section 9): 818 In last paragraph, made clear that a TCP connection was 819 described. 821 3. Security Considerations (Section 12): 822 For the DTLS over UDP case, mention existing considerations and 823 requirements for the offer/answer exchange in [13]. 825 4. Registration of SDP 'proto' Values (Section 13.1): 826 Register the two new values UDP/BFCP and UDP/TLS/BFCP in the SDP 827 parameters registry. 829 5. BFCP Version Negotiation (Section 7): 830 A new 'bfcpver' SDP media-level attribute is added in order to 831 signal supported version number. 833 Clarification and bug fixes: 835 1. Errata ID: 712 (Section 4 and Section 6): 836 Language clarification. Don't use terms like an SDP attribute is 837 "used in an 'm' line", instead make clear that the attribute is a 838 media-level attribute. 840 2. Fix typo in example (Section 11): 841 Do not use 'm-stream' in the SDP example, use the correct 'mstrm' 842 as specified in Section 11. Recommend interpreting 'm-stream' if 843 it is received, since it is present in some implementations. 845 3. Assorted clarifications (Across the document): 846 Language clarifications as a result of reviews. Also, the 847 normative language where tightened where appropriate, i.e. 848 changed from SHOULD strength to MUST in a number of places. 850 15. Acknowledgements 852 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 853 Oscar Novo provided useful ideas for the original [15]. The authors 854 also acknowledge contributions to the revision of BFCP for use over 855 an unreliable transport from Geir Arne Sandbakken, Charles Eckel, 856 Alan Ford, Eoin McLeod and Mark Thompson. Useful and important final 857 reviews were done by Ali C. Begen, Mary Barnes and Charles Eckel. 859 16. Normative References 861 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 862 Levels", BCP 14, RFC 2119, March 1997. 864 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 865 Specifications: ABNF", STD 68, RFC 5234, January 2008. 867 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 868 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 869 Session Initiation Protocol", RFC 3261, June 2002. 871 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 872 Session Description Protocol (SDP)", RFC 3264, June 2002. 874 [5] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, 875 R., and W. Polk, "Internet X.509 Public Key Infrastructure 876 Certificate and Certificate Revocation List (CRL) Profile", 877 RFC 5280, May 2008. 879 [6] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail 880 Extensions (S/MIME) Version 3.2 Certificate Handling", 881 RFC 5750, January 2010. 883 [7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 884 Session Description Protocol (SDP)", RFC 4145, September 2005. 886 [8] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 887 Eckel, "The Binary Floor Control Protocol (BFCP)", 888 draft-ietf-bfcpbis-rfc4582bis-13 (work in progress), 889 February 2015. 891 [9] Levin, O. and G. Camarillo, "The Session Description Protocol 892 (SDP) Label Attribute", RFC 4574, August 2006. 894 [10] Lennox, J., "Connection-Oriented Media Transport over the 895 Transport Layer Security (TLS) Protocol in the Session 896 Description Protocol (SDP)", RFC 4572, July 2006. 898 [11] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 899 Description Protocol", RFC 4566, July 2006. 901 [12] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 902 Security Version 1.2", RFC 6347, January 2012. 904 [13] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for 905 Establishing a Secure Real-time Transport Protocol (SRTP) 906 Security Context Using Datagram Transport Layer Security 907 (DTLS)", RFC 5763, May 2010. 909 [14] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control 910 Protocol (BFCP)", RFC 4582, November 2006. 912 [15] Camarillo, G., "Session Description Protocol (SDP) Format for 913 Binary Floor Control Protocol (BFCP) Streams", RFC 4583, 914 November 2006. 916 Authors' Addresses 918 Gonzalo Camarillo 919 Ericsson 920 Hirsalantie 11 921 FI-02420 Jorvas 922 Finland 924 Email: Gonzalo.Camarillo@ericsson.com 926 Tom Kristensen 927 Cisco 928 Philip Pedersens vei 1 929 NO-1366 Lysaker 930 Norway 932 Email: tomkrist@cisco.com, tomkri@ifi.uio.no