draft-ietf-mmusic-sdpng-trans-02.txt   draft-ietf-mmusic-sdpng-trans-03.txt 
INTERNET-DRAFT J. Ott/C. Perkins INTERNET-DRAFT J. Ott/C. Perkins
Expires: May 2003 TZI/ISI Expires: August 2003 TZI/ISI
November 2002 February 2003
SDPng Transition SDPng Transition
draft-ietf-mmusic-sdpng-trans-02.txt draft-ietf-mmusic-sdpng-trans-03.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 3, line 12 skipping to change at page 3, line 12
o the offer/answer scheme of interpreting and matching media o the offer/answer scheme of interpreting and matching media
session descriptions to negotiate media sessions to be used in session descriptions to negotiate media sessions to be used in
call or conference in a single round-trip (RFC 3264 [6]); call or conference in a single round-trip (RFC 3264 [6]);
o full support for IPv6 as network layer protocol (RFC 3266 [12]); o full support for IPv6 as network layer protocol (RFC 3266 [12]);
o SDP extensions to allow selecting ATM virtual circuits as o SDP extensions to allow selecting ATM virtual circuits as
additional network protocol and specifying ATM-specific additional network protocol and specifying ATM-specific
parameters (RFC 3108 [3]); parameters (RFC 3108 [3]);
o SDP extensions to support TDM as additional network protocol and
specify the TDM-specific parameters (draft-taylor-mmusic-sdp-
tdm-00.txt [9])
o a general extension to deal with connection-oriented transport o a general extension to deal with connection-oriented transport
protocols such as TCP (draft-ietf-mmusic-sdp-comedia-04.txt protocols such as TCP [8];
[8]);
o an extension to support SCTP as media transport protocol in o an extension to support SCTP as media transport protocol in
addition to UDP and TCP (draft-fairlie-mmusic-sdp-sctp-00.txt addition to UDP and TCP [7];
[7]);
o an SDP extension to explicitly specify RTCP port number to o an SDP extension to explicitly specify RTCP port number to
enable the necessary expressiveness for NAT traversal (draft- enable the necessary expressiveness for NAT traversal [10];
ietf-mmusic-sdp4nat-02.txt [10]);
o a mechanism (media identification, "mid") for naming and o a mechanism (media identification, "mid") for naming and
grouping ("group") SDP media lines according to one or more grouping ("group") SDP media lines according to one or more
criteria, e.g. for the purpose of lip-synchronization or for criteria, e.g. for the purpose of lip-synchronization or for
identifying media sessions carrying the same content (draft- identifying media sessions carrying the same content (RFC 3388
ietf-mmusic-fid-05.txt [4]); [4], [9]);
o the capability to indicate which media sessions shall be mapped o the capability to indicate which media sessions shall be mapped
into the same resource reservation context (draft-ietf-mmusic- into the same resource reservation context [13];
reservation-flows-00.txt [13]);
o an extension to allow expression of simultanous capabilities o an extension to allow expression of simultanous capabilities
across media sessions and formats (draft-andreasen-mmusic-sdp- across media sessions and formats (RFC 3407 [5])
simcap-05.txt [5])
o attributes for passing parameters of a keying protocol (such as o attributes for passing parameters of a keying protocol (such as
MIKEY) as part of a session description (draft-ietf-mmusic- MIKEY) as part of a session description [11];
kmgmt-ext-05.txt [11]);
o support for conveying cryptographic parameters as part of a o support for conveying cryptographic parameters as part of a
session description (draft-baugher-mmusic-sdpmediasec-00.txt session description [15];
[15]); and
o a mechanism to explicitly specify the sources allowed to provide o a mechanism to explicitly specify the sources allowed to provide
input to media sessions (draft-ietf-mmusic-sdp-srcfilter-01.txt input to media sessions [16]; and
[16]).
o a simple language to provide instructions to media mixers on o a simple language to provide instructions to media mixers on
which incoming media streams shall be combined to produce which which incoming media streams shall be combined to produce which
outgoing ones (and possbily how they shall be combined, draft- outgoing ones (and possibly how they shall be combined) [14].
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 37 skipping to change at page 5, line 26
however, specific extensions have only been defined recently for ATM however, specific extensions have only been defined recently for ATM
and are now under discussion for TDM. Extensions to other transport and are now under discussion for TDM. Extensions to other transport
(including radio interfaces or next generation wireless networks) as (including radio interfaces or next generation wireless networks) as
well as to new types of session descriptions (e.g. electronic program well as to new types of session descriptions (e.g. electronic program
guides) are conceivable. guides) are conceivable.
3. Mapping SDP to SDPng 3. Mapping SDP to SDPng
On a transition path from SDP to SDPng, allowing for a somewhat On a transition path from SDP to SDPng, allowing for a somewhat
straightforward mapping of (parts of) one description format onto the straightforward mapping of (parts of) one description format onto the
other is of crucial importance. SDPng has been designed in way that 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 allows many of the session description features of SDP to be easily
mapped onto the SDPng format and vice versa -- except that SDPng is mapped onto the SDPng format and vice versa -- except that SDPng is
more expressive than SDP and hence information loss is not unlikely more expressive than SDP, and hence information loss is not unlikely
to occur when doing the reverse mapping. The final mapping rules to occur when doing the reverse mapping. The final mapping rules
between SDP and SDPng to be drawn up shall ensure that when mapping between SDP and SDPng to be drawn up shall ensure that mapping
SDP to SDPng and then back to SDP will produce an SDP that is SDP to SDPng and then back to SDP will produce an SDP that is
functionally identical to the one originally fed into the mapping functionally identical to the one originally fed into the mapping
process. Note that the use of a number of SDP extensions (FID, process. Note that the use of a number of SDP extensions (FID,
SIMCAP) may be implied in this mapping process, depending on the use SIMCAP) may be implied in this mapping process, depending on the use
of SDP. The mapping rules will ensure that no information loss will of SDP. The mapping rules will ensure that no information loss will
occur when translating from SDP to SDPng. occur when translating from SDP to SDPng.
The SDPng design uses a structure of four sections: definitions, The SDPng design uses a structure of four sections: definitions,
potential or actual configurations, constraints and session potential or actual configurations, constraints and session
attributes. Of these, the "Configurations" and "Session attributes. Of these, the "Configurations" and "Session
Attributes" sections map well onto the current SDP. The Attributes" sections map well onto the current SDP. The
"Definitions" and "Constraints" sections provide additional "Definitions" and "Constraints" sections provide additional
structure which is not directly expressible in SDP. structure which is not directly expressible in SDP.
o At the media description level, the Potential and Actual o At the media description level, the Potential and Actual
Configurations specified in the "Configurations" section maps Configurations specified in the "Configurations" section maps
well to media descriptions ("m=", possibly "c=", and well to SDP media descriptions ("m=", possibly "c=", and
associated attributes ("a=") lines). associated attributes ("a=") lines).
o At the session description level, the SDP session parameters are o At the session description level, the SDP session parameters are
largely reflected in the "Session Attributes" section of largely reflected in the "Session Attributes" section of
SDPng. The attributes proven suitable for session announcements SDPng. The attributes proven suitable for session announcements
have been used as the basis when defining SDPng. have been used as the basis when defining SDPng.
In SDPng, media descriptions are explicitly tagged with identifiers In SDPng, media descriptions are explicitly tagged with identifiers
and thus are easily referenced for semantically grouping media and thus are easily referenced for semantically grouping media
streams (e.g. to describe alternative audio in different languages, streams (e.g. to describe alternative audio in different languages,
skipping to change at page 7, line 16 skipping to change at page 7, line 5
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, while the short-term SDPng specification aims at supporting Finally, while the short-term SDPng specification aims at supporting
only the widespread offer/answer model for capability negotiation, a only the widespread offer/answer model for capability negotiation, a
future extension will also allow for content-independent negotiation future extension will also allow for content-independent negotiation
of session parameters by defining collapsing/intersection rules. In of session parameters by defining collapsing/intersection rules. In
particular, SDPng will take into account the need for multicast-based particular, SDPng will take the need for multicast-based distributed
distributed calculation of joint capabilities into account for those calculation of joint capabilities into account for those rules (but
rules (but note that it is *not* intended as a generic format for note that it is NOT intended as a generic format for describing
describing conference state information). Such functionality is not conference state information). Such functionality is not covered by
covered by current SDP -- but there is also no perceived urgent current SDP -- but there is also no perceived urgent demand so that
demand so that this sophisticated functional component of SDPng is this sophisticated functional component of SDPng is left to a future
left to a future protocol extension. The base SDPng protocol will protocol extension. The base SDPng protocol will provide the
provide the necessary flexibility, however. 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 revisions 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 a different
sequence "<sdpng" in the beginning of the announcement body, character sequence in the beginning of the announcement body,
but this is NOT RECOMMENDED. Instead, SAPv1 SHOULD be used, but this is NOT RECOMMENDED. Instead, SAPv1 SHOULD be used,
since it contains an explicit payload identifier. 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 be used to differentiate between
anf SDPng contents. two approaches are conceivable: Either SDP and SDPng contents. Two approaches are conceivable: Either
multipart MIME message is used with two parts containing the a 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 separate 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).
It is RECOMMENDED that implementations recognize the MIME It is RECOMMENDED that implementations recognize the MIME
multipart/alternative type in SAPv1 announcements, allowing for multipart/alternative type in SAPv1 announcements, allowing for
a simple transition to SDPng. a simple transition to SDPng.
It should be noted that current session directory implementations It should be noted that current session directory implementations
only support SDP. Nevertheless, using the SAP Message Identifier only support SDP. Nevertheless, using the SAP Message Identifier
Hash and the source address, they should be able to perform session Hash and the source address, they should be able to perform session
skipping to change at page 8, line 24 skipping to change at page 8, line 13
reason knows that all its potential audience will support SDPng, the reason knows that all its potential audience will support SDPng, the
SDP announcement SHOULD be omitted. SDP announcement SHOULD be omitted.
It should be noted that, for IPv4-based multicast sessions, session It should be noted that, for IPv4-based multicast sessions, session
directories still may rely on parsing the session specifications to directories still may rely on parsing the session specifications to
avoid clashes in the multicast address space. Introducing a new avoid clashes in the multicast address space. Introducing a new
session description language will prevent older implementations from session description language will prevent older implementations from
continuing this practice successfully -- assuming that only SDPng continuing this practice successfully -- assuming that only SDPng
announcements are used and/or that old implementations do not support announcements are used and/or that old implementations do not support
MIME multipart/alternative message bodies. This use of SAP is MIME multipart/alternative message bodies. This use of SAP is
deprecated, of course. deprecated, however.
4.2. Real-Time Streaming Protocol (RTSP) 4.2. Real-Time Streaming Protocol (RTSP)
RTSP uses SDP to provide presentation descriptions (with a RTSP uses SDP to provide presentation descriptions (with a
presentation comprising one or more media sessions), typically presentation comprising one or more media sessions), typically
communicated from the server to the client (for playing) and in the communicated from the server to the client for playback, and in the
opposite direction for recording. The presentation description may opposite direction for recording. The presentation description may
also include initialization data for the various media streams and also include initialization data for the various media streams and
URLs to be used for controlling the entire presentation as well as URLs to be used for controlling the entire presentation as well as
the individual media sessions. Transport parameters -- such as IP the individual media sessions. Transport parameters -- such as IP
addresses, port numbers, etc. -- are conveyed as part of RTSP header addresses, port numbers, etc. -- are conveyed as part of RTSP header
fields. fields.
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
indicate which content types it supports. If the client specifies which content types it supports. If the client specifies both SDP
both SDP and SDPng as acceptable, the server SHOULD provide only the and SDPng as acceptable, the server SHOULD provide only the SDPng-
SDPng-based presentation description. 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 (e.g. can, theoretically, use MIME multipart bodies (e.g.
"multipart/alternative") to convey both description types "multipart/alternative") to convey both description types
simultaneously. However, it is generally not expected that today's simultaneously. However, it is generally not expected that today's
RTSP clients and servers will be able handle multipart bodies. RTSP clients and servers will be able handle multipart bodies.
Hence, if no hint is provided by the client by means of the Accept: Hence, if no hint is provided by the client by means of the Accept:
header, the server MUST provide only an SDP description. 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
skipping to change at page 9, line 45 skipping to change at page 9, line 37
acceptable content types in the Accept: header (probably including acceptable content types in the Accept: header (probably including
"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
of a peer to understand SDPng in addition (or instead) plain SDP. a peer to understand SDPng in addition to (or instead of) plain SDP.
Methods such as OPTIONS MAY be used to determine a peer's support for 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
skipping to change at page 11, line 29 skipping to change at page 11, line 20
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
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 a different character sequence.
[Editor's Note: MEGACOP also supports a binary encoding for SDP Note that MEGACOP also supports a binary encoding for SDP
messages; current practice seems to favor the text encoding for messages; current practice seems to favor the text encoding for
SDP and hence we will not address the binary encoding.] SDP and hence we will not address a binary encoding for SDPng.
Within the context of MEGACO, various extensions to SDP have been Within the context of MEGACO, various extensions to SDP have been
defined, addressing its use for capability description and also defined, addressing its use for capability description and also
defining support for further network types (presently, ATM and TDM). defining support for further network types (presently, ATM and TDM).
Capability descriptions are inherently supported by SDPng. To add Capability descriptions are inherently supported by SDPng. To add
support for further networks, the respective parameters need to be support for further networks, the respective parameters need to be
defined as network-specific SDNng packages. defined as network-specific SDNng packages.
5. SDPng and Middleboxes 5. SDPng and Middleboxes
skipping to change at page 14, line 22 skipping to change at page 14, line 12
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 and 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," RFC 3388,
draft-ietf-mmusic-fid-06.txt, Work in Progress, February 2002. December 2002.
[5] F. Andreasen, "SDP Simple Capability Declaration," RFC 3407, [5] Flemming Andreasen, "SDP Simple Capability Declaration," RFC
October 2002. 3407, October 2002.
[6] Jonathan Rosenberg and Henning Schulzrinne, "An Offer/Answer [6] Jonathan Rosenberg and Henning Schulzrinne, "An Offer/Answer
Model with SDP," RFC 3264, June 2002. Model with SDP," RFC 3264, June 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-04.txt, Work in Internet Draft draft-ietf-mmusic-sdp-comedia-04.txt, Work in
Progress, July 2002. Progress, July 2002.
[9] Tom Taylor, "Conventions for the use of the Session Description [9] Gonzalo Camarillo and Jonathan Rosenberg, "The Alternative
Protocol (SDP) for Digital Circuit Connections," Internet Draft Semantics for the Session Description Protocol Grouping
draft-taylor-mmusic-sdp-tdm-01.txt, Work in Progress, April Framework," Internet Draft draft-camarillo-mmusic-alt-00.txt,
2002. Work in Progress, February 2003.
[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, Elisabetta Carrarra, Fredrik Lindholm, Mats Naslund, [11] Jari Arkko, Elisabetta Carrarra, Fredrik Lindholm, Mats Naslund,
and Karl Norrman, "Key Management Extensions for SDP and and Karl Norrman, "Key Management Extensions for SDP and
RTSP," Internet Draft draft-ietf-mmusic-kmgmt-ext-05.txt, Work RTSP," Internet Draft draft-ietf-mmusic-kmgmt-ext-06.txt, Work
in Progress, June 2002. in Progress, February 2003.
[12] Sean Olson, Gonzalo Camarillo, Adam Roach, [12] Sean Olson, Gonzalo Camarillo, Adam Roach, "Support for IPv6 in
Session Description Protocol (SDP)", RFC 3266, June 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-03.txt, Work in Progress, November 2001. manyfolks-resource-03.txt, Work in Progress, November 2001.
[14] G. Camarillo, H. Schulzrinne, and E. Burger, "The source and [14] G. Camarillo, H. Schulzrinne, and E. Burger, "The source and
sink attributes for the Session Description Protocol", Internet sink attributes for the Session Description Protocol", Internet
Draft draft-camarillo-mmusic-source-sink-00.txt, Work in Draft draft-camarillo-mmusic-source-sink-00.txt, Work in
Progress, September 2002. Progress, September 2002.
[15] Mark Baugher, "SDP Security Descriptions for Media Streams", [15] Mark Baugher, "SDP Security Descriptions for Media Streams",
Internet Draft draft-baugher-mmusic-sdpmediasec-00.txt, Work in Internet Draft draft-baugher-mmusic-sdpmediasec-00.txt, Work in
Progress, September 2002. Progress, September 2002.
[16] B. Quinn and R. Finlayson, "SDP Source-Filters", Internet [16] B. Quinn and R. Finlayson, "SDP Source-Filters", Internet
Draft draft-ietf-mmusic-sdp-srcfilter-01.txt, Work in Progress, Draft draft-ietf-mmusic-sdp-srcfilter-02.txt, Work in Progress,
July 2002. October 2002.
[17] G. Camarillo and A. Monrad, "Mapping of Media Streams to [17] G. Camarillo and A. Monrad, "Mapping of Media Streams to
Resource Reservation Flows", Internet Draft draft-ietf-mmusic- Resource Reservation Flows", Internet Draft draft-ietf-mmusic-
reservation-flows-00.txt, Work in Progress, October 2002. reservation-flows-01.txt, Work in Progress, October 2002.
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). 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/