INTERNET-DRAFT
Network Working Group                                             J. Ott/C. Ott
Request for Comments: 4637             Helsinki University of Technology
Category: Informational                                       C. Perkins
Expires: November 2003                                           TZI/ISI
                                                             15 May 2003

                            SDPng
                                                   University of Glasgow
                                                            January 2007

       Transition
                  draft-ietf-mmusic-sdpng-trans-04.txt from the Session Description Protocol (SDP) to
                      SDP Next Generation (SDPng)

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 Memo

   This memo provides information for 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. community.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list does
   not specify an Internet standard 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. any kind.  Distribution of this document
   memo is unlimited.

   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
   group's mailing list at mmusic@ietf.org and/or the authors.

Abstract

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Today, 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 -- shortcomings, but they have also
   repeatedly shown its inherent limitations.  A successor protocol -- protocol,
   termed "SDPng" for the time being -- is 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 assessment, and remote control of media streams.  All but
   the first of these are rather different from what SDP was originally
   designed for -- 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 -- 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 workarounds (typically called "extensions")
   for those shortcomings could be found which 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 -- protocol, currently referred to as "SDPng"
   -- "SDPng", has
   been developed.

        It is worthwhile noting

      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 -- 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    draft-ietf-mmusic-sdp-new-12.txt  SDP: Session Description Protocol [1] and

   o    draft-ietf-mmusic-sdpng-06.txt  Session Description and Capability Negotiation [9].

   For SDP, a number of additional features are defined in the following
   documents that need to be taken into account:
   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 ATM Asynchronous Transfer Mode (ATM)
      virtual circuits as an additional network protocol and specifying
      ATM-specific parameters (RFC 3108 [3]);
   o  a general extension to deal with connection-oriented transport
      protocols such as TCP [12];

   o  an extension to support SCTP Stream Control Transmission Protocol
      (SCTP) as a media transport protocol in addition to UDP and TCP
      [17];

   o  an SDP extension to explicitly specify RTCP the RTP Control Protocol
      (RTCP) port number to enable the necessary expressiveness for NAT
      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. 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 simultanous simultaneous capabilities
      across media sessions and formats (RFC 3407 [5])

   o  attributes for passing parameters of a keying protocol (such as
        MIKEY)
      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 possbily 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.

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) -- (SAP), but other mechanisms for disseminating the session
      descriptions (such as HTTP, SMTP,
        NNTP, etc.) 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
        partipants
      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. (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
      media-level attributes (such as the direction attribute send-
        only, 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 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".

   It should noted

   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 TDM. time division multiplexing (TDM) networks.
   Extensions to other transport (including radio interfaces or next next-
   generation wireless networks) as well as to new types of session
   descriptions (e.g. (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 -- 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
   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 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 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 when for defining SDPng.

   In SDPng, media descriptions are explicitly tagged with identifiers
   and thus are easily referenced for semantically grouping media
   streams (e.g. (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) -- encodings), as has been
   defined for SDP in a limited fashion by the "fid" attribute set.
   SDPng allows for an even to more formally describe 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. (including, e.g., text, fax, slide presentations, and shared
   editors, etc).
   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.

        It

      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.

   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 as well as and 2) conveying
   capability descriptions and instantiation proposals at the same time
   -- 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 Configurations but use them to negotiate media
   strams 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 -- SDP, but there is also no perceived urgent demand demand, so that 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

   This section outlines for

   For each of the session control protocols described above 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 0, which is
   implemented in a number of experimental tools, and version 1 1, which
   is defined in RFC 2972.

   SAPv0:SAPv0 2974 [18].

   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 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: In SAPv1, an explicit payload type field (containing a MIME
          type) is available and should be used to differentiate between
          SDP anf and SDPng contents.  Two approaches are conceivable:
          Either multipart MIME message is used with two parts
          containing the same session descriptions -- descriptions, one expressing it in
          SDP and the other in SDPng.  Alternatively, 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.

   It should be noted

   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 -- 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. 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.

   It should be noted that,

   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 -- 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.

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) 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 (such as IP
   addresses, port numbers, etc. -- 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: Content-Type:, the
   server can, theoretically, use MIME multipart bodies (e.g. (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 preferrable 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 provision provisions to interwork with firewalls by
   including the crucial transport parameters in a separate RTSP header
   field _in_addition_ in addition to the presentation description.  This practice, in
   principle, allows to change 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/anser 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 -- round-trip, which is supported
   by SDP.  While SDPng allows to separate a separating capability exchange from
   media sesssion 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; 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 UAC MAY User Agent Client (UAC) may use an SDPng message body in a SIP
   INVITE (or other) message.  If the SIP UAS 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. (e.g., several days) so that
   extra round-trips for session setup are only 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) instead of) plain
   SDP.  Methods such as OPTIONS MAY 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 sent, which may introduce an extra round-trip 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
   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
   (as defined in [11] [11]) need to be included (not just for SIP) and so
   general mechanisms may also need to be general mechanisms included to signal security
   capabilities [11] [15] and to indicate their optional or mandatory
   use.  The same applies to quality Quality of service Service (QoS) parameters [13]
   (which are largely also motivated by SIP but are also useful with
   control protocols).

   Numerous extensions to SDP have been developed for the purpose of
   supporting certain SIP requirements -- actually requirements; actually, most of those listed
   in section 1. 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 -- protocols,
   such as ATM and TDM, which have only come up in the context of
   MEGACO, see below -- similar 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 RTP 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, 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
   inline
   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 have either have been considered in the SDPng base specification
   and the transport packagaes packages or will be added as additional attributes
   or as separate packages.

   Note that the above discussions are not just applicable to SIP but
   may be used in a broader scope (e.g. (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 while 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. (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
   paramaters
   parameters for media sessions which 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
   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 WG. 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 STUN 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 need 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, SDP and the legacy systems which that use it.

   The SDP specification [1] is stable, and mostly corrects errors in
   the original specification, with the addition of very few new
   features.  The revision is expected to be published as a proposed
   standard RFC shortly, obsoleting RFC 2327.

   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 recently been approved
   published as proposed standard RFCs, bringing minimal
   capability/alternative descriptions to SDP.

   Related is the SDP offer/answer model for SDP, published as RFC3264 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).

   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.
   (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 process, it is likely that dual descriptions
   will be common.  There is a potential for inconsistancy inconsistency between
   definitions, which may have unintended consequences if one part of
   the system, for example a middlebox, interprets the SDP format whilst
   definition while another interprets the SDPng format definition.

9.  Author's Addresses

   Joerg Ott <jo@tzi.org>
   Universitaet Bremen
   MZH 5180
   Bibliothekstr. 1
   D-28359 Bremen
   Germany
   tel:+49-421-201-7028
   sip:jo@tzi.org

   Colin Perkins <csp@csperkins.org>
   USC Information Sciences Institute
   3811 North Fairfax Drive, Suite 200
   Arlington, VA 22203
   USA
   tel:+1-703-812-3705

10.  References

9.1.  Normative References

   [1]  Mark  Handley, Van M., Jacobson, Colin V., and C. Perkins, "SDP: Session
        Description Protocol," Internet Draft draft-ietf-mmusic-sdp-
        new-11.txt, Work in Progress, November 2002. Protocol", RFC 4566, July 2006.

   [2]  Sean  Olson, Gonzalo S., Camarillo, Adam G., and A.B. Roach, "Support for IPv6 in
        Session Description Protocol (SDP)", RFC 3266, June 2002.

   [3]  3108  Kumar, R. Kumar and M. Mostafa, "Conventions for the use of the
        Session Description Protocol (SDP) for ATM Bearer Connections," Connections",
        RFC 3108, May 2001.

   [4]  Gonzalo  Camarillo, Jan Holler, Goran AP G., Eriksson, Henning G., Holler, J., and H. Schulzrinne,
        "Grouping of media lines Media Lines in SDP," the Session Description Protocol
        (SDP)", RFC 3388, December 2002.

   [5]  Flemming  Andreasen, "SDP F., "Session Description Protocol (SDP) Simple
        Capability Declaration," Declaration", RFC 3407, October 2002.

   [6]  Jonathan Rosenberg  Rosenberg, J. and Henning H. Schulzrinne, "An Offer/Answer Model with SDP,"
        Session Description Protocol (SDP)", RFC 3264, June 2002.

   [7]  Camarillo, G. Camarillo and A. Monrad, "Mapping of Media Streams to
        Resource Reservation Flows", RFC 3524, April 2003.

   [8]  Christian  Huitema, "RTCP C., "Real Time Control Protocol (RTCP) attribute in SDP," Internet Draft
        draft-ietf-mmusic-sdp4nat-03.txt, Work in Progress, September
        2002.

10.1.
        Session Description Protocol (SDP)", RFC 3605, October 2003.

9.2.  Informative References

   [9]  Dirk  Kutscher, Joerg D., Ott, Carsten J., and C. Bormann, "Session Description and
        Capability Negotiation", Internet Draft draft-ietf-mmusic-
        sdpng-06.txt, Work in Progress, March 2003. Progress.

   [10] Gonzalo Camarillo Camarillo, G. and Jonathan J. Rosenberg, "The Alternative Semantics for
        the Session Description Protocol Grouping
        Framework," Internet Draft draft-camarillo-mmusic-alt-00.txt, Framework", Work in
        Progress, February 2003.

   [11] Jari Arkko, Elisabetta Carrarra, Fredrik J., Lindholm, Mats F., Naslund,
        and Karl M., Norrman, K. and E.
        Carrara, "Key Management Extensions for SDP Session Description
        Protocol (SDP) and
        RTSP," Internet Draft draft-ietf-mmusic-kmgmt-ext-06.txt, Work
        in Progress, February 2003. Real Time Streaming Protocol (RTSP)", RFC
        4567, July 2006.

   [12] David Yon, "Connection-Oriented D. and G. Camarillo, "TCP-Based Media Transport in SDP,"
        Internet Draft draft-ietf-mmusic-sdp-comedia-05.txt, Work in
        Progress, March 2003. the
        Session Description Protocol (SDP)", RFC 4145, September 2005.

   [13] G. Camarillo (ed), W. Marshall (ed), Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
        Resource Management and SIP", Internet Draft draft-ietf-sip-
        manyfolks-resource-03.txt, Work in Progress, November 2001. Session Initiation Protocol (SIP)", RFC
        3312, October 2002.

   [14] G. Camarillo, H. G., Schulzrinne, H., and E. Burger, "The source and
        sink attributes for the Session Description Protocol", Internet
        Draft draft-camarillo-mmusic-source-sink-00.txt, Work in
        Progress, September 2002.

   [15] Mark Andreasen, F., Baugher, "SDP M., and D. Wing, "Session Description
        Protocol (SDP) Security Descriptions for Media Streams",
        Internet Draft draft-ietf-mmusic-sdescriptions-00.txt, Work in
        Progress, February 2003. RFC
        4568, July 2006.

   [16] Quinn, B. Quinn and R. Finlayson, "SDP "Session Description Protocol (SDP)
        Source-Filters", Internet
        Draft draft-ietf-mmusic-sdp-srcfilter-04.txt, Work in Progress,
        April 2003. RFC 4570, July 2006.

   [17] Robert Fairlie-Cuninghame, R., "Guidelines for specifying SCTP-
        based SCTP-based
        media transport using SDP," Internet Draft draft-fairlie-
        mmusic-sdp-sctp-00.txt, SDP", Work in Progress, May 2001.

11.

   [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

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved. IETF Trust (2007).

   This document and translations of it may be copied and furnished is subject 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 rights, licenses and derivative works.  However, this
   document itself may not be modified restrictions
   contained in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, BCP 78, and except as needed for the purpose of
   developing Internet standards in which case set forth therein, 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. authors
   retain all their rights.

   This document and the information contained herein is are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.