idnits 2.17.1 draft-ietf-mmusic-sdp-capability-negotiation-00.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 on line 1337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1327. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 457 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 18 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 RFC 3978 Section 5.4 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 (January 2, 2007) is 6323 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: 'RFC4566' is mentioned on line 533, but not defined ** Obsolete undefined reference: RFC 4566 (Obsoleted by RFC 8866) == Missing Reference: 'Section 8' is mentioned on line 1039, but not defined == Unused Reference: 'RFC2234' is defined on line 1203, but no explicit reference was found in the text == Unused Reference: 'RFC3407' is defined on line 1211, but no explicit reference was found in the text == Unused Reference: 'RFC3605' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 1226, but no explicit reference was found in the text == Unused Reference: 'RFC2327' is defined on line 1230, but no explicit reference was found in the text == Unused Reference: 'RFC3388' is defined on line 1237, but no explicit reference was found in the text == Unused Reference: 'RFC3851' is defined on line 1249, but no explicit reference was found in the text == Unused Reference: 'RFC4091' is defined on line 1253, but no explicit reference was found in the text == Unused Reference: 'I-D.jennings-sipping-multipart' is defined on line 1261, but no explicit reference was found in the text == Unused Reference: 'BESRTP' is defined on line 1277, but no explicit reference was found in the text == Unused Reference: 'SDPCapNegRqts' is defined on line 1286, but no explicit reference was found in the text == Unused Reference: 'MIKEY' is defined on line 1293, 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: 8 errors (**), 0 flaws (~~), 18 warnings (==), 11 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 Expires: July 2007 January 2, 2007 6 SDP Capability Negotiation 7 draft-ietf-mmusic-sdp-capability-negotiation-00.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 July 2, 2007. 35 Abstract 37 The Session Description Protocol (SDP) was intended for describing 38 multimedia sessions for the purposes of session announcement, session 39 invitation, and other forms of multimedia session initiation. SDP was 40 not intended to provide capability indication or capability 41 negotiation, however over the years, SDP has seen widespread adoption 42 and as a result it has been gradually extended to provide limited 43 support for these. SDP and its current extensions however do not have 44 the ability to negotiate one or more alternative transport protocols 45 (e.g. RTP profiles) which makes it particularly difficult to deploy 46 new RTP profiles such as secure RTP or RTP with RTCP-based feedback. 48 The purpose of this document is to address that and other real-life 49 limitations by extending SDP with capability negotiation parameters 50 and associated offer/answer procedures to use those parameters in a 51 backwards compatible manner. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC2119]. 59 Table of Contents 61 1. Introduction...................................................3 62 2. SDP Capability Negotiation Solution............................5 63 2.1. Solution Overview.........................................5 64 2.2. Version and Extension Indication Attributes...............8 65 2.2.1. SDP Capability Negotiation Version Attribute.........8 66 2.2.2. Supported Capability Negotiation Extensions Attribute9 67 2.2.3. Required Capability Negotiation Extension Attribute.10 68 2.3. Capability Attributes....................................11 69 2.3.1. Media Type and Format Capability Attribute..........11 70 2.3.2. Attribute Parameter Capability Attribute............14 71 2.3.3. Transport Protocol Capability Attribute.............15 72 2.4. Configuration Attributes.................................16 73 2.4.1. Potential Configuration Attribute...................16 74 2.4.2. Actual Configuration Attribute......................19 75 2.5. Offer/Answer Model Extensions............................20 76 2.5.1. Generating the Initial Offer........................21 77 2.5.2. Generating the Answer...............................22 78 2.5.3. Offerer Processing of the Answer....................22 79 2.5.4. Modifying the Session...............................23 80 3. Examples......................................................23 81 3.1. Best-Effort Secure RTP...................................23 82 4. Security Considerations.......................................25 83 5. IANA Considerations...........................................25 84 6. To Do and Open Issues.........................................26 85 7. Acknowledgments...............................................26 86 8. Change Log....................................................26 87 8.1. draft-ietf-mmusic-sdp-capability-negotiation-00..........26 88 9. References....................................................27 89 9.1. Normative References.....................................27 90 9.2. Informative References...................................27 91 Author's Addresses...............................................29 92 Intellectual Property Statement..................................29 93 Disclaimer of Validity...........................................30 94 Copyright Statement..............................................30 95 Acknowledgment...................................................30 97 1. Introduction 99 The Session Description Protocol (SDP) was intended for describing 100 multimedia sessions for the purposes of session announcement, session 101 invitation, and other forms of multimedia session initiation. The SDP 102 contains one or more media stream descriptions with information such 103 as IP-address and port, type of media stream (e.g. audio or video), 104 transport protocol (possibly including profile information, e.g. 105 RTP/AVP or RTP/SAVP), media formats (e.g. codecs), and various other 106 session and media stream parameters that define the session. 108 Simply providing media stream descriptions is sufficient for session 109 announcements for a broadcast application, where the media stream 110 parameters are fixed for all participants. When a participant wants 111 to join the session, he obtains the session announcement and uses the 112 media descriptions provided, e.g., joins a multicast group and 113 receives media packets in the encoding format specified. If the 114 media stream description is not supported by the participant, he is 115 unable to receive the media. 117 Such restrictions are not generally acceptable to multimedia session 118 invitations, where two or more entities attempt to establish a media 119 session that uses a set of media stream parameters acceptable to all 120 participants. First of all, each entity must inform the other of its 121 receive address, and secondly, the entities need to agree on the 122 media stream parameters to use for the session, e.g. transport 123 protocols and codecs. We here make a distinction between the 124 capabilities supported by each participant and the parameters that 125 can actually be used for the session. More generally, we can say that 126 we have the following: 128 o A set of capabilities and potential configurations of the media 129 stream components, supported by each side. 131 o A set of actual configurations of the media stream components, 132 which specifies which media stream components to use and with what 133 parameters. 135 o A negotiation process that takes the set of potential 136 configurations (capabilities) as input and provides the actual 137 configurations as output. 139 SDP by itself was designed to provide only the second of these, i.e., 140 the actual configurations, however over the years, use of SDP has 141 been extended beyond its original scope. Session negotiation 142 semantics were defined by the offer/answer model in RFC 3264. It 143 defines how two entities, an offerer and an answerer, exchange 144 session descriptions to negotiate a session. The offerer can include 145 one or more media formats (codecs) per media stream, and the answerer 146 then selects one or more of those offered and returns them in an 147 answer. Both the offer and the answer contain actual configurations - 148 potential configurations are not supported. The answer however may 149 reduce the set of actual configurations from the offer. 151 Other relevant extensions have been defined. Simple capability 152 declarations, which define how to provide a simple and limited set of 153 capability descriptions in SDP was defined in RFC 3407. Grouping of 154 media lines, which defines how media lines in SDP can have other 155 semantics than the traditional "simultaneous media streams" 156 semantics, was defined in RFC 3388, etc. 158 Each of these extensions was designed to solve a specific limitation 159 of SDP. Since SDP had already been stretched beyond its original 160 intent, a more comprehensive capability declaration and negotiation 161 process was intentionally not defined. Instead, work on a "next 162 generation" of a protocol to provide session description and 163 capability negotiation was initiated [SDPng]. SDPng however has not 164 gained traction and has remained as work in progress for an extended 165 period of time. Existing real-time multimedia communication 166 protocols such as SIP, RTSP, Megaco, and MGCP continue to use SDP. 167 SDP and its current extensions however do not address an increasingly 168 important problem: the ability to negotiate one or more alternative 169 transport protocols (e.g., RTP profiles). This makes it difficult to 170 deploy new RTP profiles such as secure RTP (SRTP) [SRTP], RTP with 171 RTCP-Based Feedback [AVPF], etc. This particular problem is 172 exacerbated by the fact that RTP profiles are defined independently. 173 When a new profile is defined and N other profiles already exist, 174 there is a potential need for defining N additional profiles, since 175 profiles cannot be combined automatically. For example, in order to 176 support the plain and secure RTP version of RTP with and without 177 RTCP-based feedback, four separate profiles (and hence profile 178 definitions) are needed: RTP/AVP [RFC3551], RTP/SAVP [SRTP], RTP/AVPF 179 [AVPF], and RTP/SAVPF [SAVPF]. In addition to the pressing profile 180 negotiation problem, other important real-life constraints have been 181 found as well. 183 The purpose of this document is to define a mechanism that enables 184 SDP to provide limited support for indicating capabilities and their 185 associated potential configurations and negotiate the use of those 186 potential configurations as actual configurations. It is not the 187 intent to provide a full-fledged capability indication and 188 negotiation mechanism along the lines of SDPng or ITU-T H.245. 189 Instead, the focus is on addressing a set of well-known real-life 190 limitations. 192 As mentioned above, SDP is used by several protocols, and hence the 193 mechanism should be usable by all of these. One particularly 194 important protocol for this problem however is the Session Initiation 195 Protocol (SIP) [RFC3261]. SIP uses the offer/answer model (which is 196 not specific to SIP) to negotiate sessions and hence any mechanism 197 must at least consider how it either interacts with offer/answer, or 198 how it should extend it. 200 The rest of the document is structured as follows. In Section 0we 201 present our SDP capability negotiation solution followed by examples 202 in Section 3. and security considerations in Section 4. 204 2. SDP Capability Negotiation Solution 206 In this section we first provide an overview of the SDP Capability 207 negotiation solution. This is followed by definitions of new SDP 208 attributes for the solution and its associated updated offer/answer 209 procedures. 211 2.1. Solution Overview 213 The solution consists of the following: 215 o Three new attributes to support versioning and extensions to the 216 framework itself as follows: 218 o A new attribute ("a=cver") that lists the version of the SDP 219 capability negotiation framework being used. 221 o A new attribute ("a=csup") that lists the supported extensions 222 to the framework. 224 o A new attribute ("a=creq") that lists the extensions to the 225 framework that are required to be supported by the entity 226 receiving the SDP. 228 o Three new attributes used to express capabilities as follows 229 (additional attributes can be defined as extensions): 231 o A new attribute ("a=cmed") that defines how to list the media 232 types and media formats supported as capabilities. 234 o A new attribute ("a=capar") that defines how to list the 235 attribute parameter values as capabilities. 237 o A new attribute ("a=ctrpr") that defines how to list transport 238 protocols as capabilities. 240 o Two new attributes to negotiate configurations as follows: 242 o A new attribute ("a=pcfg") that lists the potential 243 configurations supported. This is done by reference to the 244 above capabilities from the SDP in question. The potential 245 configurations are listed in order of preference. Extensions 246 can be defined as well and included in the potential 247 configurations. 249 o A new attribute ("a=acfg") to be used in an answer SDP. The 250 attribute identifies which of the potential configurations 251 from an offer SDP were used as actual configurations to form 252 the answer SDP. 254 o Extensions to the offer/answer model that allow for capabilities 255 and potential configurations to be included in an offer, where 256 they constitute offers that may be accepted by the answerer 257 instead of the actual configuration(s) included in the "m=" 258 line(s). The answerer indicates which (if any) of the potential 259 configurations it used to form the answer by including the actual 260 configuration attribute ("a=cfg") in the answer. Capabilities and 261 potential configurations may be included in answers as well, where 262 they can aid in guiding a subsequent new offer. 264 The mechanism is illustrated by the offer/answer exchange below, 265 where Alice sends an offer to Bob: 267 Alice Bob 269 | (1) Offer (SRTP and RTP) | 270 |--------------------------------->| 271 | | 272 | (2) Answer (RTP) | 273 |<---------------------------------| 274 | | 276 Alice's offer includes RTP and SRTP as alternatives. RTP is the 277 default, but SRTP is the preferred one: 279 v=0 280 o=- 25678 753849 IN IP4 128.96.41.1 281 s= 282 c=IN IP4 128.96.41.1 283 t=0 0 284 m=audio 3456 RTP/AVP 0 18 285 a=cver:0 286 a=cmed:1 audio RTP/AVP 0 18 96 287 a=ctrpr:1 RTP/SAVP 288 a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 289 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 290 a=capar:2 a=rtpmap:96 iLBC/8000 291 a=pcfg: m=1,2|3 p=1 a=1,2 292 a=pcfg: m=1,2|3 a=2 294 The "m=" line indicates that Alice is offering to use plain RTP with 295 PCMU or G.729. The capabilities are provided by the "a=cver", 296 "a=cmed", "a=ctrpr" and "a=capar" attributes. The capabilities 297 indicate that PCMU, G.729 and iLBC are supported with either RTP or 298 secure RTP. The first "capar" attribute provides a capability 299 parameter with a handle of 1. The capability parameter is a "crypto" 300 attribute in the capability set, which provides the keying material 301 for SRTP using SDP security descriptions [SDES]. The second "capar" 302 attribute provides the "rtpmap" for the dynamic payload type 96, 303 which is mapped to the iLBC codec. The "a=pcfg" attribute provides 304 the potential configurations included in the offer by reference to 305 the capability declarations. Two alternatives are provided; the 306 first one, and hence the preferred one is using media capabilities 1 307 and 2, i.e. PCMU and G.729, or media capability 3, i.e. iLBC. 308 Furthermore, transport protocol capability 1 (i.e. the RTP/SAVP 309 profile - secure RTP), and the attribute capability parameter 1, i.e. 310 the crypto attribute provided, and the attribute capability parameter 311 2, i.e. the rtpmap for iLBC is included. The second one is simply 312 using media capabilities 1 and 2, i.e. PCMU and G.729, or media 313 capability 3, i.e. iLBC under the RTP/AVP profile as listed in the 314 "m=" line. The "capar" parameter is still needed to provide the 315 rtpmap for iLBC. 317 Bob receives the SDP offer from Alice. Bob supports RTP, but not 318 SRTP, and hence he accepts the potential configuration for RTP 319 provided by Alice. Furthermore, Bob wants to use the iLBC codec and 320 hence generates the following answer: 322 v=0 323 o=- 24351 621814 IN IP4 128.96.41.2 324 s= 325 c=IN IP4 128.96.41.2 326 t=0 0 327 m=audio 4567 RTP/AVP 96 328 a=rtpmap:96 iLBC/8000 329 a=cver: 0 330 a=acfg: m=3 a=2 332 Bob includes the "a=cver" and "a=acfg" attribute in the answer to 333 inform Alice that he based his answer on an offer containing the 334 potential configuration with media capability 3 from the offer SDP 335 (i.e. iLBC under the RTP/AVP profile) and the attribute capability 336 parameter 2, i.e. the associated rtpmap. Note that in this 337 particular example, the answerer supported the capability extensions 338 defined here, however had he not, he would simply have processed the 339 offer based on the offered PCMU and G.729 codecs under the RTP/AVP 340 profile only. Consequently, the answer would have omitted the 341 "a=cver" and "a=acfg" attribute line and chosen one or both of the 342 PCMU and G.729 codecs instead. 344 2.2. Version and Extension Indication Attributes 346 In this section, we present the new attributes associated with 347 indicating the SDP capability negotiation version and extensions 348 supported and required. 350 2.2.1. SDP Capability Negotiation Version Attribute 352 The SDP Capability Negotiation Version attribute ("a=cver") lists the 353 version of the SDP Capability Negotiation supported by the entity 354 that generated the SDP. The attribute is defined as follows: 356 a=cver: 358 where is a non-zero positive integer. White space is 359 permitted, but not required, before . The value of 360 defined by this document is 0 as illustrated by the following 361 example: 363 a=cver: 0 365 The SDP Capability Negotiation version attribute MUST be present in 366 each SDP that uses the SDP Capability negotiation solution defined in 367 this document. The attribute can be provided at either the session- 368 or media-level, however there MUST NOT be more than one occurrence of 369 it. Furthermore, the attribute SHOULD be the first of the SDP 370 capability negotiation attributes provided. 372 2.2.2. Supported Capability Negotiation Extensions Attribute 374 The SDP Capability negotiation solution allows for capability 375 negotiation extensions to be defined. Associated with each such 376 extension is an option tag that identifies the extension in question. 377 Option-tags MUST be registered with IANA per the procedures defined 378 in Section 5. 380 The Supported Capability Negotiation Extensions attribute ("a=csup") 381 contains a comma-separated list of option tags identifying the SDP 382 Capability negotiation extensions supported by the entity that that 383 generated the SDP. The attribute is defined as follows: 385 a=csup: 387 where is defined by the following ABNF: 389 option-tag-list = option-tag *(COMMA option-tag) 390 option-tag = token ; defined in [SDP] 391 COMMA = *WSP "," *WSP ; defined in [RFC4234] 393 White-space is permitted before the . 395 Implementers familiar with SIP should note that the above 396 definition of COMMA differs from the one in [RFC3261]. 398 [EDITOR'S NOTE: There's nothing specific to the SDP Capability 399 Negotiation Solution for this parameter. Should consider 400 generalizing and/or providing in a separate document.] 402 The following examples illustrates the use of the "a=csup" attribute 403 with two hypothetical option tags, "foo" and "bar": 405 a=csup: foo 406 a=csup: bar 407 a=csup: foo, bar 409 The "a=csup" attribute can be provided at the session and the media- 410 level. When provided at the session-level, it applies to the entire 411 SDP. When provided at the media-level, it applies to the media-stream 412 in question only. There can be one or more "a=csup" attributes at 413 both the session and media-level (one or more per media stream in the 414 latter case). 416 Whenever an entity that supports one or more extensions to the SDP 417 Capability Negotiation framework generates an SDP, it SHOULD include 418 the "a=csup" attribute with the option tags for the extensions it 419 supports. 421 2.2.3. Required Capability Negotiation Extension Attribute 423 The SDP Capability negotiation solution allows for capability 424 negotiation extensions to be defined. Associated with each such 425 extension is an option tag that identifies the extension in question. 426 Option-tags MUST be registered with IANA per the procedures defined 427 in Section 5. 429 The Required Capability Negotiation Extensions attribute ("a=csup") 430 contains a comma-separated list of option tags identifying the SDP 431 Capability negotiation extensions that MUST be supported by the 432 entity receiving the SDP in order for that entity to properly process 433 the SDP Capability negotiation. The attribute is defined as follows: 435 a=creq: 437 where is defined in Section 2.2.2. 439 White-space is permitted before the . 441 [EDITOR'S NOTE: There's nothing specific to the SDP Capability 442 Negotiation Solution for this parameter. Should consider 443 generalizing and/or providing in a separate document.] 445 The following examples illustrates the use of the "a=creq" attribute 446 with two hypothetical option tags, "foo" and "bar": 448 a=creq: foo 449 a=creq: bar 450 a=creq: foo, bar 452 The "a=creq" attribute can be provided at the session and the media- 453 level. When provided at the session-level, it applies to the entire 454 SDP. When provided at the media-level, it applies to the media-stream 455 in question only. There can be one or more "a=creq" attributes at 456 both the session and media-level (one or more per media stream in the 457 latter case). 459 Whenever an entity generates an SDP and it requires the recipient of 460 that SDP to support one or more SDP capability negotiation extensions 461 in order to properly process the SDP Capability negotiation, the 462 "a=creq" attribute MUST be included with option-tags that identify 463 the required extensions. 465 A recipient that receives such an SDP and does not support one or 466 more of the required extensions, MUST NOT perform the SDP capability 467 negotiation defined in this document. For non-supported extensions 468 provided at the session-level, this implies that SDP capability 469 negotiation MUST NOT be performed at all. For non-supported 470 extensions at the media-level, this implies that SDP capability 471 negotiation MSUT NOT be performed for the media stream in question. 473 When an entity does not support one or more required SDP capability 474 negotiation extensions, the entity SHOULD proceed as if the SDP 475 capability negotiation attributes were not included in the first 476 place. 478 This ensures that introduction of the SDP capability negotiation 479 mechanism does not introduce any new failure scenarios. 481 2.3. Capability Attributes 483 In this section, we present the new attributes associated with 484 indicating the capabilities for use by the SDP Capability 485 negotiation. 487 2.3.1. Media Type and Format Capability Attribute 489 Media types and media formats can be expressed as capabilities by use 490 of the "a=cmed" attribute, which is defined as follows: 492 a=cmed: [ ] 494 where is an integer between 1 and 2^32-1 (both 495 included) used to number the media capabilities, and , 496 , and are defined as in the SDP "m=" line. The may contain multiple media formats. In that case, the media 498 format capability number associated with the first one provided is 499 the value of , the number associated with the second one 500 is one higher, etc. Each occurrence of the attribute MUST use a 501 different value of . Furthermore, when a "cmed" 502 attribute indicates more than one media format, the capability 503 numbers implied MUST NOT be used by any other "cmed" attribute in the 504 session description (explicitly or implicitly). When and 505 are omitted, the media capability merely indicates support 506 for the type in question, without any details as to what kind 507 of transport protocol and media formats are supported. This can for 508 example be used to indicate support for additional types of media 509 than those included as actual configurations in an offer or answer. 511 A media capability merely indicates possible support for the media 512 type and media format(s) in question. In order to actually use a 513 media capability in an offer/answer exchange, it must be referenced 514 in a potential configuration (see Section 2.4.1. 516 Media capabilities can be provided at the session-level and the 517 media-level. Media capabilities provided at the session level apply 518 to the session description in general, whereas media capabilities 519 provided at the media level apply to that media stream only. In 520 either case, the scope of the is the entire session 521 description. This enables each media capability to be referenced 522 across the entire session description (e.g. in a potential 523 configuration - see Section 2.4.1. 525 [EDITOR'S NOTE: This is clear as mud. If a media capability applies 526 to a media-stream only, then why can it still be referenced and 527 hence used as capabilities in other media streams (by the "a=pcfg") 528 attribute. The motivation is message size efficiency, but the means 529 are not clean. Session versus media-level syntax and semantics need 530 further consideration] 532 The parameter indicates the default transport protocol 533 associated with the media capability. As described in [RFC4566], the 534 value of the parameter guides the interpretation of the , which is why it is included here. Note that is also a 536 capability that can be negotiated separately (see Section 2.3.3. 538 The contains one or more media formats supported, the 539 interpretation of which depends on the value of . The rules 540 that apply to "m=" lines (as defined in [SDP]) for interpretation of 541 these apply here as well. For RTP-based transports, this implies 542 that the contains one or more RTP payload type numbers. 543 When those payload type numbers are dynamic, SDP requires an 544 "a=rtpmap" attribute to determine the actual codec. In the case of 545 SDP capability negotiation, such additional attribute parameters MUST 546 be provided in conjunction with the media capability. There are two 547 different cases to consider for this: 549 o The media capability is provided at the session level: In this 550 case, the required parameters MUST be provided in one or more 551 attribute parameter capabilities (see Section 2.3.2. listed 552 before the first "m=" line as well as before any other media 553 capability attributes ("a=cmed"). 555 o The media capability is provided at the media stream level: In 556 this case, when the payload type numbers are part of the "m=" line 557 itself, this is done by use of the "a=rtpmap" attribute as usual. 558 In all other cases, the required parameters MUST be provided in 559 one or more attribute parameter capabilities (see Section 2.3.2. 560 within the media stream description (i.e. before the next "m=" 561 line). 563 [EDITOR'S NOTE: The above assumes that intermediaries will not 564 reorder session-level attributes. It would be safer to explicitly 565 link the two, but that will require yet another attribute. Also, it 566 sends us down the path of building more complicated capabilities 567 (made up of multiple parameters). Another issue here is that 568 payload type numbers, which really have only media-level scope, are 569 ill-suited to be used at the session-level or across multiple media 570 streams (as is being done here). However, an alternative (and more 571 proper) solution seems to involve significantly more work and 572 deviations from the current SDP framework. This in turn makes it 573 more difficult to automatically use new media types, formats, 574 protocols, etc. defined elsewhere within this framework, and that 575 is a major disadvantage. Another option is to forgo the session- 576 level media capabilities as well as the ability to reference across 577 media streams - it will make the solution less efficient though and 578 difficult to express latent capabilities for media streams not 579 included in the offer or answer.] 581 The following example illustrates the first case above: 583 v=0 584 o=- 25678 753849 IN IP4 128.96.41.1 585 s= 586 c=IN IP4 128.96.41.1 587 t=0 0 588 a=cmed: 1 audio RTP/AVP 96 589 a=capar: 1 a=rtpmap:96 G729/8000 590 m=audio... 592 The following example illustrates the second case above: 594 v=0 595 o=- 25678 753849 IN IP4 128.96.41.1 596 s= 597 c=IN IP4 128.96.41.1 598 t=0 0 599 m=audio 2345 RTP/AVP 96 600 a=rtpmap:96 G729/8000 601 a=cver:0 602 a=cmed: 1 audio RTP/AVP 96 97 603 a=capar: 1 a=rtpmap:97 iLBC/8000 605 Note: Readers familiar with RFC 3407 may notice the similarity 606 between the "cmed" attribute defined above and the "cdsc" attribute 607 defined in RFC 3407. There are however a couple of important 608 differences, namely an increase in the capability numbering space 609 as well as a relaxation of certain requirements found in RFC 3407. 610 To simplify overall operation, the "cmed" parameter is limited to 611 media-level operation only as well. 613 2.3.2. Attribute Parameter Capability Attribute 615 Attributes can be expressed as negotiable parameters by use of a new 616 attribute parameter capability attribute ("a=capar"), which is 617 defined as follows: 619 a=capar: 621 where is an integer between 1 and 2^32-1 (both 622 included) used to number the attribute parameter capability and is an attribute ("a=") in its full '=' form (see 624 [SDP]). 626 The "capar" attribute can be provided at the session level and the 627 media level. Each occurrence of the attribute MUST use a different 628 value of . The values provided are 629 independent of similar values provided for other 630 attributes, i.e., they form a separate name-space for attribute 631 parameter capabilities. 633 Attribute parameter capabilities are generally used for two things. 634 First of all, they may be necessary to interpret a media format 635 capability (e.g. by including an rtpmap), or they may provide 636 attribute value parameters that are referenced in potential 637 configurations (see Section 2.4.1. ) 639 The following examples illustrate use of the "capar" attribute: 641 a=capar: 1 a=ptime:20 643 a=capar: 2 a=ptime:30 645 a=capar: 3 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAA 646 AAAGEEoo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0 647 JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUO 648 SrzKTAv9zV 649 a=capar: 4 a=crypto:1 AES_CM_128_HMAC_SHA1_32 650 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 652 The first two provide attribute values for the ptime attribute. The 653 third one provides SRTP parameters by using MIKEY with the key-mgmt 654 attribute [KMGMT]. The fourth one provides SRTP parameters by use of 655 security descriptions with the crypto attribute [SDES]. 657 Readers familiar with RFC 3407 may notice the similarity between 658 the RFC 3407 "cpar" attribute and the above. There are however a 659 couple of important differences, most notably that the "capar" 660 attribute contains a handle that enables referencing it and it 661 furthermore supports attributes only (the "cpar" attribute defined 662 in RFC 3407 supports bandwidth information as well). The "capar" 663 attribute also is not automatically associated with any particular 664 capabilities. 666 2.3.3. Transport Protocol Capability Attribute 668 Transport Protocols can be expressed as capabilities by use of a new 669 Transport Protocol Capability attribute ("a=ctrpr") defined as 670 follows: 672 a=ctrpr: 674 where is an integer between 1 and 255 (both included) 675 used to number the transport address capability for later reference, 676 and is one or more , separated by white space, as 677 defined in the SDP "m=" line. 679 The "ctrpr" attribute can be provided at the session- and media- 680 level. Each occurrence of the attribute MUST use a different value of 681 . When multiple values are provided, the first 682 one is associated with the value , the second one with 683 the value one higher, etc. The values provided are 684 independent of similar values provided for other 685 attributes, i.e., they form a separate name-space for transport 686 protocol capabilities. 688 Below, we provide examples of the "a=ctrpr" attribute: 690 a=ctrpr: 1 RTP/AVP 691 a=ctrpr: 2 RTP/AVPF 692 a=ctrpr: 3 RTP/SAVP RTP/SAVPF 694 The first one provides a capability for the "RTP/AVP" profile defined 695 in [RFC3551] and the second one provides a capability for the RTP 696 with RTCP-Based Feedback profile defined in [AVPF]. The third one 697 provides capabilities for the "RTP/SAVP" and "RTP/SAVPF" profiles. 699 Note that the "cmed" attribute provides a similar functionality by 700 including , however having this as a separate capability 701 indication can provide significant message size reduction when 702 negotiating alternative profiles (of which there can be many). In 703 particular, there is no need to repeat supported payload types. Also, 704 use of this attribute combined with the potential configuration 705 attribute (see Section 2.4. ) provides for more expressive power. 707 2.4. Configuration Attributes 709 2.4.1. Potential Configuration Attribute 711 Potential Configurations can be expressed by use of a new Potential 712 Configuration Attribute ("a=pcfg") defined as follows: 714 a=pcfg: 716 where is defined as 718 pot-cfg-list = pot-config *(1*WSP pot-config) 720 pot-config = pot-media-config | 721 pot-attribute-parameter-config | 722 pot-transport-protocol-config | 723 pot-extension-config 725 The potential configuration attribute includes one or more sets of 726 potential media configurations, attribute parameter configurations 727 and transport protocol configurations. Each of these MUST NOT be 728 present more than once in a particular potential configuration 729 attribute. Potential extension configurations can be included as 730 well. There can be more than one potential extension configuration, 731 however each particular potential extension configuration MUST NOT be 732 present more than once in a given potential configuration attribute. 734 Together, these values define a set of potential configurations. 735 There can be one or more potential configuration attributes provided 736 at the session-level as well as for each media stream. The attributes 737 are provided in order of preference. 739 [EDITOR'S NOTE: We run into another issue with session-level media 740 capabilities here. In the offer/answer model, potential 741 configurations at the media-level constitute alternative offers, 742 however at the session-level, that would/should not be the case for 743 media capabilities. Other parameters however may be used as 744 alternative offers at the session level (e.g. key-mgmt attributes 745 at the session level)] 747 pot-media-config is defined by the following ABNF: 749 pot-media-config = "m=" med-cap-list *(BAR med-cap-list) 750 med-cap-list = med-cap-num *(COMMA med-cap-num) 751 med-cap-num = 1*DIGIT ; defined in [RFC4234] 752 BAR = *WSP "|" *WSP ; defined in [RFC4234] 754 Each potential media configuration is a comma-separated list of media 755 capability numbers where med-cap-num refers to media capability 756 numbers and hence MUST be between 1 and 2^32-1 (both included). 757 Alternative potential media configurations are separated by a 758 vertical bar ("|"). The alternatives are ordered by preference. When 759 media capabilities are not included in a potential configuration at 760 the media level, the media type and media format from the associated 761 "m=" line will be used. 763 pot-attribute-parameter-config is defined by the following ABNF: 765 pot-attribute-parameter-config 766 = "a=" capar-cap-list *(BAR capar-cap-list) 767 capar-cap-list = att-cap-num *(COMMA att-cap-num) 768 att-cap-num = 1*DIGIT ;defined in [RFC4234] 770 Each potential attribute parameter configuration list is a comma- 771 separated list of attribute capability parameter numbers where att- 772 cap-num refers to attribute parameter capability numbers defined 773 above and hence MUST be between 1 and 2^32-1 (both included). 774 Alternative potential attribute parameter configurations are 775 separated by a vertical bar ("|"). The alternatives are ordered by 776 preference. 778 pot-transport-protocol-config is defined by the following ABNF: 780 pot-transport-protocol-config = 781 "p=" trpr-cap-num *(BAR trpr-cap-num) 782 trpr-cap-num = 1*DIGIT ; defined in [RFC4234] 784 The trpr-cap-num refers to transport protocol capability numbers 785 defined above and hence MUST be between 1 and 2^32-1 (both included). 786 Alternative potential transport protocol configurations are separated 787 by a vertical bar ("|"). The alternatives are ordered by preference. 789 When transport protocol capabilities are not included in a potential 790 configuration, the transport protocol information from an included 791 potential media configuration will be used. If a potential media 792 configuration is not included, the transport protocol from the media 793 description ("m=" line) will be used instead. 795 pot-extension-config is defined by the following ABNF: 797 pot-extension-config= ext-cap-name "=" 798 ext-cap-list *(BAR ext-cap-list) 799 ext-cap-name = token ; defined in [SDP] 800 ext-cap-list = ext-cap-num *(COMMA ext-cap-num) 801 ext-cap-num = 1*DIGIT ; defined in [RFC4234] 803 The ext-cap-name refers to the type of extension capability and the 804 ext-cap-num refers to a capability number associated with that 805 particular type of extension capability. The number MUST be between 806 1 and 2^32-1 (both included). Alternative potential extension 807 configurations for a particular extension are separated by a vertical 808 bar ("|"). Unsupported or unknown potential extension configs MUST 809 be ignored, unless an option tag showing the extension as being 810 required was included (see Section 2.2.3. 812 The potential configuration ("a=pcfg") attribute can be provided at 813 the session level and the media-level. Each occurrence of the 814 attribute within a given media description ("m=" line) defines a set 815 of potential configurations that can be used for that media 816 description. 818 TO DO: Need to decide on relationship between session-level and 819 media-level (how should conflicts, overlap, etc. be handled - 820 simplicity at the possible expense of expressive power is 821 preferable in the editor's opinion). 823 Below, we provide an example of the "a=pcfg" attribute in a complete 824 media description in order to properly indicate the supporting 825 attributes: 827 v=0 828 o=- 25678 753849 IN IP4 128.96.41.1 829 s= 830 c=IN IP4 128.96.41.1 831 t=0 0 832 m=audio 3456 RTP/SAVPF 0 18 833 a=crypto:1 AES_CM_128_HMAC_SHA1_32 834 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 835 a=cver: 0 836 a=cmed: 1 audio RTP/SAVP 0 4 18 837 a=ctrpr: 1 RTP/AVP RTP/AVPF 838 a=ctrpr: 3 RTP/SAVP RTP/SAVPF 839 a=pcfg: m=1|3 p=1|2|3|4 840 a=pcfg: m=2 p=1 842 We have two potential configurations listed here. The first one 843 indicates that PCMU (payload type number 0 referenced by media 844 capability number 1) or G.729 (payload type number 18 referenced by 845 media capability number 3) can be supported with either of the 846 profiles RTP/AVP, RTP/AVPF, RTP/SAVP, or RTP/SAVPF (specified by the 847 transport protocol capability numbers 1, 2, 3 and 4). The second 848 potential configuration indicates that G.723 (payload type number 4 849 referenced by media capability number 2) can be supported with the 850 RTP/AVP profile only (transport protocol capability number 1). 852 2.4.2. Actual Configuration Attribute 854 The actual configuration attribute identifies which of the potential 855 configurations from an offer SDP were used as actual configurations 856 in an answer SDP. This is done by reference to the media 857 capabilities, attribute parameter capabilities and transport protocol 858 capabilities from the offer that were actually used by the answerer 859 in his offer/answer procedure. If extension capabilities were used, 860 those will be included by reference as well. 862 The Actual Configuration Attribute ("a=acfg") is defined as follows: 864 a=acfg: 866 where is defined as 868 act-cfg-list = capability *(1*WSP capability) 870 capability = act-media-config | 871 act-attribute-parameter-config | 872 act-transport-protocol-config | 873 act-extension-config 875 act-media-config is defined by the following ABNF: 877 act-media-config = "m=" med-cap-list 879 where med-cap-list is as defined in Section 2.4.1. 881 act-attribute-parameter-config is defined by the following ABNF: 883 act-attribute-parameter-config = "a=" capar-cap-list 885 where capar-cap-list is as defined in Section 2.4.1. 887 act-transport-protocol-config is defined by the following ABNF: 889 act-transport-protocol-config = "p=" trpr-cap-num 891 where trpr-cap-num is as defined in Section 2.4.1. 893 trpr-cap-num = 1*3DIGIT ; defined in [RFC4234] 895 act-extension-config is defined by the following ABNF: 897 act-extension-config = ext-cap-name "=" ext-cap-list 899 where ext-cap-name and ext-cap-list are as defined in Section 2.4.1. 901 The actual configuration ("a=acfg") attribute can be provided at the 902 session-level and the media-level. There MUST NOT be more than one 903 occurrence of an actual configuration attribute at the session level, 904 and there MUST NOT be more than one occurrence of an actual 905 configuration attribute within a given media description. 907 Below, we provide an example of the "a=acfg" attribute (building on 908 the previous example with the potential configuration attribute): 910 v=0 911 o=- 24351 621814 IN IP4 128.96.41.2 912 s= 913 c=IN IP4 128.96.41.2 914 t=0 0 915 m=audio 4567 RTP/AVPF 0 916 a=cver: 0 917 a=acfg: m=1 p=2 919 It indicates that the answerer used an offer consisting of media 920 capability 1 from the offer (PCMU) and transport protocol capability 921 2 from the offer (RTP/AVPF). 923 2.5. Offer/Answer Model Extensions 925 In this section, we define extensions to the offer/answer model 926 defined in [RFC3264] to allow for potential configurations to be 927 included in an offer, where they constitute offers that may be 928 accepted by the answerer instead of the actual configuration(s) 929 included in the "m=" line(s). 931 [EDITOR'S NOTE: Multicast considerations have been omitted for 932 now.] 934 TO DO: Elaborate and firm up offer/answer procedures. 936 2.5.1. Generating the Initial Offer 938 An offerer that wants to use the SDP capability negotiation 939 extensions defined in this document MUST include the following in the 940 offer: 942 o an SDP capability negotiation version attribute with the version 943 set to 0 945 o one or more media capabilities (as defined in Section 2.3.1. ), if 946 alternative media types and media formats are to be indicated as 947 offerer capabilities or be negotiated. 949 o one or more attribute parameter capability attributes (as defined 950 in Section 2.3.2. ) if alternative attribute parameter values are 951 to be indicated as offerer capabilities or be negotiated. 953 o one or more transport protocol capability attributes (as defined 954 in Section 2.3.3. ) if alternative transport protocols are to be 955 to be indicated as offerer capabilities or be negotiated. 957 o one or more potential configuration attributes (as defined in 958 Section 2.4. ) if alternative potential configurations are to be 959 negotiated. 961 o one or more required capability negotiation extension attributes 962 (as defined in Section 2.2.3. ), if the answerer is required to 963 support one or more SDP capability negotiation extensions. 965 The offerer SHOULD furthermore include the following: 967 o one or more supported capability negotiation extension attributes 968 (as defined in Section 2.2.2. ), if the offerer supports one or 969 more SDP capability negotiation extensions. 971 The capabilities provided merely indicate what the offerer is capable 972 of doing. They do not constitute a commitment or even an indication 973 to actually use them. Conversely, each of the potential 974 configurations listed constitutes an alternative offer which may be 975 used to negotiate and establish the session. 977 [EDITOR'S NOTE: This is only partially true for potential 978 configurations listed at the session level. The only thing we want 979 to offer up as alternative offers at the session level is 980 attributes - not media types or media formats, which should be 981 capabilities only at the session level] 983 The current actual configuration is included in the "m=" line (as 984 defined by [RFC3264]). 986 2.5.2. Generating the Answer 988 When the answerer receives an offer with valid SDP capability 989 negotiation information in it and in particular with one or more 990 valid potential configuration information attributes present, it may 991 use any of the potential configurations as an alternative offer. A 992 potential configuration information attribute is valid if all of the 993 capabilities (media, attribute capabilities, transport protocol and 994 any extension capabilities) it references are present and valid 995 themselves. 997 The actual configuration is contained in the media description's "m=" 998 line. The answerer can send media to the offerer in accordance with 999 the actual configuration, however if it chooses to use one of the 1000 alternative potential configurations, media sent to the offerer may 1001 be discarded by the offerer until the answer is received. 1003 If the answerer chooses to accept one of the alternative potential 1004 configurations instead of the actual configuration, the answerer MUST 1005 generate an answer as if the offer contained that potential 1006 configuration instead of the actual configuration included. The 1007 answerer MUST also include an actual configuration attribute in the 1008 answer that identifies the potential configuration from the offer 1009 used by the answerer. The actual configuration attribute in the 1010 answer MUST include information about the media capabilities, 1011 attribute capability parameters, transport protocol parameters, and 1012 extension capabilities from the potential configuration that were 1013 used to generate the answer. 1015 2.5.3. Offerer Processing of the Answer 1017 When the offerer included potential configurations for a media 1018 stream, it MUST examine the answer for the presence of an actual 1019 configuration attribute for each such media stream. If the attribute 1020 is missing, offerer processing of the answer MUST proceed as defined 1021 by [RFC3264]. If the attribute is present, processing continues as 1022 follows: 1024 The actual configuration attribute specifies which of the potential 1025 configurations were used by the answerer to generate the answer. This 1026 includes all the types of capabilities from the potential 1027 configuration offered, i.e. the media formats ("cmed" capabilities), 1028 attribute capability parameters ("capar"), transport protocol 1029 capabilities ("ctrpr"), and any extension capability parameters 1030 included. 1032 The offerer MUST now process the answer as if the offer had contained 1033 the potential configuration as the actual configuration in the media 1034 description ("m=" line) and relevant attributes in the offer. 1036 2.5.4. Modifying the Session 1038 Potential configurations may be included in subsequent offers as 1039 defined in [RFC3264, Section 8]. The procedure for doing so is 1040 similar to that described above with the answer including an 1041 indication of the actual configuration used by the answerer. 1043 3. Examples 1045 In this section, we provide examples showing how to use the SDP 1046 Capability Negotiation. 1048 3.1. Best-Effort Secure RTP 1050 The following example illustrates how to use the SDP Capability 1051 negotiation extensions to support so-called Best-Effort Secure RTP. 1052 In that scenario, the offerer supports both RTP and Secure RTP. If 1053 the answerer does not support secure RTP (or the SDP capability 1054 negotiation extensions), an RTP session will be established. However, 1055 if the answerer supports Secure RTP and the SDP Capability 1056 Negotiation extensions, a Secure RTP session will be established. 1058 The best-effort Secure RTP negotiation is illustrated by the 1059 offer/answer exchange below, where Alice sends an offer to Bob: 1061 Alice Bob 1063 | (1) Offer (SRTP and RTP) | 1064 |--------------------------------->| 1065 | | 1066 | (2) Answer (RTP) | 1067 |<---------------------------------| 1068 | | 1070 Alice's offer includes RTP and SRTP as alternatives. RTP is the 1071 default, but SRTP is the preferred one: 1073 v=0 1074 o=- 25678 753849 IN IP4 128.96.41.1 1075 s= 1076 c=IN IP4 128.96.41.1 1077 t=0 0 1078 m=audio 3456 RTP/AVP 0 18 1079 a=cver:0 1080 a=ctrpr:1 RTP/SAVP RTP/AVP 1081 a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1082 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1083 FEC_ORDER=FEC_SRTP 1084 a=pcfg: p=1 a=1 1085 a=pcfg: p=2 1087 The "m=" line indicates that Alice is offering to use plain RTP with 1088 PCMU or G.729. The capability declaration is provided by the 1089 "a=cver", "a=ctrpr" and "a=capar" attributes. The capabilities 1090 indicate that both Secure RTP and normal RTP are supported. The 1091 "capar" attribute provides a capability parameter with a handle of 1. 1092 The capability parameter is a "crypto" attribute in the capability 1093 set, which provides the keying material for SRTP using SDP security 1094 descriptions [SDES]. The "a=pcfg" attribute provides the potential 1095 configurations included in the offer by reference to the 1096 capabilities. Two alternatives are provided; the first one, and 1097 hence the preferred one is transport protocol capability 1 (RTP/SAVP, 1098 i.e. secure RTP) together with the attribute capability parameter 1, 1099 i.e. the crypto attribute provided. The second one is using transport 1100 protocol capability 2. Since there are no media format capabilities 1101 included, the media format parameters from the media description 1102 itself is used. 1104 Bob receives the SDP offer from Alice. Bob supports SRTP and the SCP 1105 Capability Negotiation extensions, and hence he accepts the potential 1106 configuration for Secure RTP provided by Alice: 1108 v=0 1109 o=- 24351 621814 IN IP4 128.96.41.2 1110 s= 1111 c=IN IP4 128.96.41.2 1112 t=0 0 1113 m=audio 4567 RTP/SAVP 0 18 1114 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1115 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 1116 a=cver: 0 1117 a=acfg: p=1 a=1 1119 Bob includes the "a=cver" and "a=acfg" attribute in the answer to 1120 inform Alice that he based his answer on an offer containing the 1121 potential configuration with transport protocol capability 1 and 1122 attribute parameter capability 1 from the offer SDP (i.e. the 1123 RTP/SAVP profile using the keying material provided). Bob also 1124 includes his keying material in a crypto attribute. 1126 Note that in this particular example, the answerer supported the 1127 capability extensions defined here, however had he not, the answerer 1128 would simply have ignored the new attributes and accepted the offer 1129 to use normal RTP. In that case, the following answer would have been 1130 generated instead: 1132 v=0 1133 o=- 24351 621814 IN IP4 128.96.41.2 1134 s= 1135 c=IN IP4 128.96.41.2 1136 t=0 0 1137 m=audio 4567 RTP/AVP 0 18 1139 4. Security Considerations 1141 TBD. 1143 5. IANA Considerations 1145 TBD. 1147 [EDITOR'S NOTE: Need to define registry and procedures for option 1148 tags] 1150 [EIDTOR'S NOTE: Need to define registry and procedures for extension 1151 capabilities] 1153 6. To Do and Open Issues 1155 o Capability descriptions, potential configurations and actual 1156 configurations can be provided at both the session level and media 1157 level. It needs to be decided what the relationship between the 1158 session level and media level parameters are. 1160 o Look for "EDITOR'S NOTE" throughout the document. 1162 7. Acknowledgments 1164 Thanks to Francois Audet and Dan Wing for comments on earlier 1165 versions of this document. 1167 8. Change Log 1169 8.1. draft-ietf-mmusic-sdp-capability-negotiation-00 1171 Version 00 is the initial version. The solution provided in this 1172 initial version is based on an earlier (individual submission) 1173 version of [SDPCapNeg]. The following are the major changes compared 1174 to that document: 1176 o Solution no longer based on RFC 3407, but defines a set of similar 1177 attributes (with some differences). 1179 o Various minor changes to the previously defined attributes. 1181 o Multiple transport capabilities can be included in a single 1182 "ctrpr" attribute 1184 o A version attribute is now included. 1186 o Extensions to the framework are formally supported. 1188 o Option tags and the ability to list supported and required 1189 extensions are supported. 1191 o A best-effort SRTP example use case has been added. 1193 o Some terminology change throughout to more clearly indicate what 1194 constitutes capabilities and what constitutes configurations. 1196 9. References 1198 9.1. Normative References 1200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1201 Requirement Levels", BCP 14, RFC 2119, March 1997. 1203 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 1204 Syntax Specifications: ABNF", RFC 2234, Internet Mail 1205 Consortium and Demon Internet Ltd., November 1997. 1207 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 1208 with Session Description Protocol (SDP)", RFC 3264, June 1209 2002. 1211 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 1212 Capability Declaration", RFC 3407, October 2002. 1214 [RFC3605] C. Huitema, "Real Time Control Protocol (RTCP) attribute in 1215 Session Description Protocol (SDP)", RFC 3605, October 1216 2003. 1218 [RFC4234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 1219 Specifications: ABNF", RFC 4234, October 2005. 1221 [SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1222 Description Protocol", RFC 4566, July 2006. 1224 9.2. Informative References 1226 [RFC2046] Freed, N., and N. Borensteain, "Multipurpose Internet Mail 1227 Extensions (MIME) Part Two: Media Types", RFC 2046, 1228 November 1996. 1230 [RFC2327] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1231 Description Protocol", RFC 2327, April 1998. 1233 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1234 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 1235 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1237 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 1238 Schulzrinne, "Grouping of Media Lines in the Session 1239 Description Protocol (SDP)", RFC 3388, December 2002. 1241 [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and 1242 Video Conferences with Minimal Control", RFC 3551, July 1243 2003. 1245 [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1246 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1247 RFC 3711, March 2004. 1249 [RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 1250 (S/MIME) Version 3.1 Message Specification", RFC 3851, July 1251 2004. 1253 [RFC4091] Camarillo, G., and J. Rosenberg, The Alternative Network 1254 Address Types (ANAT) Semantics for the Session Description 1255 Protocol (SDP) Grouping Framework, RFC 4091, June 2005. 1257 [AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1258 "Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF)", 1259 Work in Progress, August 2004. 1261 [I-D.jennings-sipping-multipart] Wing, D., and C. Jennings, "Session 1262 Initiation Protocol (SIP) Offer/Answer with Multipart 1263 Alternative", Work in Progress, March 2006. 1265 [SAVPF] Ott, J., and E Carrara, "Extended Secure RTP Profile for 1266 RTCP-based Feedback (RTP/SAVPF)", Work in Progress, 1267 December 2005. 1269 [SDES] Andreasen, F., Baugher, M., and D. Wing, "Session 1270 Description Protocol Security Descriptions for Media 1271 Streams", RFC 4568, July 2006. 1273 [SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session Description 1274 and Capability Negotiation", Work in Progress, February 1275 2005. 1277 [BESRTP] Kaplan, H., and F. Audet, "Session Description Protocol 1278 (SDP) Offer/Answer Negotiation for Best-Effort Secure Real- 1279 Time Transport Protocol, Work in progress, August 2006. 1281 [KMGMT] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1282 Carrara, "Key Management Extensions for Session Description 1283 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 1284 RFC 4567, July 2006. 1286 [SDPCapNegRqts] Andreasen, F. "SDP Capability Negotiation: 1287 Requirementes and Review of Existing Work", work in 1288 progress, December 2006. 1290 [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", work in 1291 progress, December 2006. 1293 [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 1294 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1295 August 2004. 1297 Author's Addresses 1299 Flemming Andreasen 1300 Cisco Systems 1301 Edison, NJ 1303 Email: fandreas@cisco.com 1305 Intellectual Property Statement 1307 The IETF takes no position regarding the validity or scope of any 1308 Intellectual Property Rights or other rights that might be claimed to 1309 pertain to the implementation or use of the technology described in 1310 this document or the extent to which any license under such rights 1311 might or might not be available; nor does it represent that it has 1312 made any independent effort to identify any such rights. Information 1313 on the procedures with respect to rights in RFC documents can be 1314 found in BCP 78 and BCP 79. 1316 Copies of IPR disclosures made to the IETF Secretariat and any 1317 assurances of licenses to be made available, or the result of an 1318 attempt made to obtain a general license or permission for the use of 1319 such proprietary rights by implementers or users of this 1320 specification can be obtained from the IETF on-line IPR repository at 1321 http://www.ietf.org/ipr. 1323 The IETF invites any interested party to bring to its attention any 1324 copyrights, patents or patent applications, or other proprietary 1325 rights that may cover technology that may be required to implement 1326 this standard. Please address the information to the IETF at 1327 ietf-ipr@ietf.org. 1329 Disclaimer of Validity 1331 This document and the information contained herein are provided on an 1332 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1333 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1334 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1335 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1336 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1337 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1339 Copyright Statement 1341 Copyright (C) The Internet Society (2007). 1343 This document is subject to the rights, licenses and restrictions 1344 contained in BCP 78, and except as set forth therein, the authors 1345 retain all their rights. 1347 Acknowledgment 1349 Funding for the RFC Editor function is currently provided by the 1350 Internet Society.