draft-ietf-mmusic-sdpng-06.txt   draft-ietf-mmusic-sdpng-07.txt 
Network Working Group Kutscher mmusic Kutscher
Internet-Draft Ott Internet-Draft Ott
Expires: September 1, 2003 Bormann Expires: April 26, 2004 Bormann
TZI, Universitaet Bremen TZI, Universitaet Bremen
March 03, 2003 October 27, 2003
Session Description and Capability Negotiation Session Description and Capability Negotiation
draft-ietf-mmusic-sdpng-06.txt draft-ietf-mmusic-sdpng-07.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
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 The list of current Internet-Drafts can be accessed at http://
http://www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 1, 2003. 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 (2003). 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 end- with respect to configuration parameters and capabilities of
systems. end-systems.
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.9 $ $Revision: 6.18 $
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and System Model . . . . . . . . . . . . . . . . 5 2. Terminology and System Model . . . . . . . . . . . . . . . . 6
3. Capability Negotiation: Overview and Requirements . . . . . 9 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Outline of the Negotiation Process . . . . . . . . . . . . . 9 3.1 Outline of the Negotiation Process . . . . . . . . . . . . . 10
3.2 The Negotiation Process . . . . . . . . . . . . . . . . . . 11 3.2 Capability Types . . . . . . . . . . . . . . . . . . . . . . 12
4. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3 Application-specific Vocabulary . . . . . . . . . . . . . . 14
4.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . . 12 4. SDPng Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1 Potential Configurations . . . . . . . . . . . . . . . . . . 13 4.1 SDPng Base Syntax . . . . . . . . . . . . . . . . . . . . . 15
4.1.2 Actual Configurations . . . . . . . . . . . . . . . . . . . 15 4.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.1 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.4 Meta Information . . . . . . . . . . . . . . . . . . . . . . 18 4.2.2 Token Sets . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Syntax Definition Mechanisms . . . . . . . . . . . . . . . . 18 4.2.3 Numerical Values . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Referencing Definitions . . . . . . . . . . . . . . . . . . 20 4.2.4 Numerical Ranges . . . . . . . . . . . . . . . . . . . . . . 18
4.4 External Definition Packages . . . . . . . . . . . . . . . . 20 4.2.5 Sample SDPng cap Element . . . . . . . . . . . . . . . . . . 19
4.4.1 Package Definitions . . . . . . . . . . . . . . . . . . . . 20 4.2.6 Referencing Capability Elements . . . . . . . . . . . . . . 20
4.4.2 Library Definitions . . . . . . . . . . . . . . . . . . . . 21 4.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.4 Configurations . . . . . . . . . . . . . . . . . . . . . . . 22
5. Syntax Definition . . . . . . . . . . . . . . . . . . . . . 23 4.5 Constraints . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1 Potential Configurations . . . . . . . . . . . . . . . . . . 23 4.6 Session Information . . . . . . . . . . . . . . . . . . . . 24
6. Specification of the Capability Negotiation . . . . . . . . 26 4.7 Summary of SDPng XML-Syntax . . . . . . . . . . . . . . . . 24
6.1 Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 26 5. Specification of the Capability Negotiation . . . . . . . . 26
6.2 RFC2533 Negotiation . . . . . . . . . . . . . . . . . . . . 27 5.1 Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.1 Translating SDPng to RFC 2533 Expressions . . . . . . . . . 27 5.2 RFC2533 Negotiation . . . . . . . . . . . . . . . . . . . . 28
6.2.2 Applying RFC 2533 Canonicalization . . . . . . . . . . . . . 29 5.2.1 Translating SDPng to RFC 2533 Expressions . . . . . . . . . 28
6.2.3 Integrating Feature Sets into SDPng . . . . . . . . . . . . 30 5.2.2 Applying RFC 2533 Canonicalization . . . . . . . . . . . . . 31
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2.3 Integrating Feature Sets into SDPng . . . . . . . . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 5.2.4 Processing Negotiation Results . . . . . . . . . . . . . . . 32
References . . . . . . . . . . . . . . . . . . . . . . . . . 33 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 34
A. Use of SDPng in conjunction with other IETF Signaling 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 36 References . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.1 The Session Announcement Protocol (SAP) . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37
A.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . . 37 A. Formal Syntax Specifications . . . . . . . . . . . . . . . . 38
A.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . . 44 A.1 SDPng Base DTD . . . . . . . . . . . . . . . . . . . . . . . 38
A.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . . 44 A.2 SDPng XML-Schema Specification . . . . . . . . . . . . . . . 38
B. Change History . . . . . . . . . . . . . . . . . . . . . . . 45 B. Sample Package Definitions . . . . . . . . . . . . . . . . . 45
Full Copyright Statement . . . . . . . . . . . . . . . . . . 47 B.1 Sample RTP Package Definition . . . . . . . . . . . . . . . 45
B.2 Sample Audio Package Definition . . . . . . . . . . . . . . 46
B.3 Sample Video Package Definition . . . . . . . . . . . . . . 46
C. Sample SDPng Description . . . . . . . . . . . . . . . . . . 48
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
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 some applications,
e.g. for loosely coupled conferences or for broadcast scenarios, it e.g. for loosely coupled conferences or for broadcast scenarios, it
may be sufficient to simply have session parameters be fixed by the may be sufficient to simply have session parameters be fixed by the
initiator of a conference. In such a scenario no negotiation is initiator of a conference. In such a scenario no negotiation is
skipping to change at page 3, line 27 skipping to change at page 4, line 27
This approach is applicable for conferences that are announced some This approach is applicable for conferences that are announced some
time ahead of the actual start date of the conference. Potential time ahead of the actual start date of the conference. Potential
participants can check the availability of media tools in advance and participants can check the availability of media tools in advance and
tools such as session directories can configure media tools upon tools such as session directories can configure media tools upon
startup. This procedure however fails to work for conferences startup. This procedure however fails to work for conferences
initiated spontaneously including Internet phone calls or ad-hoc initiated spontaneously including Internet phone calls or ad-hoc
multiparty conferences. Fixed settings for parameters such as media 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 end- fixed audio encoding that is not available at the callee's
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 closed conferences) or maybe (potentially) even
repeatedly every time a new participant joins an active conference. repeatedly every time a new participant joins an active conference.
The latter approach may not be appropriate for every type of The latter approach may not be appropriate for every type of
conference without applying certain policies: For conferences with conference without applying certain policies: For conferences with
TV-broadcast or lecture characteristics (one main active source) it TV-broadcast or lecture characteristics (one main active source) it
is usually not desired to re-negotiate parameters every time a new is usually not desired to re-negotiate parameters every time a new
participant with an exotic configuration joins because it may participant with an exotic configuration joins because it may
skipping to change at page 4, line 20 skipping to change at page 5, line 20
designed for). designed for).
A distinction between these two "sets of semantics" is only made A distinction between these two "sets of semantics" is only made
implicitly. implicitly.
This document is based upon a set of requirements specified in a This document is based upon a set of requirements specified in a
companion document [1]. In the following, we first introduce a model companion document [1]. In the following, we first introduce a model
for session description and capability negotiation as well as the for session description and capability negotiation as well as the
basic terms used throughout this specification (Section 2). In basic terms used throughout this specification (Section 2). In
Section 3, we provide an overview of options for capability Section 3, we provide an overview of options for capability
negotiation. Next, we outline the concept for the concepts negotiation. Next, we outline the concept for the concepts underlying
underlying SDPng and introduce the syntactical components step by SDPng and introduce the syntactical components step by step in
step in Section 4. Section 4.
Appendix B lists the change history. Appendix A provide formal specifications of SDPng such as XML DTD and
Schema definitions, Appendix D describes the usage of SDPng in
conjunction with IETF control protocol for multimedia communication
and Appendix E 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 replayed, etc. with this particular device. We term features enabled
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 (e.g. G.711 and G.723.1 but not GSM); and CPU processing power and
and quality of implementation may constrain the possible video quality of implementation may constrain the possible video
encoding algorithms. 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.
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.
skipping to change at page 5, line 39 skipping to change at page 6, line 39
technical and political constraints, different configurations can be technical and political 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 Mbone. This can be achieved either by a video camera capturing the
the image and transmitting a video stream via some video tool or image and transmitting a video stream via some video tool or by
by loading a copy of the slides into a distributed electronic loading a copy of the slides into a distributed electronic
white-board. For each of these cases, additional parameters may white-board. For each of these cases, additional parameters may
exist, variations of which lead to additional configurations (see exist, variations of which lead to additional configurations (see
below). below).
Two configurations are considered different regardless of whether Two configurations are considered different regardless of whether
they employ entirely different mechanisms and protocols (as in the they employ entirely different mechanisms and protocols (as in the
previous example) or they choose the same and differ only in a single previous example) or they choose the same and differ only in a single
parameter. parameter.
Example: In case of video transmission, a JPEG-based still image Example: In case of video transmission, a JPEG-based still image
skipping to change at page 6, line 18 skipping to change at page 7, line 18
Each component's configurations are limited by the participating Each component's configurations are limited by the participating
system's capabilities. In addition, the intended use of a component system's capabilities. In addition, the intended use of a component
may constrain the possible configurations further to a subset may constrain the possible configurations further to a subset
suitable for the particular component's purpose. suitable for the particular component's purpose.
Example: In a system for highly interactive audio communication Example: In a system for highly interactive audio communication
the component responsible for audio may decide not to use the the component responsible for audio may decide not to use the
available G.723.1 audio codec to avoid the additional latency but available G.723.1 audio codec to avoid the additional latency but
only use G.711. This would be reflected in this component only only use G.711. This would be reflected in this component only
showing configurations based upon G.711. Still, multiple showing configurations based upon G.711. Still, multiple
configurations are possible, e.g. depending on the use of A-law configurations are possible, e.g. depending on the use of A-law or
or u-Law, packetization and redundancy parameters, etc. u-Law, packetization and redundancy parameters, etc.
In modeling multimedia sessions, we distinguish two types of In modeling multimedia sessions, we distinguish two types of
configurations: configurations:
o potential configurations o potential configurations
(a set of any number of configurations per component) indicating a (a set of any number of configurations per component) indicating a
system's functional capabilities as constrained by the intended system's functional capabilities as constrained by the intended
use of the various components; use of the various components;
o actual configurations o actual configurations
(exactly one per instance of a component) reflecting the mode of (exactly one per instance of a component) reflecting the mode of
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 component may indicate support for JPEG, H.261/CIF, and H.261/
H.261/QCIF. A particular instantiation for a video conference may QCIF. A particular instantiation for a video conference may use
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 (streaming or conference) consists of one or
more conference components for multimedia "interaction". more conference components for multimedia "interaction".
o A component describes a particular type of interaction (e.g. o A component describes a particular type of interaction (e.g. audio
audio conversation, slide presentation) that can be realized by conversation, slide presentation) that can be realized by means of
means of different applications (possibly using different different applications (possibly using different protocols).
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
are supported by an end-system. are supported by an end-system.
* 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 potential configurations, i.e. a decision how to realize a
skipping to change at page 7, line 33 skipping to change at page 8, line 33
2. to select one of this shared set of common potential 2. to select one of this shared set of common potential
configurations to be used for information exchange (e.g. based configurations to be used for information exchange (e.g. based
upon preferences, external constraints, etc.). upon preferences, external constraints, etc.).
Note that the meaning of the term "actual configuration" is highly Note that the meaning of the term "actual configuration" is highly
application-specific. For example, for audio transport using RTP, an application-specific. For example, for audio transport using RTP, an
actual configuration is equivalent to a payload format (potentially actual configuration is equivalent to a payload format (potentially
plus format parameters), whereas for other applications it may be a plus format parameters), whereas for other applications it may be a
MIME type. MIME type.
In SAP-based [9] session announcements on the Mbone, for which SDP In SAP-based [8] session announcements on the Mbone, for which SDP
was originally developed, the negotiation procedure is non-existent. was originally developed, the negotiation procedure is non-existent.
Instead, the announcement contains the media stream description sent Instead, the announcement contains the media stream description sent
out (i.e. the actual configurations) which implicitly describe what out (i.e. the actual configurations) which implicitly describe what a
a receiver must understand to participate. receiver must understand to participate.
In point-to-point scenarios, the negotiation procedure is typically In point-to-point scenarios, the negotiation procedure is typically
carried out implicitly: each party informs the other about what it carried out implicitly: each party informs the other about what it
can receive and the respective sender chooses from this set a can receive and the respective sender chooses from this set a
configuration that it can transmit. configuration that it can transmit.
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
skipping to change at page 8, line 14 skipping to change at page 9, line 14
The requirements for the SDPng specification, subdivided into general The requirements for the SDPng specification, subdivided into general
requirements and requirements for session descriptions, potential and requirements and requirements for session descriptions, potential and
actual configurations as well as negotiation rules, are captured in a actual configurations as well as negotiation rules, are captured in a
companion document [1]. 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 potential configurations, i.e. a decision how to realize a certain
certain component. component.
Component Component
A component describes a particular type of interaction (e.g. A component describes a particular type of interaction (e.g. audio
audio conversation, slide presentation) that can be realized by conversation, slide presentation) that can be realized by means of
means of different applications (possibly using different different applications (possibly using different protocols).
protocols).
Library
A library is a application specific collection of potential
configuration definition. For example, the RTP-AVP library would
include definitions for the audio and video codecs of the RTP
audio/video profile (AVP).
Package Package
A package is application specific data schema for expressing A package is application specific data schema for expressing
potential and actual configurations. For example, an audio potential and actual configurations. For example, an audio package
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. Capability Negotiation: Overview and Requirements 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 (i.e. capabilities) of participants in multimedia conferences and for
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
description syntax and processing rules that are applied to the
capability negotiation process. The rules specify how to process two
or more capability description in general in order to obtain an
interworking configuration.
A capability description for an endpoint is a set of individual
capabilities, each of which provides a fixed type, e.g., a numeric
value or a list value. The set of types and the corresponding
negotiation rules are defined in this memo.
In the following, we provide an overview of the negotiation process
in Section 3.1 and describe the different capability types and the
corresponding negotiation rules in Section 3.2.
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
negotiation. It defines the collapsing algorithm and the procedures negotiation. It defines the collapsing algorithm and the procedures
for exchanging SDPng documents in a negotiation phase. for exchanging SDPng documents in a negotiation phase.
The description language and the rules for the negotiation phase that The description language and the rules for the negotiation phase that
are defined here are (in general) independent of the means by which are defined here are (in general) independent of the means by which
descriptions are conveyed during a negotiation phase (a reliable descriptions are conveyed during a negotiation phase (a reliable
transport service with causal ordering is assumed). There are transport service with causal ordering is assumed). There are however
however properties and requirements of call signaling protocols that properties and requirements of call signaling protocols that have
have been considered to allow for a seamless integration of the been considered to allow for a seamless integration of the
negotiation into the call setup process. For example, in order to be negotiation into the call setup process. For example, in order to be
usable with SIP, it must be possible to negotiate the conference usable with SIP, it must be possible to negotiate the conference
configuration within the two-way-handshake of the call setup phase. configuration within the two-way-handshake of the call setup phase.
In order to use SDPng instead of SDP according to the offer/answer In order to use SDPng instead of SDP according to the offer/answer
model defined in [16] it must be possible to determine an actual model defined in [13] it must be possible to determine an actual
configuration in a single request/response cycle. configuration in a single request/response cycle.
3.1 Outline of the Negotiation Process
Conceptually, the negotiation process comprises the following Conceptually, the negotiation process comprises the following
individual steps (considering two parties, A and B, where A tries to individual steps (considering two parties, A and B, where A tries to
invite B to a conference). Please note that this describes the steps invite B to a conference). Please note that this describes the steps
of the negotiation process conceptually -- it does not specify of the negotiation process conceptually -- it does not specify
requirements for implementations. Specific procedures that MUST be requirements for implementations. Specific procedures that MUST be
followed by implementations are given below. followed by implementations are given below.
1. A determines its potential configurations for the components that 1. A determines its potential configurations for the components that
should be used in the conference (e.g. "interactive audio" and should be used in the conference (e.g. "interactive audio" and
"shared whiteboard") and sends a corresponding SDPng instance to "shared whiteboard") and sends a corresponding SDPng instance to
B. This SDPng instances is denoted "CAP(A)". B. This SDPng instances is denoted "CAP(A)".
2. B receives A's SDPng instance and analyzes the set of components 2. B receives A's SDPng instance and analyzes the set of components
(sdpng:c elements) in the description. For each component that B in the description. For each component that B wishes to support
wishes to support it generates a list of potential configurations it generates a list of potential configurations corresponding to
corresponding to B's capabilities, denoted "CAP(B)". B's capabilities, denoted "CAP(B)".
3. B applies the collapsing function and obtains a list of potential 3. B applies the collapsing function and obtains a list of potential
configurations that both A and B can support, denoted configurations that both A and B can support, denoted
"CAP(A)xCAP(B) = CAP(AB)". "CAP(A)xCAP(B) = CAP(AB)".
4. B sends CAP(B) to A. 4. B sends CAP(B) to A.
5. A also applies the collapsing function and obtains "CAP(AB)". At 5. A also applies the collapsing function and obtains "CAP(AB)". At
this step, both A and B know the capabilities of each other and this step, both A and B know the capabilities of each other and
the potential configurations that both can support. the potential configurations that both can support.
6. In order to obtain an actual configuration from the potential 6. In order to obtain an actual configuration from the potential
configuration that has been obtained, both participants have to configuration that has been obtained, both participants have to
pick a subset of the potential configurations that should pick a subset of the potential configurations that should
actually be used in the conference and generate the actual actually be used in the conference and generate the actual
configuration. It should be noted that it depends on the configuration. It should be noted that it depends on the specific
specific application whether each component must be assigned application whether each component must be assigned exactly one
exactly one actual configuration (one sdpng:alt element) or actual configuration or whether it is allowed to list multiple
whether it is allowed to list multiple actual configurations. In actual configurations. In this model we assume that A selects the
this model we assume that A selects the actual configuration, actual configuration, denoted CFG(AB).
denoted CFG(AB).
7. A augments CFG(AB) with the transport parameters it intends to 7. A augments CFG(AB) with the transport parameters it intends to
use, e.g., on which endpoint addresses A wishes to receive data, use, e.g., on which endpoint addresses A wishes to receive data,
obtaining CFG_T(A). A sends CFG_T(A) to A. obtaining CFG_T(A). A sends CFG_T(A) to A.
8. B receives CFG_T(A) and adds its own transport parameters, 8. B receives CFG_T(A) and adds its own transport parameters,
resulting in CFG_T(AB). CFG_T(AB) contains the selected actual resulting in CFG_T(AB). CFG_T(AB) contains the selected actual
configurations and the transport parameters of both A and B (plus configurations and the transport parameters of both A and B (plus
any other SDPng data, e.g., meta-information on the conference). any other SDPng data, e.g., meta-information on the conference).
CFG_T(AB) is the complete conference description. Both A and B CFG_T(AB) is the complete conference description. Both A and B
skipping to change at page 11, line 5 skipping to change at page 12, line 18
CAP(B) B's supported potential configurations CAP(B) B's supported potential configurations
CAP(AB) The set of potential configurations supported by both A CAP(AB) The set of potential configurations supported by both A
and B. and B.
CFG(AB) The set of actual configurations to be used. CFG(AB) The set of actual configurations to be used.
CFG_T(AB) The set of actual configurations to be used augmented CFG_T(AB) The set of actual configurations to be used augmented
with all required parameters. with all required parameters.
In this model, the capability negotiation and configuration exchange Note that the model presented here results in four SDPng messages. As
process leads to a description that represents a global view of the an optimization, this procedure can be abbreviated to two exchanges
configuration that should be used. This means, it contains the by including the transport (and other) parameters into the potential
complete configuration for all participants including per-participant configurations. A embeds its desired transport parameters into the
information like transport parameters. list of potential configurations and B also sends all required
parameters in the response together with B's potential
Note that the model presented here results in four SDPng messages.
As an optimization, this procedure can be abbreviated to two
exchanges by including the transport (and other) parameters into the
potential configurations. A embeds its desired transport parameters
into the list of potential configurations and B also sends all
required 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.
Specific procedures for re-negotiation and multi-party negotiation The SDPng capability negotiation process is specified in Section 5.
will be defined in a future version of this document.
3.2 The Negotiation Process 3.2 Capability Types
The algorithm for comparing two potential configurations and for The capability negotiation process relies on a fixed set of
obtaining a commonly supported subset is application specific. For processing rules for different types of capabilities. The following
some limited application scenarios, a application specific types are defined:
offer/answer process may be employed such as the SDP offer/answer
model [16].
More advanced implementations require a generic capability 1. Tokens (text strings)
negotiation mechanism that allows for application-independent
negotiation of potential configuration with parameters from different
application domains. Capability negotiation frameworks such as RFC
2533 [18] can be employed for this purpose. In a future version of
this document, we will discuss of employing a RFC 2533 based
negotiation process for comparing and matching capability
descriptions in SDPng documents.
4. SDPng Example:
This section introduces the underlying concepts of the Session <audio:encoding>PCMU</audio:encoding>
Description Protocol - next generation (SDPng). The focus of this
section is on the concepts of the capability description language
with a stepwise introduction of the various syntactical elements.
Note that this section only provides examples accompanied by
explanations. The description elements used in this section are not
normative.
4.1 Conceptual Outline Processing rule:
Ascertain identity
In Section 2 we have distinguished between potential configurations 2. Token lists
("capabilities") and actual configurations ("session descriptions").
SDPng provides the possibility to express potential configurations
and actual configurations in one document. A potential configuration
list is used to declare capabilities and an actual configuration list
is used to declare concrete configurations.
Potential configurations are described independently of actual Example:
configurations. In a "potential configurations" section, a user
agent lists its capabilities as a list of named definitions. For
negotiating capabilities from different user agents, the individual
definitions are matched in order to determine a commonly supported
subset of capabilities. The data schema for potential configurations
is defined in "package definitions". An example for an element of a
potential configuration would be the definition of a supported audio
codec.
Actual configurations can refer to capabilities and specify concrete <audio:sampling-rate>8000 16000</audio:sampling-rate>
parameters for application protocol sessions, including transport Processing rule:
parameters. Actual configurations cannot be negotiated. Determine common subset
When defining potential configurations, capabilities are never 3. Numbers
expressed with respect to other potential configuration elements,
e.g., the definition of an audio codec capability does not limit the
capability of using other audio codec. Constraints like the
simultaneous usage of capabilities can be expressed separately from
the capabilities themselves.
In addition, information about the communication session itself, such Example:
as scheduling, information on the semantics of application protocol
sessions and information on the user who has initiated a conference.
This information is expressed separately from the definition of
potential and actual configurations.
These different elements of session description are discussed in <audio:bitrate val="64"/>
detail in the following sections. There are four different elements:
Potential Configurations; see Section 4.1.1. Processing rule:
Ascertain equality
Actual Configurations; see Section 4.1.2. 4. Numerical ranges
Constraints; see Section 4.1.3. Example:
Session meta information; see Section 4.1.4. <audio:bitrate min="6" max="64"/>
4.1.1 Potential Configurations Processing rule:
Determine common subrange
A "Potential Configurations" section in an SDPng document lists SDPng distinguishes between optional and mandatory capability
individual capabilities, e.g., codec capabilities. In a capability definitions, with different processing rules for the negotiation
negotiation process these potential configurations may be compared to process. Optional definitions are used for capabilities that can be
the potential configurations that are defined in an SDPng document provided by an entity but do not have to be supported by all
from another participant. The outline of such a negotiation process participants. For example, an audio codec could provide optional
is presented in Section 3. codec parameters. The use of these parameters needs to be declared by
a session description, but if the parameter is not understood by all
implementations, a session can be established nevertheless. As a
result, the failure of a single processing step for a definition that
has been marked as "optional" does not lead to a failure of the
capability negotiation as a whole.
Please note, that in the following examples, we use a straw-man A mandatory capability on the other hand has to be supported by all
syntax in order to discuss the concepts. A final syntax will be participants. For example, the specification of an audio codec for an
formally defined in a future version of this document. audio capability is mandatory, and for obtaining an interoperable
configuration, all participants must support the same audio codec or
set of audio codecs.
These are two examples of elements in a potential configurations In addition to capabilities, a SDPng description can also provide
section: parameters that are not negotionable, e.g., transport parameters. In
SDPng, there is a distinction between capability definitions (that
are subject to a negotiation process) and parameters that are
specified by each participant. In a description of alternative
configurations for a specific component, capabilities and parameters
can be referred to and describe the configurations.
audio:codec 3.3 Application-specific Vocabulary
name=audio-basic
encoding="PCMU"
sampling="8000"
channels="[1]"
audio:codec While the SDPng specification defines the fundamental definition
name="audio-L16-mono" types, processing rules and the syntax definition for SDPng
encoding="L16" descriptions, it does not define any application-specific vocabulary.
sampling="44100" Application-specific vocabulary is defined in SDPng packages. An
channels="[1,2,4]" SDPng package defines a schema for application specific capability
and parameter descriptions. Based on the description types specified
by the SDPng base specification, a package definition specifies the
capability and parameter definitions allowed for a specific
application, the types of definitions and additional attributes,
e.g., whether a definition element is optional with respect to the
capability negotiation or not.
The following requirements can be stated for expressing potential The SDPng base specification does define some fundamental
configurations: requirements for definition elements that are specified in package
definitions, for example XML attributes for elements. Appendix A.2
provides an XML Schema definition that specifies some base types that
to be used for package definitions.
o It must be possible to name potential configuration elements. In In order to allow for an application independent processing of SDPng
the example above, this is achieved by the property "name". Names description documents, SDPng descriptions are standalone, i.e., the
MUST NOT be considered in a capability negotiation process. package definition is not required to process a corresponding SDPng
document. All information, e.g., the type of definitions and
additional attributes are contained in the SDPng document itself. An
SDPng implementation can thus be processed without access to the
package definition.
o The potential configuration elements are referred to by this name 4. SDPng Syntax
for specifying actual configurations. It MUST be ensured that
names that originate from different description documents reside
in separate namespaces in order to avoid collisions.
o The properties of a given potential configuration element MUST This section specifies the SDPng base syntax. An SDPng description is
have a well-defined type. For example, codec type names are an XML document consisting of up to five parts:
expressed as strings, and for capability negotiation, two codec
names can be processed by applying a string comparison. A maximum
frame-rate would be expressed as a number that represents an upper
limit, and for capability negotiation, the minimum of two numbers
would be used as a commonly supported value for the frame-rate.
o User agents MUST be able to infer the type of a given property Capabilities
without referring to an external schema definition, i.e., the type
must be specified either implicitly or explicitly. Note, that in
the example above, the type is not specified.
o In addition to the data type and its value a property can provide Definitions
other characteristics: Some properties that a package definition
defines for a certain application are mandatory, i.e., they must
be specified in configuration descriptions. In the example above,
this would apply to the encoding, the sampling-rate and the number
of channels. For this single potential configuration elements
these properties serve as constraints for a negotiation: The
capability description matches only those description from other
participants that provide the same encoding, the same sampling-
rate and either 1,2 or 4 channels. If a description did not
provide one of these properties, the negotiation would fail.
There are however properties that can represent optional
parameters, such as a codec parameter that can optionally be used.
If one participant specified such a property and another
participant did not, we would expect the resulting configuration
to not include that property, however, the negotiation itself
should be successful.
o Some capabilities such as codec capabilities may be associated Configurations
with additional constraints, e.g., the directionality of media
streams ('send-only', 'receive-only'). It will be defined in a
future version of this document whether the directionality is
specified as a capability (in a potential configuration) or
whether it is rather specified as an attribute of an actual
configuration.
With these requirements in mind, we add additional characteristics to Constraints
the properties in potential configuration descriptions (and change
the encoding for the second potential configuration element):
audio:codec Session Information
name=audio-basic;type=name
encoding="PCMU";type=string
sampling="8000";type=maximum-limit
channels="[1]";type=set
featureX="200";type=maximum-limit;optional
audio:codec The Capabilities section provides a list of individual capabilities.
name="audio-PCMU-44khz";type=name In a capability negotiation process, these capabilities are matched
encoding="PCMU";type=string against corresponding definitions of other participants' capability
sampling="44100";type=maximum-limit descriptions. This section MUST be present in any SDPng description.
channels="[1,2,4]";type=set
featureY="200";type=string;optional
Note again, that these descriptions merely present examples in order The Definitions section provides definitions of commonly used
to present the data model that we use for potential configurations -- parameters for later referencing. This section is OPTIONAL for SDPng
this is not the SDPng syntax. In these examples, we have added the descriptions.
optional features 'featureX' and 'featureY'.
If we assume, that the two potential configurations are contributions The Configurations section provides the description of the different
from different participants for a capability negotiation, a resulting conference components (applications in a conference). Each component
potential configuration, after a negotiation process as outlined in description can provide a list of alternative configurations. This
Section 3, could look like this: section MUST be present in any SDPng description.
audio:codec The Constraints section provides contraints on combinations of
encoding="PCMU";type=string configurations. This section is OPTIONAL for SDPng descriptions.
sampling="8000";type=maximum-limit
channels="[1]";type=set
The name cannot be considered for a capability negotiation, the The Session Information section provides meta information on the
optional properties 'featureX' and 'featureY' have only been provided conferences and on individual components. This section is OPTIONAL
by one participant each and the other properties have been processed for SDPng documents.
by the negotiation algorithms (that will be specified in a future
version of this document in Section 3).
So far, we have only considered codec capabilities. Other 4.1 SDPng Base Syntax
capabilities would include transport mechanisms, e.g., RTP/UDP/IPv4:
rtp-udp:transport An SDPng description is an XML document. The document root element
name="rtp-udp-ipv4";type=name MUST be an element of type "sdpng". The XML vocabulary for the SDPng
network="IP4;type=string base specification resides in the XML namespace "http://www.iana.org/
sdpng". The root element of an SDPng description MUST define an XML
default namespace "http://www.iana.org/sdpng". In addition, the
"sdpng" element MUST map the namespace prefix "sdpng" to the
namespace name "http://www.iana.org/sdpng". The "sdpng" element type
provides the child elements "cap", "def", "cfg", "constraints", and
"info" for the different sections of the SDPng description. The
default namespace is also applied to these elements.
4.1.2 Actual Configurations The encoding of the XML document MUST be UTF-8 (RFC2279, [16]).
The "Actual Configurations" section lists all the components that The following figure depicts the overall SDPng document structure.
constitute the multimedia application (IP telephone call, real-time
streaming application, multi-player gaming session etc.). For each
of these components, the actual configurations are given. Potential
configurations are used during capability exchange and/or
negotiation, actual configurations to configure media streams after
negotiation (e.g. with RTSP) or in session announcements (e.g. via
SAP).
Each component is labeled with an identifier so that it can be <?xml version="1.0" encoding="UTF-8"?>
referenced, e.g. to associate semantics with a particular media <sdpng xmlns="http://www.iana.org/sdpng"
stream. For such a component, any number of actual configurations xmlns:sdpng="http://www.iana.org/sdpng">
may be given with each configuration describing an alternative way to <cap>
realize the functionality of the respective component. [...]
</cap>
<def>
[...]
</def>
<cfg>
[...]
</cfg>
<constraints>
[...]
</constraints>
<info>
[...]
</info>
</sdpng>
The semantics of this are application dependent. For example, for Appendix A.1 provides a XML DTD that defines a corresponding document
SIP applications using the SDP offer/answer model, providing multiple type.
alternatives for a component (a media type in SDP) means that the
offerer is prepared to receive at any of the specified addresses any
of the specified payload formats (for RTP applications). In this
example, the order of alternatives is used to specify a preference,
i.e., the first alternative is the most preferred one.
The following example provides two alternative configurations for a Note that the elements for the optional sections "Definitions",
component named "interactive-audio". Each alternative refers to the "Contraints", and "Session-Level Information" are OPTIONAL.
RTP-transport capability named "rtp-udp-ipv4" and to an audio-codec
Application-specific vocabulary resides in its own namespace. For
each namespace name of an SDPng package, a namespace prefix MUST be
declared in the start tag of the "sdpng" element. The following
figure depicts the declaration of namespace prefixes for two package
namespaces:
<?xml version="1.0" encoding="UTF-8"?>
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:audio="http://www.iana.org/sdpng/audio">
[...]
</sdpng>
4.2 Capabilities
A section for capability descriptions is an XML element that can
provide a list of child elements. The element type is called "cap"(in
the "sdpng" namespace). Each child element represents an individual
capability. capability.
component Each capability element MUST provide an attribute "name". The value
name="interactive-audio" of this attribute SHOULD be composed of a prefix (representing a
alt namespace-name) and a unique name for the corresponding capability
name="AVP-audio-0" within that namespace. The namespace-name designates a namespace for
rtp-udp:transport the source of the capability definition, e.g., for the participant of
ref="rtp-udp-ipv4" a conference. If a prefix is specified, it MUST be separated by a
pt="96" colon (':') from the name. The namespace MUST be declared in the
direction="send-receive" respective element or in ancestor elements, e.g., the root "sdpng"
addr="224.2.0.53" element. The following figure depicts a capability element inside a
rtp-port="7800" "cap" element. Note that the child elements of "audio:codec" and the
rtcp-port="7801" other sections of the SDPng description are not shown.
audio-codec
ref="audio-basic"
alt <?xml version="1.0"?>
name="AVP-audio-11" <sdpng xmlns="http://www.iana.org/sdpng"
rtp-udp:transport xmlns:sdpng="http://www.iana.org/sdpng">
ref="rtp-udp-ipv4" <cap>
pt="97" <audio:codec name="avp:pcmu">
direction="send-receive" [One or more feature elements]
addr="224.2.0.53" </audio:codec>
rtp-port="7800"
rtcp-port="7801"
audio-codec
ref="audio-L16-stereo"
For the RTP transport configuration, additional required parameters [...]
are provided, such as the payload type number to be used (pt="97"), </cap>
the IP address and UDP port numbers for RTP and RTCP and the </sdpng>
directionality.
Note that in the example above, the actual configuration of the RTP Each capability element provides a set of features. Each feature is
transport is identical for both alternatives -- with the exception of represented by a child element. The element types are defined in
the payload type number. In a final solution, this duplication package definitions. XML Namespaces are used to disambiguate element
should be avoided by another level of indirection, i.e., by defining types and to allow for extensibility. Each feature element can
these parameters once and referencing this definition where needed. provide a "range" of values -- not only a single value. For example,
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.
SDPng provides two different ways for representing "value ranges": A
feature element can specify a set of tokens or a numerical range.
In order to determine the usable actual configurations after a Each feature that is represented by an XML feature element has a
capability negotiation, a user agent has to traverse the references well-defined type that is specified in the package definition. The
in actual configurations to potential configurations and check type determines the representation of the element values so that type
whether each capability is still supported after a negotiation information is encoded implicitly in the description document. Each
process. Only those alternatives that reference supported feature element MAY provide an attribute "status". If this attribute
capabilities can be considered for implementing the given component. is present it MUST provide one of the following values:
The semantics of specifying multiple alternatives for a component are opt:
application specific -- for RTP configurations in SDP it means that This element describes an optional feature (as described by
the endpoint is willing to receive any of the specified formats Section 3.2).
without further out-of-band signaling and that the first
configuration is preferred.
4.1.3 Constraints The three different features types (as described in Section 3.2) are
represented as described in the following sections. Section 4.2.5
provides a complete example.
Potential configurations are media, transport, and other 4.2.1 Tokens
capabilities, whereas configurations indicate which combinations of
these could be used to provide the desired functionality in a certain
setting.
There may, however, be further constraints within a system (such as Token elements provide a single token as element content. The token
CPU cycles, DSP resources available, dedicated hardware, etc.) that is of type Nmtoken (name token) as defined by [9]. The following
limit which of these configurations can be instantiated in parallel example depicts a feature element of type token.
(and how many instances of these may exist). We deliberately do not
couple this aspect of system resource limitations to the various
application semantics as the constraints may exist across application
boundaries. Also, in many cases, expressing such constraints is
simply not necessary (as many uses of the current SDP show), so
additional overhead can be avoided where this is not needed.
The usage of constraints will be specified in a future version of <audio:encoding>PCMU</audio:encoding>
this document.
4.1.4 Meta Information Boolean values SHOULD be represented as token elements with a values
of either "true" or "false".
The fourth and final section of an SDPng description is used to 4.2.2 Token Sets
specify meta information such as session layer attributes. These
attributes largely include those defined by SDP [RFC2327] (which are
explicitly indicated in the following specification) to describe
originator, purpose, and timing of a multimedia session among other
characteristics. Furthermore, SDPng includes attributes indicating
the semantics of the various Components in a teleconference or other
session.
A session-level specification for connection information (SDP "c=" Token set elements provide a token list as element content. The token
line), bandwidth information (SDP "b=" line), and encryption keys is of type Nmtokens (name tokens) as defined by [9]. The following
(SDP "k=" lines) is deliberately not provided for in SDPng. The example depicts a feature element of type token set.
relevant information can be specified directly in the Configuration
section for individual alternatives.
The section for meta information will provide for integrating and re- <audio:sampling>8000 16000</audio:sampling>
using existing meta-information frameworks such as MPEG-7. Details
will be specified in a future version of this document.
4.2 Syntax Definition Mechanisms 4.2.3 Numerical Values
In this section, we specify the syntax definition mechanisms for Elements for numbers provide an attribute "val" with a numerical
SDPng. value. The following example depicts a feature element of type
numerical value.
In order to allow for the possibility to validate session <audio:bitrate val="64"/>
descriptions and in order to allow for structured extensibility,
SDPng relies on a syntax framework that provides concepts as well as
concrete procedures for document validation and extending the set of
allowed syntax elements.
SGML/XML technologies allow for the creation of Document Type 4.2.4 Numerical Ranges
Definitions (DTDs) that can define the allowed content models for the
elements of conforming documents. Documents can be formally
validated against a given DTD to check their conformance and
correctness. XML DTDs however, cannot easily be extended. It is not
possible to alter to content models of element types or to add new
element types by third-party definition packages without creating the
possibility of name collisions.
For SDPng, a mechanism is needed that allows the specification of a Elements for numerical ranges can provide an attribute "min" and an
base syntax -- for example basic elements for the high level attribute "max". Both attributes provide a numerical value. At least
structure of description documents -- while allowing extensions, for one of these attributes MUST be present. The following example
example elements and attributes for new transport mechanisms, new depicts a feature element of type numerical range.
media types etc. to be added on demand. Still, it has to be ensured
that extensions do not result in name collisions. Furthermore, it
must be possible for applications that process descriptions documents
to distinguish extensions from base definitions.
For XML, mechanisms have been defined that allow for structured <audio:bitrate min="6" max="64"/>
extensibility of document schemata: XML Namespace and XML Schema.
XML Schema mechanisms allow to constrain the allowed document 4.2.5 Sample SDPng cap Element
content, e.g. for documents that contain structured data and also
provide the possibility that document instances can conform to
several XML Schema definitions at the same time, while allowing
Schema validators to check the conformance of these documents.
Extensions of the session description language, say for allowing to <?xml version="1.0"?>
express the parameters of a new media type, would require the <sdpng xmlns="http://www.iana.org/sdpng"
creation of a corresponding XML schema definition that contains the xmlns:sdpng="http://www.iana.org/sdpng">
specification of element types that can be used to describe <cap>
configurations of components for the new media type. Session <audio:codec name="avp:pcmu">
description documents have to reference the extension Schema module, <audio:encoding>PCMU</audio:encoding>
thus enabling parsers and validators to identify the elements of the <audio:channels>1 2</audio:channels>
new extension module and to either ignore them (if they are not <audio:sampling>8000 16000</audio:sampling>
supported) or to consider them for processing the session/capability <audio:bitrate min="6" max="64"/>
description. <audio:silence-suppression status="opt">
true
</audio:silence-suppression>
</audio:codec>
It is important to note that the functionality of validating [...]
capability and session description documents is not necessarily </cap>
required to generate or process them. For example, endpoints would </sdpng>
be configured to understand only those parts of description documents
that are conforming to the baseline specification and simply ignore
extensions they cannot support. The usage of XML and XML Schema is
thus rather motivated by the need to allow for extensions being
defined and added to the language in a structured way that does not
preclude the possibility to have applications to identify and process
the extensions elements they might support. The baseline
specification of XML Schema definitions and packages must be well-
defined and targeted to the set of parameters that are relevant for
the protocols and algorithms of the Internet Multimedia Conferencing
Architecture, i.e. transport over RTP/UDP/IP, the audio video
profile of RFC1890 etc.
Section 4.4 describes package definitions and library definition. Capability elements MAY also provide elements from different XML
namespaces. For example, a video-codec capability MAY be described
with elements declaring general video capabilities, and this element
MAY provide a list of additional codec specific feature elements, as
depicted in the following example:
4.3 Referencing Definitions <?xml version="1.0"?>
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:sdpng="http://www.iana.org/sdpng">
<cap>
<video:codec name="h263+-enhanced">
<video:encoding>H.263+</video:encoding>
<video:resolution>QCIF</video:resolution>
<video:framerate max="30"/>
<h263plus:A>foo</h263plus:A>
<h263plus:B>bar</h263plus:B>
</video:codec>
SDPng provides a referencing concept for definitions. For example, [...]
in the specification of an actual configuration, we reference the </cap>
capabilities of the potential configurations section. </sdpng>
The concrete reference mechanism depends on the syntax in use and 4.2.6 Referencing Capability Elements
will be specified in a future version of this document.
4.4 External Definition Packages The capablity elements of a "cap" element can be referenced in later
sections of the SDPng document. The fundamental model is that
capability elements specify individual capabilities (without
transport and other non-negotionable parameters) and that these
elements are later augmented in Definitions and Configurations
sections.
There are two types of external definitions: When referencing a capability element, e.g., the element video:codec,
the same element name (general identifier) is used. The referencing
element MUST provide an attribute "ref", and the value of this
attribute SHOULD provide the value of the attribute "name" of the
referenced element.
Package Definitions (Section 4.4.1) define rules, i.e., a data The referencing element MAY also provide additional feature elements
schema, for specifying parameters that are not covered by the base (that have not been provided by the referenced capability element).
SDPng specification. The referencing element MAY also provide feature elements that have
already been provided by the referenced element.
Library Definitions (Section 4.4.2) contain definitions that can be The referencing element MAY provide an attribute "name". The
referenced in SDPng documents. semantics of a reference are defined in the corresponding sections
where references to definitions are used, i.e., in Section 4.3 and in
Section 4.4.
4.4.1 Package Definitions Section 5.2.4 provides implementation requirements for dealing with
references to capability elements after a capability negotiation
process.
In order to allow for extensibility it must be possible to define 4.3 Definitions
extensions to the basic SDPng configuration options.
For example, if some application requires the use of a new transport The Definitions section is an optional section that can provide
protocol, endpoints must be able to describe their configuration with definitions of fixed parameters that are not negotionable such as
respect to the parameters of that transport protocol. The mandatory transport parameters. An SDPng description document MAY provide a
and optional parameters that can be configured and negotiated when "def" element that can provide a set of definitions as child
using the transport protocol will be specified in a definition elements.
document. Such a definition document is called a "package".
A package contains rules that specify how SDPng is used to describe Each child element of a "def" element provides an element type
conferences or end-system capabilities with respect to the parameters specified in a package definition. Such child elements are referred
of the package. The specific properties of the package definitions to as "definition elements". Definition elements can provide a set of
mechanism are still to be defined. child elements, each of which specifies a specific configuration
value. Syntactically, these child elements MUST be "feature elements"
as specified in Section 4.2. Child elements of a definition element
MUST be of type Token or of type Numerical Value. A definition
element MUST provide an attribute "name" that is used to specify a
unique name in the scope of the current SDPng description. A
definition element MAY provide an attribute "ref" that is used to
reference a capability element as specified in Section 4.2.
An example of such a package would be the RTP package that defines The following example depicts a def element with one definition
how to specify RTP parameters. Another example would be the audio element of type "rtp:udp". This element is used to specify fixed
codec package that defines how specify audio codec parameters. parameters of an RTP session -- the allowable parameters would have
been specified in a corresponding SDPng RTP package.
4.4.2 Library Definitions <?xml version="1.0"?>
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:sdpng="http://www.iana.org/sdpng">
While package definitions specify the allowed parameters for a given <cap>
profile, SDPng "Definitions" sections refer to package definitions <audio:codec name="avp:pcmu">[...]</audio:codec>
and define concrete configurations based on a specific package. <rtp:udp name="rtpudpip6">[...]</rtp:udp>
</cap>
In order for such definitions to be imported into SDPng documents, <def>
"SDPng libraries" may be defined and referenced in SDPng documents. <rtp:udp name="rtp-cfg1" ref="rtp:rtpudpip6">
A library is a set of definitions that is conforming to one or more <rtp:ip-addr>::1</rtp:ip-addr>
package definitions. <rtp:rtp-port>9456</rtp:rtp-port>
<rtp:pt>1</rtp:pt>
</rtp:udp>
</def>
The purpose of the library concept is to allow certain common <cfg>
definitions to be factored-out so that not every SDPng document has [...]
to include the basic definitions, for example the PCMU codec </cfg>
definition. SDP [2] uses a similar concept by relying on the well <constraints>
known static payload types (defined in RFC1890 [4]) that are also [...]
just referenced but never defined in SDP documents. </constraints>
<info>
[...]
</info>
An SPDng document that references definitions from an external </sdpng>
library has to declare the use of the external library. The external
library, being a set of configuration definitions for a given
package, again needs to declare the use of the package that it is
conforming to. A library itself can make reference to other external
libraries.
There are different possibilities of how package definitions and A definition element SHOULD reference a capability element provided
libraries can be used in SDPng documents: in the "cap" element, as depicted in the example. In the example, the
definition named "rtp-cfg1" provides RTP transport parameters and
references the RTP capability named "rtp:rtpudpip6". The semantics of
referencing the capability element are as follows:
o In an SPDng document, a package definition can be referenced and o An implementation MUST process the newly defined element by
all the configuration definitions are provided within the document adopting the individual feature elements of the referenced
itself. The SDPng document is self-contained with respect to the capability element.
definitions it uses.
o In an SPDng document, the use of an external library can be o For feature elements that are present in both the capability
declared. The library references a package definition and the element and the description element, the feature elements of the
SDPng document references the library. There are two alternatives definition element take precedence over the feature elements of
how external libraries can be referenced: the capability element.
by name: Referencing libraries by names implies the use of a Please note the implementation requirements for dealing with
registration authority where definitions and reference names references to capability elements after a capability negotiation
can be registered with. It is conceivable that the most common process provided in Section 5.2.4.
SDPng definitions be registered that way and that there will be
a baseline set of definitions that minimal implementations must
understand. Secondly, a registration procedure will be
defined, that allows vendors to register frequently used
definitions with a registration authority (e.g., IANA) and to
declare the use of registered definition packages in conforming
SDPng documents. Of course, care should be taken not to make
the external references too complex and thus require too much a
priori knowledge in a protocol engine implementing SDPng.
Relying on this mechanism in general is also problematic
because it impedes the extensibility, as it requires
implementors to provide support for new extensions in their
products before they can inter-operate. Registration is not
useful for spontaneous or experimental extensions that are
defined in an SDPng library.
by address: An alternative to referencing libraries by name is to 4.4 Configurations
declare the use of an external library by providing an address,
i.e., an URL, that specifies where the library can be obtained.
While this allows the use of arbitrary third-party libraries
that can extend the basic SDPng set of configuration options in
many ways, in introduces additional complexity that could
result in in higher latency for the processing of a description
document with references to external libraries. In addition,
there are problems if the referenced libraries cannot be
accessed by all communication partners.
o Because of these problematic properties of external libraries, the The Configurations section lists all the components that constitute
final SDPng specification will have to provide a set of the multimedia application (IP telephone call, real-time streaming
recommendations under which circumstances the different mechanisms application, multi-player gaming session etc.). For each of these
of referring to external definitions should be used. components, the actual configurations are given.
4.5 Mappings An SDPng document MUST provide a "cfg" element that represents the
Configurations section. The "cfg" element provides one or more
"component" element describing alternative configurations for the
component. The "cfg" element SHOULD provide at least one "component"
element. Each "component" element MUST provide an attribute "name"
that identifies the component uniquely in the scope of the SDPng
description.
A mapping needs to be defined in particular to SDP that allows to Each "component" element MUST provide one or more "alt" element, each
translate final session descriptions (i.e. the result of capability of which describes an alternative configuration for the component.
negotiation processes) to SDP documents. In principle, this can be Each "alt" element MUST provide an attribute "name" that provides a
done in a rather schematic fashion for the base specification and a unique identification for the alternative in the scope of the SDPng
set of basic packages. description. In addition, each "alt" element MUST also provide an
attribute "media" for specifying the media type for this particular
alternative. Currently defined values for this attribute are "audio",
"video", "application", "data", and "control". The semantics of these
values are described in [2].
In addition, mappings to H.245 will be defined in order to support Each "alt" element MUST provide one or more XML elements that
applications like SIP-H.323 gateways. describe the configuration parameters for the particular alternative
configuration. The elements are defined by SDPng package
specification and definition from different packages can be mixed.
The type of the elements and their order is application dependent.
5. Syntax Definition Each definition element that is contained in an "alt" element SHOULD
provide an attribute "ref". The "ref" attribute is used to specify a
reference to a capability element (from a "cap" section) or to a
definition element (from a "def" section). The value of an "ref"
element MUST provide the value of a "name" attribute of an existing
capability or definition element. A definition element MAY provide
child elements (for the specification of additional feature and
configuration parameters) but it MAY also be an empty element. The
semantics of referencing the capability element are as follows:
An SDPng description is an XML document with different element types o An implementation MUST process the newly defined element by
for the different sections. The SDPng base syntax specification adopting the individual feature elements of the referenced
defines this overall document structure. capability or definition element.
5.1 Potential Configurations o For feature elements that are present in both the capability/
definition element and the current definition element, the feature
elements of the current definition element take precedence over
the feature elements of the referenced element.
A section for potential configurations is an XML element that can Please note the implementation requirements for dealing with
provide a list of child elements. Each child element represents an references to capability elements after a capability negotiation
individual capability as described in Section 4.1.1. Each property process provided in Section 5.2.4.
is represented by an XML attribute. The element types are defined in
package definitions. XML Namespaces are used to disambiguate element
types and to allow for extensibility.
Each element MUST provide an attribute "name". The value of this The following example depicts the description of a single
attribute SHOULD be composed of a prefix (representing a namespace- configuration for a component named "interactive-audio". The
name) and a unique name for the corresponding capability within that description of the configuration references the "avp:pcmu" audio
namespace. The namespace-name designates a namespace for the source codec definition from the "cap" element and the "rtp-cfg1" RTP
of the capability definition. If a prefix is specified, it MUST be session definition from the "def" element. In this example, both
separated by a colon (':') from the name. elements of the "alt" element are empty elements that adopt the
specified values from the referenced elements.
Each element represents a "feature set" (using the terminology of <?xml version="1.0"?>
[18]). Therefore, each attribute can provide a "range" of values -- <sdpng xmlns="http://www.iana.org/sdpng"
not only a single value. For example, an attribute can specify a set xmlns:sdpng="http://www.iana.org/sdpng">
of supported alternative values for a given property, e.g., for the
sampling rate of an audio codec. SDPng provides two different ways
for representing "value ranges": An attribute can specify a set of
tokens or a numerical range.
Each property that is represented by an XML attribute has a well- <cap>
defined type that is specified in the package definition. The type <audio:codec name="avp:pcmu">[...]</audio:codec>
is encoded implicitly in the attribute value (similar to the syntax <rtp:udp name="rtpudpip6">[...]</rtp:udp>
in RFC 2533 [18]). The following types are distinguished: </cap>
Text strings, tokens <def>
An attribute may provide a token (a symbolic name), e.g., for a <rtp:udp name="rtp-cfg1" ref="rtp:rtpudpip6">
codec name. <rtp:ip-addr>::1</rtp:ip-addr>
An example for a corresponding attribute: <rtp:rtp-port>9456</rtp:rtp-port>
<rtp:pt>1</rtp:pt>
</rtp:udp>
</def>
encoding="PCMU" <cfg>
<component name="interactive-audio" media="audio">
<alt name"alt1">
<audio:codec ref="avp:pcmu"/>
<rtp:udp ref="rtp-cfg1"/>
</alt>
</component>
Token MUST be directly embedded into the attribute content, i.e., </cfg>
the token is the attribute value. <constraints>
The complete formal syntax definition of tokens will be provided [...]
in a later version of this document. </constraints>
<info>
[...]
</info>
Token sets </sdpng>
An attribute can specify a set of tokens (representing a list of
alternative values for a certain property).
An example for a corresponding attribute:
sampling="[8000,16000,44100]" 4.5 Constraints
A token set MUST be specified as a list of tokens that are The Constraints section allows to express constraints on the
separated by commas (',') and are enclosed by square brackets combination of configurations that apply across different components.
('[',']').
The complete formal syntax definition of token sets will be
provided in a later version of this document.
Numbers and Numerical ranges The "constraints" element of an SDPng description is OPTIONAL.
An attribute can specify a number or a range (minimum and maximum)
for numbers.
An example for an attribute specifying a number:
bitrate="(64)" The usage of constraints will be specified in a separate document.
A number MUST be specified as a literal value in brackets ('(', 4.6 Session Information
')').
An example for an attribute specifying a numerical range:
bitrate="(64,128)" The Session Information section is represented by an "info" element
and is intended for meta information on the conference itself and on
the individual components.
A numerical range MUST be specified as a pair of values. The The "info" element is OPTIONAL and, if it is present, it MAY provide
first value is the minimum value (included in the range) and the a list of information elements. The element types are specified in
seconds value is the maximum value (included in the range). The package definitions.
values are separated by a comma (',') and are enclosed in ('(',
')'). One of the range limits MAY be omitted, i.e., either the
minimum or the maximum value, e.g., if the range has no upper or
lower limit.
An example for an attribute specifying a numerical range without
an upper limit:
bitrate="(64,)" 4.7 Summary of SDPng XML-Syntax
The complete formal syntax definition of numbers and numerical The SDPng base specification defines the following XML element types
ranges (and a definition of the exact number type) will be that reside in the SDPng namespace designated by the namespace name
provided in a later version of this document. "http://www.iana.org/sdpng":
An example for an XML element describing an individual capability: o sdpng
<audio:codec name="avp:pcmu" encoding="PCMU" channels="[1,2]" sampling="[8000,16000]"/> o cap
Capability elements MAY also provide attribute from different XML o def
namespaces. For example, a video-codec capability MAY be described
with attributes declaring general video capabilities, and this
element MAY provide a list of additional codec specific attributes,
as depicted in the following example:
<video:codec name="h263+-enhanced" resolution="QCIF" frame-rate="(,24)" o cfg
h263plus:A="foo" h263plus:B="bar" />
The definition of "optional properties" (properties that to do not o component
constitute a constraint but not optional enhancement -- see Section
4.1.1) will be provided in a future version of this document.
6. Specification of the Capability Negotiation o alt
o constraints
o info
Appendix A.1 provides an XML DTD that specifies the content model of
the SDPng base elements.
5. Specification of the Capability Negotiation
The SDPng specification defines the syntax and the semantics of The SDPng specification defines the syntax and the semantics of
capability declarations (potential configurations). The algorithms capability descriptions. The algorithms that are used for processing
that are used for processing descriptions and for comparing descriptions and for comparing capability descriptions from different
capability descriptions from different participants are application participants are application specific.
specific.
In this section we discuss two alternative algorithms for In this section, we specify two alternative algorithms for
implementations: A model that is base on the SDP offer/answer scheme implementations: A model that is based on the SDP offer/answer scheme
(Section 6.1 and a model that is based on the feature matching (Section 5.1 and a model that is based on the feature matching
algorithm that is specified in RFC 2533 [18] (Section 6.2). algorithm that is specified in RFC 2533 [15] (Section 5.2).
6.1 Offer/Answer 5.1 Offer/Answer
The offer/answer model allows to 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 conceivable 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. disallow a video session and go with a audio-only (e.g. receiving a offer including audio and video, it may disallow
conversation) and also provides possible configurations to implement the video session and go with an audio-only conversation) and also
those components. Along with the media types and codec parameters, provides possible configurations to implement those components.
offerer and answerer specify which transport addresses to use and, in Along with the media types and codec parameters, offerer and answerer
case of RTP, which payload types they want to use for sending. specify which transport addresses to use and, in case of RTP, which
Offerer and answerer agree on a common set of media streams payload types they want to use for sending. Offerer and answerer
("components") and on a possible set of codecs ("configurations") as agree on a common set of media streams ("components") and on a
well as the transport addresses and other parameters to be used. possible set of codecs for each of these ("configurations") as well
However, they do not fix a certain configuration (unless only a as the transport addresses and other parameters to be used. However,
single one is exchanged in each direction). Instead, for each they do not fix a certain configuration (unless only a single one is
selected media stream, either peer may choose and dynamically switch exchanged in each direction). Instead, for each selected media
to any of the configurations indicated by the other side in the stream, either peer may choose and dynamically switch to any of the
respective offer or answer. configurations indicated by the other side in the respective offer or
answer.
For using SDPng with the offer/answer model (RFC 3264), the following For using SDPng with the offer/answer model (RFC 3264), the basic
considerations apply to the SDPng documents: defined in RFC 3264 for generating offers and answers apply. The
following considerations specifically apply when using offer/answer
with SDPng (instead of SDP) documents:
o For each component to be used, all necessary parameters for at o For each component to be used, all necessary parameters MUST be
least one actual configuration MUST be given, 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 session part of the SDPng document using predefined
identifiers. identifiers for certain session types.
For simple sessions, where applications can implicitly derive the
semantics of the the offered components, no such explicit mapping
is necessary. In this case, i.e. if the entire "<info>" element
or the respective elements in the "<info>" element are absent, the
order of appearance in the SDPng document is relevant as it is
with SDP.
o Components that shall not be instantiated (i.e. that are refused o For each component, the answerer performs a capability matching
by the answerer) shall either be present but have all parameters process as per then application's requirements
of the actual configuration removed (i.e. no transport addresses, For all components that are acceptable, the answerer determines
etc.) if they may be (re-)instantiated at a later stage. Or they whether or not to accept the offer.
shall be removed entirely from the answer if the respective If the answerer decides to accept the offer for a certain
component is not supported at all. In the latter case, the component, it MUST accept at least one of the potential
corresponding configurations MUST be removed from both the configurations for the respective component. It SHOULD indicate
configuration section and the session section of the SDPng this by setting the "status" attribute of the component and of the
document. selected configuration(s) to "active" (but it MAY also omit the
status attribute in both cases).
It is RECOMMENDED that the answerer selects exactly one
configuration for each component as "active".
o For each component, the alternative potential configurations MUST o The answerer MAY refuse individual configurations for a component
be listed in the order of preference. A certain preference from the offer in two ways.
indicator ("q=" value) may be included in a future revision of If the configuration shall not be used at all during a session,
this document. The considerations of RFC 3264 to simply arriving e.g. because the answerer does not support it or because the
at symmetric codec use apply. answere does not want to use this configuration at all, the
answerer MUST set the "status" attribute of the respective
component to "unused". In this case, the answerer MAY omit all
the elements contained in the respective configuration's elements.
This is equivalent to setting the port parameter to "0" in SDP.
If a configuration shall be accepted (i.e. the respective
capability shall be indicated) but no media session shall be
instantiated (not even on hold!), the answerer MUST set the
"status" attribute of the respective configuration to "available"
and omit all media-session-specific parameters the configuration.
The rules for matching properties and determining answers based upon o The answerer MAY refuse entire components that the offerer has
the offers are similar to those specified in RFC 3264. included in two ways.
If a component shall not be used at all during a session -- e.g.
because the answerer does not support any of the configurations
listed or because the answere does not want to use this component
at all -- the answerer MUST set the "status" attribute of the
respective component's to "unused". In this case, the answerer
MAY omit all the elements contained in the respective component
elements. This is equivalent to setting the port parameter to "0"
in SDP.
If a component shall be accepted (i.e. the respective capability
shall be indicated) but no media session shall be instantiated
(not even on hold!), the answerer MUST set the "status" attribute
of the respective component to "available", omit all
media-session-specific parameters from all acceptable
configurations for the respective component.
A future revision of this document will define the details for all o For each component, the alternative potential configurations MUST
the attributes discussed in RFC 3264 that require special be listed in the order of preference.
considerations (e.g. the directionality attribute for media Within a configuration, alternatives (e.g. different codecs) MUST
streams). also be listed in the order of preference.
The considerations of RFC 3264 to simply arriving at symmetric
codec use apply.
6.2 RFC2533 Negotiation If a component shall be put on hold, the status attribute of the
component MUST be set to "sendonly", "recvonly", or "inactive", as
appropriate. In this case, the status attributes of all the
contained configurations that were previously active MUST be set to
indicate "sendonly", "recvonly", or "inactive", as appropriate. The
rules from RFC 3264 for putting media streams on hold SHALL apply.
5.2 RFC2533 Negotiation
SDPng potential configurations can be processed using the RFC 2533 SDPng potential configurations can be processed using the RFC 2533
algorithm as defined in [18]. This involves the following steps: algorithm as defined in [15]. This involves the following steps:
Translating SDPng potential configurations to RFC 2533 feature set Translating SDPng capability descriptions to RFC 2533 feature set
expressions; expressions;
Applying the RFC 2533 feature match algorithm; and Applying the RFC 2533 feature match algorithm; and
Integrating the resulting feature set expressions into the SDPng Integrating the resulting feature set expressions into the SDPng
selection of actual configurations. selection of conference configurations.
6.2.1 Translating SDPng to RFC 2533 Expressions 5.2.1 Translating SDPng to RFC 2533 Expressions
SDPng potential configurations can be translated to RFC 2533 feature SDPng capability descriptions can be translated to RFC 2533 feature
sets in a straightforward way, because SDPng uses a subset of the sets in a straightforward way, because SDPng uses a subset of the
mechanisms provided by RFC 2533 with a different syntax. mechanisms provided by RFC 2533 with a different syntax.
Each capability in an SDPng section for potential configurations is Each capability is represented as an XML element with a set of child
represented as an XML element with a set of attributes. We first elements. We first describe how to translate a single capability
describe how to translate a single capability element into a RFC 2533 element into a RFC 2533 feature set, and then consider the
feature set, and then consider the combination of multiple capability combination of multiple capability elements.
elements.
Basically, all attributes of an SDPng capability element and its Basically, all attributes of an SDPng capability element and its
child elements MUST be transformed to a RFC 2533 expression, whereas child elements MUST be transformed to an RFC 2533 expression, whereas
each attribute MUST be translated to a feature predicate. The each child element MUST be translated to a feature predicate. The
resulting feature predicate are combined using the '&' (AND) resulting feature predicates are combined using the '&' (AND)
operator. The name attributes MUST NOT be considered. operator. The name attributes MUST NOT be considered.
Each predicate MUST be encapsulated by brackets ('(', ')'). Each XML Each predicate MUST be encapsulated by brackets ('(', ')'). The value
attribute value is taken as a feature predicate value, i.e., the or value range of each feature element is taken as a feature
quote are not considered. Each attribute name is directly adopted as predicate value. Each feature element name is directly adopted as a
a feature tag, including the namespace name. feature tag, including the namespace name.
The SDPng data types map to RFC 2533 feature types as follows: The SDPng data types map to RFC 2533 feature types as follows:
Token Token
A token MUST be directly adopted as a RFC 2533 token. A token MUST be directly adopted as an RFC 2533 token.
Token set Token set
A token set MUST be directly adopted as a RFC 2533 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 Number
A single number in round brackets MUST be adopted as a RFC 2533 A single number in a "val" attribute of a feature elements of type
number. The brackets MUST be removed. number MUST be adopted as an RFC 2533 number.
Numerical Ranges Numerical Ranges
A numerical range MUST be transformed to a feature set expression A numerical range MUST be transformed to a feature set expression
with two feature predicates that are combined using the "&" (AND) with two feature predicates that are combined using the "&" (AND)
operator. The first predicate specifies the lower limit and the operator. The first predicate specifies the lower limit and the
second predicate specified the upper limit. second predicate specified the upper limit.
For example, the attribute bitrate="(64,128)" would be transformed For example, the element <bitrate min="64" max="128"/> would be
to the following feature set: transformed to the following feature set:
(& (bitrate>=64) (bitrate<=128)) (& (bitrate>=64) (bitrate<=128))
A numerical range without a lower limit MUST be transformed to a A numerical range without a lower limit MUST be transformed to a
corresponding predicate with a '<=' operator and a numerical range corresponding predicate with a '<=' operator and a numerical range
without a upper limit MUST be transformed to a corresponding without a upper limit MUST be transformed to a corresponding
predicate with a '>=' operator. predicate with a '>=' operator.
For example, the attribute bitrate="(,128)" would be transformed For example, the element <bitrate max="128"/> would be transformed
to the following feature set: to the following feature set:
(bitrate<=128) (bitrate<=128)
The following sample SDPng potential configuration would be The following sample SDPng potential configuration would be
transformed as follows: transformed as follows:
Original SDPng expression: Original SDPng expression:
<video:codec name="h263+-enhanced" resolution="QCIF" frame-rate="(,24)" <video:codec name="h263+-enhanced">
h263plus:A="foo" h263plus:B="bar" /> <video:resolution>QCIF</video:resolution>
<video:frame-rate max="24"/>
<h263plus:A>foo</h263plus:A>
<h263plus:B>bar</h263plus:B>
</video:codec>
Transforming attributes to feature predicates: Transforming feature elements to feature predicates:
(& (resolution=QCIF) (frame-rate<=24) (h263plus:A=foo) (h263plus:B=bar)) (& (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 Note that in example above, the namespace name is not used for
feature tags, instead we use the namespace prefix (for abbreviation). feature tags, instead we use the namespace prefix (for abbreviation).
RFC 2533 uses the syntax rules of RFC 2506 for feature tags. An It should be noted, that implementations MUST replace the namespace
additional requirement for transforming fully-qualified attribute prefix of SDPng elements with the namespace name when performing the
names (including namespace names) to feature tags will be specified translation to an RFC 2533 expression. The following figure depicts
in a future version of this document. 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 Multiple independent capability elements MUST each be transformed
using the specification above and then combined into a single RFC using the specification above and then combined into a single RFC
2533 feature set by connecting the individual feature sets using the 2533 feature set by connecting the individual feature sets using the
'|' (OR) operator. For example, the following sample SDPng potential '|' (OR) operator. For example, the following sample SDPng potential
configuration would be transformed as follows: configuration would be transformed as follows:
<audio:codec name="avp:pcmu" encoding="PCMU" channels="[1,2]" sampling="[8000,16000]"/> <audio:codec name="avp:pcmu">
<video:codec name="h263+-enhanced" resolution="QCIF" frame-rate="(,24)" <audio:encoding>PCMU</audio:encoding>
h263plus:A="foo" h263plus:B="bar" /> <audio:channels>1 2</audio:channels>
<audio:sampling>8000 16000</audio:sampling>
</audio:codec>
Transforming attributes to feature predicates: <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:
(| (|
(& (encoding=PCMU) (channels=[1,2]) (sampling=[8000,16000])) (& (video:encoding=PCMU) (video:channels=[1,2])
(& (resolution=QCIF) (frame-rate<=24) (h263plus:A=foo) (h263plus:B=bar)) (video:sampling=[8000,16000]))
(& (video:resolution=QCIF) (video:frame-rate<=24)
(h263plus:A=foo) (h263plus:B=bar))
) )
Additional requirements for processing "optional" parameters (see 5.2.2 Applying RFC 2533 Canonicalization
Section 5) will be specified in a future version of this document.
6.2.2 Applying RFC 2533 Canonicalization
After transforming different SDPng capability descriptions from After transforming different SDPng capability descriptions from
different participants into their equivalent RFC 2533 form, the different participants into their equivalent RFC 2533 form, the
following steps MUST be performed to calculate the common subset of following steps MUST be performed to calculate the common subset of
capabilities: capabilities:
1. The individual feature sets MUST be combined into a single 1. The individual feature sets MUST be combined into a single
expression by creating conjunction of the feature sets, i.e., the expression by creating a conjunction of the feature sets, i.e.,
feature sets MUST be connected by the '&' (AND) operator. the feature sets MUST be connected by the '&' (AND) operator.
2. The resulting expression MUST be reduced to disjunctive normal 2. The resulting expression MUST be reduced to disjunctive normal
form, i.e., the canonical from as specified by RFC 2533 [18]. form, i.e., the canonical from as specified by RFC 2533 [15].
6.2.3 Integrating Feature Sets into SDPng 5.2.3 Integrating Feature Sets into SDPng
A feature set that has been created by combining multiple independent A feature set that has been created by combining multiple independent
feature sets and by reducing the result for canonical form does not feature sets and by reducing the result for canonical form does not
indicate directly which of the capability elements belong the common indicate directly which of the capability elements belong to the
subset of capabilities. The following steps MUST be performed to common subset of capabilities. SDPng uses the following approach:
determine whether an individual capability element (e.g., from one of After a "collapsing process" that has determined the commonly
the contributing SDPng capability descriptions) belongs to the result supported capabilities, the resulting RFC 2533 expression is compared
feature set. 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 Let R be the result feature set obtained from the canonicalization as
specified in Section 6.2.2. specified in Section 5.2.2.
1. For each capability element, generate the equivalent RFC 2533 1. For each capability element, generate the equivalent RFC 2533
feature set by applying the steps specified in Section 6.2.1. feature set by applying the steps specified in Section 5.2.1. Let
Let C be the resulting feature set. C be the resulting feature set.
2. Combine R and C into a single feature set by building a 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 conjunction of the two feature sets (& R C). Let the result be
the feature set T. the feature set T.
3. Reduce T to disjunctive normal form by applying the 3. Reduce T to disjunctive normal form by applying the
canonicalization as defined in RFC 2533 [18]. canonicalization as defined in RFC 2533 [15].
4. If the remaining disjunction is non-empty, the constraints 4. If the remaining disjunction is non-empty, the constraints
specified by capability element (the origin of C) can be specified by capability element (the origin of C) can be
satisfied by R, i.e., C represents a commonly supported satisfied by R, i.e., C represents a commonly supported
capability. capability.
A future version of this document will specify requirements for 5.2.4 Processing Negotiation Results
exchanging calculated capabilities and for selecting appropriate
actual configurations.
7. Open Issues 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 of baseline libraries Definition elements (inside the SDPng "def" element) and
configuration descriptions (inside the SDPng "alt" element) that
reference capability elements that have been removed after the
negotiation process, MUST be removed as well. Configuration
description (inside the SDPng "alt" element) that reference
non-existing definition elements (inside the SDPng "def" element")
MUST also be removed.
Libraries provide partially specified definitions, i.e. without 6. IANA Considerations
transport parameters. How can SDPng documents reference the
definitions and augment them with specific transport parameters?
Referencing extension packages: XML-Schema does not support the The IANA should set up a registry for XML namespaces for SDPng and
declaration of multiple schemas via the schemaLocation attribute. SDPng package definitions.
Conceivable solution: When extension packages are used, the SDPng
description is a "multi-part" object, that consists of an
integrating schema definition (that references all necessary
packages and the base definition) and the actual description
document that is a schema instance of the integrating schema.
Uniqueness of attribute values: When libraries are used they will The SDP parameter registry (http://www.iana.org/assignments/
contain definition elements with "name" attributes for later sdp-parameters) should be converted to SDPng package definitions.
referencing. How to avoid name clashes for those identifiers?
When an SDPng document uses libraries from different sources they
could be incompatible because of name collisions. Possible
solution: Prefix such IDs with a namespace name (either explicitly
or implicitly by interpreting applications). The explicit
prefixes have the advantage that no special knowledge would be
required to resolve links at the cost of very long ID values.
A registry (reuse of SDP mechanisms and names etc.) needs to be 7. Open Issues
set up.
Implicit declaration of SDPng schema and default package Revise usage of terminology (potential configuration, actual
configuration)
Should overwriting of child elements be allowed for referencing Do we need an explicit mechanism to declare the used packages?
existing definitions with the "ref" attribute? E.g., <pkg ref="http://www.iana.org/sdpng/audio"/>
We need a package definition language. XML-DTDs or XML-Schema is Data model for audio package: sampling-rate vs. RTP clock rate
not sufficient as we need ways to specify the type (string/symbol,
set, numerical range) and additional attributes (optional). Bib. references: distinguish normative and informational
A registry (reuse of SDP mechanisms and names etc.) needs to be
set up (IANA considerations).
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Teodora Guenkova, Goran Petrovic and The authors would like to thank Teodora Guenkova, Goran Petrovic and
Markus Nosse for their feedback and detailed comments. Markus Nosse for their feedback and detailed comments.
References References
[1] Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements [1] Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements
for Session Description and Capability Negotiation", Internet for Session Description and Capability Negotiation", Internet
Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001. Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001.
[2] Handley, M. and V. Jacobsen, "SDP: Session Description [2] Handley, M. and V. Jacobsen, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996. 3550, July 2003.
[4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.
[5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", draft-ietf-avt-profile-new- Conferences with Minimal Control", RFC 3551, July 2003.
10.txt (work in progress), March 2001.
[6] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, [5] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP
Payload for Redundant Audio Data", RFC 2198, September 1997. Payload for Redundant Audio Data", RFC 2198, September 1997.
[7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for [6] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999. Generic Forward Error Correction", RFC 2733, December 1999.
[8] Perkins, C. and O. Hodson, "Options for Repair of Streaming [7] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998. Media", RFC 2354, June 1998.
[9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement [8] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[10] World Wide Web Consortium (W3C), "Extensible Markup Language [9] World Wide Web Consortium (W3C), "Extensible Markup Language
(XML) 1.0 (Second Edition)", Status W3C Recommendation, Version (XML) 1.0 (Second Edition)", Status W3C Recommendation, Version
http://www.w3.org/TR/2000/REC-xml-20001006, October 2000. http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.
[11] World Wide Web Consortium (W3C), "Namespaces in XML", Status [10] World Wide Web Consortium (W3C), "Namespaces in XML", Status
W3C Recommendation, Version http://www.w3.org/TR/1999/REC-xml- W3C Recommendation, Version http://www.w3.org/TR/1999/
names-19990114, January 1999. REC-xml-names-19990114, January 1999.
[12] World Wide Web Consortium (W3C), "XML Inclusions (XInclude)
Version 1.0", Status W3C Candidate Recommendation, Version
http://www.w3.org/TR/2002/CR-xinclude-20020221, February 2002.
[13] World Wide Web Consortium (W3C), "XML Schema Part 1:
Structures", Version http://www.w3.org/TR/2001/REC-xmlschema-1-
20010502/, Status W3C Recommendation, May 2001.
[14] World Wide Web Consortium (W3C), "XML Schema Part 2: [11] World Wide Web Consortium (W3C), "XML Schema Part 1:
Datatypes", Version http://www.w3.org/TR/2001/REC-xmlschema-2- Structures", Version http://www.w3.org/TR/2001/
20010502/, Status W3C Recommendation, May 2001. REC-xmlschema-1-20010502/, Status W3C Recommendation, May 2001.
[15] World Wide Web Consortium (W3C), "XML Linking Language (XLink) [12] World Wide Web Consortium (W3C), "XML Schema Part 2:
Version 1.0", Version http://www.w3.org/TR/2001/REC-xlink- Datatypes", Version http://www.w3.org/TR/2001/
20010627/, Status W3C Recommendation, June 2001. REC-xmlschema-2-20010502/, Status W3C Recommendation, May 2001.
[16] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
SDP", RFC 3264, June 2002. SDP", RFC 3264, June 2002.
[17] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for The [14] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the
Use of XML within IETF Protocols", draft-hollenbeck-ietf-xml- Use of Extensible Markup Language (XML) within IETF Protocols",
guidelines-05.txt (work in progress), June 2002. BCP 70, RFC 3470, January 2003.
[18] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC [15] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
2533, March 1999. 2533, March 1999.
[16] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[17] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999.
Authors' Addresses Authors' Addresses
Dirk Kutscher Dirk Kutscher
TZI, Universitaet Bremen TZI, Universitaet Bremen
Bibliothekstr. 1 Bibliothekstr. 1
Bremen 28359 Bremen 28359
Germany Germany
Phone: +49.421.218-7595, sip:dku@tzi.org Phone: +49.421.218-7595, sip:dku@tzi.org
Fax: +49.421.218-7000 Fax: +49.421.218-7000
skipping to change at page 36, line 5 skipping to change at page 38, line 5
Carsten Bormann Carsten Bormann
TZI, Universitaet Bremen TZI, Universitaet Bremen
Bibliothekstr. 1 Bibliothekstr. 1
Bremen 28359 Bremen 28359
Germany Germany
Phone: +49.421.218-7024, sip:cabo@tzi.org Phone: +49.421.218-7024, sip:cabo@tzi.org
Fax: +49.421.218-7000 Fax: +49.421.218-7000
EMail: cabo@tzi.org EMail: cabo@tzi.org
Appendix A. Use of SDPng in conjunction with other IETF Signaling Appendix A. Formal Syntax Specifications
A.1 SDPng Base DTD
The following DTD specifies the SDPng base syntax. DTDs are not
XML-Namespace aware, therefore the following DTD is for informational
purposes only. Moreover, the content models for the element types
"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
specification but by independent package definitions. Common
requirements for these element types such as the "name" attribute
cannot be expressed with XML DTDs.
<!ELEMENT sdpng (cap, def?, cfg, constraints?, info?)>
<!ELEMENT cap ANY>
<!ELEMENT def ANY>
<!ELEMENT cfg (component+)>
<!ELEMENT component (alt+)>
<!ATTLIST component
name CDATA #REQUIRED
media CDATA #IMPLIED
>
<!ELEMENT alt ANY>
<!ATTLIST alt
name CDATA #REQUIRED
>
A.2 SDPng XML-Schema Specification
<xsd:schema
xmlns:sdpng="http://www.iana.org/sdpng"
targetNamespace="http://www.iana.org/sdpng"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
>
<!--
A data type for the "status" attribute
status=mandatory: feature match MUST be successful
status=opt: optional feature, feature match MAY fail
-->
<xsd:simpleType name="status">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="mandatory"/>
<xsd:enumeration value="opt"/>
</xsd:restriction>
</xsd:simpleType>
<!-- Base type for definition elements -->
<xsd:complexType name="Definition" abstract="true">
<xsd:attribute name="name" type="xsd:string" use="optional"/>
<xsd:attribute name="ref" type="xsd:string" use="optional"/>
</xsd:complexType>
<!--
Data type for the content model of mandatory feature elements of type
token
-->
<xsd:complexType name="token">
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="status" type="sdpng:status" fixed="mandatory"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<!--
Data type for the content model of optional feature elements of
type token
-->
<xsd:complexType name="opttoken">
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKEN">
<xsd:attribute name="status" type="sdpng:status" fixed="opt"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<!--
Data type for the content model of mandatory feature elements of type
token list
-->
<xsd:complexType name="tokenlist">
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKENS">
<xsd:attribute name="status" type="sdpng:status" fixed="mandatory"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<!--
Data type for the content model of optional feature elements of type
token list
-->
<xsd:complexType name="opttokenlist">
<xsd:simpleContent>
<xsd:extension base="xsd:NMTOKENS">
<xsd:attribute name="status" type="sdpng:status" fixed="opt"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<!--
Data type for the content model of mandatory feature elements of type
numerical value
-->
<xsd:complexType name="numval">
<xsd:attribute name="status" type="sdpng:status" fixed="mandatory"/>
<xsd:attribute name="val" type="xsd:decimal"/>
</xsd:complexType>
<!--
Data type for the content model of optional feature elements of
type numerical value
-->
<xsd:complexType name="optnumval">
<xsd:attribute name="status" type="sdpng:status" fixed="opt"/>
<xsd:attribute name="val" type="xsd:decimal"/>
</xsd:complexType>
<!--
Data type for the content model of mandatory feature elements of type
numerical range
-->
<xsd:complexType name="numrange">
<xsd:attribute name="status" type="sdpng:status" fixed="mandatory"/>
<xsd:attribute name="min" type="xsd:decimal"/>
<xsd:attribute name="max" type="xsd:decimal"/>
</xsd:complexType>
<!--
Data type for the content model of optional feature elements of
type numerical range
-->
<xsd:complexType name="optnumrange">
<xsd:attribute name="status" type="sdpng:status" fixed="opt"/>
<xsd:attribute name="min" type="xsd:decimal"/>
<xsd:attribute name="max" type="xsd:decimal"/>
</xsd:complexType>
<!-- Base type for definition elements -->
<xsd:complexType name="Constraint" abstract="true">
<xsd:attribute name="name" type="xsd:string" use="optional"/>
</xsd:complexType>
<!-- The base element for constraint element -->
<!-- FIXME: substitutionGroup? -->
<xsd:element name="constraint" type="sdpng:Constraint" abstract="true">
</xsd:element>
<!-- Base type for information elements -->
<xsd:complexType name="Information" abstract="true">
<xsd:attribute name="name" type="xsd:string" use="optional"/>
</xsd:complexType>
<!-- The base element for constraint element -->
<!-- FIXME: substitutionGroup? -->
<xsd:element name="information" type="sdpng:Information" abstract="true">
</xsd:element>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!--
SDPng document structure
-->
<xsd:element name="sdpng">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="sdpng:cap"/>
<xsd:element ref="sdpng:def" minOccurs="0"/>
<xsd:element ref="sdpng:cfg"/>
<xsd:element ref="sdpng:constraints" minOccurs="0"/>
<xsd:element ref="sdpng:info" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- The base element for capability and definition elements -->
<!-- FIXME: substitutionGroup? -->
<xsd:element name="definition" type="sdpng:Definition" abstract="true">
</xsd:element>
<!-- The mandatory "cap" element -->
<xsd:element name="cap">
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- The optional "def" element -->
<xsd:element name="def">
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- The mandatory "cfg" element -->
<xsd:element name="cfg">
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element ref="sdpng:component" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- The "component" element -->
<xsd:element name="component">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="sdpng:alt" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string"/>
<xsd:attribute name="media" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="alt">
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<!-- The optional "constraints" element -->
<xsd:element name="constraints">
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element ref="sdpng:constraint" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- The optional "info" element -->
<xsd:element name="info">
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element ref="sdpng:information" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Appendix B. Sample Package Definitions
B.1 Sample RTP Package Definition
<xsd:schema
xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
targetNamespace="http://www.iana.org/sdpng/rtp"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:import namespace="http://www.iana.org/sdpng" schemaLocation="sdpng-base.xsd"/>
<xsd:complexType name="IPVersion">
<xsd:simpleContent>
<xsd:restriction base="sdpng:tokenlist">
<xsd:enumeration value="IP4"/>
<xsd:enumeration value="IP6"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="RTPUDP">
<xsd:complexContent>
<xsd:extension base="sdpng:Definition">
<xsd:all>
<xsd:element name="network" type="rtp:IPVersion" minOccurs="0"/>
<xsd:element name="ip-addr" type="sdpng:opttoken" minOccurs="0"/>
<xsd:element name="rtp-port" type="sdpng:opttoken" minOccurs="0"/>
<xsd:element name="rtcp-port" type="sdpng:opttoken" minOccurs="0"/>
<xsd:element name="pt" type="sdpng:opttoken" minOccurs="0"/>
</xsd:all>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="udp" type="rtp:RTPUDP" substitutionGroup="sdpng:definition"/>
</xsd:schema>
B.2 Sample Audio Package Definition
<xsd:schema
xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
targetNamespace="http://www.iana.org/sdpng/audio"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:import namespace="http://www.iana.org/sdpng" schemaLocation="sdpng-base.xsd"/>
<xsd:complexType name="Codec">
<xsd:complexContent>
<xsd:restriction base="sdpng:Definition">
<xsd:all>
<xsd:element name="encoding" type="sdpng:token" minOccurs="0"/>
<xsd:element name="channels" type="sdpng:tokenlist" minOccurs="0"/>
<xsd:element name="sampling" type="sdpng:tokenlist" minOccurs="0"/>
</xsd:all>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="codec" type="audio:Codec" substitutionGroup="sdpng:definition"/>
</xsd:schema>
B.3 Sample Video Package Definition
<xsd:schema
xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:video="http://www.iana.org/sdpng/video"
targetNamespace="http://www.iana.org/sdpng/video"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:import namespace="http://www.iana.org/sdpng" schemaLocation="sdpng-base.xsd"/>
<xsd:complexType name="Codec">
<xsd:complexContent>
<xsd:restriction base="sdpng:Definition">
<xsd:all>
<xsd:element name="encoding" type="sdpng:token" minOccurs="0"/>
<xsd:element name="sampling" type="sdpng:tokenlist" minOccurs="0"/>
<xsd:element name="framerate" type="sdpng:opttokenlist" minOccurs="0"/>
<xsd:element name="size" type="sdpng:opttokenlist" minOccurs="0"/>
<xsd:element name="bitrate" type="sdpng:optnumrange" minOccurs="0"/>
<xsd:element name="min-quant" type="sdpng:optnum" minOccurs="0"/>
<xsd:element name="max-quant" type="sdpng:optnum" minOccurs="0"/>
<xsd:element name="gop-size" type="sdpng:optnum" minOccurs="0"/>
</xsd:all>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="codec" type="video:Codec" substitutionGroup="sdpng:definition"/>
</xsd:schema>
Appendix C. Sample SDPng Description
<?xml version="1.0" encoding="UTF-8"?>
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:video="http://www.iana.org/sdpng/video"
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/video sdpng-video-pkg.xsd
http://www.iana.org/sdpng/rtp sdpng-rtp-pkg.xsd"
>
<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>
<audio:codec name="avp:g723">
<audio:encoding>G723</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:dvi4">
<audio:encoding>DVI4</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000 11025 16000 22050</audio:sampling>
</audio:codec>
<audio:codec name="avp:lpc">
<audio:encoding>LPC</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:g722">
<audio:encoding>G722</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:l16">
<audio:encoding>L16</audio:encoding>
<audio:channels>1 2</audio:channels>
<audio:sampling>44100</audio:sampling>
</audio:codec>
<audio:codec name="avp:qcelp">
<audio:encoding>QCELP</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:cn">
<audio:encoding>CN</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:mpa">
<audio:encoding>MPA</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>32000 44100 48000</audio:sampling>
</audio:codec>
<audio:codec name="avp:g728">
<audio:encoding>G728</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:g729">
<audio:encoding>G728</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:g726-40">
<audio:encoding>G726-40</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:g726-32">
<audio:encoding>G726-32</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:g726-24">
<audio:encoding>G726-24</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:g726-16">
<audio:encoding>G726-16</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:g729d">
<audio:encoding>G729D</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:g729e">
<audio:encoding>G729E</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:gsm-efr">
<audio:encoding>GSM-EFR</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>8000</audio:sampling>
</audio:codec>
<audio:codec name="avp:l8">
<audio:encoding>L8</audio:encoding>
<audio:channels>1 2</audio:channels>
<audio:sampling>8000 16000</audio:sampling>
</audio:codec>
<audio:codec name="avp:red">
<audio:encoding>RED</audio:encoding>
<audio:channels>1 2</audio:channels>
<audio:sampling>8000 16000</audio:sampling>
</audio:codec>
<audio:codec name="avp:vdvi">
<audio:encoding>RED</audio:encoding>
<audio:channels>1</audio:channels>
<audio:sampling>var</audio:sampling>
</audio:codec>
<video:codec name="avp:celb">
<video:encoding>CelB</video:encoding>
<video:framerate>4 6 8 12 16 20 24 30</video:framerate>
</video:codec>
<rtp:udp name="rtpudpip6">
<rtp:network>IP6</rtp:network>
</rtp:udp>
</cap>
<def>
<rtp:udp name="rtp-cfg1" ref="rtpudpip6">
<rtp:ip-addr>::1</rtp:ip-addr>
<rtp:rtp-port>9546</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>
</component>
</cfg>
</sdpng>
Appendix D. Use of SDPng in Conjunction with other IETF Signaling
Protocols 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 The SDPng model provides the notion of Components to indicate the
intended types of collaboration between the users in e.g. a intended types of collaboration between the users in e.g. a
teleconferencing scenario. teleconferencing scenario.
Three different abstractions are defined that are used for describing Three different abstractions are defined that are used for describing
the properties of a specific Component: the properties of a specific Component:
o a Capability refers to the fact that one of the involved parties o a Capability refers to the fact that one of the involved parties
supports one particular way of exchanging media -- defined in supports one particular way of exchanging media -- defined in
terms of transport, codec, and other parameters -- as part of the terms of transport, codec, and other parameters -- as part of the
media session. media session.
o a Potential Configuration denotes a set of matching Capabilities o a Potential Configuration denotes a set of matching Capabilities
from all those involved parties required to successfully realize from all those involved parties that may be used for one
one particular Component. particular Component.
o an Actual Configuration indicates the Potential Configuration o an Actual Configuration indicates the Potential Configuration(s)
which was chosen by the involved parties to realize a certain and its associated media session parameters which was/were chosen
Component at one particular point in time. by the involved parties to instantiate a certain Component.
As mentioned before, this abstract notion of the interactions between As mentioned before, this abstract notion of the interactions between
a number of communicating systems needs to be mapped to the a number of communicating systems needs to be mapped to the
application scenarios of SDPng in conjunction with the various IETF application scenarios of SDPng in conjunction with the various IETF
signaling protocols: SAP, SIP, RTSP, and MEGACO. signaling protocols, including (but not limited to) SAP, SIP, RTSP,
and MEGACO.
In general, this section provides recommendations and possible In general, this section provides recommendations and possible
scenarios for the use of SDPng within specific protocols and scenarios for the use of SDPng within specific protocols and
applications. Is does not specify normative requirements. applications. Is does not specify normative requirements.
A.1 The Session Announcement Protocol (SAP) D.1 The Session Announcement Protocol (SAP)
SAP is used to disseminate a previously created (and typically fixed) SAP is used to disseminate a previously created (and typically fixed)
session description to a potentially large audience. An interested session description to a potentially large audience. An interested
member of the audience will use the SDPng description contained in member of the audience will use the SDPng description contained in
SAP to join the announced media sessions. SAP to join the announced media sessions.
This means that a SAP announcement contains the Actual Configurations This means that a SAP announcement contains the Actual Configurations
of all Components that are part of the overall teleconference or of all Components that are part of the overall teleconference or
broadcast. broadcast.
A SAP announcement may contain multiple Actual Configurations for the A SAP announcement may contain multiple Actual Configurations for the
same Component. In this case, the "same" (i.e. semantically same Component. In this case, the "same" (i.e. semantically
equivalent) media data from one configuration must be available from equivalent) media data from one configuration must be available from
each of the Actual Configurations. In practice, this limits the use each of the Actual Configurations.
of multiple Actual Configurations to single-source multicast or
broadcast scenarios.
Each receiver of a SAP announcement with SDPng compares its locally Each receiver of a SAP announcement with SDPng compares its locally
stored Capabilities to realize a certain Component against the Actual stored Capabilities to realize a certain Component against the Actual
Configurations contained in the announcement. If the intersection Configurations contained in the announcement. If the intersection
yields one or more Potential Configurations for the receiver, it yields one or more Potential Configurations for the receiver, it
chooses the one it sees fit best. If the intersection is empty, the chooses the one it sees fit best. If the intersection is empty, the
receiver cannot participate in the announced session. receiver cannot participate in the announced session.
SAP may be substituted by HTTP (in the general case, at least), SMTP, SAP may be substituted by HTTP (in the general case, at least), SMTP,
NNTP, or other IETF protocols suitable for conveying a media NNTP, or other IETF protocols suitable for conveying a media
description from one entity to one or more other without the intend description from one entity to one or more other without the intend
for further negotiation of the session parameters. for further negotiation of the session parameters.
Example from the SAP spec. to be provided. 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.
A.2 Session Initiation Protocol (SIP) D.2 Session Initiation Protocol (SIP)
SIP is used to establish and modify multimedia sessions, and SDPng SIP is used to establish and modify multimedia sessions, and SDPng
may be carried at least in SIP INVITE and ACK messages as well as in may be carried at least in SIP INVITE, ACK and UPDATE messages as
a number of responses. From dealing with legacy SDP (and its well as in a number of responses. From dealing with legacy SDP (and
essential non-suitability for capability negotiation), a particular its essential non-suitability for capability negotiation), a
use and interpretation of SDP has been defined for SIP. 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 One of the important flexibilities introduced by SIP's usage of SDP
is that a sender can change dynamically between all codecs that a is that a sender can change dynamically between all codecs that a
receiver has indicated support (and has provided an address) for. receiver has indicated support (and has provided an address) for.
Codec changes are not signaled out-of-band but only indicated by the Codec changes are not signaled out-of-band but only indicated by the
payload type within the media stream. From this arises one important payload type within the media stream. From this arises one important
consequence to the conceptual view of a Component within SDPng. consequence to the conceptual view of a Component within SDPng.
There is no clear distinction between Potential and Actual There is no clear distinction between Potential and Actual
Configurations. There need not be a single Actual Configuration be Configurations. There need not be a single Actual Configuration
chosen at setup time within the SIP signaling. Instead, a number of chosen at setup time within the SIP signaling. Instead, a number of
Potential Configurations is signaled in SIP (with all transport Potential Configurations is signaled in SIP (with all transport
parameters required for carrying media streams) and the Actual parameters required for carrying media streams) and the Actual
Configuration is only identified by the payload type which is Configuration is only identified by the payload type which is
actually being transmitted at any point in time. actually being transmitted at any point in time.
Note that since SDPng does not explicitly distinguish between Note that since SDPng does not distinguish between Potential and
Potential and Actual Configurations, this has no implications on the Actual Configurations at the syntax, this has no implications on the
SDPng signaling itself. SDPng signaling itself.
SIP relies on an "offer/answer" model for the exchange of capability SIP relies on an "offer/answer" model for the exchange of capability
and configuration information. Either the caller or the callee sends and configuration information. Either the caller or the callee sends
an initial session description that is processed by the other side an initial session description that is processed by the other side
and returned. For capability negotiation, this means that the and returned. For capability negotiation, this means that the
negotiation follows a two-stage-process: The "offerer" sends its negotiation follows a two-stage-process: The "offerer" sends its
capability description to the receiver. The receiver processes the capability description to the receiver. The receiver processes the
offerers capabilities and his own capabilities and generates a result offerers capabilities and his own capabilities and generates a result
capability description that is sent back to the offerer. Both sides capability description that is sent back to the offerer. Both sides
now know the commonly supported configurations and can initiate the now know the commonly supported configurations and can initiate the
media sessions. media sessions.
Because of this strict "offer/answer" model, the offerer must already Because of this strict "offer/answer" model, the offerer must already
send complete configurations (i.e. include transport addresses) send complete configurations (i.e. include transport addresses) along
along with the capability descriptions. The answer must also contain with the capability descriptions. The answer must also contain
complete configuration parameters. The following figure shows, how complete configuration parameters. The following figure shows, how
SDPng content can be used in an INVITE request with a correspong 200 SDPng content can be used in an INVITE request with a correspong 200
OK message. OK message.
Simple description document with only one alternative: Simple description document with only one alternative:
F1 INVITE A -> B F1 INVITE A -> B
INVITE sip:B@example.com SIP/2.0 INVITE sip:B@example.com SIP/2.0
Via: SIP/2.0/UDP hostA.example.com:5060 Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com> From: A <sip:A@example.com>
To: B <sip:B@example.com> To: B <sip:B@example.com>
Call-ID: 1234@hostA.example.com Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:UserA@192.168.1.1> Contact: <sip:UserA@192.168.1.1>
Content-Type: application/sdpng Content-Type: application/sdpng
Content-Length: 685 Content-Length: 685
<def> <?xml version="1.0" encoding="UTF-8"?>
<audio:codec name="audio-basic" encoding="PCMU"
sampling="8000" channels="1"/>
<rtp:pt name="rtp-avp-0" pt="0"> <sdpng xmlns="http://www.iana.org/sdpng"
<audio:codec ref="audio-basic"/> xmlns:audio="http://www.iana.org/sdpng/audio"
</rtp:pt> xmlns:rtp="http://www.iana.org/sdpng/rtp"
</def> 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> <cfg>
<component name="interactive-audio" media="audio"> <component>
<alt name="AVP-audio-0"> <alt>
<rtp:session> <audio:codec ref="avp:pcmu"/>
<rtp:pt ref="rtp-avp-0"/> <rtp:udp ref="rtp-cfg1">
<rtp:udp role="receive" endpoint="A" addr="192.168.1.1" <rtp:pt>0</rtp:pt>
rtp-port="7800"/> </rtp:udp>
</rtp:session> </alt>
<alt>
<audio:codec ref="avp:gsm"/>
<rtp:udp ref="rtp-cfg1">
<rtp:pt>3</rtp:pt>
</rtp:udp>
</alt> </alt>
</component> </component>
</cfg> </cfg>
<conf> </sdpng>
<owner user="A@example.com" id="98765432" version="1" nettype="IN"
addrtype="IP4" addr="192.168.1.1"/>
<session name="SDPng questions">
</session>
<info name="interactive-audio" function="voice">
Telephony media stream
<info>
</conf>
================================================== ==================================================
F2 (100 Trying) B -> A F2 (100 Trying) B -> A
SIP/2.0 100 Trying SIP/2.0 100 Trying
Via: SIP/2.0/UDP hostA.example.com:5060 Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com> From: A <sip:A@example.com>
To: B <sip:B@example.com> To: B <sip:B@example.com>
Call-ID: 1234@hostA.example.com Call-ID: 1234@hostA.example.com
skipping to change at page 40, line 4 skipping to change at page 56, line 29
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP hostA.example.com:5060 Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com> From: A <sip:A@example.com>
To: B <sip:B@example.com>;tag=987654 To: B <sip:B@example.com>;tag=987654
Call-ID: 1234@hostA.example.com Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:B@192.168.1.2> Contact: <sip:B@192.168.1.2>
Content-Type: application/sdpng Content-Type: application/sdpng
Content-Length: 479 Content-Length: 479
<def>
<audio:codec name="audio-basic" encoding="PCMU"
sampling="8000" channels="1"/>
<rtp:pt name="rtp-avp-0" pt="0"> <?xml version="1.0" encoding="UTF-8"?>
<audio:codec ref="audio-basic"/>
</rtp:pt>
</def>
<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> <cfg>
<component name="interactive-audio" media="audio"> <component>
<alt name="AVP-audio-0"> <alt>
<rtp:session> <audio:codec ref="avp:gsm"/>
<rtp:pt ref="rtp-avp-0"/> <rtp:udp ref="rtp-cfg1">
<rtp:udp role="receive" endpoint="A" addr="192.168.1.1" <rtp:pt>3</rtp:pt>
rtp-port="7800"/> </rtp:udp>
<rtp:udp role="receive" endpoint="B" addr="192.168.1.2"
rtp-port="9410"/>
</rtp:session>
</alt> </alt>
</component> </component>
</cfg> </cfg>
</sdpng>
================================================== ==================================================
ACK from A to B omitted ACK from A to B omitted
In the INVITE message, A sends B a description document, that In the INVITE message, A sends B a description document that
specifies exactly one component with one alternative (the PCMU audio specifies exactly one component with two alternatives (the PCMU and
stream). All required transport parameters all already contained in GSM audio streams). The alternatives make reference to the
the description. The rtp:udp element provides an attribute "role" capability section where the two codec types are defined. All
with a value of "receive", indicating that the specified endpoint required transport parameters all already contained in the respective
address is used by the endpoint to receive media data. The element descriptions. The <def> element contains a definition for the RTP
also provides the attribute "endpoint" with a value of "A", media sessions so that this needs not be repeated in the
denominating the endpoint that can receive data on the specified configuration of the single component. Note that the semantics of
address. This means, the semantics of specified transport addresses the component is not explicitly specified (in an <info> element) but
in configuration descriptions are the same as for SDP (when used with rather implied.
SIP): An endpoint specifies where it wants to receive data.
In the 200 OK message, B sends an updated description document to A. In the 200 OK message, B sends an updated description document to A.
For the sake of conciseness, the conf element (containing meta B supports the payload format that A has offered and adds his own
information about the conference) has been omitted. B supports the transport parameters to the configuration information, specifying the
payload format that A has offered and adds his own transport endpoint address where B wants to receive media data. In order to
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 disambiguate its transport configurations from A's, B sets the
attribute "endpoint" to the value "B". The specific value of the attribute "endpoint" to the value "B". The specific value of the
"endpoint" attribute is not important, the only requirements are that "endpoint" attribute is not important, the only requirements are that
a party that contributes to the session description, must use a a party that contributes to the session description, must use a
unique name for the endpoint attribute and that a contributing party unique name for the endpoint attribute and that a contributing party
must use the same value for the endpoint attributes of all elements must use the same value for the endpoint attributes of all elements
it adds to the session description. it adds to the session description.
The following example shows a capability description that provides D.3 Real-Time Streaming Protocol (RTSP)
two alternatives for the audio component.
Description document with two alternatives:
F1 INVITE A -> B 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.
INVITE sip:B@example.com SIP/2.0 Hence, SDPng is only used to describe alternatives to gain access to
Via: SIP/2.0/UDP hostA.example.com:5060 streaming media out of which the client has to choose. No
From: A <sip:A@example.com> interaction takes place at the SDPng level.
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: 935
<def> C->M: DESCRIBE rtsp://foo/audio-play RTSP/1.0
<audio:codec name="audio-basic" encoding="PCMU" CSeq: 1
sampling="8000" channels="1"/>
<audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/> M->C: RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: ...
<rtp:pt name="rtp-avp-0" pt="0"> <sdpng xmlns="http://www.iana.org/sdpng"
<audio:codec ref="audio-basic"/> xmlns:audio="http://www.iana.org/sdpng/audio"
</rtp:pt> 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"
<rtp:pt name="rtp-avp-18" pt="18"> owner="A@example.com" id="98765432" version="1"
<audio:codec ref="g729"/> >
</rtp:pt>
<rtp:udp name="A-rcv" role="receive" endpoint="A" addr="192.168.1.1" <cap>
rtp-port="7800"/> <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> </def>
<cfg> <cfg>
<component name="interactive-audio" media="audio"> <component>
<alt name="AVP-audio-0"> <alt>
<rtp:session format="rtp-avp-0"> <audio:codec ref="avp:pcmu"/>
<rtp:udp ref="A-rcv"/> <rtp:udp ref="rtp-cfg1">
</rtp:session> <rtp:pt>0</rtp:pt>
</rtp:udp>
</alt> </alt>
<alt name="AVP-audio-18"> <alt>
<rtp:session format="rtp-avp-18"/> <audio:codec ref="avp:gsm"/>
<rtp:udp ref="A-rcv"/> <rtp:udp ref="rtp-cfg1">
</rtp:session> <rtp:pt>3</rtp:pt>
</rtp:udp>
</alt> </alt>
</component> </component>
</cfg> </cfg>
</sdpng>
<conf> C->M: SETUP rtsp://foo/audio-play RTSP/1.0
<owner user="A@example.com" id="98765432" version="1" nettype="IN" CSeq: 2
addrtype="IP4" addr="192.168.1.1"/> Transport: RTP/AVP;unicast;client_port=8000-8001
<session name="SDPng questions">
</session>
<info name="interactive-audio" function="voice">
Telephony media stream
<info>
</conf>
==================================================
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
================================================== M->C: RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001;
server_port=51400-51401
Session: 12345678
F3 180 Ringing B -> A To be continued with PLAY and, after the audio track has completed,
finished with TEARDOWN.
SIP/2.0 180 Ringing D.4 Media Gateway Control Protocol (MEGACOP)
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
================================================== The MEGACO architecture also follows the SDPng model of a clear
F4 200 OK B -> A separation between Potential and Actual Configurations. Upon startup,
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.
SIP/2.0 200 OK Details and examples to be defined in a separate document.
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
<def> Appendix E. Change History
<audio:codec name="audio-basic" encoding="PCMU"
sampling="8000" channels="1"/>
<audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/> draft-ietf-mmusic-sdpng-07.txt
<rtp:pt name="rtp-avp-0" pt="0"> * New document structure:
<audio:codec ref="audio-basic"/>
</rtp:pt>
<rtp:pt name="rtp-avp-18" pt="18"> 1. Intro
<audio:codec ref="g729"/>
</rtp:pt>
<rtp:udp name="A-rcv" role="receive" endpoint="A" addr="192.168.1.1" 2. Terminology and System Model
rtp-port="7800"/>
<rtp:udp name="B-rcv" role="receive" endpoint="B" addr="192.168.1.2" 3. Overview
rtp-port="9410"/>
</def>
<cfg> 4. SDPng Syntax Specification
<component name="interactive-audio" media="audio">
<alt name="AVP-audio-0">
<rtp:session format="rtp-avp-0">
<rtp:udp ref="A-rcv"/>
<rtp:udp ref="B-rcv"/>
</rtp:session>
</alt>
</component>
</cfg>
==================================================
ACK from A to B omitted 5. Negotiation Process
In the INVITE message, A sends B a description document, that
specifies one component with two alternatives for the audio stream
(PCMU and G.729). Since A wants to use the same transport address
for receiving media data regardless of the payload format, A provides
the transport specification in the def element and references this
definition in the rtp:session elements for both alternatives by using
the attribute "transport".
In the 200 OK message, B sends an updated description document to A. * Changes to Section 3: Describe all concepts
B does only support PCMU, so it removes the alternative for G.729
from the description. B also defines its transport address in the
def element and references this definition by referencing the rtp:udp
element named "B-rcv".
A.3 Real-Time Streaming Protocol (RTSP) * Section 4 provides complete specification
In contrast to SIP, RTSP has, from its intended usage, a clear * Changed XML syntax: Represent tokens and token list as element
distinction between offering Potential Configurations (typically by content (not attributes)
the server) and choosing one out of these (by the client), and, in
some cases; some parameters (such as multicast addresses) may be
dictated by the server. Hence with RTSP, there is a clear
distinguish between Potential Configurations during the negotiation
phase and a finally chosen Actual Configuration according to which
streaming will take place.
Example from the RTSP spec to be provided. * a new element "def" for reusable definitions
A.4 Media Gateway Control Protocol (MEGACOP) * Adapted secion 5 accordingly
The MEGACO architecture also follows the SDPng model of a clear * Sample DTD, schema definition and same SDPng document in
separation between Potential and Actual Configurations. Upon appendix
startup, 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. * Updated section 5.1 (Offer/Answer)
Appendix B. Change History * Updated appendix D (Use of SDPng in conjunction with other IETF
Signaling Protocols)
draft-ietf-mmusic-sdpng-06.txt draft-ietf-mmusic-sdpng-06.txt
* Removed section on capability negotiation algorithm and section * Removed section on capability negotiation algorithm and section
on formal specification. Added Section 3. on formal specification. Added Section 3.
* Removed specification of concrete XML syntax from Section 4. * Removed specification of concrete XML syntax from Section 4.
Added requirements and theoretic considerations. Added requirements and theoretic considerations.
* Added clarification of term "actual configuration" in Section * Added clarification of term "actual configuration" in Section
2. 2.
* Changed "profile" to "package". * Changed "profile" to "package".
* Added introducing text to Section 4.1.
* 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 Section 5 ("Syntax Definition"). * Added a section "Syntax Definition".
* Added Section 6 ("Specification of the Capability * Added Section 5 ("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
referenced existing definitions (Section 4.3). Removed other referenced existing definitions. Removed other mechanisms for
mechanisms for referencing (attributes "format" and referencing (attributes "format" and "transport", element type
"transport", element type "use"). "use").
* Corrections to schema definitions and examples * Corrections to schema definitions and examples
draft-ietf-mmusic-sdpng-04.txt draft-ietf-mmusic-sdpng-04.txt
* New section on capability negotiation. * New section on capability negotiation.
* New section on referencing definitions (Section 4.3). * New section on referencing definitions.
* New section on properties. * New section on properties.
* New section on definition groups. * New section on definition groups.
draft-ietf-mmusic-sdpng-03.txt draft-ietf-mmusic-sdpng-03.txt
* Extension of the SDPng schema (use of Xlinks etc.) * Extension of the SDPng schema (use of Xlinks etc.)
* Clarification in the text * Clarification in the text
skipping to change at page 47, line 5 skipping to change at page 64, line 5
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
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. 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 is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 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/