draft-ietf-mmusic-sdpng-trans-00.txt   draft-ietf-mmusic-sdpng-trans-01.txt 
INTERNET-DRAFT J. Ott/C. Perkins INTERNET-DRAFT J. Ott/C. Perkins
Expires: August 2002 TZI/ISI Expires: January 2003 TZI/ISI
February 2002 July 2002
SDPng Transition SDPng Transition
draft-ietf-mmusic-sdpng-trans-00.txt draft-ietf-mmusic-sdpng-trans-01.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 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-05.txt and [1] draft-ietf-mmusic-sdp-new-10.txt and
[2] draft-ietf-mmusic-sdpng-04.txt. [2] draft-ietf-mmusic-sdpng-05.txt.
For SDP, numerous additional documents need to be taken into account: For SDP, numerous additional documents need to be taken into account:
[3] RFC 3108 [3] RFC 3108
[4] draft-ietf-mmusic-fid-05.txt [4] draft-ietf-mmusic-fid-06.txt
[5] draft-andreasen-mmusic-sdp-simcap-04.txt [5] draft-andreasen-mmusic-sdp-simcap-05.txt
[6] draft-ietf-mmusic-sdp-offer-answer-02.txt [6] draft-ietf-mmusic-sdp-offer-answer-02.txt
[7] draft-fairlie-mmusic-sdp-sctp-00.txt [7] draft-fairlie-mmusic-sdp-sctp-00.txt
[8] draft-ietf-mmusic-sdp-comedia-01.txt [8] draft-ietf-mmusic-sdp-comedia-03.txt
[9] draft-taylor-mmusic-sdp-tdm-00.txt [9] draft-taylor-mmusic-sdp-tdm-01.txt
[10] draft-ietf-mmusic-sdp4nat-01.txt [10] draft-ietf-mmusic-sdp4nat-02.txt
[11] draft-ietf-mmusic-kmgmt-ext-02.txt [11] draft-ietf-mmusic-kmgmt-ext-05.txt
[12] draft-ietf-mmusic-sdp-ipv6-02.txt [12] draft-ietf-mmusic-sdp-ipv6-03.txt
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 8, line 25 skipping to change at page 8, line 25
The use of SDP with SIP follows the offer/anser model and is The use of SDP with SIP follows the offer/anser model and is
described in [6]. It is key to the (efficiency of the) offer/answer described in [6]. It is key to the (efficiency of the) offer/answer
model that a complete capability exchange and media stream model that a complete capability exchange and media stream
instantiation be carried out in one round-trip -- which is supported instantiation be carried out in one round-trip -- which is supported
by SDP. While SDPng allows to separate capability exchange from by SDP. While SDPng allows to separate capability exchange from
media sesssion instantiation, those two pieces are also easily media sesssion instantiation, those two pieces are also easily
integrated in a single step. integrated in a single step.
SIP also uses a Content-Type: header to indicate the nature of data SIP also uses a Content-Type: header to indicate the nature of data
carried in its message body; and SIP explicitly calls for supporting carried in its message body; and SIP explicitly calls for supporting
MIME multipart message bodies. Hence, again, the MIME MIME multipart message bodies. While, again, the use of MIME
multipart/alternative should be used to simultaneously convey both an multipart/alternative would in principle be possible (from a
SDP and an SDPng session description. Whenever a peer has sent an theoretical perspective), issues regarding the actual implementation
SDPng description (or it is known from other means that the peer of multipart/alternative in SIP entities have been raised. As
supports SDPng), the SDP need no longer be sent. backward compatibility has to be achieved, a different approach is
suggested:
A SIP UAC MAY use an SDPng message body in a SIP INVITE (or other)
message. If the SIP 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 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 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 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) of 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; similarly, a 415 answer to an INVITE MAY be used to indicate SDPng. However, a peer's capabilities may not be known when the
that the media description format provided is not supported. first message is sent which may introduce an extra round-trip if
However, a peer's capabilities may not be known when the first including SDP and SDPng in the initial INVITE message is not an
message is sent which may introduce an extra round-trip if including option. Further approaches to make a UA's support for SDPng known
SDP and SDPng in the initial INVITE message is not an option. ahead of time should be explored.
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 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 [13] 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
skipping to change at page 9, line 21 skipping to change at page 9, line 33
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.
Unfortunately, within the text-based encoding, there is no means to Unfortunately, within the text-based encoding, there is no means to
differentiate several description formats. SDP messages are carried differentiate several description formats. SDP messages are carried
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
approapriate, 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; we can assume that not all of the SDPng messages will
be expressible this binary encoding. How shall we handle be expressible this binary encoding. How shall we handle
these?] these?]
5. SDPng and Middleboxes 5. SDPng and Middleboxes
TBD. TBD.
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-06.txt) is stable, The SDP specification (draft-ietf-mmusic-sdp-new-10.txt) is stable,
and mostly corrects errors in the original specification, with the and mostly corrects errors in the original specification, with the
addition of very few new features. This is expected to be published addition of very few new features. This is expected to be published
as a draft standard RFC shortly. as a draft standard RFC shortly.
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 close to completion. These include grouping (draft-ietf-mmusic-
fid-05.txt) and capability negotiation (draft-andreasen-mmusic-sdp- fid-05.txt) and capability negotiation (draft-andreasen-mmusic-sdp-
simcap-04.txt). We expect these to be completed, and published as simcap-04.txt). We expect these to be completed, and published as
proposed standard RFCs, to bring minimal capability/alternative proposed standard RFCs, to bring minimal capability/alternative
descriptions to SDP. descriptions to SDP.
skipping to change at page 10, line 30 skipping to change at page 10, line 43
7. Author's Addresses 7. 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
fax:+49-421-218-7000 sip:jo@tzi.org
Colin Perkins <csp@isi.edu> Colin Perkins <csp@isi.edu>
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 8. 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-06.txt, Work in Progress, February 2002. new-10.txt, Work in Progress, May 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-04.txt, Work in Progress, February 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, 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-05.txt, Work in Progress, September 2001. 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 Negotiation," Internet
Draft draft-andreasen-mmusic-sdp-simcap-04.txt, Work in Draft draft-andreasen-mmusic-sdp-simcap-05.txt, Work in
Progress, August 2001. Progress, February 2002.
[6] Jonathan Rosenberg, Henning Schulzrinne, "An Offer/Answer Model [6] Jonathan Rosenberg, Henning Schulzrinne, "An Offer/Answer Model
with SDP," Internet Draft draft-ietf-mmusic-sdp-offer- with SDP," Internet Draft draft-ietf-mmusic-sdp-offer-
answer-01.txt, Work in Progress, February 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-01.txt, Work in Internet Draft draft-ietf-mmusic-sdp-comedia-03.txt, Work in
Progress, October 2001. Progress, June 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-00.txt, Work in Progress, April draft-taylor-mmusic-sdp-tdm-01.txt, Work in Progress, April
2001. 2002.
[10] Christian Huitema, "RTCP attribute in SDP," Internet Draft [10] Christian Huitema, "RTCP attribute in SDP," Internet Draft
draft-ietf-mmusic-sdp4nat-01.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, Elisabette Carrarra, Fredrik Lindholm, Mats Naslund,
Karl Norrman, "Key Management Extensions for SDP and RTSP," Karl Norrman, "Key Management Extensions for SDP and RTSP,"
Internet Draft draft-ietf-mmusic-kmgmt-ext-02.txt, Work in Internet Draft draft-ietf-mmusic-kmgmt-ext-05.txt, Work in
Progress, February 2002. Progress, June 2002.
[12] Sean Olson, Gonzalo Camarillo, Adam Roach, "Support for IPv6 in [12] Sean Olson, Gonzalo Camarillo, Adam Roach, "Support for IPv6 in
SDP," Internet Draft draft-ietf-mmusic-sdp-ipv6-02.txt, Work in SDP," Internet Draft draft-ietf-mmusic-sdp-ipv6-03.txt, Work in
Progress, February 2002. Progress, February 2002.
[13] W. Marshall et al, "Integration of Resource Management and [13] G. Camarillo (ed), W. Marshall (ed), J. Rosenberg, "Integration
SIP", Internet Draft draft-ietf-sip-manyfolks-resource-03.txt, of Resource Management and SIP", Internet Draft draft-ietf-sip-
Work in Progress, November 2001. manyfolks-resource-07.txt, Work in Progress, April 2002.
9. Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved. Copyright (C) The Internet Society (1997). 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
 End of changes. 

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