draft-ietf-mmusic-sdpng-03.txt   draft-ietf-mmusic-sdpng-04.txt 
Network Working Group Kutscher Network Working Group Kutscher
Internet-Draft Ott Internet-Draft Ott
Expires: May 22, 2002 Bormann Expires: August 30, 2002 Bormann
TZI, Universitaet Bremen TZI, Universitaet Bremen
November 21, 2001 March 01, 2002
Session Description and Capability Negotiation Session Description and Capability Negotiation
draft-ietf-mmusic-sdpng-03.txt draft-ietf-mmusic-sdpng-04.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 May 22, 2002. This Internet-Draft will expire on August 30, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). 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 confctrl@isi.edu and/or the authors. group's mailing list at mmusic@ietf.org and/or the authors.
Document Revision Document Revision
$Revision: 4.7 $ $Revision: 4.23 $
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and System Model . . . . . . . . . . . . . . . 6 2. Terminology and System Model . . . . . . . . . . . . . . . 6
3. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . 9 3.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Components & Configurations . . . . . . . . . . . . . . . 11 3.1.2 Components & Configurations . . . . . . . . . . . . . . . 11
3.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.4 Session Attributes . . . . . . . . . . . . . . . . . . . . 14 3.1.4 Session Attributes . . . . . . . . . . . . . . . . . . . . 14
3.1.4.1 Owner . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.4.1 Owner . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.4.2 Session Identification . . . . . . . . . . . . . . . . . . 15 3.1.4.2 Session Identification . . . . . . . . . . . . . . . . . . 15
3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) . . . 16 3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) . . . 16
3.1.4.4 Component Semantic Specification . . . . . . . . . . . . . 17 3.1.4.4 Component Semantic Specification . . . . . . . . . . . . . 17
3.2 Syntax Definition Mechanisms . . . . . . . . . . . . . . . 18 3.2 Syntax Definition Mechanisms . . . . . . . . . . . . . . . 18
3.3 External Definition Packages . . . . . . . . . . . . . . . 20 3.3 Referencing Definitions . . . . . . . . . . . . . . . . . 20
3.3.1 Profile Definitions . . . . . . . . . . . . . . . . . . . 21 3.3.1 The sdpng:use Element Type . . . . . . . . . . . . . . . . 21
3.3.2 Library Definitions . . . . . . . . . . . . . . . . . . . 21 3.3.2 Properties . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3.3 Definition Groups . . . . . . . . . . . . . . . . . . . . 23
4. Formal Specification . . . . . . . . . . . . . . . . . . . 24 3.3.4 Usage of Child Elements and Attributes of sdpng:use
4.1 XML Schema as a Definition Mechanism . . . . . . . . . . . 24 Elements . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 SDPng Schema . . . . . . . . . . . . . . . . . . . . . . . 25 3.4 External Definition Packages . . . . . . . . . . . . . . . 28
4.3 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.4.1 Profile Definitions . . . . . . . . . . . . . . . . . . . 28
4.4 SDPng Documents . . . . . . . . . . . . . . . . . . . . . 27 3.4.2 Library Definitions . . . . . . . . . . . . . . . . . . . 29
4.5 Libraries . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6 Details on the use of specific XML Mechanisms . . . . . . 29 4. Capability Negotiation . . . . . . . . . . . . . . . . . . 32
4.6.1 Default Namespace . . . . . . . . . . . . . . . . . . . . 29 4.1 Outline of the Negotiation Process . . . . . . . . . . . . 32
4.6.2 Qualified Locals . . . . . . . . . . . . . . . . . . . . . 29 4.2 The Collapsing Algorithm . . . . . . . . . . . . . . . . . 34
4.6.3 Fixed Namespace Prefixes . . . . . . . . . . . . . . . . . 30 4.2.1 Collapsing Two Configurations . . . . . . . . . . . . . . 35
4.7 SDPng Schema Definitions . . . . . . . . . . . . . . . . . 30 4.2.1.1 Collapsing of Attributes . . . . . . . . . . . . . . . . . 35
4.7.1 SDPng Base Definition . . . . . . . . . . . . . . . . . . 30 4.2.1.2 Collapsing two Elements . . . . . . . . . . . . . . . . . 38
4.7.2 Audio Codec Profile . . . . . . . . . . . . . . . . . . . 37 4.2.1.3 Collapsing nested Elements . . . . . . . . . . . . . . . . 39
4.7.3 RTP profile . . . . . . . . . . . . . . . . . . . . . . . 38 4.2.2 Deriving an actual Configuration . . . . . . . . . . . . . 41
4.8 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5. Formal Specification . . . . . . . . . . . . . . . . . . . 42
5. Use of SDPng in conjunction with other IETF Signaling 5.1 XML Schema as a Definition Mechanism . . . . . . . . . . . 42
Protocols . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2 SDPng Schema . . . . . . . . . . . . . . . . . . . . . . . 43
5.1 The Session Announcement Protocol (SAP) . . . . . . . . . 42 5.3 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . 43 5.4 SDPng Documents . . . . . . . . . . . . . . . . . . . . . 45
5.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . 49 5.5 Libraries . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . 50 5.6 Details on the use of specific XML Mechanisms . . . . . . 47
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 51 5.6.1 Default Namespace . . . . . . . . . . . . . . . . . . . . 47
References . . . . . . . . . . . . . . . . . . . . . . . . 52 5.6.2 Qualified Locals . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53 5.6.3 Fixed Namespace Prefixes . . . . . . . . . . . . . . . . . 48
A. Base SDPng Specifications for Audio Codec Descriptions . . 54 5.7 SDPng Schema Definitions . . . . . . . . . . . . . . . . . 48
A.1 DVI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.7.1 SDPng Base Definition . . . . . . . . . . . . . . . . . . 48
A.2 G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.7.2 Audio Codec Profile . . . . . . . . . . . . . . . . . . . 55
A.3 G.726 . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.7.3 RTP profile . . . . . . . . . . . . . . . . . . . . . . . 56
A.4 G.728 . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.8 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.5 G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6. Use of SDPng in conjunction with other IETF Signaling
A.6 G.729 Annex D and E . . . . . . . . . . . . . . . . . . . 56 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 60
A.7 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.1 The Session Announcement Protocol (SAP) . . . . . . . . . 60
A.7.1 GSM Full Rate . . . . . . . . . . . . . . . . . . . . . . 56 6.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . 61
A.7.2 GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . 56 6.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . 67
A.7.3 GSM Enhanced Full Rate . . . . . . . . . . . . . . . . . . 56 6.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . 68
A.8 L8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 69
A.9 L16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 References . . . . . . . . . . . . . . . . . . . . . . . . 70
A.10 LPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 71
A.11 MPA . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 A. Base SDPng Specifications for Audio Codec Descriptions . . 72
A.12 PCMA and PCMU . . . . . . . . . . . . . . . . . . . . . . 57 A.1 DVI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.13 QCELP . . . . . . . . . . . . . . . . . . . . . . . . . . 57 A.2 G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.14 VDVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 A.3 G.726 . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B. SDPng Library for Audio Codec Definitions . . . . . . . . 58 A.4 G.728 . . . . . . . . . . . . . . . . . . . . . . . . . . 73
C. SDPng Library for RTP Payload Format Definitions . . . . . 59 A.5 G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . 73
D. Change History . . . . . . . . . . . . . . . . . . . . . . 60 A.6 G.729 Annex D and E . . . . . . . . . . . . . . . . . . . 74
Full Copyright Statement . . . . . . . . . . . . . . . . . 61 A.7 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.7.1 GSM Full Rate . . . . . . . . . . . . . . . . . . . . . . 74
A.7.2 GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . 74
A.7.3 GSM Enhanced Full Rate . . . . . . . . . . . . . . . . . . 74
A.8 L8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.9 L16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.10 LPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.11 MPA . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.12 PCMA and PCMU . . . . . . . . . . . . . . . . . . . . . . 75
A.13 QCELP . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.14 VDVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B. SDPng Library for Audio Codec Definitions . . . . . . . . 76
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 10, line 47 skipping to change at page 10, line 47
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.
Section 3.3 specifies the mechanisms for external references. 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" format="audio-basic"/>
<rtp:pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/> <rtp:pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/>
skipping to change at page 11, line 24 skipping to change at page 11, line 24
<rtp:pt name="rtp-avp-10" pt="10"> <rtp:pt name="rtp-avp-10" pt="10">
<audio:codec encoding="L16" sampling="44100" channels="2"/> <audio:codec encoding="L16" sampling="44100" channels="2"/>
</rtp:pt> </rtp:pt>
Note: For negotiation between endpoints, it may be helpful to define Note: For negotiation between endpoints, it may be helpful to define
two modes of operation: explicit and implicit. Implicit two modes of operation: explicit and implicit. Implicit
specifications may refer to externally defined entities to minimize specifications may refer to externally defined entities to minimize
traffic volume, explicit specifications would list all external traffic volume, explicit specifications would list all external
definitions used in a description in the "Definitions" section. definitions used in a description in the "Definitions" section.
Again, see Section 3.3 for complete discussion of external Again, see Section 3.4 for complete discussion of external
definitions. definitions.
The "Definitions" section may be empty if all transport, codecs, and The "Definitions" section may be empty if all transport, codecs, and
other pieces needed to the specify Potential and Actual other pieces needed to the specify Potential and Actual
Configurations (as detailed below) are either included by referencing Configurations (as detailed below) are either included by referencing
external definitions or are explicitly described within the external definitions or are explicitly described within the
Configurations themselves. Configurations themselves.
3.1.2 Components & Configurations 3.1.2 Components & Configurations
skipping to change at page 19, line 22 skipping to change at page 19, line 22
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 profile
of RFC1890 etc. of RFC1890 etc.
Section 3.3 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 4. corresponding extension mechanisms is provided in Section 5.
The example below shows how the definition of codecs, transport- The example below shows how the definition of codecs, transport-
variants and configuration of components as well as a conference variants and configuration of components as well as a conference
description are realized in SDPng. 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"
skipping to change at page 20, line 37 skipping to change at page 20, line 37
<repeat interval="7d" duration="1h"/> <repeat interval="7d" duration="1h"/>
<repeat interval="7d" duration="1h" offset="25h"/> <repeat interval="7d" duration="1h" offset="25h"/>
</time> </time>
<info name="interactive-audio" function="speaker"> <info name="interactive-audio" function="speaker">
Audio stream for the different speakers Audio stream for the different speakers
<info> <info>
</conf> </conf>
Section 4 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 A real-world capability description would likely be shorter than the
presented example because the codec and transport definitions can be presented example because the codec and transport definitions can be
factored-out to profile definition documents that would only be factored-out to profile definition documents that would only be
referenced in capability description documents. referenced in capability description documents.
3.3 External Definition Packages 3.3 Referencing Definitions
This section specifies some generic mechanisms for referencing
existing definitions. Referencing existing definition allows to
contruct definitions without having to include all parameters inline.
By using these mechanisms, complex definitions can be derived by
combining multiple basic mechanisms. Common parameters that occur in
different configurations do not have to be repeated but can be
defined once and then be referenced as often as they are needed.
3.3.1 The sdpng:use Element Type
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
following result SDPng document is generated:
<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">
<rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/>
</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>
</alt>
</c>
<cfg>
As a general rule, all references MUST be resolved before sdpng:prop
elements are processed and transformed into attribute values.
3.3.4 Usage of Child Elements and Attributes of sdpng:use Elements
It is also possible to provide arbitrary other elements within a
sdpng:use element (depending on the specific application). All
elements that occur in a sdpng:use element MUST be transfomed to
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>
<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">
<prop name="foo" value="bar"/>
</use>
</rtp:session>
</alt>
</c>
<cfg>
This will be transformed to:
<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">
<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
attribute of its parent element (rtp:udp in this case) according to
the rules specified in Section 3.3.2.
As an abbreviation, the properties for the referenced element do not
have to be specified using sdpng:prop elements within the sdpng:use
element but can also specified directly as attributes of the
sdpng:use element, as shown in the following 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" name="foo" value="bar"/>
</rtp:session>
</alt>
</c>
<cfg>
In this example, the sdp:use element has no child element sdpng:prop
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
There are two types of external definitions: There are two types of external definitions:
Profile Definitions (Section 3.3.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.3.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.
3.3.1 Profile Definitions 3.4.1 Profile Definitions
In order to allow for extensibility it must be possible to define In order to allow for extensibility it must be possible to define
extensions to the basic SDPng configuration options. extensions to the basic SDPng configuration options.
For example, if some application requires the use of a new 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".
skipping to change at page 21, line 36 skipping to change at page 29, line 21
how to specify RTP parameters. Another example would be the audio how to specify RTP parameters. Another example would be the audio
codec profiles that defines how specify audio codec parameters. codec profiles that defines how specify audio codec parameters.
SDPng documents can reference profiles and provide concrete SDPng documents can reference profiles and provide concrete
definitions, for example the definition for the GSM audio codec. definitions, for example the definition for the GSM audio codec.
(This would be done in the "Definitions" section of 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 concrete definitions of configurations can be validated against the
profile definition. profile definition.
3.3.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.
A library is a set of definitions that is conforming to one or more A library is a set of definitions that is conforming to one or more
profile definitions. profile definitions.
skipping to change at page 23, line 13 skipping to change at page 30, line 45
result in in higher latency for the processing of a description result in in higher latency for the processing of a description
document with references to external libraries. In addition, document with references to external libraries. In addition,
there are problems if the referenced libraries cannot be there are problems if the referenced libraries cannot be
accessed by all communication partners. accessed by all communication partners.
o Because of these problematic properties of external libraries, the o Because of these problematic properties of external libraries, the
final SDPng specification will have to provide a set of final SDPng specification will have to provide a set of
recommendations under which circumstances the different mechanisms recommendations under which circumstances the different mechanisms
of referring to external definitions should be used. of referring to external definitions should be used.
3.4 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 basic definitions.
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. Formal Specification 4. Capability Negotiation
SDPng is a description language for both potential configurations
(i.e. capabilities) of participants in multimedia conferencers and
for actual configurations (i.e. final specifications of parameters).
Capability negotiation is the process of generating a usable set of
potential configurations and finally an actual configuration from a
set of potential configurations provided by each potential
participant in a multimedia conference.
SDPng supports the specification of endpoint capabilities and defines
a negotiation process: In a negotiation process, capability
descriptions are exchanged between participants. These descriptions
are processed in a "collapsing" step which results in a set of
commonly supported potential configurations. In a second step, the
final actual configuration is determined that is used for a
conference. This section specifies the usage of SDPng for capability
negotiation. It defines the collapsing algorithm and the procedures
for exchanging SDPng documents in a negotiation phase.
The description language and the rules for the negotiation phase that
are defined here are (in general) independent of the means by which
descriptions are conveyed during a negotiation phase (a reliable
transport service with causal ordering is assumed). There are
however properties and requirements of call signalling protocols that
have been considered to allow for a seamless integration of the
negotiation into the call setup process. For example, in order to be
usable with SIP, it must be possible to negotiate the conference
configuration within the three-way-handshake of the call setup phase.
In order to use SDPng instead of SDP according to the offer/answer
model defined in [15] it must be able to determine an actual
configuration in a single request/response cycle.
4.1 Outline of the Negotiation Process
Conceptually, the negotiation process comprises the following
individual steps (considering two parties, A and B, where A tries to
invite B to a conference). Please note that is describes the steps
of the negotiation process conceptually -- it does not specify
requirements for implementations. Specific procedures that MUST be
followed by implementations are given below.
1. A determines its potential configurations for the components that
should be used in the conference (e.g. "interactive audio" and
"shared whiteboard") and sends a corresponding SDPng instance to
B. This SDPng instances is denoted "CAP(A)".
2. B receives A's SDPng instance and analyzes the set of components
(sdpng:c elements) in the description. For each component that B
wishes to support it generates a list of potential configurations
corresponding to B's capabilities, denoted "CAP(B)".
3. B applies the collapsing function and obtains a list of potential
configurations that both A and B can support, denoted
"CAP(A)xCAP(B) = CAP(AB)".
4. B sends CAP(B) to A.
5. A also applies the collapsing function and obtains "CAP(AB)". At
this step, both A and B know each other capabilities and the
potential configurations that both can support.
6. In order to obtain an actual configuration from the potential
configuration that have been obtained, both particpants have to
pick a subset of the potential configurations should actually be
used in the conference and generate the actual configuration. It
should be noted that it depends on the specific application
whether each component must be assigned exactly one actual
configuration (one sdpng:alt element) or whether it is allowed to
list multiple actual configurations. In this model we assume
that A selects the actual configuration, denoted CFG(AB).
7. A augments CFG(AB) with the transport parameters it intends to
use, e.g., on which endpoint addresses A wishes to receive data,
obtaining CFG_T(A). A sends CFG_T(A) to A.
8. B receives CFG_T(A) and adds its own transport parameters,
resulting in CFG_T(AB). CFG_T(AB) contains the selected actual
configurations and the transport parameters of both A and B (plus
any other SDPng data, e.g., meta-information on the conference).
CFG_T(AB) is the complete conference description. Both A and B
now have the following information:
CAP(A) A's supported potential configurations
CAP(B) B's supported potential configurations
CAP(AB) The set of potential configurations supported by both A
and B.
CFG(AB) The set of actual configurations to be used.
CFG_T(AB) The set of actual configurations to be used augmented
with all required parameters.
In this model, the capability negotiation and configuration exchange
process leads to a description that represents a global view of the
configuration that should be used. This means, it contains the
complete configuration for all participants including per-participant
information like transport parameters.
Note that the model presented here results in four SDPng exchanges.
As an optimization, this procedure can be abbreviated to two
exchanges by including the transport (and other) parameters into the
potential configurations. A embeds its desired transport parameters
into the list of potential configurations and B also sends all
required parameters in the response together with B's potential
configurations. Both A and B can then derive CFG_T(AB). Transport
parameters are usually not negotiable, therefor they have to be
distingiushed them from other configuration information.
Specific procedures for re-negotiation and multi-party negotiation
will be defined in a future version of this document.
4.2 The Collapsing Algorithm
The following procedure MUST be used for the collapsing of two SDPng
document instances into one:
CAP(A) and CAP(B) are the two SDPng description document instances.
For each component (sdpng:c element) in CAP(A) there is a
corresponding component in CAP(B). Components MAY be empty
(containing no sdpng:alt elements) which means that there is no
potential configuration and the component should not be used in the
conference.
Let cfg_AB be the result configuration element, initialized to an
empty sdpng:cfg element.
1. For each component (sdpng:c element) in CAP(A) named c_A
* Let c_AB be the current result component, initialized to an
empty sdpng:c element.
* For each alternative (sdpng:alt element) in c_A named a_A
+ For each session element (name depends on the profile being
used) in a_A named s_A
- Resolve any reference to definition elements recursively
and obtain s1_A, the standalone media session
description. (Refer to Section 4.2.1 for a description
of how to resolve references.)
- Locate the component element that matches c_A in CAP(B)
named (c_B).
- Let a_AB be the current result alternative, initialized
to an empty sdpng:alt element.
- For each alternative (sdpng:alt element) in c_B named
a_B
o For each session element (name depends on the profile
being used) in a_B named s_B
* Let s1_AB be the computed result media session
configuration.
* Resolve any reference to definition elements
recursively and obtain s1_B, the standalone media
session description.
* Apply collapse(s1_A,s2_B) to compute s1_AB, the
collapsed media session configuration.
* If s1_AB is not empty, add s1_AB to a_AB, the set
of sessions for the current result alternative.
- If a_AB is not empty, add a_AB to c_AB.
* If c_AB is not empty, add c_AB to cfg_AB.
The collapsing function for collapsing two elements is specified in
Section 4.2.1.
4.2.1 Collapsing Two Configurations
Before two media session configuration element can be collapsed as
described in Section 4.2 all references to definitions MUST be
resolved. This MUST be performed recursively, i.e. references in
definitions MUST also be resolved. For resolving references, the
algorithm specified in Section 3.3 MUST be used.
By resolving all references two intermediate session configuration
elements are obtained that can then be collapsed according to the
algorithm specified in the following sections.
4.2.1.1 Collapsing of Attributes
In SDPng, capabilities are specified in attributs of XML elements.
Three different types of capabilities with different collapsing rules
are defined. The type of a capability is encoded in the attribute
value.
Set of symbols:
An attribute can specify a set of symbols. When two attributes
are collapsed the result is the intersection of the two sets.
The following examples shows how two elements (with one attribute
representing a set of symbols) originated from two capability
descriptions from participants A and B are collapsed:
Element x in A's capability description:
<x a="[FOO, BAR, 3, 5, 8]"/>
Element x in B's capability description:
<x a="[3, 6, 8]"/>
Result:
<x a="[3, 8]"/>
If the intersection result in an empty set the collapsing process
has failed and there is no common set of values. If the
collapsing of one of an element's attributes with the type "set of
symbols" has failed, the collapsing process of the element itself
MUST be considered to have failed as well.
Numerical ranges:
An attribute can also specify a numercial range. When two
attributes are collapsed the result is the range of values that
represents the intersection of the set of values that is included
in both ranges.
The following examples shows how two elements (with one attribute
representing a numerical range) originated from two capability
descriptions from participants A and B are collapsed:
Element x in A's capability description:
<x a="(2,8)"/>
Element x in B's capability description:
<x a="(5,10)"/>
Result:
<x a="(5,8)"/>
A numerical range is represented by a tuple of comma-separated
numbers in brackets. The first number represents the lower bound
of the range and the second number represents the upper bound.
Let MIN(a,b) be a function that returns the minimum of a and b and
MAX(a,b) be a function that returns the maximum of a and b. Given
two ranges (minA, maxA) and (minB, maxB), the collapsed new range
MUST be calculated using this algorithm:
(MAX(minA, minB), MIN(maxA, maxB))
If this process results in a range with a smaller first value,
the range is invalid and the collapsing has failed since there is
no common range. If the collapsing of one of an element's
attributes with the type "numerical range" has failed, the
collapsing process of the element itself MUST be considered to
have failed as well.
Optional parameters:
A failure of collapsing attributes of the types "set of symbols"
and "numerical range" results in a failure of collapsing the
corresponding element. There is a third type named "optional
parameter" defined, that provides different collapsing rules. An
optional parameter is an attribute with an arbitrary value. When
collapsing two attributes of this type, their values MUST be
tested for equality. If they are equal, the collapsing has been
successful and the attribute MUST appear as is in the result
description. If the attributes' values are different, the
collapsing is considered to have failed and the attribute MUST not
appear in the result description. However, a failure in
collapsing an attribute of type "optional parameter" does not
affect the collapsing of the containing element.
An example for a successful collapsing:
Element x in A's capability description:
<x a="foo"/>
Element x in B's capability description:
<x a="foo"/>
Result:
<x a="foo"/>
An example for an unsuccessful collapsing:
Element x in A's capability description:
<x a="foo"/>
Element x in B's capability description:
<x a="bar"/>
Result:
<x/>
4.2.1.2 Collapsing two Elements
In order to collapse two elements with multiple attributes, the
following algorithm specified below MUST be applied. In general, the
collapsing of two elements (if successful) yields a result element
that contains the collapsed attributes. If the collapsing of two
elements has failed, no result element is generated.
1. For each attribute, determine the type and collapse the attribute
by applying the algorithm for the corresponding attribute type.
2. If an attribute with a different type than "optional parameter"
does not occur in both elements, the collapsing for this element
MUST be considered to have failed.
3. If the collapsing of any attribute with a different type than
"optional parameter" has failed, the collapsing of the element
itself MUST be considered to have failed.
4. If the collapsing has been successful, obtain the result element
by using the same element name (GI) and the attributes with their
collapsed values. Exclude any attribute of type "optional
parameter" that has failed to collapse.
An example:
Element x in A's capability description:
<x a="[FOO, BAR, 3, 5, 8]" b="(2,8)" c="foo"/>
Element x in B's capability description:
<x a="[3, 6, 8]" b="(5,10)" c="bar"/>
Result:
<x a="[3, 8]" b="(5,8)"/>
4.2.1.3 Collapsing nested Elements
In order to collapse nested elements the following algorithm MUST be
applied:
In analogy to attributes representing optional parameters there is
also the possibility to mark elements as optional for the negotiation
process. Elements MAY provide an attribute names "status" that
contains a symbol or a comma-separated list of symbols as its value.
If the value "opt" occurs in the list of a "status" attribute of both
elements to be collapsed, the elements to be collapsed are treated as
optional. This means, if the collapsing of the attributes has failed
(according to the rules specified in Section 4.2.1.2), the collapsing
process does not yield a result element but is still treated as
"successful", i.e., further collapsing operation on other elements
can continue. The semantics of optional elements are that they
describe optional features that may be supported and selected during
a negotiation phase but do not neccessarily have to be supported by
all participants in order to achieve interoperability. The example
below shows how to generate a result element in the presence of
optional child elements that have failed to collapse.
The collapsing algorithm for nested elements:
1. Let x be an element that occurs in the capability description of
two participants A and B and that should be collapsed.
2. Collapse the attributes of the element x using the algorithm
specified in Section 4.2.1.2. If the collapsing has failed
according to the rules of Section 4.2.1.2 and if the elements to
be collapsed are not marked as optional, the collapsing of the
element and all of its children MUST be considered to have
failed. The collapsing MUST be stopped. If the collapsing has
failed and both elements have been marked as optional, the child
elements MUST NOT be processed. In this case, the collapsing
process does not yield a result element but the collapsing of
other elements (sibling or parent elements) MUST be continued.
3. If the collapsing has been successful according to the rules of
Section 4.2.1.2, the child elements of A's and B's x element MUST
be processed. If there are no child elements in both A's and B's
content the collapsing has been successful and can be terminated.
If either A's or B's x element provides child elements, apply the
following algorithm to each child element named c of participant
A's element x:
1. Find a corresponding element (same GI) in the set of
participant B's child elements. If no matching element has
been found, the collapsing of element x MUST be considered to
have failed.
2. If a matching element has been found, apply the collapsing
algorithm recursively. As long as the collapsing is
successful, the result of collapsing each element is
transferred to the result element, such that the resulting
element tree is isomorphic to both A's and B's element tree.
If there are elements in B's x element that have not been
processed (because there is no corresponding element in A's x
element), the collapsing MUST be considered to have failed and
MUST be stopped.
An example:
Element x in A's capability description:
<x a="[FOO, BAR, 3, 5, 8]" b="(2,8)" c="foo">
<y b="[UVW, XYZ]"/>
</a>
Element x in B's capability description:
<x a="[3, 6, 8]" b="(5,10)" c="bar">
<y b="[RST, XYZ]"/>
</a>
Result:
<x a="[3, 8]" b="(5,8)">
<y b="[XYZ]"/>
</a>
An example for collapsing optional elements:
Element x in A's capability description:
<x a="[FOO, BAR, 3, 5, 8]" b="(2,8)" c="foo">
<y status="opt" b="[UVW, XYZ]"/>
</a>
Element x in B's capability description:
<x a="[3, 6, 8]" b="(5,10)" c="bar">
<y status="opt" b="[RST]"/>
</a>
Result:
<x a="[3, 8]" b="(5,8)"/>
4.2.2 Deriving an actual Configuration
The result of a capability negotiation process is a potential
configuration, i.e., a description potentially containing multiple
alternatives per component. The alternative themselves may provide
elements that represent collapsed capabilities. In order to derive
an actual configuration, the following problems must be addressed:
1. For each component (sdpng:c element) an appropriate alternative
(sdpng:alt element) has to be selected. It is conceivable that
the order of the alternatives in the description is used as a
preference indicator. More details have to be specified in a
future version of this document.
2. If the description of the selected alternatives contains
attributes with numerical ranges or sets of symbols with more
than one entry, those attributes either have to be transformed
that they represent a single value or participants have to agree
that an actual configuration may contain ranges and sets of
symbols. The semantics of these variable actual configurations
will have to specified in later versions of this document. For
example, for certain applications it may be desireable to agree
on ranges of values for certain attributes during a capability
negotiating meaning that any of the values of the range are
supported (and have to be supported).
The specific procedures to determine an actual configuration have to
be defined in a later version on this document.
5. Formal Specification
This section defines the SDPng syntax and the use of XML mechanisms, This section defines the SDPng syntax and the use of XML mechanisms,
such as XML Namespace and XML Schema. Section 4.1 defines the such as XML Namespace and XML Schema. Section 5.1 defines the
relation between SDPng and XML Schema, Section 4.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 4.3 list requirements for conforming to the SDPng schema, Section 5.3 list requirements for
profile definitions, Section 4.4 specifies specific requirements for profile definitions, Section 5.4 specifies specific requirements for
conforming documents and Section 4.5 lists requirements for the conforming documents and Section 5.5 lists requirements for the
definition of SDPng libraries. definition of SDPng libraries.
Section 4.7 defines the SDPng base schema, Section 4.7.2 defines the Section 5.7 defines the SDPng base schema, Section 5.7.2 defines the
profile for audio codec definitions and Section 4.7.3 defines the profile for audio codec definitions and Section 5.7.3 defines the
profile for RTP payload type definitions. profile for RTP payload type definitions.
4.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 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 24, line 45 skipping to change at page 42, line 45
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 4.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:sdpng="http://www.iana.org/sdpng"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance"
xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd"> xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd">
XML-Schema specifies that documents can assign a namespace when XML-Schema specifies that documents can assign a namespace when
skipping to change at page 25, line 24 skipping to change at page 43, line 24
for the SDPng schema definition, in order to allow for very simple for the SDPng schema definition, in order to allow for very simple
implementations. The well-known SDPng namespace prefix is "sdpng". implementations. The well-known SDPng namespace prefix is "sdpng".
Conforming Documents, profile definition and libraries MUST use this Conforming Documents, profile definition and libraries MUST use this
namespace name and this namespace prefix. 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.
4.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
"Configurations" sections, followed by one "Constraints" sections "Configurations" sections, followed by one "Constraints" sections
followed by a "Conference" section (for meta-information). Each followed by a "Conference" section (for meta-information). Each
document MUST provide the elements for definitions, configurations, document MUST provide the elements for definitions, configurations,
constraints and conference information in exactly this order, whereby constraints and conference information in exactly this order, whereby
only the configurations section is MANDATORY. Refer to Section 4.7 only the configurations section is MANDATORY. Refer to Section 5.7
for a formal definition of the SDPng base schema and the specific for a formal definition of the SDPng base schema and the specific
element types for definitions, configurations, constraints and element types for definitions, configurations, constraints and
conference information. conference information.
The SDPng base schema also specifies "abstract" base data types (by The SDPng base schema also specifies "abstract" base data types (by
means of XML-Schema type definitions) for elements that MUST be used means of XML-Schema type definitions) for elements that MUST be used
by documents in the corresponding sections. The base data types by documents in the corresponding sections. The base data types
provide common required attributes, e.g. a "name" attribute for provide common required attributes, e.g. a "name" attribute for
naming definition elements. naming definition elements.
skipping to change at page 26, line 11 skipping to change at page 44, line 11
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 concrete type definitions. The type definitions can be identified as
allowed element types for the content models that are specified in allowed element types for the content models that are specified in
the base SDPng schema definition. This allows for automatic the base SDPng schema definition. This allows for automatic
validation of profile definitions and facilitates the extension of validation of profile definitions and facilitates the extension of
SDPng. SDPng.
4.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.
The library of commonly used definitions provides data types for IP The library of commonly used definitions provides data types for IP
(and other) addresses. (and other) addresses.
A profile definition MUST import (using the XML-Schema import A profile definition MUST import (using the XML-Schema import
mechanism) the base SDPng schema definition and MUST provide an mechanism) the base SDPng schema definition and MUST provide an
extension definition, e.g., specializations of base element types. A extension definition, e.g., specializations of base element types. A
skipping to change at page 27, line 25 skipping to change at page 45, line 25
This type definition is then used to define an XML element type This type definition is then used to define an XML element type
called "codec". called "codec".
Example: Example:
<xsd:element name="codec" type="AudioCodec"/> <xsd:element name="codec" type="AudioCodec"/>
When used by SDPng documents, the general identifier is qualified When used by SDPng documents, the general identifier is qualified
with a namespace prefix, for example as in: "audio:codec". with a namespace prefix, for example as in: "audio:codec".
4.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:sdpng="http://www.iana.org/sdpng"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance"
xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd" xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd"
xmlns:audio="http://www.iana.org/sdpng/audio" xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"> xmlns:rtp="http://www.iana.org/sdpng/rtp">
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 4.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 6 below). Schema definitions in documents (see Section 7 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"):
skipping to change at page 28, line 28 skipping to change at page 46, line 28
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-
codes as seen before. codes as seen before.
4.5 Libraries 5.5 Libraries
SDPng libraries are collections of definitions that are referenced by SDPng libraries are collections of definitions that are referenced by
documents. Libraries are thus independent, valid SDPng documents. documents. Libraries are thus independent, valid SDPng documents.
For example, the definition of the different audio codecs as shown in For example, the definition of the different audio codecs as shown in
the previous example could be provided by a library that can be the previous example could be provided by a library that can be
referenced by documents without having to define such common codecs referenced by documents without having to define such common codecs
in every document. in every document.
The XML mechanism XInclude [12] is used for referencing libraries in The XML mechanism XInclude [12] is used for referencing libraries in
skipping to change at page 29, line 15 skipping to change at page 47, line 15
An alternative for XInclude would be to use references that are An alternative for XInclude would be to use references that are
resolved by applications. For XML, this would probably mean to use resolved by applications. For XML, this would probably mean to use
an XLink-based approach. This solution would require the definition an XLink-based approach. This solution would require the definition
of an SDPng link element type and require applications to support of an SDPng link element type and require applications to support
XLink (or at least the SDPng-relevant subset thereof). The inclusion XLink (or at least the SDPng-relevant subset thereof). The inclusion
at the application level is however problematic, because it does not at the application level is however problematic, because it does not
result in a common integrated XML document infoset but would require result in a common integrated XML document infoset but would require
applications to handle multiple infosets, i.e. multiple documents. applications to handle multiple infosets, i.e. multiple documents.
4.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.
4.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". That means, the general SDPng
identifiers can be used without namespace prefixes. identifiers can be used without namespace prefixes.
4.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.
Attribute names MUST NOT be fully qualified, they are considered to Attribute names MUST NOT be fully qualified, they are considered to
have the same namespace as their corresponding elements. have the same namespace as their corresponding elements.
skipping to change at page 30, line 14 skipping to change at page 48, line 14
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 process-able by non-Schema-
aware XML parsers by requiring all element names to be fully aware XML parsers by requiring all element names to be fully
qualified (no "local elements"). qualified (no "local elements").
4.6.3 Fixed Namespace Prefixes 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 namespaces names are associated with fixed
prefixes, i.e. document instances and libraries MUST always use these prefixes, 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".
4.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 4.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 4.7.2 contains a profile for audio codecs. 2. Section 5.7.2 contains a profile for audio codecs.
3. Section 4.7.3 contains a profile for RTP payload type 3. Section 5.7.3 contains a profile for RTP payload type
definitions. definitions.
4.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.
In general, these extension are implemented by deriving profile In general, these extension are implemented by deriving profile
definitions from SDPng base definitions. The deployed XML Schema definitions from SDPng base definitions. The deployed XML Schema
skipping to change at page 37, line 21 skipping to change at page 55, line 21
<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>
4.7.2 Audio Codec Profile 5.7.2 Audio Codec Profile
The following profile defines an element type that can be used for The following profile defines an element type that can be used for
specifying audio codec characteristics. The element "audio:codec" is specifying audio codec characteristics. The element "audio:codec" is
of type "audio:AudioCodec" which is derived from the SDPng base type of type "audio:AudioCodec" which is derived from the SDPng base type
"sdpng:Definition". The element "audio:codec" is declared to have "sdpng:Definition". The element "audio:codec" is declared to have
the 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 38, line 36 skipping to change at page 56, line 36
<xsd:element name="codec" substitutionGroup="sdpng:d"> <xsd:element name="codec" substitutionGroup="sdpng:d">
<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>
4.7.3 RTP profile 5.7.3 RTP profile
The following profile defines element types that can be used for The following profile defines element types that can be used for
specifying RTP payload types and RTP session configurations. The specifying RTP payload types and RTP session configurations. The
element "rtp:pt" is of type "rtp:PayloadType" which is derived from element "rtp:pt" is of type "rtp:PayloadType" which is derived from
the SDPng base type "sdpng:Definition". The element "rtp:pt" is the SDPng base type "sdpng:Definition". The element "rtp:pt" is
declared to have the 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 41, line 5 skipping to change at page 59, line 5
</xsd:choice> </xsd:choice>
<xsd:attribute name="addr" type="rtp:IP4Addr"/> <xsd:attribute name="addr" type="rtp:IP4Addr"/>
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="udp" type="rtp:UDP"/> <xsd:element name="udp" type="rtp:UDP"/>
</xsd:schema> </xsd:schema>
4.8 Issues 5.8 Issues
o Libraries provide partially specified definitions, i.e. without o Libraries provide partially specified definitions, i.e. without
transport parameters. How can SDPng documents reference the transport parameters. How can SDPng documents reference the
definitions and augment them with specific transport parameters? definitions and augment them with specific transport parameters?
o Referencing extension profiles: XML-Schema does not support the o Referencing extension profiles: XML-Schema does not support the
declaration of multiple schemas via the schemaLocation attribute. declaration of multiple schemas via the schemaLocation attribute.
Conceivable solution: When extension profiles are used, the SDPng Conceivable solution: When extension profiles are used, the SDPng
description is a "multi-part" object, that consists of an description is a "multi-part" object, that consists of an
integrating schema definition (that references all necessary integrating schema definition (that references all necessary
skipping to change at page 42, line 5 skipping to change at page 60, line 5
o Uniqueness of attribute values: When libraries are used they will o Uniqueness of attribute values: When libraries are used they will
contain definition elements with "name" attributes for later contain definition elements with "name" attributes for later
referencing. How to avoid name clashes for those identifiers? referencing. How to avoid name clashes for those identifiers?
When an SDPng document uses libraries from different sources they When an SDPng document uses libraries from different sources they
could be incompatible because of name collisions. Possible could be incompatible because of name collisions. Possible
solution: Prefix such IDs with a namespace name (either explicitly solution: Prefix such IDs with a namespace name (either explicitly
or implicitly by interpreting applications). The explicit or implicitly by interpreting applications). The explicit
prefixes have the advantage that no special knowledge would be prefixes have the advantage that no special knowledge would be
required to resolve links at the cost of very long ID values. required to resolve links at the cost of very long ID values.
5. Use of SDPng in conjunction with other IETF Signaling Protocols 6. 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 42, line 36 skipping to change at page 60, line 36
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.
5.1 The Session Announcement Protocol (SAP) 6.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 43, line 19 skipping to change at page 61, line 19
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.
5.2 Session Initiation Protocol (SIP) 6.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 49, line 42 skipping to change at page 67, line 42
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 adding "B-rcv" to the
attribute "transport" of the rtp:session element. (B could also have attribute "transport" of the rtp:session element. (B could also have
used the rtp:udp element inside the rtp:session element, but this used the rtp:udp element inside the rtp:session element, but this
example intends to demonstrate how to reference multiple transport example intends to demonstrate how to reference multiple transport
definitions by using the attribute "transport"). definitions by using the attribute "transport").
5.3 Real-Time Streaming Protocol (RTSP) 6.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.
5.4 Media Gateway Control Protocol (MEGACOP) 6.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.
6. Open Issues 7. Open Issues
Definition of baseline libraries Definition of baseline libraries
A registry (reuse of SDP mechanisms and names etc.) needs to be A registry (reuse of SDP mechanisms and names etc.) needs to be
set up. set up.
Negotiation mechanisms for multiparty conferencing need to be Negotiation mechanisms for multiparty conferencing need to be
formalized. formalized.
Mapping to other media description formats (SDP, H.245, ...) Mapping to other media description formats (SDP, H.245, ...)
skipping to change at page 53, line 9 skipping to change at page 71, line 9
http://www.w3.org/TR/2001/WD-xinclude-20010516, May 2001. http://www.w3.org/TR/2001/WD-xinclude-20010516, May 2001.
[13] World Wide Web Consortium (W3C), "XML Schema Part 1: [13] World Wide Web Consortium (W3C), "XML Schema Part 1:
Structures", Version http://www.w3.org/TR/2001/REC-xmlschema-1- Structures", Version http://www.w3.org/TR/2001/REC-xmlschema-1-
20010502/, Status W3C Recommendation, May 2001. 20010502/, Status W3C Recommendation, May 2001.
[14] World Wide Web Consortium (W3C), "XML Schema Part 2: [14] World Wide Web Consortium (W3C), "XML Schema Part 2:
Datatypes", Version http://www.w3.org/TR/2001/REC-xmlschema-2- Datatypes", Version http://www.w3.org/TR/2001/REC-xmlschema-2-
20010502/, Status W3C Recommendation, May 2001. 20010502/, Status W3C Recommendation, May 2001.
[15] 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 Authors' Addresses
Dirk Kutscher Dirk Kutscher
TZI, Universitaet Bremen TZI, Universitaet Bremen
Bibliothekstr. 1 Bibliothekstr. 1
Bremen 28359 Bremen 28359
Germany Germany
Phone: +49.421.218-7595, sip:dku@tzi.org Phone: +49.421.218-7595, sip:dku@tzi.org
Fax: +49.421.218-7000 Fax: +49.421.218-7000
skipping to change at page 60, line 7 skipping to change at page 78, line 7
<rtp:pt name="rtp-avp-0" pt="0" format="pcmu"/> <rtp:pt name="rtp-avp-0" pt="0" format="pcmu"/>
<rtp:pt name="rtp-avp-8" pt="8" format="pcma"/> <rtp:pt name="rtp-avp-8" pt="8" format="pcma"/>
<rtp:pt name="rtp-avp-12" pt="12" format="qcelp"/> <rtp:pt name="rtp-avp-12" pt="12" format="qcelp"/>
</def> </def>
Appendix D. Change History Appendix D. Change History
draft-ietf-mmusic-sdpng-04.txt
* New section on capability negotiation (Section 4).
* New section on referencing definitions (Section 3.3).
* New section on properties (Section 3.3.2).
* New section on definition groups (Section 3.3.3).
draft-ietf-mmusic-sdpng-03.txt draft-ietf-mmusic-sdpng-03.txt
* Extension of the SDPng schema (use of Xlinks etc.) * Extension of the SDPng schema (use of Xlinks etc.)
* Clarification in the text * Clarification in the text
* Fixed examples * Fixed examples
* Added example libraries as appendices * Added example libraries as appendices
* More details on usage with SIP, including examples. * More details on usage with SIP, including examples.
draft-ietf-mmusic-sdpng-02.txt draft-ietf-mmusic-sdpng-02.txt
* Added a section on formal specification mechanisms (Section 4). * Added a section on formal specification mechanisms (Section 5).
draft-ietf-mmusic-sdpng-01.txt draft-ietf-mmusic-sdpng-01.txt
* renamed section "Syntax Proposal" to "Syntax Definition * renamed section "Syntax Proposal" to "Syntax Definition
Mechanisms". More text on DTD vs. schema. Edited the example Mechanisms". More text on DTD vs. schema. Edited the example
description. description.
* updated example definitions in section "Definitions" and * updated example definitions in section "Definitions" and
"Components & Configurations" "Components & Configurations"
* section "Session Attributes" replaces section "Session" * section "Session Attributes" replaces section "Session"
* new appendix on audio codec definitions * new appendix on audio codec definitions
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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