idnits 2.17.1 draft-ietf-mmusic-sdp-miscellaneous-caps-07.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 date (July 10, 2013) is 3936 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-23) exists of draft-ietf-mmusic-sdp-cs-21 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 2 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 11, 2014 Nokia 6 R. Gilman 8 July 10, 2013 10 Miscellaneous Capabilities Negotiation in the Session Description 11 Protocol (SDP) 12 draft-ietf-mmusic-sdp-miscellaneous-caps-07 14 Abstract 16 SDP has been extended with a capability negotiation mechanism 17 framework that allows the endpoints to negotiate transport protocols 18 and attributes. This framework has been extended with a media 19 capabilities negotiation mechanism that allows endpoints to negotiate 20 additional media-related capabilities. This negotiation is embedded 21 into the widely-used SDP offer/answer procedures. 23 This memo extends the SDP capability negotiation framework to allow 24 endpoints to negotiate three additional SDP capabilities. In 25 particular, this memo provides a mechanism to negotiate bandwidth 26 ('b=' line), connection data ('c=' line), and session or media titles 27 ('i=' line for each session or media). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 11, 2014. 46 Copyright Notice 47 Copyright (c) 2013 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 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 64 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 3 66 3.1.1. Bandwidth Capability . . . . . . . . . . . . . . . . 5 67 3.1.2. Connection Data Capability . . . . . . . . . . . . . 8 68 3.1.3. Title Capability . . . . . . . . . . . . . . . . . . 12 69 3.2. Session Level versus Media Level . . . . . . . . . . . . 16 70 3.3. Offer/Answer model extensions . . . . . . . . . . . . . . 16 71 3.3.1. Generating the Initial Offer . . . . . . . . . . . . 16 72 3.3.2. Generating the Answer . . . . . . . . . . . . . . . . 17 73 3.3.3. Offerer Processing of the Answer . . . . . . . . . . 17 74 3.3.4. Modifying the Session . . . . . . . . . . . . . . . . 17 75 4. Field Replacement Rules . . . . . . . . . . . . . . . . . . . 17 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 6.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19 79 6.2. New Option Tags . . . . . . . . . . . . . . . . . . . . . 19 80 6.3. New SDP Capability Negotiation Configuration Parameters 20 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 84 8.2. Informative References . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 SDP Capability 93 Negotiation Mechanism Framework [RFC5939] which allows the endpoints 94 to negotiate capabilities, such as support for Real-time Transport 95 Protocol (RTP) [RFC3550] and Secure Real-time Transport Protocol 96 (SRTP) [RFC3711]. The SDP Media Capabilities Negotiation [RFC6871] 97 provides negotiation capabilities to media lines as well. 99 The capability negotiation is embedded into the widely used SDP offer 100 /answer procedure [RFC3264]. This memo provides the means to 101 negotiate further capabilities than those specified in the SDP 102 Capability Negotiation Mechanism Framework [RFC5939] and the SDP 103 Media Capabilities Negotiation [RFC6871]. In particular, this memo 104 provides a mechanism to negotiate bandwidth ('b='), connection data 105 ('c='), and session or media titles ('i='). 107 Since the three added capabilities are independent, it is not 108 expected that implementations will necessarily support all of them at 109 the same time. Instead, it is expected that applications will choose 110 their needed capability for their specific purpose. Due to this, we 111 are writing the normative part pertaining to each capability in a 112 self-contained section: Section 3.1.1 describes the bandwidth 113 capability extension, Section 3.1.2 describes the connection data 114 capability extension, and Section 3.1.3 describes the title 115 capability extension. Separate SDP capability negotiation option 116 tags are defined for each capability, allowing endpoints to indicate 117 and/or require support for these extensions according to procedures 118 defined in SDP Capability Negotiation [RFC5939]. 120 2. Conventions Used in This Document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in BCP 14, RFC 2119 125 [RFC2119] and indicate requirement levels for compliant 126 implementations. 128 3. Protocol Description 130 3.1. Extensions to SDP 132 The SDP Capability Negotiation Framework [RFC5939] and the SDP Media 133 Capabilities Negotiation [RFC6871] specify attributes for negotiating 134 SDP capabilities. These documents specify new attributes (e.g., 135 'acap', 'tcap', 'rmcap', 'omcap') for achieving their purpose. In 136 this document we define three new additional capability attributes 137 for SDP lines of the general form: 139 type=value 141 for types 'b', 'c', and 'i'. The corresponding capability attributes 142 are respectively defined as: 144 o 'bcap': bandwidth capability 146 o 'ccap': connection data capability 148 o 'icap': title capability 150 From the sub-rules of attribute ('a=') line in SDP [RFC4566], SDP 151 attributes are of the form: 153 attribute = (att-field ":" att-value) / att-field 154 att-field = token 155 att-value = byte-string 157 Capability attributes use only the 'att-field:att-value' form. 159 The new capabilities may be referenced in potential configurations 160 ('a=pcfg') or in latent configurations ('a=lcfg'), as productions 161 conforming to the as respectively defined in 162 RFC 5939 [RFC5939] and RFC6871 [RFC6871]. 164 extension-config-list = ["+"] ext-cap-name "=" ext-cap-list 165 ext-cap-name = 1*(ALPHA / DIGIT) 166 ; ALPHA and DIGIT defined in RFC 5234 167 ext-cap-list = 1*VCHAR ; VCHAR defined in RFC 5234 169 The optional "+" is used to indicate that the extension is mandatory 170 and MUST be supported in order to use that particular configuration. 172 The new capabilities may also be referenced in actual configurations 173 ('a=acfg') as productions conforming to the 174 defined in RFC 5939 [RFC5939]. 176 sel-extension-config = ext-cap-name "=" 1*VCHAR 178 The specific parameters are defined in the individual description of 179 each capability, below. 181 The 'bcap', 'ccap', and 'icap' capability attributes can be provided 182 at the SDP session and/or media level. According to the SDP 183 Capability Negotiation [RFC5939], each extension capability must 184 specify the implication of making it part of a configuration at the 185 media level. 187 According to SDP [RFC4566], 'b=', 'c=', and 'i=' lines may appear 188 either at session or media level. In line with this, the 'bcap', 189 'ccap', and 'icap' capability attributes, when declared at session 190 level, are to be interpreted as-if that attribute was provided with 191 that value at the session level. The 'bcap', 'ccap' and 'icap' 192 capability attributes declared at media level, are to be interpreted 193 as-if that capability attribute was declared at the media level. 195 For example, extending the example in [RFC6871] with 'icap' and 196 'bcap' capability attributes, we get the following SDP: 198 v=0 199 o=- 25678 753849 IN IP4 192.0.2.1 200 s= 201 c=IN IP4 192.0.2.1 202 t=0 0 203 a=bcap:1 CT:200 204 a=icap:1 Video conference 205 m=audio 54320 RTP/AVP 0 206 a=rmcap:1 L16/8000/1 207 a=rmcap:2 L16/16000/2 208 a=pcfg:1 m=1|2 pt=1:99,2:98 209 m=video 66544 RTP/AVP 100 210 a=rmcap:3 H263-1998/90000 211 a=rtpmap:100 H264/90000 212 a=pcfg:10 m=3 pt=3:101 b=1 i=1 214 Figure 1: Example SDP offer with bcap and icap defined at session 215 level 217 The above SDP defines one PCMU audio stream and one H.264 video 218 stream. It also defines two RTP-based media capabilities ('rmcap' 219 numbered 1 and 2), using L16 audio at 8 kbps and 16 kbps, 220 respectively, as well as an RTP-based media capability for H.263 221 video ('rmcap' numbered 3). The RTP-based media capabilities all 222 appear at the media level. The example also contains a single 223 bandwidth capability ('bcap') and a single title capability ('icap'), 224 both defined at session level. According to the definition above, 225 when the capabilities defined in the 'bcap' and 'icap' attributes are 226 referenced from the potential configuration, in the resulting SDP 227 they are to be interpreted as session level attributes (but the RTP- 228 based media capabilities are to be interpreted as media level 229 attributes). 231 3.1.1. Bandwidth Capability 232 According to RFC 4566 [RFC4566] the bandwidth field denotes the 233 proposed bandwidth to be used by the session or media. In this memo 234 we specify the bandwidth capability attribute which can also appear 235 at the SDP session and/or media level. The bandwidth field is 236 specified in RFC 4566 [RFC4566] with the following syntax: 238 b=: 240 where is an alphanumeric modifier giving the meaning of the 241 figure. 243 In this document, we define a new capability attribute: the Bandwidth 244 capability attribute 'bcap'. This attribute lists bandwidth as 245 capabilities according to the following definition: 247 "a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF 249 where is a unique integer within all the bandwidth 250 capabilities in the entire SDP, which is used to number the bandwidth 251 capability, and can take a value between 1 and 2^31-1 (both 252 included). The other elements are as defined for the 'b=' field in 253 SDP [RFC4566]. 255 This format satisfies the general attribute production rules in SDP 256 [RFC4566] according to the following Augmented Backus-Naur Form 257 (ABNF) [RFC5234] syntax: 259 att-field =/ "bcap" 260 att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth 261 bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 263 Figure 2: Syntax of the bcap attribute 265 Negotiation of bandwidth per media stream can be useful when 266 negotiating media encoding capabilities with different bandwidths. 268 3.1.1.1. Configuration Parameters 270 The SDP Capability Negotiation Framework [RFC5939] provides for the 271 existence of the 'pcfg' and 'acfg' attributes. The concept is 272 extended by the SDP Media Capabilities Negotiation [RFC6871] with an 273 'lcfg' attribute that conveys latent configurations. 275 Extensions to the 'pcfg' and 'lcfg' attributes are defined through 276 , and extensions to the 'acfg' attribute are 277 defined through the as defined in the SDP 278 Capability Negotiation [RFC5939]. 280 In this document we extend the field to be 281 able to convey lists of bandwidth capabilities in latent or potential 282 configurations, according to the following Augmented Backus-Naur Form 283 (ABNF) [RFC5234] syntax: 285 extension-config-list =/ bandwidth-config-list 286 bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR bw-cap-list) 287 ; BAR defined in RFC 5939 288 bw-cap-list = bw-cap-num *("," bw-cap-num) 289 bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 291 Figure 3: Syntax of the bandwidth parameter in 'lcfg' and 'pcfg' 292 attributes 294 Each bandwidth capability configuration is a comma-separated list of 295 bandwidth capability attribute numbers where refers to 296 the bandwidth capability numbers defined explicitly 297 earlier in this document, and hence MUST be between 1 and 2^31-1 298 (both included). Alternative bandwidth configurations are separated 299 by a vertical bar ("|"). 301 The above syntax is very flexible, allowing referencing to multiple 302 'b=' lines per configuration, even for the same . While the 303 need for such definitions is not seen, we have not restricted this, 304 as it is not restricted in SDP [RFC4566] either. 306 The bandwidth parameter to the actual configuration attribute 307 ('a=acfg') is formulated as a with 309 ext-cap-name = "b" 311 hence 313 sel-extension-config =/ sel-bandwidth-config 314 sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above. 316 Figure 4: Syntax of the bandwidth parameter in 'acfg' attributes 318 3.1.1.2. Option tag 319 The SDP Capability Negotiation Framework [RFC5939] allows for 320 capability negotiation extensions to be defined. Associated with 321 each such extension is an option tag that identifies the extension in 322 question. Hereby, we define a new option tag "bcap-v0" that 323 identifies support for the bandwidth capability. The endpoints using 324 the 'bcap' capability attribute SHOULD add the option tag to other 325 existing option tags present in the 'csup' and 'creq' attributes in 326 SDP, according to the procedures defined in the SDP Capability 327 Negotiation Framework [RFC5939]. 329 3.1.2. Connection Data Capability 331 According to SDP [RFC4566], the connection data field in SDP contains 332 the connection data, and it has the following syntax: 334 c= 336 where indicates the network type, indicates the 337 address type, and the is the connection address, 338 which is dependent on the address type. 340 At the moment, network types already defined include "IN", which 341 indicates Internet network type, and "ATM" (see RFC 3108 [RFC3108]), 342 used for describing Asynchronous Transfer Mode (ATM) bearer 343 connections. The Circuit-Switched (CS) descriptions in SDP document 344 [I-D.ietf-mmusic-sdp-cs] adds a "PSTN" network type for expressing a 345 Public Switched Telephone Network (PSTN) circuit switch. 347 SDP [RFC4566] permits specification of connection data at the SDP 348 session and/or media level. In order to permit negotiation of 349 connection data at the media level, we define the connection data 350 capability attribute ('a=ccap') in the form: 352 "a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP connection- 353 address CRLF 355 where is a unique integer within all the connection 356 capabilities in the entire SDP, which is used to identify the 357 connection data capability, and can take a value between 1 and 2^31-1 358 (both included). The other elements are as defined in [RFC4566]. 360 This format corresponds to the [RFC4566] attribute production rules 361 according to the following Augmented Backus-Naur Form (ABNF) 362 [RFC5234] syntax: 364 att-field =/ "ccap" 365 att-value =/ conn-cap-num 1*WSP nettype SP addrtype 366 SP connection-address 368 conn-cap-num = 1*10(DIGIT) ; 1 to 2^31-1, inclusive 369 ; DIGIT defined in RFC 5234 371 Figure 5: Syntax of the ccap attribute 373 The 'ccap' capability attribute allows for expressing alternative 374 connections address ("c=") lines in SDP as part of the SDP capability 375 negotiation process. One of the primary use cases for this is 376 offering alternative connection addresses where the is "IN" 377 or "PSTN", i.e. selecting between IP based bearer or a circuit- 378 switched bearer. 380 By supporting the "IN" , the 'ccap' attribute enables the 381 signaling of multiple IPv4 and IPv6 addresses, however the Standards 382 Track mechanism for negotiation of alternative IP addresses in SDP is 383 Interactive Connectivity Establishment (ICE) [RFC5245]. The 'ccap' 384 attribute does not change that and hence the combined set of actual 385 and potential configurations (as defined in [RFC5939]) for any given 386 media description MUST NOT use the 'ccap' attribute to negotiate more 387 than one address with an IN network type (i.e., it is not permissible 388 to select between "IP4" and "IP6" address families or different IP 389 addresses within the same IP address family. 391 Figure 6 is an example of an SDP offer that includes a 'ccap' 392 capability attribute. An audio stream can be setup with an RTP flow 393 or establishing a circuit-switched audio stream: 395 v=0 396 o=2987933123 2987933123 IN IP4 198.51.100.7 397 s=- 398 t=0 0 399 a=creq:med-v0,ccap-v0 400 m=audio 38902 RTP/AVP 0 8 401 c=IN IP4 198.51.100.7 402 a=ccap:1 PSTN E164 +15555556666 403 a=tcap:2 PSTN 404 a=omcap:1 - 405 a=acap:1 setup:actpass 406 a=acap:2 connection:new 407 a=acap:3 cs-correlation:callerid:+15555556666 408 a=pcfg:1 c=1 t=2 m=1 a=1,2,3 410 Figure 6: Example SDP offer with a ccap attribute 412 The example in Figure 6 represents an SDP offer indicating an audio 413 flow using RTP, such as the one represented in Figure 7 or an audio 414 flow using a circuit-switched connection, such as the one represented 415 in Figure 8. 417 v=0 418 o=2987933123 2987933123 IN IP4 198.51.100.7 419 s=- 420 t=0 0 421 m=audio 38902 RTP/AVP 0 8 422 c=IN IP4 198.51.100.7 424 Figure 7: Equivalent SDP offer with the RTP flow 426 v=0 427 o=2987933123 2987933123 IN IP4 198.51.100.7 428 s=- 429 t=0 0 430 m=audio 9 PSTN - 431 c=PSTN E164 +15555556666 432 a=setup:actpass 433 a=connection:new 434 a=cs-correlation:callerid:+15555556666 436 Figure 8: Equivalent SDP offer with the circuit-switched flow 438 This document does not define any mechanism for negotiating or 439 describing different port numbers and hence the port number from the 440 "m=" line MUST be used by default. Exceptions to this default can be 441 provided by extension mechanisms or network type specific rules. 442 This draft defines an exception when the network type is "PSTN", in 443 which case the port number is replaced with 9 (the "discard" port) as 444 described in Session Decription Protocol (SDP) Extension For Setting 445 Up Audio and Video Media Streams over Circuit-Switched Bearers in the 446 Public Switched Telephone Network (PSTN) [I-D.ietf-mmusic-sdp-cs]. 447 An endpoint offering alternative IP and PSTN bearers MUST include the 448 IP media description in the actual configuration (IP address in the 449 "c=" line and port number in the "m=" line), and the PSTN media 450 description in the potential configuration. 452 Exceptions for other network types, such as for the "ATM" network 453 type defined in [RFC3108], require additional specifications. 455 3.1.2.1. Configuration Parameters 457 The SDP Capability Negotiation Framework [RFC5939] provides for the 458 existence of the 'pcfg' and 'acfg' attributes, which can convey one 459 or more configurations to be negotiated. The concept is extended by 460 the SDP Media Capabilities Negotiation [RFC6871] with an 'lcfg' 461 attribute that conveys latent configurations. 463 In this document we define a parameter to be used 464 to specify a connection data capability in a potential or latent 465 configuration attribute. The parameter follows the form of an 466 , with 468 ext-cap-name = "c" 470 ext-cap-list = conn-cap-list 472 where, according to the following Augmented Backus-Naur Form (ABNF) 473 [RFC5234] syntax: 475 extension-config-list =/ conn-config-list 476 conn-config-list = ["+"] "c=" conn-cap-list 477 conn-cap-list = conn-cap-num *(BAR conn-cap-num) 478 conn-cap-num = 1*10(DIGIT) ; 1 to 2^32-1 inclusive 480 Figure 9: Syntax of the connection data parameter in 'lcfg' and 481 'pcfg' attributes 483 Each capability configuration alternative contains a single 484 connection data capability attribute number and refers to the conn- 485 cap-num capability number defined explicitly earlier in this 486 document, and hence MUST be between 1 and 2^31-1 (both included). 487 The connection data capability allows the expression of only a single 488 capability in each alternative, rather than a list of capabilities, 489 since no more than a single connection data field is permitted per 490 media block. Nevertheless, it is still allowed to express 491 alternative potential connection configurations separated by a 492 vertical bar ("|"). 494 An endpoint includes a plus sign ("+") in the configuration attribute 495 to mandate support for this extension. An endpoint that receives 496 this parameter prefixed with a plus sign and does not support this 497 extension MUST treat that potential configuration as not valid. 499 The connection data parameter to the actual configuration attribute 500 ('a=acfg') is formulated as a with 502 ext-cap-name = "c" 504 hence 506 sel-extension-config =/ sel-connection-config 507 sel-connection-config = "c=" conn-cap-num ; as defined above. 509 Figure 10: Syntax of the connection data parameter in 'acfg' 510 attributes 512 3.1.2.2. Option tag 514 The SDP Capability Negotiation Framework [RFC5939] solution allows 515 for capability negotiation extensions to be defined. Associated with 516 each such extension is an option tag that identifies the extension in 517 question. Hereby, we define a new option tag of "ccap-v0" that 518 identifies support for the connection data capability. This option 519 tag SHOULD be added to other existing option tags present in the 520 'csup' and 'creq' attributes in SDP, according to the procedures 521 defined in the SDP Capability Negotiation Framework [RFC5939]. 523 3.1.3. Title Capability 525 SDP [RFC4566] provides for the existence of an information field 526 expressed in the format of the 'i=' line, which can appear at the SDP 527 session and/or media level. An 'i=' line that is present at the 528 session level is known as the "session name", and its purpose is to 529 convey human-readable textual information about the session. 531 The 'i=' line in SDP can also appear at the media level, in which 532 case it is used to provide human-readable information about the media 533 stream to which it is related, e.g., it may indicate the purpose of 534 the media stream. The 'i=' line is not to be confused with the label 535 attribute ('a=label:', [RFC4574]) which provides a machine-readable 536 tag. It is foreseen that applications declaring capabilities related 537 to different configurations of a media stream may need to provide 538 different identifying information for each of those configurations. 539 That is, a party might offer alternative media configurations for a 540 stream, each of which represents a different presentation of the same 541 or similar information. For example, an audio stream might offer 542 English or Spanish configurations, or a video stream might offer a 543 choice of video source such as speaker camera, group camera, or 544 document viewer. The title capability is needed to inform the 545 answering user in order to select the proper choice, and the label is 546 used to inform the offering machine which choice the answerer has 547 selected. Hence, there is value in defining a mechanism to provide 548 titles of media streams as capabilities. 550 As defined in SDP [RFC4566], the session information field ("i=", 551 referred to as "title" in this document) is subject to the 552 "a=charset" attribute in order to support different character sets 553 and hence internationalization. The title capability attribute 554 itself ("a=icap") is however not subject to the "a=charset" attribute 555 as this would preclude the inclusion of alternative session/title 556 information each using different character sets. Instead, the 557 session/title value embedded in an "a=icap" attribute (title 558 capability) will be subject to the "a=charset" value used within a 559 configuration that includes that title capability. This provides for 560 consistent SDP operation while allowing for capabilities and 561 configurations with different session/title information values with 562 different character set encodings (with each such configuration 563 including an "a=charset" value with the relevant character set for 564 the session/title information in question). 566 According to SDP [RFC4566], the session information ('i=') line has 567 the following syntax: 569 "i=" text 571 where "text" represents a human-readable text indicating the purpose 572 of the session or media stream. 574 In this document we define a new capability attribute: the Title 575 capability 'icap'. This attribute lists session or media titles as 576 capabilities, according to the following definition: 578 "a=icap:" title-cap-num 1*WSP text 580 where is a unique integer within all the connection 581 capabilities in the entire SDP, which is used to identify the 582 particular title capability, and can take a value between 1 and 583 2^31-1 (both included). is a human-readable text that 584 indicates the purpose of the session or media stream it is supposed 585 to characterize. 587 As an example, one might use: 589 a=icap:1 Document Camera 591 to define a title capability number 1 to identify a particular source 592 of a media stream. 594 Or in another example, one might offer two title capabilities with 595 different character encodings (using the charset attribute defined in 596 SDP: Session Description Protocol [RFC4566] and the generic attribute 597 capability attribute ("a=acap:") defined in SDP Capability 598 Negotiation [RFC5939]. 600 a=icap:1 [Text encoded in ISO-8859-1] 601 a=acap:1 charset:ISO-8859-1 602 a=icap:2 [Text encoded in UTF-8] 603 a=acap:2 charset:UTF-8 605 NOTE: Due to limitations of the ASCII encoding of RFCs, the actual 606 text with non-printable characters cannot be represented in the text 607 version, but might be represented in other versions of this RFC. 609 The title capability attribute satisfies the general attribute 610 production rules in SDP [RFC4566] according to the following 611 Augmented Backus-Naur Form (ABNF) [RFC5234] syntax: 613 att-field =/ "icap" 614 att-value =/ title-cap-num 1*WSP text 615 ; text defined in RFC 4566 616 title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 618 Figure 11: Syntax of the icap attribute 620 3.1.3.1. Configuration Parameters 622 The SDP Capability Negotiation Framework [RFC5939] provides for the 623 existence of the 'pcfg' and 'acfg' attributes. The concept is 624 extended by the SDP Media Capabilities Negotiation [RFC6871] with an 625 'lcfg' attribute that conveys latent configurations. 627 In this document, we define a parameter to be 628 used to convey title capabilities in a potential or latent 629 configuration. This parameter is defined as an with the following associations: 632 ext-cap-name = "i" 634 ext-cap-list = title-cap-list 636 This leads to the following definition for the title capability 637 parameter: 639 extension-config-list =/ title-config-list 640 title-config-list = ["+"] "i=" title-cap-list 641 title-cap-list = title-cap-num *(BAR title-cap-num) 642 ; BAR defined in RFC 5939 643 title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 645 Figure 12: Syntax of the title capability parameter in 'lcfg' and 646 'pcfg' attributes 648 Each potential capability configuration contains a single title 649 capability attribute number where 'title-cap-num' is the title 650 capability number defined explicitly earlier in this document, and 651 hence must be between 1 and 2^31-1 (both included). The title 652 capability allows the expression of only a single capability in each 653 alternative, since no more than a single title field is permitted per 654 block. Nevertheless, it is still allowed to express alternative 655 potential title configurations separated by a vertical bar ("|"). 657 An endpoint includes a plus sign ("+") in the configuration attribute 658 to mandate support for this extension. An endpoint that receives 659 this parameter prefixed with a plus sign and does not support this 660 extension MUST treat that potential configuration as not valid. 662 The title parameter to the actual configuration attribute ('a=acfg') 663 is formulated as a with 665 ext-cap-name = "i" 667 hence 669 sel-extension-config =/ sel-title-config 670 sel-title-config = "i=" title-cap-num ; as defined above. 672 Figure 13: Syntax of the title parameter in 'acfg' attributes 674 3.1.3.2. Option Tag 676 At present, it is difficult to envision a scenario in which the 677 'icap' attribute must be supported or the offer must be rejected. In 678 most cases, if the icap attribute or its contents were to be ignored, 679 an offered configuration could still be chosen based on other 680 criteria such as configuration numbering. However, one might imagine 681 an SDP offer that contained English and Spanish potential 682 configurations for an audio stream. The session might be 683 unintelligible if the choice is based on configuration numbering, 684 rather than informed user selection. Based on such considerations, 685 it may well prove useful to announce the ability to use the icap 686 attribute and its contents to select media configurations, or to 687 inform the user about the selected configuration(s). Therefore, we 688 define a new option tag of "icap-v0" that identifies support for the 689 title capability. This option tag SHOULD be added to other existing 690 option tags present in the 'csup' and/or 'creq' attributes in SDP, 691 according to the procedures defined in the SDP Capability Negotiation 692 Framework [RFC5939]. The discussion above suggests that "icap-v0" 693 will typically appear in a 'csup' attribute, but rarely in a 'creq' 694 attribute. 696 3.2. Session Level versus Media Level 698 The 'bcap', 'ccap' and 'icap' attributes can appear at the SDP 699 session and/or media level. Endpoints MUST interpret capabilities 700 declared at session level as part of the session level in the 701 resulting SDP for that particular configuration. Endpoints MUST 702 interpret capabilities declared at media description as part of the 703 media level in the resulting SDP for that particular configuration. 705 The presence of the 'bcap' capability for the same at both 706 the session and media level is subject to the same constraints and 707 restrictions specified in RFC 4566 [RFC4566] for the bandwidth 708 attribute "b=". 710 To avoid confusion, the for each 'a=bcap', 'a=ccap', 711 and 'a=icap' line MUST be unique across all capability attributes of 712 the same type within the entire session description. 714 3.3. Offer/Answer model extensions 716 In this section, we define extensions to the offer/answer model 717 defined in SDP Offer/Answer Model [RFC3264] and extended in the SDP 718 Capability Negotiation [RFC5939] to allow for bandwidth, connection, 719 and title capabilities to be used with the SDP Capability Negotiation 720 framework. 722 3.3.1. Generating the Initial Offer 724 When an endpoint generates an initial offer and wants to use the 725 functionality described in the current document, it first defines 726 appropriate values for the bandwidth, connection data, and/or title 727 capability attributes according to the rules defined in [RFC4566] for 728 'b=', 'c=' and 'i=' lines. The endpoint then MUST include the 729 respective capability attributes and associated values in the SDP 730 offer. The preferred configurations for each media stream are 731 identified following the media line in a 'pcfg' attribute. Bandwidth 732 and title capabilities may also be referenced in latent 733 configurations in an 'lcfg' attribute, defined in SDP Media 734 Capabilities Negotiation [RFC6871]. 736 Implementations are advised to pay attention to the port number that 737 is used in the "m=" line. By default, a potential configuration that 738 includes a connection data capability will use the port number from 739 the "m=" line, unless the network type is "PSTN", in which case the 740 default port number used will be 9. 742 The offer SHOULD include the level of capability negotiation 743 extensions needed to support this functionality in a 'creq' 744 attribute. 746 3.3.2. Generating the Answer 748 When the answering party receives the offer, and if it supports the 749 required capability negotiation extensions, it SHOULD select the most 750 preferred configuration it can support for each media stream, and 751 build the answer accordingly, as defined in Section 3.6.2 of the SDP 752 Capability Negotiation [RFC5939]. 754 If the connection data capability is used in a selected potential 755 configuration chosen by the answerer, that offer configuration MUST 756 by default use the port number from the actual offer configuration 757 (i.e. the "m=" line), unless the network type is "PSTN", in which 758 case the default port MUST be assumed to be 9. Extensions may be 759 defined to negotiate the port number explicitly instead. 761 3.3.3. Offerer Processing of the Answer 763 When the offerer receives the answer, it MUST process the media lines 764 according to normal SDP processing rules to identify the media 765 stream(s) accepted by the answer, if any, as defined in Section 3.6.3 766 of the SDP Capability Negotiation [RFC5939]. The 'acfg' attribute, 767 if present, MUST be used to verify the proposed configuration used to 768 form the answer, and to infer the lack of acceptability of higher- 769 preference configurations that were not chosen. 771 3.3.4. Modifying the Session 773 If, at a later time, one of the parties wishes to modify the 774 operating parameters of a session, e.g. by adding a new media stream, 775 or by changing the properties used on an existing stream, it may do 776 so via the mechanisms defined for SDP offer/answer [RFC3264] and in 777 accordance with the procedures defined in Section 3.6.4 of the SDP 778 Capability Negotiation [RFC5939]. 780 4. Field Replacement Rules 781 To simplify the construction of SDP records, given the need to 782 include fields within the media description in question for endpoints 783 that do not support capabilities negotiation, we define some simple 784 field-replacement rules for those fields invoked by potential or 785 latent configurations. In particular, any 'i=' or 'c=' line invoked 786 by a configuration MUST replace the corresponding line, if present 787 within the media description in question. Any 'b=' line invoked by a 788 configuration MUST replace any 'b=' of the same bandwidth type at the 789 media level, but not at the session level. 791 5. Security Considerations 793 This document provides an extension on top of RFC 4566 [RFC4566], RFC 794 3264 [RFC3264], SDP Capability Negotiation Framework [RFC5939], and 795 SDP Media Capabilities Negotiation [RFC6871]. As such, the security 796 considerations of those documents apply. 798 The bandwidth capability attribute may be used for reserving 799 resources at endpoints and intermediaries which inspect the SDP. 800 Modification of the bandwidth value by an attacker can lead to the 801 network being underutilized (too high bandwidth value) or congested 802 (too low bandwidth value). 804 Similarly, by modifying the alternative connection address(es), an 805 attacker would be able direct media streams to a desired endpoint, 806 thus launching a version of the well known voice hammer attack (see 807 Section 18.5.1 of [RFC5245]. 809 The title capability provides for alternative "i=" line information, 810 which is intended for human consumption. However, manipulating the 811 textual information could be misused to provide false information, 812 leading to bad user experience or the person using the service making 813 wrong the choice regarding the available media streams. 815 In case it is essential to protect the capability attribute values, 816 one of the security mechanisms proposed in [RFC5939] SHOULD be used. 818 The 'i=' line and thus the value carried in the title capability 819 attribute is intended for human-readable description only. It should 820 not be parsed programmatically. 822 6. IANA Considerations 823 6.1. New SDP Attributes 825 IANA is hereby requested to register new attributes in the "att-field 826 (both session and media level)" of the "Session Description Protocol 827 (SDP) Parameters" registry, according to the following registration 828 form: 830 Attribute name: bcap 831 Long form name: Bandwidth Capability 832 Type of attribute: Both media and session level 833 Subject to charset: No 834 Purpose: Negotiate session or media-level bandwidths 835 Appropriate values: See RFC XXXX Section 3.1.1 836 [Note to the RFC Editor: Please replace the above RFC XXXX 837 with the RFC number of this specification. 838 Contact name: Miguel A. Garcia, 839 Miguel.A.Garcia@ericsson.com 841 Attribute name: ccap 842 Long form name: Connection Data Capability 843 Type of attribute: Both media and session level 844 Subject to charset: No 845 Purpose: Negotiate media-level connection data 846 Appropriate values: See RFC XXXX Section 3.1.2 847 [Note to the RFC Editor: Please replace the above RFC XXXX 848 with the RFC number of this specification. 849 Contact name: Miguel A. Garcia, 850 Miguel.A.Garcia@ericsson.com 852 Attribute name: icap 853 Long form name: Title Capability 854 Type of attribute: Both media and session level 855 Subject to charset: Yes 856 Purpose: Negotiate human-readable information 857 describing the session or media 858 Appropriate values: See RFC XXXX Section 3.1.3 859 [Note to the RFC Editor: Please replace the above RFC XXXX 860 with the RFC number of this specification. 861 Contact name: Miguel A. Garcia, 862 Miguel.A.Garcia@ericsson.com 864 6.2. New Option Tags 866 IANA is hereby requested to add the new option tags "bcap-v0", 867 "ccap-v0", and "icap-v0", defined herein, to the "SDP Capability 868 Negotiation Option Tag subregistry" of the "Session Description 869 Protocol (SDP) Parameters" registry. 871 6.3. New SDP Capability Negotiation Configuration Parameters 873 IANA is hereby requested to add the new parameter identifiers "b" for 874 "bandwidth", "c" for "connection data", and "i" for "title" to the 875 "SDP Capability Negotiation Configuration Parameters" subregistry of 876 the "Session Description Protocol (SDP) Parameters" registry. These 877 parameters are permitted in 'lcfg', 'acfg', and 'pcfg' attributes. 879 7. Acknowledgments 881 Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson 882 for arguing for the existence of this document and early reviewing 883 it. Thanks to Flemming Andreasen, Andrew Allen, and Jonathan Lennox 884 for a detailed review and many improvement suggestions. 886 8. References 888 8.1. Normative References 890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 891 Requirement Levels", BCP 14, RFC 2119, March 1997. 893 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 894 with Session Description Protocol (SDP)", RFC 3264, June 895 2002. 897 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 898 Description Protocol", RFC 4566, July 2006. 900 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 901 Specifications: ABNF", STD 68, RFC 5234, January 2008. 903 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 904 Capability Negotiation", RFC 5939, September 2010. 906 [RFC6871] Gilman, R., Even, R., and F. Andreasen, "Session 907 Description Protocol (SDP) Media Capabilities 908 Negotiation", RFC 6871, February 2013. 910 8.2. Informative References 912 [I-D.ietf-mmusic-sdp-cs] 913 Garcia, M. and S. Veikkolainen, "Session Description 914 Protocol (SDP) Extension For Setting Audio and Video Media 915 Streams Over Circuit-Switched Bearers In The Public 916 Switched Telephone Network (PSTN)", draft-ietf-mmusic-sdp- 917 cs-21 (work in progress), June 2013. 919 [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the 920 Session Description Protocol (SDP) for ATM Bearer 921 Connections", RFC 3108, May 2001. 923 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 924 Jacobson, "RTP: A Transport Protocol for Real-Time 925 Applications", STD 64, RFC 3550, July 2003. 927 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 928 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 929 RFC 3711, March 2004. 931 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 932 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 934 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 935 (ICE): A Protocol for Network Address Translator (NAT) 936 Traversal for Offer/Answer Protocols", RFC 5245, April 937 2010. 939 Authors' Addresses 941 Miguel A. Garcia-Martin 942 Ericsson 943 Calle Via de los Poblados 13 944 Madrid 28033 945 Spain 947 Phone: +34 91 339 1000 948 Email: miguel.a.garcia@ericsson.com 950 Simo Veikkolainen 951 Nokia 952 P.O. Box 226 953 NOKIA GROUP, FI 00045 954 Finland 956 Phone: +358 50 486 4463 957 Email: simo.veikkolainen@nokia.com 958 Robert R. Gilman 959 3243 W. 11th Ave. Dr. 960 Broomfield, Colorado 80020 961 U.S.A. 963 Phone: +1 303 898 9780 964 Email: bob_gilman@comcast.net