idnits 2.17.1 draft-ietf-mmusic-sdp-capability-negotiation-reqts-00.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 982. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 966. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 972. ** 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 23 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 388 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (December 17, 2006) is 6340 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 616, but not defined == Unused Reference: 'RFC2234' is defined on line 845, but no explicit reference was found in the text == Unused Reference: 'RFC3605' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'RFC4234' is defined on line 860, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'I-D.jennings-sipping-multipart' is defined on line 903, 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) -- No information found for draft-jennings-sipping-multipart - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 12 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: June 2007 December 17, 2006 6 SDP Capability Negotiation: 7 Requirements and Review of Existing Work 9 draft-ietf-mmusic-sdp-capability-negotiation-reqts-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on June 17, 2007. 37 Abstract 39 The Session Description Protocol (SDP) was intended for describing 40 multimedia sessions for the purposes of session announcement, session 41 invitation, and other forms of multimedia session initiation. SDP was 42 not intended to provide capability indication or capability 43 negotiation, however over the years, SDP has seen widespread adoption 44 and as a result it has been gradually extended to provide limited 45 support for these. SDP and its current extensions however do not 46 have, for example, the ability to negotiate one or more alternative 47 transport protocols (e.g. RTP profiles) which makes it particularly 48 difficult to deploy new RTP profiles such as secure RTP and RTP with 49 RTCP-based feedback. The purpose of this document is to identify a 50 set of requirements for SDP Capability Negotiation and evaluate 51 existing work in this area. The document does not provide any 52 solutions to SDP Capability Negotiation 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [RFC2119]. 60 Table of Contents 62 1. Introduction...................................................3 63 2. Requirements...................................................5 64 3. Review of Existing Work.......................................10 65 3.1. Grouping of Media Lines..................................10 66 3.2. Session Description Protocol (SDP) Simple Capability 67 Declaration...................................................11 68 3.3. Session Description and Capability Negotiation (SDPng)...12 69 3.4. Multipart/alternative....................................14 70 3.5. Sharing Ports Between "m=" Lines.........................15 71 3.6. Opportunistic Encryption Using a Session Attribute.......16 72 3.7. Best-Effort Secure Real-Time Transport Protocol..........16 73 3.8. Opportunistic Encryption using Probing...................17 74 4. Security Considerations.......................................18 75 5. IANA Considerations...........................................18 76 6. Acknowledgments...............................................18 77 7. Change Log....................................................18 78 7.1. draft-ietf-mmusic-sdp-capability-negotiation-reqts-00.txt18 79 7.2. draft-andreasen-mmusic-sdp-capability-negotiation-reqts- 80 00.txt........................................................19 81 8. References....................................................20 82 8.1. Normative References.....................................20 83 8.2. Informative References...................................20 84 Author's Addresses...............................................22 85 Intellectual Property Statement..................................22 86 Disclaimer of Validity...........................................23 87 Copyright Statement..............................................23 88 Acknowledgment...................................................23 90 1. Introduction 92 The Session Description Protocol (SDP) was intended for describing 93 multimedia sessions for the purposes of session announcement, session 94 invitation, and other forms of multimedia session initiation. The SDP 95 contains one or more media stream descriptions with information such 96 as IP-address and port, type of media stream (e.g. audio or video), 97 transport protocol (possibly including profile information, e.g. 98 RTP/AVP or RTP/SAVP), media formats (e.g. codecs), and various other 99 session and media stream parameters that define the session. 101 Simply providing media stream descriptions is sufficient for session 102 announcements for a broadcast application, where the media stream 103 parameters are fixed for all participants. When a participant wants 104 to join the session, he obtains the session announcement and uses the 105 media descriptions provided, e.g., joins a multicast group and 106 receives media packets in the encoding format specified. If the 107 media stream description is not supported by the participant, he is 108 unable to receive the media. 110 Such restrictions are not generally acceptable to conversational 111 multimedia session invitations, where two or more entities attempt to 112 establish a media session using a set of media stream parameters 113 acceptable to all participants. First of all, each entity must inform 114 the other of its receive address, and secondly, the entities need to 115 agree on the media stream parameters to use for the session, e.g. 116 transport protocols and codecs. We here make a distinction between 117 the capabilities supported by each participant and the parameters 118 that can actually be used for the session. More generally, we can say 119 that we have the following: 121 o A set of capabilities, or potential configurations of the media 122 stream components, supported by each side. 124 o A set of actual configurations of the media stream components, 125 which specifies which media stream components to use and with what 126 parameters. 128 o A negotiation process that takes the set of potential 129 configurations (capabilities) as input and provides the actual 130 configurations as output. 132 SDP by itself was designed to provide only the second of these, i.e., 133 the actual configurations, however over the years, use of SDP has 134 been extended beyond its original scope. Session negotiation 135 semantics were defined by the offer/answer model in RFC 3264 136 [RFC3264]. It defines how two entities, an offerer and an answerer, 137 exchange session descriptions to negotiate a session. The offerer can 138 include one or more media formats (codecs) per media stream, and the 139 answerer then selects one or more of those offered and returns them 140 in an answer. Both the offer and the answer contain actual 141 configurations - potential configurations are not supported. The 142 answer however may reduce the set of actual configurations from the 143 offer. The answerer may also include additional media formats in the 144 answer, however those media formats can only be used in the answerers 145 receive direction. Such additional media formats would be actual 146 configurations as well. 148 Other relevant extensions have been defined. Simple capability 149 declarations, which defines how to provide a simple and limited set 150 of capability descriptions in SDP was defined in RFC 3407. Grouping 151 of media lines, which defines how media lines in SDP can have other 152 semantics than the traditional "simultaneous media streams" 153 semantics, was defined in RFC 3388, etc. 155 Each of these extensions was designed to solve a specific limitation 156 of SDP. Since SDP had already been stretched beyond its original 157 intent, a more comprehensive capability declaration and negotiation 158 process was intentionally not defined. Instead, work on a "next 159 generation" of a protocol to provide session description and 160 capability negotiation was initiated [SDPng]. SDPng however has not 161 gained traction and has remained as work in progress for an extended 162 period of time. Existing real-time multimedia communication 163 protocols such as SIP, RTSP, Megaco, and MGCP continue to use SDP. 164 SDP and its current extensions however do not address an increasingly 165 important problem: the ability to negotiate one or more alternative 166 transport protocols (e.g., RTP profiles). This makes it difficult to 167 deploy new RTP profiles such as secure RTP (SRTP) [SRTP], RTP with 168 RTCP-Based Feedback [AVPF], etc. This particular problem is 169 exacerbated by the fact that RTP profiles are defined independently. 170 When a new profile is defined and N other profiles already exist, 171 there is a potential need for defining N additional profiles, since 172 profiles cannot be combined automatically. For example, in order to 173 support the plain and secure RTP version of RTP with and without 174 RTCP-based feedback, four separate profiles (and hence profile 175 definitions) are needed: RTP/AVP [RFC3551], RTP/SAVP [SRTP], RTP/AVPF 176 [AVPF], and RTP/SAVPF [SAVPF]. In addition to the pressing profile 177 negotiation problem, other important real-life constraints have been 178 found as well. 180 The purpose of this document is two-fold. 182 1. Identify a set of requirements for a SDP capability negotiation 183 mechanism that will enable SDP to provide limited support for 184 indicating potential configurations (capabilities) and negotiate the 185 use of those potential configurations as actual configurations. 187 2. Review relevant existing work in the area of SDP capability 188 negotiation and see how it aligns with the proposed requirements. 190 It should be noted, that it is not the intent to provide requirements 191 for a full-fledged capability indication and negotiation mechanism 192 along the lines of SDPng [SDPng] or ITU-T H.245 [H245]. Rather, the 193 focus is on identifying requirements for addressing a set of well- 194 known real-life limitations. 196 The rest of the document is structured as follows. In Section 2, we 197 provide a set of requirements for SDP capability negotiation, and in 198 Section 3, we review relevant existing work in this area, how a 199 solution based on that work might look, and the pros and cons 200 associated with each. An actual solution to the proposed requirements 201 will be provided separately. 203 2. Requirements 205 REQ-10: It MUST be possible to indicate and negotiate alternative 206 media formats on a per media stream basis. 208 For example, many implementations support multiple codecs, but 209 only one at a time. Changes between codecs cannot be done on- 210 the-fly, e.g. when receiving a simple RTP payload type change. 212 REQ-20: It MUST be possible to indicate and negotiate alternative 213 attribute values ("a=") on a per media stream basis. 215 For example, T.38 [T38] defines new attributes that may need to 216 be conveyed as part of a capability. Also, alternative SRTP 217 keying mechanisms (e.g. [SDES] and [KMGMT]) may use SDP 218 attributes to negotiate SRTP keying material. 220 REQ-25: It MUST be possible to indicate and negotiate alternative 221 attribute values ("a=") at the session level. 223 For example, [KMGMT] may indicate alternative key management 224 material for MIKEY [MIKEY] at the session level. 226 REQ-30: It MUST be possible to indicate and negotiate alternative 227 media format parameter values ("a=fmtp") per media format on a per 228 media stream basis. 230 For example, a media format (codec) indicated as an alternative 231 capability may include fmtp parameters. 233 REQ-40: It MUST be possible to indicate and negotiate alternative 234 transport protocols, e.g. different RTP profiles, on a per media 235 stream basis. 237 For example, "RTP/AVP" and "RTP/SAVP" may be alternatives. 239 REQ-50: It MUST be possible to indicate and negotiate alternative 240 transport protocol and media type combinations on a per media stream 241 basis. 243 For example, an entity may support a fax call using either T.38 244 fax relay ("m=image udptl t38") or PCMU ("m=audio 245 RTP/AVP 0"). 247 [Editor's note: This requirement may have interactions with ICE - 248 need to consider those further] 250 REQ-80: The mechanism MUST be backwards compatible for SIP endpoints; 251 an entity that does not support the mechanism should behave as if the 252 mechanism was not present in the signaling the first place. 254 The above is referred to as "best-case" backwards compatibility. 255 Another form of backwards compatibility could result in an error 256 message indicating the extension is not supported, however this 257 has undesirable side-effects for SIP (heterogeneous error 258 response forking problem - HERFP) and leads to additional 259 signaling. Another form of backwards compatibility would have an 260 entity that does not support the extension behaving differently 261 than it normally would (but not failing), possibly followed by 262 additional signaling to remedy this. 264 REQ-85: The mechanism SHOULD attempt to be as backwards compatible 265 and friendly as reasonably possible for SIP middle-boxes. A SIP 266 middle-box is here defined as a SIP entity between two SIP endpoints 267 in a session, that may or may not have the media associated with the 268 SIP session traverse through it. In either case, the middle box may 269 have a need to understand the details of the media streams for the 270 session. 272 For example, a SIP middle-box may inspect the SDP exchanged to 273 determine what Quality of Service to authorize for the associated 274 media streams. While such middle boxes are not part of the SIP 275 architecture or the Internet per se, they do exist in many real 276 life scenarios, and we have a desire to provide a solution for 277 those. 279 REQ-90: The mechanism MUST either be backwards compatible for Megaco 280 and MGCP or it MUST be possible to interwork it with Megaco and MGCP 281 without any additional signaling between the MGC and its peer (e.g. 282 another SIP UA as opposed to a media gateway). 284 For example, if a media gateway controller (MGC) uses SIP to 285 communicate with peers, and the MGC uses Megaco or MGCP to 286 control a media gateway, it must be possible to translate between 287 the mechanism and normal SDP. Avoiding interworking requirements 288 in the MGC is desirable. 290 REQ-100: The mechanism MUST work within the context of the 291 offer/answer model [RFC3264]. Specifically, it MUST be possible to 292 negotiate alternatives within a single offer/answer exchange. 294 REQ-110: The offer/answer model requires the offerer to be able to 295 receive media for any media streams listed as either "recvonly" or 296 "sendrecv" in an offer, as soon as that offer is generated. The 297 mechanism MUST preserve this capability for all actual configurations 298 included in an offer. 300 Potential configurations do not have such a requirement. 302 REQ-120: The mechanism MUST enable inclusion of potential 303 configurations (alternative capabilities) in the offer - the answer 304 would then indicate which, if any of these potential configurations 305 were accepted. The offerer is not required to process media for a 306 specific potential configuration until the offerer receives an answer 307 showing that potential configuration was accepted. 309 Note that this implies that it may not be possible for the 310 offerer to process early media generated using a potential 311 configuration (as opposed to the actual configuration) until the 312 answer has been received. 314 REQ-121: The mechanism SHOULD enable inclusion of potential 315 configurations for each offered media stream in the answer. The 316 offerer may wish to use such potential configurations as input to 317 generating additional offers subsequently. 319 REQ-122: The mechanism SHOULD enable inclusion of additional media 320 streams beyond those offered in the offer or accepted in the answer 321 as latent potential configurations, provided this does not unduly 322 complicate the mechanism. Latent potential configurations cannot be 323 promoted to actual configurations in the current offer/answer 324 exchange. 326 For example, an offerer that offers only audio, but is also able 327 to support video, may want to indicate this. Similarly, an 328 answerer that receives an offer for audio only, but is able to do 329 video may want to indicate this. Such capabilities are purely 330 information in the current offer/answer exchange - use of them 331 cannot be negotiated until a new offer/exchange is performed. 333 REQ-130: The mechanism MUST work as well as existing offer/answer 334 procedures in the presence of SIP forking. The mechanism MUST NOT 335 introduce any new failure scenarios for SIP forking. 337 REQ-140: The mechanism SHOULD be reasonably efficient in terms of 338 overall message size. 340 This is a relative requirement to evaluate alternative solutions 341 as opposed to an absolute and quantifiable requirement. Use of 342 compression techniques can help reduce the size of text-based 343 messages, however it is still considered important to try and 344 keep the message size reasonably small. 346 REQ-150: It SHOULD be possible to specify valid combinations of media 347 lines. 349 For example, an entity may be able to support audio and video or 350 audio and IM, but not video and IM (or all three). 352 REQ-160: It SHOULD be possible to specify valid combinations of media 353 formats between media streams. 355 For example, there may be constraints on which combinations of 356 audio and video codecs can be supported. 358 REQ-170: The mechanism MUST be extensible and allow for new types of 359 capabilities to be specified and used in potential and actual 360 configurations. 362 For example, the mechanism could be extended to negotiate unicast 363 or multicast addresses as alternatives. 365 REQ-300: The mechanism provided MUST be modular inasmuch as it can be 366 divided into a required core set of functionality that all entities 367 MUST support and an optional set of enhancements that entities MAY 368 support. Entities that implement different sets of enhancements MUST 369 be fully interoperable, albeit possibly with reduced functionality in 370 terms of the actual negotiation performed. 372 For example, not all entities may implement support for REQ-150 373 and REQ-160 375 REQ-301: The mechanism MUST provide a way for both the offerer and 376 the answerer to indicate the current version(s) of the mechanism 377 supported as well as the enhancements supported. 379 REQ-302: The mechanism MUST provide a way for the offerer to indicate 380 the version and enhancements that are used by the offerer and must be 381 supported by the answerer (and vice versa), in order to correctly 382 process the SDP capability negotiation in the offer (or answer). 384 Note that this requirement applies to the SDP capability 385 negotiation part of the SDP only - other SDP extensions are 386 unaffected by this. 388 REQ-310: The following requirements are considered enhancements as 389 defined in REQ-300: 391 * REQ-50 (alternative combinations of transport protocol and media 392 type) 394 * REQ-150 (valid combinations of media lines) 396 * REQ-160 (valid combinations of media formats between media 397 streams) 399 [Editor's Note: Should we have any security requirements - see e.g. 400 Section 4. 402 [Editor's Note: Need to consider layered codecs and how they may 403 impact the requirements] 405 Above, we presented the requirements for the capability negotiation 406 mechanism. Below, we provide a set of features that were considered 407 and then explicitly deemed to be out-of-scope: 409 o Support for negotiation of unicast and multicast addresses as 410 alternatives. It was suggested as a requirement initially, but 411 subsequent discussion led to its removal. 413 o Support for negotiation of IPv4 and IPv6 addresses as 414 alternatives. It was suggested as a requirement initially, but 415 subsequent discussion led to its removal. 417 If necessary, it should be possible to define such capabilities in 418 the form of extensions. 420 3. Review of Existing Work 422 In this section, we provide an overview of existing relevant work 423 that has either been completed or is work in progress. For each 424 item, we outline how/if it can be used to address the requirements 425 provided and the pros and cons of doing so. 427 3.1. Grouping of Media Lines 429 Grouping of Media Lines is defined in [RFC3388]. RFC 3388 defines a 430 framework that enables two or more media lines to be grouped together 431 for different purposes. Each media line is assigned an identifier and 432 one or more group attributes then references two or more of those 433 identifiers. Associated with each group attribute is a semantics 434 indication. One semantic indication is the Alternative Network 435 Address Types ("ANAT") [RFC4091] which allows for IPv4 and IPv6 436 addresses to be specified as alternatives. The requirements presented 437 above go beyond that, however a new semantic to simply indicate 438 alternative media lines and associated negotiation rules could easily 439 be defined. 441 The main advantages of such an approach would be: 443 o Mechanism Reuse: Several semantics have already been defined 444 which increases the likelihood of an implementation supporting the 445 framework. 447 The disadvantages of such an approach would be: 449 o Backwards Compatibility: The mechanism is not transparently 450 backwards compatible. If an entity that does not support the 451 mechanism receives it, the entity may incorrectly interpret the 452 SDP as consisting of multiple media streams. While RFC 3388 453 defines procedures for recognizing and recover from this when 454 using offer/answer, it can still lead to unintended behavior with 455 endpoints that do not support the mechanism. 457 In practice, it is not clear how much of an issue this is, at 458 least for intelligent SIP endpoints. Most current 459 implementations generally accept only one media stream of a 460 given type (e.g. audio). Use of alternatives with different 461 media stream types (e.g. a fax call using "audio" for voice- 462 band data or "image" for T.38) makes it less clear though. 463 Also, Media Gateway Controllers and Media Gateways that do not 464 support grouping of media lines have been known to encounter 465 problems. 467 o Semantics Combination Issues: Multiple semantics may be provided 468 by use of grouping, however they may interact with each other 469 unintentionally. For example, the "FID" semantics defined in RFC 470 3388 forbids grouping of media lines with the same transport 471 address, however that would be needed for alternative 472 capabilities. Thus, using "FID" and alternative capabilities 473 together would require special consideration. 475 o Some Combinatoric Explosion: The mechanism is not ideal to 476 indicate alternative capabilities for multiple parameters or media 477 formats within a particular media stream. For example, alternative 478 attribute values and media format parameters for several codecs 479 would lead to combinatoric explosion. 481 [Editor's note: In practice, it is not clear this is a huge issue 482 though.] 484 o Message Size: Each alternative requires full duplication of all 485 the relevant media stream parameters. 487 [Editor's note: In practice, it is not clear this is a huge issue 488 though.] 490 3.2. Session Description Protocol (SDP) Simple Capability Declaration 492 SDP Simple Capability Declaration (simcap) is defined in [RFC3407]. 493 It defines a set of SDP attributes that enables capabilities to be 494 described at a session level or on a per media stream basis. RFC 495 3407 defines capability declaration only - actual negotiation 496 procedures taking advantage of such capabilities have not been 497 defined. Such rules however could easily be defined - the negotiation 498 part would extend the offer/answer model to examine alternative 499 configurations (capabilities). In conjunction with that, attributes 500 to indicate the alternative configurations accepted would likely be 501 needed as well. 503 The main advantages of this approach are: 505 o Satisfies most of the requirements provided above. In particular, 506 by relying solely on SDP attributes, transparent backwards 507 compatibility is always ensured. 509 The disadvantages of this approach are: 511 o Offered Capabilities Hidden in Attributes: An offer may be 512 accepted by the answerer and a media stream established based on 513 SDP parameters contained in SDP attributes not known to 514 intermediaries. Such intermediaries may be back-to-back user 515 agents, or proxies that need to inspect the SDP, e.g., to 516 authorize Quality of Service, add transcoders, etc. 518 o Maximum of 255 alternative media formats per SDP: RFC 3407 519 currently allows a maximum of 255 alternative media formats 520 (codecs) per SDP. This may be too restrictive. 522 3.3. Session Description and Capability Negotiation (SDPng) 524 The Session Description and Capability Negotiation protocol [SDPng] 525 was intended as a replacement for SDP [SDP]. SDPng includes a full 526 capability indication and negotiation framework that would address 527 the shortcomings of SDP and satisfy the requirements provided above. 528 However, SDPng has not gained traction, in large part due to existing 529 widespread adoption of SDP. As a consequence, SDPng has remained as 530 work in progress with limited progress for an extended period of 531 time. 533 SDPng consists of two things: an SDPng description, which is an XML 534 document that describes the actual and/or potential configurations as 535 well as an optional negotiation process (an offer/answer compliant 536 process is included as part of SDPng). The SDPng description consists 537 of up to five parts: 539 o Capabilities: An optional list of capabilities (potential 540 configurations) to be matched with the other parties' 541 capabilities. 543 o Definitions: An optional set of definitions of commonly used 544 parameters for later referencing. 546 o Configurations: A mandatory description of the conference 547 components, each of which can provide a list of alternative 548 configurations. 550 o Constraints: An optional set of constraints of combinations 551 of configurations. Constraints are not defined as part of the 552 base SDPng specification. 554 o Session Information: Optional meta information on the 555 conferences and individual components. 557 SDPng is application-agnostic with the base specification defining a 558 basic XML schema supporting the above. In order to actually use 559 SDPng, application-specific packages are needed. Packages define 560 things such as media types, codecs and their configuration 561 parameters, etc. The base SDPng specification includes a couple of 562 example packages to support audio, video, and RTP. 564 One approach to extending SDP with capability indication and 565 negotiation capabilities could be to adopt the mechanisms defined by 566 SDPng that are necessary to satisfy the requirements provided above. 567 Those areas could then be included within SDP itself, e.g. in the 568 form of one or more SDP attributes ("a=") containing the actual SDPng 569 description. The areas to consider here include: 571 o Capabilities: This would be needed to describe alternative media 572 formats and media format parameters. 574 o Configurations: This would be needed to define alternative 575 configurations 577 The constraints and session information parts of SDPng would not be 578 used. 580 The main advantages of such an approach would be: 582 o SDPng was designed and intended to solve the general capability 583 negotiation problems faced by SDP. A considerable amount of work 584 has already gone into it and it was originally targeted as the 585 long-term direction (replacement for SDP). 587 The disadvantages of such an approach would be: 589 o Duplicate Encoding and Specification Work: SDPng uses a 590 different coding format than SDP and hence all SDP parameters 591 (incl. codecs and transports) that need to be provided will need 592 to have an equivalent SDPng definition. There is currently no 593 automatic process for translating all SDP parameters or values 594 into corresponding SDPng parameters or values; many existing SDP 595 parameters and values currently have no corresponding SDPng 596 definition. 598 o SDPng is Work in Progress: SDPng is currently work in progress but 599 has seen limited interest and progress for a while. Adoption of a 600 subset of its current definition may end up differing from the 601 final specification. Also, the current SDPng specification needs 602 further clarification and semantic tightening in a number of areas 603 that would be of relevance to this approach. 605 o Negotiation of Transport Parameters: SDPng currently does not 606 support negotiation of transport parameters as individual 607 capabilities. It is however still possible to negotiate different 608 transport parameters by providing alternative configurations. 610 o Verbose Encoding and Large Message Size: SDPng descriptions are 611 XML documents, which are fairly verbose and result in descriptions 612 that are substantially larger than existing SDP. 614 3.4. Multipart/alternative 616 In [I-D.jenning-sipping-multipart], the use of multipart/alternative 617 MIME is proposed as a way to support multiple alternative offers. 618 Each alternative offer has an id associated with it by use of a new 619 MIME header field called Content-Answering-CID. The answerer chooses 620 one of the offers and performs normal offer/answer operation on that 621 offer, and then sends back a single answer which includes the 622 Content-Answering-CID value of the offer chosen. 624 The main advantages of this approach are: 626 o It allows for use of alternative encodings of the offer, e.g. SDP 627 and SDPng, as well as varying levels of confidentiality and 628 integrity by use of S/MIME [RFC3851]. 630 Use of multipart/alternative to solve the SDP capability negotiation 631 problems however has several shortcomings: 633 o Backwards Compatibility: Neither SIP nor RTSP mandate support 634 for Multipart MIME. In the case of SIP, multipart/alternative is 635 generally incompatible with existing SIP proxies, firewalls, 636 Session Border Controllers, and endpoints. 638 o Heterogeneous Error Response Forking Problem (HERFP): When a SIP 639 proxy forks a request to multiple Contacts, each of which generate 640 a response, the proxy only forwards the "best" of these responses 641 to the request originator. If one or more of the Contacts do not 642 support multipart/alternative, the request originator may never 643 discover this. Instead, only a Contact that supports 644 multipart/alternative will be able to generate an answer that 645 reaches the request originator. 647 o Combinatoric Explosions: Use of multipart/alternative to convey 648 alternatives on a per media stream basis or even per media format 649 parameter basis quickly leads to combinatoric explosions. 651 o Message Size: Each alternative requires full duplication of all 652 the relevant SDP parameters (one complete SDP per alternative). 654 It should be noted, that use of multipart/alternative has been 655 discussed several times before and, in large part due to the problems 656 mentioned above as well as the semantics defined for 657 multipart/alternative [RFC2046], has met with opposition when it 658 comes to addressing the above types of requirements. 660 3.5. Sharing Ports Between "m=" Lines 662 SDP [SDP] does not state whether two "m=" lines can share the same 663 transport address or not but rather leaves this explicitly undefined. 664 It has been suggested that alternative capabilities for a media 665 stream could be indicated by including multiple media stream 666 descriptions sharing the same transport address (i.e. using the same 667 port number in the "m=" line and sharing the same IP-address). 669 Such practice was not defined in [RFC2327], however it was 670 suggested in an Internet-Draft version of [SDP]. Following 671 discussion of the potential problems it introduced, it was removed. 673 The main advantages of this approach would be: 675 o May not require any additional extensions to SDP - only additional 676 semantics. 678 [Editor's note: It is somewhat unclear how it would work without 679 extensions if we allow for alternative attributes and media format 680 parameters and the offerer needs to always know which ones were 681 accepted] 683 The disadvantages of this approach would be: 685 o Backwards Compatibility Issues: Since sharing of transport 686 addresses between multiple streams was never specified as part of 687 SDP, backwards compatibility is likely to be an issue. Some 688 implementations may support it whereas others may not. The lack of 689 an explicit signaling indication to indicate the desired operation 690 may lead to ungraceful failure scenarios. Offer/answer semantics 691 would be unclear here as well. 693 o Some Combinatoric Explosion: The mechanism is not ideal to 694 indicate alternative capabilities for multiple parameters or media 695 formats within a particular media stream. For example, alternative 696 attribute values and media format parameters for several codecs 697 would lead to combinatoric explosion. 699 o Message Size: Each alternative requires full duplication of all 700 the relevant media stream parameters. 702 [Editor's note: In practice, it is not clear this is a huge issue 703 though.] 705 3.6. Opportunistic Encryption Using a Session Attribute 707 This approach was suggested to address the specific scenario of 708 negotiating either RTP or SRTP. The endpoints signal their desire to 709 do SRTP by listing RTP (RTP/AVP) as the transport protocol in the 710 "m=" line in the offer together with an attribute ("a=") that 711 indicates whether SRTP is supported or not. If the answerer supports 712 SRTP and wants to use it, the answer then includes SRTP (RTP/SAVP) as 713 the transport protocol in the "m=" line. 715 The main advantages of this approach are: 717 o Compatible with non-SRTP-aware endpoints. 719 The disadvantages of this approach are: 721 o Does not allow the offerer to indicate alternatives other than 722 SRTP (including vanilla RTP as an alternative to SRTP). 724 o Addresses only a small subset of the requirements provided above. 726 3.7. Best-Effort Secure Real-Time Transport Protocol 728 This approach is documented in [BESRTP]. The approach is similar to 729 the one described above, except it does not actually include any 730 explicit signaling indication as to the transport protocols 731 supported. Instead, support for the Secure RTP profile [SRTP] is 732 inferred based on the presence of the crypto attribute defined in 733 [SDES] and/or the key-mgmt attribute defined in [KMGMT]. The draft 734 also proposes the use of separate payload types for codecs being used 735 under different profiles as a way to enable the offerer to process 736 early media packets (especially non-secure ones) prior to receiving 737 an answer (which includes the selected profiles and, in some cases, 738 information about SRTP keying material). 740 The main advantages of this approach are: 742 o Compatible with non-SRTP-aware endpoints. 744 o Provides a (separable) solution to disambiguating secure from non- 745 secure RTP packets before receiving an answer. 747 The disadvantages of this approach are: 749 o Defines new semantics above and beyond those defined by RFC 3264, 750 RFC 4567, and RFC 4568 without any explicit signaling in the offer 751 to that effect. This in turn may lead to unintended side-effects. 753 Without explicit signaling indication, it is questionable to 754 infer that presence of e.g. a crypto parameter in the offer 755 indeed indicates that the offer wants to use the mechanism 756 defined by the proposal. Furthermore, Section 5.1.2 of [SDES] 757 defines generic operation where presence of a crypto attribute 758 without e.g. SRTP as the offered transport protocol could 759 result in the media stream being rejected. 761 o Does not allow the offerer to indicate alternatives other than the 762 inferred SRTP (including vanilla RTP as an alternative to SRTP). 764 o Addresses only a small subset of the requirements provided above. 766 3.8. Opportunistic Encryption using Probing 768 This is another approach suggested to address the specific scenario 769 of negotiating either RTP or SRTP. In this case, the endpoints first 770 establish an RTP session using RTP (RTP/AVP). The endpoints send 771 probe messages, over the media path, to determine if the remote 772 endpoint supports their profile (e.g. RTP/SAVP) and keying technique. 774 The main advantages of this approach are: 776 o Compatible with non-SRTP-aware endpoints. 778 The disadvantages of this approach are: 780 o Addresses only a small subset of the requirements provided above. 782 4. Security Considerations 784 One of the motivations for SDP capability negotiation is to enable 785 best-effort SRTP negotiation, i.e. an offer/answer exchange offering 786 both a secure and a non-secure version of RTP. The answerer in turn 787 will select one of these. Such a negotiation where the offerer is 788 willing to accept either a secure or insecure RTP profile, and 789 possibly with more or less strong security algorithms as a result of 790 the negotiation opens up for a range of possible security attacks. It 791 is important that any solution for SDP capability negotiation 792 properly addresses such security risks and/or notes any security 793 threats inherent in the proposed solution. 795 [Editor's note: This almost sounds like we should have some 796 specific requirements around all of this]. 798 5. IANA Considerations 800 There are no IANA considerations in this document. 802 6. Acknowledgments 804 Thanks to the MMUSIC WG for comments on the requirements in this 805 document. Also, Francois Audet, Paul Jones and Dan Wing provided 806 specific comments on a precursor to this document. 808 7. Change Log 810 7.1. draft-ietf-mmusic-sdp-capability-negotiation-reqts-00.txt 812 Version -00 is based on draft-andreasen-mmusic-sdp-capability- 813 negotiation-reqts-00.txt with the following changes: 815 * Noted that REQ-50 may have interactions with ICE 817 * Clarified requirements REQ-80, REQ-130. 819 * Added new requirements REQ-85, REQ-121, REQ-122, REQ-301, and REQ- 820 302. 822 * Reduced requirements REQ-150 and REQ-160 to "SHOULD" strength. 824 * Minor updates to Section 3.7. and 3.8. 826 7.2. draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00.txt 828 Version -00 is the initial version. The requirements provided in this 829 initial version were taken from an earlier version of [SDPCapNeg] 830 with additional requirements added (from REQ-150 and up). 832 The ability to indicate capabilities as either mandatory or optional 833 is no longer explicitly out of scope (in order to support modularity 834 and extensibility per the newly added requirements), and neither is 835 the ability to indicate constraints on combinations of 836 configurations. 838 8. References 840 8.1. Normative References 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, March 1997. 845 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 846 Syntax Specifications: ABNF", RFC 2234, Internet Mail 847 Consortium and Demon Internet Ltd., November 1997. 849 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 850 with Session Description Protocol (SDP)", RFC 3264, June 851 2002. 853 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 854 Capability Declaration", RFC 3407, October 2002. 856 [RFC3605] C. Huitema, "Real Time Control Protocol (RTCP) attribute in 857 Session Description Protocol (SDP)", RFC 3605, October 858 2003. 860 [RFC4234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 861 Specifications: ABNF", RFC 4234, October 2005. 863 [SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 864 Description Protocol", RFC 4566, July 2006. 866 8.2. Informative References 868 [RFC2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail 869 Extensions (MIME) Part Two: Media Types", RFC 2046, 870 November 1996. 872 [RFC2327] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 873 Description Protocol", RFC 2327, April 1998. 875 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 876 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 877 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 879 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 880 Schulzrinne, "Grouping of Media Lines in the Session 881 Description Protocol (SDP)", RFC 3388, December 2002. 883 [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and 884 Video Conferences with Minimal Control", RFC 3551, July 885 2003. 887 [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 888 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 889 RFC 3711, March 2004. 891 [RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 892 (S/MIME) Version 3.1 Message Specification", RFC 3851, July 893 2004. 895 [RFC4091] Camarillo, G., and J. Rosenberg, The Alternative Network 896 Address Types (ANAT) Semantics for the Session Description 897 Protocol (SDP) Grouping Framework, RFC 4091, June 2005. 899 [AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 900 "Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF)", 901 Work in Progress, August 2004. 903 [I-D.jennings-sipping-multipart] Wing, D., and C. Jennings, "Session 904 Initiation Protocol (SIP) Offer/Answer with Multipart 905 Alternative", Work in Progress, March 2006. 907 [SAVPF] Ott, J., and E Carrara, "Extended Secure RTP Profile for 908 RTCP-based Feedback (RTP/SAVPF)", Work in Progress, 909 December 2005. 911 [SDES] Andreasen, F., Baugher, M., and D. Wing, "Session 912 Description Protocol Security Descriptions for Media 913 Streams", RFC 4568, July 2006. 915 [SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session Description 916 and Capability Negotiation", Work in Progress, February 917 2005. 919 [BESRTP] Kaplan, H., and F. Audet, "Session Description Protocol 920 (SDP) Offer/Answer Negotiation for Best-Effort Secure Real- 921 Time Transport Protocol, Work in progress, August 2006. 923 [KMGMT] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 924 Carrara, "Key Management Extensions for Session Description 925 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 926 RFC 4567, July 2006. 928 [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", work in 929 progress, December 2006. 931 [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 932 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 933 August 2004. 935 [T38] ITU-T Recommendation T.38, "Procedures for real-time Group 936 3 facsimile communication over IP networks", September 937 2005. 939 [H245] ITU-T Recommendation H.245, "Control protocol for 940 multimedia communication", May 2006. 942 Author's Addresses 944 Flemming Andreasen 945 Cisco Systems 946 Edison, NJ 948 Email: fandreas@cisco.com 950 Intellectual Property Statement 952 The IETF takes no position regarding the validity or scope of any 953 Intellectual Property Rights or other rights that might be claimed to 954 pertain to the implementation or use of the technology described in 955 this document or the extent to which any license under such rights 956 might or might not be available; nor does it represent that it has 957 made any independent effort to identify any such rights. Information 958 on the procedures with respect to rights in RFC documents can be 959 found in BCP 78 and BCP 79. 961 Copies of IPR disclosures made to the IETF Secretariat and any 962 assurances of licenses to be made available, or the result of an 963 attempt made to obtain a general license or permission for the use of 964 such proprietary rights by implementers or users of this 965 specification can be obtained from the IETF on-line IPR repository at 966 http://www.ietf.org/ipr. 968 The IETF invites any interested party to bring to its attention any 969 copyrights, patents or patent applications, or other proprietary 970 rights that may cover technology that may be required to implement 971 this standard. Please address the information to the IETF at 972 ietf-ipr@ietf.org. 974 Disclaimer of Validity 976 This document and the information contained herein are provided on an 977 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 978 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 979 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 980 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 981 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 982 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 984 Copyright Statement 986 Copyright (C) The Internet Society (2006). 988 This document is subject to the rights, licenses and restrictions 989 contained in BCP 78, and except as set forth therein, the authors 990 retain all their rights. 992 Acknowledgment 994 Funding for the RFC Editor function is currently provided by the 995 Internet Society.