idnits 2.17.1 draft-garcia-mmusic-sdp-miscellaneous-caps-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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, 2012) is 4432 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-12 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-23) exists of draft-ietf-mmusic-sdp-cs-09 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 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: September 2, 2012 Nokia 6 R. Gilman 7 March 1, 2012 9 Miscellanoues Capabilities Negotiation in the Session Description 10 Protocol (SDP) 11 draft-garcia-mmusic-sdp-miscellaneous-caps-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 three additional SDP capabilities. In 24 particular, this memo provides a mechanism to negotiate bandwidth 25 ('b=' line), connection data ('c=' line), and titles ('i=' line for 26 each session or media). 28 Status of this Memo 30 This Internet-Draft is submitted 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). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 2, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 76 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4 77 3.1. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 4 78 3.1.1. Bandwidth Capability . . . . . . . . . . . . . . . . . 7 79 3.1.2. Connection Data Capability . . . . . . . . . . . . . . 9 80 3.1.3. Title Capability . . . . . . . . . . . . . . . . . . . 11 81 3.2. Session Level versus Media Level . . . . . . . . . . . . . 14 82 3.3. Offer/Answer model extensions . . . . . . . . . . . . . . 14 83 3.3.1. Generating the Initial Offer . . . . . . . . . . . . . 15 84 3.3.2. Generating the Answer . . . . . . . . . . . . . . . . 15 85 3.3.3. Offerer Processing of the Answer . . . . . . . . . . . 15 86 3.3.4. Modifying the Session . . . . . . . . . . . . . . . . 15 87 4. Field Replacement Rules . . . . . . . . . . . . . . . . . . . 15 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 89 5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 16 90 5.2. New Option Tags . . . . . . . . . . . . . . . . . . . . . 17 91 5.3. New SDP Capability Negotiation Configuration Parameters . 17 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 93 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 99 1. Introduction 101 The Session Description Protocol (SDP) [RFC4566] is intended for 102 describing multimedia sessions for the purposes of session 103 announcement, session invitation, and other forms of multimedia 104 session initiation. SDP has been extended with a capability 105 negotiation mechanism framework [RFC5939] which allows the endpoints 106 to negotiate capabilities, such as support for Real-time Transport 107 Protocol (RTP) [RFC3550] and Secure Real-time Transport Protocol 108 (SRTP) [RFC3711]. The SDP media capabilities 109 [I-D.ietf-mmusic-sdp-media-capabilities] provides negotiation 110 capabilities to media lines as well. 112 The capability negotiation is embedded into the widely used SDP 113 offer/answer procedure [RFC3264]. This memo provides the means to 114 negotiate further capabilities than those specified in the SDP 115 capability negotiation mechanism framework [RFC5939] and the SDP 116 media capabilities negotiation 117 [I-D.ietf-mmusic-sdp-media-capabilities]. In particular, this memo 118 provides a mechanism to negotiate bandwidth ('b='), connection data 119 ('c='), and session or media titles ('i='). 121 Since the three added capabilities are highly unconnected, it is not 122 expected that implementations will support all of them at the same 123 time. Instead, it is expected that applications will choose their 124 needed capability for their specific purpose. Due to this, we are 125 writing the normative part pertaining to each capability in a self- 126 contained section: Section 3.1.1 describes the bandwidth capability 127 extension, Section 3.1.2 describes the connection data capability 128 extension, and Section 3.1.3 describes the title capability 129 extension. Separate option tags are defined for each capability. 131 2. Conventions Used in This Document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in BCP 14, RFC 2119 136 [RFC2119] and indicate requirement levels for compliant 137 implementations. 139 3. Protocol Description 141 3.1. Extensions to SDP 143 The SDP Capability Negotiation Framework [RFC5939] and the SDP media 144 capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities] 145 specify attributes for negotiating SDP capabilities. These documents 146 specify new attributes (e.g., 'acap', 'tcap', 'rmcap', 'omcap') for 147 achieving their purpose. In this document we define three new 148 additional capability attributes for SDP lines of the the general 149 form: 151 type=value 153 for types 'b', 'c', and 'i'. The corresponding capability attributes 154 are respectively defined defined as: 156 o 'bcap': bandwidth capability 158 o 'ccap': connection data capability 160 o 'icap': title capability 162 From the sub-rules of attribute ('a=') line in SDP [RFC4566], SDP 163 attributes are of the form: 165 attribute = (att-field ":" att-value) / att-field 166 att-field = token 167 att-value = byte-string 169 Capability attributes use only the 'att-field:att-value' form. 171 The new attributes may be referenced in potential configurations 172 ('a=pcfg') or in latent configurations ('a=lcfg'), as productions 173 conforming to the as respectively defined in 174 RFC 5939 [RFC5939] and the SDP media capabilities specification 175 [I-D.ietf-mmusic-sdp-media-capabilities]. 177 extension-config-list = ["+"] ext-cap-name "=" ext-cap-list 178 ext-cap-name = 1*(ALPHA / DIGIT) 179 ; ALPHA and DIGIT defined in RFC 5234 180 ext-cap-list = 1*VCHAR ; VCHAR defined in RFC 5234 182 The optional "+" is used to indicate that the extension is mandatory 183 and MUST be supported in order to use that potential configuration. 185 The new attributes may also be referenced in actual configurations 186 ('a=acfg') as productions conforming to the 187 defined in [RFC5939]. 189 sel-extension-config = ext-cap-name "=" 1*VCHAR 191 The specific parameters are defined in the individual description of 192 each capability, below. 194 The 'bcap', 'ccap', and 'icap' capability attributes can be provided 195 either at the session or media level. According to the SDP 196 Capability Negotiation [RFC5939], each extension capability must 197 specify the implication of making it part of a configuration at the 198 media level. 200 According to SDP [RFC4566], 'b=', 'c=', and 'i=' lines may appear 201 either at session or media level. In line with this, the 'bcap', 202 'ccap', and 'icap' capability attributes, when declared at session 203 level, are to be interpreted as-if that attribute was provided with 204 that value at the session level. The 'bcap', 'ccap' and 'icap' 205 capability attributes declared at media level, are to be interpreted 206 as-if that capability attribute was declared at the media level. 208 For example, extending the example in 209 [I-D.ietf-mmusic-sdp-media-capabilities] with 'icap' and 'bcap' 210 capability attributes, we get the following SDP: 212 v=0 213 o=- 25678 753849 IN IP4 192.0.2.1 214 s= 215 c=IN IP4 192.0.2.1 216 t=0 0 217 a=bcap:1 CT:200 218 a=icap:1 Video conference 219 m=audio 54320 RTP/AVP 0 220 a=rmcap:1 L16/8000/1 221 a=rmcap:2 L16/16000/2 222 a=pcfg:1 m=1|2, pt=1:99,2:98 223 m=video 66544 RTP/AVP 100 224 a=rmcap:3,4 H263-1998/90000 225 a=rtpmap:100 H264/90000 226 a=pcfg:10 m=3 pt=3:101 b=1 i=1 228 Figure 1: Example SDP offer with bcap and icap defined at session 229 level 231 The above SDP defines one PCMU audio stream and one H.264 video 232 stream. It also defines two RTP-based media capabilities ('rmcap' 233 numbered 1 and 2), using L16 audio at 8 kbps and 16 kbps, 234 respectively, as well as two RTP-based media capabilities for H.263 235 video ('rmcap' numbered 3 and 4). The RTP-based media capabilities 236 all appear at the media level. The example also contains a single 237 bandwidth capability ('bcap') and a single title capability ('icap'), 238 both defined at session level. According to the definition above, 239 when the capabilities defined in the 'bcap' and 'icap' attributes are 240 referenced from the potential configuration, in the resulting SDP 241 they are to be interpreted as session level attributes (but the RTP- 242 based media capabilities are to be interpreted as media level 243 attributes). 245 3.1.1. Bandwidth Capability 247 According to RFC 4566 [RFC4566] the bandwidth field denotes the 248 proposed bandwidth to be used by the session or media. In this memo 249 we specify the bandwidth capability attribute which can also appear 250 either at session or media level. The bandwidth field is specified 251 in RFC 4566 [RFC4566] with the following syntax: 253 b=: 255 where is an alphanumeric modifier giving the meaning of the 256 figure. 258 In this document, we define a new capability attribute: the Bandwidth 259 capability attribute 'bcap'. This attribute lists bandwidth as 260 capabilities according to the following definition: 262 "a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF 264 where is a unique integer between 1 and 2^31-1 (both 265 included) user to number the bandwidth capability, and the other 266 elements are as defined for the 'b=' field in SDP [RFC4566]. 268 This format satisfies the general attribute production rules in SDP 269 [RFC4566] according to the following Augmented Backus-Naur Form 270 (ABNF) [RFC5234] syntax: 272 att-field =/ "bcap" 273 att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth 274 bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 276 Figure 2: Syntax of the bcap attribute 278 Negotiation of bandwidth per media stream can be useful when 279 negotiating media encoding capabilities with different bandwidths. 281 3.1.1.1. Configuration Parameters 283 The SDP capability negotiation framework [RFC5939] provides for the 284 existence of the 'pcfg' and 'acfg' attributes. The concept is 285 extended by the SDP media capabilities negotiation 286 [I-D.ietf-mmusic-sdp-media-capabilities] with an 'lcfg' attribute 287 that conveys latent configurations. 289 Extensions to the 'pcfg' and 'lcfg' attributes are defined through 290 , and extensions to the 'acfg' attribute are 291 defined through the as defined in the SDP 292 Capability Negotiation [RFC5939]. 294 In this document we extend the field to be 295 able to convey lists of bandwidth capabilities in latent or potential 296 configurations, according to the following Augmented Backus-Naur Form 297 (ABNF) [RFC5234] syntax: 299 extension-config-list =/ bandwidth-config-list 300 bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR bw-cap-list) 301 ; BAR defined in RFC 5939 302 bw-cap-list = bw-cap-num *("," bw-cap-num) 303 bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 305 Figure 3: Syntax of the bandwidth parameter in 'lcfg' and 'pcfg' 306 attributes 308 Each bandwidth capability configuration is a comma-separated list of 309 bandwidth capability attribute numbers where refers to 310 the bandwidth capability numbers defined explicitly 311 earlier in this document, and hence must be between 1 and 2^31-1 312 (both included). Alternative bandwidth configurations are separated 313 by a vertical bar ("|"). 315 The above syntax is very flexible, allowing referencing to multiple 316 'b=' lines per configuration, even for the same . While the 317 need for such definitions is not seen, we have not restricted this, 318 as it is not restricted in SDP [RFC4566] either. 320 The bandwidth parameter to the actual configuration attribute 321 ('a=acfg') is formulated as a with 323 ext-cap-name = "b" 325 hence 327 sel-extension-config =/ sel-bandwidth-config 328 sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above. 330 Figure 4: Syntax of the bandwidth parameter in 'acfg' attributes 332 3.1.1.2. Option tag 334 The SDP Capability Negotiation Framework [RFC5939] allows for 335 capability negotiation extensions to be defined. Associated with 336 each such extension is an option tag that identifies the extension in 337 question. Hereby, we define a new option tag "bcap-v0" that 338 identifies support for the bandwidth capability. The endpoints using 339 the 'bcap' capability attribute SHOULD add the option tag to other 340 existing option tags present in the 'csup' and 'creq' attributes in 341 SDP, according to the procedures defined in the SDP Capability 342 Negotiation Framework [RFC5939]. 344 3.1.2. Connection Data Capability 346 According to SDP [RFC4566], the connection data field in SDP contains 347 the connection data, and it has the following syntax: 349 c= 351 where indicates the network type, indicates the 352 address type, and the is the connection address, 353 which is dependent on the address type. 355 At the moment, network types already defined include "IN", which 356 indicates Internet network type, and "ATM" (see RFC 3108 [RFC3108]), 357 used for describing Asynchronous Transfer Mode (ATM) bearer 358 connections. The Circuit-Switched (CS) descriptions in SDP document 359 [I-D.ietf-mmusic-sdp-cs] adds a "PSTN" network type for expressing a 360 Public Switched Telephone Network (PSTN) circuit switch. 362 SDP [RFC4566] permits specification of connection data at the session 363 or at the media level. In order to permit negotiation of connection 364 data at the media level, we define the connection data capability 365 attribute ('a=ccap') in the form: 367 "a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP connection- 368 address CRLF 370 where is a unique ordinal identifier of the connection 371 data capability, and the other elements are as defined in [RFC4566]. 373 This format corresponds to the [RFC4566] attribute production rules 374 according to the following Augmented Backus-Naur Form (ABNF) 375 [RFC5234] syntax: 377 att-field =/ "ccap" 378 att-value =/ conn-cap-num 1*WSP nettype SP addrtype 379 SP connection-address 380 conn-cap-num = 1*DIGIT ; 1 to 2^31-1, inclusive 382 Figure 5: Syntax of the ccap attribute 384 The 'ccap' capability attribute allows for expressing alternative 385 connection address ('c=') lines in SDP as part of the SDP capability 386 negotiation process. The 'ccap' capability attribute is intended to 387 be used only when there is no other mechanism available for 388 negotiating alternative connection address information, such as when 389 the is different among the alternative addresses. The 390 'ccap' attribute MUST NOT be used in situations where an existing 391 mechanism (such as Interactive Connectivity Establishment (ICE) 392 [RFC5245]) can be used to select between different connection 393 addresses. 395 3.1.2.1. Configuration Parameters 397 The SDP Capability Negotiation Framework [RFC5939] provides for the 398 existence of the 'pcfg' and 'acfg' attributes, which can carry one or 399 more potential configurations to be negotiated. The concept is 400 extended by the the Media Capabilities Negotiation 401 [I-D.ietf-mmusic-sdp-media-capabilities] with an 'lcfg' attribute 402 that conveys latent configurations. 404 In this document we define a parameter to be used 405 to specify a connection data capability in a potential or latent 406 configuration attribute. The parameter follows the form of an 407 , with 409 ext-cap-name = "c" 411 ext-cap-list = conn-cap-list 413 where, according to the following Augmented Backus-Naur Form (ABNF) 414 [RFC5234] syntax: 416 extension-config-list =/ conn-config-list 417 conn-config-list = "c=" conn-cap-list 418 conn-cap-list = conn-cap-num *(BAR conn-cap-num) 419 conn-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive 421 Figure 6: Syntax of the connection data parameter in 'lcfg' and 422 'pcfg' attributes 424 Each capability configuration alternative contains a single 425 connection data capability attribute number and refers to the conn- 426 cap-num capability number defined explicitly earlier in this 427 document, and hence must be between 1 and 2^31-1 (both included). 428 The connection data capability allows the expression of only a single 429 capability in each alternative, rather than a list of capabilities, 430 since no more than a single connection data field is permitted per 431 media block. Nevertheless, it is still allowed to express 432 alternative potential connection configurations separated by a 433 vertical bar ("|"). 435 The connection data parameter to the actual configuration attribute 436 ('a=acfg') is formulated as a with 438 ext-cap-name = "c" 440 hence 442 sel-extension-config =/ sel-connection-config 443 sel-connection-config = "c=" conn-cap-num ; as defined above. 445 Figure 7: Syntax of the connection data parameter in 'acfg' 446 attributes 448 3.1.2.2. Option tag 450 The SDP Capability Negotiation Framework [RFC5939] solution allows 451 for capability negotiation extensions to be defined. Associated with 452 each such extension is an option tag that identifies the extension in 453 question. Hereby, we define a new option tag of "ccap-v0" that 454 identifies support for the connection data capability. This option 455 tag SHOULD be added to other existing option tags present in the 456 'csup' and 'creq' attributes in SDP, according to the procedures 457 defined in the SDP Capability Negotiation Framework [RFC5939]. 459 3.1.3. Title Capability 461 SDP [RFC4566] provides for the existence of an information field 462 expressed in the format of the 'i=' line, which can appear either at 463 the session level or at the media level. An 'i=' line that is 464 present at the session level is known as the "session name", and its 465 purpose is to convey a human-readable textual information about the 466 session. 468 The 'i=' line in SDP can also appear at the media level, in which 469 case it is used to provide human-readable information about the media 470 stream to which it is related, e.g., it may indicate the purpose of 471 the media stream. The 'i=' line is not to be confused with the label 472 attribute ('a=label:', [RFC4574]) which provides a machine-readable 473 tag. It is foreseen that applications declaring capabilities related 474 to different configurations of a media stream may need to provide 475 different identifying information for each of those configurations. 476 That is, a party might offer alternative media configurations for a 477 stream, each of which represents a different presentation of the same 478 or similar information. For example, an audio stream might offer 479 English or Spanish configurations, or a video stream might offer a 480 choice of video source such as speaker camera, group camera, or 481 document viewer. The title capability is needed to inform the 482 answering user in order to select the proper choice, and the label is 483 used to inform the offering machine which choice the answerer has 484 selected. Hence, there is value in defining a mechanism to provide 485 titles of media streams as capabilities. 487 According to SDP [RFC4566], the session information ('i=') line has 488 the following syntax: 490 "i=" text 492 where "text" represents a human-readable text indicating the purpose 493 of the session or media stream. 495 In this document we define a new capability attribute: the Title 496 capability 'icap'. This attribute lists session or media titles as 497 capabilities, according to the following definition: 499 "a=icap:" title-cap-num 1*WSP text 501 where is a unique integer between 1 and 2^31-1 (both 502 included) user to number the unique ordinal identifier of the 503 particular title capability and is a human-readable text that 504 indicates the purpose of the session or media stream it is supposed 505 to characterize. 507 As an example, one might use: 509 a=icap:1 Document Camera 511 to define a title capability number 1 to identify a particular source 512 of a media stream. 514 The title capability attribute satisfies the general attribute 515 production rules in SDP [RFC4566] according to the following 516 Augmented Backus-Naur Form (ABNF) [RFC5234] syntax: 518 att-field =/ "icap" 519 att-value =/ title-cap-num 1*WSP text 520 ; text defined in RFC 4566 521 title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 523 Figure 8: Syntax of the icap attribute 525 3.1.3.1. Configuration Parameters 527 The SDP Capability Negotiation Framework [RFC5939] provides for the 528 existence of the 'pcfg' and 'acfg' attributes. The concept is 529 extended by the SDP media capabilities negotiation 530 [I-D.ietf-mmusic-sdp-media-capabilities] with an 'lcfg' attribute 531 that conveys latent configurations. 533 In this document, we define an parameter to be 534 used to convey title capabilities in a potential or latent 535 configuration. This parameter is defined as an with the following associations: 538 ext-cap-name = "i" 540 ext-cap-list = title-cap-list 542 This leads to the following definition for the title capability 543 parameter: 545 extension-config-list =/ title-config-list 546 title-config-list = ["+"] "i=" title-cap-list 547 title-cap-list = title-cap-num *(BAR title-cap-num) 548 ; BAR defined in RFC 5939 549 title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 551 Figure 9: Syntax of the title capability parameter in 'lcfg' and 552 'pcfg' attributes 554 Each potential capability configuration contains a single title 555 capability attribute number where 'title-cap-num' is the title 556 capability number defined explicitly earlier in this document, and 557 hence must be between 1 and 2^31-1 (both included). The title 558 capability allows the expression of only a single capability in each 559 alternative, since no more than a single title field is permitted per 560 block. Nevertheless, it is still allowed to express alternative 561 potential title configurations separated by a vertical bar ("|"). 563 An endpoint includes a plus sign ("+") in this configuration 564 attribute to mandate support for this extension. An endpoint that 565 receives this attribute prefixed with a plus sign and does not 566 support this extension MUST treat that potential configuration as not 567 valid. 569 The title parameter to the actual configuration attribute ('a=acfg') 570 is formulated as a with 572 ext-cap-name = "i" 574 hence 576 sel-extension-config =/ sel-title-config 577 sel-title-config = "i=" title-cap-num ; as defined above. 579 Figure 10: Syntax of the title parameter in 'acfg' attributes 581 3.1.3.2. Option Tag 583 At present, it is difficult to envision a scenario in which the 584 'icap' attribute must be supported or the offer must be rejected. In 585 most cases, if the icap attribute or its contents were to be ignored, 586 an offered configuration could still be chosen based on other 587 criteria such as configuration numbering. However, one might imagine 588 an SDP offer that contained English and Spanish potential 589 configurations for an audio stream. The session might be 590 unintelligible if the choice is based on configuration numbering, 591 rather than informed user selection. Based on such considerations, 592 it may well prove useful to announce the ability to use the icap 593 attribute and its contents to select media configurations, or to 594 inform the user about the selected configuration(s). Therefore, we 595 define a new option tag of "icap-v0" that identifies support for the 596 title capability. This option tag SHOULD be added to other existing 597 option tags present in the 'csup' and/or 'creq' attributes in SDP, 598 according to the procedures defined in the SDP Capability Negotiation 599 Framework [RFC5939]. The discussion above suggests that "icap-v0" 600 will typically appear in a 'csup' attribute, but rarely in a 'creq' 601 attribute. 603 3.2. Session Level versus Media Level 605 The 'bcap', 'ccap' and 'icap' attributes can appear at the session 606 level and/or at the media level. Endpoints MUST interpret 607 capabilities declared at session level as part of the session level 608 in the resulting SDP for that particular configuration. Endpoints 609 MUST interpret capabilities declared at media level as part of the 610 media level in the resulting SDP for that particular configuration. 612 If a 'bcap' capability for the same bwtype is declared at both 613 session and media level, the media level attribute overrides the 614 value of the session level attribute. 616 To avoid confusion, the for each 'a=bcap', 'a=ccap', 617 and 'a=icap' line must be unique across all capability attributes of 618 the same type within the entire session description. 620 3.3. Offer/Answer model extensions 622 In this section, we define extensions to the offer/answer model 623 defined in SDP Offer/Answer Model [RFC3264] and extended in the SDP 624 Capability Negotiation [RFC5939] to allow for bandwidth and title 625 capabilities to be used with the SDP Capability Negotiation 626 framework. 628 3.3.1. Generating the Initial Offer 630 When an endpoint generates an initial offer and wants to use the 631 functionality described in the current document, it first defines 632 appropriate values for the bandwidth, connection data, and/or title 633 capability attributes according to rules defined in [RFC4566] for 634 'b=', 'c=' and 'i=' lines. The endpoint then MUST include the 635 respective capability attributes and associated values in the SDP 636 offer. The preferred configurations for each media stream are 637 identified following the media line in a 'pcfg' attribute. Bandwidth 638 and title capabilities may also be referenced in latent 639 configurations in an 'lcfg' attribute, defined in [RFC5939]. 641 The offer SHOULD include the level of capability negotiation 642 extensions needed to support this functionality in a 'creq' 643 attribute. 645 3.3.2. Generating the Answer 647 When the answering party receives the offer, and if it supports the 648 required capability negotiation extensions, it SHOULD select the most 649 preferred configuration it can support for each media stream, and 650 build the answer accordingly, as defined in Section 3.6.2 of the SDP 651 Capability Negotiation [RFC5939]. 653 3.3.3. Offerer Processing of the Answer 655 When the offerer receives the answer, it MUST process the media lines 656 according to normal SDP processing rules to identify the media 657 stream(s) accepted by the answer, if any. The 'acfg' attribute, if 658 present, may be used to verify the proposed configuration used to 659 form the answer, and to infer the lack of acceptability of higher- 660 preference configurations that were not chosen. 662 3.3.4. Modifying the Session 664 If, at a later time, one of the parties wishes to modify the 665 operating parameters of a session, e.g. by adding a new media stream, 666 or by changing the properties used on an existing stream, it may do 667 so via the mechanisms defined for SDP offer/answer [RFC3264]. 669 4. Field Replacement Rules 671 To simplify the construction of SDP records, given the need to 672 include fields within the media description in question for endpoints 673 that do not support capabilities negotiation, we define some simple 674 field-replacement rules for those fields invoked by potential or 675 latent configurations. In particular, any 'i=' or 'c=' line invoked 676 by a configuration MUST replace the corresponding line, if present 677 within the media description in question. Any 'b=' line invoked by a 678 configuration MUST replace any 'b=' of the same bandwidth type at the 679 media level. 681 5. IANA Considerations 683 5.1. New SDP Attributes 685 IANA is hereby requested to register new attributes in the "att-field 686 (both session and media level)" of the "Session Description Protocol 687 (SDP) Parameteres" registry, according to the following registration 688 form: 690 Attribute name: bcap 691 Long form name: Bandwidth Capability 692 Type of attribute: Both media and session level 693 Subject to charset: No 694 Purpose: Negotiate session or media-level bandwidths 695 Appropriate values: See RFC XXXX 696 [Note to the RFC Editor: Please replace the above RFC XXXX 697 with the RFC number of this specification. 698 Contact name: Miguel A. Garcia, 699 Miguel.A.Garcia@ericsson.com 701 Attribute name: ccap 702 Long form name: Connection Data Capability 703 Type of attribute: Both media and session level 704 Subject to charset: No 705 Purpose: Negotiate media-level connection data 706 Appropriate values: See RFC XXXX 707 [Note to the RFC Editor: Please replace the above RFC XXXX 708 with the RFC number of this specification. 709 Contact name: Miguel A. Garcia, 710 Miguel.A.Garcia@ericsson.com 712 Attribute name: icap 713 Long form name: Title Capability 714 Type of attribute: Both media and session level 715 Subject to charset: Yes 716 Purpose: Negotiate human-readable information 717 describing the session or media 718 Appropriate values: See RFC XXXX 719 [Note to the RFC Editor: Please replace the above RFC XXXX 720 with the RFC number of this specification. 721 Contact name: Miguel A. Garcia, 722 Miguel.A.Garcia@ericsson.com 724 5.2. New Option Tags 726 IANA is hereby requested to add the new option tags "bcap-v0", 727 "ccap-v0", and "icap-v0", defined herein, to the "SDP Capability 728 Negotiation Option Tag subregistry" of the "Session Description 729 Protocol (SDP) Parameters" registry. 731 5.3. New SDP Capability Negotiation Configuration Parameters 733 IANA is hereby requested to add the new parameter identifiers "b" for 734 "bandwidth", "c" for "connection data", and "i" for "title" to the 735 "SDP Capability Negotiation Potential Configuration Parameters" 736 subregistry of the "Session Description Protocol (SDP) Parameters" 737 registry. These parameters are permitted in 'lcfg', 'acfg', and 738 'pcfg' attributes. 740 6. Security Considerations 742 This document provides an extension on top of RFC 4566 [RFC4566], RFC 743 3264 [RFC3264], SDP Capability Negotiation Framework [RFC5939], and 744 SDP media capabilities negotiation 745 [I-D.ietf-mmusic-sdp-media-capabilities]. As such, the security 746 considerations of those documents apply. 748 The bandwidth capability attribute may be used for reserving 749 resources at endpoints and intermediaries which inspect the SDP. 750 Modification of the bandwidth value by an attacker can lead to the 751 network being underutilized (too high bandwidth value) or congested 752 (too low bandwidth value). In case it is essential to protect the 753 bandwidth value, one of the security mechanisms proposed in [RFC5939] 754 should be used. 756 The 'i=' line and thus the value carried in the title capability 757 attribute is intended for human-readable description only. It should 758 not be parsed programmatically. 760 7. Acknowledgments 762 Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson 763 for arguing for the existence of this document and early reviewing 764 it. Thanks to Flemming Andreasen, Andrew Allen, and Jonathan Lennox 765 for a detailed review and many improvement suggestions. 767 8. References 769 8.1. Normative References 771 [I-D.ietf-mmusic-sdp-media-capabilities] 772 Gilman, R., Even, R., and F. Andreasen, "SDP Media 773 Mapabilities Negotiation", 774 draft-ietf-mmusic-sdp-media-capabilities-12 (work in 775 progress), October 2011. 777 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 778 Requirement Levels", BCP 14, RFC 2119, March 1997. 780 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 781 with Session Description Protocol (SDP)", RFC 3264, 782 June 2002. 784 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 785 Description Protocol", RFC 4566, July 2006. 787 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 788 Specifications: ABNF", STD 68, RFC 5234, January 2008. 790 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 791 Capability Negotiation", RFC 5939, September 2010. 793 8.2. Informative References 795 [I-D.ietf-mmusic-sdp-cs] 796 Garcia, M. and S. Veikkolainen, "Session Description 797 Protocol (SDP) Extension For Setting Up Audio and Video 798 Media Streams Over Circuit-Switched Bearers In The Public 799 Switched Telephone Network (PSTN)", 800 draft-ietf-mmusic-sdp-cs-09 (work in progress), 801 October 2011. 803 [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the 804 Session Description Protocol (SDP) for ATM Bearer 805 Connections", RFC 3108, May 2001. 807 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 808 Jacobson, "RTP: A Transport Protocol for Real-Time 809 Applications", STD 64, RFC 3550, July 2003. 811 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 812 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 813 RFC 3711, March 2004. 815 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 816 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 818 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 819 (ICE): A Protocol for Network Address Translator (NAT) 820 Traversal for Offer/Answer Protocols", RFC 5245, 821 April 2010. 823 Authors' Addresses 825 Miguel A. Garcia-Martin 826 Ericsson 827 Calle Via de los Poblados 13 828 Madrid, 28033 829 Spain 831 Phone: +34 91 339 1000 832 Email: miguel.a.garcia@ericsson.com 834 Simo Veikkolainen 835 Nokia 836 P.O. Box 407 837 NOKIA GROUP, FI 00045 838 Finland 840 Phone: +358 50 486 4463 841 Email: simo.veikkolainen@nokia.com 843 Robert R. Gilman 844 3243 W. 11th Ave. Dr. 845 Broomfield, Colorado 80020 846 U.S.A. 848 Phone: +1 303 898 9780 849 Email: bob_gilman@comcast.net