idnits 2.17.1 draft-ietf-mmusic-sdp-capability-negotiation-12.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 28, 2010) is 5164 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) == Missing Reference: 'S' is mentioned on line 3101, but not defined == Missing Reference: 'F' is mentioned on line 3101, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'ICE' -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4756 (Obsoleted by RFC 5956) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group F. Andreasen 3 Internet-Draft Cisco Systems 4 Intended Status: Proposed Standard February 28, 2010 5 Expires: August 2010 7 SDP Capability Negotiation 8 draft-ietf-mmusic-sdp-capability-negotiation-12.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on August 28, 2010. 33 Copyright and License Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the Simplified BSD License. 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Abstract 62 The Session Description Protocol (SDP) was intended for describing 63 multimedia sessions for the purposes of session announcement, 64 session invitation, and other forms of multimedia session 65 initiation. SDP was not intended to provide capability indication or 66 capability negotiation, however over the years, SDP has seen 67 widespread adoption and as a result it has been gradually extended 68 to provide limited support for these, notably in the form of the 69 offer/answer model defined in RFC 3264. SDP does not define how to 70 negotiate one or more alternative transport protocols (e.g. RTP 71 profiles) or attributes. This makes it difficult to deploy new RTP 72 profiles such as secure RTP or RTP with RTCP-based feedback, 73 negotiate use of different security keying mechanisms, etc. It also 74 presents problems for some forms of media negotiation. 76 The purpose of this document is to address these shortcomings by 77 extending SDP with capability negotiation parameters and associated 78 offer/answer procedures to use those parameters in a backwards 79 compatible manner. 81 The document defines a general SDP Capability Negotiation framework. 82 It also specifies how to provide attributes and transport protocols 83 as capabilities and negotiate them using the framework. Extensions 84 for other types of capabilities (e.g. media types and media formats) 85 may be provided in other documents. 87 Table of Contents 89 1. Introduction...................................................4 90 2. Conventions used in this document..............................7 91 3. SDP Capability Negotiation Solution............................8 92 3.1. SDP Capability Negotiation Model..........................8 93 3.2. Solution Overview........................................11 94 3.3. Version and Extension Indication Attributes..............15 95 3.3.1. Supported Capability Negotiation Extensions Attribute15 96 3.3.2. Required Capability Negotiation Extensions Attribute17 97 3.4. Capability Attributes....................................19 98 3.4.1. Attribute Capability Attribute......................19 99 3.4.2. Transport Protocol Capability Attribute.............21 100 3.4.3. Extension Capability Attributes.....................23 101 3.5. Configuration Attributes.................................24 102 3.5.1. Potential Configuration Attribute...................24 103 3.5.2. Actual Configuration Attribute......................32 104 3.6. Offer/Answer Model Extensions............................34 105 3.6.1. Generating the Initial Offer........................34 106 3.6.2. Generating the Answer...............................37 107 3.6.2.1. Example Views of Potential Configurations......44 108 3.6.3. Offerer Processing of the Answer....................46 109 3.6.4. Modifying the Session...............................48 110 3.7. Interactions with ICE....................................48 111 3.8. Interactions with SIP Option Tags........................50 112 3.9. Processing Media before Answer...........................50 113 3.10. Indicating Bandwidth Usage..............................51 114 3.11. Dealing with Large Number of Potential Configurations...53 115 3.12. SDP Capability Negotiation and Intermediaries...........54 116 3.13. Considerations for Specific Attribute Capabilities......55 117 3.13.1. The rtpmap and fmtp Attributes.....................55 118 3.13.2. Direction Attributes...............................56 119 3.14. Relationship to RFC 3407................................57 120 4. Examples......................................................57 121 4.1. Multiple Transport Protocols.............................57 122 4.2. DTLS-SRTP or SRTP with Media Level Security Descriptions.61 123 4.3. Best-Effort SRTP with Session-Level MIKEY and Media Level 124 Security Descriptions.........................................64 125 4.4. SRTP with Session-Level MIKEY and Media Level Security 126 Descriptions as Alternatives..................................69 127 5. Security Considerations.......................................72 128 6. IANA Considerations...........................................75 129 6.1. New SDP Attributes.......................................75 130 6.2. New SDP Capability Negotiation Option Tag Registry.......77 131 6.3. New SDP Capability Negotiation Potential Configuration 132 Parameter Registry............................................77 133 7. Acknowledgments...............................................78 134 8. Change Log....................................................78 135 8.1. draft-ietf-mmusic-sdp-capability-negotiation-12..........78 136 8.2. draft-ietf-mmusic-sdp-capability-negotiation-11..........78 137 8.3. draft-ietf-mmusic-sdp-capability-negotiation-10..........79 138 8.4. draft-ietf-mmusic-sdp-capability-negotiation-09..........80 139 8.5. draft-ietf-mmusic-sdp-capability-negotiation-08..........80 140 8.6. draft-ietf-mmusic-sdp-capability-negotiation-07..........81 141 8.7. draft-ietf-mmusic-sdp-capability-negotiation-06..........81 142 8.8. draft-ietf-mmusic-sdp-capability-negotiation-05..........83 143 8.9. draft-ietf-mmusic-sdp-capability-negotiation-04..........84 144 8.10. draft-ietf-mmusic-sdp-capability-negotiation-03.........84 145 8.11. draft-ietf-mmusic-sdp-capability-negotiation-02.........84 146 8.12. draft-ietf-mmusic-sdp-capability-negotiation-01.........85 147 8.13. draft-ietf-mmusic-sdp-capability-negotiation-00.........86 148 9. References....................................................87 149 9.1. Normative References.....................................87 150 9.2. Informative References...................................87 151 Author's Address.................................................90 153 1. Introduction 155 The Session Description Protocol (SDP) was intended for describing 156 multimedia sessions for the purposes of session announcement, 157 session invitation, and other forms of multimedia session 158 initiation. A SDP session description contains one or more media 159 stream descriptions with information such as IP-address and port, 160 type of media stream (e.g. audio or video), transport protocol 161 (possibly including profile information, e.g. RTP/AVP or RTP/SAVP), 162 media formats (e.g. codecs), and various other session and media 163 stream parameters that define the session. 165 Simply providing media stream descriptions is sufficient for session 166 announcements for a broadcast application, where the media stream 167 parameters are fixed for all participants. When a participant wants 168 to join the session, he obtains the session announcement and uses 169 the media descriptions provided, e.g., joins a multicast group and 170 receives media packets in the encoding format specified. If the 171 media stream description is not supported by the participant, he is 172 unable to receive the media. 174 Such restrictions are not generally acceptable to multimedia session 175 invitations, where two or more entities attempt to establish a media 176 session, that uses a set of media stream parameters acceptable to 177 all participants. First of all, each entity must inform the other of 178 its receive address, and secondly, the entities need to agree on the 179 media stream parameters to use for the session, e.g. transport 180 protocols and codecs. To solve this, RFC 3264 [RFC3264] defined the 181 offer/answer model, whereby an offerer constructs an offer SDP 182 session description that lists the media streams, codecs, and other 183 SDP parameters that the offerer is willing to use. This offer 184 session description is sent to the answerer, which chooses from 185 among the media streams, codecs and other session description 186 parameters provided, and generates an answer session description 187 with his parameters, based on that choice. The answer session 188 description is sent back to the offerer thereby completing the 189 session negotiation and enabling the establishment of the negotiated 190 media streams. 192 Taking a step back, we can make a distinction between the 193 capabilities supported by each participant, the way in which those 194 capabilities can be supported, and the parameters that can actually 195 be used for the session. More generally, we can say that we have the 196 following: 198 o A set of capabilities for the session and its associated media 199 stream components, supported by each side. The capability 200 indications by themselves do not imply a commitment to use the 201 capabilities in the session. 203 Capabilities can for example be that the "RTP/SAVP" profile is 204 supported, that the "PCMU" codec is supported, or that the 205 "crypto" attribute is supported with a particular value. 207 o A set of potential configurations indicating which combinations 208 of those capabilities can be used for the session and its 209 associated media stream components. Potential configurations are 210 not ready for use. Instead, they provide an alternative that may 211 be used, subject to further negotiation. 213 A potential configuration can for example indicate that the 214 "PCMU" codec and the "RTP/SAVP" transport protocol are not only 215 supported (i.e. listed as capabilities), but they are offered for 216 potential use in the session. 218 o An actual configuration for the session and its associated media 219 stream components, that specifies which combinations of session 220 parameters and media stream components can be used currently and 221 with what parameters. Use of an actual configuration does not 222 require any further negotiation. 224 An actual configuration can for example be that the "PCMU" codec 225 and the "RTP/SAVP" transport protocol are offered for use 226 currently. 228 o A negotiation process that takes the set of actual and potential 229 configurations (combinations of capabilities) as input and 230 provides the negotiated actual configurations as output. 232 SDP by itself was designed to provide only one of these, namely 233 listing of the actual configurations, however over the years, use of 234 SDP has been extended beyond its original scope. Of particular 235 importance are the session negotiation semantics that were defined 236 by the offer/answer model in RFC 3264. In this model, both the offer 237 and the answer contain actual configurations; separate capabilities 238 and potential configurations are not supported. 240 Other relevant extensions have been defined as well. RFC 3407 241 [RFC3407] defined simple capability declarations, which extends SDP 242 with a simple and limited set of capability descriptions. Grouping 243 of media lines, which defines how media lines in SDP can have other 244 semantics than the traditional "simultaneous media streams" 245 semantics, was defined in RFC 3388 [RFC3388], etc. 247 Each of these extensions was designed to solve a specific limitation 248 of SDP. Since SDP had already been stretched beyond its original 249 intent, a more comprehensive capability declaration and negotiation 250 process was intentionally not defined. Instead, work on a "next 251 generation" of a protocol to provide session description and 252 capability negotiation was initiated [SDPng]. SDPng defined a 253 comprehensive capability negotiation framework and protocol that was 254 not bound by existing SDP constraints. SDPng was not designed to be 255 backwards compatible with existing SDP and hence required both sides 256 to support it, with a graceful fallback to legacy operation when 257 needed. This, combined with lack of ubiquitous multipart MIME 258 support in the protocols that would carry SDP or SDPng, made it 259 challenging to migrate towards SDPng. In practice, SDPng has not 260 gained traction and as of the time of publication of this document, 261 work on SDPng has stopped. Existing real-time multimedia 262 communication protocols such as SIP, RTSP, Megaco, and MGCP continue 263 to use SDP. However, SDP does not address an increasingly important 264 problem: the ability to negotiate one or more alternative transport 265 protocols (e.g., RTP profiles) and associated parameters (e.g. SDP 266 attributes). This makes it difficult to deploy new RTP profiles 267 such as secure RTP (SRTP) [RFC3711], RTP with RTCP-Based Feedback 268 [RFC4585], etc. The problem is exacerbated by the fact that RTP 269 profiles are defined independently. When a new profile is defined 270 and N other profiles already exist, there is a potential need for 271 defining N additional profiles, since profiles cannot be combined 272 automatically. For example, in order to support the plain and 273 secure RTP version of RTP with and without RTCP-based feedback, four 274 separate profiles (and hence profile definitions) are needed: 275 RTP/AVP [RFC3551], RTP/SAVP [RFC3711], RTP/AVPF [RFC4585], and 276 RTP/SAVPF [RFC5124]. In addition to the pressing profile 277 negotiation problem, other important real-life limitations have been 278 found as well. Keying material and other parameters for example need 279 to be negotiated with some of the transport protocols, but not 280 others. Similarly, some media formats and types of media streams 281 need to negotiate a variety of different parameters. 283 The purpose of this document is to define a mechanism that enables 284 SDP to provide limited support for indicating capabilities and their 285 associated potential configurations, and negotiate the use of those 286 potential configurations as actual configurations. It is not the 287 intent to provide a full-fledged capability indication and 288 negotiation mechanism along the lines of SDPng or ITU-T H.245. 289 Instead, the focus is on addressing a set of well-known real-life 290 limitations. More specifically, the solution provided in this 291 document provides a general SDP Capability Negotiation framework 292 that is backwards compatible with existing SDP. It also defines 293 specifically how to provide attributes and transport protocols as 294 capabilities and negotiate them using the framework. Extensions for 295 other types of capabilities (e.g. media types and formats) may be 296 provided in other documents. 298 As mentioned above, SDP is used by several protocols, and hence the 299 mechanism should be usable by all of these. One particularly 300 important protocol for this problem is the Session Initiation 301 Protocol (SIP) [RFC3261]. SIP uses the offer/answer model [RFC3264] 302 (which is not specific to SIP) to negotiate sessions and hence the 303 mechanism defined here provides the offer/answer procedures to use 304 for the capability negotiation framework. 306 The rest of the document is structured as follows. In Section 3. we 307 present the SDP Capability Negotiation solution, which consists of 308 new SDP attributes and associated offer/answer procedures. In 309 Section 4. we provide examples illustrating its use and in Section 310 5. we provide the security considerations. 312 2. Conventions used in this document 314 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 315 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 316 document are to be interpreted as described in [RFC2119]. 318 3. SDP Capability Negotiation Solution 320 In this section we first present the conceptual model behind the SDP 321 capability negotiation framework followed by an overview of the SDP 322 Capability Negotiation solution. We then define new SDP attributes 323 for the solution and provide its associated updated offer/answer 324 procedures. 326 3.1. SDP Capability Negotiation Model 328 Our model uses the concepts of 330 o Capabilities 332 o Potential Configurations 334 o Actual Configurations 336 o Negotiation Process 338 as defined in Section 1. Conceptually, we want to offer not just the 339 actual configuration SDP session description (which is done with the 340 offer/answer model defined in [RFC3264]), but the actual 341 configuration SDP session description as well as one or more 342 alternative SDP session descriptions, i.e. potential configurations. 343 The answerer must choose either the actual configuration, or one of 344 the potential configurations, and generate an answer SDP session 345 description based on that. The offerer may need to perform 346 processing on the answer, which depends on the offer that was chosen 347 (actual or potential configuration). The answerer therefore informs 348 the offerer which configuration the answerer chose. The process can 349 be viewed *conceptually* as follows: 351 Offerer Answerer 352 ======= ======== 354 1) Generate offer with actual 355 configuration and alternative 356 potential configurations 357 2) Send offer with all configurations 359 +------------+ 360 | SDP o1 | 361 | (actual | 362 | config | 363 | |-+ Offer 364 +------------+ | -----> 3) Process offered configurations 365 | SDP o2 | in order of preference indicated 366 | (potential | 4) Generate answer based on chosen 367 | config 1) |-+ configuration (e.g. o2), and 368 +------------+ | inform offerer which one was 369 | SDP o3 | chosen 370 | (potential | 371 | config 2) |-+ 372 +------------+ | 373 | SDP ... | 374 : : 376 +------------+ 377 | SDP a1 | 378 Answer | (actual | 379 <----- | config,o2)| 380 | | 381 5) Process answer based on +------------+ 382 the configuration that was 383 chosen (o2), as indicated in 384 the answer 386 The above illustrates the conceptual model: The actual solution uses 387 a single SDP session description, which contains the actual 388 configuration (as with existing SDP session descriptions and the 389 offer/answer model defined in [RFC3264]) and several new attributes 390 and associated procedures, that encode the capabilities and 391 potential configurations. A more accurate depiction of the actual 392 offer SDP session description is therefore as follows: 394 +--------------------+ 395 | SDP o1 | 396 | (actual | 397 | config | 398 | | 399 | +-------------+ | 400 | | capability 1| | 401 | | capability 2| | 402 | | ... | | 403 | +-------------+ | Offer 404 | | -----> 405 | +-------------+ | 406 | | potential | | 407 | | config 1 | | 408 | | potential | | 409 | | config 2 | | 410 | | ... | | 411 | +-------------+ | 412 | | 413 +--------------------+ 415 The above structure is used for two reasons: 417 o Backwards compatibility: As noted above, support for multipart 418 MIME is not ubiquitous. By encoding both capabilities and 419 potential configurations in SDP attributes, we can represent 420 everything in a single SDP session description thereby avoiding 421 any multipart MIME support issues. Furthermore, since unknown SDP 422 attributes are ignored by the SDP recipient, we ensure that 423 entities that do not support the framework simply perform the 424 regular RFC 3264 offer/answer procedures. This provides us with 425 seamless backwards compatibility. 427 o Message size efficiency: When we have multiple media streams, 428 each of which may potentially use two or more different transport 429 protocols with a variety of different associated parameters, the 430 number of potential configurations can be large. If each possible 431 alternative is represented as a complete SDP session description 432 in an offer, we can easily end up with large messages. By 433 providing a more compact encoding, we get more efficient message 434 sizes. 436 In the next section, we describe the exact structure and specific 437 SDP parameters used to represent this. 439 3.2. Solution Overview 441 The solution consists of the following: 443 o Two new SDP attributes to support extensions to the framework 444 itself as follows: 446 o A new attribute ("a=csup") that lists the supported base 447 (optionally) and any supported extension options to the 448 framework. 450 o A new attribute ("a=creq") that lists the extensions to the 451 framework that are required to be supported by the entity 452 receiving the SDP session description in order to do 453 capability negotiation. 455 o Two new SDP attributes used to express capabilities as follows 456 (additional attributes can be defined as extensions): 458 o A new attribute ("a=acap") that defines how to list an 459 attribute name and its associated value (if any) as a 460 capability. 462 o A new attribute ("a=tcap") that defines how to list transport 463 protocols (e.g. "RTP/AVP") as capabilities. 465 o Two new SDP attributes to negotiate configurations as follows: 467 o A new attribute ("a=pcfg") that lists potential 468 configurations supported. This is done by reference to the 469 capabilities from the SDP session description in question. 470 Extension capabilities can be defined and referenced in the 471 potential configurations. Alternative potential 472 configurations have an explicit ordering associated with 473 them. Also, potential configurations are by default preferred 474 over the actual configuration included in the "m=" line and 475 its associated parameters. 477 This preference order was chosen to provide maximum 478 backwards compatibility for the capability negotiation 479 framework and the possible values offered for a session. 480 For example, an entity that wants to establish a secure 481 RTP media stream but is willing to accept a plain RTP 482 media stream (assumed to be the least common denominator 483 for most endpoints), can offer plain RTP in the actual 484 configuration and use the capability negotiation 485 extensions to indicate the preference for secure RTP. 486 Entities that do not support the capability negotiation 487 extensions or secure RTP will then default to plain RTP. 489 o A new attribute ("a=acfg") to be used in an answer SDP 490 session description. The attribute identifies a potential 491 configuration from an offer SDP session description which was 492 used as an actual configuration to form the answer SDP 493 session description. Extension capabilities can be included 494 as well. 496 o Extensions to the offer/answer model that allow for capabilities 497 and potential configurations to be included in an offer. 498 Capabilities can be provided at the session level and the media 499 level. Potential configurations can be included only at the media 500 level, where they constitute alternative offers that may be 501 accepted by the answerer instead of the actual configuration(s) 502 included in the "m=" line(s) and associated parameters. The 503 mechanisms defined in this document enable potential 504 configurations to change the transport protocol, add new 505 attributes as well as remove all existing attributes from the 506 actual configuration. The answerer indicates which (if any) of 507 the potential configurations it used to form the answer by 508 including the actual configuration attribute ("a=acfg") in the 509 answer. Capabilities may be included in answers as well, where 510 they can aid in guiding a subsequent new offer. 512 The mechanism is illustrated by the offer/answer exchange below, 513 where Alice sends an offer to Bob: 515 Alice Bob 517 | (1) Offer (SRTP and RTP) | 518 |--------------------------------->| 519 | | 520 | (2) Answer (SRTP) | 521 |<---------------------------------| 522 | | 523 | (3) Offer (SRTP) | 524 |--------------------------------->| 525 | | 526 | (4) Answer (SRTP) | 527 |<---------------------------------| 528 | | 530 Alice's offer includes RTP and SRTP as alternatives, where RTP is 531 the default (actual configuration), but SRTP is the preferred one 532 (potential configuration): 534 v=0 535 o=- 25678 753849 IN IP4 192.0.2.1 536 s= 537 c=IN IP4 192.0.2.1 538 t=0 0 539 m=audio 53456 RTP/AVP 0 18 540 a=tcap:1 RTP/SAVP 541 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 542 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 543 a=pcfg:1 t=1 a=1 545 The "m=" line indicates that Alice is offering to use plain RTP with 546 PCMU or G.729. The capabilities are provided by the "a=tcap" and 547 "a=acap" attributes. The transport capability attribute ("a=tcap") 548 indicates that secure RTP under the AVP profile ("RTP/SAVP") is 549 supported with an associated transport capability handle of 1. The 550 "acap" attribute provides an attribute capability with a handle of 551 1. The attribute capability is a "crypto" attribute, which provides 552 the keying material for SRTP using SDP security descriptions 553 [RFC4568]. The "a=pcfg" attribute provides the potential 554 configuration included in the offer by reference to the capability 555 parameters. One alternative is provided; it has a configuration 556 number of 1 and it consists of transport protocol capability 1 557 (i.e., the RTP/SAVP profile - secure RTP), and the attribute 558 capability 1 (i.e., the crypto attribute provided). Potential 559 configurations are preferred over the actual configuration included 560 in the offer SDP session description, and hence Alice is expressing 561 a preference for using secure RTP. 563 Bob receives the SDP session description offer from Alice. Bob 564 supports SRTP and the SDP Capability Negotiation framework, and 565 hence he accepts the (preferred) potential configuration for Secure 566 RTP provided by Alice and generates the following answer SDP session 567 description: 569 v=0 570 o=- 24351 621814 IN IP4 192.0.2.2 571 s= 572 c=IN IP4 192.0.2.2 573 t=0 0 574 m=audio 54568 RTP/SAVP 0 18 575 a=crypto:1 AES_CM_128_HMAC_SHA1_80 576 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 577 a=acfg:1 t=1 a=1 579 Bob includes the "a=acfg" attribute in the answer to inform Alice 580 that he based his answer on an offer using potential configuration 1 581 with transport protocol capability 1 and attribute capability 1 from 582 the offer SDP session description (i.e., the RTP/SAVP profile using 583 the keying material provided). Bob also includes his keying 584 material in a "crypto" attribute. If Bob supported one or more 585 extensions to the capability negotiation framework, he would have 586 included option tags for those in the answer as well (in an "a=csup" 587 attribute). 589 When Alice receives Bob's answer, session negotiation has completed, 590 however Alice nevertheless generates a new offer using the 591 negotiated configuration as the actual configuration. This is done 592 purely to assist any intermediaries that may reside between Alice 593 and Bob but do not support the SDP Capability Negotiation framework, 594 and hence may not understand the negotiation that just took place. 596 Alice's updated offer includes only SRTP, and it is not using the 597 SDP Capability Negotiation framework (Alice could have included the 598 capabilities as well is she wanted to): 600 v=0 601 o=- 25678 753850 IN IP4 192.0.2.1 602 s= 603 c=IN IP4 192.0.2.1 604 t=0 0 605 m=audio 53456 RTP/SAVP 0 18 606 a=crypto:1 AES_CM_128_HMAC_SHA1_80 607 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 609 The "m=" line now indicates that Alice is offering to use secure RTP 610 with PCMU or G.729. The "crypto" attribute, which provides the SRTP 611 keying material, is included with the same value again. 613 Bob receives the SDP session description offer from Alice, which he 614 accepts, and then generates an answer to Alice: 616 v=0 617 o=- 24351 621815 IN IP4 192.0.2.2 618 s= 619 c=IN IP4 192.0.2.2 620 t=0 0 621 m=audio 54568 RTP/SAVP 0 18 622 a=crypto:1 AES_CM_128_HMAC_SHA1_80 623 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 625 Bob includes the same crypto attribute as before, and the session 626 proceeds without change. Although Bob did not include any 627 capabilities in his answer, he could have done so if he wanted to. 629 Note that in this particular example, the answerer supported the 630 capability negotiation extensions defined here. Had he not, he would 631 simply have ignored the new attributes and accepted the (actual 632 configuration) offer to use normal RTP. In that case, the following 633 answer would have been generated instead: 635 v=0 636 o=- 24351 621814 IN IP4 192.0.2.2 637 s= 638 c=IN IP4 192.0.2.2 639 t=0 0 640 m=audio 54568 RTP/AVP 0 18 642 3.3. Version and Extension Indication Attributes 644 In this section, we present the new attributes associated with 645 indicating the SDP Capability Negotiation extensions supported and 646 required. 648 3.3.1. Supported Capability Negotiation Extensions Attribute 650 The SDP Capability Negotiation solution allows for capability 651 negotiation extensions to be defined. Associated with each such 652 extension is an option tag that identifies the extension in 653 question. Option-tags MUST be registered with IANA per the 654 procedures defined in Section 6.2. 656 The Supported Capability Negotiation Extensions attribute ("a=csup") 657 contains a comma-separated list of option tags identifying the SDP 658 Capability Negotiation extensions supported by the entity that 659 generated the SDP session description. The attribute can be provided 660 at the session-level and the media-level, and it is defined as 661 follows: 663 a=csup: 665 RFC 4566, Section 9, provides the ABNF [RFC5234] for SDP attributes. 666 The "csup" attribute adheres to the RFC 4566 "attribute" production, 667 with an att-value defined as follows: 669 att-value = option-tag-list 670 option-tag-list = option-tag *("," option-tag) 671 option-tag = token ; defined in [RFC4566] 673 A special base option tag with a value of "cap-v0" is defined for 674 the basic SDP Capability Negotiation framework defined in this 675 document. Entities can use this option tag with the "a=csup" 676 attribute to indicate support for the SDP Capability Negotiation 677 framework specified in this document. Please note that white space 678 is not allowed in this rule. 680 The following examples illustrate use of the "a=csup" attribute with 681 the "cap-v0" option tag and two hypothetical option tags, "foo" and 682 "bar" (note the lack of white space): 684 a=csup:cap-v0 686 a=csup:foo 688 a=csup:bar 690 a=csup:cap-v0,foo,bar 692 The "a=csup" attribute can be provided at the session and the media- 693 level. When provided at the session-level, it applies to the entire 694 SDP session description. When provided at the media-level, it 695 applies only to the media description in question (option-tags 696 provided at the session level apply as well). There MUST NOT be more 697 than one "a=csup" attribute at the session-level and one at the 698 media-level (one per media description in the latter case). 700 Whenever an entity that supports one or more extensions to the SDP 701 Capability Negotiation framework generates an SDP session 702 description, it SHOULD include the "a=csup" attribute with the 703 option tags for the extensions it supports at the session and/or 704 media-level, unless those option tags are already provided in one or 705 more "a=creq" attribute (see Section 3.3.2. ) at the relevant 706 levels. Inclusion of the base option tag is OPTIONAL; support for 707 the base framework can be inferred from presence of the "a=pcfg" 708 attribute defined in Section 3.5.1. 710 Use of the base option tag may still be useful in some scenarios, 711 e.g. when using SIP OPTIONS [RFC3261] or generating an answer to 712 an offer that did not use the SDP Capability Negotiation 713 framework. 715 3.3.2. Required Capability Negotiation Extensions Attribute 717 The Required Capability Negotiation Extensions attribute ("a=creq") 718 contains a comma-separated list of option tags (see Section 3.3.1. ) 719 specifying the SDP Capability Negotiation extensions that MUST be 720 supported by the entity receiving the SDP session description, in 721 order for that entity to properly process the SDP Capability 722 Negotiation attributes and associated procedures. There is no need 723 to include the base option-tag ("cap-v0") with the "creq" attribute, 724 since any entity that supports the "creq" attribute in the first 725 place also supports the base option-tag. Still, it is permissible to 726 do so. 728 Such functionality may be important if a future version of the 729 capability negotiation framework were not backwards compatible. 731 The attribute can be provided at the session-level and the media- 732 level, and it is defined as follows: 734 a=creq: 736 The "creq" attribute adheres to the RFC 4566 "attribute" production, 737 with an att-value defined as follows: 739 att-value = option-tag-list 741 The following examples illustrate use of the "a=creq" attribute with 742 the "cap-v0" base option tag and two hypothetical option tags, "foo" 743 and "bar" (note the lack of white space): 745 a=creq:cap-v0 747 a=creq:foo 749 a=creq:bar 751 a=creq:cap-v0,foo,bar 753 The "a=creq" attribute can be provided at the session and the media- 754 level. When provided at the session-level, it applies to the entire 755 SDP session description. When provided at the media-level, it 756 applies only to the media description in question (required option 757 tags provided at the session level apply as well). There MUST NOT be 758 more than one "a=creq" attribute at the session-level and one 759 "a=creq" attribute at the media-level (one per media description in 760 the latter case). 762 When an entity generates an SDP session description and it requires 763 the recipient of that SDP session description to support one or more 764 SDP Capability Negotiation extensions (except for the base) at the 765 session or media level in order to properly process the SDP 766 Capability Negotiation, the "a=creq" attribute MUST be included with 767 option-tags that identify the required extensions at the session 768 and/or media level. If support for an extension is needed only in 769 one or more specific potential configurations, the potential 770 configuration provides a way to indicate that instead (see Section 771 3.5.1. ). Support for the basic negotiation framework is implied by 772 the presence of an "a=pcfg" attribute (see Section 3.5.1. ) and 773 hence it is not required to include the "a=creq" attribute with the 774 base option-tag ("cap-v0"). 776 A recipient that receives an SDP session description and does not 777 support one or more of the required extensions listed in a "creq" 778 attribute MUST NOT perform the SDP Capability Negotiation defined in 779 this document; instead the recipient MUST proceed as if the SDP 780 Capability Negotiation attributes were not included in the first 781 place, i.e. the capability negotiation attributes are ignored. In 782 that case, if the SDP session description recipient is an SDP 783 answerer [RFC3264], the recipient SHOULD include a "csup" attribute 784 in the resulting SDP session description answer listing the SDP 785 Capability Negotiation extensions it actually supports. 787 This ensures that introduction of the SDP Capability Negotiation 788 mechanism by itself does not lead to session failures 790 For non-supported extensions provided at the session-level, this 791 implies that SDP Capability Negotiation MUST NOT be performed at 792 all. For non-supported extensions at the media-level, this implies 793 that SDP Capability Negotiation MUST NOT be performed for the media 794 stream in question. 796 An entity that does not support the SDP Capability Negotiation 797 framework at all, will ignore these attributes (as well as the 798 other SDP Capability Negotiation attributes) and not perform any 799 SDP Capability Negotiation in the first place. 801 3.4. Capability Attributes 803 In this section, we present the new attributes associated with 804 indicating the capabilities for use by the SDP Capability 805 Negotiation. 807 3.4.1. Attribute Capability Attribute 809 Attributes and their associated values can be expressed as 810 capabilities by use of a new attribute capability attribute 811 ("a=acap"), which is defined as follows: 813 a=acap: 815 where is an integer between 1 and 2^31-1 (both 816 included) used to number the attribute capability and is 817 an attribute ("a=") in its "" or :" 818 form, i.e., excluding the "a=" part (see [RFC4566]). The attribute 819 can be provided at the session-level and the media-level. 821 The "acap" attribute adheres to the RFC 4566 "attribute" production, 822 with an att-value defined as follows: 824 att-value = att-cap-num 1*WSP att-par 825 att-cap-num = 1*10(DIGIT) ;defined in [RFC5234] 826 att-par = attribute ;defined in [RFC4566] 828 Note that white space is not permitted before the att-cap-num. 830 When the attribute capability contains a session-level attribute, 831 that "acap" attribute can only be provided at the session level. 832 Conversely, media level attributes can be provided in attribute 833 capabilities at either the media level or session-level. The base 834 SDP Capability Negotiation framework however only defines procedures 835 for use of media-level attribute capabilities at the media level. 836 Implementations that conform only to the base framework MUST NOT 837 generate media-level attribute capabilities at the session-level, 838 however extensions may change this (see, e.g., [SDPMedCap] for one 839 such extension) and hence all implementations MUST still be prepared 840 to receive such capabilities (see Section 3.6.2. for processing 841 rules). 843 Each occurrence of the "acap" attribute in the entire session 844 description MUST use a different value of . 845 Consecutive numbering of the values is not required. 847 There is a need to be able to reference both session-level and 848 media-level attributes in potential configurations at the media 849 level, and this provides for a simple solution to avoiding overlap 850 between the references (handles) to each attribute capability. 852 The values provided are independent of similar values provided for other types of capabilities, i.e., they 854 form a separate name-space for attribute capabilities. 856 The following examples illustrate use of the "acap" attribute: 858 a=acap:1 ptime:20 860 a=acap:2 ptime:30 862 a=acap:3 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAA 863 AAAGEEoo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0 864 JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUO 865 SrzKTAv9zV 867 a=acap:4 crypto:1 AES_CM_128_HMAC_SHA1_32 868 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 870 The first two attribute capabilities provide attribute values for 871 the ptime attribute. The third provides SRTP parameters by using 872 MIKEY [RFC3830] with the key-mgmt attribute [RFC4567]. The fourth 873 provides SRTP parameters by use of security descriptions with the 874 crypto attribute [RFC4568]. Note that the line-wrapping and new- 875 lines in example three and four are provided for formatting reasons 876 only - they are not permitted in actual SDP session descriptions. 878 Readers familiar with RFC 3407 may notice the similarity between 879 the RFC 3407 "cpar" attribute and the above. There are however a 880 couple of important differences, notably that the "acap" attribute 881 contains a handle that enables referencing it and it furthermore 882 supports only attributes (the "cpar" attribute defined in RFC 3407 883 supports bandwidth information as well). The "acap" attribute also 884 is not automatically associated with any particular capabilities. 885 See Section 3.14. for the relationship to RFC 3407. 887 Attribute capabilities MUST NOT embed any capability negotiation 888 parameters. This restriction applies to all the capability 889 negotiation parameters defined in this document ("csup", "creq", 890 "acap", "tcap", "pcfg", and "acfg") as well as any capability 891 negotiation extensions defined. The following examples are thus 892 invalid attribute capabilities and MUST NOT be used: 894 a=acap:1 acap:2 foo:a ;Not allowed to embed "acap" 896 a=acap:2 a=pcfg:1 t=1 a=1 ;Not allowed to embed "pcfg" 898 The reason for this restriction is to avoid overly complex 899 processing rules resulting from the expansion of such capabilities 900 into potential configurations (see Section 3.6.2. for further 901 details). 903 3.4.2. Transport Protocol Capability Attribute 905 Transport Protocols can be expressed as capabilities by use of a new 906 Transport Protocol Capability attribute ("a=tcap") defined as 907 follows: 909 a=tcap: 911 where is an integer between 1 and 2^31-1 (both 912 included) used to number the transport address capability for later 913 reference, and is one or more , separated by 914 white space, as defined in the SDP "m=" line. The attribute can be 915 provided at the session-level and the media-level. 917 The "tcap" attribute adheres to the RFC 4566 "attribute" production, 918 with an att-value defined as follows: 920 att-value = trpr-cap-num 1*WSP proto-list 921 trpr-cap-num = 1*10(DIGIT) ;defined in [RFC5234] 922 proto-list = proto *(1*WSP proto) ;defined in [RFC4566] 924 Note that white space is not permitted before the trpr-cap-num. 926 The "tcap" attribute can be provided at the session-level and the 927 media-level. There MUST NOT be more than one "a=tcap" attribute at 928 the session-level and one at the media-level (one per media 929 description in the latter case). Each occurrence of the "tcap" 930 attribute in the entire session description MUST use a different 931 value of . When multiple values are provided, 932 the first one is associated with the value , the 933 second one with the value one higher, etc. There MUST NOT be any 934 capability number overlap between different "tcap" attributes in the 935 entire SDP session description. The values provided 936 are independent of similar values provided for other 937 capability attributes, i.e., they form a separate name-space for 938 transport protocol capabilities. Consecutive numbering of the values in different "tcap" attributes is not required. 941 Below, we provide examples of the "a=tcap" attribute: 943 a=tcap:1 RTP/AVP 945 a=tcap:2 RTP/AVPF 947 a=tcap:3 RTP/SAVP RTP/SAVPF 949 a=tcap:5 UDP/TLS/RTP/SAVP 951 The first one provides a capability for the "RTP/AVP" profile 952 defined in [RFC3551] and the second one provides a capability for 953 the RTP with RTCP-Based Feedback profile defined in [RFC4585]. The 954 third one provides capabilities for the "RTP/SAVP" (transport 955 capability number 3) and "RTP/SAVPF" profiles (transport protocol 956 capability number 4). The last one provides capabilities for 957 "UDP/TLS/RTP/SAVP", i.e. DTLS-SRTP [DTLS-SRTP](transport capability 958 number 5). 960 The "tcap" attribute by itself can only specify transport protocols 961 as defined by in [RFC4566], however full specification of a 962 media stream requires further qualification of the transport 963 protocol by one or more media format descriptions, which themselves 964 often depend on the transport protocol. As an example, [RFC3551] 965 defines the "RTP/AVP" transport for use with audio and video codecs 966 (media formats), whereas [RFC4145] defines the "TCP" transport which 967 for example may be used to negotiate T.38 fax ("image/t38"), etc. In 968 a non-SDP context, some media formats could be viewed as transports 969 themselves (e.g. T.38) however in the context of SDP and SDP 970 Capability Negotiation, they are not. If capability negotiation is 971 required for such media formats, they MUST all either be valid under 972 the transport protocol indicated in the "m=" line included for the 973 media stream description, or a suitable extension must be used, e.g. 974 SDP Media Capabilities [SDPMedCap]. 976 The ability to use a particular transport protocol is inherently 977 implied by including it in the "m=" line, regardless of whether it 978 is provided in a "tcap" attribute or not. However, if a potential 979 configuration needs to reference that transport protocol as a 980 capability, the transport protocol MUST be included explicitly in a 981 "tcap" attribute. 983 This may seem redundant (and indeed it is from the offerer's point 984 of view), however it is done to protect against intermediaries 985 (e.g. middle-boxes) that may modify "m=" lines while passing 986 unknown attributes through. If an implicit transport capability 987 were used instead (e.g. a reserved transport capability number 988 could be used to refer to the transport protocol in the "m=" 989 line), and an intermediary were to modify the transport protocol 990 in the "m=" line (e.g. to translate between plain RTP and secure 991 RTP), then the potential configuration referencing that implicit 992 transport capability may no longer be correct. With explicit 993 capabilities, we avoid this pitfall; however, the potential 994 configuration preference (see Section 3.5.1. ) may not reflect 995 that of the intermediary (which some may view as a feature). 997 Note that a transport protocol capability may be provided, 998 irrespective of whether it is referenced in a potential 999 configuration or not (just like any other capability). 1001 3.4.3. Extension Capability Attributes 1003 The SDP Capability Negotiation framework allows for new types of 1004 capabilities to be defined as extensions and used with the general 1005 capability negotiation framework. The syntax and semantics of such 1006 new capability attributes are not defined here, however in order to 1007 be used with potential configurations, they SHOULD allow for a 1008 numeric handle to be associated with each capability. This handle 1009 can be used as a reference within the potential and actual 1010 configuration attributes (see Section 3.5.1. and 3.5.2. ). The 1011 definition of such extension capability attributes MUST also state 1012 whether they can be applied at the session-level, media-level, or 1013 both. Note that extensions can have option tags defined for them, 1014 and option tags MUST be registered with the IANA in accordance with 1015 the procedures specified in Section 6.2. 1017 Extension capabilities SHOULD NOT embed any capability negotiation 1018 parameters. This applies to all the capability negotiation 1019 parameters defined in this document as well as any extensions 1020 defined. The reason for this restriction is to avoid overly complex 1021 processing rules resulting from the expansion of such capabilities 1022 into potential configurations (see Section 3.6.2. for further 1023 details). If an extension does not follow the above "SHOULD NOT" 1024 recommendation, the extension MUST provide a careful analysis of why 1025 such behavior is both necessary and safe. 1027 3.5. Configuration Attributes 1029 3.5.1. Potential Configuration Attribute 1031 Potential Configurations can be expressed by use of a new Potential 1032 Configuration Attribute ("a=pcfg") defined as follows: 1034 a=pcfg: [] 1036 where is an integer between 1 and 2^31-1 (both 1037 included). The attribute can be provided only at the media-level. 1039 The "pcfg" attribute adheres to the RFC 4566 "attribute" production, 1040 with an att-value defined as follows: 1042 att-value = config-number [1*WSP pot-cfg-list] 1043 config-number = 1*10(DIGIT) ;defined in [RFC5234] 1044 pot-cfg-list = pot-config *(1*WSP pot-config) 1045 pot-config = attribute-config-list / 1046 transport-protocol-config-list / 1047 extension-config-list 1049 The missing productions are defined below. Note that white space is 1050 not permitted before the config-number. 1052 The potential configuration attribute can be provided only at the 1053 media-level and there can be multiple instances of it within a given 1054 media description. The attribute includes a configuration number, 1055 which is an integer between 1 and 2^31-1 (both included). The 1056 configuration number MUST be unique within the media description 1057 (i.e., it has only media level scope). The configuration number also 1058 indicates the relative preference of potential configurations; lower 1059 numbers are preferred over higher numbers. Consecutive numbering of 1060 the configuration numbers in different "pcfg" attributes in a media 1061 description is not required. 1063 A potential configuration list is normally provided after the 1064 configuration number. When the potential configuration list is 1065 omitted, the potential configuration equals the actual 1066 configuration. The potential configuration list contains one or more 1067 of attribute, transport and extension configuration lists. A 1068 potential configuration may for example include attribute 1069 capabilities and transport capabilities, transport capabilities 1070 only, or some other combination of capabilities. If transport 1071 capabilities are not included in a potential configuration, the 1072 default transport for that media stream is used. 1074 The potential configuration lists generally reference one or more 1075 capabilities (extension configuration lists MAY use a different 1076 format). Those capabilities are (conceptually) used to construct a 1077 new internal version of the SDP session description by use of purely 1078 syntactic add and (possibly) delete operations on the original SDP 1079 session description (actual configuration). This provides an 1080 alternative potential configuration SDP session description that can 1081 be used by conventional SDP and offer/answer procedures if selected. 1083 This document defines attribute configuration lists and transport 1084 protocol configuration lists. Each of these MUST NOT be present 1085 more than once in a particular potential configuration attribute. 1086 Attribute capabilities referenced by the attribute configuration 1087 list (if included) are added to the actual configuration, whereas a 1088 transport capability referenced by the transport protocol 1089 configuration list (if included) replaces the default transport 1090 protocol from the actual configuration. Extension configuration 1091 lists can be included as well. There can be more than one extension 1092 configuration list, however each particular extension MUST NOT be 1093 present more than once in a given "a=pcfg" attribute. Together, the 1094 various configuration lists define a potential configuration. 1096 There can be multiple potential configurations in a media 1097 description. Each of these indicates not only a willingness, but in 1098 fact a desire to use the potential configuration. 1100 The example SDP session description below contains two potential 1101 configurations: 1103 v=0 1104 o=- 25678 753849 IN IP4 192.0.2.1 1105 s= 1106 c=IN IP4 192.0.2.1 1107 t=0 0 1108 m=audio 53456 RTP/AVP 0 18 1109 a=tcap:1 RTP/SAVP RTP/SAVPF 1110 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 1111 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 1112 a=pcfg:1 t=1 a=1 1113 a=pcfg:2 t=2 a=1 1115 Potential configuration 1 contains a transport protocol 1116 configuration list that references transport capability 1 1117 ("RTP/SAVP") and an attribute configuration list that references 1118 attribute capability 1 ("a=crypto:..."). Potential configuration 2 1119 contains a transport protocol configuration list that references 1120 transport capability 2 ("RTP/SAVPF") and an attribute configuration 1121 list that references attribute capability 1 ("a=crypto:..."). 1123 Attribute capabilities are used in a potential configuration by use 1124 of the attribute-config-list parameter, which is defined by the 1125 following ABNF: 1127 attribute-config-list = "a=" delete-attributes 1128 attribute-config-list =/ "a=" [delete-attributes ":"] 1129 mo-att-cap-list *(BAR mo-att-cap-list) 1131 delete-attributes = DELETE ( "m" ; media attributes 1132 / "s" ; session attributes 1133 / "ms" ) ; media and session attributes 1135 mo-att-cap-list = mandatory-optional-att-cap-list / 1136 mandatory-att-cap-list / 1137 optional-att-cap-list 1139 mandatory-optional-att-cap-list = mandatory-att-cap-list 1140 "," optional-att-cap-list 1141 mandatory-att-cap-list = att-cap-list 1142 optional-att-cap-list = "[" att-cap-list "]" 1144 att-cap-list = att-cap-num *("," att-cap-num) 1145 att-cap-num = 1*10(DIGIT) ;defined in [RFC5234] 1146 BAR = "|" 1147 DELETE = "-" 1149 Note that white space is not permitted within the attribute-config- 1150 list rule. 1152 Each attribute configuration list can optionally begin with 1153 instructions for how to handle attributes that are part of the 1154 actual configuration SDP session description (i.e., the "a=" lines 1155 present in the original SDP session description). By default, such 1156 attributes will remain as part of the potential configuration in 1157 question. However, if delete-attributes indicates "-m", then all 1158 attribute lines within the media description in question will be 1159 deleted in the resulting potential configuration SDP session 1160 description (i.e., all "a=" lines under the "m=" line in question). 1161 If delete-attributes indicates "-s", then all attribute lines at the 1162 session-level will be deleted (i.e., all "a=" lines before the first 1163 "m=" line). If delete-attributes indicates "-ms", then all attribute 1164 lines within this media description ("m=" line) and all attribute 1165 lines at the session-level will be deleted. 1167 The attribute capability list comes next (if included). It contains 1168 one or more alternative lists of attribute capabilities. The 1169 alternative attribute capability lists are separated by a vertical 1170 bar ("|"), and each list contains one or more attribute capabilities 1171 separated by commas (","). The attribute capabilities are either 1172 mandatory or optional. Mandatory attribute capabilities MUST be 1173 supported in order to use the potential configuration, whereas 1174 optional attribute capabilities MAY be supported in order to use the 1175 potential configuration. 1177 Within each attribute capability list, all the mandatory attribute 1178 capabilities (if any) are listed first, and all the optional 1179 attribute capabilities (if any) are listed last. The optional 1180 attribute capabilities are contained within a pair of square 1181 brackets ("[" and "]"). Each attribute capability is merely an 1182 attribute capability number (att-cap-num) that identifies a 1183 particular attribute capability by referring to attribute capability 1184 numbers defined above and hence MUST be between 1 and 2^31-1 (both 1185 included). The following example illustrates the above: 1187 a=pcfg:1 a=-m:1,2,[3,4]|1,7,[5] 1189 where 1191 o "a=-m:1,2,[3,4]|1,7,[5]" is the attribute configuration list 1193 o "-m" indicates to delete all attributes from the media 1194 description of the actual configuration 1196 o "1,2,[3,4]" and "1,7,[5]" are both attribute capability lists. 1197 The two lists are alternatives, since they are separated by a 1198 vertical bar above 1200 o "1", "2" and "7" are mandatory attribute capabilities 1202 o "3", "4" and "5" are optional attribute capabilities 1204 Note that in the example above, we have a single handle ("1") for 1205 the potential configuration(s), but there are actually two different 1206 potential configurations (separated by a vertical bar). This is done 1207 for message size efficiency reasons, which is especially important 1208 when we add other types of capabilities to the potential 1209 configuration. If there is a need to provide a unique handle for 1210 each, then separate "a=pcfg" attributes with different handles MUST 1211 be used instead. 1213 Each referenced attribute capability in the potential configuration 1214 will result in the corresponding attribute name and its associated 1215 value (contained inside the attribute capability) being added to the 1216 resulting potential configuration SDP session description. 1218 Alternative attribute capability lists are separated by a vertical 1219 bar ("|"), the scope of which extends to the next alternative (i.e., 1220 "," has higher precedence than "|"). The alternatives are ordered by 1221 preference with the most preferred listed first. In order for a 1222 recipient of the SDP session description (e.g., an answerer 1223 receiving this in an offer) to use this potential configuration, 1224 exactly one of the alternative lists MUST be selected in its 1225 entirety. This requires that all mandatory attribute capabilities 1226 referenced by the potential configuration are supported with the 1227 attribute values provided. 1229 Transport protocol configuration lists are included in a potential 1230 configuration by use of the transport-protocol-config-list 1231 parameter, which is defined by the following ABNF: 1233 transport-protocol-config-list = 1234 "t=" trpr-cap-num *(BAR trpr-cap-num) 1235 trpr-cap-num = 1*10(DIGIT) ; defined in [RFC5234] 1237 Note that white space is not permitted within this rule. 1239 The trpr-cap-num refers to transport protocol capability numbers 1240 defined above and hence MUST be between 1 and 2^31-1 (both 1241 included). Alternative transport protocol capabilities are separated 1242 by a vertical bar ("|"). The alternatives are ordered by preference 1243 with the most preferred listed first. If there are no transport 1244 protocol capabilities included in a potential configuration at the 1245 media level, the transport protocol information from the associated 1246 "m=" line MUST be used. In order for a recipient of the SDP session 1247 description (e.g., an answerer receiving this in an offer) to use 1248 this potential configuration, exactly one of the alternatives MUST 1249 be selected. This requires that the transport protocol in question 1250 is supported. 1252 In the presence of intermediaries (the existence of which may not 1253 be known), care should be taken with assuming that the transport 1254 protocol in the "m=" line will not be modified by an intermediary. 1255 Use of an explicit transport protocol capability will guard 1256 against capability negotiation implications of that. 1258 Extension capabilities can be included in a potential configuration 1259 as well by use of extension configuration lists. Extension 1260 configuration lists MUST adhere to the following ABNF: 1262 extension-config-list = ["+"] ext-cap-name "=" ext-cap-list 1263 ext-cap-name = 1*(ALPHA / DIGIT) 1264 ext-cap-list = 1*VCHAR ; defined in [RFC5234] 1266 Note that white space is not permitted within this rule. 1268 The ext-cap-name refers to the name of the extension capability and 1269 the ext-cap-list is here merely defined as a sequence of visible 1270 characters. The actual extension supported MUST refine both of these 1271 further. For extension capabilities that merely need to be 1272 referenced by a capability number, it is RECOMMENDED to follow a 1273 structure similar to what has been specified above. Unsupported or 1274 unknown potential extension configuration lists in a potential 1275 configuration attribute MUST be ignored, unless they are prefixed 1276 with the plus ("+") sign, which indicates that the extension is 1277 mandatory and MUST be supported in order to use that potential 1278 configuration. 1280 The "creq" attribute and its associated rules can be used to 1281 ensure that required extensions are supported in the first place. 1283 Extension configuration lists define new potential configuration 1284 parameters and hence they MUST be registered with IANA per the 1285 procedures defined in Section 6.3. 1287 Potential configuration attributes can be provided only at the media 1288 level, however it is possible to reference capabilities provided at 1289 either the session or media level. There are certain semantic rules 1290 and restrictions associated with this: 1292 A (media level) potential configuration attribute in a given media 1293 description MUST NOT reference a media-level capability provided in 1294 a different media description; doing so invalidates that potential 1295 configuration (note that a potential configuration attribute can 1296 contain more than one potential configuration by use of 1297 alternatives). A potential configuration attribute can however 1298 reference a session-level capability. The semantics of doing so 1299 depends on the type of capability. In the case of transport protocol 1300 capabilities it has no particular implication. In the case of 1301 attribute capabilities however, it does. More specifically, the 1302 attribute name and value (provided within that attribute capability) 1303 will be considered part of the resulting SDP for that particular 1304 configuration at the *session* level. In other words, it will be as- 1305 if that attribute was provided with that value at the session-level 1306 in the first place. As a result, the base SDP Capability Negotiation 1307 framework REQUIRES that potential configurations do not reference 1308 any session-level attribute capabilities that contain media-level 1309 attributes (since that would place a media-level attribute at the 1310 session level). Extensions may modify this behavior, as long as it 1311 is fully backwards compatible with the base specification. 1313 Individual media streams perform capability negotiation 1314 individually, and hence it is possible that one media stream (where 1315 the attribute was part of a potential configuration) chose a 1316 configuration without a session level attribute that was chosen by 1317 another media stream. The session-level attribute however remains 1318 "active" and applies to the entire resulting potential configuration 1319 SDP session description. In theory, this is problematic if one or 1320 more session-level attributes either conflicts with or potentially 1321 interacts with another session-level or media-level attribute in an 1322 undefined manner. In practice, such examples seem to be rare (at 1323 least with the SDP attributes that had been defined at time of 1324 publication of this document). 1326 A related set of problems can occur if we need coordination 1327 between session-level attributes from multiple media streams in 1328 order for a particular functionality to work. The grouping 1329 framework [RFC3388] is an example of this. If we use the SDP 1330 Capability Negotiation framework to select a session-level group 1331 attribute (provided as an attribute capability), and we require 1332 two media descriptions to do this consistently, we could have a 1333 problem. The FEC grouping semantics [RFC4756] is one example where 1334 this in theory could cause problems, however in practice, it is 1335 unclear that there is a significant problem with the grouping 1336 semantics that had been defined at time of publication of this 1337 document. 1339 Resolving the above issues in general requires inter-media stream 1340 constraints and synchronized potential configuration processing; 1341 this would add considerable complexity to the overall solution. In 1342 practice, with the SDP attributes defined at time of publication of 1343 this document, it does not seem to be a significant problem, and 1344 hence the base SDP Capability Negotiation solution does not provide 1345 a solution to this issue. Instead, it is RECOMMENDED that use of 1346 session-level attributes in a potential configuration is avoided 1347 when possible, and when not, that such use is examined closely for 1348 any potential interaction issues. If interaction is possible, the 1349 entity generating the SDP session description SHOULD NOT assume that 1350 well-defined operation will occur at the receiving entity. This 1351 implies that mechanisms which might have such interactions cannot be 1352 used in security critical contexts. 1354 The session-level operation of extension capabilities is undefined: 1355 Consequently, each new session-level extension capability defined 1356 MUST specify the implication of making it part of a configuration at 1357 the media level. 1359 Below, we provide an example of the "a=pcfg" attribute in a complete 1360 media description in order to properly indicate the supporting 1361 attributes: 1363 v=0 1364 o=- 25678 753849 IN IP4 192.0.2.1 1365 s= 1366 c=IN IP4 192.0.2.1 1367 t=0 0 1368 m=audio 53456 RTP/AVPF 0 18 1369 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 1370 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 1371 a=tcap:1 RTP/AVPF RTP/AVP RTP/SAVP RTP/SAVPF 1372 a=pcfg:1 t=4|3 a=1 1373 a=pcfg:8 t=1|2 1375 We have two potential configuration attributes listed here. The 1376 first one (and most preferred, since its configuration number is 1377 "1") indicates that either of the profiles RTP/SAVPF or RTP/SAVP 1378 (specified by the transport protocol capability numbers 4 and 3) can 1379 be supported with attribute capability 1 (the "crypto" attribute); 1380 RTP/SAVPF is preferred over RTP/SAVP since its capability number (4) 1381 is listed first in the preferred potential configuration. Note that 1382 although we have a single potential configuration attribute and 1383 associated handle, we have two potential configurations. 1385 The second potential configuration attribute indicates that the 1386 RTP/AVPF or RTP/AVP profiles can be used, with RTP/AVPF being the 1387 preferred one. This non secure RTP alternative is the less preferred 1388 one since its configuration number is "8". Again, note that we have 1389 two potential configurations here and hence a total of four 1390 potential configurations in the SDP session description above. 1392 3.5.2. Actual Configuration Attribute 1394 The actual configuration attribute identifies which of the potential 1395 configurations from an offer SDP session description was selected 1396 and used as the actual configuration to generate an answer SDP 1397 session description. This is done by including the configuration 1398 number and the configuration lists (if any) from the offer that were 1399 selected and used by the answerer in his offer/answer procedure as 1400 follows: 1402 o A selected attribute configuration MUST include the delete- 1403 attributes and the known and supported parameters from the 1404 selected alternative mo-att-cap-list (i.e., containing all 1405 mandatory and all known and supported optional capability numbers 1406 from the potential configuration). If delete-attributes were not 1407 included in the potential configuration, they will of course not 1408 be present here either. 1410 o A selected transport protocol configuration MUST include the 1411 selected transport protocol capability number. 1413 o A selected potential extension configuration MUST include the 1414 selected extension configuration parameters as specified for that 1415 particular extension. 1417 o When a configuration list contains alternatives (separated by 1418 "|"), the selected configuration only MUST be provided. 1420 Note that the selected configuration number and all selected 1421 capability numbers used in the actual configuration attribute refer 1422 to those from the offer; not the answer. 1424 The answer may for example include capabilities as well to inform 1425 the offerer of the answerers capabilities above and beyond the 1426 negotiated configuration. The actual configuration attribute does 1427 not refer to any of those answer capabilities though. 1429 The Actual Configuration Attribute ("a=acfg") is defined as follows: 1431 a=acfg: [] 1433 where is an integer between 1 and 2^31-1 (both 1434 included) that refers to the selected potential configuration. The 1435 attribute can be provided only at the media-level. 1437 The "acfg" attribute adheres to the RFC 4566 "attribute" production, 1438 with an att-value defined as follows: 1440 att-value = config-number [1*WSP sel-cfg-list] 1441 ;config-number defined in Section 3.5.1. 1442 sel-cfg-list = sel-cfg *(1*WSP sel-cfg) 1443 sel-cfg = sel-attribute-config / 1444 sel-transport-protocol-config / 1445 sel-extension-config 1447 sel-attribute-config = 1448 "a=" [delete-attributes ":"] mo-att-cap-list 1449 ; defined in Section 3.5.1. 1451 sel-transport-protocol-config = 1452 "t=" trpr-cap-num ; defined in Section 3.5.1. 1454 sel-extension-config = 1455 ext-cap-name "=" 1*VCHAR ; defined in Section 3.5.1. 1457 Note that white space is not permitted before the config-number. 1459 The actual configuration ("a=acfg") attribute can be provided only 1460 at the media-level. There MUST NOT be more than one occurrence of an 1461 actual configuration attribute within a given media description. 1463 Below, we provide an example of the "a=acfg" attribute (building on 1464 the previous example with the potential configuration attribute): 1466 v=0 1467 o=- 24351 621814 IN IP4 192.0.2.2 1468 s= 1469 c=IN IP4 192.0.2.2 1470 t=0 0 1471 m=audio 54568 RTP/SAVPF 0 1472 a=crypto:1 AES_CM_128_HMAC_SHA1_32 1473 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 1474 a=acfg:1 t=4 a=1 1476 It indicates that the answerer used an offer consisting of potential 1477 configuration number 1 with transport protocol capability 4 from the 1478 offer (RTP/SAVPF) and attribute capability 1 (the "crypto" 1479 attribute). The answerer includes his own "crypto" attribute as 1480 well. 1482 3.6. Offer/Answer Model Extensions 1484 In this section, we define extensions to the offer/answer model 1485 defined in [RFC3264] to allow for potential configurations to be 1486 included in an offer, where they constitute alternative offers that 1487 may be accepted by the answerer instead of the actual 1488 configuration(s) included in the "m=" line(s). 1490 The procedures defined in the following subsections apply to both 1491 unicast and multicast streams. 1493 3.6.1. Generating the Initial Offer 1495 An offerer that wants to use the SDP Capability Negotiation defined 1496 in this document MUST include the following in the offer: 1498 o Zero or more attribute capability attributes. There MUST be an 1499 attribute capability attribute ("a=acap") as defined in Section 1500 3.4.1. for each attribute name and associated value (if any) that 1501 needs to be indicated as a capability in the offer. Attribute 1502 capabilities may be included irrespective of whether they are 1503 referenced by a potential configuration or not. 1505 Session-level attributes and associated values MUST be provided 1506 in attribute capabilities only at the session-level, whereas 1507 media-level attributes and associated values can be provided in 1508 attribute capabilities at either the media-level or session- 1509 level. Attributes that are allowed at either the session- or 1510 media-level can be provided in attribute capabilities at either 1511 level. 1513 o Zero or more transport protocol capability attributes. There MUST 1514 be transport protocol capabilities as defined in Section 3.4.2. 1515 with values for each transport protocol that needs to be 1516 indicated as a capability in the offer. Transport protocol 1517 capabilities may be included irrespective of whether they are 1518 referenced by a potential configuration or not. 1520 Transport protocol capabilities that apply to multiple media 1521 descriptions SHOULD be provided at the session-level whereas 1522 transport protocol capabilities that apply only to a specific 1523 media description ("m=" line), SHOULD be provided within that 1524 particular media description. In either case, there MUST NOT be 1525 more than a single "a=tcap" attribute at the session-level and a 1526 single "a=tcap" attribute in each media description. 1528 o Zero or more extension capability attributes. There MUST be one 1529 or more extension capability attributes (as outlined in Section 1530 3.4.3. ) for each extension capability that is referenced by a 1531 potential configuration. Extension capability attributes that are 1532 not referenced by a potential configuration can be provided as 1533 well. 1535 o Zero or more potential configuration attributes. There MUST be 1536 one or more potential configuration attributes ("a=pcfg"), as 1537 defined in Section 3.5.1. , in each media description where 1538 alternative potential configurations are to be negotiated. Each 1539 potential configuration attribute MUST adhere to the rules 1540 provided in Section 3.5.1. and the additional rules provided 1541 below. 1543 If the offerer requires support for one or more extensions (besides 1544 the base protocol defined here), then the offerer MUST include one 1545 or more "a=creq" attributes as follows: 1547 o If support for one or more capability negotiation extensions is 1548 required for the entire session description, then option tags for 1549 those extensions MUST be included in a single session-level 1550 "creq" attribute. 1552 o For each media description that requires support for one or more 1553 capability negotiation extensions not listed at the session- 1554 level, a single "creq" attribute containing all the required 1555 extensions for that media description MUST be included within the 1556 media description (in accordance with Section 3.3.2. ). 1558 Note that extensions that only need to be supported by a particular 1559 potential configuration can use the "mandatory" extension prefix 1560 ("+") within the potential configuration (see Section 3.5.1. ). 1562 The offerer SHOULD furthermore include the following: 1564 o A supported capability negotiation extension attribute ("a=csup") 1565 at the session-level and/or media-level as defined in Section 1566 3.3.2. for each capability negotiation extension supported by the 1567 offerer and not included in a corresponding "a=creq" attribute 1568 (i.e., at the session-level or in the same media description). 1569 Option tags provided in a "a=csup" attribute at the session-level 1570 indicate extensions supported for the entire session description, 1571 whereas option tags provided in a "a=csup" attribute in a media 1572 description indicate extensions supported for only that 1573 particular media description. 1575 Capabilities provided in an offer merely indicate what the offerer 1576 is capable of doing. They do not constitute a commitment or even an 1577 indication to use them. In contrast, each potential configuration 1578 constitutes an alternative offer that the offerer would like to use. 1579 The potential configurations MUST be used by the answerer to 1580 negotiate and establish the session. 1582 The offerer MUST include one or more potential configuration 1583 attributes ("a=pcfg") in each media description where the offerer 1584 wants to provide alternative offers (in the form of potential 1585 configurations). Each potential configuration attribute in a given 1586 media description MUST contain a unique configuration number and 1587 zero, one or more potential configuration lists, as described in 1588 Section 3.5.1. Each potential configuration list MUST refer to 1589 capabilities that are provided at the session-level or within that 1590 particular media description; otherwise, the potential configuration 1591 is considered invalid. The base SDP Capability Negotiation framework 1592 REQUIRES that potential configurations do not reference any session- 1593 level attribute capabilities that contain media-level only 1594 attributes, however extensions may modify this behavior, as long as 1595 it is fully backwards compatible with the base specification. 1596 Furthermore, it is RECOMMENDED that potential configurations avoid 1597 use of session-level capabilities whenever possible; refer to 1598 Section 3.5.1. 1600 The current actual configuration is included in the "m=" line (as 1601 defined by [RFC3264]) and any associated parameters for the media 1602 description (e.g., attribute ("a=") and bandwidth ("b=") lines). 1603 Note that the actual configuration is by default the least-preferred 1604 configuration, and hence the answerer will seek to negotiate use of 1605 one of the potential configurations instead. If the offerer wishes a 1606 different preference for the actual configuration, the offerer MUST 1607 include a corresponding potential configuration with the relevant 1608 configuration number (which indicates the relative preference 1609 between potential configurations); this corresponding potential 1610 configuration should simply duplicate the actual configuration. 1612 This can either be done implicitly (by not referencing any 1613 capabilities), or explicitly (by providing and using capabilities 1614 for the transport protocol and all the attributes that are part of 1615 the actual configuration). The latter may help detect 1616 intermediaries that modify the actual configuration but are not 1617 SDP Capability Negotiation aware. 1619 Per [RFC3264], once the offerer generates the offer, he must be 1620 prepared to receive incoming media in accordance with that offer. 1621 That rule applies here as well, but only for the actual 1622 configurations provided in the offer: Media received by the offerer 1623 according to one of the potential configurations MAY be discarded, 1624 until the offerer receives an answer indicating what the actual 1625 selected configuration is. Once that answer is received, incoming 1626 media MUST be processed in accordance with the actual selected 1627 configuration indicated and the answer received (provided the 1628 offer/answer exchange completed successfully). 1630 The above rule assumes that the offerer can determine whether 1631 incoming media adheres to the actual configuration offered or one of 1632 the potential configurations instead; this may not always be the 1633 case. If the offerer wants to ensure he does not play out any 1634 garbage, the offerer SHOULD discard all media received before the 1635 answer SDP session description is received. Conversely, if the 1636 offerer wants to avoid clipping, he SHOULD attempt to play any 1637 incoming media as soon as it is received (at the risk of playing out 1638 garbage). In either case, please note that this document does not 1639 place any requirements on the offerer to process and play media 1640 before answer. For further details, please refer to Section 3.9. 1642 3.6.2. Generating the Answer 1644 When receiving an offer, the answerer MUST check for the presence of 1645 a required capability negotiation extension attribute ("a=creq") 1646 provided at the session level. If one is found, then capability 1647 negotiation MUST be performed. If none is found, then the answerer 1648 MUST check each offered media description for the presence of a 1649 required capability negotiation extension attribute ("a=creq") and 1650 one or more potential configuration attributes ("a=pcfg"). 1651 Capability negotiation MUST be performed for each media description 1652 where either of those is present in accordance with the procedures 1653 described below. 1655 The answerer MUST first ensure that it supports any required 1656 capability negotiation extensions: 1658 o If a session-level "creq" attribute is provided, and it contains 1659 an option-tag that the answerer does not support, then the 1660 answerer MUST NOT use any of the potential configuration 1661 attributes provided for any of the media descriptions. Instead, 1662 the normal offer/answer procedures MUST continue as per 1663 [RFC3264]. Furthermore, the answerer MUST include a session-level 1664 supported capability negotiation extensions attribute ("a=csup") 1665 with option tags for the capability negotiation extensions 1666 supported by the answerer. 1668 o If a media-level "creq" attribute is provided, and it contains an 1669 option tag that the answerer does not support, then the answerer 1670 MUST NOT use any of the potential configuration attributes 1671 provided for that particular media description. Instead, the 1672 offer/answer procedures for that media description MUST continue 1673 as per [RFC3264] (SDP Capability Negotiation is still performed 1674 for other media descriptions in the SDP session description). 1675 Furthermore, the answerer MUST include a supported capability 1676 negotiation extensions attribute ("a=csup") in that media 1677 description with option tags for the capability negotiation 1678 extensions supported by the answerer for that media description. 1680 Assuming all required capability negotiation extensions are 1681 supported, the answerer now proceeds as follows. 1683 For each media description where capability negotiation is to be 1684 performed (i.e. all required capability negotiation extensions are 1685 supported and at least one valid potential configuration attribute 1686 is present), the answerer MUST perform capability negotiation by 1687 using the most preferred potential configuration that is valid to 1688 the answerer, subject to any local policies. A potential 1689 configuration is valid to the answerer if: 1691 1. It is in accordance with the syntax and semantics provided in 1692 Section 3.5.1. 1694 2. It contains a configuration number that is unique within that 1695 media description. 1697 3. All attribute capabilities referenced by the potential 1698 configuration are valid themselves (as defined in Section 3.4.1. 1699 ) and each of them is provided either at the session-level or 1700 within this particular media description. For session-level 1701 attribute capabilities referenced, the attributes contained 1702 inside them MUST NOT be media-level only attributes. 1704 4. All transport protocol capabilities referenced by the potential 1705 configuration are valid themselves (as defined in Section 3.4.2. 1706 ) and each of them is furthermore provided either at the session- 1707 level or within this particular media description. 1709 5. All extension capabilities referenced by the potential 1710 configuration and supported by the answerer are valid themselves 1711 (as defined by that particular extension) and each of them are 1712 furthermore provided either at the session-level or within this 1713 particular media description. Unknown or unsupported extension 1714 capabilities MUST be ignored, unless they are prefixed with the 1715 plus ("+") sign, which indicates that the extension MUST be 1716 supported in order to use that potential configuration. If the 1717 extension is not supported, that potential configuration is not 1718 valid to the answerer. 1720 The most preferred valid potential configuration in a media 1721 description is the valid potential configuration with the lowest 1722 configuration number. The answerer MUST now process the offer for 1723 that media stream based on the most preferred valid potential 1724 configuration. Conceptually, this entails the answerer constructing 1725 an (internal) offer as follows. First, all capability negotiation 1726 parameters from the offer SDP session description are removed, 1727 thereby yielding an offer SDP session description with the actual 1728 configuration as if SDP capability negotiation was not done in the 1729 first place. Secondly, this actual configuration SDP session 1730 description is modified as follows for each media stream offered, 1731 based on the capability negotiation parameters included originally: 1733 o If a transport protocol capability is included in the potential 1734 configuration, then it replaces the transport protocol provided 1735 in the "m=" line for that media description. 1737 o If attribute capabilities are present with a delete-attributes 1738 session indication ("-s") or media and session indication ("- 1739 ms"), then all session-level attributes from the actual 1740 configuration SDP session description MUST be deleted in the 1741 resulting potential configuration SDP session description in 1742 accordance with the procedures in Section 3.5.1. If attribute 1743 capabilities are present with a delete-attributes media 1744 indication ("-m") or media and session indication ("-ms"), then 1745 all attributes from the actual configuration SDP session 1746 description inside this media description MUST be deleted. 1748 o If a session-level attribute capability is included, the 1749 attribute (and its associated value, if any) contained in it MUST 1750 be added to the resulting SDP session description. All such added 1751 session-level attributes MUST be listed before the session-level 1752 attributes that were initially present in the SDP session 1753 description. Furthermore, the added session-level attributes MUST 1754 be added in the order they were provided in the potential 1755 configuration (see also Section 3.5.1. ). 1757 This allows for attributes with implicit preference ordering 1758 to be added in the desired order; the "crypto" attribute 1759 [RFC4568] is one such example. 1761 o If a media-level attribute capability is included, then the 1762 attribute (and its associated value, if any) MUST be added to the 1763 resulting SDP session description within the media description in 1764 question. All such added media-level attributes MUST be listed 1765 before the media-level attributes that were initially present in 1766 the media description in question. Furthermore, the added media- 1767 level attributes MUST be added in the order they were provided in 1768 the potential configuration (see also Section 3.5.1. ). 1770 o If a supported extension capability is included, then it MUST be 1771 processed in accordance with the rules provided for that 1772 particular extension capability. 1774 The above steps MUST be performed exactly once per potential 1775 configuration, i.e. there MUST NOT be any recursive processing of 1776 any additional capability negotiation parameters that may 1777 (illegally) have been nested inside capabilities themselves. 1779 As an example of this, consider the (illegal) attribute capability 1781 a=acap:1 acap:2 foo:a 1783 The resulting potential configuration SDP session description 1784 will, after the above processing has been done, contain the 1785 attribute capability 1787 a=acap:2 foo:a 1789 However, since we do not perform any recursive processing of 1790 capability negotiation parameters, this second attribute 1791 capability parameter will not be processed by the offer/answer 1792 procedure. Instead, it will simply appear as a (useless) attribute 1793 in the SDP session description that will be ignored by further 1794 processing. 1796 Note that a transport protocol from the potential configuration 1797 replaces the transport protocol in the actual configuration, but an 1798 attribute capability from the potential configuration is simply 1799 added to the actual configuration. In some cases, this can result in 1800 having one or more meaningless attributes in the resulting potential 1801 configuration SDP session description, or worse, ambiguous or 1802 potentially even illegal attributes. Use of delete-attributes for 1803 the session and/or media level attributes MUST be done to avoid such 1804 scenarios. Nevertheless, it is RECOMMENDED that implementations 1805 ignore meaningless attributes that may result from potential 1806 configurations. 1808 For example, if the actual configuration was using Secure RTP and 1809 included an "a=crypto" attribute for the SRTP keying material, 1810 then use of a potential configuration that uses plain RTP would 1811 make the "crypto" attribute meaningless. The answerer may or may 1812 not ignore such a meaningless attribute. The offerer can here 1813 ensure correct operation by using delete-attributes to remove the 1814 crypto attribute (but will then need to provide attribute 1815 capabilities to reconstruct the SDP session description with the 1816 necessary attributes deleted, e.g. rtpmaps). 1818 Also note, that while it is permissible to include media-level 1819 attribute capabilities at the session-level, the base SDP Capability 1820 Negotiation framework defined here does not define any procedures 1821 for use of them, i.e. the answerer effectively ignores them. 1823 Please refer to Section 3.6.2.1. for examples of how the answerer 1824 may conceptually "see" the resulting offered alternative potential 1825 configurations. 1827 The answerer MUST check that he supports all mandatory attribute 1828 capabilities from the potential configuration (if any), the 1829 transport protocol capability (if any) from the potential 1830 configuration, and all mandatory extension capabilities from the 1831 potential configuration (if any). If he does not, the answerer MUST 1832 proceed to the second-most preferred valid potential configuration 1833 for the media description, etc. 1835 o In the case of attribute capabilities, support implies that the 1836 attribute name contained in the capability is supported and it 1837 can (and will) be negotiated successfully in the offer/answer 1838 exchange with the value provided. This does not necessarily imply 1839 that the value provided is supported in its entirety. For 1840 example, the "a=fmtp" parameter is often provided with one or 1841 more values in a list, where the offerer and answerer negotiate 1842 use of some subset of the values provided. Other attributes may 1843 include mandatory and optional parts to their values; support for 1844 the mandatory part is all that is required here. 1846 A side-effect of the above rule is that whenever an "fmtp" or 1847 "rtpmap" parameter is provided as a mandatory attribute 1848 capability, the corresponding media format (codec) must be 1849 supported and use of it negotiated successfully. If this is 1850 not the offerer's intent, the corresponding attribute 1851 capabilities must be listed as optional instead. 1853 o In the case of transport protocol capabilities, support implies 1854 that the transport protocol contained in the capability is 1855 supported and the transport protocol can (and will) be negotiated 1856 successfully in the offer/answer exchange. 1858 o In the case of extension capabilities, the extension MUST define 1859 the rules for when the extension capability is considered 1860 supported and those rules MUST be satisfied. 1862 If the answerer has exhausted all potential configurations for the 1863 media description, without finding a valid one that is also 1864 supported, then the answerer MUST process the offered media stream 1865 based on the actual configuration plus any session-level attributes 1866 added by a valid and supported potential configuration from another 1867 media description in the offered SDP session description. 1869 The above process describes potential configuration selection as a 1870 per media stream process. Inter-media stream coordination of 1871 selected potential configurations however is required in some cases. 1872 First of all, session-level attributes added by a potential 1873 configuration for one media description MUST NOT cause any problems 1874 for potential configurations selected by other media descriptions in 1875 the offer SDP session description. If the session-level attributes 1876 are mandatory, then those session-level attributes MUST furthermore 1877 be supported by the session as a whole (i.e., all the media 1878 descriptions if relevant). As mentioned earlier, this adds 1879 additional complexity to the overall processing and hence it is 1880 RECOMMENDED not to use session-level attribute capabilities in 1881 potential configurations, unless absolutely necessary. 1883 Once the answerer has selected a valid and supported offered 1884 potential configuration for all of the media streams (or has fallen 1885 back to the actual configuration plus any added session attributes), 1886 the answerer MUST generate a valid virtual answer SDP session 1887 description based on the selected potential configuration SDP 1888 session description, as "seen" by the answerer using normal 1889 offer/answer rules (see Section 3.6.2.1. for examples). The actual 1890 answer SDP session description is formed from the virtual answer SDP 1891 session description as follows: If the answerer selected one of the 1892 potential configurations in a media description, the answerer MUST 1893 include an actual configuration attribute ("a=acfg") within that 1894 media description. The "a=acfg" attribute MUST identify the 1895 configuration number for the selected potential configuration as 1896 well as the actual parameters that were used from that potential 1897 configuration; if the potential configuration included alternatives, 1898 the selected alternatives only MUST be included. Only the known and 1899 supported parameters will be included. Unknown or unsupported 1900 parameters MUST NOT be included in the actual configuration 1901 attribute. In the case of attribute capabilities, only the known and 1902 supported capabilities are included; unknown or unsupported 1903 attribute capabilities MUST NOT be included. 1905 If the answerer supports one or more capability negotiation 1906 extensions that were not included in a required capability 1907 negotiation extensions attribute in the offer, then the answerer 1908 SHOULD furthermore include a supported capability negotiation 1909 attribute ("a=csup") at the session-level with option tags for the 1910 extensions supported across media streams. Also, if the answerer 1911 supports one or more capability negotiation extensions for only 1912 particular media descriptions, then a supported capability 1913 negotiation attribute with those option-tags SHOULD be included 1914 within each relevant media description. The required capability 1915 negotiation attribute ("a=creq") MUST NOT be used in an answer. 1917 The offerer's originally provided actual configuration is contained 1918 in the offer media description's "m=" line (and associated 1919 parameters). The answerer MAY send media to the offerer in 1920 accordance with that actual configuration as soon as it receives the 1921 offer, however it MUST NOT send media based on that actual 1922 configuration if it selects an alternative potential configuration. 1923 If the answerer selects one of the potential configurations, then 1924 the answerer MAY immediately start to send media to the offerer in 1925 accordance with the selected potential configuration, however the 1926 offerer MAY discard such media or play out garbage until the offerer 1927 receives the answer. Please refer to section 3.9. for additional 1928 considerations and possible alternative solutions outside the base 1929 SDP Capability Negotiation framework. 1931 If the offerer selected a potential configuration instead of the 1932 actual configuration, then it is RECOMMENDED that the answerer sends 1933 back an answer SDP session description as soon as possible. This 1934 minimizes the risk of having media discarded or played out as 1935 garbage by the offerer. In the case of SIP [RFC3261] without any 1936 extensions, this implies that if the offer was received in an INVITE 1937 message, then the answer SDP session description should be provided 1938 in the first non-100 provisional response sent back (per RFC3261, 1939 the answer would need to be repeated in the 200 response as well, 1940 unless a relevant extension such as [RFC3262] is being used). 1942 3.6.2.1. Example Views of Potential Configurations 1944 The following examples illustrate how the answerer may conceptually 1945 "see" a potential configuration. Consider the following offered SDP 1946 session description: 1948 v=0 1949 o=alice 2891092738 2891092738 IN IP4 lost.example.com 1950 s= 1951 t=0 0 1952 c=IN IP4 lost.example.com 1953 a=tool:foo 1954 a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 1955 a=tcap:1 RTP/SAVP RTP/AVP 1956 m=audio 59000 RTP/AVP 98 1957 a=rtpmap:98 AMR/8000 1958 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32 1959 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 1960 a=pcfg:1 t=1 a=1|2 1961 m=video 52000 RTP/AVP 31 1962 a=rtpmap:31 H261/90000 1963 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 1964 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 1965 a=pcfg:1 t=1 a=1|3 1967 This particular SDP session description offers an audio stream and a 1968 video stream, each of which can either use plain RTP (actual 1969 configuration) or secure RTP (potential configuration). Furthermore, 1970 two different keying mechanisms are offered, namely session-level 1971 Key Management Extensions using MIKEY (attribute capability 1) and 1972 media-level SDP Security Descriptions (attribute capabilities 2 and 1973 3). There are several potential configurations here, however, below 1974 we show the one the answerer "sees" when using potential 1975 configuration 1 for both audio and video, and furthermore using 1976 attribute capability 1 (MIKEY) for both (we have removed all the 1977 capability negotiation attributes for clarity): 1979 v=0 1980 o=alice 2891092738 2891092738 IN IP4 lost.example.com 1981 s= 1982 t=0 0 1983 c=IN IP4 lost.example.com 1984 a=tool:foo 1985 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 1986 m=audio 59000 RTP/SAVP 98 1987 a=rtpmap:98 AMR/8000 1988 m=video 52000 RTP/SAVP 31 1989 a=rtpmap:31 H261/90000 1991 Note that the transport protocol in the media descriptions indicate 1992 use of secure RTP. 1994 Below, we show the offer the answerer "sees" when using potential 1995 configuration 1 for both audio and video and furthermore using 1996 attribute capability 2 and 3 respectively (SDP security 1997 descriptions) for the audio and video stream - note the order in 1998 which the resulting attributes are provided: 2000 v=0 2001 o=alice 2891092738 2891092738 IN IP4 lost.example.com 2002 s= 2003 t=0 0 2004 c=IN IP4 lost.example.com 2005 a=tool:foo 2006 m=audio 59000 RTP/SAVP 98 2007 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2008 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2009 a=rtpmap:98 AMR/8000 2010 m=video 52000 RTP/SAVP 31 2011 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2012 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2013 a=rtpmap:31 H261/90000 2015 Again, note that the transport protocol in the media descriptions 2016 indicate use of secure RTP. 2018 And finally, we show the offer the answerer "sees" when using 2019 potential configuration 1 with attribute capability 1 (MIKEY) for 2020 the audio stream, and potential configuration 1 with attribute 2021 capability 3 (SDP security descriptions) for the video stream: 2023 v=0 2024 o=alice 2891092738 2891092738 IN IP4 lost.example.com 2025 s= 2026 t=0 0 2027 c=IN IP4 lost.example.com 2028 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2029 a=tool:foo 2030 m=audio 59000 RTP/SAVP 98 2031 a=rtpmap:98 AMR/8000 2032 m=video 52000 RTP/SAVP 31 2033 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2034 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2035 a=rtpmap:31 H261/90000 2037 3.6.3. Offerer Processing of the Answer 2039 When the offerer attempted to use SDP Capability Negotiation in the 2040 offer, the offerer MUST examine the answer for actual use of SDP 2041 Capability Negotiation. 2043 For each media description where the offerer included a potential 2044 configuration attribute ("a=pcfg"), the offerer MUST first examine 2045 that media description for the presence of a valid actual 2046 configuration attribute ("a=acfg"). An actual configuration 2047 attribute is valid if: 2049 o it refers to a potential configuration that was present in the 2050 corresponding offer, and 2052 o it contains the actual parameters that were used from that 2053 potential configuration; if the potential configuration included 2054 alternatives, the selected alternatives only MUST be included. 2055 Note that the answer will include only parameters and attribute 2056 capabilities that are known and supported by the answerer, as 2057 described in Section 3.6.2. 2059 If a valid actual configuration attribute is not present in a media 2060 description, then the offerer MUST process the answer SDP session 2061 description for that media stream per the normal offer/answer rules 2062 defined in [RFC3264]. However, if a valid one is found, the offerer 2063 MUST instead process the answer as follows: 2065 o The actual configuration attribute specifies which of the 2066 potential configurations was used by the answerer to generate the 2067 answer for this media stream. This includes all the supported 2068 attribute capabilities and the transport capabilities referenced 2069 by the potential configuration selected, where the attribute 2070 capabilities have any associated delete-attributes included. 2071 Extension capabilities supported by the answerer are included as 2072 well. 2074 o The offerer MUST now process the answer in accordance with the 2075 rules in [RFC3264], except that it must be done as if the offer 2076 consisted of the selected potential configuration instead of the 2077 original actual configuration, including any transport protocol 2078 changes in the media ("m=") line(s), attributes added and deleted 2079 by the potential configuration at the media and session level, 2080 and any extensions used. If this derived answer is not a valid 2081 answer to the potential configuration offer selected by the 2082 answerer, the offerer MUST instead continue further processing as 2083 it would have for a regular offer/answer exchange, where the 2084 answer received does not adhere to the rules of [RFC3264]. 2086 If the offer/answer exchange was successful, and if the answerer 2087 selected one of the potential configurations from the offer as the 2088 actual configuration, and the selected potential configuration 2089 differs from the actual configuration in the offer (the "m=", "a=", 2090 etc. lines), then the offerer SHOULD initiate another offer/answer 2091 exchange. This second offer/answer exchange will not modify the 2092 session in any way, however it will help intermediaries (e.g. 2093 middleboxes), that look at the SDP session description but do not 2094 support the capability negotiation extensions, understand the 2095 details of the media stream(s) that were actually negotiated. This 2096 new offer MUST contain the selected potential configuration as the 2097 actual configuration, i.e., with the actual configuration used in 2098 the "m=" line and any other relevant attributes, bandwidth 2099 parameters, etc. 2101 Note that, per normal offer/answer rules, the second offer/answer 2102 exchange still needs to update the version number in the "o=" line 2103 (( in [RFC4566]). Attribute lines carrying keying 2104 material SHOULD repeat the keys from the previous offer, unless re- 2105 keying is necessary, e.g. due to a previously forked SIP INVITE 2106 request. Please refer to Section 3.12. for additional considerations 2107 related to intermediaries. 2109 3.6.4. Modifying the Session 2111 Capabilities and potential configurations may be included in 2112 subsequent offers as defined in [RFC3264], Section 8. The procedure 2113 for doing so is similar to that described above with the answer 2114 including an indication of the actual selected configuration used by 2115 the answerer. 2117 If the answer indicates use of a potential configuration from the 2118 offer, then the guidelines provided in Section 3.6.3. for doing a 2119 second offer/answer exchange using that potential configuration as 2120 the actual configuration apply. 2122 3.7. Interactions with ICE 2124 Interactive Connectivity Establishment (ICE) [ICE] provides a 2125 mechanism for verifying connectivity between two endpoints by 2126 sending STUN messages directly between the media endpoints. The 2127 basic ICE specification [ICE] is only defined to support UDP-based 2128 connectivity, however it allows for extensions to support other 2129 transport protocols, such as TCP, which is being specified in 2130 [ICETCP]. ICE defines a new "a=candidate" attribute, which, among 2131 other things, indicates the possible transport protocol(s) to use 2132 and then associates a priority with each of them. The most preferred 2133 transport protocol that *successfully* verifies connectivity will 2134 end up being used. 2136 When using ICE, it is thus possible that the transport protocol that 2137 will be used differs from what is specified in the "m=" line. Since 2138 both ICE and SDP Capability Negotiation may specify alternative 2139 transport protocols, there is a potentially unintended interaction 2140 when using these together. 2142 We provide the following guidelines for addressing that. 2144 There are two basic scenarios to consider: 2146 1) A particular media stream can run over different transport 2147 protocols (e.g. UDP, TCP, or TCP/TLS), and the intent is simply to 2148 use the one that works (in the preference order specified). 2150 2) A particular media stream can run over different transport 2151 protocols (e.g. UDP, TCP, or TCP/TLS) and the intent is to have the 2152 negotiation process decide which one to use (e.g. T.38 over TCP or 2153 UDP). 2155 In scenario 1, there should be ICE "a=candidate" attributes for UDP, 2156 TCP, etc. but otherwise nothing special in the potential 2157 configuration attributes to indicate the desire to use different 2158 transport protocols (e.g. UDP, or TCP). The ICE procedures 2159 essentially cover the capability negotiation required (by having the 2160 answerer select something it supports and then use of trial and 2161 error connectivity checks). 2163 Scenario 2 does not require a need to support or use ICE. Instead, 2164 we simply use transport protocol capabilities and potential 2165 configuration attributes to indicate the desired outcome. 2167 The scenarios may be combined, e.g. by offering potential 2168 configuration alternatives where some of them can support only one 2169 transport protocol (e.g. UDP), whereas others can support multiple 2170 transport protocols (e.g. UDP or TCP). In that case, there is a need 2171 for tight control over the ICE candidates that will be used for a 2172 particular configuration, yet the actual configuration may want to 2173 use all of the ICE candidates. In that case, the ICE candidate 2174 attributes can be defined as attribute capabilities and the relevant 2175 ones should then be included in the proper potential configurations 2176 (for example candidate attributes for UDP only for potential 2177 configurations that are restricted to UDP, whereas there could be 2178 candidate attributes for UDP, TCP, and TCP/TLS for potential 2179 configurations that can use all three). Furthermore, use of the 2180 delete-attributes in a potential configuration can be used to ensure 2181 that ICE will not end up using a transport protocol that is not 2182 desired for a particular configuration. 2184 SDP Capability Negotiation recommends use of a second offer/answer 2185 exchange when the negotiated actual configuration was one of the 2186 potential configurations from the offer (see Section 3.6.3. ). 2187 Similarly, ICE requires use of a second offer/answer exchange if the 2188 chosen candidate is not the same as the one in the m/c-line from the 2189 offer. When ICE and capability negotiation are used at the same 2190 time, the two secondary offer/answer exchanges SHOULD be combined to 2191 a single one. 2193 3.8. Interactions with SIP Option Tags 2195 SIP [RFC3261] allows for SIP extensions to define a SIP option tag 2196 that identifies the SIP extension. Support for one or more such 2197 extensions can be indicated by use of the SIP Supported header, and 2198 required support for one or more such extensions can be indicated by 2199 use of the SIP Require header. The "a=csup" and "a=creq" attributes 2200 defined by the SDP Capability Negotiation framework are similar, 2201 except that support for these two attributes by themselves cannot be 2202 guaranteed (since they are specified as extensions to the SDP 2203 specification [RFC4566] itself). 2205 SIP extensions with associated option tags can introduce 2206 enhancements to not only SIP, but also SDP. This is for example the 2207 case for SIP preconditions defined in [RFC3312]. When using SDP 2208 Capability Negotiation, some potential configurations may include 2209 certain SDP extensions, whereas others may not. Since the purpose of 2210 the SDP Capability Negotiation is to negotiate a session based on 2211 the features supported by both sides, use of the SIP Require header 2212 for such extensions may not produce the desired result. For example, 2213 if one potential configuration requires SIP preconditions support, 2214 another does not, and the answerer does not support preconditions, 2215 then use of the SIP Require header for preconditions would result in 2216 a session failure, in spite of the fact that a valid and supported 2217 potential configuration was included in the offer. 2219 In general, this can be alleviated by use of mandatory and optional 2220 attribute capabilities in a potential configuration. There are 2221 however cases where permissible SDP values are tied to the use of 2222 the SIP Require header. SIP preconditions [RFC3312] is one such 2223 example, where preconditions with a "mandatory" strength-tag can 2224 only be used when a SIP Require header with the SIP option tag 2225 "precondition" is included. Future SIP extensions that may want to 2226 use the SDP Capability Negotiation framework should avoid such 2227 coupling. 2229 3.9. Processing Media before Answer 2231 The offer/answer model [RFC3264] requires an offerer to be able to 2232 receive media in accordance with the offer prior to receiving the 2233 answer. This property is retained with the SDP Capability 2234 Negotiation extensions defined here, but only when the actual 2235 configuration is selected by the answerer. If a potential 2236 configuration is chosen, the offerer may decide to not process any 2237 media received before the answer is received. This may lead to 2238 clipping. Consequently, the SDP Capability Negotiation framework 2239 recommends sending back an answer SDP session description as soon as 2240 possible. 2242 The issue can be resolved by introducing a three-way handshake. In 2243 the case of SIP, this can for example be done by defining a 2244 precondition [RFC3312] for capability negotiation (or use an 2245 existing precondition that is known to generate a second 2246 offer/answer exchange before proceeding with the session). However, 2247 preconditions are often viewed as complicated to implement and they 2248 may add to overall session establishment delay by requiring an extra 2249 offer/answer exchange. 2251 An alternative three-way handshake can be performed by use of ICE 2252 [ICE]. When ICE is being used, and the answerer receives a STUN 2253 Binding Request for any one of the accepted media streams from the 2254 offerer, the answerer knows the offer has received his answer. At 2255 that point, the answerer knows that the offerer will be able to 2256 process incoming media according to the negotiated configuration and 2257 hence he can start sending media without the risk of the offerer 2258 either discarding it or playing garbage. 2260 Please note that, the above considerations notwithstanding, this 2261 document does not place any requirements on the offerer to process 2262 and play media before answer; it merely provides recommendations for 2263 how to ensure that media sent by the answerer and received by the 2264 offerer prior to receiving the answer, can in fact be rendered by 2265 the offerer. 2267 In some use cases a three-way handshake is not needed. An example is 2268 when the offerer does not need information from the answer, such as 2269 keying material in the SDP session description, in order to process 2270 incoming media. The SDP Capability Negotiation framework does not 2271 define any such solutions, however extensions may do so. For 2272 example, one technique proposed for best-effort SRTP in [BESRTP] is 2273 to provide different RTP payload type mappings for different 2274 transport protocols used, outside of the actual configuration, while 2275 still allowing them to be used by the answerer (exchange of keying 2276 material is still needed, e.g. inband). The basic SDP Capability 2277 Negotiation framework defined here does not include the ability to 2278 do so, however extensions that enable that may be defined. 2280 3.10. Indicating Bandwidth Usage 2282 The amount of bandwidth used for a particular media stream depends 2283 on the negotiated codecs, transport protocol and other parameters. 2284 For example use of Secure RTP [RFC3711] with integrity protection 2285 requires more bandwidth than plain RTP [RFC3551]. SDP defines the 2286 bandwidth ("b=") parameter to indicate the proposed bandwidth for 2287 the session or media stream. 2289 In SDP as defined by [RFC4566], each media description contains one 2290 transport protocol and one or more codecs. When specifying the 2291 proposed bandwidth, the worst case scenario must be taken into 2292 account, i.e., use of the highest bandwidth codec provided, the 2293 transport protocol indicated, and the worst case (bandwidth-wise) 2294 parameters that can be negotiated (e.g., a 32-bit HMAC or an 80-bit 2295 HMAC). 2297 The base SDP Capability Negotiation framework does not provide a way 2298 to negotiate bandwidth parameters. The issue thus remains, however 2299 it is potentially worse than with SDP per [RFC4566], since it is 2300 easier to negotiate additional codecs, and furthermore possible to 2301 negotiate different transport protocols. The recommended approach 2302 for addressing this is the same as for plain SDP; the worst case 2303 (now including potential configurations) needs to be taken into 2304 account when specifying the bandwidth parameters in the actual 2305 configuration. This can make the bandwidth value less accurate than 2306 in SDP per [RFC4566] (due to potential greater variability in the 2307 potential configuration bandwidth use). Extensions can be defined to 2308 address this shortcoming. 2310 The Transport Independent Application Specific Maximum (TIAS) 2311 bandwidth type as defined in [RFC3890] SHOULD NOT be used to try and 2312 alleviate bandwidth variability concerns due to different transport 2313 protocols, since there are some inconsistencies between [RFC3264] 2314 and [RFC3890]. More specifically, [RFC3264] defines the bandwidth 2315 parameter to apply to the receive direction for unicast streams, 2316 whereas [RFC3890] intends to use bandwidth in the send direction. 2317 Implementers are encouraged to look for an expected future solution 2318 to this. 2320 Note, that when using RTP retransmission [RFC4588] with the RTCP- 2321 based feedback profile [RFC4585] (RTP/AVPF), the retransmitted 2322 packets are part of the media stream bandwidth when using SSRC- 2323 multiplexing. If a feedback based protocol is offered as the actual 2324 configuration transport protocol, a non-feedback based protocol is 2325 offered as a potential configuration transport protocol and ends up 2326 being used, the actual bandwidth usage may be lower than the 2327 indicated bandwidth value in the offer (and vice versa). 2329 3.11. Dealing with Large Number of Potential Configurations 2331 When using the SDP Capability Negotiation, it is easy to generate 2332 offers that contain a large number of potential configurations. For 2333 example, in the offer: 2335 v=0 2336 o=- 25678 753849 IN IP4 192.0.2.1 2337 s= 2338 c=IN IP4 192.0.2.1 2339 t=0 0 2340 m=audio 53456 RTP/AVP 0 18 2341 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF 2342 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 2343 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 2344 FEC_ORDER=FEC_SRTP 2345 a=acap:2 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2346 a=acap:3 rtcp-fb:0 nack 2347 a=pcfg:1 t=1 a=1,3|2,3 2348 a=pcfg:2 t=2 a=1|2 2349 a=pcfg:3 t=3 a=3 2351 we have 5 potential configurations on top of the actual 2352 configuration for a single media stream. Adding an extension 2353 capability with just two alternatives for each would double that 2354 number (to 10), and doing the equivalent with two media streams 2355 would again double that number (to 20). While it is easy (and 2356 inexpensive) for the offerer to generate such offers, processing 2357 them at the answering side may not be. Consequently, it is 2358 RECOMMENDED that offerers do not create offers with unnecessarily 2359 large number of potential configurations in them. 2361 On the answering side, implementers MUST take care to avoid 2362 excessive memory and CPU consumption. For example, a naive 2363 implementation that first generates all the valid potential 2364 configuration SDP session descriptions internally, could find itself 2365 being memory exhausted, especially if it supports a large number of 2366 endpoints. Similarly, a naive implementation that simply performs 2367 iterative trial-and-error processing on each possible potential 2368 configuration SDP session description (in the preference order 2369 specified) could find itself being CPU constrained. An alternative 2370 strategy is to prune the search space first by discarding the set of 2371 offered potential configurations where the transport protocol 2372 indicated (if any) is not supported, and/or one or more mandatory 2373 attribute capabilities (if any) are either not supported or not 2374 valid. Potential configurations with unsupported mandatory extension 2375 configurations in them can be discarded as well. 2377 3.12. SDP Capability Negotiation and Intermediaries 2379 An intermediary is here defined as an entity between a SIP user 2380 agent A and a SIP user agent B, that need to perform some kind of 2381 processing on the SDP session descriptions exchanged between A and 2382 B, in order for the session establishment to operate as intended. 2383 Examples of such intermediaries include Session Border Controllers 2384 (SBCs) that may perform media relaying, Proxy Call Session Control 2385 Functions (P-CSCF) that may authorize use of a certain amount of 2386 network resources (bandwidth), etc. The presence and design of such 2387 intermediaries may not follow the "Internet" model or the SIP 2388 requirements for proxies (which are not supposed to look in message 2389 bodies such as SDP session descriptions), however they are a fact of 2390 life in some deployment scenarios and hence deserve consideration. 2392 If the intermediary needs to understand the characteristics of the 2393 media sessions being negotiated, e.g. the amount of bandwidth used 2394 or the transport protocol negotiated, then use of the SDP Capability 2395 Negotiation framework may impact them. For example, some 2396 intermediaries are known to disallow answers where the transport 2397 protocol differs from the one in the offer. Use of the SDP 2398 Capability Negotiation framework in the presence of such 2399 intermediaries could lead to session failures. Intermediaries that 2400 need to authorize use of network resources based on the negotiated 2401 media stream parameters are affected as well. If they inspect only 2402 the offer, then they may authorize parameters assuming a different 2403 transport protocol, codecs, etc. than what is actually being 2404 negotiated. For these, and other, reasons it is RECOMMENDED that 2405 implementers of intermediaries add support for the SDP Capability 2406 Negotiation framework. 2408 The SDP Capability Negotiation framework itself attempts to help out 2409 these intermediaries as well, by recommending a second offer/answer 2410 exchange when use of a potential configuration has been negotiated 2411 (see Section 3.6.3. ). However, there are several limitations with 2412 this approach. First of all, although the second offer/answer 2413 exchange is RECOMMENDED, it is not required and hence may not be 2414 performed. Secondly, the intermediary may refuse the initial answer, 2415 e.g. due to perceived transport protocol mismatch. Thirdly, the 2416 strategy is not foolproof since the offer/answer procedures 2417 [RFC3264] leave the original offer/answer exchange in effect when a 2418 subsequent one fails. Consider the following example: 2420 1. Offerer generates an SDP session description offer with the 2421 actual configuration specifying a low bandwidth configuration 2422 (e.g. plain RTP) and a potential configuration specifying a 2423 high(er) bandwidth configuration (e.g. secure RTP with 2424 integrity). 2426 2. An intermediary (e.g. an SBC or P-CSCF), that does not support 2427 SDP Capability Negotiation, authorizes the session based on the 2428 actual configuration it sees in the SDP session description. 2430 3. The answerer chooses the high(er) bandwidth potential 2431 configuration and generates an answer SDP session description 2432 based on that. 2434 4. The intermediary passes through the answer SDP session 2435 description. 2437 5. The offerer sees the accepted answer, and generates an updated 2438 offer that contains the selected potential configuration as the 2439 actual configuration. In other words, the high(er) bandwidth 2440 configuration (which has already been negotiated successfully) is 2441 now the actual configuration in the offer SDP session 2442 description. 2444 6. The intermediary sees the new offer, however it does not 2445 authorize the use of the high(er) bandwidth configuration, and 2446 consequently generates a rejection message to the offerer. 2448 7. The offerer receives the rejected offer. 2450 After step 7, per RFC 3264, the offer/answer exchange that completed 2451 in step 5 remains in effect, however the intermediary may not have 2452 authorized the necessary network resources and hence the media 2453 stream may experience quality issues. The solution to this problem 2454 is to upgrade the intermediary to support the SDP Capability 2455 Negotiation framework. 2457 3.13. Considerations for Specific Attribute Capabilities 2459 3.13.1. The rtpmap and fmtp Attributes 2461 The base SDP Capability Negotiation framework defines transport 2462 capabilities and attribute capabilities. Media capabilities, which 2463 can be used to describe media formats and their associated 2464 parameters, are not defined in this document, however the "rtpmap" 2465 and "fmtp" attributes can nevertheless be used as attribute 2466 capabilities. Using such attribute capabilities in a potential 2467 configuration requires a bit of care though. 2469 The rtpmap parameter binds an RTP payload type to a media format 2470 (e.g. codec). While it is possible to provide rtpmaps for payload 2471 types not found in the corresponding "m=" line, such rtpmaps provide 2472 no value in normal offer/answer exchanges, since only the payload 2473 types found in the "m=" line are part of the offer (or answer). This 2474 applies to the base SDP Capability Negotiation framework as well: 2475 Only the media formats (e.g. RTP payload types) provided in the "m=" 2476 line are actually offered; inclusion of rtpmap attributes with other 2477 RTP payload types in a potential configuration does not change this 2478 fact and hence they do not provide any useful information there. 2479 They may still be useful as pure capabilities though (outside a 2480 potential configuration) in order to inform a peer of additional 2481 codecs supported. 2483 It is possible to provide an rtpmap attribute capability with a 2484 payload type mapping to a different codec than a corresponding 2485 actual configuration "rtpmap" attribute for the media description 2486 has. Such practice is permissible as a way of indicating a 2487 capability. If that capability is included in a potential 2488 configuration, then delete-attributes (see Section 3.5.1. ) MUST be 2489 used to ensure that there is not multiple rtpmap attributes for the 2490 same payload type in a given media description (which would not be 2491 allowed by SDP [RFC4566]). 2493 Similar considerations and rules apply to the "fmtp" attribute. An 2494 fmtp attribute capability for a media format not included in the 2495 "m=" line is useless in a potential configuration (but may be useful 2496 as a capability by itself). An fmtp attribute capability in a 2497 potential configuration for a media format that already has an fmtp 2498 attribute in the actual configuration may lead to multiple fmtp 2499 format parameters for that media format and that is not allowed by 2500 SDP [RFC4566]. The delete-attributes MUST be used to ensure that 2501 there is not multiple fmtp attributes for a given media format in a 2502 media description. 2504 Extensions to the base SDP Capability Negotiation framework may 2505 change the above behavior. 2507 3.13.2. Direction Attributes 2509 SDP defines the "inactive", "sendonly", "recvonly", and "sendrecv" 2510 direction attributes. The direction attributes can be applied at 2511 either the session-level or the media-level. In either case, it is 2512 possible to define attribute capabilities for these direction 2513 capabilities; if used by a potential configuration, the normal 2514 offer/answer procedures still apply. For example, if an offered 2515 potential configuration includes the "sendonly" direction attribute, 2516 and it is selected as the actual configuration, then the answer MUST 2517 include a corresponding "recvonly" (or "inactive") attribute. 2519 3.14. Relationship to RFC 3407 2521 RFC 3407 defines capability descriptions with limited abilities to 2522 describe attributes, bandwidth parameters, transport protocols and 2523 media formats. RFC 3407 does not define any negotiation procedures 2524 for actually using those capability descriptions. 2526 This document defines new attributes for describing attribute 2527 capabilities and transport capabilities. It also defines procedures 2528 for using those capabilities as part of an offer/answer exchange. In 2529 contrast to RFC 3407, this document does not define bandwidth 2530 parameters, and it also does not define how to express ranges of 2531 values. Extensions to this document may be defined in order to fully 2532 cover all the capabilities provided by RFC 3407 (for example more 2533 general media capabilities). 2535 It is RECOMMENDED that implementations use the attributes and 2536 procedures defined in this document instead of those defined in 2537 [RFC3407]. If capability description interoperability with legacy 2538 RFC 3407 implementations is desired, implementations MAY include 2539 both RFC 3407 capability descriptions and capabilities defined by 2540 this document. The offer/answer negotiation procedures defined in 2541 this document will not use the RFC 3407 capability descriptions. 2543 4. Examples 2545 In this section, we provide examples showing how to use the SDP 2546 Capability Negotiation. 2548 4.1. Multiple Transport Protocols 2550 The following example illustrates how to use the SDP Capability 2551 Negotiation extensions to negotiate use of one out of several 2552 possible transport protocols. The offerer uses the expected least- 2553 common-denominator (plain RTP) as the actual configuration, and the 2554 alternative transport protocols as the potential configurations. 2556 The example is illustrated by the offer/answer exchange below, where 2557 Alice sends an offer to Bob: 2559 Alice Bob 2561 | (1) Offer (RTP/[S]AVP[F]) | 2562 |--------------------------------->| 2563 | | 2564 | (2) Answer (RTP/AVPF) | 2565 |<---------------------------------| 2566 | | 2567 | (3) Offer (RTP/AVPF) | 2568 |--------------------------------->| 2569 | | 2570 | (4) Answer (RTP/AVPF) | 2571 |<---------------------------------| 2572 | | 2574 Alice's offer includes plain RTP (RTP/AVP), RTP with RTCP-based 2575 feedback (RTP/AVPF), Secure RTP (RTP/SAVP), and Secure RTP with 2576 RTCP-based feedback (RTP/SAVPF) as alternatives. RTP is the default, 2577 with RTP/SAVPF, RTP/SAVP, and RTP/AVPF as the alternatives and 2578 preferred in the order listed: 2580 v=0 2581 o=- 25678 753849 IN IP4 192.0.2.1 2582 s= 2583 c=IN IP4 192.0.2.1 2584 t=0 0 2585 m=audio 53456 RTP/AVP 0 18 2586 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF 2587 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 2588 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 2589 FEC_ORDER=FEC_SRTP 2590 a=acap:2 rtcp-fb:0 nack 2591 a=pcfg:1 t=1 a=1,[2] 2592 a=pcfg:2 t=2 a=1 2593 a=pcfg:3 t=3 a=[2] 2595 The "m=" line indicates that Alice is offering to use plain RTP with 2596 PCMU or G.729. The capabilities are provided by the "a=tcap" and 2597 "a=acap" attributes. The "tcap" capability indicates that Secure 2598 RTP with RTCP-Based feedback (RTP/SAVPF), Secure RTP (RTP/SAVP), and 2599 RTP with RTCP-Based feedback are supported. The first "acap" 2600 attribute provides an attribute capability with a handle of 1. The 2601 capability is a "crypto" attribute, which provides the keying 2602 material for SRTP using SDP security descriptions [RFC4568]. The 2603 second "acap" attribute provides an attribute capability with a 2604 handle of 2. The capability is an "rtcp-fb" attribute, which is used 2605 by the RTCP-based feedback profiles to indicate that payload type 0 2606 (PCMU) supports feedback type "nack". The "a=pcfg" attributes 2607 provide the potential configurations included in the offer by 2608 reference to the capabilities. There are three potential 2609 configurations: 2611 o Potential configuration 1, which is the most preferred potential 2612 configuration specifies use of transport protocol capability 1 2613 (RTP/SAVPF) and attribute capabilities 1 (the "crypto" attribute) 2614 and 2 (the "rtcp-fb" attribute). Support for the first one is 2615 mandatory whereas support for the second one is optional. 2617 o Potential configuration 2, which is the second most preferred 2618 potential configuration specifies use of transport protocol 2619 capability 2 (RTP/SAVP) and mandatory attribute capability 1 (the 2620 "crypto" attribute). 2622 o Potential configuration 3, which is the least preferred potential 2623 configuration (but the second least preferred configuration 2624 overall, since the actual configuration provided by the "m=" line 2625 is always the least preferred configuration), specifies use of 2626 transport protocol capability 3 (RTP/AVPF) and optional attribute 2627 capability 2 (the "rtcp-fb" attribute). 2629 Bob receives the SDP session description offer from Alice. Bob does 2630 not support any secure RTP profiles, however he supports plain RTP 2631 and RTP with RTCP-based feedback, as well as the SDP Capability 2632 Negotiation extensions, and hence he accepts the potential 2633 configuration for RTP with RTCP-based feedback provided by Alice: 2635 v=0 2636 o=- 24351 621814 IN IP4 192.0.2.2 2637 s= 2638 c=IN IP4 192.0.2.2 2639 t=0 0 2640 m=audio 54568 RTP/AVPF 0 18 2641 a=rtcp-fb:0 nack 2642 a=acfg:1 t=3 a=[2] 2644 Bob includes the "a=acfg" attribute in the answer to inform Alice 2645 that he based his answer on an offer containing the potential 2646 configuration with transport protocol capability 3 and optional 2647 attribute capability 2 from the offer SDP session description (i.e. 2648 the RTP/AVPF profile using the "rtcp-fb" value provided). Bob also 2649 includes an "rtcp-fb" attribute with the value "nack" value for RTP 2650 payload type 0. 2652 When Alice receives Bob's answer, session negotiation has completed, 2653 however Alice nevertheless chooses to generate a new offer using the 2654 actual configuration. This is done purely to assist any 2655 intermediaries that may reside between Alice and Bob but do not 2656 support the SDP Capability Negotiation framework (and hence may not 2657 understand the negotiation that just took place): 2659 Alice's updated offer includes only RTP/AVPF, and it is not using 2660 the SDP Capability Negotiation framework (Alice could have included 2661 the capabilities as well if she wanted to): 2663 v=0 2664 o=- 25678 753850 IN IP4 192.0.2.1 2665 s= 2666 c=IN IP4 192.0.2.1 2667 t=0 0 2668 m=audio 53456 RTP/AVPF 0 18 2669 a=rtcp-fb:0 nack 2671 The "m=" line now indicates that Alice is offering to use RTP with 2672 RTCP-based feedback and using PCMU or G.729. The "rtcp-fb" 2673 attribute provides the feedback type "nack" for payload type 0 again 2674 (but as part of the actual configuration). 2676 Bob receives the SDP session description offer from Alice, which he 2677 accepts, and then generates an answer to Alice: 2679 v=0 2680 o=- 24351 621815 IN IP4 192.0.2.2 2681 s= 2682 c=IN IP4 192.0.2.2 2683 t=0 0 2684 m=audio 54568 RTP/AVPF 0 18 2685 a=rtcp-fb:0 nack 2687 Bob includes the same "rtcp-fb" attribute as before, and the session 2688 proceeds without change. Although Bob did not include any 2689 capabilities in his answer, he could have done so if he wanted to. 2691 Note that in this particular example, the answerer supported the SDP 2692 Capability Negotiation framework and hence the attributes and 2693 procedures defined here, however had he not, the answerer would 2694 simply have ignored the new attributes received in step 1 and 2695 accepted the offer to use normal RTP. In that case, the following 2696 answer would have been generated in step 2 instead: 2698 v=0 2699 o=- 24351 621814 IN IP4 192.0.2.2 2700 s= 2701 c=IN IP4 192.0.2.2 2702 t=0 0 2703 m=audio 54568 RTP/AVP 0 18 2705 4.2. DTLS-SRTP or SRTP with Media Level Security Descriptions 2707 The following example illustrates how to use the SDP Capability 2708 Negotiation framework to negotiate use of SRTP using either SDP 2709 Security Descriptions or DTLS-SRTP. The offerer (Alice) wants to 2710 establish a secure RTP audio stream but is willing to use plain RTP. 2711 Alice prefers to use DTLS-SRTP as the key management protocol, but 2712 supports SDP security descriptions as well (note that [DTLS-SRTP- 2713 FRAMEWORK] contains additional DTLS-SRTP examples). 2715 The example is illustrated by the offer/answer exchange below, where 2716 Alice sends an offer to Bob: 2718 Alice Bob 2720 | (1) Offer (RTP/[S]AVP,SDES | DTLS-SRTP)| 2721 |--------------------------------------->| 2722 | | 2723 |<--------- DTLS-SRTP handshake -------->| 2724 | | 2725 | (2) Answer (DTLS-SRTP) | 2726 |<---------------------------------------| 2727 | | 2728 | (3) Offer (DTLS-SRTP) | 2729 |--------------------------------------->| 2730 | | 2731 | (4) Answer (DTLS-SRTP) | 2732 |<---------------------------------------| 2733 | | 2735 Alice's offer includes an audio stream which offers use of plain RTP 2736 and secure RTP as alternatives. For the secure RTP stream, it can be 2737 established using either DTLS-SRTP or SDP Security Descriptions: 2739 v=0 2740 o=- 25678 753849 IN IP4 192.0.2.1 2741 s= 2742 t=0 0 2743 c=IN IP4 192.0.2.1 2744 a=acap:1 setup:actpass 2745 a=acap:2 fingerprint: SHA-1 \ 2746 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2747 a=tcap:1 UDP/TLS/RTP/SAVP RTP/SAVP 2748 m=audio 59000 RTP/AVP 98 2749 a=rtpmap:98 AMR/8000 2750 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_32 2751 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2752 a=pcfg:1 t=1 a=1,2 2753 a=pcfg:2 t=2 a=3 2755 The first (and preferred) potential configuration for the audio 2756 stream specifies use of transport capability 1 (UDP/TLS/RTP/SAVP), 2757 i.e. DTLS-SRTP, and attribute capabilities 1 and 2 (active/passive 2758 mode and certificate fingerprint), both of which must be supported 2759 to choose this potential configuration. The second (and less 2760 preferred) potential configuration specifies use of transport 2761 capability 2 (RTP/SAVP) and mandatory attribute capability 3, i.e. 2762 the SDP security description. 2764 Bob receives the SDP session description offer from Alice. Bob 2765 supports DTLS-SRTP as preferred by Alice and Bob now initiates the 2766 DTLS-SRTP handshake to establish the DTLS-SRTP session (see [DTLS- 2767 SRTP] for details). 2769 Bob also sends back an answer to Alice as follows: 2771 v=0 2772 o=- 24351 621814 IN IP4 192.0.2.2 2773 s= 2774 a=setup:active 2775 a=fingerprint: SHA-1 \ 2776 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2777 t=0 0 2778 c=IN IP4 192.0.2.2 2779 m=audio 54568 UDP/TLS/RTP/SAVP 98 2780 a=rtpmap:98 AMR/8000 2781 a=acfg:1 t=1 a=1,2 2783 For the audio stream, Bob accepted the use of DTLS-SRTP, and hence 2784 the profile in the "m=" line is "UDP/TLS/RTP/SAVP". Bob also includes 2785 a "setup:active" attribute to indicate he is the active endpoint for 2786 the DTLS-SRTP session as well as the fingerprint for Bob's 2787 certificate. Bob's "acfg" attribute indicates that he chose potential 2788 configuration 1 from Alice's offer. 2790 When Alice receives Bob's answer, session negotiation has completed 2791 (and Alice can verify the DTLS handshake using Bob's certificate 2792 fingerprint in the answer), however Alice nevertheless chooses to 2793 generate a new offer using the actual configuration. This is done 2794 purely to assist any intermediaries that may reside between Alice 2795 and Bob but do not support the capability negotiation extensions 2796 (and hence may not understand the negotiation that just took place): 2798 Alice's updated offer includes only DTLS-SRTP for the audio stream, 2799 and it is not using the SDP Capability Negotiation framework (Alice 2800 could have included the capabilities as well if she wanted to): 2802 v=0 2803 o=- 25678 753850 IN IP4 192.0.2.1 2804 s= 2805 t=0 0 2806 c=IN IP4 192.0.2.1 2807 a=setup:actpass 2808 a=fingerprint: SHA-1 \ 2809 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2810 m=audio 59000 UDP/TLS/RTP/AVP 98 2811 a=rtpmap:98 AMR/8000 2813 The "m=" line for the audio stream now indicates that Alice is 2814 offering to use DTLS-SRTP in active/passive mode using her 2815 certificate fingerprint provided. 2817 Bob receives the SDP session description offer from Alice, which he 2818 accepts, and then generates an answer to Alice: 2820 v=0 2821 o=- 24351 621814 IN IP4 192.0.2.2 2822 s= 2823 a=setup:active 2824 a=fingerprint: SHA-1 \ 2825 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2826 t=0 0 2827 c=IN IP4 192.0.2.2 2828 m=audio 54568 UDP/TLS/RTP/SAVP 98 2829 a=rtpmap:98 AMR/8000 2830 a=acfg:1 t=1 a=1,2 2832 Bob includes the same "setup:active" and fingerprint attributes as 2833 before, and the session proceeds without change. Although Bob did 2834 not include any capabilities in his answer, he could have done so if 2835 he wanted to. 2837 Note that in this particular example, the answerer supported the 2838 capability extensions defined here, however had he not, the answerer 2839 would simply have ignored the new attributes received in step 1 and 2840 accepted the offer to use normal RTP. In that case, the following 2841 answer would have been generated in step 2 instead: 2843 v=0 2844 o=- 24351 621814 IN IP4 192.0.2.2 2845 s= 2846 t=0 0 2847 c=IN IP4 192.0.2.2 2848 m=audio 54568 RTP/AVP 98 2849 a=rtpmap:98 AMR/8000 2851 Finally, if Bob had chosen to use SDP Security Descriptions instead 2852 of DTLS-SRTP, the following answer would have been generated: 2854 v=0 2855 o=- 24351 621814 IN IP4 192.0.2.2 2856 s= 2857 t=0 0 2858 c=IN IP4 192.0.2.2 2859 m=audio 54568 RTP/SAVP 98 2860 a=rtpmap:98 AMR/8000 2861 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2862 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 2863 a=acfg:2 t=2 a=3 2865 4.3. Best-Effort SRTP with Session-Level MIKEY and Media Level Security 2866 Descriptions 2868 The following example illustrates how to use the SDP Capability 2869 Negotiation extensions to support so-called Best-Effort Secure RTP 2870 as well as alternative keying mechanisms, more specifically MIKEY 2871 [RFC3830] and SDP Security Descriptions. The offerer (Alice) wants 2872 to establish an audio and video session. Alice prefers to use 2873 session-level MIKEY as the key management protocol, but supports SDP 2874 security descriptions as well. 2876 The example is illustrated by the offer/answer exchange below, where 2877 Alice sends an offer to Bob: 2879 Alice Bob 2881 | (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) | 2882 |--------------------------------------->| 2883 | | 2884 | (2) Answer (RTP/SAVP, SDES) | 2885 |<---------------------------------------| 2886 | | 2887 | (3) Offer (RTP/SAVP, SDES) | 2888 |--------------------------------------->| 2889 | | 2890 | (4) Answer (RTP/SAVP, SDES) | 2891 |<---------------------------------------| 2892 | | 2894 Alice's offer includes an audio and a video stream. The audio stream 2895 offers use of plain RTP and secure RTP as alternatives, whereas the 2896 video stream offers use of plain RTP, RTP with RTCP-based feedback, 2897 Secure RTP, and Secure RTP with RTCP-based feedback as alternatives: 2899 v=0 2900 o=- 25678 753849 IN IP4 192.0.2.1 2901 s= 2902 t=0 0 2903 c=IN IP4 192.0.2.1 2904 a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2905 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF 2906 m=audio 59000 RTP/AVP 98 2907 a=rtpmap:98 AMR/8000 2908 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32 2909 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2910 a=pcfg:1 t=2 a=1|2 2911 m=video 52000 RTP/AVP 31 2912 a=rtpmap:31 H261/90000 2913 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 2914 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2915 a=acap:4 rtcp-fb:* nack 2916 a=pcfg:1 t=1 a=1,4|3,4 2917 a=pcfg:2 t=2 a=1|3 2918 a=pcfg:3 t=3 a=4 2920 The potential configuration for the audio stream specifies use of 2921 transport capability 2 (RTP/SAVP) and either attribute capability 1 2922 (session-level MIKEY as the keying mechanism) or 2 (SDP Security 2923 Descriptions as the keying mechanism). Support for either of these 2924 attribute capabilities is mandatory. There are three potential 2925 configurations for the video stream. 2927 o The first configuration with configuration number 1 uses 2928 transport capability 1 (RTP/SAVPF) with either attribute 2929 capabilities 1 and 4 (session-level MIKEY and the "rtcp-fb" 2930 attribute) or attribute capabilities 3 and 4 (SDP security 2931 descriptions and the "rtcp-fb" attribute). In this example, the 2932 offerer insists on not only the keying mechanism being supported, 2933 but also that the "rtcp-fb" attribute is supported with the value 2934 indicated. Consequently, all the attribute capabilities are 2935 marked as mandatory in this potential configuration. 2937 o The second configuration with configuration number 2 uses 2938 transport capability 2 (RTP/SAVP) and either attribute capability 2939 1 (session-level MIKEY) or attribute capability 3 (SDP security 2940 descriptions). Both attribute capabilities are mandatory in this 2941 configuration. 2943 o The third configuration with configuration number 3 uses 2944 transport capability 3 (RTP/AVPF) and mandatory attribute 2945 capability 4 (the "rtcp-fb" attribute). 2947 Bob receives the SDP session description offer from Alice. Bob 2948 supports Secure RTP, Secure RTP with RTCP-based feedback and the SDP 2949 Capability Negotiation extensions. Bob also supports SDP Security 2950 Descriptions, but not MIKEY, and hence he generates the following 2951 answer: 2953 v=0 2954 o=- 24351 621814 IN IP4 192.0.2.2 2955 s= 2956 t=0 0 2957 c=IN IP4 192.0.2.2 2958 m=audio 54568 RTP/SAVP 98 2959 a=rtpmap:98 AMR/8000 2960 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2961 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 2962 a=acfg:1 t=2 a=2 2963 m=video 55468 RTP/SAVPF 31 2964 a=rtpmap:31 H261/90000 2965 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2966 inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32 2967 a=rtcp-fb:* nack 2968 a=acfg:1 t=1 a=3,4 2970 For the audio stream, Bob accepted the use of secure RTP, and hence 2971 the profile in the "m=" line is "RTP/SAVP". Bob also includes a 2972 "crypto" attribute with his own keying material, and an "acfg" 2973 attribute identifying actual configuration 1 for the audio media 2974 stream from the offer, using transport capability 2 (RTP/SAVP) and 2975 attribute capability 2 (the crypto attribute from the offer). For 2976 the video stream, Bob accepted the use of secure RTP with RTCP-based 2977 feedback, and hence the profile in the "m=" line is "RTP/SAVPF". Bob 2978 also includes a "crypto" attribute with his own keying material, and 2979 an "acfg" attribute identifying actual configuration 1 for the video 2980 stream from the offer, using transport capability 1 (RTP/SAVPF) and 2981 attribute capabilities 3 (the crypto attribute from the offer) and 4 2982 (the "rtcp-fb" attribute from the offer). 2984 When Alice receives Bob's answer, session negotiation has completed, 2985 however Alice nevertheless chooses to generate a new offer using the 2986 actual configuration. This is done purely to assist any 2987 intermediaries that may reside between Alice and Bob but do not 2988 support the capability negotiation extensions (and hence may not 2989 understand the negotiation that just took place): 2991 Alice's updated offer includes only SRTP for the audio stream SRTP 2992 with RTCP-based feedback for the video stream, and it is not using 2993 the SDP Capability Negotiation framework (Alice could have included 2994 the capabilities as well is she wanted to): 2996 v=0 2997 o=- 25678 753850 IN IP4 192.0.2.1 2998 s= 2999 t=0 0 3000 c=IN IP4 192.0.2.1 3001 m=audio 59000 RTP/SAVP 98 3002 a=rtpmap:98 AMR/8000 3003 a=crypto:1 AES_CM_128_HMAC_SHA1_32 3004 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 3005 m=video 52000 RTP/SAVPF 31 3006 a=rtpmap:31 H261/90000 3007 a=crypto:1 AES_CM_128_HMAC_SHA1_80 3008 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 3009 a=rtcp-fb:* nack 3011 The "m=" line for the audio stream now indicates that Alice is 3012 offering to use secure RTP with PCMU or G.729, whereas the "m=" line 3013 for the video stream indicates that Alice is offering to use secure 3014 RTP with RTCP-based feedback and H.261. Each media stream includes a 3015 "crypto" attribute, which provides the SRTP keying material, with 3016 the same value again. 3018 Bob receives the SDP session description offer from Alice, which he 3019 accepts, and then generates an answer to Alice: 3021 v=0 3022 o=- 24351 621815 IN IP4 192.0.2.2 3023 s= 3024 t=0 0 3025 c=IN IP4 192.0.2.2 3026 m=audio 54568 RTP/SAVP 98 3027 a=rtpmap:98 AMR/8000 3028 a=crypto:1 AES_CM_128_HMAC_SHA1_32 3029 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 3030 m=video 55468 RTP/SAVPF 31 3031 a=rtpmap:31 H261/90000 3032 a=crypto:1 AES_CM_128_HMAC_SHA1_80 3033 inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32 3034 a=rtcp-fb:* nack 3036 Bob includes the same crypto attribute as before, and the session 3037 proceeds without change. Although Bob did not include any 3038 capabilities in his answer, he could have done so if he wanted to. 3040 Note that in this particular example, the answerer supported the 3041 capability extensions defined here, however had he not, the answerer 3042 would simply have ignored the new attributes received in step 1 and 3043 accepted the offer to use normal RTP. In that case, the following 3044 answer would have been generated in step 2 instead: 3046 v=0 3047 o=- 24351 621814 IN IP4 192.0.2.2 3048 s= 3049 t=0 0 3050 c=IN IP4 192.0.2.2 3051 m=audio 54568 RTP/AVP 98 3052 a=rtpmap:98 AMR/8000 3053 m=video 55468 RTP/AVP 31 3054 a=rtpmap:31 H261/90000 3055 a=rtcp-fb:* nack 3057 Finally, if Bob had chosen to use session-level MIKEY instead of SDP 3058 security descriptions, the following answer would have been 3059 generated: 3061 v=0 3062 o=- 24351 621814 IN IP4 192.0.2.2 3063 s= 3064 t=0 0 3065 c=IN IP4 192.0.2.2 3066 a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyO... 3067 m=audio 54568 RTP/SAVP 98 3068 a=rtpmap:98 AMR/8000 3069 a=acfg:1 t=2 a=1 3070 m=video 55468 RTP/SAVPF 31 3071 a=rtpmap:31 H261/90000 3072 a=rtcp-fb:* nack 3073 a=acfg:1 t=1 a=1,4 3075 It should be noted, that although Bob could have chosen session- 3076 level MIKEY for one media stream, and SDP Security Descriptions for 3077 another media stream, there are no well-defined offerer processing 3078 rules of the resulting answer for this, and hence the offerer may 3079 incorrectly assume use of MIKEY for both streams. To avoid this, if 3080 the answerer chooses session-level MIKEY, then all secure RTP based 3081 media streams SHOULD use MIKEY (this applies irrespective of whether 3082 SDP Capability Negotiation is being used or not). Use of media-level 3083 MIKEY does not have a similar constraint. 3085 4.4. SRTP with Session-Level MIKEY and Media Level Security 3086 Descriptions as Alternatives 3088 The following example illustrates how to use the SDP Capability 3089 Negotiation framework to negotiate use of either MIKEY or SDP 3090 Security Descriptions, when one of them is included as part of the 3091 actual configuration, and the other one is being selected. The 3092 offerer (Alice) wants to establish an audio and video session. Alice 3093 prefers to use session-level MIKEY as the key management protocol, 3094 but supports SDP security descriptions as well. 3096 The example is illustrated by the offer/answer exchange below, where 3097 Alice sends an offer to Bob: 3099 Alice Bob 3101 | (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) | 3102 |--------------------------------------->| 3103 | | 3104 | (2) Answer (RTP/SAVP, SDES) | 3105 |<---------------------------------------| 3106 | | 3108 Alice's offer includes an audio and a video stream. Both the audio 3109 and the video stream offer use of secure RTP: 3111 v=0 3112 o=- 25678 753849 IN IP4 192.0.2.1 3113 s= 3114 t=0 0 3115 c=IN IP4 192.0.2.1 3116 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 3117 m=audio 59000 RTP/SAVP 98 3118 a=rtpmap:98 AMR/8000 3119 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 3120 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 3121 a=pcfg:1 a=-s:1 3122 m=video 52000 RTP/SAVP 31 3123 a=rtpmap:31 H261/90000 3124 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_80 3125 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 3126 a=pcfg:1 a=-s:2 3128 Alice does not know whether Bob supports MIKEY or SDP Security 3129 Descriptions. She could include attributes for both, however the 3130 resulting procedures and potential interactions are not well- 3131 defined. Instead, she places a session-level key-mgmt attribute for 3132 MIKEY in the actual configuration with SDP security descriptions as 3133 an alternative in the potential configuration. The potential 3134 configuration for the audio stream specifies that all session level 3135 attributes are to be deleted (i.e. the session-level "a=key-mgmt" 3136 attribute) and that mandatory attribute capability 2 is to be used 3137 (i.e. the crypto attribute). The potential configuration for the 3138 video stream is similar, except it uses its own mandatory crypto 3139 attribute capability (2). Note how deletion of the session-level 3140 attributes does not affect the media-level attributes. 3142 Bob receives the SDP session description offer from Alice. Bob 3143 supports Secure RTP and the SDP Capability Negotiation framework. 3145 Bob also supports both SDP Security Descriptions and MIKEY. Since 3146 the potential configuration is more preferred than the actual 3147 configuration, Bob (conceptually) generates an internal potential 3148 configuration SDP session description that contains the crypto 3149 attributes for the audio and video stream, but not the key-mgmt 3150 attribute for MIKEY, thereby avoiding any ambiguity between the two 3151 keying mechanisms. As a result, he generates the following answer: 3153 v=0 3154 o=- 24351 621814 IN IP4 192.0.2.2 3155 s= 3156 t=0 0 3157 c=IN IP4 192.0.2.2 3158 m=audio 54568 RTP/SAVP 98 3159 a=rtpmap:98 AMR/8000 3160 a=crypto:1 AES_CM_128_HMAC_SHA1_32 3161 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 3162 a=acfg:1 a=-s:1 3163 m=video 55468 RTP/SAVP 31 3164 a=rtpmap:31 H261/90000 3165 a=crypto:1 AES_CM_128_HMAC_SHA1_80 3166 inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32 3167 a=acfg:1 a=-s:2 3169 For the audio stream, Bob accepted the use of secure RTP using SDP 3170 security descriptions. Bob therefore includes a "crypto" attribute 3171 with his own keying material, and an "acfg" attribute identifying 3172 actual configuration 1 for the audio media stream from the offer, 3173 with the delete-attributes ("-s") and attribute capability 1 (the 3174 crypto attribute from the offer). For the video stream, Bob also 3175 accepted the use of secure RTP using SDP security descriptions. Bob 3176 therefore includes a "crypto" attribute with his own keying 3177 material, and an "acfg" attribute identifying actual configuration 1 3178 for the video stream from the offer, with the delete-attributes ("- 3179 s") and attribute capability 2. 3181 Below, we illustrate the offer SDP session description, when Bob 3182 instead offers the "crypto" attribute as the actual configuration 3183 keying mechanism and "key-mgmt" as the potential configuration: 3185 v=0 3186 o=- 25678 753849 IN IP4 192.0.2.1 3187 s= 3188 t=0 0 3189 c=IN IP4 192.0.2.1 3190 a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 3192 m=audio 59000 RTP/SAVP 98 3193 a=rtpmap:98 AMR/8000 3194 a=crypto:1 AES_CM_128_HMAC_SHA1_32 3195 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 3196 a=acap:2 rtpmap:98 AMR/8000 3197 a=pcfg:1 a=-m:1,2 3198 m=video 52000 RTP/SAVP 31 3199 a=rtpmap:31 H261/90000 3200 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 3201 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 3202 a=acap:4 rtpmap:31 H261/90000 3203 a=pcfg:1 a=-m:1,4 3205 Note how we this time need to perform delete-attributes at the 3206 media-level instead of the session-level. When doing that, all 3207 attributes from the actual configuration SDP session description, 3208 including the rtpmaps provided, are removed. Consequently, we had to 3209 include these rtpmaps as capabilities as well, and then include them 3210 in the potential configuration, thereby effectively recreating the 3211 original rtpmap attributes in the resulting potential configuration 3212 SDP session description. 3214 5. Security Considerations 3216 The SDP Capability Negotiation Framework is defined to be used 3217 within the context of the offer/answer model, and hence all the 3218 offer/answer security considerations apply here as well [RFC3264]. 3219 Similarly, the Session Initiation Protocol (SIP) uses SDP and the 3220 offer/answer model, and hence, when used in that context, the SIP 3221 security considerations apply as well [RFC3261]. 3223 However, SDP Capability Negotiation introduces additional security 3224 issues. Its use as a mechanism to enable alternative transport 3225 protocol negotiation (secure and non-secure) as well as its ability 3226 to negotiate use of more or less secure keying methods and material 3227 warrant further security considerations. Also, the (continued) 3228 support for receiving media before answer combined with negotiation 3229 of alternative transport protocols (secure and non-secure) warrant 3230 further security considerations. We discuss these issues below. 3232 The SDP Capability Negotiation framework allows for an offered media 3233 stream to both indicate and support various levels of security for 3234 that media stream. Different levels of security can for example be 3235 negotiated by use of alternative attribute capabilities each 3236 indicating more or less secure keying methods as well as more or 3237 less strong ciphers. Since the offerer indicates support for each of 3238 these alternatives, he will presumably accept the answerer seemingly 3239 selecting any of the offered alternatives. If an attacker can modify 3240 the SDP session description offer, he can thereby force the 3241 negotiation of the weakest security mechanism that the offerer is 3242 willing to accept. This may enable the attacker to compromise the 3243 security of the negotiated media stream. Similarly, if the offerer 3244 wishes to negotiate use of a secure media stream (e.g. secure RTP), 3245 but includes a non-secure media stream (e.g. plain RTP) as a valid 3246 (but less preferred) alternative, then an attacker that can modify 3247 the offered SDP session description will be able to force the 3248 establishment of an insecure media stream. The solution to both of 3249 these problems involves the use of integrity protection over the SDP 3250 session description. Ideally, this integrity protection provides 3251 end-to-end integrity protection in order to protect from any man-in- 3252 the-middle attack; secure multiparts such as S/MIME [RFC5751] 3253 provide one such solution, however S/MIME requires use and 3254 availability of a Public Key Infrastructure (PKI). A slightly less 3255 secure alternative when using SIP, but generally much easier to 3256 deploy in practice, is to use SIP Identity [RFC4474]; this requires 3257 the existence of an authentication service (see [RFC4474]). Although 3258 this mechanism still requires a PKI, it only requires that servers 3259 (as opposed to end-users) have third party validatable certificates, 3260 which significantly reduces the barrier to entry by ordinary users. 3261 Yet another, and considerably less secure, alternative is to use 3262 hop-by-hop security only, e.g. TLS or IPsec thereby ensuring the 3263 integrity of the offered SDP session description on a hop-by-hop 3264 basis. This is less secure because SIP allows partially trusted 3265 intermediaries on the signaling path, and such intermediaries 3266 processing the SIP request at each hop would be able to perform a 3267 man-in- the-middle attack by modifying the offered SDP session 3268 description. In simple architectures where the two UA's proxies 3269 communicate directly, the security provided by this method is 3270 roughly comparable to that provided by the previously discussed 3271 signature-based mechanisms. 3273 Per the normal offer/answer procedures, as soon as the offerer has 3274 generated an offer, the offerer must be prepared to receive media in 3275 accordance with that offer. The SDP Capability Negotiation preserves 3276 that behavior for the actual configuration in the offer, however the 3277 offerer has no way of knowing which configuration (actual or 3278 potential) configuration was selected by the offerer, until an 3279 answer indication is received. This opens up a new security issue 3280 where an attacker may be able to interject media towards the offerer 3281 until the answer is received. For example, the offerer may use plain 3282 RTP as the actual configuration and secure RTP as an alternative 3283 potential configuration. Even though the answerer selects secure 3284 RTP, the offerer will not know that until he receives the answer, 3285 and hence an attacker will be able to send media to the offerer 3286 meanwhile. The easiest protection against such an attack is to not 3287 offer use of the non-secure media stream in the actual 3288 configuration, however that may in itself have undesirable side- 3289 effects: If the answerer does not support the secure media stream 3290 and also does not support the capability negotiation framework, then 3291 negotiation of the media stream will fail. Alternatively, SDP 3292 security preconditions [RFC5027] can be used. This will ensure that 3293 media is not flowing until session negotiation has completed and 3294 hence the selected configuration is known. Use of preconditions 3295 however requires both sides to support them. If they don't, and use 3296 of them is required, the session will fail. As a (limited) work 3297 around to this, it is RECOMMENDED that SIP entities generate an 3298 answer SDP session description and send it to the offerer as soon as 3299 possible, for example in a 183 Session Progress message. This will 3300 limit the time during which an attacker can send media to the 3301 offerer. Section 3.9. presents other alternatives as well. 3303 Additional security considerations apply to the answer SDP session 3304 description as well. The actual configuration attribute tells the 3305 offerer which potential configuration the answer was based on, and 3306 hence an attacker that can either modify or remove the actual 3307 configuration attribute in the answer can cause session failure as 3308 well as extend the time window during which the offerer will accept 3309 incoming media that does not conform to the actual answer. The 3310 solutions to this SDP session description answer integrity problem 3311 are the same as for the offer, i.e. use of end-to-end integrity 3312 protection, SIP identity, or hop-by-hop protection. The mechanism to 3313 use depends on the mechanisms supported by the offerer as well as 3314 the acceptable security trade-offs. 3316 As described in Section 3.1. and 3.11. , SDP Capability Negotiation 3317 conceptually allows an offerer to include many different offers in a 3318 single SDP session description. This can cause the answerer to 3319 process a large number of alternative potential offers, which can 3320 consume significant memory and CPU resources. An attacker can use 3321 this amplification feature to launch a denial of service attack 3322 against the answerer. The answerer must protect itself from such 3323 attacks. As explained in Section 3.11. , the answerer can help 3324 reduce the effects of such an attack by first discarding all 3325 potential configurations that contain unsupported transport 3326 protocols, unsupported or invalid mandatory attribute capabilities, 3327 or unsupported mandatory extension configurations. The answerer 3328 should also look out for potential configurations that are designed 3329 to pass the above test, but nevertheless produce a large number of 3330 potential configuration SDP session descriptions that cannot be 3331 supported. 3333 A possible way of achieving that is for an attacker to find a 3334 valid session-level attribute that causes conflicts or otherwise 3335 interferes with individual media description configurations. At 3336 time of publication of this document, we do not know of such an 3337 SDP attribute, however this does not mean it does not exist, or 3338 that it will not exist in the future. If such attributes are found 3339 to exist, implementers should explicitly protect against them. 3341 A significant number of valid and supported potential configurations 3342 may remain. However, since all of those contain only valid and 3343 supported transport protocols and attributes, it is expected that 3344 only a few of them will need to be processed on average. Still, the 3345 answerer must ensure that it does not needlessly consume large 3346 amounts of memory or CPU resources when processing those as well as 3347 be prepared to handle the case where a large number of potential 3348 configurations still need to be processed. 3350 6. IANA Considerations 3352 6.1. New SDP Attributes 3354 The IANA is hereby requested to register the following new SDP 3355 attributes as follows: 3357 Attribute name: csup 3358 Long form name: Supported capability negotiation extensions 3359 Type of attribute: Session-level and media-level 3360 Subject to charset: No 3361 Purpose: Option tags for supported SDP capability 3362 negotiation extensions 3363 Appropriate values: See Section 3.3.1. of RFCXXXX 3364 -- Note to RFC editor: 3365 -- replace RFCXXXX by this RFC number 3366 Contact name: Flemming Andreasen, fandreas@cisco.com 3368 Attribute name: creq 3369 Long form name: Required capability negotiation extensions 3370 Type of attribute: Session-level and media-level 3371 Subject to charset: No 3372 Purpose: Option tags for required SDP capability 3373 negotiation extensions 3374 Appropriate values: See Section 3.3.2. of RFCXXXX 3375 -- Note to RFC editor: 3377 -- replace RFCXXXX by this RFC number 3378 Contact name: Flemming Andreasen, fandreas@cisco.com 3380 Attribute name: acap 3381 Long form name: Attribute capability 3382 Type of attribute: Session-level and media-level 3383 Subject to charset: No 3384 Purpose: Attribute capability containing an attribute 3385 name and associated value 3386 Appropriate values: See Section 3.4.1. of RFCXXXX 3387 -- Note to RFC editor: 3388 -- replace RFCXXXX by this RFC number 3389 Contact name: Flemming Andreasen, fandreas@cisco.com 3391 Attribute name: tcap 3392 Long form name: Transport Protocol Capability 3393 Type of attribute: Session-level and media-level 3394 Subject to charset: No 3395 Purpose: Transport protocol capability listing one or 3396 more transport protocols 3397 Appropriate values: See Section 3.4.2. of RFCXXXX 3398 -- Note to RFC editor: 3399 -- replace RFCXXXX by this RFC number 3400 Contact name: Flemming Andreasen, fandreas@cisco.com 3402 Attribute name: pcfg 3403 Long form name: Potential Configuration 3404 Type of attribute: Media-level 3405 Subject to charset: No 3406 Purpose: Potential configuration for SDP capability 3407 negotiation 3408 Appropriate values: See Section 3.5.1. of RFCXXXX 3409 -- Note to RFC editor: 3410 -- replace RFCXXXX by this RFC number 3411 Contact name: Flemming Andreasen, fandreas@cisco.com 3413 Attribute name: acfg 3414 Long form name: Actual configuration 3415 Type of attribute: Media-level 3416 Subject to charset: No 3417 Purpose: Actual configuration for SDP capability 3418 negotiation 3419 Appropriate values: See Section 3.5.2. of RFCXXXX 3420 -- Note to RFC editor: 3422 -- replace RFCXXXX by this RFC number 3423 Contact name: Flemming Andreasen, fandreas@cisco.com 3425 6.2. New SDP Capability Negotiation Option Tag Registry 3427 The IANA is hereby requested to create a new SDP Capability 3428 Negotiation Option Tag registry. An IANA SDP Capability Negotiation 3429 option tag registration MUST be documented in an RFC in accordance 3430 with the [RFC5226] IETF Review policy. The RFC MUST provide the name 3431 of the option tag, a syntax and a semantic specification of any new 3432 SDP attributes and any extensions to the potential configuration 3433 ("a=pcfg") and actual configuration ("a=acfg") attributes provided 3434 in this document. If the extension defines any new SDP attributes 3435 that are intended to be capabilities for use by the capability 3436 negotiation framework (similar to e.g. "a=acap"), those capabilities 3437 MUST adhere to the guidelines provided in Section 3.4.3. Extensions 3438 to the potential and actual configuration attributes MUST adhere to 3439 the syntax provided in Section 3.5.1. and 3.5.2. 3441 The option tag "cap-v0" is defined in this document and the IANA is 3442 hereby requested to register this option tag. 3444 6.3. New SDP Capability Negotiation Potential Configuration Parameter 3445 Registry 3447 The IANA is hereby requested to create a new SDP Capability 3448 Negotiation Potential Configuration Parameter registry. An IANA SDP 3449 Capability Negotiation potential configuration registration MUST be 3450 documented in an RFC in accordance with the [RFC5226] IETF Review 3451 policy. The RFC MUST define the syntax and semantics of each new 3452 potential configuration parameter. The syntax MUST adhere to the 3453 syntax provided for extensions in Section 3.5.1. and the semantics 3454 MUST adhere to the semantics provided for extensions in Section 3455 3.5.1. and 3.5.2. Associated with each registration MUST be the 3456 encoding name for the parameter as well as a short descriptive name 3457 for it. 3459 The potential configuration parameters "a" for "attribute" and "t" 3460 for "transport protocol" are defined in this document and the IANA 3461 is hereby requested to register these. 3463 7. Acknowledgments 3465 The SDP Capability Negotiation solution defined in this document 3466 draws on the overall capability negotiation framework that was 3467 defined by [SDPng]. Also, the SDP Capability Negotiation solution is 3468 heavily influenced by the discussions and work done by the SDP 3469 Capability Negotiation Design Team. The following people in 3470 particular provided useful comments and suggestions to either the 3471 document itself or the overall direction of the solution defined in 3472 here: Francois Audet, John Elwell, Roni Even, Miguel Garcia, Robert 3473 Gilman, Cullen Jennings, Jonathan Lennox, Matt Lepinski, Jean- 3474 Francois Mule, Joerg Ott, Colin Perkins, Jonathan Rosenberg, Thomas 3475 Stach, and Dan Wing. 3477 General Area review comments were provided by Christian Vogt, and 3478 Stephen Kent provided Security Directorate review comments. Eric 3479 Rescorla provided textual input to the Security Considerations. 3480 Alexey Melnikov, Robert Sparks, and Magnus Westerlund provided 3481 several review comments as well. 3483 8. Change Log 3485 8.1. draft-ietf-mmusic-sdp-capability-negotiation-12 3487 Addressing IESG review comments as follows: 3489 o Clarified processing rules for "creq" in Section 3.3.2. 3491 o Removed "iptv_rtsp" example in Section 3.4.2. 3493 o Fixed ABNF error in "attribute-config-list". 3495 o Changed ICE [ICE] reference from informative to normative. 3497 o Minor editorial changes. 3499 8.2. draft-ietf-mmusic-sdp-capability-negotiation-11 3501 Addressing IESG review comments as follows: 3503 o Changed att-cap-num and trpr-cap-num ABNF rules throughout to 3504 allow for no more than 10 digits. 3506 o Disallowed base framework only implementations from generating 3507 media-level attribute capabilities at the session-level, and 3508 added explicit rules for how to process them if received. 3510 o Disallowed attribute capabilities from embedding capability 3511 negotiation parameters and discouraged extension capabilities 3512 from similar behavior. Also specified non-recursive processing of 3513 capabilities on the receive side as a safeguard. 3515 o Clarified that the "tcap" attribute specifies only the transport 3516 protocol, however some MIME types can be viewed as transports as 3517 well. The base framework does not define how to negotiate those 3518 as transports, but rather only as media formats that must be 3519 valid under the transport protocol for the media description. 3521 o Changed definition (and ABNF) for attribute-config-list to allow 3522 for only delete-attributes (i.e., no attribute capabilities) 3524 o Clarified that playout of early media before answer is not a 3525 requirement. 3527 o Clarified various offer/answer aspects related to generation of 3528 potential configuration offer SDP session descriptions and 3529 virtual answer SDP session descriptions as well as operation of 3530 delete-attributes. 3532 o Defined the notion of a "valid" actual configuration and how it 3533 affects offerer processing of the answer. 3535 o Removed recommendation to use the TIAS bandwidth type [RFC3890] 3536 and added note explaining why it should not be used. 3538 o Changed IANA rules for new option tags and potential 3539 configuration parameters to follow "IETF Review" policy, and 3540 clarified that potential configuration parameters must be 3541 registered with IANA. 3543 o Changed numerous instances of "SDP" with the more accurate "SDP 3544 session description" to avoid terminology overload. 3546 o Various editorial clarifications throughout. 3548 8.3. draft-ietf-mmusic-sdp-capability-negotiation-10 3550 Addressing General Area and Security Directorate review comments as 3551 follows: 3553 o Explained and motivated the preference order between potential 3554 and actual configurations earlier in the document. 3556 o Added DTLS-SRTP example use in several places, as well as a new 3557 example call flow for DTLS-SRTP. 3559 o Added that interacting session-level attributes in potential 3560 configurations, which do not provide well-defined operation on 3561 the receiving side, cannot be used in security critical contexts. 3563 o Updated Security Considerations section. 3565 o Rephrased several sentences containing the word "only" to improve 3566 readability. 3568 o Minor editorial nit fixes, especially in the example call flows. 3570 8.4. draft-ietf-mmusic-sdp-capability-negotiation-09 3572 Incorporated Working Group Chair review comments and a few additional 3573 comments as follows: 3575 o Clarified that the "a=creq" attribute MUST NOT be used in an 3576 answer (Section 3.6.2. ). 3578 o Various editorial changes throughout. 3580 8.5. draft-ietf-mmusic-sdp-capability-negotiation-08 3582 Incorporated Working Group Last Call comments as follows: 3584 o Added second offer/answer exchange to introductory example, fixed 3585 minor error in that example, and deleted similar example in the 3586 Examples Section. 3588 o Fixed "type=value" semantic error in the attribute capability 3589 definition. 3591 o Clarified that consecutive numbering of capabilities and 3592 potential configurations is not required. 3594 o Fixed inconsistency for which parameters to include in the "acfg" 3595 attribute. 3597 o Changed second offer/answer exchange from MAY to SHOULD strength. 3599 o Clarified there should be a combined second offer/exchange when 3600 using ICE. 3602 o Moved RFC 3407 to informative references. 3604 o Various editorial clarifications. 3606 8.6. draft-ietf-mmusic-sdp-capability-negotiation-07 3608 o Removed the ability to have attribute capabilities provide 3609 attribute names without values, when those attributes otherwise 3610 require an associated value. 3612 o Document no longer obsoletes RFC 3407 but instead recommends that 3613 it is being used instead of RFC 3407. 3615 o Added ability to specific that specific extensions in a potential 3616 configuration are mandatory. 3618 o Changed ABNF for extension-config-list in potential 3619 configurations. 3621 o Removed the redundant "a=" part of attribute capabilities. 3623 o Clarified what it means to support an attribute capability in the 3624 offer/answer procedures. 3626 o Changed "a=acap" attribute and offer/answer procedures to include 3627 only the known and supported attribute capabilities. 3629 o Added new section on indicating bandwidth usage. 3631 8.7. draft-ietf-mmusic-sdp-capability-negotiation-06 3633 o Added additional background text on terminology used, and a new 3634 section on the negotiation model. 3636 o Allowed for session-level attribute capabilities to contain 3637 media-level only attributes, albeit the base framework does not 3638 define (or allow) them to be used in a potential configuration 3639 (extensions may change that) 3641 o Disallowing multiple "a=tcap" attributes at the session-level 3642 and/or on a per media description basis; at most one at the 3643 session-level and per media description now. 3645 o Changed the "a=pcfg" attribute to make a potential configuration 3646 list optional in order to allow for the actual configuration to 3647 be referenced. 3649 o Removed the ability to delete and replace individual attributes 3650 from the actual configuration SDP session description. 3652 o Introduced the notion of mandatory and optional attribute 3653 capabilities in a potential configuration and updated the 3654 "a=pcfg" attribute and associated procedures accordingly. 3656 o Specified that mandatory attribute capabilities and the transport 3657 protocol (if any) from a potential configuration need to be 3658 supported in order to select that potential configuration. 3659 Offer/answer procedures updated accordingly as well. 3661 o Noted potential interaction and synchronization issues with use 3662 of session-level attributes and attribute capabilities and added 3663 recommendation to avoid use of session-level attributes when 3664 possible. 3666 o Fixed error in "a=acfg" grammar (missing config-number) and 3667 updated attribute definition in accordance with the "a=pcfg" 3668 attribute changes. 3670 o Updated text associated with processing media before answer to 3671 allow for playing out garbage or discard until answer received. 3672 Additional detail on alternative solutions provided as well. 3674 o Added recommendation to send back answer SDP session description 3675 as soon as possible, when a potential configuration different 3676 from the actual configuration has been chosen. 3678 o Added new section on interactions with SIP option tags. 3680 o Added new section on dealing with large number of potential 3681 configurations. 3683 o Added new section on SDP capability negotiation and 3684 intermediaries. 3686 o Updated examples in accordance with other changes and to 3687 illustrate use of mandatory and optional attribute capabilities 3688 in a potential configuration. 3690 o Updated security considerations to address potential denial of 3691 service attack caused by large number of potential 3692 configurations. 3694 o Various editorial updates throughout. 3696 8.8. draft-ietf-mmusic-sdp-capability-negotiation-05 3698 o Allowed for '=' attributes to be listed as attribute 3699 capabilities the attribute name only. 3701 o Changed IP-address to conform to RFC 3330 guidelines. 3703 o Added section on relationship to RFC 3407 and "Obsoletes: 3407" 3704 in the front. 3706 o Disallowed use of white space in a number of places for more 3707 consistency with existing SDP practice 3709 o Changed "csup" and "creq" attributes to not allow multiple 3710 instances at the session-level and multiple instances per media 3711 description (only one for each now) 3713 o Changed to not require use of "creq" with base option tag ("cap- 3714 v0"). 3716 o Relaxed restrictions on extension capabilities 3718 o Updated potential configuration attribute syntax and semantics. 3719 In particular, potential configuration attributes can now replace 3720 and delete various existing attributes in original SDP session 3721 descriptions to better control potential attribute interactions 3722 with the actual configuration while preserving message size 3723 efficiency. 3725 o Updated actual configuration attribute to align with the updates 3726 to the potential configuration attributes. 3728 o Updated offer/answer procedures to align with other changes. 3730 o Changed recommendation for second offer/answer exchange to "MAY" 3731 strength, unless for the cases where it is known or suspected 3732 that it is needed. 3734 o Updated ICE interactions to explain how the new attribute 3735 delete/replace features can solve certain potential interactions. 3737 o Updated rtpmap and fmtp section to allow potential configurations 3738 to use remapped payload types in attribute capabilities for 3739 rtpmaps and fmtp parameters. 3741 o Added section on direction attributes. 3743 o Added another example showing SRTP with session-level MIKEY and 3744 SDP Security Descriptions using the attribute capability DELETE 3745 operator. 3747 8.9. draft-ietf-mmusic-sdp-capability-negotiation-04 3749 The following are the major changes compared to version -03: 3751 o Added explicit ordering rules for attributes added by potential 3752 configurations. 3754 o Noted that ICE interaction issues (ice-tcp specifically) may not 3755 be as clear as originally thought. 3757 o Added considerations on using rtpmap and fmtp attributes as 3758 attribute capabilities. 3760 o Added multiple transport protocol example. 3762 o Added session-level MIKEY and media level security descriptions 3763 example. 3765 8.10. draft-ietf-mmusic-sdp-capability-negotiation-03 3767 The following are the major changes compared to version -02: 3769 o Base option tag name changed from "v0" to "cap-v0". 3771 o Added new section on extension capability attributes 3773 o Firmed up offer/answer procedures. 3775 o Added security considerations 3777 o Added IANA considerations 3779 8.11. draft-ietf-mmusic-sdp-capability-negotiation-02 3781 The following are the major changes compared to version -01: 3783 o Potential configurations are no longer allowed at the session 3784 level 3786 o Renamed capability attributes ("capar" to "acap" and "ctrpr" to 3787 "tcap") 3789 o Changed name and semantics of the initial number (now called 3790 configuration number) in potential configuration attributes; must 3791 now be unique and can be used as a handle 3793 o Actual configuration attribute now includes configuration number 3794 from the selected potential configuration attribute 3796 o Added ABNF throughout 3798 o Specified that answerer should include "a=csup" in case of 3799 unsupported required extensions in offer. 3801 o Specified use of second offer/answer exchange when answerer 3802 selected a potential configuration 3804 o Updated rules (and added restrictions) for referencing media- and 3805 session-level capabilities in potential configurations (at the 3806 media level) 3808 o Added initial section on ICE interactions 3810 o Added initial section on receiving media before answer 3812 8.12. draft-ietf-mmusic-sdp-capability-negotiation-01 3814 The following are the major changes compared to version -00: 3816 o Media capabilities are no longer considered a core capability and 3817 hence have been removed. This leaves transport protocols and 3818 attributes as the only capabilities defined by the core. 3820 o Version attribute has been removed and an option tag to indicate 3821 the actual version has been defined instead. 3823 o Clarified rules for session-level and media level attributes 3824 provided at either level as well how they can be used in 3825 potential configurations. 3827 o Potential configuration parameters no longer have implicit 3828 ordering; an explicit preference indicator is now included. 3830 o The parameter name for transport protocols in the potential and 3831 actual configuration attributes have been changed "p" to "t". 3833 o Clarified operator precedence within potential and actual 3834 configuration attributes. 3836 o Potential configurations at the session level now limited to 3837 indicate latent capability configurations. Consequently, an 3838 actual configuration attribute can no longer be provided at the 3839 session level. 3841 o Cleaned up capability and potential configuration terminology - 3842 they are now two clearly different things. 3844 8.13. draft-ietf-mmusic-sdp-capability-negotiation-00 3846 Version 00 is the initial version. The solution provided in this 3847 initial version is based on an earlier (individual submission) 3848 version of [SDPCapNeg]. The following are the major changes compared 3849 to that document: 3851 o Solution no longer based on RFC 3407, but defines a set of 3852 similar attributes (with some differences). 3854 o Various minor changes to the previously defined attributes. 3856 o Multiple transport capabilities can be included in a single 3857 "tcap" attribute 3859 o A version attribute is now included. 3861 o Extensions to the framework are formally supported. 3863 o Option tags and the ability to list supported and required 3864 extensions are supported. 3866 o A best-effort SRTP example use case has been added. 3868 o Some terminology change throughout to more clearly indicate what 3869 constitutes capabilities and what constitutes configurations. 3871 9. References 3873 9.1. Normative References 3875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3876 Requirement Levels", BCP 14, RFC 2119, March 1997. 3878 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 3879 with Session Description Protocol (SDP)", RFC 3264, June 3880 2002. 3882 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3883 Description Protocol", RFC 4566, July 2006. 3885 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3886 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3887 May 2008. 3889 [RFC5234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 3890 Specifications: ABNF", RFC 5234, January 2008. 3892 [ICE] J. Rosenberg, "Interactive Connectivity Establishment 3893 (ICE): A Methodology for Network Address Translator (NAT) 3894 Traversal for Offer/Answer Protocols", work in progress, 3895 October 2007. 3897 9.2. Informative References 3899 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3900 A., Peterson, J., Sparks, R., Handley, M., and E. 3901 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3902 June 2002. 3904 [RFC3312] G. Camarillo, W. Marshall, and J. Rosenberg, "Integration 3905 of Resource Management and Session Initiation Protocol 3906 (SIP)", RFC 3312, October 2002. 3908 [RFC3262] J. Rosenberg, and H. Schulzrinne, "Reliability of 3909 Provisional Responses in Session Initiation Protocol 3910 (SIP)", RFC 3262, June 2002. 3912 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 3913 Schulzrinne, "Grouping of Media Lines in the Session 3914 Description Protocol (SDP)", RFC 3388, December 2002. 3916 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 3917 Capability Declaration", RFC 3407, October 2002. 3919 [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and 3920 Video Conferences with Minimal Control", RFC 3551, July 3921 2003. 3923 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 3924 Norrman, "The Secure Real-time Transport Protocol 3925 (SRTP).", RFC 3711, March 2004. 3927 [RFC3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 3928 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 3929 August 2004. 3931 [RFC3890] M. Westerlund, "A Transport Independent Bandwidth Modifier 3932 for the Session Description Protocol (SDP).", RFC 3890, 3933 September 2004. 3935 [RFC4145] Yon, D., and G. Camarillo, "TCP-Based Media Transport in 3936 the Session Description Protocol (SDP)", RFC 4145, 3937 September 2005. 3939 [RFC4474] J. Peterson, and C. Jennings, "Enhancements for 3940 Authenticated Identity Management in the Session 3941 Initiation Protocol (SIP)", RFC 4474, August 2006. 3943 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 3944 Carrara, "Key Management Extensions for Session 3945 Description Protocol (SDP) and Real Time Streaming 3946 Protocol (RTSP)", RFC 4567, July 2006. 3948 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 3949 Description Protocol Security Descriptions for Media 3950 Streams", RFC 4568, July 2006. 3952 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 3953 "Extended RTP Profile for Real-Time Transport Control 3954 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 3955 2006. 3957 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 3958 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 3959 July 2006. 3961 [RFC4756] A. Li, "Forward Error Correction Grouping Semantics in 3962 Session Description Protocol", RFC 4756, November 2006. 3964 [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for 3965 Session Description Protocol Media Streams", RFC 5027, 3966 October 2007. 3968 [RFC5124] Ott, J., and E Carrara, "Extended Secure RTP Profile for 3969 Real-time Transport Control Protocol (RTCP)-Based Feedback 3970 (RTP/SAVPF)", RFC 5124, February 2008. 3972 [RFC5751] Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet 3973 Mail Extensions (S/MIME) Version 3.2 Message 3974 Specification", RFC 5751, January 2010. 3976 [BESRTP] Kaplan, H., and F. Audet, "Session Description Protocol 3977 (SDP) Offer/Answer Negotiation for Best-Effort Secure 3978 Real-Time Transport Protocol", work in progress, October 3979 2006. 3981 [DTLS-SRTP] McGrew, D. and E. Rescorla, "Datagram Transport Layer 3982 Security (DTLS) Extension to Establish Keys for Secure 3983 Real-time Transport Protocol (SRTP)", work in progress, 3984 February 2009. 3986 [DTLS-SRTP-FRAMEWORK] Fischl, J., Tschofenig, H., and E. Rescorla, 3987 "Framework for Establishing an SRTP Security Context using 3988 DTLS", work in progress, March 2009. 3990 [ICETCP] J. Rosenberg, "TCP Candidates with Interactive 3991 Connectivity Establishment (ICE)", work in progress, 3992 October 2009. 3994 [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", (draft- 3995 andreasen-mmusic-sdp-capability-negotiation-01.txt), work 3996 in progress, December 2006. 3998 [SDPMedCap] Gilman, R, Even, R., and F. Andreasen "SDP Media 3999 Capabilities Negotiation", work in progress, July 2009. 4001 [SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session 4002 Description and Capability Negotiation", Work in Progress, 4003 February 2005. 4005 Author's Address 4007 Flemming Andreasen 4008 Cisco Systems 4009 Iselin, NJ 08830 4010 USA 4012 Email: fandreas@cisco.com