draft-ietf-mmusic-sdpng-trans-01.txt   draft-ietf-mmusic-sdpng-trans-02.txt 
INTERNET-DRAFT J. Ott/C. Perkins INTERNET-DRAFT J. Ott/C. Perkins
Expires: January 2003 TZI/ISI Expires: May 2003 TZI/ISI
July 2002 November 2002
SDPng Transition SDPng Transition
draft-ietf-mmusic-sdpng-trans-01.txt draft-ietf-mmusic-sdpng-trans-02.txt
Status of this memo Status of this memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Distribution of this document 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 Abstract
The Session Description Protocol (SDP) is today widely used in the The Session Description Protocol (SDP) is today widely used in the
Internet to announce as well as negotiate multimedia sessions and Internet to announce as well as negotiate multimedia sessions and
exchange capabilities. Having originally been designed for session exchange capabilities. Having originally been designed for session
announcements only, as opposed to announcements and capabilities announcements only, as opposed to announcements and capabilities
negotiation announcements, native SDP lacks numerous features to be negotiation announcements, native SDP lacks numerous features to be
applicable in many session scenarios. Numerous extensions have been applicable in many session scenarios. Numerous extensions have been
developed to circumvent SDP's shortcomings -- but they have also developed to circumvent SDP's shortcomings -- but they have also
repeatedly shown its inherent limitations. A successor protocol -- repeatedly shown its inherent limitations. A successor protocol --
termed "SDPng" for the time being -- is developed to address the termed "SDPng" for the time being -- is developed to address the
aforementioned needs of Internet applications in a more structured aforementioned needs of Internet applications in a more structured
manner. With the huge installed base of SDP-based applications, a manner. With the huge installed base of SDP-based applications, a
migration path needs to be developed to move from SDP to SDPng over migration path needs to be developed to move from SDP to SDPng over
time. This document outlines how this migration can be achieved: in time. This document outlines how this migration can be achieved: in
general as well as for the various IETF control protocols that general as well as for the various IETF control protocols that
potentially make use of SDP and SDPng. 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
group's mailing list at mmusic@ietf.org and/or the authors.
1. Introduction 1. Introduction
SDP is now widely used within the Internet community to describe SDP is now widely used within the Internet community to describe
media sessions and, in a limited fashion, system capabilities media sessions and, in a limited fashion, system capabilities
relating to (multi)media sessions, for a variety of application relating to (multi)media sessions, for a variety of application
scenarios: session announcements, interactive session setup, scenarios: session announcements, interactive session setup,
capability assessment and remote control of media streams. All but capability assessment and remote control of media streams. All but
the first of these are rather different from what SDP was originally 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 designed for -- but all of them share the idea of setting up and
configuring media streams. Over time, its wide range of uses has configuring media streams. Over time, its wide range of uses has
skipping to change at page 2, line 47 skipping to change at page 2, line 47
time keeping the core description format simple. SDPng uses a time keeping the core description format simple. SDPng uses a
different (more expressive) syntax than SDP does and hence is not different (more expressive) syntax than SDP does and hence is not
backward compatible at the syntax level. Nevertheless, the concepts backward compatible at the syntax level. Nevertheless, the concepts
of SDPng take into account the migration issues from SDP to SDPng by of SDPng take into account the migration issues from SDP to SDPng by
providing straightforward mappings between the two formats where providing straightforward mappings between the two formats where
possible and try to maximize compatibility from a semantics possible and try to maximize compatibility from a semantics
perspective. perspective.
The current revisions of SDP and SDPng are documented in The current revisions of SDP and SDPng are documented in
[1] draft-ietf-mmusic-sdp-new-10.txt and o draft-ietf-mmusic-sdp-new-11.txt [1] and
[2] draft-ietf-mmusic-sdpng-05.txt. o draft-ietf-mmusic-sdpng-05.txt [2].
For SDP, numerous additional documents need to be taken into account: For SDP, a number of additional features are defined in the following
documents that need to be taken into account:
[3] RFC 3108 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]);
[4] draft-ietf-mmusic-fid-06.txt o full support for IPv6 as network layer protocol (RFC 3266 [12]);
[5] draft-andreasen-mmusic-sdp-simcap-05.txt
[6] draft-ietf-mmusic-sdp-offer-answer-02.txt o SDP extensions to allow selecting ATM virtual circuits as
additional network protocol and specifying ATM-specific
parameters (RFC 3108 [3]);
[7] draft-fairlie-mmusic-sdp-sctp-00.txt o SDP extensions to support TDM as additional network protocol and
specify the TDM-specific parameters (draft-taylor-mmusic-sdp-
tdm-00.txt [9])
[8] draft-ietf-mmusic-sdp-comedia-03.txt o a general extension to deal with connection-oriented transport
protocols such as TCP (draft-ietf-mmusic-sdp-comedia-04.txt
[8]);
[9] draft-taylor-mmusic-sdp-tdm-01.txt o an extension to support SCTP as media transport protocol in
addition to UDP and TCP (draft-fairlie-mmusic-sdp-sctp-00.txt
[7]);
[10] draft-ietf-mmusic-sdp4nat-02.txt o an SDP extension to explicitly specify RTCP port number to
enable the necessary expressiveness for NAT traversal (draft-
ietf-mmusic-sdp4nat-02.txt [10]);
[11] draft-ietf-mmusic-kmgmt-ext-05.txt 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 (draft-
ietf-mmusic-fid-05.txt [4]);
[12] draft-ietf-mmusic-sdp-ipv6-03.txt o the capability to indicate which media sessions shall be mapped
into the same resource reservation context (draft-ietf-mmusic-
reservation-flows-00.txt [13]);
o an extension to allow expression of simultanous capabilities
across media sessions and formats (draft-andreasen-mmusic-sdp-
simcap-05.txt [5])
o attributes for passing parameters of a keying protocol (such as
MIKEY) as part of a session description (draft-ietf-mmusic-
kmgmt-ext-05.txt [11]);
o support for conveying cryptographic parameters as part of a
session description (draft-baugher-mmusic-sdpmediasec-00.txt
[15]); and
o a mechanism to explicitly specify the sources allowed to provide
input to media sessions (draft-ietf-mmusic-sdp-srcfilter-01.txt
[16]).
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 how they shall be combined, draft-
camarillo-mmusic-source-sink-00.txt [14]);
This document outlines a migration path from SDP to SDPng, starting This document outlines a migration path from SDP to SDPng, starting
from a short overview of the current application scenarios. In the from a short overview of the current application scenarios. In the
next step, we highlight which design decisions taken for SDPng should next step, we highlight which design decisions taken for SDPng should
simplify a smooth migration and describe how mappings between the two simplify a smooth migration and describe how mappings between the two
description formats can be performed at an abstract level. We then description formats can be performed at an abstract level. We then
address procedural issues for integrating SDP and SDPng into the address procedural issues for integrating SDP and SDPng into the
various protocols relying on those media description formats. various protocols relying on those media description formats.
Finally, we summarize work items on the agenda for SDPng. Finally, we summarize work items on the agenda for SDPng.
skipping to change at page 5, line 52 skipping to change at page 6, line 39
incorporated into SDPng by defining the appropriate extensions for incorporated into SDPng by defining the appropriate extensions for
the SDPng transports. the SDPng transports.
Similarly, new codecs can be added by just defining new codec Similarly, new codecs can be added by just defining new codec
specifications or defining entire new classes of applications to be specifications or defining entire new classes of applications to be
described as new content types ("codec") to be carried in a media described as new content types ("codec") to be carried in a media
session (including e.g. text, fax, slide presentations, shared session (including e.g. text, fax, slide presentations, shared
editors, etc). If necessary, sophisticated parameter structures can editors, etc). If necessary, sophisticated parameter structures can
be supported (even though the authors believe that simplicity is key be supported (even though the authors believe that simplicity is key
to interoperability here). This is similar to, but more structured to interoperability here). This is similar to, but more structured
than, the definition of new codecs attributes/MIME registrations in than, the definition of new codec attributes in MIME registrations
SDP. for SDP.
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 By means of its conceptual differentiation into Potential and Actual
Configurations, SDPng supports both indicating a system's Configurations, SDPng supports both indicating a system's
capabilities (without specifying transport addresses) separately from capabilities (without specifying transport addresses) separately from
the instantiation of a particular media stream as well as conveying the instantiation of a particular media stream as well as conveying
capability descriptions and instantiation proposals at the same time capability descriptions and instantiation proposals at the same time
-- thereby providing a good fit for all the above session control -- thereby providing a good fit for all the above session control
scenarios: the "announcement" and "retrieval" scenarios will just scenarios: the "announcement" and "retrieval" scenarios will just
use rather fixed Actual Configurations. The "offer/answer" model use rather fixed Actual Configurations. The "offer/answer" model
will use use Actual Configuration but use them to negotiate media will use use Actual Configuration but use them to negotiate media
strams in a two-way handshake but may in addition use Potential strams in a two-way handshake but may in addition use Potential
Configurations to indicate capabilities that shall not be used Configurations to indicate capabilities that shall not be used
immediately. The "gateway control" scenario will use both: immediately. The "gateway control" scenario will use both:
Potential Configurations to describe an MG's capabilities and Actual Potential Configurations to describe an MG's capabilities and Actual
Configurations for setting up media sessions at MGs as well as Configurations for setting up media sessions at MGs as well as
retrieving information about currently active media sessions. This retrieving information about currently active media sessions. This
differentiation is not directly expressible in SDP, although various differentiation is not directly expressible in SDP, although various
extensions can be used to overload SDP semantics to achieve at least extensions can be used to overload SDP semantics to achieve at least
part of this effect. part of this effect.
Finally, SDPng is also intended to allow for content-independent Finally, while the short-term SDPng specification aims at supporting
negotiation of session parameters by defining collapsing/intersection only the widespread offer/answer model for capability negotiation, a
rules. In particular, SDPng tries to take the need for multicast- future extension will also allow for content-independent negotiation
based distributed calculation of joint capabilities into account for of session parameters by defining collapsing/intersection rules. In
those rules (but note that it is *not* intended as a generic format particular, SDPng will take into account the need for multicast-based
for describing conference state information). Such functionality is distributed calculation of joint capabilities into account for those
not covered by current SDP. 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 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 4. Integration with Session Control Protocols
This section outlines for each of the 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 described above how SDP and SDPng can be used in parallel and
indicates how a suitable transition could be achieved. indicates how a suitable transition could be achieved.
4.1. Session Announcement Protocol (SAP) 4.1. Session Announcement Protocol (SAP)
There are two revision of SAP specified, version 0 which is There are two revisions of SAP specified, version 0 which is
implemented in a number of experimental tools, and version 1 which is implemented in a number of experimental tools, and version 1 which is
defined in RFC 2972. defined in RFC 2972.
SAPv0:SAPv0 does not support a mechanism to identify the content type SAPv0:SAPv0 does not support a mechanism to identify the content type
of a session announcement but implicitly assumes SDP. Proper of a session announcement but implicitly assumes SDP. Proper
parsers will note that the contents of the SAPv0 message does parsers will note that the contents of the SAPv0 message does
not begin with a "v=" line and hence will ignore the entire not begin with a "v=" line and hence will ignore the entire
announcement. SDPng contents MAY be identified by the character announcement. SDPng contents MAY be identified by the character
sequence "<sdpng" in the beginning of the announcement body -- sequence "<sdpng" in the beginning of the announcement body,
but such content is not strictly legal in SAPv0. 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 SAPv1:In SAPv1, an explicit payload type field (containing a MIME
type) is available and SHOULD used to differentiate between SDP type) is available and SHOULD used to differentiate between SDP
anf SDPng contents. two approaches are conceivable: Either anf SDPng contents. two approaches are conceivable: Either
multipart MIME message is used with two parts containing the multipart MIME message is used with two parts containing the
same session descriptions -- one expressing it in SDP and the same session descriptions -- one expressing it in SDP and the
other in SDPng. Alternatively, two alternate session other in SDPng. Alternatively, two alternate session
announcements may be used (being properly distinguished by the announcements may be used (being properly distinguished by the
SDP "o=" field and the SDPng equivalent). SDP "o=" field and the SDPng equivalent).
skipping to change at page 7, line 50 skipping to change at page 8, line 47
RTSP uses the Content-Type: header field to indicate the format of RTSP uses the Content-Type: header field to indicate the format of
the enclosed entity. This provides a straightforward means for the enclosed entity. This provides a straightforward means for
distinguishing SDP and SDPng-based presentation descriptions. In distinguishing SDP and SDPng-based presentation descriptions. In
addition, the Accept: header SHOULD be used by the client, to addition, the Accept: header SHOULD be used by the client, to
indicate which content types it supports. If the client specifies indicate which content types it supports. If the client specifies
both SDP and SDPng as acceptable, the server SHOULD provide only the both SDP and SDPng as acceptable, the server SHOULD provide only the
SDPng-based presentation description. SDPng-based presentation description.
If the client does not indicate a particular Content-Type: the server If the client does not indicate a particular Content-Type: the server
can, theoretically, use MIME multipart bodies to convey both can, theoretically, use MIME multipart bodies (e.g.
description types simultaneously. "multipart/alternative") to convey both description types
simultaneously. However, it is generally not expected that today's
[Editors note: can implementors comment on their ability to RTSP clients and servers will be able handle multipart bodies.
parse such content?] 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 to have the servers migrate to In general, it would be preferrable to have the servers migrate to
always supporting both description formats, thus enabling the clients always supporting both description formats, thus enabling the clients
to choose. to choose. The servers SHOULD indicate SDPng support by means of
suitable header fields whenever possible.
Finally, RTSP makes special provision to interworking with firewalls Finally, RTSP makes special provision to interworking with firewalls
by including the crucial transport parameters in a separate RTSP by including the crucial transport parameters in a separate RTSP
header field _in_addition_ to the presentation description. This header field _in_addition_ to the presentation description. This
practice in principle allows to change the presentation description practice in principle allows to change the presentation description
format without having to worry about the operation of firewalls and format without having to worry about the operation of firewalls and
similar devices. similar devices.
4.3. Session Initiation Protocol (SIP) 4.3. Session Initiation Protocol (SIP)
skipping to change at page 8, line 46 skipping to change at page 9, line 46
"application/sdp"). The SIP UAC MUST then retry INVITE (or other) "application/sdp"). The SIP UAC MUST then retry INVITE (or other)
message using the indicated session description language. The SIP message using the indicated session description language. The SIP
UAC SHOULD cache knowledge about which peers did not understand SDPng UAC SHOULD cache knowledge about which peers did not understand SDPng
as session description formats for a limited amount of time (e.g. as session description formats for a limited amount of time (e.g.
several days) so that extra round-trips for session setup are only several days) so that extra round-trips for session setup are only
incurred infrequently. Whenever a peer has sent an SDPng description incurred infrequently. Whenever a peer has sent an SDPng description
(or it is known from other means that the peer supports SDPng), this (or it is known from other means that the peer supports SDPng), this
information SHOULD also be cached. information SHOULD also be cached.
The SIP Accept: header can be exploited to determine the capability The SIP Accept: header can be exploited to determine the capability
of a peer to understand SDPng in addition (or instead) of plain SDP. of a peer to understand SDPng in addition (or instead) plain SDP.
Methods such as OPTIONS MAY be used to determine a peer's support for 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 SDPng. However, a peer's capabilities may not be known when the
first message is sent which may introduce an extra round-trip if first message is sent which may introduce an extra round-trip if
including SDP and SDPng in the initial INVITE message is not an including SDP and SDPng in the initial INVITE message is not an
option. Further approaches to make a UA's support for SDPng known option. Further approaches to make a UA's support for SDPng known
ahead of time should be explored. ahead of time should be explored.
A number of SDP extensions have been motivated by SIP-based A number of SDP extensions have been motivated by SIP-based
applications and these need to be accommodated in SDPng as well. applications and these need to be accommodated in SDPng as well.
Features such as "simcap" and "FID" are inherently supported by Features such as "simcap" and "FID" are inherently supported by
SDPng; proper definitions for connection-oriented media need to be SDPng; proper definitions for connection-oriented media need to be
fully understood and then incorporated. Key management attributes as fully understood and then incorporated. Key management attributes as
defined in [11] need to be included (not just for SIP) and so may defined in [11] need to be included (not just for SIP) and so may
need to be general mechanisms to signal security capabilities [11] need to be general mechanisms to signal security capabilities [11]
[13] and indicate their optional or mandatory use. The same applies [15] and indicate their optional or mandatory use. The same applies
to quality of service parameters [13] (which are largely also to quality of service parameters [13] (which are largely also
motivated by SIP but are also useful with control protocols). motivated by SIP but are also useful with control protocols).
In the context of SIP, a number of special rules to deal with certain Numerous extensions to SDP have been developed for the purpose of
SDP fields are set up (e.g. to work with NATs). The SDPng supporting certain SIP requirements -- actually most of those listed
development needs to make sure that similar definitions are provided in section 1. fall into this category. The following paragraphs
(as need be the handling of those in SIP). address how those are handled by and mapped to SDPng.
[Editor's note: This section needs more work on details.] 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 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
inline 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 been considered in the SDPng base specification
and the transport packagaes or will be added 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. with RTSP or MEGACO).
4.4. Media Gateway Control Protocol (MEGACOP) 4.4. Media Gateway Control Protocol (MEGACOP)
The MEGACO specification already supports two different encodings for The MEGACO specification already supports two different encodings for
capability and media stream descriptions: a text-based variant based capability and media stream descriptions: a text-based variant based
upon (a modified) SDP and a binary representation of the same upon (a modified) SDP and a binary representation of the same
information set. MGCs are required to implement both encodings while information set. MGCs are required to implement both encodings while
MGs have the choice to pick either or both. Differentiation between MGs have the choice to pick either or both. Differentiation between
the protocol encoding variants is done using different port numbers: the protocol encoding variants is done using different port numbers:
2944 for the text-based and 2945 for the binary encoding. 2944 for the text-based and 2945 for the binary encoding.
skipping to change at page 9, line 41 skipping to change at page 11, line 32
as an "octet string" without any type identifier. Defining a third as an "octet string" without any type identifier. Defining a third
port number for this further differentiation does not seem to be port number for this further differentiation does not seem to be
appropriate, particularly since the message encoding is still a text appropriate, particularly since the message encoding is still a text
format. format.
The remaining means for distinction is that an SDP specification The remaining means for distinction is that an SDP specification
would start with a "v=0" line while an SDPng document would begin would start with a "v=0" line while an SDPng document would begin
with an "<sdpng" part. with an "<sdpng" part.
[Editor's Note: MEGACOP also supports a binary encoding for SDP [Editor's Note: MEGACOP also supports a binary encoding for SDP
messages; we can assume that not all of the SDPng messages will messages; current practice seems to favor the text encoding for
be expressible this binary encoding. How shall we handle SDP and hence we will not address the binary encoding.]
these?]
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 5. SDPng and Middleboxes
TBD. Middleboxes (e.g. firewalls, NATs, NAPTs) are of significant
importance for many deployment scenarios for SDP-based signaling
protocols. The SDP description typically carries addressing
paramaters for media sessions which 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.
1) Proxies that are incorporated in middleboxes to parse and (in
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 MIDCOM
protocols (such as 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
to support -- but they would need to do so anyway.
6. Directing the Evolution of SDP 6. Directing the Evolution of SDP
With the transition from SDP to SDPng, there is the question of the With the transition from SDP to SDPng, there is the question of the
evolution of SDP, and legacy systems which use it. evolution of SDP, and legacy systems which use it.
The SDP specification (draft-ietf-mmusic-sdp-new-10.txt) is stable, The SDP specification [1] is stable, and mostly corrects errors in
and mostly corrects errors in the original specification, with the the original specification, with the addition of very few new
addition of very few new features. This is expected to be published features. The revision is expected to be published as a proposed
as a draft standard RFC shortly. standard RFC shortly, obsoleting RFC 2327.
A number of extensions to SDP for use in offer/answer scenarios are A number of extensions to SDP for use in offer/answer scenarios are
also close to completion. These include grouping (draft-ietf-mmusic- also available. These include grouping [4] and capability negotiation
fid-05.txt) and capability negotiation (draft-andreasen-mmusic-sdp- [5], which have recently been approved as proposed standard RFCs,
simcap-04.txt). We expect these to be completed, and published as bringing minimal capability/alternative descriptions to SDP.
proposed standard RFCs, to bring minimal capability/alternative
descriptions to SDP.
Related is the SDP offer/answer model for SDP, currently under Related is the SDP offer/answer model for SDP, published as RFC3264
development as draft-rosenberg-mmusic-sdp-offer-answer-01.txt). This [6]. This defines the model used to complete the steps of a
defines the model used to complete the steps of a negotiation using negotiation using SDP. A similar mode of operation will be provided
SDP. for SDPng for baseline operation with SIP (and possibly RTSP).
All these are subsumed into SDPng, so there should be no further need All these are subsumed into SDPng, so there should be no further need
for development in these areas; applications with requirements that for development in these areas; applications with requirements that
are not met by these specifications should use SDPng. are not met by these specifications should use SDPng.
There have recently been proposals to add quality of service There have recently been proposals to add quality of service
negotiation for SDP and, similarly, we expect other extensions to be negotiation for SDP and, similarly, we expect other extensions to be
proposed over time. Due to the well-known limitations of SDP, we do proposed over time. Due to the well-known limitations of SDP, we do
not believe it appropriate to continue development of more elaborate not believe it appropriate to continue development of more elaborate
extensions: for negotiation, for QoS, for security, and for other extensions: for negotiation, for QoS, for security, and for other
general-purpose or application-specific needs. general-purpose or application-specific needs.
Instead, such new work should be done in the framework of SDPng where 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 [17]).
Overall, new work should be done in the framework of SDPng where
applications and their requirements for (new) expressiveness in end- applications and their requirements for (new) expressiveness in end-
to-end exchanges to negotiate and configure media sessions will to-end exchanges to negotiate and configure media sessions will
hopefully act as a driver for that process. hopefully act as a driver for that process.
7. Author's Addresses 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 [2] provides further details.
During the transition process it is likely that dual descriptions
will be common. There is a potential for inconsistancy between
definitions, which may have unintended consequences if one part of
the system, for example a middlebox, interprets the SDP format whilst
another interprets the SDPng format definition.
9. Author's Addresses
Joerg Ott <jo@tzi.org> Joerg Ott <jo@tzi.org>
Universitaet Bremen Universitaet Bremen
MZH 5180 MZH 5180
Bibliothekstr. 1 Bibliothekstr. 1
D-28359 Bremen D-28359 Bremen
Germany Germany
tel:+49-421-201-7028 tel:+49-421-201-7028
sip:jo@tzi.org sip:jo@tzi.org
Colin Perkins <csp@isi.edu> Colin Perkins <csp@csperkins.org>
USC Information Sciences Institute USC Information Sciences Institute
3811 North Fairfax Drive, Suite 200 3811 North Fairfax Drive, Suite 200
Arlington, VA 22203 Arlington, VA 22203
USA USA
tel:+1-703-812-3705 tel:+1-703-812-3705
8. References 10. References
[1] Mark Handley, Van Jacobson, Colin Perkins, "SDP: Session [1] Mark Handley, Van Jacobson, Colin Perkins, "SDP: Session
Description Protocol," Internet Draft draft-ietf-mmusic-sdp- Description Protocol," Internet Draft draft-ietf-mmusic-sdp-
new-10.txt, Work in Progress, May 2002. new-11.txt, Work in Progress, November 2002.
[2] Dirk Kutscher, Joerg Ott, Carsten Bormann, "Session Description [2] Dirk Kutscher, Joerg Ott, Carsten Bormann, "Session Description
and Capability Negotiation", Internet Draft draft-ietf-mmusic- and Capability Negotiation", Internet Draft draft-ietf-mmusic-
sdpng-05.txt, Work in Progress, July 2002. sdpng-05.txt, Work in Progress, July 2002.
For SDP, numerous additional documents need to be taken into account: For SDP, numerous additional documents need to be taken into account:
[3] 3108 R. Kumar, M. Mostafa, "Conventions for the use of the [3] 3108 R. Kumar and M. Mostafa, "Conventions for the use of the
Session Description Protocol (SDP) for ATM Bearer Connections," Session Description Protocol (SDP) for ATM Bearer Connections,"
RFC 3108, May 2001. RFC 3108, May 2001.
[4] Gonzalo Camarillo, Jan Holler, Goran AP Eriksson, Henning [4] Gonzalo Camarillo, Jan Holler, Goran AP Eriksson, Henning
Schulzrinne, "Grouping of media lines in SDP," Internet Draft Schulzrinne, "Grouping of media lines in SDP," Internet Draft
draft-ietf-mmusic-fid-06.txt, Work in Progress, February 2002. draft-ietf-mmusic-fid-06.txt, Work in Progress, February 2002.
[5] F. Andreasen, "SDP Simple Capability Negotiation," Internet [5] F. Andreasen, "SDP Simple Capability Declaration," RFC 3407,
Draft draft-andreasen-mmusic-sdp-simcap-05.txt, Work in October 2002.
Progress, February 2002.
[6] Jonathan Rosenberg, Henning Schulzrinne, "An Offer/Answer Model [6] Jonathan Rosenberg and Henning Schulzrinne, "An Offer/Answer
with SDP," Internet Draft draft-ietf-mmusic-sdp-offer- Model with SDP," RFC 3264, June 2002.
answer-02.txt, Work in Progress, February 2002.
[7] Robert Fairlie-Cuninghame, "Guidelines for specifying SCTP- [7] Robert Fairlie-Cuninghame, "Guidelines for specifying SCTP-
based media transport using SDP," Internet Draft draft-fairlie- based media transport using SDP," Internet Draft draft-fairlie-
mmusic-sdp-sctp-00.txt, Work in Progress, May 2001. mmusic-sdp-sctp-00.txt, Work in Progress, May 2001.
[8] David Yon, "Connection-Oriented Media Transport in SDP," [8] David Yon, "Connection-Oriented Media Transport in SDP,"
Internet Draft draft-ietf-mmusic-sdp-comedia-03.txt, Work in Internet Draft draft-ietf-mmusic-sdp-comedia-04.txt, Work in
Progress, June 2002. Progress, July 2002.
[9] Tom Taylor, "Conventions for the use of the Session Description [9] Tom Taylor, "Conventions for the use of the Session Description
Protocol (SDP) for Digital Circuit Connections," Internet Draft Protocol (SDP) for Digital Circuit Connections," Internet Draft
draft-taylor-mmusic-sdp-tdm-01.txt, Work in Progress, April draft-taylor-mmusic-sdp-tdm-01.txt, Work in Progress, April
2002. 2002.
[10] Christian Huitema, "RTCP attribute in SDP," Internet Draft [10] Christian Huitema, "RTCP attribute in SDP," Internet Draft
draft-ietf-mmusic-sdp4nat-02.txt, Work in Progress, February draft-ietf-mmusic-sdp4nat-02.txt, Work in Progress, February
2002. 2002.
[11] Jari Arkko, Elisabette Carrarra, Fredrik Lindholm, Mats Naslund, [11] Jari Arkko, Elisabetta Carrarra, Fredrik Lindholm, Mats Naslund,
Karl Norrman, "Key Management Extensions for SDP and RTSP," and Karl Norrman, "Key Management Extensions for SDP and
Internet Draft draft-ietf-mmusic-kmgmt-ext-05.txt, Work in RTSP," Internet Draft draft-ietf-mmusic-kmgmt-ext-05.txt, Work
Progress, June 2002. in Progress, June 2002.
[12] Sean Olson, Gonzalo Camarillo, Adam Roach, "Support for IPv6 in [12] Sean Olson, Gonzalo Camarillo, Adam Roach,
SDP," Internet Draft draft-ietf-mmusic-sdp-ipv6-03.txt, Work in
Progress, February 2002.
[13] G. Camarillo (ed), W. Marshall (ed), J. Rosenberg, "Integration [13] G. Camarillo (ed), W. Marshall (ed), J. Rosenberg, "Integration
of Resource Management and SIP", Internet Draft draft-ietf-sip- of Resource Management and SIP", Internet Draft draft-ietf-sip-
manyfolks-resource-07.txt, Work in Progress, April 2002. manyfolks-resource-03.txt, Work in Progress, November 2001.
9. Full Copyright Statement [14] G. Camarillo, H. Schulzrinne, 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.
Copyright (C) The Internet Society (1997). All Rights Reserved. [15] Mark Baugher, "SDP Security Descriptions for Media Streams",
Internet Draft draft-baugher-mmusic-sdpmediasec-00.txt, Work in
Progress, September 2002.
[16] B. Quinn and R. Finlayson, "SDP Source-Filters", Internet
Draft draft-ietf-mmusic-sdp-srcfilter-01.txt, Work in Progress,
July 2002.
[17] G. Camarillo and A. Monrad, "Mapping of Media Streams to
Resource Reservation Flows", Internet Draft draft-ietf-mmusic-
reservation-flows-00.txt, Work in Progress, October 2002.
11. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/