Network Working Group J. Ott Request for Comments: 4637 Helsinki University of Technology Category: Informational C. Perkins University of Glasgow January 2007 Transition from the Session Description Protocol (SDP) to SDP Next Generation (SDPng) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Today, the Session Description Protocol (SDP) is 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, has been 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. 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 Ott & Perkins Informational [Page 1] RFC 4637 SDPng Transition January 2007 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, workarounds (typically called "extensions") for those shortcomings could be found that 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. Note 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 o SDP: Session Description Protocol [1] and o Session Description and Capability Negotiation [9]. For SDP, a number of additional features that need to be taken into account are defined in the following documents: o the offer/answer scheme of interpreting and matching media session descriptions to negotiate media sessions to be used in call or conference in a single round-trip (RFC 3264 [6]); o full support for IPv6 as the network layer protocol (RFC 3266 [2]); o SDP extensions to allow selecting Asynchronous Transfer Mode (ATM) virtual circuits as an additional network protocol and specifying ATM-specific parameters (RFC 3108 [3]); Ott & Perkins Informational [Page 2] RFC 4637 SDPng Transition January 2007 o a general extension to deal with connection-oriented transport protocols such as TCP [12]; o an extension to support Stream Control Transmission Protocol (SCTP) as a media transport protocol in addition to UDP and TCP [17]; o an SDP extension to explicitly specify the RTP Control Protocol (RTCP) port number to enable the necessary expressiveness for Network Address Translation (NAT) traversal [8]; o a mechanism (media identification, "mid") for naming and grouping ("group") SDP media lines according to one or more criteria, e.g., for the purpose of lip-synchronization or for identifying media sessions carrying the same content (RFC 3388 [4], [10]); o the capability to indicate which media sessions shall be mapped into the same resource reservation context [13]; o an extension to allow expression of simultaneous capabilities across media sessions and formats (RFC 3407 [5]) o attributes for passing parameters of a keying protocol (such as Multimedia Internet KEYing (MIKEY)) as part of a session description [11]; o support for conveying cryptographic parameters as part of a session description [15]; o a mechanism to explicitly specify the sources allowed to provide input to media sessions [16]; and o a simple language to provide instructions to media mixers on which incoming media streams shall be combined to produce which outgoing ones (and possibly how they shall be combined) [14]. 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. Ott & Perkins Informational [Page 3] RFC 4637 SDPng Transition January 2007 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, and Network News Transfer Protocol (NNTP)) 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 participants 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 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). Ott & Perkins Informational [Page 4] RFC 4637 SDPng Transition January 2007 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 capabilities 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". Note 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 time division multiplexing (TDM) networks. 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 a 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 mapping 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. Ott & Perkins Informational [Page 5] RFC 4637 SDPng Transition January 2007 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 that 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 for 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 for an even more formal description of 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, and shared editors). 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 codec attributes in MIME registrations for SDP. Note that it is expected that the MIME namespace for codecs will be mapped into the SDPng namespace, and a consistent mapping from SDP "a=fmtp:" attributes to SDPng codec parameters will be defined. Ott & Perkins Informational [Page 6] RFC 4637 SDPng Transition January 2007 By means of its conceptual differentiation into Potential and Actual Configurations, SDPng supports both 1) indicating a system's capabilities (without specifying transport addresses) separately from the instantiation of a particular media stream and 2) 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 Actual Configurations but use them to negotiate media streams 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, while the short-term SDPng specification aims at supporting only the widespread offer/answer model for capability negotiation, a future extension will also allow for content-independent negotiation of session parameters by defining collapsing/intersection rules. In particular, SDPng will 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, but there is also no perceived urgent demand, so this sophisticated functional component of SDPng is left to a future protocol extension. The base SDPng protocol will provide the necessary flexibility, however. 4. Integration with Session Control Protocols For each of the session control protocols described above, this section outlines 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 revisions of SAP specified, version 0, which is implemented in a number of experimental tools, and version 1, which is defined in RFC 2974 [18]. Ott & Perkins Informational [Page 7] RFC 4637 SDPng Transition January 2007 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 a different character sequence in the beginning of the announcement body, but this is not recommended. Instead, SAPv1 should be used, since it contains an explicit payload identifier. SAPv1: In SAPv1, an explicit payload type field (containing a MIME type) is available and should be used to differentiate between SDP and SDPng contents. Two approaches are conceivable: Either multipart MIME message is used with two parts containing the same session descriptions, one expressing it in SDP and the other in SDPng or, alternatively, two alternate session announcements may be used (being properly distinguished by the SDP "o=" field and the SDPng equivalent). It is recommended that implementations recognize the MIME multipart/alternative type in SAPv1 announcements, allowing for a simple transition to SDPng. Note that current session directory implementations only support SDP. Nevertheless, using the SAP Message Identifier Hash and the source address, they should be able to perform session deletions and modifications properly, even without understanding the format contained in the SAP message body. For the introduction of SDPng, session announcements should be made "bi-lingual", i.e., in SDP and SDPng. If a SAP announcer for some reason knows that all its potential audience will support SDPng, the SDP announcement should be omitted. Note that for IPv4-based multicast sessions, session directories still may rely on parsing the session specifications to avoid clashes in the multicast address space. Introducing a new session description language will prevent older implementations from continuing this practice successfully, assuming that only SDPng announcements are used and/or that old implementations do not support MIME multipart/alternative message bodies. This use of SAP is deprecated, however. Ott & Perkins Informational [Page 8] RFC 4637 SDPng Transition January 2007 4.2. Real-Time Streaming Protocol (RTSP) RTSP uses SDP to provide presentation descriptions (with a presentation comprising one or more media sessions), typically communicated from the server to the client for playing and in the opposite direction for recording. The presentation description may also include initialization data for the various media streams and URLs to be used for controlling the entire presentation as well as the individual media sessions. Transport parameters (such as IP addresses, port numbers, etc.) are conveyed as part of the RTSP header fields. RTSP uses the Content-Type: header field to indicate the format of the enclosed entity. This provides a straightforward means for distinguishing SDP and SDPng-based presentation descriptions. In addition, the Accept: header should be used by the client to indicate which content types it supports. If the client specifies both SDP and SDPng as acceptable, the server should provide only the SDPng- based presentation description. If the client does not indicate a particular Content-Type:, the server can, theoretically, use MIME multipart bodies (e.g., "multipart/alternative") to convey both description types simultaneously. However, it is generally not expected that today's RTSP clients and servers will be able to handle multipart bodies. Hence, if no hint is provided by the client by means of the Accept: header, the server must provide only an SDP description. In general, it would be preferable to have the servers migrate to always supporting both description formats, thus enabling the clients to choose. The servers should indicate SDPng support by means of suitable header fields whenever possible. Finally, RTSP makes special provisions to interwork with firewalls by including the crucial transport parameters in a separate RTSP header field in addition to the presentation description. This practice, in principle, allows for changing the presentation description format without having to worry about the operation of firewalls and similar devices. 4.3. Session Initiation Protocol (SIP) The use of SDP with SIP follows the offer/answer model and is described in [6]. It is key to the (efficiency of the) offer/answer model that a complete capability exchange and media stream instantiation be carried out in one round-trip, which is supported Ott & Perkins Informational [Page 9] RFC 4637 SDPng Transition January 2007 by SDP. While SDPng allows a separating capability exchange from media session instantiation, those two pieces are also easily integrated in a single step. SIP also uses a Content-Type: header to indicate the nature of data carried in its message body, and SIP explicitly calls for supporting MIME multipart message bodies. While, again, the use of MIME multipart/alternative would in principle be possible (from a theoretical perspective), issues regarding the actual implementation of multipart/alternative in SIP entities have been raised. As backward compatibility has to be achieved, a different approach is suggested: A SIP User Agent Client (UAC) may use an SDPng message body in a SIP INVITE (or other) message. If the SIP User Agent Server (UAS) does not support SDPng, it will return a "415 Unsupported Media Type" response to the UAC and indicate acceptable content types in the Accept: header (probably including "application/sdp"). The SIP UAC must then retry the INVITE (or other) message using the indicated session description language. The SIP UAC should cache knowledge about which peers did not understand SDPng as session description formats for a limited amount of time (e.g., several days) so that extra round-trips for session setup are incurred infrequently. Whenever a peer has sent an SDPng description (or it is known from other means that the peer supports SDPng), this information should also be cached. The SIP Accept: header can be exploited to determine the capability of a peer to understand SDPng in addition to (or instead of) plain SDP. Methods such as OPTIONS may be used to determine a peer's support for SDPng. However, a peer's capabilities may not be known when the first message is sent, which may introduce an extra round- trip if including SDP and SDPng in the initial INVITE message is not an option. Further approaches to make a UA's support for SDPng known ahead of time should be explored. A number of SDP extensions have been motivated by SIP-based applications, and these need to be accommodated in SDPng as well. Features such as "simcap" and "FID" are inherently supported by SDPng; proper definitions for connection-oriented media need to be fully understood and then incorporated. Key management attributes (as defined in [11]) need to be included (not just for SIP) and general mechanisms may also need to be included to signal security capabilities [11] [15] and to indicate their optional or mandatory use. The same applies to Quality of Service (QoS) parameters [13] (which are largely also motivated by SIP but are also useful with control protocols). Ott & Perkins Informational [Page 10] RFC 4637 SDPng Transition January 2007 Numerous extensions to SDP have been developed for the purpose of supporting certain SIP requirements; actually, most of those listed in section 1 fall into this category. The following paragraphs address how those are handled by and mapped to SDPng. IPv6 is natively supported by SDPng. For other network protocols, such as ATM and TDM, which have only come up in the context of MEGACO, see below. Similar SDPng packages need to be defined that provide the same information as the corresponding SDP extensions. Support for connection-oriented media in general will be supported in SDPng using a similar parameterization. Support for SCTP will be equivalent to the approach taken for SDP as the parameters are comparable. SDP's explicit RTCP port number parameter (that helps with NAT traversal) is inherently available in the Real-time Transport Protocol (RTP) transport specification of SDPng. Media session identification is also provided by the SDPng spec by means of naming attributes in the potential as well as actual configurations. The "Session Attributes" section of SDPng is meant to provide meta-information about the media sessions such as grouping of lip-synchronization, indicating streams semantics, etc. This section is also the place to express media "mixing" attributes as discussed in [14]. QoS parameterizations for SDPng are developed separately as package enhancements and are still under discussion. Simultaneous capabilities are dealt with by the Constraints section of SDPng where restrictions across several components as well as within a single component can be expressed. Security parameters have not yet been developed for the SDPng specification. The intention is to define a separate security package (similar to codec and transport definitions). Security parameters may be provided in the definition section for later reference from within the component specification or may be specified in-line in a component. Indicating permissible sources for unicast and particularly multicast media sessions is already covered in the basic SDPng transport specification. In summary, most of the newly developed SDP attributes and their usages either have been considered in the SDPng base specification and the transport packages or will be added as additional attributes or as separate packages. Ott & Perkins Informational [Page 11] RFC 4637 SDPng Transition January 2007 Note that the above discussions are not just applicable to SIP but may be used in a broader scope (e.g., with RTSP or MEGACO). 4.4. Media Gateway Control Protocol (MEGACOP) The MEGACO specification already supports two different encodings for capability and media stream descriptions: a text-based variant based upon (a modified) SDP and a binary representation of the same information set. MGCs are required to implement both encodings, whereas MGs have the choice to pick either or both. Differentiation between the protocol encoding variants is done using different port numbers: 2944 for the text-based and 2945 for the binary encoding. Unfortunately, within the text-based encoding, there is no means to differentiate several description formats. SDP messages are carried as an "octet string" without any type identifier. Defining a third port number for this further differentiation does not seem to be appropriate, particularly since the message encoding is still a text format. The remaining means for distinction is that an SDP specification would start with a "v=0" line while an SDPng document would begin with a different character sequence. Note that MEGACOP also supports a binary encoding for SDP messages; current practice seems to favor the text encoding for SDP and hence we will not address a binary encoding for SDPng. Within the context of MEGACO, various extensions to SDP have been defined, addressing its use for capability description and also defining support for further network types (presently, ATM and TDM). Capability descriptions are inherently supported by SDPng. To add support for further networks, the respective parameters need to be defined as network-specific SDNng packages. 5. SDPng and Middleboxes Middleboxes (e.g., firewalls, NATs, and NAPTs) are of significant importance for many deployment scenarios for SDP-based signaling protocols. The SDP description typically carries addressing parameters for media sessions that may be invalidated by middleboxes: by firewalls because they block packet destined at the respective addresses and by NA(P)Ts because they change the addresses that must actually be used. A number of approaches have been devised to deal with currently deployed and, eventually, future middleboxes: 1) co-locating a proxy for the respective signaling protocol(s) with a middlebox, 2) using Ott & Perkins Informational [Page 12] RFC 4637 SDPng Transition January 2007 extra protocols to determine the presence and the mode of operation of a NA(P)T (which does not work for firewalls), and 3) the definition of a control protocol for middleboxes. While approach 1) is entirely up to the manufacturers of middleboxes, 2) and 3) are subject to IETF standardization in the MIDCOM Working Group. 1) Proxies that are incorporated in middleboxes to parse and (in the case of NATs) possibly alter the contents of session descriptions exchanged in the signaling path will need to implement SDPng in the future. For a (potentially long) interim period, both SDP and SDPng need to be supported by such devices. 2) If entities involved in the respective signaling path use protocols such as Simple Traversal of the UDP Protocol through NAT (STUN) to determine the presence of a NAT and its mode of operation, it is up to these entities to include the correct addressing information in the SDP or SDPng session descriptions. NATs continue to operate as before and do not require any changes because of a migration from SDP to SDPng. 3) If local signaling servers or other entities use a MIDCOM protocol to configure a firewall or NAT to allow certain media streams to pass through, again, no changes need to be made to MIDCOM-enabled firewalls. The migration from SDP to SDPng is transparent to them; only the involved signaling component needs to support SDPng, but they would need to do so anyway. 6. Directing the Evolution of SDP With the transition from SDP to SDPng, there is the question of the evolution of SDP and the legacy systems that use it. The SDP specification [1] is stable, and a number of extensions to SDP for use in offer/answer scenarios are also available. These include grouping [4] and capability negotiation [5], which have been published as proposed standard RFCs, bringing minimal capability/alternative descriptions to SDP. Related is the SDP offer/answer model for SDP, published as RFC 3264 [6]. This defines the model used to complete the steps of a negotiation using SDP. A similar mode of operation will be provided for SDPng for baseline operation with SIP (and possibly RTSP). Ott & Perkins Informational [Page 13] RFC 4637 SDPng Transition January 2007 All these are subsumed into SDPng, so there should be no further need for development in these areas; applications with requirements that are not met by these specifications should use SDPng. There have recently been proposals to add quality of service negotiation for SDP and, similarly, we expect other extensions to be proposed over time. Due to the well-known limitations of SDP, we do not believe it appropriate to continue development of more elaborate extensions: for negotiation, for QoS, for security, and for other general-purpose or application-specific needs. The exceptions to this rule are clearly the addition of security features to SDP (which are required for many current SDP deployment scenarios) as well as minor extensions for media session attributes (e.g., indicating the use of joint vs. separate resource reservations as documented in [7]). Overall, new work should be done in the framework of SDPng where applications and their requirements for (new) expressiveness in end- to-end exchanges to negotiate and configure media sessions will hopefully act as a driver for that process. 7. IANA Considerations The transition from SDP to SDPng will require IANA to define new parameter registries, which will be created and populated as SDPng evolves. This memo does not, in itself, require any action by IANA. 8. Security Considerations Since SDPng performs largely the same role as SDP+extensions, it is not expected that there will be significant new security considerations as a result of the transition. The security considerations section of [9] provides further details. During the transition process, it is likely that dual descriptions will be common. There is a potential for inconsistency between definitions, which may have unintended consequences if one part of the system, for example a middlebox, interprets the SDP format definition while another interprets the SDPng format definition. Ott & Perkins Informational [Page 14] RFC 4637 SDPng Transition January 2007 9. References 9.1. Normative References [1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [2] Olson, S., Camarillo, G., and A.B. Roach, "Support for IPv6 in Session Description Protocol (SDP)", RFC 3266, June 2002. [3] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001. [4] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. [5] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002. [6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [7] Camarillo, G. and A. Monrad, "Mapping of Media Streams to Resource Reservation Flows", RFC 3524, April 2003. [8] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. 9.2. Informative References [9] Kutscher, D., Ott, J., and C. Bormann, "Session Description and Capability Negotiation", Work in Progress. [10] Camarillo, G. and J. Rosenberg, "The Alternative Semantics for the Session Description Protocol Grouping Framework", Work in Progress, February 2003. [11] Arkko, J., Lindholm, F., Naslund, M., Norrman, K. and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006. [12] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. Ott & Perkins Informational [Page 15] RFC 4637 SDPng Transition January 2007 [13] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [14] Camarillo, G., Schulzrinne, H., and E. Burger, "The source and sink attributes for the Session Description Protocol", Work in Progress, September 2002. [15] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006. [16] Quinn, B. and R. Finlayson, "Session Description Protocol (SDP) Source-Filters", RFC 4570, July 2006. [17] Fairlie-Cuninghame, R., "Guidelines for specifying SCTP-based media transport using SDP", Work in Progress, May 2001. [18] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. Authors' Addresses Joerg Ott Helsinki University of Technology Networking Laboratory PO Box 3000 02015 TKK Finland EMail: jo@acm.org Colin Perkins Department of Computing Science University of Glasgow 17 Lilybank Gardens Glasgow G12 8QQ UK EMail: csp@csperkins.org Ott & Perkins Informational [Page 16] RFC 4637 SDPng Transition January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ott & Perkins Informational [Page 17]