idnits 2.17.1 draft-ietf-mmusic-sdp-miscellaneous-caps-04.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 (March 13, 2013) is 4062 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-17 -- 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: September 14, 2013 Nokia 6 R. Gilman 7 March 13, 2013 9 Miscellaneous Capabilities Negotiation in the Session Description 10 Protocol (SDP) 11 draft-ietf-mmusic-sdp-miscellaneous-caps-04 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 14, 2013. 45 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 64 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 4 66 3.1.1. Bandwidth Capability . . . . . . . . . . . . . . . . . 6 67 3.1.2. Connection Data Capability . . . . . . . . . . . . . . 8 68 3.1.3. Title Capability . . . . . . . . . . . . . . . . . . . 12 69 3.2. Session Level versus Media Level . . . . . . . . . . . . . 15 70 3.3. Offer/Answer model extensions . . . . . . . . . . . . . . 16 71 3.3.1. Generating the Initial Offer . . . . . . . . . . . . . 16 72 3.3.2. Generating the Answer . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . 17 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 6.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 18 79 6.2. New Option Tags . . . . . . . . . . . . . . . . . . . . . 19 80 6.3. New SDP Capability Negotiation Configuration Parameters . 19 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 The Session Description Protocol (SDP) [RFC4566] is intended for 90 describing multimedia sessions for the purposes of session 91 announcement, session invitation, and other forms of multimedia 92 session initiation. SDP has been extended with a capability 93 negotiation mechanism framework [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 97 [I-D.ietf-mmusic-sdp-media-capabilities] provides negotiation 98 capabilities to media lines as well. 100 The capability negotiation is embedded into the widely used SDP 101 offer/answer procedure [RFC3264]. This memo provides the means to 102 negotiate further capabilities than those specified in the SDP 103 capability negotiation mechanism framework [RFC5939] and the SDP 104 media capabilities negotiation 105 [I-D.ietf-mmusic-sdp-media-capabilities]. In particular, this memo 106 provides a mechanism to negotiate bandwidth ('b='), connection data 107 ('c='), and session or media titles ('i='). 109 Since the three added capabilities are independent, it is not 110 expected that implementations will necessarily support all of them at 111 the same time. Instead, it is expected that applications will choose 112 their needed capability for their specific purpose. Due to this, we 113 are writing the normative part pertaining to each capability in a 114 self-contained section: Section 3.1.1 describes the bandwidth 115 capability extension, Section 3.1.2 describes the connection data 116 capability extension, and Section 3.1.3 describes the title 117 capability extension. Separate SDP capability negotiation option 118 tags are defined for each capability. 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 129 3.1. Extensions to SDP 131 The SDP Capability Negotiation Framework [RFC5939] and the SDP media 132 capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities] 133 specify attributes for negotiating SDP capabilities. These documents 134 specify new attributes (e.g., 'acap', 'tcap', 'rmcap', 'omcap') for 135 achieving their purpose. In this document we define three new 136 additional capability attributes for SDP lines of the general form: 138 type=value 140 for types 'b', 'c', and 'i'. The corresponding capability attributes 141 are respectively defined as: 143 o 'bcap': bandwidth capability 145 o 'ccap': connection data capability 147 o 'icap': title capability 149 From the sub-rules of attribute ('a=') line in SDP [RFC4566], SDP 150 attributes are of the form: 152 attribute = (att-field ":" att-value) / att-field 153 att-field = token 154 att-value = byte-string 156 Capability attributes use only the 'att-field:att-value' form. 158 The new capabilities may be referenced in potential configurations 159 ('a=pcfg') or in latent configurations ('a=lcfg'), as productions 160 conforming to the as respectively defined in 161 RFC 5939 [RFC5939] and the SDP media capabilities specification 162 [I-D.ietf-mmusic-sdp-media-capabilities]. 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 196 [I-D.ietf-mmusic-sdp-media-capabilities] with 'icap' and 'bcap' 197 capability attributes, we get the following SDP: 199 v=0 200 o=- 25678 753849 IN IP4 192.0.2.1 201 s= 202 c=IN IP4 192.0.2.1 203 t=0 0 204 a=bcap:1 CT:200 205 a=icap:1 Video conference 206 m=audio 54320 RTP/AVP 0 207 a=rmcap:1 L16/8000/1 208 a=rmcap:2 L16/16000/2 209 a=pcfg:1 m=1|2 pt=1:99,2:98 210 m=video 66544 RTP/AVP 100 211 a=rmcap:3 H263-1998/90000 212 a=rtpmap:100 H264/90000 213 a=pcfg:10 m=3 pt=3:101 b=1 i=1 215 Figure 1: Example SDP offer with bcap and icap defined at session 216 level 218 The above SDP defines one PCMU audio stream and one H.264 video 219 stream. It also defines two RTP-based media capabilities ('rmcap' 220 numbered 1 and 2), using L16 audio at 8 kbps and 16 kbps, 221 respectively, as well as an RTP-based media capability for H.263 222 video ('rmcap' numbered 3). The RTP-based media capabilities all 223 appear at the media level. The example also contains a single 224 bandwidth capability ('bcap') and a single title capability ('icap'), 225 both defined at session level. According to the definition above, 226 when the capabilities defined in the 'bcap' and 'icap' attributes are 227 referenced from the potential configuration, in the resulting SDP 228 they are to be interpreted as session level attributes (but the RTP- 229 based media capabilities are to be interpreted as media level 230 attributes). 232 3.1.1. Bandwidth Capability 234 According to RFC 4566 [RFC4566] the bandwidth field denotes the 235 proposed bandwidth to be used by the session or media. In this memo 236 we specify the bandwidth capability attribute which can also appear 237 at the SDP session and/or media level. The bandwidth field is 238 specified in RFC 4566 [RFC4566] with the following syntax: 240 b=: 242 where is an alphanumeric modifier giving the meaning of the 243 figure. 245 In this document, we define a new capability attribute: the Bandwidth 246 capability attribute 'bcap'. This attribute lists bandwidth as 247 capabilities according to the following definition: 249 "a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF 251 where is a unique integer within all the bandwidth 252 capabilities in the entire SDP, which is used to number the bandwidth 253 capability, and can take a value between 1 and 2^31-1 (both 254 included). The other elements are as defined for the 'b=' field in 255 SDP [RFC4566]. 257 This format satisfies the general attribute production rules in SDP 258 [RFC4566] according to the following Augmented Backus-Naur Form 259 (ABNF) [RFC5234] syntax: 261 att-field =/ "bcap" 262 att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth 263 bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 265 Figure 2: Syntax of the bcap attribute 267 Negotiation of bandwidth per media stream can be useful when 268 negotiating media encoding capabilities with different bandwidths. 270 3.1.1.1. Configuration Parameters 272 The SDP capability negotiation framework [RFC5939] provides for the 273 existence of the 'pcfg' and 'acfg' attributes. The concept is 274 extended by the SDP media capabilities negotiation 275 [I-D.ietf-mmusic-sdp-media-capabilities] with an 'lcfg' attribute 276 that conveys latent configurations. 278 Extensions to the 'pcfg' and 'lcfg' attributes are defined through 279 , and extensions to the 'acfg' attribute are 280 defined through the as defined in the SDP 281 Capability Negotiation [RFC5939]. 283 In this document we extend the field to be 284 able to convey lists of bandwidth capabilities in latent or potential 285 configurations, according to the following Augmented Backus-Naur Form 286 (ABNF) [RFC5234] syntax: 288 extension-config-list =/ bandwidth-config-list 289 bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR bw-cap-list) 290 ; BAR defined in RFC 5939 291 bw-cap-list = bw-cap-num *("," bw-cap-num) 292 bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 294 Figure 3: Syntax of the bandwidth parameter in 'lcfg' and 'pcfg' 295 attributes 297 Each bandwidth capability configuration is a comma-separated list of 298 bandwidth capability attribute numbers where refers to 299 the bandwidth capability numbers defined explicitly 300 earlier in this document, and hence MUST be between 1 and 2^31-1 301 (both included). Alternative bandwidth configurations are separated 302 by a vertical bar ("|"). 304 The above syntax is very flexible, allowing referencing to multiple 305 'b=' lines per configuration, even for the same . While the 306 need for such definitions is not seen, we have not restricted this, 307 as it is not restricted in SDP [RFC4566] either. 309 The bandwidth parameter to the actual configuration attribute 310 ('a=acfg') is formulated as a with 312 ext-cap-name = "b" 314 hence 316 sel-extension-config =/ sel-bandwidth-config 317 sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above. 319 Figure 4: Syntax of the bandwidth parameter in 'acfg' attributes 321 3.1.1.2. Option tag 323 The SDP Capability Negotiation Framework [RFC5939] allows for 324 capability negotiation extensions to be defined. Associated with 325 each such extension is an option tag that identifies the extension in 326 question. Hereby, we define a new option tag "bcap-v0" that 327 identifies support for the bandwidth capability. The endpoints using 328 the 'bcap' capability attribute SHOULD add the option tag to other 329 existing option tags present in the 'csup' and 'creq' attributes in 330 SDP, according to the procedures defined in the SDP Capability 331 Negotiation Framework [RFC5939]. 333 3.1.2. Connection Data Capability 335 According to SDP [RFC4566], the connection data field in SDP contains 336 the connection data, and it has the following syntax: 338 c= 340 where indicates the network type, indicates the 341 address type, and the is the connection address, 342 which is dependent on the address type. 344 At the moment, network types already defined include "IN", which 345 indicates Internet network type, and "ATM" (see RFC 3108 [RFC3108]), 346 used for describing Asynchronous Transfer Mode (ATM) bearer 347 connections. The Circuit-Switched (CS) descriptions in SDP document 348 [I-D.ietf-mmusic-sdp-cs] adds a "PSTN" network type for expressing a 349 Public Switched Telephone Network (PSTN) circuit switch. 351 SDP [RFC4566] permits specification of connection data at the SDP 352 session and/or media level. In order to permit negotiation of 353 connection data at the media level, we define the connection data 354 capability attribute ('a=ccap') in the form: 356 "a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP connection- 357 address CRLF 359 where is a unique integer within all the connection 360 capabilities in the entire SDP, which is used to identify the 361 connection data capability, and can take a value between 1 and 2^31-1 362 (both included). The other elements are as defined in [RFC4566]. 364 This format corresponds to the [RFC4566] attribute production rules 365 according to the following Augmented Backus-Naur Form (ABNF) 366 [RFC5234] syntax: 368 att-field =/ "ccap" 369 att-value =/ conn-cap-num 1*WSP nettype SP addrtype 370 SP connection-address 371 conn-cap-num = 1*10(DIGIT) ; 1 to 2^31-1, inclusive 372 ; DIGIT defined in RFC 5234 374 Figure 5: Syntax of the ccap attribute 376 The 'ccap' capability attribute allows for expressing alternative 377 connection address ('c=') lines in SDP as part of the SDP capability 378 negotiation process. The 'ccap' capability attribute is intended to 379 be used only when there is no other mechanism available for 380 negotiating alternative connection address information, such as when 381 the is different among the alternative addresses (e.g. 382 "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in 383 situations where an existing mechanism (such as Interactive 384 Connectivity Establishment (ICE) [RFC5245]) can be used to select 385 between different connection addresses (e.g. "IP4" and "IP6" or 386 different IP addresses within the same IP address family). 388 Figure 6 is an example of an SDP offer that includes a 'ccap' 389 capability attribute. An audio stream can be setup with an RTP flow 390 or establishing a circuit-switched audio stream: 392 v=0 393 o=2987933123 2987933123 IN IP4 198.51.100.7 394 s=- 395 t=0 0 396 a=creq:med-v0,ccap-v0 397 m=audio 38902 RTP/AVP 0 8 398 c=IN IP4 198.51.100.7 399 a=ccap:1 PSTN E164 +15555556666 400 a=tcap:2 PSTN 401 a=omcap:1 - 402 a=acap:1 setup:actpass 403 a=acap:2 connection:new 404 a=acap:3 cs-correlation:callerid:+15555556666 405 a=pcfg:1 c=1 t=2 m=1 a=1,2,3 407 Figure 6: Example SDP offer with a ccap attribute 409 The example in Figure 6 represents an SDP offer indicating an audio 410 flow using RTP, such as the one represented in Figure 7 or an audio 411 flow using a circuit-switched connection, such as the one represented 412 in Figure 8. 414 v=0 415 o=2987933123 2987933123 IN IP4 198.51.100.7 416 s=- 417 t=0 0 418 m=audio 38902 RTP/AVP 0 8 419 c=IN IP4 198.51.100.7 421 Figure 7: Equivalent SDP offer with the RTP flow 423 v=0 424 o=2987933123 2987933123 IN IP4 198.51.100.7 425 s=- 426 t=0 0 427 m=audio 9 PSTN - 428 c=PSTN E164 +15555556666 429 a=setup:actpass 430 a=connection:new 431 a=cs-correlation:callerid:+15555556666 433 Figure 8: Equivalent SDP offer with the circuit-switched flow 435 This document does not define any mechanism for negotiating or 436 describing different port numbers and hence the port number from the 437 "m=" line MUST be used by default. Exceptions to this default can be 438 provided by extension mechanisms or network type specific rules. 439 This draft defines an exception when the network type is "PSTN", in 440 which case the port number is replaced with 9 (the "discard" port) as 441 described in Session Decription Protocol (SDP) Extension For Setting 442 Up Audio and Video Media Streams over Circuit-Switched Bearers in the 443 Public Switched Telephone Network (PSTN) [I-D.ietf-mmusic-sdp-cs] 445 3.1.2.1. Configuration Parameters 447 The SDP Capability Negotiation Framework [RFC5939] provides for the 448 existence of the 'pcfg' and 'acfg' attributes, which can convey one 449 or more configurations to be negotiated. The concept is extended by 450 the Media Capabilities Negotiation 451 [I-D.ietf-mmusic-sdp-media-capabilities] with an 'lcfg' attribute 452 that conveys latent configurations. 454 In this document we define a parameter to be used 455 to specify a connection data capability in a potential or latent 456 configuration attribute. The parameter follows the form of an 457 , with 458 ext-cap-name = "c" 460 ext-cap-list = conn-cap-list 462 where, according to the following Augmented Backus-Naur Form (ABNF) 463 [RFC5234] syntax: 465 extension-config-list =/ conn-config-list 466 conn-config-list = ["+"] "c=" conn-cap-list 467 conn-cap-list = conn-cap-num *(BAR conn-cap-num) 468 conn-cap-num = 1*10(DIGIT) ; 1 to 2^32-1 inclusive 470 Figure 9: Syntax of the connection data parameter in 'lcfg' and 471 'pcfg' attributes 473 Each capability configuration alternative contains a single 474 connection data capability attribute number and refers to the conn- 475 cap-num capability number defined explicitly earlier in this 476 document, and hence MUST be between 1 and 2^31-1 (both included). 477 The connection data capability allows the expression of only a single 478 capability in each alternative, rather than a list of capabilities, 479 since no more than a single connection data field is permitted per 480 media block. Nevertheless, it is still allowed to express 481 alternative potential connection configurations separated by a 482 vertical bar ("|"). 484 An endpoint includes a plus sign ("+") in the configuration attribute 485 to mandate support for this extension. An endpoint that receives 486 this parameter prefixed with a plus sign and does not support this 487 extension MUST treat that potential configuration as not valid. 489 The connection data parameter to the actual configuration attribute 490 ('a=acfg') is formulated as a with 492 ext-cap-name = "c" 494 hence 496 sel-extension-config =/ sel-connection-config 497 sel-connection-config = "c=" conn-cap-num ; as defined above. 499 Figure 10: Syntax of the connection data parameter in 'acfg' 500 attributes 502 3.1.2.2. Option tag 504 The SDP Capability Negotiation Framework [RFC5939] solution allows 505 for capability negotiation extensions to be defined. Associated with 506 each such extension is an option tag that identifies the extension in 507 question. Hereby, we define a new option tag of "ccap-v0" that 508 identifies support for the connection data capability. This option 509 tag SHOULD be added to other existing option tags present in the 510 'csup' and 'creq' attributes in SDP, according to the procedures 511 defined in the SDP Capability Negotiation Framework [RFC5939]. 513 3.1.3. Title Capability 515 SDP [RFC4566] provides for the existence of an information field 516 expressed in the format of the 'i=' line, which can appear at the SDP 517 session and/or media level. An 'i=' line that is present at the 518 session level is known as the "session name", and its purpose is to 519 convey human-readable textual information about the session. 521 The 'i=' line in SDP can also appear at the media level, in which 522 case it is used to provide human-readable information about the media 523 stream to which it is related, e.g., it may indicate the purpose of 524 the media stream. The 'i=' line is not to be confused with the label 525 attribute ('a=label:', [RFC4574]) which provides a machine-readable 526 tag. It is foreseen that applications declaring capabilities related 527 to different configurations of a media stream may need to provide 528 different identifying information for each of those configurations. 529 That is, a party might offer alternative media configurations for a 530 stream, each of which represents a different presentation of the same 531 or similar information. For example, an audio stream might offer 532 English or Spanish configurations, or a video stream might offer a 533 choice of video source such as speaker camera, group camera, or 534 document viewer. The title capability is needed to inform the 535 answering user in order to select the proper choice, and the label is 536 used to inform the offering machine which choice the answerer has 537 selected. Hence, there is value in defining a mechanism to provide 538 titles of media streams as capabilities. 540 As defined in SDP [RFC4566], the session information field ("i=", 541 referred to as "title" in this document) is subject to the 542 "a=charset" attribute in order to support different character sets 543 and hence internationalization. The title capability attribute 544 itself ("a=icap") is however not subject to the "a=charset" attribute 545 as this would preclude the inclusion of alternative session/title 546 information each using different character sets. Instead, the 547 session/title value embedded in an "a=icap" attribute (title 548 capability) will be subject to the "a=charset" value used within a 549 configuration that includes that title capability. This provides for 550 consistent SDP operation while allowing for capabilities and 551 configurations with different session/title information values with 552 different character set encodings (with each such configuration 553 including an "a=charset" value with the relevant character set for 554 the session/title information in question). 556 According to SDP [RFC4566], the session information ('i=') line has 557 the following syntax: 559 "i=" text 561 where "text" represents a human-readable text indicating the purpose 562 of the session or media stream. 564 In this document we define a new capability attribute: the Title 565 capability 'icap'. This attribute lists session or media titles as 566 capabilities, according to the following definition: 568 "a=icap:" title-cap-num 1*WSP text 570 where is a unique integer within all the connection 571 capabilities in the entire SDP, which is used to identify the 572 particular title capability, and can take a value between 1 and 573 2^31-1 (both included). is a human-readable text that 574 indicates the purpose of the session or media stream it is supposed 575 to characterize. 577 As an example, one might use: 579 a=icap:1 Document Camera 581 to define a title capability number 1 to identify a particular source 582 of a media stream. 584 The title capability attribute satisfies the general attribute 585 production rules in SDP [RFC4566] according to the following 586 Augmented Backus-Naur Form (ABNF) [RFC5234] syntax: 588 att-field =/ "icap" 589 att-value =/ title-cap-num 1*WSP text 590 ; text defined in RFC 4566 591 title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 593 Figure 11: Syntax of the icap attribute 595 3.1.3.1. Configuration Parameters 597 The SDP Capability Negotiation Framework [RFC5939] provides for the 598 existence of the 'pcfg' and 'acfg' attributes. The concept is 599 extended by the SDP media capabilities negotiation 600 [I-D.ietf-mmusic-sdp-media-capabilities] with an 'lcfg' attribute 601 that conveys latent configurations. 603 In this document, we define a parameter to be 604 used to convey title capabilities in a potential or latent 605 configuration. This parameter is defined as an with the following associations: 608 ext-cap-name = "i" 610 ext-cap-list = title-cap-list 612 This leads to the following definition for the title capability 613 parameter: 615 extension-config-list =/ title-config-list 616 title-config-list = ["+"] "i=" title-cap-list 617 title-cap-list = title-cap-num *(BAR title-cap-num) 618 ; BAR defined in RFC 5939 619 title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 621 Figure 12: Syntax of the title capability parameter in 'lcfg' and 622 'pcfg' attributes 624 Each potential capability configuration contains a single title 625 capability attribute number where 'title-cap-num' is the title 626 capability number defined explicitly earlier in this document, and 627 hence must be between 1 and 2^31-1 (both included). The title 628 capability allows the expression of only a single capability in each 629 alternative, since no more than a single title field is permitted per 630 block. Nevertheless, it is still allowed to express alternative 631 potential title configurations separated by a vertical bar ("|"). 633 An endpoint includes a plus sign ("+") in the configuration attribute 634 to mandate support for this extension. An endpoint that receives 635 this parameter prefixed with a plus sign and does not support this 636 extension MUST treat that potential configuration as not valid. 638 The title parameter to the actual configuration attribute ('a=acfg') 639 is formulated as a with 640 ext-cap-name = "i" 642 hence 644 sel-extension-config =/ sel-title-config 645 sel-title-config = "i=" title-cap-num ; as defined above. 647 Figure 13: Syntax of the title parameter in 'acfg' attributes 649 3.1.3.2. Option Tag 651 At present, it is difficult to envision a scenario in which the 652 'icap' attribute must be supported or the offer must be rejected. In 653 most cases, if the icap attribute or its contents were to be ignored, 654 an offered configuration could still be chosen based on other 655 criteria such as configuration numbering. However, one might imagine 656 an SDP offer that contained English and Spanish potential 657 configurations for an audio stream. The session might be 658 unintelligible if the choice is based on configuration numbering, 659 rather than informed user selection. Based on such considerations, 660 it may well prove useful to announce the ability to use the icap 661 attribute and its contents to select media configurations, or to 662 inform the user about the selected configuration(s). Therefore, we 663 define a new option tag of "icap-v0" that identifies support for the 664 title capability. This option tag SHOULD be added to other existing 665 option tags present in the 'csup' and/or 'creq' attributes in SDP, 666 according to the procedures defined in the SDP Capability Negotiation 667 Framework [RFC5939]. The discussion above suggests that "icap-v0" 668 will typically appear in a 'csup' attribute, but rarely in a 'creq' 669 attribute. 671 3.2. Session Level versus Media Level 673 The 'bcap', 'ccap' and 'icap' attributes can appear at the SDP 674 session and/or media level. Endpoints MUST interpret capabilities 675 declared at session level as part of the session level in the 676 resulting SDP for that particular configuration. Endpoints MUST 677 interpret capabilities declared at media description as part of the 678 media level in the resulting SDP for that particular configuration. 680 The presence of the 'bcap' capability for the same at both 681 the session and media level is subject to the same constraints and 682 restrictions specified in RFC 4566 [RFC4566] for the bandwidth 683 attribute "b=". 685 To avoid confusion, the for each 'a=bcap', 'a=ccap', 686 and 'a=icap' line MUST be unique across all capability attributes of 687 the same type within the entire session description. 689 3.3. Offer/Answer model extensions 691 In this section, we define extensions to the offer/answer model 692 defined in SDP Offer/Answer Model [RFC3264] and extended in the SDP 693 Capability Negotiation [RFC5939] to allow for bandwidth, connection, 694 and title capabilities to be used with the SDP Capability Negotiation 695 framework. 697 3.3.1. Generating the Initial Offer 699 When an endpoint generates an initial offer and wants to use the 700 functionality described in the current document, it first defines 701 appropriate values for the bandwidth, connection data, and/or title 702 capability attributes according to the rules defined in [RFC4566] for 703 'b=', 'c=' and 'i=' lines. The endpoint then MUST include the 704 respective capability attributes and associated values in the SDP 705 offer. The preferred configurations for each media stream are 706 identified following the media line in a 'pcfg' attribute. Bandwidth 707 and title capabilities may also be referenced in latent 708 configurations in an 'lcfg' attribute, defined in SDP Media 709 Capabilities [I-D.ietf-mmusic-sdp-media-capabilities]. 711 Implementations are advised to pay attention to the port number that 712 is used in the "m=" line. By default, a potential configuration that 713 includes a connection data capability will use the port number from 714 the "m=" line, unless the network type is "PSTN", in which case the 715 default port number used will be 9. 717 The offer SHOULD include the level of capability negotiation 718 extensions needed to support this functionality in a 'creq' 719 attribute. 721 3.3.2. Generating the Answer 723 When the answering party receives the offer, and if it supports the 724 required capability negotiation extensions, it SHOULD select the most 725 preferred configuration it can support for each media stream, and 726 build the answer accordingly, as defined in Section 3.6.2 of the SDP 727 Capability Negotiation [RFC5939]. 729 If the connection data capability is used in a selected potential 730 configuration chosen by the answerer, that offer configuration MUST 731 by default use the port number from the actual offer configuration 732 (i.e. the "m=" line), unless the network type is "PSTN", in which 733 case the default port MUST be assumed to be 9. Extensions may be 734 defined to negotiate the port number explicitly instead. 736 3.3.3. Offerer Processing of the Answer 738 When the offerer receives the answer, it MUST process the media lines 739 according to normal SDP processing rules to identify the media 740 stream(s) accepted by the answer, if any, as defined in Section 3.6.3 741 of the SDP Capability Negotiation [RFC5939]. The 'acfg' attribute, 742 if present, MUST be used to verify the proposed configuration used to 743 form the answer, and to infer the lack of acceptability of higher- 744 preference configurations that were not chosen. 746 3.3.4. Modifying the Session 748 If, at a later time, one of the parties wishes to modify the 749 operating parameters of a session, e.g. by adding a new media stream, 750 or by changing the properties used on an existing stream, it may do 751 so via the mechanisms defined for SDP offer/answer [RFC3264] and in 752 accordance with the procedures defined in Section 3.6.4 of the SDP 753 Capability Negotiation [RFC5939]. 755 4. Field Replacement Rules 757 To simplify the construction of SDP records, given the need to 758 include fields within the media description in question for endpoints 759 that do not support capabilities negotiation, we define some simple 760 field-replacement rules for those fields invoked by potential or 761 latent configurations. In particular, any 'i=' or 'c=' line invoked 762 by a configuration MUST replace the corresponding line, if present 763 within the media description in question. Any 'b=' line invoked by a 764 configuration MUST replace any 'b=' of the same bandwidth type at the 765 media level, but not at the session level. 767 5. Security Considerations 769 This document provides an extension on top of RFC 4566 [RFC4566], RFC 770 3264 [RFC3264], SDP Capability Negotiation Framework [RFC5939], and 771 SDP media capabilities negotiation 772 [I-D.ietf-mmusic-sdp-media-capabilities]. As such, the security 773 considerations of those documents apply. 775 The bandwidth capability attribute may be used for reserving 776 resources at endpoints and intermediaries which inspect the SDP. 777 Modification of the bandwidth value by an attacker can lead to the 778 network being underutilized (too high bandwidth value) or congested 779 (too low bandwidth value). In case it is essential to protect the 780 bandwidth value, one of the security mechanisms proposed in [RFC5939] 781 SHOULD be used. 783 The 'i=' line and thus the value carried in the title capability 784 attribute is intended for human-readable description only. It should 785 not be parsed programmatically. 787 6. IANA Considerations 789 6.1. New SDP Attributes 791 IANA is hereby requested to register new attributes in the "att-field 792 (both session and media level)" of the "Session Description Protocol 793 (SDP) Parameters" registry, according to the following registration 794 form: 796 Attribute name: bcap 797 Long form name: Bandwidth Capability 798 Type of attribute: Both media and session level 799 Subject to charset: No 800 Purpose: Negotiate session or media-level bandwidths 801 Appropriate values: See RFC XXXX Section 3.1.1 802 [Note to the RFC Editor: Please replace the above RFC XXXX 803 with the RFC number of this specification. 804 Contact name: Miguel A. Garcia, 805 Miguel.A.Garcia@ericsson.com 807 Attribute name: ccap 808 Long form name: Connection Data Capability 809 Type of attribute: Both media and session level 810 Subject to charset: No 811 Purpose: Negotiate media-level connection data 812 Appropriate values: See RFC XXXX Section 3.1.2 813 [Note to the RFC Editor: Please replace the above RFC XXXX 814 with the RFC number of this specification. 815 Contact name: Miguel A. Garcia, 816 Miguel.A.Garcia@ericsson.com 818 Attribute name: icap 819 Long form name: Title Capability 820 Type of attribute: Both media and session level 821 Subject to charset: Yes 822 Purpose: Negotiate human-readable information 823 describing the session or media 824 Appropriate values: See RFC XXXX Section 3.1.3 825 [Note to the RFC Editor: Please replace the above RFC XXXX 826 with the RFC number of this specification. 827 Contact name: Miguel A. Garcia, 828 Miguel.A.Garcia@ericsson.com 830 6.2. New Option Tags 832 IANA is hereby requested to add the new option tags "bcap-v0", 833 "ccap-v0", and "icap-v0", defined herein, to the "SDP Capability 834 Negotiation Option Tag subregistry" of the "Session Description 835 Protocol (SDP) Parameters" registry. 837 6.3. New SDP Capability Negotiation Configuration Parameters 839 IANA is hereby requested to add the new parameter identifiers "b" for 840 "bandwidth", "c" for "connection data", and "i" for "title" to the 841 "SDP Capability Negotiation Configuration Parameters" subregistry of 842 the "Session Description Protocol (SDP) Parameters" registry. These 843 parameters are permitted in 'lcfg', 'acfg', and 'pcfg' attributes. 845 7. Acknowledgments 847 Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson 848 for arguing for the existence of this document and early reviewing 849 it. Thanks to Flemming Andreasen, Andrew Allen, and Jonathan Lennox 850 for a detailed review and many improvement suggestions. 852 8. References 854 8.1. Normative References 856 [I-D.ietf-mmusic-sdp-media-capabilities] 857 Gilman, R., Even, R., and F. Andreasen, "Session 858 Description Protocol (SDP) Media Capabilities 859 Negotiation", draft-ietf-mmusic-sdp-media-capabilities-17 860 (work in progress), January 2013. 862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 863 Requirement Levels", BCP 14, RFC 2119, March 1997. 865 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 866 with Session Description Protocol (SDP)", RFC 3264, 867 June 2002. 869 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 870 Description Protocol", RFC 4566, July 2006. 872 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 873 Specifications: ABNF", STD 68, RFC 5234, January 2008. 875 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 876 Capability Negotiation", RFC 5939, September 2010. 878 8.2. Informative References 880 [I-D.ietf-mmusic-sdp-cs] 881 Garcia, M. and S. Veikkolainen, "Session Description 882 Protocol (SDP) Extension For Setting Up Audio and Video 883 Media Streams Over Circuit-Switched Bearers In The Public 884 Switched Telephone Network (PSTN)", 885 draft-ietf-mmusic-sdp-cs-17 (work in progress), 886 January 2013. 888 [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the 889 Session Description Protocol (SDP) for ATM Bearer 890 Connections", RFC 3108, May 2001. 892 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 893 Jacobson, "RTP: A Transport Protocol for Real-Time 894 Applications", STD 64, RFC 3550, July 2003. 896 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 897 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 898 RFC 3711, March 2004. 900 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 901 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 903 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 904 (ICE): A Protocol for Network Address Translator (NAT) 905 Traversal for Offer/Answer Protocols", RFC 5245, 906 April 2010. 908 Authors' Addresses 910 Miguel A. Garcia-Martin 911 Ericsson 912 Calle Via de los Poblados 13 913 Madrid, 28033 914 Spain 916 Phone: +34 91 339 1000 917 Email: miguel.a.garcia@ericsson.com 918 Simo Veikkolainen 919 Nokia 920 P.O. Box 226 921 NOKIA GROUP, FI 00045 922 Finland 924 Phone: +358 50 486 4463 925 Email: simo.veikkolainen@nokia.com 927 Robert R. Gilman 928 3243 W. 11th Ave. Dr. 929 Broomfield, Colorado 80020 930 U.S.A. 932 Phone: +1 303 898 9780 933 Email: bob_gilman@comcast.net