idnits 2.17.1 draft-ietf-mmusic-sdp-capability-negotiation-13.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 (March 24, 2010) is 5146 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 3106, but not defined == Missing Reference: 'F' is mentioned on line 3106, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'ICE' -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4756 (Obsoleted by RFC 5956) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Working Group F. Andreasen 2 Internet-Draft Cisco Systems 3 Intended Status: Proposed Standard March 24, 2010 4 Expires: September 2010 6 SDP Capability Negotiation 7 draft-ietf-mmusic-sdp-capability-negotiation-13.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on September 24, 2010. 32 Copyright and License Notice 34 Copyright (c) 2010 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 Abstract 61 The Session Description Protocol (SDP) was intended for describing 62 multimedia sessions for the purposes of session announcement, 63 session invitation, and other forms of multimedia session 64 initiation. SDP was not intended to provide capability indication or 65 capability negotiation, however over the years, SDP has seen 66 widespread adoption and as a result it has been gradually extended 67 to provide limited support for these, notably in the form of the 68 offer/answer model defined in RFC 3264. SDP does not define how to 69 negotiate one or more alternative transport protocols (e.g. RTP 70 profiles) or attributes. This makes it difficult to deploy new RTP 71 profiles such as secure RTP or RTP with RTCP-based feedback, 72 negotiate use of different security keying mechanisms, etc. It also 73 presents problems for some forms of media negotiation. 75 The purpose of this document is to address these shortcomings by 76 extending SDP with capability negotiation parameters and associated 77 offer/answer procedures to use those parameters in a backwards 78 compatible manner. 80 The document defines a general SDP Capability Negotiation framework. 81 It also specifies how to provide attributes and transport protocols 82 as capabilities and negotiate them using the framework. Extensions 83 for other types of capabilities (e.g. media types and media formats) 84 may be provided in other documents. 86 Table of Contents 88 1. Introduction...................................................4 89 2. Conventions used in this document..............................7 90 3. SDP Capability Negotiation Solution............................7 91 3.1. SDP Capability Negotiation Model..........................7 92 3.2. Solution Overview........................................11 93 3.3. Version and Extension Indication Attributes..............15 94 3.3.1. Supported Capability Negotiation Extensions Attribute15 95 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......................31 104 3.6. Offer/Answer Model Extensions............................33 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...............................47 110 3.7. Interactions with ICE....................................48 111 3.8. Interactions with SIP Option Tags........................49 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...52 115 3.12. SDP Capability Negotiation and Intermediaries...........53 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................................56 120 4. Examples......................................................57 121 4.1. Multiple Transport Protocols.............................57 122 4.2. DTLS-SRTP or SRTP with Media Level Security Descriptions.60 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..................................68 127 5. Security Considerations.......................................71 128 6. IANA Considerations...........................................74 129 6.1. New SDP Attributes.......................................74 130 6.2. New SDP Capability Negotiation Option Tag Registry.......76 131 6.3. New SDP Capability Negotiation Potential Configuration 132 Parameter Registry............................................76 133 7. Acknowledgments...............................................77 134 8. Change Log....................................................77 135 8.1. draft-ietf-mmusic-sdp-capability-negotiation-13..........77 136 8.2. draft-ietf-mmusic-sdp-capability-negotiation-12..........77 137 8.3. draft-ietf-mmusic-sdp-capability-negotiation-11..........78 138 8.4. draft-ietf-mmusic-sdp-capability-negotiation-10..........79 139 8.5. draft-ietf-mmusic-sdp-capability-negotiation-09..........79 140 8.6. draft-ietf-mmusic-sdp-capability-negotiation-08..........79 141 8.7. draft-ietf-mmusic-sdp-capability-negotiation-07..........80 142 8.8. draft-ietf-mmusic-sdp-capability-negotiation-06..........80 143 8.9. draft-ietf-mmusic-sdp-capability-negotiation-05..........82 144 8.10. draft-ietf-mmusic-sdp-capability-negotiation-04.........83 145 8.11. draft-ietf-mmusic-sdp-capability-negotiation-03.........83 146 8.12. draft-ietf-mmusic-sdp-capability-negotiation-02.........84 147 8.13. draft-ietf-mmusic-sdp-capability-negotiation-01.........84 148 8.14. draft-ietf-mmusic-sdp-capability-negotiation-00.........85 149 9. References....................................................86 150 9.1. Normative References.....................................86 151 9.2. Informative References...................................86 152 Author's Address.................................................89 154 1. Introduction 156 The Session Description Protocol (SDP) was intended for describing 157 multimedia sessions for the purposes of session announcement, 158 session invitation, and other forms of multimedia session 159 initiation. A SDP session description contains one or more media 160 stream descriptions with information such as IP-address and port, 161 type of media stream (e.g. audio or video), transport protocol 162 (possibly including profile information, e.g. RTP/AVP or RTP/SAVP), 163 media formats (e.g. codecs), and various other session and media 164 stream parameters that define the session. 166 Simply providing media stream descriptions is sufficient for session 167 announcements for a broadcast application, where the media stream 168 parameters are fixed for all participants. When a participant wants 169 to join the session, he obtains the session announcement and uses 170 the media descriptions provided, e.g., joins a multicast group and 171 receives media packets in the encoding format specified. If the 172 media stream description is not supported by the participant, he is 173 unable to receive the media. 175 Such restrictions are not generally acceptable to multimedia session 176 invitations, where two or more entities attempt to establish a media 177 session, that uses a set of media stream parameters acceptable to 178 all participants. First of all, each entity must inform the other of 179 its receive address, and secondly, the entities need to agree on the 180 media stream parameters to use for the session, e.g. transport 181 protocols and codecs. To solve this, RFC 3264 [RFC3264] defined the 182 offer/answer model, whereby an offerer constructs an offer SDP 183 session description that lists the media streams, codecs, and other 184 SDP parameters that the offerer is willing to use. This offer 185 session description is sent to the answerer, which chooses from 186 among the media streams, codecs and other session description 187 parameters provided, and generates an answer session description 188 with his parameters, based on that choice. The answer session 189 description is sent back to the offerer thereby completing the 190 session negotiation and enabling the establishment of the negotiated 191 media streams. 193 Taking a step back, we can make a distinction between the 194 capabilities supported by each participant, the way in which those 195 capabilities can be supported, and the parameters that can actually 196 be used for the session. More generally, we can say that we have the 197 following: 199 o A set of capabilities for the session and its associated media 200 stream components, supported by each side. The capability 201 indications by themselves do not imply a commitment to use the 202 capabilities in the session. 204 Capabilities can for example be that the "RTP/SAVP" profile is 205 supported, that the "PCMU" codec is supported, or that the 206 "crypto" attribute is supported with a particular value. 208 o A set of potential configurations indicating which combinations 209 of those capabilities can be used for the session and its 210 associated media stream components. Potential configurations are 211 not ready for use. Instead, they provide an alternative that may 212 be used, subject to further negotiation. 214 A potential configuration can for example indicate that the 215 "PCMU" codec and the "RTP/SAVP" transport protocol are not only 216 supported (i.e. listed as capabilities), but they are offered for 217 potential use in the session. 219 o An actual configuration for the session and its associated media 220 stream components, that specifies which combinations of session 221 parameters and media stream components can be used currently and 222 with what parameters. Use of an actual configuration does not 223 require any further negotiation. 225 An actual configuration can for example be that the "PCMU" codec 226 and the "RTP/SAVP" transport protocol are offered for use 227 currently. 229 o A negotiation process that takes the set of actual and potential 230 configurations (combinations of capabilities) as input and 231 provides the negotiated actual configurations as output. 233 SDP by itself was designed to provide only one of these, namely 234 listing of the actual configurations, however over the years, use of 235 SDP has been extended beyond its original scope. Of particular 236 importance are the session negotiation semantics that were defined 237 by the offer/answer model in RFC 3264. In this model, both the offer 238 and the answer contain actual configurations; separate capabilities 239 and potential configurations are not supported. 241 Other relevant extensions have been defined as well. RFC 3407 242 [RFC3407] defined simple capability declarations, which extends SDP 243 with a simple and limited set of capability descriptions. Grouping 244 of media lines, which defines how media lines in SDP can have other 245 semantics than the traditional "simultaneous media streams" 246 semantics, was defined in RFC 3388 [RFC3388], etc. 248 Each of these extensions was designed to solve a specific limitation 249 of SDP. Since SDP had already been stretched beyond its original 250 intent, a more comprehensive capability declaration and negotiation 251 process was intentionally not defined. Instead, work on a "next 252 generation" of a protocol to provide session description and 253 capability negotiation was initiated [SDPng]. SDPng defined a 254 comprehensive capability negotiation framework and protocol that was 255 not bound by existing SDP constraints. SDPng was not designed to be 256 backwards compatible with existing SDP and hence required both sides 257 to support it, with a graceful fallback to legacy operation when 258 needed. This, combined with lack of ubiquitous multipart MIME 259 support in the protocols that would carry SDP or SDPng, made it 260 challenging to migrate towards SDPng. In practice, SDPng has not 261 gained traction and as of the time of publication of this document, 262 work on SDPng has stopped. Existing real-time multimedia 263 communication protocols such as SIP, RTSP, Megaco, and MGCP continue 264 to use SDP. However, SDP does not address an increasingly important 265 problem: the ability to negotiate one or more alternative transport 266 protocols (e.g., RTP profiles) and associated parameters (e.g. SDP 267 attributes). This makes it difficult to deploy new RTP profiles 268 such as secure RTP (SRTP) [RFC3711], RTP with RTCP-Based Feedback 269 [RFC4585], etc. The problem is exacerbated by the fact that RTP 270 profiles are defined independently. When a new profile is defined 271 and N other profiles already exist, there is a potential need for 272 defining N additional profiles, since profiles cannot be combined 273 automatically. For example, in order to support the plain and 274 secure RTP version of RTP with and without RTCP-based feedback, four 275 separate profiles (and hence profile definitions) are needed: 276 RTP/AVP [RFC3551], RTP/SAVP [RFC3711], RTP/AVPF [RFC4585], and 277 RTP/SAVPF [RFC5124]. In addition to the pressing profile 278 negotiation problem, other important real-life limitations have been 279 found as well. Keying material and other parameters for example need 280 to be negotiated with some of the transport protocols, but not 281 others. Similarly, some media formats and types of media streams 282 need to negotiate a variety of different parameters. 284 The purpose of this document is to define a mechanism that enables 285 SDP to provide limited support for indicating capabilities and their 286 associated potential configurations, and negotiate the use of those 287 potential configurations as actual configurations. It is not the 288 intent to provide a full-fledged capability indication and 289 negotiation mechanism along the lines of SDPng or ITU-T H.245. 290 Instead, the focus is on addressing a set of well-known real-life 291 limitations. More specifically, the solution provided in this 292 document provides a general SDP Capability Negotiation framework 293 that is backwards compatible with existing SDP. It also defines 294 specifically how to provide attributes and transport protocols as 295 capabilities and negotiate them using the framework. Extensions for 296 other types of capabilities (e.g. media types and formats) may be 297 provided in other documents. 299 As mentioned above, SDP is used by several protocols, and hence the 300 mechanism should be usable by all of these. One particularly 301 important protocol for this problem is the Session Initiation 302 Protocol (SIP) [RFC3261]. SIP uses the offer/answer model [RFC3264] 303 (which is not specific to SIP) to negotiate sessions and hence the 304 mechanism defined here provides the offer/answer procedures to use 305 for the capability negotiation framework. 307 The rest of the document is structured as follows. In Section 3. we 308 present the SDP Capability Negotiation solution, which consists of 309 new SDP attributes and associated offer/answer procedures. In 310 Section 4. we provide examples illustrating its use and in Section 311 5. we provide the security considerations. 313 2. Conventions used in this document 315 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 316 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 317 document are to be interpreted as described in [RFC2119]. 319 3. SDP Capability Negotiation Solution 321 In this section we first present the conceptual model behind the SDP 322 capability negotiation framework followed by an overview of the SDP 323 Capability Negotiation solution. We then define new SDP attributes 324 for the solution and provide its associated updated offer/answer 325 procedures. 327 3.1. SDP Capability Negotiation Model 329 Our model uses the concepts of 330 o Capabilities 332 o Potential Configurations 334 o Actual Configurations 336 o Negotiation Process 338 as defined in Section 1. Conceptually, we want to offer not just the 339 actual configuration SDP session description (which is done with the 340 offer/answer model defined in [RFC3264]), but the actual 341 configuration SDP session description as well as one or more 342 alternative SDP session descriptions, i.e. potential configurations. 343 The answerer must choose either the actual configuration, or one of 344 the potential configurations, and generate an answer SDP session 345 description based on that. The offerer may need to perform 346 processing on the answer, which depends on the offer that was chosen 347 (actual or potential configuration). The answerer therefore informs 348 the offerer which configuration the answerer chose. The process can 349 be viewed *conceptually* as follows: 351 Offerer Answerer 352 ======= ======== 354 1) Generate offer with actual 355 configuration and alternative 356 potential configurations 357 2) Send offer with all configurations 359 +------------+ 360 | SDP o1 | 361 | (actual | 362 | config | 363 | |-+ Offer 364 +------------+ | -----> 3) Process offered configurations 365 | SDP o2 | in order of preference indicated 366 | (potential | 4) Generate answer based on chosen 367 | config 1) |-+ configuration (e.g. o2), and 368 +------------+ | inform offerer which one was 369 | SDP o3 | chosen 370 | (potential | 371 | config 2) |-+ 372 +------------+ | 373 | SDP ... | 374 : : 376 +------------+ 377 | SDP a1 | 378 Answer | (actual | 379 <----- | config,o2)| 380 | | 381 5) Process answer based on +------------+ 382 the configuration that was 383 chosen (o2), as indicated in 384 the answer 386 The above illustrates the conceptual model: The actual solution uses 387 a single SDP session description, which contains the actual 388 configuration (as with existing SDP session descriptions and the 389 offer/answer model defined in [RFC3264]) and several new attributes 390 and associated procedures, that encode the capabilities and 391 potential configurations. A more accurate depiction of the actual 392 offer SDP session description is therefore as follows: 394 +--------------------+ 395 | SDP o1 | 396 | (actual | 397 | config | 398 | | 399 | +-------------+ | 400 | | capability 1| | 401 | | capability 2| | 402 | | ... | | 403 | +-------------+ | Offer 404 | | -----> 405 | +-------------+ | 406 | | potential | | 407 | | config 1 | | 408 | | potential | | 409 | | config 2 | | 410 | | ... | | 411 | +-------------+ | 412 | | 413 +--------------------+ 415 The above structure is used for two reasons: 417 o Backwards compatibility: As noted above, support for multipart 418 MIME is not ubiquitous. By encoding both capabilities and 419 potential configurations in SDP attributes, we can represent 420 everything in a single SDP session description thereby avoiding 421 any multipart MIME support issues. Furthermore, since unknown SDP 422 attributes are ignored by the SDP recipient, we ensure that 423 entities that do not support the framework simply perform the 424 regular RFC 3264 offer/answer procedures. This provides us with 425 seamless backwards compatibility. 427 o Message size efficiency: When we have multiple media streams, 428 each of which may potentially use two or more different transport 429 protocols with a variety of different associated parameters, the 430 number of potential configurations can be large. If each possible 431 alternative is represented as a complete SDP session description 432 in an offer, we can easily end up with large messages. By 433 providing a more compact encoding, we get more efficient message 434 sizes. 436 In the next section, we describe the exact structure and specific 437 SDP parameters used to represent this. 439 3.2. Solution Overview 441 The solution consists of the following: 443 o Two new SDP attributes to support extensions to the framework 444 itself as follows: 446 o A new attribute ("a=csup") that lists the supported base 447 (optionally) and any supported extension options to the 448 framework. 450 o A new attribute ("a=creq") that lists the extensions to the 451 framework that are required to be supported by the entity 452 receiving the SDP session description in order to do 453 capability negotiation. 455 o Two new SDP attributes used to express capabilities as follows 456 (additional attributes can be defined as extensions): 458 o A new attribute ("a=acap") that defines how to list an 459 attribute name and its associated value (if any) as a 460 capability. 462 o A new attribute ("a=tcap") that defines how to list transport 463 protocols (e.g. "RTP/AVP") as capabilities. 465 o Two new SDP attributes to negotiate configurations as follows: 467 o A new attribute ("a=pcfg") that lists potential 468 configurations supported. This is done by reference to the 469 capabilities from the SDP session description in question. 470 Extension capabilities can be defined and referenced in the 471 potential configurations. Alternative potential 472 configurations have an explicit ordering associated with 473 them. Also, potential configurations are by default preferred 474 over the actual configuration included in the "m=" line and 475 its associated parameters. 477 This preference order was chosen to provide maximum 478 backwards compatibility for the capability negotiation 479 framework and the possible values offered for a session. 480 For example, an entity that wants to establish a secure 481 RTP media stream but is willing to accept a plain RTP 482 media stream (assumed to be the least common denominator 483 for most endpoints), can offer plain RTP in the actual 484 configuration and use the capability negotiation 485 extensions to indicate the preference for secure RTP. 486 Entities that do not support the capability negotiation 487 extensions or secure RTP will then default to plain RTP. 489 o A new attribute ("a=acfg") to be used in an answer SDP 490 session description. The attribute identifies a potential 491 configuration from an offer SDP session description which was 492 used as an actual configuration to form the answer SDP 493 session description. Extension capabilities can be included 494 as well. 496 o Extensions to the offer/answer model that allow for capabilities 497 and potential configurations to be included in an offer. 498 Capabilities can be provided at the session level and the media 499 level. Potential configurations can be included only at the media 500 level, where they constitute alternative offers that may be 501 accepted by the answerer instead of the actual configuration(s) 502 included in the "m=" line(s) and associated parameters. The 503 mechanisms defined in this document enable potential 504 configurations to change the transport protocol, add new 505 attributes as well as remove all existing attributes from the 506 actual configuration. The answerer indicates which (if any) of 507 the potential configurations it used to form the answer by 508 including the actual configuration attribute ("a=acfg") in the 509 answer. Capabilities may be included in answers as well, where 510 they can aid in guiding a subsequent new offer. 512 The mechanism is illustrated by the offer/answer exchange below, 513 where Alice sends an offer to Bob: 515 Alice Bob 517 | (1) Offer (SRTP and RTP) | 518 |--------------------------------->| 519 | | 520 | (2) Answer (SRTP) | 521 |<---------------------------------| 522 | | 523 | (3) Offer (SRTP) | 524 |--------------------------------->| 525 | | 526 | (4) Answer (SRTP) | 527 |<---------------------------------| 528 | | 530 Alice's offer includes RTP and SRTP as alternatives, where RTP is 531 the default (actual configuration), but SRTP is the preferred one 532 (potential configuration): 534 v=0 535 o=- 25678 753849 IN IP4 192.0.2.1 536 s= 537 c=IN IP4 192.0.2.1 538 t=0 0 539 m=audio 53456 RTP/AVP 0 18 540 a=tcap:1 RTP/SAVP 541 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 542 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 543 a=pcfg:1 t=1 a=1 545 The "m=" line indicates that Alice is offering to use plain RTP with 546 PCMU or G.729. The capabilities are provided by the "a=tcap" and 547 "a=acap" attributes. The transport capability attribute ("a=tcap") 548 indicates that secure RTP under the AVP profile ("RTP/SAVP") is 549 supported with an associated transport capability handle of 1. The 550 "acap" attribute provides an attribute capability with a handle of 551 1. The attribute capability is a "crypto" attribute, which provides 552 the keying material for SRTP using SDP security descriptions 553 [RFC4568]. The "a=pcfg" attribute provides the potential 554 configuration included in the offer by reference to the capability 555 parameters. One alternative is provided; it has a configuration 556 number of 1 and it consists of transport protocol capability 1 557 (i.e., the RTP/SAVP profile - secure RTP), and the attribute 558 capability 1 (i.e., the crypto attribute provided). Potential 559 configurations are preferred over the actual configuration included 560 in the offer SDP session description, and hence Alice is expressing 561 a preference for using secure RTP. 563 Bob receives the SDP session description offer from Alice. Bob 564 supports SRTP and the SDP Capability Negotiation framework, and 565 hence he accepts the (preferred) potential configuration for Secure 566 RTP provided by Alice and generates the following answer SDP session 567 description: 569 v=0 570 o=- 24351 621814 IN IP4 192.0.2.2 571 s= 572 c=IN IP4 192.0.2.2 573 t=0 0 574 m=audio 54568 RTP/SAVP 0 18 575 a=crypto:1 AES_CM_128_HMAC_SHA1_80 576 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 577 a=acfg:1 t=1 a=1 579 Bob includes the "a=acfg" attribute in the answer to inform Alice 580 that he based his answer on an offer using potential configuration 1 581 with transport protocol capability 1 and attribute capability 1 from 582 the offer SDP session description (i.e., the RTP/SAVP profile using 583 the keying material provided). Bob also includes his keying 584 material in a "crypto" attribute. If Bob supported one or more 585 extensions to the capability negotiation framework, he would have 586 included option tags for those in the answer as well (in an "a=csup" 587 attribute). 589 When Alice receives Bob's answer, session negotiation has completed, 590 however Alice nevertheless generates a new offer using the 591 negotiated configuration as the actual configuration. This is done 592 purely to assist any intermediaries that may reside between Alice 593 and Bob but do not support the SDP Capability Negotiation framework, 594 and hence may not understand the negotiation that just took place. 596 Alice's updated offer includes only SRTP, and it is not using the 597 SDP Capability Negotiation framework (Alice could have included the 598 capabilities as well if she wanted to): 600 v=0 601 o=- 25678 753850 IN IP4 192.0.2.1 602 s= 603 c=IN IP4 192.0.2.1 604 t=0 0 605 m=audio 53456 RTP/SAVP 0 18 606 a=crypto:1 AES_CM_128_HMAC_SHA1_80 607 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 609 The "m=" line now indicates that Alice is offering to use secure RTP 610 with PCMU or G.729. The "crypto" attribute, which provides the SRTP 611 keying material, is included with the same value again. 613 Bob receives the SDP session description offer from Alice, which he 614 accepts, and then generates an answer to Alice: 616 v=0 617 o=- 24351 621815 IN IP4 192.0.2.2 618 s= 619 c=IN IP4 192.0.2.2 620 t=0 0 621 m=audio 54568 RTP/SAVP 0 18 622 a=crypto:1 AES_CM_128_HMAC_SHA1_80 623 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 625 Bob includes the same crypto attribute as before, and the session 626 proceeds without change. Although Bob did not include any 627 capabilities in his answer, he could have done so if he wanted to. 629 Note that in this particular example, the answerer supported the 630 capability negotiation extensions defined here. Had he not, he would 631 simply have ignored the new attributes and accepted the (actual 632 configuration) offer to use normal RTP. In that case, the following 633 answer would have been generated instead: 635 v=0 636 o=- 24351 621814 IN IP4 192.0.2.2 637 s= 638 c=IN IP4 192.0.2.2 639 t=0 0 640 m=audio 54568 RTP/AVP 0 18 642 3.3. Version and Extension Indication Attributes 644 In this section, we present the new attributes associated with 645 indicating the SDP Capability Negotiation extensions supported and 646 required. 648 3.3.1. Supported Capability Negotiation Extensions Attribute 650 The SDP Capability Negotiation solution allows for capability 651 negotiation extensions to be defined. Associated with each such 652 extension is an option tag that identifies the extension in 653 question. Option-tags MUST be registered with IANA per the 654 procedures defined in Section 6.2. 656 The Supported Capability Negotiation Extensions attribute ("a=csup") 657 contains a comma-separated list of option tags identifying the SDP 658 Capability Negotiation extensions supported by the entity that 659 generated the SDP session description. The attribute can be provided 660 at the session-level and the media-level, and it is defined as 661 follows: 663 a=csup: 665 RFC 4566, Section 9, provides the ABNF [RFC5234] for SDP attributes. 666 The "csup" attribute adheres to the RFC 4566 "attribute" production, 667 with an att-value defined as follows: 669 att-value = option-tag-list 670 option-tag-list = option-tag *("," option-tag) 671 option-tag = token ; defined in [RFC4566] 673 A special base option tag with a value of "cap-v0" is defined for 674 the basic SDP Capability Negotiation framework defined in this 675 document. Entities can use this option tag with the "a=csup" 676 attribute to indicate support for the SDP Capability Negotiation 677 framework specified in this document. Please note that white space 678 is not allowed in this rule. 680 The following examples illustrate use of the "a=csup" attribute with 681 the "cap-v0" option tag and two hypothetical option tags, "foo" and 682 "bar" (note the lack of white space): 684 a=csup:cap-v0 686 a=csup:foo 688 a=csup:bar 690 a=csup:cap-v0,foo,bar 692 The "a=csup" attribute can be provided at the session and the media- 693 level. When provided at the session-level, it applies to the entire 694 SDP session description. When provided at the media-level, it 695 applies only to the media description in question (option-tags 696 provided at the session level apply as well). There MUST NOT be more 697 than one "a=csup" attribute at the session-level and one at the 698 media-level (one per media description in the latter case). 700 Whenever an entity that supports one or more extensions to the SDP 701 Capability Negotiation framework generates an SDP session 702 description, it SHOULD include the "a=csup" attribute with the 703 option tags for the extensions it supports at the session and/or 704 media-level, unless those option tags are already provided in one or 705 more "a=creq" attribute (see Section 3.3.2. ) at the relevant 706 levels. Inclusion of the base option tag is OPTIONAL; support for 707 the base framework can be inferred from presence of the "a=pcfg" 708 attribute defined in Section 3.5.1. 710 Use of the base option tag may still be useful in some scenarios, 711 e.g. when using SIP OPTIONS [RFC3261] or generating an answer to 712 an offer that did not use the SDP Capability Negotiation 713 framework. 715 3.3.2. Required Capability Negotiation Extensions Attribute 717 The Required Capability Negotiation Extensions attribute ("a=creq") 718 contains a comma-separated list of option tags (see Section 3.3.1. ) 719 specifying the SDP Capability Negotiation extensions that MUST be 720 supported by the entity receiving the SDP session description, in 721 order for that entity to properly process the SDP Capability 722 Negotiation attributes and associated procedures. There is no need 723 to include the base option-tag ("cap-v0") with the "creq" attribute, 724 since any entity that supports the "creq" attribute in the first 725 place also supports the base option-tag. Still, it is permissible to 726 do so. 728 Such functionality may be important if a future version of the 729 capability negotiation framework were not backwards compatible. 731 The attribute can be provided at the session-level and the media- 732 level, and it is defined as follows: 734 a=creq: 736 The "creq" attribute adheres to the RFC 4566 "attribute" production, 737 with an att-value defined as follows: 739 att-value = option-tag-list 741 The following examples illustrate use of the "a=creq" attribute with 742 the "cap-v0" base option tag and two hypothetical option tags, "foo" 743 and "bar" (note the lack of white space): 745 a=creq:cap-v0 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 in 778 this document; instead the recipient MUST proceed as if the SDP 779 Capability Negotiation attributes were not included in the first 780 place, i.e. the capability negotiation attributes are ignored. In 781 that case, if the SDP session description recipient is an SDP 782 answerer [RFC3264], the recipient SHOULD include a "csup" attribute 783 in the resulting SDP session description answer listing the SDP 784 Capability Negotiation extensions it actually supports. 786 This ensures that introduction of the SDP Capability Negotiation 787 mechanism by itself does not lead to session failures 789 For non-supported extensions provided at the session-level, this 790 implies that SDP Capability Negotiation MUST NOT be performed at 791 all. For non-supported extensions at the media-level, this implies 792 that SDP Capability Negotiation MUST NOT be performed for the media 793 stream in question. 795 An entity that does not support the SDP Capability Negotiation 796 framework at all, will ignore these attributes (as well as the 797 other SDP Capability Negotiation attributes) and not perform any 798 SDP Capability Negotiation in the first place. 800 3.4. Capability Attributes 802 In this section, we present the new attributes associated with 803 indicating the capabilities for use by the SDP Capability 804 Negotiation. 806 3.4.1. Attribute Capability Attribute 808 Attributes and their associated values can be expressed as 809 capabilities by use of a new attribute capability attribute 810 ("a=acap"), which is defined as follows: 812 a=acap: 814 where is an integer between 1 and 2^31-1 (both 815 included) used to number the attribute capability and is 816 an attribute ("a=") in its "" or :" 817 form, i.e., excluding the "a=" part (see [RFC4566]). The attribute 818 can be provided at the session-level and the media-level. 820 The "acap" attribute adheres to the RFC 4566 "attribute" production, 821 with an att-value defined as follows: 823 att-value = att-cap-num 1*WSP att-par 824 att-cap-num = 1*10(DIGIT) ;defined in [RFC5234] 825 att-par = attribute ;defined in [RFC4566] 827 Note that white space is not permitted before the att-cap-num. 829 When the attribute capability contains a session-level attribute, 830 that "acap" attribute can only be provided at the session level. 831 Conversely, media level attributes can be provided in attribute 832 capabilities at either the media level or session-level. The base 833 SDP Capability Negotiation framework however only defines procedures 834 for use of media-level attribute capabilities at the media level. 835 Implementations that conform only to the base framework MUST NOT 836 generate media-level attribute capabilities at the session-level, 837 however extensions may change this (see, e.g., [SDPMedCap] for one 838 such extension) and hence all implementations MUST still be prepared 839 to receive such capabilities (see Section 3.6.2. for processing 840 rules). 842 Each occurrence of the "acap" attribute in the entire session 843 description MUST use a different value of . 844 Consecutive numbering of the values is not required. 846 There is a need to be able to reference both session-level and 847 media-level attributes in potential configurations at the media 848 level, and this provides for a simple solution to avoiding overlap 849 between the references (handles) to each attribute capability. 851 The values provided are independent of similar values provided for other types of capabilities, i.e., they 853 form a separate name-space for attribute capabilities. 855 The following examples illustrate use of the "acap" attribute: 857 a=acap:1 ptime:20 859 a=acap:2 ptime:30 861 a=acap:3 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAA 862 AAAGEEoo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0 863 JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUO 864 SrzKTAv9zV 866 a=acap:4 crypto:1 AES_CM_128_HMAC_SHA1_32 867 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 869 The first two attribute capabilities provide attribute values for 870 the ptime attribute. The third provides SRTP parameters by using 871 MIKEY [RFC3830] with the key-mgmt attribute [RFC4567]. The fourth 872 provides SRTP parameters by use of security descriptions with the 873 crypto attribute [RFC4568]. Note that the line-wrapping and new- 874 lines in example three and four are provided for formatting reasons 875 only - they are not permitted in actual SDP session descriptions. 877 Readers familiar with RFC 3407 may notice the similarity between 878 the RFC 3407 "cpar" attribute and the above. There are however a 879 couple of important differences, notably that the "acap" attribute 880 contains a handle that enables referencing it and it furthermore 881 supports only attributes (the "cpar" attribute defined in RFC 3407 882 supports bandwidth information as well). The "acap" attribute also 883 is not automatically associated with any particular capabilities. 884 See Section 3.14. for the relationship to RFC 3407. 886 Attribute capabilities MUST NOT embed any capability negotiation 887 parameters. This restriction applies to all the capability 888 negotiation parameters defined in this document ("csup", "creq", 889 "acap", "tcap", "pcfg", and "acfg") as well as any capability 890 negotiation extensions defined. The following examples are thus 891 invalid attribute capabilities and MUST NOT be used: 893 a=acap:1 acap:2 foo:a ;Not allowed to embed "acap" 895 a=acap:2 a=pcfg:1 t=1 a=1 ;Not allowed to embed "pcfg" 897 The reason for this restriction is to avoid overly complex 898 processing rules resulting from the expansion of such capabilities 899 into potential configurations (see Section 3.6.2. for further 900 details). 902 3.4.2. Transport Protocol Capability Attribute 904 Transport Protocols can be expressed as capabilities by use of a new 905 Transport Protocol Capability attribute ("a=tcap") defined as 906 follows: 908 a=tcap: 910 where is an integer between 1 and 2^31-1 (both 911 included) used to number the transport address capability for later 912 reference, and is one or more , separated by 913 white space, as defined in the SDP "m=" line. The attribute can be 914 provided at the session-level and the media-level. 916 The "tcap" attribute adheres to the RFC 4566 "attribute" production, 917 with an att-value defined as follows: 919 att-value = trpr-cap-num 1*WSP proto-list 920 trpr-cap-num = 1*10(DIGIT) ;defined in [RFC5234] 921 proto-list = proto *(1*WSP proto) ;defined in [RFC4566] 923 Note that white space is not permitted before the trpr-cap-num. 925 The "tcap" attribute can be provided at the session-level and the 926 media-level. There MUST NOT be more than one "a=tcap" attribute at 927 the session-level and one at the media-level (one per media 928 description in the latter case). Each occurrence of the "tcap" 929 attribute in the entire session description MUST use a different 930 value of . When multiple values are provided, 931 the first one is associated with the value , the 932 second one with the value one higher, etc. There MUST NOT be any 933 capability number overlap between different "tcap" attributes in the 934 entire SDP session description. The values provided 935 are independent of similar values provided for other 936 capability attributes, i.e., they form a separate name-space for 937 transport protocol capabilities. Consecutive numbering of the values in different "tcap" attributes is not required. 940 Below, we provide examples of the "a=tcap" attribute: 942 a=tcap:1 RTP/AVP 944 a=tcap:2 RTP/AVPF 946 a=tcap:3 RTP/SAVP RTP/SAVPF 948 a=tcap:5 UDP/TLS/RTP/SAVP 950 The first one provides a capability for the "RTP/AVP" profile 951 defined in [RFC3551] and the second one provides a capability for 952 the RTP with RTCP-Based Feedback profile defined in [RFC4585]. The 953 third one provides capabilities for the "RTP/SAVP" (transport 954 capability number 3) and "RTP/SAVPF" profiles (transport protocol 955 capability number 4). The last one provides capabilities for 956 "UDP/TLS/RTP/SAVP", i.e. DTLS-SRTP [DTLS-SRTP](transport capability 957 number 5). 959 The "tcap" attribute by itself can only specify transport protocols 960 as defined by in [RFC4566], however full specification of a 961 media stream requires further qualification of the transport 962 protocol by one or more media format descriptions, which themselves 963 often depend on the transport protocol. As an example, [RFC3551] 964 defines the "RTP/AVP" transport for use with audio and video codecs 965 (media formats), whereas [RFC4145] defines the "TCP" transport which 966 for example may be used to negotiate T.38 fax ("image/t38"), etc. In 967 a non-SDP context, some media formats could be viewed as transports 968 themselves (e.g. T.38) however in the context of SDP and SDP 969 Capability Negotiation, they are not. If capability negotiation is 970 required for such media formats, they MUST all either be valid under 971 the transport protocol indicated in the "m=" line included for the 972 media stream description, or a suitable extension must be used, e.g. 973 SDP Media Capabilities [SDPMedCap]. 975 The ability to use a particular transport protocol is inherently 976 implied by including it in the "m=" line, regardless of whether it 977 is provided in a "tcap" attribute or not. However, if a potential 978 configuration needs to reference that transport protocol as a 979 capability, the transport protocol MUST be included explicitly in a 980 "tcap" attribute. 982 This may seem redundant (and indeed it is from the offerer's point 983 of view), however it is done to protect against intermediaries 984 (e.g. middle-boxes) that may modify "m=" lines while passing 985 unknown attributes through. If an implicit transport capability 986 were used instead (e.g. a reserved transport capability number 987 could be used to refer to the transport protocol in the "m=" 988 line), and an intermediary were to modify the transport protocol 989 in the "m=" line (e.g. to translate between plain RTP and secure 990 RTP), then the potential configuration referencing that implicit 991 transport capability may no longer be correct. With explicit 992 capabilities, we avoid this pitfall; however, the potential 993 configuration preference (see Section 3.5.1. ) may not reflect 994 that of the intermediary (which some may view as a feature). 996 Note that a transport protocol capability may be provided, 997 irrespective of whether it is referenced in a potential 998 configuration or not (just like any other capability). 1000 3.4.3. Extension Capability Attributes 1002 The SDP Capability Negotiation framework allows for new types of 1003 capabilities to be defined as extensions and used with the general 1004 capability negotiation framework. The syntax and semantics of such 1005 new capability attributes are not defined here, however in order to 1006 be used with potential configurations, they SHOULD allow for a 1007 numeric handle to be associated with each capability. This handle 1008 can be used as a reference within the potential and actual 1009 configuration attributes (see Section 3.5.1. and 3.5.2. ). The 1010 definition of such extension capability attributes MUST also state 1011 whether they can be applied at the session-level, media-level, or 1012 both. Note that extensions can have option tags defined for them, 1013 and option tags MUST be registered with the IANA in accordance with 1014 the procedures specified in Section 6.2. 1016 Extension capabilities SHOULD NOT embed any capability negotiation 1017 parameters. This applies to all the capability negotiation 1018 parameters defined in this document as well as any extensions 1019 defined. The reason for this restriction is to avoid overly complex 1020 processing rules resulting from the expansion of such capabilities 1021 into potential configurations (see Section 3.6.2. for further 1022 details). If an extension does not follow the above "SHOULD NOT" 1023 recommendation, the extension MUST provide a careful analysis of why 1024 such behavior is both necessary and safe. 1026 3.5. Configuration Attributes 1028 3.5.1. Potential Configuration Attribute 1030 Potential Configurations can be expressed by use of a new Potential 1031 Configuration Attribute ("a=pcfg") defined as follows: 1033 a=pcfg: [] 1035 where is an integer between 1 and 2^31-1 (both 1036 included). The attribute can be provided only at the media-level. 1038 The "pcfg" attribute adheres to the RFC 4566 "attribute" production, 1039 with an att-value defined as follows: 1041 att-value = config-number [1*WSP pot-cfg-list] 1042 config-number = 1*10(DIGIT) ;defined in [RFC5234] 1043 pot-cfg-list = pot-config *(1*WSP pot-config) 1044 pot-config = attribute-config-list / 1045 transport-protocol-config-list / 1046 extension-config-list 1048 The missing productions are defined below. Note that white space is 1049 not permitted before the config-number. 1051 The potential configuration attribute can be provided only at the 1052 media-level and there can be multiple instances of it within a given 1053 media description. The attribute includes a configuration number, 1054 which is an integer between 1 and 2^31-1 (both included). The 1055 configuration number MUST be unique within the media description 1056 (i.e., it has only media level scope). The configuration number also 1057 indicates the relative preference of potential configurations; lower 1058 numbers are preferred over higher numbers. Consecutive numbering of 1059 the configuration numbers in different "pcfg" attributes in a media 1060 description is not required. 1062 A potential configuration list is normally provided after the 1063 configuration number. When the potential configuration list is 1064 omitted, the potential configuration equals the actual 1065 configuration. The potential configuration list contains one or more 1066 of attribute, transport and extension configuration lists. A 1067 potential configuration may for example include attribute 1068 capabilities and transport capabilities, transport capabilities 1069 only, or some other combination of capabilities. If transport 1070 capabilities are not included in a potential configuration, the 1071 default transport for that media stream is used. 1073 The potential configuration lists generally reference one or more 1074 capabilities (extension configuration lists MAY use a different 1075 format). Those capabilities are (conceptually) used to construct a 1076 new internal version of the SDP session description by use of purely 1077 syntactic add and (possibly) delete operations on the original SDP 1078 session description (actual configuration). This provides an 1079 alternative potential configuration SDP session description that can 1080 be used by conventional SDP and offer/answer procedures if selected. 1082 This document defines attribute configuration lists and transport 1083 protocol configuration lists. Each of these MUST NOT be present 1084 more than once in a particular potential configuration attribute. 1085 Attribute capabilities referenced by the attribute configuration 1086 list (if included) are added to the actual configuration, whereas a 1087 transport capability referenced by the transport protocol 1088 configuration list (if included) replaces the default transport 1089 protocol from the actual configuration. Extension configuration 1090 lists can be included as well. There can be more than one extension 1091 configuration list, however each particular extension MUST NOT be 1092 present more than once in a given "a=pcfg" attribute. Together, the 1093 various configuration lists define a potential configuration. 1095 There can be multiple potential configurations in a media 1096 description. Each of these indicates not only a willingness, but in 1097 fact a desire to use the potential configuration. 1099 The example SDP session description below contains two potential 1100 configurations: 1102 v=0 1103 o=- 25678 753849 IN IP4 192.0.2.1 1104 s= 1105 c=IN IP4 192.0.2.1 1106 t=0 0 1107 m=audio 53456 RTP/AVP 0 18 1108 a=tcap:1 RTP/SAVP RTP/SAVPF 1109 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 1110 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 1111 a=pcfg:1 t=1 a=1 1112 a=pcfg:2 t=2 a=1 1114 Potential configuration 1 contains a transport protocol 1115 configuration list that references transport capability 1 1116 ("RTP/SAVP") and an attribute configuration list that references 1117 attribute capability 1 ("a=crypto:..."). Potential configuration 2 1118 contains a transport protocol configuration list that references 1119 transport capability 2 ("RTP/SAVPF") and an attribute configuration 1120 list that references attribute capability 1 ("a=crypto:..."). 1122 Attribute capabilities are used in a potential configuration by use 1123 of the attribute-config-list parameter, which is defined by the 1124 following ABNF: 1126 attribute-config-list = "a=" delete-attributes 1127 attribute-config-list =/ "a=" [delete-attributes ":"] 1128 mo-att-cap-list *(BAR mo-att-cap-list) 1130 delete-attributes = DELETE ( "m" ; media attributes 1131 / "s" ; session attributes 1132 / "ms" ) ; media and session attributes 1134 mo-att-cap-list = mandatory-optional-att-cap-list / 1135 mandatory-att-cap-list / 1136 optional-att-cap-list 1138 mandatory-optional-att-cap-list = mandatory-att-cap-list 1139 "," optional-att-cap-list 1140 mandatory-att-cap-list = att-cap-list 1141 optional-att-cap-list = "[" att-cap-list "]" 1143 att-cap-list = att-cap-num *("," att-cap-num) 1144 att-cap-num = 1*10(DIGIT) ;defined in [RFC5234] 1145 BAR = "|" 1146 DELETE = "-" 1148 Note that white space is not permitted within the attribute-config- 1149 list rule. 1151 Each attribute configuration list can optionally begin with 1152 instructions for how to handle attributes that are part of the 1153 actual configuration SDP session description (i.e., the "a=" lines 1154 present in the original SDP session description). By default, such 1155 attributes will remain as part of the potential configuration in 1156 question. However, if delete-attributes indicates "-m", then all 1157 attribute lines within the media description in question will be 1158 deleted in the resulting potential configuration SDP session 1159 description (i.e., all "a=" lines under the "m=" line in question). 1160 If delete-attributes indicates "-s", then all attribute lines at the 1161 session-level will be deleted (i.e., all "a=" lines before the first 1162 "m=" line). If delete-attributes indicates "-ms", then all attribute 1163 lines within this media description ("m=" line) and all attribute 1164 lines at the session-level will be deleted. 1166 The attribute capability list comes next (if included). It contains 1167 one or more alternative lists of attribute capabilities. The 1168 alternative attribute capability lists are separated by a vertical 1169 bar ("|"), and each list contains one or more attribute capabilities 1170 separated by commas (","). The attribute capabilities are either 1171 mandatory or optional. Mandatory attribute capabilities MUST be 1172 supported in order to use the potential configuration, whereas 1173 optional attribute capabilities MAY be supported in order to use the 1174 potential configuration. 1176 Within each attribute capability list, all the mandatory attribute 1177 capabilities (if any) are listed first, and all the optional 1178 attribute capabilities (if any) are listed last. The optional 1179 attribute capabilities are contained within a pair of square 1180 brackets ("[" and "]"). Each attribute capability is merely an 1181 attribute capability number (att-cap-num) that identifies a 1182 particular attribute capability by referring to attribute capability 1183 numbers defined above and hence MUST be between 1 and 2^31-1 (both 1184 included). The following example illustrates the above: 1186 a=pcfg:1 a=-m:1,2,[3,4]|1,7,[5] 1188 where 1190 o "a=-m:1,2,[3,4]|1,7,[5]" is the attribute configuration list 1192 o "-m" indicates to delete all attributes from the media 1193 description of the actual configuration 1195 o "1,2,[3,4]" and "1,7,[5]" are both attribute capability lists. 1196 The two lists are alternatives, since they are separated by a 1197 vertical bar above 1199 o "1", "2" and "7" are mandatory attribute capabilities 1201 o "3", "4" and "5" are optional attribute capabilities 1203 Note that in the example above, we have a single handle ("1") for 1204 the potential configuration(s), but there are actually two different 1205 potential configurations (separated by a vertical bar). This is done 1206 for message size efficiency reasons, which is especially important 1207 when we add other types of capabilities to the potential 1208 configuration. If there is a need to provide a unique handle for 1209 each, then separate "a=pcfg" attributes with different handles MUST 1210 be used instead. 1212 Each referenced attribute capability in the potential configuration 1213 will result in the corresponding attribute name and its associated 1214 value (contained inside the attribute capability) being added to the 1215 resulting potential configuration SDP session description. 1217 Alternative attribute capability lists are separated by a vertical 1218 bar ("|"), the scope of which extends to the next alternative (i.e., 1219 "," has higher precedence than "|"). The alternatives are ordered by 1220 preference with the most preferred listed first. In order for a 1221 recipient of the SDP session description (e.g., an answerer 1222 receiving this in an offer) to use this potential configuration, 1223 exactly one of the alternative lists MUST be selected in its 1224 entirety. This requires that all mandatory attribute capabilities 1225 referenced by the potential configuration are supported with the 1226 attribute values provided. 1228 Transport protocol configuration lists are included in a potential 1229 configuration by use of the transport-protocol-config-list 1230 parameter, which is defined by the following ABNF: 1232 transport-protocol-config-list = 1233 "t=" trpr-cap-num *(BAR trpr-cap-num) 1234 trpr-cap-num = 1*10(DIGIT) ; defined in [RFC5234] 1236 Note that white space is not permitted within this rule. 1238 The trpr-cap-num refers to transport protocol capability numbers 1239 defined above and hence MUST be between 1 and 2^31-1 (both 1240 included). Alternative transport protocol capabilities are separated 1241 by a vertical bar ("|"). The alternatives are ordered by preference 1242 with the most preferred listed first. If there are no transport 1243 protocol capabilities included in a potential configuration at the 1244 media level, the transport protocol information from the associated 1245 "m=" line MUST be used. In order for a recipient of the SDP session 1246 description (e.g., an answerer receiving this in an offer) to use 1247 this potential configuration, exactly one of the alternatives MUST 1248 be selected. This requires that the transport protocol in question 1249 is supported. 1251 In the presence of intermediaries (the existence of which may not 1252 be known), care should be taken with assuming that the transport 1253 protocol in the "m=" line will not be modified by an intermediary. 1254 Use of an explicit transport protocol capability will guard 1255 against capability negotiation implications of that. 1257 Extension capabilities can be included in a potential configuration 1258 as well by use of extension configuration lists. Extension 1259 configuration lists MUST adhere to the following ABNF: 1261 extension-config-list = ["+"] ext-cap-name "=" ext-cap-list 1262 ext-cap-name = 1*(ALPHA / DIGIT) 1263 ext-cap-list = 1*VCHAR ; defined in [RFC5234] 1265 Note that white space is not permitted within this rule. 1267 The ext-cap-name refers to the name of the extension capability and 1268 the ext-cap-list is here merely defined as a sequence of visible 1269 characters. The actual extension supported MUST refine both of these 1270 further. For extension capabilities that merely need to be 1271 referenced by a capability number, it is RECOMMENDED to follow a 1272 structure similar to what has been specified above. Unsupported or 1273 unknown potential extension configuration lists in a potential 1274 configuration attribute MUST be ignored, unless they are prefixed 1275 with the plus ("+") sign, which indicates that the extension is 1276 mandatory and MUST be supported in order to use that potential 1277 configuration. 1279 The "creq" attribute and its associated rules can be used to 1280 ensure that required extensions are supported in the first place. 1282 Extension configuration lists define new potential configuration 1283 parameters and hence they MUST be registered with IANA per the 1284 procedures defined in Section 6.3. 1286 Potential configuration attributes can be provided only at the media 1287 level, however it is possible to reference capabilities provided at 1288 either the session or media level. There are certain semantic rules 1289 and restrictions associated with this: 1291 A (media level) potential configuration attribute in a given media 1292 description MUST NOT reference a media-level capability provided in 1293 a different media description; doing so invalidates that potential 1294 configuration (note that a potential configuration attribute can 1295 contain more than one potential configuration by use of 1296 alternatives). A potential configuration attribute can however 1297 reference a session-level capability. The semantics of doing so 1298 depends on the type of capability. In the case of transport protocol 1299 capabilities it has no particular implication. In the case of 1300 attribute capabilities however, it does. More specifically, the 1301 attribute name and value (provided within that attribute capability) 1302 will be considered part of the resulting SDP for that particular 1303 configuration at the *session* level. In other words, it will be as- 1304 if that attribute was provided with that value at the session-level 1305 in the first place. As a result, the base SDP Capability Negotiation 1306 framework REQUIRES that potential configurations do not reference 1307 any session-level attribute capabilities that contain media-level 1308 attributes (since that would place a media-level attribute at the 1309 session level). Extensions may modify this behavior, as long as it 1310 is fully backwards compatible with the base specification. 1312 Individual media streams perform capability negotiation 1313 individually, and hence it is possible that one media stream (where 1314 the attribute was part of a potential configuration) chose a 1315 configuration without a session level attribute that was chosen by 1316 another media stream. The session-level attribute however remains 1317 "active" and applies to the entire resulting potential configuration 1318 SDP session description. In theory, this is problematic if one or 1319 more session-level attributes either conflicts with or potentially 1320 interacts with another session-level or media-level attribute in an 1321 undefined manner. In practice, such examples seem to be rare (at 1322 least with the SDP attributes that had been defined at time of 1323 publication of this document). 1325 A related set of problems can occur if we need coordination 1326 between session-level attributes from multiple media streams in 1327 order for a particular functionality to work. The grouping 1328 framework [RFC3388] is an example of this. If we use the SDP 1329 Capability Negotiation framework to select a session-level group 1330 attribute (provided as an attribute capability), and we require 1331 two media descriptions to do this consistently, we could have a 1332 problem. The FEC grouping semantics [RFC4756] is one example where 1333 this in theory could cause problems, however in practice, it is 1334 unclear that there is a significant problem with the grouping 1335 semantics that had been defined at time of publication of this 1336 document. 1338 Resolving the above issues in general requires inter-media stream 1339 constraints and synchronized potential configuration processing; 1340 this would add considerable complexity to the overall solution. In 1341 practice, with the SDP attributes defined at time of publication of 1342 this document, it does not seem to be a significant problem, and 1343 hence the base SDP Capability Negotiation solution does not provide 1344 a solution to this issue. Instead, it is RECOMMENDED that use of 1345 session-level attributes in a potential configuration is avoided 1346 when possible, and when not, that such use is examined closely for 1347 any potential interaction issues. If interaction is possible, the 1348 entity generating the SDP session description SHOULD NOT assume that 1349 well-defined operation will occur at the receiving entity. This 1350 implies that mechanisms which might have such interactions cannot be 1351 used in security critical contexts. 1353 The session-level operation of extension capabilities is undefined: 1354 Consequently, each new session-level extension capability defined 1355 MUST specify the implication of making it part of a configuration at 1356 the media level. 1358 Below, we provide an example of the "a=pcfg" attribute in a complete 1359 media description in order to properly indicate the supporting 1360 attributes: 1362 v=0 1363 o=- 25678 753849 IN IP4 192.0.2.1 1364 s= 1365 c=IN IP4 192.0.2.1 1366 t=0 0 1367 m=audio 53456 RTP/AVPF 0 18 1368 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 1369 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 1370 a=tcap:1 RTP/AVPF RTP/AVP RTP/SAVP RTP/SAVPF 1371 a=pcfg:1 t=4|3 a=1 1372 a=pcfg:8 t=1|2 1374 We have two potential configuration attributes listed here. The 1375 first one (and most preferred, since its configuration number is 1376 "1") indicates that either of the profiles RTP/SAVPF or RTP/SAVP 1377 (specified by the transport protocol capability numbers 4 and 3) can 1378 be supported with attribute capability 1 (the "crypto" attribute); 1379 RTP/SAVPF is preferred over RTP/SAVP since its capability number (4) 1380 is listed first in the preferred potential configuration. Note that 1381 although we have a single potential configuration attribute and 1382 associated handle, we have two potential configurations. 1384 The second potential configuration attribute indicates that the 1385 RTP/AVPF or RTP/AVP profiles can be used, with RTP/AVPF being the 1386 preferred one. This non secure RTP alternative is the less preferred 1387 one since its configuration number is "8". Again, note that we have 1388 two potential configurations here and hence a total of four 1389 potential configurations in the SDP session description above. 1391 3.5.2. Actual Configuration Attribute 1393 The actual configuration attribute identifies which of the potential 1394 configurations from an offer SDP session description was selected 1395 and used as the actual configuration to generate an answer SDP 1396 session description. This is done by including the configuration 1397 number and the configuration lists (if any) from the offer that were 1398 selected and used by the answerer in his offer/answer procedure as 1399 follows: 1401 o A selected attribute configuration MUST include the delete- 1402 attributes and the known and supported parameters from the 1403 selected alternative mo-att-cap-list (i.e., containing all 1404 mandatory and all known and supported optional capability numbers 1405 from the potential configuration). If delete-attributes were not 1406 included in the potential configuration, they will of course not 1407 be present here either. 1409 o A selected transport protocol configuration MUST include the 1410 selected transport protocol capability number. 1412 o A selected potential extension configuration MUST include the 1413 selected extension configuration parameters as specified for that 1414 particular extension. 1416 o When a configuration list contains alternatives (separated by 1417 "|"), the selected configuration only MUST be provided. 1419 Note that the selected configuration number and all selected 1420 capability numbers used in the actual configuration attribute refer 1421 to those from the offer; not the answer. 1423 The answer may for example include capabilities as well to inform 1424 the offerer of the answerers capabilities above and beyond the 1425 negotiated configuration. The actual configuration attribute does 1426 not refer to any of those answer capabilities though. 1428 The Actual Configuration Attribute ("a=acfg") is defined as follows: 1430 a=acfg: [] 1432 where is an integer between 1 and 2^31-1 (both 1433 included) that refers to the selected potential configuration. The 1434 attribute can be provided only at the media-level. 1436 The "acfg" attribute adheres to the RFC 4566 "attribute" production, 1437 with an att-value defined as follows: 1439 att-value = config-number [1*WSP sel-cfg-list] 1440 ;config-number defined in Section 3.5.1. 1441 sel-cfg-list = sel-cfg *(1*WSP sel-cfg) 1442 sel-cfg = sel-attribute-config / 1443 sel-transport-protocol-config / 1444 sel-extension-config 1446 sel-attribute-config = 1447 "a=" [delete-attributes ":"] mo-att-cap-list 1448 ; defined in Section 3.5.1. 1450 sel-transport-protocol-config = 1451 "t=" trpr-cap-num ; defined in Section 3.5.1. 1453 sel-extension-config = 1454 ext-cap-name "=" 1*VCHAR ; defined in Section 3.5.1. 1456 Note that white space is not permitted before the config-number. 1458 The actual configuration ("a=acfg") attribute can be provided only 1459 at the media-level. There MUST NOT be more than one occurrence of an 1460 actual configuration attribute within a given media description. 1462 Below, we provide an example of the "a=acfg" attribute (building on 1463 the previous example with the potential configuration attribute): 1465 v=0 1466 o=- 24351 621814 IN IP4 192.0.2.2 1467 s= 1468 c=IN IP4 192.0.2.2 1469 t=0 0 1470 m=audio 54568 RTP/SAVPF 0 1471 a=crypto:1 AES_CM_128_HMAC_SHA1_32 1472 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 1473 a=acfg:1 t=4 a=1 1475 It indicates that the answerer used an offer consisting of potential 1476 configuration number 1 with transport protocol capability 4 from the 1477 offer (RTP/SAVPF) and attribute capability 1 (the "crypto" 1478 attribute). The answerer includes his own "crypto" attribute as 1479 well. 1481 3.6. Offer/Answer Model Extensions 1483 In this section, we define extensions to the offer/answer model 1484 defined in [RFC3264] to allow for potential configurations to be 1485 included in an offer, where they constitute alternative offers that 1486 may be accepted by the answerer instead of the actual 1487 configuration(s) included in the "m=" line(s). 1489 The procedures defined in the following subsections apply to both 1490 unicast and multicast streams. 1492 3.6.1. Generating the Initial Offer 1494 An offerer that wants to use the SDP Capability Negotiation defined 1495 in this document MUST include the following in the offer: 1497 o Zero or more attribute capability attributes. There MUST be an 1498 attribute capability attribute ("a=acap") as defined in Section 1499 3.4.1. for each attribute name and associated value (if any) that 1500 needs to be indicated as a capability in the offer. Attribute 1501 capabilities may be included irrespective of whether they are 1502 referenced by a potential configuration or not. 1504 Session-level attributes and associated values MUST be provided 1505 in attribute capabilities only at the session-level, whereas 1506 media-level attributes and associated values can be provided in 1507 attribute capabilities at either the media-level or session- 1508 level. Attributes that are allowed at either the session- or 1509 media-level can be provided in attribute capabilities at either 1510 level. 1512 o Zero or more transport protocol capability attributes. There MUST 1513 be transport protocol capabilities as defined in Section 3.4.2. 1514 with values for each transport protocol that needs to be 1515 indicated as a capability in the offer. 1517 Transport protocol capabilities may be included irrespective of 1518 whether they are referenced by a potential configuration or not. 1519 Transport protocols that apply to multiple media descriptions 1520 SHOULD be provided as transport protocol capabilities at the 1521 session-level whereas transport protocols that apply only to a 1522 specific media description ("m=" line), SHOULD be provided as 1523 transport protocol capabilities within that particular media 1524 description. In either case, there MUST NOT be more than a single 1525 "a=tcap" attribute at the session-level and a single "a=tcap" 1526 attribute in each media description. 1528 o Zero or more extension capability attributes. There MUST be one 1529 or more extension capability attributes (as outlined in Section 1530 3.4.3. ) for each extension capability that is referenced by a 1531 potential configuration. Extension capability attributes that are 1532 not referenced by a potential configuration can be provided as 1533 well. 1535 o Zero or more potential configuration attributes. There MUST be 1536 one or more potential configuration attributes ("a=pcfg"), as 1537 defined in Section 3.5.1. , in each media description where 1538 alternative potential configurations are to be negotiated. Each 1539 potential configuration attribute MUST adhere to the rules 1540 provided in Section 3.5.1. and the additional rules provided 1541 below. 1543 If the offerer requires support for one or more extensions (besides 1544 the base protocol defined here), then the offerer MUST include one 1545 or more "a=creq" attributes as follows: 1547 o If support for one or more capability negotiation extensions is 1548 required for the entire session description, then option tags for 1549 those extensions MUST be included in a single session-level 1550 "creq" attribute. 1552 o For each media description that requires support for one or more 1553 capability negotiation extensions not listed at the session- 1554 level, a single "creq" attribute containing all the required 1555 extensions for that media description MUST be included within the 1556 media description (in accordance with Section 3.3.2. ). 1558 Note that extensions that only need to be supported by a particular 1559 potential configuration can use the "mandatory" extension prefix 1560 ("+") within the potential configuration (see Section 3.5.1. ). 1562 The offerer SHOULD furthermore include the following: 1564 o A supported capability negotiation extension attribute ("a=csup") 1565 at the session-level and/or media-level as defined in Section 1566 3.3.2. for each capability negotiation extension supported by the 1567 offerer and not included in a corresponding "a=creq" attribute 1568 (i.e., at the session-level or in the same media description). 1569 Option tags provided in a "a=csup" attribute at the session-level 1570 indicate extensions supported for the entire session description, 1571 whereas option tags provided in a "a=csup" attribute in a media 1572 description indicate extensions supported for only that 1573 particular media description. 1575 Capabilities provided in an offer merely indicate what the offerer 1576 is capable of doing. They do not constitute a commitment or even an 1577 indication to use them. In contrast, each potential configuration 1578 constitutes an alternative offer that the offerer would like to use. 1579 The potential configurations MUST be used by the answerer to 1580 negotiate and establish the session. 1582 The offerer MUST include one or more potential configuration 1583 attributes ("a=pcfg") in each media description where the offerer 1584 wants to provide alternative offers (in the form of potential 1585 configurations). Each potential configuration attribute in a given 1586 media description MUST contain a unique configuration number and 1587 zero, one or more potential configuration lists, as described in 1588 Section 3.5.1. Each potential configuration list MUST refer to 1589 capabilities that are provided at the session-level or within that 1590 particular media description; otherwise, the potential configuration 1591 is considered invalid. The base SDP Capability Negotiation framework 1592 REQUIRES that potential configurations do not reference any session- 1593 level attribute capabilities that contain media-level only 1594 attributes, however extensions may modify this behavior, as long as 1595 it is fully backwards compatible with the base specification. 1596 Furthermore, it is RECOMMENDED that potential configurations avoid 1597 use of session-level capabilities whenever possible; refer to 1598 Section 3.5.1. 1600 The current actual configuration is included in the "m=" line (as 1601 defined by [RFC3264]) and any associated parameters for the media 1602 description (e.g., attribute ("a=") and bandwidth ("b=") lines). 1603 Note that the actual configuration is by default the least-preferred 1604 configuration, and hence the answerer will seek to negotiate use of 1605 one of the potential configurations instead. If the offerer wishes a 1606 different preference for the actual configuration, the offerer MUST 1607 include a corresponding potential configuration with the relevant 1608 configuration number (which indicates the relative preference 1609 between potential configurations); this corresponding potential 1610 configuration should simply duplicate the actual configuration. 1612 This can either be done implicitly (by not referencing any 1613 capabilities), or explicitly (by providing and using capabilities 1614 for the transport protocol and all the attributes that are part of 1615 the actual configuration). The latter may help detect 1616 intermediaries that modify the actual configuration but are not 1617 SDP Capability Negotiation aware. 1619 Per [RFC3264], once the offerer generates the offer, he must be 1620 prepared to receive incoming media in accordance with that offer. 1621 That rule applies here as well, but only for the actual 1622 configurations provided in the offer: Media received by the offerer 1623 according to one of the potential configurations MAY be discarded, 1624 until the offerer receives an answer indicating what the actual 1625 selected configuration is. Once that answer is received, incoming 1626 media MUST be processed in accordance with the actual selected 1627 configuration indicated and the answer received (provided the 1628 offer/answer exchange completed successfully). 1630 The above rule assumes that the offerer can determine whether 1631 incoming media adheres to the actual configuration offered or one of 1632 the potential configurations instead; this may not always be the 1633 case. If the offerer wants to ensure he does not play out any 1634 garbage, the offerer SHOULD discard all media received before the 1635 answer SDP session description is received. Conversely, if the 1636 offerer wants to avoid clipping, he SHOULD attempt to play any 1637 incoming media as soon as it is received (at the risk of playing out 1638 garbage). In either case, please note that this document does not 1639 place any requirements on the offerer to process and play media 1640 before answer. For further details, please refer to Section 3.9. 1642 3.6.2. Generating the Answer 1644 When receiving an offer, the answerer MUST check for the presence of 1645 a required capability negotiation extension attribute ("a=creq") 1646 provided at the session level. If one is found, then capability 1647 negotiation MUST be performed. If none is found, then the answerer 1648 MUST check each offered media description for the presence of a 1649 required capability negotiation extension attribute ("a=creq") and 1650 one or more potential configuration attributes ("a=pcfg"). 1651 Capability negotiation MUST be performed for each media description 1652 where either of those is present in accordance with the procedures 1653 described below. 1655 The answerer MUST first ensure that it supports any required 1656 capability negotiation extensions: 1658 o If a session-level "creq" attribute is provided, and it contains 1659 an option-tag that the answerer does not support, then the 1660 answerer MUST NOT use any of the potential configuration 1661 attributes provided for any of the media descriptions. Instead, 1662 the normal offer/answer procedures MUST continue as per 1663 [RFC3264]. Furthermore, the answerer MUST include a session-level 1664 supported capability negotiation extensions attribute ("a=csup") 1665 with option tags for the capability negotiation extensions 1666 supported by the answerer. 1668 o If a media-level "creq" attribute is provided, and it contains an 1669 option tag that the answerer does not support, then the answerer 1670 MUST NOT use any of the potential configuration attributes 1671 provided for that particular media description. Instead, the 1672 offer/answer procedures for that media description MUST continue 1673 as per [RFC3264] (SDP Capability Negotiation is still performed 1674 for other media descriptions in the SDP session description). 1675 Furthermore, the answerer MUST include a supported capability 1676 negotiation extensions attribute ("a=csup") in that media 1677 description with option tags for the capability negotiation 1678 extensions supported by the answerer for that media description. 1680 Assuming all required capability negotiation extensions are 1681 supported, the answerer now proceeds as follows. 1683 For each media description where capability negotiation is to be 1684 performed (i.e. all required capability negotiation extensions are 1685 supported and at least one valid potential configuration attribute 1686 is present), the answerer MUST perform capability negotiation by 1687 using the most preferred potential configuration that is valid to 1688 the answerer, subject to any local policies. A potential 1689 configuration is valid to the answerer if: 1691 1. It is in accordance with the syntax and semantics provided in 1692 Section 3.5.1. 1694 2. It contains a configuration number that is unique within that 1695 media description. 1697 3. All attribute capabilities referenced by the potential 1698 configuration are valid themselves (as defined in Section 3.4.1. 1699 ) and each of them is provided either at the session-level or 1700 within this particular media description. 1702 For session-level attribute capabilities referenced, the 1703 attributes contained inside them MUST NOT be media-level only 1704 attributes. Note that the answerer can only determine this for 1705 attributes supported by the answerer. If an attribute is not 1706 supported, it will simply be ignored by the answerer and hence 1707 will not trigger an "invalid" potential configuration. 1709 4. All transport protocol capabilities referenced by the potential 1710 configuration are valid themselves (as defined in Section 3.4.2. 1711 ) and each of them is furthermore provided either at the session- 1712 level or within this particular media description. 1714 5. All extension capabilities referenced by the potential 1715 configuration and supported by the answerer are valid themselves 1716 (as defined by that particular extension) and each of them are 1717 furthermore provided either at the session-level or within this 1718 particular media description. Unknown or unsupported extension 1719 capabilities MUST be ignored, unless they are prefixed with the 1720 plus ("+") sign, which indicates that the extension MUST be 1721 supported in order to use that potential configuration. If the 1722 extension is not supported, that potential configuration is not 1723 valid to the answerer. 1725 The most preferred valid potential configuration in a media 1726 description is the valid potential configuration with the lowest 1727 configuration number. The answerer MUST now process the offer for 1728 that media stream based on the most preferred valid potential 1729 configuration. Conceptually, this entails the answerer constructing 1730 an (internal) offer as follows. First, all capability negotiation 1731 parameters from the offer SDP session description are removed, 1732 thereby yielding an offer SDP session description with the actual 1733 configuration as if SDP capability negotiation was not done in the 1734 first place. Secondly, this actual configuration SDP session 1735 description is modified as follows for each media stream offered, 1736 based on the capability negotiation parameters included originally: 1738 o If a transport protocol capability is included in the potential 1739 configuration, then it replaces the transport protocol provided 1740 in the "m=" line for that media description. 1742 o If attribute capabilities are present with a delete-attributes 1743 session indication ("-s") or media and session indication ("- 1744 ms"), then all session-level attributes from the actual 1745 configuration SDP session description MUST be deleted in the 1746 resulting potential configuration SDP session description in 1747 accordance with the procedures in Section 3.5.1. If attribute 1748 capabilities are present with a delete-attributes media 1749 indication ("-m") or media and session indication ("-ms"), then 1750 all attributes from the actual configuration SDP session 1751 description inside this media description MUST be deleted. 1753 o If a session-level attribute capability is included, the 1754 attribute (and its associated value, if any) contained in it MUST 1755 be added to the resulting SDP session description. All such added 1756 session-level attributes MUST be listed before the session-level 1757 attributes that were initially present in the SDP session 1758 description. Furthermore, the added session-level attributes MUST 1759 be added in the order they were provided in the potential 1760 configuration (see also Section 3.5.1. ). 1762 This allows for attributes with implicit preference ordering 1763 to be added in the desired order; the "crypto" attribute 1764 [RFC4568] is one such example. 1766 o If a media-level attribute capability is included, then the 1767 attribute (and its associated value, if any) MUST be added to the 1768 resulting SDP session description within the media description in 1769 question. All such added media-level attributes MUST be listed 1770 before the media-level attributes that were initially present in 1771 the media description in question. Furthermore, the added media- 1772 level attributes MUST be added in the order they were provided in 1773 the potential configuration (see also Section 3.5.1. ). 1775 o If a supported extension capability is included, then it MUST be 1776 processed in accordance with the rules provided for that 1777 particular extension capability. 1779 The above steps MUST be performed exactly once per potential 1780 configuration, i.e. there MUST NOT be any recursive processing of 1781 any additional capability negotiation parameters that may 1782 (illegally) have been nested inside capabilities themselves. 1784 As an example of this, consider the (illegal) attribute capability 1786 a=acap:1 acap:2 foo:a 1788 The resulting potential configuration SDP session description 1789 will, after the above processing has been done, contain the 1790 attribute capability 1792 a=acap:2 foo:a 1794 However, since we do not perform any recursive processing of 1795 capability negotiation parameters, this second attribute 1796 capability parameter will not be processed by the offer/answer 1797 procedure. Instead, it will simply appear as a (useless) attribute 1798 in the SDP session description that will be ignored by further 1799 processing. 1801 Note that a transport protocol from the potential configuration 1802 replaces the transport protocol in the actual configuration, but an 1803 attribute capability from the potential configuration is simply 1804 added to the actual configuration. In some cases, this can result in 1805 having one or more meaningless attributes in the resulting potential 1806 configuration SDP session description, or worse, ambiguous or 1807 potentially even illegal attributes. Use of delete-attributes for 1808 the session and/or media level attributes MUST be done to avoid such 1809 scenarios. Nevertheless, it is RECOMMENDED that implementations 1810 ignore meaningless attributes that may result from potential 1811 configurations. 1813 For example, if the actual configuration was using Secure RTP and 1814 included an "a=crypto" attribute for the SRTP keying material, 1815 then use of a potential configuration that uses plain RTP would 1816 make the "crypto" attribute meaningless. The answerer may or may 1817 not ignore such a meaningless attribute. The offerer can here 1818 ensure correct operation by using delete-attributes to remove the 1819 crypto attribute (but will then need to provide attribute 1820 capabilities to reconstruct the SDP session description with the 1821 necessary attributes deleted, e.g. rtpmaps). 1823 Also note, that while it is permissible to include media-level 1824 attribute capabilities at the session-level, the base SDP Capability 1825 Negotiation framework defined here does not define any procedures 1826 for use of them, i.e. the answerer effectively ignores them. 1828 Please refer to Section 3.6.2.1. for examples of how the answerer 1829 may conceptually "see" the resulting offered alternative potential 1830 configurations. 1832 The answerer MUST check that he supports all mandatory attribute 1833 capabilities from the potential configuration (if any), the 1834 transport protocol capability (if any) from the potential 1835 configuration, and all mandatory extension capabilities from the 1836 potential configuration (if any). If he does not, the answerer MUST 1837 proceed to the second-most preferred valid potential configuration 1838 for the media description, etc. 1840 o In the case of attribute capabilities, support implies that the 1841 attribute name contained in the capability is supported and it 1842 can (and will) be negotiated successfully in the offer/answer 1843 exchange with the value provided. This does not necessarily imply 1844 that the value provided is supported in its entirety. For 1845 example, the "a=fmtp" parameter is often provided with one or 1846 more values in a list, where the offerer and answerer negotiate 1847 use of some subset of the values provided. Other attributes may 1848 include mandatory and optional parts to their values; support for 1849 the mandatory part is all that is required here. 1851 A side-effect of the above rule is that whenever an "fmtp" or 1852 "rtpmap" parameter is provided as a mandatory attribute 1853 capability, the corresponding media format (codec) must be 1854 supported and use of it negotiated successfully. If this is 1855 not the offerer's intent, the corresponding attribute 1856 capabilities must be listed as optional instead. 1858 o In the case of transport protocol capabilities, support implies 1859 that the transport protocol contained in the capability is 1860 supported and the transport protocol can (and will) be negotiated 1861 successfully in the offer/answer exchange. 1863 o In the case of extension capabilities, the extension MUST define 1864 the rules for when the extension capability is considered 1865 supported and those rules MUST be satisfied. 1867 If the answerer has exhausted all potential configurations for the 1868 media description, without finding a valid one that is also 1869 supported, then the answerer MUST process the offered media stream 1870 based on the actual configuration plus any session-level attributes 1871 added by a valid and supported potential configuration from another 1872 media description in the offered SDP session description. 1874 The above process describes potential configuration selection as a 1875 per media stream process. Inter-media stream coordination of 1876 selected potential configurations however is required in some cases. 1877 First of all, session-level attributes added by a potential 1878 configuration for one media description MUST NOT cause any problems 1879 for potential configurations selected by other media descriptions in 1880 the offer SDP session description. If the session-level attributes 1881 are mandatory, then those session-level attributes MUST furthermore 1882 be supported by the session as a whole (i.e., all the media 1883 descriptions if relevant). As mentioned earlier, this adds 1884 additional complexity to the overall processing and hence it is 1885 RECOMMENDED not to use session-level attribute capabilities in 1886 potential configurations, unless absolutely necessary. 1888 Once the answerer has selected a valid and supported offered 1889 potential configuration for all of the media streams (or has fallen 1890 back to the actual configuration plus any added session attributes), 1891 the answerer MUST generate a valid virtual answer SDP session 1892 description based on the selected potential configuration SDP 1893 session description, as "seen" by the answerer using normal 1894 offer/answer rules (see Section 3.6.2.1. for examples). The actual 1895 answer SDP session description is formed from the virtual answer SDP 1896 session description as follows: If the answerer selected one of the 1897 potential configurations in a media description, the answerer MUST 1898 include an actual configuration attribute ("a=acfg") within that 1899 media description. The "a=acfg" attribute MUST identify the 1900 configuration number for the selected potential configuration as 1901 well as the actual parameters that were used from that potential 1902 configuration; if the potential configuration included alternatives, 1903 the selected alternatives only MUST be included. Only the known and 1904 supported parameters will be included. Unknown or unsupported 1905 parameters MUST NOT be included in the actual configuration 1906 attribute. In the case of attribute capabilities, only the known and 1907 supported capabilities are included; unknown or unsupported 1908 attribute capabilities MUST NOT be included. 1910 If the answerer supports one or more capability negotiation 1911 extensions that were not included in a required capability 1912 negotiation extensions attribute in the offer, then the answerer 1913 SHOULD furthermore include a supported capability negotiation 1914 attribute ("a=csup") at the session-level with option tags for the 1915 extensions supported across media streams. Also, if the answerer 1916 supports one or more capability negotiation extensions for only 1917 particular media descriptions, then a supported capability 1918 negotiation attribute with those option-tags SHOULD be included 1919 within each relevant media description. The required capability 1920 negotiation attribute ("a=creq") MUST NOT be used in an answer. 1922 The offerer's originally provided actual configuration is contained 1923 in the offer media description's "m=" line (and associated 1924 parameters). The answerer MAY send media to the offerer in 1925 accordance with that actual configuration as soon as it receives the 1926 offer, however it MUST NOT send media based on that actual 1927 configuration if it selects an alternative potential configuration. 1928 If the answerer selects one of the potential configurations, then 1929 the answerer MAY immediately start to send media to the offerer in 1930 accordance with the selected potential configuration, however the 1931 offerer MAY discard such media or play out garbage until the offerer 1932 receives the answer. Please refer to section 3.9. for additional 1933 considerations and possible alternative solutions outside the base 1934 SDP Capability Negotiation framework. 1936 If the answerer selected a potential configuration instead of the 1937 actual configuration, then it is RECOMMENDED that the answerer sends 1938 back an answer SDP session description as soon as possible. This 1939 minimizes the risk of having media discarded or played out as 1940 garbage by the offerer. In the case of SIP [RFC3261] without any 1941 extensions, this implies that if the offer was received in an INVITE 1942 message, then the answer SDP session description should be provided 1943 in the first non-100 provisional response sent back (per RFC3261, 1944 the answer would need to be repeated in the 200 response as well, 1945 unless a relevant extension such as [RFC3262] is being used). 1947 3.6.2.1. Example Views of Potential Configurations 1949 The following examples illustrate how the answerer may conceptually 1950 "see" a potential configuration. Consider the following offered SDP 1951 session description: 1953 v=0 1954 o=alice 2891092738 2891092738 IN IP4 lost.example.com 1955 s= 1956 t=0 0 1957 c=IN IP4 lost.example.com 1958 a=tool:foo 1959 a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 1960 a=tcap:1 RTP/SAVP RTP/AVP 1961 m=audio 59000 RTP/AVP 98 1962 a=rtpmap:98 AMR/8000 1963 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32 1964 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 1965 a=pcfg:1 t=1 a=1|2 1966 m=video 52000 RTP/AVP 31 1967 a=rtpmap:31 H261/90000 1968 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 1969 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 1970 a=pcfg:1 t=1 a=1|3 1972 This particular SDP session description offers an audio stream and a 1973 video stream, each of which can either use plain RTP (actual 1974 configuration) or secure RTP (potential configuration). Furthermore, 1975 two different keying mechanisms are offered, namely session-level 1976 Key Management Extensions using MIKEY (attribute capability 1) and 1977 media-level SDP Security Descriptions (attribute capabilities 2 and 1978 3). There are several potential configurations here, however, below 1979 we show the one the answerer "sees" when using potential 1980 configuration 1 for both audio and video, and furthermore using 1981 attribute capability 1 (MIKEY) for both (we have removed all the 1982 capability negotiation attributes for clarity): 1984 v=0 1985 o=alice 2891092738 2891092738 IN IP4 lost.example.com 1986 s= 1987 t=0 0 1988 c=IN IP4 lost.example.com 1989 a=tool:foo 1990 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 1991 m=audio 59000 RTP/SAVP 98 1992 a=rtpmap:98 AMR/8000 1993 m=video 52000 RTP/SAVP 31 1994 a=rtpmap:31 H261/90000 1996 Note that the transport protocol in the media descriptions indicate 1997 use of secure RTP. 1999 Below, we show the offer the answerer "sees" when using potential 2000 configuration 1 for both audio and video and furthermore using 2001 attribute capability 2 and 3 respectively (SDP security 2002 descriptions) for the audio and video stream - note the order in 2003 which the resulting attributes are provided: 2005 v=0 2006 o=alice 2891092738 2891092738 IN IP4 lost.example.com 2007 s= 2008 t=0 0 2009 c=IN IP4 lost.example.com 2010 a=tool:foo 2011 m=audio 59000 RTP/SAVP 98 2012 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2013 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2014 a=rtpmap:98 AMR/8000 2015 m=video 52000 RTP/SAVP 31 2016 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2017 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2018 a=rtpmap:31 H261/90000 2020 Again, note that the transport protocol in the media descriptions 2021 indicate use of secure RTP. 2023 And finally, we show the offer the answerer "sees" when using 2024 potential configuration 1 with attribute capability 1 (MIKEY) for 2025 the audio stream, and potential configuration 1 with attribute 2026 capability 3 (SDP security descriptions) for the video stream: 2028 v=0 2029 o=alice 2891092738 2891092738 IN IP4 lost.example.com 2030 s= 2031 t=0 0 2032 c=IN IP4 lost.example.com 2033 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2034 a=tool:foo 2035 m=audio 59000 RTP/SAVP 98 2036 a=rtpmap:98 AMR/8000 2037 m=video 52000 RTP/SAVP 31 2038 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2039 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2040 a=rtpmap:31 H261/90000 2042 3.6.3. Offerer Processing of the Answer 2044 When the offerer attempted to use SDP Capability Negotiation in the 2045 offer, the offerer MUST examine the answer for actual use of SDP 2046 Capability Negotiation. 2048 For each media description where the offerer included a potential 2049 configuration attribute ("a=pcfg"), the offerer MUST first examine 2050 that media description for the presence of a valid actual 2051 configuration attribute ("a=acfg"). An actual configuration 2052 attribute is valid if: 2054 o it refers to a potential configuration that was present in the 2055 corresponding offer, and 2057 o it contains the actual parameters that were used from that 2058 potential configuration; if the potential configuration included 2059 alternatives, the selected alternatives only MUST be included. 2060 Note that the answer will include only parameters and attribute 2061 capabilities that are known and supported by the answerer, as 2062 described in Section 3.6.2. 2064 If a valid actual configuration attribute is not present in a media 2065 description, then the offerer MUST process the answer SDP session 2066 description for that media stream per the normal offer/answer rules 2067 defined in [RFC3264]. However, if a valid one is found, the offerer 2068 MUST instead process the answer as follows: 2070 o The actual configuration attribute specifies which of the 2071 potential configurations was used by the answerer to generate the 2072 answer for this media stream. This includes all the supported 2073 attribute capabilities and the transport capabilities referenced 2074 by the potential configuration selected, where the attribute 2075 capabilities have any associated delete-attributes included. 2076 Extension capabilities supported by the answerer are included as 2077 well. 2079 o The offerer MUST now process the answer in accordance with the 2080 rules in [RFC3264], except that it must be done as if the offer 2081 consisted of the selected potential configuration instead of the 2082 original actual configuration, including any transport protocol 2083 changes in the media ("m=") line(s), attributes added and deleted 2084 by the potential configuration at the media and session level, 2085 and any extensions used. If this derived answer is not a valid 2086 answer to the potential configuration offer selected by the 2087 answerer, the offerer MUST instead continue further processing as 2088 it would have for a regular offer/answer exchange, where the 2089 answer received does not adhere to the rules of [RFC3264]. 2091 If the offer/answer exchange was successful, and if the answerer 2092 selected one of the potential configurations from the offer as the 2093 actual configuration, and the selected potential configuration 2094 differs from the actual configuration in the offer (the "m=", "a=", 2095 etc. lines), then the offerer SHOULD initiate another offer/answer 2096 exchange. This second offer/answer exchange will not modify the 2097 session in any way, however it will help intermediaries (e.g. 2098 middleboxes), that look at the SDP session description but do not 2099 support the capability negotiation extensions, understand the 2100 details of the media stream(s) that were actually negotiated. This 2101 new offer MUST contain the selected potential configuration as the 2102 actual configuration, i.e., with the actual configuration used in 2103 the "m=" line and any other relevant attributes, bandwidth 2104 parameters, etc. 2106 Note that, per normal offer/answer rules, the second offer/answer 2107 exchange still needs to update the version number in the "o=" line 2108 (( in [RFC4566]). Attribute lines carrying keying 2109 material SHOULD repeat the keys from the previous offer, unless re- 2110 keying is necessary, e.g. due to a previously forked SIP INVITE 2111 request. Please refer to Section 3.12. for additional considerations 2112 related to intermediaries. 2114 3.6.4. Modifying the Session 2116 Capabilities and potential configurations may be included in 2117 subsequent offers as defined in [RFC3264], Section 8. The procedure 2118 for doing so is similar to that described above with the answer 2119 including an indication of the actual selected configuration used by 2120 the answerer. 2122 If the answer indicates use of a potential configuration from the 2123 offer, then the guidelines provided in Section 3.6.3. for doing a 2124 second offer/answer exchange using that potential configuration as 2125 the actual configuration apply. 2127 3.7. Interactions with ICE 2129 Interactive Connectivity Establishment (ICE) [ICE] provides a 2130 mechanism for verifying connectivity between two endpoints by 2131 sending STUN messages directly between the media endpoints. The 2132 basic ICE specification [ICE] is only defined to support UDP-based 2133 connectivity, however it allows for extensions to support other 2134 transport protocols, such as TCP, which is being specified in 2135 [ICETCP]. ICE defines a new "a=candidate" attribute, which, among 2136 other things, indicates the possible transport protocol(s) to use 2137 and then associates a priority with each of them. The most preferred 2138 transport protocol that *successfully* verifies connectivity will 2139 end up being used. 2141 When using ICE, it is thus possible that the transport protocol that 2142 will be used differs from what is specified in the "m=" line. Since 2143 both ICE and SDP Capability Negotiation may specify alternative 2144 transport protocols, there is a potentially unintended interaction 2145 when using these together. 2147 We provide the following guidelines for addressing that. 2149 There are two basic scenarios to consider: 2151 1) A particular media stream can run over different transport 2152 protocols (e.g. UDP, TCP, or TCP/TLS), and the intent is simply to 2153 use the one that works (in the preference order specified). 2155 2) A particular media stream can run over different transport 2156 protocols (e.g. UDP, TCP, or TCP/TLS) and the intent is to have the 2157 negotiation process decide which one to use (e.g. T.38 over TCP or 2158 UDP). 2160 In scenario 1, there should be ICE "a=candidate" attributes for UDP, 2161 TCP, etc. but otherwise nothing special in the potential 2162 configuration attributes to indicate the desire to use different 2163 transport protocols (e.g. UDP, or TCP). The ICE procedures 2164 essentially cover the capability negotiation required (by having the 2165 answerer select something it supports and then use of trial and 2166 error connectivity checks). 2168 Scenario 2 does not require a need to support or use ICE. Instead, 2169 we simply use transport protocol capabilities and potential 2170 configuration attributes to indicate the desired outcome. 2172 The scenarios may be combined, e.g. by offering potential 2173 configuration alternatives where some of them can support only one 2174 transport protocol (e.g. UDP), whereas others can support multiple 2175 transport protocols (e.g. UDP or TCP). In that case, there is a need 2176 for tight control over the ICE candidates that will be used for a 2177 particular configuration, yet the actual configuration may want to 2178 use all of the ICE candidates. In that case, the ICE candidate 2179 attributes can be defined as attribute capabilities and the relevant 2180 ones should then be included in the proper potential configurations 2181 (for example candidate attributes for UDP only for potential 2182 configurations that are restricted to UDP, whereas there could be 2183 candidate attributes for UDP, TCP, and TCP/TLS for potential 2184 configurations that can use all three). Furthermore, use of the 2185 delete-attributes in a potential configuration can be used to ensure 2186 that ICE will not end up using a transport protocol that is not 2187 desired for a particular configuration. 2189 SDP Capability Negotiation recommends use of a second offer/answer 2190 exchange when the negotiated actual configuration was one of the 2191 potential configurations from the offer (see Section 3.6.3. ). 2192 Similarly, ICE requires use of a second offer/answer exchange if the 2193 chosen candidate is not the same as the one in the m/c-line from the 2194 offer. When ICE and capability negotiation are used at the same 2195 time, the two secondary offer/answer exchanges SHOULD be combined to 2196 a single one. 2198 3.8. Interactions with SIP Option Tags 2200 SIP [RFC3261] allows for SIP extensions to define a SIP option tag 2201 that identifies the SIP extension. Support for one or more such 2202 extensions can be indicated by use of the SIP Supported header, and 2203 required support for one or more such extensions can be indicated by 2204 use of the SIP Require header. The "a=csup" and "a=creq" attributes 2205 defined by the SDP Capability Negotiation framework are similar, 2206 except that support for these two attributes by themselves cannot be 2207 guaranteed (since they are specified as extensions to the SDP 2208 specification [RFC4566] itself). 2210 SIP extensions with associated option tags can introduce 2211 enhancements to not only SIP, but also SDP. This is for example the 2212 case for SIP preconditions defined in [RFC3312]. When using SDP 2213 Capability Negotiation, some potential configurations may include 2214 certain SDP extensions, whereas others may not. Since the purpose of 2215 the SDP Capability Negotiation is to negotiate a session based on 2216 the features supported by both sides, use of the SIP Require header 2217 for such extensions may not produce the desired result. For example, 2218 if one potential configuration requires SIP preconditions support, 2219 another does not, and the answerer does not support preconditions, 2220 then use of the SIP Require header for preconditions would result in 2221 a session failure, in spite of the fact that a valid and supported 2222 potential configuration was included in the offer. 2224 In general, this can be alleviated by use of mandatory and optional 2225 attribute capabilities in a potential configuration. There are 2226 however cases where permissible SDP values are tied to the use of 2227 the SIP Require header. SIP preconditions [RFC3312] is one such 2228 example, where preconditions with a "mandatory" strength-tag can 2229 only be used when a SIP Require header with the SIP option tag 2230 "precondition" is included. Future SIP extensions that may want to 2231 use the SDP Capability Negotiation framework should avoid such 2232 coupling. 2234 3.9. Processing Media before Answer 2236 The offer/answer model [RFC3264] requires an offerer to be able to 2237 receive media in accordance with the offer prior to receiving the 2238 answer. This property is retained with the SDP Capability 2239 Negotiation extensions defined here, but only when the actual 2240 configuration is selected by the answerer. If a potential 2241 configuration is chosen, the offerer may decide to not process any 2242 media received before the answer is received. This may lead to 2243 clipping. Consequently, the SDP Capability Negotiation framework 2244 recommends sending back an answer SDP session description as soon as 2245 possible. 2247 The issue can be resolved by introducing a three-way handshake. In 2248 the case of SIP, this can for example be done by defining a 2249 precondition [RFC3312] for capability negotiation (or use an 2250 existing precondition that is known to generate a second 2251 offer/answer exchange before proceeding with the session). However, 2252 preconditions are often viewed as complicated to implement and they 2253 may add to overall session establishment delay by requiring an extra 2254 offer/answer exchange. 2256 An alternative three-way handshake can be performed by use of ICE 2257 [ICE]. When ICE is being used, and the answerer receives a STUN 2258 Binding Request for any one of the accepted media streams from the 2259 offerer, the answerer knows the offer has received his answer. At 2260 that point, the answerer knows that the offerer will be able to 2261 process incoming media according to the negotiated configuration and 2262 hence he can start sending media without the risk of the offerer 2263 either discarding it or playing garbage. 2265 Please note that, the above considerations notwithstanding, this 2266 document does not place any requirements on the offerer to process 2267 and play media before answer; it merely provides recommendations for 2268 how to ensure that media sent by the answerer and received by the 2269 offerer prior to receiving the answer, can in fact be rendered by 2270 the offerer. 2272 In some use cases a three-way handshake is not needed. An example is 2273 when the offerer does not need information from the answer, such as 2274 keying material in the SDP session description, in order to process 2275 incoming media. The SDP Capability Negotiation framework does not 2276 define any such solutions, however extensions may do so. For 2277 example, one technique proposed for best-effort SRTP in [BESRTP] is 2278 to provide different RTP payload type mappings for different 2279 transport protocols used, outside of the actual configuration, while 2280 still allowing them to be used by the answerer (exchange of keying 2281 material is still needed, e.g. inband). The basic SDP Capability 2282 Negotiation framework defined here does not include the ability to 2283 do so, however extensions that enable that may be defined. 2285 3.10. Indicating Bandwidth Usage 2287 The amount of bandwidth used for a particular media stream depends 2288 on the negotiated codecs, transport protocol and other parameters. 2289 For example use of Secure RTP [RFC3711] with integrity protection 2290 requires more bandwidth than plain RTP [RFC3551]. SDP defines the 2291 bandwidth ("b=") parameter to indicate the proposed bandwidth for 2292 the session or media stream. 2294 In SDP as defined by [RFC4566], each media description contains one 2295 transport protocol and one or more codecs. When specifying the 2296 proposed bandwidth, the worst case scenario must be taken into 2297 account, i.e., use of the highest bandwidth codec provided, the 2298 transport protocol indicated, and the worst case (bandwidth-wise) 2299 parameters that can be negotiated (e.g., a 32-bit HMAC or an 80-bit 2300 HMAC). 2302 The base SDP Capability Negotiation framework does not provide a way 2303 to negotiate bandwidth parameters. The issue thus remains, however 2304 it is potentially worse than with SDP per [RFC4566], since it is 2305 easier to negotiate additional codecs, and furthermore possible to 2306 negotiate different transport protocols. The recommended approach 2307 for addressing this is the same as for plain SDP; the worst case 2308 (now including potential configurations) needs to be taken into 2309 account when specifying the bandwidth parameters in the actual 2310 configuration. This can make the bandwidth value less accurate than 2311 in SDP per [RFC4566] (due to potential greater variability in the 2312 potential configuration bandwidth use). Extensions can be defined to 2313 address this shortcoming. 2315 The Transport Independent Application Specific Maximum (TIAS) 2316 bandwidth type as defined in [RFC3890] SHOULD NOT be used to try and 2317 alleviate bandwidth variability concerns due to different transport 2318 protocols, since there are some inconsistencies between [RFC3264] 2319 and [RFC3890]. More specifically, [RFC3264] defines the bandwidth 2320 parameter to apply to the receive direction for unicast streams, 2321 whereas [RFC3890] intends to use bandwidth in the send direction. 2322 Implementers are encouraged to look for an expected future solution 2323 to this. 2325 Note, that when using RTP retransmission [RFC4588] with the RTCP- 2326 based feedback profile [RFC4585] (RTP/AVPF), the retransmitted 2327 packets are part of the media stream bandwidth when using SSRC- 2328 multiplexing. If a feedback based protocol is offered as the actual 2329 configuration transport protocol, a non-feedback based protocol is 2330 offered as a potential configuration transport protocol and ends up 2331 being used, the actual bandwidth usage may be lower than the 2332 indicated bandwidth value in the offer (and vice versa). 2334 3.11. Dealing with Large Number of Potential Configurations 2336 When using the SDP Capability Negotiation, it is easy to generate 2337 offers that contain a large number of potential configurations. For 2338 example, in the offer: 2340 v=0 2341 o=- 25678 753849 IN IP4 192.0.2.1 2342 s= 2343 c=IN IP4 192.0.2.1 2344 t=0 0 2345 m=audio 53456 RTP/AVP 0 18 2346 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF 2347 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 2348 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 2349 FEC_ORDER=FEC_SRTP 2350 a=acap:2 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2351 a=acap:3 rtcp-fb:0 nack 2352 a=pcfg:1 t=1 a=1,3|2,3 2353 a=pcfg:2 t=2 a=1|2 2354 a=pcfg:3 t=3 a=3 2356 we have 5 potential configurations on top of the actual 2357 configuration for a single media stream. Adding an extension 2358 capability with just two alternatives for each would double that 2359 number (to 10), and doing the equivalent with two media streams 2360 would again double that number (to 20). While it is easy (and 2361 inexpensive) for the offerer to generate such offers, processing 2362 them at the answering side may not be. Consequently, it is 2363 RECOMMENDED that offerers do not create offers with unnecessarily 2364 large number of potential configurations in them. 2366 On the answering side, implementers MUST take care to avoid 2367 excessive memory and CPU consumption. For example, a naive 2368 implementation that first generates all the valid potential 2369 configuration SDP session descriptions internally, could find itself 2370 being memory exhausted, especially if it supports a large number of 2371 endpoints. Similarly, a naive implementation that simply performs 2372 iterative trial-and-error processing on each possible potential 2373 configuration SDP session description (in the preference order 2374 specified) could find itself being CPU constrained. An alternative 2375 strategy is to prune the search space first by discarding the set of 2376 offered potential configurations where the transport protocol 2377 indicated (if any) is not supported, and/or one or more mandatory 2378 attribute capabilities (if any) are either not supported or not 2379 valid. Potential configurations with unsupported mandatory extension 2380 configurations in them can be discarded as well. 2382 3.12. SDP Capability Negotiation and Intermediaries 2384 An intermediary is here defined as an entity between a SIP user 2385 agent A and a SIP user agent B, that need to perform some kind of 2386 processing on the SDP session descriptions exchanged between A and 2387 B, in order for the session establishment to operate as intended. 2388 Examples of such intermediaries include Session Border Controllers 2389 (SBCs) that may perform media relaying, Proxy Call Session Control 2390 Functions (P-CSCF) that may authorize use of a certain amount of 2391 network resources (bandwidth), etc. The presence and design of such 2392 intermediaries may not follow the "Internet" model or the SIP 2393 requirements for proxies (which are not supposed to look in message 2394 bodies such as SDP session descriptions), however they are a fact of 2395 life in some deployment scenarios and hence deserve consideration. 2397 If the intermediary needs to understand the characteristics of the 2398 media sessions being negotiated, e.g. the amount of bandwidth used 2399 or the transport protocol negotiated, then use of the SDP Capability 2400 Negotiation framework may impact them. For example, some 2401 intermediaries are known to disallow answers where the transport 2402 protocol differs from the one in the offer. Use of the SDP 2403 Capability Negotiation framework in the presence of such 2404 intermediaries could lead to session failures. Intermediaries that 2405 need to authorize use of network resources based on the negotiated 2406 media stream parameters are affected as well. If they inspect only 2407 the offer, then they may authorize parameters assuming a different 2408 transport protocol, codecs, etc. than what is actually being 2409 negotiated. For these, and other, reasons it is RECOMMENDED that 2410 implementers of intermediaries add support for the SDP Capability 2411 Negotiation framework. 2413 The SDP Capability Negotiation framework itself attempts to help out 2414 these intermediaries as well, by recommending a second offer/answer 2415 exchange when use of a potential configuration has been negotiated 2416 (see Section 3.6.3. ). However, there are several limitations with 2417 this approach. First of all, although the second offer/answer 2418 exchange is RECOMMENDED, it is not required and hence may not be 2419 performed. Secondly, the intermediary may refuse the initial answer, 2420 e.g. due to perceived transport protocol mismatch. Thirdly, the 2421 strategy is not foolproof since the offer/answer procedures 2422 [RFC3264] leave the original offer/answer exchange in effect when a 2423 subsequent one fails. Consider the following example: 2425 1. Offerer generates an SDP session description offer with the 2426 actual configuration specifying a low bandwidth configuration 2427 (e.g. plain RTP) and a potential configuration specifying a 2428 high(er) bandwidth configuration (e.g. secure RTP with 2429 integrity). 2431 2. An intermediary (e.g. an SBC or P-CSCF), that does not support 2432 SDP Capability Negotiation, authorizes the session based on the 2433 actual configuration it sees in the SDP session description. 2435 3. The answerer chooses the high(er) bandwidth potential 2436 configuration and generates an answer SDP session description 2437 based on that. 2439 4. The intermediary passes through the answer SDP session 2440 description. 2442 5. The offerer sees the accepted answer, and generates an updated 2443 offer that contains the selected potential configuration as the 2444 actual configuration. In other words, the high(er) bandwidth 2445 configuration (which has already been negotiated successfully) is 2446 now the actual configuration in the offer SDP session 2447 description. 2449 6. The intermediary sees the new offer, however it does not 2450 authorize the use of the high(er) bandwidth configuration, and 2451 consequently generates a rejection message to the offerer. 2453 7. The offerer receives the rejected offer. 2455 After step 7, per RFC 3264, the offer/answer exchange that completed 2456 in step 5 remains in effect, however the intermediary may not have 2457 authorized the necessary network resources and hence the media 2458 stream may experience quality issues. The solution to this problem 2459 is to upgrade the intermediary to support the SDP Capability 2460 Negotiation framework. 2462 3.13. Considerations for Specific Attribute Capabilities 2464 3.13.1. The rtpmap and fmtp Attributes 2466 The base SDP Capability Negotiation framework defines transport 2467 capabilities and attribute capabilities. Media capabilities, which 2468 can be used to describe media formats and their associated 2469 parameters, are not defined in this document, however the "rtpmap" 2470 and "fmtp" attributes can nevertheless be used as attribute 2471 capabilities. Using such attribute capabilities in a potential 2472 configuration requires a bit of care though. 2474 The rtpmap parameter binds an RTP payload type to a media format 2475 (e.g. codec). While it is possible to provide rtpmaps for payload 2476 types not found in the corresponding "m=" line, such rtpmaps provide 2477 no value in normal offer/answer exchanges, since only the payload 2478 types found in the "m=" line are part of the offer (or answer). This 2479 applies to the base SDP Capability Negotiation framework as well: 2480 Only the media formats (e.g. RTP payload types) provided in the "m=" 2481 line are actually offered; inclusion of rtpmap attributes with other 2482 RTP payload types in a potential configuration does not change this 2483 fact and hence they do not provide any useful information there. 2484 They may still be useful as pure capabilities though (outside a 2485 potential configuration) in order to inform a peer of additional 2486 codecs supported. 2488 It is possible to provide an rtpmap attribute capability with a 2489 payload type mapping to a different codec than a corresponding 2490 actual configuration "rtpmap" attribute for the media description 2491 has. Such practice is permissible as a way of indicating a 2492 capability. If that capability is included in a potential 2493 configuration, then delete-attributes (see Section 3.5.1. ) MUST be 2494 used to ensure that there is not multiple rtpmap attributes for the 2495 same payload type in a given media description (which would not be 2496 allowed by SDP [RFC4566]). 2498 Similar considerations and rules apply to the "fmtp" attribute. An 2499 fmtp attribute capability for a media format not included in the 2500 "m=" line is useless in a potential configuration (but may be useful 2501 as a capability by itself). An fmtp attribute capability in a 2502 potential configuration for a media format that already has an fmtp 2503 attribute in the actual configuration may lead to multiple fmtp 2504 format parameters for that media format and that is not allowed by 2505 SDP [RFC4566]. The delete-attributes MUST be used to ensure that 2506 there is not multiple fmtp attributes for a given media format in a 2507 media description. 2509 Extensions to the base SDP Capability Negotiation framework may 2510 change the above behavior. 2512 3.13.2. Direction Attributes 2514 SDP defines the "inactive", "sendonly", "recvonly", and "sendrecv" 2515 direction attributes. The direction attributes can be applied at 2516 either the session-level or the media-level. In either case, it is 2517 possible to define attribute capabilities for these direction 2518 capabilities; if used by a potential configuration, the normal 2519 offer/answer procedures still apply. For example, if an offered 2520 potential configuration includes the "sendonly" direction attribute, 2521 and it is selected as the actual configuration, then the answer MUST 2522 include a corresponding "recvonly" (or "inactive") attribute. 2524 3.14. Relationship to RFC 3407 2526 RFC 3407 defines capability descriptions with limited abilities to 2527 describe attributes, bandwidth parameters, transport protocols and 2528 media formats. RFC 3407 does not define any negotiation procedures 2529 for actually using those capability descriptions. 2531 This document defines new attributes for describing attribute 2532 capabilities and transport capabilities. It also defines procedures 2533 for using those capabilities as part of an offer/answer exchange. In 2534 contrast to RFC 3407, this document does not define bandwidth 2535 parameters, and it also does not define how to express ranges of 2536 values. Extensions to this document may be defined in order to fully 2537 cover all the capabilities provided by RFC 3407 (for example more 2538 general media capabilities). 2540 It is RECOMMENDED that implementations use the attributes and 2541 procedures defined in this document instead of those defined in 2542 [RFC3407]. If capability description interoperability with legacy 2543 RFC 3407 implementations is desired, implementations MAY include 2544 both RFC 3407 capability descriptions and capabilities defined by 2545 this document. The offer/answer negotiation procedures defined in 2546 this document will not use the RFC 3407 capability descriptions. 2548 4. Examples 2550 In this section, we provide examples showing how to use the SDP 2551 Capability Negotiation. 2553 4.1. Multiple Transport Protocols 2555 The following example illustrates how to use the SDP Capability 2556 Negotiation extensions to negotiate use of one out of several 2557 possible transport protocols. The offerer uses the expected least- 2558 common-denominator (plain RTP) as the actual configuration, and the 2559 alternative transport protocols as the potential configurations. 2561 The example is illustrated by the offer/answer exchange below, where 2562 Alice sends an offer to Bob: 2564 Alice Bob 2566 | (1) Offer (RTP/[S]AVP[F]) | 2567 |--------------------------------->| 2568 | | 2569 | (2) Answer (RTP/AVPF) | 2570 |<---------------------------------| 2571 | | 2572 | (3) Offer (RTP/AVPF) | 2573 |--------------------------------->| 2574 | | 2575 | (4) Answer (RTP/AVPF) | 2576 |<---------------------------------| 2577 | | 2579 Alice's offer includes plain RTP (RTP/AVP), RTP with RTCP-based 2580 feedback (RTP/AVPF), Secure RTP (RTP/SAVP), and Secure RTP with 2581 RTCP-based feedback (RTP/SAVPF) as alternatives. RTP is the default, 2582 with RTP/SAVPF, RTP/SAVP, and RTP/AVPF as the alternatives and 2583 preferred in the order listed: 2585 v=0 2586 o=- 25678 753849 IN IP4 192.0.2.1 2587 s= 2588 c=IN IP4 192.0.2.1 2589 t=0 0 2590 m=audio 53456 RTP/AVP 0 18 2591 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF 2592 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 2593 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 2594 FEC_ORDER=FEC_SRTP 2595 a=acap:2 rtcp-fb:0 nack 2596 a=pcfg:1 t=1 a=1,[2] 2597 a=pcfg:2 t=2 a=1 2598 a=pcfg:3 t=3 a=[2] 2600 The "m=" line indicates that Alice is offering to use plain RTP with 2601 PCMU or G.729. The capabilities are provided by the "a=tcap" and 2602 "a=acap" attributes. The "tcap" capability indicates that Secure 2603 RTP with RTCP-Based feedback (RTP/SAVPF), Secure RTP (RTP/SAVP), and 2604 RTP with RTCP-Based feedback are supported. The first "acap" 2605 attribute provides an attribute capability with a handle of 1. The 2606 capability is a "crypto" attribute, which provides the keying 2607 material for SRTP using SDP security descriptions [RFC4568]. The 2608 second "acap" attribute provides an attribute capability with a 2609 handle of 2. The capability is an "rtcp-fb" attribute, which is used 2610 by the RTCP-based feedback profiles to indicate that payload type 0 2611 (PCMU) supports feedback type "nack". The "a=pcfg" attributes 2612 provide the potential configurations included in the offer by 2613 reference to the capabilities. There are three potential 2614 configurations: 2616 o Potential configuration 1, which is the most preferred potential 2617 configuration specifies use of transport protocol capability 1 2618 (RTP/SAVPF) and attribute capabilities 1 (the "crypto" attribute) 2619 and 2 (the "rtcp-fb" attribute). Support for the first one is 2620 mandatory whereas support for the second one is optional. 2622 o Potential configuration 2, which is the second most preferred 2623 potential configuration specifies use of transport protocol 2624 capability 2 (RTP/SAVP) and mandatory attribute capability 1 (the 2625 "crypto" attribute). 2627 o Potential configuration 3, which is the least preferred potential 2628 configuration (but the second least preferred configuration 2629 overall, since the actual configuration provided by the "m=" line 2630 is always the least preferred configuration), specifies use of 2631 transport protocol capability 3 (RTP/AVPF) and optional attribute 2632 capability 2 (the "rtcp-fb" attribute). 2634 Bob receives the SDP session description offer from Alice. Bob does 2635 not support any secure RTP profiles, however he supports plain RTP 2636 and RTP with RTCP-based feedback, as well as the SDP Capability 2637 Negotiation extensions, and hence he accepts the potential 2638 configuration for RTP with RTCP-based feedback provided by Alice: 2640 v=0 2641 o=- 24351 621814 IN IP4 192.0.2.2 2642 s= 2643 c=IN IP4 192.0.2.2 2644 t=0 0 2645 m=audio 54568 RTP/AVPF 0 18 2646 a=rtcp-fb:0 nack 2647 a=acfg:1 t=3 a=[2] 2649 Bob includes the "a=acfg" attribute in the answer to inform Alice 2650 that he based his answer on an offer containing the potential 2651 configuration with transport protocol capability 3 and optional 2652 attribute capability 2 from the offer SDP session description (i.e. 2653 the RTP/AVPF profile using the "rtcp-fb" value provided). Bob also 2654 includes an "rtcp-fb" attribute with the value "nack" value for RTP 2655 payload type 0. 2657 When Alice receives Bob's answer, session negotiation has completed, 2658 however Alice nevertheless chooses to generate a new offer using the 2659 actual configuration. This is done purely to assist any 2660 intermediaries that may reside between Alice and Bob but do not 2661 support the SDP Capability Negotiation framework (and hence may not 2662 understand the negotiation that just took place): 2664 Alice's updated offer includes only RTP/AVPF, and it is not using 2665 the SDP Capability Negotiation framework (Alice could have included 2666 the capabilities as well if she wanted to): 2668 v=0 2669 o=- 25678 753850 IN IP4 192.0.2.1 2670 s= 2671 c=IN IP4 192.0.2.1 2672 t=0 0 2673 m=audio 53456 RTP/AVPF 0 18 2674 a=rtcp-fb:0 nack 2676 The "m=" line now indicates that Alice is offering to use RTP with 2677 RTCP-based feedback and using PCMU or G.729. The "rtcp-fb" 2678 attribute provides the feedback type "nack" for payload type 0 again 2679 (but as part of the actual configuration). 2681 Bob receives the SDP session description offer from Alice, which he 2682 accepts, and then generates an answer to Alice: 2684 v=0 2685 o=- 24351 621815 IN IP4 192.0.2.2 2686 s= 2687 c=IN IP4 192.0.2.2 2688 t=0 0 2689 m=audio 54568 RTP/AVPF 0 18 2690 a=rtcp-fb:0 nack 2692 Bob includes the same "rtcp-fb" attribute as before, and the session 2693 proceeds without change. Although Bob did not include any 2694 capabilities in his answer, he could have done so if he wanted to. 2696 Note that in this particular example, the answerer supported the SDP 2697 Capability Negotiation framework and hence the attributes and 2698 procedures defined here, however had he not, the answerer would 2699 simply have ignored the new attributes received in step 1 and 2700 accepted the offer to use normal RTP. In that case, the following 2701 answer would have been generated in step 2 instead: 2703 v=0 2704 o=- 24351 621814 IN IP4 192.0.2.2 2705 s= 2706 c=IN IP4 192.0.2.2 2707 t=0 0 2708 m=audio 54568 RTP/AVP 0 18 2710 4.2. DTLS-SRTP or SRTP with Media Level Security Descriptions 2712 The following example illustrates how to use the SDP Capability 2713 Negotiation framework to negotiate use of SRTP using either SDP 2714 Security Descriptions or DTLS-SRTP. The offerer (Alice) wants to 2715 establish a secure RTP audio stream but is willing to use plain RTP. 2716 Alice prefers to use DTLS-SRTP as the key management protocol, but 2717 supports SDP security descriptions as well (note that [DTLS-SRTP- 2718 FRAMEWORK] contains additional DTLS-SRTP examples). 2720 The example is illustrated by the offer/answer exchange below, where 2721 Alice sends an offer to Bob: 2723 Alice Bob 2725 | (1) Offer (RTP/[S]AVP,SDES | DTLS-SRTP)| 2726 |--------------------------------------->| 2727 | | 2728 |<--------- DTLS-SRTP handshake -------->| 2729 | | 2730 | (2) Answer (DTLS-SRTP) | 2731 |<---------------------------------------| 2732 | | 2733 | (3) Offer (DTLS-SRTP) | 2734 |--------------------------------------->| 2735 | | 2736 | (4) Answer (DTLS-SRTP) | 2737 |<---------------------------------------| 2738 | | 2740 Alice's offer includes an audio stream which offers use of plain RTP 2741 and secure RTP as alternatives. For the secure RTP stream, it can be 2742 established using either DTLS-SRTP or SDP Security Descriptions: 2744 v=0 2745 o=- 25678 753849 IN IP4 192.0.2.1 2746 s= 2747 t=0 0 2748 c=IN IP4 192.0.2.1 2749 a=acap:1 setup:actpass 2750 a=acap:2 fingerprint: SHA-1 \ 2751 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2752 a=tcap:1 UDP/TLS/RTP/SAVP RTP/SAVP 2753 m=audio 59000 RTP/AVP 98 2754 a=rtpmap:98 AMR/8000 2755 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_32 2756 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2757 a=pcfg:1 t=1 a=1,2 2758 a=pcfg:2 t=2 a=3 2760 The first (and preferred) potential configuration for the audio 2761 stream specifies use of transport capability 1 (UDP/TLS/RTP/SAVP), 2762 i.e. DTLS-SRTP, and attribute capabilities 1 and 2 (active/passive 2763 mode and certificate fingerprint), both of which must be supported 2764 to choose this potential configuration. The second (and less 2765 preferred) potential configuration specifies use of transport 2766 capability 2 (RTP/SAVP) and mandatory attribute capability 3, i.e. 2767 the SDP security description. 2769 Bob receives the SDP session description offer from Alice. Bob 2770 supports DTLS-SRTP as preferred by Alice and Bob now initiates the 2771 DTLS-SRTP handshake to establish the DTLS-SRTP session (see [DTLS- 2772 SRTP] for details). 2774 Bob also sends back an answer to Alice as follows: 2776 v=0 2777 o=- 24351 621814 IN IP4 192.0.2.2 2778 s= 2779 a=setup:active 2780 a=fingerprint: SHA-1 \ 2781 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2782 t=0 0 2783 c=IN IP4 192.0.2.2 2784 m=audio 54568 UDP/TLS/RTP/SAVP 98 2785 a=rtpmap:98 AMR/8000 2786 a=acfg:1 t=1 a=1,2 2788 For the audio stream, Bob accepted the use of DTLS-SRTP, and hence 2789 the profile in the "m=" line is "UDP/TLS/RTP/SAVP". Bob also includes 2790 a "setup:active" attribute to indicate he is the active endpoint for 2791 the DTLS-SRTP session as well as the fingerprint for Bob's 2792 certificate. Bob's "acfg" attribute indicates that he chose potential 2793 configuration 1 from Alice's offer. 2795 When Alice receives Bob's answer, session negotiation has completed 2796 (and Alice can verify the DTLS handshake using Bob's certificate 2797 fingerprint in the answer), however Alice nevertheless chooses to 2798 generate a new offer using the actual configuration. This is done 2799 purely to assist any intermediaries that may reside between Alice 2800 and Bob but do not support the capability negotiation extensions 2801 (and hence may not understand the negotiation that just took place): 2803 Alice's updated offer includes only DTLS-SRTP for the audio stream, 2804 and it is not using the SDP Capability Negotiation framework (Alice 2805 could have included the capabilities as well if she wanted to): 2807 v=0 2808 o=- 25678 753850 IN IP4 192.0.2.1 2809 s= 2810 t=0 0 2811 c=IN IP4 192.0.2.1 2812 a=setup:actpass 2813 a=fingerprint: SHA-1 \ 2814 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2815 m=audio 59000 UDP/TLS/RTP/AVP 98 2816 a=rtpmap:98 AMR/8000 2818 The "m=" line for the audio stream now indicates that Alice is 2819 offering to use DTLS-SRTP in active/passive mode using her 2820 certificate fingerprint provided. 2822 Bob receives the SDP session description offer from Alice, which he 2823 accepts, and then generates an answer to Alice: 2825 v=0 2826 o=- 24351 621814 IN IP4 192.0.2.2 2827 s= 2828 a=setup:active 2829 a=fingerprint: SHA-1 \ 2830 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2831 t=0 0 2832 c=IN IP4 192.0.2.2 2833 m=audio 54568 UDP/TLS/RTP/SAVP 98 2834 a=rtpmap:98 AMR/8000 2835 a=acfg:1 t=1 a=1,2 2837 Bob includes the same "setup:active" and fingerprint attributes as 2838 before, and the session proceeds without change. Although Bob did 2839 not include any capabilities in his answer, he could have done so if 2840 he wanted to. 2842 Note that in this particular example, the answerer supported the 2843 capability extensions defined here, however had he not, the answerer 2844 would simply have ignored the new attributes received in step 1 and 2845 accepted the offer to use normal RTP. In that case, the following 2846 answer would have been generated in step 2 instead: 2848 v=0 2849 o=- 24351 621814 IN IP4 192.0.2.2 2850 s= 2851 t=0 0 2852 c=IN IP4 192.0.2.2 2853 m=audio 54568 RTP/AVP 98 2854 a=rtpmap:98 AMR/8000 2856 Finally, if Bob had chosen to use SDP Security Descriptions instead 2857 of DTLS-SRTP, the following answer would have been generated: 2859 v=0 2860 o=- 24351 621814 IN IP4 192.0.2.2 2861 s= 2862 t=0 0 2863 c=IN IP4 192.0.2.2 2864 m=audio 54568 RTP/SAVP 98 2865 a=rtpmap:98 AMR/8000 2866 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2867 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 2868 a=acfg:2 t=2 a=3 2870 4.3. Best-Effort SRTP with Session-Level MIKEY and Media Level Security 2871 Descriptions 2873 The following example illustrates how to use the SDP Capability 2874 Negotiation extensions to support so-called Best-Effort Secure RTP 2875 as well as alternative keying mechanisms, more specifically MIKEY 2876 [RFC3830] and SDP Security Descriptions. The offerer (Alice) wants 2877 to establish an audio and video session. Alice prefers to use 2878 session-level MIKEY as the key management protocol, but supports SDP 2879 security descriptions as well. 2881 The example is illustrated by the offer/answer exchange below, where 2882 Alice sends an offer to Bob: 2884 Alice Bob 2886 | (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) | 2887 |--------------------------------------->| 2888 | | 2889 | (2) Answer (RTP/SAVP, SDES) | 2890 |<---------------------------------------| 2891 | | 2892 | (3) Offer (RTP/SAVP, SDES) | 2893 |--------------------------------------->| 2894 | | 2895 | (4) Answer (RTP/SAVP, SDES) | 2896 |<---------------------------------------| 2897 | | 2899 Alice's offer includes an audio and a video stream. The audio stream 2900 offers use of plain RTP and secure RTP as alternatives, whereas the 2901 video stream offers use of plain RTP, RTP with RTCP-based feedback, 2902 Secure RTP, and Secure RTP with RTCP-based feedback as alternatives: 2904 v=0 2905 o=- 25678 753849 IN IP4 192.0.2.1 2906 s= 2907 t=0 0 2908 c=IN IP4 192.0.2.1 2909 a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2910 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF 2911 m=audio 59000 RTP/AVP 98 2912 a=rtpmap:98 AMR/8000 2913 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32 2914 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2915 a=pcfg:1 t=2 a=1|2 2916 m=video 52000 RTP/AVP 31 2917 a=rtpmap:31 H261/90000 2918 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 2919 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2920 a=acap:4 rtcp-fb:* nack 2921 a=pcfg:1 t=1 a=1,4|3,4 2922 a=pcfg:2 t=2 a=1|3 2923 a=pcfg:3 t=3 a=4 2925 The potential configuration for the audio stream specifies use of 2926 transport capability 2 (RTP/SAVP) and either attribute capability 1 2927 (session-level MIKEY as the keying mechanism) or 2 (SDP Security 2928 Descriptions as the keying mechanism). Support for either of these 2929 attribute capabilities is mandatory. There are three potential 2930 configurations for the video stream. 2932 o The first configuration with configuration number 1 uses 2933 transport capability 1 (RTP/SAVPF) with either attribute 2934 capabilities 1 and 4 (session-level MIKEY and the "rtcp-fb" 2935 attribute) or attribute capabilities 3 and 4 (SDP security 2936 descriptions and the "rtcp-fb" attribute). In this example, the 2937 offerer insists on not only the keying mechanism being supported, 2938 but also that the "rtcp-fb" attribute is supported with the value 2939 indicated. Consequently, all the attribute capabilities are 2940 marked as mandatory in this potential configuration. 2942 o The second configuration with configuration number 2 uses 2943 transport capability 2 (RTP/SAVP) and either attribute capability 2944 1 (session-level MIKEY) or attribute capability 3 (SDP security 2945 descriptions). Both attribute capabilities are mandatory in this 2946 configuration. 2948 o The third configuration with configuration number 3 uses 2949 transport capability 3 (RTP/AVPF) and mandatory attribute 2950 capability 4 (the "rtcp-fb" attribute). 2952 Bob receives the SDP session description offer from Alice. Bob 2953 supports Secure RTP, Secure RTP with RTCP-based feedback and the SDP 2954 Capability Negotiation extensions. Bob also supports SDP Security 2955 Descriptions, but not MIKEY, and hence he generates the following 2956 answer: 2958 v=0 2959 o=- 24351 621814 IN IP4 192.0.2.2 2960 s= 2961 t=0 0 2962 c=IN IP4 192.0.2.2 2963 m=audio 54568 RTP/SAVP 98 2964 a=rtpmap:98 AMR/8000 2965 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2966 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 2967 a=acfg:1 t=2 a=2 2968 m=video 55468 RTP/SAVPF 31 2969 a=rtpmap:31 H261/90000 2970 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2971 inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32 2972 a=rtcp-fb:* nack 2973 a=acfg:1 t=1 a=3,4 2975 For the audio stream, Bob accepted the use of secure RTP, and hence 2976 the profile in the "m=" line is "RTP/SAVP". Bob also includes a 2977 "crypto" attribute with his own keying material, and an "acfg" 2978 attribute identifying actual configuration 1 for the audio media 2979 stream from the offer, using transport capability 2 (RTP/SAVP) and 2980 attribute capability 2 (the crypto attribute from the offer). For 2981 the video stream, Bob accepted the use of secure RTP with RTCP-based 2982 feedback, and hence the profile in the "m=" line is "RTP/SAVPF". Bob 2983 also includes a "crypto" attribute with his own keying material, and 2984 an "acfg" attribute identifying actual configuration 1 for the video 2985 stream from the offer, using transport capability 1 (RTP/SAVPF) and 2986 attribute capabilities 3 (the crypto attribute from the offer) and 4 2987 (the "rtcp-fb" attribute from the offer). 2989 When Alice receives Bob's answer, session negotiation has completed, 2990 however Alice nevertheless chooses to generate a new offer using the 2991 actual configuration. This is done purely to assist any 2992 intermediaries that may reside between Alice and Bob but do not 2993 support the capability negotiation extensions (and hence may not 2994 understand the negotiation that just took place): 2996 Alice's updated offer includes only SRTP for the audio stream SRTP 2997 with RTCP-based feedback for the video stream, and it is not using 2998 the SDP Capability Negotiation framework (Alice could have included 2999 the capabilities as well is she wanted to): 3001 v=0 3002 o=- 25678 753850 IN IP4 192.0.2.1 3003 s= 3004 t=0 0 3005 c=IN IP4 192.0.2.1 3006 m=audio 59000 RTP/SAVP 98 3007 a=rtpmap:98 AMR/8000 3008 a=crypto:1 AES_CM_128_HMAC_SHA1_32 3009 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 3010 m=video 52000 RTP/SAVPF 31 3011 a=rtpmap:31 H261/90000 3012 a=crypto:1 AES_CM_128_HMAC_SHA1_80 3013 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 3014 a=rtcp-fb:* nack 3016 The "m=" line for the audio stream now indicates that Alice is 3017 offering to use secure RTP with PCMU or G.729, whereas the "m=" line 3018 for the video stream indicates that Alice is offering to use secure 3019 RTP with RTCP-based feedback and H.261. Each media stream includes a 3020 "crypto" attribute, which provides the SRTP keying material, with 3021 the same value again. 3023 Bob receives the SDP session description offer from Alice, which he 3024 accepts, and then generates an answer to Alice: 3026 v=0 3027 o=- 24351 621815 IN IP4 192.0.2.2 3028 s= 3029 t=0 0 3030 c=IN IP4 192.0.2.2 3031 m=audio 54568 RTP/SAVP 98 3032 a=rtpmap:98 AMR/8000 3033 a=crypto:1 AES_CM_128_HMAC_SHA1_32 3034 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 3035 m=video 55468 RTP/SAVPF 31 3036 a=rtpmap:31 H261/90000 3037 a=crypto:1 AES_CM_128_HMAC_SHA1_80 3038 inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32 3039 a=rtcp-fb:* nack 3041 Bob includes the same crypto attribute as before, and the session 3042 proceeds without change. Although Bob did not include any 3043 capabilities in his answer, he could have done so if he wanted to. 3045 Note that in this particular example, the answerer supported the 3046 capability extensions defined here, however had he not, the answerer 3047 would simply have ignored the new attributes received in step 1 and 3048 accepted the offer to use normal RTP. In that case, the following 3049 answer would have been generated in step 2 instead: 3051 v=0 3052 o=- 24351 621814 IN IP4 192.0.2.2 3053 s= 3054 t=0 0 3055 c=IN IP4 192.0.2.2 3056 m=audio 54568 RTP/AVP 98 3057 a=rtpmap:98 AMR/8000 3058 m=video 55468 RTP/AVP 31 3059 a=rtpmap:31 H261/90000 3060 a=rtcp-fb:* nack 3062 Finally, if Bob had chosen to use session-level MIKEY instead of SDP 3063 security descriptions, the following answer would have been 3064 generated: 3066 v=0 3067 o=- 24351 621814 IN IP4 192.0.2.2 3068 s= 3069 t=0 0 3070 c=IN IP4 192.0.2.2 3071 a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyO... 3072 m=audio 54568 RTP/SAVP 98 3073 a=rtpmap:98 AMR/8000 3074 a=acfg:1 t=2 a=1 3075 m=video 55468 RTP/SAVPF 31 3076 a=rtpmap:31 H261/90000 3077 a=rtcp-fb:* nack 3078 a=acfg:1 t=1 a=1,4 3080 It should be noted, that although Bob could have chosen session- 3081 level MIKEY for one media stream, and SDP Security Descriptions for 3082 another media stream, there are no well-defined offerer processing 3083 rules of the resulting answer for this, and hence the offerer may 3084 incorrectly assume use of MIKEY for both streams. To avoid this, if 3085 the answerer chooses session-level MIKEY, then all secure RTP based 3086 media streams SHOULD use MIKEY (this applies irrespective of whether 3087 SDP Capability Negotiation is being used or not). Use of media-level 3088 MIKEY does not have a similar constraint. 3090 4.4. SRTP with Session-Level MIKEY and Media Level Security 3091 Descriptions as Alternatives 3093 The following example illustrates how to use the SDP Capability 3094 Negotiation framework to negotiate use of either MIKEY or SDP 3095 Security Descriptions, when one of them is included as part of the 3096 actual configuration, and the other one is being selected. The 3097 offerer (Alice) wants to establish an audio and video session. Alice 3098 prefers to use session-level MIKEY as the key management protocol, 3099 but supports SDP security descriptions as well. 3101 The example is illustrated by the offer/answer exchange below, where 3102 Alice sends an offer to Bob: 3104 Alice Bob 3106 | (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) | 3107 |--------------------------------------->| 3108 | | 3109 | (2) Answer (RTP/SAVP, SDES) | 3110 |<---------------------------------------| 3111 | | 3113 Alice's offer includes an audio and a video stream. Both the audio 3114 and the video stream offer use of secure RTP: 3116 v=0 3117 o=- 25678 753849 IN IP4 192.0.2.1 3118 s= 3119 t=0 0 3120 c=IN IP4 192.0.2.1 3121 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 3122 m=audio 59000 RTP/SAVP 98 3123 a=rtpmap:98 AMR/8000 3124 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 3125 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 3126 a=pcfg:1 a=-s:1 3127 m=video 52000 RTP/SAVP 31 3128 a=rtpmap:31 H261/90000 3129 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_80 3130 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 3131 a=pcfg:1 a=-s:2 3133 Alice does not know whether Bob supports MIKEY or SDP Security 3134 Descriptions. She could include attributes for both, however the 3135 resulting procedures and potential interactions are not well- 3136 defined. Instead, she places a session-level key-mgmt attribute for 3137 MIKEY in the actual configuration with SDP security descriptions as 3138 an alternative in the potential configuration. The potential 3139 configuration for the audio stream specifies that all session level 3140 attributes are to be deleted (i.e. the session-level "a=key-mgmt" 3141 attribute) and that mandatory attribute capability 2 is to be used 3142 (i.e. the crypto attribute). The potential configuration for the 3143 video stream is similar, except it uses its own mandatory crypto 3144 attribute capability (2). Note how deletion of the session-level 3145 attributes does not affect the media-level attributes. 3147 Bob receives the SDP session description offer from Alice. Bob 3148 supports Secure RTP and the SDP Capability Negotiation framework. 3149 Bob also supports both SDP Security Descriptions and MIKEY. Since 3150 the potential configuration is more preferred than the actual 3151 configuration, Bob (conceptually) generates an internal potential 3152 configuration SDP session description that contains the crypto 3153 attributes for the audio and video stream, but not the key-mgmt 3154 attribute for MIKEY, thereby avoiding any ambiguity between the two 3155 keying mechanisms. As a result, he generates the following answer: 3157 v=0 3158 o=- 24351 621814 IN IP4 192.0.2.2 3159 s= 3160 t=0 0 3161 c=IN IP4 192.0.2.2 3162 m=audio 54568 RTP/SAVP 98 3163 a=rtpmap:98 AMR/8000 3164 a=crypto:1 AES_CM_128_HMAC_SHA1_32 3165 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 3166 a=acfg:1 a=-s:1 3167 m=video 55468 RTP/SAVP 31 3168 a=rtpmap:31 H261/90000 3169 a=crypto:1 AES_CM_128_HMAC_SHA1_80 3170 inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32 3171 a=acfg:1 a=-s:2 3173 For the audio stream, Bob accepted the use of secure RTP using SDP 3174 security descriptions. Bob therefore includes a "crypto" attribute 3175 with his own keying material, and an "acfg" attribute identifying 3176 actual configuration 1 for the audio media stream from the offer, 3177 with the delete-attributes ("-s") and attribute capability 1 (the 3178 crypto attribute from the offer). For the video stream, Bob also 3179 accepted the use of secure RTP using SDP security descriptions. Bob 3180 therefore includes a "crypto" attribute with his own keying 3181 material, and an "acfg" attribute identifying actual configuration 1 3182 for the video stream from the offer, with the delete-attributes ("- 3183 s") and attribute capability 2. 3185 Below, we illustrate the offer SDP session description, when Bob 3186 instead offers the "crypto" attribute as the actual configuration 3187 keying mechanism and "key-mgmt" as the potential configuration: 3189 v=0 3190 o=- 25678 753849 IN IP4 192.0.2.1 3191 s= 3192 t=0 0 3193 c=IN IP4 192.0.2.1 3194 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 answerer, 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: 3379 -- replace RFCXXXX by this RFC number 3380 Contact name: Flemming Andreasen, fandreas@cisco.com 3382 Attribute name: acap 3383 Long form name: Attribute capability 3384 Type of attribute: Session-level and media-level 3385 Subject to charset: No 3386 Purpose: Attribute capability containing an attribute 3387 name and associated value 3388 Appropriate values: See Section 3.4.1. of RFCXXXX 3389 -- Note to RFC editor: 3390 -- replace RFCXXXX by this RFC number 3391 Contact name: Flemming Andreasen, fandreas@cisco.com 3393 Attribute name: tcap 3394 Long form name: Transport Protocol Capability 3395 Type of attribute: Session-level and media-level 3396 Subject to charset: No 3397 Purpose: Transport protocol capability listing one or 3398 more transport protocols 3399 Appropriate values: See Section 3.4.2. of RFCXXXX 3400 -- Note to RFC editor: 3401 -- replace RFCXXXX by this RFC number 3402 Contact name: Flemming Andreasen, fandreas@cisco.com 3404 Attribute name: pcfg 3405 Long form name: Potential Configuration 3406 Type of attribute: Media-level 3407 Subject to charset: No 3408 Purpose: Potential configuration for SDP capability 3409 negotiation 3410 Appropriate values: See Section 3.5.1. of RFCXXXX 3411 -- Note to RFC editor: 3412 -- replace RFCXXXX by this RFC number 3413 Contact name: Flemming Andreasen, fandreas@cisco.com 3415 Attribute name: acfg 3416 Long form name: Actual configuration 3417 Type of attribute: Media-level 3418 Subject to charset: No 3419 Purpose: Actual configuration for SDP capability 3420 negotiation 3421 Appropriate values: See Section 3.5.2. of RFCXXXX 3422 -- Note to RFC editor: 3423 -- replace RFCXXXX by this RFC number 3424 Contact name: Flemming Andreasen, fandreas@cisco.com 3426 6.2. New SDP Capability Negotiation Option Tag Registry 3428 The IANA is hereby requested to create a new SDP Capability 3429 Negotiation Option Tag registry. An IANA SDP Capability Negotiation 3430 option tag registration MUST be documented in an RFC in accordance 3431 with the [RFC5226] IETF Review policy. The RFC MUST provide the name 3432 of the option tag, a syntax and a semantic specification of any new 3433 SDP attributes and any extensions to the potential configuration 3434 ("a=pcfg") and actual configuration ("a=acfg") attributes provided 3435 in this document. If the extension defines any new SDP attributes 3436 that are intended to be capabilities for use by the capability 3437 negotiation framework (similar to e.g. "a=acap"), those capabilities 3438 MUST adhere to the guidelines provided in Section 3.4.3. Extensions 3439 to the potential and actual configuration attributes MUST adhere to 3440 the syntax provided in Section 3.5.1. and 3.5.2. 3442 The option tag "cap-v0" is defined in this document and the IANA is 3443 hereby requested to register this option tag. 3445 6.3. New SDP Capability Negotiation Potential Configuration Parameter 3446 Registry 3448 The IANA is hereby requested to create a new SDP Capability 3449 Negotiation Potential Configuration Parameter registry. An IANA SDP 3450 Capability Negotiation potential configuration registration MUST be 3451 documented in an RFC in accordance with the [RFC5226] IETF Review 3452 policy. The RFC MUST define the syntax and semantics of each new 3453 potential configuration parameter. The syntax MUST adhere to the 3454 syntax provided for extensions in Section 3.5.1. and the semantics 3455 MUST adhere to the semantics provided for extensions in Section 3456 3.5.1. and 3.5.2. Associated with each registration MUST be the 3457 encoding name for the parameter as well as a short descriptive name 3458 for it. 3460 The potential configuration parameters "a" for "attribute" and "t" 3461 for "transport protocol" are defined in this document and the IANA 3462 is hereby requested to register these. 3464 7. Acknowledgments 3466 The SDP Capability Negotiation solution defined in this document 3467 draws on the overall capability negotiation framework that was 3468 defined by [SDPng]. Also, the SDP Capability Negotiation solution is 3469 heavily influenced by the discussions and work done by the SDP 3470 Capability Negotiation Design Team. The following people in 3471 particular provided useful comments and suggestions to either the 3472 document itself or the overall direction of the solution defined in 3473 here: Francois Audet, John Elwell, Roni Even, Miguel Garcia, Robert 3474 Gilman, Cullen Jennings, Jonathan Lennox, Matt Lepinski, Jean- 3475 Francois Mule, Joerg Ott, Colin Perkins, Jonathan Rosenberg, Thomas 3476 Stach, and Dan Wing. 3478 General Area review comments were provided by Christian Vogt, and 3479 Stephen Kent provided Security Directorate review comments. Eric 3480 Rescorla provided textual input to the Security Considerations. 3481 Alexey Melnikov, Robert Sparks, and Magnus Westerlund provided 3482 several review comments as well. 3484 8. Change Log 3486 8.1. draft-ietf-mmusic-sdp-capability-negotiation-13 3488 o Clarified that unsupported media-level attributes in session- 3489 level attribute capabilities do not trigger an "invalid" 3490 potential configuration, since such attributes will be ignored 3491 per normal SDP rules. 3493 o Clarified text in Section 3.6.1. to more clearly distinguish 3494 between transport protocols and transport protocol capabilities. 3496 o A couple of editorial nit fixes 3498 8.2. draft-ietf-mmusic-sdp-capability-negotiation-12 3500 Addressing IESG review comments as follows: 3502 o Clarified processing rules for "creq" in Section 3.3.2. 3504 o Removed "iptv_rtsp" example in Section 3.4.2. 3506 o Fixed ABNF error in "attribute-config-list". 3508 o Changed ICE [ICE] reference from informative to normative. 3510 o Minor editorial changes. 3512 8.3. draft-ietf-mmusic-sdp-capability-negotiation-11 3514 Addressing IESG review comments as follows: 3516 o Changed att-cap-num and trpr-cap-num ABNF rules throughout to 3517 allow for no more than 10 digits. 3519 o Disallowed base framework only implementations from generating 3520 media-level attribute capabilities at the session-level, and 3521 added explicit rules for how to process them if received. 3523 o Disallowed attribute capabilities from embedding capability 3524 negotiation parameters and discouraged extension capabilities 3525 from similar behavior. Also specified non-recursive processing of 3526 capabilities on the receive side as a safeguard. 3528 o Clarified that the "tcap" attribute specifies only the transport 3529 protocol, however some MIME types can be viewed as transports as 3530 well. The base framework does not define how to negotiate those 3531 as transports, but rather only as media formats that must be 3532 valid under the transport protocol for the media description. 3534 o Changed definition (and ABNF) for attribute-config-list to allow 3535 for only delete-attributes (i.e., no attribute capabilities) 3537 o Clarified that playout of early media before answer is not a 3538 requirement. 3540 o Clarified various offer/answer aspects related to generation of 3541 potential configuration offer SDP session descriptions and 3542 virtual answer SDP session descriptions as well as operation of 3543 delete-attributes. 3545 o Defined the notion of a "valid" actual configuration and how it 3546 affects offerer processing of the answer. 3548 o Removed recommendation to use the TIAS bandwidth type [RFC3890] 3549 and added note explaining why it should not be used. 3551 o Changed IANA rules for new option tags and potential 3552 configuration parameters to follow "IETF Review" policy, and 3553 clarified that potential configuration parameters must be 3554 registered with IANA. 3556 o Changed numerous instances of "SDP" with the more accurate "SDP 3557 session description" to avoid terminology overload. 3559 o Various editorial clarifications throughout. 3561 8.4. draft-ietf-mmusic-sdp-capability-negotiation-10 3563 Addressing General Area and Security Directorate review comments as 3564 follows: 3566 o Explained and motivated the preference order between potential 3567 and actual configurations earlier in the document. 3569 o Added DTLS-SRTP example use in several places, as well as a new 3570 example call flow for DTLS-SRTP. 3572 o Added that interacting session-level attributes in potential 3573 configurations, which do not provide well-defined operation on 3574 the receiving side, cannot be used in security critical contexts. 3576 o Updated Security Considerations section. 3578 o Rephrased several sentences containing the word "only" to improve 3579 readability. 3581 o Minor editorial nit fixes, especially in the example call flows. 3583 8.5. draft-ietf-mmusic-sdp-capability-negotiation-09 3585 Incorporated Working Group Chair review comments and a few additional 3586 comments as follows: 3588 o Clarified that the "a=creq" attribute MUST NOT be used in an 3589 answer (Section 3.6.2. ). 3591 o Various editorial changes throughout. 3593 8.6. draft-ietf-mmusic-sdp-capability-negotiation-08 3595 Incorporated Working Group Last Call comments as follows: 3597 o Added second offer/answer exchange to introductory example, fixed 3598 minor error in that example, and deleted similar example in the 3599 Examples Section. 3601 o Fixed "type=value" semantic error in the attribute capability 3602 definition. 3604 o Clarified that consecutive numbering of capabilities and 3605 potential configurations is not required. 3607 o Fixed inconsistency for which parameters to include in the "acfg" 3608 attribute. 3610 o Changed second offer/answer exchange from MAY to SHOULD strength. 3612 o Clarified there should be a combined second offer/exchange when 3613 using ICE. 3615 o Moved RFC 3407 to informative references. 3617 o Various editorial clarifications. 3619 8.7. draft-ietf-mmusic-sdp-capability-negotiation-07 3621 o Removed the ability to have attribute capabilities provide 3622 attribute names without values, when those attributes otherwise 3623 require an associated value. 3625 o Document no longer obsoletes RFC 3407 but instead recommends that 3626 it is being used instead of RFC 3407. 3628 o Added ability to specific that specific extensions in a potential 3629 configuration are mandatory. 3631 o Changed ABNF for extension-config-list in potential 3632 configurations. 3634 o Removed the redundant "a=" part of attribute capabilities. 3636 o Clarified what it means to support an attribute capability in the 3637 offer/answer procedures. 3639 o Changed "a=acap" attribute and offer/answer procedures to include 3640 only the known and supported attribute capabilities. 3642 o Added new section on indicating bandwidth usage. 3644 8.8. draft-ietf-mmusic-sdp-capability-negotiation-06 3646 o Added additional background text on terminology used, and a new 3647 section on the negotiation model. 3649 o Allowed for session-level attribute capabilities to contain 3650 media-level only attributes, albeit the base framework does not 3651 define (or allow) them to be used in a potential configuration 3652 (extensions may change that) 3654 o Disallowing multiple "a=tcap" attributes at the session-level 3655 and/or on a per media description basis; at most one at the 3656 session-level and per media description now. 3658 o Changed the "a=pcfg" attribute to make a potential configuration 3659 list optional in order to allow for the actual configuration to 3660 be referenced. 3662 o Removed the ability to delete and replace individual attributes 3663 from the actual configuration SDP session description. 3665 o Introduced the notion of mandatory and optional attribute 3666 capabilities in a potential configuration and updated the 3667 "a=pcfg" attribute and associated procedures accordingly. 3669 o Specified that mandatory attribute capabilities and the transport 3670 protocol (if any) from a potential configuration need to be 3671 supported in order to select that potential configuration. 3672 Offer/answer procedures updated accordingly as well. 3674 o Noted potential interaction and synchronization issues with use 3675 of session-level attributes and attribute capabilities and added 3676 recommendation to avoid use of session-level attributes when 3677 possible. 3679 o Fixed error in "a=acfg" grammar (missing config-number) and 3680 updated attribute definition in accordance with the "a=pcfg" 3681 attribute changes. 3683 o Updated text associated with processing media before answer to 3684 allow for playing out garbage or discard until answer received. 3685 Additional detail on alternative solutions provided as well. 3687 o Added recommendation to send back answer SDP session description 3688 as soon as possible, when a potential configuration different 3689 from the actual configuration has been chosen. 3691 o Added new section on interactions with SIP option tags. 3693 o Added new section on dealing with large number of potential 3694 configurations. 3696 o Added new section on SDP capability negotiation and 3697 intermediaries. 3699 o Updated examples in accordance with other changes and to 3700 illustrate use of mandatory and optional attribute capabilities 3701 in a potential configuration. 3703 o Updated security considerations to address potential denial of 3704 service attack caused by large number of potential 3705 configurations. 3707 o Various editorial updates throughout. 3709 8.9. draft-ietf-mmusic-sdp-capability-negotiation-05 3711 o Allowed for '=' attributes to be listed as attribute 3712 capabilities the attribute name only. 3714 o Changed IP-address to conform to RFC 3330 guidelines. 3716 o Added section on relationship to RFC 3407 and "Obsoletes: 3407" 3717 in the front. 3719 o Disallowed use of white space in a number of places for more 3720 consistency with existing SDP practice 3722 o Changed "csup" and "creq" attributes to not allow multiple 3723 instances at the session-level and multiple instances per media 3724 description (only one for each now) 3726 o Changed to not require use of "creq" with base option tag ("cap- 3727 v0"). 3729 o Relaxed restrictions on extension capabilities 3731 o Updated potential configuration attribute syntax and semantics. 3732 In particular, potential configuration attributes can now replace 3733 and delete various existing attributes in original SDP session 3734 descriptions to better control potential attribute interactions 3735 with the actual configuration while preserving message size 3736 efficiency. 3738 o Updated actual configuration attribute to align with the updates 3739 to the potential configuration attributes. 3741 o Updated offer/answer procedures to align with other changes. 3743 o Changed recommendation for second offer/answer exchange to "MAY" 3744 strength, unless for the cases where it is known or suspected 3745 that it is needed. 3747 o Updated ICE interactions to explain how the new attribute 3748 delete/replace features can solve certain potential interactions. 3750 o Updated rtpmap and fmtp section to allow potential configurations 3751 to use remapped payload types in attribute capabilities for 3752 rtpmaps and fmtp parameters. 3754 o Added section on direction attributes. 3756 o Added another example showing SRTP with session-level MIKEY and 3757 SDP Security Descriptions using the attribute capability DELETE 3758 operator. 3760 8.10. draft-ietf-mmusic-sdp-capability-negotiation-04 3762 The following are the major changes compared to version -03: 3764 o Added explicit ordering rules for attributes added by potential 3765 configurations. 3767 o Noted that ICE interaction issues (ice-tcp specifically) may not 3768 be as clear as originally thought. 3770 o Added considerations on using rtpmap and fmtp attributes as 3771 attribute capabilities. 3773 o Added multiple transport protocol example. 3775 o Added session-level MIKEY and media level security descriptions 3776 example. 3778 8.11. draft-ietf-mmusic-sdp-capability-negotiation-03 3780 The following are the major changes compared to version -02: 3782 o Base option tag name changed from "v0" to "cap-v0". 3784 o Added new section on extension capability attributes 3786 o Firmed up offer/answer procedures. 3788 o Added security considerations 3789 o Added IANA considerations 3791 8.12. draft-ietf-mmusic-sdp-capability-negotiation-02 3793 The following are the major changes compared to version -01: 3795 o Potential configurations are no longer allowed at the session 3796 level 3798 o Renamed capability attributes ("capar" to "acap" and "ctrpr" to 3799 "tcap") 3801 o Changed name and semantics of the initial number (now called 3802 configuration number) in potential configuration attributes; must 3803 now be unique and can be used as a handle 3805 o Actual configuration attribute now includes configuration number 3806 from the selected potential configuration attribute 3808 o Added ABNF throughout 3810 o Specified that answerer should include "a=csup" in case of 3811 unsupported required extensions in offer. 3813 o Specified use of second offer/answer exchange when answerer 3814 selected a potential configuration 3816 o Updated rules (and added restrictions) for referencing media- and 3817 session-level capabilities in potential configurations (at the 3818 media level) 3820 o Added initial section on ICE interactions 3822 o Added initial section on receiving media before answer 3824 8.13. draft-ietf-mmusic-sdp-capability-negotiation-01 3826 The following are the major changes compared to version -00: 3828 o Media capabilities are no longer considered a core capability and 3829 hence have been removed. This leaves transport protocols and 3830 attributes as the only capabilities defined by the core. 3832 o Version attribute has been removed and an option tag to indicate 3833 the actual version has been defined instead. 3835 o Clarified rules for session-level and media level attributes 3836 provided at either level as well how they can be used in 3837 potential configurations. 3839 o Potential configuration parameters no longer have implicit 3840 ordering; an explicit preference indicator is now included. 3842 o The parameter name for transport protocols in the potential and 3843 actual configuration attributes have been changed "p" to "t". 3845 o Clarified operator precedence within potential and actual 3846 configuration attributes. 3848 o Potential configurations at the session level now limited to 3849 indicate latent capability configurations. Consequently, an 3850 actual configuration attribute can no longer be provided at the 3851 session level. 3853 o Cleaned up capability and potential configuration terminology - 3854 they are now two clearly different things. 3856 8.14. draft-ietf-mmusic-sdp-capability-negotiation-00 3858 Version 00 is the initial version. The solution provided in this 3859 initial version is based on an earlier (individual submission) 3860 version of [SDPCapNeg]. The following are the major changes compared 3861 to that document: 3863 o Solution no longer based on RFC 3407, but defines a set of 3864 similar attributes (with some differences). 3866 o Various minor changes to the previously defined attributes. 3868 o Multiple transport capabilities can be included in a single 3869 "tcap" attribute 3871 o A version attribute is now included. 3873 o Extensions to the framework are formally supported. 3875 o Option tags and the ability to list supported and required 3876 extensions are supported. 3878 o A best-effort SRTP example use case has been added. 3880 o Some terminology change throughout to more clearly indicate what 3881 constitutes capabilities and what constitutes configurations. 3883 9. References 3885 9.1. Normative References 3887 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3888 Requirement Levels", BCP 14, RFC 2119, March 1997. 3890 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 3891 with Session Description Protocol (SDP)", RFC 3264, June 3892 2002. 3894 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3895 Description Protocol", RFC 4566, July 2006. 3897 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3898 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3899 May 2008. 3901 [RFC5234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 3902 Specifications: ABNF", RFC 5234, January 2008. 3904 [ICE] J. Rosenberg, "Interactive Connectivity Establishment 3905 (ICE): A Methodology for Network Address Translator (NAT) 3906 Traversal for Offer/Answer Protocols", work in progress, 3907 October 2007. 3909 9.2. Informative References 3911 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3912 A., Peterson, J., Sparks, R., Handley, M., and E. 3913 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3914 June 2002. 3916 [RFC3312] G. Camarillo, W. Marshall, and J. Rosenberg, "Integration 3917 of Resource Management and Session Initiation Protocol 3918 (SIP)", RFC 3312, October 2002. 3920 [RFC3262] J. Rosenberg, and H. Schulzrinne, "Reliability of 3921 Provisional Responses in Session Initiation Protocol 3922 (SIP)", RFC 3262, June 2002. 3924 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 3925 Schulzrinne, "Grouping of Media Lines in the Session 3926 Description Protocol (SDP)", RFC 3388, December 2002. 3928 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 3929 Capability Declaration", RFC 3407, October 2002. 3931 [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and 3932 Video Conferences with Minimal Control", RFC 3551, July 3933 2003. 3935 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 3936 Norrman, "The Secure Real-time Transport Protocol 3937 (SRTP).", RFC 3711, March 2004. 3939 [RFC3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 3940 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 3941 August 2004. 3943 [RFC3890] M. Westerlund, "A Transport Independent Bandwidth Modifier 3944 for the Session Description Protocol (SDP).", RFC 3890, 3945 September 2004. 3947 [RFC4145] Yon, D., and G. Camarillo, "TCP-Based Media Transport in 3948 the Session Description Protocol (SDP)", RFC 4145, 3949 September 2005. 3951 [RFC4474] J. Peterson, and C. Jennings, "Enhancements for 3952 Authenticated Identity Management in the Session 3953 Initiation Protocol (SIP)", RFC 4474, August 2006. 3955 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 3956 Carrara, "Key Management Extensions for Session 3957 Description Protocol (SDP) and Real Time Streaming 3958 Protocol (RTSP)", RFC 4567, July 2006. 3960 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 3961 Description Protocol Security Descriptions for Media 3962 Streams", RFC 4568, July 2006. 3964 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 3965 "Extended RTP Profile for Real-Time Transport Control 3966 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 3967 2006. 3969 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 3970 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 3971 July 2006. 3973 [RFC4756] A. Li, "Forward Error Correction Grouping Semantics in 3974 Session Description Protocol", RFC 4756, November 2006. 3976 [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for 3977 Session Description Protocol Media Streams", RFC 5027, 3978 October 2007. 3980 [RFC5124] Ott, J., and E Carrara, "Extended Secure RTP Profile for 3981 Real-time Transport Control Protocol (RTCP)-Based Feedback 3982 (RTP/SAVPF)", RFC 5124, February 2008. 3984 [RFC5751] Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet 3985 Mail Extensions (S/MIME) Version 3.2 Message 3986 Specification", RFC 5751, January 2010. 3988 [BESRTP] Kaplan, H., and F. Audet, "Session Description Protocol 3989 (SDP) Offer/Answer Negotiation for Best-Effort Secure 3990 Real-Time Transport Protocol", work in progress, October 3991 2006. 3993 [DTLS-SRTP] McGrew, D. and E. Rescorla, "Datagram Transport Layer 3994 Security (DTLS) Extension to Establish Keys for Secure 3995 Real-time Transport Protocol (SRTP)", work in progress, 3996 February 2009. 3998 [DTLS-SRTP-FRAMEWORK] Fischl, J., Tschofenig, H., and E. Rescorla, 3999 "Framework for Establishing an SRTP Security Context using 4000 DTLS", work in progress, March 2009. 4002 [ICETCP] J. Rosenberg, "TCP Candidates with Interactive 4003 Connectivity Establishment (ICE)", work in progress, 4004 October 2009. 4006 [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", (draft- 4007 andreasen-mmusic-sdp-capability-negotiation-01.txt), work 4008 in progress, December 2006. 4010 [SDPMedCap] Gilman, R, Even, R., and F. Andreasen "SDP Media 4011 Capabilities Negotiation", work in progress, July 2009. 4013 [SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session 4014 Description and Capability Negotiation", Work in Progress, 4015 February 2005. 4017 Author's Address 4019 Flemming Andreasen 4020 Cisco Systems 4021 Iselin, NJ 08830 4022 USA 4024 Email: fandreas@cisco.com