INTERNET-DRAFT J. Ott/C. Perkins Expires: January 2003 TZI/ISI July 2002 SDPng Transition draft-ietf-mmusic-sdpng-trans-01.txt Status of this memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Abstract The Session Description Protocol (SDP) is today widely used in the Internet to announce as well as negotiate multimedia sessions and exchange capabilities. Having originally been designed for session announcements only, as opposed to announcements and capabilities negotiation announcements, native SDP lacks numerous features to be applicable in many session scenarios. Numerous extensions have been developed to circumvent SDP's shortcomings -- but they have also repeatedly shown its inherent limitations. A successor protocol -- termed "SDPng" for the time being -- is developed to address the aforementioned needs of Internet applications in a more structured manner. With the huge installed base of SDP-based applications, a migration path needs to be developed to move from SDP to SDPng over time. This document outlines how this migration can be achieved: in general as well as for the various IETF control protocols that potentially make use of SDP and SDPng. This document is a product of the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working Ott/Perkins [Page 1] INTERNET-DRAFT SDPng Transition July 2002 group's mailing list at mmusic@ietf.org and/or the authors. 1. Introduction SDP is now widely used within the Internet community to describe media sessions and, in a limited fashion, system capabilities relating to (multi)media sessions, for a variety of application scenarios: session announcements, interactive session setup, capability assessment and remote control of media streams. All but the first of these are rather different from what SDP was originally designed for -- but all of them share the idea of setting up and configuring media streams. Over time, its wide range of uses has revealed numerous shortcomings -- most of which stem from the fact that SDP has been used for lack of a better alternative and its semantics have been re-interpreted to make it fit the respective scenarios' needs. In many cases, workrounds (typically called "extensions") for those shortcomings could be found which are often rather cumbersome. While this practice has extended SDP's lifetime and provided at least a suitable basis for numerous applications, in parallel, a successor protocol -- currently referred to as "SDPng" -- has been developed. It is worthwhile noting that the aforementioned applications' needs are sufficiently similar for a single description protocol to take care of them if it was designed for this purpose from the beginning. As a lesson learned from SDP, any further expansion in scope should be avoided where no clear fit can be seen -- and specific (different) solutions should be developed instead. The design of SDPng takes into account the requirements arising from the above application scenarios and puts particular emphasis on protocol extensibility and modularization of extensions, at the same time keeping the core description format simple. SDPng uses a different (more expressive) syntax than SDP does and hence is not backward compatible at the syntax level. Nevertheless, the concepts of SDPng take into account the migration issues from SDP to SDPng by providing straightforward mappings between the two formats where possible and try to maximize compatibility from a semantics perspective. The current revisions of SDP and SDPng are documented in [1] draft-ietf-mmusic-sdp-new-10.txt and [2] draft-ietf-mmusic-sdpng-05.txt. For SDP, numerous additional documents need to be taken into account: [3] RFC 3108 [4] draft-ietf-mmusic-fid-06.txt Ott/Perkins [Page 2] INTERNET-DRAFT SDPng Transition July 2002 [5] draft-andreasen-mmusic-sdp-simcap-05.txt [6] draft-ietf-mmusic-sdp-offer-answer-02.txt [7] draft-fairlie-mmusic-sdp-sctp-00.txt [8] draft-ietf-mmusic-sdp-comedia-03.txt [9] draft-taylor-mmusic-sdp-tdm-01.txt [10] draft-ietf-mmusic-sdp4nat-02.txt [11] draft-ietf-mmusic-kmgmt-ext-05.txt [12] draft-ietf-mmusic-sdp-ipv6-03.txt This document outlines a migration path from SDP to SDPng, starting from a short overview of the current application scenarios. In the next step, we highlight which design decisions taken for SDPng should simplify a smooth migration and describe how mappings between the two description formats can be performed at an abstract level. We then address procedural issues for integrating SDP and SDPng into the various protocols relying on those media description formats. Finally, we summarize work items on the agenda for SDPng. 2. Application Scenarios The following session control protocols that make use of SDP have been standardized in the IETF so far: 1. SDP was originally developed to announce (Mbone-based) multimedia sessions via session directories using the Session Announcement Protocol (SAP) -- but other mechanisms for disseminating the session descriptions (such as HTTP, SMTP, NNTP, etc.) are conceivable as well. The major property of this application scenario is that the creator of the session description defines a (set of) fixed choice(s) for all media types in a conference and the conference partipants have no way to influence these. If they support at least one of the codecs for a particular media type they can participate in this media session, otherwise they cannot. There is no interaction between sender(s) and receiver(s) to negotiate the media stream codecs and parameters. This scenario is referred to as "announcement". 2. Another use of SDP is in conjunction with the Real-Time Streaming Protocol (RTSP). In RTSP, SDP is used to convey descriptions of a media stream interactively requested to be played from a server (or recorded by a server). SDP itself is not used for capability negotiation, not even for the addresses to be used; those are negotiated within RTSP and may override Ott/Perkins [Page 3] INTERNET-DRAFT SDPng Transition July 2002 the addresses specified as part of SDP. This scenario is referred to as "retrieval". 3. With SIP, SDP is used to propose media stream configurations and choose out of these (i.e. enable a subset of these). By proposing and accepting media stream configurations, endpoints use SDP to implicitly describe their capabilities and carry out a negotiation procedure on the media streams to use. In the context of SIP, specific meanings (including required extensions) have been defined for use of SDP with unicast addresses, for connection-oriented transports, and for certain media level attributes (such as the direction attribute send- only, receive-only, and inactive). Numerous extensions have been proposed to extend SDP to better suit SIP's needs. Besides a description of the offer/answer model, these extensions particularly include the ability to describe simultaneous capabilites and to group media stream semantically. This scenario is referred to as "offer/answer". 4. SDP is used to convey the capability descriptions of a MEGACO media gateway (MG) to its media gateway controller (MGC) as well as for the MGC to instruct the MG where to send media streams to and from where to receive media streams, including codec and parameter choice. For this purpose, SDP has been modified/extended to some degree to fit the MEGACO needs. This scenario is referred to as "gateway control". It should noted that the original SDP concept already provided an extension mechanism to cover other network types than IPv4 and IPv6; however, specific extensions have only been defined recently for ATM and are now under discussion for TDM. Extensions to other transport (including radio interfaces or next generation wireless networks) as well as to new types of session descriptions (e.g. electronic program guides) are conceivable. 3. Mapping SDP to SDPng On a transition path from SDP to SDPng, allowing for a somewhat straightforward mapping of (parts of) one description format onto the other is of crucial importance. SDPng has been designed in way that allows many of the session description features of SDP to be easily mapped onto the SDPng format and vice versa -- except that SDPng is more expressive than SDP and hence information loss is not unlikely to occur when doing the reverse mapping. The final mapping rules between SDP and SDPng to be drawn up shall ensure that when mapping Ott/Perkins [Page 4] INTERNET-DRAFT SDPng Transition July 2002 SDP to SDPng and then back to SDP will produce an SDP that is functionally identical to the one originally fed into the mapping process. Note that the use of a number of SDP extensions (FID, SIMCAP) may be implied in this mapping process, depending on the use of SDP. The mapping rules will ensure that no information loss will occur when translating from SDP to SDPng. The SDPng design uses a structure of four sections: definitions, potential or actual configurations, constraints and session attributes. Of these, the "Configurations" and "Session Attributes" sections map well onto the current SDP. The "Definitions" and "Constraints" sections provide additional structure which is not directly expressible in SDP. o At the media description level, the Potential and Actual Configurations specified in the "Configurations" section maps well to media descriptions ("m=", possibly "c=", and associated attributes ("a=") lines). o At the session description level, the SDP session parameters are largely reflected in the "Session Attributes" section of SDPng. The attributes proven suitable for session announcements have been used as the basis when defining SDPng. In SDPng, media descriptions are explicitly tagged with identifiers and thus are easily referenced for semantically grouping media streams (e.g. to describe alternative audio in different languages, media streams to be synchronized, or media streams to carry the same information simultaneously but with different encodings) -- as has been defined for SDP in a limited fashion by the "fid" attribute set. SDPng allows even to more formally describe the syntax of individual or compound media streams in the "Session Attributes" section. Furthermore, SDPng supports a superset of additional constraints that may be realized by the "simcap" extensions for SDP in the "Constraints" section. Additional address families such as ATM or TDM bearers, next generation wireless network bearers, DVB channels, etc. can be incorporated into SDPng by defining the appropriate extensions for the SDPng transports. Similarly, new codecs can be added by just defining new codec specifications or defining entire new classes of applications to be described as new content types ("codec") to be carried in a media session (including e.g. text, fax, slide presentations, shared editors, etc). If necessary, sophisticated parameter structures can be supported (even though the authors believe that simplicity is key to interoperability here). This is similar to, but more structured than, the definition of new codecs attributes/MIME registrations in SDP. By means of its conceptual differentiation into Potential and Actual Configurations, SDPng supports both indicating a system's Ott/Perkins [Page 5] INTERNET-DRAFT SDPng Transition July 2002 capabilities (without specifying transport addresses) separately from the instantiation of a particular media stream as well as conveying capability descriptions and instantiation proposals at the same time -- thereby providing a good fit for all the above session control scenarios: the "announcement" and "retrieval" scenarios will just use rather fixed Actual Configurations. The "offer/answer" model will use use Actual Configuration but use them to negotiate media strams in a two-way handshake but may in addition use Potential Configurations to indicate capabilities that shall not be used immediately. The "gateway control" scenario will use both: Potential Configurations to describe an MG's capabilities and Actual Configurations for setting up media sessions at MGs as well as retrieving information about currently active media sessions. This differentiation is not directly expressible in SDP, although various extensions can be used to overload SDP semantics to achieve at least part of this effect. Finally, SDPng is also intended to allow for content-independent negotiation of session parameters by defining collapsing/intersection rules. In particular, SDPng tries to take the need for multicast- based distributed calculation of joint capabilities into account for those rules (but note that it is *not* intended as a generic format for describing conference state information). Such functionality is not covered by current SDP. 4. Integration with Session Control Protocols This section outlines for each of the session control protocols described above how SDP and SDPng can be used in parallel and indicates how a suitable transition could be achieved. 4.1. Session Announcement Protocol (SAP) There are two revision of SAP specified, version 0 which is implemented in a number of experimental tools, and version 1 which is defined in RFC 2972. SAPv0:SAPv0 does not support a mechanism to identify the content type of a session announcement but implicitly assumes SDP. Proper parsers will note that the contents of the SAPv0 message does not begin with a "v=" line and hence will ignore the entire announcement. SDPng contents MAY be identified by the character sequence " Universitaet Bremen MZH 5180 Bibliothekstr. 1 D-28359 Bremen Germany tel:+49-421-201-7028 sip:jo@tzi.org Colin Perkins USC Information Sciences Institute 3811 North Fairfax Drive, Suite 200 Arlington, VA 22203 USA tel:+1-703-812-3705 Ott/Perkins [Page 10] INTERNET-DRAFT SDPng Transition July 2002 8. References [1] Mark Handley, Van Jacobson, Colin Perkins, "SDP: Session Description Protocol," Internet Draft draft-ietf-mmusic-sdp- new-10.txt, Work in Progress, May 2002. [2] Dirk Kutscher, Joerg Ott, Carsten Bormann, "Session Description and Capability Negotiation", Internet Draft draft-ietf-mmusic- sdpng-05.txt, Work in Progress, July 2002. For SDP, numerous additional documents need to be taken into account: [3] 3108 R. Kumar, M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections," RFC 3108, May 2001. [4] Gonzalo Camarillo, Jan Holler, Goran AP Eriksson, Henning Schulzrinne, "Grouping of media lines in SDP," Internet Draft draft-ietf-mmusic-fid-06.txt, Work in Progress, February 2002. [5] F. Andreasen, "SDP Simple Capability Negotiation," Internet Draft draft-andreasen-mmusic-sdp-simcap-05.txt, Work in Progress, February 2002. [6] Jonathan Rosenberg, Henning Schulzrinne, "An Offer/Answer Model with SDP," Internet Draft draft-ietf-mmusic-sdp-offer- answer-02.txt, Work in Progress, February 2002. [7] Robert Fairlie-Cuninghame, "Guidelines for specifying SCTP- based media transport using SDP," Internet Draft draft-fairlie- mmusic-sdp-sctp-00.txt, Work in Progress, May 2001. [8] David Yon, "Connection-Oriented Media Transport in SDP," Internet Draft draft-ietf-mmusic-sdp-comedia-03.txt, Work in Progress, June 2002. [9] Tom Taylor, "Conventions for the use of the Session Description Protocol (SDP) for Digital Circuit Connections," Internet Draft draft-taylor-mmusic-sdp-tdm-01.txt, Work in Progress, April 2002. [10] Christian Huitema, "RTCP attribute in SDP," Internet Draft draft-ietf-mmusic-sdp4nat-02.txt, Work in Progress, February 2002. [11] Jari Arkko, Elisabette Carrarra, Fredrik Lindholm, Mats Naslund, Karl Norrman, "Key Management Extensions for SDP and RTSP," Internet Draft draft-ietf-mmusic-kmgmt-ext-05.txt, Work in Progress, June 2002. [12] Sean Olson, Gonzalo Camarillo, Adam Roach, "Support for IPv6 in SDP," Internet Draft draft-ietf-mmusic-sdp-ipv6-03.txt, Work in Ott/Perkins [Page 11] INTERNET-DRAFT SDPng Transition July 2002 Progress, February 2002. [13] G. Camarillo (ed), W. Marshall (ed), J. Rosenberg, "Integration of Resource Management and SIP", Internet Draft draft-ietf-sip- manyfolks-resource-07.txt, Work in Progress, April 2002. 9. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Ott/Perkins [Page 12]