idnits 2.17.1 draft-ietf-mmusic-sdpng-trans-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 306: '... SDPng contents MAY be identified by ...' RFC 2119 keyword, line 311: '...is available and SHOULD used to differ...' RFC 2119 keyword, line 319: '... It is RECOMMENDED that impleme...' RFC 2119 keyword, line 329: '..., session announcements SHOULD be made...' RFC 2119 keyword, line 332: '... SDP announcement SHOULD be omitted....' (4 more instances...) 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 (February 2002) is 8105 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) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-06 == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-04 == Outdated reference: A later version (-06) exists of draft-ietf-mmusic-fid-05 == Outdated reference: A later version (-05) exists of draft-andreasen-mmusic-sdp-simcap-04 == Outdated reference: A later version (-02) exists of draft-ietf-mmusic-sdp-offer-answer-01 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-01 == Outdated reference: A later version (-01) exists of draft-taylor-mmusic-sdp-tdm-00 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-05) exists of draft-ietf-mmusic-sdp4nat-01 == Outdated reference: A later version (-15) exists of draft-ietf-mmusic-kmgmt-ext-02 == Outdated reference: A later version (-03) exists of draft-ietf-mmusic-sdp-ipv6-02 == Outdated reference: A later version (-07) exists of draft-ietf-sip-manyfolks-resource-03 Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Ott/C. Perkins 3 Expires: August 2002 TZI/ISI 4 February 2002 6 SDPng Transition 7 draft-ietf-mmusic-sdpng-trans-00.txt 9 Status of this memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 To view the list Internet-Draft Shadow Directories, see 28 http://www.ietf.org/shadow.html. 30 Distribution of this document is unlimited. 32 Abstract 34 The Session Description Protocol (SDP) is today widely used in the 35 Internet to announce as well as negotiate multimedia sessions and 36 exchange capabilities. Having originally been designed for session 37 announcements only, as opposed to announcements and capabilities 38 negotiation announcements, native SDP lacks numerous features to be 39 applicable in many session scenarios. Numerous extensions have been 40 developed to circumvent SDP's shortcomings -- but they have also 41 repeatedly shown its inherent limitations. A successor protocol -- 42 termed "SDPng" for the time being -- is developed to address the 43 aforementioned needs of Internet applications in a more structured 44 manner. With the huge installed base of SDP-based applications, a 45 migration path needs to be developed to move from SDP to SDPng over 46 time. This document outlines how this migration can be achieved: in 47 general as well as for the various IETF control protocols that 48 potentially make use of SDP and SDPng. 50 This document is a product of the Multiparty Multimedia Session 51 Control (MMUSIC) working group of the Internet Engineering Task 52 Force. Comments are solicited and should be addressed to the working 53 group's mailing list at mmusic@ietf.org and/or the authors. 55 1. Introduction 57 SDP is now widely used within the Internet community to describe 58 media sessions and, in a limited fashion, system capabilities 59 relating to (multi)media sessions, for a variety of application 60 scenarios: session announcements, interactive session setup, 61 capability assessment and remote control of media streams. All but 62 the first of these are rather different from what SDP was originally 63 designed for -- but all of them share the idea of setting up and 64 configuring media streams. Over time, its wide range of uses has 65 revealed numerous shortcomings -- most of which stem from the fact 66 that SDP has been used for lack of a better alternative and its 67 semantics have been re-interpreted to make it fit the respective 68 scenarios' needs. In many cases, workrounds (typically called 69 "extensions") for those shortcomings could be found which are often 70 rather cumbersome. While this practice has extended SDP's lifetime 71 and provided at least a suitable basis for numerous applications, in 72 parallel, a successor protocol -- currently referred to as "SDPng" 73 -- has been developed. 75 It is worthwhile noting that the aforementioned applications' 76 needs are sufficiently similar for a single description protocol 77 to take care of them if it was designed for this purpose from 78 the beginning. As a lesson learned from SDP, any further 79 expansion in scope should be avoided where no clear fit can be 80 seen -- and specific (different) solutions should be developed 81 instead. 83 The design of SDPng takes into account the requirements arising from 84 the above application scenarios and puts particular emphasis on 85 protocol extensibility and modularization of extensions, at the same 86 time keeping the core description format simple. SDPng uses a 87 different (more expressive) syntax than SDP does and hence is not 88 backward compatible at the syntax level. Nevertheless, the concepts 89 of SDPng take into account the migration issues from SDP to SDPng by 90 providing straightforward mappings between the two formats where 91 possible and try to maximize compatibility from a semantics 92 perspective. 94 The current revisions of SDP and SDPng are documented in 96 [1] draft-ietf-mmusic-sdp-new-05.txt and 98 [2] draft-ietf-mmusic-sdpng-04.txt. 100 For SDP, numerous additional documents need to be taken into account: 102 [3] RFC 3108 104 [4] draft-ietf-mmusic-fid-05.txt 106 [5] draft-andreasen-mmusic-sdp-simcap-04.txt 108 [6] draft-ietf-mmusic-sdp-offer-answer-02.txt 110 [7] draft-fairlie-mmusic-sdp-sctp-00.txt 112 [8] draft-ietf-mmusic-sdp-comedia-01.txt 114 [9] draft-taylor-mmusic-sdp-tdm-00.txt 116 [10] draft-ietf-mmusic-sdp4nat-01.txt 118 [11] draft-ietf-mmusic-kmgmt-ext-02.txt 120 [12] draft-ietf-mmusic-sdp-ipv6-02.txt 122 This document outlines a migration path from SDP to SDPng, starting 123 from a short overview of the current application scenarios. In the 124 next step, we highlight which design decisions taken for SDPng should 125 simplify a smooth migration and describe how mappings between the two 126 description formats can be performed at an abstract level. We then 127 address procedural issues for integrating SDP and SDPng into the 128 various protocols relying on those media description formats. 129 Finally, we summarize work items on the agenda for SDPng. 131 2. Application Scenarios 133 The following session control protocols that make use of SDP have 134 been standardized in the IETF so far: 136 1. SDP was originally developed to announce (Mbone-based) 137 multimedia sessions via session directories using the Session 138 Announcement Protocol (SAP) -- but other mechanisms for 139 disseminating the session descriptions (such as HTTP, SMTP, 140 NNTP, etc.) are conceivable as well. 142 The major property of this application scenario is that the 143 creator of the session description defines a (set of) fixed 144 choice(s) for all media types in a conference and the conference 145 partipants have no way to influence these. If they support at 146 least one of the codecs for a particular media type they can 147 participate in this media session, otherwise they cannot. There 148 is no interaction between sender(s) and receiver(s) to negotiate 149 the media stream codecs and parameters. 151 This scenario is referred to as "announcement". 153 2. Another use of SDP is in conjunction with the Real-Time 154 Streaming Protocol (RTSP). In RTSP, SDP is used to convey 155 descriptions of a media stream interactively requested to be 156 played from a server (or recorded by a server). SDP itself is 157 not used for capability negotiation, not even for the addresses 158 to be used; those are negotiated within RTSP and may override 159 the addresses specified as part of SDP. 161 This scenario is referred to as "retrieval". 163 3. With SIP, SDP is used to propose media stream configurations and 164 choose out of these (i.e. enable a subset of these). By 165 proposing and accepting media stream configurations, endpoints 166 use SDP to implicitly describe their capabilities and carry out 167 a negotiation procedure on the media streams to use. 169 In the context of SIP, specific meanings (including required 170 extensions) have been defined for use of SDP with unicast 171 addresses, for connection-oriented transports, and for certain 172 media level attributes (such as the direction attribute send- 173 only, receive-only, and inactive). 175 Numerous extensions have been proposed to extend SDP to better 176 suit SIP's needs. Besides a description of the offer/answer 177 model, these extensions particularly include the ability to 178 describe simultaneous capabilites and to group media stream 179 semantically. 181 This scenario is referred to as "offer/answer". 183 4. SDP is used to convey the capability descriptions of a MEGACO 184 media gateway (MG) to its media gateway controller (MGC) as well 185 as for the MGC to instruct the MG where to send media streams to 186 and from where to receive media streams, including codec and 187 parameter choice. 189 For this purpose, SDP has been modified/extended to some degree 190 to fit the MEGACO needs. 192 This scenario is referred to as "gateway control". 194 It should noted that the original SDP concept already provided an 195 extension mechanism to cover other network types than IPv4 and IPv6; 196 however, specific extensions have only been defined recently for ATM 197 and are now under discussion for TDM. Extensions to other transport 198 (including radio interfaces or next generation wireless networks) as 199 well as to new types of session descriptions (e.g. electronic program 200 guides) are conceivable. 202 3. Mapping SDP to SDPng 204 On a transition path from SDP to SDPng, allowing for a somewhat 205 straightforward mapping of (parts of) one description format onto the 206 other is of crucial importance. SDPng has been designed in way that 207 allows many of the session description features of SDP to be easily 208 mapped onto the SDPng format and vice versa -- except that SDPng is 209 more expressive than SDP and hence information loss is not unlikely 210 to occur when doing the reverse mapping. The final mapping rules 211 between SDP and SDPng to be drawn up shall ensure that when mapping 212 SDP to SDPng and then back to SDP will produce an SDP that is 213 functionally identical to the one originally fed into the mapping 214 process. Note that the use of a number of SDP extensions (FID, 215 SIMCAP) may be implied in this mapping process, depending on the use 216 of SDP. The mapping rules will ensure that no information loss will 217 occur when translating from SDP to SDPng. 219 The SDPng design uses a structure of four sections: definitions, 220 potential or actual configurations, constraints and session 221 attributes. Of these, the "Configurations" and "Session 222 Attributes" sections map well onto the current SDP. The 223 "Definitions" and "Constraints" sections provide additional 224 structure which is not directly expressible in SDP. 226 o At the media description level, the Potential and Actual 227 Configurations specified in the "Configurations" section maps 228 well to media descriptions ("m=", possibly "c=", and 229 associated attributes ("a=") lines). 231 o At the session description level, the SDP session parameters are 232 largely reflected in the "Session Attributes" section of 233 SDPng. The attributes proven suitable for session announcements 234 have been used as the basis when defining SDPng. 236 In SDPng, media descriptions are explicitly tagged with identifiers 237 and thus are easily referenced for semantically grouping media 238 streams (e.g. to describe alternative audio in different languages, 239 media streams to be synchronized, or media streams to carry the same 240 information simultaneously but with different encodings) -- as has 241 been defined for SDP in a limited fashion by the "fid" attribute 242 set. SDPng allows even to more formally describe the syntax of 243 individual or compound media streams in the "Session Attributes" 244 section. Furthermore, SDPng supports a superset of additional 245 constraints that may be realized by the "simcap" extensions for SDP 246 in the "Constraints" section. 248 Additional address families such as ATM or TDM bearers, next 249 generation wireless network bearers, DVB channels, etc. can be 250 incorporated into SDPng by defining the appropriate extensions for 251 the SDPng transports. 253 Similarly, new codecs can be added by just defining new codec 254 specifications or defining entire new classes of applications to be 255 described as new content types ("codec") to be carried in a media 256 session (including e.g. text, fax, slide presentations, shared 257 editors, etc). If necessary, sophisticated parameter structures can 258 be supported (even though the authors believe that simplicity is key 259 to interoperability here). This is similar to, but more structured 260 than, the definition of new codecs attributes/MIME registrations in 261 SDP. 263 By means of its conceptual differentiation into Potential and Actual 264 Configurations, SDPng supports both indicating a system's 265 capabilities (without specifying transport addresses) separately from 266 the instantiation of a particular media stream as well as conveying 267 capability descriptions and instantiation proposals at the same time 268 -- thereby providing a good fit for all the above session control 269 scenarios: the "announcement" and "retrieval" scenarios will just 270 use rather fixed Actual Configurations. The "offer/answer" model 271 will use use Actual Configuration but use them to negotiate media 272 strams in a two-way handshake but may in addition use Potential 273 Configurations to indicate capabilities that shall not be used 274 immediately. The "gateway control" scenario will use both: 275 Potential Configurations to describe an MG's capabilities and Actual 276 Configurations for setting up media sessions at MGs as well as 277 retrieving information about currently active media sessions. This 278 differentiation is not directly expressible in SDP, although various 279 extensions can be used to overload SDP semantics to achieve at least 280 part of this effect. 282 Finally, SDPng is also intended to allow for content-independent 283 negotiation of session parameters by defining collapsing/intersection 284 rules. In particular, SDPng tries to take the need for multicast- 285 based distributed calculation of joint capabilities into account for 286 those rules (but note that it is *not* intended as a generic format 287 for describing conference state information). Such functionality is 288 not covered by current SDP. 290 4. Integration with Session Control Protocols 292 This section outlines for each of the session control protocols 293 described above how SDP and SDPng can be used in parallel and 294 indicates how a suitable transition could be achieved. 296 4.1. Session Announcement Protocol (SAP) 298 There are two revision of SAP specified, version 0 which is 299 implemented in a number of experimental tools, and version 1 which is 300 defined in RFC 2972. 302 SAPv0:SAPv0 does not support a mechanism to identify the content type 303 of a session announcement but implicitly assumes SDP. Proper 304 parsers will note that the contents of the SAPv0 message does 305 not begin with a "v=" line and hence will ignore the entire 306 announcement. SDPng contents MAY be identified by the character 307 sequence " 499 Universitaet Bremen 500 MZH 5180 501 Bibliothekstr. 1 502 D-28359 Bremen 503 Germany 504 tel:+49-421-201-7028 505 fax:+49-421-218-7000 507 Colin Perkins 508 USC Information Sciences Institute 509 3811 North Fairfax Drive, Suite 200 510 Arlington, VA 22203 511 USA 512 tel:+1-703-812-3705 514 8. References 516 [1] Mark Handley, Van Jacobson, Colin Perkins, "SDP: Session 517 Description Protocol," Internet Draft draft-ietf-mmusic-sdp- 518 new-06.txt, Work in Progress, February 2002. 520 [2] Dirk Kutscher, Joerg Ott, Carsten Bormann, "Session Description 521 and Capability Negotiation", Internet Draft draft-ietf-mmusic- 522 sdpng-04.txt, Work in Progress, February 2002. 524 For SDP, numerous additional documents need to be taken into account: 526 [3] 3108 R. Kumar, M. Mostafa, "Conventions for the use of the 527 Session Description Protocol (SDP) for ATM Bearer Connections," 528 RFC 3108, May 2001. 530 [4] Gonzalo Camarillo, Jan Holler, Goran AP Eriksson, Henning 531 Schulzrinne, "Grouping of media lines in SDP," Internet Draft 532 draft-ietf-mmusic-fid-05.txt, Work in Progress, September 2001. 534 [5] F. Andreasen, "SDP Simple Capability Negotiation," Internet 535 Draft draft-andreasen-mmusic-sdp-simcap-04.txt, Work in 536 Progress, August 2001. 538 [6] Jonathan Rosenberg, Henning Schulzrinne, "An Offer/Answer Model 539 with SDP," Internet Draft draft-ietf-mmusic-sdp-offer- 540 answer-01.txt, Work in Progress, February 2002. 542 [7] Robert Fairlie-Cuninghame, "Guidelines for specifying SCTP- 543 based media transport using SDP," Internet Draft draft-fairlie- 544 mmusic-sdp-sctp-00.txt, Work in Progress, May 2001. 546 [8] David Yon, "Connection-Oriented Media Transport in SDP," 547 Internet Draft draft-ietf-mmusic-sdp-comedia-01.txt, Work in 548 Progress, October 2001. 550 [9] Tom Taylor, "Conventions for the use of the Session Description 551 Protocol (SDP) for Digital Circuit Connections," Internet Draft 552 draft-taylor-mmusic-sdp-tdm-00.txt, Work in Progress, April 553 2001. 555 [10] Christian Huitema, "RTCP attribute in SDP," Internet Draft 556 draft-ietf-mmusic-sdp4nat-01.txt, Work in Progress, February 557 2002. 559 [11] Jari Arkko, Elisabette Carrarra, Fredrik Lindholm, Mats Naslund, 560 Karl Norrman, "Key Management Extensions for SDP and RTSP," 561 Internet Draft draft-ietf-mmusic-kmgmt-ext-02.txt, Work in 562 Progress, February 2002. 564 [12] Sean Olson, Gonzalo Camarillo, Adam Roach, "Support for IPv6 in 565 SDP," Internet Draft draft-ietf-mmusic-sdp-ipv6-02.txt, Work in 566 Progress, February 2002. 568 [13] W. Marshall et al, "Integration of Resource Management and 569 SIP", Internet Draft draft-ietf-sip-manyfolks-resource-03.txt, 570 Work in Progress, November 2001. 572 9. Full Copyright Statement 574 Copyright (C) The Internet Society (1997). All Rights Reserved. 576 This document and translations of it may be copied and furnished to 577 others, and derivative works that comment on or otherwise explain it 578 or assist in its implmentation may be prepared, copied, published and 579 distributed, in whole or in part, without restriction of any kind, 580 provided that the above copyright notice and this paragraph are 581 included on all such copies and derivative works. However, this 582 document itself may not be modified in any way, such as by removing 583 the copyright notice or references to the Internet Society or other 584 Internet organizations, except as needed for the purpose of 585 developing Internet standards in which case the procedures for 586 copyrights defined in the Internet Standards process must be 587 followed, or as required to translate it into languages other than 588 English. 590 The limited permissions granted above are perpetual and will not be 591 revoked by the Internet Society or its successors or assigns. 593 This document and the information contained herein is provided on an 594 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 595 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 596 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 597 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 598 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.