idnits 2.17.1 draft-ietf-mmusic-sdp-capability-negotiation-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3507. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 11, 2007) is 5982 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 2728, but not defined == Missing Reference: 'F' is mentioned on line 2728, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4756 (Obsoleted by RFC 5956) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group F. Andreasen 3 Internet-Draft Cisco Systems 4 Intended Status: Proposed Standard December 11, 2007 5 Expires: June 2008 7 SDP Capability Negotiation 8 draft-ietf-mmusic-sdp-capability-negotiation-08.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on June 11, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The Session Description Protocol (SDP) was intended for describing 43 multimedia sessions for the purposes of session announcement, 44 session invitation, and other forms of multimedia session 45 initiation. SDP was not intended to provide capability indication or 46 capability negotiation, however over the years, SDP has seen 47 widespread adoption and as a result it has been gradually extended 48 to provide limited support for these, notably in the form of the 49 offer/answer model defined in RFC 3264. SDP and its current 50 extensions do not define how to negotiate one or more alternative 51 transport protocols (e.g. RTP profiles) or attributes. This makes it 52 difficult to deploy new RTP profiles such as secure RTP or RTP with 53 RTCP-based feedback, negotiate use of different security keying 54 mechanisms, etc. It also presents problems for some forms of media 55 negotiation. 57 The purpose of this document is to address these shortcomings by 58 extending SDP with capability negotiation parameters and associated 59 offer/answer procedures to use those parameters in a backwards 60 compatible manner. 62 The document defines a general SDP Capability Negotiation framework. 63 It also specifies how to provide attributes and transport protocols 64 as capabilities and negotiate them using the framework. Extensions 65 for other types of capabilities (e.g. media types and media formats) 66 may be provided in other documents. 68 Table of Contents 70 1. Introduction...................................................3 71 2. Conventions used in this document..............................7 72 3. SDP Capability Negotiation Solution............................7 73 3.1. SDP Capability Negotiation Model..........................7 74 3.2. Solution Overview........................................10 75 3.3. Version and Extension Indication Attributes..............14 76 3.3.1. Supported Capability Negotiation Extensions Attribute14 77 3.3.2. Required Capability Negotiation Extensions Attribute15 78 3.4. Capability Attributes....................................17 79 3.4.1. Attribute Capability Attribute......................17 80 3.4.2. Transport Protocol Capability Attribute.............19 81 3.4.3. Extension Capability Attributes.....................20 82 3.5. Configuration Attributes.................................21 83 3.5.1. Potential Configuration Attribute...................21 84 3.5.2. Actual Configuration Attribute......................28 85 3.6. Offer/Answer Model Extensions............................30 86 3.6.1. Generating the Initial Offer........................31 87 3.6.2. Generating the Answer...............................34 88 3.6.2.1. Example Views of Potential Configurations......40 89 3.6.3. Offerer Processing of the Answer....................42 90 3.6.4. Modifying the Session...............................43 91 3.7. Interactions with ICE....................................43 92 3.8. Interactions with SIP Option Tags........................45 93 3.9. Processing Media before Answer...........................46 94 3.10. Indicating Bandwidth Usage..............................47 95 3.11. Dealing with Large Number of Potential Configurations...47 96 3.12. SDP Capability Negotiation and Intermediaries...........48 97 3.13. Considerations for Specific Attribute Capabilities......50 98 3.13.1. The rtpmap and fmtp Attributes.....................50 99 3.13.2. Direction Attributes...............................51 100 3.14. Relationship to RFC 3407................................52 101 4. Examples......................................................52 102 4.1. Multiple Transport Protocols.............................52 103 4.2. Best-Effort SRTP with Session-Level MIKEY and Media Level 104 Security Descriptions.........................................56 105 4.3. SRTP with Session-Level MIKEY and Media Level Security 106 Descriptions as Alternatives..................................61 107 5. Security Considerations.......................................63 108 6. IANA Considerations...........................................66 109 6.1. New SDP Attributes.......................................66 110 6.2. New SDP Capability Negotiation Option Tag Registry.......67 111 6.3. New SDP Capability Negotiation Potential Configuration 112 Parameter Registry............................................68 113 7. Acknowledgments...............................................68 114 8. Change Log....................................................68 115 8.1. draft-ietf-mmusic-sdp-capability-negotiation-08..........68 116 8.2. draft-ietf-mmusic-sdp-capability-negotiation-07..........69 117 8.3. draft-ietf-mmusic-sdp-capability-negotiation-06..........70 118 8.4. draft-ietf-mmusic-sdp-capability-negotiation-05..........71 119 8.5. draft-ietf-mmusic-sdp-capability-negotiation-04..........72 120 8.6. draft-ietf-mmusic-sdp-capability-negotiation-03..........72 121 8.7. draft-ietf-mmusic-sdp-capability-negotiation-02..........73 122 8.8. draft-ietf-mmusic-sdp-capability-negotiation-01..........73 123 8.9. draft-ietf-mmusic-sdp-capability-negotiation-00..........74 124 9. References....................................................76 125 9.1. Normative References.....................................76 126 9.2. Informative References...................................76 127 Author's Addresses...............................................78 128 Intellectual Property Statement..................................78 129 Full Copyright Statement.........................................79 130 Acknowledgment...................................................79 132 1. Introduction 134 The Session Description Protocol (SDP) was intended for describing 135 multimedia sessions for the purposes of session announcement, 136 session invitation, and other forms of multimedia session 137 initiation. The SDP contains one or more media stream descriptions 138 with information such as IP-address and port, type of media stream 139 (e.g. audio or video), transport protocol (possibly including 140 profile information, e.g. RTP/AVP or RTP/SAVP), media formats (e.g. 141 codecs), and various other session and media stream parameters that 142 define the session. 144 Simply providing media stream descriptions is sufficient for session 145 announcements for a broadcast application, where the media stream 146 parameters are fixed for all participants. When a participant wants 147 to join the session, he obtains the session announcement and uses 148 the media descriptions provided, e.g., joins a multicast group and 149 receives media packets in the encoding format specified. If the 150 media stream description is not supported by the participant, he is 151 unable to receive the media. 153 Such restrictions are not generally acceptable to multimedia session 154 invitations, where two or more entities attempt to establish a media 155 session, that uses a set of media stream parameters acceptable to 156 all participants. First of all, each entity must inform the other of 157 its receive address, and secondly, the entities need to agree on the 158 media stream parameters to use for the session, e.g. transport 159 protocols and codecs. To solve this, RFC 3264 [RFC3264] defined the 160 offer/answer model, whereby an offerer constructs an offer SDP that 161 lists the media streams, codecs, and other SDP parameters that the 162 offerer is willing to use. This offer SDP is sent to the answerer, 163 which chooses from among the media streams, codecs and other SDP 164 parameters provided, and generates an answer SDP with his 165 parameters, based on that choice. The answer SDP is sent back to the 166 offerer thereby completing the session negotiation and enabling the 167 establishment of the negotiated media streams. 169 Taking a step back, we can make a distinction between the 170 capabilities supported by each participant, the way in which those 171 capabilities can be supported, and the parameters that can actually 172 be used for the session. More generally, we can say that we have the 173 following: 175 o A set of capabilities for the session and its associated media 176 stream components, supported by each side. The capability 177 indications by themselves do not imply a commitment to use the 178 capabilities in the session. 180 Capabilities can for example be that the "RTP/SAVP" profile is 181 supported, that the "PCMU" codec is supported, or that the 182 "crypto" attribute is supported with a particular value. 184 o A set of potential configurations indicating which combinations 185 of those capabilities can be used for the session and its 186 associated media stream components. Potential configurations are 187 not ready for use. Instead, they provide an alternative that may 188 be used, subject to further negotiation. 190 A potential configuration can for example indicate that the 191 "PCMU" codec and the "RTP/SAVP" transport protocol are not only 192 supported (i.e. listed as capabilities), but they are offered for 193 potential use in the session. 195 o An actual configuration for the session and its associated media 196 stream components, that specifies which combinations of session 197 parameters and media stream components can be used currently and 198 with what parameters. Use of an actual configuration does not 199 require any further negotiation. 201 An actual configuration can for example be that the "PCMU" codec 202 and the "RTP/SAVP" transport protocol are offered for use 203 currently. 205 o A negotiation process that takes the set of actual and potential 206 configurations (combinations of capabilities) as input and 207 provides the negotiated actual configurations as output. 209 SDP by itself was designed to provide only one of these, namely 210 listing of the actual configurations, however over the years, use of 211 SDP has been extended beyond its original scope. Of particular 212 importance are the session negotiation semantics that were defined 213 by the offer/answer model in RFC 3264. In this model, both the offer 214 and the answer contain actual configurations; separate capabilities 215 and potential configurations are not supported. 217 Other relevant extensions have been defined as well. RFC 3407 218 [RFC3407] defined simple capability declarations, which extends SDP 219 with a simple and limited set of capability descriptions. Grouping 220 of media lines, which defines how media lines in SDP can have other 221 semantics than the traditional "simultaneous media streams" 222 semantics, was defined in RFC 3388 [RFC3388], etc. 224 Each of these extensions was designed to solve a specific limitation 225 of SDP. Since SDP had already been stretched beyond its original 226 intent, a more comprehensive capability declaration and negotiation 227 process was intentionally not defined. Instead, work on a "next 228 generation" of a protocol to provide session description and 229 capability negotiation was initiated [SDPng]. SDPng defined a 230 comprehensive capability negotiation framework and protocol that was 231 not bound by existing SDP constraints. SDPng was not designed to be 232 backwards compatible with existing SDP and hence required both sides 233 to support it, with a graceful fallback to legacy operation when 234 needed. This, combined with lack of ubiquitous multipart MIME 235 support in the protocols that would carry SDP or SDPng, made it 236 challenging to migrate towards SDPng. In practice, SDPng has not 237 gained traction but rather remained as work in progress for an 238 extended period of time. Existing real-time multimedia 239 communication protocols such as SIP, RTSP, Megaco, and MGCP continue 240 to use SDP. However, SDP and its current extensions do not address 241 an increasingly important problem: the ability to negotiate one or 242 more alternative transport protocols (e.g., RTP profiles) and 243 associated parameters (e.g. SDP attributes). This makes it 244 difficult to deploy new RTP profiles such as secure RTP (SRTP) 245 [RFC3711], RTP with RTCP-Based Feedback [RFC4585], etc. The problem 246 is exacerbated by the fact that RTP profiles are defined 247 independently. When a new profile is defined and N other profiles 248 already exist, there is a potential need for defining N additional 249 profiles, since profiles cannot be combined automatically. For 250 example, in order to support the plain and secure RTP version of RTP 251 with and without RTCP-based feedback, four separate profiles (and 252 hence profile definitions) are needed: RTP/AVP [RFC3551], RTP/SAVP 253 [RFC3711], RTP/AVPF [RFC4585], and RTP/SAVPF [SAVPF]. In addition 254 to the pressing profile negotiation problem, other important real- 255 life limitations have been found as well. Keying material and other 256 parameters for example need to be negotiated with some of the 257 transport protocols, but not others. Similarly, some media formats 258 and types of media streams need to negotiate a variety of different 259 parameters. 261 The purpose of this document is to define a mechanism that enables 262 SDP to provide limited support for indicating capabilities and their 263 associated potential configurations, and negotiate the use of those 264 potential configurations as actual configurations. It is not the 265 intent to provide a full-fledged capability indication and 266 negotiation mechanism along the lines of SDPng or ITU-T H.245. 267 Instead, the focus is on addressing a set of well-known real-life 268 limitations. More specifically, the solution provided in this 269 document provides a general SDP Capability Negotiation framework 270 that is backwards compatible with existing SDP. It also defines 271 specifically how to provide attributes and transport protocols as 272 capabilities and negotiate them using the framework. Extensions for 273 other types of capabilities (e.g. media types and formats) may be 274 provided in other documents. 276 As mentioned above, SDP is used by several protocols, and hence the 277 mechanism should be usable by all of these. One particularly 278 important protocol for this problem is the Session Initiation 279 Protocol (SIP) [RFC3261]. SIP uses the offer/answer model [RFC3264] 280 (which is not specific to SIP) to negotiate sessions and hence the 281 mechanism defined here provides the offer/answer procedures to use 282 for the capability negotiation framework. 284 The rest of the document is structured as follows. In Section 3. we 285 present the SDP Capability Negotiation solution, which consists of 286 new SDP attributes and associated offer/answer procedures. In 287 Section 4. we provide examples illustrating its use and in Section 288 5. we provide the security considerations. 290 2. Conventions used in this document 292 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 293 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 294 document are to be interpreted as described in [RFC2119]. 296 3. SDP Capability Negotiation Solution 298 In this section we first present the conceptual model behind the SDP 299 capability negotiation framework followed by an overview of the SDP 300 Capability Negotiation solution. We then define new SDP attributes 301 for the solution and provide its associated updated offer/answer 302 procedures. 304 3.1. SDP Capability Negotiation Model 306 Our model uses the concepts of 308 o Capabilities 310 o Potential Configurations 312 o Actual Configurations 314 o Negotiation Process 316 as defined in Section 1. Conceptually, we want to offer not just the 317 actual configuration SDP (which is done with the current 318 offer/answer model), but the actual configuration SDP as well as one 319 or more alternative SDPs, i.e. potential configurations. The 320 answerer must choose either the actual configuration, or one of the 321 potential configurations, and generate an answer SDP based on that. 323 The offerer may need to perform processing on the answer, which 324 depends on the offer that was chosen (actual or potential 325 configuration). The answerer therefore informs the offerer which 326 configuration the answerer chose. The process can be viewed 327 *conceptually* as follows: 329 Offerer Answerer 330 ======= ======== 332 1) Generate offer with actual 333 configuration and alternative 334 potential configurations 335 2) Send offer with all configurations 337 +------------+ 338 | SDP o1 | 339 | (actual | 340 | config | 341 | |-+ Offer 342 +------------+ | -----> 3) Process offered configurations 343 | SDP o2 | in order of preference indicated 344 | (potential | 4) Generate answer based on chosen 345 | config 1) |-+ configuration (e.g. o2), and 346 +------------+ | inform offerer which one was 347 | SDP o3 | chosen 348 | (potential | 349 | config 2) |-+ 350 +------------+ | 351 | SDP ... | 352 : : 354 +------------+ 355 | SDP a1 | 356 Answer | (actual | 357 <----- | config,o2)| 358 | | 359 5) Process answer based on +------------+ 360 the configuration that was 361 chosen (o2), as indicated in 362 the answer 364 The above illustrates the conceptual model: The actual solution uses 365 a single SDP, which contains the actual configuration (as with 366 current SDP and the current offer/answer model) and several new 367 attributes and associated procedures, that encode the capabilities 368 and potential configurations. A more accurate depiction of the 369 actual offer SDP is therefore as follows: 371 +--------------------+ 372 | SDP o1 | 373 | (actual | 374 | config | 375 | | 376 | +-------------+ | 377 | | capability 1| | 378 | | capability 2| | 379 | | ... | | 380 | +-------------+ | Offer 381 | | -----> 382 | +-------------+ | 383 | | potential | | 384 | | config 1 | | 385 | | potential | | 386 | | config 2 | | 387 | | ... | | 388 | +-------------+ | 389 | | 390 +--------------------+ 392 The above structure is used for two reasons: 394 o Backwards compatibility: As noted above, support for multipart 395 MIME is not ubiquitous. By encoding both capabilities and 396 potential configurations in SDP attributes, we can represent 397 everything in a single SDP thereby avoiding any multipart MIME 398 support issues. Furthermore, since unknown SDP attributes are 399 ignored by the SDP recipient, we ensure that entities that do not 400 support the framework simply perform the regular RFC 3264 401 offer/answer procedures. This provides us with seamless backwards 402 compatibility. 404 o Message size efficiency: When we have multiple media streams, 405 each of which may potentially use two or more different transport 406 protocols with a variety of different associated parameters, the 407 number of potential configurations can be large. If each possible 408 alternative is represented as a complete SDP in an offer, we can 409 easily end up with large messages. By providing a more compact 410 encoding, we get more efficient message sizes. 412 In the next section, we describe the exact structure and specific 413 SDP parameters used to represent this. 415 3.2. Solution Overview 417 The solution consists of the following: 419 o Two new attributes to support extensions to the framework itself 420 as follows: 422 o A new attribute ("a=csup") that lists the supported base 423 (optionally) and any supported extension options to the 424 framework. 426 o A new attribute ("a=creq") that lists the extensions to the 427 framework that are required to be supported by the entity 428 receiving the SDP in order to do capability negotiation. 430 o Two new attributes used to express capabilities as follows 431 (additional attributes can be defined as extensions): 433 o A new attribute ("a=acap") that defines how to list an 434 attribute name and its associated value (if any) as a 435 capability. 437 o A new attribute ("a=tcap") that defines how to list transport 438 protocols (e.g. "RTP/AVP") as capabilities. 440 o Two new attributes to negotiate configurations as follows: 442 o A new attribute ("a=pcfg") that lists potential 443 configurations supported. This is done by reference to the 444 capabilities from the SDP in question. Extension capabilities 445 can be defined and referenced in the potential 446 configurations. Alternative potential configurations have an 447 explicit ordering associated with them. Also, potential 448 configurations are preferred over the actual configuration 449 included in the "m=" line and its associated parameters. 451 o A new attribute ("a=acfg") to be used in an answer SDP. The 452 attribute identifies a potential configuration from an offer 453 SDP which was used as an actual configuration to form the 454 answer SDP. Extension capabilities can be included as well. 456 o Extensions to the offer/answer model that allow for capabilities 457 and potential configurations to be included in an offer. 458 Capabilities can be provided at the session level and the media 459 level. Potential configurations can be included at the media 460 level only, where they constitute alternative offers that may be 461 accepted by the answerer instead of the actual configuration(s) 462 included in the "m=" line(s) and associated parameters. The 463 answerer indicates which (if any) of the potential configurations 464 it used to form the answer by including the actual configuration 465 attribute ("a=acfg") in the answer. Capabilities may be included 466 in answers as well, where they can aid in guiding a subsequent 467 new offer. 469 The mechanism is illustrated by the offer/answer exchange below, 470 where Alice sends an offer to Bob: 472 Alice Bob 474 | (1) Offer (SRTP and RTP) | 475 |--------------------------------->| 476 | | 477 | (2) Answer (SRTP) | 478 |<---------------------------------| 479 | | 480 | (3) Offer (SRTP) | 481 |--------------------------------->| 482 | | 483 | (4) Answer (SRTP) | 484 |<---------------------------------| 485 | | 487 Alice's offer includes RTP and SRTP as alternatives, where RTP is 488 the default (actual configuration), but SRTP is the preferred one 489 (potential configuration): 491 v=0 492 o=- 25678 753849 IN IP4 192.0.2.1 493 s= 494 c=IN IP4 192.0.2.1 495 t=0 0 496 m=audio 53456 RTP/AVP 0 18 497 a=tcap:1 RTP/SAVP 498 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 499 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 500 a=pcfg:1 t=1 a=1 502 The "m=" line indicates that Alice is offering to use plain RTP with 503 PCMU or G.729. The capabilities are provided by the "a=tcap" and 504 "a=acap" attributes. The transport capability attribute ("a=tcap") 505 indicates that secure RTP under the AVP profile ("RTP/SAVP") is 506 supported with an associated transport capability handle of 1. The 507 "acap" attribute provides an attribute capability with a handle of 508 1. The attribute capability is a "crypto" attribute, which provides 509 the keying material for SRTP using SDP security descriptions 510 [RFC4568]. The "a=pcfg" attribute provides the potential 511 configuration included in the offer by reference to the capability 512 parameters. One alternative is provided; it has a configuration 513 number of 1 and it consists of transport protocol capability 1 514 (i.e., the RTP/SAVP profile - secure RTP), and the attribute 515 capability 1 (i.e., the crypto attribute provided). Potential 516 configurations are preferred over the actual configuration included 517 in the offer SDP, and hence Alice is expressing a preference for 518 using secure RTP. 520 Bob receives the SDP offer from Alice. Bob supports SRTP and the SDP 521 Capability Negotiation framework, and hence he accepts the 522 (preferred) potential configuration for Secure RTP provided by Alice 523 and generates the following answer SDP: 525 v=0 526 o=- 24351 621814 IN IP4 192.0.2.2 527 s= 528 c=IN IP4 192.0.2.2 529 t=0 0 530 m=audio 54568 RTP/SAVP 0 18 531 a=crypto:1 AES_CM_128_HMAC_SHA1_80 532 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 533 a=acfg:1 t=1 a=1 535 Bob includes the "a=acfg" attribute in the answer to inform Alice 536 that he based his answer on an offer using potential configuration 1 537 with transport protocol capability 1 and attribute capability 1 from 538 the offer SDP (i.e., the RTP/SAVP profile using the keying material 539 provided). Bob also includes his keying material in a "crypto" 540 attribute. If Bob supported one or more extensions to the capability 541 negotiation framework, he would have included option tags for those 542 in the answer as well (in an "a=csup" attribute). 544 When Alice receives Bob's answer, session negotiation has completed, 545 however Alice nevertheless generates a new offer using the 546 negotiated configuration as the actual configuration. This is done 547 purely to assist any intermediaries that may reside between Alice 548 and Bob but do not support the SDP Capability Negotiation framework, 549 and hence may not understand the negotiation that just took place. 551 Alice's updated offer includes only SRTP, and it is not using the 552 SDP Capability Negotiation framework (Alice could have included the 553 capabilities as well is she wanted to): 555 v=0 556 o=- 25678 753850 IN IP4 192.0.2.1 557 s= 558 c=IN IP4 192.0.2.1 559 t=0 0 560 m=audio 53456 RTP/SAVP 0 18 561 a=crypto:1 AES_CM_128_HMAC_SHA1_80 562 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 564 The "m=" line now indicates that Alice is offering to use secure RTP 565 with PCMU or G.729. The "crypto" attribute, which provides the SRTP 566 keying material, is included with the same value again. 568 Bob receives the SDP offer from Alice, which he accepts, and then 569 generates an answer to Alice: 571 v=0 572 o=- 24351 621815 IN IP4 192.0.2.2 573 s= 574 c=IN IP4 192.0.2.2 575 t=0 0 576 m=audio 54568 RTP/SAVP 0 18 577 a=crypto:1 AES_CM_128_HMAC_SHA1_80 578 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 580 Bob includes the same crypto attribute as before, and the session 581 proceeds without change. Although Bob did not include any 582 capabilities in his answer, he could have done so if he wanted to. 584 Note that in this particular example, the answerer supported the 585 capability negotiation extensions defined here. Had he not, he would 586 simply have ignored the new attributes and accepted the (actual 587 configuration) offer to use normal RTP. In that case, the following 588 answer would have been generated instead: 590 v=0 591 o=- 24351 621814 IN IP4 192.0.2.2 592 s= 593 c=IN IP4 192.0.2.2 594 t=0 0 595 m=audio 54568 RTP/AVP 0 18 597 3.3. Version and Extension Indication Attributes 599 In this section, we present the new attributes associated with 600 indicating the SDP Capability Negotiation extensions supported and 601 required. 603 3.3.1. Supported Capability Negotiation Extensions Attribute 605 The SDP Capability Negotiation solution allows for capability 606 negotiation extensions to be defined. Associated with each such 607 extension is an option tag that identifies the extension in 608 question. Option-tags MUST be registered with IANA per the 609 procedures defined in Section 6. 611 The Supported Capability Negotiation Extensions attribute ("a=csup") 612 contains a comma-separated list of option tags identifying the SDP 613 Capability Negotiation extensions supported by the entity that 614 generated the SDP. The attribute is defined as follows: 616 a=csup: 618 RFC 4566, Section 9, provides the ABNF [RFC4234] for SDP attributes. 619 The "csup" attribute adheres to the RFC 4566 "attribute" production, 620 with an att-value defined as follows: 622 att-value = option-tag-list 623 option-tag-list = option-tag *("," option-tag) 624 option-tag = token ; defined in [RFC4566] 626 A special base option tag with a value of "cap-v0" is defined for 627 the basic SDP Capability Negotiation framework defined in this 628 document. Entities can use this option tag with the "a=csup" 629 attribute to indicate support for the SDP Capability Negotiation 630 framework specified in this document. 632 The following examples illustrate use of the "a=csup" attribute with 633 the "cap-v0" option tag and two hypothetical option tags, "foo" and 634 "bar" (note the lack of white space): 636 a=csup:cap-v0 638 a=csup:foo 639 a=csup:bar 641 a=csup:cap-v0,foo,bar 643 The "a=csup" attribute can be provided at the session and the media- 644 level. When provided at the session-level, it applies to the entire 645 SDP. When provided at the media-level, it applies to the media 646 description in question only (option-tags provided at the session 647 level apply as well). There can be at most one "a=csup" attribute at 648 the session-level and at most one at the media-level (one per media 649 description in the latter case). 651 Whenever an entity that supports one or more extensions to the SDP 652 Capability Negotiation framework generates an SDP, it SHOULD include 653 the "a=csup" attribute with the option tags for the extensions it 654 supports at the session and/or media-level, unless those option tags 655 are already provided in one or more "a=creq" attribute (see Section 656 3.3.2. ) at the relevant levels. Inclusion of the base option tag is 657 OPTIONAL; support for the base framework can be inferred from 658 presence of the "a=pcfg" attribute defined in Section 3.5.1. 660 Use of the base option tag may still be useful in some scenarios, 661 e.g. when using SIP OPTIONS [RFC3261] or generating an answer to 662 an offer that did not use the SDP Capability Negotiation 663 framework. 665 3.3.2. Required Capability Negotiation Extensions Attribute 667 The Required Capability Negotiation Extensions attribute ("a=creq") 668 contains a comma-separated list of option tags (see Section 3.3.1. ) 669 specifying the SDP Capability Negotiation extensions that MUST be 670 supported by the entity receiving the SDP, in order for that entity 671 to properly process the SDP Capability Negotiation attributes and 672 associated procedures. There is no need to include the base option- 673 tag ("cap-v0") with the "creq" attribute, since any entity that 674 supports the "creq" attribute in the first place also supports the 675 base option-tag. Still, it is permissible to do so. 677 Such functionality may be important if a future version of the 678 capability negotiation framework were not backwards compatible. 680 The attribute is defined as follows: 682 a=creq: 684 The "creq" attribute adheres to the RFC 4566 "attribute" production, 685 with an att-value defined as follows: 687 att-value = option-tag-list 689 The following examples illustrate use of the "a=creq" attribute with 690 the "cap-v0" base option tag and two hypothetical option tags, "foo" 691 and "bar" (note the lack of white space): 693 a=creq:cap-v0 695 a=creq:foo 697 a=creq:bar 699 a=creq:cap-v0,foo,bar 701 The "a=creq" attribute can be provided at the session and the media- 702 level. When provided at the session-level, it applies to the entire 703 SDP. When provided at the media-level, it applies to the media 704 description in question only (required option tags provided at the 705 session level apply as well). There can be at most one "a=creq" 706 attribute at the session-level and at most one "a=creq" attribute at 707 the media-level (one per media description in the latter case). 709 When an entity generates an SDP and it requires the recipient of 710 that SDP to support one or more SDP Capability Negotiation 711 extensions (except for the base) at the session or media level in 712 order to properly process the SDP Capability Negotiation, the 713 "a=creq" attribute MUST be included with option-tags that identify 714 the required extensions at the session and/or media level. If 715 support for an extension is needed only in one or more specific 716 potential configurations, the potential configuration provides a way 717 to indicate that instead (see Section 3.5.1. ). Support for the 718 basic negotiation framework is implied by the presence of an 719 "a=pcfg" attribute (see Section 3.5.1. ) and hence it is not 720 required to include the "a=creq" attribute with the base option-tag 721 ("cap-v0"). 723 A recipient that receives an SDP and does not support one or more of 724 the required extensions listed in a "creq" attribute, MUST NOT 725 perform the SDP Capability Negotiation defined in this document. For 726 non-supported extensions provided at the session-level, this implies 727 that SDP Capability Negotiation MUST NOT be performed at all. For 728 non-supported extensions at the media-level, this implies that SDP 729 Capability Negotiation MUST NOT be performed for the media stream in 730 question. 732 An entity that does not support the SDP Capability Negotiation 733 framework at all, will ignore these attributes (as well as the 734 other SDP Capability Negotiation attributes) and not perform any 735 SDP Capability Negotiation in the first place. 737 When an SDP recipient does not support one or more required SDP 738 Capability Negotiation extensions listed in the option tags, the 739 recipient MUST proceed as if the SDP Capability Negotiation 740 attributes were not included in the first place, i.e. all the 741 capability negotiation attributes should be ignored. If the SDP 742 recipient is an SDP answerer [RFC3264], the recipient SHOULD include 743 a "csup" attribute in the resulting SDP answer listing the SDP 744 Capability Negotiation extensions it actually supports. 746 This ensures that introduction of the SDP Capability Negotiation 747 mechanism by itself does not lead to session failures. 749 3.4. Capability Attributes 751 In this section, we present the new attributes associated with 752 indicating the capabilities for use by the SDP Capability 753 Negotiation. 755 3.4.1. Attribute Capability Attribute 757 Attributes and their associated values can be expressed as 758 capabilities by use of a new attribute capability attribute 759 ("a=acap"), which is defined as follows: 761 a=acap: 763 where is an integer between 1 and 2^31-1 (both 764 included) used to number the attribute capability and is 765 an attribute ("a=") in its "" or :" 766 form, i.e., excluding the "a=" part (see [RFC4566]). 768 The "acap" attribute adheres to the RFC 4566 "attribute" production, 769 with an att-value defined as follows: 771 att-value = att-cap-num 1*WSP att-par 772 att-cap-num = 1*DIGIT ;defined in [RFC4234] 773 att-par = attribute ;defined in RFC 4566 775 Note that white space is not permitted before the att-cap-num. 777 The "acap" attribute can be provided at the session level only when 778 the attribute capability contains session-level attributes, whereas 779 media level attributes can be provided in attribute capabilities at 780 either the media level or session-level. The base SDP Capability 781 Negotiation framework however only defines procedures for use of 782 media-level attribute capabilities at the media level (extensions 783 may define use at the session level). 785 Each occurrence of the "acap" attribute in the entire session 786 description MUST use a different value of . 787 Consecutive numbering of the values is not required. 789 There is a need to be able to reference both session-level and 790 media-level attributes in potential configurations at the media 791 level, and this provides for a simple solution to avoiding overlap 792 between the references (handles) to each attribute capability. 794 The values provided are independent of similar values provided for other types of capabilities, i.e., they 796 form a separate name-space for attribute capabilities. 798 The following examples illustrate use of the "acap" attribute: 800 a=acap:1 ptime:20 802 a=acap:2 ptime:30 804 a=acap:3 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAA 805 AAAGEEoo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0 806 JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUO 807 SrzKTAv9zV 809 a=acap:4 crypto:1 AES_CM_128_HMAC_SHA1_32 810 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 812 The first two attribute capabilities provide attribute values for 813 the ptime attribute. The third provides SRTP parameters by using 814 MIKEY [RFC3830] with the key-mgmt attribute [RFC4567]. The fourth 815 provides SRTP parameters by use of security descriptions with the 816 crypto attribute [RFC4568]. Note that the line-wrapping and new- 817 lines in example three and four are provided for formatting reasons 818 only - they are not permitted in actual SDP. 820 Readers familiar with RFC 3407 may notice the similarity between 821 the RFC 3407 "cpar" attribute and the above. There are however a 822 couple of important differences, notably that the "acap" attribute 823 contains a handle that enables referencing it and it furthermore 824 supports attributes only (the "cpar" attribute defined in RFC 3407 825 supports bandwidth information as well). The "acap" attribute also 826 is not automatically associated with any particular capabilities. 827 See Section 3.14. for the relationship to RFC 3407. 829 3.4.2. Transport Protocol Capability Attribute 831 Transport Protocols can be expressed as capabilities by use of a new 832 Transport Protocol Capability attribute ("a=tcap") defined as 833 follows: 835 a=tcap: 837 where is an integer between 1 and 2^31-1 (both 838 included) used to number the transport address capability for later 839 reference, and is one or more , separated by 840 white space, as defined in the SDP "m=" line. 842 The "tcap" attribute adheres to the RFC 4566 "attribute" production, 843 with an att-value defined as follows: 845 att-value = trpr-cap-num 1*WSP proto-list 846 trpr-cap-num = 1*DIGIT ;defined in [RFC4234] 847 proto-list = proto *(1*WSP proto) ; defined in RFC 4566 849 Note that white space is not permitted before the trpr-cap-num. 851 The "tcap" attribute can be provided at the session-level and the 852 media-level. There can be at most one "a=tcap" attribute at the 853 session-level and at most one at the media-level (one per media 854 description in the latter case). Each occurrence of the "tcap" 855 attribute in the entire session description MUST use a different 856 value of . When multiple values are provided, 857 the first one is associated with the value , the 858 second one with the value one higher, etc. There MUST NOT be any 859 capability number overlap between different "tcap" attributes in the 860 entire SDP. The values provided are independent of 861 similar values provided for other capability attributes, 862 i.e., they form a separate name-space for transport protocol 863 capabilities. Consecutive numbering of the values in 864 different "tcap" attributes is not required. 866 Below, we provide examples of the "a=tcap" attribute: 868 a=tcap:1 RTP/AVP 870 a=tcap:2 RTP/AVPF 872 a=tcap:3 RTP/SAVP RTP/SAVPF 874 The first one provides a capability for the "RTP/AVP" profile 875 defined in [RFC3551] and the second one provides a capability for 876 the RTP with RTCP-Based Feedback profile defined in [RFC4585]. The 877 third one provides capabilities for the "RTP/SAVP" (transport 878 capability number 3) and "RTP/SAVPF" profiles (transport protocol 879 capability number 4). 881 The ability to use a particular transport protocol is inherently 882 implied by including it in the "m=" line, regardless of whether it 883 is provided in a "tcap" attribute or not. However, if a potential 884 configuration needs to reference that transport protocol as a 885 capability, the transport protocol MUST be included explicitly in a 886 "tcap" attribute. 888 This may seem redundant (and indeed it is from the offerer's point 889 of view), however it is done to protect against intermediaries 890 (e.g. middle-boxes) that may modify "m=" lines while passing 891 unknown attributes through. If an implicit transport capability 892 were used instead (e.g. a reserved transport capability number 893 could be used to refer to the transport protocol in the "m=" 894 line), and an intermediary were to modify the transport protocol 895 in the "m=" line (e.g. to translate between plain RTP and secure 896 RTP), then the potential configuration referencing that implicit 897 transport capability may no longer be correct. With explicit 898 capabilities, we avoid this pitfall; however, the potential 899 configuration preference (see Section 3.5.1. ) may not reflect 900 that of the intermediary (which some may view as a feature). 902 Note that a transport protocol capability may be provided, 903 irrespective of whether it is referenced in a potential 904 configuration or not (just like any other capability). 906 3.4.3. Extension Capability Attributes 908 The SDP Capability Negotiation framework allows for new types of 909 capabilities to be defined as extensions and used with the general 910 capability negotiation framework. The syntax and semantics of such 911 new capability attributes are not defined here, however in order to 912 be used with potential configurations, they SHOULD allow for a 913 numeric handle to be associated with each capability. This handle 914 can be used as a reference within the potential and actual 915 configuration attributes (see Section 3.5.1. and 3.5.2. ). The 916 definition of such extension capability attributes MUST also state 917 whether they can be applied at the session-level, media-level, or 918 both. 920 3.5. Configuration Attributes 922 3.5.1. Potential Configuration Attribute 924 Potential Configurations can be expressed by use of a new Potential 925 Configuration Attribute ("a=pcfg") defined as follows: 927 a=pcfg: [] 929 where is an integer between 1 and 2^31-1 (both 930 included). 932 The "pcfg" attribute adheres to the RFC 4566 "attribute" production, 933 with an att-value defined as follows: 935 att-value = config-number [1*WSP pot-cfg-list] 936 config-number = 1*DIGIT ;defined in [RFC4234] 937 pot-cfg-list = pot-config *(1*WSP pot-config) 938 pot-config = attribute-config-list / 939 transport-protocol-config-list / 940 extension-config-list 942 The missing productions are defined below. Note that white space is 943 not permitted before the config-number. 945 The potential configuration attribute can be provided at the media- 946 level only and there can be multiple instances of it within a given 947 media description. The attribute includes a configuration number, 948 which is an integer between 1 and 2^31-1 (both included). The 949 configuration number MUST be unique within the media description 950 (i.e. it has media level scope only). The configuration number also 951 indicates the relative preference of potential configurations; lower 952 numbers are preferred over higher numbers. Consecutive numbering of 953 the configuration numbers in different "pcfg" attributes in a media 954 description is not required. 956 A potential configuration list is normally provided after the 957 configuration number. When the potential configuration list is 958 omitted, the potential configuration equals the actual 959 configuration. The potential configuration list contains one or more 960 of attribute, transport and extension configuration lists. A 961 potential configuration may for example include attribute 962 capabilities and transport capabilities, transport capabilities 963 only, or some other combination of capabilities. 965 The configuration lists generally reference one or more capabilities 966 (extension configuration lists MAY use a different format). Those 967 capabilities are (conceptually) used to construct a new internal 968 version of the SDP by use of purely syntactic add and (possibly) 969 delete operations on the original SDP (actual configuration). This 970 provides an alternative potential configuration SDP that can be used 971 by conventional SDP and offer/answer procedures if selected. 973 This document defines attribute configuration lists and transport 974 protocol configuration lists. Each of these MUST NOT be present 975 more than once in a particular potential configuration attribute. 976 Extension configuration lists can be included as well. There can be 977 more than one extension configuration list, however each particular 978 extension MUST NOT be present more than once in a given "a=pcfg" 979 attribute. Together, the various configuration lists define a 980 potential configuration. 982 There can be multiple potential configurations in a media 983 description. Each of these indicates not only a willingness, but in 984 fact a desire to use the potential configuration. 986 The example SDP below contains two potential configurations: 988 v=0 989 o=- 25678 753849 IN IP4 192.0.2.1 990 s= 991 c=IN IP4 192.0.2.1 992 t=0 0 993 m=audio 53456 RTP/AVP 0 18 994 a=tcap:1 RTP/SAVP RTP/SAVPF 995 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 996 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 997 a=pcfg:1 t=1 a=1 998 a=pcfg:2 t=2 a=1 1000 Potential configuration 1 contains a transport protocol 1001 configuration list that references transport capability 1 1002 ("RTP/SAVP") and an attribute configuration list that references 1003 attribute capability 1 ("a=crypto:..."). Potential configuration 2 1004 contains a transport protocol configuration list that references 1005 transport capability 2 ("RTP/SAVPF") and an attribute configuration 1006 list that references attribute capability 1 ("a=crypto:..."). 1008 Attribute capabilities are used in a potential configuration by use 1009 of the attribute-config-list parameter, which is defined by the 1010 following ABNF: 1012 attribute-config-list 1013 = "a=" [delete-attributes ":"] 1014 mo-att-cap-list *(BAR mo-att-cap-list) 1016 delete-attributes = DELETE ( "m" ; media attributes 1017 / "s" ; session attributes 1018 / "ms" ) ; media and session attributes 1020 mo-att-cap-list = mandatory-optional-att-cap-list | 1021 mandatory-att-cap-list | 1022 optional-att-cap-list 1024 mandatory-optional-att-cap-list = mandatory-att-cap-list 1025 "," optional-att-cap-list 1026 mandatory-att-cap-list = att-cap-list 1027 optional-att-cap-list = "[" att-cap-list "]" 1029 att-cap-list = att-cap-num *("," att-cap-num) 1030 att-cap-num = 1*DIGIT ;defined in [RFC4234] 1031 BAR = "|" 1032 DELETE = "-" 1034 Note that white space is not permitted within this production. 1036 Each attribute configuration list can optionally begin with 1037 instructions for how to handle attributes that are part of the 1038 actual configuration SDP (i.e., the "a=" lines present in the 1039 original SDP). By default, such attributes will remain as part of 1040 the configuration in question. However, if delete-attributes 1041 indicates "-m", then all attribute lines within the media 1042 description in question will be deleted (i.e., all "a=" lines under 1043 the "m=" line in question). If delete-attributes indicates "-s", 1044 then all attribute lines at the session-level will be deleted (i.e., 1045 all "a=" lines before the first "m=" line). If delete-attributes 1046 indicates "-ms", then all attribute lines within this media 1047 description ("m=" line) and all attribute lines at the session-level 1048 will be deleted. 1050 The attribute capability list comes next. It contains one or more 1051 alternative lists of attribute capabilities. The alternative 1052 attribute capability lists are separated by a vertical bar ("|"), 1053 and each list contains one or more attribute capabilities separated 1054 by commas (","). The attribute capabilities are either mandatory or 1055 optional. Mandatory attribute capabilities MUST be supported in 1056 order to use the potential configuration, whereas optional attribute 1057 capabilities MAY be supported in order to use the potential 1058 configuration. 1060 Within each attribute capability list, all the mandatory attribute 1061 capabilities (if any) are listed first, and all the optional 1062 attribute capabilities (if any) are listed last. The optional 1063 attribute capabilities are contained within a pair of square 1064 brackets ("[" and "]"). Each attribute capability is merely an 1065 attribute capability number (att-cap-num) that identifies a 1066 particular attribute capability by referring to attribute capability 1067 numbers defined above and hence MUST be between 1 and 2^31-1 (both 1068 included). The following example illustrates the above: 1070 a=pcfg:1 a=-m:1,2,[3,4]|1,7,[5] 1072 where 1074 o "a=-m:1,2,[3,4]|1,7,[5]" is the attribute configuration list 1076 o "-m" indicates to delete all attributes from the media 1077 description of the actual configuration 1079 o "1,2,[3,4]" and "1,7,[5]" are both attribute capability lists. 1080 The two lists are alternatives, since they are separated by a 1081 vertical bar above 1083 o "1", "2" and "7" are mandatory attribute capabilities 1085 o "3", "4" and "5" are optional attribute capabilities 1087 Note that in the example above, we have a single handle ("1") for 1088 the potential configuration(s), but there are actually two different 1089 potential configurations (separated by a vertical bar). This is done 1090 for message size efficiency reasons, which is especially important 1091 when we add other types of capabilities to the potential 1092 configuration. If there is a need to provide a unique handle for 1093 each, then separate "a=pcfg" attributes with different handles MUST 1094 be used instead. 1096 Each referenced attribute capability in the potential configuration 1097 will result in the corresponding attribute name and its associated 1098 value (contained inside the attribute capability) being added to the 1099 resulting potential configuration SDP. 1101 Alternative attribute capability lists are separated by a vertical 1102 bar ("|"), the scope of which extends to the next alternative (i.e., 1103 "," has higher precedence than "|"). The alternatives are ordered by 1104 preference with the most preferred listed first. In order for a 1105 recipient of the SDP (e.g., an answerer receiving this in an offer) 1106 to use this potential configuration, exactly one of the alternative 1107 lists MUST be selected in its entirety. This requires that all 1108 mandatory attribute capabilities referenced by the potential 1109 configuration are supported with the attribute values provided. 1111 Transport protocol configuration lists are included in a potential 1112 configuration by use of the transport-protocol-config-list 1113 parameter, which is defined by the following ABNF: 1115 transport-protocol-config-list = 1116 "t=" trpr-cap-num *(BAR trpr-cap-num) 1117 trpr-cap-num = 1*DIGIT ; defined in [RFC4234] 1119 Note that white space is not permitted within this production. 1121 The trpr-cap-num refers to transport protocol capability numbers 1122 defined above and hence MUST be between 1 and 2^31-1 (both 1123 included). Alternative transport protocol capabilities are separated 1124 by a vertical bar ("|"). The alternatives are ordered by preference 1125 with the most preferred listed first. If there are no transport 1126 protocol capabilities included in a potential configuration at the 1127 media level, the transport protocol information from the associated 1128 "m=" line MUST be used. In order for a recipient of the SDP (e.g., 1129 an answerer receiving this in an offer) to use this potential 1130 configuration, exactly one of the alternatives MUST be selected. 1131 This requires that the transport protocol in question is supported. 1133 In the presence of intermediaries (the existence of which may not 1134 be known), care should be taken with assuming that the transport 1135 protocol in the "m=" line will not be modified by an intermediary. 1136 Use of an explicit transport protocol capability will guard 1137 against capability negotiation implications of that. 1139 Extension capabilities can be included in a potential configuration 1140 as well by use of extension configuration lists. Such extension 1141 configuration lists MUST adhere to the following ABNF: 1143 extension-config-list= ["+"] ext-cap-name "=" 1144 ext-cap-list 1145 ext-cap-name = 1*(ALPHA / DIGIT) 1146 ext-cap-list = 1*VCHAR ; defined in [RFC4234] 1148 Note that white space is not permitted within this production. 1150 The ext-cap-name refers to the name of the extension capability and 1151 the ext-cap-list is here merely defined as a sequence of visible 1152 characters. The actual extension supported MUST refine both of these 1153 further. For extension capabilities that merely need to be 1154 referenced by a capability number, it is RECOMMENDED to follow a 1155 structure similar to what has been specified above. Unsupported or 1156 unknown potential extension configuration lists in a potential 1157 configuration attribute MUST be ignored, unless they are prefixed 1158 with the plus ("+") sign, which indicates that the extension is 1159 mandatory and MUST be supported in order to use that potential 1160 configuration. 1162 The "creq" attribute and its associated rules can be used to 1163 ensure that required extensions are supported in the first place. 1165 Potential configuration attributes can be provided at the media 1166 level only, however it is possible to reference capabilities 1167 provided at either the session or media level. There are certain 1168 semantic rules and restrictions associated with this: 1170 A (media level) potential configuration attribute in a given media 1171 description MUST NOT reference a media-level capability provided in 1172 a different media description; doing so invalidates that potential 1173 configuration (note that a potential configuration attribute can 1174 contain more than one potential configuration by use of 1175 alternatives). A potential configuration attribute can however 1176 reference a session-level capability. The semantics of doing so 1177 depends on the type of capability. In the case of transport protocol 1178 capabilities it has no particular implication. In the case of 1179 attribute capabilities however, it does. More specifically, the 1180 attribute name and value (provided within that attribute capability) 1181 will be considered part of the resulting SDP for that particular 1182 configuration at the *session* level. In other words, it will be as- 1183 if that attribute was provided with that value at the session-level 1184 in the first place. As a result, the base SDP Capability Negotiation 1185 framework REQUIRES that potential configurations do not reference 1186 any session-level attribute capabilities that contain media-level 1187 attributes (since that would place a media-level attribute at the 1188 session level). Extensions may modify this behavior, as long as it 1189 is fully backwards compatible with the base specification. 1191 Individual media streams perform capability negotiation 1192 individually, and hence it is possible that one media stream (where 1193 the attribute was part of a potential configuration) chose a 1194 configuration without a session level attribute that was chosen by 1195 another media stream. The session-level attribute however remains 1196 "active" and applies to the entire resulting potential configuration 1197 SDP. In theory, this is problematic if one or more session-level 1198 attributes either conflicts with or potentially interacts with 1199 another session-level or media-level attribute in an undefined 1200 manner. In practice, such examples seem to be rare (at least with 1201 the currently defined SDP attributes). 1203 A related set of problems can occur if we need coordination 1204 between session-level attributes from multiple media streams in 1205 order for a particular functionality to work. The grouping 1206 framework [RFC3388] is an example of this. If we use the SDP 1207 Capability Negotiation framework to select a session-level group 1208 attribute (provided as an attribute capability), and we require 1209 two media descriptions to do this consistently, we could have a 1210 problem. The FEC grouping semantics [RFC4756] is one example where 1211 this in theory could cause problems, however in practice, it is 1212 unclear that there is a significant problem with the currently 1213 defined grouping semantics. 1215 Resolving the above issues in general requires inter-media stream 1216 constraints and synchronized potential configuration processing; 1217 this would add considerable complexity to the overall solution. In 1218 practice, with the currently defined SDP attributes, it does not 1219 seem to be a significant problem, and hence the core SDP Capability 1220 Negotiation solution does not provide a solution to this issue. 1221 Instead, it is RECOMMENDED that use of session-level attributes in a 1222 potential configuration is avoided when possible, and when not, that 1223 such use is examined closely for any potential interaction issues. 1224 If interaction is possible, the entity generating the SDP SHOULD NOT 1225 assume that well-defined operation will occur at the receiving 1226 entity. 1228 The session-level operation of extension capabilities is undefined: 1229 Consequently, each new session-level extension capability defined 1230 MUST specify the implication of making it part of a configuration at 1231 the media level. 1233 Below, we provide an example of the "a=pcfg" attribute in a complete 1234 media description in order to properly indicate the supporting 1235 attributes: 1237 v=0 1238 o=- 25678 753849 IN IP4 192.0.2.1 1239 s= 1240 c=IN IP4 192.0.2.1 1241 t=0 0 1242 m=audio 53456 RTP/AVPF 0 18 1243 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 1244 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 1245 a=tcap:1 RTP/AVPF RTP/AVP RTP/SAVP RTP/SAVPF 1246 a=pcfg:1 t=4|3 a=1 1247 a=pcfg:8 t=1|2 1249 We have two potential configuration attributes listed here. The 1250 first one (and most preferred, since its configuration number is 1251 "1") indicates that either of the profiles RTP/SAVPF or RTP/SAVP 1252 (specified by the transport protocol capability numbers 4 and 3) can 1253 be supported with attribute capability 1 (the "crypto" attribute); 1254 RTP/SAVPF is preferred over RTP/SAVP since its capability number (4) 1255 is listed first in the preferred potential configuration. Note that 1256 although we have a single potential configuration attribute and 1257 associated handle, we have two potential configurations. 1259 The second potential configuration attribute indicates that the 1260 RTP/AVPF or RTP/AVP profiles can be used, with RTP/AVPF being the 1261 preferred one. This non secure RTP alternative is the less preferred 1262 one since its configuration number is "8". Again, note that we have 1263 two potential configurations here and hence a total of four 1264 potential configurations in the SDP above. 1266 3.5.2. Actual Configuration Attribute 1268 The actual configuration attribute identifies which of the potential 1269 configurations from an offer SDP was selected and used as the actual 1270 configuration to generate an answer SDP. This is done by including 1271 the configuration number and the configuration lists (if any) from 1272 the offer that were selected and used by the answerer in his 1273 offer/answer procedure as follows: 1275 o A selected attribute configuration MUST include the delete- 1276 attributes and the known and supported parameters from the 1277 selected alternative mo-att-cap-list (i.e., containing all 1278 mandatory and all known and supported optional capability numbers 1279 from the potential configuration). If delete-attributes were not 1280 included in the potential configuration, they will of course not 1281 be present here either. 1283 o A selected transport protocol configuration MUST include the 1284 selected transport protocol capability number. 1286 o A selected potential extension configuration MUST include the 1287 selected extension configuration parameters as specified for that 1288 particular extension. 1290 o When a configuration list contains alternatives (separated by 1291 "|"), the selected configuration only MUST be provided. 1293 Note that the selected configuration number and all selected 1294 capability numbers used in the actual configuration attribute refer 1295 to those from the offer; not the answer. 1297 The answer may for example include capabilities as well to inform 1298 the offerer of the answerers capabilities above and beyond the 1299 negotiated configuration. The actual configuration attribute does 1300 not refer to any of those answer capabilities though. 1302 The Actual Configuration Attribute ("a=acfg") is defined as follows: 1304 a=acfg: [] 1306 where is an integer between 1 and 2^31-1 (both 1307 included). 1309 The "acfg" attribute adheres to the RFC 4566 "attribute" production, 1310 with an att-value defined as follows: 1312 att-value = config-number [1*WSP sel-cfg-list] 1313 ;config-number defined in Section 3.5.1. 1314 sel-cfg-list = sel-cfg *(1*WSP sel-cfg) 1315 sel-cfg = sel-attribute-config / 1316 sel-transport-protocol-config / 1317 sel-extension-config 1319 sel-attribute-config = 1320 "a=" [delete-attributes ":"] mo-att-cap-list 1321 ; defined in Section 3.5.1. 1323 sel-transport-protocol-config = 1324 "t=" trpr-cap-num ; defined in Section 3.5.1. 1326 sel-extension-config = 1327 ext-cap-name "=" 1*VCHAR ; defined in Section 3.5.1. 1329 Note that white space is not permitted before the config-number. 1331 The actual configuration ("a=acfg") attribute can be provided at the 1332 media-level only. There MUST NOT be more than one occurrence of an 1333 actual configuration attribute within a given media description. 1335 Below, we provide an example of the "a=acfg" attribute (building on 1336 the previous example with the potential configuration attribute): 1338 v=0 1339 o=- 24351 621814 IN IP4 192.0.2.2 1340 s= 1341 c=IN IP4 192.0.2.2 1342 t=0 0 1343 m=audio 54568 RTP/SAVPF 0 1344 a=crypto:1 AES_CM_128_HMAC_SHA1_32 1345 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 1346 a=acfg:1 t=4 a=1 1348 It indicates that the answerer used an offer consisting of potential 1349 configuration number 1 with transport protocol capability 4 from the 1350 offer (RTP/SAVPF) and attribute capability 1 (the "crypto" 1351 attribute). The answerer includes his own "crypto" attribute as 1352 well. 1354 3.6. Offer/Answer Model Extensions 1356 In this section, we define extensions to the offer/answer model 1357 defined in [RFC3264] to allow for potential configurations to be 1358 included in an offer, where they constitute alternative offers that 1359 may be accepted by the answerer instead of the actual 1360 configuration(s) included in the "m=" line(s). 1362 The procedures defined in the following subsections apply to both 1363 unicast and multicast streams. 1365 3.6.1. Generating the Initial Offer 1367 An offerer that wants to use the SDP Capability Negotiation defined 1368 in this document MUST include the following in the offer: 1370 o Zero or more attribute capability attributes. There MUST be an 1371 attribute capability attribute ("a=acap") as defined in Section 1372 3.4.1. for each attribute name and associated value (if any) that 1373 needs to be indicated as a capability in the offer. Attribute 1374 capabilities may be included irrespective of whether they are 1375 referenced by a potential configuration or not. 1377 Session-level attributes and associated values MUST be provided 1378 in attribute capabilities at the session-level only, whereas 1379 media-level attributes and associated values can be provided in 1380 attribute capabilities at either the media-level or session- 1381 level. Attributes that are allowed at either the session- or 1382 media-level can be provided in attribute capabilities at either 1383 level. 1385 o Zero or more transport protocol capability attributes. There MUST 1386 be transport protocol capabilities as defined in Section 3.4.2. 1387 with values for each transport protocol that needs to be 1388 indicated as a capability in the offer. Transport protocol 1389 capabilities may be included irrespective of whether they are 1390 referenced by a potential configuration or not. 1392 Transport protocol capabilities that apply to multiple media 1393 descriptions SHOULD be provided at the session-level whereas 1394 transport protocol capabilities that apply to a specific media 1395 description ("m=" line) only, SHOULD be provided within that 1396 particular media description. In either case, there MUST NOT be 1397 more than a single "a=tcap" attribute at the session-level and a 1398 single "a=tcap" attribute in each media description. 1400 o Zero or more extension capability attributes. There MUST be one 1401 or more extension capability attributes (as outlined in Section 1402 3.4.3. ) for each extension capability that is referenced by a 1403 potential configuration. Extension capability attributes that are 1404 not referenced by a potential configuration can be provided as 1405 well. 1407 o Zero or more potential configuration attributes. There MUST be 1408 one or more potential configuration attributes ("a=pcfg"), as 1409 defined in Section 3.5.1. , in each media description where 1410 alternative potential configurations are to be negotiated. Each 1411 potential configuration attribute MUST adhere to the rules 1412 provided in Section 3.5.1. and the additional rules provided 1413 below. 1415 If the offerer requires support for more or extensions (besides the 1416 base protocol defined here), then the offerer MUST include one or 1417 more "a=creq" attributes as follows: 1419 o If support for one or more capability negotiation extensions is 1420 required for the entire session description, then option tags for 1421 those extensions MUST be included in a single session-level 1422 "creq" attribute. 1424 o For each media description that requires support for one or more 1425 capability negotiation extensions not listed at the session- 1426 level, a single "creq" attribute containing all the required 1427 extensions for that media description MUST be included within the 1428 media description (in accordance with Section 3.3.2. ). 1430 Note that extensions that only need to be supported by a particular 1431 potential configuration can use the "mandatory" extension prefix 1432 ("+") within the potential configuration (see Section 3.5.1. ). 1434 The offerer SHOULD furthermore include the following: 1436 o A supported capability negotiation extension attribute ("a=csup") 1437 at the session-level and/or media-level as defined in Section 1438 3.3.2. for each capability negotiation extension supported by the 1439 offerer and not included in a corresponding "a=creq" attribute 1440 (i.e., at the session-level or in the same media description). 1441 Option tags provided in a "a=csup" attribute at the session-level 1442 indicate extensions supported for the entire session description, 1443 whereas option tags provided in a "a=csup" attribute in a media 1444 description indicate extensions supported for that particular 1445 media description only. 1447 Capabilities provided in an offer merely indicate what the offerer 1448 is capable of doing. They do not constitute a commitment or even an 1449 indication to use them. In contrast, each potential configuration 1450 constitutes an alternative offer that the offerer would like to use. 1451 The potential configurations MUST be used by the answerer to 1452 negotiate and establish the session. 1454 The offerer MUST include one or more potential configuration 1455 attributes ("a=pcfg") in each media description where the offerer 1456 wants to provide alternative offers (in the form of potential 1457 configurations). Each potential configuration attribute in a given 1458 media description MUST contain a unique configuration number and one 1459 or more potential configuration lists, as described in Section 1460 3.5.1. Each potential configuration list MUST refer to capabilities 1461 that are provided at the session-level or within that particular 1462 media description; otherwise, the potential configuration is 1463 considered invalid. The base SDP Capability Negotiation framework 1464 REQUIRES that potential configurations do not reference any session- 1465 level attribute capabilities that contain media-level only 1466 attributes, however extensions may modify this behavior, as long as 1467 it is fully backwards compatible with the base specification. 1468 Furthermore, it is RECOMMENDED that potential configurations avoid 1469 use of session-level capabilities whenever possible; refer to 1470 Section 3.5.1. 1472 The current actual configuration is included in the "m=" line (as 1473 defined by [RFC3264]) and any associated parameters for the media 1474 description (e.g., attribute ("a=") and bandwidth ("b=") lines). 1475 Note that the actual configuration is by default the least-preferred 1476 configuration, and hence the answerer will seek to negotiate use of 1477 one of the potential configurations instead. If the offerer wishes a 1478 different preference for the actual configuration, the offerer MUST 1479 include a corresponding potential configuration with the relevant 1480 configuration number (which indicates the relative preference 1481 between potential configurations); this corresponding potential 1482 configuration should simply duplicate the actual configuration. 1484 This can either be done implicitly (by not referencing any 1485 capabilities), or explicitly (by providing and using capabilities 1486 for the transport protocol and all the attributes that are part of 1487 the actual configuration). The latter may help detect 1488 intermediaries that modify the actual configuration but are not 1489 SDP Capability Negotiation aware. 1491 Per [RFC3264], once the offerer generates the offer, he must be 1492 prepared to receive incoming media in accordance with that offer. 1493 That rule applies here as well, but for the actual configurations 1494 provided in the offer only: Media received by the offerer according 1495 to one of the potential configurations MAY be discarded, until the 1496 offerer receives an answer indicating what the actual selected 1497 configuration is. Once that answer is received, incoming media MUST 1498 be processed in accordance with the actual selected configuration 1499 indicated and the answer received (provided the offer/answer 1500 exchange completed successfully). 1502 The above rule assumes that the offerer can determine whether 1503 incoming media adheres to the actual configuration offered or one of 1504 the potential configurations instead; this may not always be the 1505 case. If the offerer wants to ensure he does not play out any 1506 garbage, the offerer SHOULD discard all media received before the 1507 answer SDP is received. Conversely, if the offerer wants to avoid 1508 clipping, he should attempt to play any incoming media as soon as it 1509 is received (at the risk of playing out garbage). For further 1510 details, please refer to Section 3.9. 1512 3.6.2. Generating the Answer 1514 When receiving an offer, the answerer MUST check for the presence of 1515 a required capability negotiation extension attribute ("a=creq") 1516 provided at the session level. If one is found, then capability 1517 negotiation MUST be performed. If none is found, then the answerer 1518 MUST check each offered media description for the presence of a 1519 required capability negotiation extension attribute ("a=creq") and 1520 one or more potential configuration attributes ("a=pcfg"). 1521 Capability negotiation MUST be performed for each media description 1522 where either of those is present in accordance with the procedures 1523 described below. 1525 The answerer MUST first ensure that it supports any required 1526 capability negotiation extensions: 1528 o If a session-level "creq" attribute is provided, and it contains 1529 an option-tag that the answerer does not support, then the 1530 answerer MUST NOT use any of the potential configuration 1531 attributes provided for any of the media descriptions. Instead, 1532 the normal offer/answer procedures MUST continue as per 1533 [RFC3264]. Furthermore, the answerer MUST include a session-level 1534 supported capability negotiation extensions attribute ("a=csup") 1535 with option tags for the capability negotiation extensions 1536 supported by the answerer. 1538 o If a media-level "creq" attribute is provided, and it contains an 1539 option tag that the answerer does not support, then the answerer 1540 MUST NOT use any of the potential configuration attributes 1541 provided for that particular media description. Instead, the 1542 offer/answer procedures for that media description MUST continue 1543 as per [RFC3264] (SDP Capability Negotiation is still performed 1544 for other media descriptions in the SDP). Furthermore, the 1545 answerer MUST include a supported capability negotiation 1546 extensions attribute ("a=csup") in that media description with 1547 option tags for the capability negotiation extensions supported 1548 by the answerer for that media description. 1550 Assuming all required capability negotiation extensions are 1551 supported, the answerer now proceeds as follows. 1553 For each media description where capability negotiation is to be 1554 performed (i.e. all required capability negotiation extensions are 1555 supported and at least one valid potential configuration attribute 1556 is present), the answerer MUST attempt to perform capability 1557 negotiation by using the most preferred potential configuration that 1558 is valid to the answerer. A potential configuration is valid to the 1559 answerer if: 1561 1. It is in accordance with the syntax and semantics provided in 1562 Section 3.5.1. 1564 2. It contains a configuration number that is unique within that 1565 media description. 1567 3. All attribute capabilities referenced by the potential 1568 configuration are valid themselves (as defined in Section 3.4.1. 1569 ) and each of them is provided either at the session-level or 1570 within this particular media description. For session-level 1571 attribute capabilities referenced, the attributes contained 1572 inside them MUST NOT be media-level only attributes. 1574 4. All transport protocol capabilities referenced by the potential 1575 configuration are valid themselves (as defined in Section 3.4.2. 1576 ) and each of them is furthermore provided either at the session- 1577 level or within this particular media description. 1579 5. All extension capabilities referenced by the potential 1580 configuration and supported by the answerer are valid themselves 1581 (as defined by that particular extension) and each of them are 1582 furthermore provided either at the session-level or within this 1583 particular media description. Unknown or unsupported extension 1584 capabilities MUST be ignored, unless they are prefixed with the 1585 plus ("+") sign, which indicates that the extension MUST be 1586 supported in order to use that potential configuration. If the 1587 extension is not supported, that potential configuration is not 1588 valid to the answerer. 1590 The most preferred valid potential configuration in a media 1591 description is the valid potential configuration with the lowest 1592 configuration number. The answerer MUST now process the offer for 1593 that media stream based on the most preferred valid potential 1594 configuration. Conceptually, this entails the answerer constructing 1595 an (internal) offer that consists of the actual configuration offer 1596 SDP, with the following changes for each media stream offered: 1598 o If a transport protocol capability is included in the potential 1599 configuration, then it replaces the transport protocol provided 1600 in the "m=" line for that media description. 1602 o If attribute capabilities are present with a delete-attributes 1603 session indication ("-s"), then all session-level attributes from 1604 the actual configuration SDP MUST be deleted in accordance with 1605 the procedures in Section 3.5.1. If attribute capabilities are 1606 present with a delete-attributes media indication ("-m"), then 1607 all attributes from the actual configuration SDP inside this 1608 media description MUST be deleted. 1610 o If a session-level attribute capability is included, the 1611 attribute (and its associated value, if any) contained in it MUST 1612 be added to the resulting SDP. All such added session-level 1613 attributes MUST be listed before the session-level attributes 1614 that were initially present in the SDP. Furthermore, the added 1615 session-level attributes MUST be added in the order they were 1616 provided in the potential configuration (see also Section 3.5.1. 1617 ). 1619 This allows for attributes with implicit preference ordering 1620 to be added in the desired order; the "crypto" attribute 1621 [RFC4568] is one such example. 1623 o If a media-level attribute capability is included, then the 1624 attribute (and its associated value, if any) MUST be added to the 1625 resulting SDP within the media description in question. All such 1626 added media-level attributes MUST be listed before the media- 1627 level attributes that were initially present in the SDP in the 1628 media description in question. Furthermore, the added media-level 1629 attributes MUST be added in the order they were provided in the 1630 potential configuration (see also Section 3.5.1. ). 1632 o If a supported extension capability is included, then it MUST be 1633 processed in accordance with the rules provided for that 1634 particular extension capability. 1636 Note that a transport protocol from the potential configuration 1637 replaces the transport protocol in the actual configuration, but an 1638 attribute capability from the potential configuration is simply 1639 added to the actual configuration. In some cases, this can result in 1640 having one or more meaningless attributes in the resulting potential 1641 configuration SDP, or worse, ambiguous or potentially even illegal 1642 attributes. Use of delete-attributes for the session and/or media 1643 level attributes MUST be done to avoid such scenarios. Nevertheless, 1644 it is RECOMMENDED that implementations ignore meaningless attributes 1645 that may result from potential configurations. 1647 For example, if the actual configuration was using Secure RTP and 1648 included an "a=crypto" attribute for the SRTP keying material, 1649 then use of a potential configuration that uses plain RTP would 1650 make the "crypto" attribute meaningless. The answerer may or may 1651 not ignore such a meaningless attribute. The offerer can here 1652 ensure correct operation by using delete-attributes to remove the 1653 crypto attribute (but will then need to provide attribute 1654 capabilities to reconstruct the SDP with the necessary attributes 1655 deleted, e.g. rtpmaps). 1657 Please refer to Section 3.6.2.1. for examples of how the answerer 1658 may conceptually "see" the resulting offered alternative potential 1659 configurations. 1661 The answerer MUST check that he supports all mandatory attribute 1662 capabilities from the potential configuration (if any), the 1663 transport protocol capability (if any) from the potential 1664 configuration, and all mandatory extension capabilities from the 1665 potential configuration (if any). If he does not, the answerer MUST 1666 proceed to the second-most preferred valid potential configuration 1667 for the media description, etc. 1669 o In the case of attribute capabilities, support implies that the 1670 attribute name contained in the capability is supported and it 1671 can (and will) be negotiated successfully in the offer/answer 1672 exchange with the value provided. This does not necessarily imply 1673 that the value provided is supported in its entirety. For 1674 example, the "a=fmtp" parameter is often provided with one or 1675 more values in a list, where the offerer and answerer negotiate 1676 use of some subset of the values provided. Other attributes may 1677 include mandatory and optional parts to their values; support for 1678 the mandatory part is all that is required here. 1680 A side-effect of the above rule is that whenever an "fmtp" or 1681 "rtpmap" parameter is provided as a mandatory attribute 1682 capability, the corresponding media format (codec) must be 1683 supported and use of it negotiated successfully. If this is 1684 not the offerer's intent, the corresponding attribute 1685 capabilities must be listed as optional instead. 1687 o In the case of transport protocol capabilities, support implies 1688 that the transport protocol contained in the capability is 1689 supported and the transport protocol can (and will) be negotiated 1690 successfully in the offer/answer exchange. 1692 o In the case of extension capabilities, the extension MUST define 1693 the rules for when the extension capability is considered 1694 supported and those rules MUST be satisfied. 1696 If the answerer has exhausted all potential configurations for the 1697 media description, without finding a valid one that is also 1698 supported, then the answerer MUST process the offered media stream 1699 based on the actual configuration plus any session-level attributes 1700 added by a valid and supported potential configuration from another 1701 media description in the offered SDP. 1703 The above process describes potential configuration selection as a 1704 per media stream process. Inter-media stream coordination of 1705 selected potential configurations however is required in some cases. 1706 First of all, session-level attributes added by a potential 1707 configuration for one media description MUST NOT cause any problems 1708 for potential configurations selected by other media descriptions in 1709 the offer SDP. If the session-level attributes are mandatory, then 1710 those session-level attributes MUST furthermore be supported by the 1711 session as a whole (i.e., all the media descriptions if relevant). 1712 As mentioned earlier, this adds additional complexity to the overall 1713 processing and hence it is RECOMMENDED not to use session-level 1714 attribute capabilities in potential configurations, unless 1715 absolutely necessary. 1717 Once the answerer has selected a valid and supported offered 1718 potential configuration for all of the media streams (or has fallen 1719 back to the actual configuration plus any added session attributes), 1720 the answerer MUST generate a valid answer SDP based on the selected 1721 potential configuration SDP, as "seen" by the answerer (see Section 1722 3.6.2.1. for examples). Furthermore, if the answerer selected one of 1723 the potential configurations in a media description, the answerer 1724 MUST include an actual configuration attribute ("a=acfg") within 1725 that media description. The "a=acfg" attribute MUST identify the 1726 configuration number for the selected potential configuration as 1727 well as the actual parameters that were used from that potential 1728 configuration; if the potential configuration included alternatives, 1729 the selected alternatives only MUST be included. Only the known and 1730 supported parameters will be included. Unknown or unsupported 1731 parameters MUST NOT be included in the actual configuration 1732 attribute. In the case of attribute capabilities, only the known and 1733 supported capabilities are included; unknown or unsupported 1734 attribute capabilities MUST NOT be included. 1736 If the answerer supports one or more capability negotiation 1737 extensions that were not included in a required capability 1738 negotiation extensions attribute in the offer, then the answerer 1739 SHOULD furthermore include a supported capability negotiation 1740 attribute ("a=csup") at the session-level with option tags for the 1741 extensions supported across media streams. Also, if the answerer 1742 supports one or more capability negotiation extensions for 1743 particular media descriptions only, then a supported capability 1744 negotiation attribute with those option-tags SHOULD be included 1745 within each relevant media description. 1747 The offerer's originally provided actual configuration is contained 1748 in the offer media description's "m=" line (and associated 1749 parameters). The answerer MAY send media to the offerer in 1750 accordance with that actual configuration as soon as it receives the 1751 offer, however it MUST NOT send media based on that actual 1752 configuration if it selects an alternative potential configuration. 1753 If the answerer selects one of the potential configurations, then 1754 the answerer MAY immediately start to send media to the offerer in 1755 accordance with the selected potential configuration, however the 1756 offerer MAY discard such media or play out garbage until the offerer 1757 receives the answer. Please refer to section 3.9. for additional 1758 considerations and possible alternative solutions outside the base 1759 SDP Capability Negotiation framework. 1761 If the offerer selected a potential configuration instead of the 1762 actual configuration, then it is RECOMMENDED that the answerer sends 1763 back an answer SDP as soon as possible. This minimizes the risk of 1764 having media discarded or played out as garbage by the offerer. In 1765 the case of SIP [RFC3261] without any extensions, this implies that 1766 if the offer was received in an INVITE message, then the answer SDP 1767 should be provided in the first non-100 provisional response sent 1768 back (per RFC3261, the answer would need to be repeated in the 200 1769 response as well, unless a relevant extension such as [RFC3262] is 1770 being used). 1772 3.6.2.1. Example Views of Potential Configurations 1774 The following examples illustrate how the answerer may conceptually 1775 "see" a potential configuration. Consider the following offered SDP: 1777 v=0 1778 o=alice 2891092738 2891092738 IN IP4 lost.example.com 1779 s= 1780 t=0 0 1781 c=IN IP4 lost.example.com 1782 a=tool:foo 1783 a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 1784 a=tcap:1 RTP/SAVP RTP/AVP 1785 m=audio 59000 RTP/AVP 98 1786 a=rtpmap:98 AMR/8000 1787 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32 1788 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 1789 a=pcfg:1 t=1 a=1|2 1790 m=video 52000 RTP/AVP 31 1791 a=rtpmap:31 H261/90000 1792 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 1793 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 1794 a=pcfg:1 t=1 a=1|3 1796 This particular SDP offers an audio stream and a video stream, each 1797 of which can either use plain RTP (actual configuration) or secure 1798 RTP (potential configuration). Furthermore, two different keying 1799 mechanisms are offered, namely session-level Key Management 1800 Extensions using MIKEY (attribute capability 1) and media-level SDP 1801 Security Descriptions (attribute capabilities 2 and 3). There are 1802 several potential configurations here, however, below we show the 1803 one the answerer "sees" when using potential configuration 1 for 1804 both audio and video, and furthermore using attribute capability 1 1805 (MIKEY) for both (we have removed all the capability negotiation 1806 attributes for clarity): 1808 v=0 1809 o=alice 2891092738 2891092738 IN IP4 lost.example.com 1810 s= 1811 t=0 0 1812 c=IN IP4 lost.example.com 1813 a=tool:foo 1814 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 1815 m=audio 59000 RTP/SAVP 98 1816 a=rtpmap:98 AMR/8000 1817 m=video 52000 RTP/SAVP 31 1818 a=rtpmap:31 H261/90000 1820 Note that the transport protocol in the media descriptions indicate 1821 use of secure RTP. 1823 Below, we show the offer the answerer "sees" when using potential 1824 configuration 1 for both audio and video and furthermore using 1825 attribute capability 2 and 3 respectively (SDP security 1826 descriptions) for the audio and video stream - note the order in 1827 which the resulting attributes are provided: 1829 v=0 1830 o=alice 2891092738 2891092738 IN IP4 lost.example.com 1831 s= 1832 t=0 0 1833 c=IN IP4 lost.example.com 1834 a=tool:foo 1835 m=audio 59000 RTP/SAVP 98 1836 a=crypto:1 AES_CM_128_HMAC_SHA1_32 1837 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 1838 a=rtpmap:98 AMR/8000 1839 m=video 52000 RTP/SAVP 31 1840 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1841 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 1842 a=rtpmap:31 H261/90000 1844 Again, note that the transport protocol in the media descriptions 1845 indicate use of secure RTP. 1847 And finally, we show the offer the answerer "sees" when using 1848 potential configuration 1 with attribute capability 1 (MIKEY) for 1849 the audio stream, and potential configuration 1 with attribute 1850 capability 3 (SDP security descriptions) for the video stream: 1852 v=0 1853 o=alice 2891092738 2891092738 IN IP4 lost.example.com 1854 s= 1855 t=0 0 1856 c=IN IP4 lost.example.com 1857 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 1858 a=tool:foo 1859 m=audio 59000 RTP/SAVP 98 1860 a=rtpmap:98 AMR/8000 1861 m=video 52000 RTP/SAVP 31 1862 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1863 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 1864 a=rtpmap:31 H261/90000 1866 3.6.3. Offerer Processing of the Answer 1868 When the offerer attempted to use SDP Capability Negotiation in the 1869 offer, the offerer MUST examine the answer for actual use of SDP 1870 Capability Negotiation. 1872 For each media description where the offerer included a potential 1873 configuration attribute ("a=pcfg"), the offerer MUST first examine 1874 that media description for the presence of an actual configuration 1875 attribute ("a=acfg"). If an actual configuration attribute is not 1876 present in a media description, then the offerer MUST process the 1877 answer SDP for that media stream per the normal offer/answer rules 1878 defined in [RFC3264]. However, if one is found, the offerer MUST 1879 instead process the answer as follows: 1881 o The actual configuration attribute specifies which of the 1882 potential configurations was used by the answerer to generate the 1883 answer for this media stream. This includes all the supported 1884 attribute capabilities and the transport capabilities referenced 1885 by the potential configuration selected, where the attribute 1886 capabilities have any associated delete-attributes included. 1887 Extension capabilities supported by the answerer are included as 1888 well. 1890 o The offerer MUST now process the answer in accordance with the 1891 rules in [RFC3264], except that it must be done as if the offer 1892 consisted of the selected potential configuration instead of the 1893 original actual configuration, including any transport protocol 1894 changes in the media ("m=") line(s), attributes added and deleted 1895 by the potential configuration at the media and session level, 1896 and any extensions used. 1898 If the offer/answer exchange was successful, and if the answerer 1899 selected one of the potential configurations from the offer as the 1900 actual configuration, and the selected potential configuration 1901 differs from the actual configuration in the offer (the "m=", "a=", 1902 etc. lines), then the offerer SHOULD initiate another offer/answer 1903 exchange. This second offer/answer exchange will not modify the 1904 session in any way, however it will help intermediaries (e.g. 1905 middleboxes), that look at the SDP but do not support the capability 1906 negotiation extensions, understand the details of the media 1907 stream(s) that were actually negotiated. This new offer MUST contain 1908 the selected potential configuration as the actual configuration, 1909 i.e., with the actual configuration used in the "m=" line and any 1910 other relevant attributes, bandwidth parameters, etc. 1912 Note that, per normal offer/answer rules, the second offer/answer 1913 exchange still needs to update the version number in the "o=" line 1914 (( in [RFC4566]). Attribute lines carrying keying 1915 material SHOULD repeat the keys from the previous offer, unless re- 1916 keying is necessary, e.g. due to a previously forked SIP INVITE 1917 request. Please refer to Section 3.12. for additional considerations 1918 related to intermediaries. 1920 3.6.4. Modifying the Session 1922 Capabilities and potential configurations may be included in 1923 subsequent offers as defined in [RFC3264], Section 8. The procedure 1924 for doing so is similar to that described above with the answer 1925 including an indication of the actual selected configuration used by 1926 the answerer. 1928 If the answer indicates use of a potential configuration from the 1929 offer, then the guidelines provided in Section 3.6.3. for doing a 1930 second offer/answer exchange using that potential configuration as 1931 the actual configuration apply. 1933 3.7. Interactions with ICE 1935 Interactive Connectivity Establishment (ICE) [ICE] provides a 1936 mechanism for verifying connectivity between two endpoints by 1937 sending STUN messages directly between the media endpoints. The 1938 basic ICE specification [ICE] is defined to support UDP-based 1939 connectivity only, however it allows for extensions to support other 1940 transport protocols, such as TCP, which is being specified in 1941 [ICETCP]. ICE defines a new "a=candidate" attribute, which, among 1942 other things, indicates the possible transport protocol(s) to use 1943 and then associates a priority with each of them. The most preferred 1944 transport protocol that *successfully* verifies connectivity will 1945 end up being used. 1947 When using ICE, it is thus possible that the transport protocol that 1948 will be used differs from what is specified in the "m=" line. Since 1949 both ICE and SDP Capability Negotiation may specify alternative 1950 transport protocols, there is a potentially unintended interaction 1951 when using these together. 1953 We provide the following guidelines for addressing that. 1955 There are two basic scenarios to consider: 1957 1) A particular media stream can run over different transport 1958 protocols (e.g. UDP, TCP, or TCP/TLS), and the intent is simply to 1959 use the one that works (in the preference order specified). 1961 2) A particular media stream can run over different transport 1962 protocols (e.g. UDP, TCP, or TCP/TLS) and the intent is to have the 1963 negotiation process decide which one to use (e.g. T.38 over TCP or 1964 UDP). 1966 In scenario 1, there should be ICE "a=candidate" attributes for UDP, 1967 TCP, etc. but otherwise nothing special in the potential 1968 configuration attributes to indicate the desire to use different 1969 transport protocols (e.g. UDP, or TCP). The ICE procedures 1970 essentially cover the capability negotiation required (by having the 1971 answerer select something it supports and then use of trial and 1972 error connectivity checks). 1974 Scenario 2 does not require a need to support or use ICE. Instead, 1975 we simply use transport protocol capabilities and potential 1976 configuration attributes to indicate the desired outcome. 1978 The scenarios may be combined, e.g. by offering potential 1979 configuration alternatives where some of them can support one 1980 transport protocol only (e.g. UDP), whereas others can support 1981 multiple transport protocols (e.g. UDP or TCP). In that case, there 1982 is a need for tight control over the ICE candidates that will be 1983 used for a particular configuration, yet the actual configuration 1984 may want to use all of the ICE candidates. In that case, the ICE 1985 candidate attributes can be defined as attribute capabilities and 1986 the relevant ones should then be included in the proper potential 1987 configurations (for example candidate attributes for UDP only for 1988 potential configurations that are restricted to UDP, whereas there 1989 could be candidate attributes for UDP, TCP, and TCP/TLS for 1990 potential configurations that can use all three). Furthermore, use 1991 of the delete-attributes in a potential configuration can be used to 1992 ensure that ICE will not end up using a transport protocol that is 1993 not desired for a particular configuration. 1995 SDP Capability Negotiation recommends use of a second offer/answer 1996 exchange when the negotiated actual configuration was one of the 1997 potential configurations from the offer. Similarly, ICE requires use 1998 of a second offer/answer exchange if the chosen candidate is not the 1999 same as the one in the m/c-line from the offer. When ICE and 2000 capability negotiation are used at the same time, the two secondary 2001 offer/answer exchanges should be combined to a single one. 2003 3.8. Interactions with SIP Option Tags 2005 SIP [RFC3261] allows for SIP extensions to define a SIP option tag 2006 that identifies the SIP extension. Support for one or more such 2007 extensions can be indicated by use of the SIP Supported header, and 2008 required support for one or more such extensions can be indicated by 2009 use of the SIP Require header. The "a=csup" and "a=creq" attributes 2010 defined by the SDP Capability Negotiation framework are similar, 2011 except that support for these two attributes by themselves cannot be 2012 guaranteed (since they are specified as extensions to the SDP 2013 specification [RFC4566] itself). 2015 SIP extensions with associated option tags can introduce 2016 enhancements to not only SIP, but also SDP. This is for example the 2017 case for SIP preconditions defined in [RFC3312]. When using SDP 2018 Capability Negotiation, some potential configurations may include 2019 certain SDP extensions, whereas others may not. Since the purpose of 2020 the SDP Capability Negotiation is to negotiate a session based on 2021 the features supported by both sides, use of the SIP Require header 2022 for such extensions may not produce the desired result. For example, 2023 if one potential configuration requires SIP preconditions support, 2024 another does not, and the answerer does not support preconditions, 2025 then use of the SIP Require header for preconditions would result in 2026 a session failure, in spite of the fact that a valid and supported 2027 potential configuration was included in the offer. 2029 In general, this can be alleviated by use of mandatory and optional 2030 attribute capabilities in a potential configuration. There are 2031 however cases where permissible SDP values are tied to the use of 2032 the SIP Require header. SIP preconditions [RFC3312] is one such 2033 example, where preconditions with a "mandatory" strength-tag can 2034 only be used when a SIP Require header with the SIP option tag 2035 "precondition" is included. Future SIP extensions that may want to 2036 use the SDP Capability Negotiation framework should avoid such 2037 coupling. 2039 3.9. Processing Media before Answer 2041 The offer/answer model requires an offerer to be able to receive 2042 media in accordance with the offer prior to receiving the answer. 2043 This property is retained with the SDP Capability Negotiation 2044 extensions defined here, but only when the actual configuration is 2045 selected by the answerer. If a potential configuration is chosen, it 2046 is permissible for the offerer to not process any media received 2047 before the answer is received. This may lead to clipping. 2048 Consequently, the SDP Capability Negotiation framework recommends 2049 sending back an answer SDP as soon as possible. 2051 The issue can be resolved by introducing a three-way handshake. In 2052 the case of SIP, this can for example be done by defining a 2053 precondition [RFC3312] for capability negotiation (or use an 2054 existing precondition that is known to generate a second 2055 offer/answer exchange before proceeding with the session). However, 2056 preconditions are often viewed as complicated to implement and they 2057 may add to overall session establishment delay by requiring an extra 2058 offer/answer exchange. 2060 An alternative three-way handshake can be performed by use of ICE 2061 [ICE]. When ICE is being used, and the answerer receives a STUN 2062 Binding Request for any one of the accepted media streams from the 2063 offerer, the answerer knows the offer has received his answer. At 2064 that point, the answerer knows that the offerer will be able to 2065 process incoming media according to the negotiated configuration and 2066 hence he can start sending media without the risk of the offerer 2067 either discarding it or playing garbage. 2069 In some use cases a three-way handshake is not needed. An example is 2070 when the offerer does not need information from the answer, such as 2071 keying material in the SDP, in order to process incoming media. The 2072 SDP Capability Negotiation framework does not define any such 2073 solutions, however extensions may do so. For example, one technique 2074 proposed for best-effort SRTP in [BESRTP] is to provide different 2075 RTP payload type mappings for different transport protocols used, 2076 outside of the actual configuration, while still allowing them to be 2077 used by the answerer (exchange of keying material is still needed, 2078 e.g. inband). The basic SDP Capability Negotiation framework defined 2079 here does not include the ability to do so, however extensions that 2080 enable that may be defined. 2082 3.10. Indicating Bandwidth Usage 2084 The amount of bandwidth to use for a particular media stream depends 2085 on the codecs, transport protocol and other parameters being used. 2086 For example use of Secure RTP [RFC3711] with integrity protection 2087 requires more bandwidth than plain RTP [RFC3551]. SDP defines the 2088 bandwidth ("b=") parameter to indicate the proposed bandwidth for 2089 the session or media stream. 2091 In current SDP, each media description contains one transport 2092 protocol and one or more codecs. When specifying the proposed 2093 bandwidth, the worst case scenario must be taken into account, i.e., 2094 use of the highest bandwidth codec provided, the transport protocol 2095 indicated, and the worst case (bandwidth-wise) parameters that can 2096 be negotiated (e.g., a 32-bit HMAC or an 80-bit HMAC). 2098 The core SDP capability negotiation framework does not provide a way 2099 to negotiate bandwidth parameters. The issue thus remains, however 2100 it is potentially worse than with current SDP, since it is easier to 2101 negotiate additional codecs, and furthermore possible to negotiate 2102 different transport protocols. The recommended approach for 2103 addressing this is the same as for plain SDP; the worst case (now 2104 including potential configurations) needs to be taken into account 2105 when specifying the bandwidth parameters in the actual 2106 configuration. This can make the bandwidth value less accurate than 2107 in current SDP (due to potential greater variability in the 2108 potential configuration bandwidth use). Extensions can be defined to 2109 address this shortcoming. Also, the Transport Independent 2110 Application Specific Maximum (TIAS) bandwidth type defined in 2111 [RFC3890] can be used to alleviate bandwidth variability concerns 2112 due to different transport protocols. 2114 Note, that when using RTP retransmission [RFC4588] with the RTCP- 2115 based feedback profile [RFC4585] (RTP/AVPF), the retransmitted 2116 packets are part of the media stream bandwidth when using SSRC- 2117 multiplexing. If a non-feedback based protocol is offered as an 2118 alternative transport protocol, it is possible that the bandwidth 2119 indication should have been lower. 2121 3.11. Dealing with Large Number of Potential Configurations 2123 When using the SDP Capability Negotiation, it is easy to generate 2124 offers that contain a large number of potential configurations. For 2125 example, in the offer: 2127 v=0 2128 o=- 25678 753849 IN IP4 192.0.2.1 2129 s= 2130 c=IN IP4 192.0.2.1 2131 t=0 0 2132 m=audio 53456 RTP/AVP 0 18 2133 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF 2134 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 2135 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 2136 FEC_ORDER=FEC_SRTP 2137 a=acap:2 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2138 a=acap:3 rtcp-fb:0 nack 2139 a=pcfg:1 t=1 a=1,3|2,3 2140 a=pcfg:2 t=2 a=1|2 2141 a=pcfg:3 t=3 a=3 2143 we have 5 potential configurations on top of the actual 2144 configuration for a single media stream. Adding an extension 2145 capability with just two alternatives for each would double that 2146 number (to 10), and doing the equivalent with two media streams 2147 would again double that number (to 20). While it is easy (and 2148 inexpensive) for the offerer to generate such offers, processing 2149 them at the answering side may not be. Consequently, it is 2150 RECOMMENDED that offerers do not create offers with unnecessarily 2151 large number of potential configurations in them. 2153 On the answering side, implementers MUST take care to avoid 2154 excessive memory and CPU consumption. For example, a naive 2155 implementation that first generates all the valid potential 2156 configuration SDPs internally, could find itself being memory 2157 exhausted, especially if it supports a large number of endpoints. 2158 Similarly, a naive implementation that simply performs iterative 2159 trial-and-error processing on each possible potential configuration 2160 SDP (in the preference order specified) could find itself being CPU 2161 constrained. An alternative strategy is to prune the search space 2162 first by discarding the set of offered potential configurations 2163 where the transport protocol indicated (if any) is not supported, 2164 and/or one or more mandatory attribute capabilities (if any) are 2165 either not supported or not valid. Potential configurations with 2166 unsupported mandatory extension configurations in them can be 2167 discarded as well. 2169 3.12. SDP Capability Negotiation and Intermediaries 2171 An intermediary is here defined as an entity between a SIP user 2172 agent A and a SIP user agent B, that need to perform some kind of 2173 processing on the SDP exchanged between A and B, in order for the 2174 session establishment to operate as intended. Examples of such 2175 intermediaries include Session Border Controllers (SBCs) that may 2176 perform media relaying, Proxy Call Session Control Functions (P- 2177 CSCF) that may authorize use of a certain amount of network 2178 resources (bandwidth), etc. The presence and design of such 2179 intermediaries may not follow the "Internet" model or the SIP 2180 requirements for proxies (which are not supposed to look in message 2181 bodies such as SDP), however they are a fact of life in some 2182 deployment scenarios currently and hence deserve consideration. 2184 If the intermediary needs to understand the characteristics of the 2185 media sessions being negotiated, e.g. the amount of bandwidth used 2186 or the transport protocol negotiated, then use of the SDP Capability 2187 Negotiation framework may impact them. For example, some 2188 intermediaries are known to disallow answers where the transport 2189 protocol differs from the one in the offer. Use of the SDP 2190 Capability Negotiation framework in the presence of such 2191 intermediaries could lead to session failures. Intermediaries that 2192 need to authorize use of network resources based on the negotiated 2193 media stream parameters are affected as well. If they inspect only 2194 the offer, then they may authorize parameters assuming a different 2195 transport protocol, codecs, etc. than what is actually being 2196 negotiated. For these, and other, reasons it is RECOMMENDED that 2197 implementers of intermediaries add support for the SDP Capability 2198 Negotiation framework. 2200 The SDP Capability Negotiation framework itself attempts to help out 2201 these intermediaries as well, by optionally performing a second 2202 offer/answer exchange when use of a potential configuration has been 2203 negotiated (see Section 3.6.3. ). However, there are several 2204 limitations with this approach. First of all, the second 2205 offer/answer exchange is not required and hence may not be 2206 performed. Secondly, the intermediary may refuse the initial answer, 2207 e.g. due to perceived transport protocol mismatch. Thirdly, the 2208 strategy is not foolproof, since the offer/answer procedures 2209 [RFC3264] leave the original offer/answer exchange in effect when a 2210 subsequent one fails; consider the following example: 2212 1. Offerer generates an SDP offer with the actual configuration 2213 specifying a low bandwidth configuration (e.g. plain RTP) and a 2214 potential configuration specifying a high(er) bandwidth 2215 configuration (e.g. secure RTP with integrity). 2217 2. An intermediary (e.g. an SBC or P-CSCF), that does not support 2218 SDP Capability Negotiation, authorizes the session based on the 2219 actual configuration it sees in the SDP. 2221 3. The answerer chooses the high(er) bandwidth potential 2222 configuration and generates an answer SDP based on that. 2224 4. The intermediary passes through the answer SDP. 2226 5. The offerer sees the accepted answer, and generates an updated 2227 offer that contains the selected potential configuration as the 2228 actual configuration. In other words, the high(er) bandwidth 2229 configuration (which has already been negotiated successfully) is 2230 now the actual configuration in the offer SDP. 2232 6. The intermediary sees the new offer, however it does not 2233 authorize the use of the high(er) bandwidth configuration, and 2234 consequently generates a rejection message to the offerer. 2236 7. The offerer receives the rejected offer. 2238 After step 7, per RFC 3264, the offer/answer exchange that completed 2239 in step 5 remains in effect, however the intermediary may not have 2240 authorized the necessary network resources and hence the media 2241 stream may experience quality issues. The solution to this problem 2242 is to upgrade the intermediary to support the SDP Capability 2243 Negotiation framework. 2245 3.13. Considerations for Specific Attribute Capabilities 2247 3.13.1. The rtpmap and fmtp Attributes 2249 The core SDP Capability Negotiation framework defines transport 2250 capabilities and attribute capabilities. Media capabilities, which 2251 can be used to describe media formats and their associated 2252 parameters, are not defined in this document, however the "rtpmap" 2253 and "fmtp" attributes can nevertheless be used as attribute 2254 capabilities. Using such attribute capabilities in a potential 2255 configuration requires a bit of care though. 2257 The rtpmap parameter binds an RTP payload type to a media format 2258 (e.g. codec). While it is possible to provide rtpmaps for payload 2259 types not found in the corresponding "m=" line, such rtpmaps provide 2260 no value in normal offer/answer exchanges, since only the payload 2261 types found in the "m=" line are part of the offer (or answer). This 2262 applies to the core SDP Capability Negotiation framework as well: 2264 Only the media formats (e.g. RTP payload types) provided in the "m=" 2265 line are actually offered; inclusion of rtpmap attributes with other 2266 RTP payload types in a potential configuration does not change this 2267 fact and hence they do not provide any useful information there. 2268 They may still be useful as pure capabilities though (outside a 2269 potential configuration) in order to inform a peer of additional 2270 codecs supported. 2272 It is possible to provide an rtpmap attribute capability with a 2273 payload type mapping to a different codec than a corresponding 2274 actual configuration "rtpmap" attribute for the media description 2275 has. Such practice is permissible as a way of indicating a 2276 capability. If that capability is included in a potential 2277 configuration, then delete-attributes (see Section 3.5.1. ) MUST be 2278 used to ensure that there is not multiple rtpmap attributes for the 2279 same payload type in a given media description (which would not be 2280 allowed by SDP [RFC4566]). 2282 Similar considerations and rules apply to the "fmtp" attribute. An 2283 fmtp attribute capability for a media format not included in the 2284 "m=" line is useless in a potential configuration (but may be useful 2285 as a capability by itself). An fmtp attribute capability in a 2286 potential configuration for a media format that already has an fmtp 2287 attribute in the actual configuration may lead to multiple fmtp 2288 format parameters for that media format and that is not allowed by 2289 SDP [RFC4566]. The delete-attributes MUST be used to ensure that 2290 there is not multiple fmtp attributes for a given media format in a 2291 media description. 2293 Extensions to the core SDP Capability Negotiation framework may 2294 change the above behavior. 2296 3.13.2. Direction Attributes 2298 SDP defines the "inactive", "sendonly", "recvonly", and "sendrecv" 2299 direction attributes. The direction attributes can be applied at 2300 either the session-level or the media-level. In either case, it is 2301 possible to define attribute capabilities for these direction 2302 capabilities; if used by a potential configuration, the normal 2303 offer/answer procedures still apply. For example, if an offered 2304 potential configuration includes the "sendonly" direction attribute, 2305 and it is selected as the actual configuration, then the answer MUST 2306 include a corresponding "recvonly" (or "inactive") attribute. 2308 3.14. Relationship to RFC 3407 2310 RFC 3407 defines capability descriptions with limited abilities to 2311 describe attributes, bandwidth parameters, transport protocols and 2312 media formats. RFC 3407 does not define any negotiation procedures 2313 for actually using those capability descriptions. 2315 This document defines new attributes for describing attribute 2316 capabilities and transport capabilities. It also defines procedures 2317 for using those capabilities as part of an offer/answer exchange. In 2318 contrast to RFC 3407, this document does not define bandwidth 2319 parameters, and it also does not define how to express ranges of 2320 values. Extensions to this document may be defined in order to fully 2321 cover all the capabilities provided by RFC 3407 (for example more 2322 general media capabilities). 2324 It is RECOMMENDED that implementations use the attributes and 2325 procedures defined in this document instead of those defined in 2326 [RFC3407]. If capability description interoperability with legacy 2327 RFC 3407 implementations is desired, implementations MAY include 2328 both RFC 3407 capability descriptions and capabilities defined by 2329 this document. The offer/answer negotiation procedures defined in 2330 this document will not use the RFC 3407 capability descriptions. 2332 4. Examples 2334 In this section, we provide examples showing how to use the SDP 2335 Capability Negotiation. 2337 4.1. Multiple Transport Protocols 2339 The following example illustrates how to use the SDP Capability 2340 Negotiation extensions to negotiate use of one out of several 2341 possible transport protocols. The offerer uses the expected least- 2342 common-denominator (plain RTP) as the actual configuration, and the 2343 alternative transport protocols as the potential configurations. 2345 The example is illustrated by the offer/answer exchange below, where 2346 Alice sends an offer to Bob: 2348 Alice Bob 2350 | (1) Offer (RTP/[S]AVP[F]) | 2351 |--------------------------------->| 2352 | | 2353 | (2) Answer (RTP/AVPF) | 2354 |<---------------------------------| 2355 | | 2356 | (3) Offer (RTP/AVPF) | 2357 |--------------------------------->| 2358 | | 2359 | (4) Answer (RTP/AVPF) | 2360 |<---------------------------------| 2361 | | 2363 Alice's offer includes plain RTP (RTP/AVP), RTP with RTCP-based 2364 feedback (RTP/AVPF), Secure RTP (RTP/SAVP), and Secure RTP with 2365 RTCP-based feedback (RTP/SAVPF) and SRTP as alternatives. RTP is the 2366 default, with RTP/SAVPF, RTP/SAVP, and RTP/AVPF as the alternatives 2367 and preferred in the order listed: 2369 v=0 2370 o=- 25678 753849 IN IP4 192.0.2.1 2371 s= 2372 c=IN IP4 192.0.2.1 2373 t=0 0 2374 m=audio 53456 RTP/AVP 0 18 2375 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF 2376 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 2377 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 2378 FEC_ORDER=FEC_SRTP 2379 a=acap:2 rtcp-fb:0 nack 2380 a=pcfg:1 t=1 a=1,[2] 2381 a=pcfg:2 t=2 a=1 2382 a=pcfg:3 t=3 a=[2] 2384 The "m=" line indicates that Alice is offering to use plain RTP with 2385 PCMU or G.729. The capabilities are provided by the "a=tcap" and 2386 "a=acap" attributes. The "tcap" capability indicates that Secure 2387 RTP with RTCP-Based feedback (RTP/SAVPF), Secure RTP (RTP/SAVP), and 2388 RTP with RTCP-Based feedback are supported. The first "acap" 2389 attribute provides an attribute capability with a handle of 1. The 2390 capability is a "crypto" attribute, which provides the keying 2391 material for SRTP using SDP security descriptions [RFC4568]. The 2392 second "acap" attribute provides an attribute capability with a 2393 handle of 2. The capability is an "rtcp-fb" attribute, which is used 2394 by the RTCP-based feedback profiles to indicate that payload type 0 2395 (PCMU) supports feedback type "nack". The "a=pcfg" attributes 2396 provide the potential configurations included in the offer by 2397 reference to the capabilities. There are three potential 2398 configurations: 2400 o Potential configuration 1, which is the most preferred potential 2401 configuration specifies use of transport protocol capability 1 2402 (RTP/SAVPF) and attribute capabilities 1 (the "crypto" attribute) 2403 and 2 (the "rtcp-fb" attribute). Support for the first one is 2404 mandatory whereas support for the second one is optional. 2406 o Potential configuration 2, which is the second most preferred 2407 potential configuration specifies use of transport protocol 2408 capability 2 (RTP/SAVP) and mandatory attribute capability 1 (the 2409 "crypto" attribute). 2411 o Potential configuration 3, which is the least preferred potential 2412 configuration (but the second least preferred configuration 2413 overall, since the actual configuration provided by the "m=" line 2414 is always the least preferred configuration), specifies use of 2415 transport protocol capability 3 (RTP/AVPF) and optional attribute 2416 capability 2 (the "rtcp-fb" attribute). 2418 Bob receives the SDP offer from Alice. Bob does not support any 2419 secure RTP profiles, however he supports plain RTP and RTP with 2420 RTCP-based feedback, as well as the SDP Capability Negotiation 2421 extensions, and hence he accepts the potential configuration for RTP 2422 with RTCP-based feedback provided by Alice: 2424 v=0 2425 o=- 24351 621814 IN IP4 192.0.2.2 2426 s= 2427 c=IN IP4 192.0.2.2 2428 t=0 0 2429 m=audio 54568 RTP/AVPF 0 18 2430 a=rtcp-fb:0 nack 2431 a=acfg:1 t=3 a=[2] 2433 Bob includes the "a=acfg" attribute in the answer to inform Alice 2434 that he based his answer on an offer containing the potential 2435 configuration with transport protocol capability 3 and optional 2436 attribute capability 2 from the offer SDP (i.e. the RTP/AVPF profile 2437 using the "rtcp-fb" value provided). Bob also includes an "rtcp-fb" 2438 attribute with the value "nack" value for RTP payload type 0. 2440 When Alice receives Bob's answer, session negotiation has completed, 2441 however Alice nevertheless chooses to generate a new offer using the 2442 actual configuration. This is done purely to assist any 2443 intermediaries that may reside between Alice and Bob but do not 2444 support the SDP Capability Negotiation framework (and hence may not 2445 understand the negotiation that just took place): 2447 Alice's updated offer includes only RTP/AVPF, and it is not using 2448 the SDP Capability Negotiation framework (Alice could have included 2449 the capabilities as well if she wanted to): 2451 v=0 2452 o=- 25678 753850 IN IP4 192.0.2.1 2453 s= 2454 c=IN IP4 192.0.2.1 2455 t=0 0 2456 m=audio 53456 RTP/AVPF 0 18 2457 a=rtcp-fb:0 nack 2459 The "m=" line now indicates that Alice is offering to use RTP with 2460 RTCP-based feedback and using PCMU or G.729. The "rtcp-fb" 2461 attribute provides the feedback type "nack" for payload type 0 again 2462 (but as part of the actual configuration). 2464 Bob receives the SDP offer from Alice, which he accepts, and then 2465 generates an answer to Alice: 2467 v=0 2468 o=- 24351 621815 IN IP4 192.0.2.2 2469 s= 2470 c=IN IP4 192.0.2.2 2471 t=0 0 2472 m=audio 54568 RTP/AVPF 0 18 2473 a=rtcp-fb:0 nack 2475 Bob includes the same "rtcp-fb" attribute as before, and the session 2476 proceeds without change. Although Bob did not include any 2477 capabilities in his answer, he could have done so if he wanted to. 2479 Note that in this particular example, the answerer supported the SDP 2480 Capability Negotiation framework and hence the attributes and 2481 procedures defined here, however had he not, the answerer would 2482 simply have ignored the new attributes received in step 1 and 2483 accepted the offer to use normal RTP. In that case, the following 2484 answer would have been generated in step 2 instead: 2486 v=0 2487 o=- 24351 621814 IN IP4 192.0.2.2 2488 s= 2489 c=IN IP4 192.0.2.2 2490 t=0 0 2491 m=audio 54568 RTP/AVP 0 18 2493 4.2. Best-Effort SRTP with Session-Level MIKEY and Media Level Security 2494 Descriptions 2496 The following example illustrates how to use the SDP Capability 2497 Negotiation extensions to support so-called Best-Effort Secure RTP 2498 as well as alternative keying mechanisms, more specifically MIKEY 2499 [RFC3830] and SDP Security Descriptions. The offerer (Alice) wants 2500 to establish an audio and video session. Alice prefers to use 2501 session-level MIKEY as the key management protocol, but supports SDP 2502 security descriptions as well. 2504 The example is illustrated by the offer/answer exchange below, where 2505 Alice sends an offer to Bob: 2507 Alice Bob 2509 | (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) | 2510 |--------------------------------------->| 2511 | | 2512 | (2) Answer (RTP/SAVP, SDES) | 2513 |<---------------------------------------| 2514 | | 2515 | (3) Offer (RTP/SAVP, SDES) | 2516 |--------------------------------------->| 2517 | | 2518 | (4) Answer (RTP/SAVP, SDES) | 2519 |<---------------------------------------| 2520 | | 2522 Alice's offer includes an audio and a video stream. The audio stream 2523 offers use of plain RTP and secure RTP as alternatives, whereas the 2524 video stream offers use of plain RTP, RTP with RTCP-based feedback, 2525 Secure RTP, and Secure RTP with RTCP-based feedback as alternatives: 2527 v=0 2528 o=- 25678 753849 IN IP4 192.0.2.1 2529 s= 2530 t=0 0 2531 c=IN IP4 192.0.2.1 2532 a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2533 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF 2534 m=audio 59000 RTP/AVP 98 2535 a=rtpmap:98 AMR/8000 2536 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32 2537 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2538 a=pcfg:1 t=2 a=1|2 2539 m=video 52000 RTP/AVP 31 2540 a=rtpmap:31 H261/90000 2541 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 2542 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2543 a=acap:4 rtcp-fb:* nack 2544 a=pcfg:1 t=1 a=1,4|3,4 2545 a=pcfg:2 t=2 a=1|3 2546 a=pcfg:3 t=3 a=4 2548 The potential configuration for the audio stream specifies use of 2549 transport capability 2 (RTP/SAVP) and either attribute capability 1 2550 (session-level MIKEY as the keying mechanism) or 2 (SDP Security 2551 Descriptions as the keying mechanism). Support for either of these 2552 attribute capabilities is mandatory. There are three potential 2553 configurations for the video stream. 2555 o The first configuration with configuration number 1 uses 2556 transport capability 1 (RTP/SAVPF) with either attribute 2557 capabilities 1 and 4 (session-level MIKEY and the "rtcp-fb" 2558 attribute) or attribute capabilities 3 and 4 (SDP security 2559 descriptions and the "rtcp-fb" attribute). In this example, the 2560 offerer insists on not only the keying mechanism being supported, 2561 but also that the "rtcp-fb" attribute is supported with the value 2562 indicated. Consequently, all the attribute capabilities are 2563 marked as mandatory in this potential configuration. 2565 o The second configuration with configuration number 2 uses 2566 transport capability 2 (RTP/SAVP) and either attribute capability 2567 1 (session-level MIKEY) or attribute capability 3 (SDP security 2568 descriptions). Both attribute capabilities are mandatory in this 2569 configuration. 2571 o The third configuration with configuration number 3 uses 2572 transport capability 3 (RTP/AVPF) and mandatory attribute 2573 capability 4 (the "rtcp-fb" attribute). 2575 Bob receives the SDP offer from Alice. Bob supports Secure RTP, 2576 Secure RTP with RTCP-based feedback and the SDP Capability 2577 Negotiation extensions. Bob also supports SDP Security Descriptions, 2578 but not MIKEY, and hence he generates the following answer: 2580 v=0 2581 o=- 24351 621814 IN IP4 192.0.2.2 2582 s= 2583 t=0 0 2584 c=IN IP4 192.0.2.2 2585 m=audio 54568 RTP/SAVP 98 2586 a=rtpmap:98 AMR/8000 2587 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2588 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 2589 a=acfg:1 t=2 a=2 2590 m=video 55468 RTP/SAVPF 31 2591 a=rtpmap:31 H261/90000 2592 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2593 inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32 2594 a=rtcp-fb:* nack 2595 a=acfg:1 t=1 a=3,4 2597 For the audio stream, Bob accepted the use of secure RTP, and hence 2598 the profile in the "m=" line is "RTP/SAVP". Bob also includes a 2599 "crypto" attribute with his own keying material, and an "acfg" 2600 attribute identifying actual configuration 1 for the audio media 2601 stream from the offer, using transport capability 2 (RTP/SAVP) and 2602 attribute capability 2 (the crypto attribute from the offer). For 2603 the video stream, Bob accepted the use of secure RTP with RTCP-based 2604 feedback, and hence the profile in the "m=" line is "RTP/SAVPF". Bob 2605 also includes a "crypto" attribute with his own keying material, and 2606 an "acfg" attribute identifying actual configuration 1 for the video 2607 stream from the offer, using transport capability 1 (RTP/SAVPF) and 2608 attribute capabilities 3 (the crypto attribute from the offer) and 4 2609 (the "rtcp-fb" attribute from the offer). 2611 When Alice receives Bob's answer, session negotiation has completed, 2612 however Alice nevertheless chooses to generate a new offer using the 2613 actual configuration. This is done purely to assist any 2614 intermediaries that may reside between Alice and Bob but do not 2615 support the capability negotiation extensions (and hence may not 2616 understand the negotiation that just took place): 2618 Alice's updated offer includes only SRTP for the audio stream SRTP 2619 with RTCP-based feedback for the video stream, and it is not using 2620 the SDP Capability Negotiation framework (Alice could have included 2621 the capabilities as well is she wanted to): 2623 v=0 2624 o=- 25678 753849 IN IP4 192.0.2.1 2625 s= 2626 t=0 0 2627 c=IN IP4 192.0.2.1 2628 m=audio 59000 RTP/SAVP 98 2629 a=rtpmap:98 AMR/8000 2630 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2631 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2632 m=video 52000 RTP/SAVPF 31 2633 a=rtpmap:31 H261/90000 2634 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2635 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2636 a=rtcp-fb:* nack 2638 The "m=" line for the audio stream now indicates that Alice is 2639 offering to use secure RTP with PCMU or G.729, whereas the "m=" line 2640 for the video stream indicates that Alice is offering to use secure 2641 RTP with RTCP-based feedback and H.261. Each media stream includes a 2642 "crypto" attribute, which provides the SRTP keying material, with 2643 the same value again. 2645 Bob receives the SDP offer from Alice, which he accepts, and then 2646 generates an answer to Alice: 2648 v=0 2649 o=- 24351 621814 IN IP4 192.0.2.2 2650 s= 2651 t=0 0 2652 c=IN IP4 192.0.2.2 2653 m=audio 54568 RTP/SAVP 98 2654 a=rtpmap:98 AMR/8000 2655 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2656 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 2657 m=video 55468 RTP/SAVPF 31 2658 a=rtpmap:31 H261/90000 2659 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2660 inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32 2661 a=rtcp-fb:* nack 2663 Bob includes the same crypto attribute as before, and the session 2664 proceeds without change. Although Bob did not include any 2665 capabilities in his answer, he could have done so if he wanted to. 2667 Note that in this particular example, the answerer supported the 2668 capability extensions defined here, however had he not, the answerer 2669 would simply have ignored the new attributes received in step 1 and 2670 accepted the offer to use normal RTP. In that case, the following 2671 answer would have been generated in step 2 instead: 2673 v=0 2674 o=- 24351 621814 IN IP4 192.0.2.2 2675 s= 2676 t=0 0 2677 c=IN IP4 192.0.2.2 2678 m=audio 54568 RTP/AVP 98 2679 a=rtpmap:98 AMR/8000 2680 m=video 55468 RTP/AVP 31 2681 a=rtpmap:31 H261/90000 2682 a=rtcp-fb:* nack 2684 Finally, if Bob had chosen to use session-level MIKEY instead of SDP 2685 security descriptions instead, the following answer would have been 2686 generated: 2688 v=0 2689 o=- 25678 753849 IN IP4 192.0.2.1 2690 s= 2691 t=0 0 2692 c=IN IP4 192.0.2.1 2693 a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyO... 2694 m=audio 59000 RTP/AVP 98 2695 a=rtpmap:98 AMR/8000 2696 a=acfg:1 t=2 a=1 2697 m=video 52000 RTP/SAVPF 31 2698 a=rtpmap:31 H261/90000 2699 a=rtcp-fb:* nack 2700 a=acfg:1 t=1 a=1,4 2702 It should be noted, that although Bob could have chosen session- 2703 level MIKEY for one media stream, and SDP Security Descriptions for 2704 another media stream, there are no well-defined offerer processing 2705 rules of the resulting answer for this, and hence the offerer may 2706 incorrectly assume use of MIKEY for both streams. To avoid this, if 2707 the answerer chooses session-level MIKEY, then all secure RTP based 2708 media streams SHOULD use MIKEY (this applies irrespective of whether 2709 SDP Capability Negotiation is being used or not). Use of media-level 2710 MIKEY does not have a similar constraint. 2712 4.3. SRTP with Session-Level MIKEY and Media Level Security 2713 Descriptions as Alternatives 2715 The following example illustrates how to use the SDP Capability 2716 Negotiation framework to negotiate use of either MIKEY or SDP 2717 Security Descriptions, when one of them is included as part of the 2718 actual configuration, and the other one is being selected. The 2719 offerer (Alice) wants to establish an audio and video session. Alice 2720 prefers to use session-level MIKEY as the key management protocol, 2721 but supports SDP security descriptions as well. 2723 The example is illustrated by the offer/answer exchange below, where 2724 Alice sends an offer to Bob: 2726 Alice Bob 2728 | (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) | 2729 |--------------------------------------->| 2730 | | 2731 | (2) Answer (RTP/SAVP, SDES) | 2732 |<---------------------------------------| 2733 | | 2735 Alice's offer includes an audio and a video stream. Both the audio 2736 and the video stream offer use of secure RTP: 2738 v=0 2739 o=- 25678 753849 IN IP4 192.0.2.1 2740 s= 2741 t=0 0 2742 c=IN IP4 192.0.2.1 2743 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2744 m=audio 59000 RTP/SAVP 98 2745 a=rtpmap:98 AMR/8000 2746 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 2747 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2748 a=pcfg:1 a=-s:1 2749 m=video 52000 RTP/SAVP 31 2750 a=rtpmap:31 H261/90000 2751 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_80 2752 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2753 a=pcfg:1 a=-s:2 2755 Alice does not know whether Bob supports MIKEY or SDP Security 2756 Descriptions. She could include attributes for both, however the 2757 resulting procedures and potential interactions are not well- 2758 defined. Instead, she places a session-level key-mgmt attribute for 2759 MIKEY in the actual configuration with SDP security descriptions as 2760 an alternative in the potential configuration. The potential 2761 configuration for the audio stream specifies that all session level 2762 attributes are to be deleted (i.e. the session-level "a=key-mgmt" 2763 attribute) and that mandatory attribute capability 2 is to be used 2764 (i.e. the crypto attribute). The potential configuration for the 2765 video stream is similar, except it uses it's own mandatory crypto 2766 attribute capability (2). Note how deletion of the session-level 2767 attributes does not affect the media-level attributes. 2769 Bob receives the SDP offer from Alice. Bob supports Secure RTP and 2770 the SDP Capability Negotiation framework. Bob also supports both SDP 2771 Security Descriptions and MIKEY. Since the potential configuration 2772 is more preferred than the actual configuration, Bob (conceptually) 2773 generates an internal potential configuration SDP that contains the 2774 crypto attributes for the audio and video stream, but not the key- 2775 mgmt attribute for MIKEY, thereby avoiding any ambiguity between the 2776 two keying mechanisms. As a result, he generates the following 2777 answer: 2779 v=0 2780 o=- 24351 621814 IN IP4 192.0.2.2 2781 s= 2782 t=0 0 2783 c=IN IP4 192.0.2.2 2784 m=audio 54568 RTP/SAVP 98 2785 a=rtpmap:98 AMR/8000 2786 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2787 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 2788 a=acfg:1 a=-s:1 2789 m=video 55468 RTP/SAVP 31 2790 a=rtpmap:31 H261/90000 2791 a=crypto:1 AES_CM_128_HMAC_SHA1_80 2792 inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32 2793 a=acfg:1 a=-s:2 2795 For the audio stream, Bob accepted the use of secure RTP using SDP 2796 security descriptions. Bob therefore includes a "crypto" attribute 2797 with his own keying material, and an "acfg" attribute identifying 2798 actual configuration 1 for the audio media stream from the offer, 2799 with the delete-attributes ("-s") and attribute capability 1 (the 2800 crypto attribute from the offer). For the video stream, Bob also 2801 accepted the use of secure RTP using SDP security descriptions. Bob 2802 therefore includes a "crypto" attribute with his own keying 2803 material, and an "acfg" attribute identifying actual configuration 1 2804 for the video stream from the offer, with the delete-attributes ("- 2805 s") and attribute capability 2. 2807 Below, we illustrate the offer SDP, when Bob instead offers the 2808 "crypto" attribute as the actual configuration keying mechanism and 2809 "key-mgmt" as the potential configuration: 2811 v=0 2812 o=- 25678 753849 IN IP4 192.0.2.1 2813 s= 2814 t=0 0 2815 c=IN IP4 192.0.2.1 2816 a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 2817 m=audio 59000 RTP/SAVP 98 2818 a=rtpmap:98 AMR/8000 2819 a=crypto:1 AES_CM_128_HMAC_SHA1_32 2820 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 2821 a=acap:2 rtpmap:98 AMR/8000 2822 a=pcfg:1 a=-m:1,2 2823 m=video 52000 RTP/SAVP 31 2824 a=rtpmap:31 H261/90000 2825 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 2826 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 2827 a=acap:4 rtpmap:31 H261/90000 2828 a=pcfg:1 a=-m:1,4 2830 Note how we this time need to perform delete-attributes at the 2831 media-level instead of the session-level. When doing that, all 2832 attributes from the actual configuration SDP, including the rtpmaps 2833 provided, are removed. Consequently, we had to include these rtpmaps 2834 as capabilities as well, and then include them in the potential 2835 configuration, thereby effectively recreating the original rtpmap 2836 attributes in the resulting potential configuration SDP. 2838 5. Security Considerations 2840 The SDP Capability Negotiation Framework is defined to be used 2841 within the context of the offer/answer model, and hence all the 2842 offer/answer security considerations apply here as well. Similarly, 2843 the Session Initiation Protocol (SIP) uses SDP and the offer/answer 2844 model, and hence, when used in that context, the SIP security 2845 considerations apply as well. 2847 However, SDP Capability Negotiation introduces additional security 2848 issues. Its use as a mechanism to enable alternative transport 2849 protocol negotiation (secure and non-secure) as well as its ability 2850 to negotiate use of more or less secure keying methods and material 2851 warrant further security considerations. Also, the (continued) 2852 support for receiving media before answer combined with negotiation 2853 of alternative transport protocols (secure and non-secure) warrant 2854 further security considerations. We discuss these issues below. 2856 The SDP Capability Negotiation framework allows for an offered media 2857 stream to both indicate and support various levels of security for 2858 that media stream. Different levels of security can for example be 2859 negotiated by use of alternative attribute capabilities each 2860 indicating more or less secure keying methods as well as more or 2861 less strong ciphers. Since the offerer indicates support for each of 2862 these alternatives, he will presumably accept the answerer seemingly 2863 selecting any of the offered alternatives. If an attacker can modify 2864 the SDP offer, he can thereby force the negotiation of the weakest 2865 security mechanism that the offerer is willing to accept. This may 2866 enable the attacker to compromise the security of the negotiated 2867 media stream. Similarly, if the offerer wishes to negotiate use of a 2868 secure media stream (e.g. secure RTP), but includes a non-secure 2869 media stream (e.g. plain RTP) as a valid (but less preferred) 2870 alternative, then an attacker that can modify the offered SDP will 2871 be able to force the establishment of an insecure media stream. The 2872 solution to both of these problems involves the use of integrity 2873 protection over the SDP. Ideally, this integrity protection provides 2874 end-to-end integrity protection in order to protect from any man-in- 2875 the-middle attack; secure multiparts such as S/MIME [RFC3851] 2876 provide one such solution, however S/MIME requires use and 2877 availability of a Public Key Infrastructure (PKI). A slightly less 2878 secure alternative when using SIP, but generally much easier to 2879 deploy in practice (since it does not require a PKI), is to use SIP 2880 Identity [RFC4474]; this requires the existence of an authentication 2881 service (see [RFC4474]). Yet another, and considerably less secure, 2882 alternative is to use hop-by-hop security only, e.g. TLS or IPSec 2883 thereby ensuring the integrity of the offered SDP on a hop-by-hop 2884 basis. Note however that SIP proxies or other intermediaries 2885 processing the SIP request at each hop are able to perform a man-in- 2886 the-middle attack by modifying the offered SDP. 2888 Per the normal offer/answer procedures, as soon as the offerer has 2889 generated an offer, the offerer must be prepared to receive media in 2890 accordance with that offer. The SDP Capability Negotiation preserves 2891 that behavior for the actual configuration in the offer, however the 2892 offerer has no way of knowing which configuration (actual or 2893 potential) configuration was selected by the offerer, until an 2894 answer indication is received. This opens up a new security issue 2895 where an attacker may be able to interject media towards the offerer 2896 until the answer is received. For example, the offerer may use plain 2897 RTP as the actual configuration and secure RTP as an alternative 2898 potential configuration. Even though the answerer selects secure 2899 RTP, the offerer will not know that until he receives the answer, 2900 and hence an attacker will be able to send media to the offerer 2901 meanwhile. The easiest protection against such an attack is to not 2902 offer use of the non-secure media stream in the actual 2903 configuration, however that may in itself have undesirable side- 2904 effects: If the answerer does not support the secure media stream 2905 and also does not support the capability negotiation framework, then 2906 negotiation of the media stream will fail. Alternatively, SDP 2907 security preconditions [RFC5027] can be used. This will ensure that 2908 media is not flowing until session negotiation has completed and 2909 hence the selected configuration is known. Use of preconditions 2910 however requires both sides to support them. If they don't, and use 2911 of them is required, the session will fail. As a (limited) work 2912 around to this, it is RECOMMENDED that SIP entities generate an 2913 answer SDP and send it to the offerer as soon as possible, for 2914 example in a 183 Session Progress message. This will limit the time 2915 during which an attacker can send media to the offerer. Section 3.9. 2916 presents other alternatives as well. 2918 Additional security considerations apply to the answer SDP as well. 2919 The actual configuration attribute tells the offerer which potential 2920 configuration the answer was based on, and hence an attacker that 2921 can either modify or remove the actual configuration attribute in 2922 the answer can cause session failure as well as extend the time 2923 window during which the offerer will accept incoming media that does 2924 not conform to the actual answer. The solutions to this SDP answer 2925 integrity problem are the same as for the offer, i.e. use of end-to- 2926 end integrity protection, SIP identity, or hop-by-hop protection. 2927 The mechanism to use depends on the mechanisms supported by the 2928 offerer as well as the acceptable security trade-offs. 2930 As described in Section 3.1. , SDP Capability Negotiation 2931 conceptually allows an offerer to include many different offers in a 2932 single SDP. This can cause the answerer to process a large number of 2933 alternative potential offers, which can consume significant memory 2934 and CPU resources. An attacker can use this amplification feature to 2935 launch a denial of service attack against the answerer. The answerer 2936 MUST protect itself from such attacks. As explained in Section 3.10. 2937 , the answerer can help reduce the effects of such an attack by 2938 first discarding all potential configurations that contain 2939 unsupported transport protocols, unsupported or invalid mandatory 2940 attribute capabilities, or unsupported mandatory extension 2941 configurations. The answerer SHOULD also look out for potential 2942 configurations that are designed to pass the above test, but 2943 nevertheless produce a large number of potential configuration SDPs 2944 that cannot be supported. 2946 A possible way of achieving that is for an attacker to find a 2947 valid session-level attribute that causes conflicts or otherwise 2948 interferes with individual media description configurations. 2949 Currently, we do not know of such an SDP attribute, however this 2950 does not mean it does not exist, or that it will not exist in the 2951 future. If such attributes are found to exist, implementers should 2952 explicitly protect against them. 2954 A significant number of valid and supported potential configurations 2955 may remain. However, since all of those contain only valid and 2956 supported transport protocols and attributes, it is expected that 2957 only a few of them will need to be processed on average. Still, the 2958 answerer MUST ensure that it does not needlessly consume large 2959 amounts of memory or CPU resources when processing those as well as 2960 be prepared to handle the case where a large number of potential 2961 configurations still need to be processed. 2963 6. IANA Considerations 2965 6.1. New SDP Attributes 2967 The IANA is hereby requested to register the following new SDP 2968 attributes as follows: 2970 Attribute name: csup 2971 Long form name: Supported capability negotiation extensions 2972 Type of attribute: Session-level and media-level 2973 Subject to charset: No 2974 Purpose: Option tags for supported SDP capability 2975 negotiation extensions 2976 Appropriate values: See Section 3.3.1. 2978 Attribute name: creq 2979 Long form name: Required capability negotiation extensions 2980 Type of attribute: Session-level and media-level 2981 Subject to charset: No 2982 Purpose: Option tags for required SDP capability 2983 negotiation extensions 2984 Appropriate values: See Section 3.3.2. 2986 Attribute name: acap 2987 Long form name: Attribute capability 2988 Type of attribute: Session-level and media-level 2989 Subject to charset: No 2990 Purpose: Attribute capability containing an attribute 2991 name and associated value 2992 Appropriate values: See Section 3.4.1. 2994 Attribute name: tcap 2995 Long form name: Transport Protocol Capability 2996 Type of attribute: Session-level and media-level 2997 Subject to charset: No 2998 Purpose: Transport protocol capability listing one or 2999 more transport protocols 3000 Appropriate values: See Section 3.4.2. 3002 Attribute name: pcfg 3003 Long form name: Potential Configuration 3004 Type of attribute: Media-level 3005 Subject to charset: No 3006 Purpose: Potential configuration for SDP capability 3007 negotiation 3008 Appropriate values: See Section 3.5.1. 3010 Attribute name: acfg 3011 Long form name: Actual configuration 3012 Type of attribute: Media-level 3013 Subject to charset: No 3014 Purpose: Actual configuration for SDP capability 3015 negotiation 3016 Appropriate values: See Section 3.5.2. 3018 6.2. New SDP Capability Negotiation Option Tag Registry 3020 The IANA is hereby requested to create a new SDP Capability 3021 Negotiation Option Tag registry. An IANA SDP Capability Negotiation 3022 option tag registration MUST be documented in an RFC in accordance 3023 with the [RFC2434] Specification Required policy. The RFC MUST 3024 provide the name of the option tag, a syntax and a semantic 3025 specification of any new SDP attributes and any extensions to the 3026 potential and actual configuration attributes provided in this 3027 document. New SDP attributes that are intended to be capabilities 3028 for use by the capability negotiation framework MUST adhere to the 3029 guidelines provided in Section 3.4.3. Extensions to the potential 3030 and actual configuration attributes MUST adhere to the syntax 3031 provided in Section 3.5.1. and 3.5.2. 3033 The option tag "cap-v0" is defined in this document and the IANA is 3034 hereby requested to register this option tag. 3036 6.3. New SDP Capability Negotiation Potential Configuration Parameter 3037 Registry 3039 The IANA is hereby requested to create a new SDP Capability 3040 Negotiation Potential Configuration Parameter registry. An IANA SDP 3041 Capability Negotiation potential configuration registration MUST be 3042 documented in an RFC in accordance with the [RFC2434] Specification 3043 Required policy. The RFC MUST define the syntax and semantics of 3044 each new potential configuration parameter. The syntax MUST adhere 3045 to the syntax provided for extensions in Section 3.5.1. and the 3046 semantics MUST adhere to the semantics provided for extensions in 3047 Section 3.5.1. and 3.5.2. Associated with each registration MUST be 3048 the encoding name for the parameter as well as a short descriptive 3049 name for it. 3051 The potential configuration parameters "a" for "attribute" and "t" 3052 for "transport protocol" are defined in this document and the IANA 3053 is hereby requested to register these. 3055 7. Acknowledgments 3057 The SDP Capability Negotiation solution defined in this document 3058 draws on the overall capability negotiation framework that was 3059 defined by [SDPng]. Also, the SDP Capability Negotiation solution is 3060 heavily influenced by the discussions and work done by the SDP 3061 Capability Negotiation Design Team. The following people in 3062 particular provided useful comments and suggestions to either the 3063 document itself or the overall direction of the solution defined in 3064 here: Francois Audet, John Elwell, Roni Even, Robert Gilman, Cullen 3065 Jennings, Jonathan Lennox, Matt Lepinski, Joerg Ott, Colin Perkins, 3066 Jonathan Rosenberg, Thomas Stach, and Dan Wing. 3068 8. Change Log 3070 8.1. draft-ietf-mmusic-sdp-capability-negotiation-08 3072 Incorporated Working Group Last Call comments as follows: 3074 o Added second offer/answer exchange to introductory example, fixed 3075 minor error in that example, and deleted similar example in the 3076 Examples Section. 3078 o Fixed "type=value" semantic error in the attribute capability 3079 definition. 3081 o Clarified that consecutive numbering of capabilities and 3082 potential configurations is not required. 3084 o Fixed inconsistency for which parameters to include in the "acfg" 3085 attribute. 3087 o Changed second offer/answer exchange from MAY to SHOULD strength. 3089 o Clarified there should be a combined second offer/exchange when 3090 using ICE. 3092 o Moved RFC 3407 to informative references. 3094 o Various editorial clarifications. 3096 8.2. draft-ietf-mmusic-sdp-capability-negotiation-07 3098 o Removed the ability to have attribute capabilities provide 3099 attribute names without values, when those attributes otherwise 3100 require an associated value. 3102 o Document no longer obsoletes RFC 3407 but instead recommends that 3103 it is being used instead of RFC 3407. 3105 o Added ability to specific that specific extensions in a potential 3106 configuration are mandatory. 3108 o Changed ABNF for extension-config-list in potential 3109 configurations. 3111 o Removed the redundant "a=" part of attribute capabilities. 3113 o Clarified what it means to support an attribute capability in the 3114 offer/answer procedures. 3116 o Changed "a=acap" attribute and offer/answer procedures to include 3117 only the known and supported attribute capabilities. 3119 o Added new section on indicating bandwidth usage. 3121 8.3. draft-ietf-mmusic-sdp-capability-negotiation-06 3123 o Added additional background text on terminology used, and a new 3124 section on the negotiation model. 3126 o Allowed for session-level attribute capabilities to contain 3127 media-level only attributes, albeit the base framework does not 3128 define (or allow) them to be used in a potential configuration 3129 (extensions may change that) 3131 o Disallowing multiple "a=tcap" attributes at the session-level 3132 and/or on a per media description basis; at most one at the 3133 session-level and per media description now. 3135 o Changed the "a=pcfg" attribute to make a potential configuration 3136 list optional in order to allow for the actual configuration to 3137 be referenced. 3139 o Removed the ability to delete and replace individual attributes 3140 from the actual configuration SDP. 3142 o Introduced the notion of mandatory and optional attribute 3143 capabilities in a potential configuration and updated the 3144 "a=pcfg" attribute and associated procedures accordingly. 3146 o Specified that mandatory attribute capabilities and the transport 3147 protocol (if any) from a potential configuration need to be 3148 supported in order to select that potential configuration. 3149 Offer/answer procedures updated accordingly as well. 3151 o Noted potential interaction and synchronization issues with use 3152 of session-level attributes and attribute capabilities and added 3153 recommendation to avoid use of session-level attributes when 3154 possible. 3156 o Fixed error in "a=acfg" grammar (missing config-number) and 3157 updated attribute definition in accordance with the "a=pcfg" 3158 attribute changes. 3160 o Updated text associated with processing media before answer to 3161 allow for playing out garbage or discard until answer received. 3162 Additional detail on alternative solutions provided as well. 3164 o Added recommendation to send back answer SDP as soon as possible, 3165 when a potential configuration different from the actual 3166 configuration has been chosen. 3168 o Added new section on interactions with SIP option tags. 3170 o Added new section on dealing with large number of potential 3171 configurations. 3173 o Added new section on SDP capability negotiation and 3174 intermediaries. 3176 o Updated examples in accordance with other changes and to 3177 illustrate use of mandatory and optional attribute capabilities 3178 in a potential configuration. 3180 o Updated security considerations to address potential denial of 3181 service attack caused by large number of potential 3182 configurations. 3184 o Various editorial updates throughout. 3186 8.4. draft-ietf-mmusic-sdp-capability-negotiation-05 3188 o Allowed for '=' attributes to be listed as attribute 3189 capabilities the attribute name only. 3191 o Changed IP-address to conform to RFC 3330 guidelines. 3193 o Added section on relationship to RFC 3407 and "Obsoletes: 3407" 3194 in the front. 3196 o Disallowed use of white space in a number of places for more 3197 consistency with existing SDP practice 3199 o Changed "csup" and "creq" attributes to not allow multiple 3200 instances at the session-level and multiple instances per media 3201 description (only one for each now) 3203 o Changed to not require use of "creq" with base option tag ("cap- 3204 v0"). 3206 o Relaxed restrictions on extension capabilities 3208 o Updated potential configuration attribute syntax and semantics. 3209 In particular, potential configuration attributes can now replace 3210 and delete various existing attributes in original SDP to better 3211 control potential attribute interactions with the actual 3212 configuration while preserving message size efficiency. 3214 o Updated actual configuration attribute to align with the updates 3215 to the potential configuration attributes. 3217 o Updated offer/answer procedures to align with other changes. 3219 o Changed recommendation for second offer/answer exchange to "MAY" 3220 strength, unless for the cases where it is known or suspected 3221 that it is needed. 3223 o Updated ICE interactions to explain how the new attribute 3224 delete/replace features can solve certain potential interactions. 3226 o Updated rtpmap and fmtp section to allow potential configurations 3227 to use remapped payload types in attribute capabilities for 3228 rtpmaps and fmtp parameters. 3230 o Added section on direction attributes. 3232 o Added another example showing SRTP with session-level MIKEY and 3233 SDP Security Descriptions using the attribute capability DELETE 3234 operator. 3236 8.5. draft-ietf-mmusic-sdp-capability-negotiation-04 3238 The following are the major changes compared to version -03: 3240 o Added explicit ordering rules for attributes added by potential 3241 configurations. 3243 o Noted that ICE interaction issues (ice-tcp specifically) may not 3244 be as clear as originally thought. 3246 o Added considerations on using rtpmap and fmtp attributes as 3247 attribute capabilities. 3249 o Added multiple transport protocol example. 3251 o Added session-level MIKEY and media level security descriptions 3252 example. 3254 8.6. draft-ietf-mmusic-sdp-capability-negotiation-03 3256 The following are the major changes compared to version -02: 3258 o Base option tag name changed from "v0" to "cap-v0". 3260 o Added new section on extension capability attributes 3262 o Firmed up offer/answer procedures. 3264 o Added security considerations 3266 o Added IANA considerations 3268 8.7. draft-ietf-mmusic-sdp-capability-negotiation-02 3270 The following are the major changes compared to version -01: 3272 o Potential configurations are no longer allowed at the session 3273 level 3275 o Renamed capability attributes ("capar" to "acap" and "ctrpr" to 3276 "tcap") 3278 o Changed name and semantics of the initial number (now called 3279 configuration number) in potential configuration attributes; must 3280 now be unique and can be used as a handle 3282 o Actual configuration attribute now includes configuration number 3283 from the selected potential configuration attribute 3285 o Added ABNF throughout 3287 o Specified that answerer should include "a=csup" in case of 3288 unsupported required extensions in offer. 3290 o Specified use of second offer/answer exchange when answerer 3291 selected a potential configuration 3293 o Updated rules (and added restrictions) for referencing media- and 3294 session-level capabilities in potential configurations (at the 3295 media level) 3297 o Added initial section on ICE interactions 3299 o Added initial section on receiving media before answer 3301 8.8. draft-ietf-mmusic-sdp-capability-negotiation-01 3303 The following are the major changes compared to version -00: 3305 o Media capabilities are no longer considered a core capability and 3306 hence have been removed. This leaves transport protocols and 3307 attributes as the only capabilities defined by the core. 3309 o Version attribute has been removed and an option tag to indicate 3310 the actual version has been defined instead. 3312 o Clarified rules for session-level and media level attributes 3313 provided at either level as well how they can be used in 3314 potential configurations. 3316 o Potential configuration parameters no longer have implicit 3317 ordering; an explicit preference indicator is now included. 3319 o The parameter name for transport protocols in the potential and 3320 actual configuration attributes have been changed "p" to "t". 3322 o Clarified operator precedence within potential and actual 3323 configuration attributes. 3325 o Potential configurations at the session level now limited to 3326 indicate latent capability configurations. Consequently, an 3327 actual configuration attribute can no longer be provided at the 3328 session level. 3330 o Cleaned up capability and potential configuration terminology - 3331 they are now two clearly different things. 3333 8.9. draft-ietf-mmusic-sdp-capability-negotiation-00 3335 Version 00 is the initial version. The solution provided in this 3336 initial version is based on an earlier (individual submission) 3337 version of [SDPCapNeg]. The following are the major changes compared 3338 to that document: 3340 o Solution no longer based on RFC 3407, but defines a set of 3341 similar attributes (with some differences). 3343 o Various minor changes to the previously defined attributes. 3345 o Multiple transport capabilities can be included in a single 3346 "tcap" attribute 3348 o A version attribute is now included. 3350 o Extensions to the framework are formally supported. 3352 o Option tags and the ability to list supported and required 3353 extensions are supported. 3355 o A best-effort SRTP example use case has been added. 3357 o Some terminology change throughout to more clearly indicate what 3358 constitutes capabilities and what constitutes configurations. 3360 9. References 3362 9.1. Normative References 3364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3365 Requirement Levels", BCP 14, RFC 2119, March 1997. 3367 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3368 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3369 October 1998. 3371 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 3372 with Session Description Protocol (SDP)", RFC 3264, June 3373 2002. 3375 [RFC4234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 3376 Specifications: ABNF", RFC 4234, October 2005. 3378 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3379 Description Protocol", RFC 4566, July 2006. 3381 9.2. Informative References 3383 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3384 A., Peterson, J., Sparks, R., Handley, M., and E. 3385 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3386 June 2002. 3388 [RFC3312] G. Camarillo, W. Marshall, and J. Rosenberg, "Integration 3389 of Resource Management and Session Initiation Protocol 3390 (SIP)", RFC 3312, October 2002. 3392 [RFC3262] J. Rosenberg, and H. Schulzrinne, "Reliability of 3393 Provisional Responses in Session Initiation Protocol 3394 (SIP)", RFC 3262, June 2002. 3396 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 3397 Schulzrinne, "Grouping of Media Lines in the Session 3398 Description Protocol (SDP)", RFC 3388, December 2002. 3400 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 3401 Capability Declaration", RFC 3407, October 2002. 3403 [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and 3404 Video Conferences with Minimal Control", RFC 3551, July 3405 2003. 3407 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 3408 Norrman, "The Secure Real-time Transport Protocol 3409 (SRTP).", RFC 3711, March 2004. 3411 [RFC3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 3412 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 3413 August 2004. 3415 [RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 3416 (S/MIME) Version 3.1 Message Specification", RFC 3851, 3417 July 2004. 3419 [RFC3890] M. Westerlund, "A Transport Independent Bandwidth Modifier 3420 for the Session Description Protocol (SDP).", RFC 3890, 3421 September 2004. 3423 [RFC4474] J. Peterson, and C. Jennings, "Enhancements for 3424 Authenticated Identity Management in the Session 3425 Initiation Protocol (SIP)", RFC 4474, August 2006. 3427 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 3428 Carrara, "Key Management Extensions for Session 3429 Description Protocol (SDP) and Real Time Streaming 3430 Protocol (RTSP)", RFC 4567, July 2006. 3432 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 3433 Description Protocol Security Descriptions for Media 3434 Streams", RFC 4568, July 2006. 3436 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 3437 "Extended RTP Profile for Real-Time Transport Control 3438 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 3439 2006. 3441 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 3442 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 3443 July 2006. 3445 [RFC4756] A. Li, "Forward Error Correction Grouping Semantics in 3446 Session Description Protocol", RFC 4756, November 2006. 3448 [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for 3449 Session Description Protocol Media Streams", RFC 5027, 3450 October 2007. 3452 [BESRTP] Kaplan, H., and F. Audet, "Session Description Protocol 3453 (SDP) Offer/Answer Negotiation for Best-Effort Secure 3454 Real-Time Transport Protocol, Work in progress, August 3455 2006. 3457 [ICE] J. Rosenberg, "Interactive Connectivity Establishment 3458 (ICE): A Methodology for Network Address Translator (NAT) 3459 Traversal for Offer/Answer Protocols", work in progress, 3460 September 2007. 3462 [ICETCP] J. Rosenberg, "TCP Candidates with Interactive 3463 Connectivity Establishment (ICE)", work in progress, July 3464 2007. 3466 [SAVPF] Ott, J., and E Carrara, "Extended Secure RTP Profile for 3467 RTCP-based Feedback (RTP/SAVPF)", Work in Progress, May 3468 2007. 3470 [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", work in 3471 progress, December 2006. 3473 [SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session 3474 Description and Capability Negotiation", Work in Progress, 3475 February 2005. 3477 Author's Addresses 3479 Flemming Andreasen 3480 Cisco Systems 3481 Edison, NJ 3483 Email: fandreas@cisco.com 3485 Intellectual Property Statement 3487 The IETF takes no position regarding the validity or scope of any 3488 Intellectual Property Rights or other rights that might be claimed 3489 to pertain to the implementation or use of the technology described 3490 in this document or the extent to which any license under such 3491 rights might or might not be available; nor does it represent that 3492 it has made any independent effort to identify any such rights. 3493 Information on the procedures with respect to rights in RFC 3494 documents can be found in BCP 78 and BCP 79. 3496 Copies of IPR disclosures made to the IETF Secretariat and any 3497 assurances of licenses to be made available, or the result of an 3498 attempt made to obtain a general license or permission for the use 3499 of such proprietary rights by implementers or users of this 3500 specification can be obtained from the IETF on-line IPR repository 3501 at http://www.ietf.org/ipr. 3503 The IETF invites any interested party to bring to its attention any 3504 copyrights, patents or patent applications, or other proprietary 3505 rights that may cover technology that may be required to implement 3506 this standard. Please address the information to the IETF at 3507 ietf-ipr@ietf.org. 3509 Full Copyright Statement 3511 Copyright (C) The IETF Trust (2007). 3513 This document is subject to the rights, licenses and restrictions 3514 contained in BCP 78, and except as set forth therein, the authors 3515 retain all their rights. 3517 This document and the information contained herein are provided on 3518 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 3519 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 3520 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 3521 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 3522 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 3523 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 3524 FOR A PARTICULAR PURPOSE. 3526 Acknowledgment 3528 Funding for the RFC Editor function is currently provided by the 3529 Internet Society.