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