idnits 2.17.1
draft-ietf-mmusic-sdpng-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 84 instances of too long lines in the document, the longest
one being 12 characters in excess of 72.
** There are 182 instances of lines with control characters in the document.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 956: '... for the alternative "rtp-avp-10" MUST...'
RFC 2119 keyword, line 958: '...e" elements itself, those MUST also be...'
RFC 2119 keyword, line 1009: '... MUST be transformed to attributes o...'
RFC 2119 keyword, line 1011: '... MUST be overwritten....'
RFC 2119 keyword, line 1072: '... element MUST be replaced by the con...'
(57 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
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.
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 01, 2002) is 8092 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: 'RFC2327' on line 632
== Unused Reference: '3' is defined on line 3031, but no explicit reference
was found in the text
== Unused Reference: '6' is defined on line 3042, but no explicit reference
was found in the text
== Unused Reference: '7' is defined on line 3046, but no explicit reference
was found in the text
== Unused Reference: '8' is defined on line 3049, but no explicit reference
was found in the text
== Unused Reference: '10' is defined on line 3055, but no explicit
reference was found in the text
-- Possible downref: Normative reference to a draft: ref. '1'
** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566)
** Obsolete normative reference: RFC 1889 (ref. '3') (Obsoleted by RFC 3550)
** Obsolete normative reference: RFC 1890 (ref. '4') (Obsoleted by RFC 3551)
== Outdated reference: A later version (-13) exists of
draft-ietf-avt-profile-new-10
-- Possible downref: Normative reference to a draft: ref. '5'
** Obsolete normative reference: RFC 2733 (ref. '7') (Obsoleted by RFC 5109)
** Downref: Normative reference to an Informational RFC: RFC 2354 (ref. '8')
** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '9')
-- Possible downref: Non-RFC (?) normative reference: ref. '10'
-- Possible downref: Non-RFC (?) normative reference: ref. '11'
-- Possible downref: Non-RFC (?) normative reference: ref. '12'
-- Possible downref: Non-RFC (?) normative reference: ref. '13'
-- Possible downref: Non-RFC (?) normative reference: ref. '14'
== Outdated reference: A later version (-02) exists of
draft-ietf-mmusic-sdp-offer-answer-01
Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments
(--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group Kutscher
3 Internet-Draft Ott
4 Expires: August 30, 2002 Bormann
5 TZI, Universitaet Bremen
6 March 01, 2002
8 Session Description and Capability Negotiation
9 draft-ietf-mmusic-sdpng-04.txt
11 Status of this Memo
13 This document is an Internet-Draft and is in full conformance with
14 all provisions of Section 10 of RFC2026.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
19 Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on August 30, 2002.
34 Copyright Notice
36 Copyright (C) The Internet Society (2002). All Rights Reserved.
38 Abstract
40 This document defines a language for describing multimedia sessions
41 with respect to configuration parameters and capabilities of end-
42 systems.
44 This document is a product of the Multiparty Multimedia Session
45 Control (MMUSIC) working group of the Internet Engineering Task
46 Force. Comments are solicited and should be addressed to the working
47 group's mailing list at mmusic@ietf.org and/or the authors.
49 Document Revision
50 $Revision: 4.23 $
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
55 2. Terminology and System Model . . . . . . . . . . . . . . . 6
56 3. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . 9
57 3.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . 9
58 3.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
59 3.1.2 Components & Configurations . . . . . . . . . . . . . . . 11
60 3.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . 13
61 3.1.4 Session Attributes . . . . . . . . . . . . . . . . . . . . 14
62 3.1.4.1 Owner . . . . . . . . . . . . . . . . . . . . . . . . . . 15
63 3.1.4.2 Session Identification . . . . . . . . . . . . . . . . . . 15
64 3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) . . . 16
65 3.1.4.4 Component Semantic Specification . . . . . . . . . . . . . 17
66 3.2 Syntax Definition Mechanisms . . . . . . . . . . . . . . . 18
67 3.3 Referencing Definitions . . . . . . . . . . . . . . . . . 20
68 3.3.1 The sdpng:use Element Type . . . . . . . . . . . . . . . . 21
69 3.3.2 Properties . . . . . . . . . . . . . . . . . . . . . . . . 22
70 3.3.3 Definition Groups . . . . . . . . . . . . . . . . . . . . 23
71 3.3.4 Usage of Child Elements and Attributes of sdpng:use
72 Elements . . . . . . . . . . . . . . . . . . . . . . . . . 26
73 3.4 External Definition Packages . . . . . . . . . . . . . . . 28
74 3.4.1 Profile Definitions . . . . . . . . . . . . . . . . . . . 28
75 3.4.2 Library Definitions . . . . . . . . . . . . . . . . . . . 29
76 3.5 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 30
77 4. Capability Negotiation . . . . . . . . . . . . . . . . . . 32
78 4.1 Outline of the Negotiation Process . . . . . . . . . . . . 32
79 4.2 The Collapsing Algorithm . . . . . . . . . . . . . . . . . 34
80 4.2.1 Collapsing Two Configurations . . . . . . . . . . . . . . 35
81 4.2.1.1 Collapsing of Attributes . . . . . . . . . . . . . . . . . 35
82 4.2.1.2 Collapsing two Elements . . . . . . . . . . . . . . . . . 38
83 4.2.1.3 Collapsing nested Elements . . . . . . . . . . . . . . . . 39
84 4.2.2 Deriving an actual Configuration . . . . . . . . . . . . . 41
85 5. Formal Specification . . . . . . . . . . . . . . . . . . . 42
86 5.1 XML Schema as a Definition Mechanism . . . . . . . . . . . 42
87 5.2 SDPng Schema . . . . . . . . . . . . . . . . . . . . . . . 43
88 5.3 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 44
89 5.4 SDPng Documents . . . . . . . . . . . . . . . . . . . . . 45
90 5.5 Libraries . . . . . . . . . . . . . . . . . . . . . . . . 46
91 5.6 Details on the use of specific XML Mechanisms . . . . . . 47
92 5.6.1 Default Namespace . . . . . . . . . . . . . . . . . . . . 47
93 5.6.2 Qualified Locals . . . . . . . . . . . . . . . . . . . . . 47
94 5.6.3 Fixed Namespace Prefixes . . . . . . . . . . . . . . . . . 48
95 5.7 SDPng Schema Definitions . . . . . . . . . . . . . . . . . 48
96 5.7.1 SDPng Base Definition . . . . . . . . . . . . . . . . . . 48
97 5.7.2 Audio Codec Profile . . . . . . . . . . . . . . . . . . . 55
98 5.7.3 RTP profile . . . . . . . . . . . . . . . . . . . . . . . 56
99 5.8 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 59
100 6. Use of SDPng in conjunction with other IETF Signaling
101 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 60
102 6.1 The Session Announcement Protocol (SAP) . . . . . . . . . 60
103 6.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . 61
104 6.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . 67
105 6.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . 68
106 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 69
107 References . . . . . . . . . . . . . . . . . . . . . . . . 70
108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 71
109 A. Base SDPng Specifications for Audio Codec Descriptions . . 72
110 A.1 DVI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
111 A.2 G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 73
112 A.3 G.726 . . . . . . . . . . . . . . . . . . . . . . . . . . 73
113 A.4 G.728 . . . . . . . . . . . . . . . . . . . . . . . . . . 73
114 A.5 G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . 73
115 A.6 G.729 Annex D and E . . . . . . . . . . . . . . . . . . . 74
116 A.7 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
117 A.7.1 GSM Full Rate . . . . . . . . . . . . . . . . . . . . . . 74
118 A.7.2 GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . 74
119 A.7.3 GSM Enhanced Full Rate . . . . . . . . . . . . . . . . . . 74
120 A.8 L8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
121 A.9 L16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
122 A.10 LPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
123 A.11 MPA . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
124 A.12 PCMA and PCMU . . . . . . . . . . . . . . . . . . . . . . 75
125 A.13 QCELP . . . . . . . . . . . . . . . . . . . . . . . . . . 75
126 A.14 VDVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
127 B. SDPng Library for Audio Codec Definitions . . . . . . . . 76
128 C. SDPng Library for RTP Payload Format Definitions . . . . . 77
129 D. Change History . . . . . . . . . . . . . . . . . . . . . . 78
130 Full Copyright Statement . . . . . . . . . . . . . . . . . 79
132 1. Introduction
134 Multiparty multimedia conferencing is one of the applications that
135 require dynamic interchange of end-system capabilities and the
136 negotiation of a parameter set that is appropriate for all sending
137 and receiving end-systems in a conference. For some applications,
138 e.g. for loosely coupled conferences or for broadcast scenarios, it
139 may be sufficient to simply have session parameters be fixed by the
140 initiator of a conference. In such a scenario no negotiation is
141 required because only those participants with media tools that
142 support the predefined settings can join a media session and/or a
143 conference.
145 This approach is applicable for conferences that are announced some
146 time ahead of the actual start date of the conference. Potential
147 participants can check the availability of media tools in advance and
148 tools such as session directories can configure media tools upon
149 startup. This procedure however fails to work for conferences
150 initiated spontaneously including Internet phone calls or ad-hoc
151 multiparty conferences. Fixed settings for parameters such as media
152 types, their encoding etc. can easily inhibit the initiation of
153 conferences, for example in situations where a caller insists on a
154 fixed audio encoding that is not available at the callee's end-
155 system.
157 To allow for spontaneous conferences, the process of defining a
158 conference's parameter set must therefore be performed either at
159 conference start (for closed conferences) or maybe (potentially) even
160 repeatedly every time a new participant joins an active conference.
161 The latter approach may not be appropriate for every type of
162 conference without applying certain policies: For conferences with
163 TV-broadcast or lecture characteristics (one main active source) it
164 is usually not desired to re-negotiate parameters every time a new
165 participant with an exotic configuration joins because it may
166 inconvenience existing participants or even exclude the main source
167 from media sessions. But conferences with equal "rights" for
168 participants that are open for new participants on the other hand
169 would need a different model of dynamic capability negotiation, for
170 example a telephone call that is extended to a 3-parties conference
171 at some time during the session.
173 SDP [2] allows to specify multimedia sessions (i.e. conferences,
174 "session" as used here is not to be confused with "RTP session"!) by
175 providing general information about the session as a whole and
176 specifications for all the media streams (RTP sessions and others) to
177 be used to exchange information within the multimedia session.
179 Currently, media descriptions in SDP are used for two purposes:
181 o to describe session parameters for announcements and invitations
182 (the original purpose of SDP) and
184 o to describe the capabilities of a system and possibly provide a
185 choice between a number of alternatives (which SDP was not
186 designed for).
188 A distinction between these two "sets of semantics" is only made
189 implicitly.
191 This document is based upon a set of requirements specified in a
192 companion document [1]. In the following, we first introduce a model
193 for session description and capability negotiation as well as the
194 basic terms used throughout this specification (section 2). Next, we
195 outline the concept for the concepts underlying SDPng and introduce
196 the syntactical components step by step in section 3. In section 4,
197 we provide a formal definition of the SDPng session description
198 language. Finally, we overview aspects of using SDPng with various
199 IETF signaling protocols in section 5. In Appendix A, we provide
200 basic audio codec and payload type definitions that are subsumed in
201 SDPng libraries in Appendix B and Appendix C.
203 The next version of this draft will only contain the formal
204 specification of the language itself. Requirements and the
205 description of the system model will be moved to a separate document.
207 2. Terminology and System Model
209 Any (computer) system has, at a time, a number of rather fixed
210 hardware as well as software resources. These resources ultimately
211 define the limitations on what can be captured, displayed, rendered,
212 replayed, etc. with this particular device. We term features enabled
213 and restricted by these resources "system capabilities".
215 Example: System capabilities may include: a limitation of the
216 screen resolution for true color by the graphics board; available
217 audio hardware or software may offer only certain media encodings
218 (e.g. G.711 and G.723.1 but not GSM); and CPU processing power and
219 quality of implementation may constrain the possible video
220 encoding algorithms.
222 In multiparty multimedia conferences, participants employ different
223 "components" in conducting the conference.
225 Example: In lecture multicast conferences one component might be
226 the voice transmission for the lecturer, another the transmission
227 of video pictures showing the lecturer and the third the
228 transmission of presentation material.
230 Depending on system capabilities, user preferences and other
231 technical and political constraints, different configurations can be
232 chosen to accomplish the use of these components in a conference.
234 Each component can be characterized at least by (a) its intended use
235 (i.e. the function it shall provide) and (b) one or more possible
236 ways to realize this function. Each way of realizing a particular
237 function is referred to as a "configuration".
239 Example: A conference component's intended use may be to make
240 transparencies of a presentation visible to the audience on the
241 Mbone. This can be achieved either by a video camera capturing
242 the image and transmitting a video stream via some video tool or
243 by loading a copy of the slides into a distributed electronic
244 white-board. For each of these cases, additional parameters may
245 exist, variations of which lead to additional configurations (see
246 below).
248 Two configurations are considered different regardless of whether
249 they employ entirely different mechanisms and protocols (as in the
250 previous example) or they choose the same and differ only in a single
251 parameter.
253 Example: In case of video transmission, a JPEG-based still image
254 protocol may be used, H.261 encoded CIF images could be sent, as
255 could H.261 encoded QCIF images. All three cases constitute
256 different configurations. Of course there are many more detailed
257 protocol parameters.
259 Each component's configurations are limited by the participating
260 system's capabilities. In addition, the intended use of a component
261 may constrain the possible configurations further to a subset
262 suitable for the particular component's purpose.
264 Example: In a system for highly interactive audio communication
265 the component responsible for audio may decide not to use the
266 available G.723.1 audio codec to avoid the additional latency but
267 only use G.711. This would be reflected in this component only
268 showing configurations based upon G.711. Still, multiple
269 configurations are possible, e.g. depending on the use of A-law
270 or u-Law, packetization and redundancy parameters, etc.
272 In modelling multimedia sessions, we distinguish two types of
273 configurations:
275 o potential configurations
276 (a set of any number of configurations per component) indicating a
277 system's functional capabilities as constrained by the intended
278 use of the various components;
280 o actual configurations
281 (exactly one per instance of a component) reflecting the mode of
282 operation of this component's particular instantiation.
284 Example: The potential configuration of the aforementioned video
285 component may indicate support for JPEG, H.261/CIF, and
286 H.261/QCIF. A particular instantiation for a video conference may
287 use the actual configuration of H.261/CIF for exchanging video
288 streams.
290 In summary, the key terms of this model are:
292 o A multimedia session (streaming or conference) consists of one or
293 more conference components for multimedia "interaction".
295 o A component describes a particular type of interaction (e.g. audio
296 conversation, slide presentation) that can be realized by means of
297 different applications (possibly using different protocols).
299 o A configuration is a set of parameters that are required to
300 implement a certain variation (realization) of a certain
301 component. There are actual and potential configurations.
303 * Potential configurations describe possible configurations that
304 are supported by an end-system.
306 * An actual configuration is an "instantiation" of one of the
307 potential configurations, i.e. a decision how to realize a
308 certain component.
310 In less abstract words, potential configurations describe what a
311 system can do ("capabilities") and actual configurations describe
312 how a system is configured to operate at a certain point in time
313 (media stream spec).
315 To decide on a certain actual configuration, a negotiation process
316 needs to take place between the involved peers:
318 1. to determine which potential configuration(s) they have in
319 common, and
321 2. to select one of this shared set of common potential
322 configurations to be used for information exchange (e.g. based
323 upon preferences, external constraints, etc.).
325 In SAP-based [9] session announcements on the Mbone, for which SDP
326 was originally developed, the negotiation procedure is non-existent.
327 Instead, the announcement contains the media stream description sent
328 out (i.e. the actual configurations) which implicitly describe what a
329 receiver must understand to participate.
331 In point-to-point scenarios, the negotiation procedure is typically
332 carried out implicitly: each party informs the other about what it
333 can receive and the respective sender chooses from this set a
334 configuration that it can transmit.
336 Capability negotiation must not only work for 2-party conferences but
337 is also required for multi-party conferences. Especially for the
338 latter case it is required that the process to determine the subset
339 of allowable potential configurations is deterministic to reduce the
340 number of required round trips before a session can be established.
341 For instance, in order to be used with SIP, the capability
342 negotiation is required to work with the offer/answer model that is
343 for session initiation with SIP -- limiting the negotiation to
344 exactly one round trip.
346 The requirements for the SDPng specification, subdivided into general
347 requirements and requirements for session descriptions, potential and
348 actual configurations as well as negotiation rules, are captured in a
349 companion document [1].
351 3. SDPng
353 This section introduces the underlying concepts of the Session
354 Description Protocol - next generation (SDPng). The focus of this
355 section is on the concepts of the capability description and
356 negotiation language with a stepwise introduction of the various
357 syntactical elements. Note that this section does only examples
358 accompanied by explanations -- a full formal specification is
359 provided in section 4.
361 3.1 Conceptual Outline
363 The description language follows the system model introduced in the
364 beginning of this document. We use a rather abstract language to
365 avoid misinterpretations due to different intuitive understanding of
366 terms as far as possible.
368 The concept of a capability description language addresses various
369 pieces of a full description of system and application capabilities
370 in four separate "sections":
372 Definitions (elementary and compound); see Section 3.1.1.
374 Potential or Actual Configurations; see Section 3.1.2.
376 Constraints; see Section 3.1.3.
378 Session attributes; see Section 3.1.4.
380 3.1.1 Definitions
382 The "Definitions" section specifies a number of basic abstractions
383 that are later referenced to avoid repetitions in more complex
384 specifications and allow for a concise representation. Definition
385 elements are labelled with an identifier by which they may be
386 referenced. They may be elementary or compound (i.e. combinations
387 of elementary entities). Examples of definitions that could occur in
388 "Definitions" sections include (but are not limited to) codec
389 definitions, redundancy schemes, transport mechanisms and payload
390 formats.
392 Elementary definition elements do not reference other elements. Each
393 elementary entity only consists of one of more attributes and their
394 values. Default values specified in the definition section may be
395 overridden in descriptions for potential (and later actual)
396 configurations. A mechanisms for overriding definitions is specified
397 below.
399 For the moment, elementary abstractions are defined for media types
400 (i.e. codecs) and for media transports mechanisms. For each
401 transport and for each codec to be used, the respective attributes
402 need to be defined. This definition may either be provided within
403 the "Definitions" section itself or in an external document (similar
404 to the audio-video profile or an IANA registry that defines payload
405 types and media stream identifiers).
407 It is not required to define all codecs and transport mechanisms in a
408 "Definitions" sections and reference them when specifying potential
409 and actual configurations. Instead, a syntactic mechanism is defined
410 that allows to give some definitions directly in a configurations
411 section.
413 Examples for elementary definitions:
415
418
421 The element type "audio:codec" is used in these examples to define
422 audio codec configurations. The configuration parameters are given
423 as attribute values.
425 Definitions may have default values specified along with them for
426 each attribute (as well as for their contents). Some of these
427 default values may be overridden so that a codec definition can
428 easily be re-used in a different context (e.g. by specifying a
429 different sampling rate) without the need for a large number of base
430 specifications. In the following example the definition of audio-
431 L16-mono is re-used for the defintion of the corresponding stereo
432 codec. Appendix A provides a complete set of corresponding
433 audio:codec definitions of the codecs used in RFC 1890 [4].
435
438 The example shows how existing definitions can be referenced in new
439 definitions. This approach allows to create simple as well as more
440 complex definitions in an extensible set of reference documents.
441 Section 3.4 specifies the mechanisms for external references.
443 Besides definitions of audio codecs other definitions such as RTP
444 payload formats and specific transport mechanisms are suitable to be
445 defined in a definition section for later referencing. The following
446 example shows how RTP payload types are defined using a pre-defined
447 codec.
449
450
452 In this example, the payload type "rtp-avp-11" is defined with
453 payload type number 11, referencing the codec "audio-L16-mono".
454 Instead of referencing an existing definition it is also possible to
455 define the format "inline":
457
458
459
461 Note: For negotiation between endpoints, it may be helpful to define
462 two modes of operation: explicit and implicit. Implicit
463 specifications may refer to externally defined entities to minimize
464 traffic volume, explicit specifications would list all external
465 definitions used in a description in the "Definitions" section.
466 Again, see Section 3.4 for complete discussion of external
467 definitions.
469 The "Definitions" section may be empty if all transport, codecs, and
470 other pieces needed to the specify Potential and Actual
471 Configurations (as detailed below) are either included by referencing
472 external definitions or are explicitly described within the
473 Configurations themselves.
475 3.1.2 Components & Configurations
477 The "Configurations" section contains all the components that
478 constitute the multimedia application (IP telephone call, real-time
479 streaming application, multi-player gaming session etc.). For each
480 of these components, the potential and, later, the actual
481 configurations are given. Potential configurations are used during
482 capability exchange and/or negotiation, actual configurations to
483 configure media streams after negotiation (e.g. with RTSP) or in
484 session announcements (e.g. via SAP). A potential and the actual
485 configuration of a component may be identical.
487 Each component is labelled with an identifier so that it can be
488 referenced, e.g. to associate semantics with a particular media
489 stream. For such a component, any number of configurations may be
490 given with each configuration describing an alternative way to
491 realize the functionality of the respective component.
493 Each configuration (potential as well as actual) is labelled with an
494 identifier. A configuration combines one or more (elementary and/or
495 compound) entities from the "Definitions" section to describe a
496 potential or an actual configuration. Within the specification of
497 the configuration, default values from the referenced entities may be
498 overwritten. In addition, it is also possible to provide definition
499 elements inline, inside the definition of a configuration.
501 Note: Not all protocol environments and their respective operation
502 allow to explicitly distinguish between Potential and Actual
503 Configurations. Therefore, SDPng so far does not provide for
504 syntactical identification of a Configurations as being a Potential
505 or an Actual one. The semantics of configurations are to be
506 determined from the requirements of the specific protocol that uses
507 SDPng to express capabilities and configurations.
509 The following example shows how RTP sessions can be described by
510 referencing payload definitions.
512
513
514
515
516
517
518
520
521
522
523
524
525
526
528 For example, an IP telephone call may require just a single component
529 "name=interactive-audio" with two possible ways of implementing it.
530 The two corresponding configurations are "AVP-audio-0" without
531 modification, the other ("AVP-audio-11") uses linear 16-bit encoding.
532 Typically, transport address parameters such as the port number would
533 also be provided. In this example, this information is given by the
534 "rtp:udp" element. Of course, it must be possible to specify other
535 transport mechanisms as well. See Section 3.2 for a discussion of
536 extension mechanisms that allow applications to use non-standard
537 transport (or other) specifications.
539 During/after the negotiation phase, an actual configuration is chosen
540 out of a number of alternative potential configurations, the actual
541 configuration may refer to the potential configuration just by its
542 "id", possibly allowing for some parameter modifications.
543 Alternatively, the full actual configuration may be given.
545 Instead of referencing existing payload type definitions it is also
546 possible to provide the required information "inline". The following
547 example illustrates this:
549
550
551
552
553
554
556
557
558
559
560
561
563 The UDP/IPv4 multicast transport that is used in the examples is a
564 simple variant of a transport specification. More complex ones are
565 conceivable. For example, it must also be possible to specify the
566 usage of source filters (inclusion and exclusion), Source Specific
567 Multicast, the usage of multi-unicast, or other parameters such as
568 QoS parameters. Therefore it is possible to extend the definition of
569 transport mechanisms by providing the required information in the
570 element content. An example:
572
573
574
575
576
577
578
579
580
581
582
584 Additional transport mechanisms and options will be defined in future
585 versions of this document.
587 3.1.3 Constraints
589 Definitions specify media, transport, and other capabilities, whereas
590 configurations indicate which combinations of these could be used to
591 provide the desired functionality in a certain setting.
593 There may, however, be further constraints within a system (such as
594 CPU cycles, DSP resources available, dedicated hardware, etc.) that
595 limit which of these configurations can be instantiated in parallel
596 (and how many instances of these may exist). We deliberately do not
597 couple this aspect of system resource limitations to the various
598 application semantics as the constraints may exist across application
599 boundaries. Also, in many cases, expressing such constraints is
600 simply not necessary (as many uses of the current SDP show), so
601 additional overhead can be avoided where this is not needed.
603 Therefore, we introduce a "Constraints" section to contain these
604 additional limitations. Constraints refer to potential
605 configurations and to entity definitions and express and use simple
606 logic to express mutual exclusion, limit the number of
607 instantiations, and allow only certain combinations. The following
608 example shows the definition of a constraints that restricts the
609 maximum number of instantiation of two alternatives (that would have
610 to be defined in the configuration section before) when they are used
611 in parallel:
613
614
615
616
617
618
620 As the example shows, constraints are defined by defining limits on
621 simultaneous instantiations of alternatives. They are not defined by
622 expressing abstract end-system resources, such as CPU speed or memory
623 size.
625 By default, the "Constraints" section is empty (or missing) which
626 means that no further restrictions apply.
628 3.1.4 Session Attributes
630 The fourth and final section of the SDPng syntax addresses session
631 layer attributes. These attributes largely include those defined by
632 SDP [RFC2327] (which are explicitly indicated in the following
633 specification) to describe originator, purpose, and timing of a
634 multimedia session among other characteristics. Furthermore, SDPng
635 includes attributes indicating the semantics of the various
636 Components in a teleconference or other session. This part of the
637 specification is open ended with an IANA registry to be set up to
638 register further types of components; only a few of the examples are
639 listed here.
641 A session-level specification for connection information (SDP "c="
642 line), bandwidth information (SDP "b=" line), and encryption keys
643 (SDP "k=" lines) is deliberately not provided for in SDPng. The
644 relevant information can be specified directly in the Configuration
645 section for individual alternatives.
647 Session level attributes as defined by SDP still have to be examined
648 and adopted for SDPng in a future revision of this specification.
650 3.1.4.1 Owner
652 The owner refers to the creator of a session as defined in RFC2327
653 ("o=" line). The syntax is as follows:
655
658 The owner element must be present if SDPng is used with SAP. For all
659 other protocols, the owner element is not necessarily required. The
660 attributes listed above match those from the SDP specification; all
661 attributes must be present and they are used following the rules of
662 RFC2327.
664 The owner element is an empty element.
666 3.1.4.2 Session Identification
668 The "session" element is used to identify the session and to provide
669 a description and possible further references. It provides the
670 following attributes:
672 name: The session name as it is to appear e.g. in a session
673 directory. This is equivalent to the SDP "s=" line.
675 The session element can contain arbitrary text of any length (but
676 authors are encouraged to keep the inline description brief and
677 provide additional information via URLs using the info element
678 described below. This text is used to provide a description of the
679 session; it is the equivalent of the SDP "i=" lines.
681 Additionally, the session element can contain other elements of the
682 following types to provide further information about the session and
683 its creator:
685 info: The info element is intended to provide a pointer to further
686 information on the session itself. It is an empty element and
687 provides the attribute xlink:href that is used to specify an URI.
688 Info elements are optional, they may occur any number of times.
690 contact: The contact element provides contact information on the
691 creator of the session. It is an empty element and provides an
692 attribute xlink:href that is used to specify an URI. Any URI
693 scheme suitable to reach a person or a group of persons is
694 acceptable (e.g. sip:, mailto:, tel:). Contact elements are
695 optional, they may occur any number of times.
697
698 And here comes a long description of the seminar indicating what
699 this might be about and so forth. But we also include further
700 information -- as additional elements:
701
702
703
704
705
706
707
709 3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines)
711 The time specification for a session follows the same rules as in
712 SDP. Time specifications are usually only meaningful when used in
713 conjunction with SAP and are optional. SDPng uses the following
714 elements and attributes to specify timing:
716 The element "time" is used to indicate a schedule for the session;
717 time has two optional attributes:
719 start: The starting time of the first occurrence of the session as
720 defined in RFC2327.
722 end: The ending time of the last occurrence of the session as defined
723 in RFC2327.
725 The time element can contain the following elements:
727 repeat: This element specifies the repetition pattern for the
728 schedule. There may be zero or more occurrences of this element
729 within the time element. "repeat" has two mandatory and one
730 optional attribute and is an empty element; the attributes are as
731 defined in SDP:
733 interval: The duration between two start times of the session.
734 This attribute is always present.
736 duration: The duration for which the session will be active
737 starting at each repetition interval. This attribute is always
738 present.
740 offset: The offset relative to "start" attribute at which this
741 repetition of the session is start. This attribute is
742 optional; if it is absent, a default value of "0" is assumed.
744 Formatting of the attribute values follows the rules defined in
745 RFC2327.
747 zone: The zone element specifies one or more time zone adjustments as
748 defined in RFC2327. This element has zero or more occurrences in
749 the time element. It is an empty element and has two attributes
750 as defined in SDP:
752 adjtime: The time at which the next adjustment will take place.
754 delta: The adjustment offset (typically +/- 1 hours).
756 The example from RFC2327, page 16, expressed in SDPng:
758
763 The time element can occur multiple times.
765 3.1.4.4 Component Semantic Specification
767 Another important session parameter is to specify - ideally in a
768 machine-readable way but at least understandable for humans - the
769 function of the various components in a session. Typically, the
770 semantics of the streams are implicitly assumed (e.g. a video stream
771 goes together with the only audio stream in a session). There are,
772 however, scenarios in which such intuitive understanding is not
773 sufficient and the semantics must be made explicit.
775
776 Audio stream for the different speakers
777
779 The above example shows a simple definition of the semantics for the
780 component "audio-interactive". Further options may be added to
781 provide additional information, e.g. language, and other functions
782 may be specified (e.g. "panel", "audience", "chair", etc.).
784 3.2 Syntax Definition Mechanisms
786 In order to allow for the possibility to validate session
787 descriptions and in order to allow for structured extensibility,
788 SDPng relies on a syntax framework that provides concepts as well as
789 concrete procedures for document validation and extending the set of
790 allowed syntax elements.
792 SGML/XML technologies allow for the creation of Document Type
793 Definitions (DTDs) that can define the allowed content models for the
794 elements of conforming documents. Documents can be formally
795 validated against a given DTD to check their conformance and
796 correctness. XML DTDs however, cannot easily be extended. It is not
797 possible to alter to content models of element types or to add new
798 element types after the DTD has been specified.
800 For SDPng, a mechanism is needed that allows the specification of a
801 base syntax -- for example basic elements for the high level
802 structure of description documents -- while allowing extensions, for
803 example elements and attributes for new transport mechanisms, new
804 media types etc. to be added on demand. Still, it has to be ensured
805 that extensions do not result in name collisions. Furthermore, it
806 must be possible for applications that process descriptions documents
807 to distinguish extensions from base definitions.
809 For XML, mechanisms have been defined that allow for structured
810 extensibility of a model of allowed syntax: XML Namespace and XML
811 Schema.
813 XML Schema mechanisms allows to constrain the allowed document
814 content, e.g. for documents that contain structured data and also
815 provide the possibility that document instances can conform to
816 several XML Schema definitions at the same time, while allowing
817 Schema validators to check the conformance of these documents.
819 Extensions of the session description language, say for allowing to
820 express the parameters of a new media type, would require the
821 creation of a corresponding XML schema definition that contains the
822 specification of element types that can be used to describe
823 configurations of components for the new media type. Session
824 description documents have to reference the non-standard Schema
825 module, thus enabling parsers and validators to identify the elements
826 of the new extension module and to either ignore them (if they are
827 not supported) or to consider them for processing the
828 session/capability description.
830 It is important to note that the functionality of validating
831 capability and session description documents is not necessarily
832 required to generate or process them. For example, endpoints would
833 be configured to understand only those parts of description documents
834 that are conforming to the baseline specification and simply ignore
835 extensions they cannot support. The usage of XML and XML Schema is
836 thus rather motivated by the need to allow for extensions being
837 defined and added to the language in a structured way that does not
838 preclude the possibility to have applications to identify and process
839 the extensions elements they might support. The baseline
840 specification of XML Schema definitions and profiles must be well-
841 defined and targeted to the set of parameters that are relevant for
842 the protocols and algorithms of the Internet Multimedia Conferencing
843 Architecture, i.e. transport over RTP/UDP/IP, the audio video profile
844 of RFC1890 etc.
846 Section 3.4 describes profile definitions and library definition. A
847 detailed definition of how the formal SDPng syntax and the
848 corresponding extension mechanisms is provided in Section 5.
850 The example below shows how the definition of codecs, transport-
851 variants and configuration of components as well as a conference
852 description are realized in SDPng.
854
855
858
861
862
864
866
867
868
869
870
871
872
874
875
876
877
878
879
880
882
883
884
885
886
888
889
891
892 This seminar is about SDPng...
893
894
895
896
898
903
904 Audio stream for the different speakers
905
907
909 Section 5 specifies the formal Schema definition that this example is
910 conforming to.
912 A real-world capability description would likely be shorter than the
913 presented example because the codec and transport definitions can be
914 factored-out to profile definition documents that would only be
915 referenced in capability description documents.
917 3.3 Referencing Definitions
919 This section specifies some generic mechanisms for referencing
920 existing definitions. Referencing existing definition allows to
921 contruct definitions without having to include all parameters inline.
922 By using these mechanisms, complex definitions can be derived by
923 combining multiple basic mechanisms. Common parameters that occur in
924 different configurations do not have to be repeated but can be
925 defined once and then be referenced as often as they are needed.
927 3.3.1 The sdpng:use Element Type
929 The element type "sdpng:use" is a generic reference mechanisms that
930 allows to refer to arbitrary definition within another definition or
931 configuration element. "sdpng:use" is an element type with one
932 mandatory attribute called "href". The value of that attribute is
933 the name of the definition to be referenced. An example:
935
936
937
938
939
940
941
942
943
944
945
946
948 In this example, an element "rtp:udp" is used in the definitions
949 section to define some transport parameters that should later be re-
950 used by referencing this definition using the specified name
951 "endpoint-addr-1". Within the element "rtp:session" in the
952 configurations section the definition is referenced using the "use"
953 element.
955 An implementation that processes this SDPng document and wants to
956 evaluate the configuration for the alternative "rtp-avp-10" MUST
957 replace the "use" element by the referenced element. If the
958 referenced element contains "use" elements itself, those MUST also be
959 dereferenced.
961 When applying this algorithm to the sample SDPng document, the
962 following result SDPng document is generated:
964
965
966
967
968
969
970
971
972
973
974
975
977 For the purpose of comparing configurations, both SDPng documents are
978 equal.
980 3.3.2 Properties
982 The element type "sdpng:prop" can be used to add properties to
983 definitions. "sdpng:prop" has two attributes:
985 name: the name of the property
987 value: the value for the named property
989 For example:
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1007 For comparing and collapsing elements, all sdpng:prop element that
1008 are contained in a parent element (like alt in the example above)
1009 MUST be transformed to attributes of the containing element. If the
1010 parent element already provides a corresponding attribute its value
1011 MUST be overwritten.
1013 The example above would thus be transformed to:
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1030 The main purpose of the sdpng:prop element type is to provide a
1031 mechanism by which attributes of referenced elements can be modified
1032 by the referring element. An application for this is described in
1033 Section 3.3.4.
1035 3.3.3 Definition Groups
1037 Using the sdpng:group element arbitrary definition can be combined
1038 and defined as a group with a specific name. Using this name, the
1039 definitions contained in the group can be referenced with the
1040 sdpng:use element and embedded into other elements.
1042 An example for the use of the sdpng:group element:
1044
1045
1046
1047
1049
1050
1051
1052
1054
1055
1056
1058
1059
1060
1061
1062
1063
1064
1065
1067 This example shows how a group that has been defined in the
1068 definitions section is referenced using the sdpng:use element. The
1069 group element contains two sdpng:prop elements.
1071 For comparing and collapsing elements, all references to sdpng:group
1072 element MUST be replaced by the content of the corresponding
1073 sdpng:group element. The example above would thus be transformed to:
1075
1076
1077
1078
1080
1081
1082
1083
1085
1086
1087
1089
1090
1091
1092
1093
1094
1095
1096
1097
1099 In this example the content of the sdpng:group element named g1 has
1100 been embedded into the alt element that contained the sdpng:use
1101 element referencing the group element.
1103 According to the rules in Section 3.3.2 the sdpng:prop elements are
1104 transformed in a second step to yield the following final decription:
1106
1107
1108
1109
1111
1112
1113
1114
1116
1117
1118
1120
1121
1122
1123
1124
1125
1126
1128 As a general rule, all references MUST be resolved before sdpng:prop
1129 elements are processed and transformed into attribute values.
1131 3.3.4 Usage of Child Elements and Attributes of sdpng:use Elements
1133 It is also possible to provide arbitrary other elements within a
1134 sdpng:use element (depending on the specific application). All
1135 elements that occur in a sdpng:use element MUST be transfomed to
1136 child elements of the referenced element when resolving a sdpng:use
1137 reference. If the reference already provides child elements, the
1138 child elements of the sdpng:use element are added to the list of
1139 child elements of the referenced element.
1141 Any existing elements of a referenced element with the same GI as an
1142 element in the corresponding sdpng:use element MUST be replaced by
1143 the element of the sdpng:use element. This mechanism allows to
1144 extend and to change referenced elements in a simple way.
1146 In the following we give an example of using an sdpng:prop element
1147 within a sdpng:use element which has the semantics of adding
1148 properties to the referenced element. The semantics and processing
1149 requirements for the sdpng:prop element are specified in Section
1150 3.3.2.
1152 Example for the usage of an sdpng:use element containing an
1153 sdpng:prop element:
1155
1156
1157
1158
1159
1160
1161
1162
1165
1166
1167
1168
1170 This will be transformed to:
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1187 In a second step, the sdpng:prop element would be transformed to an
1188 attribute of its parent element (rtp:udp in this case) according to
1189 the rules specified in Section 3.3.2.
1191 As an abbreviation, the properties for the referenced element do not
1192 have to be specified using sdpng:prop elements within the sdpng:use
1193 element but can also specified directly as attributes of the
1194 sdpng:use element, as shown in the following example:
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1209 In this example, the sdp:use element has no child element sdpng:prop
1210 but provides the property "foo" directly as an attribute. All
1211 attributes of a sdpng:use element other than href MUST be transformed
1212 to attributes of the referenced elements.
1214 If the referenced element is a definition group (see Section 3.3.3),
1215 any child elements of an sdpng:use element MUST be transformed to
1216 child elements of the parent element of the sdpng:use element. Any
1217 properties (either explicit sdpng:prop elements or attributes of the
1218 sdpng:use element) MUST be transformed to properties of the parent
1219 element of the sdpng:use element.
1221 3.4 External Definition Packages
1223 There are two types of external definitions:
1225 Profile Definitions (Section 3.4.1) define rules for specifying
1226 parameters that are not covered by the base SDPng specification.
1228 Library Definitions (Section 3.4.2) contain definitions that can be
1229 referenced in SDPng documents.
1231 3.4.1 Profile Definitions
1233 In order to allow for extensibility it must be possible to define
1234 extensions to the basic SDPng configuration options.
1236 For example, if some application requires the use of a new transport
1237 protocol, endpoints must be able to describe their configuration with
1238 respect to the parameters of that transport protocol. The mandatory
1239 and optional parameters that can be configured and negotiated when
1240 using the transport protocol will be specified in a definition
1241 document. Such a definition document is called a "profile".
1243 A profile contains rules that specify how SDPng is used to describe
1244 conferences or end-system capabilities with respect to the parameters
1245 of the profile. The concrete properties of the profile definitions
1246 mechanism are still to be defined.
1248 An example of such a profile would be the RTP profile that defines
1249 how to specify RTP parameters. Another example would be the audio
1250 codec profiles that defines how specify audio codec parameters.
1252 SDPng documents can reference profiles and provide concrete
1253 definitions, for example the definition for the GSM audio codec.
1254 (This would be done in the "Definitions" section of an SDPng
1255 document.) An SDPng document that references a profile and provides
1256 concrete definitions of configurations can be validated against the
1257 profile definition.
1259 3.4.2 Library Definitions
1261 While profile definitions specify the allowed parameters for a given
1262 profile, SDPng "Definitions" sections refer to profile definitions
1263 and define concrete configurations based on a specific profile.
1265 In order for such definitions to be imported into SDPng documents,
1266 "SDPng libraries" may be defined and referenced in SDPng documents.
1267 A library is a set of definitions that is conforming to one or more
1268 profile definitions.
1270 The purpose of the library concept is to allow certain common
1271 definitions to be factored-out so that not every SDPng document has
1272 to include the basic definitions, for example the PCMU codec
1273 definition. SDP [2] uses a similar concept by relying on the well
1274 known static payload types (defined in RFC1890 [4]) that are also
1275 just referenced but never defined in SDP documents.
1277 An SPDng document that references definitions from an external
1278 library has to declare the use of the external library. The external
1279 library, being a set of configuration definitions for a given
1280 profile, again needs to declare the use of the profile that it is
1281 conforming to. A library itself can make reference to other external
1282 libraries.
1284 There are different possibilities of how profiles definitions and
1285 libraries can be used in SDPng documents:
1287 o In an SPDng document, a profile definition can be referenced and
1288 all the configuration definitions are provided within the document
1289 itself. The SDPng document is self-contained with respect to the
1290 definitions it uses.
1292 o In an SPDng document, the use of an external library can be
1293 declared. The library references a profile definition and the
1294 SDPng document references the library. There are two alternatives
1295 how external libraries can be referenced:
1297 by name: Referencing libraries by names implies the use of a
1298 registration authority where definitions and reference names
1299 can be registered with. It is conceivable that the most common
1300 SDPng definitions be registered that way and that there will be
1301 a baseline set of definitions that minimal implementations must
1302 understand. Secondly, a registration procedure will be
1303 defined, that allows vendors to register frequently used
1304 definitions with a registration authority (e.g., IANA) and to
1305 declare the use of registered definition packages in conforming
1306 SDPng documents. Of course, care should be taken not to make
1307 the external references too complex and thus require too much a
1308 priori knowledge in a protocol engine implementing SDPng.
1309 Relying on this mechanism in general is also problematic
1310 because it impedes the extensibility, as it requires
1311 implementors to provide support for new extensions in their
1312 products before they can inter-operate. Registration is not
1313 useful for spontaneous or experimental extensions that are
1314 defined in an SDPng library.
1316 by address: An alternative to referencing libraries by name is to
1317 declare the use of an external library by providing an address,
1318 i.e., an URL, that specifies where the library can be obtained.
1319 While this allows the use of arbitrary third-party libraries
1320 that can extend the basic SDPng set of configuration options in
1321 many ways, in introduces additional complexity that could
1322 result in in higher latency for the processing of a description
1323 document with references to external libraries. In addition,
1324 there are problems if the referenced libraries cannot be
1325 accessed by all communication partners.
1327 o Because of these problematic properties of external libraries, the
1328 final SDPng specification will have to provide a set of
1329 recommendations under which circumstances the different mechanisms
1330 of referring to external definitions should be used.
1332 3.5 Mappings
1334 A mapping needs to be defined in particular to SDP that allows to
1335 translate final session descriptions (i.e. the result of capability
1336 negotiation processes) to SDP documents. In principle, this can be
1337 done in a rather schematic fashion for the basic definitions.
1339 In addition, mappings to H.245 will be defined in order to support
1340 applications like SIP-H.323 gateways.
1342 4. Capability Negotiation
1344 SDPng is a description language for both potential configurations
1345 (i.e. capabilities) of participants in multimedia conferencers and
1346 for actual configurations (i.e. final specifications of parameters).
1347 Capability negotiation is the process of generating a usable set of
1348 potential configurations and finally an actual configuration from a
1349 set of potential configurations provided by each potential
1350 participant in a multimedia conference.
1352 SDPng supports the specification of endpoint capabilities and defines
1353 a negotiation process: In a negotiation process, capability
1354 descriptions are exchanged between participants. These descriptions
1355 are processed in a "collapsing" step which results in a set of
1356 commonly supported potential configurations. In a second step, the
1357 final actual configuration is determined that is used for a
1358 conference. This section specifies the usage of SDPng for capability
1359 negotiation. It defines the collapsing algorithm and the procedures
1360 for exchanging SDPng documents in a negotiation phase.
1362 The description language and the rules for the negotiation phase that
1363 are defined here are (in general) independent of the means by which
1364 descriptions are conveyed during a negotiation phase (a reliable
1365 transport service with causal ordering is assumed). There are
1366 however properties and requirements of call signalling protocols that
1367 have been considered to allow for a seamless integration of the
1368 negotiation into the call setup process. For example, in order to be
1369 usable with SIP, it must be possible to negotiate the conference
1370 configuration within the three-way-handshake of the call setup phase.
1371 In order to use SDPng instead of SDP according to the offer/answer
1372 model defined in [15] it must be able to determine an actual
1373 configuration in a single request/response cycle.
1375 4.1 Outline of the Negotiation Process
1377 Conceptually, the negotiation process comprises the following
1378 individual steps (considering two parties, A and B, where A tries to
1379 invite B to a conference). Please note that is describes the steps
1380 of the negotiation process conceptually -- it does not specify
1381 requirements for implementations. Specific procedures that MUST be
1382 followed by implementations are given below.
1384 1. A determines its potential configurations for the components that
1385 should be used in the conference (e.g. "interactive audio" and
1386 "shared whiteboard") and sends a corresponding SDPng instance to
1387 B. This SDPng instances is denoted "CAP(A)".
1389 2. B receives A's SDPng instance and analyzes the set of components
1390 (sdpng:c elements) in the description. For each component that B
1391 wishes to support it generates a list of potential configurations
1392 corresponding to B's capabilities, denoted "CAP(B)".
1394 3. B applies the collapsing function and obtains a list of potential
1395 configurations that both A and B can support, denoted
1396 "CAP(A)xCAP(B) = CAP(AB)".
1398 4. B sends CAP(B) to A.
1400 5. A also applies the collapsing function and obtains "CAP(AB)". At
1401 this step, both A and B know each other capabilities and the
1402 potential configurations that both can support.
1404 6. In order to obtain an actual configuration from the potential
1405 configuration that have been obtained, both particpants have to
1406 pick a subset of the potential configurations should actually be
1407 used in the conference and generate the actual configuration. It
1408 should be noted that it depends on the specific application
1409 whether each component must be assigned exactly one actual
1410 configuration (one sdpng:alt element) or whether it is allowed to
1411 list multiple actual configurations. In this model we assume
1412 that A selects the actual configuration, denoted CFG(AB).
1414 7. A augments CFG(AB) with the transport parameters it intends to
1415 use, e.g., on which endpoint addresses A wishes to receive data,
1416 obtaining CFG_T(A). A sends CFG_T(A) to A.
1418 8. B receives CFG_T(A) and adds its own transport parameters,
1419 resulting in CFG_T(AB). CFG_T(AB) contains the selected actual
1420 configurations and the transport parameters of both A and B (plus
1421 any other SDPng data, e.g., meta-information on the conference).
1422 CFG_T(AB) is the complete conference description. Both A and B
1423 now have the following information:
1425 CAP(A) A's supported potential configurations
1427 CAP(B) B's supported potential configurations
1429 CAP(AB) The set of potential configurations supported by both A
1430 and B.
1432 CFG(AB) The set of actual configurations to be used.
1434 CFG_T(AB) The set of actual configurations to be used augmented
1435 with all required parameters.
1437 In this model, the capability negotiation and configuration exchange
1438 process leads to a description that represents a global view of the
1439 configuration that should be used. This means, it contains the
1440 complete configuration for all participants including per-participant
1441 information like transport parameters.
1443 Note that the model presented here results in four SDPng exchanges.
1444 As an optimization, this procedure can be abbreviated to two
1445 exchanges by including the transport (and other) parameters into the
1446 potential configurations. A embeds its desired transport parameters
1447 into the list of potential configurations and B also sends all
1448 required parameters in the response together with B's potential
1449 configurations. Both A and B can then derive CFG_T(AB). Transport
1450 parameters are usually not negotiable, therefor they have to be
1451 distingiushed them from other configuration information.
1453 Specific procedures for re-negotiation and multi-party negotiation
1454 will be defined in a future version of this document.
1456 4.2 The Collapsing Algorithm
1458 The following procedure MUST be used for the collapsing of two SDPng
1459 document instances into one:
1461 CAP(A) and CAP(B) are the two SDPng description document instances.
1462 For each component (sdpng:c element) in CAP(A) there is a
1463 corresponding component in CAP(B). Components MAY be empty
1464 (containing no sdpng:alt elements) which means that there is no
1465 potential configuration and the component should not be used in the
1466 conference.
1468 Let cfg_AB be the result configuration element, initialized to an
1469 empty sdpng:cfg element.
1471 1. For each component (sdpng:c element) in CAP(A) named c_A
1473 * Let c_AB be the current result component, initialized to an
1474 empty sdpng:c element.
1476 * For each alternative (sdpng:alt element) in c_A named a_A
1478 + For each session element (name depends on the profile being
1479 used) in a_A named s_A
1481 - Resolve any reference to definition elements recursively
1482 and obtain s1_A, the standalone media session
1483 description. (Refer to Section 4.2.1 for a description
1484 of how to resolve references.)
1486 - Locate the component element that matches c_A in CAP(B)
1487 named (c_B).
1489 - Let a_AB be the current result alternative, initialized
1490 to an empty sdpng:alt element.
1492 - For each alternative (sdpng:alt element) in c_B named
1493 a_B
1495 o For each session element (name depends on the profile
1496 being used) in a_B named s_B
1498 * Let s1_AB be the computed result media session
1499 configuration.
1501 * Resolve any reference to definition elements
1502 recursively and obtain s1_B, the standalone media
1503 session description.
1505 * Apply collapse(s1_A,s2_B) to compute s1_AB, the
1506 collapsed media session configuration.
1508 * If s1_AB is not empty, add s1_AB to a_AB, the set
1509 of sessions for the current result alternative.
1511 - If a_AB is not empty, add a_AB to c_AB.
1513 * If c_AB is not empty, add c_AB to cfg_AB.
1515 The collapsing function for collapsing two elements is specified in
1516 Section 4.2.1.
1518 4.2.1 Collapsing Two Configurations
1520 Before two media session configuration element can be collapsed as
1521 described in Section 4.2 all references to definitions MUST be
1522 resolved. This MUST be performed recursively, i.e. references in
1523 definitions MUST also be resolved. For resolving references, the
1524 algorithm specified in Section 3.3 MUST be used.
1526 By resolving all references two intermediate session configuration
1527 elements are obtained that can then be collapsed according to the
1528 algorithm specified in the following sections.
1530 4.2.1.1 Collapsing of Attributes
1532 In SDPng, capabilities are specified in attributs of XML elements.
1533 Three different types of capabilities with different collapsing rules
1534 are defined. The type of a capability is encoded in the attribute
1535 value.
1537 Set of symbols:
1538 An attribute can specify a set of symbols. When two attributes
1539 are collapsed the result is the intersection of the two sets.
1541 The following examples shows how two elements (with one attribute
1542 representing a set of symbols) originated from two capability
1543 descriptions from participants A and B are collapsed:
1545 Element x in A's capability description:
1546
1548 Element x in B's capability description:
1549
1551 Result:
1552
1554 If the intersection result in an empty set the collapsing process
1555 has failed and there is no common set of values. If the
1556 collapsing of one of an element's attributes with the type "set of
1557 symbols" has failed, the collapsing process of the element itself
1558 MUST be considered to have failed as well.
1560 Numerical ranges:
1561 An attribute can also specify a numercial range. When two
1562 attributes are collapsed the result is the range of values that
1563 represents the intersection of the set of values that is included
1564 in both ranges.
1566 The following examples shows how two elements (with one attribute
1567 representing a numerical range) originated from two capability
1568 descriptions from participants A and B are collapsed:
1570 Element x in A's capability description:
1571
1573 Element x in B's capability description:
1574
1576 Result:
1577
1579 A numerical range is represented by a tuple of comma-separated
1580 numbers in brackets. The first number represents the lower bound
1581 of the range and the second number represents the upper bound.
1582 Let MIN(a,b) be a function that returns the minimum of a and b and
1583 MAX(a,b) be a function that returns the maximum of a and b. Given
1584 two ranges (minA, maxA) and (minB, maxB), the collapsed new range
1585 MUST be calculated using this algorithm:
1587 (MAX(minA, minB), MIN(maxA, maxB))
1589 If this process results in a range with a smaller first value,
1590 the range is invalid and the collapsing has failed since there is
1591 no common range. If the collapsing of one of an element's
1592 attributes with the type "numerical range" has failed, the
1593 collapsing process of the element itself MUST be considered to
1594 have failed as well.
1596 Optional parameters:
1597 A failure of collapsing attributes of the types "set of symbols"
1598 and "numerical range" results in a failure of collapsing the
1599 corresponding element. There is a third type named "optional
1600 parameter" defined, that provides different collapsing rules. An
1601 optional parameter is an attribute with an arbitrary value. When
1602 collapsing two attributes of this type, their values MUST be
1603 tested for equality. If they are equal, the collapsing has been
1604 successful and the attribute MUST appear as is in the result
1605 description. If the attributes' values are different, the
1606 collapsing is considered to have failed and the attribute MUST not
1607 appear in the result description. However, a failure in
1608 collapsing an attribute of type "optional parameter" does not
1609 affect the collapsing of the containing element.
1611 An example for a successful collapsing:
1613 Element x in A's capability description:
1614
1616 Element x in B's capability description:
1617
1619 Result:
1620
1622 An example for an unsuccessful collapsing:
1624 Element x in A's capability description:
1625
1627 Element x in B's capability description:
1628
1630 Result:
1631
1633 4.2.1.2 Collapsing two Elements
1635 In order to collapse two elements with multiple attributes, the
1636 following algorithm specified below MUST be applied. In general, the
1637 collapsing of two elements (if successful) yields a result element
1638 that contains the collapsed attributes. If the collapsing of two
1639 elements has failed, no result element is generated.
1641 1. For each attribute, determine the type and collapse the attribute
1642 by applying the algorithm for the corresponding attribute type.
1644 2. If an attribute with a different type than "optional parameter"
1645 does not occur in both elements, the collapsing for this element
1646 MUST be considered to have failed.
1648 3. If the collapsing of any attribute with a different type than
1649 "optional parameter" has failed, the collapsing of the element
1650 itself MUST be considered to have failed.
1652 4. If the collapsing has been successful, obtain the result element
1653 by using the same element name (GI) and the attributes with their
1654 collapsed values. Exclude any attribute of type "optional
1655 parameter" that has failed to collapse.
1657 An example:
1659 Element x in A's capability description:
1660
1662 Element x in B's capability description:
1663
1665 Result:
1666
1668 4.2.1.3 Collapsing nested Elements
1670 In order to collapse nested elements the following algorithm MUST be
1671 applied:
1673 In analogy to attributes representing optional parameters there is
1674 also the possibility to mark elements as optional for the negotiation
1675 process. Elements MAY provide an attribute names "status" that
1676 contains a symbol or a comma-separated list of symbols as its value.
1677 If the value "opt" occurs in the list of a "status" attribute of both
1678 elements to be collapsed, the elements to be collapsed are treated as
1679 optional. This means, if the collapsing of the attributes has failed
1680 (according to the rules specified in Section 4.2.1.2), the collapsing
1681 process does not yield a result element but is still treated as
1682 "successful", i.e., further collapsing operation on other elements
1683 can continue. The semantics of optional elements are that they
1684 describe optional features that may be supported and selected during
1685 a negotiation phase but do not neccessarily have to be supported by
1686 all participants in order to achieve interoperability. The example
1687 below shows how to generate a result element in the presence of
1688 optional child elements that have failed to collapse.
1690 The collapsing algorithm for nested elements:
1692 1. Let x be an element that occurs in the capability description of
1693 two participants A and B and that should be collapsed.
1695 2. Collapse the attributes of the element x using the algorithm
1696 specified in Section 4.2.1.2. If the collapsing has failed
1697 according to the rules of Section 4.2.1.2 and if the elements to
1698 be collapsed are not marked as optional, the collapsing of the
1699 element and all of its children MUST be considered to have
1700 failed. The collapsing MUST be stopped. If the collapsing has
1701 failed and both elements have been marked as optional, the child
1702 elements MUST NOT be processed. In this case, the collapsing
1703 process does not yield a result element but the collapsing of
1704 other elements (sibling or parent elements) MUST be continued.
1706 3. If the collapsing has been successful according to the rules of
1707 Section 4.2.1.2, the child elements of A's and B's x element MUST
1708 be processed. If there are no child elements in both A's and B's
1709 content the collapsing has been successful and can be terminated.
1710 If either A's or B's x element provides child elements, apply the
1711 following algorithm to each child element named c of participant
1712 A's element x:
1714 1. Find a corresponding element (same GI) in the set of
1715 participant B's child elements. If no matching element has
1716 been found, the collapsing of element x MUST be considered to
1717 have failed.
1719 2. If a matching element has been found, apply the collapsing
1720 algorithm recursively. As long as the collapsing is
1721 successful, the result of collapsing each element is
1722 transferred to the result element, such that the resulting
1723 element tree is isomorphic to both A's and B's element tree.
1725 If there are elements in B's x element that have not been
1726 processed (because there is no corresponding element in A's x
1727 element), the collapsing MUST be considered to have failed and
1728 MUST be stopped.
1730 An example:
1732 Element x in A's capability description:
1733
1734
1735
1737 Element x in B's capability description:
1738
1739
1740
1742 Result:
1743
1744
1745
1747 An example for collapsing optional elements:
1749 Element x in A's capability description:
1750
1751
1752
1754 Element x in B's capability description:
1755
1756
1757
1759 Result:
1760
1762 4.2.2 Deriving an actual Configuration
1764 The result of a capability negotiation process is a potential
1765 configuration, i.e., a description potentially containing multiple
1766 alternatives per component. The alternative themselves may provide
1767 elements that represent collapsed capabilities. In order to derive
1768 an actual configuration, the following problems must be addressed:
1770 1. For each component (sdpng:c element) an appropriate alternative
1771 (sdpng:alt element) has to be selected. It is conceivable that
1772 the order of the alternatives in the description is used as a
1773 preference indicator. More details have to be specified in a
1774 future version of this document.
1776 2. If the description of the selected alternatives contains
1777 attributes with numerical ranges or sets of symbols with more
1778 than one entry, those attributes either have to be transformed
1779 that they represent a single value or participants have to agree
1780 that an actual configuration may contain ranges and sets of
1781 symbols. The semantics of these variable actual configurations
1782 will have to specified in later versions of this document. For
1783 example, for certain applications it may be desireable to agree
1784 on ranges of values for certain attributes during a capability
1785 negotiating meaning that any of the values of the range are
1786 supported (and have to be supported).
1788 The specific procedures to determine an actual configuration have to
1789 be defined in a later version on this document.
1791 5. Formal Specification
1793 This section defines the SDPng syntax and the use of XML mechanisms,
1794 such as XML Namespace and XML Schema. Section 5.1 defines the
1795 relation between SDPng and XML Schema, Section 5.2 specifies general
1796 requirements for documents and profile definitions that are
1797 conforming to the SDPng schema, Section 5.3 list requirements for
1798 profile definitions, Section 5.4 specifies specific requirements for
1799 conforming documents and Section 5.5 lists requirements for the
1800 definition of SDPng libraries.
1802 Section 5.7 defines the SDPng base schema, Section 5.7.2 defines the
1803 profile for audio codec definitions and Section 5.7.3 defines the
1804 profile for RTP payload type definitions.
1806 5.1 XML Schema as a Definition Mechanism
1808 SDPng documents reference profile schema definitions and libraries.
1809 Profile schema definitions contain schema definitions of SDPng
1810 document elements. For example, the general structure is specified
1811 by a schema definition and extensions to SDPng for specific
1812 applications are specified as schema definitions as well.
1814 The baseline SDPng specification consists of a profile (a schema
1815 definition) and a library of commonly used definitions.
1817 SDPng uses XML-Schema [13][14] for defining the possible logical
1818 structures of SDPng documents for the following reasons:
1820 Extensibility: XML-Schema provides mechanisms that allow to extend
1821 existing definitions allowing to uniquely identify element types
1822 (by relying on XML namespaces [11]).
1824 Modularity: XML-Schema provide mechanisms that allow to organize
1825 schema definitions in multiple components.
1827 Expressiveness: XML-Schema provides many data types, that can be
1828 refined by user-supplied definitions.
1830 SDPng documents MUST be schema instances of the SDPng schema as
1831 defined in Section 5.7. The following example shows how a Schema
1832 definition can be referenced in a document instance.
1834 Beginning of an SDPng-document:
1836
1837
1841 XML-Schema specifies that documents can assign a namespace when
1842 referencing a schema definition. A SDPng namespace is defined for
1843 this purpose. The name of this namespace is
1844 "http://www.iana.org/sdpng". A well-known namespace prefix is used
1845 for the SDPng schema definition, in order to allow for very simple
1846 implementations. The well-known SDPng namespace prefix is "sdpng".
1847 Conforming Documents, profile definition and libraries MUST use this
1848 namespace name and this namespace prefix.
1850 For SDPng documents, this initial declaration can be added implicitly
1851 by applications, so that declarations like the one above do not have
1852 to be included in every description document. Details are to be
1853 defined in a later version of this document.
1855 5.2 SDPng Schema
1857 The basic SDPng schema definitions specifies the general document
1858 structures, e.g., one "Definitions" section followed by one
1859 "Configurations" sections, followed by one "Constraints" sections
1860 followed by a "Conference" section (for meta-information). Each
1861 document MUST provide the elements for definitions, configurations,
1862 constraints and conference information in exactly this order, whereby
1863 only the configurations section is MANDATORY. Refer to Section 5.7
1864 for a formal definition of the SDPng base schema and the specific
1865 element types for definitions, configurations, constraints and
1866 conference information.
1868 The SDPng base schema also specifies "abstract" base data types (by
1869 means of XML-Schema type definitions) for elements that MUST be used
1870 by documents in the corresponding sections. The base data types
1871 provide common required attributes, e.g. a "name" attribute for
1872 naming definition elements.
1874 Example:
1875 The following example shows the definition of the base type for
1876 definition elements:
1878
1879
1880
1882 Profiles can then define specific types that augment the base type
1883 definitions. Common attributes or content models, that have been
1884 defined by this base definition, do not have to be provided by those
1885 concrete type definitions. The type definitions can be identified as
1886 allowed element types for the content models that are specified in
1887 the base SDPng schema definition. This allows for automatic
1888 validation of profile definitions and facilitates the extension of
1889 SDPng.
1891 5.3 Profiles
1893 The baseline SDPng specification consists of a profile (a schema
1894 definition) and a library of commonly used definitions.
1896 The library of commonly used definitions provides data types for IP
1897 (and other) addresses.
1899 A profile definition MUST import (using the XML-Schema import
1900 mechanism) the base SDPng schema definition and MUST provide an
1901 extension definition, e.g., specializations of base element types. A
1902 profile definition MUST also provide a target namespace name for its
1903 definitions. For well-known (registered) profiles, the namespace
1904 name will be registered by IANA. Proprietary profiles will use other
1905 namespace names, for example, based on domain names, that are
1906 registered by vendors providing a profile.
1908 Example:
1909 The following example shows such a declaration at the beginning of a
1910 profile definition:
1912
1917
1920 In this example, the namespace prefix "audio" is defined and later
1921 used in schema definitions. (The example profile provides definition
1922 mechanisms for audio codecs.)
1924 The following example shows, how a derived type for "definition"
1925 elements can be specified with XML-Schema mechanisms. In this case,
1926 the abstract type "Definition" (fully qualified as
1927 "sdpng:Definition") is augmented by three attributes that are useful
1928 for defining audio codecs.
1930 Example:
1932
1933
1934
1935
1936
1937
1938
1939
1940
1942 This type definition is then used to define an XML element type
1943 called "codec".
1945 Example:
1947
1949 When used by SDPng documents, the general identifier is qualified
1950 with a namespace prefix, for example as in: "audio:codec".
1952 5.4 SDPng Documents
1954 SDPng documents MUST reference the employed profiles and provide
1955 namespace prefixes for the namespace names of the profiles as shown
1956 in the following example.
1958 Example:
1960
1966 For well-known registered profiles, the namespace name AND the used
1967 namespace prefix SHOULD be registered to allow for simple basic
1968 implementations that can match identifiers by using fixed fully
1969 qualified names without having to interpret namespace declarations
1970 (see Section 5.6.3). There is one issue with declaring used XML-
1971 Schema definitions in documents (see Section 7 below).
1973 The general structure of an SDPng documents MUST conform to the basic
1974 SDPng schema definition and MAY provide a "def" element for
1975 definitions; it MUST provide a "cfg" element for the configuration
1976 section; it MAY provide a "constraints" and a "conf" element.
1978 Example:
1979 The following example shows a sample definition section where the
1980 element "codec" of the "audio codec profile" is used (plus the
1981 element type "pt" of an "RTP profile"):
1983
1984
1986
1988
1991
1992
1994 It can be seen how the attribute name (provided by the base type for
1995 definition elements) and the profile specific attributes "encoding",
1996 "channels" and "sampling" are used together.
1998 The element "rtp:pt" is used to defined a payload type. "rtp:pt"
1999 would have been defined in another profile, again using a type
2000 derived from the base definition type. "rtp:pt" provides attribute
2001 for referencing other definitions, e.g., the definition of audio-
2002 codes as seen before.
2004 5.5 Libraries
2006 SDPng libraries are collections of definitions that are referenced by
2007 documents. Libraries are thus independent, valid SDPng documents.
2009 For example, the definition of the different audio codecs as shown in
2010 the previous example could be provided by a library that can be
2011 referenced by documents without having to define such common codecs
2012 in every document.
2014 The XML mechanism XInclude [12] is used for referencing libraries in
2015 SDPng documents. XInlcude works at the XML Information Set
2016 ("infoset") level, i.e. the mechanisms allows to have an integrating
2017 document reference fragment documents, while these fragments are
2018 well-formed (and, if applicable, valid) documents themselves. By
2019 resolving XInclude directives in integrating documents the documents'
2020 infosets are "merged" together, enabling applications to operate on
2021 the resulting infosets as if it had been generated by parsing a
2022 single, monolithic document.
2024 Inclusion at the XML infoset level has the advantage that documents
2025 are standalone -- they can be validated independently. Another
2026 advantage is that is relatively easy to generate a "merged" infoset
2027 for applications that are not able to resolve references to libraries
2028 themselves.
2030 An alternative for XInclude would be to use references that are
2031 resolved by applications. For XML, this would probably mean to use
2032 an XLink-based approach. This solution would require the definition
2033 of an SDPng link element type and require applications to support
2034 XLink (or at least the SDPng-relevant subset thereof). The inclusion
2035 at the application level is however problematic, because it does not
2036 result in a common integrated XML document infoset but would require
2037 applications to handle multiple infosets, i.e. multiple documents.
2039 5.6 Details on the use of specific XML Mechanisms
2041 This section specifies the use of specific XML mechanisms for SDPng.
2042 In order to allow for efficient parsing and processing, not all
2043 features of XML Schema are allowed. Some variable information is set
2044 to fixed values to allow the development of simplistic servers.
2046 5.6.1 Default Namespace
2048 SDPng document instances MUST use the SDPng namespace
2049 "http://www.iana.org/sdpng". That means, the general SDPng
2050 identifiers can be used without namespace prefixes.
2052 5.6.2 Qualified Locals
2054 XML Schema allows to specify qualification of elements and
2055 attributes. It is possible to use non-qualified element and
2056 attribute names in Schema definitions and document instances for so-
2057 called "local definitions" (this is the default setting). "Local
2058 Definitions" are contained within "global definitions" in an XML
2059 schema definition. In order to simplify parsing and processing of
2060 SDPng document instances, all elements MUST be fully qualified.
2061 Attribute names MUST NOT be fully qualified, they are considered to
2062 have the same namespace as their corresponding elements.
2064 This means, the SDPng Schema definition contains the following
2065 attributes for the "schema" element, that MUST also be used by SDPng
2066 profiles:
2068 o elementFormDefault="qualified"
2069 This means that "locally defined" elements that are used within
2070 the scope of fully-qualified elements MUST always be fully
2071 qualified as well.
2073 o attributeFormDefault="unqualified"
2074 This means that attribute names do not have to be fully qualified.
2075 Implementations MUST infer the namespace for attributes from the
2076 namespace of the element that the attribute belongs to. Note that
2077 the specification of XML Namespaces [11] defines that default
2078 namespaces do not apply to attributes. In profile definitions,
2079 all attributes MUST be defined locally. The same holds for the
2080 base SDPng schema.
2082 These rules make SDPng document instances process-able by non-Schema-
2083 aware XML parsers by requiring all element names to be fully
2084 qualified (no "local elements").
2086 5.6.3 Fixed Namespace Prefixes
2088 In order to facilitate the development of basic implementations, a
2089 few commonly used namespaces names are associated with fixed
2090 prefixes, i.e. document instances and libraries MUST always use these
2091 prefixes. These prefixes MUST NOT be used for namespaces names than
2092 the ones that are assigned to them. In order to ensure the
2093 uniqueness of namespace prefixes, namespace prefixes will be have to
2094 registered together with the corresponding namespace names.
2096 The namespace prefix for the SDPng namespace is "sdpng".
2098 5.7 SDPng Schema Definitions
2100 This section provides the definition of the base SDPng XML Schema.
2102 1. Section 5.7.1 contains the base definition that provides the
2103 general element types for SDPng.
2105 2. Section 5.7.2 contains a profile for audio codecs.
2107 3. Section 5.7.3 contains a profile for RTP payload type
2108 definitions.
2110 5.7.1 SDPng Base Definition
2112 This schema definition defines the general structure of SDPng
2113 document instances. It defines the top-level element type "desc"
2114 that can have a sequence of "def", "cfg", "constraints" and "conf"
2115 elements as element content.
2117 In addition, "extensions hooks" are provided that can be used by
2118 extension profiles providing definitions for specific applications.
2119 In general, these extension are implemented by deriving profile
2120 definitions from SDPng base definitions. The deployed XML Schema
2121 mechanisms are "deriving by extension" and "substitution groups".
2122 The SDPng base definition provides different base types (as
2123 complexType definitions) for elements that are to be used in "def",
2124 "cfg" and "conf" sections. In addition, it also defines specific
2125 element types as "head elements" with assigned types that are used
2126 for defining the content model of, e.g., the "def" element type.
2128 Profiles that provide new element types for specific applications
2129 will define types that are derived from the base types and provide
2130 the additional attributes and element content definitions that are
2131 required for the application. The XML element types that are defined
2132 in a profile are declared as valid substitutes for the base elements
2133 ("head elements") by setting the "substitutionGroup" attribute to the
2134 name of the "head element" type.
2136 For an extension-profile that provides new definition element types,
2137 e.g. for codec definitions, a new complexType would be defined that
2138 extends sdpng:Definition (see below). An element type definition
2139 that assigns that new type must then be declared to be in the
2140 substitutionGroup "sdpng:d".
2142 This mechanism allows common rules for attributes and content models
2143 to be defined in base element definition and re-used by extension
2144 profiles and it also allows validating parsers to identify the
2145 correct type of elements that have been defined by profile
2146 definitions.
2148 The SDPng Base Definition:
2150
2156
2157
2158 This schema definition defines the general structure of SDPng
2159 document instances. It provides base type and base element
2160 definition for elements to occur in the different sections (def,
2161 cfg, constraints, conf) to be derived from in extension-profile
2162 definitions.
2164 For an extension-profile that provides new definition element
2165 types, e.g. for codec definitions, a new complexType would be
2166 defined that extends sdpng:Definition (see below). An element
2167 type definition that assigns that new type must then be declared
2168 to be in the substitutionGroup "sdpng:d".
2169
2170
2171
2172
2173
2174 The top-level element of an SDPng document. It defines the
2175 overall structure of an SPDng document.
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2188
2190
2191
2192 The definitions section
2193
2194
2195
2196
2197
2198
2199
2201
2203
2204
2205 The configurations section
2206
2207
2208
2209
2210
2211
2212
2214
2216
2217
2218 The constraints section
2220
2221
2222
2223
2224
2225
2226
2228
2230
2231
2232 The conference section
2233
2234
2236
2238
2239
2240
2241 Placeholder base element for a definition element in the
2242 definitions section. To be derived from by specific definition
2243 element type definitions.
2244
2245
2246
2248
2250
2251
2252
2253 Placeholder base element for a configuration element in the
2254 configurations section. To be derived from by specific
2255 configuration element type definitions.
2256
2257
2258
2260
2262
2263
2264
2265 Placeholder base element for a contraint element in the
2266 contraints section. To be derived from by specific constraint
2267 element type definitions.
2269
2270
2271
2273
2275
2276
2277
2278 The base type for definition. Defines a attribute "name" for
2279 naming definitions.
2280
2281
2282
2283
2285
2287
2288
2289
2290 The specification of a component consists of a sequence of
2291 alternatives.
2292
2293
2294
2295
2296
2297
2298
2299
2301
2302
2303
2304 Each alternative consists of a "sc" (session configuration)
2305 element. The "sc" element is a base element of base type
2306 "sdpng:Session" that is used to derive specific session types
2307 in extension profiles.
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2319
2320
2321
2322 The (abstract) base type for session elements. To be derived
2323 from in extension profiles.
2324
2325
2326
2328
2330
2331
2332
2333 The current content model for constraints is a sequence of
2334 "sdpng:par" elements. In each "par" element a sequence of
2335 "use-alt" elements may be used to specific the definitions
2336 that may used in parallel. Each "use-alt" element can define
2337 the number of minimum and maximum instantiations.
2338
2339
2340
2341
2342
2343
2345
2346
2347
2348
2349
2350
2351
2352
2354
2355
2356
2357
2359
2361
2362
2364
2366
2367
2368
2369
2370
2371
2373
2374
2375
2376 The base type for conference meta inforformation
2377 element. Currently, there is no common content model defined.
2378
2379
2380
2382
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2401
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2429 5.7.2 Audio Codec Profile
2431 The following profile defines an element type that can be used for
2432 specifying audio codec characteristics. The element "audio:codec" is
2433 of type "audio:AudioCodec" which is derived from the SDPng base type
2434 "sdpng:Definition". The element "audio:codec" is declared to have
2435 the substitution group "sdpng:d" (the "head element" of the SDPng
2436 base definition).
2438 This means, "audio:codec" element can be used as child elements in
2439 "sdpng:def" elements. In addition to the attributes specified here
2440 "audio:codec" elements will also have to provide a "name" attribute
2441 as defined by "sdpng:Definition".
2443
2450
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2465
2466
2467
2468
2469
2470
2471
2472
2474 5.7.3 RTP profile
2476 The following profile defines element types that can be used for
2477 specifying RTP payload types and RTP session configurations. The
2478 element "rtp:pt" is of type "rtp:PayloadType" which is derived from
2479 the SDPng base type "sdpng:Definition". The element "rtp:pt" is
2480 declared to have the substitution group "sdpng:d" (the "head element"
2481 of the SDPng base definition).
2483 The element "rtp:session" is of type "rtp:Session" which is derived
2484 from the SDPng base type "sdpng:SessionConfig". The element
2485 "rtp:session" is declared to have the substitution group "sdpng:sc"
2486 (the "head element" of the SDPng base definition).
2488 The RTP profile in turn defines base types for the specification of
2489 transport parameters that are to be derived from by profiles that
2490 define rules for elements that can be used to specify parameters for
2491 specific transport mechanisms.
2493
2500
2503
2504
2505
2506 PayloadType, the element for payload type definitions is
2507 derived from "sdpng:Definition". Inside an element of this
2508 type, more definitions may be given (derived from
2509 sdpng:Definition themselves). If no definition is given in the
2510 content, a definition may be referenced using the "format
2511 attribute".
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2527
2529
2531
2533
2534
2535
2537
2538
2539
2540
2541
2542
2543
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2556
2557
2558
2560
2561
2562
2564
2565
2566
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2581
2583
2585 5.8 Issues
2587 o Libraries provide partially specified definitions, i.e. without
2588 transport parameters. How can SDPng documents reference the
2589 definitions and augment them with specific transport parameters?
2591 o Referencing extension profiles: XML-Schema does not support the
2592 declaration of multiple schemas via the schemaLocation attribute.
2593 Conceivable solution: When extension profiles are used, the SDPng
2594 description is a "multi-part" object, that consists of an
2595 integrating schema definition (that references all necessary
2596 profiles and the base definition) and the actual description
2597 document that is a schema instance of the integrating schema.
2599 o Uniqueness of attribute values: When libraries are used they will
2600 contain definition elements with "name" attributes for later
2601 referencing. How to avoid name clashes for those identifiers?
2602 When an SDPng document uses libraries from different sources they
2603 could be incompatible because of name collisions. Possible
2604 solution: Prefix such IDs with a namespace name (either explicitly
2605 or implicitly by interpreting applications). The explicit
2606 prefixes have the advantage that no special knowledge would be
2607 required to resolve links at the cost of very long ID values.
2609 6. Use of SDPng in conjunction with other IETF Signaling Protocols
2611 The SDPng model provides the notion of Components to indicate the
2612 intended types of collaboration between the users in e.g. a
2613 teleconferencing scenario.
2615 Three different abstractions are defined that are used for describing
2616 the properties of a specific Component:
2618 o a Capability refers to the fact that one of the involved parties
2619 supports one particular way of exchanging media -- defined in
2620 terms of transport, codec, and other parameters -- as part of the
2621 media session.
2623 o a Potential Configuration denotes a set of matching Capabilities
2624 from all those involved parties required to successfully realize
2625 one particular Component.
2627 o an Actual Configuration indicates the Potential Configuration
2628 which was chosen by the involved parties to realize a certain
2629 Component at one particular point in time.
2631 As mentioned before, this abstract notion of the interactions between
2632 a number of communicating systems needs to be mapped to the
2633 application scenarios of SDPng in conjunction with the various IETF
2634 signaling protocols: SAP, SIP, RTSP, and MEGACO.
2636 In general, this section provides recommendations and possible
2637 scenarios for the use of SDPng within specific protocols and
2638 applications. Is does not specify normative requirements.
2640 6.1 The Session Announcement Protocol (SAP)
2642 SAP is used to disseminate a previously created (and typically fixed)
2643 session description to a potentially large audience. An interested
2644 member of the audience will use the SDPng description contained in
2645 SAP to join the announced media sessions.
2647 This means that a SAP announcement contains the Actual Configurations
2648 of all Components that are part of the overall teleconference or
2649 broadcast.
2651 A SAP announcement may contain multiple Actual Configurations for the
2652 same Component. In this case, the "same" (i.e. semantically
2653 equivalent) media data from one configuration must be available from
2654 each of the Actual Configurations. In practice, this limits the use
2655 of multiple Actual Configurations to single-source multicast or
2656 broadcast scenarios.
2658 Each receiver of a SAP announcement with SDPng compares its locally
2659 stored Capabilities to realize a certain Component against the Actual
2660 Configurations contained in the announcement. If the intersection
2661 yields one or more Potential Configurations for the receiver, it
2662 chooses the one it sees fit best. If the intersection is empty, the
2663 receiver cannot participate in the announced session.
2665 SAP may be substituted by HTTP (in the general case, at least), SMTP,
2666 NNTP, or other IETF protocols suitable for conveying a media
2667 description from one entity to one or more other without the intend
2668 for further negotiation of the session parameters.
2670 Example from the SAP spec. to be provided.
2672 6.2 Session Initiation Protocol (SIP)
2674 SIP is used to establish and modify multimedia sessions, and SDPng
2675 may be carried at least in SIP INVITE and ACK messages as well as in
2676 a number of responses. From dealing with legacy SDP (and its
2677 essential non-suitability for capability negotiation), a particular
2678 use and interpretation of SDP has been defined for SIP.
2680 One of the important flexibilities introduced by SIP's usage of SDP
2681 is that a sender can change dynamically between all codecs that a
2682 receiver has indicated support (and has provided an address) for.
2683 Codec changes are not signaled out-of-band but only indicated by the
2684 payload type within the media stream. From this arises one important
2685 consequence to the conceptual view of a Component within SDPng.
2687 There is no clear distinction between Potential and Actual
2688 Configurations. There need not be a single Actual Configuration be
2689 chosen at setup time within the SIP signaling. Instead, a number of
2690 Potential Configurations is signaled in SIP (with all transport
2691 parameters required for carrying media streams) and the Actual
2692 Configuration is only identified by the payload type which is
2693 actually being transmitted at any point in time.
2695 Note that since SDPng does not explicitly distinguish between
2696 Potential and Actual Configurations, this has no implications on the
2697 SDPng signaling itself.
2699 SIP relies on an "offer/answer" model for the exchange of capability
2700 and configuration information. Either the caller or the callee sends
2701 an initial session description that is processed by the other side
2702 and returned. For capability negotiation, this means that the
2703 negotiation follows a two-stage-process: The "offerer" sends its
2704 capability description to the receiver. The receiver processes the
2705 offerers capabilities and his own capabilities and generates a result
2706 capability description that is sent back to the offerer. Both sides
2707 now know the commonly supported configurations and can initiate the
2708 media sessions.
2710 Because of this strict "offer/answer" model, the offerer must already
2711 send complete configurations (i.e. include transport addresses) along
2712 with the capability descriptions. The answer must also contain
2713 complete configuration parameters. The following figure shows, how
2714 SDPng content can be used in an INVITE request with a correspong 200
2715 OK message.
2717 Simple description document with only one alternative:
2719 F1 INVITE A -> B
2721 INVITE sip:B@example.com SIP/2.0
2722 Via: SIP/2.0/UDP hostA.example.com:5060
2723 From: A
2724 To: B
2725 Call-ID: 1234@hostA.example.com
2726 CSeq: 1 INVITE
2727 Contact:
2728 Content-Type: application/sdpng
2729 Content-Length: 685
2731
2732
2735
2736
2738
2739
2740
2741
2742
2744
2745
2746
2747
2749
2750
2752
2753
2754
2755 Telephony media stream
2756
2757
2759 ==================================================
2761 F2 (100 Trying) B -> A
2763 SIP/2.0 100 Trying
2764 Via: SIP/2.0/UDP hostA.example.com:5060
2765 From: A
2766 To: B
2767 Call-ID: 1234@hostA.example.com
2768 CSeq: 1 INVITE
2769 Content-Length: 0
2771 ==================================================
2773 F3 180 Ringing B -> A
2775 SIP/2.0 180 Ringing
2776 Via: SIP/2.0/UDP hostA.example.com:5060
2777 From: A
2778 To: B ;tag=987654
2779 Call-ID: 1234@hostA.example.com
2780 CSeq: 1 INVITE
2781 Content-Length: 0
2783 ==================================================
2785 F4 200 OK B -> A
2787 SIP/2.0 200 OK
2788 Via: SIP/2.0/UDP hostA.example.com:5060
2789 From: A
2790 To: B ;tag=987654
2791 Call-ID: 1234@hostA.example.com
2792 CSeq: 1 INVITE
2793 Contact:
2794 Content-Type: application/sdpng
2795 Content-Length: 479
2797
2798
2801
2803
2805
2806
2807
2808
2809
2811
2813
2814
2815
2816
2817 ==================================================
2819 ACK from A to B omitted
2821 In the INVITE message, A sends B a description document, that
2822 specifies exactly one component with one alternative (the PCMU audio
2823 stream). All required transport parameters all already contained in
2824 the description. The rtp:udp element provides an attribute "role"
2825 with a value of "receive", indicating that the specified endpoint
2826 address is used by the endpoint to receive media data. The element
2827 also provides the attribute "endpoint" with a value of "A",
2828 denominating the endpoint that can receive data on the specified
2829 address. This means, the semantics of specified transport addresses
2830 in configuration descriptions are the same as for SDP (when used with
2831 SIP): An endpoint specifies where it wants to receive data.
2833 In the 200 OK message, B sends an updated description document to A.
2834 For the sake of conciseness, the conf element (containing meta
2835 information about the conference) has been omitted. B supports the
2836 payload format that A has offered and adds his own transport
2837 parameters to the configuration information, specifying the endpoint
2838 address where B wants to receive media data. In order to
2839 disambiguate its transport configurations from A's, B sets the
2840 attribute "endpoint" to the value "B". The specific value of the
2841 "endpoint" attribute is not important, the only requirements are that
2842 a party that contributes to the session description, must use a
2843 unique name for the endpoint attribute and that a contributing party
2844 must use the same value for the endpoint attributes of all elements
2845 it adds to the session description.
2847 The following example shows a capability description that provides
2848 two alternatives for the audio component.
2850 Description document with two alternatives:
2852 F1 INVITE A -> B
2854 INVITE sip:B@example.com SIP/2.0
2855 Via: SIP/2.0/UDP hostA.example.com:5060
2856 From: A
2857 To: B
2858 Call-ID: 1234@hostA.example.com
2859 CSeq: 1 INVITE
2860 Contact:
2861 Content-Type: application/sdpng
2862 Content-Length: 935
2864
2865
2868
2870
2871
2873
2875
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2888
2889
2891
2892
2893
2894 Telephony media stream
2895
2896
2898 ==================================================
2900 F2 (100 Trying) B -> A
2902 SIP/2.0 100 Trying
2903 Via: SIP/2.0/UDP hostA.example.com:5060
2904 From: A
2905 To: B
2906 Call-ID: 1234@hostA.example.com
2907 CSeq: 1 INVITE
2908 Content-Length: 0
2910 ==================================================
2912 F3 180 Ringing B -> A
2914 SIP/2.0 180 Ringing
2915 Via: SIP/2.0/UDP hostA.example.com:5060
2916 From: A
2917 To: B ;tag=987654
2918 Call-ID: 1234@hostA.example.com
2919 CSeq: 1 INVITE
2920 Content-Length: 0
2922 ==================================================
2924 F4 200 OK B -> A
2926 SIP/2.0 200 OK
2927 Via: SIP/2.0/UDP hostA.example.com:5060
2928 From: A
2929 To: B ;tag=987654
2930 Call-ID: 1234@hostA.example.com
2931 CSeq: 1 INVITE
2932 Contact:
2933 Content-Type: application/sdpng
2934 Content-Length: 479
2936
2937
2940
2941
2942
2944
2947
2949
2951
2952
2953
2954
2955
2956
2957
2958 ==================================================
2960 ACK from A to B omitted
2962 In the INVITE message, A sends B a description document, that
2963 specifies one component with two alternatives for the audio stream
2964 (PCMU and G.729). Since A wants to use the same transport address
2965 for receiving media data regardless of the payload format, A provides
2966 the transport specification in the def element and references this
2967 definition in the rtp:session elements for both alternatives by using
2968 the attribute "transport".
2970 In the 200 OK message, B sends an updated description document to A.
2971 B does only support PCMU, so it removes the alternative for G.729
2972 from the description. B also defines its transport address in the
2973 def element and references this definition by adding "B-rcv" to the
2974 attribute "transport" of the rtp:session element. (B could also have
2975 used the rtp:udp element inside the rtp:session element, but this
2976 example intends to demonstrate how to reference multiple transport
2977 definitions by using the attribute "transport").
2979 6.3 Real-Time Streaming Protocol (RTSP)
2981 In contrast to SIP, RTSP has, from its intended usage, a clear
2982 distinction between offering Potential Configurations (typically by
2983 the server) and choosing one out of these (by the client), and, in
2984 some cases; some parameters (such as multicast addresses) may be
2985 dictated by the server. Hence with RTSP, there is a clear
2986 distinguish between Potential Configurations during the negotiation
2987 phase and a finally chosen Actual Configuration according to which
2988 streaming will take place.
2990 Example from the RTSP spec to be provided.
2992 6.4 Media Gateway Control Protocol (MEGACOP)
2994 The MEGACO architecture also follows the SDPng model of a clear
2995 separation between Potential and Actual Configurations. Upon
2996 startup, a Media Gateway (MG) will "register" with its Media Gateway
2997 Controller (MGC) and the latter will audit the MG for its
2998 Capabilities. Those will be provided as Potential Configurations,
2999 possibly with extensive Constraints specifications. Whenever a media
3000 path needs to be set up by the MGC between two MGs or an MG needs to
3001 be reconfigured internally, the MGC will use (updated) Actual
3002 Configurations.
3004 Details and examples to be defined.
3006 7. Open Issues
3008 Definition of baseline libraries
3010 A registry (reuse of SDP mechanisms and names etc.) needs to be
3011 set up.
3013 Negotiation mechanisms for multiparty conferencing need to be
3014 formalized.
3016 Mapping to other media description formats (SDP, H.245, ...)
3017 should be provided. For H.245, this is probably a different
3018 document (belonging to the SIP-H.323 inter-working group).
3020 Implicit declaration of SDPng schema and default profiles
3022 References
3024 [1] Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements
3025 for Session Description and Capability Negotiation", Internet
3026 Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001.
3028 [2] Handley, M. and V. Jacobsen, "SDP: Session Description
3029 Protocol", RFC 2327, April 1998.
3031 [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen,
3032 "RTP: A Transport Protocol for Real-Time Applications", RFC
3033 1889, January 1996.
3035 [4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
3036 with Minimal Control", RFC 1890, January 1996.
3038 [5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
3039 Conferences with Minimal Control", draft-ietf-avt-profile-new-
3040 10.txt (work in progress), March 2001.
3042 [6] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
3043 M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP
3044 Payload for Redundant Audio Data", RFC 2198, September 1997.
3046 [7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
3047 Generic Forward Error Correction", RFC 2733, December 1999.
3049 [8] Perkins, C. and O. Hodson, "Options for Repair of Streaming
3050 Media", RFC 2354, June 1998.
3052 [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
3053 Protocol", RFC 2974, October 2000.
3055 [10] World Wide Web Consortium (W3C), "Extensible Markup Language
3056 (XML) 1.0 (Second Edition)", Status W3C Recommendation, Version
3057 http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.
3059 [11] World Wide Web Consortium (W3C), "Namespaces in XML", Status
3060 W3C Recommendation, Version http://www.w3.org/TR/1999/REC-xml-
3061 names-19990114, January 1999.
3063 [12] World Wide Web Consortium (W3C), "XML Inclusions (XInclude)
3064 Version 1.0", Status W3C Working Draft, Version
3065 http://www.w3.org/TR/2001/WD-xinclude-20010516, May 2001.
3067 [13] World Wide Web Consortium (W3C), "XML Schema Part 1:
3068 Structures", Version http://www.w3.org/TR/2001/REC-xmlschema-1-
3069 20010502/, Status W3C Recommendation, May 2001.
3071 [14] World Wide Web Consortium (W3C), "XML Schema Part 2:
3072 Datatypes", Version http://www.w3.org/TR/2001/REC-xmlschema-2-
3073 20010502/, Status W3C Recommendation, May 2001.
3075 [15] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
3076 SDP", draft-ietf-mmusic-sdp-offer-answer-01.txt (work in
3077 progress), February 2002.
3079 Authors' Addresses
3081 Dirk Kutscher
3082 TZI, Universitaet Bremen
3083 Bibliothekstr. 1
3084 Bremen 28359
3085 Germany
3087 Phone: +49.421.218-7595, sip:dku@tzi.org
3088 Fax: +49.421.218-7000
3089 EMail: dku@tzi.uni-bremen.de
3091 Joerg Ott
3092 TZI, Universitaet Bremen
3093 Bibliothekstr. 1
3094 Bremen 28359
3095 Germany
3097 Phone: +49.421.201-7028, sip:jo@tzi.org
3098 Fax: +49.421.218-7000
3099 EMail: jo@tzi.uni-bremen.de
3101 Carsten Bormann
3102 TZI, Universitaet Bremen
3103 Bibliothekstr. 1
3104 Bremen 28359
3105 Germany
3107 Phone: +49.421.218-7024, sip:cabo@tzi.org
3108 Fax: +49.421.218-7000
3109 EMail: cabo@tzi.org
3111 Appendix A. Base SDPng Specifications for Audio Codec Descriptions
3113 [5] specifies a number of audio codecs including short name to be
3114 used as reference by session description protocols such as SDP and
3115 SDPng. Those codec names, as listed in the first column of the above
3116 table, are used to identify codecs in SDPng.
3118 The following sections indicate the default values that are assumed
3119 if nothing else than the codec reference is specified.
3121 The following audio:codec attributes are defined for audio codecs:
3123 name: the identifier to be later used for referencing the codec spec
3125 encoding: the RTP/AVP profile identifier as registered with IANA
3127 mime: the MIME type; may alternatively be specified instead of
3128 "encoding"
3130 channels: the number of independent media channels
3132 pattern: the media channel pattern for mapping channels to payload
3134 sampling: the sample rate for the codec (which in most cases equals
3135 the RTP clock)
3137 Furthermore, options may be defined of the following format:
3139
3141 if a value is associated with the option (note that arbitrary complex
3142 values are allowed), or alternatively:
3144
3146 if the option is just a boolean indicator.
3148 Attributes for the "option" tag are the following:
3150 id: the identifier for the option (variable name)
3152 collaps: the collapsing rules for this optional element, defined as
3153 follows:
3155 min: for numeric values only
3157 max: for numeric values only
3158 x: intersection of enumerated values, value lists
3160 A.1 DVI4
3162
3164
3165
3166
3167
3169 Note that there is no default sampling rate specified for DVI4 and
3170 hence a sampling rate MUST be specified.
3172 A.2 G.722
3174
3175
3177 Note as per [5] that the RTP clock rate is 8000Hz rather than 16000
3178 Hz.
3180 A.3 G.726
3182
3183
3184
3185
3187
3189 A.4 G.728
3191
3192
3194 A.5 G.729
3196 G.729 Annex A: reduced complexity of G.729
3197 G.729 Annex B: comfort noise
3199
3200
3202 For further codec description, the following options (which carry no
3203 values associated with them) MAY be included:
3205
3206
3208
3209
3211 As stated in [5], the use of these options can be detected within the
3212 media stream.
3214 A.6 G.729 Annex D and E
3216
3217
3219 The following option MAY be used with both Annexes D and E:
3221
3222
3224 A.7 GSM
3226 A.7.1 GSM Full Rate
3228 The GSM Full Rate codec is indicated as follows:
3230
3231
3233 A.7.2 GSM Half Rate
3235 The GSM Half Rate codec is indicated as follows:
3237
3239 A.7.3 GSM Enhanced Full Rate
3241 The GSM Enhanced Full Rate codec is indicated as follows:
3243
3245 A.8 L8
3247
3249 A.9 L16
3251
3253
3254
3255
3256
3258 A.10 LPC
3260
3262 A.11 MPA
3264
3265
3267 A.12 PCMA and PCMU
3269
3270
3272
3273
3275 A.13 QCELP
3277
3278
3280 A.14 VDVI
3282
3284 Appendix B. SDPng Library for Audio Codec Definitions
3286 This section contains an SDPng library with the audio codec
3287 definitions from Appendix A.
3289
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3317
3319 Appendix C. SDPng Library for RTP Payload Format Definitions
3321 This section contains an SDPng library with the RTP payload format
3322 definitions from Appendix A.
3324
3331
3333
3335
3337
3338
3339
3341
3343
3345
3347
3349
3351
3353
3354
3355
3357
3359
3361
3363
3365
3367 Appendix D. Change History
3369 draft-ietf-mmusic-sdpng-04.txt
3371 * New section on capability negotiation (Section 4).
3373 * New section on referencing definitions (Section 3.3).
3375 * New section on properties (Section 3.3.2).
3377 * New section on definition groups (Section 3.3.3).
3379 draft-ietf-mmusic-sdpng-03.txt
3381 * Extension of the SDPng schema (use of Xlinks etc.)
3383 * Clarification in the text
3385 * Fixed examples
3387 * Added example libraries as appendices
3389 * More details on usage with SIP, including examples.
3391 draft-ietf-mmusic-sdpng-02.txt
3393 * Added a section on formal specification mechanisms (Section 5).
3395 draft-ietf-mmusic-sdpng-01.txt
3397 * renamed section "Syntax Proposal" to "Syntax Definition
3398 Mechanisms". More text on DTD vs. schema. Edited the example
3399 description.
3401 * updated example definitions in section "Definitions" and
3402 "Components & Configurations"
3404 * section "Session Attributes" replaces section "Session"
3406 * new appendix on audio codec definitions
3408 Full Copyright Statement
3410 Copyright (C) The Internet Society (2002). All Rights Reserved.
3412 This document and translations of it may be copied and furnished to
3413 others, and derivative works that comment on or otherwise explain it
3414 or assist in its implementation may be prepared, copied, published
3415 and distributed, in whole or in part, without restriction of any
3416 kind, provided that the above copyright notice and this paragraph are
3417 included on all such copies and derivative works. However, this
3418 document itself may not be modified in any way, such as by removing
3419 the copyright notice or references to the Internet Society or other
3420 Internet organizations, except as needed for the purpose of
3421 developing Internet standards in which case the procedures for
3422 copyrights defined in the Internet Standards process must be
3423 followed, or as required to translate it into languages other than
3424 English.
3426 The limited permissions granted above are perpetual and will not be
3427 revoked by the Internet Society or its successors or assigns.
3429 This document and the information contained herein is provided on an
3430 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
3431 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
3432 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
3433 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
3434 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3436 Acknowledgement
3438 Funding for the RFC Editor function is currently provided by the
3439 Internet Society.