idnits 2.17.1 draft-ietf-mmusic-sdp-capability-negotiation-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 14, 2010) is 5175 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 3104, but not defined == Missing Reference: 'F' is mentioned on line 3104, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- 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 (==), 7 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 14, 2010 5 Expires: August 2010 7 SDP Capability Negotiation 8 draft-ietf-mmusic-sdp-capability-negotiation-11.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 14, 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............................7 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-11..........78 136 8.2. draft-ietf-mmusic-sdp-capability-negotiation-10..........79 137 8.3. draft-ietf-mmusic-sdp-capability-negotiation-09..........80 138 8.4. draft-ietf-mmusic-sdp-capability-negotiation-08..........80 139 8.5. draft-ietf-mmusic-sdp-capability-negotiation-07..........80 140 8.6. draft-ietf-mmusic-sdp-capability-negotiation-06..........81 141 8.7. draft-ietf-mmusic-sdp-capability-negotiation-05..........82 142 8.8. draft-ietf-mmusic-sdp-capability-negotiation-04..........83 143 8.9. draft-ietf-mmusic-sdp-capability-negotiation-03..........84 144 8.10. draft-ietf-mmusic-sdp-capability-negotiation-02.........84 145 8.11. draft-ietf-mmusic-sdp-capability-negotiation-01.........85 146 8.12. draft-ietf-mmusic-sdp-capability-negotiation-00.........86 147 9. References....................................................87 148 9.1. Normative References.....................................87 149 9.2. Informative References...................................87 150 Author's Address.................................................90 152 1. Introduction 154 The Session Description Protocol (SDP) was intended for describing 155 multimedia sessions for the purposes of session announcement, 156 session invitation, and other forms of multimedia session 157 initiation. A SDP session description contains one or more media 158 stream descriptions with information such as IP-address and port, 159 type of media stream (e.g. audio or video), transport protocol 160 (possibly including profile information, e.g. RTP/AVP or RTP/SAVP), 161 media formats (e.g. codecs), and various other session and media 162 stream parameters that define the session. 164 Simply providing media stream descriptions is sufficient for session 165 announcements for a broadcast application, where the media stream 166 parameters are fixed for all participants. When a participant wants 167 to join the session, he obtains the session announcement and uses 168 the media descriptions provided, e.g., joins a multicast group and 169 receives media packets in the encoding format specified. If the 170 media stream description is not supported by the participant, he is 171 unable to receive the media. 173 Such restrictions are not generally acceptable to multimedia session 174 invitations, where two or more entities attempt to establish a media 175 session, that uses a set of media stream parameters acceptable to 176 all participants. First of all, each entity must inform the other of 177 its receive address, and secondly, the entities need to agree on the 178 media stream parameters to use for the session, e.g. transport 179 protocols and codecs. To solve this, RFC 3264 [RFC3264] defined the 180 offer/answer model, whereby an offerer constructs an offer SDP 181 session description that lists the media streams, codecs, and other 182 SDP parameters that the offerer is willing to use. This offer 183 session description is sent to the answerer, which chooses from 184 among the media streams, codecs and other session description 185 parameters provided, and generates an answer session description 186 with his parameters, based on that choice. The answer session 187 description is sent back to the offerer thereby completing the 188 session negotiation and enabling the establishment of the negotiated 189 media streams. 191 Taking a step back, we can make a distinction between the 192 capabilities supported by each participant, the way in which those 193 capabilities can be supported, and the parameters that can actually 194 be used for the session. More generally, we can say that we have the 195 following: 197 o A set of capabilities for the session and its associated media 198 stream components, supported by each side. The capability 199 indications by themselves do not imply a commitment to use the 200 capabilities in the session. 202 Capabilities can for example be that the "RTP/SAVP" profile is 203 supported, that the "PCMU" codec is supported, or that the 204 "crypto" attribute is supported with a particular value. 206 o A set of potential configurations indicating which combinations 207 of those capabilities can be used for the session and its 208 associated media stream components. Potential configurations are 209 not ready for use. Instead, they provide an alternative that may 210 be used, subject to further negotiation. 212 A potential configuration can for example indicate that the 213 "PCMU" codec and the "RTP/SAVP" transport protocol are not only 214 supported (i.e. listed as capabilities), but they are offered for 215 potential use in the session. 217 o An actual configuration for the session and its associated media 218 stream components, that specifies which combinations of session 219 parameters and media stream components can be used currently and 220 with what parameters. Use of an actual configuration does not 221 require any further negotiation. 223 An actual configuration can for example be that the "PCMU" codec 224 and the "RTP/SAVP" transport protocol are offered for use 225 currently. 227 o A negotiation process that takes the set of actual and potential 228 configurations (combinations of capabilities) as input and 229 provides the negotiated actual configurations as output. 231 SDP by itself was designed to provide only one of these, namely 232 listing of the actual configurations, however over the years, use of 233 SDP has been extended beyond its original scope. Of particular 234 importance are the session negotiation semantics that were defined 235 by the offer/answer model in RFC 3264. In this model, both the offer 236 and the answer contain actual configurations; separate capabilities 237 and potential configurations are not supported. 239 Other relevant extensions have been defined as well. RFC 3407 240 [RFC3407] defined simple capability declarations, which extends SDP 241 with a simple and limited set of capability descriptions. Grouping 242 of media lines, which defines how media lines in SDP can have other 243 semantics than the traditional "simultaneous media streams" 244 semantics, was defined in RFC 3388 [RFC3388], etc. 246 Each of these extensions was designed to solve a specific limitation 247 of SDP. Since SDP had already been stretched beyond its original 248 intent, a more comprehensive capability declaration and negotiation 249 process was intentionally not defined. Instead, work on a "next 250 generation" of a protocol to provide session description and 251 capability negotiation was initiated [SDPng]. SDPng defined a 252 comprehensive capability negotiation framework and protocol that was 253 not bound by existing SDP constraints. SDPng was not designed to be 254 backwards compatible with existing SDP and hence required both sides 255 to support it, with a graceful fallback to legacy operation when 256 needed. This, combined with lack of ubiquitous multipart MIME 257 support in the protocols that would carry SDP or SDPng, made it 258 challenging to migrate towards SDPng. In practice, SDPng has not 259 gained traction and as of the time of publication of this document, 260 work on SDPng has stopped. Existing real-time multimedia 261 communication protocols such as SIP, RTSP, Megaco, and MGCP continue 262 to use SDP. However, SDP does not address an increasingly important 263 problem: the ability to negotiate one or more alternative transport 264 protocols (e.g., RTP profiles) and associated parameters (e.g. SDP 265 attributes). This makes it difficult to deploy new RTP profiles 266 such as secure RTP (SRTP) [RFC3711], RTP with RTCP-Based Feedback 267 [RFC4585], etc. The problem is exacerbated by the fact that RTP 268 profiles are defined independently. When a new profile is defined 269 and N other profiles already exist, there is a potential need for 270 defining N additional profiles, since profiles cannot be combined 271 automatically. For example, in order to support the plain and 272 secure RTP version of RTP with and without RTCP-based feedback, four 273 separate profiles (and hence profile definitions) are needed: 274 RTP/AVP [RFC3551], RTP/SAVP [RFC3711], RTP/AVPF [RFC4585], and 275 RTP/SAVPF [RFC5124]. In addition to the pressing profile 276 negotiation problem, other important real-life limitations have been 277 found as well. Keying material and other parameters for example need 278 to be negotiated with some of the transport protocols, but not 279 others. Similarly, some media formats and types of media streams 280 need to negotiate a variety of different parameters. 282 The purpose of this document is to define a mechanism that enables 283 SDP to provide limited support for indicating capabilities and their 284 associated potential configurations, and negotiate the use of those 285 potential configurations as actual configurations. It is not the 286 intent to provide a full-fledged capability indication and 287 negotiation mechanism along the lines of SDPng or ITU-T H.245. 288 Instead, the focus is on addressing a set of well-known real-life 289 limitations. More specifically, the solution provided in this 290 document provides a general SDP Capability Negotiation framework 291 that is backwards compatible with existing SDP. It also defines 292 specifically how to provide attributes and transport protocols as 293 capabilities and negotiate them using the framework. Extensions for 294 other types of capabilities (e.g. media types and formats) may be 295 provided in other documents. 297 As mentioned above, SDP is used by several protocols, and hence the 298 mechanism should be usable by all of these. One particularly 299 important protocol for this problem is the Session Initiation 300 Protocol (SIP) [RFC3261]. SIP uses the offer/answer model [RFC3264] 301 (which is not specific to SIP) to negotiate sessions and hence the 302 mechanism defined here provides the offer/answer procedures to use 303 for the capability negotiation framework. 305 The rest of the document is structured as follows. In Section 3. we 306 present the SDP Capability Negotiation solution, which consists of 307 new SDP attributes and associated offer/answer procedures. In 308 Section 4. we provide examples illustrating its use and in Section 309 5. we provide the security considerations. 311 2. Conventions used in this document 313 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 314 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 315 document are to be interpreted as described in [RFC2119]. 317 3. SDP Capability Negotiation Solution 319 In this section we first present the conceptual model behind the SDP 320 capability negotiation framework followed by an overview of the SDP 321 Capability Negotiation solution. We then define new SDP attributes 322 for the solution and provide its associated updated offer/answer 323 procedures. 325 3.1. SDP Capability Negotiation Model 327 Our model uses the concepts of 329 o Capabilities 331 o Potential Configurations 333 o Actual Configurations 335 o Negotiation Process 337 as defined in Section 1. Conceptually, we want to offer not just the 338 actual configuration SDP session description (which is done with the 339 offer/answer model defined in [RFC3264]), but the actual 340 configuration SDP session description as well as one or more 341 alternative SDP session descriptions, i.e. potential configurations. 342 The answerer must choose either the actual configuration, or one of 343 the potential configurations, and generate an answer SDP session 344 description based on that. The offerer may need to perform 345 processing on the answer, which depends on the offer that was chosen 346 (actual or potential configuration). The answerer therefore informs 347 the offerer which configuration the answerer chose. The process can 348 be viewed *conceptually* as follows: 350 Offerer Answerer 351 ======= ======== 353 1) Generate offer with actual 354 configuration and alternative 355 potential configurations 356 2) Send offer with all configurations 358 +------------+ 359 | SDP o1 | 360 | (actual | 361 | config | 362 | |-+ Offer 363 +------------+ | -----> 3) Process offered configurations 364 | SDP o2 | in order of preference indicated 365 | (potential | 4) Generate answer based on chosen 366 | config 1) |-+ configuration (e.g. o2), and 367 +------------+ | inform offerer which one was 368 | SDP o3 | chosen 369 | (potential | 370 | config 2) |-+ 371 +------------+ | 372 | SDP ... | 373 : : 375 +------------+ 376 | SDP a1 | 377 Answer | (actual | 378 <----- | config,o2)| 379 | | 380 5) Process answer based on +------------+ 381 the configuration that was 382 chosen (o2), as indicated in 383 the answer 385 The above illustrates the conceptual model: The actual solution uses 386 a single SDP session description, which contains the actual 387 configuration (as with existing SDP session descriptions and the 388 offer/answer model defined in [RFC3264]) and several new attributes 389 and associated procedures, that encode the capabilities and 390 potential configurations. A more accurate depiction of the actual 391 offer SDP session description is therefore as follows: 393 +--------------------+ 394 | SDP o1 | 395 | (actual | 396 | config | 397 | | 398 | +-------------+ | 399 | | capability 1| | 400 | | capability 2| | 401 | | ... | | 402 | +-------------+ | Offer 403 | | -----> 404 | +-------------+ | 405 | | potential | | 406 | | config 1 | | 407 | | potential | | 408 | | config 2 | | 409 | | ... | | 410 | +-------------+ | 411 | | 412 +--------------------+ 414 The above structure is used for two reasons: 416 o Backwards compatibility: As noted above, support for multipart 417 MIME is not ubiquitous. By encoding both capabilities and 418 potential configurations in SDP attributes, we can represent 419 everything in a single SDP session description thereby avoiding 420 any multipart MIME support issues. Furthermore, since unknown SDP 421 attributes are ignored by the SDP recipient, we ensure that 422 entities that do not support the framework simply perform the 423 regular RFC 3264 offer/answer procedures. This provides us with 424 seamless backwards compatibility. 426 o Message size efficiency: When we have multiple media streams, 427 each of which may potentially use two or more different transport 428 protocols with a variety of different associated parameters, the 429 number of potential configurations can be large. If each possible 430 alternative is represented as a complete SDP session description 431 in an offer, we can easily end up with large messages. By 432 providing a more compact encoding, we get more efficient message 433 sizes. 435 In the next section, we describe the exact structure and specific 436 SDP parameters used to represent this. 438 3.2. Solution Overview 440 The solution consists of the following: 442 o Two new SDP attributes to support extensions to the framework 443 itself as follows: 445 o A new attribute ("a=csup") that lists the supported base 446 (optionally) and any supported extension options to the 447 framework. 449 o A new attribute ("a=creq") that lists the extensions to the 450 framework that are required to be supported by the entity 451 receiving the SDP session description in order to do 452 capability negotiation. 454 o Two new SDP attributes used to express capabilities as follows 455 (additional attributes can be defined as extensions): 457 o A new attribute ("a=acap") that defines how to list an 458 attribute name and its associated value (if any) as a 459 capability. 461 o A new attribute ("a=tcap") that defines how to list transport 462 protocols (e.g. "RTP/AVP") as capabilities. 464 o Two new SDP attributes to negotiate configurations as follows: 466 o A new attribute ("a=pcfg") that lists potential 467 configurations supported. This is done by reference to the 468 capabilities from the SDP session description in question. 469 Extension capabilities can be defined and referenced in the 470 potential configurations. Alternative potential 471 configurations have an explicit ordering associated with 472 them. Also, potential configurations are by default preferred 473 over the actual configuration included in the "m=" line and 474 its associated parameters. 476 This preference order was chosen to provide maximum 477 backwards compatibility for the capability negotiation 478 framework and the possible values offered for a session. 479 For example, an entity that wants to establish a secure 480 RTP media stream but is willing to accept a plain RTP 481 media stream (assumed to be the least common denominator 482 for most endpoints), can offer plain RTP in the actual 483 configuration and use the capability negotiation 484 extensions to indicate the preference for secure RTP. 485 Entities that do not support the capability negotiation 486 extensions or secure RTP will then default to plain RTP. 488 o A new attribute ("a=acfg") to be used in an answer SDP 489 session description. The attribute identifies a potential 490 configuration from an offer SDP session description which was 491 used as an actual configuration to form the answer SDP 492 session description. Extension capabilities can be included 493 as well. 495 o Extensions to the offer/answer model that allow for capabilities 496 and potential configurations to be included in an offer. 497 Capabilities can be provided at the session level and the media 498 level. Potential configurations can be included only at the media 499 level, where they constitute alternative offers that may be 500 accepted by the answerer instead of the actual configuration(s) 501 included in the "m=" line(s) and associated parameters. The 502 mechanisms defined in this document enables potential 503 configurations to change the transport protocol, add new 504 attributes, as well as remove all existing attributes from the 505 actual configuration. The answerer indicates which (if any) of 506 the potential configurations it used to form the answer by 507 including the actual configuration attribute ("a=acfg") in the 508 answer. Capabilities may be included in answers as well, where 509 they can aid in guiding a subsequent new offer. 511 The mechanism is illustrated by the offer/answer exchange below, 512 where Alice sends an offer to Bob: 514 Alice Bob 516 | (1) Offer (SRTP and RTP) | 517 |--------------------------------->| 518 | | 519 | (2) Answer (SRTP) | 520 |<---------------------------------| 521 | | 522 | (3) Offer (SRTP) | 523 |--------------------------------->| 524 | | 525 | (4) Answer (SRTP) | 526 |<---------------------------------| 527 | | 529 Alice's offer includes RTP and SRTP as alternatives, where RTP is 530 the default (actual configuration), but SRTP is the preferred one 531 (potential configuration): 533 v=0 534 o=- 25678 753849 IN IP4 192.0.2.1 535 s= 536 c=IN IP4 192.0.2.1 537 t=0 0 538 m=audio 53456 RTP/AVP 0 18 539 a=tcap:1 RTP/SAVP 540 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 541 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 542 a=pcfg:1 t=1 a=1 544 The "m=" line indicates that Alice is offering to use plain RTP with 545 PCMU or G.729. The capabilities are provided by the "a=tcap" and 546 "a=acap" attributes. The transport capability attribute ("a=tcap") 547 indicates that secure RTP under the AVP profile ("RTP/SAVP") is 548 supported with an associated transport capability handle of 1. The 549 "acap" attribute provides an attribute capability with a handle of 550 1. The attribute capability is a "crypto" attribute, which provides 551 the keying material for SRTP using SDP security descriptions 552 [RFC4568]. The "a=pcfg" attribute provides the potential 553 configuration included in the offer by reference to the capability 554 parameters. One alternative is provided; it has a configuration 555 number of 1 and it consists of transport protocol capability 1 556 (i.e., the RTP/SAVP profile - secure RTP), and the attribute 557 capability 1 (i.e., the crypto attribute provided). Potential 558 configurations are preferred over the actual configuration included 559 in the offer SDP session description, and hence Alice is expressing 560 a preference for using secure RTP. 562 Bob receives the SDP session description offer from Alice. Bob 563 supports SRTP and the SDP Capability Negotiation framework, and 564 hence he accepts the (preferred) potential configuration for Secure 565 RTP provided by Alice and generates the following answer SDP session 566 description: 568 v=0 569 o=- 24351 621814 IN IP4 192.0.2.2 570 s= 571 c=IN IP4 192.0.2.2 572 t=0 0 573 m=audio 54568 RTP/SAVP 0 18 574 a=crypto:1 AES_CM_128_HMAC_SHA1_80 575 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 576 a=acfg:1 t=1 a=1 578 Bob includes the "a=acfg" attribute in the answer to inform Alice 579 that he based his answer on an offer using potential configuration 1 580 with transport protocol capability 1 and attribute capability 1 from 581 the offer SDP session description (i.e., the RTP/SAVP profile using 582 the keying material provided). Bob also includes his keying 583 material in a "crypto" attribute. If Bob supported one or more 584 extensions to the capability negotiation framework, he would have 585 included option tags for those in the answer as well (in an "a=csup" 586 attribute). 588 When Alice receives Bob's answer, session negotiation has completed, 589 however Alice nevertheless generates a new offer using the 590 negotiated configuration as the actual configuration. This is done 591 purely to assist any intermediaries that may reside between Alice 592 and Bob but do not support the SDP Capability Negotiation framework, 593 and hence may not understand the negotiation that just took place. 595 Alice's updated offer includes only SRTP, and it is not using the 596 SDP Capability Negotiation framework (Alice could have included the 597 capabilities as well is she wanted to): 599 v=0 600 o=- 25678 753850 IN IP4 192.0.2.1 601 s= 602 c=IN IP4 192.0.2.1 603 t=0 0 604 m=audio 53456 RTP/SAVP 0 18 605 a=crypto:1 AES_CM_128_HMAC_SHA1_80 606 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 608 The "m=" line now indicates that Alice is offering to use secure RTP 609 with PCMU or G.729. The "crypto" attribute, which provides the SRTP 610 keying material, is included with the same value again. 612 Bob receives the SDP session description offer from Alice, which he 613 accepts, and then generates an answer to Alice: 615 v=0 616 o=- 24351 621815 IN IP4 192.0.2.2 617 s= 618 c=IN IP4 192.0.2.2 619 t=0 0 620 m=audio 54568 RTP/SAVP 0 18 621 a=crypto:1 AES_CM_128_HMAC_SHA1_80 622 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 624 Bob includes the same crypto attribute as before, and the session 625 proceeds without change. Although Bob did not include any 626 capabilities in his answer, he could have done so if he wanted to. 628 Note that in this particular example, the answerer supported the 629 capability negotiation extensions defined here. Had he not, he would 630 simply have ignored the new attributes and accepted the (actual 631 configuration) offer to use normal RTP. In that case, the following 632 answer would have been generated instead: 634 v=0 635 o=- 24351 621814 IN IP4 192.0.2.2 636 s= 637 c=IN IP4 192.0.2.2 638 t=0 0 639 m=audio 54568 RTP/AVP 0 18 641 3.3. Version and Extension Indication Attributes 643 In this section, we present the new attributes associated with 644 indicating the SDP Capability Negotiation extensions supported and 645 required. 647 3.3.1. Supported Capability Negotiation Extensions Attribute 649 The SDP Capability Negotiation solution allows for capability 650 negotiation extensions to be defined. Associated with each such 651 extension is an option tag that identifies the extension in 652 question. Option-tags MUST be registered with IANA per the 653 procedures defined in Section 6.2. 655 The Supported Capability Negotiation Extensions attribute ("a=csup") 656 contains a comma-separated list of option tags identifying the SDP 657 Capability Negotiation extensions supported by the entity that 658 generated the SDP session description. The attribute can be provided 659 at the session-level and the media-level, and it is defined as 660 follows: 662 a=csup: 664 RFC 4566, Section 9, provides the ABNF [RFC5234] for SDP attributes. 665 The "csup" attribute adheres to the RFC 4566 "attribute" production, 666 with an att-value defined as follows: 668 att-value = option-tag-list 669 option-tag-list = option-tag *("," option-tag) 670 option-tag = token ; defined in [RFC4566] 672 A special base option tag with a value of "cap-v0" is defined for 673 the basic SDP Capability Negotiation framework defined in this 674 document. Entities can use this option tag with the "a=csup" 675 attribute to indicate support for the SDP Capability Negotiation 676 framework specified in this document. Please note that white space 677 is not allowed in this rule. 679 The following examples illustrate use of the "a=csup" attribute with 680 the "cap-v0" option tag and two hypothetical option tags, "foo" and 681 "bar" (note the lack of white space): 683 a=csup:cap-v0 685 a=csup:foo 687 a=csup:bar 689 a=csup:cap-v0,foo,bar 691 The "a=csup" attribute can be provided at the session and the media- 692 level. When provided at the session-level, it applies to the entire 693 SDP session description. When provided at the media-level, it 694 applies only to the media description in question (option-tags 695 provided at the session level apply as well). There MUST NOT be more 696 than one "a=csup" attribute at the session-level and one at the 697 media-level (one per media description in the latter case). 699 Whenever an entity that supports one or more extensions to the SDP 700 Capability Negotiation framework generates an SDP session 701 description, it SHOULD include the "a=csup" attribute with the 702 option tags for the extensions it supports at the session and/or 703 media-level, unless those option tags are already provided in one or 704 more "a=creq" attribute (see Section 3.3.2. ) at the relevant 705 levels. Inclusion of the base option tag is OPTIONAL; support for 706 the base framework can be inferred from presence of the "a=pcfg" 707 attribute defined in Section 3.5.1. 709 Use of the base option tag may still be useful in some scenarios, 710 e.g. when using SIP OPTIONS [RFC3261] or generating an answer to 711 an offer that did not use the SDP Capability Negotiation 712 framework. 714 3.3.2. Required Capability Negotiation Extensions Attribute 716 The Required Capability Negotiation Extensions attribute ("a=creq") 717 contains a comma-separated list of option tags (see Section 3.3.1. ) 718 specifying the SDP Capability Negotiation extensions that MUST be 719 supported by the entity receiving the SDP session description, in 720 order for that entity to properly process the SDP Capability 721 Negotiation attributes and associated procedures. There is no need 722 to include the base option-tag ("cap-v0") with the "creq" attribute, 723 since any entity that supports the "creq" attribute in the first 724 place also supports the base option-tag. Still, it is permissible to 725 do so. 727 Such functionality may be important if a future version of the 728 capability negotiation framework were not backwards compatible. 730 The attribute can be provided at the session-level and the media- 731 level, and it is defined as follows: 733 a=creq: 735 The "creq" attribute adheres to the RFC 4566 "attribute" production, 736 with an att-value defined as follows: 738 att-value = option-tag-list 740 The following examples illustrate use of the "a=creq" attribute with 741 the "cap-v0" base option tag and two hypothetical option tags, "foo" 742 and "bar" (note the lack of white space): 744 a=creq:cap-v0 746 a=creq:foo 748 a=creq:bar 750 a=creq:cap-v0,foo,bar 752 The "a=creq" attribute can be provided at the session and the media- 753 level. When provided at the session-level, it applies to the entire 754 SDP session description. When provided at the media-level, it 755 applies only to the media description in question (required option 756 tags provided at the session level apply as well). There MUST NOT be 757 more than one "a=creq" attribute at the session-level and one 758 "a=creq" attribute at the media-level (one per media description in 759 the latter case). 761 When an entity generates an SDP session description and it requires 762 the recipient of that SDP session description to support one or more 763 SDP Capability Negotiation extensions (except for the base) at the 764 session or media level in order to properly process the SDP 765 Capability Negotiation, the "a=creq" attribute MUST be included with 766 option-tags that identify the required extensions at the session 767 and/or media level. If support for an extension is needed only in 768 one or more specific potential configurations, the potential 769 configuration provides a way to indicate that instead (see Section 770 3.5.1. ). Support for the basic negotiation framework is implied by 771 the presence of an "a=pcfg" attribute (see Section 3.5.1. ) and 772 hence it is not required to include the "a=creq" attribute with the 773 base option-tag ("cap-v0"). 775 A recipient that receives an SDP session description and does not 776 support one or more of the required extensions listed in a "creq" 777 attribute, MUST NOT perform the SDP Capability Negotiation defined 778 in this document. For non-supported extensions provided at the 779 session-level, this implies that SDP Capability Negotiation MUST NOT 780 be performed at all. For non-supported extensions at the media- 781 level, this implies that SDP Capability Negotiation MUST NOT be 782 performed for the media stream in question. 784 An entity that does not support the SDP Capability Negotiation 785 framework at all, will ignore these attributes (as well as the 786 other SDP Capability Negotiation attributes) and not perform any 787 SDP Capability Negotiation in the first place. 789 When an SDP session description recipient does not support one or 790 more required SDP Capability Negotiation extensions listed in the 791 option tags, the recipient MUST proceed as if the SDP Capability 792 Negotiation attributes were not included in the first place, i.e. 793 all the capability negotiation attributes should be ignored. In 794 that case, if the SDP session description recipient is an SDP 795 answerer [RFC3264], the recipient SHOULD include a "csup" attribute 796 in the resulting SDP session description answer listing the SDP 797 Capability Negotiation extensions it actually supports. 799 This ensures that introduction of the SDP Capability Negotiation 800 mechanism by itself does not lead to session failures. 802 3.4. Capability Attributes 804 In this section, we present the new attributes associated with 805 indicating the capabilities for use by the SDP Capability 806 Negotiation. 808 3.4.1. Attribute Capability Attribute 810 Attributes and their associated values can be expressed as 811 capabilities by use of a new attribute capability attribute 812 ("a=acap"), which is defined as follows: 814 a=acap: 816 where is an integer between 1 and 2^31-1 (both 817 included) used to number the attribute capability and is 818 an attribute ("a=") in its "" or :" 819 form, i.e., excluding the "a=" part (see [RFC4566]). The attribute 820 can be provided at the session-level and the media-level. 822 The "acap" attribute adheres to the RFC 4566 "attribute" production, 823 with an att-value defined as follows: 825 att-value = att-cap-num 1*WSP att-par 826 att-cap-num = 1*10(DIGIT) ;defined in [RFC5234] 827 att-par = attribute ;defined in RFC 4566 829 Note that white space is not permitted before the att-cap-num. 831 When the attribute capability contains a session-level attribute, 832 that "acap" attribute can only be provided at the session level. 833 Conversely, media level attributes can be provided in attribute 834 capabilities at either the media level or session-level. The base 835 SDP Capability Negotiation framework however only defines procedures 836 for use of media-level attribute capabilities at the media level. 837 Implementations that conform only to the base framework MUST NOT 838 generate media-level attribute capabilities at the session-level, 839 however extensions may change this (see, e.g., [SDPMedCap] for one 840 such extension) and hence all implementations MUST still be prepared 841 to receive such capabilities (see Section 3.6.2. for processing 842 rules). 844 Each occurrence of the "acap" attribute in the entire session 845 description MUST use a different value of . 846 Consecutive numbering of the values is not required. 848 There is a need to be able to reference both session-level and 849 media-level attributes in potential configurations at the media 850 level, and this provides for a simple solution to avoiding overlap 851 between the references (handles) to each attribute capability. 853 The values provided are independent of similar values provided for other types of capabilities, i.e., they 855 form a separate name-space for attribute capabilities. 857 The following examples illustrate use of the "acap" attribute: 859 a=acap:1 ptime:20 861 a=acap:2 ptime:30 863 a=acap:3 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAA 864 AAAGEEoo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0 865 JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUO 866 SrzKTAv9zV 868 a=acap:4 crypto:1 AES_CM_128_HMAC_SHA1_32 869 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 871 The first two attribute capabilities provide attribute values for 872 the ptime attribute. The third provides SRTP parameters by using 873 MIKEY [RFC3830] with the key-mgmt attribute [RFC4567]. The fourth 874 provides SRTP parameters by use of security descriptions with the 875 crypto attribute [RFC4568]. Note that the line-wrapping and new- 876 lines in example three and four are provided for formatting reasons 877 only - they are not permitted in actual SDP session description. 879 Readers familiar with RFC 3407 may notice the similarity between 880 the RFC 3407 "cpar" attribute and the above. There are however a 881 couple of important differences, notably that the "acap" attribute 882 contains a handle that enables referencing it and it furthermore 883 supports only attributes (the "cpar" attribute defined in RFC 3407 884 supports bandwidth information as well). The "acap" attribute also 885 is not automatically associated with any particular capabilities. 886 See Section 3.14. for the relationship to RFC 3407. 888 Attribute capabilities MUST NOT embed any capability negotiation 889 parameters. This restriction applies to all the capability 890 negotiation parameters defined in this document ("csup", "creq", 891 "acap", "pcfg", and "acfg") as well as any extensions defined. The 892 following examples are thus invalid attribute capabilities and MUST 893 NOT be used: 895 a=acap:1 acap:2 foo:a ;Not allowed to embed "acap" 897 a=acap:2 a=pcfg:1 t=1 a=1 ;Not allowed to embed "pcfg" 899 The reason for this restriction is to avoid overly complex 900 processing rules resulting from the expansion of such capabilities 901 into potential configurations (see Section 3.6.2. for further 902 details). 904 3.4.2. Transport Protocol Capability Attribute 906 Transport Protocols can be expressed as capabilities by use of a new 907 Transport Protocol Capability attribute ("a=tcap") defined as 908 follows: 910 a=tcap: 912 where is an integer between 1 and 2^31-1 (both 913 included) used to number the transport address capability for later 914 reference, and is one or more , separated by 915 white space, as defined in the SDP "m=" line. The attribute can be 916 provided at the session-level and the media-level. 918 The "tcap" attribute adheres to the RFC 4566 "attribute" production, 919 with an att-value defined as follows: 921 att-value = trpr-cap-num 1*WSP proto-list 922 trpr-cap-num = 1*10(DIGIT) ;defined in [RFC5234] 923 proto-list = proto *(1*WSP proto) ; defined in RFC 4566 925 Note that white space is not permitted before the trpr-cap-num. 927 The "tcap" attribute can be provided at the session-level and the 928 media-level. There MUST NOT be more than one "a=tcap" attribute at 929 the session-level and one at the media-level (one per media 930 description in the latter case). Each occurrence of the "tcap" 931 attribute in the entire session description MUST use a different 932 value of . When multiple values are provided, 933 the first one is associated with the value , the 934 second one with the value one higher, etc. There MUST NOT be any 935 capability number overlap between different "tcap" attributes in the 936 entire SDP session description. The values provided 937 are independent of similar values provided for other 938 capability attributes, i.e., they form a separate name-space for 939 transport protocol capabilities. Consecutive numbering of the values in different "tcap" attributes is not required. 942 Below, we provide examples of the "a=tcap" attribute: 944 a=tcap:1 RTP/AVP 946 a=tcap:2 RTP/AVPF 948 a=tcap:3 RTP/SAVP RTP/SAVPF 950 a=tcap:5 UDP/TLS/RTP/SAVP 952 The first one provides a capability for the "RTP/AVP" profile 953 defined in [RFC3551] and the second one provides a capability for 954 the RTP with RTCP-Based Feedback profile defined in [RFC4585]. The 955 third one provides capabilities for the "RTP/SAVP" (transport 956 capability number 3) and "RTP/SAVPF" profiles (transport protocol 957 capability number 4). The last one provides capabilities for 958 "UDP/TLS/RTP/SAVP", i.e. DTLS-SRTP [DTLS-SRTP](transport capability 959 number 5). 961 The "tcap" attribute by itself can only specify transport protocols 962 as defined by in [RFC4566], however full specification of a 963 media stream requires further qualification of the transport 964 protocol by one or more media format descriptions, which themselves 965 often depend on the transport protocol. As an example, [RFC3551] 966 defines the "RTP/AVP" transport for use with audio and video codecs 967 (media formats), whereas [RFC4145] for example defines the "TCP" 968 transport protocol which may be used to negotiate, e.g. image/t38, 969 application/iptv_rtsp, etc. In a non-SDP context, some of these 970 media formats could be viewed as transports themselves (e.g. T.38) 971 however in the context of SDP and SDP Capability Negotiation, they 972 are not. If capability negotiation is required for such media 973 formats, they MUST all either be valid under the transport protocol 974 indicated in the "m=" line included for the media stream 975 description, or a suitable extension must be used, e.g. SDP Media 976 Capabilities [SDPMedCap]. 978 The ability to use a particular transport protocol is inherently 979 implied by including it in the "m=" line, regardless of whether it 980 is provided in a "tcap" attribute or not. However, if a potential 981 configuration needs to reference that transport protocol as a 982 capability, the transport protocol MUST be included explicitly in a 983 "tcap" attribute. 985 This may seem redundant (and indeed it is from the offerer's point 986 of view), however it is done to protect against intermediaries 987 (e.g. middle-boxes) that may modify "m=" lines while passing 988 unknown attributes through. If an implicit transport capability 989 were used instead (e.g. a reserved transport capability number 990 could be used to refer to the transport protocol in the "m=" 991 line), and an intermediary were to modify the transport protocol 992 in the "m=" line (e.g. to translate between plain RTP and secure 993 RTP), then the potential configuration referencing that implicit 994 transport capability may no longer be correct. With explicit 995 capabilities, we avoid this pitfall; however, the potential 996 configuration preference (see Section 3.5.1. ) may not reflect 997 that of the intermediary (which some may view as a feature). 999 Note that a transport protocol capability may be provided, 1000 irrespective of whether it is referenced in a potential 1001 configuration or not (just like any other capability). 1003 3.4.3. Extension Capability Attributes 1005 The SDP Capability Negotiation framework allows for new types of 1006 capabilities to be defined as extensions and used with the general 1007 capability negotiation framework. The syntax and semantics of such 1008 new capability attributes are not defined here, however in order to 1009 be used with potential configurations, they SHOULD allow for a 1010 numeric handle to be associated with each capability. This handle 1011 can be used as a reference within the potential and actual 1012 configuration attributes (see Section 3.5.1. and 3.5.2. ). The 1013 definition of such extension capability attributes MUST also state 1014 whether they can be applied at the session-level, media-level, or 1015 both. Note that extensions can have option tags defined for them, 1016 and option tags MUST be registered with the IANA in accordance with 1017 the procedures specified in Section 6.2. 1019 Extension capabilities SHOULD NOT embed any capability negotiation 1020 parameters. This applies to all the capability negotiation 1021 parameters defined in this document as well as any extensions 1022 defined. The reason for this restriction is to avoid overly complex 1023 processing rules resulting from the expansion of such capabilities 1024 into potential configurations (see Section 3.6.2. for further 1025 details). If an extension does not follow the above "SHOULD NOT" 1026 recommendation, the extension MUST provide a careful analysis of why 1027 such behavior is both necessary and safe. 1029 3.5. Configuration Attributes 1031 3.5.1. Potential Configuration Attribute 1033 Potential Configurations can be expressed by use of a new Potential 1034 Configuration Attribute ("a=pcfg") defined as follows: 1036 a=pcfg: [] 1038 where is an integer between 1 and 2^31-1 (both 1039 included). The attribute can be provided only at the media-level. 1041 The "pcfg" attribute adheres to the RFC 4566 "attribute" production, 1042 with an att-value defined as follows: 1044 att-value = config-number [1*WSP pot-cfg-list] 1045 config-number = 1*10(DIGIT) ;defined in [RFC5234] 1046 pot-cfg-list = pot-config *(1*WSP pot-config) 1047 pot-config = attribute-config-list / 1048 transport-protocol-config-list / 1049 extension-config-list 1051 The missing productions are defined below. Note that white space is 1052 not permitted before the config-number. 1054 The potential configuration attribute can be provided only at the 1055 media-level and there can be multiple instances of it within a given 1056 media description. The attribute includes a configuration number, 1057 which is an integer between 1 and 2^31-1 (both included). The 1058 configuration number MUST be unique within the media description 1059 (i.e., it has only media level scope). The configuration number also 1060 indicates the relative preference of potential configurations; lower 1061 numbers are preferred over higher numbers. Consecutive numbering of 1062 the configuration numbers in different "pcfg" attributes in a media 1063 description is not required. 1065 A potential configuration list is normally provided after the 1066 configuration number. When the potential configuration list is 1067 omitted, the potential configuration equals the actual 1068 configuration. The potential configuration list contains one or more 1069 of attribute, transport and extension configuration lists. A 1070 potential configuration may for example include attribute 1071 capabilities and transport capabilities, transport capabilities 1072 only, or some other combination of capabilities. If transport 1073 capabilities are not included in a potential configuration, the 1074 default transport for that media stream is used. 1076 The potential configuration lists generally reference one or more 1077 capabilities (extension configuration lists MAY use a different 1078 format). Those capabilities are (conceptually) used to construct a 1079 new internal version of the SDP session description by use of purely 1080 syntactic add and (possibly) delete operations on the original SDP 1081 session description (actual configuration). This provides an 1082 alternative potential configuration SDP session description that can 1083 be used by conventional SDP and offer/answer procedures if selected. 1085 This document defines attribute configuration lists and transport 1086 protocol configuration lists. Each of these MUST NOT be present 1087 more than once in a particular potential configuration attribute. 1088 Attribute capabilities referenced by the attribute configuration 1089 list (if included) are added to the actual configuration, whereas a 1090 transport capability referenced by the transport protocol 1091 configuration list (if included) replaces the default transport 1092 protocol from the actual configuration. Extension configuration 1093 lists can be included as well. There can be more than one extension 1094 configuration list, however each particular extension MUST NOT be 1095 present more than once in a given "a=pcfg" attribute. Together, the 1096 various configuration lists define a potential configuration. 1098 There can be multiple potential configurations in a media 1099 description. Each of these indicates not only a willingness, but in 1100 fact a desire to use the potential configuration. 1102 The example SDP session description below contains two potential 1103 configurations: 1105 v=0 1106 o=- 25678 753849 IN IP4 192.0.2.1 1107 s= 1108 c=IN IP4 192.0.2.1 1109 t=0 0 1110 m=audio 53456 RTP/AVP 0 18 1111 a=tcap:1 RTP/SAVP RTP/SAVPF 1112 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 1113 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 1114 a=pcfg:1 t=1 a=1 1115 a=pcfg:2 t=2 a=1 1117 Potential configuration 1 contains a transport protocol 1118 configuration list that references transport capability 1 1119 ("RTP/SAVP") and an attribute configuration list that references 1120 attribute capability 1 ("a=crypto:..."). Potential configuration 2 1121 contains a transport protocol configuration list that references 1122 transport capability 2 ("RTP/SAVPF") and an attribute configuration 1123 list that references attribute capability 1 ("a=crypto:..."). 1125 Attribute capabilities are used in a potential configuration by use 1126 of the attribute-config-list parameter, which is defined by the 1127 following ABNF: 1129 attribute-config-list = "a=" delete-attributes 1130 attribute-config-list =/ "a=" [delete-attributes ":"] 1131 mo-att-cap-list *(BAR mo-att-cap-list)) 1133 delete-attributes = DELETE ( "m" ; media attributes 1134 / "s" ; session attributes 1135 / "ms" ) ; media and session attributes 1137 mo-att-cap-list = mandatory-optional-att-cap-list / 1138 mandatory-att-cap-list / 1139 optional-att-cap-list 1141 mandatory-optional-att-cap-list = mandatory-att-cap-list 1142 "," optional-att-cap-list 1143 mandatory-att-cap-list = att-cap-list 1144 optional-att-cap-list = "[" att-cap-list "]" 1146 att-cap-list = att-cap-num *("," att-cap-num) 1147 att-cap-num = 1*10(DIGIT) ;defined in [RFC5234] 1148 BAR = "|" 1149 DELETE = "-" 1151 Note that white space is not permitted within the attribute-config- 1152 list rule. 1154 Each attribute configuration list can optionally begin with 1155 instructions for how to handle attributes that are part of the 1156 actual configuration SDP session description (i.e., the "a=" lines 1157 present in the original SDP session description). By default, such 1158 attributes will remain as part of the potential configuration in 1159 question. However, if delete-attributes indicates "-m", then all 1160 attribute lines within the media description in question will be 1161 deleted in the resulting potential configuration SDP session 1162 description (i.e., all "a=" lines under the "m=" line in question). 1163 If delete-attributes indicates "-s", then all attribute lines at the 1164 session-level will be deleted (i.e., all "a=" lines before the first 1165 "m=" line). If delete-attributes indicates "-ms", then all attribute 1166 lines within this media description ("m=" line) and all attribute 1167 lines at the session-level will be deleted. 1169 The attribute capability list comes next (if included). It contains 1170 one or more alternative lists of attribute capabilities. The 1171 alternative attribute capability lists are separated by a vertical 1172 bar ("|"), and each list contains one or more attribute capabilities 1173 separated by commas (","). The attribute capabilities are either 1174 mandatory or optional. Mandatory attribute capabilities MUST be 1175 supported in order to use the potential configuration, whereas 1176 optional attribute capabilities MAY be supported in order to use the 1177 potential configuration. 1179 Within each attribute capability list, all the mandatory attribute 1180 capabilities (if any) are listed first, and all the optional 1181 attribute capabilities (if any) are listed last. The optional 1182 attribute capabilities are contained within a pair of square 1183 brackets ("[" and "]"). Each attribute capability is merely an 1184 attribute capability number (att-cap-num) that identifies a 1185 particular attribute capability by referring to attribute capability 1186 numbers defined above and hence MUST be between 1 and 2^31-1 (both 1187 included). The following example illustrates the above: 1189 a=pcfg:1 a=-m:1,2,[3,4]|1,7,[5] 1191 where 1193 o "a=-m:1,2,[3,4]|1,7,[5]" is the attribute configuration list 1195 o "-m" indicates to delete all attributes from the media 1196 description of the actual configuration 1198 o "1,2,[3,4]" and "1,7,[5]" are both attribute capability lists. 1199 The two lists are alternatives, since they are separated by a 1200 vertical bar above 1202 o "1", "2" and "7" are mandatory attribute capabilities 1204 o "3", "4" and "5" are optional attribute capabilities 1206 Note that in the example above, we have a single handle ("1") for 1207 the potential configuration(s), but there are actually two different 1208 potential configurations (separated by a vertical bar). This is done 1209 for message size efficiency reasons, which is especially important 1210 when we add other types of capabilities to the potential 1211 configuration. If there is a need to provide a unique handle for 1212 each, then separate "a=pcfg" attributes with different handles MUST 1213 be used instead. 1215 Each referenced attribute capability in the potential configuration 1216 will result in the corresponding attribute name and its associated 1217 value (contained inside the attribute capability) being added to the 1218 resulting potential configuration SDP session description. 1220 Alternative attribute capability lists are separated by a vertical 1221 bar ("|"), the scope of which extends to the next alternative (i.e., 1222 "," has higher precedence than "|"). The alternatives are ordered by 1223 preference with the most preferred listed first. In order for a 1224 recipient of the SDP session description (e.g., an answerer 1225 receiving this in an offer) to use this potential configuration, 1226 exactly one of the alternative lists MUST be selected in its 1227 entirety. This requires that all mandatory attribute capabilities 1228 referenced by the potential configuration are supported with the 1229 attribute values provided. 1231 Transport protocol configuration lists are included in a potential 1232 configuration by use of the transport-protocol-config-list 1233 parameter, which is defined by the following ABNF: 1235 transport-protocol-config-list = 1236 "t=" trpr-cap-num *(BAR trpr-cap-num) 1237 trpr-cap-num = 1*10(DIGIT) ; defined in [RFC5234] 1239 Note that white space is not permitted within this rule. 1241 The trpr-cap-num refers to transport protocol capability numbers 1242 defined above and hence MUST be between 1 and 2^31-1 (both 1243 included). Alternative transport protocol capabilities are separated 1244 by a vertical bar ("|"). The alternatives are ordered by preference 1245 with the most preferred listed first. If there are no transport 1246 protocol capabilities included in a potential configuration at the 1247 media level, the transport protocol information from the associated 1248 "m=" line MUST be used. In order for a recipient of the SDP session 1249 description (e.g., an answerer receiving this in an offer) to use 1250 this potential configuration, exactly one of the alternatives MUST 1251 be selected. This requires that the transport protocol in question 1252 is supported. 1254 In the presence of intermediaries (the existence of which may not 1255 be known), care should be taken with assuming that the transport 1256 protocol in the "m=" line will not be modified by an intermediary. 1257 Use of an explicit transport protocol capability will guard 1258 against capability negotiation implications of that. 1260 Extension capabilities can be included in a potential configuration 1261 as well by use of extension configuration lists. Extension 1262 configuration lists MUST adhere to the following ABNF: 1264 extension-config-list= ["+"] ext-cap-name "=" 1265 ext-cap-list 1266 ext-cap-name = 1*(ALPHA / DIGIT) 1267 ext-cap-list = 1*VCHAR ; defined in [RFC5234] 1269 Note that white space is not permitted within this rule. 1271 The ext-cap-name refers to the name of the extension capability and 1272 the ext-cap-list is here merely defined as a sequence of visible 1273 characters. The actual extension supported MUST refine both of these 1274 further. For extension capabilities that merely need to be 1275 referenced by a capability number, it is RECOMMENDED to follow a 1276 structure similar to what has been specified above. Unsupported or 1277 unknown potential extension configuration lists in a potential 1278 configuration attribute MUST be ignored, unless they are prefixed 1279 with the plus ("+") sign, which indicates that the extension is 1280 mandatory and MUST be supported in order to use that potential 1281 configuration. 1283 The "creq" attribute and its associated rules can be used to 1284 ensure that required extensions are supported in the first place. 1286 Extension configuration lists define new potential configuration 1287 parameters and hence they MUST be registered with IANA per the 1288 procedures defined in Section 6.3. 1290 Potential configuration attributes can be provided only at the media 1291 level, however it is possible to reference capabilities provided at 1292 either the session or media level. There are certain semantic rules 1293 and restrictions associated with this: 1295 A (media level) potential configuration attribute in a given media 1296 description MUST NOT reference a media-level capability provided in 1297 a different media description; doing so invalidates that potential 1298 configuration (note that a potential configuration attribute can 1299 contain more than one potential configuration by use of 1300 alternatives). A potential configuration attribute can however 1301 reference a session-level capability. The semantics of doing so 1302 depends on the type of capability. In the case of transport protocol 1303 capabilities it has no particular implication. In the case of 1304 attribute capabilities however, it does. More specifically, the 1305 attribute name and value (provided within that attribute capability) 1306 will be considered part of the resulting SDP for that particular 1307 configuration at the *session* level. In other words, it will be as- 1308 if that attribute was provided with that value at the session-level 1309 in the first place. As a result, the base SDP Capability Negotiation 1310 framework REQUIRES that potential configurations do not reference 1311 any session-level attribute capabilities that contain media-level 1312 attributes (since that would place a media-level attribute at the 1313 session level). Extensions may modify this behavior, as long as it 1314 is fully backwards compatible with the base specification. 1316 Individual media streams perform capability negotiation 1317 individually, and hence it is possible that one media stream (where 1318 the attribute was part of a potential configuration) chose a 1319 configuration without a session level attribute that was chosen by 1320 another media stream. The session-level attribute however remains 1321 "active" and applies to the entire resulting potential configuration 1322 SDP session description. In theory, this is problematic if one or 1323 more session-level attributes either conflicts with or potentially 1324 interacts with another session-level or media-level attribute in an 1325 undefined manner. In practice, such examples seem to be rare (at 1326 least with the SDP attributes that had been defined at time of 1327 publication of this document). 1329 A related set of problems can occur if we need coordination 1330 between session-level attributes from multiple media streams in 1331 order for a particular functionality to work. The grouping 1332 framework [RFC3388] is an example of this. If we use the SDP 1333 Capability Negotiation framework to select a session-level group 1334 attribute (provided as an attribute capability), and we require 1335 two media descriptions to do this consistently, we could have a 1336 problem. The FEC grouping semantics [RFC4756] is one example where 1337 this in theory could cause problems, however in practice, it is 1338 unclear that there is a significant problem with the grouping 1339 semantics that had been defined at time of publication of this 1340 document. 1342 Resolving the above issues in general requires inter-media stream 1343 constraints and synchronized potential configuration processing; 1344 this would add considerable complexity to the overall solution. In 1345 practice, with the SDP attributes defined at time of publication of 1346 this document, it does not seem to be a significant problem, and 1347 hence the base SDP Capability Negotiation solution does not provide 1348 a solution to this issue. Instead, it is RECOMMENDED that use of 1349 session-level attributes in a potential configuration is avoided 1350 when possible, and when not, that such use is examined closely for 1351 any potential interaction issues. If interaction is possible, the 1352 entity generating the SDP session description SHOULD NOT assume that 1353 well-defined operation will occur at the receiving entity. This 1354 implies that mechanisms which might have such interactions cannot be 1355 used in security critical contexts. 1357 The session-level operation of extension capabilities is undefined: 1358 Consequently, each new session-level extension capability defined 1359 MUST specify the implication of making it part of a configuration at 1360 the media level. 1362 Below, we provide an example of the "a=pcfg" attribute in a complete 1363 media description in order to properly indicate the supporting 1364 attributes: 1366 v=0 1367 o=- 25678 753849 IN IP4 192.0.2.1 1368 s= 1369 c=IN IP4 192.0.2.1 1370 t=0 0 1371 m=audio 53456 RTP/AVPF 0 18 1372 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 1373 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 1374 a=tcap:1 RTP/AVPF RTP/AVP RTP/SAVP RTP/SAVPF 1375 a=pcfg:1 t=4|3 a=1 1376 a=pcfg:8 t=1|2 1378 We have two potential configuration attributes listed here. The 1379 first one (and most preferred, since its configuration number is 1380 "1") indicates that either of the profiles RTP/SAVPF or RTP/SAVP 1381 (specified by the transport protocol capability numbers 4 and 3) can 1382 be supported with attribute capability 1 (the "crypto" attribute); 1383 RTP/SAVPF is preferred over RTP/SAVP since its capability number (4) 1384 is listed first in the preferred potential configuration. Note that 1385 although we have a single potential configuration attribute and 1386 associated handle, we have two potential configurations. 1388 The second potential configuration attribute indicates that the 1389 RTP/AVPF or RTP/AVP profiles can be used, with RTP/AVPF being the 1390 preferred one. This non secure RTP alternative is the less preferred 1391 one since its configuration number is "8". Again, note that we have 1392 two potential configurations here and hence a total of four 1393 potential configurations in the SDP session description above. 1395 3.5.2. Actual Configuration Attribute 1397 The actual configuration attribute identifies which of the potential 1398 configurations from an offer SDP session description was selected 1399 and used as the actual configuration to generate an answer SDP 1400 session description. This is done by including the configuration 1401 number and the configuration lists (if any) from the offer that were 1402 selected and used by the answerer in his offer/answer procedure as 1403 follows: 1405 o A selected attribute configuration MUST include the delete- 1406 attributes and the known and supported parameters from the 1407 selected alternative mo-att-cap-list (i.e., containing all 1408 mandatory and all known and supported optional capability numbers 1409 from the potential configuration). If delete-attributes were not 1410 included in the potential configuration, they will of course not 1411 be present here either. 1413 o A selected transport protocol configuration MUST include the 1414 selected transport protocol capability number. 1416 o A selected potential extension configuration MUST include the 1417 selected extension configuration parameters as specified for that 1418 particular extension. 1420 o When a configuration list contains alternatives (separated by 1421 "|"), the selected configuration only MUST be provided. 1423 Note that the selected configuration number and all selected 1424 capability numbers used in the actual configuration attribute refer 1425 to those from the offer; not the answer. 1427 The answer may for example include capabilities as well to inform 1428 the offerer of the answerers capabilities above and beyond the 1429 negotiated configuration. The actual configuration attribute does 1430 not refer to any of those answer capabilities though. 1432 The Actual Configuration Attribute ("a=acfg") is defined as follows: 1434 a=acfg: [] 1436 where is an integer between 1 and 2^31-1 (both 1437 included) that refers to the selected potential configuration. The 1438 attribute can be provided only at the media-level. 1440 The "acfg" attribute adheres to the RFC 4566 "attribute" production, 1441 with an att-value defined as follows: 1443 att-value = config-number [1*WSP sel-cfg-list] 1444 ;config-number defined in Section 3.5.1. 1445 sel-cfg-list = sel-cfg *(1*WSP sel-cfg) 1446 sel-cfg = sel-attribute-config / 1447 sel-transport-protocol-config / 1448 sel-extension-config 1450 sel-attribute-config = 1451 "a=" [delete-attributes ":"] mo-att-cap-list 1452 ; defined in Section 3.5.1. 1454 sel-transport-protocol-config = 1455 "t=" trpr-cap-num ; defined in Section 3.5.1. 1457 sel-extension-config = 1458 ext-cap-name "=" 1*VCHAR ; defined in Section 3.5.1. 1460 Note that white space is not permitted before the config-number. 1462 The actual configuration ("a=acfg") attribute can be provided only 1463 at the media-level. There MUST NOT be more than one occurrence of an 1464 actual configuration attribute within a given media description. 1466 Below, we provide an example of the "a=acfg" attribute (building on 1467 the previous example with the potential configuration attribute): 1469 v=0 1470 o=- 24351 621814 IN IP4 192.0.2.2 1471 s= 1472 c=IN IP4 192.0.2.2 1473 t=0 0 1474 m=audio 54568 RTP/SAVPF 0 1475 a=crypto:1 AES_CM_128_HMAC_SHA1_32 1476 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 1477 a=acfg:1 t=4 a=1 1479 It indicates that the answerer used an offer consisting of potential 1480 configuration number 1 with transport protocol capability 4 from the 1481 offer (RTP/SAVPF) and attribute capability 1 (the "crypto" 1482 attribute). The answerer includes his own "crypto" attribute as 1483 well. 1485 3.6. Offer/Answer Model Extensions 1487 In this section, we define extensions to the offer/answer model 1488 defined in [RFC3264] to allow for potential configurations to be 1489 included in an offer, where they constitute alternative offers that 1490 may be accepted by the answerer instead of the actual 1491 configuration(s) included in the "m=" line(s). 1493 The procedures defined in the following subsections apply to both 1494 unicast and multicast streams. 1496 3.6.1. Generating the Initial Offer 1498 An offerer that wants to use the SDP Capability Negotiation defined 1499 in this document MUST include the following in the offer: 1501 o Zero or more attribute capability attributes. There MUST be an 1502 attribute capability attribute ("a=acap") as defined in Section 1503 3.4.1. for each attribute name and associated value (if any) that 1504 needs to be indicated as a capability in the offer. Attribute 1505 capabilities may be included irrespective of whether they are 1506 referenced by a potential configuration or not. 1508 Session-level attributes and associated values MUST be provided 1509 in attribute capabilities only at the session-level, whereas 1510 media-level attributes and associated values can be provided in 1511 attribute capabilities at either the media-level or session- 1512 level. Attributes that are allowed at either the session- or 1513 media-level can be provided in attribute capabilities at either 1514 level. 1516 o Zero or more transport protocol capability attributes. There MUST 1517 be transport protocol capabilities as defined in Section 3.4.2. 1518 with values for each transport protocol that needs to be 1519 indicated as a capability in the offer. Transport protocol 1520 capabilities may be included irrespective of whether they are 1521 referenced by a potential configuration or not. 1523 Transport protocol capabilities that apply to multiple media 1524 descriptions SHOULD be provided at the session-level whereas 1525 transport protocol capabilities that apply only to a specific 1526 media description ("m=" line), SHOULD be provided within that 1527 particular media description. In either case, there MUST NOT be 1528 more than a single "a=tcap" attribute at the session-level and a 1529 single "a=tcap" attribute in each media description. 1531 o Zero or more extension capability attributes. There MUST be one 1532 or more extension capability attributes (as outlined in Section 1533 3.4.3. ) for each extension capability that is referenced by a 1534 potential configuration. Extension capability attributes that are 1535 not referenced by a potential configuration can be provided as 1536 well. 1538 o Zero or more potential configuration attributes. There MUST be 1539 one or more potential configuration attributes ("a=pcfg"), as 1540 defined in Section 3.5.1. , in each media description where 1541 alternative potential configurations are to be negotiated. Each 1542 potential configuration attribute MUST adhere to the rules 1543 provided in Section 3.5.1. and the additional rules provided 1544 below. 1546 If the offerer requires support for one or more extensions (besides 1547 the base protocol defined here), then the offerer MUST include one 1548 or more "a=creq" attributes as follows: 1550 o If support for one or more capability negotiation extensions is 1551 required for the entire session description, then option tags for 1552 those extensions MUST be included in a single session-level 1553 "creq" attribute. 1555 o For each media description that requires support for one or more 1556 capability negotiation extensions not listed at the session- 1557 level, a single "creq" attribute containing all the required 1558 extensions for that media description MUST be included within the 1559 media description (in accordance with Section 3.3.2. ). 1561 Note that extensions that only need to be supported by a particular 1562 potential configuration can use the "mandatory" extension prefix 1563 ("+") within the potential configuration (see Section 3.5.1. ). 1565 The offerer SHOULD furthermore include the following: 1567 o A supported capability negotiation extension attribute ("a=csup") 1568 at the session-level and/or media-level as defined in Section 1569 3.3.2. for each capability negotiation extension supported by the 1570 offerer and not included in a corresponding "a=creq" attribute 1571 (i.e., at the session-level or in the same media description). 1572 Option tags provided in a "a=csup" attribute at the session-level 1573 indicate extensions supported for the entire session description, 1574 whereas option tags provided in a "a=csup" attribute in a media 1575 description indicate extensions supported for only that 1576 particular media description. 1578 Capabilities provided in an offer merely indicate what the offerer 1579 is capable of doing. They do not constitute a commitment or even an 1580 indication to use them. In contrast, each potential configuration 1581 constitutes an alternative offer that the offerer would like to use. 1582 The potential configurations MUST be used by the answerer to 1583 negotiate and establish the session. 1585 The offerer MUST include one or more potential configuration 1586 attributes ("a=pcfg") in each media description where the offerer 1587 wants to provide alternative offers (in the form of potential 1588 configurations). Each potential configuration attribute in a given 1589 media description MUST contain a unique configuration number and 1590 zero, one or more potential configuration lists, as described in 1591 Section 3.5.1. Each potential configuration list MUST refer to 1592 capabilities that are provided at the session-level or within that 1593 particular media description; otherwise, the potential configuration 1594 is considered invalid. The base SDP Capability Negotiation framework 1595 REQUIRES that potential configurations do not reference any session- 1596 level attribute capabilities that contain media-level only 1597 attributes, however extensions may modify this behavior, as long as 1598 it is fully backwards compatible with the base specification. 1599 Furthermore, it is RECOMMENDED that potential configurations avoid 1600 use of session-level capabilities whenever possible; refer to 1601 Section 3.5.1. 1603 The current actual configuration is included in the "m=" line (as 1604 defined by [RFC3264]) and any associated parameters for the media 1605 description (e.g., attribute ("a=") and bandwidth ("b=") lines). 1606 Note that the actual configuration is by default the least-preferred 1607 configuration, and hence the answerer will seek to negotiate use of 1608 one of the potential configurations instead. If the offerer wishes a 1609 different preference for the actual configuration, the offerer MUST 1610 include a corresponding potential configuration with the relevant 1611 configuration number (which indicates the relative preference 1612 between potential configurations); this corresponding potential 1613 configuration should simply duplicate the actual configuration. 1615 This can either be done implicitly (by not referencing any 1616 capabilities), or explicitly (by providing and using capabilities 1617 for the transport protocol and all the attributes that are part of 1618 the actual configuration). The latter may help detect 1619 intermediaries that modify the actual configuration but are not 1620 SDP Capability Negotiation aware. 1622 Per [RFC3264], once the offerer generates the offer, he must be 1623 prepared to receive incoming media in accordance with that offer. 1624 That rule applies here as well, but only for the actual 1625 configurations provided in the offer: Media received by the offerer 1626 according to one of the potential configurations MAY be discarded, 1627 until the offerer receives an answer indicating what the actual 1628 selected configuration is. Once that answer is received, incoming 1629 media MUST be processed in accordance with the actual selected 1630 configuration indicated and the answer received (provided the 1631 offer/answer exchange completed successfully). 1633 The above rule assumes that the offerer can determine whether 1634 incoming media adheres to the actual configuration offered or one of 1635 the potential configurations instead; this may not always be the 1636 case. If the offerer wants to ensure he does not play out any 1637 garbage, the offerer SHOULD discard all media received before the 1638 answer SDP session description is received. Conversely, if the 1639 offerer wants to avoid clipping, he SHOULD attempt to play any 1640 incoming media as soon as it is received (at the risk of playing out 1641 garbage). In either case, please note that this document does not 1642 place any requirements on the offerer to process and play media 1643 before answer. For further details, please refer to Section 3.9. 1645 3.6.2. Generating the Answer 1647 When receiving an offer, the answerer MUST check for the presence of 1648 a required capability negotiation extension attribute ("a=creq") 1649 provided at the session level. If one is found, then capability 1650 negotiation MUST be performed. If none is found, then the answerer 1651 MUST check each offered media description for the presence of a 1652 required capability negotiation extension attribute ("a=creq") and 1653 one or more potential configuration attributes ("a=pcfg"). 1654 Capability negotiation MUST be performed for each media description 1655 where either of those is present in accordance with the procedures 1656 described below. 1658 The answerer MUST first ensure that it supports any required 1659 capability negotiation extensions: 1661 o If a session-level "creq" attribute is provided, and it contains 1662 an option-tag that the answerer does not support, then the 1663 answerer MUST NOT use any of the potential configuration 1664 attributes provided for any of the media descriptions. Instead, 1665 the normal offer/answer procedures MUST continue as per 1666 [RFC3264]. Furthermore, the answerer MUST include a session-level 1667 supported capability negotiation extensions attribute ("a=csup") 1668 with option tags for the capability negotiation extensions 1669 supported by the answerer. 1671 o If a media-level "creq" attribute is provided, and it contains an 1672 option tag that the answerer does not support, then the answerer 1673 MUST NOT use any of the potential configuration attributes 1674 provided for that particular media description. Instead, the 1675 offer/answer procedures for that media description MUST continue 1676 as per [RFC3264] (SDP Capability Negotiation is still performed 1677 for other media descriptions in the SDP session description). 1678 Furthermore, the answerer MUST include a supported capability 1679 negotiation extensions attribute ("a=csup") in that media 1680 description with option tags for the capability negotiation 1681 extensions supported by the answerer for that media description. 1683 Assuming all required capability negotiation extensions are 1684 supported, the answerer now proceeds as follows. 1686 For each media description where capability negotiation is to be 1687 performed (i.e. all required capability negotiation extensions are 1688 supported and at least one valid potential configuration attribute 1689 is present), the answerer MUST perform capability negotiation by 1690 using the most preferred potential configuration that is valid to 1691 the answerer, subject to any local policies. A potential 1692 configuration is valid to the answerer if: 1694 1. It is in accordance with the syntax and semantics provided in 1695 Section 3.5.1. 1697 2. It contains a configuration number that is unique within that 1698 media description. 1700 3. All attribute capabilities referenced by the potential 1701 configuration are valid themselves (as defined in Section 3.4.1. 1702 ) and each of them is provided either at the session-level or 1703 within this particular media description. For session-level 1704 attribute capabilities referenced, the attributes contained 1705 inside them MUST NOT be media-level only attributes. 1707 4. All transport protocol capabilities referenced by the potential 1708 configuration are valid themselves (as defined in Section 3.4.2. 1709 ) and each of them is furthermore provided either at the session- 1710 level or within this particular media description. 1712 5. All extension capabilities referenced by the potential 1713 configuration and supported by the answerer are valid themselves 1714 (as defined by that particular extension) and each of them are 1715 furthermore provided either at the session-level or within this 1716 particular media description. Unknown or unsupported extension 1717 capabilities MUST be ignored, unless they are prefixed with the 1718 plus ("+") sign, which indicates that the extension MUST be 1719 supported in order to use that potential configuration. If the 1720 extension is not supported, that potential configuration is not 1721 valid to the answerer. 1723 The most preferred valid potential configuration in a media 1724 description is the valid potential configuration with the lowest 1725 configuration number. The answerer MUST now process the offer for 1726 that media stream based on the most preferred valid potential 1727 configuration. Conceptually, this entails the answerer constructing 1728 an (internal) offer as follows. First, all capability negotiation 1729 parameters from the offer SDP session description are removed, 1730 thereby yielding an offer SDP session description with the actual 1731 configuration as if SDP capability negotiation was not done in the 1732 first place. Secondly, this actual configuration SDP session 1733 description is then modified as follows for each media stream 1734 offered based on the capability negotiation parameters included 1735 originally: 1737 o If a transport protocol capability is included in the potential 1738 configuration, then it replaces the transport protocol provided 1739 in the "m=" line for that media description. 1741 o If attribute capabilities are present with a delete-attributes 1742 session indication ("-s") or media and session indication ("- 1743 ms"), then all session-level attributes from the actual 1744 configuration SDP session description MUST be deleted in the 1745 resulting potential configuration SDP session description in 1746 accordance with the procedures in Section 3.5.1. If attribute 1747 capabilities are present with a delete-attributes media 1748 indication ("-m") or media and session indication ("-ms"), then 1749 all attributes from the actual configuration SDP session 1750 description inside this media description MUST be deleted. 1752 o If a session-level attribute capability is included, the 1753 attribute (and its associated value, if any) contained in it MUST 1754 be added to the resulting SDP session description. All such added 1755 session-level attributes MUST be listed before the session-level 1756 attributes that were initially present in the SDP session 1757 description. Furthermore, the added session-level attributes MUST 1758 be added in the order they were provided in the potential 1759 configuration (see also Section 3.5.1. ). 1761 This allows for attributes with implicit preference ordering 1762 to be added in the desired order; the "crypto" attribute 1763 [RFC4568] is one such example. 1765 o If a media-level attribute capability is included, then the 1766 attribute (and its associated value, if any) MUST be added to the 1767 resulting SDP session description within the media description in 1768 question. All such added media-level attributes MUST be listed 1769 before the media-level attributes that were initially present in 1770 the media description in question. Furthermore, the added media- 1771 level attributes MUST be added in the order they were provided in 1772 the potential configuration (see also Section 3.5.1. ). 1774 o If a supported extension capability is included, then it MUST be 1775 processed in accordance with the rules provided for that 1776 particular extension capability. 1778 The above steps MUST be performed exactly once per potential 1779 configuration, i.e. there MUST NOT be any recursive processing of 1780 any additional capability negotiation parameters that may have been 1781 nested inside capabilities themselves. 1783 As an example of this, consider the attribute capability 1785 a=acap:1 acap:2 foo:a 1787 The resulting potential configuration SDP session description 1788 will, after the above processing has been done, contain the 1789 attribute capability 1791 a=acap:2 foo:a 1793 However, since we do not perform any recursive processing of 1794 capability negotiation parameters, this second attribute 1795 capability parameter will not be processed by the offer/answer 1796 procedure. Instead, it will simply appear as a (useless) attribute 1797 in the SDP session description that will be ignored by further 1798 processing. 1800 Note that a transport protocol from the potential configuration 1801 replaces the transport protocol in the actual configuration, but an 1802 attribute capability from the potential configuration is simply 1803 added to the actual configuration. In some cases, this can result in 1804 having one or more meaningless attributes in the resulting potential 1805 configuration SDP session description, or worse, ambiguous or 1806 potentially even illegal attributes. Use of delete-attributes for 1807 the session and/or media level attributes MUST be done to avoid such 1808 scenarios. Nevertheless, it is RECOMMENDED that implementations 1809 ignore meaningless attributes that may result from potential 1810 configurations. 1812 For example, if the actual configuration was using Secure RTP and 1813 included an "a=crypto" attribute for the SRTP keying material, 1814 then use of a potential configuration that uses plain RTP would 1815 make the "crypto" attribute meaningless. The answerer may or may 1816 not ignore such a meaningless attribute. The offerer can here 1817 ensure correct operation by using delete-attributes to remove the 1818 crypto attribute (but will then need to provide attribute 1819 capabilities to reconstruct the SDP session description with the 1820 necessary attributes deleted, e.g. rtpmaps). 1822 Also note, that while it is permissible to include media-level 1823 attribute capabilities at the session-level, the base SDP Capability 1824 Negotiation framework defined here does not define any procedures 1825 for use of them, i.e. the answerer effectively ignores them. 1827 Please refer to Section 3.6.2.1. for examples of how the answerer 1828 may conceptually "see" the resulting offered alternative potential 1829 configurations. 1831 The answerer MUST check that he supports all mandatory attribute 1832 capabilities from the potential configuration (if any), the 1833 transport protocol capability (if any) from the potential 1834 configuration, and all mandatory extension capabilities from the 1835 potential configuration (if any). If he does not, the answerer MUST 1836 proceed to the second-most preferred valid potential configuration 1837 for the media description, etc. 1839 o In the case of attribute capabilities, support implies that the 1840 attribute name contained in the capability is supported and it 1841 can (and will) be negotiated successfully in the offer/answer 1842 exchange with the value provided. This does not necessarily imply 1843 that the value provided is supported in its entirety. For 1844 example, the "a=fmtp" parameter is often provided with one or 1845 more values in a list, where the offerer and answerer negotiate 1846 use of some subset of the values provided. Other attributes may 1847 include mandatory and optional parts to their values; support for 1848 the mandatory part is all that is required here. 1850 A side-effect of the above rule is that whenever an "fmtp" or 1851 "rtpmap" parameter is provided as a mandatory attribute 1852 capability, the corresponding media format (codec) must be 1853 supported and use of it negotiated successfully. If this is 1854 not the offerer's intent, the corresponding attribute 1855 capabilities must be listed as optional instead. 1857 o In the case of transport protocol capabilities, support implies 1858 that the transport protocol contained in the capability is 1859 supported and the transport protocol can (and will) be negotiated 1860 successfully in the offer/answer exchange. 1862 o In the case of extension capabilities, the extension MUST define 1863 the rules for when the extension capability is considered 1864 supported and those rules MUST be satisfied. 1866 If the answerer has exhausted all potential configurations for the 1867 media description, without finding a valid one that is also 1868 supported, then the answerer MUST process the offered media stream 1869 based on the actual configuration plus any session-level attributes 1870 added by a valid and supported potential configuration from another 1871 media description in the offered SDP session description. 1873 The above process describes potential configuration selection as a 1874 per media stream process. Inter-media stream coordination of 1875 selected potential configurations however is required in some cases. 1876 First of all, session-level attributes added by a potential 1877 configuration for one media description MUST NOT cause any problems 1878 for potential configurations selected by other media descriptions in 1879 the offer SDP session description. If the session-level attributes 1880 are mandatory, then those session-level attributes MUST furthermore 1881 be supported by the session as a whole (i.e., all the media 1882 descriptions if relevant). As mentioned earlier, this adds 1883 additional complexity to the overall processing and hence it is 1884 RECOMMENDED not to use session-level attribute capabilities in 1885 potential configurations, unless absolutely necessary. 1887 Once the answerer has selected a valid and supported offered 1888 potential configuration for all of the media streams (or has fallen 1889 back to the actual configuration plus any added session attributes), 1890 the answerer MUST generate a valid virtual answer SDP session 1891 description based on the selected potential configuration SDP 1892 session description, as "seen" by the answerer using normal 1893 offer/answer rules (see Section 3.6.2.1. for examples). The actual 1894 answer is formed from the virtual answer as follows: If the answerer 1895 selected one of the potential configurations in a media description, 1896 the answerer MUST include an actual configuration attribute 1897 ("a=acfg") within that media description. The "a=acfg" attribute 1898 MUST identify the configuration number for the selected potential 1899 configuration as well as the actual parameters that were used from 1900 that potential configuration; if the potential configuration 1901 included alternatives, the selected alternatives only MUST be 1902 included. Only the known and supported parameters will be included. 1903 Unknown or unsupported parameters MUST NOT be included in the actual 1904 configuration attribute. In the case of attribute capabilities, only 1905 the known and supported capabilities are included; unknown or 1906 unsupported attribute capabilities MUST NOT be included. 1908 If the answerer supports one or more capability negotiation 1909 extensions that were not included in a required capability 1910 negotiation extensions attribute in the offer, then the answerer 1911 SHOULD furthermore include a supported capability negotiation 1912 attribute ("a=csup") at the session-level with option tags for the 1913 extensions supported across media streams. Also, if the answerer 1914 supports one or more capability negotiation extensions for only 1915 particular media descriptions, then a supported capability 1916 negotiation attribute with those option-tags SHOULD be included 1917 within each relevant media description. The required capability 1918 negotiation attribute ("a=creq") MUST NOT be used in an answer. 1920 The offerer's originally provided actual configuration is contained 1921 in the offer media description's "m=" line (and associated 1922 parameters). The answerer MAY send media to the offerer in 1923 accordance with that actual configuration as soon as it receives the 1924 offer, however it MUST NOT send media based on that actual 1925 configuration if it selects an alternative potential configuration. 1926 If the answerer selects one of the potential configurations, then 1927 the answerer MAY immediately start to send media to the offerer in 1928 accordance with the selected potential configuration, however the 1929 offerer MAY discard such media or play out garbage until the offerer 1930 receives the answer. Please refer to section 3.9. for additional 1931 considerations and possible alternative solutions outside the base 1932 SDP Capability Negotiation framework. 1934 If the offerer selected a potential configuration instead of the 1935 actual configuration, then it is RECOMMENDED that the answerer sends 1936 back an answer SDP session description as soon as possible. This 1937 minimizes the risk of having media discarded or played out as 1938 garbage by the offerer. In the case of SIP [RFC3261] without any 1939 extensions, this implies that if the offer was received in an INVITE 1940 message, then the answer SDP session description should be provided 1941 in the first non-100 provisional response sent back (per RFC3261, 1942 the answer would need to be repeated in the 200 response as well, 1943 unless a relevant extension such as [RFC3262] is being used). 1945 3.6.2.1. Example Views of Potential Configurations 1947 The following examples illustrate how the answerer may conceptually 1948 "see" a potential configuration. Consider the following offered SDP 1949 session description: 1951 v=0 1952 o=alice 2891092738 2891092738 IN IP4 lost.example.com 1953 s= 1954 t=0 0 1955 c=IN IP4 lost.example.com 1956 a=tool:foo 1957 a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 1958 a=tcap:1 RTP/SAVP RTP/AVP 1959 m=audio 59000 RTP/AVP 98 1960 a=rtpmap:98 AMR/8000 1961 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32 1962 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 1963 a=pcfg:1 t=1 a=1|2 1964 m=video 52000 RTP/AVP 31 1965 a=rtpmap:31 H261/90000 1966 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 1967 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 1968 a=pcfg:1 t=1 a=1|3 1970 This particular SDP session description offers an audio stream and a 1971 video stream, each of which can either use plain RTP (actual 1972 configuration) or secure RTP (potential configuration). Furthermore, 1973 two different keying mechanisms are offered, namely session-level 1974 Key Management Extensions using MIKEY (attribute capability 1) and 1975 media-level SDP Security Descriptions (attribute capabilities 2 and 1976 3). There are several potential configurations here, however, below 1977 we show the one the answerer "sees" when using potential 1978 configuration 1 for both audio and video, and furthermore using 1979 attribute capability 1 (MIKEY) for both (we have removed all the 1980 capability negotiation attributes for clarity): 1982 v=0 1983 o=alice 2891092738 2891092738 IN IP4 lost.example.com 1984 s= 1985 t=0 0 1986 c=IN IP4 lost.example.com 1987 a=tool:foo 1988 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 1989 m=audio 59000 RTP/SAVP 98 1990 a=rtpmap:98 AMR/8000 1991 m=video 52000 RTP/SAVP 31 1992 a=rtpmap:31 H261/90000 1994 Note that the transport protocol in the media descriptions indicate 1995 use of secure RTP. 1997 Below, we show the offer the answerer "sees" when using potential 1998 configuration 1 for both audio and video and furthermore using 1999 attribute capability 2 and 3 respectively (SDP security 2000 descriptions) for the audio and video stream - note the order in 2001 which the resulting attributes are provided: 2003 v=0 2004 o=alice 2891092738 2891092738 IN IP4 lost.example.com 2005 s= 2006 t=0 0 2007 c=IN IP4 lost.example.com 2008 a=tool:foo 2009 m=audio 59000 RTP/SAVP 98 2010 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2011 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2012 a=rtpmap:98 AMR/8000 2013 m=video 52000 RTP/SAVP 31 2014 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2015 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2016 a=rtpmap:31 H261/90000 2018 Again, note that the transport protocol in the media descriptions 2019 indicate use of secure RTP. 2021 And finally, we show the offer the answerer "sees" when using 2022 potential configuration 1 with attribute capability 1 (MIKEY) for 2023 the audio stream, and potential configuration 1 with attribute 2024 capability 3 (SDP security descriptions) for the video stream: 2026 v=0 2027 o=alice 2891092738 2891092738 IN IP4 lost.example.com 2028 s= 2029 t=0 0 2030 c=IN IP4 lost.example.com 2031 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2032 a=tool:foo 2033 m=audio 59000 RTP/SAVP 98 2034 a=rtpmap:98 AMR/8000 2035 m=video 52000 RTP/SAVP 31 2036 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2037 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2038 a=rtpmap:31 H261/90000 2040 3.6.3. Offerer Processing of the Answer 2042 When the offerer attempted to use SDP Capability Negotiation in the 2043 offer, the offerer MUST examine the answer for actual use of SDP 2044 Capability Negotiation. 2046 For each media description where the offerer included a potential 2047 configuration attribute ("a=pcfg"), the offerer MUST first examine 2048 that media description for the presence of a valid actual 2049 configuration attribute ("a=acfg"). An actual configuration 2050 attribute is valid if 2052 o it refers to a potential configuration that was present in the 2053 corresponding offer, and 2055 o it contains the actual parameters that were used from that 2056 potential configuration; if the potential configuration included 2057 alternatives, the selected alternatives only MUST be included. 2058 Note that the answer will include only parameters and attribute 2059 capabilities that are known and supported by the answerer, as 2060 described in Section 3.6.2. 2062 If a valid actual configuration attribute is not present in a media 2063 description, then the offerer MUST process the answer SDP session 2064 description for that media stream per the normal offer/answer rules 2065 defined in [RFC3264]. However, if one is found, the offerer MUST 2066 instead process the answer as follows: 2068 o The actual configuration attribute specifies which of the 2069 potential configurations was used by the answerer to generate the 2070 answer for this media stream. This includes all the supported 2071 attribute capabilities and the transport capabilities referenced 2072 by the potential configuration selected, where the attribute 2073 capabilities have any associated delete-attributes included. 2074 Extension capabilities supported by the answerer are included as 2075 well. 2077 o The offerer MUST now process the answer in accordance with the 2078 rules in [RFC3264], except that it must be done as if the offer 2079 consisted of the selected potential configuration instead of the 2080 original actual configuration, including any transport protocol 2081 changes in the media ("m=") line(s), attributes added and deleted 2082 by the potential configuration at the media and session level, 2083 and any extensions used. If this derived answer is not a valid 2084 answer to the potential configuration offer selected by the 2085 answerer, the offerer MUST instead continue further processing as 2086 it would have for a regular offer/answer exchange, where the 2087 answer received does not adhere to the rules of [RFC3264]. 2089 If the offer/answer exchange was successful, and if the answerer 2090 selected one of the potential configurations from the offer as the 2091 actual configuration, and the selected potential configuration 2092 differs from the actual configuration in the offer (the "m=", "a=", 2093 etc. lines), then the offerer SHOULD initiate another offer/answer 2094 exchange. This second offer/answer exchange will not modify the 2095 session in any way, however it will help intermediaries (e.g. 2096 middleboxes), that look at the SDP session description but do not 2097 support the capability negotiation extensions, understand the 2098 details of the media stream(s) that were actually negotiated. This 2099 new offer MUST contain the selected potential configuration as the 2100 actual configuration, i.e., with the actual configuration used in 2101 the "m=" line and any other relevant attributes, bandwidth 2102 parameters, etc. 2104 Note that, per normal offer/answer rules, the second offer/answer 2105 exchange still needs to update the version number in the "o=" line 2106 (( in [RFC4566]). Attribute lines carrying keying 2107 material SHOULD repeat the keys from the previous offer, unless re- 2108 keying is necessary, e.g. due to a previously forked SIP INVITE 2109 request. Please refer to Section 3.12. for additional considerations 2110 related to intermediaries. 2112 3.6.4. Modifying the Session 2114 Capabilities and potential configurations may be included in 2115 subsequent offers as defined in [RFC3264], Section 8. The procedure 2116 for doing so is similar to that described above with the answer 2117 including an indication of the actual selected configuration used by 2118 the answerer. 2120 If the answer indicates use of a potential configuration from the 2121 offer, then the guidelines provided in Section 3.6.3. for doing a 2122 second offer/answer exchange using that potential configuration as 2123 the actual configuration apply. 2125 3.7. Interactions with ICE 2127 Interactive Connectivity Establishment (ICE) [ICE] provides a 2128 mechanism for verifying connectivity between two endpoints by 2129 sending STUN messages directly between the media endpoints. The 2130 basic ICE specification [ICE] is only defined to support UDP-based 2131 connectivity, however it allows for extensions to support other 2132 transport protocols, such as TCP, which is being specified in 2133 [ICETCP]. ICE defines a new "a=candidate" attribute, which, among 2134 other things, indicates the possible transport protocol(s) to use 2135 and then associates a priority with each of them. The most preferred 2136 transport protocol that *successfully* verifies connectivity will 2137 end up being used. 2139 When using ICE, it is thus possible that the transport protocol that 2140 will be used differs from what is specified in the "m=" line. Since 2141 both ICE and SDP Capability Negotiation may specify alternative 2142 transport protocols, there is a potentially unintended interaction 2143 when using these together. 2145 We provide the following guidelines for addressing that. 2147 There are two basic scenarios to consider: 2149 1) A particular media stream can run over different transport 2150 protocols (e.g. UDP, TCP, or TCP/TLS), and the intent is simply to 2151 use the one that works (in the preference order specified). 2153 2) A particular media stream can run over different transport 2154 protocols (e.g. UDP, TCP, or TCP/TLS) and the intent is to have the 2155 negotiation process decide which one to use (e.g. T.38 over TCP or 2156 UDP). 2158 In scenario 1, there should be ICE "a=candidate" attributes for UDP, 2159 TCP, etc. but otherwise nothing special in the potential 2160 configuration attributes to indicate the desire to use different 2161 transport protocols (e.g. UDP, or TCP). The ICE procedures 2162 essentially cover the capability negotiation required (by having the 2163 answerer select something it supports and then use of trial and 2164 error connectivity checks). 2166 Scenario 2 does not require a need to support or use ICE. Instead, 2167 we simply use transport protocol capabilities and potential 2168 configuration attributes to indicate the desired outcome. 2170 The scenarios may be combined, e.g. by offering potential 2171 configuration alternatives where some of them can support only one 2172 transport protocol (e.g. UDP), whereas others can support multiple 2173 transport protocols (e.g. UDP or TCP). In that case, there is a need 2174 for tight control over the ICE candidates that will be used for a 2175 particular configuration, yet the actual configuration may want to 2176 use all of the ICE candidates. In that case, the ICE candidate 2177 attributes can be defined as attribute capabilities and the relevant 2178 ones should then be included in the proper potential configurations 2179 (for example candidate attributes for UDP only for potential 2180 configurations that are restricted to UDP, whereas there could be 2181 candidate attributes for UDP, TCP, and TCP/TLS for potential 2182 configurations that can use all three). Furthermore, use of the 2183 delete-attributes in a potential configuration can be used to ensure 2184 that ICE will not end up using a transport protocol that is not 2185 desired for a particular configuration. 2187 SDP Capability Negotiation recommends use of a second offer/answer 2188 exchange when the negotiated actual configuration was one of the 2189 potential configurations from the offer (see Section 3.6.3. ). 2190 Similarly, ICE requires use of a second offer/answer exchange if the 2191 chosen candidate is not the same as the one in the m/c-line from the 2192 offer. When ICE and capability negotiation are used at the same 2193 time, the two secondary offer/answer exchanges SHOULD be combined to 2194 a single one. 2196 3.8. Interactions with SIP Option Tags 2198 SIP [RFC3261] allows for SIP extensions to define a SIP option tag 2199 that identifies the SIP extension. Support for one or more such 2200 extensions can be indicated by use of the SIP Supported header, and 2201 required support for one or more such extensions can be indicated by 2202 use of the SIP Require header. The "a=csup" and "a=creq" attributes 2203 defined by the SDP Capability Negotiation framework are similar, 2204 except that support for these two attributes by themselves cannot be 2205 guaranteed (since they are specified as extensions to the SDP 2206 specification [RFC4566] itself). 2208 SIP extensions with associated option tags can introduce 2209 enhancements to not only SIP, but also SDP. This is for example the 2210 case for SIP preconditions defined in [RFC3312]. When using SDP 2211 Capability Negotiation, some potential configurations may include 2212 certain SDP extensions, whereas others may not. Since the purpose of 2213 the SDP Capability Negotiation is to negotiate a session based on 2214 the features supported by both sides, use of the SIP Require header 2215 for such extensions may not produce the desired result. For example, 2216 if one potential configuration requires SIP preconditions support, 2217 another does not, and the answerer does not support preconditions, 2218 then use of the SIP Require header for preconditions would result in 2219 a session failure, in spite of the fact that a valid and supported 2220 potential configuration was included in the offer. 2222 In general, this can be alleviated by use of mandatory and optional 2223 attribute capabilities in a potential configuration. There are 2224 however cases where permissible SDP values are tied to the use of 2225 the SIP Require header. SIP preconditions [RFC3312] is one such 2226 example, where preconditions with a "mandatory" strength-tag can 2227 only be used when a SIP Require header with the SIP option tag 2228 "precondition" is included. Future SIP extensions that may want to 2229 use the SDP Capability Negotiation framework should avoid such 2230 coupling. 2232 3.9. Processing Media before Answer 2234 The offer/answer model [RFC3264] requires an offerer to be able to 2235 receive media in accordance with the offer prior to receiving the 2236 answer. This property is retained with the SDP Capability 2237 Negotiation extensions defined here, but only when the actual 2238 configuration is selected by the answerer. If a potential 2239 configuration is chosen, the offerer may decide to not process any 2240 media received before the answer is received. This may lead to 2241 clipping. Consequently, the SDP Capability Negotiation framework 2242 recommends sending back an answer SDP session description as soon as 2243 possible. 2245 The issue can be resolved by introducing a three-way handshake. In 2246 the case of SIP, this can for example be done by defining a 2247 precondition [RFC3312] for capability negotiation (or use an 2248 existing precondition that is known to generate a second 2249 offer/answer exchange before proceeding with the session). However, 2250 preconditions are often viewed as complicated to implement and they 2251 may add to overall session establishment delay by requiring an extra 2252 offer/answer exchange. 2254 An alternative three-way handshake can be performed by use of ICE 2255 [ICE]. When ICE is being used, and the answerer receives a STUN 2256 Binding Request for any one of the accepted media streams from the 2257 offerer, the answerer knows the offer has received his answer. At 2258 that point, the answerer knows that the offerer will be able to 2259 process incoming media according to the negotiated configuration and 2260 hence he can start sending media without the risk of the offerer 2261 either discarding it or playing garbage. 2263 Please note that, the above considerations notwithstanding, this 2264 document does not place any requirements on the offerer to process 2265 and play media before answer; it merely provides recommendations for 2266 how to ensure that media sent by the answerer and received by the 2267 offerer prior to receiving the answer, can in fact be rendered by 2268 the offerer. 2270 In some use cases a three-way handshake is not needed. An example is 2271 when the offerer does not need information from the answer, such as 2272 keying material in the SDP session description, in order to process 2273 incoming media. The SDP Capability Negotiation framework does not 2274 define any such solutions, however extensions may do so. For 2275 example, one technique proposed for best-effort SRTP in [BESRTP] is 2276 to provide different RTP payload type mappings for different 2277 transport protocols used, outside of the actual configuration, while 2278 still allowing them to be used by the answerer (exchange of keying 2279 material is still needed, e.g. inband). The basic SDP Capability 2280 Negotiation framework defined here does not include the ability to 2281 do so, however extensions that enable that may be defined. 2283 3.10. Indicating Bandwidth Usage 2285 The amount of bandwidth used for a particular media stream depends 2286 on the negotiated codecs, transport protocol and other parameters. 2287 For example use of Secure RTP [RFC3711] with integrity protection 2288 requires more bandwidth than plain RTP [RFC3551]. SDP defines the 2289 bandwidth ("b=") parameter to indicate the proposed bandwidth for 2290 the session or media stream. 2292 In SDP as defined by [RFC4566], each media description contains one 2293 transport protocol and one or more codecs. When specifying the 2294 proposed bandwidth, the worst case scenario must be taken into 2295 account, i.e., use of the highest bandwidth codec provided, the 2296 transport protocol indicated, and the worst case (bandwidth-wise) 2297 parameters that can be negotiated (e.g., a 32-bit HMAC or an 80-bit 2298 HMAC). 2300 The base SDP Capability Negotiation framework does not provide a way 2301 to negotiate bandwidth parameters. The issue thus remains, however 2302 it is potentially worse than with SDP per [RFC4566], since it is 2303 easier to negotiate additional codecs, and furthermore possible to 2304 negotiate different transport protocols. The recommended approach 2305 for addressing this is the same as for plain SDP; the worst case 2306 (now including potential configurations) needs to be taken into 2307 account when specifying the bandwidth parameters in the actual 2308 configuration. This can make the bandwidth value less accurate than 2309 in SDP per [RFC4566] (due to potential greater variability in the 2310 potential configuration bandwidth use). Extensions can be defined to 2311 address this shortcoming. 2313 The Transport Independent Application Specific Maximum (TIAS) 2314 bandwidth type as defined in [RFC3890] SHOULD NOT be used to try and 2315 alleviate bandwidth variability concerns due to different transport 2316 protocols since there are some inconsistencies between [RFC3264] and 2317 [RFC3890]. More specifically, [RFC3264] defines the bandwidth 2318 parameter to apply to the receive direction for unicast streams, 2319 whereas [RFC3890] intends to use bandwidth in the send direction. 2320 Implementers are encouraged to look for an expected future solution 2321 to this. 2323 Note, that when using RTP retransmission [RFC4588] with the RTCP- 2324 based feedback profile [RFC4585] (RTP/AVPF), the retransmitted 2325 packets are part of the media stream bandwidth when using SSRC- 2326 multiplexing. If a feedback based protocol is offered as the actual 2327 configuration transport protocol, a non-feedback based protocol is 2328 offered as a potential configuration transport protocol and ends up 2329 being used, the actual bandwidth usage may be lower than the 2330 indicated bandwidth value in the offer (and vice versa). 2332 3.11. Dealing with Large Number of Potential Configurations 2334 When using the SDP Capability Negotiation, it is easy to generate 2335 offers that contain a large number of potential configurations. For 2336 example, in the offer: 2338 v=0 2339 o=- 25678 753849 IN IP4 192.0.2.1 2340 s= 2341 c=IN IP4 192.0.2.1 2342 t=0 0 2343 m=audio 53456 RTP/AVP 0 18 2344 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF 2345 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 2346 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 2347 FEC_ORDER=FEC_SRTP 2348 a=acap:2 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2349 a=acap:3 rtcp-fb:0 nack 2350 a=pcfg:1 t=1 a=1,3|2,3 2351 a=pcfg:2 t=2 a=1|2 2352 a=pcfg:3 t=3 a=3 2354 we have 5 potential configurations on top of the actual 2355 configuration for a single media stream. Adding an extension 2356 capability with just two alternatives for each would double that 2357 number (to 10), and doing the equivalent with two media streams 2358 would again double that number (to 20). While it is easy (and 2359 inexpensive) for the offerer to generate such offers, processing 2360 them at the answering side may not be. Consequently, it is 2361 RECOMMENDED that offerers do not create offers with unnecessarily 2362 large number of potential configurations in them. 2364 On the answering side, implementers MUST take care to avoid 2365 excessive memory and CPU consumption. For example, a naive 2366 implementation that first generates all the valid potential 2367 configuration SDP session descriptions internally, could find itself 2368 being memory exhausted, especially if it supports a large number of 2369 endpoints. Similarly, a naive implementation that simply performs 2370 iterative trial-and-error processing on each possible potential 2371 configuration SDP session description (in the preference order 2372 specified) could find itself being CPU constrained. An alternative 2373 strategy is to prune the search space first by discarding the set of 2374 offered potential configurations where the transport protocol 2375 indicated (if any) is not supported, and/or one or more mandatory 2376 attribute capabilities (if any) are either not supported or not 2377 valid. Potential configurations with unsupported mandatory extension 2378 configurations in them can be discarded as well. 2380 3.12. SDP Capability Negotiation and Intermediaries 2382 An intermediary is here defined as an entity between a SIP user 2383 agent A and a SIP user agent B, that need to perform some kind of 2384 processing on the SDP session descriptions exchanged between A and 2385 B, in order for the session establishment to operate as intended. 2386 Examples of such intermediaries include Session Border Controllers 2387 (SBCs) that may perform media relaying, Proxy Call Session Control 2388 Functions (P-CSCF) that may authorize use of a certain amount of 2389 network resources (bandwidth), etc. The presence and design of such 2390 intermediaries may not follow the "Internet" model or the SIP 2391 requirements for proxies (which are not supposed to look in message 2392 bodies such as SDP session descriptions), however they are a fact of 2393 life in some deployment scenarios and hence deserve consideration. 2395 If the intermediary needs to understand the characteristics of the 2396 media sessions being negotiated, e.g. the amount of bandwidth used 2397 or the transport protocol negotiated, then use of the SDP Capability 2398 Negotiation framework may impact them. For example, some 2399 intermediaries are known to disallow answers where the transport 2400 protocol differs from the one in the offer. Use of the SDP 2401 Capability Negotiation framework in the presence of such 2402 intermediaries could lead to session failures. Intermediaries that 2403 need to authorize use of network resources based on the negotiated 2404 media stream parameters are affected as well. If they inspect only 2405 the offer, then they may authorize parameters assuming a different 2406 transport protocol, codecs, etc. than what is actually being 2407 negotiated. For these, and other, reasons it is RECOMMENDED that 2408 implementers of intermediaries add support for the SDP Capability 2409 Negotiation framework. 2411 The SDP Capability Negotiation framework itself attempts to help out 2412 these intermediaries as well, by recommending a second offer/answer 2413 exchange when use of a potential configuration has been negotiated 2414 (see Section 3.6.3. ). However, there are several limitations with 2415 this approach. First of all, although the second offer/answer 2416 exchange is RECOMMENDED, it is not required and hence may not be 2417 performed. Secondly, the intermediary may refuse the initial answer, 2418 e.g. due to perceived transport protocol mismatch. Thirdly, the 2419 strategy is not foolproof, since the offer/answer procedures 2420 [RFC3264] leave the original offer/answer exchange in effect when a 2421 subsequent one fails; consider the following example: 2423 1. Offerer generates an SDP session description offer with the 2424 actual configuration specifying a low bandwidth configuration 2425 (e.g. plain RTP) and a potential configuration specifying a 2426 high(er) bandwidth configuration (e.g. secure RTP with 2427 integrity). 2429 2. An intermediary (e.g. an SBC or P-CSCF), that does not support 2430 SDP Capability Negotiation, authorizes the session based on the 2431 actual configuration it sees in the SDP session description. 2433 3. The answerer chooses the high(er) bandwidth potential 2434 configuration and generates an answer SDP session description 2435 based on that. 2437 4. The intermediary passes through the answer SDP session 2438 description. 2440 5. The offerer sees the accepted answer, and generates an updated 2441 offer that contains the selected potential configuration as the 2442 actual configuration. In other words, the high(er) bandwidth 2443 configuration (which has already been negotiated successfully) is 2444 now the actual configuration in the offer SDP session 2445 description. 2447 6. The intermediary sees the new offer, however it does not 2448 authorize the use of the high(er) bandwidth configuration, and 2449 consequently generates a rejection message to the offerer. 2451 7. The offerer receives the rejected offer. 2453 After step 7, per RFC 3264, the offer/answer exchange that completed 2454 in step 5 remains in effect, however the intermediary may not have 2455 authorized the necessary network resources and hence the media 2456 stream may experience quality issues. The solution to this problem 2457 is to upgrade the intermediary to support the SDP Capability 2458 Negotiation framework. 2460 3.13. Considerations for Specific Attribute Capabilities 2462 3.13.1. The rtpmap and fmtp Attributes 2464 The base SDP Capability Negotiation framework defines transport 2465 capabilities and attribute capabilities. Media capabilities, which 2466 can be used to describe media formats and their associated 2467 parameters, are not defined in this document, however the "rtpmap" 2468 and "fmtp" attributes can nevertheless be used as attribute 2469 capabilities. Using such attribute capabilities in a potential 2470 configuration requires a bit of care though. 2472 The rtpmap parameter binds an RTP payload type to a media format 2473 (e.g. codec). While it is possible to provide rtpmaps for payload 2474 types not found in the corresponding "m=" line, such rtpmaps provide 2475 no value in normal offer/answer exchanges, since only the payload 2476 types found in the "m=" line are part of the offer (or answer). This 2477 applies to the base SDP Capability Negotiation framework as well: 2478 Only the media formats (e.g. RTP payload types) provided in the "m=" 2479 line are actually offered; inclusion of rtpmap attributes with other 2480 RTP payload types in a potential configuration does not change this 2481 fact and hence they do not provide any useful information there. 2482 They may still be useful as pure capabilities though (outside a 2483 potential configuration) in order to inform a peer of additional 2484 codecs supported. 2486 It is possible to provide an rtpmap attribute capability with a 2487 payload type mapping to a different codec than a corresponding 2488 actual configuration "rtpmap" attribute for the media description 2489 has. Such practice is permissible as a way of indicating a 2490 capability. If that capability is included in a potential 2491 configuration, then delete-attributes (see Section 3.5.1. ) MUST be 2492 used to ensure that there is not multiple rtpmap attributes for the 2493 same payload type in a given media description (which would not be 2494 allowed by SDP [RFC4566]). 2496 Similar considerations and rules apply to the "fmtp" attribute. An 2497 fmtp attribute capability for a media format not included in the 2498 "m=" line is useless in a potential configuration (but may be useful 2499 as a capability by itself). An fmtp attribute capability in a 2500 potential configuration for a media format that already has an fmtp 2501 attribute in the actual configuration may lead to multiple fmtp 2502 format parameters for that media format and that is not allowed by 2503 SDP [RFC4566]. The delete-attributes MUST be used to ensure that 2504 there is not multiple fmtp attributes for a given media format in a 2505 media description. 2507 Extensions to the base SDP Capability Negotiation framework may 2508 change the above behavior. 2510 3.13.2. Direction Attributes 2512 SDP defines the "inactive", "sendonly", "recvonly", and "sendrecv" 2513 direction attributes. The direction attributes can be applied at 2514 either the session-level or the media-level. In either case, it is 2515 possible to define attribute capabilities for these direction 2516 capabilities; if used by a potential configuration, the normal 2517 offer/answer procedures still apply. For example, if an offered 2518 potential configuration includes the "sendonly" direction attribute, 2519 and it is selected as the actual configuration, then the answer MUST 2520 include a corresponding "recvonly" (or "inactive") attribute. 2522 3.14. Relationship to RFC 3407 2524 RFC 3407 defines capability descriptions with limited abilities to 2525 describe attributes, bandwidth parameters, transport protocols and 2526 media formats. RFC 3407 does not define any negotiation procedures 2527 for actually using those capability descriptions. 2529 This document defines new attributes for describing attribute 2530 capabilities and transport capabilities. It also defines procedures 2531 for using those capabilities as part of an offer/answer exchange. In 2532 contrast to RFC 3407, this document does not define bandwidth 2533 parameters, and it also does not define how to express ranges of 2534 values. Extensions to this document may be defined in order to fully 2535 cover all the capabilities provided by RFC 3407 (for example more 2536 general media capabilities). 2538 It is RECOMMENDED that implementations use the attributes and 2539 procedures defined in this document instead of those defined in 2540 [RFC3407]. If capability description interoperability with legacy 2541 RFC 3407 implementations is desired, implementations MAY include 2542 both RFC 3407 capability descriptions and capabilities defined by 2543 this document. The offer/answer negotiation procedures defined in 2544 this document will not use the RFC 3407 capability descriptions. 2546 4. Examples 2548 In this section, we provide examples showing how to use the SDP 2549 Capability Negotiation. 2551 4.1. Multiple Transport Protocols 2553 The following example illustrates how to use the SDP Capability 2554 Negotiation extensions to negotiate use of one out of several 2555 possible transport protocols. The offerer uses the expected least- 2556 common-denominator (plain RTP) as the actual configuration, and the 2557 alternative transport protocols as the potential configurations. 2559 The example is illustrated by the offer/answer exchange below, where 2560 Alice sends an offer to Bob: 2562 Alice Bob 2564 | (1) Offer (RTP/[S]AVP[F]) | 2565 |--------------------------------->| 2566 | | 2567 | (2) Answer (RTP/AVPF) | 2568 |<---------------------------------| 2569 | | 2570 | (3) Offer (RTP/AVPF) | 2571 |--------------------------------->| 2572 | | 2573 | (4) Answer (RTP/AVPF) | 2574 |<---------------------------------| 2575 | | 2577 Alice's offer includes plain RTP (RTP/AVP), RTP with RTCP-based 2578 feedback (RTP/AVPF), Secure RTP (RTP/SAVP), and Secure RTP with 2579 RTCP-based feedback (RTP/SAVPF) as alternatives. RTP is the default, 2580 with RTP/SAVPF, RTP/SAVP, and RTP/AVPF as the alternatives and 2581 preferred in the order listed: 2583 v=0 2584 o=- 25678 753849 IN IP4 192.0.2.1 2585 s= 2586 c=IN IP4 192.0.2.1 2587 t=0 0 2588 m=audio 53456 RTP/AVP 0 18 2589 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF 2590 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 2591 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 2592 FEC_ORDER=FEC_SRTP 2593 a=acap:2 rtcp-fb:0 nack 2594 a=pcfg:1 t=1 a=1,[2] 2595 a=pcfg:2 t=2 a=1 2596 a=pcfg:3 t=3 a=[2] 2598 The "m=" line indicates that Alice is offering to use plain RTP with 2599 PCMU or G.729. The capabilities are provided by the "a=tcap" and 2600 "a=acap" attributes. The "tcap" capability indicates that Secure 2601 RTP with RTCP-Based feedback (RTP/SAVPF), Secure RTP (RTP/SAVP), and 2602 RTP with RTCP-Based feedback are supported. The first "acap" 2603 attribute provides an attribute capability with a handle of 1. The 2604 capability is a "crypto" attribute, which provides the keying 2605 material for SRTP using SDP security descriptions [RFC4568]. The 2606 second "acap" attribute provides an attribute capability with a 2607 handle of 2. The capability is an "rtcp-fb" attribute, which is used 2608 by the RTCP-based feedback profiles to indicate that payload type 0 2609 (PCMU) supports feedback type "nack". The "a=pcfg" attributes 2610 provide the potential configurations included in the offer by 2611 reference to the capabilities. There are three potential 2612 configurations: 2614 o Potential configuration 1, which is the most preferred potential 2615 configuration specifies use of transport protocol capability 1 2616 (RTP/SAVPF) and attribute capabilities 1 (the "crypto" attribute) 2617 and 2 (the "rtcp-fb" attribute). Support for the first one is 2618 mandatory whereas support for the second one is optional. 2620 o Potential configuration 2, which is the second most preferred 2621 potential configuration specifies use of transport protocol 2622 capability 2 (RTP/SAVP) and mandatory attribute capability 1 (the 2623 "crypto" attribute). 2625 o Potential configuration 3, which is the least preferred potential 2626 configuration (but the second least preferred configuration 2627 overall, since the actual configuration provided by the "m=" line 2628 is always the least preferred configuration), specifies use of 2629 transport protocol capability 3 (RTP/AVPF) and optional attribute 2630 capability 2 (the "rtcp-fb" attribute). 2632 Bob receives the SDP session description offer from Alice. Bob does 2633 not support any secure RTP profiles, however he supports plain RTP 2634 and RTP with RTCP-based feedback, as well as the SDP Capability 2635 Negotiation extensions, and hence he accepts the potential 2636 configuration for RTP with RTCP-based feedback provided by Alice: 2638 v=0 2639 o=- 24351 621814 IN IP4 192.0.2.2 2640 s= 2641 c=IN IP4 192.0.2.2 2642 t=0 0 2643 m=audio 54568 RTP/AVPF 0 18 2644 a=rtcp-fb:0 nack 2645 a=acfg:1 t=3 a=[2] 2647 Bob includes the "a=acfg" attribute in the answer to inform Alice 2648 that he based his answer on an offer containing the potential 2649 configuration with transport protocol capability 3 and optional 2650 attribute capability 2 from the offer SDP session description (i.e. 2651 the RTP/AVPF profile using the "rtcp-fb" value provided). Bob also 2652 includes an "rtcp-fb" attribute with the value "nack" value for RTP 2653 payload type 0. 2655 When Alice receives Bob's answer, session negotiation has completed, 2656 however Alice nevertheless chooses to generate a new offer using the 2657 actual configuration. This is done purely to assist any 2658 intermediaries that may reside between Alice and Bob but do not 2659 support the SDP Capability Negotiation framework (and hence may not 2660 understand the negotiation that just took place): 2662 Alice's updated offer includes only RTP/AVPF, and it is not using 2663 the SDP Capability Negotiation framework (Alice could have included 2664 the capabilities as well if she wanted to): 2666 v=0 2667 o=- 25678 753850 IN IP4 192.0.2.1 2668 s= 2669 c=IN IP4 192.0.2.1 2670 t=0 0 2671 m=audio 53456 RTP/AVPF 0 18 2672 a=rtcp-fb:0 nack 2674 The "m=" line now indicates that Alice is offering to use RTP with 2675 RTCP-based feedback and using PCMU or G.729. The "rtcp-fb" 2676 attribute provides the feedback type "nack" for payload type 0 again 2677 (but as part of the actual configuration). 2679 Bob receives the SDP session description offer from Alice, which he 2680 accepts, and then generates an answer to Alice: 2682 v=0 2683 o=- 24351 621815 IN IP4 192.0.2.2 2684 s= 2685 c=IN IP4 192.0.2.2 2686 t=0 0 2687 m=audio 54568 RTP/AVPF 0 18 2688 a=rtcp-fb:0 nack 2690 Bob includes the same "rtcp-fb" attribute as before, and the session 2691 proceeds without change. Although Bob did not include any 2692 capabilities in his answer, he could have done so if he wanted to. 2694 Note that in this particular example, the answerer supported the SDP 2695 Capability Negotiation framework and hence the attributes and 2696 procedures defined here, however had he not, the answerer would 2697 simply have ignored the new attributes received in step 1 and 2698 accepted the offer to use normal RTP. In that case, the following 2699 answer would have been generated in step 2 instead: 2701 v=0 2702 o=- 24351 621814 IN IP4 192.0.2.2 2703 s= 2704 c=IN IP4 192.0.2.2 2705 t=0 0 2706 m=audio 54568 RTP/AVP 0 18 2708 4.2. DTLS-SRTP or SRTP with Media Level Security Descriptions 2710 The following example illustrates how to use the SDP Capability 2711 Negotiation framework to negotiate use of SRTP using either SDP 2712 Security Descriptions or DTLS-SRTP. The offerer (Alice) wants to 2713 establish a secure RTP audio stream but is willing to use plain RTP. 2714 Alice prefers to use DTLS-SRTP as the key management protocol, but 2715 supports SDP security descriptions as well (note that [DTLS-SRTP- 2716 FRAMEWORK] contains additional DTLS-SRTP examples). 2718 The example is illustrated by the offer/answer exchange below, where 2719 Alice sends an offer to Bob: 2721 Alice Bob 2723 | (1) Offer (RTP/[S]AVP,SDES | DTLS-SRTP)| 2724 |--------------------------------------->| 2725 | | 2726 |<--------- DTLS-SRTP handshake -------->| 2727 | | 2728 | (2) Answer (DTLS-SRTP) | 2729 |<---------------------------------------| 2730 | | 2731 | (3) Offer (DTLS-SRTP) | 2732 |--------------------------------------->| 2733 | | 2734 | (4) Answer (DTLS-SRTP) | 2735 |<---------------------------------------| 2736 | | 2738 Alice's offer includes an audio stream which offers use of plain RTP 2739 and secure RTP as alternatives. For the secure RTP stream, it can be 2740 established using either DTLS-SRTP or SDP Security Descriptions: 2742 v=0 2743 o=- 25678 753849 IN IP4 192.0.2.1 2744 s= 2745 t=0 0 2746 c=IN IP4 192.0.2.1 2747 a=acap:1 setup:actpass 2748 a=acap:2 fingerprint: SHA-1 \ 2749 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2750 a=tcap:1 UDP/TLS/RTP/SAVP RTP/SAVP 2751 m=audio 59000 RTP/AVP 98 2752 a=rtpmap:98 AMR/8000 2753 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_32 2754 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2755 a=pcfg:1 t=1 a=1,2 2756 a=pcfg:2 t=2 a=3 2758 The first (and preferred) potential configuration for the audio 2759 stream specifies use of transport capability 1 (UDP/TLS/RTP/SAVP), 2760 i.e. DTLS-SRTP, and attribute capabilities 1 and 2 (active/passive 2761 mode and certificate fingerprint), both of which must be supported 2762 to choose this potential configuration. The second (and less 2763 preferred) potential configuration specifies use of transport 2764 capability 2 (RTP/SAVP) and mandatory attribute capability 3, i.e. 2765 the SDP security description. 2767 Bob receives the SDP session description offer from Alice. Bob 2768 supports DTLS-SRTP as preferred by Alice and Bob now initiates the 2769 DTLS-SRTP handshake to establish the DTLS-SRTP session (see [DTLS- 2770 SRTP] for details). 2772 Bob also sends back an answer to Alice as follows: 2774 v=0 2775 o=- 24351 621814 IN IP4 192.0.2.2 2776 s= 2777 a=setup:active 2778 a=fingerprint: SHA-1 \ 2779 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2780 t=0 0 2781 c=IN IP4 192.0.2.2 2782 m=audio 54568 UDP/TLS/RTP/SAVP 98 2783 a=rtpmap:98 AMR/8000 2784 a=acfg:1 t=1 a=1,2 2786 For the audio stream, Bob accepted the use of DTLS-SRTP, and hence 2787 the profile in the "m=" line is "UDP/TLS/RTP/SAVP". Bob also includes 2788 a "setup:active" attribute to indicate he is the active endpoint for 2789 the DTLS-SRTP session as well as the fingerprint for Bob's 2790 certificate. Bob's "acfg" attribute indicates that he chose potential 2791 configuration 1 from Alice's offer. 2793 When Alice receives Bob's answer, session negotiation has completed 2794 (and Alice can verify the DTLS handshake using Bob's certificate 2795 fingerprint in the answer), however Alice nevertheless chooses to 2796 generate a new offer using the actual configuration. This is done 2797 purely to assist any intermediaries that may reside between Alice 2798 and Bob but do not support the capability negotiation extensions 2799 (and hence may not understand the negotiation that just took place): 2801 Alice's updated offer includes only DTLS-SRTP for the audio stream, 2802 and it is not using the SDP Capability Negotiation framework (Alice 2803 could have included the capabilities as well if she wanted to): 2805 v=0 2806 o=- 25678 753850 IN IP4 192.0.2.1 2807 s= 2808 t=0 0 2809 c=IN IP4 192.0.2.1 2810 a=setup:actpass 2811 a=fingerprint: SHA-1 \ 2812 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2813 m=audio 59000 UDP/TLS/RTP/AVP 98 2814 a=rtpmap:98 AMR/8000 2816 The "m=" line for the audio stream now indicates that Alice is 2817 offering to use DTLS-SRTP in active/passive mode using her 2818 certificate fingerprint provided. 2820 Bob receives the SDP session description offer from Alice, which he 2821 accepts, and then generates an answer to Alice: 2823 v=0 2824 o=- 24351 621814 IN IP4 192.0.2.2 2825 s= 2826 a=setup:active 2827 a=fingerprint: SHA-1 \ 2828 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2829 t=0 0 2830 c=IN IP4 192.0.2.2 2831 m=audio 54568 UDP/TLS/RTP/SAVP 98 2832 a=rtpmap:98 AMR/8000 2833 a=acfg:1 t=1 a=1,2 2835 Bob includes the same "setup:active" and fingerprint attributes as 2836 before, and the session proceeds without change. Although Bob did 2837 not include any capabilities in his answer, he could have done so if 2838 he wanted to. 2840 Note that in this particular example, the answerer supported the 2841 capability extensions defined here, however had he not, the answerer 2842 would simply have ignored the new attributes received in step 1 and 2843 accepted the offer to use normal RTP. In that case, the following 2844 answer would have been generated in step 2 instead: 2846 v=0 2847 o=- 24351 621814 IN IP4 192.0.2.2 2848 s= 2849 t=0 0 2850 c=IN IP4 192.0.2.2 2851 m=audio 54568 RTP/AVP 98 2852 a=rtpmap:98 AMR/8000 2854 Finally, if Bob had chosen to use SDP Security Descriptions instead 2855 of DTLS-SRTP, the following answer would have been generated: 2857 v=0 2858 o=- 24351 621814 IN IP4 192.0.2.2 2859 s= 2860 t=0 0 2861 c=IN IP4 192.0.2.2 2862 m=audio 54568 RTP/SAVP 98 2863 a=rtpmap:98 AMR/8000 2864 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2865 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 2866 a=acfg:2 t=2 a=3 2868 4.3. Best-Effort SRTP with Session-Level MIKEY and Media Level Security 2869 Descriptions 2871 The following example illustrates how to use the SDP Capability 2872 Negotiation extensions to support so-called Best-Effort Secure RTP 2873 as well as alternative keying mechanisms, more specifically MIKEY 2874 [RFC3830] and SDP Security Descriptions. The offerer (Alice) wants 2875 to establish an audio and video session. Alice prefers to use 2876 session-level MIKEY as the key management protocol, but supports SDP 2877 security descriptions as well. 2879 The example is illustrated by the offer/answer exchange below, where 2880 Alice sends an offer to Bob: 2882 Alice Bob 2884 | (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) | 2885 |--------------------------------------->| 2886 | | 2887 | (2) Answer (RTP/SAVP, SDES) | 2888 |<---------------------------------------| 2889 | | 2890 | (3) Offer (RTP/SAVP, SDES) | 2891 |--------------------------------------->| 2892 | | 2893 | (4) Answer (RTP/SAVP, SDES) | 2894 |<---------------------------------------| 2895 | | 2897 Alice's offer includes an audio and a video stream. The audio stream 2898 offers use of plain RTP and secure RTP as alternatives, whereas the 2899 video stream offers use of plain RTP, RTP with RTCP-based feedback, 2900 Secure RTP, and Secure RTP with RTCP-based feedback as alternatives: 2902 v=0 2903 o=- 25678 753849 IN IP4 192.0.2.1 2904 s= 2905 t=0 0 2906 c=IN IP4 192.0.2.1 2907 a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2908 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF 2909 m=audio 59000 RTP/AVP 98 2910 a=rtpmap:98 AMR/8000 2911 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32 2912 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2913 a=pcfg:1 t=2 a=1|2 2914 m=video 52000 RTP/AVP 31 2915 a=rtpmap:31 H261/90000 2916 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 2917 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2918 a=acap:4 rtcp-fb:* nack 2919 a=pcfg:1 t=1 a=1,4|3,4 2920 a=pcfg:2 t=2 a=1|3 2921 a=pcfg:3 t=3 a=4 2923 The potential configuration for the audio stream specifies use of 2924 transport capability 2 (RTP/SAVP) and either attribute capability 1 2925 (session-level MIKEY as the keying mechanism) or 2 (SDP Security 2926 Descriptions as the keying mechanism). Support for either of these 2927 attribute capabilities is mandatory. There are three potential 2928 configurations for the video stream. 2930 o The first configuration with configuration number 1 uses 2931 transport capability 1 (RTP/SAVPF) with either attribute 2932 capabilities 1 and 4 (session-level MIKEY and the "rtcp-fb" 2933 attribute) or attribute capabilities 3 and 4 (SDP security 2934 descriptions and the "rtcp-fb" attribute). In this example, the 2935 offerer insists on not only the keying mechanism being supported, 2936 but also that the "rtcp-fb" attribute is supported with the value 2937 indicated. Consequently, all the attribute capabilities are 2938 marked as mandatory in this potential configuration. 2940 o The second configuration with configuration number 2 uses 2941 transport capability 2 (RTP/SAVP) and either attribute capability 2942 1 (session-level MIKEY) or attribute capability 3 (SDP security 2943 descriptions). Both attribute capabilities are mandatory in this 2944 configuration. 2946 o The third configuration with configuration number 3 uses 2947 transport capability 3 (RTP/AVPF) and mandatory attribute 2948 capability 4 (the "rtcp-fb" attribute). 2950 Bob receives the SDP session description offer from Alice. Bob 2951 supports Secure RTP, Secure RTP with RTCP-based feedback and the SDP 2952 Capability Negotiation extensions. Bob also supports SDP Security 2953 Descriptions, but not MIKEY, and hence he generates the following 2954 answer: 2956 v=0 2957 o=- 24351 621814 IN IP4 192.0.2.2 2958 s= 2959 t=0 0 2960 c=IN IP4 192.0.2.2 2961 m=audio 54568 RTP/SAVP 98 2962 a=rtpmap:98 AMR/8000 2963 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2964 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 2965 a=acfg:1 t=2 a=2 2966 m=video 55468 RTP/SAVPF 31 2967 a=rtpmap:31 H261/90000 2968 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2969 inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32 2970 a=rtcp-fb:* nack 2971 a=acfg:1 t=1 a=3,4 2973 For the audio stream, Bob accepted the use of secure RTP, and hence 2974 the profile in the "m=" line is "RTP/SAVP". Bob also includes a 2975 "crypto" attribute with his own keying material, and an "acfg" 2976 attribute identifying actual configuration 1 for the audio media 2977 stream from the offer, using transport capability 2 (RTP/SAVP) and 2978 attribute capability 2 (the crypto attribute from the offer). For 2979 the video stream, Bob accepted the use of secure RTP with RTCP-based 2980 feedback, and hence the profile in the "m=" line is "RTP/SAVPF". Bob 2981 also includes a "crypto" attribute with his own keying material, and 2982 an "acfg" attribute identifying actual configuration 1 for the video 2983 stream from the offer, using transport capability 1 (RTP/SAVPF) and 2984 attribute capabilities 3 (the crypto attribute from the offer) and 4 2985 (the "rtcp-fb" attribute from the offer). 2987 When Alice receives Bob's answer, session negotiation has completed, 2988 however Alice nevertheless chooses to generate a new offer using the 2989 actual configuration. This is done purely to assist any 2990 intermediaries that may reside between Alice and Bob but do not 2991 support the capability negotiation extensions (and hence may not 2992 understand the negotiation that just took place): 2994 Alice's updated offer includes only SRTP for the audio stream SRTP 2995 with RTCP-based feedback for the video stream, and it is not using 2996 the SDP Capability Negotiation framework (Alice could have included 2997 the capabilities as well is she wanted to): 2999 v=0 3000 o=- 25678 753850 IN IP4 192.0.2.1 3001 s= 3002 t=0 0 3003 c=IN IP4 192.0.2.1 3004 m=audio 59000 RTP/SAVP 98 3005 a=rtpmap:98 AMR/8000 3006 a=crypto:1 AES_CM_128_HMAC_SHA1_32 3007 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 3008 m=video 52000 RTP/SAVPF 31 3009 a=rtpmap:31 H261/90000 3010 a=crypto:1 AES_CM_128_HMAC_SHA1_80 3011 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 3012 a=rtcp-fb:* nack 3014 The "m=" line for the audio stream now indicates that Alice is 3015 offering to use secure RTP with PCMU or G.729, whereas the "m=" line 3016 for the video stream indicates that Alice is offering to use secure 3017 RTP with RTCP-based feedback and H.261. Each media stream includes a 3018 "crypto" attribute, which provides the SRTP keying material, with 3019 the same value again. 3021 Bob receives the SDP session description offer from Alice, which he 3022 accepts, and then generates an answer to Alice: 3024 v=0 3025 o=- 24351 621815 IN IP4 192.0.2.2 3026 s= 3027 t=0 0 3028 c=IN IP4 192.0.2.2 3029 m=audio 54568 RTP/SAVP 98 3030 a=rtpmap:98 AMR/8000 3031 a=crypto:1 AES_CM_128_HMAC_SHA1_32 3032 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 3033 m=video 55468 RTP/SAVPF 31 3034 a=rtpmap:31 H261/90000 3035 a=crypto:1 AES_CM_128_HMAC_SHA1_80 3036 inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32 3037 a=rtcp-fb:* nack 3039 Bob includes the same crypto attribute as before, and the session 3040 proceeds without change. Although Bob did not include any 3041 capabilities in his answer, he could have done so if he wanted to. 3043 Note that in this particular example, the answerer supported the 3044 capability extensions defined here, however had he not, the answerer 3045 would simply have ignored the new attributes received in step 1 and 3046 accepted the offer to use normal RTP. In that case, the following 3047 answer would have been generated in step 2 instead: 3049 v=0 3050 o=- 24351 621814 IN IP4 192.0.2.2 3051 s= 3052 t=0 0 3053 c=IN IP4 192.0.2.2 3054 m=audio 54568 RTP/AVP 98 3055 a=rtpmap:98 AMR/8000 3056 m=video 55468 RTP/AVP 31 3057 a=rtpmap:31 H261/90000 3058 a=rtcp-fb:* nack 3060 Finally, if Bob had chosen to use session-level MIKEY instead of SDP 3061 security descriptions, the following answer would have been 3062 generated: 3064 v=0 3065 o=- 24351 621814 IN IP4 192.0.2.2 3066 s= 3067 t=0 0 3068 c=IN IP4 192.0.2.2 3069 a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyO... 3070 m=audio 54568 RTP/SAVP 98 3071 a=rtpmap:98 AMR/8000 3072 a=acfg:1 t=2 a=1 3073 m=video 55468 RTP/SAVPF 31 3074 a=rtpmap:31 H261/90000 3075 a=rtcp-fb:* nack 3076 a=acfg:1 t=1 a=1,4 3078 It should be noted, that although Bob could have chosen session- 3079 level MIKEY for one media stream, and SDP Security Descriptions for 3080 another media stream, there are no well-defined offerer processing 3081 rules of the resulting answer for this, and hence the offerer may 3082 incorrectly assume use of MIKEY for both streams. To avoid this, if 3083 the answerer chooses session-level MIKEY, then all secure RTP based 3084 media streams SHOULD use MIKEY (this applies irrespective of whether 3085 SDP Capability Negotiation is being used or not). Use of media-level 3086 MIKEY does not have a similar constraint. 3088 4.4. SRTP with Session-Level MIKEY and Media Level Security 3089 Descriptions as Alternatives 3091 The following example illustrates how to use the SDP Capability 3092 Negotiation framework to negotiate use of either MIKEY or SDP 3093 Security Descriptions, when one of them is included as part of the 3094 actual configuration, and the other one is being selected. The 3095 offerer (Alice) wants to establish an audio and video session. Alice 3096 prefers to use session-level MIKEY as the key management protocol, 3097 but supports SDP security descriptions as well. 3099 The example is illustrated by the offer/answer exchange below, where 3100 Alice sends an offer to Bob: 3102 Alice Bob 3104 | (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) | 3105 |--------------------------------------->| 3106 | | 3107 | (2) Answer (RTP/SAVP, SDES) | 3108 |<---------------------------------------| 3109 | | 3111 Alice's offer includes an audio and a video stream. Both the audio 3112 and the video stream offer use of secure RTP: 3114 v=0 3115 o=- 25678 753849 IN IP4 192.0.2.1 3116 s= 3117 t=0 0 3118 c=IN IP4 192.0.2.1 3119 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 3120 m=audio 59000 RTP/SAVP 98 3121 a=rtpmap:98 AMR/8000 3122 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 3123 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 3124 a=pcfg:1 a=-s:1 3125 m=video 52000 RTP/SAVP 31 3126 a=rtpmap:31 H261/90000 3127 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_80 3128 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 3129 a=pcfg:1 a=-s:2 3131 Alice does not know whether Bob supports MIKEY or SDP Security 3132 Descriptions. She could include attributes for both, however the 3133 resulting procedures and potential interactions are not well- 3134 defined. Instead, she places a session-level key-mgmt attribute for 3135 MIKEY in the actual configuration with SDP security descriptions as 3136 an alternative in the potential configuration. The potential 3137 configuration for the audio stream specifies that all session level 3138 attributes are to be deleted (i.e. the session-level "a=key-mgmt" 3139 attribute) and that mandatory attribute capability 2 is to be used 3140 (i.e. the crypto attribute). The potential configuration for the 3141 video stream is similar, except it uses its own mandatory crypto 3142 attribute capability (2). Note how deletion of the session-level 3143 attributes does not affect the media-level attributes. 3145 Bob receives the SDP session description offer from Alice. Bob 3146 supports Secure RTP and the SDP Capability Negotiation framework. 3148 Bob also supports both SDP Security Descriptions and MIKEY. Since 3149 the potential configuration is more preferred than the actual 3150 configuration, Bob (conceptually) generates an internal potential 3151 configuration SDP session description that contains the crypto 3152 attributes for the audio and video stream, but not the key-mgmt 3153 attribute for MIKEY, thereby avoiding any ambiguity between the two 3154 keying mechanisms. As a result, he generates the following answer: 3156 v=0 3157 o=- 24351 621814 IN IP4 192.0.2.2 3158 s= 3159 t=0 0 3160 c=IN IP4 192.0.2.2 3161 m=audio 54568 RTP/SAVP 98 3162 a=rtpmap:98 AMR/8000 3163 a=crypto:1 AES_CM_128_HMAC_SHA1_32 3164 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 3165 a=acfg:1 a=-s:1 3166 m=video 55468 RTP/SAVP 31 3167 a=rtpmap:31 H261/90000 3168 a=crypto:1 AES_CM_128_HMAC_SHA1_80 3169 inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32 3170 a=acfg:1 a=-s:2 3172 For the audio stream, Bob accepted the use of secure RTP using SDP 3173 security descriptions. Bob therefore includes a "crypto" attribute 3174 with his own keying material, and an "acfg" attribute identifying 3175 actual configuration 1 for the audio media stream from the offer, 3176 with the delete-attributes ("-s") and attribute capability 1 (the 3177 crypto attribute from the offer). For the video stream, Bob also 3178 accepted the use of secure RTP using SDP security descriptions. Bob 3179 therefore includes a "crypto" attribute with his own keying 3180 material, and an "acfg" attribute identifying actual configuration 1 3181 for the video stream from the offer, with the delete-attributes ("- 3182 s") and attribute capability 2. 3184 Below, we illustrate the offer SDP session description, when Bob 3185 instead offers the "crypto" attribute as the actual configuration 3186 keying mechanism and "key-mgmt" as the potential configuration: 3188 v=0 3189 o=- 25678 753849 IN IP4 192.0.2.1 3190 s= 3191 t=0 0 3192 c=IN IP4 192.0.2.1 3193 a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 3195 m=audio 59000 RTP/SAVP 98 3196 a=rtpmap:98 AMR/8000 3197 a=crypto:1 AES_CM_128_HMAC_SHA1_32 3198 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 3199 a=acap:2 rtpmap:98 AMR/8000 3200 a=pcfg:1 a=-m:1,2 3201 m=video 52000 RTP/SAVP 31 3202 a=rtpmap:31 H261/90000 3203 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 3204 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 3205 a=acap:4 rtpmap:31 H261/90000 3206 a=pcfg:1 a=-m:1,4 3208 Note how we this time need to perform delete-attributes at the 3209 media-level instead of the session-level. When doing that, all 3210 attributes from the actual configuration SDP session description, 3211 including the rtpmaps provided, are removed. Consequently, we had to 3212 include these rtpmaps as capabilities as well, and then include them 3213 in the potential configuration, thereby effectively recreating the 3214 original rtpmap attributes in the resulting potential configuration 3215 SDP session description. 3217 5. Security Considerations 3219 The SDP Capability Negotiation Framework is defined to be used 3220 within the context of the offer/answer model, and hence all the 3221 offer/answer security considerations apply here as well [RFC3264]. 3222 Similarly, the Session Initiation Protocol (SIP) uses SDP and the 3223 offer/answer model, and hence, when used in that context, the SIP 3224 security considerations apply as well [RFC3261]. 3226 However, SDP Capability Negotiation introduces additional security 3227 issues. Its use as a mechanism to enable alternative transport 3228 protocol negotiation (secure and non-secure) as well as its ability 3229 to negotiate use of more or less secure keying methods and material 3230 warrant further security considerations. Also, the (continued) 3231 support for receiving media before answer combined with negotiation 3232 of alternative transport protocols (secure and non-secure) warrant 3233 further security considerations. We discuss these issues below. 3235 The SDP Capability Negotiation framework allows for an offered media 3236 stream to both indicate and support various levels of security for 3237 that media stream. Different levels of security can for example be 3238 negotiated by use of alternative attribute capabilities each 3239 indicating more or less secure keying methods as well as more or 3240 less strong ciphers. Since the offerer indicates support for each of 3241 these alternatives, he will presumably accept the answerer seemingly 3242 selecting any of the offered alternatives. If an attacker can modify 3243 the SDP session description offer, he can thereby force the 3244 negotiation of the weakest security mechanism that the offerer is 3245 willing to accept. This may enable the attacker to compromise the 3246 security of the negotiated media stream. Similarly, if the offerer 3247 wishes to negotiate use of a secure media stream (e.g. secure RTP), 3248 but includes a non-secure media stream (e.g. plain RTP) as a valid 3249 (but less preferred) alternative, then an attacker that can modify 3250 the offered SDP session description will be able to force the 3251 establishment of an insecure media stream. The solution to both of 3252 these problems involves the use of integrity protection over the SDP 3253 session description. Ideally, this integrity protection provides 3254 end-to-end integrity protection in order to protect from any man-in- 3255 the-middle attack; secure multiparts such as S/MIME [RFC5751] 3256 provide one such solution, however S/MIME requires use and 3257 availability of a Public Key Infrastructure (PKI). A slightly less 3258 secure alternative when using SIP, but generally much easier to 3259 deploy in practice, is to use SIP Identity [RFC4474]; this requires 3260 the existence of an authentication service (see [RFC4474]). Although 3261 this mechanism still requires a PKI, it only requires that servers 3262 (as opposed to end-users) have third party validatable certificates, 3263 which significantly reduces the barrier to entry by ordinary users. 3264 Yet another, and considerably less secure, alternative is to use 3265 hop-by-hop security only, e.g. TLS or IPsec thereby ensuring the 3266 integrity of the offered SDP session description on a hop-by-hop 3267 basis. This is less secure because SIP allows partially trusted 3268 intermediaries on the signaling path, and such intermediaries 3269 processing the SIP request at each hop would be able to perform a 3270 man-in- the-middle attack by modifying the offered SDP session 3271 description. In simple architectures where the two UA's proxies 3272 communicate directly, the security provided by this method is 3273 roughly comparable to that provided by the previously discussed 3274 signature-based mechanisms. 3276 Per the normal offer/answer procedures, as soon as the offerer has 3277 generated an offer, the offerer must be prepared to receive media in 3278 accordance with that offer. The SDP Capability Negotiation preserves 3279 that behavior for the actual configuration in the offer, however the 3280 offerer has no way of knowing which configuration (actual or 3281 potential) configuration was selected by the offerer, until an 3282 answer indication is received. This opens up a new security issue 3283 where an attacker may be able to interject media towards the offerer 3284 until the answer is received. For example, the offerer may use plain 3285 RTP as the actual configuration and secure RTP as an alternative 3286 potential configuration. Even though the answerer selects secure 3287 RTP, the offerer will not know that until he receives the answer, 3288 and hence an attacker will be able to send media to the offerer 3289 meanwhile. The easiest protection against such an attack is to not 3290 offer use of the non-secure media stream in the actual 3291 configuration, however that may in itself have undesirable side- 3292 effects: If the answerer does not support the secure media stream 3293 and also does not support the capability negotiation framework, then 3294 negotiation of the media stream will fail. Alternatively, SDP 3295 security preconditions [RFC5027] can be used. This will ensure that 3296 media is not flowing until session negotiation has completed and 3297 hence the selected configuration is known. Use of preconditions 3298 however requires both sides to support them. If they don't, and use 3299 of them is required, the session will fail. As a (limited) work 3300 around to this, it is RECOMMENDED that SIP entities generate an 3301 answer SDP session description and send it to the offerer as soon as 3302 possible, for example in a 183 Session Progress message. This will 3303 limit the time during which an attacker can send media to the 3304 offerer. Section 3.9. presents other alternatives as well. 3306 Additional security considerations apply to the answer SDP session 3307 description as well. The actual configuration attribute tells the 3308 offerer which potential configuration the answer was based on, and 3309 hence an attacker that can either modify or remove the actual 3310 configuration attribute in the answer can cause session failure as 3311 well as extend the time window during which the offerer will accept 3312 incoming media that does not conform to the actual answer. The 3313 solutions to this SDP session description answer integrity problem 3314 are the same as for the offer, i.e. use of end-to-end integrity 3315 protection, SIP identity, or hop-by-hop protection. The mechanism to 3316 use depends on the mechanisms supported by the offerer as well as 3317 the acceptable security trade-offs. 3319 As described in Section 3.1. and 3.11. , SDP Capability Negotiation 3320 conceptually allows an offerer to include many different offers in a 3321 single SDP session description. This can cause the answerer to 3322 process a large number of alternative potential offers, which can 3323 consume significant memory and CPU resources. An attacker can use 3324 this amplification feature to launch a denial of service attack 3325 against the answerer. The answerer must protect itself from such 3326 attacks. As explained in Section 3.11. , the answerer can help 3327 reduce the effects of such an attack by first discarding all 3328 potential configurations that contain unsupported transport 3329 protocols, unsupported or invalid mandatory attribute capabilities, 3330 or unsupported mandatory extension configurations. The answerer 3331 should also look out for potential configurations that are designed 3332 to pass the above test, but nevertheless produce a large number of 3333 potential configuration SDP session descriptions that cannot be 3334 supported. 3336 A possible way of achieving that is for an attacker to find a 3337 valid session-level attribute that causes conflicts or otherwise 3338 interferes with individual media description configurations. At 3339 time of publication of this document, we do not know of such an 3340 SDP attribute, however this does not mean it does not exist, or 3341 that it will not exist in the future. If such attributes are found 3342 to exist, implementers should explicitly protect against them. 3344 A significant number of valid and supported potential configurations 3345 may remain. However, since all of those contain only valid and 3346 supported transport protocols and attributes, it is expected that 3347 only a few of them will need to be processed on average. Still, the 3348 answerer must ensure that it does not needlessly consume large 3349 amounts of memory or CPU resources when processing those as well as 3350 be prepared to handle the case where a large number of potential 3351 configurations still need to be processed. 3353 6. IANA Considerations 3355 6.1. New SDP Attributes 3357 The IANA is hereby requested to register the following new SDP 3358 attributes as follows: 3360 Attribute name: csup 3361 Long form name: Supported capability negotiation extensions 3362 Type of attribute: Session-level and media-level 3363 Subject to charset: No 3364 Purpose: Option tags for supported SDP capability 3365 negotiation extensions 3366 Appropriate values: See Section 3.3.1. of RFCXXXX 3367 -- Note to RFC editor: 3368 -- replace RFCXXXX by this RFC number 3369 Contact name: Flemming Andreasen, fandreas@cisco.com 3371 Attribute name: creq 3372 Long form name: Required capability negotiation extensions 3373 Type of attribute: Session-level and media-level 3374 Subject to charset: No 3375 Purpose: Option tags for required SDP capability 3376 negotiation extensions 3377 Appropriate values: See Section 3.3.2. of RFCXXXX 3378 -- Note to RFC editor: 3380 -- replace RFCXXXX by this RFC number 3381 Contact name: Flemming Andreasen, fandreas@cisco.com 3383 Attribute name: acap 3384 Long form name: Attribute capability 3385 Type of attribute: Session-level and media-level 3386 Subject to charset: No 3387 Purpose: Attribute capability containing an attribute 3388 name and associated value 3389 Appropriate values: See Section 3.4.1. of RFCXXXX 3390 -- Note to RFC editor: 3391 -- replace RFCXXXX by this RFC number 3392 Contact name: Flemming Andreasen, fandreas@cisco.com 3394 Attribute name: tcap 3395 Long form name: Transport Protocol Capability 3396 Type of attribute: Session-level and media-level 3397 Subject to charset: No 3398 Purpose: Transport protocol capability listing one or 3399 more transport protocols 3400 Appropriate values: See Section 3.4.2. of RFCXXXX 3401 -- Note to RFC editor: 3402 -- replace RFCXXXX by this RFC number 3403 Contact name: Flemming Andreasen, fandreas@cisco.com 3405 Attribute name: pcfg 3406 Long form name: Potential Configuration 3407 Type of attribute: Media-level 3408 Subject to charset: No 3409 Purpose: Potential configuration for SDP capability 3410 negotiation 3411 Appropriate values: See Section 3.5.1. of RFCXXXX 3412 -- Note to RFC editor: 3413 -- replace RFCXXXX by this RFC number 3414 Contact name: Flemming Andreasen, fandreas@cisco.com 3416 Attribute name: acfg 3417 Long form name: Actual configuration 3418 Type of attribute: Media-level 3419 Subject to charset: No 3420 Purpose: Actual configuration for SDP capability 3421 negotiation 3422 Appropriate values: See Section 3.5.2. of RFCXXXX 3423 -- Note to RFC editor: 3425 -- replace RFCXXXX by this RFC number 3426 Contact name: Flemming Andreasen, fandreas@cisco.com 3428 6.2. New SDP Capability Negotiation Option Tag Registry 3430 The IANA is hereby requested to create a new SDP Capability 3431 Negotiation Option Tag registry. An IANA SDP Capability Negotiation 3432 option tag registration MUST be documented in an RFC in accordance 3433 with the [RFC5226] IETF Review policy. The RFC MUST provide the name 3434 of the option tag, a syntax and a semantic specification of any new 3435 SDP attributes and any extensions to the potential configuration 3436 ("a=pcfg") and actual configuration ("a=acfg") attributes provided 3437 in this document. If the extension defines any new SDP attributes 3438 that are intended to be capabilities for use by the capability 3439 negotiation framework (similar to e.g. "a=acap"), those capabilities 3440 MUST adhere to the guidelines provided in Section 3.4.3. Extensions 3441 to the potential and actual configuration attributes MUST adhere to 3442 the syntax provided in Section 3.5.1. and 3.5.2. 3444 The option tag "cap-v0" is defined in this document and the IANA is 3445 hereby requested to register this option tag. 3447 6.3. New SDP Capability Negotiation Potential Configuration Parameter 3448 Registry 3450 The IANA is hereby requested to create a new SDP Capability 3451 Negotiation Potential Configuration Parameter registry. An IANA SDP 3452 Capability Negotiation potential configuration registration MUST be 3453 documented in an RFC in accordance with the [RFC5226] IETF Review 3454 policy. The RFC MUST define the syntax and semantics of each new 3455 potential configuration parameter. The syntax MUST adhere to the 3456 syntax provided for extensions in Section 3.5.1. and the semantics 3457 MUST adhere to the semantics provided for extensions in Section 3458 3.5.1. and 3.5.2. Associated with each registration MUST be the 3459 encoding name for the parameter as well as a short descriptive name 3460 for it. 3462 The potential configuration parameters "a" for "attribute" and "t" 3463 for "transport protocol" are defined in this document and the IANA 3464 is hereby requested to register these. 3466 7. Acknowledgments 3468 The SDP Capability Negotiation solution defined in this document 3469 draws on the overall capability negotiation framework that was 3470 defined by [SDPng]. Also, the SDP Capability Negotiation solution is 3471 heavily influenced by the discussions and work done by the SDP 3472 Capability Negotiation Design Team. The following people in 3473 particular provided useful comments and suggestions to either the 3474 document itself or the overall direction of the solution defined in 3475 here: Francois Audet, John Elwell, Roni Even, Miguel Garcia, Robert 3476 Gilman, Cullen Jennings, Jonathan Lennox, Matt Lepinski, Jean- 3477 Francois Mule, Joerg Ott, Colin Perkins, Jonathan Rosenberg, Thomas 3478 Stach, and Dan Wing. 3480 General Area review comments were provided by Christian Vogt, and 3481 Stephen Kent provided Security Directorate review comments. Eric 3482 Rescorla provided textual input to the Security Considerations. 3483 Alexey Melnikov, Robert Sparks, and Magnus Westerlund provided 3484 several review comments as well. 3486 8. Change Log 3488 8.1. draft-ietf-mmusic-sdp-capability-negotiation-11 3490 Addressing IESG review comments as follows: 3492 o Changed att-cap-num and trpr-cap-num ABNF rules throughout to 3493 allow for no more than 10 digits. 3495 o Disallowed base framework only implementations from generating 3496 media-level attribute capabilities at the session-level, and 3497 added explicit rules for how to process them if received. 3499 o Disallowed attribute capabilities from embedding capability 3500 negotiation parameters and discouraged extension capabilities 3501 from similar behavior. Also specified non-recursive processing of 3502 capabilities on the receive side as a safeguard. 3504 o Clarified that the "tcap" attribute specifies only the transport 3505 protocol, however some MIME types can be viewed as transports as 3506 well. The base framework does not define how to negotiate those 3507 as transports, but rather only as media formats that must be 3508 valid under the transport protocol for the media description. 3510 o Changed definition (and ABNF) for attribute-config-list to allow 3511 for only delete-attributes (i.e., no attribute capabilities) 3513 o Clarified that playout of early media before answer is not a 3514 requirement. 3516 o Clarified various offer/answer aspects related to generation of 3517 potential configuration offer SDP session descriptions and 3518 virtual answer SDP session descriptions as well as operation of 3519 delete-attributes. 3521 o Defined the notion of a "valid" actual configuration and how it 3522 affects offerer processing of the answer. 3524 o Removed recommendation to use the TIAS bandwidth type [RFC3890] 3525 and added note explaining why it should not be used. 3527 o Changed IANA rules for new option tags and potential 3528 configuration parameters to follow "IETF Review" policy, and 3529 clarified that potential configuration parameters must be 3530 registered with IANA. 3532 o Changed numerous instances of "SDP" with the more accurate "SDP 3533 session description" to avoid terminology overload. 3535 o Various editorial clarifications throughout. 3537 8.2. draft-ietf-mmusic-sdp-capability-negotiation-10 3539 Addressing General Area and Security Directorate review comments as 3540 follows: 3542 o Explained and motivated the preference order between potential 3543 and actual configurations earlier in the document. 3545 o Added DTLS-SRTP example use in several places, as well as a new 3546 example call flow for DTLS-SRTP. 3548 o Added that interacting session-level attributes in potential 3549 configurations, which do not provide well-defined operation on 3550 the receiving side, cannot be used in security critical contexts. 3552 o Updated Security Considerations section. 3554 o Rephrased several sentences containing the word "only" to improve 3555 readability. 3557 o Minor editorial nit fixes, especially in the example call flows. 3559 8.3. draft-ietf-mmusic-sdp-capability-negotiation-09 3561 Incorporated Working Group Chair review comments and a few additional 3562 comments as follows: 3564 o Clarified that the "a=creq" attribute MUST NOT be used in an 3565 answer (Section 3.6.2. ). 3567 o Various editorial changes throughout. 3569 8.4. draft-ietf-mmusic-sdp-capability-negotiation-08 3571 Incorporated Working Group Last Call comments as follows: 3573 o Added second offer/answer exchange to introductory example, fixed 3574 minor error in that example, and deleted similar example in the 3575 Examples Section. 3577 o Fixed "type=value" semantic error in the attribute capability 3578 definition. 3580 o Clarified that consecutive numbering of capabilities and 3581 potential configurations is not required. 3583 o Fixed inconsistency for which parameters to include in the "acfg" 3584 attribute. 3586 o Changed second offer/answer exchange from MAY to SHOULD strength. 3588 o Clarified there should be a combined second offer/exchange when 3589 using ICE. 3591 o Moved RFC 3407 to informative references. 3593 o Various editorial clarifications. 3595 8.5. draft-ietf-mmusic-sdp-capability-negotiation-07 3597 o Removed the ability to have attribute capabilities provide 3598 attribute names without values, when those attributes otherwise 3599 require an associated value. 3601 o Document no longer obsoletes RFC 3407 but instead recommends that 3602 it is being used instead of RFC 3407. 3604 o Added ability to specific that specific extensions in a potential 3605 configuration are mandatory. 3607 o Changed ABNF for extension-config-list in potential 3608 configurations. 3610 o Removed the redundant "a=" part of attribute capabilities. 3612 o Clarified what it means to support an attribute capability in the 3613 offer/answer procedures. 3615 o Changed "a=acap" attribute and offer/answer procedures to include 3616 only the known and supported attribute capabilities. 3618 o Added new section on indicating bandwidth usage. 3620 8.6. draft-ietf-mmusic-sdp-capability-negotiation-06 3622 o Added additional background text on terminology used, and a new 3623 section on the negotiation model. 3625 o Allowed for session-level attribute capabilities to contain 3626 media-level only attributes, albeit the base framework does not 3627 define (or allow) them to be used in a potential configuration 3628 (extensions may change that) 3630 o Disallowing multiple "a=tcap" attributes at the session-level 3631 and/or on a per media description basis; at most one at the 3632 session-level and per media description now. 3634 o Changed the "a=pcfg" attribute to make a potential configuration 3635 list optional in order to allow for the actual configuration to 3636 be referenced. 3638 o Removed the ability to delete and replace individual attributes 3639 from the actual configuration SDP session description. 3641 o Introduced the notion of mandatory and optional attribute 3642 capabilities in a potential configuration and updated the 3643 "a=pcfg" attribute and associated procedures accordingly. 3645 o Specified that mandatory attribute capabilities and the transport 3646 protocol (if any) from a potential configuration need to be 3647 supported in order to select that potential configuration. 3648 Offer/answer procedures updated accordingly as well. 3650 o Noted potential interaction and synchronization issues with use 3651 of session-level attributes and attribute capabilities and added 3652 recommendation to avoid use of session-level attributes when 3653 possible. 3655 o Fixed error in "a=acfg" grammar (missing config-number) and 3656 updated attribute definition in accordance with the "a=pcfg" 3657 attribute changes. 3659 o Updated text associated with processing media before answer to 3660 allow for playing out garbage or discard until answer received. 3661 Additional detail on alternative solutions provided as well. 3663 o Added recommendation to send back answer SDP session description 3664 as soon as possible, when a potential configuration different 3665 from the actual configuration has been chosen. 3667 o Added new section on interactions with SIP option tags. 3669 o Added new section on dealing with large number of potential 3670 configurations. 3672 o Added new section on SDP capability negotiation and 3673 intermediaries. 3675 o Updated examples in accordance with other changes and to 3676 illustrate use of mandatory and optional attribute capabilities 3677 in a potential configuration. 3679 o Updated security considerations to address potential denial of 3680 service attack caused by large number of potential 3681 configurations. 3683 o Various editorial updates throughout. 3685 8.7. draft-ietf-mmusic-sdp-capability-negotiation-05 3687 o Allowed for '=' attributes to be listed as attribute 3688 capabilities the attribute name only. 3690 o Changed IP-address to conform to RFC 3330 guidelines. 3692 o Added section on relationship to RFC 3407 and "Obsoletes: 3407" 3693 in the front. 3695 o Disallowed use of white space in a number of places for more 3696 consistency with existing SDP practice 3698 o Changed "csup" and "creq" attributes to not allow multiple 3699 instances at the session-level and multiple instances per media 3700 description (only one for each now) 3702 o Changed to not require use of "creq" with base option tag ("cap- 3703 v0"). 3705 o Relaxed restrictions on extension capabilities 3707 o Updated potential configuration attribute syntax and semantics. 3708 In particular, potential configuration attributes can now replace 3709 and delete various existing attributes in original SDP session 3710 descriptions to better control potential attribute interactions 3711 with the actual configuration while preserving message size 3712 efficiency. 3714 o Updated actual configuration attribute to align with the updates 3715 to the potential configuration attributes. 3717 o Updated offer/answer procedures to align with other changes. 3719 o Changed recommendation for second offer/answer exchange to "MAY" 3720 strength, unless for the cases where it is known or suspected 3721 that it is needed. 3723 o Updated ICE interactions to explain how the new attribute 3724 delete/replace features can solve certain potential interactions. 3726 o Updated rtpmap and fmtp section to allow potential configurations 3727 to use remapped payload types in attribute capabilities for 3728 rtpmaps and fmtp parameters. 3730 o Added section on direction attributes. 3732 o Added another example showing SRTP with session-level MIKEY and 3733 SDP Security Descriptions using the attribute capability DELETE 3734 operator. 3736 8.8. draft-ietf-mmusic-sdp-capability-negotiation-04 3738 The following are the major changes compared to version -03: 3740 o Added explicit ordering rules for attributes added by potential 3741 configurations. 3743 o Noted that ICE interaction issues (ice-tcp specifically) may not 3744 be as clear as originally thought. 3746 o Added considerations on using rtpmap and fmtp attributes as 3747 attribute capabilities. 3749 o Added multiple transport protocol example. 3751 o Added session-level MIKEY and media level security descriptions 3752 example. 3754 8.9. draft-ietf-mmusic-sdp-capability-negotiation-03 3756 The following are the major changes compared to version -02: 3758 o Base option tag name changed from "v0" to "cap-v0". 3760 o Added new section on extension capability attributes 3762 o Firmed up offer/answer procedures. 3764 o Added security considerations 3766 o Added IANA considerations 3768 8.10. draft-ietf-mmusic-sdp-capability-negotiation-02 3770 The following are the major changes compared to version -01: 3772 o Potential configurations are no longer allowed at the session 3773 level 3775 o Renamed capability attributes ("capar" to "acap" and "ctrpr" to 3776 "tcap") 3778 o Changed name and semantics of the initial number (now called 3779 configuration number) in potential configuration attributes; must 3780 now be unique and can be used as a handle 3782 o Actual configuration attribute now includes configuration number 3783 from the selected potential configuration attribute 3785 o Added ABNF throughout 3786 o Specified that answerer should include "a=csup" in case of 3787 unsupported required extensions in offer. 3789 o Specified use of second offer/answer exchange when answerer 3790 selected a potential configuration 3792 o Updated rules (and added restrictions) for referencing media- and 3793 session-level capabilities in potential configurations (at the 3794 media level) 3796 o Added initial section on ICE interactions 3798 o Added initial section on receiving media before answer 3800 8.11. draft-ietf-mmusic-sdp-capability-negotiation-01 3802 The following are the major changes compared to version -00: 3804 o Media capabilities are no longer considered a core capability and 3805 hence have been removed. This leaves transport protocols and 3806 attributes as the only capabilities defined by the core. 3808 o Version attribute has been removed and an option tag to indicate 3809 the actual version has been defined instead. 3811 o Clarified rules for session-level and media level attributes 3812 provided at either level as well how they can be used in 3813 potential configurations. 3815 o Potential configuration parameters no longer have implicit 3816 ordering; an explicit preference indicator is now included. 3818 o The parameter name for transport protocols in the potential and 3819 actual configuration attributes have been changed "p" to "t". 3821 o Clarified operator precedence within potential and actual 3822 configuration attributes. 3824 o Potential configurations at the session level now limited to 3825 indicate latent capability configurations. Consequently, an 3826 actual configuration attribute can no longer be provided at the 3827 session level. 3829 o Cleaned up capability and potential configuration terminology - 3830 they are now two clearly different things. 3832 8.12. draft-ietf-mmusic-sdp-capability-negotiation-00 3834 Version 00 is the initial version. The solution provided in this 3835 initial version is based on an earlier (individual submission) 3836 version of [SDPCapNeg]. The following are the major changes compared 3837 to that document: 3839 o Solution no longer based on RFC 3407, but defines a set of 3840 similar attributes (with some differences). 3842 o Various minor changes to the previously defined attributes. 3844 o Multiple transport capabilities can be included in a single 3845 "tcap" attribute 3847 o A version attribute is now included. 3849 o Extensions to the framework are formally supported. 3851 o Option tags and the ability to list supported and required 3852 extensions are supported. 3854 o A best-effort SRTP example use case has been added. 3856 o Some terminology change throughout to more clearly indicate what 3857 constitutes capabilities and what constitutes configurations. 3859 9. References 3861 9.1. Normative References 3863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3864 Requirement Levels", BCP 14, RFC 2119, March 1997. 3866 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 3867 with Session Description Protocol (SDP)", RFC 3264, June 3868 2002. 3870 [RFC5234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 3871 Specifications: ABNF", RFC 5234, January 2008. 3873 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3874 Description Protocol", RFC 4566, July 2006. 3876 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3877 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3878 May 2008. 3880 9.2. Informative References 3882 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3883 A., Peterson, J., Sparks, R., Handley, M., and E. 3884 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3885 June 2002. 3887 [RFC3312] G. Camarillo, W. Marshall, and J. Rosenberg, "Integration 3888 of Resource Management and Session Initiation Protocol 3889 (SIP)", RFC 3312, October 2002. 3891 [RFC3262] J. Rosenberg, and H. Schulzrinne, "Reliability of 3892 Provisional Responses in Session Initiation Protocol 3893 (SIP)", RFC 3262, June 2002. 3895 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 3896 Schulzrinne, "Grouping of Media Lines in the Session 3897 Description Protocol (SDP)", RFC 3388, December 2002. 3899 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 3900 Capability Declaration", RFC 3407, October 2002. 3902 [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and 3903 Video Conferences with Minimal Control", RFC 3551, July 3904 2003. 3906 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 3907 Norrman, "The Secure Real-time Transport Protocol 3908 (SRTP).", RFC 3711, March 2004. 3910 [RFC3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 3911 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 3912 August 2004. 3914 [RFC3890] M. Westerlund, "A Transport Independent Bandwidth Modifier 3915 for the Session Description Protocol (SDP).", RFC 3890, 3916 September 2004. 3918 [RFC4145] Yon, D., and G. Camarillo, "TCP-Based Media Transport in 3919 the Session Description Protocol (SDP)", RFC 4145, 3920 September 2005. 3922 [RFC4474] J. Peterson, and C. Jennings, "Enhancements for 3923 Authenticated Identity Management in the Session 3924 Initiation Protocol (SIP)", RFC 4474, August 2006. 3926 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 3927 Carrara, "Key Management Extensions for Session 3928 Description Protocol (SDP) and Real Time Streaming 3929 Protocol (RTSP)", RFC 4567, July 2006. 3931 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 3932 Description Protocol Security Descriptions for Media 3933 Streams", RFC 4568, July 2006. 3935 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 3936 "Extended RTP Profile for Real-Time Transport Control 3937 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 3938 2006. 3940 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 3941 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 3942 July 2006. 3944 [RFC4756] A. Li, "Forward Error Correction Grouping Semantics in 3945 Session Description Protocol", RFC 4756, November 2006. 3947 [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for 3948 Session Description Protocol Media Streams", RFC 5027, 3949 October 2007. 3951 [RFC5124] Ott, J., and E Carrara, "Extended Secure RTP Profile for 3952 Real-time Transport Control Protocol (RTCP)-Based Feedback 3953 (RTP/SAVPF)", RFC 5124, February 2008. 3955 [RFC5751] Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet 3956 Mail Extensions (S/MIME) Version 3.2 Message 3957 Specification", RFC 5751, January 2010. 3959 [BESRTP] Kaplan, H., and F. Audet, "Session Description Protocol 3960 (SDP) Offer/Answer Negotiation for Best-Effort Secure 3961 Real-Time Transport Protocol", work in progress, October 3962 2006. 3964 [DTLS-SRTP] McGrew, D. and E. Rescorla, "Datagram Transport Layer 3965 Security (DTLS) Extension to Establish Keys for Secure 3966 Real-time Transport Protocol (SRTP)", work in progress, 3967 February 2009. 3969 [DTLS-SRTP-FRAMEWORK] Fischl, J., Tschofenig, H., and E. Rescorla, 3970 "Framework for Establishing an SRTP Security Context using 3971 DTLS", work in progress, March 2009. 3973 [ICE] J. Rosenberg, "Interactive Connectivity Establishment 3974 (ICE): A Methodology for Network Address Translator (NAT) 3975 Traversal for Offer/Answer Protocols", work in progress, 3976 October 2007. 3978 [ICETCP] J. Rosenberg, "TCP Candidates with Interactive 3979 Connectivity Establishment (ICE)", work in progress, 3980 October 2009. 3982 [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", (draft- 3983 andreasen-mmusic-sdp-capability-negotiation-01.txt), work 3984 in progress, December 2006. 3986 [SDPMedCap] Gilman, R, Even, R., and F. Andreasen "SDP Media 3987 Capabilities Negotiation", work in progress, July 2009. 3989 [SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session 3990 Description and Capability Negotiation", Work in Progress, 3991 February 2005. 3993 Author's Address 3995 Flemming Andreasen 3996 Cisco Systems 3997 Iselin, NJ 08830 3998 USA 4000 Email: fandreas@cisco.com