idnits 2.17.1 draft-ietf-mmusic-sdpng-trans-02.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 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 354: '... SDPng contents MAY be identified by ...' RFC 2119 keyword, line 356: '... but this is NOT RECOMMENDED. Instead,...' RFC 2119 keyword, line 360: '...is available and SHOULD used to differ...' RFC 2119 keyword, line 368: '... It is RECOMMENDED that impleme...' RFC 2119 keyword, line 378: '..., session announcements SHOULD be made...' (10 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 (November 2002) is 7833 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-11 == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-05 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-04 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-05) exists of draft-ietf-mmusic-sdp4nat-02 == Outdated reference: A later version (-15) exists of draft-ietf-mmusic-kmgmt-ext-05 -- Possible downref: Non-RFC (?) normative reference: ref. '12' == Outdated reference: A later version (-07) exists of draft-ietf-sip-manyfolks-resource-03 == Outdated reference: A later version (-01) exists of draft-camarillo-mmusic-source-sink-00 -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-srcfilter-01 == Outdated reference: A later version (-01) exists of draft-ietf-mmusic-reservation-flows-00 Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Ott/C. Perkins 3 Expires: May 2003 TZI/ISI 4 November 2002 6 SDPng Transition 7 draft-ietf-mmusic-sdpng-trans-02.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 This document is a product of the Multiparty Multimedia Session 33 Control (MMUSIC) working group of the Internet Engineering Task 34 Force. Comments are solicited and should be addressed to the working 35 group's mailing list at mmusic@ietf.org and/or the authors. 37 Abstract 39 The Session Description Protocol (SDP) is today widely used in the 40 Internet to announce as well as negotiate multimedia sessions and 41 exchange capabilities. Having originally been designed for session 42 announcements only, as opposed to announcements and capabilities 43 negotiation announcements, native SDP lacks numerous features to be 44 applicable in many session scenarios. Numerous extensions have been 45 developed to circumvent SDP's shortcomings -- but they have also 46 repeatedly shown its inherent limitations. A successor protocol -- 47 termed "SDPng" for the time being -- is developed to address the 48 aforementioned needs of Internet applications in a more structured 49 manner. With the huge installed base of SDP-based applications, a 50 migration path needs to be developed to move from SDP to SDPng over 51 time. This document outlines how this migration can be achieved: in 52 general as well as for the various IETF control protocols that 53 potentially make use of SDP and SDPng. 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 o draft-ietf-mmusic-sdp-new-11.txt [1] and 98 o draft-ietf-mmusic-sdpng-05.txt [2]. 100 For SDP, a number of additional features are defined in the following 101 documents that need to be taken into account: 103 o the offer/answer scheme of interpreting and matching media 104 session descriptions to negotiate media sessions to be used in 105 call or conference in a single round-trip (RFC 3264 [6]); 107 o full support for IPv6 as network layer protocol (RFC 3266 [12]); 109 o SDP extensions to allow selecting ATM virtual circuits as 110 additional network protocol and specifying ATM-specific 111 parameters (RFC 3108 [3]); 113 o SDP extensions to support TDM as additional network protocol and 114 specify the TDM-specific parameters (draft-taylor-mmusic-sdp- 115 tdm-00.txt [9]) 117 o a general extension to deal with connection-oriented transport 118 protocols such as TCP (draft-ietf-mmusic-sdp-comedia-04.txt 119 [8]); 121 o an extension to support SCTP as media transport protocol in 122 addition to UDP and TCP (draft-fairlie-mmusic-sdp-sctp-00.txt 123 [7]); 125 o an SDP extension to explicitly specify RTCP port number to 126 enable the necessary expressiveness for NAT traversal (draft- 127 ietf-mmusic-sdp4nat-02.txt [10]); 129 o a mechanism (media identification, "mid") for naming and 130 grouping ("group") SDP media lines according to one or more 131 criteria, e.g. for the purpose of lip-synchronization or for 132 identifying media sessions carrying the same content (draft- 133 ietf-mmusic-fid-05.txt [4]); 135 o the capability to indicate which media sessions shall be mapped 136 into the same resource reservation context (draft-ietf-mmusic- 137 reservation-flows-00.txt [13]); 139 o an extension to allow expression of simultanous capabilities 140 across media sessions and formats (draft-andreasen-mmusic-sdp- 141 simcap-05.txt [5]) 143 o attributes for passing parameters of a keying protocol (such as 144 MIKEY) as part of a session description (draft-ietf-mmusic- 145 kmgmt-ext-05.txt [11]); 147 o support for conveying cryptographic parameters as part of a 148 session description (draft-baugher-mmusic-sdpmediasec-00.txt 149 [15]); and 151 o a mechanism to explicitly specify the sources allowed to provide 152 input to media sessions (draft-ietf-mmusic-sdp-srcfilter-01.txt 153 [16]). 155 o a simple language to provide instructions to media mixers on 156 which incoming media streams shall be combined to produce which 157 outgoing ones (and possbily how they shall be combined, draft- 158 camarillo-mmusic-source-sink-00.txt [14]); 160 This document outlines a migration path from SDP to SDPng, starting 161 from a short overview of the current application scenarios. In the 162 next step, we highlight which design decisions taken for SDPng should 163 simplify a smooth migration and describe how mappings between the two 164 description formats can be performed at an abstract level. We then 165 address procedural issues for integrating SDP and SDPng into the 166 various protocols relying on those media description formats. 167 Finally, we summarize work items on the agenda for SDPng. 169 2. Application Scenarios 171 The following session control protocols that make use of SDP have 172 been standardized in the IETF so far: 174 1. SDP was originally developed to announce (Mbone-based) 175 multimedia sessions via session directories using the Session 176 Announcement Protocol (SAP) -- but other mechanisms for 177 disseminating the session descriptions (such as HTTP, SMTP, 178 NNTP, etc.) are conceivable as well. 180 The major property of this application scenario is that the 181 creator of the session description defines a (set of) fixed 182 choice(s) for all media types in a conference and the conference 183 partipants have no way to influence these. If they support at 184 least one of the codecs for a particular media type they can 185 participate in this media session, otherwise they cannot. There 186 is no interaction between sender(s) and receiver(s) to negotiate 187 the media stream codecs and parameters. 189 This scenario is referred to as "announcement". 191 2. Another use of SDP is in conjunction with the Real-Time 192 Streaming Protocol (RTSP). In RTSP, SDP is used to convey 193 descriptions of a media stream interactively requested to be 194 played from a server (or recorded by a server). SDP itself is 195 not used for capability negotiation, not even for the addresses 196 to be used; those are negotiated within RTSP and may override 197 the addresses specified as part of SDP. 199 This scenario is referred to as "retrieval". 201 3. With SIP, SDP is used to propose media stream configurations and 202 choose out of these (i.e. enable a subset of these). By 203 proposing and accepting media stream configurations, endpoints 204 use SDP to implicitly describe their capabilities and carry out 205 a negotiation procedure on the media streams to use. 207 In the context of SIP, specific meanings (including required 208 extensions) have been defined for use of SDP with unicast 209 addresses, for connection-oriented transports, and for certain 210 media level attributes (such as the direction attribute send- 211 only, receive-only, and inactive). 213 Numerous extensions have been proposed to extend SDP to better 214 suit SIP's needs. Besides a description of the offer/answer 215 model, these extensions particularly include the ability to 216 describe simultaneous capabilites and to group media stream 217 semantically. 219 This scenario is referred to as "offer/answer". 221 4. SDP is used to convey the capability descriptions of a MEGACO 222 media gateway (MG) to its media gateway controller (MGC) as well 223 as for the MGC to instruct the MG where to send media streams to 224 and from where to receive media streams, including codec and 225 parameter choice. 227 For this purpose, SDP has been modified/extended to some degree 228 to fit the MEGACO needs. 230 This scenario is referred to as "gateway control". 232 It should noted that the original SDP concept already provided an 233 extension mechanism to cover other network types than IPv4 and IPv6; 234 however, specific extensions have only been defined recently for ATM 235 and are now under discussion for TDM. Extensions to other transport 236 (including radio interfaces or next generation wireless networks) as 237 well as to new types of session descriptions (e.g. electronic program 238 guides) are conceivable. 240 3. Mapping SDP to SDPng 242 On a transition path from SDP to SDPng, allowing for a somewhat 243 straightforward mapping of (parts of) one description format onto the 244 other is of crucial importance. SDPng has been designed in way that 245 allows many of the session description features of SDP to be easily 246 mapped onto the SDPng format and vice versa -- except that SDPng is 247 more expressive than SDP and hence information loss is not unlikely 248 to occur when doing the reverse mapping. The final mapping rules 249 between SDP and SDPng to be drawn up shall ensure that when mapping 250 SDP to SDPng and then back to SDP will produce an SDP that is 251 functionally identical to the one originally fed into the mapping 252 process. Note that the use of a number of SDP extensions (FID, 253 SIMCAP) may be implied in this mapping process, depending on the use 254 of SDP. The mapping rules will ensure that no information loss will 255 occur when translating from SDP to SDPng. 257 The SDPng design uses a structure of four sections: definitions, 258 potential or actual configurations, constraints and session 259 attributes. Of these, the "Configurations" and "Session 260 Attributes" sections map well onto the current SDP. The 261 "Definitions" and "Constraints" sections provide additional 262 structure which is not directly expressible in SDP. 264 o At the media description level, the Potential and Actual 265 Configurations specified in the "Configurations" section maps 266 well to media descriptions ("m=", possibly "c=", and 267 associated attributes ("a=") lines). 269 o At the session description level, the SDP session parameters are 270 largely reflected in the "Session Attributes" section of 271 SDPng. The attributes proven suitable for session announcements 272 have been used as the basis when defining SDPng. 274 In SDPng, media descriptions are explicitly tagged with identifiers 275 and thus are easily referenced for semantically grouping media 276 streams (e.g. to describe alternative audio in different languages, 277 media streams to be synchronized, or media streams to carry the same 278 information simultaneously but with different encodings) -- as has 279 been defined for SDP in a limited fashion by the "fid" attribute 280 set. SDPng allows even to more formally describe the syntax of 281 individual or compound media streams in the "Session Attributes" 282 section. Furthermore, SDPng supports a superset of additional 283 constraints that may be realized by the "simcap" extensions for SDP 284 in the "Constraints" section. 286 Additional address families such as ATM or TDM bearers, next 287 generation wireless network bearers, DVB channels, etc. can be 288 incorporated into SDPng by defining the appropriate extensions for 289 the SDPng transports. 291 Similarly, new codecs can be added by just defining new codec 292 specifications or defining entire new classes of applications to be 293 described as new content types ("codec") to be carried in a media 294 session (including e.g. text, fax, slide presentations, shared 295 editors, etc). If necessary, sophisticated parameter structures can 296 be supported (even though the authors believe that simplicity is key 297 to interoperability here). This is similar to, but more structured 298 than, the definition of new codec attributes in MIME registrations 299 for SDP. 301 It is expected that the MIME namespace for codecs will be mapped 302 into the SDPng namespace, and a consistent mapping from SDP 303 "a=fmtp:" attributes to SDPng codec parameters will be 304 defined. 306 By means of its conceptual differentiation into Potential and Actual 307 Configurations, SDPng supports both indicating a system's 308 capabilities (without specifying transport addresses) separately from 309 the instantiation of a particular media stream as well as conveying 310 capability descriptions and instantiation proposals at the same time 311 -- thereby providing a good fit for all the above session control 312 scenarios: the "announcement" and "retrieval" scenarios will just 313 use rather fixed Actual Configurations. The "offer/answer" model 314 will use use Actual Configuration but use them to negotiate media 315 strams in a two-way handshake but may in addition use Potential 316 Configurations to indicate capabilities that shall not be used 317 immediately. The "gateway control" scenario will use both: 318 Potential Configurations to describe an MG's capabilities and Actual 319 Configurations for setting up media sessions at MGs as well as 320 retrieving information about currently active media sessions. This 321 differentiation is not directly expressible in SDP, although various 322 extensions can be used to overload SDP semantics to achieve at least 323 part of this effect. 325 Finally, while the short-term SDPng specification aims at supporting 326 only the widespread offer/answer model for capability negotiation, a 327 future extension will also allow for content-independent negotiation 328 of session parameters by defining collapsing/intersection rules. In 329 particular, SDPng will take into account the need for multicast-based 330 distributed calculation of joint capabilities into account for those 331 rules (but note that it is *not* intended as a generic format for 332 describing conference state information). Such functionality is not 333 covered by current SDP -- but there is also no perceived urgent 334 demand so that this sophisticated functional component of SDPng is 335 left to a future protocol extension. The base SDPng protocol will 336 provide the necessary flexibility, however. 338 4. Integration with Session Control Protocols 340 This section outlines for each of the session control protocols 341 described above how SDP and SDPng can be used in parallel and 342 indicates how a suitable transition could be achieved. 344 4.1. Session Announcement Protocol (SAP) 346 There are two revisions of SAP specified, version 0 which is 347 implemented in a number of experimental tools, and version 1 which is 348 defined in RFC 2972. 350 SAPv0:SAPv0 does not support a mechanism to identify the content type 351 of a session announcement but implicitly assumes SDP. Proper 352 parsers will note that the contents of the SAPv0 message does 353 not begin with a "v=" line and hence will ignore the entire 354 announcement. SDPng contents MAY be identified by the character 355 sequence " 670 Universitaet Bremen 671 MZH 5180 672 Bibliothekstr. 1 673 D-28359 Bremen 674 Germany 675 tel:+49-421-201-7028 676 sip:jo@tzi.org 678 Colin Perkins 679 USC Information Sciences Institute 680 3811 North Fairfax Drive, Suite 200 681 Arlington, VA 22203 682 USA 683 tel:+1-703-812-3705 685 10. References 687 [1] Mark Handley, Van Jacobson, Colin Perkins, "SDP: Session 688 Description Protocol," Internet Draft draft-ietf-mmusic-sdp- 689 new-11.txt, Work in Progress, November 2002. 691 [2] Dirk Kutscher, Joerg Ott, Carsten Bormann, "Session Description 692 and Capability Negotiation", Internet Draft draft-ietf-mmusic- 693 sdpng-05.txt, Work in Progress, July 2002. 695 For SDP, numerous additional documents need to be taken into account: 697 [3] 3108 R. Kumar and M. Mostafa, "Conventions for the use of the 698 Session Description Protocol (SDP) for ATM Bearer Connections," 699 RFC 3108, May 2001. 701 [4] Gonzalo Camarillo, Jan Holler, Goran AP Eriksson, Henning 702 Schulzrinne, "Grouping of media lines in SDP," Internet Draft 703 draft-ietf-mmusic-fid-06.txt, Work in Progress, February 2002. 705 [5] F. Andreasen, "SDP Simple Capability Declaration," RFC 3407, 706 October 2002. 708 [6] Jonathan Rosenberg and Henning Schulzrinne, "An Offer/Answer 709 Model with SDP," RFC 3264, June 2002. 711 [7] Robert Fairlie-Cuninghame, "Guidelines for specifying SCTP- 712 based media transport using SDP," Internet Draft draft-fairlie- 713 mmusic-sdp-sctp-00.txt, Work in Progress, May 2001. 715 [8] David Yon, "Connection-Oriented Media Transport in SDP," 716 Internet Draft draft-ietf-mmusic-sdp-comedia-04.txt, Work in 717 Progress, July 2002. 719 [9] Tom Taylor, "Conventions for the use of the Session Description 720 Protocol (SDP) for Digital Circuit Connections," Internet Draft 721 draft-taylor-mmusic-sdp-tdm-01.txt, Work in Progress, April 722 2002. 724 [10] Christian Huitema, "RTCP attribute in SDP," Internet Draft 725 draft-ietf-mmusic-sdp4nat-02.txt, Work in Progress, February 726 2002. 728 [11] Jari Arkko, Elisabetta Carrarra, Fredrik Lindholm, Mats Naslund, 729 and Karl Norrman, "Key Management Extensions for SDP and 730 RTSP," Internet Draft draft-ietf-mmusic-kmgmt-ext-05.txt, Work 731 in Progress, June 2002. 733 [12] Sean Olson, Gonzalo Camarillo, Adam Roach, 735 [13] G. Camarillo (ed), W. Marshall (ed), J. Rosenberg, "Integration 736 of Resource Management and SIP", Internet Draft draft-ietf-sip- 737 manyfolks-resource-03.txt, Work in Progress, November 2001. 739 [14] G. Camarillo, H. Schulzrinne, and E. Burger, "The source and 740 sink attributes for the Session Description Protocol", Internet 741 Draft draft-camarillo-mmusic-source-sink-00.txt, Work in 742 Progress, September 2002. 744 [15] Mark Baugher, "SDP Security Descriptions for Media Streams", 745 Internet Draft draft-baugher-mmusic-sdpmediasec-00.txt, Work in 746 Progress, September 2002. 748 [16] B. Quinn and R. Finlayson, "SDP Source-Filters", Internet 749 Draft draft-ietf-mmusic-sdp-srcfilter-01.txt, Work in Progress, 750 July 2002. 752 [17] G. Camarillo and A. Monrad, "Mapping of Media Streams to 753 Resource Reservation Flows", Internet Draft draft-ietf-mmusic- 754 reservation-flows-00.txt, Work in Progress, October 2002. 756 11. Full Copyright Statement 758 Copyright (C) The Internet Society (2002). All Rights Reserved. 760 This document and translations of it may be copied and furnished to 761 others, and derivative works that comment on or otherwise explain it 762 or assist in its implmentation may be prepared, copied, published and 763 distributed, in whole or in part, without restriction of any kind, 764 provided that the above copyright notice and this paragraph are 765 included on all such copies and derivative works. However, this 766 document itself may not be modified in any way, such as by removing 767 the copyright notice or references to the Internet Society or other 768 Internet organizations, except as needed for the purpose of 769 developing Internet standards in which case the procedures for 770 copyrights defined in the Internet Standards process must be 771 followed, or as required to translate it into languages other than 772 English. 774 The limited permissions granted above are perpetual and will not be 775 revoked by the Internet Society or its successors or assigns. 777 This document and the information contained herein is provided on an 778 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 779 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 780 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 781 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 782 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.