idnits 2.17.1
draft-ietf-mmusic-sdpng-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1.a on line 16.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 2511.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2483.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2490.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2496.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
2502), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 36.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== 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 separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 21 instances of too long lines in the document, the longest
one being 16 characters in excess of 72.
** There are 280 instances of lines with control characters in the document.
== There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
** 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 208: '...n is an optional feature, which MAY be...'
RFC 2119 keyword, line 489: '...ions. Specific procedures that MUST be...'
RFC 2119 keyword, line 676: '... This section is OPTIONAL for a SDPng ...'
RFC 2119 keyword, line 680: '...ng. This section is OPTIONAL for SDPng...'
RFC 2119 keyword, line 686: '... section MUST be present in any SDPn...'
(73 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- 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 (February 20, 2005) is 7004 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: 'RF2974' on line 1193
-- Looks like a reference, but probably isn't: 'RFC3261' on line 1343
== Unused Reference: '1' is defined on line 1702, but no explicit reference
was found in the text
== Unused Reference: '3' is defined on line 1709, but no explicit reference
was found in the text
== Unused Reference: '4' is defined on line 1713, but no explicit reference
was found in the text
== Unused Reference: '5' is defined on line 1716, but no explicit reference
was found in the text
== Unused Reference: '6' is defined on line 1720, but no explicit reference
was found in the text
== Unused Reference: '7' is defined on line 1723, but no explicit reference
was found in the text
== Unused Reference: '10' is defined on line 1733, but no explicit
reference was found in the text
== Unused Reference: '11' is defined on line 1737, but no explicit
reference was found in the text
== Unused Reference: '12' is defined on line 1741, but no explicit
reference was found in the text
== Unused Reference: '14' is defined on line 1748, but no explicit
reference was found in the text
== Unused Reference: '15' is defined on line 1752, but no explicit
reference was found in the text
== Unused Reference: '17' is defined on line 1758, 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 2733 (ref. '6') (Obsoleted by RFC 5109)
** Downref: Normative reference to an Informational RFC: RFC 2354 (ref. '7')
** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '8')
-- Possible downref: Non-RFC (?) normative reference: 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'
** Obsolete normative reference: RFC 2279 (ref. '16') (Obsoleted by RFC
3629)
Summary: 17 errors (**), 0 flaws (~~), 15 warnings (==), 14 comments
(--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 mmusic Kutscher
3 Internet-Draft Ott
4 Expires: August 21, 2005 Bormann
5 TZI, Universitaet Bremen
6 February 20, 2005
8 Session Description and Capability Negotiation
9 draft-ietf-mmusic-sdpng-08.txt
11 Status of this Memo
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with RFC 3668.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress".
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt
31 To view the list Internet-Draft Shadow Directories, see
32 http://www.ietf.org/shadow.html.
34 Copyright Notice
36 Copyright (C) The Internet Society (2005). All Rights Reserved.
38 Abstract
40 This document defines a language for describing multimedia sessions
41 with respect to configuration parameters and capabilities of
42 end-systems. The description language is independent of specific
43 application scenarios (session announcement, session setup for
44 interactive communication etc.) and is not limited to specific media
45 types, capabilities, or configuration parameters.
47 This document is a product of the Multiparty Multimedia Session
48 Control (MMUSIC) working group of the Internet Engineering Task
49 Force. Comments are solicited and should be addressed to the working
50 group's mailing list at mmusic@ietf.org and/or the authors.
52 Document Revision
54 $Revision: 6.21 $
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Terminology and System Model . . . . . . . . . . . . . . . . 7
60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11
61 3.1 Outline of the Negotiation Process . . . . . . . . . . . . . 11
62 3.2 SDPng Data Types . . . . . . . . . . . . . . . . . . . . . . 13
63 3.3 Application-specific Vocabulary . . . . . . . . . . . . . . 15
64 4. SDPng Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
65 4.1 SDPng Base Syntax . . . . . . . . . . . . . . . . . . . . . 16
66 4.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 18
67 4.2.1 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
68 4.2.2 Token Sets . . . . . . . . . . . . . . . . . . . . . . . . . 19
69 4.2.3 Numerical Values . . . . . . . . . . . . . . . . . . . . . . 19
70 4.2.4 Numerical Ranges . . . . . . . . . . . . . . . . . . . . . . 19
71 4.2.5 Sample SDPng cap Element . . . . . . . . . . . . . . . . . . 20
72 4.2.6 Referencing Capability Elements . . . . . . . . . . . . . . 21
73 4.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 21
74 4.4 Configurations . . . . . . . . . . . . . . . . . . . . . . . 23
75 4.5 Constraints . . . . . . . . . . . . . . . . . . . . . . . . 25
76 4.6 Session Information . . . . . . . . . . . . . . . . . . . . 25
77 4.7 Summary of SDPng XML-Syntax . . . . . . . . . . . . . . . . 26
78 5. Usage of SDPng in Different Application Scenarios . . . . . 28
79 5.1 Broadcast/Announcement Scenarios . . . . . . . . . . . . . . 28
80 5.2 Real-Time-Streaming . . . . . . . . . . . . . . . . . . . . 29
81 5.3 Two-Way Session Setup . . . . . . . . . . . . . . . . . . . 31
82 5.4 Multi-Party-Conferencing with Negotiation . . . . . . . . . 38
83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39
84 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 40
85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
86 References . . . . . . . . . . . . . . . . . . . . . . . . . 42
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43
88 A. Formal Syntax Specifications . . . . . . . . . . . . . . . . 44
89 A.1 SDPng Base DTD . . . . . . . . . . . . . . . . . . . . . . . 44
90 A.2 SDPng XML-Schema Specification . . . . . . . . . . . . . . . 45
91 B. Sample Package Definitions . . . . . . . . . . . . . . . . . 51
92 B.1 Sample RTP Package Definition . . . . . . . . . . . . . . . 51
93 B.2 Sample Audio Package Definition . . . . . . . . . . . . . . 52
94 B.3 Sample Video Package Definition . . . . . . . . . . . . . . 52
95 C. Sample SDPng Description . . . . . . . . . . . . . . . . . . 54
96 D. Change History . . . . . . . . . . . . . . . . . . . . . . . 58
97 Intellectual Property and Copyright Statements . . . . . . . 61
99 1. Introduction
101 Different applications in the multimedia realtime communication
102 domain require a means for session description and capability
103 negotiation. For example, for establishing an interactive audio
104 communication session between two participants, end-systems must be
105 dynamically configured with respect to codec types, codec parameters,
106 transport protocol parameters and other configuration details. All
107 these parameters can be viewed as the configuration for a session,
108 and a session description language is used to describe this
109 configuration unambiguously.
111 While the fundamental requirement to describe session parameters
112 applies to all application scenarios, there are differences in how
113 configurations are obtained and distributed among participants. For
114 broadcast applications, e.g., sessions that are announced using SAP
115 or IMG protocols, the sender is typically distributing a session
116 description to potential receivers, describing the technical
117 parameters (e.g., multicast addresses, port numbers, codecs etc.) and
118 providing additional information about the session such as
119 meta-information (about the content) and scheduling information.
120 While a sender might provide alternative variants of one specific
121 broadcast event (different language versions, different media codec
122 configurations for different quality levels etc.) there is typically
123 no negotiation process between sender and receiver in order to obtain
124 the optimal configuration for a specific receiver. Instead, the
125 sender may provide different potential configurations and the
126 receiver would select the most appropriate one.
128 Real-time-streaming applications such as "video-on-demand" provide
129 similar but slightly different requirements. Still the sender is
130 typically providing a set of different potential configurations, out
131 of which the receiver may select the most appropriate one, so there
132 is not really a negotiation of content and its representation (on the
133 session description level). But, differently to the aforementioned
134 scenarios, the receiver must tell the sender the endpoint address,
135 i.e., where media data should be sent to. Depending on the control
136 protocol, this may be specified using the session description
137 language or other means (as it is done with RTSP).
139 Multiparty multimedia conferencing is one of the applications that
140 require dynamic interchange of end-system capabilities and the
141 negotiation of a parameter set that is appropriate for all sending
142 and receiving end-systems in a conference. For spontaneously
143 initiated conferences including Internet phone calls or ad-hoc
144 multiparty conferences, fixed settings for parameters such as media
145 types, their encoding etc. can easily inhibit the initiation of
146 conferences, for example in situations where a caller insists on a
147 fixed audio encoding that is not available at the callee's
148 end-system.
150 To allow for spontaneous conferences, the process of defining a
151 conference's parameter set must therefore be performed either at
152 conference start (for conferences with a fixed set of participants)
153 or maybe (potentially) even repeatedly every time a new participant
154 joins an active conference. The latter approach may not be
155 appropriate for every type of conference without applying certain
156 policies: For conferences with TV-broadcast or lecture
157 characteristics (one main active source) it is usually not desired to
158 re-negotiate parameters every time a new participant with an exotic
159 configuration joins because it may inconvenience existing
160 participants or even exclude the main source from media sessions. But
161 conferences with equal "rights" for participants that are open for
162 new participants on the other hand would need a different model of
163 dynamic capability negotiation, for example a telephone call that is
164 extended to a 3-parties conference at some time during the session.
166 SDP [2] allows to specify multimedia sessions (i.e. conferences,
167 "session" as used here is not to be confused with "RTP session"!) by
168 providing general information about the session as a whole and
169 specifications for all the media streams (RTP sessions and others) to
170 be used to exchange information within the multimedia session.
172 Currently, media descriptions in SDP are used for two purposes:
174 o to describe session parameters for announcements and invitations
175 (the original purpose of SDP) and
177 o to describe the capabilities of a system and possibly provide a
178 choice between a number of alternatives (which SDP was not
179 designed for).
181 A distinction between these two "sets of semantics" was initially
182 only made implicitly. While numerous extensions to SDP were
183 developed to account for various aspects of interactive session
184 establishment (the offer/answer model in RFC 3264, grouping of media
185 sessions in RFC 3388, and simple capability declaration in RFC 3407,
186 among others), their expressiveness is naturally constrained by the
187 simple (and veru limited) SDP syntax.
189 SDPng, the session description languages specified in this document,
190 provide a common, XML-based framework for session description and
191 capability description for the aforementioned application scenarios.
192 It allows for distributing "fixed" configuration descriptions in
193 broadcast application scenarios but also supports the dynamic
194 negotiation of session parameters for interactive multimedia
195 conferences.
197 In order to support a broad range of different applications, SDPng
198 itself is completely application-agnostic. The base specification
199 does not define any application-specific vocabulary, e.g., media
200 types, codecs and their configuration parameters etc., but is
201 intended as an extensible framework that provides the necessary
202 extensibility mechanisms for supporting both future applications and
203 future transport and encoding mechanisms.
205 With respect to capability negotiation, SDPng is based on the
206 following principles:
208 Capability negotiation is an optional feature, which MAY be
209 employed for specific applications, e.g., session setup for
210 interactive communication.
212 SDPng provides the framework for describing capabilities and
213 linking them to configurations of application sessions, but the
214 base specification does not prescribe negotiation algorithms such
215 as feature matching.
217 The SDPng base specification provides the necessary support for
218 application-independent capability negotiation, i.e., an SDPng
219 processor that receives capability descriptions from one or
220 multiple participants does not need to understand the capability
221 semantics in order to process the different capability
222 descriptions. For this purpose, SDPng provides a well-defined set
223 of data types and defines a value representation that allows SDPng
224 processors to infer data types without requiring access to schema
225 definitions and without requiring application-specific knowledge.
227 For most application classes, especially for broadcast applications,
228 the session description will have to provide information about the
229 session that is not used to configure end-systems but rather to
230 facilitate content navigation for human users. For example, This
231 meta-information can include author/source details, additional
232 information about the whole session or individual media sessions,
233 scheduling information and other, arbitrary information that is
234 related to the session but not directly required to achieve
235 interoperability between end-systems. SDPng provides fundamental
236 mechanisms that support the inclusion of meta-information:
238 Descriptions of application components (media sessions) and
239 alternative configurations can be labeled to enable later
240 referencing, i.e., for associating meta-information. For example,
241 in a multi-language TV broadcast session, the language information
242 could be provided by a meta-information fragment that assigns
243 language tags to media session descriptions by referencing them.
245 SDPng itself does not define vocabulary for specifying
246 meta-information, but allows for including arbitrary
247 meta-information fragments, e.g., MPEG-7 descriptions. These
248 description may either be included or inline or be referenced by
249 URIs.
251 In the following, we first introduce a model for session description
252 and capability negotiation as well as the basic terms used throughout
253 this specification (Section 2). In Section 3, we provide an overview
254 of options for capability negotiation. Next, we outline the concept
255 for the concepts underlying SDPng and introduce the syntactical
256 components step by step in Section 4. Section 5 describes how SDPng
257 can be used in different application scenarios.
259 Appendix A provide formal specifications of SDPng such as XML DTD and
260 Schema definitions, Appendix B provides some sample package
261 definitions, Appendix C provides a sample SDPng description, and
262 Appendix D lists the change history.
264 2. Terminology and System Model
266 Any (computer) system has, at a time, a number of rather fixed
267 hardware as well as software resources. These resources ultimately
268 define the limitations on what can be captured, displayed, rendered,
269 replayed, etc. with this particular device. We term features enabled
270 and restricted by these resources "system capabilities".
272 Example: System capabilities may include: a limitation of the
273 screen resolution for true color by the graphics board; available
274 audio hardware or software may offer only certain media encodings
275 (e.g. G.711 and G.723.1 but not GSM); and CPU processing power,
276 available licenses, and quality of implementation may constrain
277 the possible video encoding algorithms.
279 In multiparty multimedia conferences, participants employ different
280 "components" in conducting the conference; similarly, a multimedia
281 (rather than plain TV) broadcast may comprise several components that
282 make up the full presentation.
284 Example: In lecture multicast conferences one component might be
285 the voice transmission for the lecturer, another the transmission
286 of video pictures showing the lecturer and the third the
287 transmission of presentation material.
289 Depending on system capabilities, user preferences and other
290 technical and policy constraints, different configurations can be
291 chosen to accomplish the use of these components in a conference.
293 Each component can be characterized at least by (a) its intended use
294 (i.e. the function it shall provide) and (b) one or more possible
295 ways to realize this function. Each way of realizing a particular
296 function is referred to as a "configuration".
298 Example: A conference component's intended use may be to make
299 transparencies of a presentation visible to the audience on the
300 Mbone. This can be achieved either by a video camera capturing the
301 image and transmitting a video stream via some video tool or by
302 loading a copy of the slides into a distributed electronic
303 white-board. For each of these cases, additional parameters may
304 exist, variations of which lead to additional configurations (see
305 below).
307 Two configurations are considered different regardless of whether
308 they employ entirely different mechanisms and protocols (as in the
309 previous example) or they choose the same and differ only in a single
310 parameter.
312 Example: In case of video transmission, a JPEG-based still image
313 protocol may be used, H.261 encoded CIF images could be sent, as
314 could H.261 encoded QCIF images. All three cases constitute
315 different configurations. Of course there are many more detailed
316 protocol parameters.
318 Each component's configurations are limited by the participating
319 system's capabilities. In addition, the intended use of a component
320 may constrain the possible configurations further to a subset
321 suitable for the particular component's purpose.
323 Example: In a system for highly interactive audio communication
324 the component responsible for audio may decide not to use the
325 available G.723.1 audio codec to avoid the additional latency but
326 only use G.711. This would be reflected in this component only
327 showing configurations based upon G.711. Still, multiple
328 configurations are possible, e.g. depending on the use of A-law or
329 u-Law, packetization and redundancy parameters, etc.
331 In modeling multimedia sessions, we distinguish two types of
332 configurations:
334 o potential configurations
335 (a set of any number of configurations per component) indicating a
336 system's functional capabilities as constrained by the intended
337 use of the various components;
339 o actual configurations
340 (exactly one per instance of a component) reflecting the mode of
341 operation of this component's particular instantiation.
343 Example: The potential configuration of the aforementioned video
344 component may indicate support for JPEG, H.261/CIF, and H.261/
345 QCIF. A particular instantiation for a video conference may use
346 the actual configuration of H.261/CIF for exchanging video
347 streams.
349 In summary, the key terms of this model are:
351 o A multimedia session (broadcast, streaming or conference) consists
352 of one or more conference components for multimedia "interaction".
354 o A component describes a particular type of interaction (e.g. audio
355 conversation, slide presentation) that can be realized by means of
356 different applications (possibly using different protocols).
358 o A configuration is a set of parameters that are required to
359 implement a certain variation (realization) of a certain
360 component. There are actual and potential configurations.
362 * Potential configurations describe possible configurations that
363 are supported by an end-system.
365 * An actual configuration is an "instantiation" of one of the
366 potential configurations, i.e. a decision how to realize a
367 certain component.
369 In less abstract words, potential configurations describe what a
370 system can do ("capabilities") and actual configurations describe
371 how a system is configured to operate at a certain point in time
372 (media stream spec).
374 To decide on a certain actual configuration, a negotiation process
375 needs to take place between the involved peers:
377 1. to determine which potential configuration(s) they have in
378 common, and
380 2. to select one of this shared set of common potential
381 configurations to be used for information exchange (e.g. based
382 upon preferences, external constraints, etc.).
384 Note that the meaning of the term "actual configuration" is highly
385 application-specific. For example, for audio transport using RTP, an
386 actual configuration is equivalent to a payload format (potentially
387 plus format parameters), whereas for other applications it may be a
388 MIME type.
390 In SAP-based [8] session announcements on the Mbone, for which SDP
391 was originally developed, the negotiation procedure is non-existent.
392 Instead, the announcement contains the media stream description sent
393 out (i.e. the actual configurations) which implicitly describe what a
394 receiver must understand to participate.
396 In point-to-point scenarios, the negotiation procedure is typically
397 carried out implicitly: each party informs the other about what it
398 can receive and the respective sender chooses from this set a
399 configuration that it can transmit.
401 Capability negotiation must not only work for 2-party conferences but
402 is also required for multi-party conferences. Especially for the
403 latter case it is required that the process to determine the subset
404 of allowable potential configurations is deterministic to reduce the
405 number of required round trips before a session can be established.
406 For instance, in order to be used with SIP, the capability
407 negotiation is required to work with the offer/answer model that is
408 for session initiation with SIP -- limiting the negotiation to
409 exactly one round trip.
411 The following list explains some terms used in this document:
413 Actual Configuration
414 An actual configuration is an "instantiation" of one of the
415 potential configurations, i.e. a decision how to realize a certain
416 component.
418 Component
419 A component describes a particular type of interaction (e.g. audio
420 conversation, slide presentation) that can be realized by means of
421 different applications (possibly using different protocols).
423 Package
424 A package is an application specific data schema for expressing
425 potential and actual configurations. For example, an audio package
426 specifies the data schema for audio codecs.
428 Potential Configuration
429 Potential configurations describe possible configurations that are
430 supported by an end-system ("capabilities").
432 3. Overview
434 SDPng is a description language for both potential configurations
435 (i.e. capabilities) of participants in multimedia conference and for
436 actual configurations (i.e. final specifications of parameters).
437 Capability negotiation is the process of generating a usable set of
438 potential configurations and finally an actual configuration from a
439 set of potential configurations provided by each potential
440 participant in a multimedia conference.
442 SDPng itself is an application-independent framework that defines a
443 description syntax that are enable an (optional) capability
444 negotiation process. It should be noted, that SDPng can be used
445 without capability negotiation and that the specific negotiation
446 algorithm is not specified in this document.
448 A capability description for an endpoint is a set of individual
449 capabilities, each of which provides a fixed type, e.g., a numeric
450 value or a list value. The set of types and the corresponding
451 abstract negotiation rules are defined in this memo. The SDPng data
452 types are relevant to all SDPng application domains, while the
453 processing rules are only applicable to application domains that rely
454 on capability negotiation.
456 In the following, we provide a conceptual overview of the negotiation
457 process in Section 3.1 and describe the different capability types
458 and the corresponding abstract negotiation rules in Section 3.2.
460 3.1 Outline of the Negotiation Process
462 SDPng supports the specification of endpoint capabilities and defines
463 a negotiation process: In a negotiation process, capability
464 descriptions are exchanged between participants. These descriptions
465 are processed in a "collapsing" step which results in a set of
466 commonly supported potential configurations. In a second step, the
467 final actual configuration is determined that is used for a
468 conference. This section specifies the usage of SDPng for capability
469 negotiation. It defines the collapsing algorithm and the procedures
470 for exchanging SDPng documents in a negotiation phase.
472 The description language and the rules for the negotiation phase that
473 are defined here are (in general) independent of the means by which
474 descriptions are conveyed during a negotiation phase (a reliable
475 transport service with causal ordering is assumed). There are however
476 properties and requirements of call signaling protocols that have
477 been considered to allow for a seamless integration of the
478 negotiation into the call setup process. For example, in order to be
479 usable with SIP, it must be possible to negotiate the conference
480 configuration within the two-way-handshake of the call setup phase.
481 In order to use SDPng instead of SDP according to the offer/answer
482 model defined in [13] it must be possible to determine an actual
483 configuration in a single request/response cycle.
485 Conceptually, the negotiation process comprises the following
486 individual steps (considering two parties, A and B, where A tries to
487 invite B to a conference). Please note that this describes the steps
488 of the negotiation process conceptually -- it does not specify
489 requirements for implementations. Specific procedures that MUST be
490 followed by implementations are given below.
492 1. A determines its potential configurations for the components that
493 should be used in the conference (e.g. "interactive audio" and
494 "shared whiteboard") and sends a corresponding SDPng instance to
495 B. This SDPng instances is denoted "CAP(A)".
497 2. B receives A's SDPng instance and analyzes the set of components
498 in the description. For each component that B wishes to support
499 it generates a list of potential configurations corresponding to
500 B's capabilities, denoted "CAP(B)".
502 3. B applies the collapsing function and obtains a list of potential
503 configurations that both A and B can support, denoted
504 "CAP(A)xCAP(B) = CAP(AB)".
506 4. B sends CAP(B) to A.
508 5. A also applies the collapsing function and obtains "CAP(AB)". At
509 this step, both A and B know the capabilities of each other and
510 the potential configurations that both can support.
512 6. In order to obtain an actual configuration from the potential
513 configuration that has been obtained, both participants have to
514 pick a subset of the potential configurations that should
515 actually be used in the conference and generate the actual
516 configuration. It should be noted that it depends on the specific
517 application whether each component must be assigned exactly one
518 actual configuration or whether it is allowed to list multiple
519 actual configurations. In this model we assume that A selects the
520 actual configuration, denoted CFG(AB).
522 7. A augments CFG(AB) with the transport parameters it intends to
523 use, e.g., on which endpoint addresses A wishes to receive data,
524 obtaining CFG_T(A). A sends CFG_T(A) to A.
526 8. B receives CFG_T(A) and adds its own transport parameters,
527 resulting in CFG_T(AB). CFG_T(AB) contains the selected actual
528 configurations and the transport parameters of both A and B (plus
529 any other SDPng data, e.g., meta-information on the conference).
530 CFG_T(AB) is the complete conference description. Both A and B
531 now have the following information:
533 CAP(A) A's supported potential configurations
535 CAP(B) B's supported potential configurations
537 CAP(AB) The set of potential configurations supported by both A
538 and B.
540 CFG(AB) The set of actual configurations to be used.
542 CFG_T(AB) The set of actual configurations to be used augmented
543 with all required parameters.
545 Note that the model presented here results in four SDPng messages. As
546 an optimization, this procedure can be abbreviated to two exchanges
547 by including the transport (and other) parameters into the potential
548 configurations. A embeds its desired transport parameters into the
549 list of potential configurations and B also sends all required
550 parameters in the response together with B's potential
551 configurations. Both A and B can then derive CFG_T(AB). Transport
552 parameters are usually not negotiable, therefor they have to be
553 distinguished from other configuration information.
555 Note also that, in case of multicast/broadcast scenarios, the sender
556 may simply provide the full description of the alternative
557 configurations including (transport) parameters. The potential
558 receivers will decide based upon this information whether or not they
559 are capable of receiving the respective media sessions and pick the
560 most suitable configuration.
562 3.2 SDPng Data Types
564 The description of actual configurations and the capability
565 negotiation process rely on a fixed set of data types with
566 corresponding processing rules. The following types are defined:
568 1. Tokens (text strings)
570 Example:
572 PCMU
574 Processing rule:
575 Ascertain identity (compare strings)
577 2. Token lists
579 Example:
581 8000 16000
583 Processing rule:
584 Determine common subset
586 3. Numbers
588 Example:
590
592 Processing rule:
593 Ascertain equality
595 4. Numerical ranges
597 Example:
599
601 Processing rule:
602 Determine common subrange
604 SDPng distinguishes between optional and mandatory capability
605 definitions, with different processing rules for the negotiation
606 process. Optional definitions are used for capabilities that can be
607 provided by an entity but do not have to be supported by all
608 participants. For example, an audio codec could provide optional
609 codec parameters. The use of these parameters needs to be declared by
610 a session description, but if the parameter is not understood by all
611 implementations, a session can be established nevertheless. As a
612 result, the failure of a single processing step for a definition that
613 has been marked as "optional" does not lead to a failure of the
614 capability negotiation as a whole.
616 A mandatory capability on the other hand has to be supported by all
617 participants. For example, the specification of an audio codec for an
618 audio capability is mandatory, and for obtaining an interoperable
619 configuration, all participants must support the same audio codec or
620 set of audio codecs.
622 In addition to capabilities, a SDPng description can also provide
623 parameters that are not negotionable, e.g., transport parameters. In
624 SDPng, there is a distinction between capability definitions (that
625 are subject to a negotiation process) and parameters that are
626 specified by each participant. In a description of alternative
627 configurations for a specific component, capabilities and parameters
628 can be referred to and describe the configurations.
630 3.3 Application-specific Vocabulary
632 While the SDPng specification defines the fundamental types, abstract
633 processing rules and the syntax definition for SDPng descriptions, it
634 does not define any application-specific vocabulary.
635 Application-specific vocabulary is defined in SDPng packages. An
636 SDPng package defines a schema for application specific capability
637 and parameter descriptions. Based on the description types specified
638 by the SDPng base specification, a package definition specifies the
639 capability and parameter definitions allowed for a specific
640 application, the types of definitions and additional attributes,
641 e.g., whether a definition element is optional with respect to the
642 capability negotiation or not.
644 The SDPng base specification does define some fundamental
645 requirements for definition elements that are specified in package
646 definitions, for example XML attributes for elements. Appendix A.2
647 provides an XML Schema definition that specifies some base types to
648 be used for package definitions.
650 In order to allow for an application independent processing of SDPng
651 description documents, SDPng descriptions are standalone, i.e., the
652 package definition is not required to process a corresponding SDPng
653 document. All information, e.g., the type of definitions and
654 additional attributes are contained in the SDPng document itself. An
655 SDPng implementation can thus be processed without access to the
656 package definition.
658 4. SDPng Syntax
660 This section specifies the SDPng base syntax. An SDPng description is
661 an XML document consisting of up to five parts:
663 Capabilities
665 Definitions
667 Configurations
669 Constraints
671 Session Information
673 The Capabilities section provides a list of individual capabilities.
674 In a capability negotiation process, these capabilities are matched
675 against corresponding definitions of other participants' capability
676 descriptions. This section is OPTIONAL for a SDPng description
677 document.
679 The Definitions section provides definitions of commonly used
680 parameters for later referencing. This section is OPTIONAL for SDPng
681 descriptions.
683 The Configurations section provides the description of the different
684 conference components (applications in a conference). Each component
685 description can provide a list of alternative configurations. This
686 section MUST be present in any SDPng description.
688 The Constraints section provides contraints on combinations of
689 configurations. This section is OPTIONAL for SDPng descriptions.
691 The Session Information section provides meta information on the
692 conferences and on individual components. This section is OPTIONAL
693 for SDPng documents.
695 4.1 SDPng Base Syntax
697 An SDPng description is an XML document. The document root element
698 MUST be an element of type "sdpng". The XML vocabulary for the SDPng
699 base specification resides in the XML namespace "http://www.iana.org/
700 sdpng". The root element of an SDPng description MUST define an XML
701 default namespace "http://www.iana.org/sdpng". In addition, the
702 "sdpng" element MUST map the namespace prefix "sdpng" to the
703 namespace name "http://www.iana.org/sdpng". The "sdpng" element type
704 provides the child elements "cap", "def", "cfg", "constraints", and
705 "info" for the different sections of the SDPng description. The
706 default namespace is also applied to these elements.
708 The encoding of the XML document MUST be UTF-8 (RFC2279, [16]).
710 The following figure depicts the overall SDPng document structure.
712
713
715
716 [...]
717
718
719 [...]
720
721
722 [...]
723
724
725 [...]
726
727
728 [...]
729
730
732 Appendix A.1 provides a XML DTD that defines a corresponding document
733 type.
735 Note that the elements for the optional sections "Capabilities",
736 "Definitions", "Contraints", and "Session-Level Information" are
737 OPTIONAL.
739 Application-specific vocabulary resides in its own namespace. For
740 each namespace name of an SDPng package, a namespace prefix MUST be
741 declared in the start tag of the "sdpng" element. The following
742 figure depicts the declaration of namespace prefixes for two package
743 namespaces:
745
746
750 [...]
751
753 4.2 Capabilities
755 A section for capability descriptions is an XML element that can
756 provide a list of child elements. The element type is called "cap"(in
757 the "sdpng" namespace). Each child element represents an individual
758 capability.
760 Each capability element MUST provide an attribute "name". The value
761 of this attribute SHOULD be composed of a prefix (representing a
762 namespace-name) and a unique name for the corresponding capability
763 within that namespace. The namespace-name designates a namespace for
764 the source of the capability definition, e.g., for the participant of
765 a conference. If a prefix is specified, it MUST be separated by a
766 colon (':') from the name. The namespace MUST be declared in the
767 respective element or in ancestor elements, e.g., the root "sdpng"
768 element. The following figure depicts a capability element inside a
769 "cap" element. Note that the child elements of "audio:codec" and the
770 other sections of the SDPng description are not shown.
772
773
775
776
777 [One or more feature elements]
778
780 [...]
781
782
784 Each capability element provides a set of features. Each feature is
785 represented by a child element. The element types are defined in
786 package definitions. XML Namespaces are used to disambiguate element
787 types and to allow for extensibility. Each feature element can
788 provide a "range" of values -- not only a single value. For example,
789 a feature element can specify a set of supported alternative values
790 for a given property, e.g., for the sampling rate of an audio codec.
791 SDPng provides two different ways for representing "value ranges": A
792 feature element can specify a set of tokens or a numerical range.
794 Each feature that is represented by an XML feature element has a
795 well-defined type that is specified in the package definition. The
796 type determines the representation of the element values in XML so
797 that type information is encoded implicitly in the description
798 document. For example, a token set can be identified by the presence
799 of whitespace separated list of token as element content of the
800 respective feature element. Each feature element MAY provide an
801 attribute "status". If this attribute is present it MUST provide one
802 of the following values:
804 opt:
805 This element describes an optional feature (as described by
806 Section 3.2).
808 The three different features types (as described in Section 3.2) are
809 represented as described in the following sections. Section 4.2.5
810 provides a complete example.
812 4.2.1 Tokens
814 Token elements provide a single token as element content. The token
815 is of type Nmtoken (name token) as defined by [9]. The following
816 example depicts a feature element of type token.
818 PCMU
820 Boolean values SHOULD be represented as token elements with a values
821 of either "true" or "false".
823 4.2.2 Token Sets
825 Token set elements provide a token list as element content. The token
826 is of type Nmtokens (name tokens) as defined by [9]. The following
827 example depicts a feature element of type token set.
829 8000 16000 32000
831 4.2.3 Numerical Values
833 Elements for numbers provide an attribute "val" with a numerical
834 value. The following example depicts a feature element of type
835 numerical value.
837
839 4.2.4 Numerical Ranges
841 Elements for numerical ranges can provide an attribute "min" and an
842 attribute "max". Both attributes provide a numerical value. At least
843 one of these attributes MUST be present. The following example
844 depicts a feature element of type numerical range.
846
848 4.2.5 Sample SDPng cap Element
850
851
853
854
855 PCMU
856 1 2
857 8000 16000
858
859
860 true
861
862
864 [...]
865
866
868 Capability elements MAY also provide elements from different XML
869 namespaces. For example, a video-codec capability MAY be described
870 with elements declaring general video capabilities, and this element
871 MAY provide a list of additional codec specific feature elements, as
872 depicted in the following example:
874
875
877
878
879 H.263+
880 QCIF
881
882 foo
883 bar
884
886 [...]
887
888
890 4.2.6 Referencing Capability Elements
892 The capablity elements of a "cap" element can be referenced in later
893 sections of the SDPng document. The fundamental model is that
894 capability elements specify individual capabilities (without
895 transport and other non-negotionable parameters) and that these
896 elements are later augmented in Definitions and Configurations
897 sections.
899 When referencing a capability element, e.g., the element video:codec,
900 the same element name (general identifier) is used. The referencing
901 element MUST provide an attribute "ref", and the value of this
902 attribute SHOULD provide the value of the attribute "name" of the
903 referenced element.
905 The referencing element MAY also provide additional feature elements
906 (that have not been provided by the referenced capability element).
907 The referencing element MAY also provide feature elements that have
908 already been provided by the referenced element.
910 The referencing element MAY provide an attribute "name". The
911 semantics of a reference are defined in the corresponding sections
912 where references to definitions are used, i.e., in Section 4.3 and in
913 Section 4.4.
915 4.3 Definitions
917 The Definitions section is an optional section that can provide
918 definitions of fixed parameters that are not negotionable such as
919 transport parameters. An SDPng description document MAY provide a
920 "def" element that can provide a set of definitions as child
921 elements.
923 Each child element of a "def" element provides an element type
924 specified in a package definition. Such child elements are referred
925 to as "definition elements". Definition elements can provide a set of
926 child elements, each of which specifies a specific configuration
927 value. Syntactically, these child elements MUST be "feature elements"
928 as specified in Section 4.2. Child elements of a definition element
929 MUST be of type Token or of type Numerical Value. A definition
930 element MUST provide an attribute "name" that is used to specify a
931 unique name in the scope of the current SDPng description. A
932 definition element MAY provide an attribute "ref" that is used to
933 reference a capability element as specified in Section 4.2.
935 The following example depicts a def element with one definition
936 element of type "rtp:udp". This element is used to specify fixed
937 parameters of an RTP session -- the allowable parameters would have
938 been specified in a corresponding SDPng RTP package.
940
941
944
945 [...]
946 [...]
947
949
950
951 ::1
952 9456
953 1
954
955
957
958 [...]
959
960
961 [...]
962
963
964 [...]
965
967
969 A definition element SHOULD reference a capability element provided
970 in the "cap" element, as depicted in the example. In the example, the
971 definition named "rtp-cfg1" provides RTP transport parameters and
972 references the RTP capability named "rtp:rtpudpip6". The semantics of
973 referencing the capability element are as follows:
975 o An implementation MUST process the newly defined element by
976 adopting the individual feature elements of the referenced
977 capability element.
979 o For feature elements that are present in both the capability
980 element and the description element, the feature elements of the
981 definition element take precedence over the feature elements of
982 the capability element.
984 4.4 Configurations
986 The Configurations section lists all the components that constitute
987 the multimedia application (IP telephone call, real-time streaming
988 application, multi-player gaming session etc.). For each of these
989 components, the actual configurations are given.
991 An SDPng document MUST provide a "cfg" element that represents the
992 Configurations section. The "cfg" element provides one or more
993 "component" element describing alternative configurations for the
994 component. The "cfg" element SHOULD provide at least one "component"
995 element. Each "component" element MUST provide an attribute "name"
996 that identifies the component uniquely in the scope of the SDPng
997 description. Each "component" element MAY provide an attribute status
998 of type CDATA that MAY be used to specify application specific status
999 information.
1001 Each "component" element MUST provide one or more "alt" element, each
1002 of which describes an alternative configuration for the component.
1003 Each "alt" element MUST provide an attribute "name" that provides a
1004 unique identification for the alternative in the scope of the SDPng
1005 description. In addition, each "alt" element MUST also provide an
1006 attribute "media" for specifying the media type for this particular
1007 alternative. Currently defined values for this attribute are "audio",
1008 "video", "application", "data", and "control". The semantics of these
1009 values are described in [2].
1011 Each "alt" element MUST provide one or more XML elements that
1012 describe the configuration parameters for the particular alternative
1013 configuration. The elements are defined by SDPng package
1014 specification and definitions from different packages can be mixed.
1015 The type of the elements and their order is application dependent.
1017 Each definition element that is contained in an "alt" element MAY
1018 provide an attribute "ref". The "ref" attribute is used to specify a
1019 reference to a capability element (from a "cap" section) or to a
1020 definition element (from a "def" section). The value of an "ref"
1021 element MUST provide the value of a "name" attribute of an existing
1022 capability or definition element. A definition element MAY provide
1023 child elements (for the specification of additional feature and
1024 configuration parameters) but it MAY also be an empty element. The
1025 semantics of referencing the capability element are as follows:
1027 o An implementation MUST process the newly defined element by
1028 adopting the individual feature elements of the referenced
1029 capability or definition element.
1031 o For feature elements that are present in both the capability/
1032 definition element and the current definition element, the feature
1033 elements of the current definition element take precedence over
1034 the feature elements of the referenced element.
1036 It should be noted that the inclusion of definition by reference is
1037 NOT MANDATORY. For certain applications such as session announcement,
1038 it may be sufficient to provide the configuration data directly
1039 inside an "alt" element.
1041 The following example depicts the description of a single
1042 configuration for a component named "interactive-audio". The
1043 description of the configuration references the "avp:pcmu" audio
1044 codec definition from the "cap" element and the "rtp-cfg1" RTP
1045 session definition from the "def" element. In this example, both
1046 elements of the "alt" element are empty elements that adopt the
1047 specified values from the referenced elements.
1049
1050
1053
1054 [...]
1055 [...]
1056
1058
1059
1060 ::1
1061 9456
1062 1
1063
1064
1066
1067
1068
1069
1070
1071
1072
1074
1075
1076 [...]
1077
1078
1080 [...]
1081
1083
1085 4.5 Constraints
1087 The Constraints section allows to express constraints on the
1088 combination of configurations that apply across different components.
1089 This feature is intended for specialized devices with strict
1090 limitations on, e.g., parallel codec instantiations due to limited
1091 DSP resources. The SDPng base specification does not define the use
1092 of constraints. Instead, the usage of constraints will be specified
1093 in a separate document.
1095 The "constraints" element of an SDPng description is OPTIONAL.
1097 4.6 Session Information
1099 The Session Information section is represented by an "info" element
1100 and is intended for meta information on the conference itself and on
1101 the individual components. In an SDPng description document, the
1102 "info" element MAY provide one or multiple "part" element, each of
1103 which may contain arbitrary meta-description content.
1105 The "info" element is OPTIONAL in an SDPng description document.
1107 Each "part" element inside an "info" element MUST provide a "type"
1108 attribute that specifies the type of the meta-information content,
1109 e.g., "MPEG-7", "TV-Anytime", "MPEG-21", "SDP".
1111 Each "part" element inside an "info" element MAY provide a "ref"
1112 attribute that can be used to specify an URI for the meta-information
1113 content. If a "ref" attribute is provided the "part" element MUST be
1114 empty.
1116
1117
1120
1121 [...]
1122 [...]
1123
1124
1125
1126 ::1
1127 9456
1128 1
1129
1130
1132
1133
1134
1135
1136
1137
1138
1140
1141
1142 [...]
1143
1144
1145
1146 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
1147 s=SDP Seminar
1148 i=A Seminar on the session description protocol
1149 u=http://www.example.com/seminars/sdp.pdf
1150 e=j.doe@example.com (Jane Doe)
1151 t=2873397496 2873404696
1152
1153
1155
1157 4.7 Summary of SDPng XML-Syntax
1159 The SDPng base specification defines the following XML element types
1160 that reside in the SDPng namespace designated by the namespace name
1161 "http://www.iana.org/sdpng":
1163 o sdpng
1165 o cap
1167 o def
1169 o cfg
1170 o component
1172 o alt
1174 o constraints
1176 o info
1178 Appendix A.1 provides an XML DTD that specifies the content model of
1179 the SDPng base elements.
1181 5. Usage of SDPng in Different Application Scenarios
1183 This informative section describes how SDPng can be used in different
1184 application scenarios, namely broadcast/announcement,
1185 real-time-streaming, two-way-session-setup, and multiparty
1186 conferencing with negotiation.
1188 5.1 Broadcast/Announcement Scenarios
1190 Broadcast and multicast application scenarios rely on session
1191 announcements to communicate information about multimedia sessions
1192 and their associated parameters. Historically, in the Mbone, the
1193 Session Announcement Protocol (SAP) [RF2974] was used to convey
1194 static session descriptions via multicast but the same information
1195 could also be advertized by means of email, NetNews, or web pages.
1196 For some years, digital television used Electronic Program Guides
1197 (EPGs) to convey programming information (movie schedule, metadata,
1198 channel information) to large audiences. More recently, streaming
1199 services for (3G and beyond) mobile networks make use of similar
1200 concepts to announce streaming services. As a response to these
1201 needs, the generalized framework of Internet Media Guides (IMGs) has
1202 been devised to address conveying scheduling and media information to
1203 potentially large receiver groups. This subsection addresses the use
1204 of SDPng with SAP and IMG-based session announcements.
1206 SAP and IMGs are used to disseminate a previously created (and
1207 typically fixed) session description to a potentially large audience.
1208 An interested member of the audience will use the SDPng description
1209 communicated via SAP or IMGs to join the announced media sessions.
1210 While this is supported by MIME types identifying SDPng contents with
1211 implied semantics, the IMG framework explicitly suggests interactive
1212 retrieval using HTTP. Furthermore, IMG has the concept of
1213 asynchronous notifications/updates to existing SDPng descriptions: it
1214 makes use of a (SIP-based) notification mechanism that allows
1215 interested parties to monitor the state of session descriptions and
1216 receive asynchronous updates whenever the description changes.
1218 SAP makes extensive use of the SDP session level attributes to
1219 provide a (limited) set of descriptive metadata for the session,
1220 including scheduling and subject information. Quite a bit of this
1221 information is application-specific and is therefore not defined in
1222 the baseline SDPng spec. In particular, IMGs are expected to be used
1223 with more encompassing metadata description formats (such as MPEG-7)
1224 which will carry the respective information so that these need not be
1225 replicated in SDPng itself.
1227 While SAP only supports full SDP descriptions (which are minimal in
1228 size), IMGs allows in addition to the (potentially large)
1229 (collections of) SDPng descriptions and associated metadata to carry
1230 delta information or pointers to contents (URIs). The structured
1231 format of the XML-based SDP goes well with both concepts and allows
1232 to identify subparts of SDPng messages where and perform operations
1233 on them via well-defined means.
1235 5.2 Real-Time-Streaming
1237 Real-time streaming provides an interactive way to offer real-time
1238 media to users. In contrast to the announcement/broadcast based
1239 described in the previous section, where the communication is mostly
1240 unidirectional and interested receivers just "tune" into the
1241 respective media session, with RTSP an interactive session setup
1242 exists. This also informs the media server that there are parties
1243 interested in a particular media stream and provides the opportunity
1244 to the client to obtain the most appropriate variant of a media
1245 stream.
1247 Similar to SAP and IMGs, RTSP has, from its intended usage, a clear
1248 distinction between offering a set of Potential Configurations (by
1249 the server) and choosing one out of these (by the client). There is
1250 no capability negotiation process involved: the server provides a
1251 complete SDPng document describing all Components making up a
1252 presentation and includes detailed codec and transport parameters for
1253 each of there. The client may only pick one out of alternatives for
1254 each of the offered Components but has no further option to negotiate
1255 parameters in depth. Where some additional exchange is necesary --
1256 e.g. for the client's transport addresses and security parameters --,
1257 the respective parameters are no encoded in SDPng; instead,
1258 additional RTSP header fields and parameters are field for this
1259 purpose.
1261 Hence, SDPng is only used to describe alternatives to gain access to
1262 streaming media out of which the client has to choose. No
1263 interaction takes place at the SDPng level.
1265 It should be noted that SAP or IMG-based announcements may also be
1266 used to point users to RTSP servers. In such a case, the
1267 "negotiation" is a two-stage process: the media discovery takes place
1268 using SAP or IMG and leads to the RTSP server. The actual streaming
1269 invocation process then takes place interactively between the RTSP
1270 client and server as described in this section.
1272 C->M: DESCRIBE rtsp://foo/audio-play RTSP/1.0
1273 CSeq: 1
1275 M->C: RTSP/1.0 200 OK
1276 CSeq: 1
1277 Content-Type: application/sdp
1278 Content-Length: ...
1280
1291
1292
1293 PCMU
1294 1
1295 8000
1296
1297
1298 GSM
1299 1
1300 8000
1301
1302
1303
1304
1305 192.168.47.11
1306 51400
1307
1308
1309
1310
1311
1312
1313
1314 0
1315
1316
1317
1318
1319
1320 3
1321
1322
1323
1324
1325
1327 C->M: SETUP rtsp://foo/audio-play RTSP/1.0
1328 CSeq: 2
1329 Transport: RTP/AVP;unicast;client_port=8000-8001
1331 M->C: RTSP/1.0 200 OK
1332 CSeq: 2
1333 Transport: RTP/AVP;unicast;client_port=8000-8001;
1334 server_port=51400-51401
1335 Session: 12345678
1337 To be continued with PLAY and, after the audio track has completed,
1338 finished with TEARDOWN.
1340 5.3 Two-Way Session Setup
1342 The major application of SDP today is its use with the Session
1343 Initiation Protocol (SIP) [RFC3261]. Session descriptions are used
1344 configure the media streams between two parties involved in a
1345 multimedia call.
1347 SIP is used to establish and modify multimedia sessions, and SDPng
1348 may be carried at least in SIP INVITE, ACK and UPDATE messages as
1349 well as in a number of responses. From dealing with legacy SDP (and
1350 its essential non-suitability for capability negotiation), a
1351 particular use and interpretation of SDP has been defined for SIP,
1352 generalized in the offer/answer model documented in RFC 3264.
1354 One of the important flexibilities introduced by SIP's usage of SDP
1355 is that a sender can change dynamically between all codecs that a
1356 receiver has indicated support (and has provided an address) for.
1357 Codec changes are not signaled out-of-band but only indicated by the
1358 payload type within the media stream. From this arises one important
1359 consequence to the conceptual view of a Component within SDPng.
1361 There is no clear distinction between Potential and Actual
1362 Configurations. There need not be a single Actual Configuration
1363 chosen at setup time within the SIP signaling. Instead, a number of
1364 Potential Configurations is signaled in SIP (with all transport
1365 parameters required for carrying media streams) and the Actual
1366 Configuration is only identified by the payload type which is
1367 actually being transmitted at any point in time.
1369 Note that since SDPng does not distinguish between Potential and
1370 Actual Configurations at the syntax, this has no implications on the
1371 SDPng signaling itself but is merely up to interpretation.
1373 SIP relies on an "offer/answer" model for the exchange of capability
1374 and configuration information. Either the caller or the callee sends
1375 an initial session description that is processed by the other side
1376 and returned. For capability negotiation, this means that the
1377 negotiation follows a two-stage-process: The "offerer" sends its
1378 capability description to the receiver. The receiver processes the
1379 offerers capabilities and his own capabilities and generates a result
1380 capability description that is sent back to the offerer. Both sides
1381 now know the commonly supported configurations and can initiate the
1382 media sessions.
1384 Because of this strict "offer/answer" model, the offerer must already
1385 send complete configurations (i.e. include transport addresses) along
1386 with the capability descriptions. The answer must also contain
1387 complete configuration parameters. The following figure shows, how
1388 SDPng content can be used in an INVITE request with a corresponding
1389 200 OK message.
1391 Simple description document with only one alternative:
1393 F1 INVITE A -> B
1395 INVITE sip:B@example.com SIP/2.0
1396 Via: SIP/2.0/UDP hostA.example.com:5060
1397 From: A
1398 To: B
1399 Call-ID: 1234@hostA.example.com
1400 CSeq: 1 INVITE
1401 Contact:
1402 Content-Type: application/sdpng
1403 Content-Length: 685
1405
1407
1418
1419
1420 PCMU
1421 1
1422 8000
1423
1424
1425 GSM
1426 1
1427 8000
1428
1429
1430
1431
1432 192.168.47.11
1433 51400
1434
1435
1436
1437
1438
1439
1440
1441 0
1442
1443
1444
1445
1446
1447 3
1448
1449
1450
1451
1452
1454 ==================================================
1456 F2 (100 Trying) B -> A
1458 SIP/2.0 100 Trying
1459 Via: SIP/2.0/UDP hostA.example.com:5060
1460 From: A
1461 To: B
1462 Call-ID: 1234@hostA.example.com
1463 CSeq: 1 INVITE
1464 Content-Length: 0
1466 ==================================================
1467 F3 180 Ringing B -> A
1469 SIP/2.0 180 Ringing
1470 Via: SIP/2.0/UDP hostA.example.com:5060
1471 From: A
1472 To: B ;tag=987654
1473 Call-ID: 1234@hostA.example.com
1474 CSeq: 1 INVITE
1475 Content-Length: 0
1477 ==================================================
1479 F4 200 OK B -> A
1481 SIP/2.0 200 OK
1482 Via: SIP/2.0/UDP hostA.example.com:5060
1483 From: A
1484 To: B ;tag=987654
1485 Call-ID: 1234@hostA.example.com
1486 CSeq: 1 INVITE
1487 Contact:
1488 Content-Type: application/sdpng
1489 Content-Length: 479
1491
1493
1504
1505
1506 PCMU
1507 1
1508 8000
1509
1510
1511 GSM
1512 1
1513 8000
1514
1516
1517
1518
1519 192.168.47.12
1520 60006
1521
1522
1523
1524
1525
1526
1527
1528 3
1529
1530
1531
1532
1533
1535 ==================================================
1537 ACK from A to B omitted
1539 In the INVITE message, A sends B a description document that
1540 specifies exactly one component with two alternatives (the PCMU and
1541 GSM audio streams). The alternatives make reference to the
1542 capability section where the two codec types are defined. All
1543 required transport parameters are already contained in the respective
1544 descriptions but they are kept separate from the capability part.
1545 The element contains a definition for the RTP media sessions so
1546 that this needs not be repeated in the configuration of the single
1547 component. Note that the semantics of the component is not
1548 explicitly specified (in an element) but rather implied.
1550 In the 200 OK message, B sends an updated description document to A.
1551 B supports the payload format that A has offered and adds his own
1552 transport parameters to the configuration information, specifying the
1553 endpoint address where B wants to receive media data. In order to
1554 disambiguate its transport configurations from A's, B sets the
1555 attribute "endpoint" to the value "B". The specific value of the
1556 "endpoint" attribute is not important, the only requirements are that
1557 a party that contributes to the session description, must use a
1558 unique name for the endpoint attribute and that a contributing party
1559 must use the same value for the endpoint attributes of all elements
1560 it adds to the session description.
1562 The offer/answer model allows communicating peers to determine a
1563 (common) mode of operation to exchange media streams in a single
1564 round-trip. Basically, the offerer proposes a set of components,
1565 providing one or more alternatives ("potential configurations") for
1566 each of these. From this offer, the answerer learns which components
1567 may be used and which configurations are applicable to realize these
1568 components. The answerer indicates which components it supports
1569 (e.g. receiving a offer including audio and video, it may disallow
1570 the video session and go with an audio-only conversation) and also
1571 provides possible configurations to implement those components.
1572 Along with the media types and codec parameters, offerer and answerer
1573 specify which transport addresses to use and, in case of RTP, which
1574 payload types they want to use for sending. Offerer and answerer
1575 agree on a common set of media streams ("components") and on a
1576 possible set of codecs for each of these ("configurations") as well
1577 as the transport addresses and other parameters to be used. However,
1578 they do not fix a certain configuration (unless only a single one is
1579 exchanged in each direction). Instead, for each selected media
1580 stream, either peer may choose and dynamically switch to any of the
1581 configurations indicated by the other side in the respective offer or
1582 answer.
1584 For using SDPng with the offer/answer model (RFC 3264), the basic
1585 defined in RFC 3264 for generating offers and answers apply. The
1586 following considerations specifically apply when using offer/answer
1587 with SDPng (instead of SDP) documents:
1589 o For each component to be used, all necessary parameters MUST be
1590 given for at least one configuration per component, i.e. transport
1591 addresses and payload formats MUST be specified along with the
1592 capabilities.
1594 o Matching of components is done based upon their identification in
1595 the info part of the SDPng document using predefined identifiers
1596 for certain session types.
1597 For simple sessions, where applications can implicitly derive the
1598 semantics of the the offered components, no such explicit mapping
1599 is necessary. In this case, i.e. if the entire "" element
1600 or the respective elements in the "" element are absent, the
1601 order of appearance in the SDPng document is relevant as it is
1602 with SDP.
1604 o For each component, the answerer performs a capability matching
1605 process as per then application's requirements
1606 For all components that are acceptable, the answerer determines
1607 whether or not to accept the offer.
1608 If the answerer decides to accept the offer for a certain
1609 component, it MUST accept at least one of the potential
1610 configurations for the respective component. It SHOULD indicate
1611 this by setting the "status" attribute of the component and of the
1612 selected configuration(s) to "active" (but it MAY also omit the
1613 status attribute in both cases).
1614 It is RECOMMENDED that the answerer selects exactly one
1615 configuration for each component as "active".
1617 o The answerer MAY refuse individual configurations for a component
1618 from the offer in two ways.
1619 If the configuration shall not be used at all during a session,
1620 e.g. because the answerer does not support it or because the
1621 answere does not want to use this configuration at all, the
1622 answerer MUST set the "status" attribute of the respective
1623 component to "unused". In this case, the answerer MAY omit all
1624 the elements contained in the respective configuration's elements.
1625 This is equivalent to setting the port parameter to "0" in SDP.
1626 If a configuration shall be accepted (i.e. the respective
1627 capability shall be indicated) but no media session shall be
1628 instantiated (not even on hold!), the answerer MUST set the
1629 "status" attribute of the respective configuration to "available"
1630 and omit all media-session-specific parameters the configuration.
1632 o The answerer MAY refuse entire components that the offerer has
1633 included in two ways.
1634 If a component shall not be used at all during a session -- e.g.
1635 because the answerer does not support any of the configurations
1636 listed or because the answere does not want to use this component
1637 at all -- the answerer MUST set the "status" attribute of the
1638 respective component's to "unused". In this case, the answerer
1639 MAY omit all the elements contained in the respective component
1640 elements. This is equivalent to setting the port parameter to "0"
1641 in SDP.
1642 If a component shall be accepted (i.e. the respective capability
1643 shall be indicated) but no media session shall be instantiated
1644 (not even on hold!), the answerer MUST set the "status" attribute
1645 of the respective component to "available", omit all
1646 media-session-specific parameters from all acceptable
1647 configurations for the respective component.
1649 o For each component, the alternative potential configurations MUST
1650 be listed in the order of preference.
1651 Within a configuration, alternatives (e.g. different codecs) MUST
1652 also be listed in the order of preference.
1653 The considerations of RFC 3264 to simply arriving at symmetric
1654 codec use apply.
1656 If a component shall be put on hold, the status attribute of the
1657 component MUST be set to "sendonly", "recvonly", or "inactive", as
1658 appropriate. In this case, the status attributes of all the
1659 contained configurations that were previously active MUST be set to
1660 indicate "sendonly", "recvonly", or "inactive", as appropriate. The
1661 rules from RFC 3264 for putting media streams on hold SHALL apply.
1663 5.4 Multi-Party-Conferencing with Negotiation
1665 The indipendent capability collapsing properties of SDPng allow to
1666 calculate the "intersection" of any number of SDPng documents
1667 independently and easily derive a common subset. Details are TBD in a
1668 separate document.
1670 6. IANA Considerations
1672 The IANA should set up a registry for XML namespaces for SDPng and
1673 SDPng package definitions.
1675 The SDP parameter registry (http://www.iana.org/assignments/
1676 sdp-parameters) should be converted to SDPng package definitions.
1678 7. Open Issues
1680 Meta-Information for SDPng description (author, version etc.)?
1682 Revise usage of terminology (potential configuration, actual
1683 configuration)
1685 Do we need an explicit mechanism to declare the used packages?
1686 E.g.,
1688 Data model for audio package: sampling-rate vs. RTP clock rate
1690 Bib. references: distinguish normative and informational
1692 A registry (reuse of SDP mechanisms and names etc.) needs to be
1693 set up (IANA considerations).
1695 8. Acknowledgements
1697 The authors would like to thank Teodora Guenkova, Goran Petrovic and
1698 Markus Nosse for their feedback and detailed comments.
1700 References
1702 [1] Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements
1703 for Session Description and Capability Negotiation", Internet
1704 Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001.
1706 [2] Handley, M. and V. Jacobsen, "SDP: Session Description
1707 Protocol", RFC 2327, April 1998.
1709 [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
1710 "RTP: A Transport Protocol for Real-Time Applications", RFC
1711 3550, July 2003.
1713 [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
1714 Conferences with Minimal Control", RFC 3551, July 2003.
1716 [5] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
1717 M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP
1718 Payload for Redundant Audio Data", RFC 2198, September 1997.
1720 [6] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
1721 Generic Forward Error Correction", RFC 2733, December 1999.
1723 [7] Perkins, C. and O. Hodson, "Options for Repair of Streaming
1724 Media", RFC 2354, June 1998.
1726 [8] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
1727 Protocol", RFC 2974, October 2000.
1729 [9] World Wide Web Consortium (W3C), "Extensible Markup Language
1730 (XML) 1.0 (Second Edition)", Status W3C Recommendation, Version
1731 http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.
1733 [10] World Wide Web Consortium (W3C), "Namespaces in XML", Status
1734 W3C Recommendation, Version http://www.w3.org/TR/1999/
1735 REC-xml-names-19990114, January 1999.
1737 [11] World Wide Web Consortium (W3C), "XML Schema Part 1:
1738 Structures", Version http://www.w3.org/TR/2001/
1739 REC-xmlschema-1-20010502/, Status W3C Recommendation, May 2001.
1741 [12] World Wide Web Consortium (W3C), "XML Schema Part 2:
1742 Datatypes", Version http://www.w3.org/TR/2001/
1743 REC-xmlschema-2-20010502/, Status W3C Recommendation, May 2001.
1745 [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
1746 SDP", RFC 3264, June 2002.
1748 [14] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the
1749 Use of Extensible Markup Language (XML) within IETF Protocols",
1750 BCP 70, RFC 3470, January 2003.
1752 [15] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
1753 2533, March 1999.
1755 [16] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
1756 2279, January 1998.
1758 [17] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
1759 Registration Procedure", BCP 31, RFC 2506, March 1999.
1761 Authors' Addresses
1763 Dirk Kutscher
1764 TZI, Universitaet Bremen
1765 Bibliothekstr. 1
1766 Bremen 28359
1767 Germany
1769 Phone: +49.421.218-7595, sip:dku@tzi.org
1770 Fax: +49.421.218-7000
1771 EMail: dku@tzi.uni-bremen.de
1773 Joerg Ott
1774 TZI, Universitaet Bremen
1775 Bibliothekstr. 1
1776 Bremen 28359
1777 Germany
1779 Phone: +49.421.201-7028, sip:jo@tzi.org
1780 Fax: +49.421.218-7000
1781 EMail: jo@tzi.uni-bremen.de
1783 Carsten Bormann
1784 TZI, Universitaet Bremen
1785 Bibliothekstr. 1
1786 Bremen 28359
1787 Germany
1789 Phone: +49.421.218-7024, sip:cabo@tzi.org
1790 Fax: +49.421.218-7000
1791 EMail: cabo@tzi.org
1793 Appendix A. Formal Syntax Specifications
1795 A.1 SDPng Base DTD
1797 The following DTD specifies the SDPng base syntax. DTDs are not
1798 XML-Namespace aware, therefore the following DTD is for informational
1799 purposes only. Moreover, the content models for the element types
1800 "cap" and "def" have to be empty in this DTD as the specific element
1801 types for the allowed child elements are not defined by the base
1802 specification but by independent package definitions. Common
1803 requirements for these element types such as the "name" attribute
1804 cannot be expressed with XML DTDs.
1806
1808
1810
1812
1814
1815
1821
1822
1827
1829
1831
1832
1837 A.2 SDPng XML-Schema Specification
1839
1847
1855
1856
1857
1858
1859
1860
1862
1864
1865
1866
1867
1869
1874
1875
1876
1877
1878
1879
1880
1882
1887
1888
1889
1890
1891
1892
1893
1895
1900
1901
1902
1903
1904
1905
1906
1908
1913
1914
1915
1916
1917
1918
1919
1921
1926
1927
1928
1929
1931
1936
1937
1938
1939
1941
1946
1947
1948
1949
1950
1952
1957
1958
1959
1960
1961
1963
1965
1966
1967
1969
1970
1972
1973
1975
1977
1978
1979
1980
1982
1984
1985
1987
1989
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2005
2006
2008
2009
2011
2013
2014
2015
2016
2017
2018
2019
2021
2023
2024
2025
2026
2027
2028
2029
2031
2033
2034
2035
2036
2037
2038
2039
2041
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2054
2055
2056
2057
2058
2059
2060
2061
2062
2064
2066
2067
2068
2069
2070
2071
2072
2074
2076
2077
2078
2079
2080
2081
2082
2084
2086 Appendix B. Sample Package Definitions
2088 B.1 Sample RTP Package Definition
2090
2098
2100
2101
2102
2103
2104
2105
2106
2107
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2123
2125
2127 B.2 Sample Audio Package Definition
2129
2137
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2151
2153
2155 B.3 Sample Video Package Definition
2157
2165
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2184
2186
2188 Appendix C. Sample SDPng Description
2190
2192
2203
2204
2205 PCMU
2206 1
2207 8000
2208
2209
2210 GSM
2211 1
2212 8000
2213
2214
2215 G723
2216 1
2217 8000
2218
2219
2220 DVI4
2221 1
2222 8000 11025 16000 22050
2223
2224
2225 LPC
2226 1
2227 8000
2228
2229
2230 G722
2231 1
2232 8000
2233
2234
2235 L16
2236 1 2
2237 44100
2238
2239
2240 QCELP
2241 1
2242 8000
2243
2244
2245 CN
2246 1
2247 8000
2248
2249
2250 MPA
2251 1
2252 32000 44100 48000
2253
2254
2255 G728
2256 1
2257 8000
2258
2259
2260 G728
2261 1
2262 8000
2263
2264
2265 G726-40
2266 1
2267 8000
2268
2269
2270 G726-32
2271 1
2272 8000
2273
2274
2275 G726-24
2276 1
2277 8000
2278
2279
2280 G726-16
2281 1
2282 8000
2283
2284
2285 G729D
2286 1
2287 8000
2288
2289
2290 G729E
2291 1
2292 8000
2293
2294
2295 GSM-EFR
2296 1
2297 8000
2298
2299
2300 L8
2301 1 2
2302 8000 16000
2303
2304
2305 RED
2306 1 2
2307 8000 16000
2308
2309
2310 RED
2311 1
2312 var
2313
2315
2316 CelB
2317 4 6 8 12 16 20 24 30
2318
2320
2321 IP6
2322
2324
2325
2326
2327 ::1
2328 9546
2329
2330
2331
2332
2333
2334
2335
2336 0
2337
2338
2339
2340
2341
2343 Appendix D. Change History
2345 draft-ietf-mmusic-sdpng-08.txt
2347 * Changed introduction: emphasis on non-negotiation scenarios
2348 (broadcast etc.), describe main concepts
2350 * element "cap" is now OPTIONAL.
2352 * new "status" attribute for "component" element type
2354 * new "part" element for "info" element (meta-information)
2356 * Removed section "Specification of the Capability Negotiation"
2358 * Removed appendix "Use of SDPng in Conjunction with other IETF
2359 Signaling Protocols"
2361 * Added section "Usage of SDPng in Different Application
2362 Scenarios"
2364 * Updated DTD and XML-Schema-Definition wrt to afore-mentioned
2365 changes
2367 draft-ietf-mmusic-sdpng-07.txt
2369 * New document structure:
2371 1. Intro
2373 2. Terminology and System Model
2375 3. Overview
2377 4. SDPng Syntax Specification
2379 5. Negotiation Process
2381 * Changes to Section 3: Describe all concepts
2383 * Section 4 provides complete specification
2385 * Changed XML syntax: Represent tokens and token list as element
2386 content (not attributes)
2388 * a new element "def" for reusable definitions
2390 * Adapted secion 5 accordingly
2391 * Sample DTD, schema definition and same SDPng document in
2392 appendix
2394 * Updated section 5.1 (Offer/Answer)
2396 * Updated appendix D (Use of SDPng in conjunction with other IETF
2397 Signaling Protocols)
2399 draft-ietf-mmusic-sdpng-06.txt
2401 * Removed section on capability negotiation algorithm and section
2402 on formal specification. Added Section 3.
2404 * Removed specification of concrete XML syntax from Section 4.
2405 Added requirements and theoretic considerations.
2407 * Added clarification of term "actual configuration" in Section
2408 2.
2410 * Changed "profile" to "package".
2412 * Added a list of terms with explanation at the end of Section 2.
2414 * Removed audio and RTP packages from appendix.
2416 * Added a section "Syntax Definition".
2418 * Added section "Specification of the Capability Negotiation".
2420 draft-ietf-mmusic-sdpng-05.txt
2422 * Moved audio and RTP packages to appendix.
2424 * Moved section "Use of SDPng in conjunction with other IETF
2425 Signaling Protocols" to appendix.
2427 * Changed mechanism for references to definitions: Definition
2428 elements provide an attribute "ref" that can be used to
2429 referenced existing definitions. Removed other mechanisms for
2430 referencing (attributes "format" and "transport", element type
2431 "use").
2433 * Corrections to schema definitions and examples
2435 draft-ietf-mmusic-sdpng-04.txt
2437 * New section on capability negotiation.
2439 * New section on referencing definitions.
2441 * New section on properties.
2443 * New section on definition groups.
2445 draft-ietf-mmusic-sdpng-03.txt
2447 * Extension of the SDPng schema (use of Xlinks etc.)
2449 * Clarification in the text
2451 * Fixed examples
2453 * Added example libraries as appendices
2455 * More details on usage with SIP, including examples.
2457 draft-ietf-mmusic-sdpng-02.txt
2459 * Added a section on formal specification mechanisms.
2461 draft-ietf-mmusic-sdpng-01.txt
2463 * renamed section "Syntax Proposal" to "Syntax Definition
2464 Mechanisms". More text on DTD vs. schema. Edited the example
2465 description.
2467 * updated example definitions in section "Definitions" and
2468 "Components & Configurations"
2470 * section "Session Attributes" replaces section "Session"
2472 * new appendix on audio codec definitions
2474 IPR Notice
2476 The IETF takes no position regarding the validity or scope of any
2477 Intellectual Property Rights or other rights that might be claimed to
2478 pertain to the implementation or use of the technology described in
2479 this document or the extent to which any license under such rights
2480 might or might not be available; nor does it represent that it has
2481 made any independent effort to identify any such rights. Information
2482 on the procedures with respect to rights in RFC documents can be
2483 found in BCP 78 and BCP 79.
2485 Copies of IPR disclosures made to the IETF Secretariat and any
2486 assurances of licenses to be made available, or the result of an
2487 attempt made to obtain a general license or permission for the use of
2488 such proprietary rights by implementers or users of this
2489 specification can be obtained from the IETF on-line IPR repository at
2490 http://www.ietf.org/ipr.
2492 The IETF invites any interested party to bring to its attention any
2493 copyrights, patents or patent applications, or other proprietary
2494 rights that may cover technology that may be required to implement
2495 this standard. Please address the information to the IETF at ietf-
2496 ipr@ietf.org.
2498 Full Copyright Statement
2500 Copyright (C) The Internet Society (2005). This document is subject
2501 to the rights, licenses and restrictions contained in BCP 78, and
2502 except as set forth therein, the authors retain all their rights.
2504 This document and the information contained herein are provided on
2505 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
2506 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
2507 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
2508 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
2509 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
2510 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
2511 PARTICULAR PURPOSE.
2513 Acknowledgment
2515 Funding for the RFC Editor function is currently provided by the
2516 Internet Society.