idnits 2.17.1 draft-andreasen-mmusic-sdp-capability-negotiation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1356. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 31 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 507 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 20, 2006) is 6397 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.jenning-sipping-multipart' is mentioned on line 515, but not defined == Missing Reference: 'Section 8' is mentioned on line 1163, but not defined == Unused Reference: 'RFC2234' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: 'RFC3605' is defined on line 1254, but no explicit reference was found in the text == Unused Reference: 'I-D.jennings-sipping-multipart' is defined on line 1301, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4566 (ref. 'SDP') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4091 (Obsoleted by RFC 5245) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group F. Andreasen 3 Internet Draft Cisco Systems 4 Expires: April 2007 October 20, 2006 6 SDP Capability Negotiation 7 draft-andreasen-mmusic-sdp-capability-negotiation-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on April 20, 2007. 35 Abstract 37 The Session Description Protocol (SDP) was intended for describing 38 multimedia sessions for the purposes of session announcement, session 39 invitation, and other forms of multimedia session initiation. SDP was 40 not intended to provide capability indication or capability 41 negotiation, however over the years, SDP has seen widespread adoption 42 and as a result it has been gradually extended to provide limited 43 support for these. SDP and its current extensions however do not have 44 the ability to negotiate one or more alternative transport protocols 45 (e.g. RTP profiles) which makes it particularly difficult to deploy 46 new RTP profiles such as secure RTP and RTP with RTCP-based feedback. 48 The purpose of this document is to address that by identifying a set 49 of requirements, evaluate existing work in this area, and provide a 50 recommended solution for extending SDP with capability negotiation. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 Table of Contents 60 1. Introduction...................................................3 61 2. Requirements...................................................5 62 3. Review of Existing Work........................................7 63 3.1. Grouping of Media Lines...................................8 64 3.2. Session Description Protocol (SDP) Simple Capability 65 Declaration....................................................9 66 3.3. Session Description and Capability Negotiation (SDPng)...10 67 3.4. Multipart/alternative....................................12 68 3.5. Sharing Ports Between "m=" Lines.........................13 69 3.6. Opportunistic Encryption Using a Session Attribute.......14 70 3.7. Best-Effort Secure Real-Time Transport Protocol..........14 71 3.8. Opportunistic Encryption using Probing...................15 72 4. Proposed Solution.............................................15 73 4.1. Solution Overview........................................15 74 4.2. Extensions to Simcap.....................................17 75 4.3. Attribute Definitions....................................18 76 4.3.1. The Attribute Parameter Capability Attribute........18 77 4.3.2. The Transport Protocol Capability Attribute.........19 78 4.3.3. The Potential Configuration Attribute...............20 79 4.3.4. The Actual Configuration Attribute..................22 80 4.4. Offer/Answer Model Extensions............................24 81 4.4.1. Generating the Initial Offer........................24 82 4.4.2. Generating the Answer...............................24 83 4.4.3. Offerer Processing of the Answer....................25 84 4.4.4. Modifying the Session...............................25 85 5. Examples......................................................26 86 6. Security Considerations.......................................26 87 7. IANA Considerations...........................................26 88 8. To Do and Open Issues.........................................26 89 9. Acknowledgments...............................................26 90 10. Change Log...................................................26 91 10.1. Changes since -00.......................................26 92 11. References...................................................28 93 11.1. Normative References....................................28 94 11.2. Informative References..................................28 95 Author's Addresses...............................................30 96 Intellectual Property Statement..................................30 97 Disclaimer of Validity...........................................30 98 Copyright Statement..............................................30 99 Acknowledgment...................................................31 101 1. Introduction 103 The Session Description Protocol (SDP) was intended for describing 104 multimedia sessions for the purposes of session announcement, session 105 invitation, and other forms of multimedia session initiation. The SDP 106 contains one or more media stream descriptions with information such 107 as IP-address and port, type of media stream (e.g. audio or video), 108 transport protocol (possibly including profile information, e.g. 109 RTP/AVP or RTP/SAVP), media formats (e.g. codecs), and various other 110 session and media stream parameters that define the session. 112 Simply providing media stream descriptions is sufficient for session 113 announcements for a broadcast application, where the media stream 114 parameters are fixed for all participants. When a participant wants 115 to join the session, he obtains the session announcement and uses the 116 media descriptions provided, e.g., joins a multicast group and 117 receives media packets in the encoding format specified. If the 118 media stream description is not supported by the participant, he is 119 unable to receive the media. 121 Such restrictions are not generally acceptable to multimedia session 122 invitations, where two or more entities attempt to establish a media 123 session using a set of media stream parameters acceptable to all 124 participants. First of all, each entity must inform the other of its 125 receive address, and secondly, the entities need to agree on the 126 media stream parameters to use for the session, e.g. transport 127 protocols and codecs. We here make a distinction between the 128 capabilities supported by each participant and the parameters that 129 can actually be used for the session. More generally, we can say that 130 we have the following: 132 o A set of capabilities, or potential configurations of the media 133 stream components, supported by each side. 135 o A set of actual configurations of the media stream components, 136 which specifies which media stream components to use and with what 137 parameters. 139 o A negotiation process that takes the set of potential 140 configurations (capabilities) as input and provides the actual 141 configurations as output. 143 SDP by itself was designed to provide only the second of these, i.e., 144 the actual configurations, however over the years, use of SDP has 145 been extended beyond its original scope. Session negotiation 146 semantics was defined by the offer/answer model in RFC 3264. It 147 defines how two entities, an offerer and an answerer, exchange SDPs 148 to negotiate a session. The offerer can include one or more media 149 formats (codecs) per media stream, and the answerer then selects one 150 or more of those offered and returns them in an answer. Both the 151 offer and the answer contain actual configurations - potential 152 configurations are not supported. The answer however may reduce the 153 set of actual configurations from the offer. 155 Other relevant extensions have been defined. Simple capability 156 declarations, which defines how to provide a simple and limited set 157 of capability descriptions in SDP was defined in RFC 3407. Grouping 158 of media lines, which defines how media lines in SDP can have other 159 semantics than the traditional "simultaneous media streams" 160 semantics, was defined in RFC 3388, etc. 162 Each of these extensions was designed to solve a specific limitation 163 of SDP. Since SDP had already been stretched beyond its original 164 intent, a more comprehensive capability declaration and negotiation 165 process was intentionally not defined. Instead, work on a "next 166 generation" of a protocol to provide session description and 167 capability negotiation was initiated [SDPng]. SDPng however has not 168 gained traction and has remained as work in progress for an extended 169 period of time. Existing real-time multimedia communication 170 protocols such as SIP, RTSP, Megaco, and MGCP continue to use SDP. 171 SDP and its current extensions however do not address an increasingly 172 important problem: the ability to negotiate one or more alternative 173 transport protocols (e.g., RTP profiles). This makes it difficult to 174 deploy new RTP profiles such as secure RTP (SRTP) [SRTP], RTP with 175 RTCP-Based Feedback [AVPF], etc. This particular problem is 176 exacerbated by the fact that RTP profiles are defined independently. 177 When a new profile is defined and N other profiles already exist, 178 there is a potential need for defining N additional profiles, since 179 profiles cannot be combined automatically. For example, in order to 180 support the plain and secure RTP version of RTP with and without 181 RTCP-based feedback, four separate profiles (and hence profile 182 definitions) are needed: RTP/AVP [RFC3551], RTP/SAVP [SRTP], RTP/AVPF 183 [AVPF], and RTP/SAVPF [SAVPF]. In addition to the pressing profile 184 negotiation problem, other important real-life constraints have been 185 found as well. 187 The purpose of this document is to define a mechanism that enables 188 SDP to provide limited support for indicating potential 189 configurations (capabilities) and negotiate the use of those 190 potential configurations as actual configurations. It is not the 191 intent to provide a full-fledged capability indication and 192 negotiation mechanism along the lines of SDPng or ITU-T H.245. 193 Instead, the focus is on addressing a set of well-known real-life 194 limitations. 196 As mentioned above, SDP is used by several protocols, and hence the 197 mechanism should be usable by all of these. One particularly 198 important protocol for this problem however is the Session Initiation 199 Protocol (SIP) [RFC3261]. SIP uses the offer/answer model (which is 200 not specific to SIP) to negotiate sessions and hence any mechanism 201 must at least consider how it either interacts with offer/answer, or 202 how it should extend it. 204 The rest of the document is structured as follows. We first provide a 205 set of requirements for the solution in Section 2. In Section 3. we 206 review relevant existing work in this area, how a solution based on 207 that might look, and the pros and cons associated with each. In 208 Section 4. we present our proposed solution in more detail followed 209 examples in Section 5. and security considerations in Section 6. 211 2. Requirements 213 REQ-10: It MUST be possible to indicate and negotiate alternative 214 media formats on a per media stream basis. 216 For example, many implementations support multiple codecs, but 217 only one at a time. Changes between codecs cannot be done on- 218 the-fly, e.g. when receiving a simple RTP payload type change. 220 REQ-20: It MUST be possible to indicate and negotiate alternative 221 attribute values ("a=") on a per media stream basis. 223 For example, T.38 defines new attributes that may need to be 224 conveyed as part of a capability. 226 REQ-25: It MUST be possible to indicate and negotiate alternative 227 attribute values ("a=") at the session level. 229 REQ-30: It MUST be possible to indicate and negotiate alternative 230 media format parameter values ("a=fmtp") per media format on a per 231 media stream basis. 233 For example, a media format (codec) indicated as an alternative 234 capability may include fmtp parameters. 236 REQ-40: It MUST be possible to indicate and negotiate alternative 237 transport protocols, e.g. different RTP profiles, on a per media 238 stream basis. 240 For example, "RTP/AVP" and "RTP/SAVP" may be alternatives. 242 REQ-50: It MUST be possible to indicate and negotiate alternative 243 transport protocol and media type combinations on a per media stream 244 basis. 246 For example, an entity may support a fax call using either T.38 247 fax relay ("m=image udptl t38") or PCMU ("m=audio 248 RTP/AVP 0"). 250 REQ-80: The mechanism MUST be backwards compatible for SIP. Ideally, 251 the mechanism should be completely transparent to entities that do 252 not support it, without the need for any further signaling. 254 REQ-90: The mechanism MUST either be backwards compatible for Megaco 255 and MGCP or it MUST be possible to interwork it with Megaco and MGCP 256 without any additional signaling between the MGC and its peer (e.g. 257 another SIP UA as opposed to a media gateway). 259 For example, if a media gateway controller (MGC) uses SIP to 260 communicate with peers, and the MGC uses Megaco or MGCP to 261 control a media gateway, it must be possible to translate between 262 the mechanism and normal SDP. Avoiding interworking requirements 263 in the MGC is desirable. 265 REQ-100: The mechanism MUST work within the context of the 266 offer/answer model [RFC3264]. Specifically, it MUST be possible to 267 negotiate alternatives within a single offer/answer exchange. 269 REQ-110: The offer/answer model requires the offerer to be able to 270 receive media for any media streams listed as either "recvonly" or 271 "sendrecv" in an offer, as soon as that offer is generated. The 272 mechanism MUST preserve this capability for all actual configurations 273 included in an offer. 275 Potential configurations do not have such a requirement. 277 REQ-120: The mechanism MUST enable inclusion of potential 278 configurations (alternative capabilities) in the offer - the answer 279 would then indicate which, if any of these potential configurations 280 were accepted. The offerer is not required to process media for a 281 specific potential configuration until the offerer receives an answer 282 showing that potential configuration was accepted. 284 Note that this implies that it may not be possible for the 285 offerer to process early media generated using a potential 286 configuration (as opposed to the actual configuration) until the 287 answer has been received. 289 REQ-130: The mechanism MUST work in the presence of SIP forking. 291 REQ-140: The mechanism SHOULD be reasonably efficient in terms of 292 overall message size. 294 This is a relative requirement to evaluate alternative solutions 295 as opposed to an absolute and quantifiable requirement. Use of 296 compression techniques can help reduce the size of text-based 297 messages, however it is still considered important to try and 298 keep the message size reasonably small. 300 Above, we presented the requirements for the capability negotiation 301 mechanism. Below, we provide a set of features that were considered 302 and then explicitly deemed to be out-of-scope: 304 o Indication of mandatory and optional capabilities. 306 o Constraints on combinations of configurations, e.g. inability to 307 use a video codec together with a particular audio codec, 308 parameter X values that can only be used with parameter Y values, 309 etc. 311 o Support for negotiation of unicast and multicast addresses as 312 alternatives. It was suggested as a requirement initially, but 313 subsequent discussion led to its removal. 315 o Support for negotiation of IPv4 and IPv6 addresses as 316 alternatives. It was suggested as a requirement initially, but 317 subsequent discussion let to its removal. 319 3. Review of Existing Work 321 In this section, we provide an overview of existing relevant work 322 that has either been completed or is work in progress. For each 323 item, we outline how/if it can be used to address the requirements 324 provided and the pros and cons of doing so. 326 3.1. Grouping of Media Lines 328 Grouping of Media Lines is defined in [RFC3388]. RFC 3388 defines a 329 framework that enables two or media lines to be grouped together for 330 different purposes. Each media line is assigned an identifier and one 331 or more group attributes then references two or more of those 332 identifiers. Associated with each group attribute is a semantics 333 indication. One semantic indication is the Alternative Network 334 Address Types ("ANAT") [RFC4091] which allows for IPv4 and IPv6 335 addresses to be specified as alternatives. The requirements presented 336 above go beyond that, however a new semantic to simply indicate 337 alternative media lines and associated negotiation rules could easily 338 be defined. 340 The main advantages of such an approach would be: 342 o Mechanism Reuse: Several semantics have already been defined 343 which increases the likelihood of an implementation supporting the 344 framework. 346 The disadvantages of such an approach would be: 348 o Backwards Compatibility: The mechanism is not transparently 349 backwards compatible. If an entity that does not support the 350 mechanism receives it, the entity may incorrectly interpret the 351 SDP as consisting of multiple media streams. While RFC 3388 352 defines procedures for recognizing and recover from this when 353 using offer/answer, it can still lead to unintended behavior with 354 endpoints that do not support the mechanism. 356 In practice, it is not clear how much of an issue this is, at 357 least for intelligent SIP endpoints. Most current 358 implementations generally accept only one media stream of a 359 given type (e.g. audio). Use of alternatives with different 360 media stream types (e.g. a fax call using "audio" for voice- 361 band data or "image" for T.38) makes it less clear though. 362 Also, Media Gateway Controllers and Media Gateways that do not 363 support grouping of media lines have been known to encounter 364 problems. 366 o Semantics Combination Issues: Multiple semantics may be provided 367 by use of grouping, however they may interact with each other 368 unintentionally. For example, the "FID" semantics defined in RFC 369 3388 forbids grouping of media lines with the same transport 370 address, however that would be needed for alternative 371 capabilities. Thus, using "FID" and alternative capabilities 372 together would require special consideration. 374 o Some Combinatoric Explosion: The mechanism is not ideal to 375 indicate alternative capabilities for multiple parameters or media 376 formats within a particular media stream. For example, alternative 377 attribute values and media format parameters for several codecs 378 would lead to combinatoric explosion. 380 [Editor's note: In practice, it is not clear this is a huge issue 381 though.] 383 o Message Size: Each alternative requires full duplication of all 384 the relevant media stream parameters. 386 [Editor's note: In practice, it is not clear this is a huge issue 387 though.] 389 3.2. Session Description Protocol (SDP) Simple Capability Declaration 391 SDP Simple Capability Declaration (simcap) is defined in [RFC3407]. 392 It defines a set of SDP attributes that enables capabilities to be 393 described at a session level or on a per media stream basis. RFC 394 3407 defines capability declaration only - actual negotiation 395 procedures taking advantage of such capabilities have not been 396 defined. Such rules however could easily be defined - the negotiation 397 part would extend the offer/answer model to examine alternative 398 configurations (capabilities). In conjunction with that, attributes 399 to indicate the alternative configurations accepted would likely be 400 needed as well. 402 The main advantages of this approach are: 404 o Satisfies all the requirements provided above. In particular, by 405 relying solely on SDP attributes, transparent backwards 406 compatibility is always ensured. 408 The disadvantages of this approach are: 410 o Offered Capabilities Hidden in Attributes: An offer may be 411 accepted by the answerer and a media stream established based on 412 SDP parameters contained in SDP attributes not known to 413 intermediaries. Such intermediaries may be back-to-back user 414 agents, or proxies that need to inspect the SDP, e.g., to 415 authorize Quality of Service, add transcoders, etc. 417 o Maximum of 255 alternative media formats per SDP: RFC 3407 418 currently allows a maximum of 255 alternative media formats 419 (codecs) per SDP. This may be too restrictive. 421 3.3. Session Description and Capability Negotiation (SDPng) 423 The Session Description and Capability Negotiation protocol [SDPng] 424 was intended as a replacement for SDP [SDP]. SDPng includes a full 425 capability indication and negotiation framework that would address 426 the shortcomings of SDP and satisfy the requirements provided above. 427 However, SDPng has not gained traction, in large part due to existing 428 widespread adoption of SDP. As a consequence, SDPng has remained as 429 work in progress with limited progress for an extended period of 430 time. 432 SDPng consists of two things: an SDPng description, which is an XML 433 document that describes the actual and/or potential configurations as 434 well as an optional negotiation process (an offer/answer compliant 435 process is included as part of SDPng). The SDPng description consists 436 of up to five parts: 438 o Capabilities: An optional list of capabilities (potential 439 configurations) to be matched with the other parties' 440 capabilities. 442 o Definitions: An optional set of definitions of commonly used 443 parameters for later referencing. 445 o Configurations: A mandatory description of the conference 446 components, each of which can provide a list of alternative 447 configurations. 449 o Constraints: An optional set of constraints of combinations 450 of configurations. Constraints are not defined as part of the 451 base SDPng specification. 453 o Session Information: Optional meta information on the 454 conferences and individual components. 456 SDPng is application-agnostic with the base specification defining a 457 basic XML schema supporting the above. In order to actually use 458 SDPng, application-specific packages are needed. Packages define 459 things such as media types, codecs and their configuration 460 parameters, etc. The base SDPng specification includes a couple of 461 example packages to support audio, video, and RTP. 463 One approach to extending SDP with capability indication and 464 negotiation capabilities could be to adopt the mechanisms defined by 465 SDPng that are necessary to satisfy the requirements provided above. 466 Those areas could then be included within SDP itself, e.g. in the 467 form of one or more SDP attributes ("a=") containing the actual SDPng 468 description. The areas to consider here include: 470 o Capabilities: This would be needed to describe alternative media 471 formats and media format parameters. 473 o Configurations: This would be needed to define alternative 474 configurations 476 The constraints and session information parts of SDPng would not be 477 used. 479 The main advantages of such an approach would be: 481 o SDPng was designed and intended to solve the general capability 482 negotiation problems faced by SDP. A considerable amount of work 483 has already gone into it and it was originally targeted as the 484 long-term direction (replacement for SDP). 486 The disadvantages of such an approach would be: 488 o Duplicate Encoding and Specification Work: SDPng uses a 489 different coding format than SDP and hence all SDP parameters 490 (incl. codecs and transports) that need to be provided will need 491 to have an equivalent SDPng definition. There is currently no 492 automatic process for translating all SDP parameters or values 493 into corresponding SDPng parameters or values; many existing SDP 494 parameters and values currently have no corresponding SDPng 495 definition. 497 o SDPng is Work in Progress: SDPng is currently work in progress but 498 has seen limited interest and progress for a while. Adoption of a 499 subset of its current definition may end up differing from the 500 final specification. Also, the current SDPng specification needs 501 further clarification and semantic tightening in a number of areas 502 that would be of relevance to this approach. 504 o Negotiation of Transport Parameters: SDPng currently does not 505 support negotiation of transport parameters as individual 506 capabilities. It is however still possible to negotiate different 507 transport parameters by providing alternative configurations. 509 o Verbose Encoding and Large Message Size: SDPng descriptions are 510 XML documents, which are fairly verbose and result in descriptions 511 that are substantially larger than existing SDP. 513 3.4. Multipart/alternative 515 In [I-D.jenning-sipping-multipart], the use of multipart/alternative 516 MIME is proposed as a way to support multiple alternative offers. 517 Each alternative offer has an id associated with it by use of a new 518 MIME header field called Content-Answering-CID. The answerer chooses 519 one of the offers and performs normal offer/answer operation on that 520 offer, and then sends back a single answer which includes the 521 Content-Answering-CID value of the offer chosen. 523 The main advantages of this approach are: 525 o It allows for use of alternative encodings of the offer, e.g. SDP 526 and SDPng, as well as varying levels of confidentiality and 527 integrity by use of S/MIME [RFC3851]. 529 Use of multipart/alternative to solve the SDP capability negotiation 530 problems however has several shortcomings: 532 o Backwards Compatibility: Neither SIP nor RTSP mandate support 533 for Multipart MIME. In the case of SIP, multipart/alternative is 534 generally incompatible with existing SIP proxies, firewalls, 535 Session Border Controllers, and endpoints. 537 o Heterogeneous Error Response Forking Problem (HERFP): When a SIP 538 proxy forks a request to multiple Contacts, each of which generate 539 a response, the proxy only forwards the "best" of these responses 540 to the request originator. If one or more of the Contacts do not 541 support multipart/alternative, the request originator may never 542 discover this. Instead, only a Contact that supports 543 multipart/alternative will be able to generate an answer that 544 reaches the request originator. 546 o Combinatoric Explosions: Use of multipart/alternative to convey 547 alternatives on a per media stream basis or even per media format 548 parameter basis quickly leads to combinatoric explosions. 550 o Message Size: Each alternative requires full duplication of all 551 the relevant SDP parameters (one complete SDP per alternative). 553 It should be noted, that use of multipart/alternative has been 554 discussed several times before and, in large part due to the problems 555 mentioned above as well as the semantics defined for 556 multipart/alternative [RFC2046], has met with opposition when it 557 comes to addressing the above types of requirements. 559 3.5. Sharing Ports Between "m=" Lines 561 SDP [SDP] does not state whether two "m=" lines can share the same 562 transport address or not but rather leaves this explicitly undefined. 563 It has been suggested that alternative capabilities for a media 564 stream could be indicated by including multiple media stream 565 descriptions sharing the same transport address (i.e. using the same 566 port number in the "m=" line and sharing the same IP-address). 568 Such practice was not defined in [RFC2327], however it was 569 suggested in an Internet-Draft version of [SDP]. Following 570 discussion of the potential problems it introduced, it was removed. 572 The main advantages of this approach would be: 574 o May not require any additional extensions to SDP - only additional 575 semantics. 577 [Editor's note: It is somewhat unclear how it would work without 578 extensions if we allow for alternative attributes and media format 579 parameters and the offerer needs to always know which ones were 580 accepted] 582 The disadvantages of this approach would be: 584 o Backwards Compatibility Issues: Since sharing of transport 585 addresses between multiple streams was never specified as part of 586 SDP, backwards compatibility is likely to be an issue. Some 587 implementations may support it whereas others may not. The lack of 588 an explicit signaling indication to indicate the desired operation 589 may lead to ungraceful failure scenarios. Offer/answer semantics 590 would be unclear here as well. 592 o Some Combinatoric Explosion: The mechanism is not ideal to 593 indicate alternative capabilities for multiple parameters or media 594 formats within a particular media stream. For example, alternative 595 attribute values and media format parameters for several codecs 596 would lead to combinatoric explosion. 598 o Message Size: Each alternative requires full duplication of all 599 the relevant media stream parameters. 601 [Editor's note: In practice, it is not clear this is a huge issue 602 though.] 604 3.6. Opportunistic Encryption Using a Session Attribute 606 This approach was suggested to address the specific scenario of 607 negotiating either RTP or SRTP. The endpoints signal their desire to 608 do SRTP by listing RTP (RTP/AVP) as the transport protocol in the 609 "m=" line in the offer together with an attribute ("a=") that 610 indicates whether SRTP is supported or not. If the answerer supports 611 SRTP and wants to use it, the answer then includes SRTP (RTP/SAVP) as 612 the transport protocol in the "m=" line. 614 The main advantages of this approach are: 616 o Compatible with non-SRTP-aware endpoints. 618 The disadvantages of this approach are: 620 o Does not allow the offerer to indicate alternatives other than 621 SRTP (including vanilla RTP as an alternative to SRTP). 623 o Addresses only a small subset of the requirements provided above. 625 3.7. Best-Effort Secure Real-Time Transport Protocol 627 This approach is documented in [BESRTP]. The approach is similar to 628 the one described above, except it does not actually include any 629 explicit signaling indication as to the transport protocols 630 supported. Instead, support for the Secure RTP profile [SRTP] is 631 inferred based on the presence of the crypto attribute defined in 632 [SDES] and/or the key-mgmt attribute defined in [KMGMT]. 634 The main advantages of this approach are: 636 o Compatible with non-SRTP-aware endpoints. 638 The disadvantages of this approach are: 640 o Defines new semantics above and beyond those defined by RFC 3264, 641 RFC 4567, and RFC 4568 without any explicit signaling in the offer 642 to that effect. This in turn may lead to unintended side-effects. 644 Without explicit signaling indication, it is questionable to 645 infer that presence of e.g. a crypto parameter in the offer 646 indeed indicates that the offer wants to use the mechanism 647 defined by the proposal. Furthermore, Section 5.1.2 of [SDES] 648 defines generic operation where presence of a crypto attribute 649 without e.g. SRTP as the offered transport protocol could 650 result in the media stream being rejected. 652 o Does not allow the offerer to indicate alternatives other than the 653 inferred SRTP (including vanilla RTP as an alternative to SRTP). 655 o Addresses only a small subset of the requirements provided above. 657 3.8. Opportunistic Encryption using Probing 659 This is another approach suggested to address the specific scenario 660 of negotiating either RTP or SRTP. In this case, the endpoints first 661 establish an RTP session using RTP (RTP/AVP). The endpoints send 662 probe messages, over the media path, to determine if the remote 663 endpoint supports their keying technique. 665 The main advantages of this approach are: 667 o Compatible with non-SRTP-aware endpoints. 669 The disadvantages of this approach are: 671 o Addresses only a small subset of the requirements provided above. 673 4. Proposed Solution 675 Based on the requirements provided in Section 2. and the alternatives 676 examined in Section 3. the solution based on the Session Description 677 Protocol (SDP) Simple Capability Declaration (simcap) [RFC3407] with 678 extensions as outlined in Section 3.2. is preferred. In this section 679 we present that solution in detail. 681 4.1. Solution Overview 683 The solution consists of the following: 685 o The capability declaration mechanism defined by simcap [RFC3407] 686 with a few extensions. 688 o A new attribute ("a=capar") similar to the "a=cpar" attribute 689 defined by simcap, except with a handle that enables referencing 690 individual attribute capabilities (and for attributes only). 692 o A new attribute ("a=ctrpr") that defines how to list transport 693 protocols as capabilities. 695 o A new attribute ("a=pcfg") that lists the potential configurations 696 supported by the entity that generated the SDP. This is done by 697 reference to the extended simcap capabilities from the SDP in 698 question, and optionally one or more of the transport protocol 699 capabilities. The potential configurations are listed in order of 700 preference. 702 o A new attribute ("a=acfg") to be used in an answer SDP. The 703 attribute identifies which of the potential configurations from an 704 offer SDP were used as actual configurations to form the answer 705 SDP. This is done by listing the potential configurations that 706 were used from the offer SDP. 708 o Extensions to the offer/answer model that allow for potential 709 configurations to be included in an offer, where they constitute 710 offers that may be accepted by the answerer instead of the actual 711 configuration(s) included in the "m=" line(s). 713 The mechanism is illustrated by the offer/answer exchange below, 714 where Alice sends an offer to Bob: 716 Alice Bob 718 | (1) Offer (SRTP and RTP) | 719 |--------------------------------->| 720 | | 721 | (2) Answer (RTP) | 722 |<---------------------------------| 723 | | 725 Alice's offer includes RTP and SRTP as alternatives. RTP is the 726 default, but SRTP is the preferred one: 728 v=0 729 o=- 25678 753849 IN IP4 128.96.41.1 730 s= 731 c=IN IP4 128.96.41.1 732 t=0 0 733 m=audio 3456 RTP/AVP 0 18 734 a=sqn: 0 735 a=cdsc: 1 audio RTP/AVP 0 18 736 a=cdsc: 3 audio RTP/SAVP 0 18 737 a=capar: 1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 738 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 739 a=pcfg: c=3,4 a=1 740 a=pcfg: c=1,2 742 The "m=" line indicates that Alice is offering to use plain RTP with 743 PCMU or G.729. The extended simcap capability declaration is 744 provided by the "a=sqn" and "a=cdsc" attributes as defined in 745 [RFC3407], and the new "a=capar" attribute defined in this document. 746 The capabilities indicate that PCMU and G.729 are supported with 747 either RTP or secure RTP. The "capar" attribute provides a capability 748 parameter with a handle of 1. The capability parameter is a "crypto" 749 attribute in the capability set, which provides the keying material 750 for SRTP using SDP security descriptions [SDES]. The new "a=pcfg" 751 attribute provides the potential configurations included in the offer 752 by reference to the simcap capability declarations. Two alternatives 753 are provided; the first one, and hence the preferred one is using 754 capabilities 3 and 4, i.e. PCMU and G.729 under the RTP/SAVP profile 755 (secure RTP) together with the attribute capability parameter 1, i.e. 756 the crypto attribute provided. The second one is using capabilities 1 757 and 2, i.e. PCMU and G.729 under the RTP/AVP profile. 759 Bob receives the SDP offer from Alice. Bob supports RTP, but not 760 SRTP, and hence he accepts the potential configuration for RTP 761 provided by Alice: 763 v=0 764 o=- 24351 621814 IN IP4 128.96.41.2 765 s= 766 c=IN IP4 128.96.41.2 767 t=0 0 768 m=audio 4567 RTP/AVP 0 18 769 a=acfg: c=1,2 771 Bob includes the new "a=acfg" attribute in the answer to inform Alice 772 that he based his answer on an offer containing the potential 773 configuration with capabilities 1 and 2 from the offer SDP (i.e. PCMU 774 and G.729 under the RTP/AVP profile). Note that in this particular 775 example, the answerer supported the capability extensions defined 776 here, however had he not, everything would still have worked fine 777 since the actual configuration is what was being used. Consequently, 778 the answer would simply have omitted the "a=acfg" attribute line. 780 4.2. Extensions to Simcap 782 Simcap [RFC3407] defines capability descriptions to be on the form: 784 a=cdsc: 786 where is an integer between 1 and 255 (both included) used 787 to number the capabilities, and , , and 788 are defined as in the SDP "m=" line. We extend that definition here 789 to allow for wild-carding of the , and 790 parameters at the session level only. The wild-card character to use 791 is asterisk ("*"). This enables us to provide session level 792 capability parameters that are not specific to any particular media 793 stream, or applies only to certain types of media streams. Such 794 capability parameters apply to all media streams that match the 795 combined , and provided. 797 An example use case is to allow for negotiation of MIKEY at the 798 session level outside of a specific simcap capability description 799 (and hence media type) by use of the key management framework 800 [KMGMT]. 802 This is illustrated by the following examples: 804 a=cdsc: 1 * * * 806 a=cdsc: 2 audio * * 808 In the first example, the capability description applies to all media 809 stream. In the second example, the capability description applies to 810 media streams of type audio only. 812 Simcap capability descriptions start with a sequence number ("a=sqn") 813 and, as specified in [RFC3407], require that a capability description 814 as defined by simcap, i.e. an "a=cdsc" line, follows immediately 815 after the sequence number. We remove that requirement here. As a 816 result of that, we enable the new "a=capar" attribute (and other 817 parameters) to follow after the sequence number. There is however not 818 a requirement that it follows immediately after the sequence number. 820 4.3. Attribute Definitions 822 4.3.1. The Attribute Parameter Capability Attribute 824 Attributes can be expressed as negotiable parameters by use of a new 825 attribute parameter capability attribute ("a=capar") similar to the 826 "a=cpar" attribute defined by simcap, except with a handle that 827 enables referencing it and supporting attributes only (the "cpar" 828 attribute defined in RFC 3407 supports bandwidth information as 829 well). The attribute is defined as follows: 831 a=capar: 833 where is an integer between 1 and 255 (both included) 834 used to number the attribute parameter capability and is an 835 attribute ("a=") in its full '=' form (see [SDP]) 836 The "capar" attribute can be provided at the session level or the 837 media level. Each occurrence of the attribute MUST use a different 838 value of , with the first one being 1, the second one 839 being 2, etc. The values provided are independent of 840 similar values provided for other attributes, i.e., they 841 form a separate name-space for attribute parameter capabilities. 843 TO DO: There is a need to clarify the relationship between this 844 one, the simcap cpar values, and regular attributes (actual 845 configuration attributes). The basic idea is that attributes that 846 can only be used with certain potential configurations should be 847 provided here and then included by reference in those potential 848 configurations. 850 The following example illustrates use of the "capar" attribute: 852 a=capar: 1 a=ptime:20 854 a=capar: 2 a=ptime:30 856 a=capar: 3 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAA 857 AAAGEEoo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0 858 JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUO 859 SrzKTAv9zV 861 a=capar: 4 a=crypto:1 AES_CM_128_HMAC_SHA1_32 862 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 864 The first two ones provide attribute values for the ptime attribute. 865 The third one provides SRTP parameters by using MIKEY with the key- 866 mgmt attribute [KMGMT]. The fourth one provides SRTP parameters by 867 use of security descriptions with the crypto attribute [SDES]. 869 4.3.2. The Transport Protocol Capability Attribute 871 Transport Protocols can be expressed as capabilities by use of a new 872 Transport Protocol Capability attribute ("a=ctrpr") defined as 873 follows: 875 a=ctrpr: 877 where is an integer between 1 and 255 (both included) 878 used to number the transport address capability for later reference, 879 and is defined as in the SDP "m=" line. 881 The "ctrpr" attribute can be provided at either the session or media- 882 level. Each occurrence of the attribute MUST use a different value of 883 , with the first one being 1, the second one being 2, 884 etc. The values provided are independent of similar 885 values provided for other attributes, i.e., they form a 886 separate name-space for transport protocol capabilities. 888 Below, we provide examples of the "a=ctrpr" attribute: 890 a=ctrpr: 1 RTP/AVP 891 a=ctrpr: 2 RTP/AVPF 893 The first one provides a capability for the "RTP/AVP" profile defined 894 in [RFC3551] and the second one provides a capability for the RTP 895 with RTCP-Based Feedback profile defined in [AVPF]. 897 Note that the simcap extensions already provide similar functionality 898 by inclusion in the "cdsc" attribute (as illustrated by the example 899 in Section 4.1. ), however having this as a separate capability 900 indication can provide significant message size reduction when 901 negotiating alternative profiles (of which there can be many). In 902 particular, there is no need to repeat supported payload types. Also, 903 use of this attribute combined with the potential configuration 904 attribute (see Section 4.3.3. ) provides for more expressive power. 906 4.3.3. The Potential Configuration Attribute 908 Potential Configurations can be expressed by use of a new Potential 909 Configuration Attribute ("a=pcfg") defined as follows: 911 a=pcfg: 912 [] 913 [] 915 The potential configuration attribute includes one or more sets of 916 simcap-capabilities. A list of attribute parameter capabilities and a 917 list of transport protocol capabilities can optionally be included as 918 well. Together, these values define a set of potential 919 configurations. There can be one or more potential configuration 920 attributes provided at the session level as well as for each media 921 stream. The attributes are provided in order of preference. 923 TO DO: Clean up capability and configuration terminology. 925 is defined by the following ABNF: 927 simcap-capabilities = "c=" cap-list *("|" cap-list) 928 cap-list = cap-num *("," cap-num) 929 cap-num = 1*3DIGIT ; defined in [RFC4234] 931 Each capability list is a comma-separated list of simcap capability 932 numbers where cap-num refers to simcap capability numbers and hence 933 MUST be between 1 and 255 (both included). Alternative potential 934 simcap configurations are separated by a vertical bar ("|"). The 935 alternatives are ordered by preference. 937 is defined by the following ABNF: 939 attribute-parameter-capabilities 940 = "a=" capar-cap-list *("|" capar-cap-list) 941 capar-cap-list = att-cap-num *("," att-cap-num) 942 att-cap-num = 1*3DIGIT ;defined in [RFC4234] 944 Each attribute parameter capability list is a comma-separated list of 945 attribute capability parameter numbers where att-cap-num refers to 946 attribute parameter capability numbers defined above and hence MUST 947 be between 1 and 255 (both included). Alternative attribute parameter 948 capabilities are separated by a vertical bar ("|"). The alternatives 949 are ordered by preference. 951 is defined by the following ABNF: 953 transport-protocol-capabilities = 954 "p=" trpr-cap-num *("|" trpr-cap-num) 955 trpr-cap-num = 1*3DIGIT ; defined in [RFC4234] 957 The trpr-cap-num refers to transport protocol capability numbers 958 defined above and hence MUST be between 1 and 255 (both included). 959 Alternative transport protocol capabilities are separated by a 960 vertical bar ("|"). When transport protocol capabilities are not 961 included, the transport protocol information from the media 962 description ("m=" line) will be used. 964 The potential configuration ("a=pcfg") attribute can be provided at 965 the session level and the media-level. Each occurrence of the 966 attribute within a given media description ("m=" line) defines a set 967 of potential configurations that can be used for that media 968 description. 970 TO DO: Need to decide on relationship between session-level and 971 media-level (how should conflicts, overlap, etc. be handled - 972 simplicity at the possible expense of expressive power is 973 preferable in the editor's opinion). 975 Below, we provide an example of the "a=pcfg" attribute in a complete 976 media description in order to properly indicate the supporting 977 attributes: 979 v=0 980 o=- 25678 753849 IN IP4 128.96.41.1 981 s= 982 c=IN IP4 128.96.41.1 983 t=0 0 984 m=audio 3456 RTP/SAVPF 0 18 985 a=crypto:1 AES_CM_128_HMAC_SHA1_32 986 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 987 a=sqn: 0 988 a=cdsc: 1 audio RTP/SAVP 0 4 18 989 a=ctrpr: 1 RTP/AVP 990 a=ctrpr: 2 RTP/AVPF 991 a=ctrpr: 3 RTP/SAVP 992 a=ctrpr: 4 RTP/SAVPF 993 a=pcfg: c=1|3 p=1|2|3|4 994 a=pcfg: c=2 p=1 996 We have two potential configurations listed here. The first one 997 indicates that PCMU (payload type number 0 referenced by simcap 998 capability number 1) or G.729 (payload type number 18 referenced by 999 simcap capability number 3) can be supported with either of the 1000 profiles RTP/AVP, RTP/AVPF, RTP/SAVP, or RTP/SAVPF (specified by the 1001 transport protocol capability numbers 1,2,3 and 4). The second 1002 potential configuration indicates that G.723 (payload type number 4 1003 referenced by simcap capability number 2) can be supported with the 1004 RTP/AVP profile only (transport protocol capability number 1). 1006 4.3.4. The Actual Configuration Attribute 1008 The actual configuration attribute identifies which of the potential 1009 configurations from an offer SDP were used as actual configurations 1010 in an answer SDP. This is done by reference to the simcap 1011 capabilities, and the transport protocol (if included) capabilities 1012 from the offer that were actually used by the answerer in his 1013 offer/answer procedure. 1015 The Actual Configuration Attribute ("a=acfg") is defined as follows: 1017 a=acfg: 1018 [] 1019 [ is defined by the following ABNF: 1023 simcap-capability-list = "c=" cap-list 1024 cap-list = cap-num *("," cap-num) 1025 cap-num = 1*3DIGIT ; defined in [RFC4234] 1027 Each capability list is a comma-separated list of simcap capability 1028 numbers where cap-num refers to simcap capability numbers and hence 1029 MUST be between 1 and 255 (both included). 1031 is defined by the following ABNF: 1033 attribute-parameter-capabilities = "a=" capar-cap-list 1034 capar-cap-list = att-cap-num *("," att-cap-num) 1035 att-cap-num = 1*3DIGIT ;defined in [RFC4234] 1037 Each attribute parameter capability list is a comma-separated list of 1038 attribute capability parameter numbers where att-cap-num refers to 1039 attribute parameter capability numbers defined above and hence MUST 1040 be between 1 and 255 (both included). 1042 is defined by the following ABNF: 1044 transport-protocol-capability = "p=" trpr-cap-num 1045 trpr-cap-num = 1*3DIGIT ; defined in [RFC4234] 1047 The trpr-cap-num refers to transport protocol capability numbers 1048 defined above and hence MUST be between 1 and 255 (both included). 1049 When a transport protocol capability is not included, the transport 1050 protocol information from the media description ("m=" line) in the 1051 offer is being used. 1053 The actual configuration ("a=acfg") attribute can be provided at the 1054 session level and the media-level. There MUST NOT be more than one 1055 occurrence of an actual configuration attribute at the session level, 1056 and there MUST NOT be more than one occurrence of an actual 1057 configuration attribute within a given media description. 1059 Below, we provide an example of the "a=acfg" attribute (building on 1060 the previous example with the potential configuration attribute): 1062 v=0 1063 o=- 24351 621814 IN IP4 128.96.41.2 1064 s= 1065 c=IN IP4 128.96.41.2 1066 t=0 0 1067 m=audio 4567 RTP/AVPF 0 1068 a=acfg: c=1 p=2 1070 It indicates that the answerer used an offer consisting of simcap 1071 capability 1 from the offer (PCMU) and transport protocol capability 1072 2 from the offer (RTP/AVPF). 1074 4.4. Offer/Answer Model Extensions 1076 In this section, we define extensions to the offer/answer model 1077 defined in [RFC3264] to allow for potential configurations to be 1078 included in an offer, where they constitute offers that may be 1079 accepted by the answerer instead of the actual configuration(s) 1080 included in the "m=" line(s). 1082 [Editor's Note: Multicast considerations have been omitted for 1083 now.] 1085 TO DO: Elaborate and firm up offer/answer procedures. 1087 4.4.1. Generating the Initial Offer 1089 An offerer that wants to use capability negotiation extensions 1090 defined in this document MUST include the following in the offer: 1092 o one or more simcap capability descriptions (as defined in 1093 [RFC3407] and extended above) for each of the capabilities. 1095 o optionally, one or more attribute parameter capability attributes 1096 (as defined in Section 4.3.1. ) if one or more alternative 1097 attribute parameter values is to be negotiated. 1099 o optionally, one or more transport protocol capability attributes 1100 (as defined in Section 4.3.2. ) if one or more alternative 1101 transport protocols is to be negotiated. 1103 o one or more potential configuration attributes (as defined in 1104 Section 4.3.3. which define the potential configurations supported 1105 by the offerer. 1107 Each of the potential configurations listed constitutes an 1108 alternative offer which may be used to negotiate and establish the 1109 session. The current actual configuration is included in the "m=" 1110 line (as defined by [RFC3264]). 1112 4.4.2. Generating the Answer 1114 When the answerer receives an offer with one or more valid potential 1115 configuration information attributes present, it may use any of the 1116 potential configurations as an alternative offer. A potential 1117 configuration information attribute is valid if all of the 1118 capabilities (simcap, attribute capabilities and transport protocol) 1119 it references are present and valid themselves. 1121 The actual configuration is contained in the media description's "m=" 1122 line. The answerer can send media to the offerer in accordance with 1123 the actual configuration, however if it chooses to use one of the 1124 alternative potential configurations, media sent to the offerer may 1125 be discarded by the offerer until the answer is received. 1127 If the answerer chooses to accept one of the alternative potential 1128 configurations instead of the actual configuration, the answerer MUST 1129 generate an answer as if the offer contained that potential 1130 configuration instead of the actual configuration included. The 1131 answerer MUST also include an actual configuration attribute in the 1132 answer that identifies the potential configuration from the offer 1133 used by the answerer. The actual configuration attribute in the 1134 answer MUST include information about the capabilities. Furthermore, 1135 if the offered potential configuration included attribute capability 1136 parameters and/or transport protocol capabilities, those parameters 1137 MUST be included in the actual configuration attribute in the answer 1138 as well. 1140 4.4.3. Offerer Processing of the Answer 1142 When the offerer included potential configurations for a media 1143 stream, it MUST examine the answer for the presence of an actual 1144 configuration attribute for each such media stream. If the attribute 1145 is missing, offerer processing of the answer MUST proceed as defined 1146 by [RFC3264]. If the attribute is present, processing continues as 1147 follows: 1149 The actual configuration attribute specifies which of the potential 1150 configurations was used by the answerer to generate the answer. This 1151 includes all the types of capabilities from the potential 1152 configuration offered, i.e. the media formats ("cdsc" capabilities), 1153 attribute capability parameters ("capar") and transport protocol 1154 capabilities ("ctrpr") 1156 The offerer MUST now process the answer as if the offer had contained 1157 the potential configuration as the actual configuration in the media 1158 description ("m=" line) and relevant attributes in the offer. 1160 4.4.4. Modifying the Session 1162 Potential configurations may be included in subsequent offers as 1163 defined in [RFC3264, Section 8]. The procedure for doing so is 1164 similar to that described above with the answer including an 1165 indication of the actual configuration used by the answerer. 1167 5. Examples 1169 TBD. 1171 6. Security Considerations 1173 TBD. 1175 7. IANA Considerations 1177 TBD. 1179 8. To Do and Open Issues 1181 o Capability descriptions, potential configurations and actual 1182 configurations can be provided at both the session level and media 1183 level. It needs to be decided what the relationship between the 1184 session level and media level parameters are. 1186 o We are currently capping all capability numbers at 255. Is this a 1187 concern, not least considering the limits apply to the session, 1188 not just individual media streams. 1190 9. Acknowledgments 1192 Thanks to Francois Audet and Dan Wing for comments on this document. 1194 10. Change Log 1196 10.1. Changes since -00 1198 o Added requirements to allow for alternative attribute values to be 1199 negotiated at the session level. 1201 o Removed requirements to support unicast/multicast as alternatives 1202 and IPv4/IPv6 as alternatives. 1204 o Updated section 3.6. on opportunistic encryption using a session 1205 attribute 1207 o Added new section 3.7. on best-effort secure real-time transport 1208 protocol. 1210 o Updated solution to align with updated requirements. More 1211 specifically 1213 o Added minor extensions to simcap in new Section 4.2. 1215 o Removed the "a=ctrad" attribute that supported transport 1216 addresses as capabilities and updated the rest of the 1217 attributes and procedures accordingly. 1219 o Allowed for the "a=ctrpr" to be specified at the session level 1220 as well. 1222 o Updated semantics for the "a=pcfg" attribute to specify that 1223 potential configurations are listed in order of preference. 1225 o Defined a new attribute "a=capar" that enables the offerer to 1226 determine which of several possible alternative attributes 1227 from an offer was chosen by the answerer. 1229 o Updated example in Section 4.1. to illustrate backwards 1230 compatibility with a non-SRTP capable endpoint. 1232 o Updated open issues section and in particular noted issue 1233 around session level and media level parameter semantics 1234 overlap. 1236 11. References 1238 11.1. Normative References 1240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1241 Requirement Levels", BCP 14, RFC 2119, March 1997. 1243 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 1244 Syntax Specifications: ABNF", RFC 2234, Internet Mail 1245 Consortium and Demon Internet Ltd., November 1997. 1247 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 1248 with Session Description Protocol (SDP)", RFC 3264, June 1249 2002. 1251 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 1252 Capability Declaration", RFC 3407, October 2002. 1254 [RFC3605] C. Huitema, "Real Time Control Protocol (RTCP) attribute in 1255 Session Description Protocol (SDP)", RFC 3605, October 1256 2003. 1258 [RFC4234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 1259 Specifications: ABNF", RFC 4234, October 2005. 1261 [SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1262 Description Protocol", RFC 4566, July 2006. 1264 11.2. Informative References 1266 [RFC2046] Freed, N., and N. Borensteain, "Multipurpose Internet Mail 1267 Extensions (MIME) Part Two: Media Types", RFC 2046, 1268 November 1996. 1270 [RFC2327] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1271 Description Protocol", RFC 2327, April 1998. 1273 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1274 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 1275 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1277 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 1278 Schulzrinne, "Grouping of Media Lines in the Session 1279 Description Protocol (SDP)", RFC 3388, December 2002. 1281 [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and 1282 Video Conferences with Minimal Control", RFC 3551, July 1283 2003. 1285 [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1286 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1287 RFC 3711, March 2004. 1289 [RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 1290 (S/MIME) Version 3.1 Message Specification", RFC 3851, July 1291 2004. 1293 [RFC4091] Camarillo, G., and J. Rosenberg, The Alternative Network 1294 Address Types (ANAT) Semantics for the Session Description 1295 Protocol (SDP) Grouping Framework, RFC 4091, June 2005. 1297 [AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1298 "Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF)", 1299 Work in Progress, August 2004. 1301 [I-D.jennings-sipping-multipart] Wing, D., and C. Jennings, "Session 1302 Initiation Protocol (SIP) Offer/Answer with Multipart 1303 Alternative", Work in Progress, March 2006. 1305 [SAVPF] Ott, J., and E Carrara, "Extended Secure RTP Profile for 1306 RTCP-based Feedback (RTP/SAVPF)", Work in Progress, 1307 December 2005. 1309 [SDES] Andreasen, F., Baugher, M., and D. Wing, "Session 1310 Description Protocol Security Descriptions for Media 1311 Streams", RFC 4568, July 2006. 1313 [SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session Description 1314 and Capability Negotiation", Work in Progress, February 1315 2005. 1317 [BESRTP] Kaplan, H., and F. Audet, "Session Description Protocol 1318 (SDP) Offer/Answer Negotiation for Best-Effort Secure Real- 1319 Time Transport Protocol, Work in progress, August 2006. 1321 [KMGMT] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1322 Carrara, "Key Management Extensions for Session Description 1323 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 1324 RFC 4567, July 2006. 1326 Author's Addresses 1328 Flemming Andreasen 1329 Cisco Systems 1330 Edison, NJ 1332 Email: fandreas@cisco.com 1334 Intellectual Property Statement 1336 The IETF takes no position regarding the validity or scope of any 1337 Intellectual Property Rights or other rights that might be claimed to 1338 pertain to the implementation or use of the technology described in 1339 this document or the extent to which any license under such rights 1340 might or might not be available; nor does it represent that it has 1341 made any independent effort to identify any such rights. Information 1342 on the procedures with respect to rights in RFC documents can be 1343 found in BCP 78 and BCP 79. 1345 Copies of IPR disclosures made to the IETF Secretariat and any 1346 assurances of licenses to be made available, or the result of an 1347 attempt made to obtain a general license or permission for the use of 1348 such proprietary rights by implementers or users of this 1349 specification can be obtained from the IETF on-line IPR repository at 1350 http://www.ietf.org/ipr. 1352 The IETF invites any interested party to bring to its attention any 1353 copyrights, patents or patent applications, or other proprietary 1354 rights that may cover technology that may be required to implement 1355 this standard. Please address the information to the IETF at 1356 ietf-ipr@ietf.org. 1358 Disclaimer of Validity 1360 This document and the information contained herein are provided on an 1361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1363 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1364 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1365 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1368 Copyright Statement 1370 Copyright (C) The Internet Society (2006). 1372 This document is subject to the rights, licenses and restrictions 1373 contained in BCP 78, and except as set forth therein, the authors 1374 retain all their rights. 1376 Acknowledgment 1378 Funding for the RFC Editor function is currently provided by the 1379 Internet Society.