draft-ietf-mmusic-sdpng-07.txt   draft-ietf-mmusic-sdpng-08.txt 
mmusic Kutscher mmusic Kutscher
Internet-Draft Ott Internet-Draft Ott
Expires: April 26, 2004 Bormann Expires: August 21, 2005 Bormann
TZI, Universitaet Bremen TZI, Universitaet Bremen
October 27, 2003 February 20, 2005
Session Description and Capability Negotiation Session Description and Capability Negotiation
draft-ietf-mmusic-sdpng-07.txt draft-ietf-mmusic-sdpng-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC2026. applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with RFC 3668.
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
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 http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document defines a language for describing multimedia sessions This document defines a language for describing multimedia sessions
with respect to configuration parameters and capabilities of with respect to configuration parameters and capabilities of
end-systems. end-systems. The description language is independent of specific
application scenarios (session announcement, session setup for
interactive communication etc.) and is not limited to specific media
types, capabilities, or configuration parameters.
This document is a product of the Multiparty Multimedia Session This document is a product of the Multiparty Multimedia Session
Control (MMUSIC) working group of the Internet Engineering Task Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the working Force. Comments are solicited and should be addressed to the working
group's mailing list at mmusic@ietf.org and/or the authors. group's mailing list at mmusic@ietf.org and/or the authors.
Document Revision Document Revision
$Revision: 6.18 $
$Revision: 6.21 $
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and System Model . . . . . . . . . . . . . . . . 6 2. Terminology and System Model . . . . . . . . . . . . . . . . 7
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Outline of the Negotiation Process . . . . . . . . . . . . . 10 3.1 Outline of the Negotiation Process . . . . . . . . . . . . . 11
3.2 Capability Types . . . . . . . . . . . . . . . . . . . . . . 12 3.2 SDPng Data Types . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Application-specific Vocabulary . . . . . . . . . . . . . . 14 3.3 Application-specific Vocabulary . . . . . . . . . . . . . . 15
4. SDPng Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 4. SDPng Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 SDPng Base Syntax . . . . . . . . . . . . . . . . . . . . . 15 4.1 SDPng Base Syntax . . . . . . . . . . . . . . . . . . . . . 16
4.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.1 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2 Token Sets . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.2 Token Sets . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.3 Numerical Values . . . . . . . . . . . . . . . . . . . . . . 18 4.2.3 Numerical Values . . . . . . . . . . . . . . . . . . . . . . 19
4.2.4 Numerical Ranges . . . . . . . . . . . . . . . . . . . . . . 18 4.2.4 Numerical Ranges . . . . . . . . . . . . . . . . . . . . . . 19
4.2.5 Sample SDPng cap Element . . . . . . . . . . . . . . . . . . 19 4.2.5 Sample SDPng cap Element . . . . . . . . . . . . . . . . . . 20
4.2.6 Referencing Capability Elements . . . . . . . . . . . . . . 20 4.2.6 Referencing Capability Elements . . . . . . . . . . . . . . 21
4.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4 Configurations . . . . . . . . . . . . . . . . . . . . . . . 22 4.4 Configurations . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Constraints . . . . . . . . . . . . . . . . . . . . . . . . 24 4.5 Constraints . . . . . . . . . . . . . . . . . . . . . . . . 25
4.6 Session Information . . . . . . . . . . . . . . . . . . . . 24 4.6 Session Information . . . . . . . . . . . . . . . . . . . . 25
4.7 Summary of SDPng XML-Syntax . . . . . . . . . . . . . . . . 24 4.7 Summary of SDPng XML-Syntax . . . . . . . . . . . . . . . . 26
5. Specification of the Capability Negotiation . . . . . . . . 26 5. Usage of SDPng in Different Application Scenarios . . . . . 28
5.1 Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1 Broadcast/Announcement Scenarios . . . . . . . . . . . . . . 28
5.2 RFC2533 Negotiation . . . . . . . . . . . . . . . . . . . . 28 5.2 Real-Time-Streaming . . . . . . . . . . . . . . . . . . . . 29
5.2.1 Translating SDPng to RFC 2533 Expressions . . . . . . . . . 28 5.3 Two-Way Session Setup . . . . . . . . . . . . . . . . . . . 31
5.2.2 Applying RFC 2533 Canonicalization . . . . . . . . . . . . . 31 5.4 Multi-Party-Conferencing with Negotiation . . . . . . . . . 38
5.2.3 Integrating Feature Sets into SDPng . . . . . . . . . . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39
5.2.4 Processing Negotiation Results . . . . . . . . . . . . . . . 32 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 40
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 34 References . . . . . . . . . . . . . . . . . . . . . . . . . 42
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43
References . . . . . . . . . . . . . . . . . . . . . . . . . 36 A. Formal Syntax Specifications . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 A.1 SDPng Base DTD . . . . . . . . . . . . . . . . . . . . . . . 44
A. Formal Syntax Specifications . . . . . . . . . . . . . . . . 38 A.2 SDPng XML-Schema Specification . . . . . . . . . . . . . . . 45
A.1 SDPng Base DTD . . . . . . . . . . . . . . . . . . . . . . . 38 B. Sample Package Definitions . . . . . . . . . . . . . . . . . 51
A.2 SDPng XML-Schema Specification . . . . . . . . . . . . . . . 38 B.1 Sample RTP Package Definition . . . . . . . . . . . . . . . 51
B. Sample Package Definitions . . . . . . . . . . . . . . . . . 45 B.2 Sample Audio Package Definition . . . . . . . . . . . . . . 52
B.1 Sample RTP Package Definition . . . . . . . . . . . . . . . 45 B.3 Sample Video Package Definition . . . . . . . . . . . . . . 52
B.2 Sample Audio Package Definition . . . . . . . . . . . . . . 46 C. Sample SDPng Description . . . . . . . . . . . . . . . . . . 54
B.3 Sample Video Package Definition . . . . . . . . . . . . . . 46 D. Change History . . . . . . . . . . . . . . . . . . . . . . . 58
C. Sample SDPng Description . . . . . . . . . . . . . . . . . . 48 Intellectual Property and Copyright Statements . . . . . . . 61
D. Use of SDPng in Conjunction with other IETF Signaling
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.1 The Session Announcement Protocol (SAP) . . . . . . . . . . 52
D.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . . 53
D.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . . 58
D.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . . 59
E. Change History . . . . . . . . . . . . . . . . . . . . . . . 61
Intellectual Property and Copyright Statements . . . . . . . 64
1. Introduction 1. Introduction
Different applications in the multimedia realtime communication
domain require a means for session description and capability
negotiation. For example, for establishing an interactive audio
communication session between two participants, end-systems must be
dynamically configured with respect to codec types, codec parameters,
transport protocol parameters and other configuration details. All
these parameters can be viewed as the configuration for a session,
and a session description language is used to describe this
configuration unambiguously.
While the fundamental requirement to describe session parameters
applies to all application scenarios, there are differences in how
configurations are obtained and distributed among participants. For
broadcast applications, e.g., sessions that are announced using SAP
or IMG protocols, the sender is typically distributing a session
description to potential receivers, describing the technical
parameters (e.g., multicast addresses, port numbers, codecs etc.) and
providing additional information about the session such as
meta-information (about the content) and scheduling information.
While a sender might provide alternative variants of one specific
broadcast event (different language versions, different media codec
configurations for different quality levels etc.) there is typically
no negotiation process between sender and receiver in order to obtain
the optimal configuration for a specific receiver. Instead, the
sender may provide different potential configurations and the
receiver would select the most appropriate one.
Real-time-streaming applications such as "video-on-demand" provide
similar but slightly different requirements. Still the sender is
typically providing a set of different potential configurations, out
of which the receiver may select the most appropriate one, so there
is not really a negotiation of content and its representation (on the
session description level). But, differently to the aforementioned
scenarios, the receiver must tell the sender the endpoint address,
i.e., where media data should be sent to. Depending on the control
protocol, this may be specified using the session description
language or other means (as it is done with RTSP).
Multiparty multimedia conferencing is one of the applications that Multiparty multimedia conferencing is one of the applications that
require dynamic interchange of end-system capabilities and the require dynamic interchange of end-system capabilities and the
negotiation of a parameter set that is appropriate for all sending negotiation of a parameter set that is appropriate for all sending
and receiving end-systems in a conference. For some applications, and receiving end-systems in a conference. For spontaneously
e.g. for loosely coupled conferences or for broadcast scenarios, it initiated conferences including Internet phone calls or ad-hoc
may be sufficient to simply have session parameters be fixed by the multiparty conferences, fixed settings for parameters such as media
initiator of a conference. In such a scenario no negotiation is
required because only those participants with media tools that
support the predefined settings can join a media session and/or a
conference.
This approach is applicable for conferences that are announced some
time ahead of the actual start date of the conference. Potential
participants can check the availability of media tools in advance and
tools such as session directories can configure media tools upon
startup. This procedure however fails to work for conferences
initiated spontaneously including Internet phone calls or ad-hoc
multiparty conferences. Fixed settings for parameters such as media
types, their encoding etc. can easily inhibit the initiation of types, their encoding etc. can easily inhibit the initiation of
conferences, for example in situations where a caller insists on a conferences, for example in situations where a caller insists on a
fixed audio encoding that is not available at the callee's fixed audio encoding that is not available at the callee's
end-system. end-system.
To allow for spontaneous conferences, the process of defining a To allow for spontaneous conferences, the process of defining a
conference's parameter set must therefore be performed either at conference's parameter set must therefore be performed either at
conference start (for closed conferences) or maybe (potentially) even conference start (for conferences with a fixed set of participants)
repeatedly every time a new participant joins an active conference. or maybe (potentially) even repeatedly every time a new participant
The latter approach may not be appropriate for every type of joins an active conference. The latter approach may not be
conference without applying certain policies: For conferences with appropriate for every type of conference without applying certain
TV-broadcast or lecture characteristics (one main active source) it policies: For conferences with TV-broadcast or lecture
is usually not desired to re-negotiate parameters every time a new characteristics (one main active source) it is usually not desired to
participant with an exotic configuration joins because it may re-negotiate parameters every time a new participant with an exotic
inconvenience existing participants or even exclude the main source configuration joins because it may inconvenience existing
from media sessions. But conferences with equal "rights" for participants or even exclude the main source from media sessions. But
participants that are open for new participants on the other hand conferences with equal "rights" for participants that are open for
would need a different model of dynamic capability negotiation, for new participants on the other hand would need a different model of
example a telephone call that is extended to a 3-parties conference dynamic capability negotiation, for example a telephone call that is
at some time during the session. extended to a 3-parties conference at some time during the session.
SDP [2] allows to specify multimedia sessions (i.e. conferences, SDP [2] allows to specify multimedia sessions (i.e. conferences,
"session" as used here is not to be confused with "RTP session"!) by "session" as used here is not to be confused with "RTP session"!) by
providing general information about the session as a whole and providing general information about the session as a whole and
specifications for all the media streams (RTP sessions and others) to specifications for all the media streams (RTP sessions and others) to
be used to exchange information within the multimedia session. be used to exchange information within the multimedia session.
Currently, media descriptions in SDP are used for two purposes: Currently, media descriptions in SDP are used for two purposes:
o to describe session parameters for announcements and invitations o to describe session parameters for announcements and invitations
(the original purpose of SDP) and (the original purpose of SDP) and
o to describe the capabilities of a system and possibly provide a o to describe the capabilities of a system and possibly provide a
choice between a number of alternatives (which SDP was not choice between a number of alternatives (which SDP was not
designed for). designed for).
A distinction between these two "sets of semantics" is only made A distinction between these two "sets of semantics" was initially
implicitly. only made implicitly. While numerous extensions to SDP were
developed to account for various aspects of interactive session
establishment (the offer/answer model in RFC 3264, grouping of media
sessions in RFC 3388, and simple capability declaration in RFC 3407,
among others), their expressiveness is naturally constrained by the
simple (and veru limited) SDP syntax.
This document is based upon a set of requirements specified in a SDPng, the session description languages specified in this document,
companion document [1]. In the following, we first introduce a model provide a common, XML-based framework for session description and
for session description and capability negotiation as well as the capability description for the aforementioned application scenarios.
basic terms used throughout this specification (Section 2). In It allows for distributing "fixed" configuration descriptions in
Section 3, we provide an overview of options for capability broadcast application scenarios but also supports the dynamic
negotiation. Next, we outline the concept for the concepts underlying negotiation of session parameters for interactive multimedia
SDPng and introduce the syntactical components step by step in conferences.
Section 4.
In order to support a broad range of different applications, SDPng
itself is completely application-agnostic. The base specification
does not define any application-specific vocabulary, e.g., media
types, codecs and their configuration parameters etc., but is
intended as an extensible framework that provides the necessary
extensibility mechanisms for supporting both future applications and
future transport and encoding mechanisms.
With respect to capability negotiation, SDPng is based on the
following principles:
Capability negotiation is an optional feature, which MAY be
employed for specific applications, e.g., session setup for
interactive communication.
SDPng provides the framework for describing capabilities and
linking them to configurations of application sessions, but the
base specification does not prescribe negotiation algorithms such
as feature matching.
The SDPng base specification provides the necessary support for
application-independent capability negotiation, i.e., an SDPng
processor that receives capability descriptions from one or
multiple participants does not need to understand the capability
semantics in order to process the different capability
descriptions. For this purpose, SDPng provides a well-defined set
of data types and defines a value representation that allows SDPng
processors to infer data types without requiring access to schema
definitions and without requiring application-specific knowledge.
For most application classes, especially for broadcast applications,
the session description will have to provide information about the
session that is not used to configure end-systems but rather to
facilitate content navigation for human users. For example, This
meta-information can include author/source details, additional
information about the whole session or individual media sessions,
scheduling information and other, arbitrary information that is
related to the session but not directly required to achieve
interoperability between end-systems. SDPng provides fundamental
mechanisms that support the inclusion of meta-information:
Descriptions of application components (media sessions) and
alternative configurations can be labeled to enable later
referencing, i.e., for associating meta-information. For example,
in a multi-language TV broadcast session, the language information
could be provided by a meta-information fragment that assigns
language tags to media session descriptions by referencing them.
SDPng itself does not define vocabulary for specifying
meta-information, but allows for including arbitrary
meta-information fragments, e.g., MPEG-7 descriptions. These
description may either be included or inline or be referenced by
URIs.
In the following, we first introduce a model for session description
and capability negotiation as well as the basic terms used throughout
this specification (Section 2). In Section 3, we provide an overview
of options for capability negotiation. Next, we outline the concept
for the concepts underlying SDPng and introduce the syntactical
components step by step in Section 4. Section 5 describes how SDPng
can be used in different application scenarios.
Appendix A provide formal specifications of SDPng such as XML DTD and Appendix A provide formal specifications of SDPng such as XML DTD and
Schema definitions, Appendix D describes the usage of SDPng in Schema definitions, Appendix B provides some sample package
conjunction with IETF control protocol for multimedia communication definitions, Appendix C provides a sample SDPng description, and
and Appendix E lists the change history. Appendix D lists the change history.
2. Terminology and System Model 2. Terminology and System Model
Any (computer) system has, at a time, a number of rather fixed Any (computer) system has, at a time, a number of rather fixed
hardware as well as software resources. These resources ultimately hardware as well as software resources. These resources ultimately
define the limitations on what can be captured, displayed, rendered, define the limitations on what can be captured, displayed, rendered,
replayed, etc. with this particular device. We term features enabled replayed, etc. with this particular device. We term features enabled
and restricted by these resources "system capabilities". and restricted by these resources "system capabilities".
Example: System capabilities may include: a limitation of the Example: System capabilities may include: a limitation of the
screen resolution for true color by the graphics board; available screen resolution for true color by the graphics board; available
audio hardware or software may offer only certain media encodings audio hardware or software may offer only certain media encodings
(e.g. G.711 and G.723.1 but not GSM); and CPU processing power and (e.g. G.711 and G.723.1 but not GSM); and CPU processing power,
quality of implementation may constrain the possible video available licenses, and quality of implementation may constrain
encoding algorithms. the possible video encoding algorithms.
In multiparty multimedia conferences, participants employ different In multiparty multimedia conferences, participants employ different
"components" in conducting the conference. "components" in conducting the conference; similarly, a multimedia
(rather than plain TV) broadcast may comprise several components that
make up the full presentation.
Example: In lecture multicast conferences one component might be Example: In lecture multicast conferences one component might be
the voice transmission for the lecturer, another the transmission the voice transmission for the lecturer, another the transmission
of video pictures showing the lecturer and the third the of video pictures showing the lecturer and the third the
transmission of presentation material. transmission of presentation material.
Depending on system capabilities, user preferences and other Depending on system capabilities, user preferences and other
technical and political constraints, different configurations can be technical and policy constraints, different configurations can be
chosen to accomplish the use of these components in a conference. chosen to accomplish the use of these components in a conference.
Each component can be characterized at least by (a) its intended use Each component can be characterized at least by (a) its intended use
(i.e. the function it shall provide) and (b) one or more possible (i.e. the function it shall provide) and (b) one or more possible
ways to realize this function. Each way of realizing a particular ways to realize this function. Each way of realizing a particular
function is referred to as a "configuration". function is referred to as a "configuration".
Example: A conference component's intended use may be to make Example: A conference component's intended use may be to make
transparencies of a presentation visible to the audience on the transparencies of a presentation visible to the audience on the
Mbone. This can be achieved either by a video camera capturing the Mbone. This can be achieved either by a video camera capturing the
skipping to change at page 7, line 41 skipping to change at page 8, line 44
operation of this component's particular instantiation. operation of this component's particular instantiation.
Example: The potential configuration of the aforementioned video Example: The potential configuration of the aforementioned video
component may indicate support for JPEG, H.261/CIF, and H.261/ component may indicate support for JPEG, H.261/CIF, and H.261/
QCIF. A particular instantiation for a video conference may use QCIF. A particular instantiation for a video conference may use
the actual configuration of H.261/CIF for exchanging video the actual configuration of H.261/CIF for exchanging video
streams. streams.
In summary, the key terms of this model are: In summary, the key terms of this model are:
o A multimedia session (streaming or conference) consists of one or o A multimedia session (broadcast, streaming or conference) consists
more conference components for multimedia "interaction". of one or more conference components for multimedia "interaction".
o A component describes a particular type of interaction (e.g. audio o A component describes a particular type of interaction (e.g. audio
conversation, slide presentation) that can be realized by means of conversation, slide presentation) that can be realized by means of
different applications (possibly using different protocols). different applications (possibly using different protocols).
o A configuration is a set of parameters that are required to o A configuration is a set of parameters that are required to
implement a certain variation (realization) of a certain implement a certain variation (realization) of a certain
component. There are actual and potential configurations. component. There are actual and potential configurations.
* Potential configurations describe possible configurations that * Potential configurations describe possible configurations that
skipping to change at page 9, line 5 skipping to change at page 10, line 7
Capability negotiation must not only work for 2-party conferences but Capability negotiation must not only work for 2-party conferences but
is also required for multi-party conferences. Especially for the is also required for multi-party conferences. Especially for the
latter case it is required that the process to determine the subset latter case it is required that the process to determine the subset
of allowable potential configurations is deterministic to reduce the of allowable potential configurations is deterministic to reduce the
number of required round trips before a session can be established. number of required round trips before a session can be established.
For instance, in order to be used with SIP, the capability For instance, in order to be used with SIP, the capability
negotiation is required to work with the offer/answer model that is negotiation is required to work with the offer/answer model that is
for session initiation with SIP -- limiting the negotiation to for session initiation with SIP -- limiting the negotiation to
exactly one round trip. exactly one round trip.
The requirements for the SDPng specification, subdivided into general
requirements and requirements for session descriptions, potential and
actual configurations as well as negotiation rules, are captured in a
companion document [1].
The following list explains some terms used in this document: The following list explains some terms used in this document:
Actual Configuration Actual Configuration
An actual configuration is an "instantiation" of one of the An actual configuration is an "instantiation" of one of the
potential configurations, i.e. a decision how to realize a certain potential configurations, i.e. a decision how to realize a certain
component. component.
Component Component
A component describes a particular type of interaction (e.g. audio A component describes a particular type of interaction (e.g. audio
conversation, slide presentation) that can be realized by means of conversation, slide presentation) that can be realized by means of
different applications (possibly using different protocols). different applications (possibly using different protocols).
Package Package
A package is application specific data schema for expressing A package is an application specific data schema for expressing
potential and actual configurations. For example, an audio package potential and actual configurations. For example, an audio package
specifies the data schema for audio codecs. specifies the data schema for audio codecs.
Potential Configuration Potential Configuration
Potential configurations describe possible configurations that are Potential configurations describe possible configurations that are
supported by an end-system ("capabilities"). supported by an end-system ("capabilities").
3. Overview 3. Overview
SDPng is a description language for both potential configurations SDPng is a description language for both potential configurations
(i.e. capabilities) of participants in multimedia conferences and for (i.e. capabilities) of participants in multimedia conference and for
actual configurations (i.e. final specifications of parameters). actual configurations (i.e. final specifications of parameters).
Capability negotiation is the process of generating a usable set of Capability negotiation is the process of generating a usable set of
potential configurations and finally an actual configuration from a potential configurations and finally an actual configuration from a
set of potential configurations provided by each potential set of potential configurations provided by each potential
participant in a multimedia conference. participant in a multimedia conference.
SDPng itself is an application-independent framework that defines a SDPng itself is an application-independent framework that defines a
description syntax and processing rules that are applied to the description syntax that are enable an (optional) capability
capability negotiation process. The rules specify how to process two negotiation process. It should be noted, that SDPng can be used
or more capability description in general in order to obtain an without capability negotiation and that the specific negotiation
interworking configuration. algorithm is not specified in this document.
A capability description for an endpoint is a set of individual A capability description for an endpoint is a set of individual
capabilities, each of which provides a fixed type, e.g., a numeric capabilities, each of which provides a fixed type, e.g., a numeric
value or a list value. The set of types and the corresponding value or a list value. The set of types and the corresponding
negotiation rules are defined in this memo. abstract negotiation rules are defined in this memo. The SDPng data
types are relevant to all SDPng application domains, while the
processing rules are only applicable to application domains that rely
on capability negotiation.
In the following, we provide an overview of the negotiation process In the following, we provide a conceptual overview of the negotiation
in Section 3.1 and describe the different capability types and the process in Section 3.1 and describe the different capability types
corresponding negotiation rules in Section 3.2. and the corresponding abstract negotiation rules in Section 3.2.
3.1 Outline of the Negotiation Process 3.1 Outline of the Negotiation Process
SDPng supports the specification of endpoint capabilities and defines SDPng supports the specification of endpoint capabilities and defines
a negotiation process: In a negotiation process, capability a negotiation process: In a negotiation process, capability
descriptions are exchanged between participants. These descriptions descriptions are exchanged between participants. These descriptions
are processed in a "collapsing" step which results in a set of are processed in a "collapsing" step which results in a set of
commonly supported potential configurations. In a second step, the commonly supported potential configurations. In a second step, the
final actual configuration is determined that is used for a final actual configuration is determined that is used for a
conference. This section specifies the usage of SDPng for capability conference. This section specifies the usage of SDPng for capability
skipping to change at page 12, line 28 skipping to change at page 13, line 31
Note that the model presented here results in four SDPng messages. As Note that the model presented here results in four SDPng messages. As
an optimization, this procedure can be abbreviated to two exchanges an optimization, this procedure can be abbreviated to two exchanges
by including the transport (and other) parameters into the potential by including the transport (and other) parameters into the potential
configurations. A embeds its desired transport parameters into the configurations. A embeds its desired transport parameters into the
list of potential configurations and B also sends all required list of potential configurations and B also sends all required
parameters in the response together with B's potential parameters in the response together with B's potential
configurations. Both A and B can then derive CFG_T(AB). Transport configurations. Both A and B can then derive CFG_T(AB). Transport
parameters are usually not negotiable, therefor they have to be parameters are usually not negotiable, therefor they have to be
distinguished from other configuration information. distinguished from other configuration information.
The SDPng capability negotiation process is specified in Section 5. Note also that, in case of multicast/broadcast scenarios, the sender
may simply provide the full description of the alternative
configurations including (transport) parameters. The potential
receivers will decide based upon this information whether or not they
are capable of receiving the respective media sessions and pick the
most suitable configuration.
3.2 Capability Types 3.2 SDPng Data Types
The capability negotiation process relies on a fixed set of The description of actual configurations and the capability
processing rules for different types of capabilities. The following negotiation process rely on a fixed set of data types with
types are defined: corresponding processing rules. The following types are defined:
1. Tokens (text strings) 1. Tokens (text strings)
Example: Example:
<audio:encoding>PCMU</audio:encoding> <audio:encoding>PCMU</audio:encoding>
Processing rule: Processing rule:
Ascertain identity Ascertain identity (compare strings)
2. Token lists 2. Token lists
Example: Example:
<audio:sampling-rate>8000 16000</audio:sampling-rate> <audio:sampling-rate>8000 16000</audio:sampling-rate>
Processing rule: Processing rule:
Determine common subset Determine common subset
3. Numbers 3. Numbers
Example: Example:
<audio:bitrate val="64"/> <audio:bitrate val="64"/>
Processing rule: Processing rule:
skipping to change at page 14, line 7 skipping to change at page 15, line 11
In addition to capabilities, a SDPng description can also provide In addition to capabilities, a SDPng description can also provide
parameters that are not negotionable, e.g., transport parameters. In parameters that are not negotionable, e.g., transport parameters. In
SDPng, there is a distinction between capability definitions (that SDPng, there is a distinction between capability definitions (that
are subject to a negotiation process) and parameters that are are subject to a negotiation process) and parameters that are
specified by each participant. In a description of alternative specified by each participant. In a description of alternative
configurations for a specific component, capabilities and parameters configurations for a specific component, capabilities and parameters
can be referred to and describe the configurations. can be referred to and describe the configurations.
3.3 Application-specific Vocabulary 3.3 Application-specific Vocabulary
While the SDPng specification defines the fundamental definition While the SDPng specification defines the fundamental types, abstract
types, processing rules and the syntax definition for SDPng processing rules and the syntax definition for SDPng descriptions, it
descriptions, it does not define any application-specific vocabulary. does not define any application-specific vocabulary.
Application-specific vocabulary is defined in SDPng packages. An Application-specific vocabulary is defined in SDPng packages. An
SDPng package defines a schema for application specific capability SDPng package defines a schema for application specific capability
and parameter descriptions. Based on the description types specified and parameter descriptions. Based on the description types specified
by the SDPng base specification, a package definition specifies the by the SDPng base specification, a package definition specifies the
capability and parameter definitions allowed for a specific capability and parameter definitions allowed for a specific
application, the types of definitions and additional attributes, application, the types of definitions and additional attributes,
e.g., whether a definition element is optional with respect to the e.g., whether a definition element is optional with respect to the
capability negotiation or not. capability negotiation or not.
The SDPng base specification does define some fundamental The SDPng base specification does define some fundamental
requirements for definition elements that are specified in package requirements for definition elements that are specified in package
definitions, for example XML attributes for elements. Appendix A.2 definitions, for example XML attributes for elements. Appendix A.2
provides an XML Schema definition that specifies some base types that provides an XML Schema definition that specifies some base types to
to be used for package definitions. be used for package definitions.
In order to allow for an application independent processing of SDPng In order to allow for an application independent processing of SDPng
description documents, SDPng descriptions are standalone, i.e., the description documents, SDPng descriptions are standalone, i.e., the
package definition is not required to process a corresponding SDPng package definition is not required to process a corresponding SDPng
document. All information, e.g., the type of definitions and document. All information, e.g., the type of definitions and
additional attributes are contained in the SDPng document itself. An additional attributes are contained in the SDPng document itself. An
SDPng implementation can thus be processed without access to the SDPng implementation can thus be processed without access to the
package definition. package definition.
4. SDPng Syntax 4. SDPng Syntax
skipping to change at page 15, line 23 skipping to change at page 16, line 23
Configurations Configurations
Constraints Constraints
Session Information Session Information
The Capabilities section provides a list of individual capabilities. The Capabilities section provides a list of individual capabilities.
In a capability negotiation process, these capabilities are matched In a capability negotiation process, these capabilities are matched
against corresponding definitions of other participants' capability against corresponding definitions of other participants' capability
descriptions. This section MUST be present in any SDPng description. descriptions. This section is OPTIONAL for a SDPng description
document.
The Definitions section provides definitions of commonly used The Definitions section provides definitions of commonly used
parameters for later referencing. This section is OPTIONAL for SDPng parameters for later referencing. This section is OPTIONAL for SDPng
descriptions. descriptions.
The Configurations section provides the description of the different The Configurations section provides the description of the different
conference components (applications in a conference). Each component conference components (applications in a conference). Each component
description can provide a list of alternative configurations. This description can provide a list of alternative configurations. This
section MUST be present in any SDPng description. section MUST be present in any SDPng description.
skipping to change at page 16, line 33 skipping to change at page 17, line 33
[...] [...]
</constraints> </constraints>
<info> <info>
[...] [...]
</info> </info>
</sdpng> </sdpng>
Appendix A.1 provides a XML DTD that defines a corresponding document Appendix A.1 provides a XML DTD that defines a corresponding document
type. type.
Note that the elements for the optional sections "Definitions", Note that the elements for the optional sections "Capabilities",
"Contraints", and "Session-Level Information" are OPTIONAL. "Definitions", "Contraints", and "Session-Level Information" are
OPTIONAL.
Application-specific vocabulary resides in its own namespace. For Application-specific vocabulary resides in its own namespace. For
each namespace name of an SDPng package, a namespace prefix MUST be each namespace name of an SDPng package, a namespace prefix MUST be
declared in the start tag of the "sdpng" element. The following declared in the start tag of the "sdpng" element. The following
figure depicts the declaration of namespace prefixes for two package figure depicts the declaration of namespace prefixes for two package
namespaces: namespaces:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<sdpng xmlns="http://www.iana.org/sdpng" <sdpng xmlns="http://www.iana.org/sdpng"
xmlns:sdpng="http://www.iana.org/sdpng" xmlns:sdpng="http://www.iana.org/sdpng"
skipping to change at page 17, line 48 skipping to change at page 18, line 48
package definitions. XML Namespaces are used to disambiguate element package definitions. XML Namespaces are used to disambiguate element
types and to allow for extensibility. Each feature element can types and to allow for extensibility. Each feature element can
provide a "range" of values -- not only a single value. For example, provide a "range" of values -- not only a single value. For example,
a feature element can specify a set of supported alternative values a feature element can specify a set of supported alternative values
for a given property, e.g., for the sampling rate of an audio codec. for a given property, e.g., for the sampling rate of an audio codec.
SDPng provides two different ways for representing "value ranges": A SDPng provides two different ways for representing "value ranges": A
feature element can specify a set of tokens or a numerical range. feature element can specify a set of tokens or a numerical range.
Each feature that is represented by an XML feature element has a Each feature that is represented by an XML feature element has a
well-defined type that is specified in the package definition. The well-defined type that is specified in the package definition. The
type determines the representation of the element values so that type type determines the representation of the element values in XML so
information is encoded implicitly in the description document. Each that type information is encoded implicitly in the description
feature element MAY provide an attribute "status". If this attribute document. For example, a token set can be identified by the presence
is present it MUST provide one of the following values: of whitespace separated list of token as element content of the
respective feature element. Each feature element MAY provide an
attribute "status". If this attribute is present it MUST provide one
of the following values:
opt: opt:
This element describes an optional feature (as described by This element describes an optional feature (as described by
Section 3.2). Section 3.2).
The three different features types (as described in Section 3.2) are The three different features types (as described in Section 3.2) are
represented as described in the following sections. Section 4.2.5 represented as described in the following sections. Section 4.2.5
provides a complete example. provides a complete example.
4.2.1 Tokens 4.2.1 Tokens
skipping to change at page 18, line 30 skipping to change at page 19, line 32
Boolean values SHOULD be represented as token elements with a values Boolean values SHOULD be represented as token elements with a values
of either "true" or "false". of either "true" or "false".
4.2.2 Token Sets 4.2.2 Token Sets
Token set elements provide a token list as element content. The token Token set elements provide a token list as element content. The token
is of type Nmtokens (name tokens) as defined by [9]. The following is of type Nmtokens (name tokens) as defined by [9]. The following
example depicts a feature element of type token set. example depicts a feature element of type token set.
<audio:sampling>8000 16000</audio:sampling> <audio:sampling>8000 16000 32000</audio:sampling>
4.2.3 Numerical Values 4.2.3 Numerical Values
Elements for numbers provide an attribute "val" with a numerical Elements for numbers provide an attribute "val" with a numerical
value. The following example depicts a feature element of type value. The following example depicts a feature element of type
numerical value. numerical value.
<audio:bitrate val="64"/> <audio:bitrate val="64"/>
4.2.4 Numerical Ranges 4.2.4 Numerical Ranges
skipping to change at page 20, line 30 skipping to change at page 21, line 30
The referencing element MAY also provide additional feature elements The referencing element MAY also provide additional feature elements
(that have not been provided by the referenced capability element). (that have not been provided by the referenced capability element).
The referencing element MAY also provide feature elements that have The referencing element MAY also provide feature elements that have
already been provided by the referenced element. already been provided by the referenced element.
The referencing element MAY provide an attribute "name". The The referencing element MAY provide an attribute "name". The
semantics of a reference are defined in the corresponding sections semantics of a reference are defined in the corresponding sections
where references to definitions are used, i.e., in Section 4.3 and in where references to definitions are used, i.e., in Section 4.3 and in
Section 4.4. Section 4.4.
Section 5.2.4 provides implementation requirements for dealing with
references to capability elements after a capability negotiation
process.
4.3 Definitions 4.3 Definitions
The Definitions section is an optional section that can provide The Definitions section is an optional section that can provide
definitions of fixed parameters that are not negotionable such as definitions of fixed parameters that are not negotionable such as
transport parameters. An SDPng description document MAY provide a transport parameters. An SDPng description document MAY provide a
"def" element that can provide a set of definitions as child "def" element that can provide a set of definitions as child
elements. elements.
Each child element of a "def" element provides an element type Each child element of a "def" element provides an element type
specified in a package definition. Such child elements are referred specified in a package definition. Such child elements are referred
skipping to change at page 22, line 7 skipping to change at page 23, line 5
o An implementation MUST process the newly defined element by o An implementation MUST process the newly defined element by
adopting the individual feature elements of the referenced adopting the individual feature elements of the referenced
capability element. capability element.
o For feature elements that are present in both the capability o For feature elements that are present in both the capability
element and the description element, the feature elements of the element and the description element, the feature elements of the
definition element take precedence over the feature elements of definition element take precedence over the feature elements of
the capability element. the capability element.
Please note the implementation requirements for dealing with
references to capability elements after a capability negotiation
process provided in Section 5.2.4.
4.4 Configurations 4.4 Configurations
The Configurations section lists all the components that constitute The Configurations section lists all the components that constitute
the multimedia application (IP telephone call, real-time streaming the multimedia application (IP telephone call, real-time streaming
application, multi-player gaming session etc.). For each of these application, multi-player gaming session etc.). For each of these
components, the actual configurations are given. components, the actual configurations are given.
An SDPng document MUST provide a "cfg" element that represents the An SDPng document MUST provide a "cfg" element that represents the
Configurations section. The "cfg" element provides one or more Configurations section. The "cfg" element provides one or more
"component" element describing alternative configurations for the "component" element describing alternative configurations for the
component. The "cfg" element SHOULD provide at least one "component" component. The "cfg" element SHOULD provide at least one "component"
element. Each "component" element MUST provide an attribute "name" element. Each "component" element MUST provide an attribute "name"
that identifies the component uniquely in the scope of the SDPng that identifies the component uniquely in the scope of the SDPng
description. description. Each "component" element MAY provide an attribute status
of type CDATA that MAY be used to specify application specific status
information.
Each "component" element MUST provide one or more "alt" element, each Each "component" element MUST provide one or more "alt" element, each
of which describes an alternative configuration for the component. of which describes an alternative configuration for the component.
Each "alt" element MUST provide an attribute "name" that provides a Each "alt" element MUST provide an attribute "name" that provides a
unique identification for the alternative in the scope of the SDPng unique identification for the alternative in the scope of the SDPng
description. In addition, each "alt" element MUST also provide an description. In addition, each "alt" element MUST also provide an
attribute "media" for specifying the media type for this particular attribute "media" for specifying the media type for this particular
alternative. Currently defined values for this attribute are "audio", alternative. Currently defined values for this attribute are "audio",
"video", "application", "data", and "control". The semantics of these "video", "application", "data", and "control". The semantics of these
values are described in [2]. values are described in [2].
Each "alt" element MUST provide one or more XML elements that Each "alt" element MUST provide one or more XML elements that
describe the configuration parameters for the particular alternative describe the configuration parameters for the particular alternative
configuration. The elements are defined by SDPng package configuration. The elements are defined by SDPng package
specification and definition from different packages can be mixed. specification and definitions from different packages can be mixed.
The type of the elements and their order is application dependent. The type of the elements and their order is application dependent.
Each definition element that is contained in an "alt" element SHOULD Each definition element that is contained in an "alt" element MAY
provide an attribute "ref". The "ref" attribute is used to specify a provide an attribute "ref". The "ref" attribute is used to specify a
reference to a capability element (from a "cap" section) or to a reference to a capability element (from a "cap" section) or to a
definition element (from a "def" section). The value of an "ref" definition element (from a "def" section). The value of an "ref"
element MUST provide the value of a "name" attribute of an existing element MUST provide the value of a "name" attribute of an existing
capability or definition element. A definition element MAY provide capability or definition element. A definition element MAY provide
child elements (for the specification of additional feature and child elements (for the specification of additional feature and
configuration parameters) but it MAY also be an empty element. The configuration parameters) but it MAY also be an empty element. The
semantics of referencing the capability element are as follows: semantics of referencing the capability element are as follows:
o An implementation MUST process the newly defined element by o An implementation MUST process the newly defined element by
adopting the individual feature elements of the referenced adopting the individual feature elements of the referenced
capability or definition element. capability or definition element.
o For feature elements that are present in both the capability/ o For feature elements that are present in both the capability/
definition element and the current definition element, the feature definition element and the current definition element, the feature
elements of the current definition element take precedence over elements of the current definition element take precedence over
the feature elements of the referenced element. the feature elements of the referenced element.
Please note the implementation requirements for dealing with It should be noted that the inclusion of definition by reference is
references to capability elements after a capability negotiation NOT MANDATORY. For certain applications such as session announcement,
process provided in Section 5.2.4. it may be sufficient to provide the configuration data directly
inside an "alt" element.
The following example depicts the description of a single The following example depicts the description of a single
configuration for a component named "interactive-audio". The configuration for a component named "interactive-audio". The
description of the configuration references the "avp:pcmu" audio description of the configuration references the "avp:pcmu" audio
codec definition from the "cap" element and the "rtp-cfg1" RTP codec definition from the "cap" element and the "rtp-cfg1" RTP
session definition from the "def" element. In this example, both session definition from the "def" element. In this example, both
elements of the "alt" element are empty elements that adopt the elements of the "alt" element are empty elements that adopt the
specified values from the referenced elements. specified values from the referenced elements.
<?xml version="1.0"?> <?xml version="1.0"?>
skipping to change at page 23, line 44 skipping to change at page 24, line 39
<def> <def>
<rtp:udp name="rtp-cfg1" ref="rtp:rtpudpip6"> <rtp:udp name="rtp-cfg1" ref="rtp:rtpudpip6">
<rtp:ip-addr>::1</rtp:ip-addr> <rtp:ip-addr>::1</rtp:ip-addr>
<rtp:rtp-port>9456</rtp:rtp-port> <rtp:rtp-port>9456</rtp:rtp-port>
<rtp:pt>1</rtp:pt> <rtp:pt>1</rtp:pt>
</rtp:udp> </rtp:udp>
</def> </def>
<cfg> <cfg>
<component name="interactive-audio" media="audio"> <component name="interactive-audio" media="audio" status="active">
<alt name"alt1"> <alt name"alt1">
<audio:codec ref="avp:pcmu"/> <audio:codec ref="avp:pcmu"/>
<rtp:udp ref="rtp-cfg1"/> <rtp:udp ref="rtp-cfg1"/>
</alt> </alt>
</component> </component>
</cfg> </cfg>
<constraints> <constraints>
[...] [...]
</constraints> </constraints>
<info> <info>
[...] [...]
</info> </info>
</sdpng> </sdpng>
4.5 Constraints 4.5 Constraints
The Constraints section allows to express constraints on the The Constraints section allows to express constraints on the
combination of configurations that apply across different components. combination of configurations that apply across different components.
This feature is intended for specialized devices with strict
limitations on, e.g., parallel codec instantiations due to limited
DSP resources. The SDPng base specification does not define the use
of constraints. Instead, the usage of constraints will be specified
in a separate document.
The "constraints" element of an SDPng description is OPTIONAL. The "constraints" element of an SDPng description is OPTIONAL.
The usage of constraints will be specified in a separate document.
4.6 Session Information 4.6 Session Information
The Session Information section is represented by an "info" element The Session Information section is represented by an "info" element
and is intended for meta information on the conference itself and on and is intended for meta information on the conference itself and on
the individual components. the individual components. In an SDPng description document, the
"info" element MAY provide one or multiple "part" element, each of
which may contain arbitrary meta-description content.
The "info" element is OPTIONAL and, if it is present, it MAY provide The "info" element is OPTIONAL in an SDPng description document.
a list of information elements. The element types are specified in
package definitions. Each "part" element inside an "info" element MUST provide a "type"
attribute that specifies the type of the meta-information content,
e.g., "MPEG-7", "TV-Anytime", "MPEG-21", "SDP".
Each "part" element inside an "info" element MAY provide a "ref"
attribute that can be used to specify an URI for the meta-information
content. If a "ref" attribute is provided the "part" element MUST be
empty.
<?xml version="1.0"?>
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:sdpng="http://www.iana.org/sdpng">
<cap>
<audio:codec name="avp:pcmu">[...]</audio:codec>
<rtp:udp name="rtpudpip6">[...]</rtp:udp>
</cap>
<def>
<rtp:udp name="rtp-cfg1" ref="rtp:rtpudpip6">
<rtp:ip-addr>::1</rtp:ip-addr>
<rtp:rtp-port>9456</rtp:rtp-port>
<rtp:pt>1</rtp:pt>
</rtp:udp>
</def>
<cfg>
<component name="interactive-audio" media="audio" status="active">
<alt name"alt1">
<audio:codec ref="avp:pcmu"/>
<rtp:udp ref="rtp-cfg1"/>
</alt>
</component>
</cfg>
<constraints>
[...]
</constraints>
<info>
<part type="SDP">
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
t=2873397496 2873404696
</part>
</info>
</sdpng>
4.7 Summary of SDPng XML-Syntax 4.7 Summary of SDPng XML-Syntax
The SDPng base specification defines the following XML element types The SDPng base specification defines the following XML element types
that reside in the SDPng namespace designated by the namespace name that reside in the SDPng namespace designated by the namespace name
"http://www.iana.org/sdpng": "http://www.iana.org/sdpng":
o sdpng o sdpng
o cap o cap
skipping to change at page 24, line 45 skipping to change at page 27, line 4
that reside in the SDPng namespace designated by the namespace name that reside in the SDPng namespace designated by the namespace name
"http://www.iana.org/sdpng": "http://www.iana.org/sdpng":
o sdpng o sdpng
o cap o cap
o def o def
o cfg o cfg
o component o component
o alt o alt
o constraints o constraints
o info o info
Appendix A.1 provides an XML DTD that specifies the content model of Appendix A.1 provides an XML DTD that specifies the content model of
the SDPng base elements. the SDPng base elements.
5. Specification of the Capability Negotiation 5. Usage of SDPng in Different Application Scenarios
The SDPng specification defines the syntax and the semantics of This informative section describes how SDPng can be used in different
capability descriptions. The algorithms that are used for processing application scenarios, namely broadcast/announcement,
descriptions and for comparing capability descriptions from different real-time-streaming, two-way-session-setup, and multiparty
participants are application specific. conferencing with negotiation.
In this section, we specify two alternative algorithms for 5.1 Broadcast/Announcement Scenarios
implementations: A model that is based on the SDP offer/answer scheme
(Section 5.1 and a model that is based on the feature matching
algorithm that is specified in RFC 2533 [15] (Section 5.2).
5.1 Offer/Answer Broadcast and multicast application scenarios rely on session
announcements to communicate information about multimedia sessions
and their associated parameters. Historically, in the Mbone, the
Session Announcement Protocol (SAP) [RF2974] was used to convey
static session descriptions via multicast but the same information
could also be advertized by means of email, NetNews, or web pages.
For some years, digital television used Electronic Program Guides
(EPGs) to convey programming information (movie schedule, metadata,
channel information) to large audiences. More recently, streaming
services for (3G and beyond) mobile networks make use of similar
concepts to announce streaming services. As a response to these
needs, the generalized framework of Internet Media Guides (IMGs) has
been devised to address conveying scheduling and media information to
potentially large receiver groups. This subsection addresses the use
of SDPng with SAP and IMG-based session announcements.
SAP and IMGs are used to disseminate a previously created (and
typically fixed) session description to a potentially large audience.
An interested member of the audience will use the SDPng description
communicated via SAP or IMGs to join the announced media sessions.
While this is supported by MIME types identifying SDPng contents with
implied semantics, the IMG framework explicitly suggests interactive
retrieval using HTTP. Furthermore, IMG has the concept of
asynchronous notifications/updates to existing SDPng descriptions: it
makes use of a (SIP-based) notification mechanism that allows
interested parties to monitor the state of session descriptions and
receive asynchronous updates whenever the description changes.
SAP makes extensive use of the SDP session level attributes to
provide a (limited) set of descriptive metadata for the session,
including scheduling and subject information. Quite a bit of this
information is application-specific and is therefore not defined in
the baseline SDPng spec. In particular, IMGs are expected to be used
with more encompassing metadata description formats (such as MPEG-7)
which will carry the respective information so that these need not be
replicated in SDPng itself.
While SAP only supports full SDP descriptions (which are minimal in
size), IMGs allows in addition to the (potentially large)
(collections of) SDPng descriptions and associated metadata to carry
delta information or pointers to contents (URIs). The structured
format of the XML-based SDP goes well with both concepts and allows
to identify subparts of SDPng messages where and perform operations
on them via well-defined means.
5.2 Real-Time-Streaming
Real-time streaming provides an interactive way to offer real-time
media to users. In contrast to the announcement/broadcast based
described in the previous section, where the communication is mostly
unidirectional and interested receivers just "tune" into the
respective media session, with RTSP an interactive session setup
exists. This also informs the media server that there are parties
interested in a particular media stream and provides the opportunity
to the client to obtain the most appropriate variant of a media
stream.
Similar to SAP and IMGs, RTSP has, from its intended usage, a clear
distinction between offering a set of Potential Configurations (by
the server) and choosing one out of these (by the client). There is
no capability negotiation process involved: the server provides a
complete SDPng document describing all Components making up a
presentation and includes detailed codec and transport parameters for
each of there. The client may only pick one out of alternatives for
each of the offered Components but has no further option to negotiate
parameters in depth. Where some additional exchange is necesary --
e.g. for the client's transport addresses and security parameters --,
the respective parameters are no encoded in SDPng; instead,
additional RTSP header fields and parameters are field for this
purpose.
Hence, SDPng is only used to describe alternatives to gain access to
streaming media out of which the client has to choose. No
interaction takes place at the SDPng level.
It should be noted that SAP or IMG-based announcements may also be
used to point users to RTSP servers. In such a case, the
"negotiation" is a two-stage process: the media discovery takes place
using SAP or IMG and leads to the RTSP server. The actual streaming
invocation process then takes place interactively between the RTSP
client and server as described in this section.
C->M: DESCRIBE rtsp://foo/audio-play RTSP/1.0
CSeq: 1
M->C: RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: ...
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng sdpng-base.xsd
http://www.iana.org/sdpng/audio sdpng-audio-pkg.xsd
http://www.iana.org/sdpng/rtp sdpng-rtp-pkg.xsd"
owner="A@example.com" id="98765432" version="1"
>
<cap>
<audio:codec name="avp:pcmu">
<audio:encoding>PCMU</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:gsm">
<audio:encoding>GSM</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
</cap>
<def>
<rtp:udp name="rtp-cfg1" ref="rtpudpip4">
<rtp:ip-addr>192.168.47.11</rtp:ip-addr>
<rtp:rtp-port>51400</rtp:rtp-port>
</rtp:udp>
</def>
<cfg>
<component>
<alt>
<audio:codec ref="avp:pcmu"/>
<rtp:udp ref="rtp-cfg1">
<rtp:pt>0</rtp:pt>
</rtp:udp>
</alt>
<alt>
<audio:codec ref="avp:gsm"/>
<rtp:udp ref="rtp-cfg1">
<rtp:pt>3</rtp:pt>
</rtp:udp>
</alt>
</component>
</cfg>
</sdpng>
C->M: SETUP rtsp://foo/audio-play RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001
M->C: RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001;
server_port=51400-51401
Session: 12345678
To be continued with PLAY and, after the audio track has completed,
finished with TEARDOWN.
5.3 Two-Way Session Setup
The major application of SDP today is its use with the Session
Initiation Protocol (SIP) [RFC3261]. Session descriptions are used
configure the media streams between two parties involved in a
multimedia call.
SIP is used to establish and modify multimedia sessions, and SDPng
may be carried at least in SIP INVITE, ACK and UPDATE messages as
well as in a number of responses. From dealing with legacy SDP (and
its essential non-suitability for capability negotiation), a
particular use and interpretation of SDP has been defined for SIP,
generalized in the offer/answer model documented in RFC 3264.
One of the important flexibilities introduced by SIP's usage of SDP
is that a sender can change dynamically between all codecs that a
receiver has indicated support (and has provided an address) for.
Codec changes are not signaled out-of-band but only indicated by the
payload type within the media stream. From this arises one important
consequence to the conceptual view of a Component within SDPng.
There is no clear distinction between Potential and Actual
Configurations. There need not be a single Actual Configuration
chosen at setup time within the SIP signaling. Instead, a number of
Potential Configurations is signaled in SIP (with all transport
parameters required for carrying media streams) and the Actual
Configuration is only identified by the payload type which is
actually being transmitted at any point in time.
Note that since SDPng does not distinguish between Potential and
Actual Configurations at the syntax, this has no implications on the
SDPng signaling itself but is merely up to interpretation.
SIP relies on an "offer/answer" model for the exchange of capability
and configuration information. Either the caller or the callee sends
an initial session description that is processed by the other side
and returned. For capability negotiation, this means that the
negotiation follows a two-stage-process: The "offerer" sends its
capability description to the receiver. The receiver processes the
offerers capabilities and his own capabilities and generates a result
capability description that is sent back to the offerer. Both sides
now know the commonly supported configurations and can initiate the
media sessions.
Because of this strict "offer/answer" model, the offerer must already
send complete configurations (i.e. include transport addresses) along
with the capability descriptions. The answer must also contain
complete configuration parameters. The following figure shows, how
SDPng content can be used in an INVITE request with a corresponding
200 OK message.
Simple description document with only one alternative:
F1 INVITE A -> B
INVITE sip:B@example.com SIP/2.0
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Contact: <sip:UserA@192.168.1.1>
Content-Type: application/sdpng
Content-Length: 685
<?xml version="1.0" encoding="UTF-8"?>
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng sdpng-base.xsd
http://www.iana.org/sdpng/audio sdpng-audio-pkg.xsd
http://www.iana.org/sdpng/rtp sdpng-rtp-pkg.xsd"
owner="A@example.com" id="98765432" version="1"
>
<cap>
<audio:codec name="avp:pcmu">
<audio:encoding>PCMU</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:gsm">
<audio:encoding>GSM</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
</cap>
<def>
<rtp:udp name="rtp-cfg1" ref="rtpudpip4">
<rtp:ip-addr>192.168.47.11</rtp:ip-addr>
<rtp:rtp-port>51400</rtp:rtp-port>
</rtp:udp>
</def>
<cfg>
<component>
<alt>
<audio:codec ref="avp:pcmu"/>
<rtp:udp ref="rtp-cfg1">
<rtp:pt>0</rtp:pt>
</rtp:udp>
</alt>
<alt>
<audio:codec ref="avp:gsm"/>
<rtp:udp ref="rtp-cfg1">
<rtp:pt>3</rtp:pt>
</rtp:udp>
</alt>
</component>
</cfg>
</sdpng>
==================================================
F2 (100 Trying) B -> A
SIP/2.0 100 Trying
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Content-Length: 0
==================================================
F3 180 Ringing B -> A
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>;tag=987654
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Content-Length: 0
==================================================
F4 200 OK B -> A
SIP/2.0 200 OK
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>;tag=987654
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Contact: <sip:B@192.168.1.2>
Content-Type: application/sdpng
Content-Length: 479
<?xml version="1.0" encoding="UTF-8"?>
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng sdpng-base.xsd
http://www.iana.org/sdpng/audio sdpng-audio-pkg.xsd
http://www.iana.org/sdpng/rtp sdpng-rtp-pkg.xsd"
owner="B@example.com" id="4595647" version="1"
>
<cap>
<audio:codec name="avp:pcmu">
<audio:encoding>PCMU</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:gsm">
<audio:encoding>GSM</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
</cap>
<def>
<rtp:udp name="rtp-cfg1" ref="rtpudpip4">
<rtp:ip-addr>192.168.47.12</rtp:ip-addr>
<rtp:rtp-port>60006</rtp:rtp-port>
</rtp:udp>
</def>
<cfg>
<component>
<alt>
<audio:codec ref="avp:gsm"/>
<rtp:udp ref="rtp-cfg1">
<rtp:pt>3</rtp:pt>
</rtp:udp>
</alt>
</component>
</cfg>
</sdpng>
==================================================
ACK from A to B omitted
In the INVITE message, A sends B a description document that
specifies exactly one component with two alternatives (the PCMU and
GSM audio streams). The alternatives make reference to the
capability section where the two codec types are defined. All
required transport parameters are already contained in the respective
descriptions but they are kept separate from the capability part.
The <def> element contains a definition for the RTP media sessions so
that this needs not be repeated in the configuration of the single
component. Note that the semantics of the component is not
explicitly specified (in an <info> element) but rather implied.
In the 200 OK message, B sends an updated description document to A.
B supports the payload format that A has offered and adds his own
transport parameters to the configuration information, specifying the
endpoint address where B wants to receive media data. In order to
disambiguate its transport configurations from A's, B sets the
attribute "endpoint" to the value "B". The specific value of the
"endpoint" attribute is not important, the only requirements are that
a party that contributes to the session description, must use a
unique name for the endpoint attribute and that a contributing party
must use the same value for the endpoint attributes of all elements
it adds to the session description.
The offer/answer model allows communicating peers to determine a The offer/answer model allows communicating peers to determine a
(common) mode of operation to exchange media streams in a single (common) mode of operation to exchange media streams in a single
round-trip. Basically, the offerer proposes a set of components, round-trip. Basically, the offerer proposes a set of components,
providing one or more alternatives ("potential configurations") for providing one or more alternatives ("potential configurations") for
each of these. From this offer, the answerer learns which components each of these. From this offer, the answerer learns which components
may be used and which configurations are applicable to realize these may be used and which configurations are applicable to realize these
components. The answerer indicates which components it supports components. The answerer indicates which components it supports
(e.g. receiving a offer including audio and video, it may disallow (e.g. receiving a offer including audio and video, it may disallow
the video session and go with an audio-only conversation) and also the video session and go with an audio-only conversation) and also
skipping to change at page 26, line 52 skipping to change at page 36, line 38
defined in RFC 3264 for generating offers and answers apply. The defined in RFC 3264 for generating offers and answers apply. The
following considerations specifically apply when using offer/answer following considerations specifically apply when using offer/answer
with SDPng (instead of SDP) documents: with SDPng (instead of SDP) documents:
o For each component to be used, all necessary parameters MUST be o For each component to be used, all necessary parameters MUST be
given for at least one configuration per component, i.e. transport given for at least one configuration per component, i.e. transport
addresses and payload formats MUST be specified along with the addresses and payload formats MUST be specified along with the
capabilities. capabilities.
o Matching of components is done based upon their identification in o Matching of components is done based upon their identification in
the session part of the SDPng document using predefined the info part of the SDPng document using predefined identifiers
identifiers for certain session types. for certain session types.
For simple sessions, where applications can implicitly derive the For simple sessions, where applications can implicitly derive the
semantics of the the offered components, no such explicit mapping semantics of the the offered components, no such explicit mapping
is necessary. In this case, i.e. if the entire "<info>" element is necessary. In this case, i.e. if the entire "<info>" element
or the respective elements in the "<info>" element are absent, the or the respective elements in the "<info>" element are absent, the
order of appearance in the SDPng document is relevant as it is order of appearance in the SDPng document is relevant as it is
with SDP. with SDP.
o For each component, the answerer performs a capability matching o For each component, the answerer performs a capability matching
process as per then application's requirements process as per then application's requirements
For all components that are acceptable, the answerer determines For all components that are acceptable, the answerer determines
skipping to change at page 28, line 23 skipping to change at page 38, line 9
The considerations of RFC 3264 to simply arriving at symmetric The considerations of RFC 3264 to simply arriving at symmetric
codec use apply. codec use apply.
If a component shall be put on hold, the status attribute of the If a component shall be put on hold, the status attribute of the
component MUST be set to "sendonly", "recvonly", or "inactive", as component MUST be set to "sendonly", "recvonly", or "inactive", as
appropriate. In this case, the status attributes of all the appropriate. In this case, the status attributes of all the
contained configurations that were previously active MUST be set to contained configurations that were previously active MUST be set to
indicate "sendonly", "recvonly", or "inactive", as appropriate. The indicate "sendonly", "recvonly", or "inactive", as appropriate. The
rules from RFC 3264 for putting media streams on hold SHALL apply. rules from RFC 3264 for putting media streams on hold SHALL apply.
5.2 RFC2533 Negotiation 5.4 Multi-Party-Conferencing with Negotiation
SDPng potential configurations can be processed using the RFC 2533
algorithm as defined in [15]. This involves the following steps:
Translating SDPng capability descriptions to RFC 2533 feature set
expressions;
Applying the RFC 2533 feature match algorithm; and
Integrating the resulting feature set expressions into the SDPng
selection of conference configurations.
5.2.1 Translating SDPng to RFC 2533 Expressions
SDPng capability descriptions can be translated to RFC 2533 feature
sets in a straightforward way, because SDPng uses a subset of the
mechanisms provided by RFC 2533 with a different syntax.
Each capability is represented as an XML element with a set of child
elements. We first describe how to translate a single capability
element into a RFC 2533 feature set, and then consider the
combination of multiple capability elements.
Basically, all attributes of an SDPng capability element and its
child elements MUST be transformed to an RFC 2533 expression, whereas
each child element MUST be translated to a feature predicate. The
resulting feature predicates are combined using the '&' (AND)
operator. The name attributes MUST NOT be considered.
Each predicate MUST be encapsulated by brackets ('(', ')'). The value
or value range of each feature element is taken as a feature
predicate value. Each feature element name is directly adopted as a
feature tag, including the namespace name.
The SDPng data types map to RFC 2533 feature types as follows:
Token
A token MUST be directly adopted as an RFC 2533 token.
Token set
A token set MUST be adopted as an RFC 2533 set (a comma-separated
token list inside square brackets, such as
"video:channels=[1,2]").
Number
A single number in a "val" attribute of a feature elements of type
number MUST be adopted as an RFC 2533 number.
Numerical Ranges
A numerical range MUST be transformed to a feature set expression
with two feature predicates that are combined using the "&" (AND)
operator. The first predicate specifies the lower limit and the
second predicate specified the upper limit.
For example, the element <bitrate min="64" max="128"/> would be
transformed to the following feature set:
(& (bitrate>=64) (bitrate<=128))
A numerical range without a lower limit MUST be transformed to a
corresponding predicate with a '<=' operator and a numerical range
without a upper limit MUST be transformed to a corresponding
predicate with a '>=' operator.
For example, the element <bitrate max="128"/> would be transformed
to the following feature set:
(bitrate<=128)
The following sample SDPng potential configuration would be
transformed as follows:
Original SDPng expression:
<video:codec name="h263+-enhanced">
<video:resolution>QCIF</video:resolution>
<video:frame-rate max="24"/>
<h263plus:A>foo</h263plus:A>
<h263plus:B>bar</h263plus:B>
</video:codec>
Transforming feature elements to feature predicates:
(& (video:resolution=QCIF) (video:frame-rate<=24)
(h263plus:A=foo) (h263plus:B=bar))
RFC 2533 uses the syntax rules of RFC 2506 [17] for feature tags.
Note that in example above, the namespace name is not used for
feature tags, instead we use the namespace prefix (for abbreviation).
It should be noted, that implementations MUST replace the namespace
prefix of SDPng elements with the namespace name when performing the
translation to an RFC 2533 expression. The following figure depicts
an corresponding expression for the previous example:
(& (http://www.iana.org/sdpng/video:resolution=QCIF)
(http://www.iana.org/sdpng/video:frame-rate<=24)
(http://www.example.com/h263plus:A=foo)
(http://www.example.com/h263plus:B=bar))
For this example, we assume that the prefix "video" has been assigned
to the namespace name "http://www.iana.org/sdpng/video" and that the
prefix "h263plus" has been assigned to the namespace name "http://
www.example.com/h263plus". In the following examples, we will use the
abbreviated form (using the namespace prefix only).
Multiple independent capability elements MUST each be transformed
using the specification above and then combined into a single RFC
2533 feature set by connecting the individual feature sets using the
'|' (OR) operator. For example, the following sample SDPng potential
configuration would be transformed as follows:
<audio:codec name="avp:pcmu">
<audio:encoding>PCMU</audio:encoding>
<audio:channels>1 2</audio:channels>
<audio:sampling>8000 16000</audio:sampling>
</audio:codec>
<video:codec name="h263+-enhanced">
<video:resolution>QCIF</video:resolution>
<video:frame-rate max="24"/>
<h263plus:A>foo</h263plus:A>
<h263plus:B>bar</h263plus:B>
</video:codec>
Transforming feature elements to feature predicates:
(|
(& (video:encoding=PCMU) (video:channels=[1,2])
(video:sampling=[8000,16000]))
(& (video:resolution=QCIF) (video:frame-rate<=24)
(h263plus:A=foo) (h263plus:B=bar))
)
5.2.2 Applying RFC 2533 Canonicalization
After transforming different SDPng capability descriptions from
different participants into their equivalent RFC 2533 form, the
following steps MUST be performed to calculate the common subset of
capabilities:
1. The individual feature sets MUST be combined into a single
expression by creating a conjunction of the feature sets, i.e.,
the feature sets MUST be connected by the '&' (AND) operator.
2. The resulting expression MUST be reduced to disjunctive normal
form, i.e., the canonical from as specified by RFC 2533 [15].
5.2.3 Integrating Feature Sets into SDPng
A feature set that has been created by combining multiple independent
feature sets and by reducing the result for canonical form does not
indicate directly which of the capability elements belong to the
common subset of capabilities. SDPng uses the following approach:
After a "collapsing process" that has determined the commonly
supported capabilities, the resulting RFC 2533 expression is compared
to the original SDPng capability description. For this purpose, each
SDPng capability element is transformed to an RFC 2533 expression and
matched against the negotiation result (by constructing a conjunction
of the two feature sets). If the resulting canonical disjunctive form
is non-empty, the respective capability element represents a commonly
supported capability and can be adopted for the conference
configuration.
A future version of this document will specify how to adopt
individual values from the negotiation result for the SDPng
capability element.
The following steps MUST be performed to determine whether an
individual capability element (e.g., from one of the contributing
SDPng capability descriptions) belongs to the result feature set.
Let R be the result feature set obtained from the canonicalization as
specified in Section 5.2.2.
1. For each capability element, generate the equivalent RFC 2533
feature set by applying the steps specified in Section 5.2.1. Let
C be the resulting feature set.
2. Combine R and C into a single feature set by building a
conjunction of the two feature sets (& R C). Let the result be
the feature set T.
3. Reduce T to disjunctive normal form by applying the
canonicalization as defined in RFC 2533 [15].
4. If the remaining disjunction is non-empty, the constraints
specified by capability element (the origin of C) can be
satisfied by R, i.e., C represents a commonly supported
capability.
5.2.4 Processing Negotiation Results
The capability negotiation results in an updated list of capability
elements of the SDPng "cap" element. The capability elements describe
the commonly supported capabilities. Capabilities that are not
supported by all end-systems have been removed.
Definition elements (inside the SDPng "def" element) and The indipendent capability collapsing properties of SDPng allow to
configuration descriptions (inside the SDPng "alt" element) that calculate the "intersection" of any number of SDPng documents
reference capability elements that have been removed after the independently and easily derive a common subset. Details are TBD in a
negotiation process, MUST be removed as well. Configuration separate document.
description (inside the SDPng "alt" element) that reference
non-existing definition elements (inside the SDPng "def" element")
MUST also be removed.
6. IANA Considerations 6. IANA Considerations
The IANA should set up a registry for XML namespaces for SDPng and The IANA should set up a registry for XML namespaces for SDPng and
SDPng package definitions. SDPng package definitions.
The SDP parameter registry (http://www.iana.org/assignments/ The SDP parameter registry (http://www.iana.org/assignments/
sdp-parameters) should be converted to SDPng package definitions. sdp-parameters) should be converted to SDPng package definitions.
7. Open Issues 7. Open Issues
Meta-Information for SDPng description (author, version etc.)?
Revise usage of terminology (potential configuration, actual Revise usage of terminology (potential configuration, actual
configuration) configuration)
Do we need an explicit mechanism to declare the used packages? Do we need an explicit mechanism to declare the used packages?
E.g., <pkg ref="http://www.iana.org/sdpng/audio"/> E.g., <pkg ref="http://www.iana.org/sdpng/audio"/>
Data model for audio package: sampling-rate vs. RTP clock rate Data model for audio package: sampling-rate vs. RTP clock rate
Bib. references: distinguish normative and informational Bib. references: distinguish normative and informational
skipping to change at page 38, line 18 skipping to change at page 44, line 18
The following DTD specifies the SDPng base syntax. DTDs are not The following DTD specifies the SDPng base syntax. DTDs are not
XML-Namespace aware, therefore the following DTD is for informational XML-Namespace aware, therefore the following DTD is for informational
purposes only. Moreover, the content models for the element types purposes only. Moreover, the content models for the element types
"cap" and "def" have to be empty in this DTD as the specific element "cap" and "def" have to be empty in this DTD as the specific element
types for the allowed child elements are not defined by the base types for the allowed child elements are not defined by the base
specification but by independent package definitions. Common specification but by independent package definitions. Common
requirements for these element types such as the "name" attribute requirements for these element types such as the "name" attribute
cannot be expressed with XML DTDs. cannot be expressed with XML DTDs.
<!ELEMENT sdpng (cap, def?, cfg, constraints?, info?)> <!ELEMENT sdpng (cap?, def?, cfg, constraints?, info?)>
<!ELEMENT cap ANY> <!ELEMENT cap ANY>
<!ELEMENT def ANY> <!ELEMENT def ANY>
<!ELEMENT cfg (component+)> <!ELEMENT cfg (component+)>
<!ELEMENT component (alt+)> <!ELEMENT component (alt+)>
<!ATTLIST component <!ATTLIST component
name CDATA #REQUIRED name CDATA #REQUIRED
media CDATA #IMPLIED media CDATA #IMPLIED
status CDATA #IMPLIED
> >
<!ELEMENT alt ANY> <!ELEMENT alt ANY>
<!ATTLIST alt <!ATTLIST alt
name CDATA #REQUIRED name CDATA #REQUIRED
status CDATA #IMPLIED
>
<!ELEMENT constraints ANY>
<!ELEMENT info (part+)>
<!ELEMENT part ANY>
<!ATTLIST part
type CDATA #REQUIRED
ref CDATA #IMPLIED
> >
A.2 SDPng XML-Schema Specification A.2 SDPng XML-Schema Specification
<xsd:schema <xsd:schema
xmlns:sdpng="http://www.iana.org/sdpng" xmlns:sdpng="http://www.iana.org/sdpng"
targetNamespace="http://www.iana.org/sdpng" targetNamespace="http://www.iana.org/sdpng"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified" attributeFormDefault="unqualified"
skipping to change at page 41, line 41 skipping to change at page 48, line 12
<!-- The base element for constraint element --> <!-- The base element for constraint element -->
<!-- FIXME: substitutionGroup? --> <!-- FIXME: substitutionGroup? -->
<xsd:element name="constraint" type="sdpng:Constraint" abstract="true"> <xsd:element name="constraint" type="sdpng:Constraint" abstract="true">
</xsd:element> </xsd:element>
<!-- Base type for information elements --> <!-- Base type for information elements -->
<xsd:complexType name="Information" abstract="true"> <xsd:complexType name="Information" abstract="true">
<xsd:attribute name="name" type="xsd:string" use="optional"/> <xsd:attribute name="type" type="xsd:string"/>
<xsd:attribute name="ref" type="xsd:string" use="optional"/>
</xsd:complexType> </xsd:complexType>
<!-- The base element for constraint element --> <!-- The nformation part element -->
<!-- FIXME: substitutionGroup? -->
<xsd:element name="information" type="sdpng:Information" abstract="true"> <xsd:element name="part" type="sdpng:Information" abstract="true">
</xsd:element> </xsd:element>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- <!--
SDPng document structure SDPng document structure
--> -->
<xsd:element name="sdpng"> <xsd:element name="sdpng">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:cap"/> <xsd:element ref="sdpng:cap" minOccurs="0"/>
<xsd:element ref="sdpng:def" minOccurs="0"/> <xsd:element ref="sdpng:def" minOccurs="0"/>
<xsd:element ref="sdpng:cfg"/> <xsd:element ref="sdpng:cfg"/>
<xsd:element ref="sdpng:constraints" minOccurs="0"/> <xsd:element ref="sdpng:constraints" minOccurs="0"/>
<xsd:element ref="sdpng:info" minOccurs="0"/> <xsd:element ref="sdpng:info" minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<!-- The base element for capability and definition elements --> <!-- The base element for capability and definition elements -->
<!-- FIXME: substitutionGroup? --> <!-- FIXME: substitutionGroup? -->
<xsd:element name="definition" type="sdpng:Definition" abstract="true"> <xsd:element name="definition" type="sdpng:Definition" abstract="true">
</xsd:element> </xsd:element>
<!-- The mandatory "cap" element --> <!-- The optional "cap" element -->
<xsd:element name="cap"> <xsd:element name="cap">
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/> <xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<!-- The optional "def" element --> <!-- The optional "def" element -->
skipping to change at page 43, line 24 skipping to change at page 49, line 38
</xsd:element> </xsd:element>
<!-- The "component" element --> <!-- The "component" element -->
<xsd:element name="component"> <xsd:element name="component">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:alt" minOccurs="1" maxOccurs="unbounded"/> <xsd:element ref="sdpng:alt" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="name" type="xsd:string"/>
<xsd:attribute name="media" type="xsd:string"/> <xsd:attribute name="media" type="xsd:string" use="optional"/>
<xsd:attribute name="status" type="xsd:string" use="optional"/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<xsd:element name="alt"> <xsd:element name="alt">
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/> <xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="name" type="xsd:string"/>
<xsd:attribute name="status" type="xsd:string" use="optional"/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<!-- The optional "constraints" element --> <!-- The optional "constraints" element -->
<xsd:element name="constraints"> <xsd:element name="constraints">
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:constraint" maxOccurs="unbounded"/> <xsd:element ref="sdpng:constraint" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
skipping to change at page 44, line 4 skipping to change at page 50, line 19
<xsd:element name="constraints"> <xsd:element name="constraints">
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:constraint" maxOccurs="unbounded"/> <xsd:element ref="sdpng:constraint" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<!-- The optional "info" element --> <!-- The optional "info" element -->
<xsd:element name="info"> <xsd:element name="info">
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:information" maxOccurs="unbounded"/> <xsd:element ref="sdpng:part" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:schema> </xsd:schema>
Appendix B. Sample Package Definitions Appendix B. Sample Package Definitions
B.1 Sample RTP Package Definition B.1 Sample RTP Package Definition
skipping to change at page 52, line 5 skipping to change at page 58, line 5
<alt> <alt>
<audio:codec ref="avp:pcmu"/> <audio:codec ref="avp:pcmu"/>
<rtp:udp ref="rtp-cfg1"> <rtp:udp ref="rtp-cfg1">
<rtp:pt>0</rtp:pt> <rtp:pt>0</rtp:pt>
</rtp:udp> </rtp:udp>
</alt> </alt>
</component> </component>
</cfg> </cfg>
</sdpng> </sdpng>
Appendix D. Use of SDPng in Conjunction with other IETF Signaling Appendix D. Change History
Protocols
This appendix is included temporarily and for informational purposes
only. Ultimately, it is up to each existing and evolving application
protocol to specify its use of SDPng.
The SDPng model provides the notion of Components to indicate the
intended types of collaboration between the users in e.g. a
teleconferencing scenario.
Three different abstractions are defined that are used for describing
the properties of a specific Component:
o a Capability refers to the fact that one of the involved parties
supports one particular way of exchanging media -- defined in
terms of transport, codec, and other parameters -- as part of the
media session.
o a Potential Configuration denotes a set of matching Capabilities
from all those involved parties that may be used for one
particular Component.
o an Actual Configuration indicates the Potential Configuration(s)
and its associated media session parameters which was/were chosen
by the involved parties to instantiate a certain Component.
As mentioned before, this abstract notion of the interactions between
a number of communicating systems needs to be mapped to the
application scenarios of SDPng in conjunction with the various IETF
signaling protocols, including (but not limited to) SAP, SIP, RTSP,
and MEGACO.
In general, this section provides recommendations and possible
scenarios for the use of SDPng within specific protocols and
applications. Is does not specify normative requirements.
D.1 The Session Announcement Protocol (SAP)
SAP is used to disseminate a previously created (and typically fixed)
session description to a potentially large audience. An interested
member of the audience will use the SDPng description contained in
SAP to join the announced media sessions.
This means that a SAP announcement contains the Actual Configurations
of all Components that are part of the overall teleconference or
broadcast.
A SAP announcement may contain multiple Actual Configurations for the
same Component. In this case, the "same" (i.e. semantically
equivalent) media data from one configuration must be available from
each of the Actual Configurations.
Each receiver of a SAP announcement with SDPng compares its locally
stored Capabilities to realize a certain Component against the Actual
Configurations contained in the announcement. If the intersection
yields one or more Potential Configurations for the receiver, it
chooses the one it sees fit best. If the intersection is empty, the
receiver cannot participate in the announced session.
SAP may be substituted by HTTP (in the general case, at least), SMTP,
NNTP, or other IETF protocols suitable for conveying a media
description from one entity to one or more other without the intend
for further negotiation of the session parameters.
SAP makes extensive use of the SDP session level attributes to
provide a (limited) set of descriptive metadata for the session,
including scheduling and subject information. Quite a bit of this
information is application-specific and is therefore not defined in
the baseline SDPng spec.
D.2 Session Initiation Protocol (SIP)
SIP is used to establish and modify multimedia sessions, and SDPng
may be carried at least in SIP INVITE, ACK and UPDATE messages as
well as in a number of responses. From dealing with legacy SDP (and
its essential non-suitability for capability negotiation), a
particular use and interpretation of SDP has been defined for SIP,
generalized in the offer/answer model documented in RFC 3264.
One of the important flexibilities introduced by SIP's usage of SDP
is that a sender can change dynamically between all codecs that a
receiver has indicated support (and has provided an address) for.
Codec changes are not signaled out-of-band but only indicated by the
payload type within the media stream. From this arises one important
consequence to the conceptual view of a Component within SDPng.
There is no clear distinction between Potential and Actual
Configurations. There need not be a single Actual Configuration
chosen at setup time within the SIP signaling. Instead, a number of
Potential Configurations is signaled in SIP (with all transport
parameters required for carrying media streams) and the Actual
Configuration is only identified by the payload type which is
actually being transmitted at any point in time.
Note that since SDPng does not distinguish between Potential and
Actual Configurations at the syntax, this has no implications on the
SDPng signaling itself.
SIP relies on an "offer/answer" model for the exchange of capability
and configuration information. Either the caller or the callee sends
an initial session description that is processed by the other side
and returned. For capability negotiation, this means that the
negotiation follows a two-stage-process: The "offerer" sends its
capability description to the receiver. The receiver processes the
offerers capabilities and his own capabilities and generates a result
capability description that is sent back to the offerer. Both sides
now know the commonly supported configurations and can initiate the
media sessions.
Because of this strict "offer/answer" model, the offerer must already
send complete configurations (i.e. include transport addresses) along
with the capability descriptions. The answer must also contain
complete configuration parameters. The following figure shows, how
SDPng content can be used in an INVITE request with a correspong 200
OK message.
Simple description document with only one alternative:
F1 INVITE A -> B
INVITE sip:B@example.com SIP/2.0
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Contact: <sip:UserA@192.168.1.1>
Content-Type: application/sdpng
Content-Length: 685
<?xml version="1.0" encoding="UTF-8"?>
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng sdpng-base.xsd
http://www.iana.org/sdpng/audio sdpng-audio-pkg.xsd
http://www.iana.org/sdpng/rtp sdpng-rtp-pkg.xsd"
owner="A@example.com" id="98765432" version="1"
>
<cap>
<audio:codec name="avp:pcmu">
<audio:encoding>PCMU</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:gsm">
<audio:encoding>GSM</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
</cap>
<def>
<rtp:udp name="rtp-cfg1" ref="rtpudpip4">
<rtp:ip-addr>192.168.47.11</rtp:ip-addr>
<rtp:rtp-port>51400</rtp:rtp-port>
</rtp:udp>
</def>
<cfg>
<component>
<alt>
<audio:codec ref="avp:pcmu"/>
<rtp:udp ref="rtp-cfg1">
<rtp:pt>0</rtp:pt>
</rtp:udp>
</alt>
<alt>
<audio:codec ref="avp:gsm"/>
<rtp:udp ref="rtp-cfg1">
<rtp:pt>3</rtp:pt>
</rtp:udp>
</alt>
</component>
</cfg>
</sdpng>
==================================================
F2 (100 Trying) B -> A
SIP/2.0 100 Trying
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Content-Length: 0
==================================================
F3 180 Ringing B -> A
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>;tag=987654
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Content-Length: 0
==================================================
F4 200 OK B -> A
SIP/2.0 200 OK
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>;tag=987654
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Contact: <sip:B@192.168.1.2>
Content-Type: application/sdpng
Content-Length: 479
<?xml version="1.0" encoding="UTF-8"?>
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng sdpng-base.xsd
http://www.iana.org/sdpng/audio sdpng-audio-pkg.xsd
http://www.iana.org/sdpng/rtp sdpng-rtp-pkg.xsd"
owner="B@example.com" id="4595647" version="1"
>
<cap>
<audio:codec name="avp:pcmu">
<audio:encoding>PCMU</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:gsm">
<audio:encoding>GSM</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
</cap>
<def>
<rtp:udp name="rtp-cfg1" ref="rtpudpip4">
<rtp:ip-addr>192.168.47.12</rtp:ip-addr>
<rtp:rtp-port>60006</rtp:rtp-port>
</rtp:udp>
</def>
<cfg>
<component>
<alt>
<audio:codec ref="avp:gsm"/>
<rtp:udp ref="rtp-cfg1">
<rtp:pt>3</rtp:pt>
</rtp:udp>
</alt>
</component>
</cfg>
</sdpng>
==================================================
ACK from A to B omitted
In the INVITE message, A sends B a description document that
specifies exactly one component with two alternatives (the PCMU and
GSM audio streams). The alternatives make reference to the
capability section where the two codec types are defined. All
required transport parameters all already contained in the respective
descriptions. The <def> element contains a definition for the RTP
media sessions so that this needs not be repeated in the
configuration of the single component. Note that the semantics of
the component is not explicitly specified (in an <info> element) but
rather implied.
In the 200 OK message, B sends an updated description document to A.
B supports the payload format that A has offered and adds his own
transport parameters to the configuration information, specifying the
endpoint address where B wants to receive media data. In order to
disambiguate its transport configurations from A's, B sets the
attribute "endpoint" to the value "B". The specific value of the
"endpoint" attribute is not important, the only requirements are that
a party that contributes to the session description, must use a
unique name for the endpoint attribute and that a contributing party
must use the same value for the endpoint attributes of all elements
it adds to the session description.
D.3 Real-Time Streaming Protocol (RTSP)
In contrast to SIP, RTSP has, from its intended usage, a clear
distinction between offering a set of Potential Configurations (by
the server) and choosing one out of these (by the client). However,
there is no capability negotiation process involved: the server
provides a complete SDPng document describing all Components making
up a presentation and includes detailed codec and transport
parameters for each of there. The client may only pick one out of
alternatives for each of the offered Components but has no further
option to negotiate parameters in depth. Where some additional
exchange is necesary -- e.g. for the client's transport addresses and
security parameters --, the respective parameters are no encoded in
SDPng; instead, additional RTSP header fields and parameters are
field for this purpose.
Hence, SDPng is only used to describe alternatives to gain access to
streaming media out of which the client has to choose. No
interaction takes place at the SDPng level.
C->M: DESCRIBE rtsp://foo/audio-play RTSP/1.0
CSeq: 1
M->C: RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: ...
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng sdpng-base.xsd
http://www.iana.org/sdpng/audio sdpng-audio-pkg.xsd
http://www.iana.org/sdpng/rtp sdpng-rtp-pkg.xsd"
owner="A@example.com" id="98765432" version="1" draft-ietf-mmusic-sdpng-08.txt
>
<cap> * Changed introduction: emphasis on non-negotiation scenarios
<audio:codec name="avp:pcmu"> (broadcast etc.), describe main concepts
<audio:encoding>PCMU</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:gsm">
<audio:encoding>GSM</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
</cap>
<def>
<rtp:udp name="rtp-cfg1" ref="rtpudpip4">
<rtp:ip-addr>192.168.47.11</rtp:ip-addr>
<rtp:rtp-port>51400</rtp:rtp-port>
</rtp:udp>
</def>
<cfg>
<component>
<alt>
<audio:codec ref="avp:pcmu"/>
<rtp:udp ref="rtp-cfg1">
<rtp:pt>0</rtp:pt>
</rtp:udp>
</alt>
<alt>
<audio:codec ref="avp:gsm"/>
<rtp:udp ref="rtp-cfg1">
<rtp:pt>3</rtp:pt>
</rtp:udp>
</alt>
</component>
</cfg>
</sdpng>
C->M: SETUP rtsp://foo/audio-play RTSP/1.0 * element "cap" is now OPTIONAL.
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001
M->C: RTSP/1.0 200 OK * new "status" attribute for "component" element type
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001;
server_port=51400-51401
Session: 12345678
To be continued with PLAY and, after the audio track has completed, * new "part" element for "info" element (meta-information)
finished with TEARDOWN.
D.4 Media Gateway Control Protocol (MEGACOP) * Removed section "Specification of the Capability Negotiation"
The MEGACO architecture also follows the SDPng model of a clear * Removed appendix "Use of SDPng in Conjunction with other IETF
separation between Potential and Actual Configurations. Upon startup, Signaling Protocols"
a Media Gateway (MG) will "register" with its Media Gateway
Controller (MGC) and the latter will audit the MG for its
Capabilities. Those will be provided as Potential Configurations,
possibly with extensive Constraints specifications. Whenever a media
path needs to be set up by the MGC between two MGs or an MG needs to
be reconfigured internally, the MGC will use (updated) Actual
Configurations.
Details and examples to be defined in a separate document. * Added section "Usage of SDPng in Different Application
Scenarios"
Appendix E. Change History * Updated DTD and XML-Schema-Definition wrt to afore-mentioned
changes
draft-ietf-mmusic-sdpng-07.txt draft-ietf-mmusic-sdpng-07.txt
* New document structure: * New document structure:
1. Intro 1. Intro
2. Terminology and System Model 2. Terminology and System Model
3. Overview 3. Overview
skipping to change at page 62, line 11 skipping to change at page 59, line 31
2. 2.
* Changed "profile" to "package". * Changed "profile" to "package".
* Added a list of terms with explanation at the end of Section 2. * Added a list of terms with explanation at the end of Section 2.
* Removed audio and RTP packages from appendix. * Removed audio and RTP packages from appendix.
* Added a section "Syntax Definition". * Added a section "Syntax Definition".
* Added Section 5 ("Specification of the Capability * Added section "Specification of the Capability Negotiation".
Negotiation").
draft-ietf-mmusic-sdpng-05.txt draft-ietf-mmusic-sdpng-05.txt
* Moved audio and RTP packages to appendix. * Moved audio and RTP packages to appendix.
* Moved section "Use of SDPng in conjunction with other IETF * Moved section "Use of SDPng in conjunction with other IETF
Signaling Protocols" to appendix. Signaling Protocols" to appendix.
* Changed mechanism for references to definitions: Definition * Changed mechanism for references to definitions: Definition
elements provide an attribute "ref" that can be used to elements provide an attribute "ref" that can be used to
skipping to change at page 64, line 4 skipping to change at page 61, line 4
* renamed section "Syntax Proposal" to "Syntax Definition * renamed section "Syntax Proposal" to "Syntax Definition
Mechanisms". More text on DTD vs. schema. Edited the example Mechanisms". More text on DTD vs. schema. Edited the example
description. description.
* updated example definitions in section "Definitions" and * updated example definitions in section "Definitions" and
"Components & Configurations" "Components & Configurations"
* section "Session Attributes" replaces section "Session" * section "Session Attributes" replaces section "Session"
* new appendix on audio codec definitions * new appendix on audio codec definitions
IPR Notice
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
This document and translations of it may be copied and furnished to except as set forth therein, the authors retain all their rights.
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein are provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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