draft-ietf-mmusic-sdpng-04.txt   draft-ietf-mmusic-sdpng-05.txt 
Network Working Group Kutscher Network Working Group Kutscher
Internet-Draft Ott Internet-Draft Ott
Expires: August 30, 2002 Bormann Expires: December 30, 2002 Bormann
TZI, Universitaet Bremen TZI, Universitaet Bremen
March 01, 2002 July 01, 2002
Session Description and Capability Negotiation Session Description and Capability Negotiation
draft-ietf-mmusic-sdpng-04.txt draft-ietf-mmusic-sdpng-05.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 August 30, 2002. This Internet-Draft will expire on December 30, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document defines a language for describing multimedia sessions This document defines a language for describing multimedia sessions
with respect to configuration parameters and capabilities of end- with respect to configuration parameters and capabilities of end-
systems. systems.
This document is a product of the Multiparty Multimedia Session This document is a product of the Multiparty Multimedia Session
Control (MMUSIC) working group of the Internet Engineering Task Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the working Force. Comments are solicited and should be addressed to the working
group's mailing list at mmusic@ietf.org and/or the authors. group's mailing list at mmusic@ietf.org and/or the authors.
Document Revision Document Revision
$Revision: 4.23 $ $Revision: 4.12 $
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 . . . . . . . . . . . . . . . 17
3.3 Referencing Definitions . . . . . . . . . . . . . . . . . 20 3.3 Referencing Definitions . . . . . . . . . . . . . . . . . 20
3.3.1 The sdpng:use Element Type . . . . . . . . . . . . . . . . 21 3.3.1 The attribute "ref" . . . . . . . . . . . . . . . . . . . 21
3.3.2 Properties . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4 External Definition Packages . . . . . . . . . . . . . . . 22
3.3.3 Definition Groups . . . . . . . . . . . . . . . . . . . . 23 3.4.1 Profile Definitions . . . . . . . . . . . . . . . . . . . 22
3.3.4 Usage of Child Elements and Attributes of sdpng:use 3.4.2 Library Definitions . . . . . . . . . . . . . . . . . . . 23
Elements . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 External Definition Packages . . . . . . . . . . . . . . . 28 4. Capability Negotiation . . . . . . . . . . . . . . . . . . 26
3.4.1 Profile Definitions . . . . . . . . . . . . . . . . . . . 28 4.1 Outline of the Negotiation Process . . . . . . . . . . . . 26
3.4.2 Library Definitions . . . . . . . . . . . . . . . . . . . 29 4.2 The Collapsing Algorithm . . . . . . . . . . . . . . . . . 28
3.5 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.1 Collapsing Two Configurations . . . . . . . . . . . . . . 29
4. Capability Negotiation . . . . . . . . . . . . . . . . . . 32 4.2.1.1 Collapsing of Attributes . . . . . . . . . . . . . . . . . 29
4.1 Outline of the Negotiation Process . . . . . . . . . . . . 32 4.2.1.2 Collapsing two Elements . . . . . . . . . . . . . . . . . 32
4.2 The Collapsing Algorithm . . . . . . . . . . . . . . . . . 34 4.2.1.3 Collapsing nested Elements . . . . . . . . . . . . . . . . 33
4.2.1 Collapsing Two Configurations . . . . . . . . . . . . . . 35 4.2.2 Deriving an actual Configuration . . . . . . . . . . . . . 35
4.2.1.1 Collapsing of Attributes . . . . . . . . . . . . . . . . . 35 5. Formal Specification . . . . . . . . . . . . . . . . . . . 36
4.2.1.2 Collapsing two Elements . . . . . . . . . . . . . . . . . 38 5.1 XML Schema as a Definition Mechanism . . . . . . . . . . . 36
4.2.1.3 Collapsing nested Elements . . . . . . . . . . . . . . . . 39 5.2 SDPng Schema . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2 Deriving an actual Configuration . . . . . . . . . . . . . 41 5.3 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 38
5. Formal Specification . . . . . . . . . . . . . . . . . . . 42 5.4 SDPng Documents . . . . . . . . . . . . . . . . . . . . . 39
5.1 XML Schema as a Definition Mechanism . . . . . . . . . . . 42 5.5 Libraries . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 SDPng Schema . . . . . . . . . . . . . . . . . . . . . . . 43 5.6 Details on the use of specific XML Mechanisms . . . . . . 41
5.3 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.6.1 Default Namespace . . . . . . . . . . . . . . . . . . . . 41
5.4 SDPng Documents . . . . . . . . . . . . . . . . . . . . . 45 5.6.2 Qualified Locals . . . . . . . . . . . . . . . . . . . . . 41
5.5 Libraries . . . . . . . . . . . . . . . . . . . . . . . . 46 5.6.3 Fixed Namespace Prefixes . . . . . . . . . . . . . . . . . 42
5.6 Details on the use of specific XML Mechanisms . . . . . . 47 5.7 SDPng Schema Definitions . . . . . . . . . . . . . . . . . 42
5.6.1 Default Namespace . . . . . . . . . . . . . . . . . . . . 47 5.7.1 SDPng Base Definition . . . . . . . . . . . . . . . . . . 42
5.6.2 Qualified Locals . . . . . . . . . . . . . . . . . . . . . 47 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 50
5.6.3 Fixed Namespace Prefixes . . . . . . . . . . . . . . . . . 48 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 51
5.7 SDPng Schema Definitions . . . . . . . . . . . . . . . . . 48 References . . . . . . . . . . . . . . . . . . . . . . . . 52
5.7.1 SDPng Base Definition . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53
5.7.2 Audio Codec Profile . . . . . . . . . . . . . . . . . . . 55 A. SDPng Audio Codec Profile and Audio Codec Library . . . . 55
5.7.3 RTP profile . . . . . . . . . . . . . . . . . . . . . . . 56 A.1 Audio Codec Profile . . . . . . . . . . . . . . . . . . . 55
5.8 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.2 SDPng Library for Audio Codec Definitions . . . . . . . . 57
6. Use of SDPng in conjunction with other IETF Signaling A.2.1 DVI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Protocols . . . . . . . . . . . . . . . . . . . . . . . . 60 A.2.2 G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1 The Session Announcement Protocol (SAP) . . . . . . . . . 60 A.2.3 G.726 . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . 61 A.2.4 G.728 . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . 67 A.2.5 G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . 68 A.2.6 G.729 Annex D and E . . . . . . . . . . . . . . . . . . . 59
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 69 A.2.7 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
References . . . . . . . . . . . . . . . . . . . . . . . . 70 A.2.7.1 GSM Full Rate . . . . . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 71 A.2.7.2 GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . 60
A. Base SDPng Specifications for Audio Codec Descriptions . . 72 A.2.7.3 GSM Enhanced Full Rate . . . . . . . . . . . . . . . . . . 60
A.1 DVI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.2.8 L8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2 G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.2.9 L16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.3 G.726 . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.2.10 LPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.4 G.728 . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.2.11 MPA . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.5 G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.2.12 PCMA and PCMU . . . . . . . . . . . . . . . . . . . . . . 61
A.6 G.729 Annex D and E . . . . . . . . . . . . . . . . . . . 74 A.2.13 QCELP . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.7 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 A.2.14 VDVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.7.1 GSM Full Rate . . . . . . . . . . . . . . . . . . . . . . 74 B. SDPng Profile for RTP Profile and RTP Library . . . . . . 63
A.7.2 GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . 74 B.1 RTP profile . . . . . . . . . . . . . . . . . . . . . . . 63
A.7.3 GSM Enhanced Full Rate . . . . . . . . . . . . . . . . . . 74 B.2 SDPng Library for RTP Payload Format Definitions . . . . . 65
A.8 L8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 C. Use of SDPng in conjunction with other IETF Signaling
A.9 L16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 67
A.10 LPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 C.1 The Session Announcement Protocol (SAP) . . . . . . . . . 67
A.11 MPA . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 C.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . 68
A.12 PCMA and PCMU . . . . . . . . . . . . . . . . . . . . . . 75 C.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . 75
A.13 QCELP . . . . . . . . . . . . . . . . . . . . . . . . . . 75 C.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . 75
A.14 VDVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 D. Change History . . . . . . . . . . . . . . . . . . . . . . 76
B. SDPng Library for Audio Codec Definitions . . . . . . . . 76 Full Copyright Statement . . . . . . . . . . . . . . . . . 78
C. SDPng Library for RTP Payload Format Definitions . . . . . 77
D. Change History . . . . . . . . . . . . . . . . . . . . . . 78
Full Copyright Statement . . . . . . . . . . . . . . . . . 79
1. Introduction 1. Introduction
Multiparty multimedia conferencing is one of the applications that Multiparty multimedia conferencing is one of the applications that
require dynamic interchange of end-system capabilities and the require dynamic interchange of end-system capabilities and the
negotiation of a parameter set that is appropriate for all sending negotiation of a parameter set that is appropriate for all sending
and receiving end-systems in a conference. For some applications, and receiving end-systems in a conference. For some applications,
e.g. for loosely coupled conferences or for broadcast scenarios, it e.g. for loosely coupled conferences or for broadcast scenarios, it
may be sufficient to simply have session parameters be fixed by the may be sufficient to simply have session parameters be fixed by the
initiator of a conference. In such a scenario no negotiation is initiator of a conference. In such a scenario no negotiation is
skipping to change at page 5, line 25 skipping to change at page 5, line 25
This document is based upon a set of requirements specified in a This document is based upon a set of requirements specified in a
companion document [1]. In the following, we first introduce a model companion document [1]. In the following, we first introduce a model
for session description and capability negotiation as well as the for session description and capability negotiation as well as the
basic terms used throughout this specification (section 2). Next, we basic terms used throughout this specification (section 2). 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 provide IETF signaling protocols in section 5. In Appendix A, we provide
basic audio codec and payload type definitions that are subsumed in basic audio codec and payload type definitions that are subsumed in
SDPng libraries in Appendix B and Appendix C. SDPng libraries in Appendix A.2 and Appendix B.2.
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 enabled replayed, etc. with this particular device. We term features
and restricted by these resources "system capabilities". enabled and restricted by these resources "system capabilities".
Example: System capabilities may include: a limitation of the Example: System capabilities may include: a limitation of the
screen resolution for true color by the graphics board; available screen resolution for true color by the graphics board; available
audio hardware or software may offer only certain media encodings audio hardware or software may offer only certain media encodings
(e.g. G.711 and G.723.1 but not GSM); and CPU processing power and (e.g. G.711 and G.723.1 but not GSM); and CPU processing power
quality of implementation may constrain the possible video and quality of implementation may constrain the possible video
encoding algorithms. encoding algorithms.
In multiparty multimedia conferences, participants employ different In multiparty multimedia conferences, participants employ different
"components" in conducting the conference. "components" in conducting the conference.
Example: In lecture multicast conferences one component might be Example: In lecture multicast conferences one component might be
the voice transmission for the lecturer, another the transmission the voice transmission for the lecturer, another the transmission
of video pictures showing the lecturer and the third the of video pictures showing the lecturer and the third the
transmission of presentation material. transmission of presentation material.
skipping to change at page 7, line 44 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. audio o A component describes a particular type of interaction (e.g.
conversation, slide presentation) that can be realized by means of audio conversation, slide presentation) that can be realized by
different applications (possibly using different protocols). means of different applications (possibly using different
protocols).
o A configuration is a set of parameters that are required to o A configuration is a set of parameters that are required to
implement a certain variation (realization) of a certain implement a certain variation (realization) of a certain
component. There are actual and potential configurations. component. There are actual and potential configurations.
* Potential configurations describe possible configurations that * Potential configurations describe possible configurations that
are supported by an end-system. are supported by an end-system.
* An actual configuration is an "instantiation" of one of the * An actual configuration is an "instantiation" of one of the
potential configurations, i.e. a decision how to realize a potential configurations, i.e. a decision how to realize a
skipping to change at page 8, line 30 skipping to change at page 8, line 30
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 [9] session announcements on the Mbone, for which SDP In SAP-based [9] session announcements on the Mbone, for which SDP
was originally developed, the negotiation procedure is non-existent. was originally developed, the negotiation procedure is non-existent.
Instead, the announcement contains the media stream description sent Instead, the announcement contains the media stream description sent
out (i.e. the actual configurations) which implicitly describe what a out (i.e. the actual configurations) which implicitly describe what
receiver must understand to participate. a receiver must understand to participate.
In point-to-point scenarios, the negotiation procedure is typically In point-to-point scenarios, the negotiation procedure is typically
carried out implicitly: each party informs the other about what it carried out implicitly: each party informs the other about what it
can receive and the respective sender chooses from this set a can receive and the respective sender chooses from this set a
configuration that it can transmit. configuration that it can transmit.
Capability negotiation must not only work for 2-party conferences but Capability negotiation must not only work for 2-party conferences but
is also required for multi-party conferences. Especially for the is also required for multi-party conferences. Especially for the
latter case it is required that the process to determine the subset latter case it is required that the process to determine the subset
of allowable potential configurations is deterministic to reduce the of allowable potential configurations is deterministic to reduce the
skipping to change at page 9, line 11 skipping to change at page 9, line 11
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). The focus of this Description Protocol - next generation (SDPng). The focus of this
section is on the concepts of the capability description and section is on the concepts of the capability description and
negotiation language with a stepwise introduction of the various negotiation language with a stepwise introduction of the various
syntactical elements. Note that this section does only examples syntactical elements. Note that this section only provides examples
accompanied by explanations -- a full formal specification is accompanied by explanations -- a complete formal specification is
provided in section 4. provided in section 4.
3.1 Conceptual Outline 3.1 Conceptual Outline
The description language follows the system model introduced in the
beginning of this document. We use a rather abstract language to
avoid misinterpretations due to different intuitive understanding of
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
in four separate "sections": in four separate "sections":
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.
skipping to change at page 9, line 50 skipping to change at page 9, line 45
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 that could occur in of elementary entities). Examples of definitions that could occur in
"Definitions" sections include (but are not limited to) codec "Definitions" sections include (but are not limited to) codec
definitions, redundancy schemes, transport mechanisms and payload definitions, redundancy schemes, transport mechanisms and payload
formats. 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 mechanism for overriding definitions is specified
below. below.
For the moment, elementary abstractions are defined for media types For the moment, elementary abstractions are defined for media types
(i.e. codecs) and for media transports mechanisms. For each (i.e. codecs) and for media transport mechanisms. For each
transport and for each codec to be used, the respective attributes transport and for each codec to be used, the respective attributes
need to be defined. This definition may either be provided within need to be defined. This definition may either be provided within
the "Definitions" section itself or in an external document (similar the "Definitions" section itself or in an external document (similar
to the audio-video profile or an IANA registry that defines payload to the audio-video profile or an IANA registry that defines payload
types and media stream identifiers). types and media stream identifiers).
It is not required to define all codecs and transport mechanisms in a It is not required to define all codecs and transport mechanisms in a
"Definitions" sections and reference them when specifying potential "Definitions" sections and reference them when specifying potential
and actual configurations. Instead, a syntactic mechanism is defined and actual configurations. Instead, a syntactic mechanism is defined
that allows to give some definitions directly in a configurations that allows to provide some definitions directly in a 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"/>
skipping to change at page 10, line 46 skipping to change at page 10, line 41
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 codecs 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 existing definitions can be referenced in new The example shows how existing definitions can be referenced in new
definitions. This approach allows to create simple as well as more definitions. This approach allows to create simple as well as more
complex definitions in an extensible set of reference documents. complex definitions in an extensible set of reference documents. The
Section 3.4 specifies the mechanisms for external references. attribute "use" is defined in Section 3.3. Section 3.4 specifies the
mechanisms for external references.
Besides definitions of audio codecs other definitions such as RTP Besides definitions of audio codecs, other definitions such as RTP
payload formats and specific transport mechanisms are suitable to be payload formats and specific transport mechanisms are suitable to be
defined in a definition section for later referencing. The following defined in a definition section for later referencing. The following
example shows how RTP payload types are defined using a pre-defined example shows how RTP payload types are defined using a pre-defined
codec. codec.
<rtp:pt name="rtp-avp-0" pt="0" format="audio-basic"/> <rtp:pt name="rtp-avp-0" pt="0">
<rtp:pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/> <audio:codec ref="audio-basic"/>
</rtp:pt>
<rtp:pt name="rtp-avp-11" pt="11">
<audio:codec ref="audio-L16-mono"/>
</rtp:pt>
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
two modes of operation: explicit and implicit. Implicit
specifications may refer to externally defined entities to minimize
traffic volume, explicit specifications would list all external
definitions used in a description in the "Definitions" section.
Again, see Section 3.4 for complete discussion of external
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 specify the 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 application (IP telephone call, real-time constitute the multimedia application (IP telephone call, real-time
streaming application, multi-player gaming session etc.). For each streaming application, multi-player gaming session etc.). For each
of these components, the potential and, later, the actual of these components, the potential and, later, the actual
skipping to change at page 12, line 14 skipping to change at page 12, line 8
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. In addition, it is also possible to provide definition overwritten. In addition, it is also possible to provide definition
elements inline, inside the definition of a configuration. 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 Configuration as being a Potential or
or an Actual one. The semantics of configurations are to be an Actual one. The semantics of configurations are to be determined
determined from the requirements of the specific protocol that uses from the requirements of the specific protocol that uses SDPng to
SDPng to express capabilities and configurations. 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>
<rtp:pt ref="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>
<rtp:pt ref="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>
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.
skipping to change at page 13, line 8 skipping to change at page 12, line 52
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 directly in the rtp:pt
example illustrates this: element. The following 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"/>
skipping to change at page 13, line 37 skipping to change at page 13, line 32
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 such as Multicast, the usage of multi-unicast, or other parameters such as
QoS parameters. Therefore it is possible to extend the definition of QoS parameters. Therefore it is possible to extend the definition of
transport mechanisms by providing the required information in the transport mechanisms by providing the required information in the
element 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>
<rtp:pt ref="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>
Additional transport mechanisms and options will be defined in future Additional transport mechanisms and options will be defined in future
versions of this document. SDPng profile definition, not in the base specification.
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 resources available, dedicated hardware, etc.) that CPU cycles, DSP resources available, dedicated hardware, etc.) that
limit which of these configurations can be instantiated in parallel limit which of these configurations can be instantiated in parallel
skipping to change at page 14, line 44 skipping to change at page 14, line 40
As the example shows, constraints 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 end-system 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 is used to specify
layer attributes. These attributes largely include those defined by meta information such as session layer attributes. These attributes
SDP [RFC2327] (which are explicitly indicated in the following largely include those defined by SDP [RFC2327] (which are explicitly
specification) to describe originator, purpose, and timing of a indicated in the following specification) to describe originator,
multimedia session among other characteristics. Furthermore, SDPng purpose, and timing of a multimedia session among other
includes attributes indicating the semantics of the various characteristics. Furthermore, SDPng includes attributes indicating
Components in a teleconference or other session. This part of the the semantics of the various Components in a teleconference or other
specification is open ended with an IANA registry to be set up to session.
register further types of components; only a few of the examples are
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. The (SDP "k=" lines) is deliberately not provided for in SDPng. The
relevant information can be specified directly in the Configuration relevant information can be specified directly in the Configuration
section for individual alternatives. section for individual alternatives.
Session level attributes as defined by SDP still have to be examined
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" session-id="session-id" version="version" <owner user="username" session-id="session-id" version="version"
nettype="IN" addrtype="IP4" addr="130.149.25.97"/> nettype="IN" addrtype="IP4" addr="192.168.1.1"/>
The owner element 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 element is not necessarily required. The other protocols, the owner element is not necessarily required. The
attributes listed above match those from the SDP specification; all attributes listed above match those from the SDP specification; all
attributes must be present and they are used following the rules of attributes must be present and they are used following the rules of
RFC2327. RFC2327.
The owner element is an empty element. The owner element is an empty element.
3.1.4.2 Session Identification 3.1.4.2 Session Identification
skipping to change at page 18, line 22 skipping to change at page 18, line 14
SDPng relies on a syntax framework that provides concepts as well as SDPng relies on a syntax framework that provides concepts as well as
concrete procedures for document validation and extending the set of concrete procedures for document validation and extending the set of
allowed syntax elements. allowed syntax elements.
SGML/XML technologies allow for the creation of Document Type SGML/XML technologies allow for the creation of Document Type
Definitions (DTDs) that can define the allowed content models for the Definitions (DTDs) that can define the allowed content models for the
elements of conforming documents. Documents can be formally elements of conforming documents. Documents can be formally
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 by third-party definition packages without creating the
possibility of name collisions.
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 descriptions documents must be possible for applications that process descriptions documents
to distinguish 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 document schemata: XML Namespace and XML Schema.
Schema.
XML Schema mechanisms allows to constrain the allowed document XML Schema mechanisms allow 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.
Extensions of the session description language, say for allowing to Extensions of the session description language, say for allowing to
express the parameters of a new media type, would require the express the parameters of a new media type, would require the
creation of a corresponding XML schema definition that contains the creation of a corresponding XML schema definition that contains the
specification of element types that can be used to describe specification of element types that can be used to describe
configurations of components for the new media type. Session configurations of components for the new media type. Session
description documents have to reference the non-standard Schema description documents have to reference the extension Schema module,
module, thus enabling parsers and validators to identify the elements thus enabling parsers and validators to identify the elements of the
of the new extension module and to either ignore them (if they are new extension module and to either ignore them (if they are not
not supported) or to consider them for processing the supported) or to consider them for processing the session/capability
session/capability description. description.
It is important to note that the functionality of validating It is important to note that the functionality of validating
capability and session description documents is not necessarily capability and session description documents is not necessarily
required to generate or process them. For example, endpoints would required to generate or process them. For example, endpoints would
be configured to understand only those parts of description documents be configured to understand only those parts of description documents
that are conforming to the baseline specification and simply ignore that are conforming to the baseline specification and simply ignore
extensions they cannot support. The usage of XML and XML Schema is extensions they cannot support. The usage of XML and XML Schema is
thus rather motivated by the need to allow for extensions being thus rather motivated by the need to allow for extensions being
defined and added to the language in a structured way that does not defined and added to the language in a structured way that does not
preclude the possibility to have applications to identify and process preclude the possibility to have applications to identify and process
the extensions elements they might support. The baseline the extensions elements they might support. The baseline
specification of XML Schema definitions and profiles must be well- specification of XML Schema definitions and 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 profile Architecture, i.e. transport over RTP/UDP/IP, the audio video
of RFC1890 etc. profile of RFC1890 etc.
Section 3.4 describes profile definitions and library definition. A Section 3.4 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 5. corresponding extension mechanisms is provided in Section 5.
The example below shows how the definition of codecs, transport- The example below is a complete SDPng document. It shows how the
variants and configuration of components as well as a conference definition of codecs, transport-variants and configuration of
description are realized in SDPng. components as well as a conference description are realized in SDPng:
<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"/>
<rtp:pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/> <audio:codec ref="audio-basic"/>
</rtp:pt
<rtp:pt name="rtp-avp-11" pt="11">
<audio:codec ref="audio-L16-mono"/>
</rtp:pt
</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>
<rtp:pt ref="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>
<rtp:pt ref="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>
skipping to change at page 20, line 40 skipping to change at page 20, line 39
<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>
Section 5 specifies the formal Schema definition that this example is Section 5 specifies the formal Schema definition that this example is
conforming to. conforming to.
A real-world capability description would likely be shorter than the
presented example because the codec and transport definitions can be
factored-out to profile definition documents that would only be
referenced in capability description documents.
3.3 Referencing Definitions 3.3 Referencing Definitions
This section specifies some generic mechanisms for referencing This section specifies some generic mechanisms for referencing
existing definitions. Referencing existing definition allows to existing definitions. Referencing existing definitions allows to
contruct definitions without having to include all parameters inline. contruct definitions without having to include all parameters inline.
By using these mechanisms, complex definitions can be derived by By using these mechanisms, complex definitions can be derived by
combining multiple basic mechanisms. Common parameters that occur in combining multiple basic mechanisms. Common parameters that occur in
different configurations do not have to be repeated but can be different configurations do not have to be repeated but can be
defined once and then be referenced as often as they are needed. defined once and then be referenced as often as they are needed.
3.3.1 The sdpng:use Element Type 3.3.1 The attribute "ref"
The element type "sdpng:use" is a generic reference mechanisms that
allows to refer to arbitrary definition within another definition or
configuration element. "sdpng:use" is an element type with one
mandatory attribute called "href". The value of that attribute is
the name of the definition to be referenced. An example:
<def>
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/>
</def>
<cfg>
<c name="interactive-audio" media="audio">
<alt name="alt-avp-audio-10">
<rtp:session format="rtp-avp-10">
<use href="endpoint-addr-1"/>
</rtp:session>
</alt>
</c>
<cfg>
In this example, an element "rtp:udp" is used in the definitions
section to define some transport parameters that should later be re-
used by referencing this definition using the specified name
"endpoint-addr-1". Within the element "rtp:session" in the
configurations section the definition is referenced using the "use"
element.
An implementation that processes this SDPng document and wants to
evaluate the configuration for the alternative "rtp-avp-10" MUST
replace the "use" element by the referenced element. If the
referenced element contains "use" elements itself, those MUST also be
dereferenced.
When applying this algorithm to the sample SDPng document, the The attribute "ref" is a generic reference mechanism that is used in
following result SDPng document is generated: referencing elements to reference an existing element of the same
element type. An example:
<def> <def>
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/> <rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/>
</def> </def>
<cfg> <cfg>
<c name="interactive-audio" media="audio"> <component name="interactive-audio" media="audio">
<alt name="alt-avp-audio-10"> <alt name="alt-avp-audio-10">
<rtp:session format="rtp-avp-10"> <rtp:session>
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/> <rtp:udp ref="endpoint-addr-1"/>
</rtp:session>
</alt>
</c>
<cfg>
For the purpose of comparing configurations, both SDPng documents are
equal.
3.3.2 Properties
The element type "sdpng:prop" can be used to add properties to
definitions. "sdpng:prop" has two attributes:
name: the name of the property
value: the value for the named property
For example:
<def>
<audio:codec name="g722" encoding="G722" channels="1" sampling="16000"/>
<rtp:pt name="rtp-avp-9" pt="9" format="g722"/>
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/>
</def>
<cfg>
<c name="interactive-audio" media="audio">
<alt name="alt-avp-audio-9-4">
<rtp:session format="rtp-avp-9">
<use href="endpoint-addr-1"/>
</rtp:session>
<prop name="foo" value="bar"/>
</alt>
</c>
<cfg>
For comparing and collapsing elements, all sdpng:prop element that
are contained in a parent element (like alt in the example above)
MUST be transformed to attributes of the containing element. If the
parent element already provides a corresponding attribute its value
MUST be overwritten.
The example above would thus be transformed to:
<def>
<audio:codec name="g722" encoding="G722" channels="1" sampling="16000"/>
<rtp:pt name="rtp-avp-9" pt="9" format="g722"/>
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/>
</def>
<cfg>
<c name="interactive-audio" media="audio">
<alt name="alt-avp-audio-9-4" foo="bar">
<rtp:session format="rtp-avp-9">
<use href="endpoint-addr-1"/>
</rtp:session>
</alt>
</c>
<cfg>
The main purpose of the sdpng:prop element type is to provide a
mechanism by which attributes of referenced elements can be modified
by the referring element. An application for this is described in
Section 3.3.4.
3.3.3 Definition Groups
Using the sdpng:group element arbitrary definition can be combined
and defined as a group with a specific name. Using this name, the
definitions contained in the group can be referenced with the
sdpng:use element and embedded into other elements.
An example for the use of the sdpng:group element:
<def>
<audio:codec name="g722" encoding="G722" channels="1" sampling="16000"/>
<rtp:pt name="rtp-avp-9" pt="9" format="g722"/>
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/>
<group name="g1">
<prop name="foo" value="bar"/>
<prop name="xyz" value="uvw"/>
</group>
</def>
<cfg>
<c name="interactive-audio" media="audio">
<alt name="alt-avp-audio-9-4">
<rtp:session format="rtp-avp-9">
<use href="endpoint-addr-1"/>
</rtp:session>
<use href="g1"/>
</alt>
</c>
<cfg>
This example shows how a group that has been defined in the
definitions section is referenced using the sdpng:use element. The
group element contains two sdpng:prop elements.
For comparing and collapsing elements, all references to sdpng:group
element MUST be replaced by the content of the corresponding
sdpng:group element. The example above would thus be transformed to:
<def>
<audio:codec name="g722" encoding="G722" channels="1" sampling="16000"/>
<rtp:pt name="rtp-avp-9" pt="9" format="g722"/>
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/>
<group name="g1">
<prop name="foo" value="bar"/>
<prop name="xyz" value="uvw"/>
</group>
</def>
<cfg>
<c name="interactive-audio" media="audio">
<alt name="alt-avp-audio-9-4">
<rtp:session format="rtp-avp-9">
<use href="endpoint-addr-1"/>
</rtp:session>
<prop name="foo" value="bar"/>
<prop name="xyz" value="uvw"/>
</alt>
</c>
<cfg>
In this example the content of the sdpng:group element named g1 has
been embedded into the alt element that contained the sdpng:use
element referencing the group element.
According to the rules in Section 3.3.2 the sdpng:prop elements are
transformed in a second step to yield the following final decription:
<def>
<audio:codec name="g722" encoding="G722" channels="1" sampling="16000"/>
<rtp:pt name="rtp-avp-9" pt="9" format="g722"/>
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/>
<group name="g1">
<prop name="foo" value="bar"/>
<prop name="xyz" value="uvw"/>
</group>
</def>
<cfg>
<c name="interactive-audio" media="audio">
<alt name="alt-avp-audio-9-4" foo="bar" xyz="uvw">
<rtp:session format="rtp-avp-9">
<use href="endpoint-addr-1"/>
</rtp:session> </rtp:session>
</alt> </alt>
</c> </component>
<cfg> <cfg>
As a general rule, all references MUST be resolved before sdpng:prop In this example, an element of the type "rtp:udp" is specified in the
elements are processed and transformed into attribute values. definitions section of an SDPng document that is named "endpoint-
addr-1" in its "name" attribute. The element is referenced in the
3.3.4 Usage of Child Elements and Attributes of sdpng:use Elements definition of the alternative "alt-avp-audio-10", within the
"rtp:session" element. The "rtp:session" provides an child element
It is also possible to provide arbitrary other elements within a "rtp:udp" that does not provide content or attributes on its own.
sdpng:use element (depending on the specific application). All Instead, it references the "rtp:udp" element named "endpoint-addr-1"
elements that occur in a sdpng:use element MUST be transfomed to by using this identifier in its "ref" attribute.
child elements of the referenced element when resolving a sdpng:use
reference. If the reference already provides child elements, the
child elements of the sdpng:use element are added to the list of
child elements of the referenced element.
Any existing elements of a referenced element with the same GI as an
element in the corresponding sdpng:use element MUST be replaced by
the element of the sdpng:use element. This mechanism allows to
extend and to change referenced elements in a simple way.
In the following we give an example of using an sdpng:prop element
within a sdpng:use element which has the semantics of adding
properties to the referenced element. The semantics and processing
requirements for the sdpng:prop element are specified in Section
3.3.2.
Example for the usage of an sdpng:use element containing an
sdpng:prop element:
<def> The requirements for implementation concerning the processing of the
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/> "ref" attribute are as follows:
</def>
<cfg>
<c name="interactive-audio" media="audio">
<alt name="alt-avp-audio-10">
<rtp:session format="rtp-avp-10">
<use href="endpoint-addr-1">
<prop name="foo" value="bar"/>
</use>
</rtp:session>
</alt>
</c>
<cfg>
This will be transformed to: 1. The parsing application MUST try to locate an element of the
element type as the referencing element.
<def> 2. If such an element is found, the attributes of the referencing
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/> element MUST be augmented with the attributes of the referenced
</def> element. Only those attributes that are not specified by the
<cfg> referencing element MUST be considered.
<c name="interactive-audio" media="audio">
<alt name="alt-avp-audio-10">
<rtp:session format="rtp-avp-10">
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53">
<prop name="foo" value="bar"/>
</rtp:udp>
</rtp:session>
</alt>
</c>
<cfg>
In a second step, the sdpng:prop element would be transformed to an 3. The content of referenced element, i.e., child elements or
attribute of its parent element (rtp:udp in this case) according to character content, MUST be added to the content of the
the rules specified in Section 3.3.2. referencing element. The content of the referenced element MUST
be added before the content of the referencing element. For
example, if a referenced element A provides the child elements a1
and a2, and a referencing element B provides the child elements
b1 and b2, the resulting content will consists of the following
child elements in this order; a1,a2,b1,b2. The semantics of the
resulting content are completely application dependent, i.e., an
profile SHOULD specify corresponding content models and define
the semantics, for example for multiple occurenced of an element
of a certain type.
As an abbreviation, the properties for the referenced element do not The following example provides an example of an reference to an
have to be specified using sdpng:prop elements within the sdpng:use existing element by an refering element that overwrites an attribute
element but can also specified directly as attributes of the of the referenced element.
sdpng:use element, as shown in the following example:
<def> <def>
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/> <rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/>
</def> </def>
<cfg> <cfg>
<c name="interactive-audio" media="audio"> <component name="interactive-audio" media="audio">
<alt name="alt-avp-audio-10"> <alt name="alt-avp-audio-10">
<rtp:session format="rtp-avp-10"> <rtp:session>
<use href="endpoint-addr-1" name="foo" value="bar"/> <rtp:udp ref="endpoint-addr-1" rtp-port="8000"/>
</rtp:session> </rtp:session>
</alt> </alt>
</c> </component>
<cfg> <cfg>
In this example, the sdp:use element has no child element sdpng:prop Open Issue: Should overwriting of child elements be allowed as well?
but provides the property "foo" directly as an attribute. All
attributes of a sdpng:use element other than href MUST be transformed
to attributes of the referenced elements.
If the referenced element is a definition group (see Section 3.3.3),
any child elements of an sdpng:use element MUST be transformed to
child elements of the parent element of the sdpng:use element. Any
properties (either explicit sdpng:prop elements or attributes of the
sdpng:use element) MUST be transformed to properties of the parent
element of the sdpng:use element.
3.4 External Definition Packages 3.4 External Definition Packages
There are two types of external definitions: There are two types of external definitions:
Profile Definitions (Section 3.4.1) define rules for specifying Profile Definitions (Section 3.4.1) define rules for specifying
parameters that are not covered by the base SDPng specification. parameters that are not covered by the base SDPng specification.
Library Definitions (Section 3.4.2) contain definitions that can be Library Definitions (Section 3.4.2) contain definitions that can be
referenced in SDPng documents. referenced in SDPng documents.
skipping to change at page 29, line 7 skipping to change at page 23, line 7
For example, if some application requires the use of a new transport For example, if some application requires the use of a new transport
protocol, endpoints must be able to describe their configuration with protocol, endpoints must be able to describe their configuration with
respect to the parameters of that transport protocol. The mandatory respect to the parameters of that transport protocol. The mandatory
and optional parameters that can be configured and negotiated when and optional parameters that can be configured and negotiated when
using the transport protocol will be specified in a definition using the transport protocol will be specified in a definition
document. Such a definition document is called a "profile". document. Such a definition document is called a "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 end-system 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 specific 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 specific
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 an SDPng (This would be done in the "Definitions" section of an SDPng
document.) An SDPng document that references a profile and provides document.) An SDPng document that references a profile and provides
concrete definitions of configurations can be validated against the specific definitions of configurations can be validated against the
profile definition. profile definition.
3.4.2 Library Definitions 3.4.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 "Definitions" sections refer to profile definitions profile, SDPng "Definitions" sections refer to profile definitions
and 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,
"SDPng libraries" may be defined and referenced in SDPng documents. "SDPng libraries" may be defined and referenced in SDPng documents.
skipping to change at page 30, line 50 skipping to change at page 24, line 50
o Because of these problematic properties of external libraries, the o Because of these problematic properties of external libraries, the
final SDPng specification will have to provide a set of final SDPng specification will have to provide a set of
recommendations under which circumstances the different mechanisms recommendations under which circumstances the different mechanisms
of referring to external definitions should be used. of referring to external definitions should be used.
3.5 Mappings 3.5 Mappings
A mapping needs to be defined in particular to SDP that allows to A mapping needs to be defined in particular to SDP that allows to
translate final session descriptions (i.e. the result of capability translate final session descriptions (i.e. the result of capability
negotiation processes) to SDP documents. In principle, this can be negotiation processes) to SDP documents. In principle, this can be
done in a rather schematic fashion for the basic definitions. done in a rather schematic fashion for the base specification and a
set of basic profiles.
In addition, mappings to H.245 will be defined in order to support In addition, mappings to H.245 will be defined in order to support
applications like SIP-H.323 gateways. applications like SIP-H.323 gateways.
4. Capability Negotiation 4. Capability Negotiation
SDPng is a description language for both potential configurations SDPng is a description language for both potential configurations
(i.e. capabilities) of participants in multimedia conferencers and (i.e. capabilities) of participants in multimedia conferencers and
for actual configurations (i.e. final specifications of parameters). for actual configurations (i.e. final specifications of parameters).
Capability negotiation is the process of generating a usable set of Capability negotiation is the process of generating a usable set of
skipping to change at page 32, line 35 skipping to change at page 26, line 35
The description language and the rules for the negotiation phase that The description language and the rules for the negotiation phase that
are defined here are (in general) independent of the means by which are defined here are (in general) independent of the means by which
descriptions are conveyed during a negotiation phase (a reliable descriptions are conveyed during a negotiation phase (a reliable
transport service with causal ordering is assumed). There are transport service with causal ordering is assumed). There are
however properties and requirements of call signalling protocols that however properties and requirements of call signalling protocols that
have been considered to allow for a seamless integration of the have been considered to allow for a seamless integration of the
negotiation into the call setup process. For example, in order to be negotiation into the call setup process. For example, in order to be
usable with SIP, it must be possible to negotiate the conference usable with SIP, it must be possible to negotiate the conference
configuration within the three-way-handshake of the call setup phase. configuration within the three-way-handshake of the call setup phase.
In order to use SDPng instead of SDP according to the offer/answer In order to use SDPng instead of SDP according to the offer/answer
model defined in [15] it must be able to determine an actual model defined in [16] it must be possible to determine an actual
configuration in a single request/response cycle. configuration in a single request/response cycle.
4.1 Outline of the Negotiation Process 4.1 Outline of the Negotiation Process
Conceptually, the negotiation process comprises the following Conceptually, the negotiation process comprises the following
individual steps (considering two parties, A and B, where A tries to individual steps (considering two parties, A and B, where A tries to
invite B to a conference). Please note that is describes the steps invite B to a conference). Please note that this describes the steps
of the negotiation process conceptually -- it does not specify of the negotiation process conceptually -- it does not specify
requirements for implementations. Specific procedures that MUST be requirements for implementations. Specific procedures that MUST be
followed by implementations are given below. followed by implementations are given below.
1. A determines its potential configurations for the components that 1. A determines its potential configurations for the components that
should be used in the conference (e.g. "interactive audio" and should be used in the conference (e.g. "interactive audio" and
"shared whiteboard") and sends a corresponding SDPng instance to "shared whiteboard") and sends a corresponding SDPng instance to
B. This SDPng instances is denoted "CAP(A)". B. This SDPng instances is denoted "CAP(A)".
2. B receives A's SDPng instance and analyzes the set of components 2. B receives A's SDPng instance and analyzes the set of components
skipping to change at page 33, line 15 skipping to change at page 27, line 15
wishes to support it generates a list of potential configurations wishes to support it generates a list of potential configurations
corresponding to B's capabilities, denoted "CAP(B)". corresponding to B's capabilities, denoted "CAP(B)".
3. B applies the collapsing function and obtains a list of potential 3. B applies the collapsing function and obtains a list of potential
configurations that both A and B can support, denoted configurations that both A and B can support, denoted
"CAP(A)xCAP(B) = CAP(AB)". "CAP(A)xCAP(B) = CAP(AB)".
4. B sends CAP(B) to A. 4. B sends CAP(B) to A.
5. A also applies the collapsing function and obtains "CAP(AB)". At 5. A also applies the collapsing function and obtains "CAP(AB)". At
this step, both A and B know each other capabilities and the this step, both A and B know the capabilities of each other and
potential configurations that both can support. the potential configurations that both can support.
6. In order to obtain an actual configuration from the potential 6. In order to obtain an actual configuration from the potential
configuration that have been obtained, both particpants have to configuration that has been obtained, both particpants have to
pick a subset of the potential configurations should actually be pick a subset of the potential configurations that should
used in the conference and generate the actual configuration. It actually be used in the conference and generate the actual
should be noted that it depends on the specific application configuration. It should be noted that it depends on the
whether each component must be assigned exactly one actual specific application whether each component must be assigned
configuration (one sdpng:alt element) or whether it is allowed to exactly one actual configuration (one sdpng:alt element) or
list multiple actual configurations. In this model we assume whether it is allowed to list multiple actual configurations. In
that A selects the actual configuration, denoted CFG(AB). this model we assume that A selects the actual configuration,
denoted CFG(AB).
7. A augments CFG(AB) with the transport parameters it intends to 7. A augments CFG(AB) with the transport parameters it intends to
use, e.g., on which endpoint addresses A wishes to receive data, use, e.g., on which endpoint addresses A wishes to receive data,
obtaining CFG_T(A). A sends CFG_T(A) to A. obtaining CFG_T(A). A sends CFG_T(A) to A.
8. B receives CFG_T(A) and adds its own transport parameters, 8. B receives CFG_T(A) and adds its own transport parameters,
resulting in CFG_T(AB). CFG_T(AB) contains the selected actual resulting in CFG_T(AB). CFG_T(AB) contains the selected actual
configurations and the transport parameters of both A and B (plus configurations and the transport parameters of both A and B (plus
any other SDPng data, e.g., meta-information on the conference). any other SDPng data, e.g., meta-information on the conference).
CFG_T(AB) is the complete conference description. Both A and B CFG_T(AB) is the complete conference description. Both A and B
skipping to change at page 34, line 17 skipping to change at page 28, line 19
information like transport parameters. information like transport parameters.
Note that the model presented here results in four SDPng exchanges. Note that the model presented here results in four SDPng exchanges.
As an optimization, this procedure can be abbreviated to two As an optimization, this procedure can be abbreviated to two
exchanges by including the transport (and other) parameters into the exchanges by including the transport (and other) parameters into the
potential configurations. A embeds its desired transport parameters potential configurations. A embeds its desired transport parameters
into the list of potential configurations and B also sends all into the list of potential configurations and B also sends all
required parameters in the response together with B's potential required parameters in the response together with B's potential
configurations. Both A and B can then derive CFG_T(AB). Transport configurations. Both A and B can then derive CFG_T(AB). Transport
parameters are usually not negotiable, therefor they have to be parameters are usually not negotiable, therefor they have to be
distingiushed them from other configuration information. distingiushed from other configuration information.
Specific procedures for re-negotiation and multi-party negotiation Specific procedures for re-negotiation and multi-party negotiation
will be defined in a future version of this document. will be defined in a future version of this document.
4.2 The Collapsing Algorithm 4.2 The Collapsing Algorithm
The following procedure MUST be used for the collapsing of two SDPng The following procedure MUST be used for the collapsing of two SDPng
document instances into one: document instances into one:
CAP(A) and CAP(B) are the two SDPng description document instances. CAP(A) and CAP(B) are the two SDPng description document instances.
skipping to change at page 36, line 9 skipping to change at page 30, line 9
4.2.1.1 Collapsing of Attributes 4.2.1.1 Collapsing of Attributes
In SDPng, capabilities are specified in attributs of XML elements. In SDPng, capabilities are specified in attributs of XML elements.
Three different types of capabilities with different collapsing rules Three different types of capabilities with different collapsing rules
are defined. The type of a capability is encoded in the attribute are defined. The type of a capability is encoded in the attribute
value. value.
Set of symbols: Set of symbols:
An attribute can specify a set of symbols. When two attributes An attribute can specify a set of symbols. When two attributes
are collapsed the result is the intersection of the two sets. are collapsed, the result is the intersection of the two sets.
The following examples shows how two elements (with one attribute The following examples shows how two elements (with one attribute
representing a set of symbols) originated from two capability representing a set of symbols) originated from two capability
descriptions from participants A and B are collapsed: descriptions from participants A and B are collapsed:
Element x in A's capability description: Element x in A's capability description:
<x a="[FOO, BAR, 3, 5, 8]"/> <x a="[FOO, BAR, 3, 5, 8]"/>
Element x in B's capability description: Element x in B's capability description:
<x a="[3, 6, 8]"/> <x a="[3, 6, 8]"/>
skipping to change at page 37, line 13 skipping to change at page 31, line 13
A numerical range is represented by a tuple of comma-separated A numerical range is represented by a tuple of comma-separated
numbers in brackets. The first number represents the lower bound numbers in brackets. The first number represents the lower bound
of the range and the second number represents the upper bound. of the range and the second number represents the upper bound.
Let MIN(a,b) be a function that returns the minimum of a and b and Let MIN(a,b) be a function that returns the minimum of a and b and
MAX(a,b) be a function that returns the maximum of a and b. Given MAX(a,b) be a function that returns the maximum of a and b. Given
two ranges (minA, maxA) and (minB, maxB), the collapsed new range two ranges (minA, maxA) and (minB, maxB), the collapsed new range
MUST be calculated using this algorithm: MUST be calculated using this algorithm:
(MAX(minA, minB), MIN(maxA, maxB)) (MAX(minA, minB), MIN(maxA, maxB))
If this process results in a range with a smaller first value, If this process results in a range with a smaller second value,
the range is invalid and the collapsing has failed since there is the range is invalid and the collapsing has failed since there is
no common range. If the collapsing of one of an element's no common range. If the collapsing of one of an element's
attributes with the type "numerical range" has failed, the attributes with the type "numerical range" has failed, the
collapsing process of the element itself MUST be considered to collapsing process of the element itself MUST be considered to
have failed as well. have failed as well.
Optional parameters: Optional parameters:
A failure of collapsing attributes of the types "set of symbols" A failure of collapsing attributes of the types "set of symbols"
and "numerical range" results in a failure of collapsing the and "numerical range" results in a failure of collapsing the
corresponding element. There is a third type named "optional corresponding element. There is a third type named "optional
skipping to change at page 39, line 12 skipping to change at page 33, line 12
Result: Result:
<x a="[3, 8]" b="(5,8)"/> <x a="[3, 8]" b="(5,8)"/>
4.2.1.3 Collapsing nested Elements 4.2.1.3 Collapsing nested Elements
In order to collapse nested elements the following algorithm MUST be In order to collapse nested elements the following algorithm MUST be
applied: applied:
In analogy to attributes representing optional parameters there is In analogy to attributes representing optional parameters there is
also the possibility to mark elements as optional for the negotiation also the possibility to mark elements as optional for the negotiation
process. Elements MAY provide an attribute names "status" that process. Elements MAY provide an attribute named "status" that
contains a symbol or a comma-separated list of symbols as its value. contains a symbol or a comma-separated list of symbols as its value.
If the value "opt" occurs in the list of a "status" attribute of both If the value "opt" occurs in the list of a "status" attribute of both
elements to be collapsed, the elements to be collapsed are treated as elements to be collapsed, the elements to be collapsed MUST be
optional. This means, if the collapsing of the attributes has failed treated as optional. This means, if the collapsing of the attributes
(according to the rules specified in Section 4.2.1.2), the collapsing has failed (according to the rules specified in Section 4.2.1.2), the
process does not yield a result element but is still treated as collapsing process MUST NOT not yield a result element but MUST still
"successful", i.e., further collapsing operation on other elements be treated as "successful", i.e., further collapsing operation on
can continue. The semantics of optional elements are that they other elements can continue. The semantics of optional elements are
describe optional features that may be supported and selected during that they describe optional features that may be supported and
a negotiation phase but do not neccessarily have to be supported by selected during a negotiation phase but do not neccessarily have to
all participants in order to achieve interoperability. The example be supported by all participants in order to achieve
below shows how to generate a result element in the presence of interoperability. The example below shows how to generate a result
optional child elements that have failed to collapse. element in the presence of optional child elements that have failed
to collapse.
The collapsing algorithm for nested elements: The collapsing algorithm for nested elements:
1. Let x be an element that occurs in the capability description of 1. Let x be an element that occurs in the capability description of
two participants A and B and that should be collapsed. two participants A and B and that should be collapsed.
2. Collapse the attributes of the element x using the algorithm 2. Collapse the attributes of the element x using the algorithm
specified in Section 4.2.1.2. If the collapsing has failed specified in Section 4.2.1.2. If the collapsing has failed
according to the rules of Section 4.2.1.2 and if the elements to according to the rules of Section 4.2.1.2 and if the elements to
be collapsed are not marked as optional, the collapsing of the be collapsed are not marked as optional, the collapsing of the
skipping to change at page 42, line 16 skipping to change at page 36, line 16
This section defines the SDPng syntax and the use of XML mechanisms, This section defines the SDPng syntax and the use of XML mechanisms,
such as XML Namespace and XML Schema. Section 5.1 defines the such as XML Namespace and XML Schema. Section 5.1 defines the
relation between SDPng and XML Schema, Section 5.2 specifies general relation between SDPng and XML Schema, Section 5.2 specifies general
requirements for documents and profile definitions that are requirements for documents and profile definitions that are
conforming to the SDPng schema, Section 5.3 list requirements for conforming to the SDPng schema, Section 5.3 list requirements for
profile definitions, Section 5.4 specifies specific requirements for profile definitions, Section 5.4 specifies specific requirements for
conforming documents and Section 5.5 lists requirements for the conforming documents and Section 5.5 lists requirements for the
definition of SDPng libraries. definition of SDPng libraries.
Section 5.7 defines the SDPng base schema, Section 5.7.2 defines the Section 5.7 defines the SDPng base schema, Appendix A.1 defines the
profile for audio codec definitions and Section 5.7.3 defines the profile for audio codec definitions and Appendix B defines the
profile for RTP payload type definitions. profile for RTP payload type definitions.
5.1 XML Schema as a Definition Mechanism 5.1 XML Schema as a Definition Mechanism
SDPng documents 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
definition) and a library of commonly used definitions.
SDPng uses XML-Schema [13][14] 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
existing definitions allowing to uniquely identify element types existing definitions allowing to uniquely identify element types
(by relying on XML namespaces [11]). (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 MUST be schema instances of the SDPng schema as SDPng documents MUST be schema instances of the SDPng schema as
defined in Section 5.7. The following example shows how a Schema defined in Section 5.7. The following example shows how a Schema
definition can be referenced in 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="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 is defined for referencing a schema definition. A SDPng namespace is defined for
this purpose. The name of this namespace is this purpose. The name of this namespace is
"http://www.iana.org/sdpng". A well-known namespace prefix is used "http://www.iana.org/sdpng". SDPng documents MUST use this namespace
for the SDPng schema definition, in order to allow for very simple as their default namespace.
implementations. The well-known SDPng namespace prefix is "sdpng".
Conforming Documents, profile definition and libraries MUST use this
namespace name and this namespace prefix.
For SDPng documents, this initial declaration can be added implicitly For SDPng documents, this initial declaration can be added implicitly
by applications, so that declarations like the one above do not have by applications, so that declarations like the one above do not have
to be included in every description document. Details are to be to be included in every description document. Details are to be
defined in a later version of this document. defined in a later version of this document.
5.2 SDPng Schema 5.2 SDPng Schema
The basic SDPng schema definitions specifies the general document The basic SDPng schema definitions specifies the general document
structures, e.g., one "Definitions" section followed by one structures, e.g., one "Definitions" section followed by one
skipping to change at page 44, line 5 skipping to change at page 37, line 44
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 name="name" type="xsd:string"/>
</xsd:complexType> </xsd:complexType>
Profiles can then define specific 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 specific 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 facilitates the extension of validation of profile definitions and facilitates the extension of
SDPng. SDPng.
5.3 Profiles 5.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.
skipping to change at page 45, line 33 skipping to change at page 39, line 33
with a namespace prefix, for example as in: "audio:codec". with a namespace prefix, for example as in: "audio:codec".
5.4 SDPng Documents 5.4 SDPng Documents
SDPng documents MUST reference the employed profiles and provide SDPng documents MUST reference the employed profiles and provide
namespace prefixes for the namespace names of the profiles as shown namespace prefixes for the namespace names of the profiles as shown
in the following example. in the following example.
Example: Example:
<sdpng:desc xmlns:sdpng="http://www.iana.org/sdpng" <sdpng:desc xmlns="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">
For well-known registered profiles, the namespace name AND the used For well-known registered profiles, the namespace name AND the used
namespace prefix SHOULD be registered to allow for simple basic namespace prefix SHOULD be registered to allow for simple 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
(see Section 5.6.3). There is one issue with declaring used XML- (see Section 5.6.3). There is one issue with declaring used XML-
Schema definitions in documents (see Section 7 below). Schema definitions in documents (see Section 6 below).
The general structure of an SDPng documents MUST conform to the basic The general structure of an SDPng documents MUST conform to the basic
SDPng schema definition and MAY provide a "def" element for SDPng schema definition and MAY provide a "def" element for
definitions; it MUST provide a "cfg" element for the configuration definitions; it MUST provide a "cfg" element for the configuration
section; it MAY provide a "constraints" and a "conf" element. section; it MAY provide a "constraints" and a "conf" element.
Example: 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"
sampling="8000"/> sampling="8000"/>
<rtp:pt name="rtp-avp-18" pt="18" format="g729"/> <rtp:pt name="rtp-avp-18" pt="18">
<audio:codec ref="g729"/>
</rtp:pt
</def> </def>
It can be seen how the attribute name (provided by the base type for It can be seen how the attribute name (provided by the base type for
definition elements) and the profile specific attributes "encoding", definition elements) and the profile specific attributes "encoding",
"channels" and "sampling" are used together. "channels" and "sampling" are used together.
The element "rtp:pt" is used to defined a payload type. "rtp:pt" The element "rtp:pt" is used to defined a payload type. "rtp:pt"
would have been defined in another profile, again using a type would have been defined in another profile, again using a type
derived from the base definition type. "rtp:pt" provides attribute derived from the base definition type. "rtp:pt" provides attribute
for referencing other definitions, e.g., the definition of audio- for referencing other definitions, e.g., the definition of audio-
skipping to change at page 47, line 6 skipping to change at page 41, line 8
infosets are "merged" together, enabling applications to operate on infosets are "merged" together, enabling applications to operate on
the resulting infosets as if it had been generated by parsing a the resulting infosets as if it had been generated by parsing a
single, monolithic 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
resolved by applications. For XML, this would probably mean to use
an XLink-based approach. This solution would require the definition
of an SDPng link element type and require applications to support
XLink (or at least the SDPng-relevant subset thereof). The inclusion
at the application level is however problematic, because it does not
result in a common integrated XML document infoset but would require
applications to handle multiple infosets, i.e. multiple documents.
5.6 Details on the use of specific XML Mechanisms 5.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.
5.6.1 Default Namespace 5.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". That means, the general SDPng "http://www.iana.org/sdpng" as their default namespace. That means,
identifiers can be used without namespace prefixes. the general SDPng identifiers can be used without namespace prefixes.
5.6.2 Qualified Locals 5.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 for so- attribute names in Schema definitions and document instances for so-
called "local definitions" (this is the default setting). "Local called "local definitions" (this is the default setting). "Local
Definitions" are contained within "global definitions" in an XML Definitions" are contained within "global definitions" in an XML
schema definition. In order to simplify parsing and processing of schema definition. In order to simplify parsing and processing of
SDPng document instances, all elements MUST be fully qualified. SDPng document instances, all elements MUST be fully qualified.
skipping to change at page 48, line 10 skipping to change at page 41, line 51
o attributeFormDefault="unqualified" o attributeFormDefault="unqualified"
This means that attribute names do not have to be fully qualified. This means that attribute names do not have to be fully qualified.
Implementations MUST infer the namespace for attributes from the Implementations MUST infer the namespace for attributes from the
namespace of the element that the attribute belongs to. Note that namespace of the element that the attribute belongs to. Note that
the specification of XML Namespaces [11] defines that default the specification of XML Namespaces [11] defines that default
namespaces do not apply to attributes. In profile definitions, namespaces do not apply to attributes. In profile definitions,
all attributes MUST be defined locally. The same holds for the all attributes MUST be defined locally. The same holds for the
base SDPng schema. base SDPng schema.
These rules make SDPng document instances process-able by non-Schema- These rules make SDPng document instances processable 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").
5.6.3 Fixed Namespace Prefixes 5.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 used namespaces names are associated with fixed few commonly used namespace names are associated with fixed prefixes,
prefixes, i.e. document instances and libraries MUST always use these i.e. document instances and libraries MUST always use these
prefixes. These prefixes MUST NOT be used for namespaces names than prefixes. These prefixes MUST NOT be used for namespaces names than
the ones that are assigned to them. In order to ensure the the ones that are assigned to them. In order to ensure the
uniqueness of namespace prefixes, namespace prefixes will be have to uniqueness of namespace prefixes, namespace prefixes will be have to
registered together with the corresponding namespace names. registered together with the corresponding namespace names.
The namespace prefix for the SDPng namespace is "sdpng". The namespace prefix for the SDPng namespace is "sdpng".
5.7 SDPng Schema Definitions 5.7 SDPng Schema Definitions
This section provides the definition of the base SDPng XML Schema. This section provides the definition of the base SDPng XML Schema.
1. Section 5.7.1 contains the base definition that provides the 1. Section 5.7.1 contains the base definition that provides the
general element types for SDPng. general element types for SDPng.
2. Section 5.7.2 contains a profile for audio codecs. 2. Appendix A.1 contains a profile for audio codecs.
3. Section 5.7.3 contains a profile for RTP payload type 3. Appendix B contains a profile for RTP payload type definitions.
definitions.
5.7.1 SDPng Base Definition 5.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", "constraints" 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.
skipping to change at page 49, line 17 skipping to change at page 43, line 9
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 substitutes 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 that provides new definition element types, For an extension profile that provides new definition element types,
e.g. for codec definitions, a new complexType would be defined that e.g. for codec definitions, a new complexType would be defined that
extends sdpng:Definition (see below). An element type definition extends sdpng:Definition (see below). An element type definition
that assigns that new type must then be declared to be in the that assigns that new type must then be declared to be in the
substitutionGroup "sdpng:d". substitutionGroup "sdpng:definition".
This mechanism allows common rules for attributes and content models This mechanism allows common rules for attributes and content models
to be defined in base element definition and re-used by extension to be defined in base element definition and re-used by extension
profiles and it also allows validating parsers to identify the profiles and it also allows validating parsers to identify the
correct type of elements that have been defined by profile correct type of elements that have been defined by profile
definitions. definitions.
The SDPng Base Definition: 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"
xmlns:xlink="http://www.w3.org/1999/xlink"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xsd:import namespace="http://www.w3.org/1999/xlink"
schemaLocation="xlink.xsd"/>
<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 that provides new definition element For an extension-profile that provides new definition element
types, e.g. for codec definitions, a new complexType would be types, e.g. for codec definitions, a new complexType would 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:definition".
</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 50, line 29 skipping to change at page 44, line 27
</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:definition" 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:component" 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:constraint" 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="definition" 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="component" type="sdpng:Component">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
Placeholder base element for a configuration element in the The configuration element in the configurations section.
configurations section. To be derived from by specific
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="constraint" 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. The attribute 'name' MUST be used for
specifying a name in a definiton. The attribute 'ref' MUST be
used for referencing a previously defined definition.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="name" type="xsd:string" use="optional"/>
<xsd:attribute name="ref" type="xsd:string" use="optional"/>
</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>
skipping to change at page 52, line 40 skipping to change at page 46, line 38
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:alt" minOccurs="1" maxOccurs="unbounded"/> <xsd:element ref="sdpng:alt" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="name" type="xsd:string"/>
<xsd:attribute name="media" type="xsd:string"/> <xsd:attribute name="media" type="xsd:string"/>
</xsd:complexType> </xsd:complexType>
<xsd:element name="alt"> <xsd:element name="alt">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
Each alternative consists of a "sc" (session configuration) Each alternative consists of a "sessionConfig" (session
element. The "sc" element is a base element of base type configuration) element. The "sessionConfig" element is a base
"sdpng:Session" that is used to derive specific session types element of base type "sdpng:Session" that is used to derive
in extension profiles. specific session types in extension profiles.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:complexType mixed="false"> <xsd:complexType mixed="false">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:sc" minOccurs="1" maxOccurs="1"/> <xsd:element ref="sdpng:sessionConfig" minOccurs="1" maxOccurs="1"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="name" type="xsd:string"/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<xsd:element name="sc" type="sdpng:SessionConfig"/> <xsd:element name="sessionConfig" type="sdpng:SessionConfig"/>
<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>
skipping to change at page 54, line 44 skipping to change at page 48, line 44
<!-- 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:complexType name="SimpleLink" mixed="false">
<xsd:attribute name="xlink:type" type="xsd:string" fixed="simple"/> <xsd:attribute ref="xlink:type" fixed="simple"/>
<xsd:attribute name="xlink:role" type="xsd:string"/> <xsd:attribute ref="xlink:role"/>
<xsd:attribute name="xlink:arcrole" type="xsd:string"/> <xsd:attribute ref="xlink:arcrole"/>
<xsd:attribute name="xlink:title" type="xsd:string"/> <xsd:attribute ref="xlink:title"/>
<xsd:attribute name="xlink:show" type="xsd:string" fixed="none"/> <xsd:attribute ref="xlink:show" fixed="none"/>
<xsd:attribute name="xlink:actuate" type="xsd:string" fixed="none"/> <xsd:attribute ref="xlink:actuate" fixed="none"/>
<xsd:attribute name="xlink:href" type="xsd:string"/> <xsd:attribute ref="xlink:href"/>
</xsd:complexType> </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" type="sdpng:SimpleLink"/> <xsd:element name="info" type="sdpng:SimpleLink"/>
<xsd:sequence minOccurs="0"> <xsd:sequence minOccurs="0">
<xsd:element name="contact" type="sdpng:SimpleLink"/> <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>
5.7.2 Audio Codec Profile The SDPng XML schema definition references some attribute definition
for Xlink attributes (as defined by the Xlink specification [15]):
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.w3.org/1999/xlink"
targetNamespace="http://www.w3.org/1999/xlink"
>
<xsd:attribute name="type" type="xsd:string"/>
<xsd:attribute name="role" type="xsd:string"/>
<xsd:attribute name="arcrole" type="xsd:string"/>
<xsd:attribute name="title" type="xsd:string"/>
<xsd:attribute name="show" type="xsd:string"/>
<xsd:attribute name="actuate" type="xsd:string"/>
<xsd:attribute name="href" type="xsd:string"/>
</xsd:schema>
6. Open Issues
Definition of baseline libraries
Libraries provide partially specified definitions, i.e. without
transport parameters. How can SDPng documents reference the
definitions and augment them with specific transport parameters?
Referencing extension profiles: XML-Schema does not support the
declaration of multiple schemas via the schemaLocation attribute.
Conceivable solution: When extension profiles are used, the SDPng
description is a "multi-part" object, that consists of an
integrating schema definition (that references all necessary
profiles and the base definition) and the actual description
document that is a schema instance of the integrating schema.
Uniqueness of attribute values: When libraries are used they will
contain definition elements with "name" attributes for later
referencing. How to avoid name clashes for those identifiers?
When an SDPng document uses libraries from different sources they
could be incompatible because of name collisions. Possible
solution: Prefix such IDs with a namespace name (either explicitly
or implicitly by interpreting applications). The explicit
prefixes have the advantage that no special knowledge would be
required to resolve links at the cost of very long ID values.
A registry (reuse of SDP mechanisms and names etc.) needs to be
set up.
Negotiation mechanisms for multiparty conferencing need to be
formalized.
Mapping to other media description formats (SDP, H.245, ...)
should be provided. For H.245, this is probably a different
document (belonging to the SIP-H.323 inter-working group).
Implicit declaration of SDPng schema and default profiles
Should overwriting of child elements be allowed for referencing
existing definitions with the "ref" attribute?
7. Acknowledgements
The authors would like to thank Teodora Guenkova, Goran Petrovic and
Markus Nosse for their feedback and detailed comments.
References
[1] Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements
for Session Description and Capability Negotiation", Internet
Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001.
[2] Handley, M. and V. Jacobsen, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.
[5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", draft-ietf-avt-profile-new-
10.txt (work in progress), March 2001.
[6] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP
Payload for Redundant Audio Data", RFC 2198, September 1997.
[7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[8] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998.
[9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[10] World Wide Web Consortium (W3C), "Extensible Markup Language
(XML) 1.0 (Second Edition)", Status W3C Recommendation, Version
http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.
[11] World Wide Web Consortium (W3C), "Namespaces in XML", Status
W3C Recommendation, Version http://www.w3.org/TR/1999/REC-xml-
names-19990114, January 1999.
[12] World Wide Web Consortium (W3C), "XML Inclusions (XInclude)
Version 1.0", Status W3C Candidate Recommendation, Version
http://www.w3.org/TR/2002/CR-xinclude-20020221, February 2002.
[13] World Wide Web Consortium (W3C), "XML Schema Part 1:
Structures", Version http://www.w3.org/TR/2001/REC-xmlschema-1-
20010502/, Status W3C Recommendation, May 2001.
[14] World Wide Web Consortium (W3C), "XML Schema Part 2:
Datatypes", Version http://www.w3.org/TR/2001/REC-xmlschema-2-
20010502/, Status W3C Recommendation, May 2001.
[15] World Wide Web Consortium (W3C), "XML Linking Language (XLink)
Version 1.0", Version http://www.w3.org/TR/2001/REC-xlink-
20010627/, Status W3C Recommendation, June 2001.
[16] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
SDP", draft-ietf-mmusic-sdp-offer-answer-02.txt (work in
progress), February 2002.
[17] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for The
Use of XML within IETF Protocols", draft-hollenbeck-ietf-xml-
guidelines-05.txt (work in progress), June 2002.
Authors' Addresses
Dirk Kutscher
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen 28359
Germany
Phone: +49.421.218-7595, sip:dku@tzi.org
Fax: +49.421.218-7000
EMail: dku@tzi.uni-bremen.de
Joerg Ott
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen 28359
Germany
Phone: +49.421.201-7028, sip:jo@tzi.org
Fax: +49.421.218-7000
EMail: jo@tzi.uni-bremen.de
Carsten Bormann
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen 28359
Germany
Phone: +49.421.218-7024, sip:cabo@tzi.org
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Appendix A. SDPng Audio Codec Profile and Audio Codec Library
This section defines an SDPng profile for audio codec definitions and
a corresponding library of SDPng definitions of specific audio
codecs.
A.1 Audio Codec Profile
[5] specifies a number of audio codecs including short name to be
used as reference by session description protocols such as SDP and
SDPng. Those codec names, as listed in the first column of the above
table, are used to identify codecs in SDPng.
The following sections indicate the default values that are assumed
if nothing else than the codec reference is specified.
The following audio:codec attributes are defined for audio codecs:
name: the identifier to be later used for referencing the codec spec
encoding: the RTP/AVP profile identifier as registered with IANA
mime: the MIME type; may alternatively be specified instead of
"encoding"
channels: the number of independent media channels
pattern: the media channel pattern for mapping channels to payload
sampling: the sample rate for the codec (which in most cases equals
the RTP clock)
Furthermore, options may be defined of the following format:
<option id="name">value</option>
if a value is associated with the option (note that arbitrary complex
values are allowed), or alternatively:
<option id="name"/>
if the option is just a boolean indicator.
Attributes for the "option" tag are the following:
id: the identifier for the option (variable name)
collaps: the collapsing rules for this optional element, defined as
follows:
min: for numeric values only
max: for numeric values only
x: intersection of enumerated values, value lists
The following profile defines an element type that can be used for 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 substitution group "sdpng:d" (the "head element" of the SDPng the substitution group "sdpng:d" (the "head element" of the SDPng
base 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
skipping to change at page 56, line 27 skipping to change at page 57, line 27
<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>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="codec" substitutionGroup="sdpng:d"> <xsd:element name="codec" substitutionGroup="sdpng:definition">
<xsd:complexType> <xsd:complexType>
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="audio:AudioCodec"/> <xsd:extension base="audio:AudioCodec"/>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:schema> </xsd:schema>
5.7.3 RTP profile A.2 SDPng Library for Audio Codec Definitions
This section contains an SDPng library with the audio codec
definitions from Appendix A.
A.2.1 DVI4
<audio:codec name="dvi4" encoding="DVI4" channels="1" sampling="8000">
<rtp:pt name="rtp-avp-5" pt="5">
<audio:codec ref="dvi4"/>
</rtp:pt>
<rtp:pt name="rtp-avp-6" pt="6">
<audio:codec ref="dvi4" sampling="16000"/>
</rtp:pt>
Note that there is no default sampling rate specified for DVI4 and
hence a sampling rate MUST be specified.
A.2.2 G.722
<audio:codec name="g722" encoding="G722" channels="1" sampling="16000"/>
<rtp:pt name="rtp-avp-9" pt="9">
<audio:codec ref="g722"/>
</rtp:pt>
Note as per [5] that the RTP clock rate is 8000Hz rather than 16000
Hz.
A.2.3 G.726
<audio:codec name="g726-40" encoding="G726-40" channels="1" sampling="8000"/>
<audio:codec name="g726-32" encoding="G726-32" channels="1" sampling="8000"/>
<audio:codec name="g726-24" encoding="G726-24" channels="1" sampling="8000"/>
<audio:codec name="g726-16" encoding="G726-16" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-5" pt="5">
<audio:codec ref="g726-32"/>
</rtp:pt>
A.2.4 G.728
<audio:codec name="g728" encoding="G728" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-15" pt="15">
<audio:codec ref="g728"/>
</rtp:pt>
A.2.5 G.729
G.729 Annex A: reduced complexity of G.729
G.729 Annex B: comfort noise
<audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-18" pt="18">
<audio:codec ref="g729"/>
</rtp:pt>
For further codec description, the following options (which carry no
values associated with them) MAY be included:
<option id="annexA"/>
<!-- to indicate the use of Annex A reduced complexity -->
<option id="annexB"/>
<!-- to indicate the use of Annex B comfort noise -->
As stated in [5], the use of these options can be detected within the
media stream.
A.2.6 G.729 Annex D and E
<audio:codec name="g729d" encoding="G729D" channels="1" sampling="8000"/>
<audio:codec name="g729e" encoding="G729E" channels="1" sampling="8000"/>
The following option MAY be used with both Annexes D and E:
<option id="annexB"/>
<!-- to indicate the use of Annex B comfort noise -->
A.2.7 GSM
A.2.7.1 GSM Full Rate
The GSM Full Rate codec is indicated as follows:
<audio:codec name="gsm" encoding="GSM" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-3" pt="3">
<audio:codec ref="gsm"/>
</rtp:pt>
A.2.7.2 GSM Half Rate
The GSM Half Rate codec is indicated as follows:
<audio:codec name="gsm-hr" encoding="GSM-HR" channels="1" sampling="8000"/>
A.2.7.3 GSM Enhanced Full Rate
The GSM Enhanced Full Rate codec is indicated as follows:
<audio:codec name="gsm-efr" encoding="GSM-EFR" channels="1" sampling="8000"/>
A.2.8 L8
<audio:codec name="l8" encoding="L8" channels="1" sampling="8000"/>
A.2.9 L16
<audio:codec name="l16" encoding="L16" channels="1" sampling="8000"/>
<audio:codec name="l16-2" ref="l16" channels="2"/>
<rtp:pt name="rtp-avp-10" pt="10">
<audio:codec ref="l16"/>
</rtp:pt>
<rtp:pt name="rtp-avp-11" pt="11">
<audio:codec ref="l16-2"/>
</rtp:pt>
A.2.10 LPC
<audio:codec name="lpc" encoding="LPC" channels="1" sampling="8000"/>
A.2.11 MPA
<audio:codec name="mpa" encoding="MPA" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-14" pt="14">
<audio:codec ref="mpa"/>
</rtp:pt>
A.2.12 PCMA and PCMU
<audio:codec name="pcmu" encoding="PCMU" channels="1" sampling="8000"/>
<audio:codec name="pcma" encoding="PCMA" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-0" pt="0">
<audio:codec ref="pcmu"/>
</rtp:pt>
<rtp:pt name="rtp-avp-8" pt="8">
<audio:codec ref="pcma"/>
</rtp:pt>
A.2.13 QCELP
<audio:codec name="qcelp" encoding="QCELP" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-12" pt="12">
<audio:codec ref="qcelp"/>
</rtp:pt>
A.2.14 VDVI
<audio:codec name="vdvi" encoding="VDVI" channels="1" sampling="8000"/>
<def xmlns="http://www.iana.org/sdpng"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng/int integrated.xsd"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp">
<audio:codec name="dvi4" encoding="DVI4" channels="1" sampling="8000"/>
<audio:codec name="g722" encoding="G722" channels="1" sampling="16000"/>
<audio:codec name="g726-40" encoding="G726-40" channels="1" sampling="8000"/>
<audio:codec name="g726-32" encoding="G726-32" channels="1" sampling="8000"/>
<audio:codec name="g726-24" encoding="G726-24" channels="1" sampling="8000"/>
<audio:codec name="g726-16" encoding="G726-16" channels="1" sampling="8000"/>
<audio:codec name="g728" encoding="G728" channels="1" sampling="8000"/>
<audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/>
<audio:codec name="g729d" encoding="G729D" channels="1" sampling="8000"/>
<audio:codec name="g729e" encoding="G729E" channels="1" sampling="8000"/>
<audio:codec name="gsm" encoding="GSM" channels="1" sampling="8000"/>
<audio:codec name="gsm-hr" encoding="GSM-HR" channels="1" sampling="8000"/>
<audio:codec name="gsm-efr" encoding="GSM-EFR" channels="1" sampling="8000"/>
<audio:codec name="l8" encoding="L8" channels="1" sampling="8000"/>
<audio:codec name="l16" encoding="L16" channels="1" sampling="8000"/>
<audio:codec name="lpc" encoding="LPC" channels="1" sampling="8000"/>
<audio:codec name="mpa" encoding="MPA" channels="1" sampling="8000"/>
<audio:codec name="pcmu" encoding="PCMU" channels="1" sampling="8000"/>
<audio:codec name="pcma" encoding="PCMA" channels="1" sampling="8000"/>
<audio:codec name="qcelp" encoding="QCELP" channels="1" sampling="8000"/>
<audio:codec name="vdvi" encoding="VDVI" channels="1" sampling="8000"/>
</def>
Appendix B. SDPng Profile for RTP Profile and RTP Library
B.1 RTP profile
The following profile defines element types that can be used for 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 substitution 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
skipping to change at page 57, line 26 skipping to change at page 63, line 42
<xsd:import namespace="http://www.iana.org/sdpng" <xsd:import namespace="http://www.iana.org/sdpng"
schemaLocation="sdpng.xsd"/> 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).
content, a definition may be referenced using the "format
attribute".
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:complexContent mixed="false"> <xsd:complexContent mixed="false">
<xsd:extension base="sdpng:Definition"> <xsd:extension base="sdpng:Definition">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="sdpng:d" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="sdpng:definition" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="pt" type="xsd:unsignedByte"/> <xsd:attribute name="pt" type="xsd:unsignedByte"/>
<xsd:attribute name="format" type="xsd:string">
<!-- IDREF? Issue: unique names for definitions!-->
</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:definition"/>
<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<xsd:element name="session" type="rtp:Session" substitutionGroup="sdpng:sc"/> <xsd:element name="session" type="rtp:Session" substitutionGroup="sdpng:sessionConfig"/>
<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 ref="rtp:pt"/>
<xsd:element ref="rtp:transport"/>
</xsd:sequence> </xsd:sequence>
<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:complexContent>
<xsd:extension base="sdpng:Definition"> <xsd:extension base="sdpng:Definition">
<xsd:attribute name="role" type="xsd:string"/> <xsd:attribute name="role" type="xsd:string"/>
<xsd:attribute name="endpoint" 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:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="transport" type="rtp:Transport" substitutionGroup="sdpng:definition"/>
<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>
<xsd:simpleType name="IP6Addr"> <xsd:simpleType name="IP6Addr">
<xsd:restriction base="rtp:IPAddr"/> <xsd:restriction base="rtp:IPAddr"/>
skipping to change at page 58, line 48 skipping to change at page 65, line 13
<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" substitutionGroup="rtp:transport"/>
</xsd:schema> </xsd:schema>
5.8 Issues B.2 SDPng Library for RTP Payload Format Definitions
o Libraries provide partially specified definitions, i.e. without This section contains an SDPng library with the RTP payload format
transport parameters. How can SDPng documents reference the definitions from Appendix A.
definitions and augment them with specific transport parameters?
o Referencing extension profiles: XML-Schema does not support the <def xmlns="http://www.iana.org/sdpng"
declaration of multiple schemas via the schemaLocation attribute. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Conceivable solution: When extension profiles are used, the SDPng xsi:schemaLocation="http://www.iana.org/sdpng/int integrated.xsd"
description is a "multi-part" object, that consists of an xmlns:audio="http://www.iana.org/sdpng/audio"
integrating schema definition (that references all necessary xmlns:rtp="http://www.iana.org/sdpng/rtp"
profiles and the base definition) and the actual description xmlns:xi="http://www.w3.org/2001/XInclude">
document that is a schema instance of the integrating schema.
o Uniqueness of attribute values: When libraries are used they will <!-- import audio codec definitions here: -->
contain definition elements with "name" attributes for later
referencing. How to avoid name clashes for those identifiers?
When an SDPng document uses libraries from different sources they
could be incompatible because of name collisions. Possible
solution: Prefix such IDs with a namespace name (either explicitly
or implicitly by interpreting applications). The explicit
prefixes have the advantage that no special knowledge would be
required to resolve links at the cost of very long ID values.
6. Use of SDPng in conjunction with other IETF Signaling Protocols <xi:xinclude href="http://www.iana.org/sdpng/audio/audio.sdpng" parse="xml"/>
<rtp:pt name="rtp-avp-5" pt="5">
<audio:codec ref="dvi4"/>
</rtp:pt>
<rtp:pt name="rtp-avp-6" pt="6">
<audio:codec ref="dvi4" sampling="16000">
</rtp:pt>
<rtp:pt name="rtp-avp-9" pt="9">
<audio:codec ref="g722"/>
</rtp:pt>
<rtp:pt name="rtp-avp-5" pt="5">
<audio:codec ref="g726-32"/>
</rtp:pt>
<rtp:pt name="rtp-avp-15" pt="15">
<audio:codec ref="g728"/>
</rtp:pt>
<rtp:pt name="rtp-avp-18" pt="18">
<audio:codec ref="g729"/>
</rtp:pt>
<rtp:pt name="rtp-avp-3" pt="3">
<audio:codec ref="gsm"/>
</rtp:pt>
<rtp:pt name="rtp-avp-10" pt="10">
<audio:codec ref="l16"/>
</rtp:pt>
<rtp:pt name="rtp-avp-11" pt="11">
<audio:codec ref="l16-2"/>
</rtp:pt>
<rtp:pt name="rtp-avp-14" pt="14">
<audio:codec ref="mpa"/>
</rtp:pt>
<rtp:pt name="rtp-avp-0" pt="0">
<audio:codec ref="pcmu"/>
</rtp:pt>
<rtp:pt name="rtp-avp-8" pt="8">
<audio:codec ref="pcma"/>
</rtp:pt>
<rtp:pt name="rtp-avp-12" pt="12">
<audio:codec ref="qcelp"/>
</rtp:pt>
</def>
Appendix C. Use of SDPng in conjunction with other IETF Signaling
Protocols
The SDPng model provides the notion of Components to indicate the The SDPng model provides the notion of Components to indicate the
intended types of collaboration between the users in e.g. a intended types of collaboration between the users in e.g. a
teleconferencing scenario. teleconferencing scenario.
Three different abstractions are defined that are used for describing Three different abstractions are defined that are used for describing
the properties of a specific Component: the properties of a specific Component:
o a Capability refers to the fact that one of the involved parties o a Capability refers to the fact that one of the involved parties
supports one particular way of exchanging media -- defined in supports one particular way of exchanging media -- defined in
skipping to change at page 60, line 36 skipping to change at page 67, line 37
As mentioned before, this abstract notion of the interactions between As mentioned before, this abstract notion of the interactions between
a number of communicating systems needs to be mapped to the a number of communicating systems needs to be mapped to the
application scenarios of SDPng in conjunction with the various IETF application scenarios of SDPng in conjunction with the various IETF
signaling protocols: SAP, SIP, RTSP, and MEGACO. signaling protocols: SAP, SIP, RTSP, and MEGACO.
In general, this section provides recommendations and possible In general, this section provides recommendations and possible
scenarios for the use of SDPng within specific protocols and scenarios for the use of SDPng within specific protocols and
applications. Is does not specify normative requirements. applications. Is does not specify normative requirements.
6.1 The Session Announcement Protocol (SAP) C.1 The Session Announcement Protocol (SAP)
SAP is used to disseminate a previously created (and typically fixed) SAP is used to disseminate a previously created (and typically fixed)
session description to a potentially large audience. An interested session description to a potentially large audience. An interested
member of the audience will use the SDPng description contained in member of the audience will use the SDPng description contained in
SAP to join the announced media sessions. SAP to join the announced media sessions.
This means that a SAP announcement contains the Actual Configurations This means that a SAP announcement contains the Actual Configurations
of all Components that are part of the overall teleconference or of all Components that are part of the overall teleconference or
broadcast. broadcast.
skipping to change at page 61, line 19 skipping to change at page 68, line 20
chooses the one it sees fit best. If the intersection is empty, the chooses the one it sees fit best. If the intersection is empty, the
receiver cannot participate in the announced session. receiver cannot participate in the announced session.
SAP may be substituted by HTTP (in the general case, at least), SMTP, SAP may be substituted by HTTP (in the general case, at least), SMTP,
NNTP, or other IETF protocols suitable for conveying a media NNTP, or other IETF protocols suitable for conveying a media
description from one entity to one or more other without the intend description from one entity to one or more other without the intend
for further negotiation of the session parameters. for further negotiation of the session parameters.
Example from the SAP spec. to be provided. Example from the SAP spec. to be provided.
6.2 Session Initiation Protocol (SIP) C.2 Session Initiation Protocol (SIP)
SIP is used to establish and modify multimedia sessions, and SDPng SIP is used to establish and modify multimedia sessions, and SDPng
may be carried at least in SIP INVITE and ACK messages as well as in may be carried at least in SIP INVITE and ACK messages as well as in
a number of responses. From dealing with legacy SDP (and its a number of responses. From dealing with legacy SDP (and its
essential non-suitability for capability negotiation), a particular essential non-suitability for capability negotiation), a particular
use and interpretation of SDP has been defined for SIP. use and interpretation of SDP has been defined for SIP.
One of the important flexibilities introduced by SIP's usage of SDP One of the important flexibilities introduced by SIP's usage of SDP
is that a sender can change dynamically between all codecs that a is that a sender can change dynamically between all codecs that a
receiver has indicated support (and has provided an address) for. receiver has indicated support (and has provided an address) for.
skipping to change at page 62, line 9 skipping to change at page 69, line 11
an initial session description that is processed by the other side an initial session description that is processed by the other side
and returned. For capability negotiation, this means that the and returned. For capability negotiation, this means that the
negotiation follows a two-stage-process: The "offerer" sends its negotiation follows a two-stage-process: The "offerer" sends its
capability description to the receiver. The receiver processes the capability description to the receiver. The receiver processes the
offerers capabilities and his own capabilities and generates a result offerers capabilities and his own capabilities and generates a result
capability description that is sent back to the offerer. Both sides capability description that is sent back to the offerer. Both sides
now know the commonly supported configurations and can initiate the now know the commonly supported configurations and can initiate the
media sessions. media sessions.
Because of this strict "offer/answer" model, the offerer must already Because of this strict "offer/answer" model, the offerer must already
send complete configurations (i.e. include transport addresses) along send complete configurations (i.e. include transport addresses)
with the capability descriptions. The answer must also contain along with the capability descriptions. The answer must also contain
complete configuration parameters. The following figure shows, how complete configuration parameters. The following figure shows, how
SDPng content can be used in an INVITE request with a correspong 200 SDPng content can be used in an INVITE request with a correspong 200
OK message. OK message.
Simple description document with only one alternative: Simple description document with only one alternative:
F1 INVITE A -> B F1 INVITE A -> B
INVITE sip:B@example.com SIP/2.0 INVITE sip:B@example.com SIP/2.0
Via: SIP/2.0/UDP hostA.example.com:5060 Via: SIP/2.0/UDP hostA.example.com:5060
skipping to change at page 62, line 33 skipping to change at page 69, line 35
Call-ID: 1234@hostA.example.com Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:UserA@192.168.1.1> Contact: <sip:UserA@192.168.1.1>
Content-Type: application/sdpng Content-Type: application/sdpng
Content-Length: 685 Content-Length: 685
<def> <def>
<audio:codec name="audio-basic" encoding="PCMU" <audio:codec name="audio-basic" encoding="PCMU"
sampling="8000" channels="1"/> sampling="8000" channels="1"/>
<rtp:pt name="rtp-avp-0" pt="0" format="audio-basic"/> <rtp:pt name="rtp-avp-0" pt="0">
<audio:codec ref="audio-basic"/>
</rtp:pt>
</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>
<rtp:pt ref="rtp-avp-0"/>
<rtp:udp role="receive" endpoint="A" addr="192.168.1.1" <rtp:udp role="receive" endpoint="A" addr="192.168.1.1"
rtp-port="7800"/> rtp-port="7800"/>
</rtp:session> </rtp:session>
</alt> </alt>
</component> </component>
</cfg> </cfg>
<conf> <conf>
<owner user="A@example.com" id="98765432" version="1" nettype="IN" <owner user="A@example.com" id="98765432" version="1" nettype="IN"
addrtype="IP4" addr="192.168.1.1"/> addrtype="IP4" addr="192.168.1.1"/>
<session name="SDPng questions"> <session name="SDPng questions">
</session> </session>
<info name="interactive-audio" function="voice"> <info name="interactive-audio" function="voice">
Telephony media stream Telephony media stream
<info> <info>
</conf> </conf>
================================================== ==================================================
F2 (100 Trying) B -> A F2 (100 Trying) B -> A
SIP/2.0 100 Trying SIP/2.0 100 Trying
skipping to change at page 63, line 46 skipping to change at page 71, line 4
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP hostA.example.com:5060 Via: SIP/2.0/UDP hostA.example.com:5060
From: A <sip:A@example.com> From: A <sip:A@example.com>
To: B <sip:B@example.com>;tag=987654 To: B <sip:B@example.com>;tag=987654
Call-ID: 1234@hostA.example.com Call-ID: 1234@hostA.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:B@192.168.1.2> Contact: <sip:B@192.168.1.2>
Content-Type: application/sdpng Content-Type: application/sdpng
Content-Length: 479 Content-Length: 479
<def> <def>
<audio:codec name="audio-basic" encoding="PCMU" <audio:codec name="audio-basic" encoding="PCMU"
sampling="8000" channels="1"/> sampling="8000" channels="1"/>
<rtp:pt name="rtp-avp-0" pt="0" format="audio-basic"/> <rtp:pt name="rtp-avp-0" pt="0">
<audio:codec ref="audio-basic"/>
</rtp:pt>
</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>
<rtp:pt ref="rtp-avp-0"/>
<rtp:udp role="receive" endpoint="A" addr="192.168.1.1" <rtp:udp role="receive" endpoint="A" addr="192.168.1.1"
rtp-port="7800"/> rtp-port="7800"/>
<rtp:udp role="receive" endpoint="B" addr="192.168.1.2" <rtp:udp role="receive" endpoint="B" addr="192.168.1.2"
rtp-port="9410"/> rtp-port="9410"/>
</rtp:session> </rtp:session>
</alt> </alt>
</component> </component>
</cfg> </cfg>
================================================== ==================================================
skipping to change at page 65, line 29 skipping to change at page 72, line 37
Contact: <sip:UserA@192.168.1.1> Contact: <sip:UserA@192.168.1.1>
Content-Type: application/sdpng Content-Type: application/sdpng
Content-Length: 935 Content-Length: 935
<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="g729" encoding="G729" channels="1" sampling="8000"/> <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-0" pt="0">
<rtp:pt name="rtp-avp-18" pt="18" format="g729"/> <audio:codec ref="audio-basic"/>
</rtp:pt>
<rtp:pt name="rtp-avp-18" pt="18">
<audio:codec ref="g729"/>
</rtp:pt>
<rtp:udp name="A-rcv" role="receive" endpoint="A" addr="192.168.1.1" <rtp:udp name="A-rcv" role="receive" endpoint="A" addr="192.168.1.1"
rtp-port="7800"/> rtp-port="7800"/>
</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" transport="A-rcv""/> <rtp:session format="rtp-avp-0">
<rtp:udp ref="A-rcv"/>
</rtp:session>
</alt> </alt>
<alt name="AVP-audio-18"> <alt name="AVP-audio-18">
<rtp:session format="rtp-avp-18" transport="A-rcv"/> <rtp:session format="rtp-avp-18"/>
<rtp:udp ref="A-rcv"/>
</rtp:session>
</alt> </alt>
</component> </component>
</cfg> </cfg>
<conf> <conf>
<owner user="A@example.com" id="98765432" version="1" nettype="IN" <owner user="A@example.com" id="98765432" version="1" nettype="IN"
addrtype="IP4" addr="192.168.1.1"/> addrtype="IP4" addr="192.168.1.1"/>
<session name="SDPng questions"> <session name="SDPng questions">
</session> </session>
<info name="interactive-audio" function="voice"> <info name="interactive-audio" function="voice">
Telephony media stream Telephony media stream
<info> <info>
</conf> </conf>
================================================== ==================================================
F2 (100 Trying) B -> A F2 (100 Trying) B -> A
SIP/2.0 100 Trying SIP/2.0 100 Trying
skipping to change at page 67, line 4 skipping to change at page 74, line 21
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:B@192.168.1.2> Contact: <sip:B@192.168.1.2>
Content-Type: application/sdpng Content-Type: application/sdpng
Content-Length: 479 Content-Length: 479
<def> <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="g729" encoding="G729" channels="1" sampling="8000"/> <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:pt name="rtp-avp-0" pt="0">
<audio:codec ref="audio-basic"/>
</rtp:pt>
<rtp:pt name="rtp-avp-18" pt="18">
<audio:codec ref="g729"/>
</rtp:pt>
<rtp:udp name="A-rcv" role="receive" endpoint="A" addr="192.168.1.1" <rtp:udp name="A-rcv" role="receive" endpoint="A" addr="192.168.1.1"
rtp-port="7800"/> rtp-port="7800"/>
<rtp:udp name="B-rcv" role="receive" endpoint="B" addr="192.168.1.2" <rtp:udp name="B-rcv" role="receive" endpoint="B" addr="192.168.1.2"
rtp-port="9410"/> rtp-port="9410"/>
</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" transport="A-rcv B-rcv"/> <rtp:session format="rtp-avp-0">
<rtp:udp ref="A-rcv"/>
<rtp:udp ref="B-rcv"/>
</rtp:session>
</alt> </alt>
</component> </component>
</cfg> </cfg>
================================================== ==================================================
ACK from A to B omitted ACK from A to B omitted
In the INVITE message, A sends B a description document, that In the INVITE message, A sends B a description document, that
specifies one component with two alternatives for the audio stream specifies one component with two alternatives for the audio stream
(PCMU and G.729). Since A wants to use the same transport address (PCMU and G.729). Since A wants to use the same transport address
for receiving media data regardless of the payload format, A provides for receiving media data regardless of the payload format, A provides
the transport specification in the def element and references this the transport specification in the def element and references this
definition in the rtp:session elements for both alternatives by using definition in the rtp:session elements for both alternatives by using
the attribute "transport". the attribute "transport".
In the 200 OK message, B sends an updated description document to A. In the 200 OK message, B sends an updated description document to A.
B does only support PCMU, so it removes the alternative for G.729 B does only support PCMU, so it removes the alternative for G.729
skipping to change at page 67, line 36 skipping to change at page 75, line 15
specifies one component with two alternatives for the audio stream specifies one component with two alternatives for the audio stream
(PCMU and G.729). Since A wants to use the same transport address (PCMU and G.729). Since A wants to use the same transport address
for receiving media data regardless of the payload format, A provides for receiving media data regardless of the payload format, A provides
the transport specification in the def element and references this the transport specification in the def element and references this
definition in the rtp:session elements for both alternatives by using definition in the rtp:session elements for both alternatives by using
the attribute "transport". the attribute "transport".
In the 200 OK message, B sends an updated description document to A. In the 200 OK message, B sends an updated description document to A.
B does only support PCMU, so it removes the alternative for G.729 B does only support PCMU, so it removes the alternative for G.729
from the description. B also defines its transport address in the from the description. B also defines its transport address in the
def element and references this definition by adding "B-rcv" to the def element and references this definition by referencing the rtp:udp
attribute "transport" of the rtp:session element. (B could also have element named "B-rcv".
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").
6.3 Real-Time Streaming Protocol (RTSP) C.3 Real-Time Streaming Protocol (RTSP)
In contrast to SIP, RTSP has, from its intended usage, a clear In contrast to SIP, RTSP has, from its intended usage, a clear
distinction between offering Potential Configurations (typically by distinction between offering Potential Configurations (typically by
the server) and choosing one out of these (by the client), and, in the server) and choosing one out of these (by the client), and, in
some cases; some parameters (such as multicast addresses) may be some cases; some parameters (such as multicast addresses) may be
dictated by the server. Hence with RTSP, there is a clear dictated by the server. Hence with RTSP, there is a clear
distinguish between Potential Configurations during the negotiation distinguish between Potential Configurations during the negotiation
phase and a finally chosen Actual Configuration according to which phase and a finally chosen Actual Configuration according to which
streaming will take place. streaming will take place.
Example from the RTSP spec to be provided. Example from the RTSP spec to be provided.
6.4 Media Gateway Control Protocol (MEGACOP) C.4 Media Gateway Control Protocol (MEGACOP)
The MEGACO architecture also follows the SDPng model of a clear The MEGACO architecture also follows the SDPng model of a clear
separation between Potential and Actual Configurations. Upon separation between Potential and Actual Configurations. Upon
startup, a Media Gateway (MG) will "register" with its Media Gateway startup, a Media Gateway (MG) will "register" with its Media Gateway
Controller (MGC) and the latter will audit the MG for its Controller (MGC) and the latter will audit the MG for its
Capabilities. Those will be provided as Potential Configurations, Capabilities. Those will be provided as Potential Configurations,
possibly with extensive Constraints specifications. Whenever a media possibly with extensive Constraints specifications. Whenever a media
path needs to be set up by the MGC between two MGs or an MG needs to path needs to be set up by the MGC between two MGs or an MG needs to
be reconfigured internally, the MGC will use (updated) Actual be reconfigured internally, the MGC will use (updated) Actual
Configurations. Configurations.
Details and examples to be defined. Details and examples to be defined.
7. Open Issues Appendix D. Change History
Definition of baseline libraries
A registry (reuse of SDP mechanisms and names etc.) needs to be
set up.
Negotiation mechanisms for multiparty conferencing need to be
formalized.
Mapping to other media description formats (SDP, H.245, ...)
should be provided. For H.245, this is probably a different
document (belonging to the SIP-H.323 inter-working group).
Implicit declaration of SDPng schema and default profiles
References
[1] Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements
for Session Description and Capability Negotiation", Internet
Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001.
[2] Handley, M. and V. Jacobsen, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.
[5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", draft-ietf-avt-profile-new-
10.txt (work in progress), March 2001.
[6] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP
Payload for Redundant Audio Data", RFC 2198, September 1997.
[7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[8] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998.
[9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[10] World Wide Web Consortium (W3C), "Extensible Markup Language
(XML) 1.0 (Second Edition)", Status W3C Recommendation, Version
http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.
[11] World Wide Web Consortium (W3C), "Namespaces in XML", Status
W3C Recommendation, Version http://www.w3.org/TR/1999/REC-xml-
names-19990114, January 1999.
[12] World Wide Web Consortium (W3C), "XML Inclusions (XInclude)
Version 1.0", Status W3C Working Draft, Version
http://www.w3.org/TR/2001/WD-xinclude-20010516, May 2001.
[13] World Wide Web Consortium (W3C), "XML Schema Part 1:
Structures", Version http://www.w3.org/TR/2001/REC-xmlschema-1-
20010502/, Status W3C Recommendation, May 2001.
[14] World Wide Web Consortium (W3C), "XML Schema Part 2:
Datatypes", Version http://www.w3.org/TR/2001/REC-xmlschema-2-
20010502/, Status W3C Recommendation, May 2001.
[15] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
SDP", draft-ietf-mmusic-sdp-offer-answer-01.txt (work in
progress), February 2002.
Authors' Addresses
Dirk Kutscher
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen 28359
Germany
Phone: +49.421.218-7595, sip:dku@tzi.org
Fax: +49.421.218-7000
EMail: dku@tzi.uni-bremen.de
Joerg Ott
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen 28359
Germany
Phone: +49.421.201-7028, sip:jo@tzi.org
Fax: +49.421.218-7000
EMail: jo@tzi.uni-bremen.de
Carsten Bormann
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen 28359
Germany
Phone: +49.421.218-7024, sip:cabo@tzi.org
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Appendix A. Base SDPng Specifications for Audio Codec Descriptions
[5] specifies a number of audio codecs including short name to be
used as reference by session description protocols such as SDP and
SDPng. Those codec names, as listed in the first column of the above
table, are used to identify codecs in SDPng.
The following sections indicate the default values that are assumed
if nothing else than the codec reference is specified.
The following audio:codec attributes are defined for audio codecs:
name: the identifier to be later used for referencing the codec spec
encoding: the RTP/AVP profile identifier as registered with IANA
mime: the MIME type; may alternatively be specified instead of
"encoding"
channels: the number of independent media channels
pattern: the media channel pattern for mapping channels to payload
sampling: the sample rate for the codec (which in most cases equals
the RTP clock)
Furthermore, options may be defined of the following format:
<option id="name">value</option>
if a value is associated with the option (note that arbitrary complex
values are allowed), or alternatively:
<option id="name"/>
if the option is just a boolean indicator.
Attributes for the "option" tag are the following:
id: the identifier for the option (variable name)
collaps: the collapsing rules for this optional element, defined as
follows:
min: for numeric values only
max: for numeric values only
x: intersection of enumerated values, value lists
A.1 DVI4
<audio:codec name="dvi4" encoding="DVI4" channels="1" sampling="8000">
<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>
Note that there is no default sampling rate specified for DVI4 and
hence a sampling rate MUST be specified.
A.2 G.722
<audio:codec name="g722" encoding="G722" channels="1" sampling="16000"/>
<rtp:pt name="rtp-avp-9" pt="9" format="g722"/>
Note as per [5] that the RTP clock rate is 8000Hz rather than 16000
Hz.
A.3 G.726
<audio:codec name="g726-40" encoding="G726-40" channels="1" sampling="8000"/>
<audio:codec name="g726-32" encoding="G726-32" channels="1" sampling="8000"/>
<audio:codec name="g726-24" encoding="G726-24" channels="1" sampling="8000"/>
<audio:codec name="g726-16" encoding="G726-16" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-5" pt="5" format="g726-32"/>
A.4 G.728
<audio:codec name="g728" encoding="G728" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-15" pt="15" format="g728"/>
A.5 G.729
G.729 Annex A: reduced complexity of G.729
G.729 Annex B: comfort noise
<audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-18" pt="18" format="g729"/>
For further codec description, the following options (which carry no
values associated with them) MAY be included:
<option id="annexA"/>
<!-- to indicate the use of Annex A reduced complexity -->
<option id="annexB"/>
<!-- to indicate the use of Annex B comfort noise -->
As stated in [5], the use of these options can be detected within the
media stream.
A.6 G.729 Annex D and E
<audio:codec name="g729d" encoding="G729D" channels="1" sampling="8000"/>
<audio:codec name="g729e" encoding="G729E" channels="1" sampling="8000"/>
The following option MAY be used with both Annexes D and E:
<option id="annexB"/>
<!-- to indicate the use of Annex B comfort noise -->
A.7 GSM
A.7.1 GSM Full Rate
The GSM Full Rate codec is indicated as follows:
<audio:codec name="gsm" encoding="GSM" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-3" pt="3" format="gsm"/>
A.7.2 GSM Half Rate
The GSM Half Rate codec is indicated as follows:
<audio:codec name="gsm-hr" encoding="GSM-HR" channels="1" sampling="8000"/>
A.7.3 GSM Enhanced Full Rate
The GSM Enhanced Full Rate codec is indicated as follows:
<audio:codec name="gsm-efr" encoding="GSM-EFR" channels="1" sampling="8000"/>
A.8 L8
<audio:codec name="l8" encoding="L8" channels="1" sampling="8000"/>
A.9 L16
<audio:codec name="l16" encoding="L16" channels="1" sampling="8000"/>
<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>
A.10 LPC
<audio:codec name="lpc" encoding="LPC" channels="1" sampling="8000"/>
A.11 MPA
<audio:codec name="mpa" encoding="MPA" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-14" pt="14" format="mpa"/>
A.12 PCMA and PCMU
<audio:codec name="pcmu" encoding="PCMU" channels="1" sampling="8000"/>
<audio:codec name="pcma" encoding="PCMA" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-0" pt="0" format="pcmu"/>
<rtp:pt name="rtp-avp-8" pt="8" format="pcma"/>
A.13 QCELP
<audio:codec name="qcelp" encoding="QCELP" channels="1" sampling="8000"/>
<rtp:pt name="rtp-avp-12" pt="12" format="qcelp"/>
A.14 VDVI
<audio:codec name="vdvi" encoding="VDVI" channels="1" sampling="8000"/>
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"/> draft-ietf-mmusic-sdpng-05.txt
<rtp:pt name="rtp-avp-8" pt="8" format="pcma"/> * Moved audio and RTP profile to appendix.
<rtp:pt name="rtp-avp-12" pt="12" format="qcelp"/> * Moved section "Use of SDPng in conjunction with other IETF
Signaling Protocols" to appendix.
</def> * Changed mechanism for references to definitions: Definition
elements provide an attribute "ref" that can be used to
referenced existing definitions (Section 3.3). Removed other
mechanisms for referencing (attributes "format" and
"transport", element type "use").
Appendix D. Change History * Corrections to schema definitions and examples
draft-ietf-mmusic-sdpng-04.txt draft-ietf-mmusic-sdpng-04.txt
* New section on capability negotiation (Section 4). * New section on capability negotiation (Section 4).
* New section on referencing definitions (Section 3.3). * New section on referencing definitions (Section 3.3).
* New section on properties (Section 3.3.2). * New section on properties.
* New section on definition groups (Section 3.3.3). * New section on definition groups.
draft-ietf-mmusic-sdpng-03.txt draft-ietf-mmusic-sdpng-03.txt
* Extension of the SDPng schema (use of Xlinks etc.) * Extension of the SDPng schema (use of Xlinks etc.)
* Clarification in the text * Clarification in the text
* Fixed examples * Fixed examples
* Added example libraries as appendices * Added example libraries as appendices
 End of changes. 

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