idnits 2.17.1 draft-garcia-mmusic-sdp-icap-bcap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. 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 (February 2, 2011) is 4832 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) == Outdated reference: A later version (-17) exists of draft-ietf-mmusic-sdp-media-capabilities-10 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 3 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: August 6, 2011 Nokia 6 R. Gilman 7 February 2, 2011 9 Miscellaneous Capabilities Negotiation in the Session Description 10 Protocol (SDP) 11 draft-garcia-mmusic-sdp-icap-bcap-01 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 two additional SDP capabilities. In 24 particular, this memo provides a mechanism to negotiate media titles 25 ("i=" line for each media) and media bandwidth ("b=" line). 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 6, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 75 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5 76 3.1. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 5 77 3.1.1. Bandwidth Capability . . . . . . . . . . . . . . . . . 6 78 3.1.2. Information Capability . . . . . . . . . . . . . . . . 8 79 3.2. Session Level versus Media Level . . . . . . . . . . . . . 10 80 4. Field Replacement Rules . . . . . . . . . . . . . . . . . . . 10 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 11 83 5.2. New Option Tags . . . . . . . . . . . . . . . . . . . . . 11 84 5.3. New SDP Capability Negotiation Configuration Parameters . 11 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 89 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 92 1. Introduction 94 The Session Description Protocol (SDP) [RFC4566] is intended for 95 describing multimedia sessions for the purposes of session 96 announcement, session invitation, and other forms of multimedia 97 session initiation. SDP has been extended with a capability 98 negotiation mechanism framework [RFC5939] which allows the endpoints 99 to negotiate capabilities, such as support for Realtime Transport 100 Protocol (RTP) [RFC3550] and Secure Realtime Transport Protocol 101 (SRTP) [RFC3711]. The SDP media capabilities [RFC5939] provides 102 negotiation capabilities to media lines as well. 104 The capability negotiation is embedded into the widely used SDP 105 offer/answer procedure [RFC3264]. This memo provides the means to 106 negotiate further capabilities than those specified in the SDP 107 capability negotiation mechanism framework [RFC5939] and the SDP 108 media capabilities negotiation 109 [I-D.ietf-mmusic-sdp-media-capabilities]. In particular, this memo 110 provides a mechanism to negotiate media titles ("i=") and media 111 bandwidth ("b="). 113 It would have been possible to define a mechanism to negotiate media 114 encryption keys ("k="). However, the usage of the media encryption 115 keys ("k=") is highly discouraged in favour of other existing more 116 sophisticated mechanisms. Therefore, we are not providing a 117 mechanism to provide capabilities for media encryption keys ("k=") at 118 this stage. 120 Since the two added capabilities are highly unconnected, it is not 121 expected that implementations will support both at the same time. 122 Instead, it is expected that applications will choose their needed 123 capability for their specific purpose. Due to this, we are writing 124 the normative part pertaining to both capabilities in a self- 125 contained section: Section 3.1.1 describes the bandwidth capability 126 extension, and Section 3.1.2 describes the information capability 127 extension. Separate option tags are defined for both capabilities. 129 2. Conventions Used in This Document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in BCP 14, RFC 2119 134 [RFC2119] and indicate requirement levels for compliant 135 implementations. 137 3. Protocol Description 139 3.1. Extensions to SDP 141 The SDP Capability Negotiation Framework [RFC5939] and the SDP media 142 capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities] 143 specify attributes for negotiating SDP capabilities. These documents 144 specify new attributes (e.g., 'acap', 'tcap', 'mcap') for achieving 145 their purpose. In this document we define two new additional 146 capability attributes for SDP lines of the the general form: 148 type=value 150 for types "i" and "b". The corresponding capability attributes are 151 defined as "icap" and "bcap", respectively. 153 From the sub-rules of "a=" line in SDP [RFC4566], SDP attributes are 154 of the form: 156 attribute = (att-field ":" att-value) / att-field 157 att-field = token 158 att-value = byte-string 160 Capability attributes use only the 'att-field:att-value' form. 162 The new attributes may be referenced in potential configurations 163 ("a=pcfg") or in latent configurations ("a=lcfg"), as productions 164 conforming to the extension-config-list as defined in [RFC5939]. 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 [RFC5234] 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 [RFC5939]. 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. In this memo, 194 we specify the bandwidth at the media level. The bandwidth field is 195 specified in RFC 4566 [RFC4566] with the following syntax: 197 b=: 199 where is an alphanumeric modifier giving the meaning of the 200 figure. 202 In this document, we define a new capability attribute: the bandwidth 203 capability attribute "bcap". This attribute lists bandwidth as 204 capabilities according to the following definition: 206 "a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF 208 where is a unique ordinal identifier of the bandwidth 209 capability, and the other elements are as defined for the "b=" field 210 in [RFC4566]. 212 This format satisfies the general attribute production rules in 213 [RFC4566] according to the following Augmented Backus-Naur Form 214 (ABNF) [RFC5234] syntax: 216 att-field = "bcap" 217 att-value = bw-cap-num 1*WSP bwtype ":" bandwidth 218 bw-cap-num = 1*DIGIT ; integer between 1 and 2^31-1, inclusive 220 Negotiation of bandwidth per media stream can be useful when 221 negotiating media encoding capabilities with different bandwidths. 223 3.1.1.1. Configuration Parameters 225 The SDP capability negotiation framework [RFC5939] provides for the 226 existence of the "pcfg" and "acfg" attributes, which can carry one or 227 more potential configurations to be negotiated. The concept is 228 extended by the the SDP media capabilities negotiation 229 [I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute 230 that conveys latent configurations. 232 Extensions to the "pcfg" and "lcfg" attributes are defined through 233 , and extensions to the "acfg" attribute are 234 defined through the as defined in [RFC5939]. 236 In this document we extend the field to be 237 able to convey lists of bandwidth capabilities in latent or potential 238 configurations, according to the following Augmented Backus-Naur Form 239 (ABNF) [RFC5234] syntax: 241 extension-config-list = bandwidth-config-list 243 bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR b-cap-list) 244 bw-cap-list = bw-cap-num *("," b-cap-num) 245 bw-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive 247 Figure 1: Syntax of the bandwidth parameter in lcfg and pcfg 248 attributes 250 Each bandwidth capability configuration is a comma-separated list of 251 bandwidth capability attribute numbers where 'b-cap-num' refers to 252 the bw-cap-num bandwidth capability numbers defined explicitly 253 earlier in this document, and hence must be between 1 and 2^31-1 254 (both included). Alternative bandwidth configurations are separated 255 by a vertical bar ("|"). 257 The bandwidth parameter to the actual configuration attribute 258 ("a=acfg") is formulated as a sel-extension-config with 260 ext-cap-name = "b" 262 hence 264 sel-extension-config = sel-bandwidth-config 265 sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above. 267 Figure 2: Syntax of the bandwidth parameter in acfg attributes 269 3.1.1.2. Option tag 271 The SDP capability negotiation framework [RFC5939] allows for 272 capability negotiation extensions to be defined. Associated with 273 each such extension is an option tag that identifies the extension in 274 question. Hereby, we define a new option tag "bcap-v0" that 275 identifies support for the bandwidth capability. This option tag 276 SHOULD be added to other existing option tags present in the "csup" 277 and "creq" attributes in SDP, according to the procedures defined in 278 the SDP Capability Negotiation Framework [RFC5939]. 280 3.1.2. Information Capability 282 RFC 4566 [RFC4566] provides for the existence of an information field 283 expressed in the format of the "i=" line, which can appear either at 284 the session level or at the media level. An "i=" line that is 285 present at the session level is known as the "session name", and its 286 purpose is to convey a human-readable textual information about the 287 session. We don't see much usage of capabilities related to the "i=" 288 line at the session level. 290 The "i=" line in SDP can also appear at the media level, in which 291 case it is used to provide human-readable information about the media 292 stream to which it is related, e.g., it may indicate the purpose of 293 the media stream. The information field is not to be confused with 294 the label attribute ("a=label:"), [RFC4574]) which provides a 295 machine-readable tag. It is foreseen that applications declaring 296 capabilities related to different configurations of a media stream 297 may need to provide different identifying information for each of 298 those configurations. That is, a party might offer alternative media 299 configurations for a stream, each of which represents a different 300 presentation of the same or similar information. For example, an 301 audio stream might offer English or Spanish configurations, or a 302 video stream might offer a choice of video source such as speaker 303 camera, group camera, or document viewer. The information capability 304 is needed to inform the answering user in order to select the proper 305 choice, and the label is used to inform the offering machine which 306 choice the answerer has selected. Hence, there is value in defining 307 a mechanism to provide information of media streams as capabilities. 309 According to SDP [RFC4566], the media label has the following syntax: 311 "i="text 313 where "text" represents a human-readable text indicating the purpose 314 of the media stream. 316 In this document we define a new capability attribute: the 317 information media capability, "icap". This attribute lists 318 information media labels as capabilities, according to the following 319 definition: 321 "a=icap:" info-cap-num 1*WSP text 323 where is the unique ordinal identifier of the 324 particular media information capability and is a human- 325 readable text that indicates the purpose of the media stream it is 326 supposed to characterize. 328 As an example, one might use: 330 a=icap:1 Document Camera 332 to represent a purpose of a media stream identified with the 333 capability number 1. 335 The media information capability attribute satisfies the general 336 attribute production rules in [RFC4566] according to the following 337 Augmented Backus-Naur Form (ABNF) [RFC5234] syntax: 339 att-field = "icap" 340 att-value = info-cap-num 1*WSP text 341 ; text is defined in RFC 4566 342 info-cap-num = 1*DIGIT ; integer between 1 and 2^31-1 344 3.1.2.1. Configuration Parameters 346 The SDP Capability Negotiation Framework [RFC5939] provides for the 347 existence of the "pcfg" and "acfg" attributes, which can carry one or 348 more potential configurations to be negotiated. The concept is 349 extended by the the SDP media capabilities negotiation 350 [I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute 351 that conveys latent configurations. 353 In this document, we define an parameter to be 354 used to convey information capabilities in a potential or latent 355 configuration. This parameter is defined as an with the following associations: 358 ext-cap-name = "i" 360 ext-cap-list = info-cap-list 362 This leads to the following definition for the information capability 363 parameter: 365 extension-config-list = info-config-list 366 info-config-list = "i=" info-cap-list 367 info-cap-list = info-cap-num *(BAR info-cap-num); BAR defined in RFC5939 368 info-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive 370 Figure 3: Syntax of the information capability parameter in lcfg and 371 pcfg attributes 373 Each potential capability configuration contains a single information 374 capability attribute number where 'info-cap-num' is the information 375 capability number defined explicitly earlier in this document, and 376 hence must be between 1 and 2^31-1 (both included). The information 377 capability allows the expression of only a single capability in each 378 alternative, since no more than a single information field is 379 permitted per media block. Nevertheless, it is still allowed to 380 express alternative potential information configurations separated by 381 a vertical bar ("|"). 383 3.1.2.2. Option Tag 385 At present, it is difficult to envision a scenario in which the 386 'icap' attribute must be supported or the offer must be rejected. In 387 most cases, if the icap attribute or its contents were to be ignored, 388 an offered configuration could still be chosen based on other 389 criteria such as configuration numbering. However, one might imagine 390 an SDP offer that contained English and Spanish potential 391 configurations for an audio stream. The session might be 392 unintelligible if the choice is based on configuration numbering, 393 rather than informed user selection. Based on such considerations, 394 it may well prove useful to announce the ability to use the icap 395 attribute and its contents to select media configurations, or to 396 inform the user about the selected configuration(s). Therefore, we 397 define a new option tag of "icap-v0" that identifies support for the 398 media information capability. This option tag SHOULD be added to 399 other existing option tags present in the "csup" and/or "creq" 400 attributes in SDP, according to the procedures defined in the SDP 401 Capability Negotiation Framework [RFC5939]. The discusion above 402 suggests that "icap-v0" will typically appear in a "csup" attribute, 403 but rarely in a "creq" attribute. 405 3.2. Session Level versus Media Level 407 The icap and bcap attributes can appear at the session level and/or 408 at the media level, but MUST be interpreted as a media-level 409 capability. To avoid confusion, the for each line 410 must be unique across all capability attributes of the same type 411 within the entire session description. As described below, these 412 capability attributes may be referenced by acfg, pcfg and/or lcfg 413 attributes. 415 4. Field Replacement Rules 417 To simplify the construction of SDP records, given the need to 418 include fields at the base level for endpoints that do not support 419 capabilities negotiation, we define some simple field-replacement 420 rules for those fields invoked by potential or latent configurations. 421 In particular, any i-field invoked by a configuration MUST replace 422 the corresponding field, if present at the base media level. Any 423 b-field invoked by a configuration MUST replace any b-field of the 424 same bandwidth type at the media level. 426 5. IANA Considerations 428 5.1. New SDP Attributes 430 IANA is hereby requested to register the following new SDP 431 attributes: 433 Attribute name: icap 435 Long form name: Information Capability 437 Type of attribute: Media-level 439 Subject to charset: Yes 441 Purpose: Negotiate human-readable media information 443 Appropriate values: See Section 3.1.2 445 Attribute name: bcap 447 Long form name: Bandwidth Capability 449 Type of attribute: Media-level 451 Subject to charset: No 453 Purpose: Negotiate media-level bandwidths 455 Appropriate values: See Section 3.1.1 457 5.2. New Option Tags 459 IANA is hereby requested to add the new option tags "bcap-v0" and 460 "icap-v0", defined herein, to the SDP Capability Negotiation Option 461 Tag Registry. 463 5.3. New SDP Capability Negotiation Configuration Parameters 465 IANA is hereby requested to add the new parameter identifiers "i" for 466 "information" and "b" for "bandwidth" to the Potential Configuration 467 Parameter Registry. These parameters are permitted in 'lcfg', 468 'acfg', and 'pcfg' attributes. 470 6. Security Considerations 472 This document provides an extension on top of RFC 4566 [RFC4566], RFC 473 3264 [RFC3264], SDP Capability Negotiation Framework [RFC5939], and 474 SDP media capabilities negotiation 475 [I-D.ietf-mmusic-sdp-media-capabilities]. As such, the security 476 considerations of those documents apply. 478 7. Acknowledgments 480 Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson 481 for arguing for the existence of this document and early reviewing 482 it. 484 8. References 486 8.1. Normative References 488 [I-D.ietf-mmusic-sdp-media-capabilities] 489 Gilman, R., Even, R., and F. Andreasen, "SDP media 490 capabilities Negotiation", 491 draft-ietf-mmusic-sdp-media-capabilities-10 (work in 492 progress), July 2010. 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 498 with Session Description Protocol (SDP)", RFC 3264, 499 June 2002. 501 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 502 Description Protocol", RFC 4566, July 2006. 504 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 505 Specifications: ABNF", STD 68, RFC 5234, January 2008. 507 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 508 Capability Negotiation", RFC 5939, September 2010. 510 8.2. Informative References 512 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 513 Jacobson, "RTP: A Transport Protocol for Real-Time 514 Applications", STD 64, RFC 3550, July 2003. 516 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 517 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 518 RFC 3711, March 2004. 520 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 521 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 523 Authors' Addresses 525 Miguel A. Garcia-Martin 526 Ericsson 527 Calle Via de los Poblados 13 528 Madrid, 28033 529 Spain 531 Phone: +34 91 339 1000 532 Email: miguel.a.garcia@ericsson.com 534 Simo Veikkolainen 535 Nokia 536 P.O. Box 407 537 NOKIA GROUP, FI 00045 538 Finland 540 Phone: +358 50 486 4463 541 Email: simo.veikkolainen@nokia.com 543 Robert R. Gilman 544 3243 W. 11th Ave. Dr. 545 Broomfield, Colorado 80020 546 U.S.A. 548 Phone: +1 303 898 9780 549 Email: bob_gilman@comcast.net