draft-ietf-mmusic-sdpng-02.txt   draft-ietf-mmusic-sdpng-03.txt 
Network Working Group Kutscher Network Working Group Kutscher
Internet-Draft Ott Internet-Draft Ott
Expires: February 22, 2002 Bormann Expires: May 22, 2002 Bormann
TZI, Universitaet Bremen TZI, Universitaet Bremen
August 24, 2001 November 21, 2001
Session Description and Capability Negotiation Session Description and Capability Negotiation
draft-ietf-mmusic-sdpng-02.txt draft-ietf-mmusic-sdpng-03.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 February 22, 2002. This Internet-Draft will expire on May 22, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). 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 confctrl@isi.edu and/or the authors. group's mailing list at confctrl@isi.edu and/or the authors.
Document Revision Document Revision
$Revision: 2.7 $ $Revision: 4.7 $
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and System Model . . . . . . . . . . . . . . . 6 2. Terminology and System Model . . . . . . . . . . . . . . . 6
3. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . 9 3.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Components & Configurations . . . . . . . . . . . . . . . 11 3.1.2 Components & Configurations . . . . . . . . . . . . . . . 11
3.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.4 Session Attributes . . . . . . . . . . . . . . . . . . . . 14 3.1.4 Session Attributes . . . . . . . . . . . . . . . . . . . . 14
3.1.4.1 Owner . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.4.1 Owner . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.4.2 Session Identification . . . . . . . . . . . . . . . . . . 15 3.1.4.2 Session Identification . . . . . . . . . . . . . . . . . . 15
3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) . . . 16 3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) . . . 16
3.1.4.4 Component Semantic Specification . . . . . . . . . . . . . 17 3.1.4.4 Component Semantic Specification . . . . . . . . . . . . . 17
3.2 Syntax Definition Mechanisms . . . . . . . . . . . . . . . 18 3.2 Syntax Definition Mechanisms . . . . . . . . . . . . . . . 18
3.3 External Definition Packages . . . . . . . . . . . . . . . 21 3.3 External Definition Packages . . . . . . . . . . . . . . . 20
3.3.1 Profile Definitions . . . . . . . . . . . . . . . . . . . 21 3.3.1 Profile Definitions . . . . . . . . . . . . . . . . . . . 21
3.3.2 Library Definitions . . . . . . . . . . . . . . . . . . . 21 3.3.2 Library Definitions . . . . . . . . . . . . . . . . . . . 21
3.4 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 23
4. Formal Specification . . . . . . . . . . . . . . . . . . . 24 4. Formal Specification . . . . . . . . . . . . . . . . . . . 24
4.1 XML Schema as a Definition Mechanism . . . . . . . . . . . 24 4.1 XML Schema as a Definition Mechanism . . . . . . . . . . . 24
4.2 SDPng Schema . . . . . . . . . . . . . . . . . . . . . . . 25 4.2 SDPng Schema . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.3 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 SDPng Documents . . . . . . . . . . . . . . . . . . . . . 26 4.4 SDPng Documents . . . . . . . . . . . . . . . . . . . . . 27
4.5 Libraries . . . . . . . . . . . . . . . . . . . . . . . . 27 4.5 Libraries . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6 Details on the use of specific XML Mechanisms . . . . . . 28 4.6 Details on the use of specific XML Mechanisms . . . . . . 29
4.6.1 Default Namespace . . . . . . . . . . . . . . . . . . . . 28 4.6.1 Default Namespace . . . . . . . . . . . . . . . . . . . . 29
4.6.2 Qualified Locals . . . . . . . . . . . . . . . . . . . . . 29 4.6.2 Qualified Locals . . . . . . . . . . . . . . . . . . . . . 29
4.6.3 Fixed Namespace Prefixes . . . . . . . . . . . . . . . . . 29 4.6.3 Fixed Namespace Prefixes . . . . . . . . . . . . . . . . . 30
4.7 SDPng Schema Definitions . . . . . . . . . . . . . . . . . 29 4.7 SDPng Schema Definitions . . . . . . . . . . . . . . . . . 30
4.7.1 SDPng Base Definition . . . . . . . . . . . . . . . . . . 30 4.7.1 SDPng Base Definition . . . . . . . . . . . . . . . . . . 30
4.7.2 Audio Codec Profile . . . . . . . . . . . . . . . . . . . 36 4.7.2 Audio Codec Profile . . . . . . . . . . . . . . . . . . . 37
4.7.3 RTP profile . . . . . . . . . . . . . . . . . . . . . . . 37 4.7.3 RTP profile . . . . . . . . . . . . . . . . . . . . . . . 38
4.8 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.8 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5. Use of SDPng in conjunction with other IETF Signaling 5. Use of SDPng in conjunction with other IETF Signaling
Protocols . . . . . . . . . . . . . . . . . . . . . . . . 41 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1 The Session Announcement Protocol (SAP) . . . . . . . . . 41 5.1 The Session Announcement Protocol (SAP) . . . . . . . . . 42
5.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . 42 5.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . 43
5.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . 42 5.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . 49
5.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . 43 5.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . 50
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 44 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 51
References . . . . . . . . . . . . . . . . . . . . . . . . 45 References . . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53
A. Base SDPng Specifications for Audio Codec Descriptions . . 47 A. Base SDPng Specifications for Audio Codec Descriptions . . 54
A.1 DVI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.1 DVI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.2 G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.2 G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.3 G.726 . . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.3 G.726 . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.4 G.728 . . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.4 G.728 . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.5 G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.5 G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.6 G.729 Annex D and E . . . . . . . . . . . . . . . . . . . 49 A.6 G.729 Annex D and E . . . . . . . . . . . . . . . . . . . 56
A.7 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 A.7 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
A.7.1 GSM Full Rate . . . . . . . . . . . . . . . . . . . . . . 49 A.7.1 GSM Full Rate . . . . . . . . . . . . . . . . . . . . . . 56
A.7.2 GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . 49 A.7.2 GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . 56
A.7.3 GSM Enhanced Full Rate . . . . . . . . . . . . . . . . . . 49 A.7.3 GSM Enhanced Full Rate . . . . . . . . . . . . . . . . . . 56
A.8 L8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.8 L8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.9 L16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.9 L16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.10 LPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.10 LPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.11 MPA . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.11 MPA . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.12 PCMA and PCMU . . . . . . . . . . . . . . . . . . . . . . 50 A.12 PCMA and PCMU . . . . . . . . . . . . . . . . . . . . . . 57
A.13 QCELP . . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.13 QCELP . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.14 VDVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.14 VDVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
B. Change History . . . . . . . . . . . . . . . . . . . . . . 51 B. SDPng Library for Audio Codec Definitions . . . . . . . . 58
Full Copyright Statement . . . . . . . . . . . . . . . . . 52 C. SDPng Library for RTP Payload Format Definitions . . . . . 59
D. Change History . . . . . . . . . . . . . . . . . . . . . . 60
Full Copyright Statement . . . . . . . . . . . . . . . . . 61
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
required because only those participants with media tools that required because only those participants with media tools that
support the predefined settings can join a media session and/or a support the predefined settings can join a media session and/or a
conference. conference.
This approach is applicable for conferences that are announced some This approach is applicable for conferences that are announced some
time ahead of the actual start date of the conference. Potential time ahead of the actual start date of the conference. Potential
participants can check the availability of media tools in advance and participants can check the availability of media tools in advance and
tools like session directories can configure media tools on startup. tools such as session directories can configure media tools upon
This procedure however fails to work for conferences initiated startup. This procedure however fails to work for conferences
spontaneously like Internet phone calls or ad-hoc multiparty initiated spontaneously including Internet phone calls or ad-hoc
conferences. Fixed settings for parameters like media types, their multiparty conferences. Fixed settings for parameters such as media
encoding etc. can easily inhibit the initiation of conferences, for types, their encoding etc. can easily inhibit the initiation of
example in situations where a caller insists on a fixed audio conferences, for example in situations where a caller insists on a
encoding that is not available at the callee's end system. fixed audio encoding that is not available at the callee's end-
system.
To allow for spontaneous conferences, the process of defining a To allow for spontaneous conferences, the process of defining a
conference's parameter set must therefore be performed either at conference's parameter set must therefore be performed either at
conference start (for closed conferences) or maybe (potentially) even conference start (for closed conferences) or maybe (potentially) even
repeatedly every time a new participant joins an active conference. repeatedly every time a new participant joins an active conference.
The latter approach may not be appropriate for every type of The latter approach may not be appropriate for every type of
conference without applying certain policies: For conferences with conference without applying certain policies: For conferences with
TV-broadcast or lecture characteristics (one main active source) it TV-broadcast or lecture characteristics (one main active source) it
is usually not desired to re-negotiate parameters every time a new is usually not desired to re-negotiate parameters every time a new
participant with an exotic configuration joins because it may participant with an exotic configuration joins because it may
skipping to change at page 5, line 16 skipping to change at page 5, line 16
(the original purpose of SDP) and (the original purpose of SDP) and
o to describe the capabilities of a system and possibly provide a o to describe the capabilities of a system and possibly provide a
choice between a number of alternatives (which SDP was not choice between a number of alternatives (which SDP was not
designed for). designed for).
A distinction between these two "sets of semantics" is only made A distinction between these two "sets of semantics" 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 and introduce the for session description and capability negotiation as well as the
basic terms used throughout this specification (section 2). Then we basic terms used throughout this specification (section 2). Next, we
outline the concept for the concepts underlying SDPng and introduce outline the concept for the concepts underlying SDPng and introduce
the syntactical components step by step in section 3. In section 4, the syntactical components step by step in section 3. In section 4,
we provide a formal definition of the SDPng session description we provide a formal definition of the SDPng session description
language. Finally, we overview aspects of using SDPng with various language. Finally, we overview aspects of using SDPng with various
IETF signaling protocols in section 5. In Appendix A, we introduce IETF signaling protocols in section 5. In Appendix A, we provide
basic audio codec and payload type definitions. basic audio codec and payload type definitions that are subsumed in
SDPng libraries in Appendix B and Appendix C.
The next version of this draft will only contain the formal
specification of the language itself. Requirements and the
description of the system model will be moved to a separate document.
2. Terminology and System Model 2. Terminology and System Model
Any (computer) system has, at a time, a number of rather fixed Any (computer) system has, at a time, a number of rather fixed
hardware as well as software resources. These resources ultimately hardware as well as software resources. These resources ultimately
define the limitations on what can be captured, displayed, rendered, define the limitations on what can be captured, displayed, rendered,
replayed, etc. with this particular device. We term features replayed, etc. with this particular device. We term features enabled
enabled and restricted by these resources "system capabilities". and restricted by these resources "system capabilities".
Example: System capabilities may include: a limitation of the Example: System capabilities may include: a limitation of the
screen resolution for true color by the graphics board; available screen resolution for true color by the graphics board; available
audio hardware or software may offer only certain media encodings audio hardware or software may offer only certain media encodings
(e.g. G.711 and G.723.1 but not GSM); and CPU processing power (e.g. G.711 and G.723.1 but not GSM); and CPU processing power and
and quality of implementation may constrain the possible video quality of implementation may constrain the possible video
encoding algorithms. encoding algorithms.
In multiparty multimedia conferences, participants employ different In multiparty multimedia conferences, participants employ different
"components" in conducting the conference. "components" in conducting the conference.
Example: In lecture multicast conferences one component might be Example: In lecture multicast conferences one component might be
the voice transmission for the lecturer, another the transmission the voice transmission for the lecturer, another the transmission
of video pictures showing the lecturer and the third the of video pictures showing the lecturer and the third the
transmission of presentation material. transmission of presentation material.
Depending on system capabilities, user preferences and other Depending on system capabilities, user preferences and other
technical and political constraints, different configurations can be technical and political constraints, different configurations can be
chosen to accomplish the "deployment" of these components. chosen to accomplish the use of these components in a conference.
Each component can be characterized at least by (a) its intended use Each component can be characterized at least by (a) its intended use
(i.e. the function it shall provide) and (b) a one or more possible (i.e. the function it shall provide) and (b) one or more possible
ways to realize this function. Each way of realizing a particular ways to realize this function. Each way of realizing a particular
function is referred to as a "configuration". function is referred to as a "configuration".
Example: A conference component's intended use may be to make Example: A conference component's intended use may be to make
transparencies of a presentation visible to the audience on the transparencies of a presentation visible to the audience on the
Mbone. This can be achieved either by a video camera capturing Mbone. This can be achieved either by a video camera capturing
the image and transmitting a video stream via some video tool or the image and transmitting a video stream via some video tool or
by loading a copy of the slides into a distributed electronic by loading a copy of the slides into a distributed electronic
whiteboard. For each of these cases, additional parameters may white-board. For each of these cases, additional parameters may
exist, variations of which lead to additional configurations (see exist, variations of which lead to additional configurations (see
below). below).
Two configurations are considered different regardless of whether Two configurations are considered different regardless of whether
they employ entirely different mechanisms and protocols (as in the they employ entirely different mechanisms and protocols (as in the
previous example) or they choose the same and differ only in a single previous example) or they choose the same and differ only in a single
parameter. parameter.
Example: In case of video transmission, a JPEG-based still image Example: In case of video transmission, a JPEG-based still image
protocol may be used, H.261 encoded CIF images could be sent as protocol may be used, H.261 encoded CIF images could be sent, as
could H.261 encoded QCIF images. All three cases constitute could H.261 encoded QCIF images. All three cases constitute
different configurations. Of course there are many more detailed different configurations. Of course there are many more detailed
protocol parameters. protocol parameters.
Each component's configurations are limited by the participating Each component's configurations are limited by the participating
system's capabilities. In addition, the intended use of a component system's capabilities. In addition, the intended use of a component
may constrain the possible configurations further to a subset may constrain the possible configurations further to a subset
suitable for the particular component's purpose. suitable for the particular component's purpose.
Example: In a system for highly interactive audio communication Example: In a system for highly interactive audio communication
the component responsible for audio may decide not to use the the component responsible for audio may decide not to use the
available G.723.1 audio codec to avoid the additional latency but available G.723.1 audio codec to avoid the additional latency but
only use G.711. This would be reflected in this component only only use G.711. This would be reflected in this component only
showing configurations based upon G.711. Still, multiple showing configurations based upon G.711. Still, multiple
configurations are possible, e.g. depending on the use of A-law configurations are possible, e.g. depending on the use of A-law
or u-Law, packetization and redundancy parameters, etc. or u-Law, packetization and redundancy parameters, etc.
In this system model, we distinguish two types of configurations: In modelling multimedia sessions, we distinguish two types of
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 7, line 43 skipping to change at page 7, line 44
component may indicate support for JPEG, H.261/CIF, and component may indicate support for JPEG, H.261/CIF, and
H.261/QCIF. A particular instantiation for a video conference may H.261/QCIF. A particular instantiation for a video conference may
use the actual configuration of H.261/CIF for exchanging video use the actual configuration of H.261/CIF for exchanging video
streams. streams.
In summary, the key terms of this model are: In summary, the key terms of this model are:
o A multimedia session (streaming or conference) consists of one or o A multimedia session (streaming or conference) consists of one or
more conference components for multimedia "interaction". more conference components for multimedia "interaction".
o A component describes a particular type of interaction (e.g. o A component describes a particular type of interaction (e.g. audio
audio conversation, slide presentation) that can be realized by conversation, slide presentation) that can be realized by means of
means of different applications (possibly using different different applications (possibly using different protocols).
protocols).
o A configuration is a set of parameters that are required to o A configuration is a set of parameters that are required to
implement a certain variation (realization) of a certain implement a certain variation (realization) of a certain
component. There are actual and potential configurations. component. There are actual and potential configurations.
* Potential configurations describe possible configurations that * Potential configurations describe possible configurations that
are supported by an end system. are supported by an end-system.
* An actual configuration is an "instantiation" of one of the * An actual configuration is an "instantiation" of one of the
potential configurations, i.e. a decision how to realize a potential configurations, i.e. a decision how to realize a
certain component. certain component.
In less abstract words, potential configurations describe what a In less abstract words, potential configurations describe what a
system can do ("capabilities") and actual configurations describe system can do ("capabilities") and actual configurations describe
how a system is configured to operate at a certain point in time how a system is configured to operate at a certain point in time
(media stream spec). (media stream spec).
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.).
In SAP-based [11] 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
a receiver must understand to participate. receiver must understand to participate.
In point-to-point scenarios, the negotiation procedure is typically In point-to-point scenarios, the negotiation procedure is typically
carried out implicitly: each party informs the other about what it carried out implicitly: each party informs the other about what it
can receive and the respective sender chooses from this set a can receive and the respective sender chooses from this set a
configuration that it can transmit. configuration that it can transmit.
Capability negotiation must not only work for 2-party conferences but Capability negotiation must not only work for 2-party conferences but
is also required for multi-party conferences. Especially for the is also required for multi-party conferences. Especially for the
latter case it is required that the process of determining the subset latter case it is required that the process to determine the subset
of allowable potential configurations is deterministic to reduce the of allowable potential configurations is deterministic to reduce the
number of required round trips before a session can be established. number of required round trips before a session can be established.
For instance, in order to be used with SIP, the capability
negotiation is required to work with the offer/answer model that is
for session initiation with SIP -- limiting the negotiation to
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 3. SDPng
This section introduces the underlying concepts of the Session This section introduces the underlying concepts of the Session
Description Protocol - next generation (SDPng) that is to meet most Description Protocol - next generation (SDPng). The focus of this
of the above requirements. The focus of this section is on the section is on the concepts of the capability description and
concepts of such a capability description and negotiation language negotiation language with a stepwise introduction of the various
with a stepwise introduction of the various syntactical elements; a syntactical elements. Note that this section does only examples
full formal specification is provided in section 4. accompanied by explanations -- a full formal specification is
provided in section 4.
3.1 Conceptual Outline 3.1 Conceptual Outline
The description language follows the system model introduced in the The description language follows the system model introduced in the
beginning of this document. We use a rather abstract language to beginning of this document. We use a rather abstract language to
avoid misinterpretations due to different intuitive understanding of avoid misinterpretations due to different intuitive understanding of
terms as far as possible. terms as far as possible.
The concept of a capability description language addresses various The concept of a capability description language addresses various
pieces of a full description of system and application capabilities pieces of a full description of system and application capabilities
skipping to change at page 9, line 35 skipping to change at page 9, line 36
Definitions (elementary and compound); see Section 3.1.1. Definitions (elementary and compound); see Section 3.1.1.
Potential or Actual Configurations; see Section 3.1.2. Potential or Actual Configurations; see Section 3.1.2.
Constraints; see Section 3.1.3. Constraints; see Section 3.1.3.
Session attributes; see Section 3.1.4. Session attributes; see Section 3.1.4.
3.1.1 Definitions 3.1.1 Definitions
The definition section specifies a number of basic abstractions that The "Definitions" section specifies a number of basic abstractions
are later referenced to avoid repetitions in more complex that are later referenced to avoid repetitions in more complex
specifications and allow for a concise representation. Definition specifications and allow for a concise representation. Definition
elements are labelled with an identifier by which they may be elements are labelled with an identifier by which they may be
referenced. They may be elementary or compound (i.e. combinations referenced. They may be elementary or compound (i.e. combinations
of elementary entities). Examples of definitions of that sections of elementary entities). Examples of definitions that could occur in
include (but are not limited to) codec definitions, redundancy "Definitions" sections include (but are not limited to) codec
schemes, transport mechanisms and payload formats. definitions, redundancy schemes, transport mechanisms and payload
formats.
Elementary definition elements do not reference other elements. Each Elementary definition elements do not reference other elements. Each
elementary entity only consists of one of more attributes and their elementary entity only consists of one of more attributes and their
values. Default values specified in the definition section may be values. Default values specified in the definition section may be
overridden in descriptions for potential (and later actual) overridden in descriptions for potential (and later actual)
configurations. A mechanisms for overriding definitions is specified configurations. A mechanisms for overriding definitions is specified
below. below.
For the moment, elementary elements are defined for media types (i.e. For the moment, elementary abstractions are defined for media types
(i.e. codecs) and for media transports mechanisms. For each
codecs) and for media transports. For each transport and for each transport and for each codec to be used, the respective attributes
codec to be used, the respective attributes need to be defined. This need to be defined. This definition may either be provided within
definition may either be provided within the "Definitions" section the "Definitions" section itself or in an external document (similar
itself or in an external document (similar to the audio-video profile to the audio-video profile or an IANA registry that defines payload
or an IANA registry that define payload types and media stream types and media stream identifiers).
identifiers.
It is not required to define all codec, transport mechanisms in a It is not required to define all codecs and transport mechanisms in a
definitions sections and reference them in the definition of "Definitions" sections and reference them when specifying potential
potential and actual configurations. Instead, a syntactic mechanism and actual configurations. Instead, a syntactic mechanism is defined
is defined that allows to specify some definitions directly in a that allows to give some definitions directly in a configurations
configurations section. section.
Examples for elementary definitions: Examples for elementary definitions:
<audio:codec name="audio-basic" encoding="PCMU" <audio:codec name="audio-basic" encoding="PCMU"
sampling="8000 channels="1"/> sampling="8000" channels="1"/>
<audio:codec name="audio-L16-mono" encoding="L16" <audio:codec name="audio-L16-mono" encoding="L16"
sampling="44100 channels="1"/> sampling="44100" channels="1"/>
The element type "audio:codec" is used in these examples to define The element type "audio:codec" is used in these examples to define
audio codec configurations. The configuration parameters are given audio codec configurations. The configuration parameters are given
as attribute values. as attribute values.
Definitions may have default values specified along with them for Definitions may have default values specified along with them for
each attribute (as well as for their contents). Some of these each attribute (as well as for their contents). Some of these
default values may be overridden so that a codec definition can default values may be overridden so that a codec definition can
easily be re-used in a different context (e.g. by specifying a easily be re-used in a different context (e.g. by specifying a
different sampling rate) without the need for a large number of base different sampling rate) without the need for a large number of base
specifications. In the following example the definition of audio- specifications. In the following example the definition of audio-
L16-mono is re-used for the defintion of the corresponding stereo L16-mono is re-used for the defintion of the corresponding stereo
codec. Appendix A provides a complete set of corresponding codec. Appendix A provides a complete set of corresponding
audio:codec definitions of the codec used in RFC 1890 [4]. audio:codec definitions of the codecs used in RFC 1890 [4].
<audio:codec name="audio-L16-stereo" ref="audio-L16-mono" <audio:codec name="audio-L16-stereo" ref="audio-L16-mono"
channels="2"/> channels="2"/>
The example shows how exisiting defintions can be referenced in new The example shows how existing definitions can be referenced in new
definitiones. This approach allows to have simple as well as more definitions. This approach allows to create simple as well as more
complex definitions which are commonly used be available in an complex definitions in an extensible set of reference documents.
extensible set of reference documents. Section 3.3 specifies the Section 3.3 specifies the mechanisms for external references.
mechanisms for external references.
Besides definitions of audio codecs there will be other definitions
like RTP payload format and specific transport mechanisms that are
suitable to be defined in a defintion section for later referencing.
The following example shows how RTP payload types are defined using a Besides definitions of audio codecs other definitions such as RTP
pre-defined codec. 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" format="audio-basic"/> <rtp:pt name="rtp-avp-0" pt="0" format="audio-basic"/>
<rtp:pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/> <rtp:pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/>
In this example, the payload type "rtp-avp-11" is defined with In this example, the payload type "rtp-avp-11" is defined with
payload type number 11, referencing the codec "audio-L16-mono". payload type number 11, referencing the codec "audio-L16-mono".
Instead of referencing an existing definition it is also possible to Instead of referencing an existing definition it is also possible to
define the format "inline": define the format "inline":
<rtp:pt name="rtp-avp-10" pt="10"> <rtp:pt name="rtp-avp-10" pt="10">
<audio:codec encoding="L16" sampling="44100 channels="2"/> <audio:codec encoding="L16" sampling="44100" channels="2"/>
</rtp:pt> </rtp:pt>
Note: For negotiation between endpoints, it may be helpful to define Note: For negotiation between endpoints, it may be helpful to define
two modes of operation: explicit and implicit. Implicit two modes of operation: explicit and implicit. Implicit
specifications may refer to externally defined entities to minimize specifications may refer to externally defined entities to minimize
traffic volume, explicit specifications would list all external traffic volume, explicit specifications would list all external
definitions used in a description in the "Definitions" section. definitions used in a description in the "Definitions" section.
Again, see Section 3.3 for complete discussion of external Again, see Section 3.3 for complete discussion of external
definitions. definitions.
The "Definitions" section may be empty if all transport, codecs, and The "Definitions" section may be empty if all transport, codecs, and
other pieces needed to the specify Potential and Actual other pieces needed to the specify Potential and Actual
Configurations (as detailed below) are either included by referencing Configurations (as detailed below) are either included by referencing
external definitions or are explicitly described within the external definitions or are explicitly described within the
Configurations themselves. Configurations themselves.
3.1.2 Components & Configurations 3.1.2 Components & Configurations
The "Configurations" section contains all the components that The "Configurations" section contains all the components that
constitute the multimedia conference (IP telephone call, multiplayer constitute the multimedia application (IP telephone call, real-time
gaming session etc.). For each of these components, the potential streaming application, multi-player gaming session etc.). For each
and, later, the actual configurations are given. Potential of these components, the potential and, later, the actual
configurations are used during capability exchange and/or configurations are given. Potential configurations are used during
negotiation, actual configurations to configure media streams after capability exchange and/or negotiation, actual configurations to
negotiation (e.g. with RTSP) or in session announcements (e.g. via configure media streams after negotiation (e.g. with RTSP) or in
SAP). A potential and the actual configuration of a component may be session announcements (e.g. via SAP). A potential and the actual
identical. configuration of a component may be identical.
Each component is labelled with an identifier so that it can be Each component is labelled with an identifier so that it can be
referenced, e.g. to associate semantics with a particular media referenced, e.g. to associate semantics with a particular media
stream. For such a component, any number of configurations may be stream. For such a component, any number of configurations may be
given with each configuration describing an alternate way to realize given with each configuration describing an alternative way to
the functionality of the respective component. realize the functionality of the respective component.
Each configuration (potential as well as actual) is labelled with an Each configuration (potential as well as actual) is labelled with an
identifier. A configuration combines one or more (elementary and/or identifier. A configuration combines one or more (elementary and/or
compound) entities from the "Definitions" section to describe a compound) entities from the "Definitions" section to describe a
potential or an actual configuration. Within the specification of potential or an actual configuration. Within the specification of
the configuration, default values from the referenced entities may be the configuration, default values from the referenced entities may be
overwritten. 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 Note: Not all protocol environments and their respective operation
allow to explicitly distinguish between Potential and Actual allow to explicitly distinguish between Potential and Actual
Configurations. Therefore, SDPng so far does not provide for Configurations. Therefore, SDPng so far does not provide for
syntactical identification of a Configurations as being a Potential syntactical identification of a Configurations as being a Potential
or an Actual one. or an Actual one. The semantics of configurations are to be
determined from the requirements of the specific protocol that uses
SDPng to express capabilities and configurations.
The following example shows how RTP sessions can be described by The following example shows how RTP sessions can be described by
referencing payload definitions. referencing payload definitions.
<cfg> <cfg>
<component name="interactive-audio" media="audio"> <component name="interactive-audio" media="audio">
<alt name="AVP-audio-0"> <alt name="AVP-audio-0">
<rtp:session format="rtp-avp-0"> <rtp:session format="rtp-avp-0">
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/> <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
</rtp:session> </rtp:session>
skipping to change at page 12, line 41 skipping to change at page 12, line 44
</alt> </alt>
</component> </component>
</cfg> </cfg>
For example, an IP telephone call may require just a single component For example, an IP telephone call may require just a single component
"name=interactive-audio" with two possible ways of implementing it. "name=interactive-audio" with two possible ways of implementing it.
The two corresponding configurations are "AVP-audio-0" without The two corresponding configurations are "AVP-audio-0" without
modification, the other ("AVP-audio-11") uses linear 16-bit encoding. modification, the other ("AVP-audio-11") uses linear 16-bit encoding.
Typically, transport address parameters such as the port number would Typically, transport address parameters such as the port number would
also be provided. In this example, this information is given by the also be provided. In this example, this information is given by the
"udp" element. Of course, it must be possible to specify other "rtp:udp" element. Of course, it must be possible to specify other
transport mechanisms as well. See Section 3.2 for a discussion of transport mechanisms as well. See Section 3.2 for a discussion of
extension mechanisms that allow applications to use non-standard extension mechanisms that allow applications to use non-standard
transport (or other) specifications. transport (or other) specifications.
During/after the negotiation phase, an actual configuration is chosen During/after the negotiation phase, an actual configuration is chosen
out of a number of alternative potential configurations, the actual out of a number of alternative potential configurations, the actual
configuration may refer to the potential configuration just by its configuration may refer to the potential configuration just by its
"id", possibly allowing for some parameter modifications. "id", possibly allowing for some parameter modifications.
Alternatively, the full actual configuration may be given. Alternatively, the full actual configuration may be given.
Instead of referencing existing payload type definitions it is also Instead of referencing existing payload type definitions it is also
possible to provide the required information "inline". The following possible to provide the required information "inline". The following
example illustrates this: example illustrates this:
<cfg> <cfg>
<component name="audio1" media="audio"> <component name="audio1" media="audio">
<alt name= AVP-audio-0"> <alt name="AVP-audio-0">
<rtp:session> <rtp:session>
<rtp:pt pt="0"> <rtp:pt pt="0">
<audio:codec name="audio-basic" encoding="PCMU" <audio:codec name="audio-basic" encoding="PCMU"
sampling="8000 channels="1"/> sampling="8000" channels="1"/>
</rtp:pt> </rtp:pt>
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/> <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
</rtp:session> </rtp:session>
</alt> </alt>
</component> </component>
</cfg> </cfg>
The UDP/IPv4 multicast transport that is used in the examples is a The UDP/IPv4 multicast transport that is used in the examples is a
simple variant of a transport specification. More complex ones are simple variant of a transport specification. More complex ones are
conceivable. For example, it must also be possible to specify the conceivable. For example, it must also be possible to specify the
usage of source filters (inclusion and exclusion), Source Specific usage of source filters (inclusion and exclusion), Source Specific
Multicast, the usage of multi-unicast, or other parameters. Multicast, the usage of multi-unicast, or other parameters such as
Therefore it is possible to extend the definition of transport QoS parameters. Therefore it is possible to extend the definition of
mechanisms by providing the required information in the element transport mechanisms by providing the required information in the
content. An example: element content. An example:
<cfg> <cfg>
<component name="audio1" media="audio"> <component name="audio1" media="audio">
<alt name= AVP-audio-0"> <alt name="AVP-audio-0">
<rtp:session format="rtp-avp-0"> <rtp:session format="rtp-avp-0">
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"> <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801">
<option name="ssm" sender="sender.example.com"/> <option name="ssm" sender="sender.example.com"/>
</rtp:udp> </rtp:udp>
</rtp:session> </rtp:session>
</alt> </alt>
</component> </component>
</cfg> </cfg>
More transport mechanisms and options will be defined in future Additional transport mechanisms and options will be defined in future
versions of this document. versions of this document.
3.1.3 Constraints 3.1.3 Constraints
Definitions specify media, transport, and other capabilities, whereas Definitions specify media, transport, and other capabilities, whereas
configurations indicate which combinations of these could be used to configurations indicate which combinations of these could be used to
provide the desired functionality in a certain setting. provide the desired functionality in a certain setting.
There may, however, be further constraints within a system (such as There may, however, be further constraints within a system (such as
CPU cycles, DSP available, dedicated hardware, etc.) that limit which CPU cycles, DSP resources available, dedicated hardware, etc.) that
of these configurations can be instantiated in parallel (and how many limit which of these configurations can be instantiated in parallel
instances of these may exist). We deliberately do not couple this (and how many instances of these may exist). We deliberately do not
aspect of system resource limitations to the various application couple this aspect of system resource limitations to the various
semantics as the constraints exist across application boundaries. application semantics as the constraints may exist across application
Also, in many cases, expressing such constraints is simply not boundaries. Also, in many cases, expressing such constraints is
necessary (as many uses of the current SDP show), so additional simply not necessary (as many uses of the current SDP show), so
overhead can be avoided where this is not needed. additional overhead can be avoided where this is not needed.
Therefore, we introduce a "Constraints" section to contain these Therefore, we introduce a "Constraints" section to contain these
additional limitations. Constraints refer to potential additional limitations. Constraints refer to potential
configurations and to entity definitions and express and use simple configurations and to entity definitions and express and use simple
logic to express mutual exclusion, limit the number of logic to express mutual exclusion, limit the number of
instantiations, and allow only certain combinations. The following instantiations, and allow only certain combinations. The following
example shows the definition of a constraints that restricts the example shows the definition of a constraints that restricts the
maximum number of instantiation of two alternatives (that would have maximum number of instantiation of two alternatives (that would have
to be defined in the configuration section before) when they are used to be defined in the configuration section before) when they are used
in parallel: in parallel:
<constraints> <constraints>
<par> <par>
<use-alt ref="AVP-audio-11" max="5"> <use-alt ref="AVP-audio-11" max="5">
<use-alt ref="AVP-video-32" max="1"> <use-alt ref="AVP-video-32" max="1">
</par> </par>
</constraints> </constraints>
As the example shows, contraints are defined by defining limits on As the example shows, constraints are defined by defining limits on
simultaneous instantiations of alternatives. They are not defined by simultaneous instantiations of alternatives. They are not defined by
expressing abstract endsystem resources, such as CPU speed or memory expressing abstract end-system resources, such as CPU speed or memory
size. size.
By default, the "Constraints" section is empty (or missing) which By default, the "Constraints" section is empty (or missing) which
means that no further restrictions apply. means that no further restrictions apply.
3.1.4 Session Attributes 3.1.4 Session Attributes
The fourth and final section of the SDPng syntax addresses session The fourth and final section of the SDPng syntax addresses session
layer attributes. These attributes largely include those defined by layer attributes. These attributes largely include those defined by
SDP [RFC2327] (which are explicitly indicated in the following SDP [RFC2327] (which are explicitly indicated in the following
specification) to describe originator, purpose, and timing of a specification) to describe originator, purpose, and timing of a
multimedia session among other characteristics. Furthermore, SDPng multimedia session among other characteristics. Furthermore, SDPng
includes attributes indicating the semantics of the various includes attributes indicating the semantics of the various
Components in a teleconference or other session. This part of the Components in a teleconference or other session. This part of the
specification is open ended with an IANA registry to be set up to specification is open ended with an IANA registry to be set up to
register further types of components; only a few of the examples are register further types of components; only a few of the examples are
listed here. listed here.
A session-level specification for connection information (SDP "c=" A session-level specification for connection information (SDP "c="
line), bandwidth information (SDP "b=" line), and encryption keys line), bandwidth information (SDP "b=" line), and encryption keys
(SDP "k=" lines) is deliberately not provided for in SDPng. (SDP "k=" lines) is deliberately not provided for in SDPng. The
relevant information can be specified directly in the Configuration
section for individual alternatives.
Session level attributes as defined by SDP still have to be examined Session level attributes as defined by SDP still have to be examined
and adopted for SDPng in a future revision of this specification. and adopted for SDPng in a future revision of this specification.
3.1.4.1 Owner 3.1.4.1 Owner
The owner refers to the creator of a session as defined in RFC2327 The owner refers to the creator of a session as defined in RFC2327
("o=" line). The syntax is as follows: ("o=" line). The syntax is as follows:
<owner user="username" id="session-id" version="version" nettype="IN" <owner user="username" session-id="session-id" version="version"
addrtype="IP4" addr="130.149.25.97"/> nettype="IN" addrtype="IP4" addr="130.149.25.97"/>
The owner field MUST be present if SDPng is used with SAP. For all The owner element must be present if SDPng is used with SAP. For all
other protocols, the owner field MAY be specified. The attributes other protocols, the owner element is not necessarily required. The
listed above match those from the SDP specification; all attributes attributes listed above match those from the SDP specification; all
MUST be present and they MUST be created following the rules of attributes must be present and they are used following the rules of
RFC2327. RFC2327.
Note: There are several possible ways ahead on this part: "owner" The owner element is an empty element.
could stand as it is right now, but the various values of the various
attributes could be concatenated (separated by blanks) the result
being identical to the contents of the SDP "o=" line -- which then
could be represented as either a single attribute or as contents of
the "owner" element. Alternatively, the owner element could become
part of the "session" element described below. Or the contents of
the owner element could become an attribute of the "session" element
below.
3.1.4.2 Session Identification 3.1.4.2 Session Identification
The "session" element is used to identify the session and to provide The "session" element is used to identify the session and to provide
a description and possible further references. The following a description and possible further references. It provides the
attributes are defined: following attributes:
name: The session name as it is to appear e.g. in a session name: The session name as it is to appear e.g. in a session
directory. This is equivalent to the SDP "s=" line. This directory. This is equivalent to the SDP "s=" line.
attribute MUST be present.
info: A pointer to further information about the session; this
attribute MUST contain a URI. The attribute itself is OPTIONAL.
The session element MAY contain arbitrary text of any length (but The session element can contain arbitrary text of any length (but
authors are encouraged to keep the inline description brief and authors are encouraged to keep the inline description brief and
provide additional information via URLs. This text is used to provide additional information via URLs using the info element
provide a description of the session; it is the equivalent of the SDP described below. This text is used to provide a description of the
"i=" lines. session; it is the equivalent of the SDP "i=" lines.
Furthermore, the session element MAY contain other elements of the Additionally, the session element can contain other elements of the
following types to provide further information about the session and following types to provide further information about the session and
its creator: its creator:
info: The info element is intended to provide a pointer to further info: The info element is intended to provide a pointer to further
information on the session itself. Its contents MUST be exactly information on the session itself. It is an empty element and
one URI. If both the info attribute and one or more info elements provides the attribute xlink:href that is used to specify an URI.
are present, the union of the respective values is used. Info Info elements are optional, they may occur any number of times.
elements are OPTIONAL, they MAY be repeated any number of times.
contact: The contact element provides contact information on the contact: The contact element provides contact information on the
creator of the session; its contents MUST be exactly one URI. Any creator of the session. It is an empty element and provides an
URI scheme suitable to reach a person or a group of persons is attribute xlink:href that is used to specify an URI. Any URI
scheme suitable to reach a person or a group of persons is
acceptable (e.g. sip:, mailto:, tel:). Contact elements are acceptable (e.g. sip:, mailto:, tel:). Contact elements are
OPTIONAL, they MAY be repeated any number of times. optional, they may occur any number of times.
<session name="An SDPng seminar" info="http://www.dmn.tzi.org/ietf/mmusic/"> <session name="An SDPng seminar">
And here comes a long description of the seminar indicating what And here comes a long description of the seminar indicating what
this might be about and so forth. But we also include further this might be about and so forth. But we also include further
information -- as additional elements: information -- as additional elements:
<info>http://www.ietf.org/</info> <info xlink:href="http://www.ietf.org/"/>
<contact>mailto:joe@example.com</contact> <contact xlink:href="mailto:joe@example.com"/>
<contact>mailto:bob@example.com</contact> <contact xlink:href="mailto:bob@example.com"/>
<contact>tel:+49421281</contact> <contact xlink:href="tel:+49421218"/>
<contact>sip:joe@example.com</contact> <contact xlink:href="sip:joe@example.com"/>
<contact>sip:bob@example.com</contact> <contact xlink:href="sip:bob@example.com"/>
</session> </session>
3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) 3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines)
The time specification for a session follows the same rules as in The time specification for a session follows the same rules as in
SDP. Time specifications are usually only meaningful when used in SDP. Time specifications are usually only meaningful when used in
conjunction with SAP and hence are OPTIONAL. SDPng uses the conjunction with SAP and are optional. SDPng uses the following
following elements and attributes to specify timing: elements and attributes to specify timing:
The element "time" is used to indicate a schedule for the session; The element "time" is used to indicate a schedule for the session;
time has two optional attributes: time has two optional attributes:
start: The starting time of the first occurrence of the session as start: The starting time of the first occurrence of the session as
defined in RFC2327. defined in RFC2327.
end: The ending time of the last occurrence of the session as defined end: The ending time of the last occurrence of the session as defined
in RFC2327. in RFC2327.
The time element MAY contain the following elements but otherwise The time element can contain the following elements:
MUST be empty:
repeat: This element specifies the repetition pattern for the repeat: This element specifies the repetition pattern for the
schedule. There MAY be zero or more occurrences of this element schedule. There may be zero or more occurrences of this element
within the time element. "repeat" has two MANDATORY and one within the time element. "repeat" has two mandatory and one
OPTIONAL attribute and no further contents; the attributes are as optional attribute and is an empty element; the attributes are as
defined in SDP: defined in SDP:
interval: The duration between two start times of the session. interval: The duration between two start times of the session.
This attribute MUST be present. This attribute is always present.
duration: The duration for which the session will be active duration: The duration for which the session will be active
starting at each repetition interval. This attribute MUST be starting at each repetition interval. This attribute is always
present. present.
offset: The offset relative to "start" attribute at which this offset: The offset relative to "start" attribute at which this
repetition of the session is start. This attribute is repetition of the session is start. This attribute is
OPTIONAL; if it is absent, a default value of "0" is assumed. optional; if it is absent, a default value of "0" is assumed.
Formatting of the attribute values MUST follow the rules defined Formatting of the attribute values follows the rules defined in
in RFC2327. RFC2327.
zone: The zone element specifies one or more time zone adjustments as zone: The zone element specifies one or more time zone adjustments as
defined in RFC2327. This element MAY have zero or more defined in RFC2327. This element has zero or more occurrences in
occurrences in the time element. It has two attributes as defined the time element. It is an empty element and has two attributes
in SDP: as defined in SDP:
adjtime: The time at which the next adjustment will take place. adjtime: The time at which the next adjustment will take place.
delta: The adjustment offset (typically +/- 1 hours). delta: The adjustment offset (typically +/- 1 hours).
The example from RFC2327, page 16, expressed in SDPng: The example from RFC2327, page 16, expressed in SDPng:
<time start="3034423619" stop="3042462419"> <time start="3034423619" stop="3042462419">
<repeat interval="7d" duration="1h"/> <repeat interval="7d" duration="1h"/>
<repeat interval="7d" duration="1h" offset="25h"/> <repeat interval="7d" duration="1h" offset="25h"/>
</time> </time>
The time element can occur multiple times.
3.1.4.4 Component Semantic Specification 3.1.4.4 Component Semantic Specification
Another important session parameter is to specify - ideally in a Another important session parameter is to specify - ideally in a
machine-readable way but at least understandable for humans - the machine-readable way but at least understandable for humans - the
function of the various components in a session. Typically, the function of the various components in a session. Typically, the
semantics of the streams are implicitly assumed (e.g. a video stream semantics of the streams are implicitly assumed (e.g. a video stream
goes together with the only audio stream in a session). There are, goes together with the only audio stream in a session). There are,
however, scenarios in which such intuitive understanding is not however, scenarios in which such intuitive understanding is not
sufficient and the semantics must be made explicit. sufficient and the semantics must be made explicit.
<info name="audio-interactive" function="speaker"> <info name="audio-interactive" function="speaker">
Audio stream for the different speakers Audio stream for the different speakers
</info> </info>
The above example shows a simple definition of the semantics for a The above example shows a simple definition of the semantics for the
the component "interactive-audio". Further options may be added to component "audio-interactive". Further options may be added to
provide additional information, e.g. language, and other functions provide additional information, e.g. language, and other functions
may be specified (e.g. "panel", "audience", "chair", etc.). may be specified (e.g. "panel", "audience", "chair", etc.).
3.2 Syntax Definition Mechanisms 3.2 Syntax Definition Mechanisms
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 it is descriptions and in order to allow for structured extensibility,
proposed to rely on a syntax framework that provides concepts as well SDPng relies on a syntax framework that provides concepts as well as
as concrete procedures for document validation and extending the set concrete procedures for document validation and extending the set of
of allowed syntax elements. allowed syntax elements.
SGML/XML technologies allow for the preparation 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
validated against a given DTD to check their conformance and validated against a given DTD to check their conformance and
correctness. XML DTDs however, cannot easily be extended. It is not correctness. XML DTDs however, cannot easily be extended. It is not
possible to alter to content models of element types or to add new possible to alter to content models of element types or to add new
element types after the DTD has been specified. element types after the DTD has been specified.
For SDPng, a mechanism is needed that allows the specification of a For SDPng, a mechanism is needed that allows the specification of a
base syntax -- for example basic elements for the high level base syntax -- for example basic elements for the high level
structure of description documents -- while allowing extensions, for structure of description documents -- while allowing extensions, for
example elements and attributes for new transport mechanisms, new example elements and attributes for new transport mechanisms, new
media types etc. to be added on demand. Still, it has to be ensured media types etc. to be added on demand. Still, it has to be ensured
that extensions do not result in name collisions. Furthermore, it that extensions do not result in name collisions. Furthermore, it
must be possible for applications that process descriptios documents must be possible for applications that process descriptions documents
to disinguish extensions from base definitions. to distinguish extensions from base definitions.
For XML, mechanisms have been defined that allow for structured For XML, mechanisms have been defined that allow for structured
extensibility of a model of allowed syntax: XML Namespace and XML extensibility of a model of allowed syntax: XML Namespace and XML
Schema. Schema.
XML Schema mechanisms allows to constrain the allowed document XML Schema mechanisms allows to constrain the allowed document
content, e.g. for documents that contain structured data and also content, e.g. for documents that contain structured data and also
provide the possibility that document instances can conform to provide the possibility that document instances can conform to
several XML Schema definitions at the same time, while allowing several XML Schema definitions at the same time, while allowing
Schema validators to check the conformance of these documents. Schema validators to check the conformance of these documents.
skipping to change at page 19, line 27 skipping to change at page 19, line 19
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 profiles 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
profile of RFC1890 etc. of RFC1890 etc.
Section 3.3 describes profile definitions and library definition. A Section 3.3 describes profile definitions and library definition. A
detailed definition of how the formal SDPng syntax and the detailed definition of how the formal SDPng syntax and the
corresponding extension mechanisms is provided in Section 4. corresponding extension mechanisms is provided in Section 4.
The example below shows how the definition of codecs, transport- The example below shows how the definition of codecs, transport-
variants and configuration of components could be realized. Please variants and configuration of components as well as a conference
note that this is not a complete example and that identifiers have description are realized in SDPng.
been chosen arbitrarily.
<def> <def>
<audio:codec name="audio-basic" encoding="PCMU" <audio:codec name="audio-basic" encoding="PCMU"
sampling="8000 channels="1"/> sampling="8000" channels="1"/>
<audio:codec name="audio-L16-mono" encoding="L16" <audio:codec name="audio-L16-mono" encoding="L16"
sampling="44100 channels="1"/> sampling="44100" channels="1"/>
<rtp:pt name="rtp-avp-0" pt="0" format="audio-basic"/> <rtp:pt name="rtp-avp-0" pt="0" format="audio-basic"/>
<rtp:pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/> <rtp:pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/>
</def> </def>
<cfg> <cfg>
<component name="interactive-audio" media="audio"> <component name="interactive-audio" media="audio">
<alt name= AVP-audio-0"> <alt name="AVP-audio-0">
<rtp:session format="rtp-avp-0"> <rtp:session format="rtp-avp-0">
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/> <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
</rtp:session> </rtp:session>
</alt> </alt>
<alt name= AVP-audio-11"> <alt name="AVP-audio-11">
<rtp:session format="rtp-avp-11"> <rtp:session format="rtp-avp-11">
<rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/> <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
</rtp:session> </rtp:session>
</alt> </alt>
</component> </component>
</cfg> </cfg>
<constraints> <constraints>
<par> <par>
<use-alt ref="AVP-audio-11" max="1"> <use-alt ref="AVP-audio-11" max="1">
</par> </par>
</constraints> </constraints>
<conf> <conf>
<owner user="joe@example.com" id="foobar" version="1" nettype="IN" <owner user="joe@example.com" id="foobar" version="1" nettype="IN"
addrtype="IP4" addr="130.149.25.97"/> addrtype="IP4" addr="130.149.25.97"/>
<session name="An SDPng seminar" info="http://www.dmn.tzi.org/ietf/mmusic/"> <session name="An SDPng seminar">
This seminar is about SDPng... This seminar is about SDPng...
<info>http://www.ietf.org/</info> <info xlink:href="http://www.ietf.org/"/>
<contact>mailto:joe@example.comg</contact> <contact xlink:href="mailto:joe@example.com"/>
<contact>sip:joe@example.com</contact> <contact xlink:href="sip:joe@example.com"/>
</session> </session>
<time start="3034423619" stop="3042462419"> <time start="3034423619" stop="3042462419">
<repeat interval="7d" duration="1h"/> <repeat interval="7d" duration="1h"/>
<repeat interval="7d" duration="1h" offset="25h"/> <repeat interval="7d" duration="1h" offset="25h"/>
</time> </time>
<info name="interactive-audio" function="speaker"> <info name="interactive-audio" function="speaker">
Audio stream for the different speakers Audio stream for the different speakers
<info> <info>
</conf> </conf>
The example does also not include specifications of XML Schema Section 4 specifies the formal Schema definition that this example is
definitions or references to such definitions. This will be provided conforming to.
in a future version of this draft.
A real-world capability description would likely be shorter than the A real-world capability description would likely be shorter than the
presented example because the codec and transport definitions can be presented example because the codec and transport definitions can be
factored-out to profile definition documents that would only be factored-out to profile definition documents that would only be
referenced in capability description documents. referenced in capability description documents.
3.3 External Definition Packages 3.3 External Definition Packages
There are two types of external definitions:
Profile Definitions (Section 3.3.1) define rules for specifying
parameters that are not covered by the base SDPng specification.
Library Definitions (Section 3.3.2) contain definitions that can be
referenced in SDPng documents.
3.3.1 Profile Definitions 3.3.1 Profile 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 esoteric For example, if some application requires the use of a new transport
transport protocol, endpoints must be able describe their protocol, endpoints must be able to describe their configuration with
configuration with respect to the parameters of that transport respect to the parameters of that transport protocol. The mandatory
protocol. The mandatory and optional parameters that can be and optional parameters that can be configured and negotiated when
configured and negotiated when using the transport protocol will be using the transport protocol will be specified in a definition
specified in a definition document. Such a definition document is document. Such a definition document is called a "profile".
called a "profile".
A profile contains rules that specify how SDPng is used to describe A profile contains rules that specify how SDPng is used to describe
conferences or endsystem capabilities with respect to the parameters conferences or end-system capabilities with respect to the parameters
of the profile. The concrete properties of the profile definitions of the profile. The concrete properties of the profile 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 profile would be the RTP profile 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 profiles that defines how specify audio codec parameters.
SDPng documents can reference profiles and provide concrete SDPng documents can reference profiles and provide concrete
definitions, for example the definition for the GSM audio codec. definitions, for example the definition for the GSM audio codec.
(This would be done in the "Definitions" section of a SDPng (This would be done in the "Definitions" section of an SDPng
document.) A SDPng document that references a profile and provides document.) An SDPng document that references a profile and provides
concrete defintions of configurations can be validated against the concrete definitions of configurations can be validated against the
profile definition. profile definition.
3.3.2 Library Definitions 3.3.2 Library Definitions
While profile definitions specify the allowed parameters for a given While profile definitions specify the allowed parameters for a given
profile SDPng definition sections refer to profile definitions and profile, SDPng "Definitions" sections refer to profile definitions
define concrete configurations based on a specific profile. and define concrete configurations based on a specific profile.
In order for such definitions to be imported into SDPng documents, In order for such definitions to be imported into SDPng documents,
there will be the notion of "SDPng libraries". A library is a set of "SDPng libraries" may be defined and referenced in SDPng documents.
definitions that is conforming to a certain profile definition (or to A library is a set of definitions that is conforming to one or more
more than one profile definition -- this needs to be defined). profile 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 profile, again needs to declare the use of the profile that it is
conforming to. conforming to. A library itself can make reference to other external
libraries.
There are different possibilities of how profiles definitions and There are different possibilities of how profiles 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 profile 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
skipping to change at page 22, line 41 skipping to change at page 22, line 39
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
definitions with a registration authority (e.g., IANA) and to definitions with a registration authority (e.g., IANA) and to
declare the use of registered definition packages in conforming declare the use of registered definition packages in conforming
SDPng documents. Of course, care should be taken not to make SDPng documents. Of course, care should be taken not to make
the external references too complex and thus require too much a the external references too complex and thus require too much a
priori knowledge in a protocol engine implementing SDPng. priori knowledge in a protocol engine implementing SDPng.
Relying on this mechanism in general is also problematic Relying on this mechanism in general is also problematic
because it impedes the extensiblity, because it requires because it impedes the extensibility, as it requires
implementors to provide support for new extensions in their implementors to provide support for new extensions in their
products before they can interoperate. Registration is not products before they can inter-operate. Registration is not
useful for spontaneous or experimental extensions that are useful for spontaneous or experimental extensions that are
defined in an SDPng library. defined in an SDPng library.
by address: An alternative to referencing libraries by name is to by address: An alternative to referencing libraries by name is to
declare the use of an external library by providing an address, declare the use of an external library by providing an address,
i.e., an URL, that specifies where the library can be obtained. i.e., an URL, that specifies where the library can be obtained.
While is allows the use of arbitrary third-party libraries that While this allows the use of arbitrary third-party libraries
can extend the basic SDPng set of configuration options in many that can extend the basic SDPng set of configuration options in
ways there are problems if the referenced libraries cannot be many ways, in introduces additional complexity that could
result in in higher latency for the processing of a description
document with references to external libraries. In addition,
there are problems if the referenced libraries cannot be
accessed by all communication partners. 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 externalizing definitions should be used. of referring to external definitions should be used.
3.4 Mappings 3.4 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 basic definitions. done in a rather schematic fashion for the basic definitions.
Furthermore, to accommodate SIP-H.323 gateways, a mapping from SDPng In addition, mappings to H.245 will be defined in order to support
to H.245 needs to be specified at some point. applications like SIP-H.323 gateways.
4. Formal Specification 4. Formal Specification
This section defines the SDPng syntax and the use of XML mechanisms,
such as XML Namespace and XML Schema. Section 4.1 defines the
relation between SDPng and XML Schema, Section 4.2 specifies general
requirements for documents and profile definitions that are
conforming to the SDPng schema, Section 4.3 list requirements for
profile definitions, Section 4.4 specifies specific requirements for
conforming documents and Section 4.5 lists requirements for the
definition of SDPng libraries.
Section 4.7 defines the SDPng base schema, Section 4.7.2 defines the
profile for audio codec definitions and Section 4.7.3 defines the
profile for RTP payload type definitions.
4.1 XML Schema as a Definition Mechanism 4.1 XML Schema as a Definition Mechanism
SDPng document reference profile schema definitions and libraries. SDPng documents reference profile schema definitions and libraries.
Profile schema definitions contain schema definitions of SDPng Profile schema definitions contain schema definitions of SDPng
document elements. For example, the general structure is specified document elements. For example, the general structure is specified
by a schema definition and extensions to SDPng for specific by a schema definition and extensions to SDPng for specific
applications are specified as schema definitions as well. applications are specified as schema definitions as well.
The baseline SDPng specification consists of a profile (a schema The baseline SDPng specification consists of a profile (a schema
definition) and a library of commonly used definitions. definition) and a library of commonly used definitions.
SDPng uses XML-Schema [15][16] for defining the possible logical SDPng uses XML-Schema [13][14] for defining the possible logical
structures of SDPng documents for the following reasons: structures of SDPng documents for the following reasons:
Extensibility: XML-Schema provides mechanisms that allow to extend Extensibility: XML-Schema provides mechanisms that allow to extend
exisiting definitions allowing to uniquely identify element types existing definitions allowing to uniquely identify element types
(by relying on XML namespaces [13]). (by relying on XML namespaces [11]).
Modularity: XML-Schema provide mechanisms that allow to organize Modularity: XML-Schema provide mechanisms that allow to organize
schema definitions in multiple components. schema definitions in multiple components.
Expressiveness: XML-Schema provides many data types, that can be Expressiveness: XML-Schema provides many data types, that can be
refined by user-supplied definitions. refined by user-supplied definitions.
SDPng documents are schema instances of the SDPng schema. The SDPng documents MUST be schema instances of the SDPng schema as
following example shows, how a Schema definition can be referenced in defined in Section 4.7. The following example shows how a Schema
a document instance. definition can be referenced in a document instance.
Beginning of an SDPng-document: Beginning of an SDPng-document:
<?xml version="1.0" ?> <?xml version="1.0" ?>
<sdpng:desc xmlns:sdpng="http://www.iana.org/sdpng" <sdpng:desc xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance"
xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd" xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd">
>
XML-Schema specifies, that documents can assign a namespace when XML-Schema specifies that documents can assign a namespace when
referencing a schema definition. A SDPng namespace will be defined referencing a schema definition. A SDPng namespace is defined for
for this purpose (it has to be decided later which namespace name to this purpose. The name of this namespace is
use -- this can be a URI, as in the example, or a URN). It is "http://www.iana.org/sdpng". A well-known namespace prefix is used
proposed that a commonly used namespace prefix is used (e.g. fixed for the SDPng schema definition, in order to allow for very simple
to "sdpng") for the SDPng schema definition. implementations. The well-known SDPng namespace prefix is "sdpng".
Conforming Documents, profile definition and libraries MUST use this
namespace name and this namespace prefix.
It will be worked-out, how much of this initial declaration can be For SDPng documents, this initial declaration can be added implicitly
added implicitely by applications, so that declarations like the one by applications, so that declarations like the one above do not have
above do not have to be included in every description document. to be included in every description document. Details are to be
defined in a later version of this document.
4.2 SDPng Schema 4.2 SDPng Schema
The basic SDPng schema definitions specifies the general document The basic SDPng schema definitions specifies the general document
structures, e.g., "definitions" sections followed by "configurations" structures, e.g., one "Definitions" section followed by one
sections, followed by "constraints" sections followed by a "conf" "Configurations" sections, followed by one "Constraints" sections
section (for meta-information). 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 4.7
for a formal definition of the SDPng base schema and the specific
element types for definitions, configurations, constraints and
conference information.
It also specifies "abstract" base data types (by means of XML-Schema The SDPng base schema also specifies "abstract" base data types (by
type definitions) for elements that should be used by documents in means of XML-Schema type definitions) for elements that MUST be used
the corresponding sections. The base data types can provide common by documents in the corresponding sections. The base data types
required attributes, e.g. a "name" attribute for naming definition provide common required attributes, e.g. a "name" attribute for
elements. naming definition elements.
Example:
The following example shows the definition of the base type for The following example shows the definition of the base type for
definition elements: definition elements:
<xsd:complexType name="Definition" abstract="true" mixed="false"> <xsd:complexType name="Definition" abstract="true" mixed="false">
<xsd:attribute name="name" type="xsd:string"> </xsd:attribute> <xsd:attribute name="name" type="xsd:string"/>
</xsd:complexType> </xsd:complexType>
Profiles can then define concrete types that augment the base type Profiles can then define specific types that augment the base type
definitions. Common attributes or content models, that have been definitions. Common attributes or content models, that have been
defined by this base definition, do not have to be provided by those defined by this base definition, do not have to be provided by those
concrete type definitions. The type definitions can be identified as concrete type definitions. The type definitions can be identified as
allowed element types for the content models that are specified in allowed element types for the content models that are specified in
the base SDPng schema definition. This allows for automatic the base SDPng schema definition. This allows for automatic
validation of profile definitions and faciliates the extension of validation of profile definitions and facilitates the extension of
SDPng. SDPng.
4.3 Profiles 4.3 Profiles
The baseline SDPng specification consists of a profile (a schema The baseline SDPng specification consists of a profile (a schema
definition) and a library of commonly used definitions. definition) and a library of commonly used definitions.
The library of commonly used definitions provides data types for IP The library of commonly used definitions provides data types for IP
(or other) addresses etc. Details have to be provided at a later (and other) addresses.
time.
A profile definition imports (using the XML-Schema import mechanism) A profile definition MUST import (using the XML-Schema import
the base SDPng schema definition and provided extension definition, mechanism) the base SDPng schema definition and MUST provide an
e.g., specializations of base element types. They also provide a extension definition, e.g., specializations of base element types. A
target namespace name for the definitions of the corresponding profile definition MUST also provide a target namespace name for its
profile. For well-known (registered) profiles the namespace name definitions. For well-known (registered) profiles, the namespace
will be registered by IANA. Proprietary profiles will use other name will be registered by IANA. Proprietary profiles will use other
namespace names, for example, based on domain names, that are namespace names, for example, based on domain names, that are
registered by vendors providing a profile. registered by vendors providing a profile.
Example:
The following example shows such a declaration at the beginning of a The following example shows such a declaration at the beginning of a
profile definition: profile definition:
<xsd:schema targetNamespace="http://www.iana.org/sdpng/audio" <xsd:schema targetNamespace="http://www.iana.org/sdpng/audio"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:sdpng="http://www.iana.org/sdpng" xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio" xmlns:audio="http://www.iana.org/sdpng/audio">
>
<xsd:import namespace="http://www.iana.org/sdpng" schemaLocation="sdpng.xsd"> <xsd:import namespace="http://www.iana.org/sdpng"
</xsd:import> schemaLocation="sdpng.xsd"/>
In this example the namespace prefix "audio" is defined and later In this example, the namespace prefix "audio" is defined and later
used in schema definitions. (The example profile provides definition used in schema definitions. (The example profile provides definition
mechanisms for audio codecs.) mechanisms for audio codecs.)
The following example shows, how a derived type for "definition" The following example shows, how a derived type for "definition"
elements can be specified with XML-Schema mechanisms. In this case elements can be specified with XML-Schema mechanisms. In this case,
the abstract type "Definition" (fully qualified as the abstract type "Definition" (fully qualified as
"sdpng:Definition") is augemented by three attributes that are useful "sdpng:Definition") is augmented by three attributes that are useful
for defining audio codecs. for defining audio codecs.
Example:
<xsd:complexType name="AudioCodec" mixed="false"> <xsd:complexType name="AudioCodec" mixed="false">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="sdpng:Definition"> <xsd:extension base="sdpng:Definition">
<xsd:attribute name="encoding" type="xsd:string"> <xsd:attribute name="encoding" type="xsd:string"/>
</xsd:attribute> <xsd:attribute name="sampling" type="xsd:positiveInteger"/>
<xsd:attribute name="sampling" type="xsd::positiveInteger"> <xsd:attribute name="channels" type="xsd:positiveInteger"/>
</xsd:attribute>
<xsd:attribute name="channels" type="xsd:positiveInteger">
</xsd:attribute>
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
This type definition is then used to define an XML element type This type definition is then used to define an XML element type
called "codec". called "codec".
<xsd:element name="codec" type="AudioCodec"> </xsd:element> Example:
<xsd:element name="codec" type="AudioCodec"/>
When used by SDPng documents, the general identifier is qualified When used by SDPng documents, the general identifier is qualified
with a namespace prefix, for example like in: "audio:codec". with a namespace prefix, for example as in: "audio:codec".
4.4 SDPng Documents 4.4 SDPng Documents
SDPng documents have to reference the employed profiles and provide SDPng documents MUST reference the employed profiles and provide
namespace prefixes for the namespace names of the profiles. For namespace prefixes for the namespace names of the profiles as shown
example: in the following example.
Example:
<sdpng:desc xmlns:sdpng="http://www.iana.org/sdpng" <sdpng:desc xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance"
xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd" xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd"
xmlns:audio="http://www.iana.org/sdpng/audio" xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp" xmlns:rtp="http://www.iana.org/sdpng/rtp">
>
It is proposed that for well-known registered profiles, the namespace For well-known registered profiles, the namespace name AND the used
name AND the used namespace prefix is registered to allow for simple namespace prefix SHOULD be registered to allow for simple basic
basic implementations that can match identifiers by using fixed fully implementations that can match identifiers by using fixed fully
qualified names without having to interpret namespace declarations. qualified names without having to interpret namespace declarations
There is one issue with declaring used XML-Schema definitions in (see Section 4.6.3). There is one issue with declaring used XML-
documents (see section "Issues" below). Schema definitions in documents (see Section 6 below).
The general structure of an SDPng would conform to the basic SDPng The general structure of an SDPng documents MUST conform to the basic
schema definition and provide a "def" element for definitions, a SDPng schema definition and MAY provide a "def" element for
"cfg" element for the configuration section etc. definitions; it MUST provide a "cfg" element for the configuration
section; it MAY provide a "constraints" and a "conf" element.
Example:
The following example shows a sample definition section where the The following example shows a sample definition section where the
element "codec" of the "audio codec profile" is used (plus the element "codec" of the "audio codec profile" is used (plus the
element type "pt" of an "RTP profile"): element type "pt" of an "RTP profile"):
<def> <def>
<audio:codec name="dvi4" encoding="DVI4" channels="1" <audio:codec name="dvi4" encoding="DVI4" channels="1"
sampling="8000"/> sampling="8000"/>
<audio:codec name="g722" encoding="G722" channels="1" <audio:codec name="g722" encoding="G722" channels="1"
sampling="16000"/> sampling="16000"/>
<audio:codec name="g729" encoding="G729" channels="1" <audio:codec name="g729" encoding="G729" channels="1"
skipping to change at page 28, line 10 skipping to change at page 28, line 38
4.5 Libraries 4.5 Libraries
SDPng libraries are collections of definitions that are referenced by SDPng libraries are collections of definitions that are referenced by
documents. Libraries are thus independent, valid SDPng documents. documents. Libraries are thus independent, valid SDPng documents.
For example, the definition of the different audio codecs as shown in For example, the definition of the different audio codecs as shown in
the previous example could be provided by a library that can be the previous example could be provided by a library that can be
referenced by documents without having to define such common codecs referenced by documents without having to define such common codecs
in every document. in every document.
The XML mechanism XIncludes [14] will be used for referencing The XML mechanism XInclude [12] is used for referencing libraries in
libraries in SDPng documents. XInlcude work at the "infoset" level, SDPng documents. XInlcude works at the XML Information Set
i.e. the mechanisms allows to have an integrating document reference ("infoset") level, i.e. the mechanisms allows to have an integrating
fragment document, while these fragment are well-formed (and, if document reference fragment documents, while these fragments are
applicable valid) document themselves. By resolving XInclude well-formed (and, if applicable, valid) documents themselves. By
directives in integrating documents the documents' infosets are resolving XInclude directives in integrating documents the documents'
"merged" together, enabling applications to operate on the resulting infosets are "merged" together, enabling applications to operate on
infosets as if it had been generated by parsing a single, monolithic the resulting infosets as if it had been generated by parsing a
document. single, monolithic document.
Inclusion at the XML infoset level has the advantage that documents Inclusion at the XML infoset level has the advantage that documents
are standalone -- they can be validated independently. Another are standalone -- they can be validated independently. Another
advantage is that is relatively easy to generate a "merged" infoset advantage is that is relatively easy to generate a "merged" infoset
for applications that are not able to resolve references to libraries for applications that are not able to resolve references to libraries
themselves. themselves.
An alternative for XInclude would be to use references that are An alternative for XInclude would be to use references that are
resolved by applications. For XML, this would probably mean to use resolved by applications. For XML, this would probably mean to use
an XLink-based approach. This solution would require the definition an XLink-based approach. This solution would require the definition
of an SDPng link element type and require applications to support of an SDPng link element type and require applications to support
XLink (or at least the SDPng-relevant subset thereof). The inclusion XLink (or at least the SDPng-relevant subset thereof). The inclusion
at the application level is however problematic, because it does not at the application level is however problematic, because it does not
result in a common integrated XML document infoset but would require result in a common integrated XML document infoset but would require
applications to handle multiple infosets, i.e. multiple documents. applications to handle multiple infosets, i.e. multiple documents.
More details on library inclusion plus an example have to be provided
at a later time.
4.6 Details on the use of specific XML Mechanisms 4.6 Details on the use of specific XML Mechanisms
This section specifies the use of specific XML mechanisms for SDPng. This section specifies the use of specific XML mechanisms for SDPng.
In order to allow for efficient parsing and processing, not all In order to allow for efficient parsing and processing, not all
features of XML Schema are allowed. Some variable information is set features of XML Schema are allowed. Some variable information is set
to fixed values to allow the development of simplistic servers. to fixed values to allow the development of simplistic servers.
4.6.1 Default Namespace 4.6.1 Default Namespace
SDPng document instances MUST use the SDPng namespace SDPng document instances MUST use the SDPng namespace
"http://www.iana.org/sdpng" (tentative). That means, the general "http://www.iana.org/sdpng". That means, the general SDPng
SDPng identifiers can be used without namespace prefix. identifiers can be used without namespace prefixes.
4.6.2 Qualified Locals 4.6.2 Qualified Locals
XML Schema allows to specify qualification of elements and XML Schema allows to specify qualification of elements and
attributes. It is possible to use non-qualified element and attributes. It is possible to use non-qualified element and
attribute names in Schema definitions and document instances (this is attribute names in Schema definitions and document instances for so-
the default setting). In order to simplify parsing and processing of called "local definitions" (this is the default setting). "Local
SDPng document instances, all element MUST be fully qualified. Definitions" are contained within "global definitions" in an XML
Attribute names MUST NOT be fully qualified. 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 This means, the SDPng Schema definition contains the following
attributes for the "schema" element, that MUST also be used by SDPng attributes for the "schema" element, that MUST also be used by SDPng
profiles: profiles:
o elementFormDefault="qualified" o elementFormDefault="qualified"
This means that "local" elements that used within the scope of This means that "locally defined" elements that are used within
fully-qualified elements MUST be fully qualified. the scope of fully-qualified elements MUST always be fully
qualified as well.
o attributeFormDefault="unqualified" o attributeFormDefault="unqualified"
This means, that attribute names do not have to be fully This means that attribute names do not have to be fully qualified.
qualified. Implementations MUST infer the namespace for Implementations MUST infer the namespace for attributes from the
attributes from the namespace of the element that the attribute is namespace of the element that the attribute belongs to. Note that
used in. Note that the specification of XML Namespaces [13] the specification of XML Namespaces [11] defines that default
defines that default namespaces do not apply to attributes. 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- These rules make SDPng document instances process-able by non-Schema-
aware XML parsers by requiring all element names to be fully aware XML parsers by requiring all element names to be fully
qualified (no "local elements"). qualified (no "local elements").
4.6.3 Fixed Namespace Prefixes 4.6.3 Fixed Namespace Prefixes
In order to facilitate the development of basic implementations, a In order to facilitate the development of basic implementations, a
few commonly namespaces names may be associated with fixed prefixes, few commonly used namespaces names are associated with fixed
i.e. document instances and libraries MUST always use these prefixes, i.e. document instances and libraries MUST always use these
prefixes. Theses prefixes MUST NOT be used for other namespaces prefixes. These prefixes MUST NOT be used for namespaces names than
names than the ones that are assigned to them. A possible solution the ones that are assigned to them. In order to ensure the
could be to provide the possibility to register namespace prefixes as uniqueness of namespace prefixes, namespace prefixes will be have to
well as namespace names. registered together with the corresponding namespace names.
The tentative prefix for the SDPng namespace is "sdpng". The namespace prefix for the SDPng namespace is "sdpng".
4.7 SDPng Schema Definitions 4.7 SDPng Schema Definitions
This section provides an initial set of SDPng XML Schema definitions. This section provides the definition of the base SDPng XML Schema.
1. Section 4.7.1 contains the base definition that provide the 1. Section 4.7.1 contains the base definition that provides the
general element types for SDPng. general element types for SDPng.
2. Section 4.7.2 contains a profile for audio codecs. 2. Section 4.7.2 contains a profile for audio codecs.
3. Section 4.7.3 contains a profile for RTP payload type 3. Section 4.7.3 contains a profile for RTP payload type
definitions. definitions.
4.7.1 SDPng Base Definition 4.7.1 SDPng Base Definition
This schema definition defines the general structure of SDPng This schema definition defines the general structure of SDPng
document instances. It defines the top-level element type "desc" document instances. It defines the top-level element type "desc"
that can have a sequence of "def", "cfg", "contraints" and "conf" that can have a sequence of "def", "cfg", "constraints" and "conf"
elements as element content. elements as element content.
In addition, "extensions hooks" are provided that can be used by In addition, "extensions hooks" are provided that can be used by
extension profiles providing definitions for specific applications. extension profiles providing definitions for specific applications.
In general, these extension are implemented by deriving profile In general, these extension are implemented by deriving profile
definitions from SDPng base definitions. The deployed XML Schema definitions from SDPng base definitions. The deployed XML Schema
mechanisms are "deriving by extension" and "substitution groups". mechanisms are "deriving by extension" and "substitution groups".
The SDPng base definition provides different base types (as The SDPng base definition provides different base types (as
complexType definitions) for elements that are to be used in "def", complexType definitions) for elements that are to be used in "def",
"cfg" and "conf" sections. In addition, it also defines specific "cfg" and "conf" sections. In addition, it also defines specific
element types as "head elements" with assigned types that are used element types as "head elements" with assigned types that are used
for defining the content model of, e.g., the "def" element type. for defining the content model of, e.g., the "def" element type.
Profiles that provide new element types for specific applications Profiles that provide new element types for specific applications
will define types that are derived from the base types and provide will define types that are derived from the base types and provide
the additional attributes and element content definitions that are the additional attributes and element content definitions that are
required for the application. The XML element types that are defined required for the application. The XML element types that are defined
in a profile are declared as valid subsitutes for the base elements in a profile are declared as valid substitutes for the base elements
("head elements") by setting the "substitutionGroup" attribute to the ("head elements") by setting the "substitutionGroup" attribute to the
name of the "head element" type. name of the "head element" type.
For an extension-profile definition, that defines new definition For an extension-profile that provides new definition element types,
element types, e.g. for codec definitions, a new complexType would e.g. for codec definitions, a new complexType would be defined that
be defined that extends sdpng:Definition (see below). An element extends sdpng:Definition (see below). An element type definition
type definition that assigns that new type must then be declared to that assigns that new type must then be declared to be in the
be in the substitutionGroup "sdpng:d". substitutionGroup "sdpng:d".
This mechanism allows common attribute and content model rules to be This mechanism allows common rules for attributes and content models
defined in base element definition and re-used by extension profiles to be defined in base element definition and re-used by extension
and it also allows validating parsers to identify the correct type of profiles and it also allows validating parsers to identify the
elements that have been defined by profile definitions. correct type of elements that have been defined by profile
definitions.
The SDPng Base Definition:
<xsd:schema targetNamespace="http://www.iana.org/sdpng" <xsd:schema targetNamespace="http://www.iana.org/sdpng"
xmlns:sdpng="http://www.iana.org/sdpng" xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This schema definition defines the general structure of SDPng This schema definition defines the general structure of SDPng
document instances. It provides base type and base element document instances. It provides base type and base element
definition for elements to occur in the different sections (def, definition for elements to occur in the different sections (def,
cfg, constraints, conf) to be derived from in extension-profile cfg, constraints, conf) to be derived from in extension-profile
definitions. definitions.
For an extension-profile definition, that defines new definition For an extension-profile that provides new definition element
element types, e.g. for codec definitions, a new complexType would types, e.g. for codec definitions, a new complexType would be
be defined that extends sdpng:Definition (see below). An element defined that extends sdpng:Definition (see below). An element
type definition that assigns that new type must then be declared type definition that assigns that new type must then be declared
to be in the substitutionGroup "sdpng:d". to be in the substitutionGroup "sdpng:d".
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:element name="desc"> <xsd:element name="desc">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
The top-level element of an SDPng document. It defines the The top-level element of an SDPng document. It defines the
overall structure of an SPDng document. overall structure of an SPDng document.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:def" minOccurs="0"/> <xsd:element ref="sdpng:def" minOccurs="0"/>
skipping to change at page 31, line 36 skipping to change at page 32, line 21
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:def" minOccurs="0"/> <xsd:element ref="sdpng:def" minOccurs="0"/>
<xsd:element ref="sdpng:cfg"/> <xsd:element ref="sdpng:cfg"/>
<xsd:element ref="sdpng:constraints" minOccurs="0"/> <xsd:element ref="sdpng:constraints" minOccurs="0"/>
<xsd:element ref="sdpng:conf" minOccurs="0"/> <xsd:element ref="sdpng:conf" minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:element name="def"> <xsd:element name="def">
<xsd:annotation> <xsd:annotation>
<xsd:documentation>The definitions section</xsd:documentation> <xsd:documentation>The definitions section</xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:d" maxOccurs="unbounded"/> <xsd:element ref="sdpng:d" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:element name="cfg"> <xsd:element name="cfg">
<xsd:annotation> <xsd:annotation>
<xsd:documentation>The configurations section</xsd:documentation> <xsd:documentation>The configurations section</xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:c" maxOccurs="unbounded"/> <xsd:element ref="sdpng:c" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:element name="constraints"> <xsd:element name="constraints">
<xsd:annotation> <xsd:annotation>
<xsd:documentation>The constraints section</xsd:documentation> <xsd:documentation>The constraints section</xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:cn" maxOccurs="unbounded"/> <xsd:element ref="sdpng:cn" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:element name="conf" type="sdpng:Conference"> <xsd:element name="conf" type="sdpng:Conference">
<xsd:annotation> <xsd:annotation>
<xsd:documentation>The conference section</xsd:documentation> <xsd:documentation>The conference section</xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:element> </xsd:element>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:element name="d" type="sdpng:Definition"> <xsd:element name="d" type="sdpng:Definition">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
Placeholder base element for a definition element in the Placeholder base element for a definition element in the
definitions section. To be derived from by specific definition definitions section. To be derived from by specific definition
element type definitions. element type definitions.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:element> </xsd:element>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:element name="c" type="sdpng:Component"> <xsd:element name="c" type="sdpng:Component">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
Placeholder base element for a configuration element in the Placeholder base element for a configuration element in the
configurations section. To be derived from by specific configurations section. To be derived from by specific
configuration element type definitions. configuration element type definitions.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:element> </xsd:element>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:element name="cn" type="sdpng:Constraint"> <xsd:element name="cn" type="sdpng:Constraint">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
Placeholder base element for a contraint element in the Placeholder base element for a contraint element in the
contraints section. To be derived from by specific constraint contraints section. To be derived from by specific constraint
element type definitions. element type definitions.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:element> </xsd:element>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:complexType name="Definition" abstract="true" mixed="false"> <xsd:complexType name="Definition" abstract="true" mixed="false">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
The base type for definition. Defines a attribute "name" for The base type for definition. Defines a attribute "name" for
naming definitions. naming definitions.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="name" type="xsd:string"/>
</xsd:complexType> </xsd:complexType>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:complexType name="Component" mixed="false"> <xsd:complexType name="Component" mixed="false">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
The specification of a component consists of a sequence of The specification of a component consists of a sequence of
alternatives. alternatives.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:alt" minOccurs="1" maxOccurs="unbounded"/> <xsd:element ref="sdpng:alt" minOccurs="1" maxOccurs="unbounded"/>
skipping to change at page 34, line 31 skipping to change at page 35, line 15
<xsd:complexType name="SessionConfig" abstract="true" mixed="false"> <xsd:complexType name="SessionConfig" abstract="true" mixed="false">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
The (abstract) base type for session elements. To be derived The (abstract) base type for session elements. To be derived
from in extension profiles. from in extension profiles.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:complexType> </xsd:complexType>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:complexType name="Constraint" mixed="false"> <xsd:complexType name="Constraint" mixed="false">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
The current content model for constraints is a sequence of The current content model for constraints is a sequence of
"sdpng:par" elements. In each "par" element a sequence of "sdpng:par" elements. In each "par" element a sequence of
"use-alt" elements may be used to specific the definitions "use-alt" elements may be used to specific the definitions
that may used in parallel. Each "use-alt" element can define that may used in parallel. Each "use-alt" element can define
the number of minimum and maximum instantiations. the number of minimum and maximum instantiations.
</xsd:documentation> </xsd:documentation>
skipping to change at page 35, line 20 skipping to change at page 36, line 4
<xsd:element name="use-alt"> <xsd:element name="use-alt">
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:attribute name="ref" type="xsd:string"/> <xsd:attribute name="ref" type="xsd:string"/>
<xsd:attribute name="min" type="xsd:positiveInteger" <xsd:attribute name="min" type="xsd:positiveInteger"
use="optional"/> use="optional"/>
<xsd:attribute name="max" type="xsd:positiveInteger" <xsd:attribute name="max" type="xsd:positiveInteger"
use="optional"/> use="optional"/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:complexType name="Conference" mixed="false"> <xsd:complexType name="Conference" mixed="false">
<xsd:sequence> <xsd:sequence>
<xsd:element name="meta" type="sdpng:ConfItem"/> <xsd:element name="meta" type="sdpng:ConfItem"/>
</xsd:sequence> </xsd:sequence>
<!-- TBD --> <!-- TBD -->
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="ConfItem" abstract="true" mixed="false"> <xsd:complexType name="ConfItem" abstract="true" mixed="false">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
The base type for conference meta inforformation The base type for conference meta inforformation
element. Currently, there is no common content model defined. element. Currently, there is no common content model defined.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:complexType> </xsd:complexType>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:element name="owner"> <xsd:element name="owner">
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:complexContent mixed="false"> <xsd:complexContent mixed="false">
<xsd:extension base="sdpng:ConfItem"> <xsd:extension base="sdpng:ConfItem">
<xsd:attribute name="user" type="xsd:string"/> <xsd:attribute name="user" type="xsd:string"/>
<xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="session-id" type="xsd:string"/>
<xsd:attribute name="version" type="xsd:string"/> <xsd:attribute name="version" type="xsd:string"/>
<xsd:attribute name="nettype" type="xsd:string"/> <xsd:attribute name="nettype" type="xsd:string"/>
<xsd:attribute name="addrtype" type="xsd:string"/> <xsd:attribute name="addrtype" type="xsd:string"/>
<xsd:attribute name="addr" type="xsd:string"> <xsd:attribute name="addr" type="xsd:string">
<!-- FIXME: re-use common address type! --> <!-- FIXME: re-use common address type! -->
</xsd:attribute> </xsd:attribute>
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:complexType name="SimpleLink" mixed="false">
<xsd:attribute name="xlink:type" type="xsd:string" fixed="simple"/>
<xsd:attribute name="xlink:role" type="xsd:string"/>
<xsd:attribute name="xlink:arcrole" type="xsd:string"/>
<xsd:attribute name="xlink:title" type="xsd:string"/>
<xsd:attribute name="xlink:show" type="xsd:string" fixed="none"/>
<xsd:attribute name="xlink:actuate" type="xsd:string" fixed="none"/>
<xsd:attribute name="xlink:href" type="xsd:string"/>
</xsd:complexType>
<xsd:element name="session"> <xsd:element name="session">
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:complexContent mixed="false"> <xsd:complexContent mixed="false">
<xsd:extension base="sdpng:ConfItem"> <xsd:extension base="sdpng:ConfItem">
<xsd:sequence> <xsd:sequence>
<xsd:element name="description" type="xsd:string"/> <xsd:element name="description" type="xsd:string"/>
<xsd:element name="info"> <xsd:element name="info" type="sdpng:SimpleLink"/>
<xsd:complexType mixed="false">
<xsd:attribute name="href" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:sequence minOccurs="0"> <xsd:sequence minOccurs="0">
<xsd:element name="contact" type="xsd:string"/> <xsd:element name="contact" type="sdpng:SimpleLink"/>
</xsd:sequence> </xsd:sequence>
</xsd:sequence> </xsd:sequence>
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:schema> </xsd:schema>
4.7.2 Audio Codec Profile 4.7.2 Audio Codec Profile
The following profile defines an element type that can be used for The following profile defines an element type that can be used for
specifying audio codec characteristics. The element "audio:codec" is specifying audio codec characteristics. The element "audio:codec" is
of type "audio:AudioCodec" which is derived from the SDPng base type of type "audio:AudioCodec" which is derived from the SDPng base type
"sdpng:Definition". The element "audio:codec" is declared to have "sdpng:Definition". The element "audio:codec" is declared to have
the subsitution group "sdpng:d" (the "head element" of the SDPng base the substitution group "sdpng:d" (the "head element" of the SDPng
definition). base definition).
This means, "audio:codec" element can be used as child elements in This means, "audio:codec" element can be used as child elements in
"sdpng:def" elements. In addition to the attributes specified here "sdpng:def" elements. In addition to the attributes specified here
"audio:codec" elements will also have to provide a "name" attribute "audio:codec" elements will also have to provide a "name" attribute
as defined by "sdpng:Definition". as defined by "sdpng:Definition".
<xsd:schema targetNamespace="http://www.iana.org/sdpng/audio" <xsd:schema targetNamespace="http://www.iana.org/sdpng/audio"
xmlns:audio="http://www.iana.org/sdpng/audio" xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:sdpng="http://www.iana.org/sdpng" xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xsd:import namespace="http://www.iana.org/sdpng" schemaLocation="sdpng.xsd"/> <xsd:import namespace="http://www.iana.org/sdpng"
schemaLocation="sdpng.xsd"/>
<!-- AudioCodecs extends the abstract type "Definition" --> <!-- AudioCodecs extends the abstract type "Definition" -->
<!-- The data types for the attributes could be more restrictive... --> <!-- The data types for the attributes could be more restrictive... -->
<xsd:complexType name="AudioCodec" mixed="false"> <xsd:complexType name="AudioCodec" mixed="false">
<xsd:complexContent mixed="false"> <xsd:complexContent mixed="false">
<xsd:extension base="sdpng:Definition"> <xsd:extension base="sdpng:Definition">
<xsd:attribute name="encoding" type="xsd:string"/> <xsd:attribute name="encoding" type="xsd:string"/>
<xsd:attribute name="sampling" type="xsd:positiveInteger"/> <xsd:attribute name="sampling" type="xsd:positiveInteger"/>
<xsd:attribute name="channels" type="xsd:positiveInteger"/> <xsd:attribute name="channels" type="xsd:positiveInteger"/>
</xsd:extension> </xsd:extension>
skipping to change at page 37, line 41 skipping to change at page 38, line 42
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:schema> </xsd:schema>
4.7.3 RTP profile 4.7.3 RTP profile
The following profile defines element types that can be used for The following profile defines element types that can be used for
specifying RTP payload types and RTP session configurations. The specifying RTP payload types and RTP session configurations. The
element "rtp:pt" is of type "rtp:PayloadType" which is derived from element "rtp:pt" is of type "rtp:PayloadType" which is derived from
the SDPng base type "sdpng:Definition". The element "rtp:pt" is the SDPng base type "sdpng:Definition". The element "rtp:pt" is
declared to have the subsitution group "sdpng:d" (the "head element" declared to have the substitution group "sdpng:d" (the "head element"
of the SDPng base definition). of the SDPng base definition).
The element "rtp:session" is of type "rtp:Session" which is derived The element "rtp:session" is of type "rtp:Session" which is derived
from the SDPng base type "sdpng:SessionConfig". The element from the SDPng base type "sdpng:SessionConfig". The element
"rtp:session" is declared to have the subsitution group "sdpng:sc" "rtp:session" is declared to have the substitution group "sdpng:sc"
(the "head element" of the SDPng base definition). (the "head element" of the SDPng base definition).
The RTP profile in turn defines base types for the specification of The RTP profile in turn defines base types for the specification of
transport parameters that are to be derived from by profiles that transport parameters that are to be derived from by profiles that
define rules for elements that can be used to specifiy parameters for define rules for elements that can be used to specify parameters for
specific transport mechanisms. specific transport mechanisms.
<xsd:schema targetNamespace="http://www.iana.org/sdpng/rtp" <xsd:schema targetNamespace="http://www.iana.org/sdpng/rtp"
xmlns:rtp="http://www.iana.org/sdpng/rtp" xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:sdpng="http://www.iana.org/sdpng" xmlns:sdpng="http://www.iana.org/sdpng"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xsd:import namespace="http://www.iana.org/sdpng" schemaLocation="sdpng.xsd"/> <xsd:import namespace="http://www.iana.org/sdpng"
schemaLocation="sdpng.xsd"/>
<xsd:complexType name="PayloadType" mixed="false"> <xsd:complexType name="PayloadType" mixed="false">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
PayloadType, the element for payload type definitions is PayloadType, the element for payload type definitions is
derived from "sdpng:Definition". Inside an element of this derived from "sdpng:Definition". Inside an element of this
type, more definitions may be given (derived from type, more definitions may be given (derived from
sdpng:Definition themselves). If no definition is given in the sdpng:Definition themselves). If no definition is given in the
content, a definition may be referenced using the "format content, a definition may be referenced using the "format
attribute". attribute".
skipping to change at page 38, line 42 skipping to change at page 39, line 46
<xsd:attribute name="pt" type="xsd:unsignedByte"/> <xsd:attribute name="pt" type="xsd:unsignedByte"/>
<xsd:attribute name="format" type="xsd:string"> <xsd:attribute name="format" type="xsd:string">
<!-- IDREF? Issue: unique names for definitions!--> <!-- IDREF? Issue: unique names for definitions!-->
</xsd:attribute> </xsd:attribute>
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="pt" type="rtp:PayloadType" substitutionGroup="sdpng:d"/> <xsd:element name="pt" type="rtp:PayloadType" substitutionGroup="sdpng:d"/>
<!-- ______________________________________________________________________ --> <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:element name="session" type="rtp:Session" <xsd:element name="session" type="rtp:Session" substitutionGroup="sdpng:sc"/>
substitutionGroup="sdpng:sc"/>
<xsd:complexType name="Session" mixed="false"> <xsd:complexType name="Session" mixed="false">
<xsd:complexContent mixed="false"> <xsd:complexContent mixed="false">
<xsd:extension base="sdpng:SessionConfig"> <xsd:extension base="sdpng:SessionConfig">
<xsd:sequence> <xsd:sequence>
<xsd:element name="transport" type="rtp:Transport"/> <xsd:element name="transport" type="rtp:Transport"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="format" type="xsd:string"/> <xsd:attribute name="format" type="xsd:string"/>
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="Transport" abstract="true" mixed="false"> <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="rtp-port" type="xsd:unsignedShort" use="optional"/>
<xsd:attribute name="rtcp-port" type="xsd:unsignedShort" use="optional"/> <xsd:attribute name="rtcp-port" type="xsd:unsignedShort" use="optional"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:simpleType name="IPAddr"> <xsd:simpleType name="IPAddr">
<xsd:restriction base="xsd:string"/> <xsd:restriction base="xsd:string"/>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="IP4Addr"> <xsd:simpleType name="IP4Addr">
<xsd:restriction base="rtp:IPAddr"/> <xsd:restriction base="rtp:IPAddr"/>
</xsd:simpleType> </xsd:simpleType>
skipping to change at page 39, line 39 skipping to change at page 40, line 47
<xsd:extension base="rtp:Transport"> <xsd:extension base="rtp:Transport">
<xsd:choice> <xsd:choice>
<xsd:element name="option"> <xsd:element name="option">
<!-- define options --> <!-- define options -->
</xsd:element> </xsd:element>
</xsd:choice> </xsd:choice>
<xsd:attribute name="addr" type="rtp:IP4Addr"/> <xsd:attribute name="addr" type="rtp:IP4Addr"/>
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="udp" type="rtp:UDP"/> <xsd:element name="udp" type="rtp:UDP"/>
</xsd:schema> </xsd:schema>
4.8 Issues 4.8 Issues
o Libraries provide partially specified definitions, i.e. without o 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 conrete transport parameters? definitions and augment them with specific transport parameters?
o Referencing extension profiles: XML-Schema does not support the o Referencing extension profiles: 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 profiles 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 profiles 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.
o Uniqueness of attribute values: When libraries are used they will o 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 solution: Prefix such IDs with a namespace name (either explicitly
explicitely or implicitely by interpreting applications). The or implicitly by interpreting applications). The explicit
explicit prefixes have the advantage that no special knowledge prefixes have the advantage that no special knowledge would be
would be required to ressolve links at the cost of very long ID required to resolve links at the cost of very long ID values.
values.
5. Use of SDPng in conjunction with other IETF Signaling Protocols 5. Use of SDPng in conjunction with other IETF Signaling Protocols
SDPng defines the notion of Components to indicate the intended types The SDPng model provides the notion of Components to indicate the
of collaboration between the users in e.g. a teleconferencing intended types of collaboration between the users in e.g. a
scenario. teleconferencing scenario.
For the means conceivable to realize a particular Component, SDPng Three different abstractions are defined that are used for describing
conceptually distinguishes three levels of support: the properties of a specific Component:
a Capapility refers to the fact that one of the involved parties o a Capability refers to the fact that one of the involved parties
supports one particular way of exchanging media -- defined in supports one particular way of exchanging media -- defined in
terms of transport, codec, and other parameters -- as part of the terms of transport, codec, and other parameters -- as part of the
teleconference. media session.
a Potential Configuration denotes a set of matching Capabilities o a Potential Configuration denotes a set of matching Capabilities
from all those involved parties required to successfully realize from all those involved parties required to successfully realize
one particular Component. one particular Component.
an Actual Configuration indicates the Potential Configuration o an Actual Configuration indicates the Potential Configuration
which was chosen by the involved parties to realize a certain which was chosen by the involved parties to realize a certain
Component at one particular point in time. Component at one particular point in time.
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
scenarios for the use of SDPng within specific protocols and
applications. Is does not specify normative requirements.
5.1 The Session Announcement Protocol (SAP) 5.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 announcements contains the Actual This means that a SAP announcement contains the Actual Configurations
Configurations of all Components that are part of the overall of all Components that are part of the overall teleconference or
teleconference or broadcast. broadcast.
A SAP announcement may contain multiple Actual Configurations for the A SAP announcement may contain multiple Actual Configurations for the
same Component. In this case, the "same" (i.e. semantically same Component. In this case, the "same" (i.e. semantically
equivalent) media data from one configuration must be available from equivalent) media data from one configuration must be available from
each of the Actual Configurations. In practice, this limits the use each of the Actual Configurations. In practice, this limits the use
of multiple Actual Configurations to single-source multicast or of multiple Actual Configurations to single-source multicast or
broadcast scenarios. broadcast scenarios.
Each receiver of a SAP announcement with SDPng compares its locally Each receiver of a SAP announcement with SDPng compares its locally
stored Capabiities to realize a certain Component against the Actual stored Capabilities to realize a certain Component against the Actual
Configurations contained in the announcement. If the intersection Configurations contained in the announcement. If the intersection
yields one or more Potential Configurations for the receiver, it yields one or more Potential Configurations for the receiver, it
chooses the one it sees fit best. If the intersection is empty, the chooses the one it sees fit best. If the intersection is empty, the
receiver cannot participate in the announced session. receiver cannot participate in the announced session.
SAP may be substituted by HTTP (in the general case, at least), SMTP, SAP may be substituted by HTTP (in the general case, at least), SMTP,
NNTP, or other IETF protocols suitable for conveying a media NNTP, or other IETF protocols suitable for conveying a media
description from one entity to one or more other without the intend description from one entity to one or more other without the intend
for further negotiation of the session parameters. for further negotiation of the session parameters.
skipping to change at page 42, line 35 skipping to change at page 43, line 39
receiver has indicated support (and has provided an address) for. receiver has indicated support (and has provided an address) for.
Codec changes are not signaled out-of-band but only indicated by the Codec changes are not signaled out-of-band but only indicated by the
payload type within the media stream. From this arises one important payload type within the media stream. From this arises one important
consequence to the conceptual view of a Component within SDPng. consequence to the conceptual view of a Component within SDPng.
There is no clear distinction between Potential and Actual There is no clear distinction between Potential and Actual
Configurations. There need not be a single Actual Configuration be Configurations. There need not be a single Actual Configuration be
chosen at setup time within the SIP signaling. Instead, a number of chosen at setup time within the SIP signaling. Instead, a number of
Potential Configurations is signaled in SIP (with all transport Potential Configurations is signaled in SIP (with all transport
parameters required for carrying media streams) and the Actual parameters required for carrying media streams) and the Actual
Configuration is only identified by the paylaod type which is Configuration is only identified by the payload type which is
actually being transmitted at any point in time. actually being transmitted at any point in time.
Note that since SDPng does not explicitly distinguish between Note that since SDPng does not explicitly distinguish between
Potential and Actual Configurations, this has no implications on the Potential and Actual Configurations, this has no implications on the
SDPng signaling itself. SDPng signaling itself.
SIP Examples to be defined. SIP relies on an "offer/answer" model for the exchange of capability
and configuration information. Either the caller or the callee sends
an initial session description that is processed by the other side
and returned. For capability negotiation, this means that the
negotiation follows a two-stage-process: The "offerer" sends its
capability description to the receiver. The receiver processes the
offerers capabilities and his own capabilities and generates a result
capability description that is sent back to the offerer. Both sides
now know the commonly supported configurations and can initiate the
media sessions.
Because of this strict "offer/answer" model, the offerer must already
send complete configurations (i.e. include transport addresses) along
with the capability descriptions. The answer must also contain
complete configuration parameters. The following figure shows, how
SDPng content can be used in an INVITE request with a correspong 200
OK message.
Simple description document with only one alternative:
F1 INVITE A -> B
INVITE sip:B@example.com SIP/2.0
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Contact: <sip:UserA@192.168.1.1>
Content-Type: application/sdpng
Content-Length: 685
<def>
<audio:codec name="audio-basic" encoding="PCMU"
sampling="8000" channels="1"/>
<rtp:pt name="rtp-avp-0" pt="0" format="audio-basic"/>
</def>
<cfg>
<component name="interactive-audio" media="audio">
<alt name="AVP-audio-0">
<rtp:session format="rtp-avp-0">
<rtp:udp role="receive" endpoint="A" addr="192.168.1.1"
rtp-port="7800"/>
</rtp:session>
</alt>
</component>
</cfg>
<conf>
<owner user="A@example.com" id="98765432" version="1" nettype="IN"
addrtype="IP4" addr="192.168.1.1"/>
<session name="SDPng questions">
</session>
<info name="interactive-audio" function="voice">
Telephony media stream
<info>
</conf>
==================================================
F2 (100 Trying) B -> A
SIP/2.0 100 Trying
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Content-Length: 0
==================================================
F3 180 Ringing B -> A
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>;tag=987654
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Content-Length: 0
==================================================
F4 200 OK B -> A
SIP/2.0 200 OK
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>;tag=987654
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Contact: <sip:B@192.168.1.2>
Content-Type: application/sdpng
Content-Length: 479
<def>
<audio:codec name="audio-basic" encoding="PCMU"
sampling="8000" channels="1"/>
<rtp:pt name="rtp-avp-0" pt="0" format="audio-basic"/>
</def>
<cfg>
<component name="interactive-audio" media="audio">
<alt name="AVP-audio-0">
<rtp:session format="rtp-avp-0">
<rtp:udp role="receive" endpoint="A" addr="192.168.1.1"
rtp-port="7800"/>
<rtp:udp role="receive" endpoint="B" addr="192.168.1.2"
rtp-port="9410"/>
</rtp:session>
</alt>
</component>
</cfg>
==================================================
ACK from A to B omitted
In the INVITE message, A sends B a description document, that
specifies exactly one component with one alternative (the PCMU audio
stream). All required transport parameters all already contained in
the description. The rtp:udp element provides an attribute "role"
with a value of "receive", indicating that the specified endpoint
address is used by the endpoint to receive media data. The element
also provides the attribute "endpoint" with a value of "A",
denominating the endpoint that can receive data on the specified
address. This means, the semantics of specified transport addresses
in configuration descriptions are the same as for SDP (when used with
SIP): An endpoint specifies where it wants to receive data.
In the 200 OK message, B sends an updated description document to A.
For the sake of conciseness, the conf element (containing meta
information about the conference) has been omitted. B supports the
payload format that A has offered and adds his own transport
parameters to the configuration information, specifying the endpoint
address where B wants to receive media data. In order to
disambiguate its transport configurations from A's, B sets the
attribute "endpoint" to the value "B". The specific value of the
"endpoint" attribute is not important, the only requirements are that
a party that contributes to the session description, must use a
unique name for the endpoint attribute and that a contributing party
must use the same value for the endpoint attributes of all elements
it adds to the session description.
The following example shows a capability description that provides
two alternatives for the audio component.
Description document with two alternatives:
F1 INVITE A -> B
INVITE sip:B@example.com SIP/2.0
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Contact: <sip:UserA@192.168.1.1>
Content-Type: application/sdpng
Content-Length: 935
<def>
<audio:codec name="audio-basic" encoding="PCMU"
sampling="8000" channels="1"/>
<audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-0" pt="0" format="audio-basic"/>
<rtp:pt name="rtp-avp-18" pt="18" format="g729"/>
<rtp:udp name="A-rcv" role="receive" endpoint="A" addr="192.168.1.1"
rtp-port="7800"/>
</def>
<cfg>
<component name="interactive-audio" media="audio">
<alt name="AVP-audio-0">
<rtp:session format="rtp-avp-0" transport="A-rcv""/>
</alt>
<alt name="AVP-audio-18">
<rtp:session format="rtp-avp-18" transport="A-rcv"/>
</alt>
</component>
</cfg>
<conf>
<owner user="A@example.com" id="98765432" version="1" nettype="IN"
addrtype="IP4" addr="192.168.1.1"/>
<session name="SDPng questions">
</session>
<info name="interactive-audio" function="voice">
Telephony media stream
<info>
</conf>
==================================================
F2 (100 Trying) B -> A
SIP/2.0 100 Trying
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Content-Length: 0
==================================================
F3 180 Ringing B -> A
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>;tag=987654
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Content-Length: 0
==================================================
F4 200 OK B -> A
SIP/2.0 200 OK
Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com>
To: B <sip:B@example.com>;tag=987654
Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE
Contact: <sip:B@192.168.1.2>
Content-Type: application/sdpng
Content-Length: 479
<def>
<audio:codec name="audio-basic" encoding="PCMU"
sampling="8000" channels="1"/>
<audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-0" pt="0" format="audio-basic"/>
<rtp:pt name="rtp-avp-18" pt="18" format="g729"/>
<rtp:udp name="A-rcv" role="receive" endpoint="A" addr="192.168.1.1"
rtp-port="7800"/>
<rtp:udp name="B-rcv" role="receive" endpoint="B" addr="192.168.1.2"
rtp-port="9410"/>
</def>
<cfg>
<component name="interactive-audio" media="audio">
<alt name="AVP-audio-0">
<rtp:session format="rtp-avp-0" transport="A-rcv B-rcv"/>
</alt>
</component>
</cfg>
==================================================
ACK from A to B omitted
In the INVITE message, A sends B a description document, that
specifies one component with two alternatives for the audio stream
(PCMU and G.729). Since A wants to use the same transport address
for receiving media data regardless of the payload format, A provides
the transport specification in the def element and references this
definition in the rtp:session elements for both alternatives by using
the attribute "transport".
In the 200 OK message, B sends an updated description document to A.
B does only support PCMU, so it removes the alternative for G.729
from the description. B also defines its transport address in the
def element and references this definition by adding "B-rcv" to the
attribute "transport" of the rtp:session element. (B could also have
used the rtp:udp element inside the rtp:session element, but this
example intends to demonstrate how to reference multiple transport
definitions by using the attribute "transport").
5.3 Real-Time Streaming Protocol (RTSP) 5.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
skipping to change at page 44, line 7 skipping to change at page 51, line 7
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.
6. Open Issues 6. Open Issues
The precise sytnax for referencing profiles and libraries needs to Definition of baseline libraries
be worked out.
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.
Transport and Payload type specifications need to be defined as
additional appendices.
Negotiation mechanisms for multiparty conferencing need to be Negotiation mechanisms for multiparty conferencing need to be
formalized. formalized.
Further details on the signaling protocols need to be filled in.
Mapping to other media description formats (SDP, H.245, ...) Mapping to other media description formats (SDP, H.245, ...)
should be provided. For H.245, this is probably a different should be provided. For H.245, this is probably a different
document (beloning to the SIP-H.323 interworking group). document (belonging to the SIP-H.323 inter-working group).
Implicit declaration of SDPng schema and default profiles
References References
[1] Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements [1] Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements
for Session Description and Capability Negotiation", Internet for Session Description and Capability Negotiation", Internet
Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001. Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001.
[2] Handley, M. and V. Jacobsen, "SDP: Session Description [2] Handley, M. and V. Jacobsen, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
skipping to change at page 45, line 29 skipping to change at page 52, line 29
with Minimal Control", RFC 1890, January 1996. with Minimal Control", RFC 1890, January 1996.
[5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video [5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", draft-ietf-avt-profile-new- Conferences with Minimal Control", draft-ietf-avt-profile-new-
10.txt (work in progress), March 2001. 10.txt (work in progress), March 2001.
[6] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, [6] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP
Payload for Redundant Audio Data", RFC 2198, September 1997. Payload for Redundant Audio Data", RFC 2198, September 1997.
[7] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC [7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
2533, March 1999.
[8] Klyne, G., "Protocol-independent Content Negotiation
Framework", RFC 2703, September 1999.
[9] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999. Generic Forward Error Correction", RFC 2733, December 1999.
[10] Perkins, C. and O. Hodson, "Options for Repair of Streaming [8] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998. Media", RFC 2354, June 1998.
[11] Handley, M., Perkins, C. and E. Whelan, "Session Announcement [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[12] World Wide Web Consortium (W3C), "Extensible Markup Language [10] World Wide Web Consortium (W3C), "Extensible Markup Language
(XML) 1.0 (Second Edition)", Status W3C Recommendation, Version (XML) 1.0 (Second Edition)", Status W3C Recommendation, Version
http://www.w3.org/TR/2000/REC-xml-20001006, October 2000. http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.
[13] World Wide Web Consortium (W3C), "Namespaces in XML", Status [11] World Wide Web Consortium (W3C), "Namespaces in XML", Status
W3C Recommendation, Version http://www.w3.org/TR/1999/REC-xml- W3C Recommendation, Version http://www.w3.org/TR/1999/REC-xml-
names-19990114, January 1999. names-19990114, January 1999.
[14] World Wide Web Consortium (W3C), "XML Inclusions (XInclude) [12] World Wide Web Consortium (W3C), "XML Inclusions (XInclude)
Version 1.0", Status W3C Working Draft, Version Version 1.0", Status W3C Working Draft, Version
http://www.w3.org/TR/2001/WD-xinclude-20010516, May 2001. http://www.w3.org/TR/2001/WD-xinclude-20010516, May 2001.
[15] World Wide Web Consortium (W3C), "XML Schema Part 1: [13] World Wide Web Consortium (W3C), "XML Schema Part 1:
Structures", Version http://www.w3.org/TR/2001/REC-xmlschema-1- Structures", Version http://www.w3.org/TR/2001/REC-xmlschema-1-
20010502/, Status W3C Recommendation, May 2001. 20010502/, Status W3C Recommendation, May 2001.
[16] 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.
Authors' Addresses Authors' Addresses
Dirk Kutscher Dirk Kutscher
TZI, Universitaet Bremen TZI, Universitaet Bremen
Bibliothekstr. 1 Bibliothekstr. 1
Bremen 28359 Bremen 28359
Germany Germany
skipping to change at page 47, line 31 skipping to change at page 54, line 31
mime: the MIME type; may alternatively be specified instead of mime: the MIME type; may alternatively be specified instead of
"encoding" "encoding"
channels: the number of independent media channels channels: the number of independent media channels
pattern: the media channel pattern for mapping channels to payload pattern: the media channel pattern for mapping channels to payload
sampling: the sample rate for the codec (which in most cases equals sampling: the sample rate for the codec (which in most cases equals
the RTP clock) the RTP clock)
Furthermode, options may be defined of the following format: Furthermore, options may be defined of the following format:
<option id="name">value</option> <option id="name">value</option>
if a value is associated with the option (note that arbitrary complex if a value is associated with the option (note that arbitrary complex
values are allowed), or alternatively: values are allowed), or alternatively:
<option id="name"/> <option id="name"/>
if the option is just a boolean indicator. if the option is just a boolean indicator.
skipping to change at page 51, line 5 skipping to change at page 58, line 5
A.13 QCELP A.13 QCELP
<audio:codec name="qcelp" encoding="QCELP" channels="1" sampling="8000"/> <audio:codec name="qcelp" encoding="QCELP" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-12" pt="12" format="qcelp"/> <rtp:pt name="rtp-avp-12" pt="12" format="qcelp"/>
A.14 VDVI A.14 VDVI
<audio:codec name="vdvi" encoding="VDVI" channels="1" sampling="8000"/> <audio:codec name="vdvi" encoding="VDVI" channels="1" sampling="8000"/>
Appendix B. Change History Appendix B. SDPng Library for Audio Codec Definitions
This section contains an SDPng library with the audio codec
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">
<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 C. 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" format="dvi4"/>
<rtp:pt name="rtp-avp-6" pt="6">
<audio:codec encoding="DVI4" channels="1" sampling="16000">
</rtp:pt>
<rtp:pt name="rtp-avp-9" pt="9" format="g722"/>
<rtp:pt name="rtp-avp-5" pt="5" format="g726-32"/>
<rtp:pt name="rtp-avp-15" pt="15" format="g728"/>
<rtp:pt name="rtp-avp-18" pt="18" format="g729"/>
<rtp:pt name="rtp-avp-3" pt="3" format="gsm"/>
<rtp:pt name="rtp-avp-11" pt="11" format="gsm"/>
<rtp:pt name="rtp-avp-10" pt="11" format="gsm">
<audio:codec encoding="L16" channels="2" sampling="8000"/>
</rtp:pt>
<rtp:pt name="rtp-avp-14" pt="14" format="mpa"/>
<rtp:pt name="rtp-avp-0" pt="0" format="pcmu"/>
<rtp:pt name="rtp-avp-8" pt="8" format="pcma"/>
<rtp:pt name="rtp-avp-12" pt="12" format="qcelp"/>
</def>
Appendix D. Change History
draft-ietf-mmusic-sdpng-03.txt
* Extension of the SDPng schema (use of Xlinks etc.)
* Clarification in the text
* Fixed examples
* Added example libraries as appendices
* 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 4). * Added a section on formal specification mechanisms (Section 4).
draft-ietf-mmusic-sdpng-01.txt draft-ietf-mmusic-sdpng-01.txt
* renamed section "Syntax Propsal" 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 Atrributes" 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 (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). 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
 End of changes. 

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