idnits 2.17.1 draft-ietf-mmusic-sdp-capability-negotiation-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1623. 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 26 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (February 13, 2007) is 6276 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: 'Section 8' is mentioned on line 1015, but not defined == Unused Reference: 'RFC2234' is defined on line 1487, but no explicit reference was found in the text == Unused Reference: 'RFC3407' is defined on line 1495, but no explicit reference was found in the text == Unused Reference: 'RFC3605' is defined on line 1498, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 1510, but no explicit reference was found in the text == Unused Reference: 'RFC2327' is defined on line 1514, but no explicit reference was found in the text == Unused Reference: 'RFC3388' is defined on line 1521, but no explicit reference was found in the text == Unused Reference: 'RFC3851' is defined on line 1533, but no explicit reference was found in the text == Unused Reference: 'RFC4091' is defined on line 1537, but no explicit reference was found in the text == Unused Reference: 'I-D.jennings-sipping-multipart' is defined on line 1545, but no explicit reference was found in the text == Unused Reference: 'SDPCapNegRqts' is defined on line 1570, but no explicit reference was found in the text == Unused Reference: 'MIKEY' is defined on line 1577, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4566 (ref. 'SDP') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- 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 4091 (Obsoleted by RFC 5245) Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Working Group F. Andreasen 2 Internet-Draft Cisco Systems 3 Intended Status: Proposed Standard February 13, 2007 4 Expires: August 2007 6 SDP Capability Negotiation 7 draft-ietf-mmusic-sdp-capability-negotiation-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on August 13, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The Session Description Protocol (SDP) was intended for describing 42 multimedia sessions for the purposes of session announcement, session 43 invitation, and other forms of multimedia session initiation. SDP was 44 not intended to provide capability indication or capability 45 negotiation, however over the years, SDP has seen widespread adoption 46 and as a result it has been gradually extended to provide limited 47 support for these. SDP and its current extensions however do not have 48 the ability to negotiate one or more alternative transport protocols 49 (e.g. RTP profiles) which makes it particularly difficult to deploy 50 new RTP profiles such as secure RTP or RTP with RTCP-based feedback. 51 The purpose of this document is to address that and other real-life 52 limitations by extending SDP with capability negotiation parameters 53 and associated offer/answer procedures to use those parameters in a 54 backwards compatible manner. 56 The solution provided in this document provides a general SDP 57 capability negotiation framework. It also defines specifically how to 58 provide attributes and transport protocols as capabilities and 59 negotiate them using the framework. Extensions for other types of 60 capabilities (e.g. media types and formats) may be provided in other 61 documents. 63 Table of Contents 65 1. Introduction...................................................3 66 2. Conventions used in this document..............................5 67 3. SDP Capability Negotiation Solution............................6 68 3.1. Solution Overview.........................................6 69 3.2. Version and Extension Indication Attributes...............9 70 3.2.1. Supported Capability Negotiation Extensions Attribute9 71 3.2.2. Required Capability Negotiation Extension Attribute.10 72 3.3. Capability Attributes....................................12 73 3.3.1. Attribute Capability Attribute......................12 74 3.3.2. Transport Protocol Capability Attribute.............13 75 3.4. Configuration Attributes.................................15 76 3.4.1. Potential Configuration Attribute...................15 77 3.4.2. Actual Configuration Attribute......................18 78 3.5. Offer/Answer Model Extensions............................20 79 3.5.1. Generating the Initial Offer........................20 80 3.5.2. Generating the Answer...............................21 81 3.5.3. Offerer Processing of the Answer....................22 82 3.5.4. Modifying the Session...............................22 83 3.6. Interactions with ICE....................................23 84 3.7. Processing Media before Answer...........................24 85 4. Examples......................................................24 86 4.1. Best-Effort Secure RTP...................................24 87 4.2. Multiple Transport Protocols.............................27 88 4.3. Session-Level MIKEY and Media Level Security Descriptions30 89 4.4. Capability Negotiation with Interactive Connectivity 90 Establishment.................................................30 91 5. Security Considerations.......................................30 92 6. IANA Considerations...........................................30 93 7. To Do and Open Issues.........................................30 94 8. Acknowledgments...............................................30 95 9. Change Log....................................................31 96 9.1. draft-ietf-mmusic-sdp-capability-negotiation-02..........31 97 9.2. draft-ietf-mmusic-sdp-capability-negotiation-01..........31 98 9.3. draft-ietf-mmusic-sdp-capability-negotiation-00..........32 99 10. References...................................................34 100 10.1. Normative References....................................34 101 10.2. Informative References..................................34 102 Author's Addresses...............................................36 103 Intellectual Property Statement..................................36 104 Full.............................................................37 105 Copyright Statement..............................................37 106 Acknowledgment...................................................37 108 1. Introduction 110 The Session Description Protocol (SDP) was intended for describing 111 multimedia sessions for the purposes of session announcement, session 112 invitation, and other forms of multimedia session initiation. The SDP 113 contains one or more media stream descriptions with information such 114 as IP-address and port, type of media stream (e.g. audio or video), 115 transport protocol (possibly including profile information, e.g. 116 RTP/AVP or RTP/SAVP), media formats (e.g. codecs), and various other 117 session and media stream parameters that define the session. 119 Simply providing media stream descriptions is sufficient for session 120 announcements for a broadcast application, where the media stream 121 parameters are fixed for all participants. When a participant wants 122 to join the session, he obtains the session announcement and uses the 123 media descriptions provided, e.g., joins a multicast group and 124 receives media packets in the encoding format specified. If the 125 media stream description is not supported by the participant, he is 126 unable to receive the media. 128 Such restrictions are not generally acceptable to multimedia session 129 invitations, where two or more entities attempt to establish a media 130 session that uses a set of media stream parameters acceptable to all 131 participants. First of all, each entity must inform the other of its 132 receive address, and secondly, the entities need to agree on the 133 media stream parameters to use for the session, e.g. transport 134 protocols and codecs. We here make a distinction between the 135 capabilities supported by each participant, the way in which those 136 capabilities can be supported and the parameters that can actually be 137 used for the session. More generally, we can say that we have the 138 following: 140 o A set of capabilities for the session and its associated media 141 stream components, supported by each side. 143 o A set of potential configurations indicating which of those 144 capabilities can be used for the session and its associated media 145 stream components. 147 o A set of actual configurations for the session and its associated 148 media stream components, which specifies which combinations of 149 session parameters and media stream components to use and with 150 what parameters. 152 o A negotiation process that takes the set of potential 153 configurations (combinations of capabilities) as input and 154 provides the actual configurations as output. 156 SDP by itself was designed to provide only one of these, namely the 157 actual configurations, however over the years, use of SDP has been 158 extended beyond its original scope. Session negotiation semantics 159 were defined by the offer/answer model in RFC 3264. It defines how 160 two entities, an offerer and an answerer, exchange session 161 descriptions to negotiate a session. The offerer can include one or 162 more media formats (codecs) per media stream, and the answerer then 163 selects one or more of those offered and returns them in an answer. 164 Both the offer and the answer contain actual configurations; 165 capabilities and potential configurations are not supported. The 166 answer however may reduce the set of actual configurations from the 167 offer as well as extend the set of actual configurations that can be 168 used to receive media by the answerer. 170 Other relevant extensions have been defined. Simple capability 171 declarations, which define how to provide a simple and limited set of 172 capability descriptions in SDP was defined in RFC 3407. Grouping of 173 media lines, which defines how media lines in SDP can have other 174 semantics than the traditional "simultaneous media streams" 175 semantics, was defined in RFC 3388, etc. 177 Each of these extensions was designed to solve a specific limitation 178 of SDP. Since SDP had already been stretched beyond its original 179 intent, a more comprehensive capability declaration and negotiation 180 process was intentionally not defined. Instead, work on a "next 181 generation" of a protocol to provide session description and 182 capability negotiation was initiated [SDPng]. SDPng however has not 183 gained traction and has remained as work in progress for an extended 184 period of time. Existing real-time multimedia communication 185 protocols such as SIP, RTSP, Megaco, and MGCP continue to use SDP. 186 SDP and its current extensions however do not address an increasingly 187 important problem: the ability to negotiate one or more alternative 188 transport protocols (e.g., RTP profiles). This makes it difficult to 189 deploy new RTP profiles such as secure RTP (SRTP) [SRTP], RTP with 190 RTCP-Based Feedback [AVPF], etc. This particular problem is 191 exacerbated by the fact that RTP profiles are defined independently. 192 When a new profile is defined and N other profiles already exist, 193 there is a potential need for defining N additional profiles, since 194 profiles cannot be combined automatically. For example, in order to 195 support the plain and secure RTP version of RTP with and without 196 RTCP-based feedback, four separate profiles (and hence profile 197 definitions) are needed: RTP/AVP [RFC3551], RTP/SAVP [SRTP], RTP/AVPF 198 [AVPF], and RTP/SAVPF [SAVPF]. In addition to the pressing profile 199 negotiation problem, other important real-life limitations have been 200 found as well. 202 The purpose of this document is to define a mechanism that enables 203 SDP to provide limited support for indicating capabilities and their 204 associated potential configurations, and negotiate the use of those 205 potential configurations as actual configurations. It is not the 206 intent to provide a full-fledged capability indication and 207 negotiation mechanism along the lines of SDPng or ITU-T H.245. 208 Instead, the focus is on addressing a set of well-known real-life 209 limitations. More specifically, the solution provided in this 210 document provides a general SDP capability negotiation framework. It 211 also defines specifically how to provide attributes and transport 212 protocols as capabilities and negotiate them using the framework. 213 Extensions for other types of capabilities (e.g. media types and 214 formats) may be provided in other documents. 216 As mentioned above, SDP is used by several protocols, and hence the 217 mechanism should be usable by all of these. One particularly 218 important protocol for this problem is the Session Initiation 219 Protocol (SIP) [RFC3261]. SIP uses the offer/answer model (which is 220 not specific to SIP) to negotiate sessions and hence the mechanism 221 defined here defines the offer/answer procedures to use for the 222 capability negotiation framework. 224 The rest of the document is structured as follows. In Section 3. we 225 present our SDP capability negotiation solution, which consists of 226 new SDP attributes and associated offer/answer procedures. In Section 227 4. we provide examples illustrating its use and in Section 5. we 228 provide the security considerations. 230 2. Conventions used in this document 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 234 document are to be interpreted as described in [RFC2119]. 236 3. SDP Capability Negotiation Solution 238 In this section we first provide an overview of the SDP Capability 239 negotiation solution. This is followed by definitions of new SDP 240 attributes for the solution and its associated updated offer/answer 241 procedures. 243 3.1. Solution Overview 245 The solution consists of the following: 247 o Two new attributes to support versioning and extensions to the 248 framework itself as follows: 250 o A new attribute ("a=csup") that lists the supported base and 251 extension options to the framework. 253 o A new attribute ("a=creq") that lists the base and or 254 extensions to the framework that are required to be supported 255 by the entity receiving the SDP in order to do capability 256 negotiation. 258 o Two new attributes used to express capabilities as follows 259 (additional attributes can be defined as extensions): 261 o A new attribute ("a=acap") that defines how to list attribute 262 parameter values ("a=" values) as capabilities. 264 o A new attribute ("a=tcap") that defines how to list transport 265 protocols (e.g. "RTP/AVP") as capabilities. 267 o Two new attributes to negotiate configurations as follows: 269 o A new attribute ("a=pcfg") that lists the potential 270 configurations supported. This is done by reference to the 271 capabilities from the SDP in question. Multiple potential 272 configurations have an explicitly indicated ordering 273 associated with them. Extension capabilities can be defined 274 and referenced in the potential configurations. 276 o A new attribute ("a=acfg") to be used in an answer SDP. The 277 attribute identifies which of the potential configurations 278 from an offer SDP were used as actual configurations to form 279 the answer SDP. Extension capabilities can be included as 280 well. 282 o Extensions to the offer/answer model that allow for capabilities 283 and potential configurations to be included in an offer. 284 Capabilities can be provided at the session level or the media 285 level. Potential configurations can be included at the media level 286 only, where they constitute alternative offers that may be 287 accepted by the answerer instead of the actual configuration(s) 288 included in the "m=" line(s). The answerer indicates which (if 289 any) of the potential configurations it used to form the answer by 290 including the actual configuration attribute ("a=acfg") in the 291 answer. Capabilities may be included in answers as well, where 292 they can aid in guiding a subsequent new offer. 294 The mechanism is illustrated by the offer/answer exchange below, 295 where Alice sends an offer to Bob: 297 Alice Bob 299 | (1) Offer (SRTP and RTP) | 300 |--------------------------------->| 301 | | 302 | (2) Answer (SRTP) | 303 |<---------------------------------| 304 | | 306 Alice's offer includes RTP and SRTP as alternatives. RTP is the 307 default (actual configuration), but SRTP is the preferred one 308 (potential configuration): 310 v=0 311 o=- 25678 753849 IN IP4 128.96.41.1 312 s= 313 c=IN IP4 128.96.41.1 314 t=0 0 315 m=audio 3456 RTP/AVP 0 18 316 a=creq: v0 317 a=tcap:1 RTP/SAVP 318 a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 319 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 320 a=pcfg:1 t=1 a=1 322 The "m=" line indicates that Alice is offering to use plain RTP with 323 PCMU or G.729. The required base and extensions are provided by the 324 "a=creq" attribute, which includes the option tag "v0" to indicate 325 that the base framework defined here must be supported. The 326 capabilities are provided by the "a=tcap" and "a=acap" attributes. 327 The transport capabilities ("a=tcap") indicate that secure RTP under 328 the AVP profile ("RTP/SAVP") is supported with an associated 329 transport capability handle of 1. The "acap" attribute provides an 330 attribute capability with a handle of 1. The attribute capability is 331 a "crypto" attribute, which provides the keying material for SRTP 332 using SDP security descriptions [SDES]. The "a=pcfg" attribute 333 provides the potential configuration included in the offer by 334 reference to the capability parameters. One alternative is provided; 335 it has a configuration number of 1 and it consists of transport 336 protocol capability 1 (i.e. the RTP/SAVP profile - secure RTP), and 337 the attribute capability 1, i.e. the crypto attribute provided. 338 Potential configurations are always preferred over actual 339 configurations, and hence Alice is expressing a preference for using 340 secure RTP. 342 Bob receives the SDP offer from Alice. Bob supports SRTP and the SDP 343 Capability Negotiation framework, and hence he accepts the 344 (preferred) potential configuration for Secure RTP provided by Alice: 346 v=0 347 o=- 24351 621814 IN IP4 128.96.41.2 348 s= 349 c=IN IP4 128.96.41.2 350 t=0 0 351 m=audio 4567 RTP/SAVP 0 18 352 a=crypto:1 AES_CM_128_HMAC_SHA1_80 353 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 354 a=acfg:1 t=1 a=1 356 Bob includes the "a=acfg" attribute in the answer to inform Alice 357 that he based his answer on an offer containing the potential 358 configuration with transport protocol capability 1 and attribute 359 capability 1 from the offer SDP (i.e. the RTP/SAVP profile using the 360 keying material provided). Bob also includes his keying material in 361 a crypto attribute. If Bob supported one or more extensions to the 362 capability negotiation framework, he would have included those in the 363 answer as well (in an "a=csup" attribute). 365 Note that in this particular example, the answerer supported the 366 capability negotiation extensions defined here, however had he not, 367 the answerer would simply have ignored the new attributes and 368 accepted the (actual configuration) offer to use normal RTP. In that 369 case, the following answer would have been generated instead: 371 v=0 372 o=- 24351 621814 IN IP4 128.96.41.2 373 s= 374 c=IN IP4 128.96.41.2 375 t=0 0 376 m=audio 4567 RTP/AVP 0 18 378 3.2. Version and Extension Indication Attributes 380 In this section, we present the new attributes associated with 381 indicating the SDP capability negotiation extensions supported and 382 required. 384 3.2.1. Supported Capability Negotiation Extensions Attribute 386 The SDP Capability negotiation solution allows for capability 387 negotiation extensions to be defined. Associated with each such 388 extension is an option tag that identifies the extension in question. 389 Option-tags MUST be registered with IANA per the procedures defined 390 in Section 6. 392 The Supported Capability Negotiation Extensions attribute ("a=csup") 393 contains a comma-separated list of option tags identifying the SDP 394 Capability negotiation extensions supported by the entity that 395 generated the SDP. The attribute is defined as follows: 397 a=csup: 399 RFC 4566, Section 9, provides the ABNF for SDP attributes. The "csup" 400 attribute adheres to the RFC 4566 "attribute" production, with an 401 att-value defined as follows: 403 att-value = *WSP option-tag-list 404 option-tag-list = option-tag *(COMMA option-tag) 405 option-tag = token ; defined in [SDP] 406 COMMA = *WSP "," *WSP ; defined in [RFC4234] 408 Note that white-space is permitted before the option-tag-list. Also, 409 implementers familiar with SIP should note that the above definition 410 of COMMA differs from the one in [RFC3261]. 412 A special base option tag with a value of "v0" is defined for the 413 basic SDP capability negotiation framework. Entities use this option 414 tag with the "a=csup" attribute to indicate support for the SDP 415 capability negotiation framework specified in this document. 417 The following examples illustrates the use of the "a=csup" attribute 418 with the "v0" option tags and two hypothetical option tags, "foo" and 419 "bar": 421 a=csup: v0 422 a=csup: foo 423 a=csup: bar 424 a=csup: v0, foo, bar 426 The "a=csup" attribute can be provided at the session and the media- 427 level. When provided at the session-level, it applies to the entire 428 SDP. When provided at the media-level, it applies to the media-stream 429 in question only (option-tags provided at the session level apply as 430 well). There can be one or more "a=csup" attributes at both the 431 session and media-level (one or more per media stream in the latter 432 case). 434 Whenever an entity that supports one or more extensions to the SDP 435 Capability Negotiation framework generates an SDP, it SHOULD include 436 the "a=csup" attribute with the option tags for the extensions it 437 supports at the session and/or media-level, unless those option tags 438 are already provided in one or more "a=creq" attribute (see Section 439 3.2.2. ) at the relevant levels. The base option tag MAY be included. 441 3.2.2. Required Capability Negotiation Extension Attribute 443 The SDP Capability negotiation solution allows for capability 444 negotiation extensions to be defined. Associated with each such 445 extension is an option tag that identifies the extension in question. 446 Option-tags MUST be registered with IANA per the procedures defined 447 in Section 6. 449 The Required Capability Negotiation Extensions attribute ("a=creq") 450 contains a comma-separated list of option tags identifying the SDP 451 Capability negotiation extensions that MUST be supported by the 452 entity receiving the SDP in order for that entity to properly process 453 the SDP Capability negotiation. The attribute is defined as follows: 455 a=creq: 457 The "creq" attribute adheres to the RFC 4566 "attribute" production, 458 with an att-value defined as follows: 460 att-value = *WSP option-tag-list 462 where "option-tag-list" is defined in Section 3.2.1. Note that 463 white-space is permitted before the option-tag-list. 465 The following examples illustrate the use of the "a=creq" attribute 466 with the "v0" base option tag and two hypothetical option tags, "foo" 467 and "bar": 469 a=creq: v0 470 a=creq: foo 471 a=creq: bar 472 a=creq: v0, foo, bar 474 The "a=creq" attribute can be provided at the session and the media- 475 level. When provided at the session-level, it applies to the entire 476 SDP. When provided at the media-level, it applies to the media-stream 477 in question only (required option tags provided at the session level 478 apply as well). There can be one or more "a=creq" attributes at both 479 the session and media-level (one or more per media stream in the 480 latter case). 482 When an entity generates an SDP and it requires the recipient of that 483 SDP to support one or more SDP capability negotiation extensions in 484 order to properly process the SDP Capability negotiation, the 485 "a=creq" attribute MUST be included with option-tags that identify 486 the required extensions at the session and/or media level, unless it 487 is already known that the receiving entity supports those option-tags 488 at the relevant levels (in which case their inclusion is OPTIONAL). 490 An example of this is when generating an answer to an offer. If the 491 answerer supports the required option-tags from the offer, and the 492 answerer does not require any additional option-tags beyond what 493 was listed in either the required ("a=creq") or supported 494 ("a=csup") attributes from the offer, then the answerer is not 495 required to include a required ("a=creq") attribute with any 496 option-tags that may need to be supported (such as the base option 497 tag - "v0"). 499 A recipient that receives an SDP and does not support one or more of 500 the required extensions listed in a "creq" attribute, MUST NOT 501 perform the SDP capability negotiation defined in this document. For 502 non-supported extensions provided at the session-level, this implies 503 that SDP capability negotiation MUST NOT be performed at all. For 504 non-supported extensions at the media-level, this implies that SDP 505 capability negotiation MUST NOT be performed for the media stream in 506 question. 508 When an entity does not support one or more required SDP capability 509 negotiation extensions, the entity SHOULD proceed as if the SDP 510 capability negotiation attributes were not included in the first 511 place, i.e. all the capability negotiation attributes should be 512 ignored. In that case, the entity SHOULD include a "csup" attribute 513 listing the SDP capability negotiation extensions it actually 514 supports. 516 This ensures that introduction of the SDP capability negotiation 517 mechanism does not introduce any new failure scenarios. 519 The above rules apply to the base option tag as well. Thus, entities 520 compliant to this specification MUST include a "creq" attribute (at 521 least in an offer) that includes the option tag "v0" as illustrated 522 below: 524 a=creq: v0 526 3.3. Capability Attributes 528 In this section, we present the new attributes associated with 529 indicating the capabilities for use by the SDP Capability 530 negotiation. 532 3.3.1. Attribute Capability Attribute 534 Attributes can be expressed as negotiable parameters by use of a new 535 attribute capability attribute ("a=acap"), which is defined as 536 follows: 538 a=acap: 540 where is an integer between 1 and 2^31-1 (both 541 included) used to number the attribute capability and is an 542 attribute ("a=") in its full '=' form (see [SDP]). 544 The "acap" attribute adheres to the RFC 4566 "attribute" production, 545 with an att-value defined as follows: 547 att-value = *WSP att-cap-num 1*WSP att-par 548 att-cap-num = 1*DIGIT ;defined in [RFC4234] 549 att-par = attribute ;defined in RFC 4266 551 Note that white-space is permitted before the att-cap-num. The "acap" 552 attribute can be provided at the session level for session-level 553 attributes and the media level for media-level attributes. The "acap" 554 attribute MUST NOT be used to provide a media-level attribute at the 555 session-level or vice versa. 557 Each occurrence of the "acap" attribute in the entire session 558 description MUST use a different value of . 560 There is a need to be able to reference both session-level and 561 media-level attributes in potential configurations at the media 562 level, and this provides for a simple solution to avoiding overlap 563 between the references (handles) to each attribute capability. 565 The values provided are independent of similar values provided for other capability attributes, i.e., they form 567 a separate name-space for attribute capabilities. 569 The following examples illustrate use of the "acap" attribute: 571 a=acap: 1 a=ptime:20 573 a=acap: 2 a=ptime:30 575 a=acap: 3 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAA 576 AAAGEEoo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0 577 JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUO 578 SrzKTAv9zV 580 a=acap: 4 a=crypto:1 AES_CM_128_HMAC_SHA1_32 581 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 583 The first two provide attribute values for the ptime attribute. The 584 third provides SRTP parameters by using MIKEY with the key-mgmt 585 attribute [KMGMT]. The fourth provides SRTP parameters by use of 586 security descriptions with the crypto attribute [SDES]. Note that the 587 line-wrapping and new-lines in example three and four are provided 588 for formatting reasons only - they are not permitted in actual SDP. 590 Readers familiar with RFC 3407 may notice the similarity between 591 the RFC 3407 "cpar" attribute and the above. There are however a 592 couple of important differences, most notably that the "acap" 593 attribute contains a handle that enables referencing it and it 594 furthermore supports attributes only (the "cpar" attribute defined 595 in RFC 3407 supports bandwidth information as well). The "acap" 596 attribute also is not automatically associated with any particular 597 capabilities. 599 3.3.2. Transport Protocol Capability Attribute 601 Transport Protocols can be expressed as capabilities by use of a new 602 Transport Protocol Capability attribute ("a=tcap") defined as 603 follows: 605 a=tcap: 607 where is an integer between 1 and 2^31-1 (both 608 included) used to number the transport address capability for later 609 reference, and is one or more , separated by 610 white space, as defined in the SDP "m=" line. 612 The "tcap" attribute adheres to the RFC 4566 "attribute" production, 613 with an att-value defined as follows: 615 att-value = *WSP trpr-cap-num 1*WSP proto-list 616 trpr-cap-num = 1*DIGIT ;defined in [RFC4234] 617 proto-list = proto *(1*WSP proto) ; defined in RFC 4566 619 Note that white-space is permitted before the trpr-cap-num. The 620 "tcap" attribute can be provided at the session- and media-level. 621 Each occurrence of the "tcap" attribute in the entire session 622 description MUST use a different value of . When 623 multiple values are provided, the first one is associated 624 with the value , the second one with the value one 625 higher, etc. The values provided are independent of 626 similar values provided for other capability attributes, 627 i.e., they form a separate name-space for transport protocol 628 capabilities. 630 Below, we provide examples of the "a=tcap" attribute: 632 a=tcap: 1 RTP/AVP 633 a=tcap: 2 RTP/AVPF 634 a=tcap: 3 RTP/SAVP RTP/SAVPF 636 The first one provides a capability for the "RTP/AVP" profile defined 637 in [RFC3551] and the second one provides a capability for the RTP 638 with RTCP-Based Feedback profile defined in [AVPF]. The third one 639 provides capabilities for the "RTP/SAVP" and "RTP/SAVPF" profiles. 641 Transport capabilities are inherently included in the "m=" line, 642 however they still need to be specified explicitly in a "tcap" 643 attribute, if they are to be used as a capability. This may seem 644 redundant (and indeed it is from the offerer's point of view), 645 however it is done to protect against middle-boxes that may modify 646 "m=" lines while passing unknown attributes through. If an implicit 647 capability were used instead (e.g. a reserved transport capability 648 number could be used to refer to the transport protocol in the "m=" 649 line), and a middle-box were to modify the transport protocol in the 650 "m=" line (e.g. to translate between plain RTP and secure RTP), then 651 the potential configuration referencing that implicit transport 652 capability may no longer be correct. With explicit capabilities, we 653 avoid this pitfall, although the potential configuration preference 654 (see Section 3.4.1. ) may not reflect that of the middle-box (which 655 some may view as a feature). 657 3.4. Configuration Attributes 659 3.4.1. Potential Configuration Attribute 661 Potential Configurations can be expressed by use of a new Potential 662 Configuration Attribute ("a=pcfg") defined as follows: 664 a=pcfg: 666 where is an integer between 1 and 2^31-1 (both 667 included). 669 The "pcfg" attribute adheres to the RFC 4566 "attribute" production, 670 with an att-value defined as follows: 672 att-value = *WSP config-number 1*WSP pot-cfg-list 673 config-number = 1*DIGIT ;defined in [RFC4234] 674 pot-cfg-list = pot-config *(1*WSP pot-config) 675 pot-config = pot-attribute-parameter-config / 676 pot-transport-protocol-config / 677 pot-extension-config 679 The missing productions are defined below. Note that white-space is 680 permitted before the config-number. 682 The potential configuration attribute can be provided at the media- 683 level only. The attribute includes a configuration number, which is 684 an integer between 1 and 2^31-1 (both included). The configuration 685 number MUST be unique within the media stream. The configuration 686 number also indicates the relative preference of potential 687 configurations; lower numbers are preferred over higher numbers. 689 After the configuration number, one or more potential configuration 690 parameters MUST be provided. This document defines potential 691 attribute parameter configurations and potential transport protocol 692 configurations. Each of these MUST NOT be present more than once in 693 a particular potential configuration attribute. Potential extension 694 configurations can be included as well; unknown potential extension 695 configurations MUST be ignored (if support is required, then the 696 "a=creq" with a suitable option tag should be used). There can be 697 more than one potential extension configuration, however each 698 particular potential extension configuration MUST NOT be present more 699 than once in a given potential configuration attribute. Together, 700 these values define a potential configuration. 702 There can be multiple potential configurations provided within a 703 media description. Each of these indicates not only a willingness, 704 but in fact a desire to use the potential configuration. 706 Attribute capabilities are included in a potential configuration by 707 use of the pot-attribute-parameter-config parameter, which is defined 708 by the following ABNF: 710 pot-attribute-parameter-config 711 = "a=" acap-cap-list *(BAR acap-cap-list) 712 acap-cap-list = att-cap-num *(COMMA att-cap-num) 713 att-cap-num = 1*DIGIT ;defined in [RFC4234] 714 BAR = *WSP "|" *WSP ; defined in [RFC4234] 716 Each potential attribute parameter configuration list is a comma- 717 separated list of attribute capability numbers where att-cap-num 718 refers to attribute capability numbers defined above and hence MUST 719 be between 1 and 2^31-1 (both included). Alternative potential 720 attribute parameter configurations are separated by a vertical bar 721 ("|"), the scope of which extends to the next alternative (i.e. "," 722 has higher precedence than "|"). The alternatives are ordered by 723 preference with the most preferred listed first. 725 Transport protocol capabilities are included in a potential 726 configuration by use of the pot-transport-protocol-config parameter, 727 which is defined by the following ABNF: 729 pot-transport-protocol-config = 730 "t=" trpr-cap-num *(BAR trpr-cap-num) 731 trpr-cap-num = 1*DIGIT ; defined in [RFC4234] 733 The trpr-cap-num refers to transport protocol capability numbers 734 defined above and hence MUST be between 1 and 2^31-1 (both included). 735 Alternative potential transport protocol configurations are separated 736 by a vertical bar ("|"). The alternatives are ordered by preference 737 with the most preferred listed first. When transport protocol 738 capabilities are not included in a potential configuration at the 739 media level, the transport protocol information from the associated 740 "m=" line will be used. 742 In the presence of middle-boxes (the existence of which may not be 743 known), care should be taken with assuming that the transport 744 protocol in the "m=" line will not be modified by a middle-box. Use 745 of an explicit capability will guard against the capability 746 indications of that. 748 Extension capabilities can be included in a potential configuration 749 as well. Such extensions MUST adhere to the following ABNF: 751 pot-extension-config = ext-cap-name "=" 752 ext-cap-list *(BAR ext-cap-list) 753 ext-cap-name = token ; defined in [SDP] 754 ext-cap-list = ext-cap-num *(COMMA ext-cap-num) 755 ext-cap-num = 1*DIGIT ; defined in [RFC4234] 757 The ext-cap-name refers to the type of extension capability and the 758 ext-cap-num refers to a capability number associated with that 759 particular type of extension capability. The number MUST be between 760 1 and 2^31-1 (both included). Alternative potential extension 761 configurations for a particular extension are separated by a vertical 762 bar ("|"),the scope of which extends to the next alternative (i.e. 763 "," has higher precedence than "|"). Unsupported or unknown 764 potential extension configs MUST be ignored. 766 The "creq" attribute and its associated rules can be used to ensure 767 that required extensions are supported in the first place. 769 Potential configurations can be provided at the media level only, 770 however it is possible to reference capabilities provided at either 771 the session or media level. There are certain semantic rules and 772 restrictions associated with this: 774 A (media level) potential configuration in a given media description 775 MUST NOT reference a media-level capability provided in a different 776 media description; doing so invalidates that potential configuration. 777 A potential configuration can however reference a session-level 778 capability. The semantics of doing so (should that potential 779 configuration be chosen), depends on the type of capability. In the 780 case of transport capabilities, this has no particular implication. 781 In the case of attribute capabilities however, it does. More 782 specifically, the corresponding attribute value (provided within that 783 attribute capability) will be considered part of the active 784 configuration at the *session* level. In other words, it will be as- 785 if that attribute was simply provided with that value at the session- 786 level in the first place. Note that individual media streams perform 787 capability negotiation individually, and hence it is possible that 788 another media stream (where the attribute was part of a potential 789 configuration) chose a configuration without that session level 790 attribute. The session-level attribute however remains "active" and 791 hence applies to the entire session. It is up to the entity that 792 generates the SDP to ensure that in such cases, the resulting active 793 configuration SDP is still meaningful. 795 The session-level operation of extension capabilities is undefined: 796 Consequently, if session-level extension capabilities are defined, 797 they MUST specify the implication of making them part of an active 798 configuration at the media level. 800 Below, we provide an example of the "a=pcfg" attribute in a complete 801 media description in order to properly indicate the supporting 802 attributes: 804 v=0 805 o=- 25678 753849 IN IP4 128.96.41.1 806 s= 807 c=IN IP4 128.96.41.1 808 t=0 0 809 m=audio 3456 RTP/AVPF 0 18 810 a=creq: v0 811 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 812 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 813 a=tcap: 1 RTP/AVPF RTP/AVP 814 a=tcap: 3 RTP/SAVP RTP/SAVPF 815 a=pcfg:1 t=4|3 a=1 816 a=pcfg:8 t=1|2 818 We have two potential configurations listed here. The first one (and 819 most preferred, since its configuration number is "1") indicates that 820 either of the profiles RTP/SAVPF or RTP/SAVP (specified by the 821 transport protocol capability numbers 4 and 3) can be supported with 822 attribute capability 1 (the "crypto" attribute); RTP/SAVPF is 823 preferred over RTP/SAVP since its capability number (4) is listed 824 first in the preferred potential configuration. The second potential 825 configuration indicates that the RTP/AVPF of RTP/AVP profile can be 826 used, with RTP/AVPF being the preferred one. This non secure RTP 827 alternative is the less preferred one since its configuration number 828 is "8". 830 3.4.2. Actual Configuration Attribute 832 The actual configuration attribute identifies which of the potential 833 configurations from an offer SDP were used as actual configurations 834 in an answer SDP. This is done by reference to the configuration 835 number and the attribute capabilities and transport protocol 836 capabilities from the offer that were actually used by the answerer 837 in his offer/answer procedure. If extension capabilities were used, 838 those will be included by reference as well. Note that the 839 configuration number and all capability numbers used are those from 840 the offer; not the answer. 842 The Actual Configuration Attribute ("a=acfg") is defined as follows: 844 a=acfg: 846 The "acfg" attribute adheres to the RFC 4566 "attribute" production, 847 with an att-value defined as follows: 849 att-value = *WSP config-number 1*WSP act-cfg-list 850 ;config-number defined in Section 3.4.1. 851 act-cfg-list = capability *(1*WSP capability) 852 capability = act-attribute-parameter-config / 853 act-transport-protocol-config / 854 act-extension-config 856 act-attribute-parameter-config = 857 "a=" acap-cap-list ; defined in Section 3.4.1. 859 act-transport-protocol-config = 860 "t=" trpr-cap-num ; defined in Section 3.4.1. 862 act-extension-config = 863 ext-cap-name "=" ext-cap-list ; defined in Section 3.4.1. 865 Note that white-space is permitted before the config-number. The 866 actual configuration ("a=acfg") attribute can be provided at the 867 media-level only. There MUST NOT be more than one occurrence of an 868 actual configuration attribute within a given media description. 870 Below, we provide an example of the "a=acfg" attribute (building on 871 the previous example with the potential configuration attribute): 873 v=0 874 o=- 24351 621814 IN IP4 128.96.41.2 875 s= 876 c=IN IP4 128.96.41.2 877 t=0 0 878 m=audio 4567 RTP/SAVPF 0 879 a=creq: 0 880 a=acfg:1 t=4 a=1 882 It indicates that the answerer used an offer consisting of potential 883 configuration number 1 with transport protocol capability 4 from the 884 offer (RTP/SAVPF) and attribute capability 1 (the "crypto" 885 attribute). 887 3.5. Offer/Answer Model Extensions 889 In this section, we define extensions to the offer/answer model 890 defined in [RFC3264] to allow for potential configurations to be 891 included in an offer, where they constitute offers that may be 892 accepted by the answerer instead of the actual configuration(s) 893 included in the "m=" line(s). 895 [EDITOR'S NOTE: Multicast considerations have been omitted for 896 now.] 898 TO DO: Elaborate and firm up offer/answer procedures. 900 3.5.1. Generating the Initial Offer 902 An offerer that wants to use the SDP capability negotiation 903 extensions defined in this document MUST include the following in the 904 offer: 906 o an SDP capability negotiation required extensions attribute ("a- 907 creq") that contains the option tag "v0". It must either be 908 provided at the session-level or for each individual media stream. 909 Option tags for any other required extensions MUST be included as 910 well (in accordance with Section 3.2.2. ) 912 o one or more attribute capability attributes (as defined in Section 913 3.3.1. ) if alternative attribute parameter values are to be 914 indicated as offerer capabilities or be negotiated. 916 o one or more transport protocol capability attributes (as defined 917 in Section 3.3.2. ) if alternative transport protocols are to be 918 to be indicated as offerer capabilities or be negotiated. 920 o one or more potential configuration attributes (as defined in 921 Section 3.4. ) if alternative potential configurations are to be 922 negotiated. 924 o one or more required capability negotiation extension attributes 925 (as defined in Section 3.2.2. ), if the answerer is required to 926 support one or more SDP capability negotiation extensions. 928 The offerer SHOULD furthermore include the following: 930 o one or more supported capability negotiation extension attributes 931 ("a=csup" as defined in Section 3.2.1. ), if the offerer supports 932 one or more SDP capability negotiation extensions that have not 933 been included in one or more "a=creq" attributes at the relevant 934 session and media level(s). 936 The capabilities provided merely indicate what the offerer is capable 937 of doing. They do not constitute a commitment or even an indication 938 to actually use them. This applies to potential configurations listed 939 at the session level as well. Conversely, each of the potential 940 configurations listed at the media level constitutes an alternative 941 offer which may be used to negotiate and establish the session. 943 The current actual configuration is included in the "m=" line (as 944 defined by [RFC3264]). Per [RFC3264], once the offerer generates the 945 offer, he must be prepared to receive incoming media in accordance 946 with that offer. That rule applies here as well, but for the actual 947 configurations only; media received by the offerer according to one 948 of the potential configurations MAY be discarded, until the offerer 949 receives an answer indicating what the actual configuration is. Once 950 that answer is received, incoming media MUST be processed in 951 accordance with the actual configuration indicated and the answer 952 received. 954 3.5.2. Generating the Answer 956 When the answerer receives an offer with valid SDP capability 957 negotiation information in it and in particular with one or more 958 valid potential configuration information attributes present, it may 959 use any of the potential configurations as an alternative offer. A 960 potential configuration information attribute is valid if all of the 961 capabilities (attribute capabilities, transport protocol capabilities 962 and any extension capabilities) it references are present and valid 963 themselves. 965 The actual configuration is contained in the media description's "m=" 966 line. The answerer can send media to the offerer in accordance with 967 the actual configuration, however if it chooses to use one of the 968 alternative potential configurations, media sent to the offerer may 969 be discarded by the offerer until the answer is received. 971 If the answerer chooses to accept one of the alternative potential 972 configurations instead of the actual configuration, the answerer MUST 973 generate an answer as if the offer contained that potential 974 configuration instead of the actual configuration included. The 975 answerer MUST also include an actual configuration attribute in the 976 answer that identifies the potential configuration from the offer 977 used by the answerer. The actual configuration attribute in the 978 answer MUST include information about the attribute capabilities, 979 transport protocol parameters, and extension capabilities from the 980 potential configuration that were used to generate the answer. 982 3.5.3. Offerer Processing of the Answer 984 When the offerer included potential configurations for a media 985 stream, it MUST examine the answer for the presence of an actual 986 configuration attribute for each such media stream. If the attribute 987 is missing, offerer processing of the answer MUST proceed as defined 988 by [RFC3264]. If the attribute is present, processing continues as 989 follows: 991 The actual configuration attribute specifies which of the potential 992 configurations were used by the answerer to generate the answer. This 993 includes all the types of capabilities from the potential 994 configuration offered, i.e. the attribute capabilities ("a=acap"), 995 transport protocol capabilities ("a=tcap"), and any extension 996 capability parameters included. 998 The offerer MUST now process the answer as if the offer had contained 999 the potential configuration as the actual configuration in the media 1000 description ("m=" line) and relevant attributes in the offer. 1002 If the answerer selected one of the potential configurations from the 1003 offer as the actual configuration, then the offerer SHOULD perform 1004 another offer/answer exchange, where the offer contains the selected 1005 potential configuration as the actual configuration, i.e. with the 1006 actual configuration used in the "m=" line and any other relevant 1007 attributes. This second offer/answer exchange will not modify the 1008 session anyway, however it will help intermediaries that look at the 1009 SDP, but do not understand the capability negotiation extensions, to 1010 understand the details of the negotiated media streams. 1012 3.5.4. Modifying the Session 1014 Potential configurations may be included in subsequent offers as 1015 defined in [RFC3264, Section 8]. The procedure for doing so is 1016 similar to that described above with the answer including an 1017 indication of the actual configuration used by the answerer. 1019 If the answer indicates use of a potential configuration from the 1020 offer, then a second offer/answer exchange using that potential 1021 configuration as the actual configuration SHOULD be performed. 1023 3.6. Interactions with ICE 1025 Interactive Connectivity Establishment (ICE) [ICE] provides a 1026 mechanism for verifying connectivity between two endpoints by sending 1027 STUN messages directly between the media endpoints. The basic ICE 1028 specification [ICE] is defined to support UDP-based connectivity 1029 only, however it allows for extensions to support other transport 1030 protocols, such as TCP, which is being specified in [ICETCP]. ICE 1031 defines a new "a=candidate" attribute, which, among other things, 1032 indicates the possible transport protocol(s) to use and then 1033 associates a priority with each of them. The most preferred transport 1034 protocol that *successfully* verifies connectivity will end up being 1035 used. 1037 When using ICE, it is thus possible that the transport protocol that 1038 will be used differs from what is specified in the "m=" line. 1039 Furthermore, since both ICE and SDP Capability Negotiation may now 1040 specify alternative transport protocols, there is a potentially 1041 unintended interaction when using these together. 1043 We provide the following guidelines for addressing that. 1045 [EDITOR'S NOTE: This requires more work] 1047 There are two basic scenarios to consider here: 1049 1) A particular media stream can run over different transport 1050 protocols (e.g. UDP, TCP, or TCP/TLS), and the intent is simply to 1051 use the one that works (in the preference order specified). 1053 2) A particular media stream can run over different transport 1054 protocols (e.g. UDP, TCP, or TCP/TLS) and the intent is to have the 1055 negotiation process decide which one to use (e.g. T.38 over TCP or 1056 UDP). 1058 In scenario 1, there should be ICE "a=candidate" attributes for UDP, 1059 TCP, etc. but otherwise nothing special in the potential 1060 configuration attributes to indicate the desire to use different 1061 transport protocols (e.g. UDP, or TCP). The ICE procedures 1062 essentially cover the capability negotiation required (by having the 1063 answerer select something it supports and then use of trial and 1064 error). 1066 Scenario 2 does not require a need to support or use ICE. Instead, we 1067 simply use transport protocol capabilities and potential 1068 configuration attributes to indicate the desired outcome. 1070 The scenarios may be combined, e.g. by offering potential 1071 configuration alternatives where some of them can support one 1072 transport protocol only (e.g. UDP), whereas others can support 1073 multiple transport protocols (e.g. UDP or TCP). In that case, the ICE 1074 candidate attributes should be defined as attribute capabilities and 1075 the relevant ones should then be included in the proper potential 1076 configurations (for example candidate attributes for UDP only for 1077 potential configurations that are restricted to UDP, whereas there 1078 could be candidate attributes for UDP, TCP, and TCP/TLS for potential 1079 configurations that can use all three). 1081 3.7. Processing Media before Answer 1083 The offer/answer model requires an offerer to be able to receive 1084 media in accordance with the offer prior to receiving the answer. 1085 This property is retained with the SDP capability negotiation 1086 extensions defined here, but only when the actual configuration is 1087 selected by the answerer. If a potential configuration is chosen, it 1088 is permissible for the offerer to not process any media received 1089 before the answer is received. This however may lead to clipping. 1091 In the case of SIP, this issue could be solved easily by defining a 1092 precondition [RFC3312] for capability negotiation, however 1093 preconditions are viewed as complicated to implement and they add to 1094 overall session establishment delay by requiring an extra 1095 offer/answer exchange. An alternative is therefore desirable. 1097 The SDP capability negotiation framework does not define such an 1098 alternative, however extensions may do so. For example, one technique 1099 proposed for best-effort SRTP in [BESRTP] is to provide different RTP 1100 payload type mappings for different transport protocols used. The 1101 basic SDP capability negotiation framework defined here does not 1102 include the ability to do so, however extensions that enable that may 1103 be defined. 1105 4. Examples 1107 In this section, we provide examples showing how to use the SDP 1108 Capability Negotiation. 1110 4.1. Best-Effort Secure RTP 1112 The following example illustrates how to use the SDP Capability 1113 negotiation extensions to support so-called Best-Effort Secure RTP. 1114 In that scenario, the offerer supports both RTP and Secure RTP. If 1115 the answerer does not support secure RTP (or the SDP capability 1116 negotiation extensions), an RTP session will be established. However, 1117 if the answerer supports Secure RTP and the SDP Capability 1118 Negotiation extensions, a Secure RTP session will be established. 1120 The best-effort Secure RTP negotiation is illustrated by the 1121 offer/answer exchange below, where Alice sends an offer to Bob: 1123 Alice Bob 1125 | (1) Offer (SRTP and RTP) | 1126 |--------------------------------->| 1127 | | 1128 | (2) Answer (SRTP) | 1129 |<---------------------------------| 1130 | | 1131 | (3) Offer (SRTP) | 1132 |--------------------------------->| 1133 | | 1134 | (4) Answer (SRTP) | 1135 |<---------------------------------| 1136 | | 1138 Alice's offer includes RTP and SRTP as alternatives. RTP is the 1139 default, but SRTP is the preferred one: 1141 v=0 1142 o=- 25678 753849 IN IP4 128.96.41.1 1143 s= 1144 c=IN IP4 128.96.41.1 1145 t=0 0 1146 m=audio 3456 RTP/AVP 0 18 1147 a=creq: v0 1148 a=tcap:1 RTP/SAVP RTP/AVP 1149 a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1150 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1151 FEC_ORDER=FEC_SRTP 1152 a=pcfg:1 t=1 a=1 1154 The "m=" line indicates that Alice is offering to use plain RTP with 1155 PCMU or G.729. Alice indicates that support for the base protocol 1156 defined here is required by including the "a=creq" attribute 1157 containing the value "v0". The capabilities are provided by the 1158 "a=tcap" and "a=acap" attributes. The "tcap" capability indicates 1159 that both Secure RTP and normal RTP are supported. The "acap" 1160 attribute provides a capability parameter with a handle of 1. The 1161 capability parameter is a "crypto" attribute, which provides the 1162 keying material for SRTP using SDP security descriptions [SDES]. The 1163 "a=pcfg" attribute provides the potential configurations included in 1164 the offer by reference to the capabilities. A single potential 1165 configuration with a configuration number of "1" is provided. It 1166 includes is transport protocol capability 1 (RTP/SAVP, i.e. secure 1167 RTP) together with the attribute capability 1, i.e. the crypto 1168 attribute provided. 1170 Bob receives the SDP offer from Alice. Bob supports SRTP and the SDP 1171 Capability Negotiation extensions, and hence he accepts the potential 1172 configuration for Secure RTP provided by Alice: 1174 v=0 1175 o=- 24351 621814 IN IP4 128.96.41.2 1176 s= 1177 c=IN IP4 128.96.41.2 1178 t=0 0 1179 m=audio 4567 RTP/SAVP 0 18 1180 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1181 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 1182 a=acfg:1 t=1 a=1 1184 Bob includes the "a=acfg" attribute in the answer to inform Alice 1185 that he based his answer on an offer containing the potential 1186 configuration with transport protocol capability 1 and attribute 1187 capability 1 from the offer SDP (i.e. the RTP/SAVP profile using the 1188 keying material provided). Bob also includes his keying material in 1189 a crypto attribute. 1191 When Alice receives Bob's answer, session negotiation has completed, 1192 however Alice nevertheless generates a new offer using the actual 1193 configuration. This is done purely to assist any middle-boxes that 1194 may reside between Alice and Bob but do not support the capability 1195 negotiation extensions (and hence may not understand the negotiation 1196 that just took place): 1198 Alice's updated offer includes only SRTP, and it is not using the SDP 1199 capability negotiation extensions (Alice could have included the 1200 capabilities as well is she wanted to): 1202 v=0 1203 o=- 25678 753850 IN IP4 128.96.41.1 1204 s= 1205 c=IN IP4 128.96.41.1 1206 t=0 0 1207 m=audio 3456 RTP/SAVP 0 18 1208 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1209 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1210 FEC_ORDER=FEC_SRTP 1212 The "m=" line now indicates that Alice is offering to use secure RTP 1213 with PCMU or G.729. The "crypto" attribute, which provides the SRTP 1214 keying material, is included with the same value again. 1216 Bob receives the SDP offer from Alice, which he accepts, and then 1217 generates an answer to Alice: 1219 v=0 1220 o=- 24351 621815 IN IP4 128.96.41.2 1221 s= 1222 c=IN IP4 128.96.41.2 1223 t=0 0 1224 m=audio 4567 RTP/SAVP 0 18 1225 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1226 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 1228 Bob includes the same crypto attribute as before, and the session 1229 proceeds without change. Although Bob did not include any 1230 capabilities in his answer, he could of course have done so if he 1231 wanted to. 1233 Note that in this particular example, the answerer supported the 1234 capability extensions defined here, however had he not, the answerer 1235 would simply have ignored the new attributes received in step 1 and 1236 accepted the offer to use normal RTP. In that case, the following 1237 answer would have been generated in step 2 instead: 1239 v=0 1240 o=- 24351 621814 IN IP4 128.96.41.2 1241 s= 1242 c=IN IP4 128.96.41.2 1243 t=0 0 1244 m=audio 4567 RTP/AVP 0 18 1246 4.2. Multiple Transport Protocols 1248 [EDITOR'S NOTE: Example to be updated - old copy below] 1250 The following example illustrates how to use the SDP Capability 1251 negotiation extensions to support so-called Best-Effort Secure RTP. 1252 In that scenario, the offerer supports both RTP and Secure RTP. If 1253 the answerer does not support secure RTP (or the SDP capability 1254 negotiation extensions), an RTP session will be established. However, 1255 if the answerer supports Secure RTP and the SDP Capability 1256 Negotiation extensions, a Secure RTP session will be established. 1258 The best-effort Secure RTP negotiation is illustrated by the 1259 offer/answer exchange below, where Alice sends an offer to Bob: 1261 Alice Bob 1263 | (1) Offer (SRTP and RTP) | 1264 |--------------------------------->| 1265 | | 1266 | (2) Answer (SRTP) |@@ 1267 |<---------------------------------| 1268 | | 1269 | (3) Offer (SRTP) | 1270 |--------------------------------->| 1271 | | 1272 | (4) Answer (SRTP) | 1273 |<---------------------------------| 1274 Alice's offer includes RTP and SRTP as alternatives. RTP is the 1275 default, but SRTP is the preferred one: 1277 v=0 1278 o=- 25678 753849 IN IP4 128.96.41.1 1279 s= 1280 c=IN IP4 128.96.41.1 1281 t=0 0 1282 m=audio 3456 RTP/AVP 0 18 1283 a=creq: v0 1284 a=tcap:1 RTP/SAVP RTP/AVP 1285 a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1286 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1287 FEC_ORDER=FEC_SRTP 1288 a=pcfg:5 t=1 a=1 1289 a=pcfg:10 t=2 1291 The "m=" line indicates that Alice is offering to use plain RTP with 1292 PCMU or G.729. Alice indicates that support for the base protocol 1293 defined here is required by including the "a=creq" attribute 1294 containing the value "v0". The capabilities are provided by the 1295 "a=tcap" and "a=acap" attributes. The capabilities indicate that 1296 both Secure RTP and normal RTP are supported. The "acap" attribute 1297 provides a capability parameter with a handle of 1. The capability 1298 parameter is a "crypto" attribute in the capability set, which 1299 provides the keying material for SRTP using SDP security descriptions 1300 [SDES]. The "a=pcfg" attribute provides the potential configurations 1301 included in the offer by reference to the capabilities. Two 1302 alternatives are provided; the first one with preference "5" (and 1303 hence the preferred one since the preference on the second one is 1304 "10") is transport protocol capability 1 (RTP/SAVP, i.e. secure RTP) 1305 together with the attribute capability 1, i.e. the crypto attribute 1306 provided. The second one is using transport protocol capability 2. 1307 Note that we could have omitted the second potential configuration 1308 since it equals the actual configuration (which is always the least 1309 preferred configuration). 1311 Bob receives the SDP offer from Alice. Bob supports SRTP and the SDP 1312 Capability Negotiation extensions, and hence he accepts the potential 1313 configuration for Secure RTP provided by Alice: 1315 v=0 1316 o=- 24351 621814 IN IP4 128.96.41.2 1317 s= 1318 c=IN IP4 128.96.41.2 1319 t=0 0 1320 m=audio 4567 RTP/SAVP 0 18 1321 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1322 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 1323 a=csup: foo 1324 a=acfg:1 t=1 a=1 1326 Bob includes the "a=acfg" attribute in the answer to inform Alice 1327 that he based his answer on an offer containing the potential 1328 configuration with transport protocol capability 1 and attribute 1329 capability 1 from the offer SDP (i.e. the RTP/SAVP profile using the 1330 keying material provided). Bob also includes his keying material in 1331 a crypto attribute. Finally, Bob supports an SDP capability 1332 negotiation extension with the option tag "foo" and hence he includes 1333 the "a=csup" parameter containing value "foo" in the answer. 1335 Note that in this particular example, the answerer supported the 1336 capability extensions defined here, however had he not, the answerer 1337 would simply have ignored the new attributes and accepted the offer 1338 to use normal RTP. In that case, the following answer would have been 1339 generated instead: 1341 v=0 1342 o=- 24351 621814 IN IP4 128.96.41.2 1343 s= 1344 c=IN IP4 128.96.41.2 1345 t=0 0 1346 m=audio 4567 RTP/AVP 0 18 1348 4.3. Session-Level MIKEY and Media Level Security Descriptions 1350 [EDITOR'S NOTE: Example to be added] 1352 4.4. Capability Negotiation with Interactive Connectivity Establishment 1354 [EDITOR'S NOTE: Example to be added] 1356 5. Security Considerations 1358 TBD. 1360 6. IANA Considerations 1362 TBD. 1364 [EDITOR'S NOTE: Need to define registry and procedures for option 1365 tags] 1367 [EIDTOR'S NOTE: Need to define registry and procedures for extension 1368 capabilities] 1370 7. To Do and Open Issues 1372 o Look for "EDITOR'S NOTE" throughout the document. 1374 8. Acknowledgments 1376 This document is heavily influenced by the discussions and work done 1377 by the SDP Capability Negotiation Design team. The following people 1378 in particular provided useful comments and suggestions to either the 1379 document itself or the overall direction of the solution defined in 1380 here: Roni Even, Robert Gilman, Cullen Jennings, Matt Lepinski, Joerg 1381 Ott, Colin Perkins, and Thomas Stach. 1383 Francois Audet and Dan Wing provided useful comments on earlier 1384 versions of this document. 1386 9. Change Log 1388 9.1. draft-ietf-mmusic-sdp-capability-negotiation-02 1390 The following are the major changes compared to version -01: 1392 o Potential configurations are no longer allowed at the session 1393 level 1395 o Renamed capability attributes ("capar" to "acap" and "ctrpr" to 1396 "tcap") 1398 o Changed name and semantics of the initial number (now called 1399 configuration number) in potential configuration attributes; must 1400 now be unique and can be used as a handle 1402 o Actual configuration attribute now includes configuration number 1403 from the selected potential configuration attribute 1405 o Added ABNF throughout 1407 o Specified that answerer should include "a=csup" in case of 1408 unsupported required extensions in offer. 1410 o Specified use of second offer/answer exchange when answerer 1411 selected a potential configuration 1413 o Updated rules (and added restrictions) for referencing media- and 1414 session-level capabilities in potential configurations (at the 1415 media level) 1417 o Added initial section on ICE interactions 1419 o Added initial section on receiving media before answer 1421 9.2. draft-ietf-mmusic-sdp-capability-negotiation-01 1423 The following are the major changes compared to version -00: 1425 o Media capabilities are no longer considered a core capability and 1426 hence have been removed. This leaves transport protocols and 1427 attributes as the only capabilities defined by the core. 1429 o Version attribute has been removed and an option tag to indicate 1430 the actual version has been defined instead. 1432 o Clarified rules for session-level and media level attributes 1433 provided at either level as well how they can be used in potential 1434 configurations. 1436 o Potential configuration parameters no longer have implicit 1437 ordering; an explicit preference indicator is now included. 1439 o The parameter name for transport protocols in the potential and 1440 actual configuration attributes have been changed "p" to "t". 1442 o Clarified operator precedence within potential and actual 1443 configuration attributes. 1445 o Potential configurations at the session level now limited to 1446 indicate latent capability configurations. Consequently, an actual 1447 configuration attribute can no longer be provided at the session 1448 level. 1450 o Cleaned up capability and potential configuration terminology - 1451 they are now two clearly different things. 1453 9.3. draft-ietf-mmusic-sdp-capability-negotiation-00 1455 Version 00 is the initial version. The solution provided in this 1456 initial version is based on an earlier (individual submission) 1457 version of [SDPCapNeg]. The following are the major changes compared 1458 to that document: 1460 o Solution no longer based on RFC 3407, but defines a set of similar 1461 attributes (with some differences). 1463 o Various minor changes to the previously defined attributes. 1465 o Multiple transport capabilities can be included in a single "tcap" 1466 attribute 1468 o A version attribute is now included. 1470 o Extensions to the framework are formally supported. 1472 o Option tags and the ability to list supported and required 1473 extensions are supported. 1475 o A best-effort SRTP example use case has been added. 1477 o Some terminology change throughout to more clearly indicate what 1478 constitutes capabilities and what constitutes configurations. 1480 10. References 1482 10.1. Normative References 1484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1485 Requirement Levels", BCP 14, RFC 2119, March 1997. 1487 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 1488 Syntax Specifications: ABNF", RFC 2234, Internet Mail 1489 Consortium and Demon Internet Ltd., November 1997. 1491 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 1492 with Session Description Protocol (SDP)", RFC 3264, June 1493 2002. 1495 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 1496 Capability Declaration", RFC 3407, October 2002. 1498 [RFC3605] C. Huitema, "Real Time Control Protocol (RTCP) attribute in 1499 Session Description Protocol (SDP)", RFC 3605, October 1500 2003. 1502 [RFC4234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 1503 Specifications: ABNF", RFC 4234, October 2005. 1505 [SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1506 Description Protocol", RFC 4566, July 2006. 1508 10.2. Informative References 1510 [RFC2046] Freed, N., and N. Borensteain, "Multipurpose Internet Mail 1511 Extensions (MIME) Part Two: Media Types", RFC 2046, 1512 November 1996. 1514 [RFC2327] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1515 Description Protocol", RFC 2327, April 1998. 1517 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1518 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 1519 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1521 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 1522 Schulzrinne, "Grouping of Media Lines in the Session 1523 Description Protocol (SDP)", RFC 3388, December 2002. 1525 [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and 1526 Video Conferences with Minimal Control", RFC 3551, July 1527 2003. 1529 [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1530 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1531 RFC 3711, March 2004. 1533 [RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 1534 (S/MIME) Version 3.1 Message Specification", RFC 3851, July 1535 2004. 1537 [RFC4091] Camarillo, G., and J. Rosenberg, The Alternative Network 1538 Address Types (ANAT) Semantics for the Session Description 1539 Protocol (SDP) Grouping Framework, RFC 4091, June 2005. 1541 [AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1542 "Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF)", 1543 Work in Progress, August 2004. 1545 [I-D.jennings-sipping-multipart] Wing, D., and C. Jennings, "Session 1546 Initiation Protocol (SIP) Offer/Answer with Multipart 1547 Alternative", Work in Progress, March 2006. 1549 [SAVPF] Ott, J., and E Carrara, "Extended Secure RTP Profile for 1550 RTCP-based Feedback (RTP/SAVPF)", Work in Progress, 1551 December 2005. 1553 [SDES] Andreasen, F., Baugher, M., and D. Wing, "Session 1554 Description Protocol Security Descriptions for Media 1555 Streams", RFC 4568, July 2006. 1557 [SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session Description 1558 and Capability Negotiation", Work in Progress, February 1559 2005. 1561 [BESRTP] Kaplan, H., and F. Audet, "Session Description Protocol 1562 (SDP) Offer/Answer Negotiation for Best-Effort Secure Real- 1563 Time Transport Protocol, Work in progress, August 2006. 1565 [KMGMT] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1566 Carrara, "Key Management Extensions for Session Description 1567 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 1568 RFC 4567, July 2006. 1570 [SDPCapNegRqts] Andreasen, F. "SDP Capability Negotiation: 1571 Requirementes and Review of Existing Work", work in 1572 progress, December 2006. 1574 [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", work in 1575 progress, December 2006. 1577 [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 1578 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1579 August 2004. 1581 [ICE] J. Rosenberg, "Interactive Connectivity Establishment 1582 (ICE): A Methodology for Network Address Translator (NAT) 1583 Traversal for Offer/Answer Protocols", work in progress, 1584 January 2007. 1586 [ICETCP] J. Rosenberg, "TCP Candidates with Interactive Connectivity 1587 Establishment (ICE)", work in progress, October 2006. 1589 [RFC3312] G. Camarillo, W. Marshall, and J. Rosenberg, "Integration 1590 of Resource Management and Session Initiatio Protocol 1591 (SIP)", RFC 3312, October 2002. 1593 Author's Addresses 1595 Flemming Andreasen 1596 Cisco Systems 1597 Edison, NJ 1599 Email: fandreas@cisco.com 1601 Intellectual Property Statement 1603 The IETF takes no position regarding the validity or scope of any 1604 Intellectual Property Rights or other rights that might be claimed to 1605 pertain to the implementation or use of the technology described in 1606 this document or the extent to which any license under such rights 1607 might or might not be available; nor does it represent that it has 1608 made any independent effort to identify any such rights. Information 1609 on the procedures with respect to rights in RFC documents can be 1610 found in BCP 78 and BCP 79. 1612 Copies of IPR disclosures made to the IETF Secretariat and any 1613 assurances of licenses to be made available, or the result of an 1614 attempt made to obtain a general license or permission for the use of 1615 such proprietary rights by implementers or users of this 1616 specification can be obtained from the IETF on-line IPR repository at 1617 http://www.ietf.org/ipr. 1619 The IETF invites any interested party to bring to its attention any 1620 copyrights, patents or patent applications, or other proprietary 1621 rights that may cover technology that may be required to implement 1622 this standard. Please address the information to the IETF at 1623 ietf-ipr@ietf.org. 1625 Full Copyright Statement 1627 Copyright (C) The IETF Trust (2007). 1629 This document is subject to the rights, licenses and restrictions 1630 contained in BCP 78, and except as set forth therein, the authors 1631 retain all their rights. 1633 This document and the information contained herein are provided on an 1634 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1635 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1636 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1637 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1638 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1639 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1641 Acknowledgment 1643 Funding for the RFC Editor function is currently provided by the 1644 Internet Society.