idnits 2.17.1 draft-ietf-mmusic-sdp-misc-cap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1, 2010) is 5171 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: 'RFC4234' is mentioned on line 182, but not defined ** Obsolete undefined reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-09) exists of draft-boucadair-mmusic-altc-00 ** Downref: Normative reference to an Informational draft: draft-boucadair-mmusic-altc (ref. 'I-D.boucadair-mmusic-altc') == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-11 == Outdated reference: A later version (-23) exists of draft-ietf-mmusic-sdp-cs-03 == Outdated reference: A later version (-17) exists of draft-ietf-mmusic-sdp-media-capabilities-09 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC WG M. Garcia-Martin 3 Internet-Draft Ericsson 4 Intended status: Standards Track S. Veikkolainen 5 Expires: September 2, 2010 Nokia 6 R. Gilman 7 March 1, 2010 9 Miscellaneous Capabilities Negotiation in the Session Description 10 Protocol (SDP) 11 draft-ietf-mmusic-sdp-misc-cap-00 13 Abstract 15 SDP has been extended with a capability negotiation mechanism 16 framework that allows the endpoints to negotiate transport protocols 17 and attributes. This framework has been extended with a Media 18 capabilities negotiation mechanism that allows endpoints to negotiate 19 additional media-related capabilities. This negotiation is embedded 20 into the widely-used SDP offer/answer procedures. 22 This memo extends the SDP capability negotiation framework to allow 23 endpoints to negotiate a number of miscellaneous SDP capabilities. 24 In particular, this memo provides a mechanism to negotiate media 25 titles ("i=" line for each media), connection data ("c=" line), and 26 media bandwidth ("b=" line). 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on September 2, 2010. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 82 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5 83 3.1. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 5 84 3.1.1. Bandwidth Capability . . . . . . . . . . . . . . . . . 6 85 3.1.2. Connection Data Capability . . . . . . . . . . . . . . 8 86 3.1.3. Information Capability . . . . . . . . . . . . . . . . 10 87 3.2. Session Level versus Media Level . . . . . . . . . . . . . 13 88 4. Field Replacement Rules . . . . . . . . . . . . . . . . . . . 13 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 14 91 5.2. New Option Tags . . . . . . . . . . . . . . . . . . . . . 14 92 5.3. New SDP Capability Negotiation Configuration Parameters . 15 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 94 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 97 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 100 1. Introduction 102 The Session Description Protocol (SDP) [RFC4566] is intended for 103 describing multimedia sessions for the purposes of session 104 announcement, session invitation, and other forms of multimedia 105 session initiation. SDP has been extended with a capability 106 negotiation mechanism framework 107 [I-D.ietf-mmusic-sdp-capability-negotiation] that allows the 108 endpoints to negotiate capabilities, such as support for Realtime 109 Transport Protocol (RTP) [RFC3550] and Secure Realtime Transport 110 Protocol (SRTP) [RFC3711]. The SDP media capabilities 111 [I-D.ietf-mmusic-sdp-media-capabilities] provides negotiation 112 capabilities to media lines as well. 114 This negotiation is embedded into the widely used SDP offer/answer 115 procedures [RFC3264]. This memo provides the means to negotiate 116 further capabilities than those specified in the SDP capability 117 negotiation mechanism framework 118 [I-D.ietf-mmusic-sdp-capability-negotiation] and the SDP media 119 capabilities [I-D.ietf-mmusic-sdp-media-capabilities]. In 120 particular, this memo provides a mechanism to negotiate media titles 121 ("i="), connection data ("c="), and media bandwidth ("b="). It would 122 have been possible to define a mechanism to negotiate media 123 encryption keys ("k="). However, the usage of the media encryption 124 keys ("k=") is highly discouraged in favour of other existing more 125 sophisticated mechanisms. Therefore, we are not providing a 126 mechanism to provide capabilities for media encryption keys ("k=") at 127 this stage. 129 Since the three added capabilities are highly unconnected, it is not 130 expected that implementations will support all three at the same 131 time. Instead, it is expected that applications will choose their 132 needed capability for their specific purpose. Due to this, we are 133 writing the normative part pertaining to each capability in a self- 134 contained section. In particular, Section 3.1.1 describes the 135 bandwidth capability extension, Section 3.1.2 describes the 136 connection data capability extension, and Section 3.1.3 describes the 137 information capability extension. Separate option tags are defined 138 for each capability. 140 2. Conventions Used in This Document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in BCP 14, RFC 2119 145 [RFC2119] and indicate requirement levels for compliant 146 implementations. 148 3. Protocol Description 150 3.1. Extensions to SDP 152 The SDP Capability Negotiation Framework 153 [I-D.ietf-mmusic-sdp-capability-negotiation] and the SDP media 154 capabilities [I-D.ietf-mmusic-sdp-media-capabilities] specify 155 attributes for negotiating SDP capabilities. These documents specify 156 new attributes (e.g., 'acap', 'tcap', 'mcap') for achieving their 157 purpose. In this document we define a number of new additional 158 capability attributes for SDP lines of the the general form: 160 type=value 162 for types "i", "c", and "b". The corresponding capability attributes 163 are defined as "icap", "ccap", and "bcap", respectively. 165 From the sub-rules of "a=" line in SDP [RFC4566], SDP attributes are 166 of the form: 168 attribute = (att-field ":" att-value) / att-field 169 att-field = token 170 att-value = byte-string 172 Capability attributes use only the 'att-field:att-value' form. 174 The new attributes may be referenced in potential configurations 175 ("a=pcfg") or in latent configurations ("a=lcfg"), as productions 176 conforming to the extension-config-list as defined in 177 [I-D.ietf-mmusic-sdp-capability-negotiation]. 179 extension-config-list = ["+"] ext-cap-name "=" 180 ext-cap-list 181 ext-cap-name = 1*(ALPHA / DIGIT) 182 ext-cap-list = 1*VCHAR ; defined in [RFC4234] 184 The optional "+" is used to indicate that the entire configuration, 185 not just the parameter, must be ignored if the parameter is not 186 supported. The attributes may be referenced in actual configurations 187 as productions conforming to the sel-extension-config defined in 188 [I-D.ietf-mmusic-sdp-capability-negotiation]. 190 sel-extension-config = ext-cap-name "=" 1*VCHAR 192 The specific parameters are defined in the individual description of 193 each capability, below. 195 It is not the intention of this work to negotiate these new 196 capabilities at the session level, rather only at the media level. 197 Therefore, capabilities referenced by any configuration attribute 198 MUST appear at the media level when a configuration is "converted" to 199 a corresponding media block. For this reason, the "icap" attribute 200 is called the "media information capability". Specific values for 201 each new attribute are described below. 203 3.1.1. Bandwidth Capability 205 According to RFC 4566 [RFC4566] the bandwidth field denotes the 206 proposed bandwidth to be used by the session or media. For what it 207 concerns this memo, we focus on the bandwidth at the media level. 208 This bandwidth field is specified in RFC 4566 [RFC4566] according to 209 the following syntax: 211 b=: 213 where is an alphanumeric modifier giving the meaning of the 214 figure. 216 In this document, we define a new capability attribute: the bandwidth 217 capability attribute "bcap". This attribute lists bandwidth as 218 capabilities according to the following definition: 220 "a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF 222 where is a unique ordinal identifier of the bandwidth 223 capability, and the other elements are as defined for the "b=" field 224 in [RFC4566]. 226 This format satisfies the general attribute production rules in 227 [RFC4566] according to the following Augmented Backus-Naur Form 228 (ABNF) [RFC5234] syntax: 230 att-field = "bcap" 231 att-value = bw-cap-num 1*WSP bwtype ":" bandwidth 232 bw-cap-num = 1*DIGIT ; integer between 1 and 2^31-1, inclusive 234 Negotiation of bandwidth per media stream can be useful when 235 negotiating media encoding capabilities with different bandwidths. 237 3.1.1.1. Configuration Parameters 239 The SDP Capability Negotiation Framework 240 [I-D.ietf-mmusic-sdp-capability-negotiation] provides for the 241 existence of the "pcfg" and "acfg" attributes, which can carry one or 242 more potential configurations to be negotiated. The concept is 243 extended by the the Media Capabilities Negotiation 245 [I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute 246 that conveys latent configurations. Extensions to the "pcfg" and 247 "lcfg" attributes are defined through , and 248 extensions to the "acfg" attribute are defined through the as defined in 250 [I-D.ietf-mmusic-sdp-capability-negotiation]. 252 In this document we extend the field to be 253 able to convey lists of bandwidth capabilities in latent or potential 254 configurations, according to the following Augmented Backus-Naur Form 255 (ABNF) [RFC5234] syntax: 257 extension-config-list = bandwidth-config-list 259 bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR b-cap-list) 260 bw-cap-list = bw-cap-num *("," b-cap-num) 261 bw-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive 263 Figure 1: Syntax of the bandwidth parameter in lcfg and pcfg 264 attributes 266 Each bandwidth capability configuration is a comma-separated list of 267 bandwidth capability attribute numbers where 'b-cap-num' refers to 268 the bw-cap-num bandwidth capability numbers defined explicitly 269 earlier in this document, and hence must be between 1 and 2^31-1 270 (both included). Alternative bandwidth configurations are separated 271 by a vertical bar ("|"). 273 The bandwidth parameter to the actual configuration attribute 274 ("a=acfg") is formulated as a sel-extension-config with 276 ext-cap-name = "b" 278 hence 280 sel-extension-config = sel-bandwidth-config 281 sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above. 283 Figure 2: Syntax of the bandwidth parameter in acfg attributes 285 3.1.1.2. Option tag 287 The SDP Capability Negotiation Framework 288 [I-D.ietf-mmusic-sdp-capability-negotiation] solution allows for 289 capability negotiation extensions to be defined. Associated with 290 each such extension is an option tag that identifies the extension in 291 question. Hereby, we define a new option tag of "bcap-v0" that 292 identifies support for the bandwidth capability. This option tag 293 SHOULD be added to other existing option tags present in the "csup" 294 and "creq" attributes in SDP, according to the procedures defined in 295 the SDP Capability Negotiation Framework 296 [I-D.ietf-mmusic-sdp-capability-negotiation]. 298 3.1.2. Connection Data Capability 300 According to SDP [RFC4566], the connection data field in SDP contains 301 the connection data, and it has the following syntax: 303 c= 305 where indicates the network type, indicates the 306 address type, and the is the connection address, 307 which is dependent on the address type. For internet (IN) network 308 type transport addresses, the port number () which appears in 309 the media line is also required to complete the address. 311 The address types "IP4" and "IP6" indicate the type of IP addresses. 313 [I-D.ietf-mmusic-sdp-cs] defines a circuit-switched (CS) network type 314 intended primarily to identify an alternative media path in case IN 315 connectivity is overloadad or unavailable. This use requires the SDP 316 Capability Negotiation ([I-D.ietf-mmusic-sdp-capability-negotiation]) 317 framework, as illustrated below. 319 SDP [RFC4566] permits specification of connection data at the session 320 or at the media level. In order to permit negotiation of connection 321 data at the media level, we define the connection data capability 322 attribute ("a=ccap") in the form: 324 "a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP connection- 325 address SP port ["/" integer] CRLF 327 where is a unique ordinal identifier of the connection 328 data capability, and the other elements are as defined in [RFC4566]. 330 This format corresponds to the [RFC4566] attribute production rules 331 according to the following Augmented Backus-Naur Form (ABNF) 332 [RFC5234] syntax: 334 att-field = "ccap" 335 att-value = conn-cap-num 1*WSP nettype SP addrtype 336 SP connection-address SP port ["/" integer] 337 conn-cap-num = 1*DIGIT ; integer between 1 and 2^31-1, inclusive 339 The ccap attribute contains a port number, which is required for the 340 media line when converting a potential or latent configuration into a 341 conventional media description. The ccap attribute is a media-level- 342 only attribute. When a potential configuration references a ccap 343 attribute, and that configuration is converted to an equivalent media 344 description, the resulting configuration will contain a media-level 345 connection ("c=") line derived from the ccap information. 347 A potential or latent configuration may invoke no more than one ccap 348 attribute at a time (see below). 350 The connection information capability can be used to negotiate the 351 use of IPv4 or IPv6 addresses without resort to Interactive 352 Connectivity Establishment(ICE) [I-D.ietf-mmusic-ice]. Note, 353 however, that ICE provides for real-time reachability testing of 354 multiple addresses, whereas use of the connection capability forces 355 an early choice of connection address. 357 [I-D.boucadair-mmusic-altc] describes a simple method of specifying 358 alternative network addresses when the transport protocol () 359 is the same. 361 3.1.2.1. Configuration Parameters 363 The SDP Capability Negotiation Framework 364 [I-D.ietf-mmusic-sdp-capability-negotiation] provides for the 365 existence of the "pcfg" and "acfg" attributes, which can carry one or 366 more potential configurations to be negotiated. The concept is 367 extended by the the Media Capabilities Negotiation 368 [I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute 369 that conveys latent configurations. 371 In this document we define a parameter to be used 372 to specify a connection data capability in a potential or latent 373 configuration attribute. The parameter follows the form of an 374 extension-config-list, with 376 ext-cap-name = "c" 378 ext-cap-list = conn-cap-list 380 where, according to the following Augmented Backus-Naur Form (ABNF) 381 [RFC5234] syntax: 383 extension-config-list = conn-config-list 384 conn-config-list = "c=" conn-cap-list 385 conn-cap-list = conn-cap-num *(BAR conn-cap-num) 386 conn-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive 388 Figure 3: Syntax of the connection data parameter in lcfg and pcfg 389 attributes 391 Each capability configuration alternative contains a single 392 connection data capability attribute number and refers to the conn- 393 cap-num capability number defined explicitly earlier in this 394 document, and hence must be between 1 and 2^31-1 (both included). 395 The connection data capability allows the expression of only a single 396 capability in each alternative, rather than a list of capabilities, 397 since no more than a single connection data field is permitted per 398 media block. Nevertheless, it is still allowed to express 399 alternative potential connection configurations separated by a 400 vertical bar ("|"). 402 The connection data parameter to the actual configuration attribute 403 ("a=acfg") is formulated as a sel-extension-config with 405 ext-cap-name = "c" 407 hence 409 sel-extension-config = sel-connection-config 410 sel-connection-config = "c=" conn-cap-num ; as defined above. 412 Figure 4: Syntax of the connection data parameter in acfg attributes 414 3.1.2.2. Option tag 416 The SDP Capability Negotiation Framework 417 [I-D.ietf-mmusic-sdp-capability-negotiation] solution allows for 418 capability negotiation extensions to be defined. Associated with 419 each such extension is an option tag that identifies the extension in 420 question. Hereby, we define a new option tag of "ccap-v0" that 421 identifies support for the connection data capability. This option 422 tag SHOULD be added to other existing option tags present in the 423 "csup" and "creq" attributes in SDP, according to the procedures 424 defined in the SDP Capability Negotiation Framework 425 [I-D.ietf-mmusic-sdp-capability-negotiation]. 427 3.1.3. Information Capability 429 RFC 4566 [RFC4566] provides for the existence of an information field 430 expressed in the format of the "i=" line, which can appear either at 431 the session level or at the media level. An "i=" line that is 432 present at the session level is known as the "session name", and its 433 purpose is to convey a human-readable textual information about the 434 session. We don't see much usage of capabilities related to the "i=" 435 line at the session level. 437 The "i=" line in SDP can also appear at the media level, in which 438 case it is used to provide human-readable information about the media 439 stream to which it is related, e.g., it may indicate the purpose of 440 the media stream. The information field is not to be confused with 441 the label attribute ("a=label:...), [RFC4574]) which provides a 442 machine-readable tag. It is foreseen that applications declaring 443 capabilities related to different configurations of a media stream 444 may need to provide different identifying information for each of 445 those configurations. That is, a party might offer alternative media 446 configurations for a stream, each of which represents a different 447 presentation of the same or similar information. For example, an 448 audio stream might offer English or Spanish configurations, or a 449 video stream might offer a choice of video source such as speaker 450 camera, group camera, or document viewer. The information capability 451 is needed to inform the answering user in order to select the proper 452 choice, and the label is used to inform the offering machine which 453 choice the answerer has selected. Hence, there is value in defining 454 a mechanism to provide information of media streams as capabilities. 456 According to SDP [RFC4566], the media label has the following syntax: 458 "i="text 460 where "text" represents a human-readable text indicating the purpose 461 of the media stream. 463 In this document we define a new capability attribute: the 464 information media capability, "icap". This attribute lists 465 information media labels as capabilities, according to the following 466 definition: 468 "a=icap:" info-cap-num 1*WSP text 470 where is the ordinal identifier of the particular 471 media information capability and is a human-readable text that 472 indicates the purpose of the media stream it is supposed to 473 characterize. 475 As an example, one might use: 477 a=icap:1 Document Camera 479 to represent a purpose of a media stream identified with the 480 capability number 1. 482 The media information capability attribute satisfies the general 483 attribute production rules in [RFC4566] according to the following 484 Augmented Backus-Naur Form (ABNF) [RFC5234] syntax: 486 att-field = "icap" 487 att-value = info-cap-num 1*WSP text 488 ; text is defined in RFC 4566 489 info-cap-num = 1*DIGIT ; integer between 1 and 2^31-1 491 3.1.3.1. Configuration Parameters 493 The SDP Capability Negotiation Framework 494 [I-D.ietf-mmusic-sdp-capability-negotiation] provides for the 495 existence of the "pcfg" and "acfg" attributes, which can carry one or 496 more potential configurations to be negotiated. The concept is 497 extended by the the Media Capabilities Negotiation 498 [I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute 499 that conveys latent configurations. 501 In this document, we define an parameter to be 502 used to convey information capabilities in a potential or latent 503 configuration. This parameter is defined as an with the following associations: 506 ext-cap-name = "i" 508 ext-cap-list = info-cap-list 510 This leads to the following definition for the information capability 511 parameter: 513 extension-config-list = info-config-list 514 info-config-list = "i=" info-cap-list 515 info-cap-list = info-cap-num *(BAR info-cap-num) 516 info-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive 517 ; BAR defined in SDP capabilities 518 ; negotiation 520 Figure 5: Syntax of the information capability parameter in lcfg and 521 pcfg attributes 523 Each potential capability configuration contains a single information 524 capability attribute number where 'info-cap-num' is the information 525 capability number defined explicitly earlier in this document, and 526 hence must be between 1 and 2^31-1 (both included). The information 527 capability allows the expression of only a single capability in each 528 alternative, since no more than a single information field is 529 permitted per media block. Nevertheless, it is still allowed to 530 express alternative potential information configurations separated by 531 a vertical bar ("|"). 533 3.1.3.2. Option Tag 535 At present, it is difficult to envision a scenario in which the 536 'icap' attribute must be supported or the offer must be rejected. In 537 most cases, if the icap attribute or its contents were to be ignored, 538 an offered configuration could still be chosen based on other 539 criteria such as configuration numbering. However, one might imagine 540 an SDP offer that contained English and Spanish potential 541 configurations for an audio stream. The session might be 542 unintelligible if the choice is based on configuration numbering, 543 rather than informed user selection. Based on such considerations, 544 it may well prove useful to announce the ability to use the icap 545 attribute and its contents to select media configurations, or to 546 inform the user about the selected configuration(s). Therefore, we 547 define a new option tag of "icap-v0" that identifies support for the 548 media information capability. This option tag SHOULD be added to 549 other existing option tags present in the "csup" and/or "creq" 550 attributes in SDP, according to the procedures defined in the SDP 551 Capability Negotiation Framework 552 [I-D.ietf-mmusic-sdp-capability-negotiation]. The discusion above 553 suggests that "icap-v0" will typically appear in a "csup" attribute, 554 but rarely in a "creq" attribute. 556 3.2. Session Level versus Media Level 558 The icap, ccap, and bcap attributes can appear at the session level 559 and/or at the media level, but MUST be interpreted as a media-level 560 capability. To avoid confusion, the for each line 561 must be unique across all capability attributes of the same type 562 within the entire session description. As described below, these 563 capability attributes may be referenced by acfg, pcfg and/or lcfg 564 attributes. 566 4. Field Replacement Rules 568 To simplify the construction of SDP records, given the need to 569 include fields at the base level for endpoints that do not support 570 capabilities negotiation, we define some simple field-replacement 571 rules for those fields invoked by potential or latent configurations. 572 In particular, any i-field or c-field invoked by a configuration MUST 573 replace the corresponding field, if present at the base media level. 574 Any b-field invoked by a configuration MUST replace any b-field of 575 the same bandwidth type at the media level. 577 5. IANA Considerations 579 5.1. New SDP Attributes 581 IANA is hereby requested to register the following new SDP 582 attributes: 584 Attribute name: icap 586 Long form name: Information Capability 588 Type of attribute: Media-level 590 Subject to charset: Yes 592 Purpose: Negotiate human-readable media information 594 Appropriate values: See Section 3.1.3 596 Attribute name: ccap 598 Long form name: Connection Data Capability 600 Type of attribute: Media-level 602 Subject to charset: No 604 Purpose: Negotiate media-level connection data 606 Appropriate values: See Section 3.1.2 608 Attribute name: bcap 610 Long form name: Bandwidth Capability 612 Type of attribute: Media-level 614 Subject to charset: No 616 Purpose: Negotiate media-level bandwidths 618 Appropriate values: See Section 3.1.1 620 5.2. New Option Tags 622 IANA is hereby requested to add the new option tags "ccap-v0", 623 "icap-v0", and "bcap-v0", defined herein, to the SDP Capability 624 Negotiation Option Tag Registry. 626 5.3. New SDP Capability Negotiation Configuration Parameters 628 6. Security Considerations 630 This document provides an extension on top of RFC 4566 [RFC4566], RFC 631 3264 [RFC3264], SDP Capability Negotiation Framework 632 [I-D.ietf-mmusic-sdp-capability-negotiation], and SDP Media 633 Capabilities Negotiation [I-D.ietf-mmusic-sdp-media-capabilities]. 634 As such, the security considerations of those documents apply. 636 7. Acknowledgments 638 Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson 639 for arguing for the existence of this document and early reviewing 640 it. 642 8. References 644 8.1. Normative References 646 [I-D.boucadair-mmusic-altc] 647 Boucadair, M., Kaplan, H., Gilman, R., and S. 648 Veikkolainen, "Session Description Protocol (SDP) 649 Alternate Connectivity (ALTC) Attribute", 650 draft-boucadair-mmusic-altc-00 (work in progress), 651 February 2010. 653 [I-D.ietf-mmusic-sdp-capability-negotiation] 654 Andreasen, F., "SDP Capability Negotiation", 655 draft-ietf-mmusic-sdp-capability-negotiation-11 (work in 656 progress), February 2010. 658 [I-D.ietf-mmusic-sdp-cs] 659 Garcia, M. and S. Veikkolainen, "Session Description 660 Protocol (SDP) Extension For Setting Up Audio and Video 661 Media Streams Over Circuit-Switched Bearers In The Public 662 Switched Telephone Network (PSTN)", 663 draft-ietf-mmusic-sdp-cs-03 (work in progress), 664 February 2010. 666 [I-D.ietf-mmusic-sdp-media-capabilities] 667 Gilman, R., Even, R., and F. Andreasen, "SDP media 668 capabilities Negotiation", 669 draft-ietf-mmusic-sdp-media-capabilities-09 (work in 670 progress), February 2010. 672 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 673 Requirement Levels", BCP 14, RFC 2119, March 1997. 675 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 676 with Session Description Protocol (SDP)", RFC 3264, 677 June 2002. 679 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 680 Description Protocol", RFC 4566, July 2006. 682 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 683 Specifications: ABNF", STD 68, RFC 5234, January 2008. 685 8.2. Informative References 687 [I-D.ietf-mmusic-ice] 688 Rosenberg, J., "Interactive Connectivity Establishment 689 (ICE): A Protocol for Network Address Translator (NAT) 690 Traversal for Offer/Answer Protocols", 691 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 693 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 694 Jacobson, "RTP: A Transport Protocol for Real-Time 695 Applications", STD 64, RFC 3550, July 2003. 697 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 698 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 699 RFC 3711, March 2004. 701 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 702 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 704 Authors' Addresses 706 Miguel A. Garcia-Martin 707 Ericsson 708 Calle Via de los Poblados 13 709 Madrid, 28033 710 Spain 712 Phone: +34 91 339 1000 713 Email: miguel.a.garcia@ericsson.com 714 Simo Veikkolainen 715 Nokia 716 P.O. Box 407 717 NOKIA GROUP, FI 00045 718 Finland 720 Phone: +358 50 486 4463 721 Email: simo.veikkolainen@nokia.com 723 Robert R. Gilman 724 3243 W. 11th Ave. Dr. 725 Broomfield, Colorado 80020 726 U.S.A. 728 Phone: +1 303 898 9780 729 Email: bob_gilman@comcast.net