idnits 2.17.1 draft-ietf-bfcpbis-rfc4583bis-06.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 12, 2013) is 4090 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 469 ** Obsolete normative reference: RFC 5750 (ref. '6') (Obsoleted by RFC 8550) == Outdated reference: A later version (-16) exists of draft-ietf-bfcpbis-rfc4582bis-08 ** 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 16, 2013 February 12, 2013 8 Session Description Protocol (SDP) Format for Binary Floor Control 9 Protocol (BFCP) Streams 10 draft-ietf-bfcpbis-rfc4583bis-06 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 12. 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 16, 2013. 39 Copyright Notice 41 Copyright (c) 2013 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 5. The 'confid' and 'userid' SDP Attributes . . . . . . . . . . . 6 61 6. Association between Streams and Floors . . . . . . . . . . . . 6 62 7. BFCP Connection Management . . . . . . . . . . . . . . . . . . 7 63 7.1. TCP Connection Management . . . . . . . . . . . . . . . . 7 64 8. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 65 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 11.1. Registration of SDP 'proto' Values . . . . . . . . . . . . 11 69 11.2. Registration of the SDP 'floorctrl' Attribute . . . . . . 11 70 11.3. Registration of the SDP 'confid' Attribute . . . . . . . . 12 71 11.4. Registration of the SDP 'userid' Attribute . . . . . . . . 12 72 11.5. Registration of the SDP 'floorid' Attribute . . . . . . . 12 73 12. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 13 74 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 75 14. Normative References . . . . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 As discussed in the BFCP (Binary Floor Control Protocol) 81 specification [8], a given BFCP client needs a set of data in order 82 to establish a BFCP connection to a floor control server. These data 83 include the transport address of the server, the conference 84 identifier, and the user identifier. 86 One way for clients to obtain this information is to use an offer/ 87 answer [4] exchange. This document specifies how to encode this 88 information in the SDP session descriptions that are part of such an 89 offer/answer exchange. 91 User agents typically use the offer/answer model to establish a 92 number of media streams of different types. Following this model, a 93 BFCP connection is described as any other media stream by using an 94 SDP 'm' line, possibly followed by a number of attributes encoded in 95 'a' lines. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14, RFC 2119 [1] and indicate requirement levels for compliant 103 implementations. 105 3. Fields in the 'm' Line 107 This section describes how to generate an 'm' line for a BFCP stream. 109 According to the SDP specification [11], the 'm' line format is the 110 following: 112 m= ... 114 The media field MUST have a value of "application". 116 The port field is set depending on the value of the transport field, 117 as explained below. A port field value of zero has the standard SDP 118 meaning (i.e., rejection of the media stream) regardless of the 119 transport used. 121 When TCP is used as the transport, the port field is set following 122 the rules in [7]. Depending on the value of the 'setup' attribute 123 (discussed in Section 7.1), the port field contains the port to 124 which the remote endpoint will direct BFCP messages or is 125 irrelevant (i.e., the endpoint will initiate the connection 126 towards the remote endpoint) and should be set to a value of 9, 127 which is the discard port. 129 When UDP is used as the transport, the port field contains the 130 port to which the remote endpoint will direct BFCP messages 131 regardless of the value of the 'setup' attribute. 133 We define four new values for the transport field: TCP/BFCP, TCP/TLS/ 134 BFCP, UDP/BFCP, and UDP/TLS/BFCP. TCP/BFCP is used when BFCP runs 135 directly on top of TCP, TCP/TLS/BFCP is used when BFCP runs on top of 136 TLS, which in turn runs on top of TCP. Similarly, UDP/BFCP is used 137 when BFCP runs directly on top of UDP, and UDP/TLS/BFCP is used when 138 BFCP runs on top of DTLS [12], which in turn runs on top of UDP. 140 The fmt (format) list is ignored for BFCP. The fmt list of BFCP 'm' 141 lines SHOULD contain a single "*" character. 143 The following is an example of an 'm' line for a BFCP connection: 145 m=application 50000 TCP/TLS/BFCP * 147 4. Floor Control Server Determination 149 When two endpoints establish a BFCP stream, they need to determine 150 which of them acts as a floor control server. In the most common 151 scenario, a client establishes a BFCP stream with a conference server 152 that acts as the floor control server. Floor control server 153 determination is straight forward because one endpoint can only act 154 as a client and the other can only act as a floor control server. 156 However, there are scenarios where both endpoints could act as a 157 floor control server. For example, in a two-party session that 158 involves an audio stream and a shared whiteboard, the endpoints need 159 to decide which party will be acting as the floor control server. 161 Furthermore, there are situations where both the offerer and the 162 answerer act as both clients and floor control servers in the same 163 session. For example, in a two-party session that involves an audio 164 stream and a shared whiteboard, one party acts as the floor control 165 server for the audio stream and the other acts as the floor control 166 server for the shared whiteboard. 168 We define the 'floorctrl' SDP media-level attribute to perform floor 169 control determination. Its Augmented BNF syntax [2] is: 171 floor-control-attribute = "a=floorctrl:" role *(SP role) 172 role = "c-only" / "s-only" / "c-s" 174 The offerer includes this attribute to state all the roles it would 175 be willing to perform: 177 c-only: The offerer would be willing to act as a floor control 178 client only. 180 s-only: The offerer would be willing to act as a floor control 181 server only. 183 c-s: The offerer would be willing to act both as a floor control 184 client and as a floor control server. 186 If an SDP media description in an offer contains a 'floorctrl' 187 attribute, the answerer accepting that media MUST include one in the 188 corresponding media description of the answer. The answerer includes 189 this attribute to state which role the answerer will perform. That 190 is, the answerer chooses one of the roles the offerer is willing to 191 perform and generates an answer with the corresponding role for the 192 answerer. Table 1 shows the corresponding roles for an answerer, 193 depending on the offerer's role. 195 +---------+----------+ 196 | Offerer | Answerer | 197 +---------+----------+ 198 | c-only | s-only | 199 | s-only | c-only | 200 | c-s | c-s | 201 +---------+----------+ 203 Table 1: Roles 205 The following are the descriptions of the roles when they are chosen 206 by an answerer: 208 c-only: The answerer will act as a floor control client. 209 Consequently, the offerer will act as a floor control server. 211 s-only: The answerer will act as a floor control server. 212 Consequently, the offerer will act as a floor control client. 214 c-s: The answerer will act both as a floor control client and as a 215 floor control server. Consequently, the offerer will also act 216 both as a floor control client and as a floor control server. 218 Endpoints that use the offer/answer model to establish BFCP 219 connections MUST support the 'floorctrl' attribute. A floor control 220 server acting as an offerer or as an answerer SHOULD include this 221 attribute in its session descriptions. 223 If the 'floorctrl' attribute is not used in an offer/answer exchange, 224 by default the offerer and the answerer will act as a floor control 225 client and as a floor control server, respectively. 227 The following is an example of a 'floorctrl' attribute in an offer. 228 When this attribute appears in an answer, it only carries one role: 230 a=floorctrl:c-only s-only c-s 232 5. The 'confid' and 'userid' SDP Attributes 234 We define the 'confid' and the 'userid' SDP media-level attributes. 235 These attributes are used by a floor control server to provide a 236 client with a conference ID and a user ID, respectively. Their 237 Augmented BNF syntax [2] is: 239 confid-attribute = "a=confid:" conference-id 240 conference-id = token 241 userid-attribute = "a=userid:" user-id 242 user-id = token 244 The 'confid' and the 'userid' attributes carry the decimal integer 245 representation of a conference ID and a user ID, respectively. 247 Endpoints that use the offer/answer model to establish BFCP 248 connections MUST support the 'confid' and the 'userid' attributes. A 249 floor control server acting as an offerer or as an answerer SHOULD 250 include these attributes in its session descriptions. 252 6. Association between Streams and Floors 254 We define the 'floorid' SDP media-level attribute. Its Augmented BNF 255 syntax [2] is: 257 floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)] 259 The 'floorid' attribute is used in the SDP media description for BFCP 260 media. It defines a floor identifier and, possibly, associates it 261 with one or more media streams. The token representing the floor ID 262 is the integer representation of the Floor ID to be used in BFCP. 263 The token representing the media stream is a pointer to the media 264 stream, which is identified by an SDP label attribute [9]. 266 Endpoints that use the offer/answer model to establish BFCP 267 connections MUST support the 'floorid' and the 'label' attributes. A 268 floor control server acting as an offerer or as an answerer SHOULD 269 include these attributes in its session descriptions. 271 Note: In [15] 'm-stream' was erroneously used in Section 9. Although 272 the example was non-normative, it is implemented by some vendors and 273 occurs in cases where the endpoint is willing to act as an server. 274 Therefore, it is RECOMMENDED to support parsing and interpreting 275 'm-stream' the same way as 'mstrm' when receiving. 277 7. BFCP Connection Management 279 BFCP connections may use TCP or UDP as the underlying transport. 280 BFCP entities exchanging BFCP messages over UDP will direct the BFCP 281 messages to the peer side connection address and port provided in the 282 SDP 'm' line. TCP connection management is more complicated and is 283 described below. 285 7.1. TCP Connection Management 287 The management of the TCP connection used to transport BFCP is 288 performed using the 'setup' and 'connection' attributes, as defined 289 in [7]. 291 The 'setup' attribute indicates which of the endpoints (client or 292 floor control server) initiates the TCP connection. The 'connection' 293 attribute handles TCP connection reestablishment. 295 The BFCP specification [8] describes a number of situations when the 296 TCP connection between a client and the floor control server needs to 297 be reestablished. However, that specification does not describe the 298 reestablishment process because this process depends on how the 299 connection was established in the first place. BFCP entities using 300 the offer/answer model follow the following rules. 302 When the existing TCP connection is reset following the rules in [8], 303 the client SHOULD generate an offer towards the floor control server 304 in order to reestablish the connection. If a TCP connection cannot 305 deliver a BFCP message and times out, the entity that attempted to 306 send the message (i.e., the one that detected the TCP timeout) SHOULD 307 generate an offer in order to reestablish the TCP connection. 309 Endpoints that use the offer/answer model to establish TCP 310 connections MUST support the 'setup' and 'connection' attributes. 312 8. Authentication 314 When a BFCP connection is established using the offer/answer model, 315 it is assumed that the offerer and the answerer authenticate each 316 other using some mechanism. Once this mutual authentication takes 317 place, all the offerer and the answerer need to ensure is that the 318 entity they are receiving BFCP messages from is the same as the one 319 that generated the previous offer or answer. 321 When SIP is used to perform an offer/answer exchange, the initial 322 mutual authentication takes place at the SIP level. Additionally, 323 SIP uses S/MIME [6] to provide an integrity-protected channel with 324 optional confidentiality for the offer/answer exchange. BFCP takes 325 advantage of this integrity-protected offer/answer exchange to 326 perform authentication. Within the offer/answer exchange, the 327 offerer and answerer exchange the fingerprints of their self-signed 328 certificates. These self-signed certificates are then used to 329 establish the TLS/DTLS connection that will carry BFCP traffic 330 between the offerer and the answerer. 332 BFCP clients and floor control servers follow the rules in [10] 333 regarding certificate choice and presentation. This implies that 334 unless a 'fingerprint' attribute is included in the session 335 description, the certificate provided at the TLS-/DTLS-level MUST 336 either be directly signed by one of the other party's trust anchors 337 or be validated using a certification path that terminates at one of 338 the other party's trust anchors [5]. Endpoints that use the offer/ 339 answer model to establish BFCP connections MUST support the 340 'fingerprint' attribute and SHOULD include it in their session 341 descriptions. 343 When TLS is used with TCP, once the underlying connection is 344 established, the answerer acts as the TLS server regardless of its 345 role (passive or active) in the TCP establishment procedure. 347 Endpoints that use the offer/answer model to establish a DTLS 348 association MUST support the 'setup' attribute, as defined in [7]. 349 When DTLS is used with UDP, the 'setup' attribute indicates which of 350 the endpoints (client or floor control server) initiates the DTLS 351 association setup. The requirements for the offer/answer exchange 352 specified in [13], Section 5 MUST be followed when using DTLS. 354 Informational note: How to determine which endpoint to initiate 355 the TLS/DTLS association depends on the selected underlying 356 transport. It was decided to keep the original semantics in [15] 357 for TCP to retain backwards compatibility. When using UDP, the 358 procedure above was preferred since it adheres to [13] as used for 359 DTLS-SRTP, it does not overload offer/answer semantics, and it 360 works for offerless INVITE in scenarios with B2BUAs. 362 9. Examples 364 For the purpose of brevity, the main portion of the session 365 description is omitted in the examples, which only show 'm' lines and 366 their attributes. 368 The following is an example of an offer sent by a conference server 369 to a client. 371 m=application 50000 TCP/TLS/BFCP * 372 a=setup:passive 373 a=connection:new 374 a=fingerprint:SHA-1 \ 375 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 376 a=floorctrl:s-only 377 a=confid:4321 378 a=userid:1234 379 a=floorid:1 mstrm:10 380 a=floorid:2 mstrm:11 381 m=audio 50002 RTP/AVP 0 382 a=label:10 383 m=video 50004 RTP/AVP 31 384 a=label:11 386 Note that due to RFC formatting conventions, this document splits SDP 387 across lines whose content would exceed 72 characters. A backslash 388 character marks where this line folding has taken place. This 389 backslash and its trailing CRLF and whitespace would not appear in 390 actual SDP content. 392 The following is the answer returned by the client. 394 m=application 9 TCP/TLS/BFCP * 395 a=setup:active 396 a=connection:new 397 a=fingerprint:SHA-1 \ 398 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 399 a=floorctrl:c-only 400 m=audio 55000 RTP/AVP 0 401 m=video 55002 RTP/AVP 31 403 A similar example using unreliable transport and DTLS is shown below, 404 where the offer is sent from a client. 406 m=application 50000 UDP/TLS/BFCP * 407 a=setup:actpass 408 a=fingerprint:SHA-1 \ 409 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 410 a=floorctrl:c-only s-only 411 a=confid:4321 412 a=userid:1234 413 a=floorid:1 mstrm:10 414 a=floorid:2 mstrm:11 415 m=audio 50002 RTP/AVP 0 416 a=label:10 417 m=video 50004 RTP/AVP 31 418 a=label:11 420 The following is the answer returned by the server. 422 m=application 55000 UDP/TLS/BFCP * 423 a=setup:active 424 a=fingerprint:SHA-1 \ 425 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 426 a=floorctrl:s-only 427 a=confid:4321 428 a=userid:1234 429 a=floorid:1 mstrm:10 430 a=floorid:2 mstrm:11 431 m=audio 55002 RTP/AVP 0 432 m=video 55004 RTP/AVP 31 434 10. Security Considerations 436 The BFCP [8], SDP [11], and offer/answer [4] specifications discuss 437 security issues related to BFCP, SDP, and offer/answer, respectively. 438 In addition, [7] and [10] discuss security issues related to the 439 establishment of TCP and TLS connections using an offer/answer model. 440 Furthermore, when using DTLS over UDP, considerations for its use 441 with RTP and RTCP are presented in [13]. The requirements for the 442 offer/answer exchange, as listed in Section 5 of that document, MUST 443 be followed. 445 BFCP assumes that an initial integrity-protected channel is used to 446 exchange self-signed certificates between a client and the floor 447 control server. For session descriptions carried in SIP [3], S/MIME 449 [6] is the natural choice to provide such a channel. 451 11. IANA Considerations 453 [Editorial note: The changes in Section 11.1 instruct the IANA to 454 register the two new values UDP/BFCP and UDP/TLS/BFCP for the SDP 455 'proto' field, the rest is unchanged from [14].] 457 11.1. Registration of SDP 'proto' Values 459 The IANA has registered the following values for the SDP 'proto' 460 field under the Session Description Protocol (SDP) Parameters 461 registry: 463 +--------------+------------+ 464 | Value | Reference | 465 +--------------+------------+ 466 | TCP/BFCP | [RFC XXXX] | 467 | TCP/TLS/BFCP | [RFC XXXX] | 468 | UDP/BFCP | [RFC XXXX] | 469 | UDP/TLS/BFCP | [RFC XXXX] | 470 +--------------+------------+ 472 Table 2: Values for the SDP 'proto' field 474 11.2. Registration of the SDP 'floorctrl' Attribute 476 The IANA has registered the following SDP att-field under the Session 477 Description Protocol (SDP) Parameters registry: 479 Contact name: Gonzalo.Camarillo@ericsson.com 481 Attribute name: floorctrl 483 Long-form attribute name: Floor Control 485 Type of attribute: Media level 487 Subject to charset: No 489 Purpose of attribute: The 'floorctrl' attribute is used to perform 490 floor control server determination. 492 Allowed attribute values: 1*("c-only" / "s-only" / "c-s") 494 11.3. Registration of the SDP 'confid' Attribute 496 The IANA has registered the following SDP att-field under the Session 497 Description Protocol (SDP) Parameters registry: 499 Contact name: Gonzalo.Camarillo@ericsson.com 501 Attribute name: confid 503 Long-form attribute name: Conference Identifier 505 Type of attribute: Media level 507 Subject to charset: No 509 Purpose of attribute: The 'confid' attribute carries the integer 510 representation of a Conference ID. 512 Allowed attribute values: A token 514 11.4. Registration of the SDP 'userid' Attribute 516 The IANA has registered the following SDP att-field under the Session 517 Description Protocol (SDP) Parameters registry: 519 Contact name: Gonzalo.Camarillo@ericsson.com 521 Attribute name: userid 523 Long-form attribute name: User Identifier 525 Type of attribute: Media level 527 Subject to charset: No 529 Purpose of attribute: The 'userid' attribute carries the integer 530 representation of a User ID. 532 Allowed attribute values: A token 534 11.5. Registration of the SDP 'floorid' Attribute 536 The IANA has registered the following SDP att-field under the Session 537 Description Protocol (SDP) Parameters registry: 539 Contact name: Gonzalo.Camarillo@ericsson.com 541 Attribute name: floorid 543 Long-form attribute name: Floor Identifier 545 Type of attribute: Media level 547 Subject to charset: No 549 Purpose of attribute: The 'floorid' attribute associates a floor 550 with one or more media streams. 552 Allowed attribute values: Tokens 554 12. Changes from RFC 4583 556 Following is the list of technical changes and other fixes from [15]. 558 Main purpose of this work was to add signaling support necessary to 559 support BFCP over unreliable transport, as described in [8], 560 resulting in the following changes: 562 Fields in the 'm' Line (Section 3): 563 The section is re-written to remove reference to the 564 exclusivity of TCP as a transport for BFCP streams. The 565 transport field values UDP/BFCP and UDP/TLS/BFCP added. 567 Authentication (Section 8): 568 In last paragraph, made clear that a TCP connection was 569 described. 571 Security Considerations (Section 10): 572 For the DTLS over UDP case, mention existing considerations and 573 requirements for the offer/answer exchange in [13]. 575 Registration of SDP 'proto' Values (Section 11.1): 576 Register the two new values UDP/BFCP and UDP/TLS/BFCP in the 577 SDP parameters registry. 579 The clarification and bug fixes: 581 Errata ID: 712 (Section 4 and Section 6): 582 Language clarification. Don't use terms like an SDP attribute is 583 "used in an 'm' line", instead make clear that the attribute is a 584 media-level attribute. 586 Fix typo in example (Section 9): 587 Do not use 'm-stream' in the SDP example, use the correct 'mstrm' 588 as specified in Section 9. Recommend interpreting 'm-stream' if 589 it is received, since it is present in some implementations. 591 13. Acknowledgements 593 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 594 Oscar Novo provided useful ideas for the original [15]. The authors 595 also acknowledge contributions to the revision of BFCP for use over 596 an unreliable transport from Geir Arne Sandbakken, Charles Eckel, 597 Eoin McLeod and Mark Thompson. 599 14. Normative References 601 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 602 Levels", BCP 14, RFC 2119, March 1997. 604 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 605 Specifications: ABNF", STD 68, RFC 5234, January 2008. 607 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 608 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 609 Session Initiation Protocol", RFC 3261, June 2002. 611 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 612 Session Description Protocol (SDP)", RFC 3264, June 2002. 614 [5] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, 615 R., and W. Polk, "Internet X.509 Public Key Infrastructure 616 Certificate and Certificate Revocation List (CRL) Profile", 617 RFC 5280, May 2008. 619 [6] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail 620 Extensions (S/MIME) Version 3.2 Certificate Handling", 621 RFC 5750, January 2010. 623 [7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 624 Session Description Protocol (SDP)", RFC 4145, September 2005. 626 [8] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 627 Eckel, "The Binary Floor Control Protocol (BFCP)", 628 draft-ietf-bfcpbis-rfc4582bis-08 (work in progress), 629 January 2013. 631 [9] Levin, O. and G. Camarillo, "The Session Description Protocol 632 (SDP) Label Attribute", RFC 4574, August 2006. 634 [10] Lennox, J., "Connection-Oriented Media Transport over the 635 Transport Layer Security (TLS) Protocol in the Session 636 Description Protocol (SDP)", RFC 4572, July 2006. 638 [11] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 639 Description Protocol", RFC 4566, July 2006. 641 [12] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 642 Security Version 1.2", RFC 6347, January 2012. 644 [13] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for 645 Establishing a Secure Real-time Transport Protocol (SRTP) 646 Security Context Using Datagram Transport Layer Security 647 (DTLS)", RFC 5763, May 2010. 649 [14] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control 650 Protocol (BFCP)", RFC 4582, November 2006. 652 [15] Camarillo, G., "Session Description Protocol (SDP) Format for 653 Binary Floor Control Protocol (BFCP) Streams", RFC 4583, 654 November 2006. 656 Authors' Addresses 658 Gonzalo Camarillo 659 Ericsson 660 Hirsalantie 11 661 Jorvas 02420 662 Finland 664 Email: Gonzalo.Camarillo@ericsson.com 666 Tom Kristensen 667 Cisco 668 Philip Pedersens vei 22 669 N-1366 Lysaker 670 Norway 672 Email: tomkrist@cisco.com, tomkri@ifi.uio.no