draft-ietf-mmusic-sdpng-05.txt   draft-ietf-mmusic-sdpng-06.txt 
Network Working Group Kutscher Network Working Group Kutscher
Internet-Draft Ott Internet-Draft Ott
Expires: December 30, 2002 Bormann Expires: September 1, 2003 Bormann
TZI, Universitaet Bremen TZI, Universitaet Bremen
July 01, 2002 March 03, 2003
Session Description and Capability Negotiation Session Description and Capability Negotiation
draft-ietf-mmusic-sdpng-05.txt draft-ietf-mmusic-sdpng-06.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 groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at 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 December 30, 2002. This Internet-Draft will expire on September 1, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). 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 end-
systems. 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: 4.12 $ $Revision: 6.9 $
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and System Model . . . . . . . . . . . . . . . 6 2. Terminology and System Model . . . . . . . . . . . . . . . . 5
3. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Capability Negotiation: Overview and Requirements . . . . . 9
3.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . 9 3.1 Outline of the Negotiation Process . . . . . . . . . . . . . 9
3.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 The Negotiation Process . . . . . . . . . . . . . . . . . . 11
3.1.2 Components & Configurations . . . . . . . . . . . . . . . 11 4. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . 13 4.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . . 12
3.1.4 Session Attributes . . . . . . . . . . . . . . . . . . . . 14 4.1.1 Potential Configurations . . . . . . . . . . . . . . . . . . 13
3.1.4.1 Owner . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.2 Actual Configurations . . . . . . . . . . . . . . . . . . . 15
3.1.4.2 Session Identification . . . . . . . . . . . . . . . . . . 15 4.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) . . . 16 4.1.4 Meta Information . . . . . . . . . . . . . . . . . . . . . . 18
3.1.4.4 Component Semantic Specification . . . . . . . . . . . . . 17 4.2 Syntax Definition Mechanisms . . . . . . . . . . . . . . . . 18
3.2 Syntax Definition Mechanisms . . . . . . . . . . . . . . . 17 4.3 Referencing Definitions . . . . . . . . . . . . . . . . . . 20
3.3 Referencing Definitions . . . . . . . . . . . . . . . . . 20 4.4 External Definition Packages . . . . . . . . . . . . . . . . 20
3.3.1 The attribute "ref" . . . . . . . . . . . . . . . . . . . 21 4.4.1 Package Definitions . . . . . . . . . . . . . . . . . . . . 20
3.4 External Definition Packages . . . . . . . . . . . . . . . 22 4.4.2 Library Definitions . . . . . . . . . . . . . . . . . . . . 21
3.4.1 Profile Definitions . . . . . . . . . . . . . . . . . . . 22 4.5 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.2 Library Definitions . . . . . . . . . . . . . . . . . . . 23 5. Syntax Definition . . . . . . . . . . . . . . . . . . . . . 23
3.5 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1 Potential Configurations . . . . . . . . . . . . . . . . . . 23
4. Capability Negotiation . . . . . . . . . . . . . . . . . . 26 6. Specification of the Capability Negotiation . . . . . . . . 26
4.1 Outline of the Negotiation Process . . . . . . . . . . . . 26 6.1 Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 The Collapsing Algorithm . . . . . . . . . . . . . . . . . 28 6.2 RFC2533 Negotiation . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Collapsing Two Configurations . . . . . . . . . . . . . . 29 6.2.1 Translating SDPng to RFC 2533 Expressions . . . . . . . . . 27
4.2.1.1 Collapsing of Attributes . . . . . . . . . . . . . . . . . 29 6.2.2 Applying RFC 2533 Canonicalization . . . . . . . . . . . . . 29
4.2.1.2 Collapsing two Elements . . . . . . . . . . . . . . . . . 32 6.2.3 Integrating Feature Sets into SDPng . . . . . . . . . . . . 30
4.2.1.3 Collapsing nested Elements . . . . . . . . . . . . . . . . 33 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.2 Deriving an actual Configuration . . . . . . . . . . . . . 35 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
5. Formal Specification . . . . . . . . . . . . . . . . . . . 36 References . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1 XML Schema as a Definition Mechanism . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34
5.2 SDPng Schema . . . . . . . . . . . . . . . . . . . . . . . 37 A. Use of SDPng in conjunction with other IETF Signaling
5.3 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 38 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4 SDPng Documents . . . . . . . . . . . . . . . . . . . . . 39 A.1 The Session Announcement Protocol (SAP) . . . . . . . . . . 36
5.5 Libraries . . . . . . . . . . . . . . . . . . . . . . . . 40 A.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . . 37
5.6 Details on the use of specific XML Mechanisms . . . . . . 41 A.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . . 44
5.6.1 Default Namespace . . . . . . . . . . . . . . . . . . . . 41 A.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . . 44
5.6.2 Qualified Locals . . . . . . . . . . . . . . . . . . . . . 41 B. Change History . . . . . . . . . . . . . . . . . . . . . . . 45
5.6.3 Fixed Namespace Prefixes . . . . . . . . . . . . . . . . . 42 Full Copyright Statement . . . . . . . . . . . . . . . . . . 47
5.7 SDPng Schema Definitions . . . . . . . . . . . . . . . . . 42
5.7.1 SDPng Base Definition . . . . . . . . . . . . . . . . . . 42
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 50
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 51
References . . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53
A. SDPng Audio Codec Profile and Audio Codec Library . . . . 55
A.1 Audio Codec Profile . . . . . . . . . . . . . . . . . . . 55
A.2 SDPng Library for Audio Codec Definitions . . . . . . . . 57
A.2.1 DVI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.2.2 G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.2.3 G.726 . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.2.4 G.728 . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.2.5 G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.2.6 G.729 Annex D and E . . . . . . . . . . . . . . . . . . . 59
A.2.7 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.2.7.1 GSM Full Rate . . . . . . . . . . . . . . . . . . . . . . 59
A.2.7.2 GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . 60
A.2.7.3 GSM Enhanced Full Rate . . . . . . . . . . . . . . . . . . 60
A.2.8 L8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2.9 L16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2.10 LPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2.11 MPA . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2.12 PCMA and PCMU . . . . . . . . . . . . . . . . . . . . . . 61
A.2.13 QCELP . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.2.14 VDVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
B. SDPng Profile for RTP Profile and RTP Library . . . . . . 63
B.1 RTP profile . . . . . . . . . . . . . . . . . . . . . . . 63
B.2 SDPng Library for RTP Payload Format Definitions . . . . . 65
C. Use of SDPng in conjunction with other IETF Signaling
Protocols . . . . . . . . . . . . . . . . . . . . . . . . 67
C.1 The Session Announcement Protocol (SAP) . . . . . . . . . 67
C.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . 68
C.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . 75
C.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . 75
D. Change History . . . . . . . . . . . . . . . . . . . . . . 76
Full Copyright Statement . . . . . . . . . . . . . . . . . 78
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 5, line 18 skipping to change at page 4, line 18
o to describe the capabilities of a system and possibly provide a o to describe the capabilities of a system and possibly provide a
choice between a number of alternatives (which SDP was not choice between a number of alternatives (which SDP was not
designed for). designed for).
A distinction between these two "sets of semantics" is only made A distinction between these two "sets of semantics" 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). Next, we basic terms used throughout this specification (Section 2). In
outline the concept for the concepts underlying SDPng and introduce Section 3, we provide an overview of options for capability
the syntactical components step by step in section 3. In section 4, negotiation. Next, we outline the concept for the concepts
we provide a formal definition of the SDPng session description underlying SDPng and introduce the syntactical components step by
language. Finally, we overview aspects of using SDPng with various step in Section 4.
IETF signaling protocols in section 5. In Appendix A, we provide
basic audio codec and payload type definitions that are subsumed in Appendix B lists the change history.
SDPng libraries in Appendix A.2 and Appendix B.2.
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 and restricted by these resources "system capabilities". enabled 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
skipping to change at page 7, line 21 skipping to change at page 6, line 21
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 u-Law, packetization and redundancy parameters, etc. or u-Law, packetization and redundancy parameters, etc.
In modelling 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.
skipping to change at page 8, line 27 skipping to change at page 7, line 27
To decide on a certain actual configuration, a negotiation process To decide on a certain actual configuration, a negotiation process
needs to take place between the involved peers: needs to take place between the involved peers:
1. to determine which potential configuration(s) they have in 1. to determine which potential configuration(s) they have in
common, and common, and
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
application-specific. For example, for audio transport using RTP, an
actual configuration is equivalent to a payload format (potentially
plus format parameters), whereas for other applications it may be a
MIME type.
In SAP-based [9] session announcements on the Mbone, for which SDP In SAP-based [9] 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 receiver must understand to participate. a 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.
skipping to change at page 9, line 5 skipping to change at page 8, line 10
For instance, in order to be used with SIP, the capability For instance, in order to be used with SIP, the capability
negotiation is required to work with the offer/answer model that is negotiation is required to work with the offer/answer model that is
for session initiation with SIP -- limiting the negotiation to for session initiation with SIP -- limiting the negotiation to
exactly one round trip. exactly one round trip.
The requirements for the SDPng specification, subdivided into general 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].
3. SDPng The following list explains some terms used in this document:
This section introduces the underlying concepts of the Session Actual Configuration
Description Protocol - next generation (SDPng). The focus of this An actual configuration is an "instantiation" of one of the
section is on the concepts of the capability description and potential configurations, i.e. a decision how to realize a
negotiation language with a stepwise introduction of the various certain component.
syntactical elements. Note that this section only provides examples
accompanied by explanations -- a complete formal specification is
provided in section 4.
3.1 Conceptual Outline Component
A component describes a particular type of interaction (e.g.
audio conversation, slide presentation) that can be realized by
means of different applications (possibly using different
protocols).
The concept of a capability description language addresses various Library
pieces of a full description of system and application capabilities A library is a application specific collection of potential
in four separate "sections": configuration definition. For example, the RTP-AVP library would
include definitions for the audio and video codecs of the RTP
audio/video profile (AVP).
Definitions (elementary and compound); see Section 3.1.1. Package
A package is application specific data schema for expressing
potential and actual configurations. For example, an audio
package specifies the data schema for audio codecs.
Potential or Actual Configurations; see Section 3.1.2. Potential Configuration
Potential configurations describe possible configurations that are
supported by an end-system ("capabilities").
Constraints; see Section 3.1.3. 3. Capability Negotiation: Overview and Requirements
Session attributes; see Section 3.1.4. SDPng is a description language for both potential configurations
(i.e. capabilities) of participants in multimedia conferences and
for actual configurations (i.e. final specifications of parameters).
Capability negotiation is the process of generating a usable set of
potential configurations and finally an actual configuration from a
set of potential configurations provided by each potential
participant in a multimedia conference.
3.1.1 Definitions SDPng supports the specification of endpoint capabilities and defines
a negotiation process: In a negotiation process, capability
descriptions are exchanged between participants. These descriptions
are processed in a "collapsing" step which results in a set of
commonly supported potential configurations. In a second step, the
final actual configuration is determined that is used for a
conference. This section specifies the usage of SDPng for capability
negotiation. It defines the collapsing algorithm and the procedures
for exchanging SDPng documents in a negotiation phase.
The "Definitions" section specifies a number of basic abstractions The description language and the rules for the negotiation phase that
that are later referenced to avoid repetitions in more complex are defined here are (in general) independent of the means by which
specifications and allow for a concise representation. Definition descriptions are conveyed during a negotiation phase (a reliable
elements are labelled with an identifier by which they may be transport service with causal ordering is assumed). There are
referenced. They may be elementary or compound (i.e. combinations however properties and requirements of call signaling protocols that
of elementary entities). Examples of definitions that could occur in have been considered to allow for a seamless integration of the
"Definitions" sections include (but are not limited to) codec negotiation into the call setup process. For example, in order to be
definitions, redundancy schemes, transport mechanisms and payload usable with SIP, it must be possible to negotiate the conference
formats. configuration within the two-way-handshake of the call setup phase.
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
configuration in a single request/response cycle.
Elementary definition elements do not reference other elements. Each 3.1 Outline of the Negotiation Process
elementary entity only consists of one of more attributes and their
values. Default values specified in the definition section may be
overridden in descriptions for potential (and later actual)
configurations. A mechanism for overriding definitions is specified
below.
For the moment, elementary abstractions are defined for media types Conceptually, the negotiation process comprises the following
(i.e. codecs) and for media transport mechanisms. For each individual steps (considering two parties, A and B, where A tries to
transport and for each codec to be used, the respective attributes invite B to a conference). Please note that this describes the steps
need to be defined. This definition may either be provided within of the negotiation process conceptually -- it does not specify
the "Definitions" section itself or in an external document (similar requirements for implementations. Specific procedures that MUST be
to the audio-video profile or an IANA registry that defines payload followed by implementations are given below.
types and media stream identifiers).
It is not required to define all codecs and transport mechanisms in a 1. A determines its potential configurations for the components that
"Definitions" sections and reference them when specifying potential should be used in the conference (e.g. "interactive audio" and
and actual configurations. Instead, a syntactic mechanism is defined "shared whiteboard") and sends a corresponding SDPng instance to
that allows to provide some definitions directly in a configurations B. This SDPng instances is denoted "CAP(A)".
section.
Examples for elementary definitions: 2. B receives A's SDPng instance and analyzes the set of components
(sdpng:c elements) in the description. For each component that B
wishes to support it generates a list of potential configurations
corresponding to B's capabilities, denoted "CAP(B)".
<audio:codec name="audio-basic" encoding="PCMU" 3. B applies the collapsing function and obtains a list of potential
sampling="8000" channels="1"/> configurations that both A and B can support, denoted
"CAP(A)xCAP(B) = CAP(AB)".
<audio:codec name="audio-L16-mono" encoding="L16" 4. B sends CAP(B) to A.
sampling="44100" channels="1"/>
The element type "audio:codec" is used in these examples to define 5. A also applies the collapsing function and obtains "CAP(AB)". At
audio codec configurations. The configuration parameters are given this step, both A and B know the capabilities of each other and
as attribute values. the potential configurations that both can support.
Definitions may have default values specified along with them for 6. In order to obtain an actual configuration from the potential
each attribute (as well as for their contents). Some of these configuration that has been obtained, both participants have to
default values may be overridden so that a codec definition can pick a subset of the potential configurations that should
easily be re-used in a different context (e.g. by specifying a actually be used in the conference and generate the actual
different sampling rate) without the need for a large number of base configuration. It should be noted that it depends on the
specifications. In the following example the definition of audio- specific application whether each component must be assigned
L16-mono is re-used for the defintion of the corresponding stereo exactly one actual configuration (one sdpng:alt element) or
codec. Appendix A provides a complete set of corresponding whether it is allowed to list multiple actual configurations. In
audio:codec definitions of the codecs used in RFC 1890 [4]. this model we assume that A selects the actual configuration,
denoted CFG(AB).
<audio:codec name="audio-L16-stereo" ref="audio-L16-mono" 7. A augments CFG(AB) with the transport parameters it intends to
channels="2"/> use, e.g., on which endpoint addresses A wishes to receive data,
obtaining CFG_T(A). A sends CFG_T(A) to A.
The example shows how existing definitions can be referenced in new 8. B receives CFG_T(A) and adds its own transport parameters,
definitions. This approach allows to create simple as well as more resulting in CFG_T(AB). CFG_T(AB) contains the selected actual
complex definitions in an extensible set of reference documents. The configurations and the transport parameters of both A and B (plus
attribute "use" is defined in Section 3.3. Section 3.4 specifies the any other SDPng data, e.g., meta-information on the conference).
mechanisms for external references. CFG_T(AB) is the complete conference description. Both A and B
now have the following information:
Besides definitions of audio codecs, other definitions such as RTP CAP(A) A's supported potential configurations
payload formats and specific transport mechanisms are suitable to be
defined in a definition section for later referencing. The following
example shows how RTP payload types are defined using a pre-defined
codec.
<rtp:pt name="rtp-avp-0" pt="0"> CAP(B) B's supported potential configurations
<audio:codec ref="audio-basic"/>
</rtp:pt>
<rtp:pt name="rtp-avp-11" pt="11"> CAP(AB) The set of potential configurations supported by both A
<audio:codec ref="audio-L16-mono"/> and B.
</rtp:pt>
In this example, the payload type "rtp-avp-11" is defined with CFG(AB) The set of actual configurations to be used.
payload type number 11, referencing the codec "audio-L16-mono".
Instead of referencing an existing definition it is also possible to
define the format "inline":
<rtp:pt name="rtp-avp-10" pt="10"> CFG_T(AB) The set of actual configurations to be used augmented
<audio:codec encoding="L16" sampling="44100" channels="2"/> with all required parameters.
</rtp:pt>
The "Definitions" section may be empty if all transport, codecs, and In this model, the capability negotiation and configuration exchange
other pieces needed to specify the Potential and Actual process leads to a description that represents a global view of the
Configurations (as detailed below) are either included by referencing configuration that should be used. This means, it contains the
external definitions or are explicitly described within the complete configuration for all participants including per-participant
Configurations themselves. information like transport parameters.
3.1.2 Components & Configurations 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
parameters are usually not negotiable, therefor they have to be
distinguished from other configuration information.
The "Configurations" section contains all the components that Specific procedures for re-negotiation and multi-party negotiation
constitute the multimedia application (IP telephone call, real-time will be defined in a future version of this document.
streaming application, multi-player gaming session etc.). For each
of these components, the potential and, later, 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). A potential and the actual
configuration of a component may be identical.
Each component is labelled with an identifier so that it can be 3.2 The Negotiation Process
referenced, e.g. to associate semantics with a particular media
stream. For such a component, any number of configurations may be
given with each configuration describing an alternative way to
realize the functionality of the respective component.
Each configuration (potential as well as actual) is labelled with an The algorithm for comparing two potential configurations and for
identifier. A configuration combines one or more (elementary and/or obtaining a commonly supported subset is application specific. For
compound) entities from the "Definitions" section to describe a some limited application scenarios, a application specific
potential or an actual configuration. Within the specification of offer/answer process may be employed such as the SDP offer/answer
the configuration, default values from the referenced entities may be model [16].
overwritten. In addition, it is also possible to provide definition
elements inline, inside the definition of a configuration.
Note: Not all protocol environments and their respective operation More advanced implementations require a generic capability
allow to explicitly distinguish between Potential and Actual negotiation mechanism that allows for application-independent
Configurations. Therefore, SDPng so far does not provide for negotiation of potential configuration with parameters from different
syntactical identification of a Configuration as being a Potential or application domains. Capability negotiation frameworks such as RFC
an Actual one. The semantics of configurations are to be determined 2533 [18] can be employed for this purpose. In a future version of
from the requirements of the specific protocol that uses SDPng to this document, we will discuss of employing a RFC 2533 based
express capabilities and configurations. negotiation process for comparing and matching capability
descriptions in SDPng documents.
The following example shows how RTP sessions can be described by 4. SDPng
referencing payload definitions:
<cfg> This section introduces the underlying concepts of the Session
<component name="interactive-audio" media="audio"> Description Protocol - next generation (SDPng). The focus of this
<alt name="AVP-audio-0"> section is on the concepts of the capability description language
<rtp:session> with a stepwise introduction of the various syntactical elements.
<rtp:pt ref="rtp-avp-0"/> Note that this section only provides examples accompanied by
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/> explanations. The description elements used in this section are not
</rtp:session> normative.
</alt>
<alt name= AVP-audio-11"> 4.1 Conceptual Outline
<rtp:session>
<rtp:pt ref="rtp-avp-11"/>
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
</rtp:session>
</alt>
</component>
</cfg>
For example, an IP telephone call may require just a single component In Section 2 we have distinguished between potential configurations
"name=interactive-audio" with two possible ways of implementing it. ("capabilities") and actual configurations ("session descriptions").
The two corresponding configurations are "AVP-audio-0" without SDPng provides the possibility to express potential configurations
modification, the other ("AVP-audio-11") uses linear 16-bit encoding. and actual configurations in one document. A potential configuration
Typically, transport address parameters such as the port number would list is used to declare capabilities and an actual configuration list
also be provided. In this example, this information is given by the is used to declare concrete configurations.
"rtp:udp" element. Of course, it must be possible to specify other
transport mechanisms as well. See Section 3.2 for a discussion of
extension mechanisms that allow applications to use non-standard
transport (or other) specifications.
During/after the negotiation phase, an actual configuration is chosen Potential configurations are described independently of actual
out of a number of alternative potential configurations, the actual configurations. In a "potential configurations" section, a user
configuration may refer to the potential configuration just by its agent lists its capabilities as a list of named definitions. For
"id", possibly allowing for some parameter modifications. negotiating capabilities from different user agents, the individual
Alternatively, the full actual configuration may be given. 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.
Instead of referencing existing payload type definitions it is also Actual configurations can refer to capabilities and specify concrete
possible to provide the required information directly in the rtp:pt parameters for application protocol sessions, including transport
element. The following example illustrates this: parameters. Actual configurations cannot be negotiated.
<cfg> When defining potential configurations, capabilities are never
<component name="audio1" media="audio"> expressed with respect to other potential configuration elements,
<alt name="AVP-audio-0"> e.g., the definition of an audio codec capability does not limit the
<rtp:session> capability of using other audio codec. Constraints like the
<rtp:pt pt="0"> simultaneous usage of capabilities can be expressed separately from
<audio:codec name="audio-basic" encoding="PCMU" the capabilities themselves.
sampling="8000" channels="1"/>
</rtp:pt>
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
</rtp:session>
</alt>
</component>
</cfg>
The UDP/IPv4 multicast transport that is used in the examples is a In addition, information about the communication session itself, such
simple variant of a transport specification. More complex ones are as scheduling, information on the semantics of application protocol
conceivable. For example, it must also be possible to specify the sessions and information on the user who has initiated a conference.
usage of source filters (inclusion and exclusion), Source Specific This information is expressed separately from the definition of
Multicast, the usage of multi-unicast, or other parameters such as potential and actual configurations.
QoS parameters. Therefore it is possible to extend the definition of
transport mechanisms by providing the required information in the
element content. An example:
<cfg> These different elements of session description are discussed in
<component name="audio1" media="audio"> detail in the following sections. There are four different elements:
<alt name="AVP-audio-0">
<rtp:session>
<rtp:pt ref="rtp-avp-0"/>
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801">
<option name="ssm" sender="sender.example.com"/>
</rtp:udp>
</rtp:session>
</alt>
</component>
</cfg>
Additional transport mechanisms and options will be defined in future Potential Configurations; see Section 4.1.1.
SDPng profile definition, not in the base specification.
3.1.3 Constraints Actual Configurations; see Section 4.1.2.
Definitions specify media, transport, and other capabilities, whereas Constraints; see Section 4.1.3.
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 Session meta information; see Section 4.1.4.
CPU cycles, DSP resources available, dedicated hardware, etc.) that
limit which of these configurations can be instantiated in parallel
(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.
Therefore, we introduce a "Constraints" section to contain these 4.1.1 Potential Configurations
additional limitations. Constraints refer to potential
configurations and to entity definitions and express and use simple
logic to express mutual exclusion, limit the number of
instantiations, and allow only certain combinations. The following
example shows the definition of a constraints that restricts the
maximum number of instantiation of two alternatives (that would have
to be defined in the configuration section before) when they are used
in parallel:
<constraints> A "Potential Configurations" section in an SDPng document lists
<par> individual capabilities, e.g., codec capabilities. In a capability
<use-alt ref="AVP-audio-11" max="5"> negotiation process these potential configurations may be compared to
<use-alt ref="AVP-video-32" max="1"> the potential configurations that are defined in an SDPng document
</par> from another participant. The outline of such a negotiation process
</constraints> is presented in Section 3.
As the example shows, constraints are defined by defining limits on Please note, that in the following examples, we use a straw-man
simultaneous instantiations of alternatives. They are not defined by syntax in order to discuss the concepts. A final syntax will be
expressing abstract end-system resources, such as CPU speed or memory formally defined in a future version of this document.
size.
By default, the "Constraints" section is empty (or missing) which These are two examples of elements in a potential configurations
means that no further restrictions apply. section:
3.1.4 Session Attributes audio:codec
name=audio-basic
encoding="PCMU"
sampling="8000"
channels="[1]"
The fourth and final section of the SDPng syntax is used to specify audio:codec
meta information such as session layer attributes. These attributes name="audio-L16-mono"
largely include those defined by SDP [RFC2327] (which are explicitly encoding="L16"
indicated in the following specification) to describe originator, sampling="44100"
purpose, and timing of a multimedia session among other channels="[1,2,4]"
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=" The following requirements can be stated for expressing potential
line), bandwidth information (SDP "b=" line), and encryption keys configurations:
(SDP "k=" lines) is deliberately not provided for in SDPng. The
relevant information can be specified directly in the Configuration
section for individual alternatives.
3.1.4.1 Owner o It must be possible to name potential configuration elements. In
the example above, this is achieved by the property "name". Names
MUST NOT be considered in a capability negotiation process.
The owner refers to the creator of a session as defined in RFC2327 o The potential configuration elements are referred to by this name
("o=" line). The syntax is as follows: 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.
<owner user="username" session-id="session-id" version="version" o The properties of a given potential configuration element MUST
nettype="IN" addrtype="IP4" addr="192.168.1.1"/> have a well-defined type. For example, codec type names are
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.
The owner element must be present if SDPng is used with SAP. For all o User agents MUST be able to infer the type of a given property
other protocols, the owner element is not necessarily required. The without referring to an external schema definition, i.e., the type
attributes listed above match those from the SDP specification; all must be specified either implicitly or explicitly. Note, that in
attributes must be present and they are used following the rules of the example above, the type is not specified.
RFC2327.
The owner element is an empty element. o In addition to the data type and its value a property can provide
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.
3.1.4.2 Session Identification o Some capabilities such as codec capabilities may be associated
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.
The "session" element is used to identify the session and to provide With these requirements in mind, we add additional characteristics to
a description and possible further references. It provides the the properties in potential configuration descriptions (and change
following attributes: the encoding for the second potential configuration element):
name: The session name as it is to appear e.g. in a session audio:codec
directory. This is equivalent to the SDP "s=" line. name=audio-basic;type=name
encoding="PCMU";type=string
sampling="8000";type=maximum-limit
channels="[1]";type=set
featureX="200";type=maximum-limit;optional
The session element can contain arbitrary text of any length (but audio:codec
authors are encouraged to keep the inline description brief and name="audio-PCMU-44khz";type=name
provide additional information via URLs using the info element encoding="PCMU";type=string
described below. This text is used to provide a description of the sampling="44100";type=maximum-limit
session; it is the equivalent of the SDP "i=" lines. channels="[1,2,4]";type=set
featureY="200";type=string;optional
Additionally, the session element can contain other elements of the Note again, that these descriptions merely present examples in order
following types to provide further information about the session and to present the data model that we use for potential configurations --
its creator: this is not the SDPng syntax. In these examples, we have added the
optional features 'featureX' and 'featureY'.
info: The info element is intended to provide a pointer to further If we assume, that the two potential configurations are contributions
information on the session itself. It is an empty element and from different participants for a capability negotiation, a resulting
provides the attribute xlink:href that is used to specify an URI. potential configuration, after a negotiation process as outlined in
Info elements are optional, they may occur any number of times. Section 3, could look like this:
contact: The contact element provides contact information on the audio:codec
creator of the session. It is an empty element and provides an encoding="PCMU";type=string
attribute xlink:href that is used to specify an URI. Any URI sampling="8000";type=maximum-limit
scheme suitable to reach a person or a group of persons is channels="[1]";type=set
acceptable (e.g. sip:, mailto:, tel:). Contact elements are
optional, they may occur any number of times.
<session name="An SDPng seminar"> The name cannot be considered for a capability negotiation, the
And here comes a long description of the seminar indicating what optional properties 'featureX' and 'featureY' have only been provided
this might be about and so forth. But we also include further by one participant each and the other properties have been processed
information -- as additional elements: by the negotiation algorithms (that will be specified in a future
<info xlink:href="http://www.ietf.org/"/> version of this document in Section 3).
<contact xlink:href="mailto:joe@example.com"/>
<contact xlink:href="mailto:bob@example.com"/>
<contact xlink:href="tel:+49421218"/>
<contact xlink:href="sip:joe@example.com"/>
<contact xlink:href="sip:bob@example.com"/>
</session>
3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) So far, we have only considered codec capabilities. Other
capabilities would include transport mechanisms, e.g., RTP/UDP/IPv4:
The time specification for a session follows the same rules as in rtp-udp:transport
SDP. Time specifications are usually only meaningful when used in name="rtp-udp-ipv4";type=name
conjunction with SAP and are optional. SDPng uses the following network="IP4;type=string
elements and attributes to specify timing:
The element "time" is used to indicate a schedule for the session; 4.1.2 Actual Configurations
time has two optional attributes:
start: The starting time of the first occurrence of the session as The "Actual Configurations" section lists all the components that
defined in RFC2327. 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).
end: The ending time of the last occurrence of the session as defined Each component is labeled with an identifier so that it can be
in RFC2327. referenced, e.g. to associate semantics with a particular media
stream. For such a component, any number of actual configurations
may be given with each configuration describing an alternative way to
realize the functionality of the respective component.
The time element can contain the following elements: The semantics of this are application dependent. For example, for
SIP applications using the SDP offer/answer model, providing multiple
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.
repeat: This element specifies the repetition pattern for the The following example provides two alternative configurations for a
schedule. There may be zero or more occurrences of this element component named "interactive-audio". Each alternative refers to the
within the time element. "repeat" has two mandatory and one RTP-transport capability named "rtp-udp-ipv4" and to an audio-codec
optional attribute and is an empty element; the attributes are as capability.
defined in SDP:
interval: The duration between two start times of the session. component
This attribute is always present. name="interactive-audio"
alt
name="AVP-audio-0"
rtp-udp:transport
ref="rtp-udp-ipv4"
pt="96"
direction="send-receive"
addr="224.2.0.53"
rtp-port="7800"
rtcp-port="7801"
audio-codec
ref="audio-basic"
duration: The duration for which the session will be active alt
starting at each repetition interval. This attribute is always name="AVP-audio-11"
present. rtp-udp:transport
ref="rtp-udp-ipv4"
pt="97"
direction="send-receive"
addr="224.2.0.53"
rtp-port="7800"
rtcp-port="7801"
audio-codec
ref="audio-L16-stereo"
offset: The offset relative to "start" attribute at which this For the RTP transport configuration, additional required parameters
repetition of the session is start. This attribute is are provided, such as the payload type number to be used (pt="97"),
optional; if it is absent, a default value of "0" is assumed. the IP address and UDP port numbers for RTP and RTCP and the
directionality.
Formatting of the attribute values follows the rules defined in Note that in the example above, the actual configuration of the RTP
RFC2327. transport is identical for both alternatives -- with the exception of
the payload type number. In a final solution, this duplication
should be avoided by another level of indirection, i.e., by defining
these parameters once and referencing this definition where needed.
zone: The zone element specifies one or more time zone adjustments as In order to determine the usable actual configurations after a
defined in RFC2327. This element has zero or more occurrences in capability negotiation, a user agent has to traverse the references
the time element. It is an empty element and has two attributes in actual configurations to potential configurations and check
as defined in SDP: whether each capability is still supported after a negotiation
process. Only those alternatives that reference supported
capabilities can be considered for implementing the given component.
adjtime: The time at which the next adjustment will take place. The semantics of specifying multiple alternatives for a component are
application specific -- for RTP configurations in SDP it means that
the endpoint is willing to receive any of the specified formats
without further out-of-band signaling and that the first
configuration is preferred.
delta: The adjustment offset (typically +/- 1 hours). 4.1.3 Constraints
The example from RFC2327, page 16, expressed in SDPng: Potential configurations are media, transport, and other
capabilities, whereas configurations indicate which combinations of
these could be used to provide the desired functionality in a certain
setting.
<time start="3034423619" stop="3042462419"> There may, however, be further constraints within a system (such as
<repeat interval="7d" duration="1h"/> CPU cycles, DSP resources available, dedicated hardware, etc.) that
<repeat interval="7d" duration="1h" offset="25h"/> limit which of these configurations can be instantiated in parallel
</time> (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 time element can occur multiple times. The usage of constraints will be specified in a future version of
this document.
3.1.4.4 Component Semantic Specification 4.1.4 Meta Information
Another important session parameter is to specify - ideally in a The fourth and final section of an SDPng description is used to
machine-readable way but at least understandable for humans - the specify meta information such as session layer attributes. These
function of the various components in a session. Typically, the attributes largely include those defined by SDP [RFC2327] (which are
semantics of the streams are implicitly assumed (e.g. a video stream explicitly indicated in the following specification) to describe
goes together with the only audio stream in a session). There are, originator, purpose, and timing of a multimedia session among other
however, scenarios in which such intuitive understanding is not characteristics. Furthermore, SDPng includes attributes indicating
sufficient and the semantics must be made explicit. the semantics of the various Components in a teleconference or other
session.
<info name="audio-interactive" function="speaker"> A session-level specification for connection information (SDP "c="
Audio stream for the different speakers line), bandwidth information (SDP "b=" line), and encryption keys
</info> (SDP "k=" lines) is deliberately not provided for in SDPng. The
relevant information can be specified directly in the Configuration
section for individual alternatives.
The above example shows a simple definition of the semantics for the The section for meta information will provide for integrating and re-
component "audio-interactive". Further options may be added to using existing meta-information frameworks such as MPEG-7. Details
provide additional information, e.g. language, and other functions will be specified in a future version of this document.
may be specified (e.g. "panel", "audience", "chair", etc.).
3.2 Syntax Definition Mechanisms 4.2 Syntax Definition Mechanisms
In this section, we specify the syntax definition mechanisms for
SDPng.
In order to allow for the possibility to validate session In order to allow for the possibility to validate session
descriptions and in order to allow for structured extensibility, descriptions and in order to allow for structured extensibility,
SDPng relies on a syntax framework that provides concepts as well as SDPng relies on a syntax framework that provides concepts as well as
concrete procedures for document validation and extending the set of concrete procedures for document validation and extending the set of
allowed syntax elements. allowed syntax elements.
SGML/XML technologies allow for the creation of Document Type SGML/XML technologies allow for the creation of Document Type
Definitions (DTDs) that can define the allowed content models for the Definitions (DTDs) that can define the allowed content models for the
elements of conforming documents. Documents can be formally elements of conforming documents. Documents can be formally
skipping to change at page 19, line 8 skipping to change at page 20, line 10
It is important to note that the functionality of validating It is important to note that the functionality of validating
capability and session description documents is not necessarily capability and session description documents is not necessarily
required to generate or process them. For example, endpoints would required to generate or process them. For example, endpoints would
be configured to understand only those parts of description documents be configured to understand only those parts of description documents
that are conforming to the baseline specification and simply ignore that are conforming to the baseline specification and simply ignore
extensions they cannot support. The usage of XML and XML Schema is extensions they cannot support. The usage of XML and XML Schema is
thus rather motivated by the need to allow for extensions being thus rather motivated by the need to allow for extensions being
defined and added to the language in a structured way that does not defined and added to the language in a structured way that does not
preclude the possibility to have applications to identify and process preclude the possibility to have applications to identify and process
the extensions elements they might support. The baseline the extensions elements they might support. The baseline
specification of XML Schema definitions and profiles must be well- specification of XML Schema definitions and packages must be well-
defined and targeted to the set of parameters that are relevant for defined and targeted to the set of parameters that are relevant for
the protocols and algorithms of the Internet Multimedia Conferencing the protocols and algorithms of the Internet Multimedia Conferencing
Architecture, i.e. transport over RTP/UDP/IP, the audio video Architecture, i.e. transport over RTP/UDP/IP, the audio video
profile of RFC1890 etc. profile of RFC1890 etc.
Section 3.4 describes profile definitions and library definition. A Section 4.4 describes package definitions and library definition.
detailed definition of how the formal SDPng syntax and the
corresponding extension mechanisms is provided in Section 5.
The example below is a complete SDPng document. It shows how the
definition of codecs, transport-variants and configuration of
components as well as a conference description are realized in SDPng:
<def>
<audio:codec name="audio-basic" encoding="PCMU"
sampling="8000" channels="1"/>
<audio:codec name="audio-L16-mono" encoding="L16"
sampling="44100" channels="1"/>
<rtp:pt name="rtp-avp-0" pt="0"/>
<audio:codec ref="audio-basic"/>
</rtp:pt
<rtp:pt name="rtp-avp-11" pt="11">
<audio:codec ref="audio-L16-mono"/>
</rtp:pt
</def>
<cfg>
<component name="interactive-audio" media="audio">
<alt name="AVP-audio-0">
<rtp:session>
<rtp:pt ref="rtp-avp-0"/>
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
</rtp:session>
</alt>
<alt name="AVP-audio-11">
<rtp:session>
<rtp:pt ref="rtp-avp-11"/>
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
</rtp:session>
</alt>
</component>
</cfg>
<constraints>
<par>
<use-alt ref="AVP-audio-11" max="1">
</par>
</constraints>
<conf>
<owner user="joe@example.com" id="foobar" version="1" nettype="IN"
addrtype="IP4" addr="130.149.25.97"/>
<session name="An SDPng seminar">
This seminar is about SDPng...
<info xlink:href="http://www.ietf.org/"/>
<contact xlink:href="mailto:joe@example.com"/>
<contact xlink:href="sip:joe@example.com"/>
</session>
<time start="3034423619" stop="3042462419">
<repeat interval="7d" duration="1h"/>
<repeat interval="7d" duration="1h" offset="25h"/>
</time>
<info name="interactive-audio" function="speaker">
Audio stream for the different speakers
<info>
</conf>
Section 5 specifies the formal Schema definition that this example is
conforming to.
3.3 Referencing Definitions
This section specifies some generic mechanisms for referencing
existing definitions. Referencing existing definitions allows to
contruct definitions without having to include all parameters inline.
By using these mechanisms, complex definitions can be derived by
combining multiple basic mechanisms. Common parameters that occur in
different configurations do not have to be repeated but can be
defined once and then be referenced as often as they are needed.
3.3.1 The attribute "ref"
The attribute "ref" is a generic reference mechanism that is used in
referencing elements to reference an existing element of the same
element type. An example:
<def>
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/>
</def>
<cfg>
<component name="interactive-audio" media="audio">
<alt name="alt-avp-audio-10">
<rtp:session>
<rtp:udp ref="endpoint-addr-1"/>
</rtp:session>
</alt>
</component>
<cfg>
In this example, an element of the type "rtp:udp" is specified in the
definitions section of an SDPng document that is named "endpoint-
addr-1" in its "name" attribute. The element is referenced in the
definition of the alternative "alt-avp-audio-10", within the
"rtp:session" element. The "rtp:session" provides an child element
"rtp:udp" that does not provide content or attributes on its own.
Instead, it references the "rtp:udp" element named "endpoint-addr-1"
by using this identifier in its "ref" attribute.
The requirements for implementation concerning the processing of the
"ref" attribute are as follows:
1. The parsing application MUST try to locate an element of the
element type as the referencing element.
2. If such an element is found, the attributes of the referencing
element MUST be augmented with the attributes of the referenced
element. Only those attributes that are not specified by the
referencing element MUST be considered.
3. The content of referenced element, i.e., child elements or
character content, MUST be added to the content of the
referencing element. The content of the referenced element MUST
be added before the content of the referencing element. For
example, if a referenced element A provides the child elements a1
and a2, and a referencing element B provides the child elements
b1 and b2, the resulting content will consists of the following
child elements in this order; a1,a2,b1,b2. The semantics of the
resulting content are completely application dependent, i.e., an
profile SHOULD specify corresponding content models and define
the semantics, for example for multiple occurenced of an element
of a certain type.
The following example provides an example of an reference to an 4.3 Referencing Definitions
existing element by an refering element that overwrites an attribute
of the referenced element.
<def> SDPng provides a referencing concept for definitions. For example,
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/> in the specification of an actual configuration, we reference the
</def> capabilities of the potential configurations section.
<cfg>
<component name="interactive-audio" media="audio">
<alt name="alt-avp-audio-10">
<rtp:session>
<rtp:udp ref="endpoint-addr-1" rtp-port="8000"/>
</rtp:session>
</alt>
</component>
<cfg>
Open Issue: Should overwriting of child elements be allowed as well? The concrete reference mechanism depends on the syntax in use and
will be specified in a future version of this document.
3.4 External Definition Packages 4.4 External Definition Packages
There are two types of external definitions: There are two types of external definitions:
Profile Definitions (Section 3.4.1) define rules for specifying Package Definitions (Section 4.4.1) define rules, i.e., a data
parameters that are not covered by the base SDPng specification. schema, for specifying parameters that are not covered by the base
SDPng specification.
Library Definitions (Section 3.4.2) contain definitions that can be Library Definitions (Section 4.4.2) contain definitions that can be
referenced in SDPng documents. referenced in SDPng documents.
3.4.1 Profile Definitions 4.4.1 Package Definitions
In order to allow for extensibility it must be possible to define In order to allow for extensibility it must be possible to define
extensions to the basic SDPng configuration options. extensions to the basic SDPng configuration options.
For example, if some application requires the use of a new transport For example, if some application requires the use of a new transport
protocol, endpoints must be able to describe their configuration with protocol, endpoints must be able to describe their configuration with
respect to the parameters of that transport protocol. The mandatory respect to the parameters of that transport protocol. The mandatory
and optional parameters that can be configured and negotiated when and optional parameters that can be configured and negotiated when
using the transport protocol will be specified in a definition using the transport protocol will be specified in a definition
document. Such a definition document is called a "profile". document. Such a definition document is called a "package".
A profile contains rules that specify how SDPng is used to describe A package contains rules that specify how SDPng is used to describe
conferences or end-system capabilities with respect to the parameters conferences or end-system capabilities with respect to the parameters
of the profile. The specific properties of the profile definitions of the package. The specific properties of the package definitions
mechanism are still to be defined. mechanism are still to be defined.
An example of such a profile would be the RTP profile that defines An example of such a package would be the RTP package that defines
how to specify RTP parameters. Another example would be the audio how to specify RTP parameters. Another example would be the audio
codec profiles that defines how specify audio codec parameters. codec package that defines how specify audio codec parameters.
SDPng documents can reference profiles and provide specific
definitions, for example the definition for the GSM audio codec.
(This would be done in the "Definitions" section of an SDPng
document.) An SDPng document that references a profile and provides
specific definitions of configurations can be validated against the
profile definition.
3.4.2 Library Definitions 4.4.2 Library Definitions
While profile definitions specify the allowed parameters for a given While package definitions specify the allowed parameters for a given
profile, SDPng "Definitions" sections refer to profile definitions profile, SDPng "Definitions" sections refer to package definitions
and define concrete configurations based on a specific profile. and define concrete configurations based on a specific package.
In order for such definitions to be imported into SDPng documents, In order for such definitions to be imported into SDPng documents,
"SDPng libraries" may be defined and referenced in SDPng documents. "SDPng libraries" may be defined and referenced in SDPng documents.
A library is a set of definitions that is conforming to one or more A library is a set of definitions that is conforming to one or more
profile definitions. package definitions.
The purpose of the library concept is to allow certain common The purpose of the library concept is to allow certain common
definitions to be factored-out so that not every SDPng document has definitions to be factored-out so that not every SDPng document has
to include the basic definitions, for example the PCMU codec to include the basic definitions, for example the PCMU codec
definition. SDP [2] uses a similar concept by relying on the well definition. SDP [2] uses a similar concept by relying on the well
known static payload types (defined in RFC1890 [4]) that are also known static payload types (defined in RFC1890 [4]) that are also
just referenced but never defined in SDP documents. just referenced but never defined in SDP documents.
An SPDng document that references definitions from an external An SPDng document that references definitions from an external
library has to declare the use of the external library. The external library has to declare the use of the external library. The external
library, being a set of configuration definitions for a given library, being a set of configuration definitions for a given
profile, again needs to declare the use of the profile that it is package, again needs to declare the use of the package that it is
conforming to. A library itself can make reference to other external conforming to. A library itself can make reference to other external
libraries. libraries.
There are different possibilities of how profiles definitions and There are different possibilities of how package definitions and
libraries can be used in SDPng documents: libraries can be used in SDPng documents:
o In an SPDng document, a profile definition can be referenced and o In an SPDng document, a package definition can be referenced and
all the configuration definitions are provided within the document all the configuration definitions are provided within the document
itself. The SDPng document is self-contained with respect to the itself. The SDPng document is self-contained with respect to the
definitions it uses. definitions it uses.
o In an SPDng document, the use of an external library can be o In an SPDng document, the use of an external library can be
declared. The library references a profile definition and the declared. The library references a package definition and the
SDPng document references the library. There are two alternatives SDPng document references the library. There are two alternatives
how external libraries can be referenced: how external libraries can be referenced:
by name: Referencing libraries by names implies the use of a by name: Referencing libraries by names implies the use of a
registration authority where definitions and reference names registration authority where definitions and reference names
can be registered with. It is conceivable that the most common can be registered with. It is conceivable that the most common
SDPng definitions be registered that way and that there will be SDPng definitions be registered that way and that there will be
a baseline set of definitions that minimal implementations must a baseline set of definitions that minimal implementations must
understand. Secondly, a registration procedure will be understand. Secondly, a registration procedure will be
defined, that allows vendors to register frequently used defined, that allows vendors to register frequently used
skipping to change at page 24, line 45 skipping to change at page 22, line 37
result in in higher latency for the processing of a description result in in higher latency for the processing of a description
document with references to external libraries. In addition, document with references to external libraries. In addition,
there are problems if the referenced libraries cannot be there are problems if the referenced libraries cannot be
accessed by all communication partners. accessed by all communication partners.
o Because of these problematic properties of external libraries, the o Because of these problematic properties of external libraries, the
final SDPng specification will have to provide a set of final SDPng specification will have to provide a set of
recommendations under which circumstances the different mechanisms recommendations under which circumstances the different mechanisms
of referring to external definitions should be used. of referring to external definitions should be used.
3.5 Mappings 4.5 Mappings
A mapping needs to be defined in particular to SDP that allows to A mapping needs to be defined in particular to SDP that allows to
translate final session descriptions (i.e. the result of capability translate final session descriptions (i.e. the result of capability
negotiation processes) to SDP documents. In principle, this can be negotiation processes) to SDP documents. In principle, this can be
done in a rather schematic fashion for the base specification and a done in a rather schematic fashion for the base specification and a
set of basic profiles. set of basic packages.
In addition, mappings to H.245 will be defined in order to support In addition, mappings to H.245 will be defined in order to support
applications like SIP-H.323 gateways. applications like SIP-H.323 gateways.
4. Capability Negotiation 5. Syntax Definition
SDPng is a description language for both potential configurations
(i.e. capabilities) of participants in multimedia conferencers and
for actual configurations (i.e. final specifications of parameters).
Capability negotiation is the process of generating a usable set of
potential configurations and finally an actual configuration from a
set of potential configurations provided by each potential
participant in a multimedia conference.
SDPng supports the specification of endpoint capabilities and defines
a negotiation process: In a negotiation process, capability
descriptions are exchanged between participants. These descriptions
are processed in a "collapsing" step which results in a set of
commonly supported potential configurations. In a second step, the
final actual configuration is determined that is used for a
conference. This section specifies the usage of SDPng for capability
negotiation. It defines the collapsing algorithm and the procedures
for exchanging SDPng documents in a negotiation phase.
The description language and the rules for the negotiation phase that
are defined here are (in general) independent of the means by which
descriptions are conveyed during a negotiation phase (a reliable
transport service with causal ordering is assumed). There are
however properties and requirements of call signalling protocols that
have been considered to allow for a seamless integration of the
negotiation into the call setup process. For example, in order to be
usable with SIP, it must be possible to negotiate the conference
configuration within the three-way-handshake of the call setup phase.
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
configuration in a single request/response cycle.
4.1 Outline of the Negotiation Process
Conceptually, the negotiation process comprises the following
individual steps (considering two parties, A and B, where A tries to
invite B to a conference). Please note that this describes the steps
of the negotiation process conceptually -- it does not specify
requirements for implementations. Specific procedures that MUST be
followed by implementations are given below.
1. A determines its potential configurations for the components that
should be used in the conference (e.g. "interactive audio" and
"shared whiteboard") and sends a corresponding SDPng instance to
B. This SDPng instances is denoted "CAP(A)".
2. B receives A's SDPng instance and analyzes the set of components
(sdpng:c elements) in the description. For each component that B
wishes to support it generates a list of potential configurations
corresponding to B's capabilities, denoted "CAP(B)".
3. B applies the collapsing function and obtains a list of potential
configurations that both A and B can support, denoted
"CAP(A)xCAP(B) = CAP(AB)".
4. B sends CAP(B) to A.
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
the potential configurations that both can support.
6. In order to obtain an actual configuration from the potential
configuration that has been obtained, both particpants have to
pick a subset of the potential configurations that should
actually be used in the conference and generate the actual
configuration. It should be noted that it depends on the
specific application whether each component must be assigned
exactly one actual configuration (one sdpng:alt element) or
whether it is allowed to list multiple actual configurations. In
this model we assume that A selects the actual configuration,
denoted CFG(AB).
7. A augments CFG(AB) with the transport parameters it intends to
use, e.g., on which endpoint addresses A wishes to receive data,
obtaining CFG_T(A). A sends CFG_T(A) to A.
8. B receives CFG_T(A) and adds its own transport parameters,
resulting in CFG_T(AB). CFG_T(AB) contains the selected actual
configurations and the transport parameters of both A and B (plus
any other SDPng data, e.g., meta-information on the conference).
CFG_T(AB) is the complete conference description. Both A and B
now have the following information:
CAP(A) A's supported potential configurations
CAP(B) B's supported potential configurations
CAP(AB) The set of potential configurations supported by both A
and B.
CFG(AB) The set of actual configurations to be used.
CFG_T(AB) The set of actual configurations to be used augmented
with all required parameters.
In this model, the capability negotiation and configuration exchange
process leads to a description that represents a global view of the
configuration that should be used. This means, it contains the
complete configuration for all participants including per-participant
information like transport parameters.
Note that the model presented here results in four SDPng exchanges.
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
parameters are usually not negotiable, therefor they have to be
distingiushed from other configuration information.
Specific procedures for re-negotiation and multi-party negotiation
will be defined in a future version of this document.
4.2 The Collapsing Algorithm
The following procedure MUST be used for the collapsing of two SDPng
document instances into one:
CAP(A) and CAP(B) are the two SDPng description document instances.
For each component (sdpng:c element) in CAP(A) there is a
corresponding component in CAP(B). Components MAY be empty
(containing no sdpng:alt elements) which means that there is no
potential configuration and the component should not be used in the
conference.
Let cfg_AB be the result configuration element, initialized to an
empty sdpng:cfg element.
1. For each component (sdpng:c element) in CAP(A) named c_A
* Let c_AB be the current result component, initialized to an
empty sdpng:c element.
* For each alternative (sdpng:alt element) in c_A named a_A
+ For each session element (name depends on the profile being
used) in a_A named s_A
- Resolve any reference to definition elements recursively
and obtain s1_A, the standalone media session
description. (Refer to Section 4.2.1 for a description
of how to resolve references.)
- Locate the component element that matches c_A in CAP(B)
named (c_B).
- Let a_AB be the current result alternative, initialized
to an empty sdpng:alt element.
- For each alternative (sdpng:alt element) in c_B named
a_B
o For each session element (name depends on the profile
being used) in a_B named s_B
* Let s1_AB be the computed result media session
configuration.
* Resolve any reference to definition elements
recursively and obtain s1_B, the standalone media
session description.
* Apply collapse(s1_A,s2_B) to compute s1_AB, the
collapsed media session configuration.
* If s1_AB is not empty, add s1_AB to a_AB, the set
of sessions for the current result alternative.
- If a_AB is not empty, add a_AB to c_AB.
* If c_AB is not empty, add c_AB to cfg_AB.
The collapsing function for collapsing two elements is specified in
Section 4.2.1.
4.2.1 Collapsing Two Configurations
Before two media session configuration element can be collapsed as
described in Section 4.2 all references to definitions MUST be
resolved. This MUST be performed recursively, i.e. references in
definitions MUST also be resolved. For resolving references, the
algorithm specified in Section 3.3 MUST be used.
By resolving all references two intermediate session configuration
elements are obtained that can then be collapsed according to the
algorithm specified in the following sections.
4.2.1.1 Collapsing of Attributes
In SDPng, capabilities are specified in attributs of XML elements.
Three different types of capabilities with different collapsing rules
are defined. The type of a capability is encoded in the attribute
value.
Set of symbols:
An attribute can specify a set of symbols. When two attributes
are collapsed, the result is the intersection of the two sets.
The following examples shows how two elements (with one attribute
representing a set of symbols) originated from two capability
descriptions from participants A and B are collapsed:
Element x in A's capability description:
<x a="[FOO, BAR, 3, 5, 8]"/>
Element x in B's capability description:
<x a="[3, 6, 8]"/>
Result:
<x a="[3, 8]"/>
If the intersection result in an empty set the collapsing process
has failed and there is no common set of values. If the
collapsing of one of an element's attributes with the type "set of
symbols" has failed, the collapsing process of the element itself
MUST be considered to have failed as well.
Numerical ranges:
An attribute can also specify a numercial range. When two
attributes are collapsed the result is the range of values that
represents the intersection of the set of values that is included
in both ranges.
The following examples shows how two elements (with one attribute
representing a numerical range) originated from two capability
descriptions from participants A and B are collapsed:
Element x in A's capability description:
<x a="(2,8)"/>
Element x in B's capability description:
<x a="(5,10)"/>
Result:
<x a="(5,8)"/>
A numerical range is represented by a tuple of comma-separated
numbers in brackets. The first number represents the lower bound
of the range and the second number represents the upper bound.
Let MIN(a,b) be a function that returns the minimum of a and b and
MAX(a,b) be a function that returns the maximum of a and b. Given
two ranges (minA, maxA) and (minB, maxB), the collapsed new range
MUST be calculated using this algorithm:
(MAX(minA, minB), MIN(maxA, maxB))
If this process results in a range with a smaller second value,
the range is invalid and the collapsing has failed since there is
no common range. If the collapsing of one of an element's
attributes with the type "numerical range" has failed, the
collapsing process of the element itself MUST be considered to
have failed as well.
Optional parameters:
A failure of collapsing attributes of the types "set of symbols"
and "numerical range" results in a failure of collapsing the
corresponding element. There is a third type named "optional
parameter" defined, that provides different collapsing rules. An
optional parameter is an attribute with an arbitrary value. When
collapsing two attributes of this type, their values MUST be
tested for equality. If they are equal, the collapsing has been
successful and the attribute MUST appear as is in the result
description. If the attributes' values are different, the
collapsing is considered to have failed and the attribute MUST not
appear in the result description. However, a failure in
collapsing an attribute of type "optional parameter" does not
affect the collapsing of the containing element.
An example for a successful collapsing:
Element x in A's capability description:
<x a="foo"/>
Element x in B's capability description:
<x a="foo"/>
Result:
<x a="foo"/>
An example for an unsuccessful collapsing:
Element x in A's capability description:
<x a="foo"/>
Element x in B's capability description:
<x a="bar"/>
Result:
<x/>
4.2.1.2 Collapsing two Elements
In order to collapse two elements with multiple attributes, the
following algorithm specified below MUST be applied. In general, the
collapsing of two elements (if successful) yields a result element
that contains the collapsed attributes. If the collapsing of two
elements has failed, no result element is generated.
1. For each attribute, determine the type and collapse the attribute
by applying the algorithm for the corresponding attribute type.
2. If an attribute with a different type than "optional parameter"
does not occur in both elements, the collapsing for this element
MUST be considered to have failed.
3. If the collapsing of any attribute with a different type than
"optional parameter" has failed, the collapsing of the element
itself MUST be considered to have failed.
4. If the collapsing has been successful, obtain the result element
by using the same element name (GI) and the attributes with their
collapsed values. Exclude any attribute of type "optional
parameter" that has failed to collapse.
An example:
Element x in A's capability description:
<x a="[FOO, BAR, 3, 5, 8]" b="(2,8)" c="foo"/>
Element x in B's capability description:
<x a="[3, 6, 8]" b="(5,10)" c="bar"/>
Result:
<x a="[3, 8]" b="(5,8)"/>
4.2.1.3 Collapsing nested Elements
In order to collapse nested elements the following algorithm MUST be
applied:
In analogy to attributes representing optional parameters there is
also the possibility to mark elements as optional for the negotiation
process. Elements MAY provide an attribute named "status" that
contains a symbol or a comma-separated list of symbols as its value.
If the value "opt" occurs in the list of a "status" attribute of both
elements to be collapsed, the elements to be collapsed MUST be
treated as optional. This means, if the collapsing of the attributes
has failed (according to the rules specified in Section 4.2.1.2), the
collapsing process MUST NOT not yield a result element but MUST still
be treated as "successful", i.e., further collapsing operation on
other elements can continue. The semantics of optional elements are
that they describe optional features that may be supported and
selected during a negotiation phase but do not neccessarily have to
be supported by all participants in order to achieve
interoperability. The example below shows how to generate a result
element in the presence of optional child elements that have failed
to collapse.
The collapsing algorithm for nested elements:
1. Let x be an element that occurs in the capability description of
two participants A and B and that should be collapsed.
2. Collapse the attributes of the element x using the algorithm
specified in Section 4.2.1.2. If the collapsing has failed
according to the rules of Section 4.2.1.2 and if the elements to
be collapsed are not marked as optional, the collapsing of the
element and all of its children MUST be considered to have
failed. The collapsing MUST be stopped. If the collapsing has
failed and both elements have been marked as optional, the child
elements MUST NOT be processed. In this case, the collapsing
process does not yield a result element but the collapsing of
other elements (sibling or parent elements) MUST be continued.
3. If the collapsing has been successful according to the rules of
Section 4.2.1.2, the child elements of A's and B's x element MUST
be processed. If there are no child elements in both A's and B's
content the collapsing has been successful and can be terminated.
If either A's or B's x element provides child elements, apply the
following algorithm to each child element named c of participant
A's element x:
1. Find a corresponding element (same GI) in the set of
participant B's child elements. If no matching element has
been found, the collapsing of element x MUST be considered to
have failed.
2. If a matching element has been found, apply the collapsing
algorithm recursively. As long as the collapsing is
successful, the result of collapsing each element is
transferred to the result element, such that the resulting
element tree is isomorphic to both A's and B's element tree.
If there are elements in B's x element that have not been
processed (because there is no corresponding element in A's x
element), the collapsing MUST be considered to have failed and
MUST be stopped.
An example:
Element x in A's capability description:
<x a="[FOO, BAR, 3, 5, 8]" b="(2,8)" c="foo">
<y b="[UVW, XYZ]"/>
</a>
Element x in B's capability description:
<x a="[3, 6, 8]" b="(5,10)" c="bar">
<y b="[RST, XYZ]"/>
</a>
Result:
<x a="[3, 8]" b="(5,8)">
<y b="[XYZ]"/>
</a>
An example for collapsing optional elements:
Element x in A's capability description:
<x a="[FOO, BAR, 3, 5, 8]" b="(2,8)" c="foo">
<y status="opt" b="[UVW, XYZ]"/>
</a>
Element x in B's capability description:
<x a="[3, 6, 8]" b="(5,10)" c="bar">
<y status="opt" b="[RST]"/>
</a>
Result:
<x a="[3, 8]" b="(5,8)"/>
4.2.2 Deriving an actual Configuration
The result of a capability negotiation process is a potential
configuration, i.e., a description potentially containing multiple
alternatives per component. The alternative themselves may provide
elements that represent collapsed capabilities. In order to derive
an actual configuration, the following problems must be addressed:
1. For each component (sdpng:c element) an appropriate alternative
(sdpng:alt element) has to be selected. It is conceivable that
the order of the alternatives in the description is used as a
preference indicator. More details have to be specified in a
future version of this document.
2. If the description of the selected alternatives contains
attributes with numerical ranges or sets of symbols with more
than one entry, those attributes either have to be transformed
that they represent a single value or participants have to agree
that an actual configuration may contain ranges and sets of
symbols. The semantics of these variable actual configurations
will have to specified in later versions of this document. For
example, for certain applications it may be desireable to agree
on ranges of values for certain attributes during a capability
negotiating meaning that any of the values of the range are
supported (and have to be supported).
The specific procedures to determine an actual configuration have to
be defined in a later version on this document.
5. Formal Specification
This section defines the SDPng syntax and the use of XML mechanisms,
such as XML Namespace and XML Schema. Section 5.1 defines the
relation between SDPng and XML Schema, Section 5.2 specifies general
requirements for documents and profile definitions that are
conforming to the SDPng schema, Section 5.3 list requirements for
profile definitions, Section 5.4 specifies specific requirements for
conforming documents and Section 5.5 lists requirements for the
definition of SDPng libraries.
Section 5.7 defines the SDPng base schema, Appendix A.1 defines the
profile for audio codec definitions and Appendix B defines the
profile for RTP payload type definitions.
5.1 XML Schema as a Definition Mechanism
SDPng documents reference profile schema definitions and libraries.
Profile schema definitions contain schema definitions of SDPng
document elements. For example, the general structure is specified
by a schema definition and extensions to SDPng for specific
applications are specified as schema definitions as well.
SDPng uses XML-Schema [13][14] for defining the possible logical
structures of SDPng documents for the following reasons:
Extensibility: XML-Schema provides mechanisms that allow to extend
existing definitions allowing to uniquely identify element types
(by relying on XML namespaces [11]).
Modularity: XML-Schema provide mechanisms that allow to organize
schema definitions in multiple components.
Expressiveness: XML-Schema provides many data types, that can be
refined by user-supplied definitions.
SDPng documents MUST be schema instances of the SDPng schema as
defined in Section 5.7. The following example shows how a Schema
definition can be referenced in a document instance.
Beginning of an SDPng-document:
<?xml version="1.0" ?>
<sdpng:desc xmlns="http://www.iana.org/sdpng"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd">
XML-Schema specifies that documents can assign a namespace when
referencing a schema definition. A SDPng namespace is defined for
this purpose. The name of this namespace is
"http://www.iana.org/sdpng". SDPng documents MUST use this namespace
as their default namespace.
For SDPng documents, this initial declaration can be added implicitly
by applications, so that declarations like the one above do not have
to be included in every description document. Details are to be
defined in a later version of this document.
5.2 SDPng Schema
The basic SDPng schema definitions specifies the general document
structures, e.g., one "Definitions" section followed by one
"Configurations" sections, followed by one "Constraints" sections
followed by a "Conference" section (for meta-information). Each
document MUST provide the elements for definitions, configurations,
constraints and conference information in exactly this order, whereby
only the configurations section is MANDATORY. Refer to Section 5.7
for a formal definition of the SDPng base schema and the specific
element types for definitions, configurations, constraints and
conference information.
The SDPng base schema also specifies "abstract" base data types (by
means of XML-Schema type definitions) for elements that MUST be used
by documents in the corresponding sections. The base data types
provide common required attributes, e.g. a "name" attribute for
naming definition elements.
Example:
The following example shows the definition of the base type for
definition elements:
<xsd:complexType name="Definition" abstract="true" mixed="false">
<xsd:attribute name="name" type="xsd:string"/>
</xsd:complexType>
Profiles can then define specific types that augment the base type
definitions. Common attributes or content models, that have been
defined by this base definition, do not have to be provided by those
specific type definitions. The type definitions can be identified as
allowed element types for the content models that are specified in
the base SDPng schema definition. This allows for automatic
validation of profile definitions and facilitates the extension of
SDPng.
5.3 Profiles
The baseline SDPng specification consists of a profile (a schema
definition) and a library of commonly used definitions.
The library of commonly used definitions provides data types for IP
(and other) addresses.
A profile definition MUST import (using the XML-Schema import
mechanism) the base SDPng schema definition and MUST provide an
extension definition, e.g., specializations of base element types. A
profile definition MUST also provide a target namespace name for its
definitions. For well-known (registered) profiles, the namespace
name will be registered by IANA. Proprietary profiles will use other
namespace names, for example, based on domain names, that are
registered by vendors providing a profile.
Example:
The following example shows such a declaration at the beginning of a
profile definition:
<xsd:schema targetNamespace="http://www.iana.org/sdpng/audio"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio">
<xsd:import namespace="http://www.iana.org/sdpng"
schemaLocation="sdpng.xsd"/>
In this example, the namespace prefix "audio" is defined and later
used in schema definitions. (The example profile provides definition
mechanisms for audio codecs.)
The following example shows, how a derived type for "definition"
elements can be specified with XML-Schema mechanisms. In this case,
the abstract type "Definition" (fully qualified as
"sdpng:Definition") is augmented by three attributes that are useful
for defining audio codecs.
Example:
<xsd:complexType name="AudioCodec" mixed="false">
<xsd:complexContent>
<xsd:extension base="sdpng:Definition">
<xsd:attribute name="encoding" type="xsd:string"/>
<xsd:attribute name="sampling" type="xsd:positiveInteger"/>
<xsd:attribute name="channels" type="xsd:positiveInteger"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
This type definition is then used to define an XML element type
called "codec".
Example:
<xsd:element name="codec" type="AudioCodec"/>
When used by SDPng documents, the general identifier is qualified
with a namespace prefix, for example as in: "audio:codec".
5.4 SDPng Documents
SDPng documents MUST reference the employed profiles and provide
namespace prefixes for the namespace names of the profiles as shown
in the following example.
Example: An SDPng description is an XML document with different element types
for the different sections. The SDPng base syntax specification
defines this overall document structure.
<sdpng:desc xmlns="http://www.iana.org/sdpng" 5.1 Potential Configurations
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp">
For well-known registered profiles, the namespace name AND the used A section for potential configurations is an XML element that can
namespace prefix SHOULD be registered to allow for simple basic provide a list of child elements. Each child element represents an
implementations that can match identifiers by using fixed fully individual capability as described in Section 4.1.1. Each property
qualified names without having to interpret namespace declarations is represented by an XML attribute. The element types are defined in
(see Section 5.6.3). There is one issue with declaring used XML- package definitions. XML Namespaces are used to disambiguate element
Schema definitions in documents (see Section 6 below). types and to allow for extensibility.
The general structure of an SDPng documents MUST conform to the basic Each element MUST provide an attribute "name". The value of this
SDPng schema definition and MAY provide a "def" element for attribute SHOULD be composed of a prefix (representing a namespace-
definitions; it MUST provide a "cfg" element for the configuration name) and a unique name for the corresponding capability within that
section; it MAY provide a "constraints" and a "conf" element. namespace. The namespace-name designates a namespace for the source
of the capability definition. If a prefix is specified, it MUST be
separated by a colon (':') from the name.
Example: Each element represents a "feature set" (using the terminology of
The following example shows a sample definition section where the [18]). Therefore, each attribute can provide a "range" of values --
element "codec" of the "audio codec profile" is used (plus the not only a single value. For example, an attribute can specify a set
element type "pt" of an "RTP profile"): 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.
<def> Each property that is represented by an XML attribute has a well-
<audio:codec name="dvi4" encoding="DVI4" channels="1" defined type that is specified in the package definition. The type
sampling="8000"/> is encoded implicitly in the attribute value (similar to the syntax
<audio:codec name="g722" encoding="G722" channels="1" in RFC 2533 [18]). The following types are distinguished:
sampling="16000"/>
<audio:codec name="g729" encoding="G729" channels="1"
sampling="8000"/>
<rtp:pt name="rtp-avp-18" pt="18"> Text strings, tokens
<audio:codec ref="g729"/> An attribute may provide a token (a symbolic name), e.g., for a
</rtp:pt codec name.
</def> An example for a corresponding attribute:
It can be seen how the attribute name (provided by the base type for encoding="PCMU"
definition elements) and the profile specific attributes "encoding",
"channels" and "sampling" are used together.
The element "rtp:pt" is used to defined a payload type. "rtp:pt" Token MUST be directly embedded into the attribute content, i.e.,
would have been defined in another profile, again using a type the token is the attribute value.
derived from the base definition type. "rtp:pt" provides attribute The complete formal syntax definition of tokens will be provided
for referencing other definitions, e.g., the definition of audio- in a later version of this document.
codes as seen before.
5.5 Libraries Token sets
An attribute can specify a set of tokens (representing a list of
alternative values for a certain property).
An example for a corresponding attribute:
SDPng libraries are collections of definitions that are referenced by sampling="[8000,16000,44100]"
documents. Libraries are thus independent, valid SDPng documents.
For example, the definition of the different audio codecs as shown in A token set MUST be specified as a list of tokens that are
the previous example could be provided by a library that can be separated by commas (',') and are enclosed by square brackets
referenced by documents without having to define such common codecs ('[',']').
in every document. The complete formal syntax definition of token sets will be
provided in a later version of this document.
The XML mechanism XInclude [12] is used for referencing libraries in Numbers and Numerical ranges
SDPng documents. XInlcude works at the XML Information Set An attribute can specify a number or a range (minimum and maximum)
("infoset") level, i.e. the mechanisms allows to have an integrating for numbers.
document reference fragment documents, while these fragments are An example for an attribute specifying a number:
well-formed (and, if applicable, valid) documents themselves. By
resolving XInclude directives in integrating documents the documents'
infosets are "merged" together, enabling applications to operate on
the resulting infosets as if it had been generated by parsing a
single, monolithic document.
Inclusion at the XML infoset level has the advantage that documents bitrate="(64)"
are standalone -- they can be validated independently. Another
advantage is that is relatively easy to generate a "merged" infoset
for applications that are not able to resolve references to libraries
themselves.
5.6 Details on the use of specific XML Mechanisms A number MUST be specified as a literal value in brackets ('(',
')').
An example for an attribute specifying a numerical range:
This section specifies the use of specific XML mechanisms for SDPng. bitrate="(64,128)"
In order to allow for efficient parsing and processing, not all
features of XML Schema are allowed. Some variable information is set
to fixed values to allow the development of simplistic servers.
5.6.1 Default Namespace A numerical range MUST be specified as a pair of values. The
first value is the minimum value (included in the range) and the
seconds value is the maximum value (included in the range). The
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:
SDPng document instances MUST use the SDPng namespace bitrate="(64,)"
"http://www.iana.org/sdpng" as their default namespace. That means,
the general SDPng identifiers can be used without namespace prefixes.
5.6.2 Qualified Locals The complete formal syntax definition of numbers and numerical
ranges (and a definition of the exact number type) will be
provided in a later version of this document.
XML Schema allows to specify qualification of elements and An example for an XML element describing an individual capability:
attributes. It is possible to use non-qualified element and
attribute names in Schema definitions and document instances for so-
called "local definitions" (this is the default setting). "Local
Definitions" are contained within "global definitions" in an XML
schema definition. In order to simplify parsing and processing of
SDPng document instances, all elements MUST be fully qualified.
Attribute names MUST NOT be fully qualified, they are considered to
have the same namespace as their corresponding elements.
This means, the SDPng Schema definition contains the following <audio:codec name="avp:pcmu" encoding="PCMU" channels="[1,2]" sampling="[8000,16000]"/>
attributes for the "schema" element, that MUST also be used by SDPng
profiles:
o elementFormDefault="qualified" Capability elements MAY also provide attribute from different XML
This means that "locally defined" elements that are used within namespaces. For example, a video-codec capability MAY be described
the scope of fully-qualified elements MUST always be fully with attributes declaring general video capabilities, and this
qualified as well. element MAY provide a list of additional codec specific attributes,
as depicted in the following example:
o attributeFormDefault="unqualified" <video:codec name="h263+-enhanced" resolution="QCIF" frame-rate="(,24)"
This means that attribute names do not have to be fully qualified. h263plus:A="foo" h263plus:B="bar" />
Implementations MUST infer the namespace for attributes from the
namespace of the element that the attribute belongs to. Note that
the specification of XML Namespaces [11] defines that default
namespaces do not apply to attributes. In profile definitions,
all attributes MUST be defined locally. The same holds for the
base SDPng schema.
These rules make SDPng document instances processable by non-Schema- The definition of "optional properties" (properties that to do not
aware XML parsers by requiring all element names to be fully constitute a constraint but not optional enhancement -- see Section
qualified (no "local elements"). 4.1.1) will be provided in a future version of this document.
5.6.3 Fixed Namespace Prefixes 6. Specification of the Capability Negotiation
In order to facilitate the development of basic implementations, a The SDPng specification defines the syntax and the semantics of
few commonly used namespace names are associated with fixed prefixes, capability declarations (potential configurations). The algorithms
i.e. document instances and libraries MUST always use these that are used for processing descriptions and for comparing
prefixes. These prefixes MUST NOT be used for namespaces names than capability descriptions from different participants are application
the ones that are assigned to them. In order to ensure the specific.
uniqueness of namespace prefixes, namespace prefixes will be have to
registered together with the corresponding namespace names.
The namespace prefix for the SDPng namespace is "sdpng". In this section we discuss two alternative algorithms for
implementations: A model that is base on the SDP offer/answer scheme
(Section 6.1 and a model that is based on the feature matching
algorithm that is specified in RFC 2533 [18] (Section 6.2).
5.7 SDPng Schema Definitions 6.1 Offer/Answer
This section provides the definition of the base SDPng XML Schema. The offer/answer model allows to communicating peers to determine a
(common) mode of operation to exchange media streams in a single
round-trip. Basically, the offerer proposes a set of components,
providing one or more alternatives ("potential configurations") for
each of these. From this offer, the answerer learns which components
may be used and which configurations are conceivable to realize these
components. The answerer indicates which components it supports
(e.g. disallow a video session and go with a audio-only
conversation) and also provides possible configurations to implement
those components. Along with the media types and codec parameters,
offerer and answerer specify which transport addresses to use and, in
case of RTP, which payload types they want to use for sending.
Offerer and answerer agree on a common set of media streams
("components") and on a possible set of codecs ("configurations") as
well as the transport addresses and other parameters to be used.
However, they do not fix a certain configuration (unless only a
single one is exchanged in each direction). Instead, for each
selected media stream, either peer may choose and dynamically switch
to any of the configurations indicated by the other side in the
respective offer or answer.
1. Section 5.7.1 contains the base definition that provides the For using SDPng with the offer/answer model (RFC 3264), the following
general element types for SDPng. considerations apply to the SDPng documents:
2. Appendix A.1 contains a profile for audio codecs. o For each component to be used, all necessary parameters for at
least one actual configuration MUST be given, i.e. transport
addresses and payload formats MUST be specified along with the
capabilities.
3. Appendix B contains a profile for RTP payload type definitions. o Matching of components is done based upon their identification in
the session part of the SDPng document using predefined
identifiers.
5.7.1 SDPng Base Definition o Components that shall not be instantiated (i.e. that are refused
by the answerer) shall either be present but have all parameters
of the actual configuration removed (i.e. no transport addresses,
etc.) if they may be (re-)instantiated at a later stage. Or they
shall be removed entirely from the answer if the respective
component is not supported at all. In the latter case, the
corresponding configurations MUST be removed from both the
configuration section and the session section of the SDPng
document.
This schema definition defines the general structure of SDPng o For each component, the alternative potential configurations MUST
document instances. It defines the top-level element type "desc" be listed in the order of preference. A certain preference
that can have a sequence of "def", "cfg", "constraints" and "conf" indicator ("q=" value) may be included in a future revision of
elements as element content. this document. The considerations of RFC 3264 to simply arriving
at symmetric codec use apply.
In addition, "extensions hooks" are provided that can be used by The rules for matching properties and determining answers based upon
extension profiles providing definitions for specific applications. the offers are similar to those specified in RFC 3264.
In general, these extension are implemented by deriving profile
definitions from SDPng base definitions. The deployed XML Schema
mechanisms are "deriving by extension" and "substitution groups".
The SDPng base definition provides different base types (as
complexType definitions) for elements that are to be used in "def",
"cfg" and "conf" sections. In addition, it also defines specific
element types as "head elements" with assigned types that are used
for defining the content model of, e.g., the "def" element type.
Profiles that provide new element types for specific applications A future revision of this document will define the details for all
will define types that are derived from the base types and provide the attributes discussed in RFC 3264 that require special
the additional attributes and element content definitions that are considerations (e.g. the directionality attribute for media
required for the application. The XML element types that are defined streams).
in a profile are declared as valid substitutes for the base elements
("head elements") by setting the "substitutionGroup" attribute to the
name of the "head element" type.
For an extension profile that provides new definition element types, 6.2 RFC2533 Negotiation
e.g. for codec definitions, a new complexType would be defined that
extends sdpng:Definition (see below). An element type definition
that assigns that new type must then be declared to be in the
substitutionGroup "sdpng:definition".
This mechanism allows common rules for attributes and content models SDPng potential configurations can be processed using the RFC 2533
to be defined in base element definition and re-used by extension algorithm as defined in [18]. This involves the following steps:
profiles and it also allows validating parsers to identify the
correct type of elements that have been defined by profile
definitions.
The SDPng Base Definition: Translating SDPng potential configurations to RFC 2533 feature set
expressions;
<xsd:schema targetNamespace="http://www.iana.org/sdpng" Applying the RFC 2533 feature match algorithm; and
xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xlink="http://www.w3.org/1999/xlink"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:import namespace="http://www.w3.org/1999/xlink" Integrating the resulting feature set expressions into the SDPng
schemaLocation="xlink.xsd"/> selection of actual configurations.
<xsd:annotation> 6.2.1 Translating SDPng to RFC 2533 Expressions
<xsd:documentation>
This schema definition defines the general structure of SDPng
document instances. It provides base type and base element
definition for elements to occur in the different sections (def,
cfg, constraints, conf) to be derived from in extension-profile
definitions.
For an extension-profile that provides new definition element SDPng potential configurations can be translated to RFC 2533 feature
types, e.g. for codec definitions, a new complexType would be sets in a straightforward way, because SDPng uses a subset of the
defined that extends sdpng:Definition (see below). An element mechanisms provided by RFC 2533 with a different syntax.
type definition that assigns that new type must then be declared
to be in the substitutionGroup "sdpng:definition".
</xsd:documentation>
</xsd:annotation>
<xsd:element name="desc"> Each capability in an SDPng section for potential configurations is
<xsd:annotation> represented as an XML element with a set of attributes. We first
<xsd:documentation> describe how to translate a single capability element into a RFC 2533
The top-level element of an SDPng document. It defines the feature set, and then consider the combination of multiple capability
overall structure of an SPDng document. elements.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element ref="sdpng:def" minOccurs="0"/>
<xsd:element ref="sdpng:cfg"/>
<xsd:element ref="sdpng:constraints" minOccurs="0"/>
<xsd:element ref="sdpng:conf" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> Basically, all attributes of an SDPng capability element and its
child elements MUST be transformed to a RFC 2533 expression, whereas
each attribute MUST be translated to a feature predicate. The
resulting feature predicate are combined using the '&' (AND)
operator. The name attributes MUST NOT be considered.
<xsd:element name="def"> Each predicate MUST be encapsulated by brackets ('(', ')'). Each XML
<xsd:annotation> attribute value is taken as a feature predicate value, i.e., the
<xsd:documentation>The definitions section</xsd:documentation> quote are not considered. Each attribute name is directly adopted as
</xsd:annotation> a feature tag, including the namespace name.
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> The SDPng data types map to RFC 2533 feature types as follows:
<xsd:element name="cfg"> Token
<xsd:annotation> A token MUST be directly adopted as a RFC 2533 token.
<xsd:documentation>The configurations section</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element ref="sdpng:component" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> Token set
A token set MUST be directly adopted as a RFC 2533 set.
<xsd:element name="constraints"> Number
<xsd:annotation> A single number in round brackets MUST be adopted as a RFC 2533
<xsd:documentation>The constraints section</xsd:documentation> number. The brackets MUST be removed.
</xsd:annotation>
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element ref="sdpng:constraint" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> Numerical Ranges
A numerical range MUST be transformed to a feature set expression
with two feature predicates that are combined using the "&" (AND)
operator. The first predicate specifies the lower limit and the
second predicate specified the upper limit.
For example, the attribute bitrate="(64,128)" would be transformed
to the following feature set:
<xsd:element name="conf" type="sdpng:Conference"> (& (bitrate>=64) (bitrate<=128))
<xsd:annotation>
<xsd:documentation>The conference section</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> A numerical range without a lower limit MUST be transformed to a
corresponding predicate with a '<=' operator and a numerical range
without a upper limit MUST be transformed to a corresponding
predicate with a '>=' operator.
For example, the attribute bitrate="(,128)" would be transformed
to the following feature set:
<xsd:element name="definition" type="sdpng:Definition"> (bitrate<=128)
<xsd:annotation>
<xsd:documentation>
Placeholder base element for a definition element in the
definitions section. To be derived from by specific definition
element type definitions.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> The following sample SDPng potential configuration would be
transformed as follows:
<xsd:element name="component" type="sdpng:Component"> Original SDPng expression:
<xsd:annotation>
<xsd:documentation>
The configuration element in the configurations section.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <video:codec name="h263+-enhanced" resolution="QCIF" frame-rate="(,24)"
h263plus:A="foo" h263plus:B="bar" />
<xsd:element name="constraint" type="sdpng:Constraint"> Transforming attributes to feature predicates:
<xsd:annotation>
<xsd:documentation>
Placeholder base element for a contraint element in the
contraints section. To be derived from by specific constraint
element type definitions.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:complexType name="Definition" abstract="true" mixed="false"> (& (resolution=QCIF) (frame-rate<=24) (h263plus:A=foo) (h263plus:B=bar))
<xsd:annotation>
<xsd:documentation>
The base type for definition. Defines a attribute "name" for
naming definitions. The attribute 'name' MUST be used for
specifying a name in a definiton. The attribute 'ref' MUST be
used for referencing a previously defined definition.
</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="name" type="xsd:string" use="optional"/>
<xsd:attribute name="ref" type="xsd:string" use="optional"/>
</xsd:complexType>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> Note that in example above, the namespace name is not used for
feature tags, instead we use the namespace prefix (for abbreviation).
RFC 2533 uses the syntax rules of RFC 2506 for feature tags. An
additional requirement for transforming fully-qualified attribute
names (including namespace names) to feature tags will be specified
in a future version of this document.
<xsd:complexType name="Component" mixed="false"> Multiple independent capability elements MUST each be transformed
<xsd:annotation> using the specification above and then combined into a single RFC
<xsd:documentation> 2533 feature set by connecting the individual feature sets using the
The specification of a component consists of a sequence of '|' (OR) operator. For example, the following sample SDPng potential
alternatives. configuration would be transformed as follows:
</xsd:documentation>
</xsd:annotation>
<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 name="alt"> <audio:codec name="avp:pcmu" encoding="PCMU" channels="[1,2]" sampling="[8000,16000]"/>
<xsd:annotation> <video:codec name="h263+-enhanced" resolution="QCIF" frame-rate="(,24)"
<xsd:documentation> h263plus:A="foo" h263plus:B="bar" />
Each alternative consists of a "sessionConfig" (session
configuration) element. The "sessionConfig" element is a base
element of base type "sdpng:Session" that is used to derive
specific session types in extension profiles.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element ref="sdpng:sessionConfig" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="sessionConfig" type="sdpng:SessionConfig"/>
<xsd:complexType name="SessionConfig" abstract="true" mixed="false"> Transforming attributes to feature predicates:
<xsd:annotation>
<xsd:documentation>
The (abstract) base type for session elements. To be derived
from in extension profiles.
</xsd:documentation>
</xsd:annotation>
</xsd:complexType>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> (|
(& (encoding=PCMU) (channels=[1,2]) (sampling=[8000,16000]))
(& (resolution=QCIF) (frame-rate<=24) (h263plus:A=foo) (h263plus:B=bar))
)
<xsd:complexType name="Constraint" mixed="false"> Additional requirements for processing "optional" parameters (see
<xsd:annotation> Section 5) will be specified in a future version of this document.
<xsd:documentation>
The current content model for constraints is a sequence of
"sdpng:par" elements. In each "par" element a sequence of
"use-alt" elements may be used to specific the definitions
that may used in parallel. Each "use-alt" element can define
the number of minimum and maximum instantiations.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element ref="sdpng:par"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="par"> 6.2.2 Applying RFC 2533 Canonicalization
<xsd:complexType mixed="false">
<xsd:sequence>
<xsd:element ref="sdpng:use-alt">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="use-alt"> After transforming different SDPng capability descriptions from
<xsd:complexType mixed="false"> different participants into their equivalent RFC 2533 form, the
<xsd:attribute name="ref" type="xsd:string"/> following steps MUST be performed to calculate the common subset of
<xsd:attribute name="min" type="xsd:positiveInteger" capabilities:
use="optional"/>
<xsd:attribute name="max" type="xsd:positiveInteger"
use="optional"/>
</xsd:complexType>
</xsd:element>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:complexType name="Conference" mixed="false"> 1. The individual feature sets MUST be combined into a single
<xsd:sequence> expression by creating conjunction of the feature sets, i.e., the
<xsd:element name="meta" type="sdpng:ConfItem"/> feature sets MUST be connected by the '&' (AND) operator.
</xsd:sequence>
<!-- TBD -->
</xsd:complexType>
<xsd:complexType name="ConfItem" abstract="true" mixed="false"> 2. The resulting expression MUST be reduced to disjunctive normal
<xsd:annotation> form, i.e., the canonical from as specified by RFC 2533 [18].
<xsd:documentation>
The base type for conference meta inforformation
element. Currently, there is no common content model defined.
</xsd:documentation>
</xsd:annotation>
</xsd:complexType>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> 6.2.3 Integrating Feature Sets into SDPng
<xsd:element name="owner"> A feature set that has been created by combining multiple independent
<xsd:complexType mixed="false"> feature sets and by reducing the result for canonical form does not
<xsd:complexContent mixed="false"> indicate directly which of the capability elements belong the common
<xsd:extension base="sdpng:ConfItem"> subset of capabilities. The following steps MUST be performed to
<xsd:attribute name="user" type="xsd:string"/> determine whether an individual capability element (e.g., from one of
<xsd:attribute name="session-id" type="xsd:string"/> the contributing SDPng capability descriptions) belongs to the result
<xsd:attribute name="version" type="xsd:string"/> feature set.
<xsd:attribute name="nettype" type="xsd:string"/>
<xsd:attribute name="addrtype" type="xsd:string"/>
<xsd:attribute name="addr" type="xsd:string">
<!-- FIXME: re-use common address type! -->
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> Let R be the result feature set obtained from the canonicalization as
specified in Section 6.2.2.
<xsd:complexType name="SimpleLink" mixed="false"> 1. For each capability element, generate the equivalent RFC 2533
<xsd:attribute ref="xlink:type" fixed="simple"/> feature set by applying the steps specified in Section 6.2.1.
<xsd:attribute ref="xlink:role"/> Let C be the resulting feature set.
<xsd:attribute ref="xlink:arcrole"/>
<xsd:attribute ref="xlink:title"/>
<xsd:attribute ref="xlink:show" fixed="none"/>
<xsd:attribute ref="xlink:actuate" fixed="none"/>
<xsd:attribute ref="xlink:href"/>
</xsd:complexType>
<xsd:element name="session">
<xsd:complexType mixed="false">
<xsd:complexContent mixed="false">
<xsd:extension base="sdpng:ConfItem">
<xsd:sequence>
<xsd:element name="description" type="xsd:string"/>
<xsd:element name="info" type="sdpng:SimpleLink"/>
<xsd:sequence minOccurs="0">
<xsd:element name="contact" type="sdpng:SimpleLink"/>
</xsd:sequence>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>
The SDPng XML schema definition references some attribute definition 2. Combine R and C into a single feature set by building a
for Xlink attributes (as defined by the Xlink specification [15]): conjunction of the two feature sets (& R C). Let the result be
the feature set T.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 3. Reduce T to disjunctive normal form by applying the
xmlns="http://www.w3.org/1999/xlink" canonicalization as defined in RFC 2533 [18].
targetNamespace="http://www.w3.org/1999/xlink"
>
<xsd:attribute name="type" type="xsd:string"/> 4. If the remaining disjunction is non-empty, the constraints
<xsd:attribute name="role" type="xsd:string"/> specified by capability element (the origin of C) can be
<xsd:attribute name="arcrole" type="xsd:string"/> satisfied by R, i.e., C represents a commonly supported
<xsd:attribute name="title" type="xsd:string"/> capability.
<xsd:attribute name="show" type="xsd:string"/>
<xsd:attribute name="actuate" type="xsd:string"/>
<xsd:attribute name="href" type="xsd:string"/>
</xsd:schema> A future version of this document will specify requirements for
exchanging calculated capabilities and for selecting appropriate
actual configurations.
6. Open Issues 7. Open Issues
Definition of baseline libraries Definition of baseline libraries
Libraries provide partially specified definitions, i.e. without Libraries provide partially specified definitions, i.e. without
transport parameters. How can SDPng documents reference the transport parameters. How can SDPng documents reference the
definitions and augment them with specific transport parameters? definitions and augment them with specific transport parameters?
Referencing extension profiles: XML-Schema does not support the Referencing extension packages: XML-Schema does not support the
declaration of multiple schemas via the schemaLocation attribute. declaration of multiple schemas via the schemaLocation attribute.
Conceivable solution: When extension profiles are used, the SDPng Conceivable solution: When extension packages are used, the SDPng
description is a "multi-part" object, that consists of an description is a "multi-part" object, that consists of an
integrating schema definition (that references all necessary integrating schema definition (that references all necessary
profiles and the base definition) and the actual description packages and the base definition) and the actual description
document that is a schema instance of the integrating schema. document that is a schema instance of the integrating schema.
Uniqueness of attribute values: When libraries are used they will Uniqueness of attribute values: When libraries are used they will
contain definition elements with "name" attributes for later contain definition elements with "name" attributes for later
referencing. How to avoid name clashes for those identifiers? referencing. How to avoid name clashes for those identifiers?
When an SDPng document uses libraries from different sources they When an SDPng document uses libraries from different sources they
could be incompatible because of name collisions. Possible could be incompatible because of name collisions. Possible
solution: Prefix such IDs with a namespace name (either explicitly solution: Prefix such IDs with a namespace name (either explicitly
or implicitly by interpreting applications). The explicit or implicitly by interpreting applications). The explicit
prefixes have the advantage that no special knowledge would be prefixes have the advantage that no special knowledge would be
required to resolve links at the cost of very long ID values. required to resolve links at the cost of very long ID values.
A registry (reuse of SDP mechanisms and names etc.) needs to be A registry (reuse of SDP mechanisms and names etc.) needs to be
set up. set up.
Negotiation mechanisms for multiparty conferencing need to be Implicit declaration of SDPng schema and default package
formalized.
Mapping to other media description formats (SDP, H.245, ...)
should be provided. For H.245, this is probably a different
document (belonging to the SIP-H.323 inter-working group).
Implicit declaration of SDPng schema and default profiles
Should overwriting of child elements be allowed for referencing Should overwriting of child elements be allowed for referencing
existing definitions with the "ref" attribute? existing definitions with the "ref" attribute?
7. Acknowledgements We need a package definition language. XML-DTDs or XML-Schema is
not sufficient as we need ways to specify the type (string/symbol,
set, numerical range) and additional attributes (optional).
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.
skipping to change at page 53, line 14 skipping to change at page 34, line 14
[14] World Wide Web Consortium (W3C), "XML Schema Part 2: [14] World Wide Web Consortium (W3C), "XML Schema Part 2:
Datatypes", Version http://www.w3.org/TR/2001/REC-xmlschema-2- Datatypes", Version http://www.w3.org/TR/2001/REC-xmlschema-2-
20010502/, Status W3C Recommendation, May 2001. 20010502/, Status W3C Recommendation, May 2001.
[15] World Wide Web Consortium (W3C), "XML Linking Language (XLink) [15] World Wide Web Consortium (W3C), "XML Linking Language (XLink)
Version 1.0", Version http://www.w3.org/TR/2001/REC-xlink- Version 1.0", Version http://www.w3.org/TR/2001/REC-xlink-
20010627/, Status W3C Recommendation, June 2001. 20010627/, Status W3C Recommendation, June 2001.
[16] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [16] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
SDP", draft-ietf-mmusic-sdp-offer-answer-02.txt (work in SDP", RFC 3264, June 2002.
progress), February 2002.
[17] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for The [17] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for The
Use of XML within IETF Protocols", draft-hollenbeck-ietf-xml- Use of XML within IETF Protocols", draft-hollenbeck-ietf-xml-
guidelines-05.txt (work in progress), June 2002. guidelines-05.txt (work in progress), June 2002.
[18] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
2533, 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 55, line 5 skipping to change at page 36, 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. SDPng Audio Codec Profile and Audio Codec Library Appendix A. Use of SDPng in conjunction with other IETF Signaling
This section defines an SDPng profile for audio codec definitions and
a corresponding library of SDPng definitions of specific audio
codecs.
A.1 Audio Codec Profile
[5] specifies a number of audio codecs including short name to be
used as reference by session description protocols such as SDP and
SDPng. Those codec names, as listed in the first column of the above
table, are used to identify codecs in SDPng.
The following sections indicate the default values that are assumed
if nothing else than the codec reference is specified.
The following audio:codec attributes are defined for audio codecs:
name: the identifier to be later used for referencing the codec spec
encoding: the RTP/AVP profile identifier as registered with IANA
mime: the MIME type; may alternatively be specified instead of
"encoding"
channels: the number of independent media channels
pattern: the media channel pattern for mapping channels to payload
sampling: the sample rate for the codec (which in most cases equals
the RTP clock)
Furthermore, options may be defined of the following format:
<option id="name">value</option>
if a value is associated with the option (note that arbitrary complex
values are allowed), or alternatively:
<option id="name"/>
if the option is just a boolean indicator.
Attributes for the "option" tag are the following:
id: the identifier for the option (variable name)
collaps: the collapsing rules for this optional element, defined as
follows:
min: for numeric values only
max: for numeric values only
x: intersection of enumerated values, value lists
The following profile defines an element type that can be used for
specifying audio codec characteristics. The element "audio:codec" is
of type "audio:AudioCodec" which is derived from the SDPng base type
"sdpng:Definition". The element "audio:codec" is declared to have
the substitution group "sdpng:d" (the "head element" of the SDPng
base definition).
This means, "audio:codec" element can be used as child elements in
"sdpng:def" elements. In addition to the attributes specified here
"audio:codec" elements will also have to provide a "name" attribute
as defined by "sdpng:Definition".
<xsd:schema targetNamespace="http://www.iana.org/sdpng/audio"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:import namespace="http://www.iana.org/sdpng"
schemaLocation="sdpng.xsd"/>
<!-- AudioCodecs extends the abstract type "Definition" -->
<!-- The data types for the attributes could be more restrictive... -->
<xsd:complexType name="AudioCodec" mixed="false">
<xsd:complexContent mixed="false">
<xsd:extension base="sdpng:Definition">
<xsd:attribute name="encoding" type="xsd:string"/>
<xsd:attribute name="sampling" type="xsd:positiveInteger"/>
<xsd:attribute name="channels" type="xsd:positiveInteger"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="codec" substitutionGroup="sdpng:definition">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="audio:AudioCodec"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>
A.2 SDPng Library for Audio Codec Definitions
This section contains an SDPng library with the audio codec
definitions from Appendix A.
A.2.1 DVI4
<audio:codec name="dvi4" encoding="DVI4" channels="1" sampling="8000">
<rtp:pt name="rtp-avp-5" pt="5">
<audio:codec ref="dvi4"/>
</rtp:pt>
<rtp:pt name="rtp-avp-6" pt="6">
<audio:codec ref="dvi4" sampling="16000"/>
</rtp:pt>
Note that there is no default sampling rate specified for DVI4 and
hence a sampling rate MUST be specified.
A.2.2 G.722
<audio:codec name="g722" encoding="G722" channels="1" sampling="16000"/>
<rtp:pt name="rtp-avp-9" pt="9">
<audio:codec ref="g722"/>
</rtp:pt>
Note as per [5] that the RTP clock rate is 8000Hz rather than 16000
Hz.
A.2.3 G.726
<audio:codec name="g726-40" encoding="G726-40" channels="1" sampling="8000"/>
<audio:codec name="g726-32" encoding="G726-32" channels="1" sampling="8000"/>
<audio:codec name="g726-24" encoding="G726-24" channels="1" sampling="8000"/>
<audio:codec name="g726-16" encoding="G726-16" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-5" pt="5">
<audio:codec ref="g726-32"/>
</rtp:pt>
A.2.4 G.728
<audio:codec name="g728" encoding="G728" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-15" pt="15">
<audio:codec ref="g728"/>
</rtp:pt>
A.2.5 G.729
G.729 Annex A: reduced complexity of G.729
G.729 Annex B: comfort noise
<audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-18" pt="18">
<audio:codec ref="g729"/>
</rtp:pt>
For further codec description, the following options (which carry no
values associated with them) MAY be included:
<option id="annexA"/>
<!-- to indicate the use of Annex A reduced complexity -->
<option id="annexB"/>
<!-- to indicate the use of Annex B comfort noise -->
As stated in [5], the use of these options can be detected within the
media stream.
A.2.6 G.729 Annex D and E
<audio:codec name="g729d" encoding="G729D" channels="1" sampling="8000"/>
<audio:codec name="g729e" encoding="G729E" channels="1" sampling="8000"/>
The following option MAY be used with both Annexes D and E:
<option id="annexB"/>
<!-- to indicate the use of Annex B comfort noise -->
A.2.7 GSM
A.2.7.1 GSM Full Rate
The GSM Full Rate codec is indicated as follows:
<audio:codec name="gsm" encoding="GSM" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-3" pt="3">
<audio:codec ref="gsm"/>
</rtp:pt>
A.2.7.2 GSM Half Rate
The GSM Half Rate codec is indicated as follows:
<audio:codec name="gsm-hr" encoding="GSM-HR" channels="1" sampling="8000"/>
A.2.7.3 GSM Enhanced Full Rate
The GSM Enhanced Full Rate codec is indicated as follows:
<audio:codec name="gsm-efr" encoding="GSM-EFR" channels="1" sampling="8000"/>
A.2.8 L8
<audio:codec name="l8" encoding="L8" channels="1" sampling="8000"/>
A.2.9 L16
<audio:codec name="l16" encoding="L16" channels="1" sampling="8000"/>
<audio:codec name="l16-2" ref="l16" channels="2"/>
<rtp:pt name="rtp-avp-10" pt="10">
<audio:codec ref="l16"/>
</rtp:pt>
<rtp:pt name="rtp-avp-11" pt="11">
<audio:codec ref="l16-2"/>
</rtp:pt>
A.2.10 LPC
<audio:codec name="lpc" encoding="LPC" channels="1" sampling="8000"/>
A.2.11 MPA
<audio:codec name="mpa" encoding="MPA" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-14" pt="14">
<audio:codec ref="mpa"/>
</rtp:pt>
A.2.12 PCMA and PCMU
<audio:codec name="pcmu" encoding="PCMU" channels="1" sampling="8000"/>
<audio:codec name="pcma" encoding="PCMA" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-0" pt="0">
<audio:codec ref="pcmu"/>
</rtp:pt>
<rtp:pt name="rtp-avp-8" pt="8">
<audio:codec ref="pcma"/>
</rtp:pt>
A.2.13 QCELP
<audio:codec name="qcelp" encoding="QCELP" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-12" pt="12">
<audio:codec ref="qcelp"/>
</rtp:pt>
A.2.14 VDVI
<audio:codec name="vdvi" encoding="VDVI" channels="1" sampling="8000"/>
<def xmlns="http://www.iana.org/sdpng"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng/int integrated.xsd"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp">
<audio:codec name="dvi4" encoding="DVI4" channels="1" sampling="8000"/>
<audio:codec name="g722" encoding="G722" channels="1" sampling="16000"/>
<audio:codec name="g726-40" encoding="G726-40" channels="1" sampling="8000"/>
<audio:codec name="g726-32" encoding="G726-32" channels="1" sampling="8000"/>
<audio:codec name="g726-24" encoding="G726-24" channels="1" sampling="8000"/>
<audio:codec name="g726-16" encoding="G726-16" channels="1" sampling="8000"/>
<audio:codec name="g728" encoding="G728" channels="1" sampling="8000"/>
<audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/>
<audio:codec name="g729d" encoding="G729D" channels="1" sampling="8000"/>
<audio:codec name="g729e" encoding="G729E" channels="1" sampling="8000"/>
<audio:codec name="gsm" encoding="GSM" channels="1" sampling="8000"/>
<audio:codec name="gsm-hr" encoding="GSM-HR" channels="1" sampling="8000"/>
<audio:codec name="gsm-efr" encoding="GSM-EFR" channels="1" sampling="8000"/>
<audio:codec name="l8" encoding="L8" channels="1" sampling="8000"/>
<audio:codec name="l16" encoding="L16" channels="1" sampling="8000"/>
<audio:codec name="lpc" encoding="LPC" channels="1" sampling="8000"/>
<audio:codec name="mpa" encoding="MPA" channels="1" sampling="8000"/>
<audio:codec name="pcmu" encoding="PCMU" channels="1" sampling="8000"/>
<audio:codec name="pcma" encoding="PCMA" channels="1" sampling="8000"/>
<audio:codec name="qcelp" encoding="QCELP" channels="1" sampling="8000"/>
<audio:codec name="vdvi" encoding="VDVI" channels="1" sampling="8000"/>
</def>
Appendix B. SDPng Profile for RTP Profile and RTP Library
B.1 RTP profile
The following profile defines element types that can be used for
specifying RTP payload types and RTP session configurations. The
element "rtp:pt" is of type "rtp:PayloadType" which is derived from
the SDPng base type "sdpng:Definition". The element "rtp:pt" is
declared to have the substitution group "sdpng:d" (the "head element"
of the SDPng base definition).
The element "rtp:session" is of type "rtp:Session" which is derived
from the SDPng base type "sdpng:SessionConfig". The element
"rtp:session" is declared to have the substitution group "sdpng:sc"
(the "head element" of the SDPng base definition).
The RTP profile in turn defines base types for the specification of
transport parameters that are to be derived from by profiles that
define rules for elements that can be used to specify parameters for
specific transport mechanisms.
<xsd:schema targetNamespace="http://www.iana.org/sdpng/rtp"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:import namespace="http://www.iana.org/sdpng"
schemaLocation="sdpng.xsd"/>
<xsd:complexType name="PayloadType" mixed="false">
<xsd:annotation>
<xsd:documentation>
PayloadType, the element for payload type definitions is
derived from "sdpng:Definition". Inside an element of this
type, more definitions may be given (derived from
sdpng:Definition themselves).
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent mixed="false">
<xsd:extension base="sdpng:Definition">
<xsd:sequence>
<xsd:element ref="sdpng:definition" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="pt" type="xsd:unsignedByte"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="pt" type="rtp:PayloadType" substitutionGroup="sdpng:definition"/>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:element name="session" type="rtp:Session" substitutionGroup="sdpng:sessionConfig"/>
<xsd:complexType name="Session" mixed="false">
<xsd:complexContent mixed="false">
<xsd:extension base="sdpng:SessionConfig">
<xsd:sequence>
<xsd:element ref="rtp:pt"/>
<xsd:element ref="rtp:transport"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Transport" abstract="true" mixed="false">
<xsd:complexContent>
<xsd:extension base="sdpng:Definition">
<xsd:attribute name="role" type="xsd:string"/>
<xsd:attribute name="endpoint" type="xsd:string"/>
<xsd:attribute name="rtp-port" type="xsd:unsignedShort" use="optional"/>
<xsd:attribute name="rtcp-port" type="xsd:unsignedShort" use="optional"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="transport" type="rtp:Transport" substitutionGroup="sdpng:definition"/>
<xsd:simpleType name="IPAddr">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="IP4Addr">
<xsd:restriction base="rtp:IPAddr"/>
</xsd:simpleType>
<xsd:simpleType name="IP6Addr">
<xsd:restriction base="rtp:IPAddr"/>
</xsd:simpleType>
<xsd:complexType name="UDP" mixed="false">
<xsd:complexContent mixed="false">
<xsd:extension base="rtp:Transport">
<xsd:choice>
<xsd:element name="option">
<!-- define options -->
</xsd:element>
</xsd:choice>
<xsd:attribute name="addr" type="rtp:IP4Addr"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="udp" type="rtp:UDP" substitutionGroup="rtp:transport"/>
</xsd:schema>
B.2 SDPng Library for RTP Payload Format Definitions
This section contains an SDPng library with the RTP payload format
definitions from Appendix A.
<def xmlns="http://www.iana.org/sdpng"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng/int integrated.xsd"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xi="http://www.w3.org/2001/XInclude">
<!-- import audio codec definitions here: -->
<xi:xinclude href="http://www.iana.org/sdpng/audio/audio.sdpng" parse="xml"/>
<rtp:pt name="rtp-avp-5" pt="5">
<audio:codec ref="dvi4"/>
</rtp:pt>
<rtp:pt name="rtp-avp-6" pt="6">
<audio:codec ref="dvi4" sampling="16000">
</rtp:pt>
<rtp:pt name="rtp-avp-9" pt="9">
<audio:codec ref="g722"/>
</rtp:pt>
<rtp:pt name="rtp-avp-5" pt="5">
<audio:codec ref="g726-32"/>
</rtp:pt>
<rtp:pt name="rtp-avp-15" pt="15">
<audio:codec ref="g728"/>
</rtp:pt>
<rtp:pt name="rtp-avp-18" pt="18">
<audio:codec ref="g729"/>
</rtp:pt>
<rtp:pt name="rtp-avp-3" pt="3">
<audio:codec ref="gsm"/>
</rtp:pt>
<rtp:pt name="rtp-avp-10" pt="10">
<audio:codec ref="l16"/>
</rtp:pt>
<rtp:pt name="rtp-avp-11" pt="11">
<audio:codec ref="l16-2"/>
</rtp:pt>
<rtp:pt name="rtp-avp-14" pt="14">
<audio:codec ref="mpa"/>
</rtp:pt>
<rtp:pt name="rtp-avp-0" pt="0">
<audio:codec ref="pcmu"/>
</rtp:pt>
<rtp:pt name="rtp-avp-8" pt="8">
<audio:codec ref="pcma"/>
</rtp:pt>
<rtp:pt name="rtp-avp-12" pt="12">
<audio:codec ref="qcelp"/>
</rtp:pt>
</def>
Appendix C. Use of SDPng in conjunction with other IETF Signaling
Protocols Protocols
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
skipping to change at page 67, line 37 skipping to change at page 36, line 37
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: 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.
C.1 The Session Announcement Protocol (SAP) A.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.
skipping to change at page 68, line 20 skipping to change at page 37, line 20
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. Example from the SAP spec. to be provided.
C.2 Session Initiation Protocol (SIP) A.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 and ACK messages as well as in
a number of responses. From dealing with legacy SDP (and its a number of responses. From dealing with legacy SDP (and its
essential non-suitability for capability negotiation), a particular essential non-suitability for capability negotiation), a particular
use and interpretation of SDP has been defined for SIP. use and interpretation of SDP has been defined for SIP.
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.
skipping to change at page 75, line 18 skipping to change at page 44, line 18
the transport specification in the def element and references this the transport specification in the def element and references this
definition in the rtp:session elements for both alternatives by using definition in the rtp:session elements for both alternatives by using
the attribute "transport". the attribute "transport".
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.
B does only support PCMU, so it removes the alternative for G.729 B does only support PCMU, so it removes the alternative for G.729
from the description. B also defines its transport address in the from the description. B also defines its transport address in the
def element and references this definition by referencing the rtp:udp def element and references this definition by referencing the rtp:udp
element named "B-rcv". element named "B-rcv".
C.3 Real-Time Streaming Protocol (RTSP) A.3 Real-Time Streaming Protocol (RTSP)
In contrast to SIP, RTSP has, from its intended usage, a clear In contrast to SIP, RTSP has, from its intended usage, a clear
distinction between offering Potential Configurations (typically by distinction between offering Potential Configurations (typically by
the server) and choosing one out of these (by the client), and, in the server) and choosing one out of these (by the client), and, in
some cases; some parameters (such as multicast addresses) may be some cases; some parameters (such as multicast addresses) may be
dictated by the server. Hence with RTSP, there is a clear dictated by the server. Hence with RTSP, there is a clear
distinguish between Potential Configurations during the negotiation distinguish between Potential Configurations during the negotiation
phase and a finally chosen Actual Configuration according to which phase and a finally chosen Actual Configuration according to which
streaming will take place. streaming will take place.
Example from the RTSP spec to be provided. Example from the RTSP spec to be provided.
C.4 Media Gateway Control Protocol (MEGACOP) A.4 Media Gateway Control Protocol (MEGACOP)
The MEGACO architecture also follows the SDPng model of a clear The MEGACO architecture also follows the SDPng model of a clear
separation between Potential and Actual Configurations. Upon separation between Potential and Actual Configurations. Upon
startup, a Media Gateway (MG) will "register" with its Media Gateway startup, a Media Gateway (MG) will "register" with its Media Gateway
Controller (MGC) and the latter will audit the MG for its Controller (MGC) and the latter will audit the MG for its
Capabilities. Those will be provided as Potential Configurations, Capabilities. Those will be provided as Potential Configurations,
possibly with extensive Constraints specifications. Whenever a media 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 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 be reconfigured internally, the MGC will use (updated) Actual
Configurations. Configurations.
Details and examples to be defined. Details and examples to be defined.
Appendix D. Change History Appendix B. Change History
draft-ietf-mmusic-sdpng-06.txt
* Removed section on capability negotiation algorithm and section
on formal specification. Added Section 3.
* Removed specification of concrete XML syntax from Section 4.
Added requirements and theoretic considerations.
* Added clarification of term "actual configuration" in Section
2.
* Changed "profile" to "package".
* Added introducing text to Section 4.1.
* Added a list of terms with explanation at the end of Section 2.
* Removed audio and RTP packages from appendix.
* Added Section 5 ("Syntax Definition").
* Added Section 6 ("Specification of the Capability
Negotiation").
draft-ietf-mmusic-sdpng-05.txt draft-ietf-mmusic-sdpng-05.txt
* Moved audio and RTP profile 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 3.3). Removed other referenced existing definitions (Section 4.3). Removed other
mechanisms for referencing (attributes "format" and mechanisms for referencing (attributes "format" and
"transport", element type "use"). "transport", element type "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 (Section 4). * New section on capability negotiation.
* New section on referencing definitions (Section 3.3). * New section on referencing definitions (Section 4.3).
* 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
* Fixed examples * Fixed examples
* Added example libraries as appendices * Added example libraries as appendices
* More details on usage with SIP, including examples. * More details on usage with SIP, including examples.
draft-ietf-mmusic-sdpng-02.txt draft-ietf-mmusic-sdpng-02.txt
* Added a section on formal specification mechanisms (Section 5). * Added a section on formal specification mechanisms.
draft-ietf-mmusic-sdpng-01.txt draft-ietf-mmusic-sdpng-01.txt
* renamed section "Syntax Proposal" to "Syntax Definition * renamed section "Syntax Proposal" to "Syntax Definition
Mechanisms". More text on DTD vs. schema. Edited the example Mechanisms". More text on DTD vs. schema. Edited the example
description. description.
* updated example definitions in section "Definitions" and * updated example definitions in section "Definitions" and
"Components & Configurations" "Components & Configurations"
* section "Session Attributes" replaces section "Session" * section "Session Attributes" replaces section "Session"
* new appendix on audio codec definitions * new appendix on audio codec definitions
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its 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
 End of changes. 

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