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.