idnits 2.17.1 draft-garcia-mmusic-sdp-misc-cap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 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 (July 8, 2009) is 5404 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 169, but not defined ** Obsolete undefined reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-10 == Outdated reference: A later version (-17) exists of draft-ietf-mmusic-sdp-media-capabilities-07 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). 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: January 9, 2010 Nokia 6 R. Gilman 7 July 8, 2009 9 Miscellaneous Capabilities Negotiation in the Session Description 10 Protocol (SDP) 11 draft-garcia-mmusic-sdp-misc-cap-01 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may not be modified, 17 and derivative works of it may not be created, except to format it 18 for publication as an RFC or to translate it into languages other 19 than English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 9, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 SDP has been extended with a capability negotiation mechanism 53 framework that allows the endpoints to negotiate transport protocols 54 and attributes. This framework has been extended with a Media 55 capabilities negotiation mechanism that allows endpoints to negotiate 56 additional media-related capabilities. This negotiation is embedded 57 into the widely-used SDP offer/answer procedures. 59 This memo extends the SDP capability negotiation framework to allow 60 endpoints to negotiate a number of miscellaneous SDP capabilities. 61 In particular, this memo provides a mechanism to negotiate media 62 titles ("i=" line for each media), connection data ("c=" line), and 63 media bandwidth ("b=" line). 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 69 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 4 71 3.1.1. Bandwidth Capability . . . . . . . . . . . . . . . . . 5 72 3.1.2. Connection Data Capability . . . . . . . . . . . . . . 7 73 3.1.3. Information Capability . . . . . . . . . . . . . . . . 9 74 3.2. Session Level versus Media Level . . . . . . . . . . . . . 12 75 4. Field Replacement Rules . . . . . . . . . . . . . . . . . . . 12 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 12 78 5.2. New Option Tags . . . . . . . . . . . . . . . . . . . . . 13 79 5.3. New SDP Capability Negotiation Configuration Parameters . 13 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 The Session Description Protocol (SDP) [RFC4566] is intended for 90 describing multimedia sessions for the purposes of session 91 announcement, session invitation, and other forms of multimedia 92 session initiation. SDP has been extended with a capability 93 negotiation mechanism framework 94 [I-D.ietf-mmusic-sdp-capability-negotiation] that allows the 95 endpoints to negotiate capabilities, such as support for Realtime 96 Transport Protocol (RTP) [RFC3550] and Secure Realtime Transport 97 Protocol (SRTP) [RFC3711]. The SDP media capabilities 98 [I-D.ietf-mmusic-sdp-media-capabilities] provides negotiation 99 capabilities to media lines as well. 101 This negotiation is embedded into the widely used SDP offer/answer 102 procedures [RFC3264]. This memo provides the means to negotiate 103 further capabilities than those specified in the SDP capability 104 negotiation mechanism framework 105 [I-D.ietf-mmusic-sdp-capability-negotiation] and the SDP media 106 capabilities [I-D.ietf-mmusic-sdp-media-capabilities]. In 107 particular, this memo provides a mechanism to negotiate media titles 108 ("i="), connection data ("c="), and media bandwidth ("b="). It would 109 have been possible to define a mechanism to negotiate media 110 encryption keys ("k="). However, the usage of the media encryption 111 keys ("k=") is highly discouraged in favour of other existing more 112 sophisticated mechanisms. Therefore, we are not providing a 113 mechanism to provide capabilities for media encryption keys ("k=") at 114 this stage. 116 Since the three added capabilities are highly unconnected, it is not 117 expected that implementations will support all three at the same 118 time. Instead, it is expected that applications will choose their 119 needed capability for their specific purpose. Due to this, we are 120 writing the normative part pertaining to each capability in a self- 121 contained section. In particular, Section 3.1.1 describes the 122 bandwidth capability extension, Section 3.1.2 describes the 123 connection data capability extension, and Section 3.1.3 describes the 124 information capability extension. Separate option tags are defined 125 for each capability. 127 2. Conventions Used in This Document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in BCP 14, RFC 2119 132 [RFC2119] and indicate requirement levels for compliant 133 implementations. 135 3. Protocol Description 137 3.1. Extensions to SDP 139 The SDP Capability Negotiation Framework 140 [I-D.ietf-mmusic-sdp-capability-negotiation] and the SDP media 141 capabilities [I-D.ietf-mmusic-sdp-media-capabilities] specify 142 attributes for negotiating SDP capabilities. These documents specify 143 new attributes (e.g., 'acap', 'tcap', 'mcap') for achieving their 144 purpose. In this document we define a number of new additional 145 capability attributes for SDP lines of the the general form: 147 type=value 149 for types "i", "c", and "b". The corresponding capability attributes 150 are defined as "icap", "ccap", and "bcap", respectively. 152 From the sub-rules of "a=" line in SDP [RFC4566], SDP attributes are 153 of the form: 155 attribute = (att-field ":" att-value) / att-field 156 att-field = token 157 att-value = byte-string 159 Capability attributes use only the 'att-field:att-value' form. 161 The new attributes may be referenced in potential configurations 162 ("a=pcfg") or in latent configurations ("a=lcfg"), as productions 163 conforming to the extension-config-list as defined in 164 [I-D.ietf-mmusic-sdp-capability-negotiation]. 166 extension-config-list = ["+"] ext-cap-name "=" 167 ext-cap-list 168 ext-cap-name = 1*(ALPHA / DIGIT) 169 ext-cap-list = 1*VCHAR ; defined in [RFC4234] 171 The optional "+" is used to indicate that the entire configuration, 172 not just the parameter, must be ignored if the parameter is not 173 supported. The attributes may be referenced in actual configurations 174 as productions conforming to the sel-extension-config defined in 175 [I-D.ietf-mmusic-sdp-capability-negotiation]. 177 sel-extension-config = ext-cap-name "=" 1*VCHAR 179 The specific parameters are defined in the individual description of 180 each capability, below. 182 It is not the intention of this work to negotiate these new 183 capabilities at the session level, rather only at the media level. 184 Therefore, capabilities referenced by any configuration attribute 185 MUST appear at the media level when a configuration is "converted" to 186 a corresponding media block. For this reason, the "icap" attribute 187 is called the "media information capability". Specific values for 188 each new attribute are described below. 190 3.1.1. Bandwidth Capability 192 According to RFC 4566 [RFC4566] the bandwidth field denotes the 193 proposed bandwidth to be used by the session or media. For what it 194 concerns this memo, we focus on the bandwidth at the media level. 195 This bandwidth field is specified in RFC 4566 [RFC4566] according to 196 the following syntax: 198 b=: 200 where is an alphanumeric modifier giving the meaning of the 201 figure. 203 In this document, we define a new capability attribute: the bandwidth 204 capability attribute "bcap". This attribute lists bandwidth as 205 capabilities according to the following definition: 207 "a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF 209 where is a unique ordinal identifier of the bandwidth 210 capability, and the other elements are as defined for the "b=" field 211 in [RFC4566]. 213 This format satisfies the general attribute production rules in 214 [RFC4566] according to the following Augmented Backus-Naur Form 215 (ABNF) [RFC5234] syntax: 217 att-field = "bcap" 218 att-value = bw-cap-num 1*WSP bwtype ":" bandwidth 219 bw-cap-num = 1*DIGIT ; integer between 1 and 2^31-1, inclusive 221 Negotiation of bandwidth per media stream can be useful when 222 negotiating media encoding capabilities with different bandwidths. 224 3.1.1.1. Configuration Parameters 226 The SDP Capability Negotiation Framework 227 [I-D.ietf-mmusic-sdp-capability-negotiation] provides for the 228 existence of the "pcfg" and "acfg" attributes, which can carry one or 229 more potential configurations to be negotiated. The concept is 230 extended by the the Media Capabilities Negotiation 232 [I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute 233 that conveys latent configurations. Extensions to the "pcfg" and 234 "lcfg" attributes are defined through , and 235 extensions to the "acfg" attribute are defined through the as defined in 237 [I-D.ietf-mmusic-sdp-capability-negotiation]. 239 In this document we extend the field to be 240 able to convey lists of bandwidth capabilities in latent or potential 241 configurations, according to the following Augmented Backus-Naur Form 242 (ABNF) [RFC5234] syntax: 244 extension-config-list = bandwidth-config-list 246 bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR b-cap-list) 247 bw-cap-list = bw-cap-num *("," b-cap-num) 248 bw-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive 250 Figure 1: Syntax of the bandwidth parameter in lcfg and pcfg 251 attributes 253 Each bandwidth capability configuration is a comma-separated list of 254 bandwidth capability attribute numbers where 'b-cap-num' refers to 255 the bw-cap-num bandwidth capability numbers defined explicitly 256 earlier in this document, and hence must be between 1 and 2^31-1 257 (both included). Alternative bandwidth configurations are separated 258 by a vertical bar ("|"). 260 The bandwidth parameter to the actual configuration attribute 261 ("a=acfg") is formulated as a sel-extension-config with 263 ext-cap-name = "b" 265 hence 267 sel-extension-config = sel-bandwidth-config 268 sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above. 270 Figure 2: Syntax of the bandwidth parameter in acfg attributes 272 3.1.1.2. Option tag 274 The SDP Capability Negotiation Framework 275 [I-D.ietf-mmusic-sdp-capability-negotiation] solution allows for 276 capability negotiation extensions to be defined. Associated with 277 each such extension is an option tag that identifies the extension in 278 question. Hereby, we define a new option tag of "bcap-v0" that 279 identifies support for the bandwidth capability. This option tag 280 SHOULD be added to other existing option tags present in the "csup" 281 and "creq" attributes in SDP, according to the procedures defined in 282 the SDP Capability Negotiation Framework 283 [I-D.ietf-mmusic-sdp-capability-negotiation]. 285 3.1.2. Connection Data Capability 287 According to SDP [RFC4566], the connection data field in SDP contains 288 the connection data, and it has the following syntax: 290 c= 292 where indicates the network type, indicates the 293 address type, and the is the connection address, 294 which is dependent on the address type. 296 At the moment, the only network type defined is "IN", which indicates 297 Internet network type. The address types "IP4" and "IP6" indicate 298 the type of IP addresses. 300 SDP [RFC4566] permits specification of connection data at the session 301 or at the media level. In order to permit negotiation of connection 302 data at the media level, we define the connection data capability 303 attribute ("a=ccap") in the form: 305 "a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP connection- 306 address CRLF 308 where is a unique ordinal identifier of the connection 309 data capability, and the other elements are as defined in [RFC4566]. 311 This format corresponds to the [RFC4566] attribute production rules 312 according to the following Augmented Backus-Naur Form (ABNF) 313 [RFC5234] syntax: 315 att-field = "ccap" 316 att-value = conn-cap-num 1*WSP nettype SP addrtype 317 SP connection-address 318 conn-cap-num = 1*DIGIT ; integer between 1 and 2^31-1, inclusive 320 The connection information capability can be used to negotiate the 321 use of IPv4 or IPv6 addresses without resort to Interactive 322 Connectivity Establishment(ICE) [I-D.ietf-mmusic-ice]. Note, 323 however, that ICE provides for real-time reachability testing of 324 multiple addresses, whereas use of the connection capability forces 325 an early choice of connection address. 327 3.1.2.1. Configuration Parameters 329 The SDP Capability Negotiation Framework 330 [I-D.ietf-mmusic-sdp-capability-negotiation] provides for the 331 existence of the "pcfg" and "acfg" attributes, which can carry one or 332 more potential configurations to be negotiated. The concept is 333 extended by the the Media Capabilities Negotiation 334 [I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute 335 that conveys latent configurations. 337 In this document we define a parameter to be used 338 to specify a connection data capability in a potential or latent 339 configuration attribute. The parameter follows the form of an 340 extension-config-list, with 342 ext-cap-name = "c" 344 ext-cap-list = conn-cap-list 346 where, according to the following Augmented Backus-Naur Form (ABNF) 347 [RFC5234] syntax: 349 extension-config-list = conn-config-list 350 conn-config-list = "c=" conn-cap-list 351 conn-cap-list = conn-cap-num *(BAR conn-cap-num) 352 conn-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive 354 Figure 3: Syntax of the connection data parameter in lcfg and pcfg 355 attributes 357 Each capability configuration alternative contains a single 358 connection data capability attribute number and refers to the conn- 359 cap-num capability number defined explicitly earlier in this 360 document, and hence must be between 1 and 2^31-1 (both included). 361 The connection data capability allows the expression of only a single 362 capability in each alternative, rather than a list of capabilities, 363 since no more than a single connection data field is permitted per 364 media block. Nevertheless, it is still allowed to express 365 alternative potential connection configurations separated by a 366 vertical bar ("|"). 368 The connection data parameter to the actual configuration attribute 369 ("a=acfg") is formulated as a sel-extension-config with 371 ext-cap-name = "c" 373 hence 374 sel-extension-config = sel-connection-config 375 sel-connection-config = "c=" conn-cap-num ; as defined above. 377 Figure 4: Syntax of the connection data parameter in acfg attributes 379 3.1.2.2. Option tag 381 The SDP Capability Negotiation Framework 382 [I-D.ietf-mmusic-sdp-capability-negotiation] solution allows for 383 capability negotiation extensions to be defined. Associated with 384 each such extension is an option tag that identifies the extension in 385 question. Hereby, we define a new option tag of "ccap-v0" that 386 identifies support for the connection data capability. This option 387 tag SHOULD be added to other existing option tags present in the 388 "csup" and "creq" attributes in SDP, according to the procedures 389 defined in the SDP Capability Negotiation Framework 390 [I-D.ietf-mmusic-sdp-capability-negotiation]. 392 3.1.3. Information Capability 394 RFC 4566 [RFC4566] provides for the existence of an information field 395 expressed in the format of the "i=" line, which can appear either at 396 the session level or at the media level. An "i=" line that is 397 present at the session level is known as the "session name", and its 398 purpose is to convey a human-readable textual information about the 399 session. We don't see much usage of capabilities related to the "i=" 400 line at the session level. 402 The "i=" line in SDP can also appear at the media level, in which 403 case it is used to provide human-readable information about the media 404 stream to which it is related, e.g., it may indicate the purpose of 405 the media stream. The information field is not to be confused with 406 the label attribute ("a=label:...), [RFC4574]) which provides a 407 machine-readable tag. It is foreseen that applications declaring 408 capabilities related to different configurations of a media stream 409 may need to provide different identifying information for each of 410 those configurations. That is, a party might offer alternative media 411 configurations for a stream, each of which represents a different 412 presentation of the same or similar information. For example, an 413 audio stream might offer English or Spanish configurations, or a 414 video stream might offer a choice of video source such as speaker 415 camera, group camera, or document viewer. The information capability 416 is needed to inform the answering user in order to select the proper 417 choice, and the label is used to inform the offering machine which 418 choice the answerer has selected. Hence, there is value in defining 419 a mechanism to provide information of media streams as capabilities. 421 According to SDP [RFC4566], the media label has the following syntax: 423 "i="text 425 where "text" represents a human-readable text indicating the purpose 426 of the media stream. 428 In this document we define a new capability attribute: the 429 information media capability, "icap". This attribute lists 430 information media labels as capabilities, according to the following 431 definition: 433 "a=icap:" info-cap-num 1*WSP text 435 where is the ordinal identifier of the particular 436 media information capability and is a human-readable text that 437 indicates the purpose of the media stream it is supposed to 438 characterize. 440 As an example, one might use: 442 a=icap:1 Document Camera 444 to represent a purpose of a media stream identified with the 445 capability number 1. 447 The media information capability attribute satisfies the general 448 attribute production rules in [RFC4566] according to the following 449 Augmented Backus-Naur Form (ABNF) [RFC5234] syntax: 451 att-field = "icap" 452 att-value = info-cap-num 1*WSP text 453 ; text is defined in RFC 4566 454 info-cap-num = 1*DIGIT ; integer between 1 and 2^31-1 456 3.1.3.1. Configuration Parameters 458 The SDP Capability Negotiation Framework 459 [I-D.ietf-mmusic-sdp-capability-negotiation] provides for the 460 existence of the "pcfg" and "acfg" attributes, which can carry one or 461 more potential configurations to be negotiated. The concept is 462 extended by the the Media Capabilities Negotiation 463 [I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute 464 that conveys latent configurations. 466 In this document, we define an parameter to be 467 used to convey information capabilities in a potential or latent 468 configuration. This parameter is defined as an with the following associations: 471 ext-cap-name = "i" 473 ext-cap-list = info-cap-list 475 This leads to the following definition for the information capability 476 parameter: 478 extension-config-list = info-config-list 479 info-config-list = "i=" info-cap-list 480 info-cap-list = info-cap-num *(BAR info-cap-num) 481 info-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive 482 ; BAR defined in SDP capabilities 483 ; negotiation 485 Figure 5: Syntax of the information capability parameter in lcfg and 486 pcfg attributes 488 Each potential capability configuration contains a single information 489 capability attribute number where 'info-cap-num' is the information 490 capability number defined explicitly earlier in this document, and 491 hence must be between 1 and 2^31-1 (both included). The information 492 capability allows the expression of only a single capability in each 493 alternative, since no more than a single information field is 494 permitted per media block. Nevertheless, it is still allowed to 495 express alternative potential information configurations separated by 496 a vertical bar ("|"). 498 3.1.3.2. Option Tag 500 At present, it is difficult to envision a scenario in which the 501 'icap' attribute must be supported or the offer must be rejected. In 502 most cases, if the icap attribute or its contents were to be ignored, 503 an offered configuration could still be chosen based on other 504 criteria such as configuration numbering. However, one might imagine 505 an SDP offer that contained English and Spanish potential 506 configurations for an audio stream. The session might be 507 unintelligible if the choice is based on configuration numbering, 508 rather than informed user selection. Based on such considerations, 509 it may well prove useful to announce the ability to use the icap 510 attribute and its contents to select media configurations, or to 511 inform the user about the selected configuration(s). Therefore, we 512 define a new option tag of "icap-v0" that identifies support for the 513 media information capability. This option tag SHOULD be added to 514 other existing option tags present in the "csup" and/or "creq" 515 attributes in SDP, according to the procedures defined in the SDP 516 Capability Negotiation Framework 517 [I-D.ietf-mmusic-sdp-capability-negotiation]. The discusion above 518 suggests that "icap-v0" will typically appear in a "csup" attribute, 519 but rarely in a "creq" attribute. 521 3.2. Session Level versus Media Level 523 The icap, ccap, and bcap attributes can appear at the session level 524 and/or at the media level, but MUST be interpreted as a media-level 525 capability. To avoid confusion, the for each line 526 must be unique across all capability attributes of the same type 527 within the entire session description. As described below, these 528 capability attributes may be referenced by acfg, pcfg and/or lcfg 529 attributes. 531 4. Field Replacement Rules 533 To simplify the construction of SDP records, given the need to 534 include fields at the base level for endpoints that do not support 535 capabilities negotiation, we define some simple field-replacement 536 rules for those fields invoked by potential or latent configurations. 537 In particular, any i-field or c-field invoked by a configuration MUST 538 replace the corresponding field, if present at the base media level. 539 Any b-field invoked by a configuration MUST replace any b-field of 540 the same bandwidth type at the media level. 542 5. IANA Considerations 544 5.1. New SDP Attributes 546 IANA is hereby requested to register the following new SDP 547 attributes: 549 Attribute name: icap 551 Long form name: Information Capability 553 Type of attribute: Media-level 555 Subject to charset: Yes 557 Purpose: Negotiate human-readable media information 559 Appropriate values: See Section 3.1.3 561 Attribute name: ccap 563 Long form name: Connection Data Capability 564 Type of attribute: Media-level 566 Subject to charset: No 568 Purpose: Negotiate media-level connection data 570 Appropriate values: See Section 3.1.2 572 Attribute name: bcap 574 Long form name: Bandwidth Capability 576 Type of attribute: Media-level 578 Subject to charset: No 580 Purpose: Negotiate media-level bandwidths 582 Appropriate values: See Section 3.1.1 584 5.2. New Option Tags 586 IANA is hereby requested to add the new option tags "ccap-v0", 587 "icap-v0", and "bcap-v0", defined herein, to the SDP Capability 588 Negotiation Option Tag Registry. 590 5.3. New SDP Capability Negotiation Configuration Parameters 592 6. Security Considerations 594 This document provides an extension on top of RFC 4566 [RFC4566], RFC 595 3264 [RFC3264], SDP Capability Negotiation Framework 596 [I-D.ietf-mmusic-sdp-capability-negotiation], and SDP Media 597 Capabilities Negotiation [I-D.ietf-mmusic-sdp-media-capabilities]. 598 As such, the security considerations of those documents apply. 600 7. Acknowledgments 602 Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson 603 for arguing for the existence of this document and early reviewing 604 it. 606 8. References 607 8.1. Normative References 609 [I-D.ietf-mmusic-sdp-capability-negotiation] 610 Andreasen, F., "SDP Capability Negotiation", 611 draft-ietf-mmusic-sdp-capability-negotiation-10 (work in 612 progress), May 2009. 614 [I-D.ietf-mmusic-sdp-media-capabilities] 615 Gilman, R., Even, R., and F. Andreasen, "SDP media 616 capabilities Negotiation", 617 draft-ietf-mmusic-sdp-media-capabilities-07 (work in 618 progress), February 2009. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 624 with Session Description Protocol (SDP)", RFC 3264, 625 June 2002. 627 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 628 Description Protocol", RFC 4566, July 2006. 630 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 631 Specifications: ABNF", STD 68, RFC 5234, January 2008. 633 8.2. Informative References 635 [I-D.ietf-mmusic-ice] 636 Rosenberg, J., "Interactive Connectivity Establishment 637 (ICE): A Protocol for Network Address Translator (NAT) 638 Traversal for Offer/Answer Protocols", 639 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 641 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 642 Jacobson, "RTP: A Transport Protocol for Real-Time 643 Applications", STD 64, RFC 3550, July 2003. 645 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 646 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 647 RFC 3711, March 2004. 649 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 650 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 652 Authors' Addresses 654 Miguel A. Garcia-Martin 655 Ericsson 656 Calle Via de los Poblados 13 657 Madrid, 28033 658 Spain 660 Phone: +34 91 339 1000 661 Email: miguel.a.garcia@ericsson.com 663 Simo Veikkolainen 664 Nokia 665 P.O. Box 407 666 NOKIA GROUP, FI 00045 667 Finland 669 Phone: +358 50 486 4463 670 Email: simo.veikkolainen@nokia.com 672 Robert R. Gilman 673 3243 W. 11th Ave. Dr. 674 Broomfield, Colorado 80020 675 U.S.A. 677 Phone: +1 303 898 9780 678 Email: bob_gilman@comcast.net