Network Working Group Kutscher Internet-Draft Ott Expires: December 30, 2002 Bormann TZI, Universitaet Bremen July 01, 2002 Session Description and Capability Negotiation draft-ietf-mmusic-sdpng-05.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 30, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines a language for describing multimedia sessions with respect to configuration parameters and capabilities of end- systems. This document is a product of the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at mmusic@ietf.org and/or the authors. Document Revision Kutscher, et al. Expires December 30, 2002 [Page 1] Internet-Draft SDPng July 2002 $Revision: 4.12 $ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology and System Model . . . . . . . . . . . . . . . 6 3. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . 9 3.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2 Components & Configurations . . . . . . . . . . . . . . . 11 3.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.4 Session Attributes . . . . . . . . . . . . . . . . . . . . 14 3.1.4.1 Owner . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.4.2 Session Identification . . . . . . . . . . . . . . . . . . 15 3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) . . . 16 3.1.4.4 Component Semantic Specification . . . . . . . . . . . . . 17 3.2 Syntax Definition Mechanisms . . . . . . . . . . . . . . . 17 3.3 Referencing Definitions . . . . . . . . . . . . . . . . . 20 3.3.1 The attribute "ref" . . . . . . . . . . . . . . . . . . . 21 3.4 External Definition Packages . . . . . . . . . . . . . . . 22 3.4.1 Profile Definitions . . . . . . . . . . . . . . . . . . . 22 3.4.2 Library Definitions . . . . . . . . . . . . . . . . . . . 23 3.5 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 24 4. Capability Negotiation . . . . . . . . . . . . . . . . . . 26 4.1 Outline of the Negotiation Process . . . . . . . . . . . . 26 4.2 The Collapsing Algorithm . . . . . . . . . . . . . . . . . 28 4.2.1 Collapsing Two Configurations . . . . . . . . . . . . . . 29 4.2.1.1 Collapsing of Attributes . . . . . . . . . . . . . . . . . 29 4.2.1.2 Collapsing two Elements . . . . . . . . . . . . . . . . . 32 4.2.1.3 Collapsing nested Elements . . . . . . . . . . . . . . . . 33 4.2.2 Deriving an actual Configuration . . . . . . . . . . . . . 35 5. Formal Specification . . . . . . . . . . . . . . . . . . . 36 5.1 XML Schema as a Definition Mechanism . . . . . . . . . . . 36 5.2 SDPng Schema . . . . . . . . . . . . . . . . . . . . . . . 37 5.3 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.4 SDPng Documents . . . . . . . . . . . . . . . . . . . . . 39 5.5 Libraries . . . . . . . . . . . . . . . . . . . . . . . . 40 5.6 Details on the use of specific XML Mechanisms . . . . . . 41 5.6.1 Default Namespace . . . . . . . . . . . . . . . . . . . . 41 5.6.2 Qualified Locals . . . . . . . . . . . . . . . . . . . . . 41 5.6.3 Fixed Namespace Prefixes . . . . . . . . . . . . . . . . . 42 5.7 SDPng Schema Definitions . . . . . . . . . . . . . . . . . 42 5.7.1 SDPng Base Definition . . . . . . . . . . . . . . . . . . 42 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 50 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 51 References . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53 A. SDPng Audio Codec Profile and Audio Codec Library . . . . 55 Kutscher, et al. Expires December 30, 2002 [Page 2] Internet-Draft SDPng July 2002 A.1 Audio Codec Profile . . . . . . . . . . . . . . . . . . . 55 A.2 SDPng Library for Audio Codec Definitions . . . . . . . . 57 A.2.1 DVI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 A.2.2 G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 58 A.2.3 G.726 . . . . . . . . . . . . . . . . . . . . . . . . . . 58 A.2.4 G.728 . . . . . . . . . . . . . . . . . . . . . . . . . . 58 A.2.5 G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.2.6 G.729 Annex D and E . . . . . . . . . . . . . . . . . . . 59 A.2.7 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.2.7.1 GSM Full Rate . . . . . . . . . . . . . . . . . . . . . . 59 A.2.7.2 GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . 60 A.2.7.3 GSM Enhanced Full Rate . . . . . . . . . . . . . . . . . . 60 A.2.8 L8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 A.2.9 L16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 A.2.10 LPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 A.2.11 MPA . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 A.2.12 PCMA and PCMU . . . . . . . . . . . . . . . . . . . . . . 61 A.2.13 QCELP . . . . . . . . . . . . . . . . . . . . . . . . . . 61 A.2.14 VDVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 B. SDPng Profile for RTP Profile and RTP Library . . . . . . 63 B.1 RTP profile . . . . . . . . . . . . . . . . . . . . . . . 63 B.2 SDPng Library for RTP Payload Format Definitions . . . . . 65 C. Use of SDPng in conjunction with other IETF Signaling Protocols . . . . . . . . . . . . . . . . . . . . . . . . 67 C.1 The Session Announcement Protocol (SAP) . . . . . . . . . 67 C.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . 68 C.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . 75 C.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . 75 D. Change History . . . . . . . . . . . . . . . . . . . . . . 76 Full Copyright Statement . . . . . . . . . . . . . . . . . 78 Kutscher, et al. Expires December 30, 2002 [Page 3] Internet-Draft SDPng July 2002 1. Introduction Multiparty multimedia conferencing is one of the applications that require dynamic interchange of end-system capabilities and the negotiation of a parameter set that is appropriate for all sending and receiving end-systems in a conference. For some applications, e.g. for loosely coupled conferences or for broadcast scenarios, it may be sufficient to simply have session parameters be fixed by the initiator of a conference. In such a scenario no negotiation is required because only those participants with media tools that support the predefined settings can join a media session and/or a conference. This approach is applicable for conferences that are announced some time ahead of the actual start date of the conference. Potential participants can check the availability of media tools in advance and tools such as session directories can configure media tools upon startup. This procedure however fails to work for conferences initiated spontaneously including Internet phone calls or ad-hoc multiparty conferences. Fixed settings for parameters such as media types, their encoding etc. can easily inhibit the initiation of conferences, for example in situations where a caller insists on a fixed audio encoding that is not available at the callee's end- system. To allow for spontaneous conferences, the process of defining a conference's parameter set must therefore be performed either at conference start (for closed conferences) or maybe (potentially) even repeatedly every time a new participant joins an active conference. The latter approach may not be appropriate for every type of conference without applying certain policies: For conferences with TV-broadcast or lecture characteristics (one main active source) it is usually not desired to re-negotiate parameters every time a new participant with an exotic configuration joins because it may inconvenience existing participants or even exclude the main source from media sessions. But conferences with equal "rights" for participants that are open for new participants on the other hand would need a different model of dynamic capability negotiation, for example a telephone call that is extended to a 3-parties conference at some time during the session. SDP [2] allows to specify multimedia sessions (i.e. conferences, "session" as used here is not to be confused with "RTP session"!) by providing general information about the session as a whole and specifications for all the media streams (RTP sessions and others) to be used to exchange information within the multimedia session. Currently, media descriptions in SDP are used for two purposes: Kutscher, et al. Expires December 30, 2002 [Page 4] Internet-Draft SDPng July 2002 o to describe session parameters for announcements and invitations (the original purpose of SDP) and o to describe the capabilities of a system and possibly provide a choice between a number of alternatives (which SDP was not designed for). A distinction between these two "sets of semantics" is only made implicitly. This document is based upon a set of requirements specified in a companion document [1]. In the following, we first introduce a model for session description and capability negotiation as well as the basic terms used throughout this specification (section 2). Next, we outline the concept for the concepts underlying SDPng and introduce the syntactical components step by step in section 3. In section 4, we provide a formal definition of the SDPng session description language. Finally, we overview aspects of using SDPng with various IETF signaling protocols in section 5. In Appendix A, we provide basic audio codec and payload type definitions that are subsumed in SDPng libraries in Appendix A.2 and Appendix B.2. Kutscher, et al. Expires December 30, 2002 [Page 5] Internet-Draft SDPng July 2002 2. Terminology and System Model Any (computer) system has, at a time, a number of rather fixed hardware as well as software resources. These resources ultimately define the limitations on what can be captured, displayed, rendered, replayed, etc. with this particular device. We term features enabled and restricted by these resources "system capabilities". Example: System capabilities may include: a limitation of the screen resolution for true color by the graphics board; available audio hardware or software may offer only certain media encodings (e.g. G.711 and G.723.1 but not GSM); and CPU processing power and quality of implementation may constrain the possible video encoding algorithms. In multiparty multimedia conferences, participants employ different "components" in conducting the conference. Example: In lecture multicast conferences one component might be the voice transmission for the lecturer, another the transmission of video pictures showing the lecturer and the third the transmission of presentation material. Depending on system capabilities, user preferences and other technical and political constraints, different configurations can be chosen to accomplish the use of these components in a conference. Each component can be characterized at least by (a) its intended use (i.e. the function it shall provide) and (b) one or more possible ways to realize this function. Each way of realizing a particular function is referred to as a "configuration". Example: A conference component's intended use may be to make transparencies of a presentation visible to the audience on the Mbone. This can be achieved either by a video camera capturing the image and transmitting a video stream via some video tool or by loading a copy of the slides into a distributed electronic white-board. For each of these cases, additional parameters may exist, variations of which lead to additional configurations (see below). Two configurations are considered different regardless of whether they employ entirely different mechanisms and protocols (as in the previous example) or they choose the same and differ only in a single parameter. Example: In case of video transmission, a JPEG-based still image protocol may be used, H.261 encoded CIF images could be sent, as Kutscher, et al. Expires December 30, 2002 [Page 6] Internet-Draft SDPng July 2002 could H.261 encoded QCIF images. All three cases constitute different configurations. Of course there are many more detailed protocol parameters. Each component's configurations are limited by the participating system's capabilities. In addition, the intended use of a component may constrain the possible configurations further to a subset suitable for the particular component's purpose. Example: In a system for highly interactive audio communication the component responsible for audio may decide not to use the available G.723.1 audio codec to avoid the additional latency but only use G.711. This would be reflected in this component only showing configurations based upon G.711. Still, multiple configurations are possible, e.g. depending on the use of A-law or u-Law, packetization and redundancy parameters, etc. In modelling multimedia sessions, we distinguish two types of configurations: o potential configurations (a set of any number of configurations per component) indicating a system's functional capabilities as constrained by the intended use of the various components; o actual configurations (exactly one per instance of a component) reflecting the mode of operation of this component's particular instantiation. Example: The potential configuration of the aforementioned video component may indicate support for JPEG, H.261/CIF, and H.261/QCIF. A particular instantiation for a video conference may use the actual configuration of H.261/CIF for exchanging video streams. In summary, the key terms of this model are: o A multimedia session (streaming or conference) consists of one or more conference components for multimedia "interaction". o A component describes a particular type of interaction (e.g. audio conversation, slide presentation) that can be realized by means of different applications (possibly using different protocols). o A configuration is a set of parameters that are required to implement a certain variation (realization) of a certain component. There are actual and potential configurations. Kutscher, et al. Expires December 30, 2002 [Page 7] Internet-Draft SDPng July 2002 * Potential configurations describe possible configurations that are supported by an end-system. * An actual configuration is an "instantiation" of one of the potential configurations, i.e. a decision how to realize a certain component. In less abstract words, potential configurations describe what a system can do ("capabilities") and actual configurations describe how a system is configured to operate at a certain point in time (media stream spec). To decide on a certain actual configuration, a negotiation process needs to take place between the involved peers: 1. to determine which potential configuration(s) they have in common, and 2. to select one of this shared set of common potential configurations to be used for information exchange (e.g. based upon preferences, external constraints, etc.). In SAP-based [9] session announcements on the Mbone, for which SDP was originally developed, the negotiation procedure is non-existent. Instead, the announcement contains the media stream description sent out (i.e. the actual configurations) which implicitly describe what a receiver must understand to participate. In point-to-point scenarios, the negotiation procedure is typically carried out implicitly: each party informs the other about what it can receive and the respective sender chooses from this set a configuration that it can transmit. Capability negotiation must not only work for 2-party conferences but is also required for multi-party conferences. Especially for the latter case it is required that the process to determine the subset of allowable potential configurations is deterministic to reduce the number of required round trips before a session can be established. For instance, in order to be used with SIP, the capability negotiation is required to work with the offer/answer model that is for session initiation with SIP -- limiting the negotiation to exactly one round trip. The requirements for the SDPng specification, subdivided into general requirements and requirements for session descriptions, potential and actual configurations as well as negotiation rules, are captured in a companion document [1]. Kutscher, et al. Expires December 30, 2002 [Page 8] Internet-Draft SDPng July 2002 3. SDPng This section introduces the underlying concepts of the Session Description Protocol - next generation (SDPng). The focus of this section is on the concepts of the capability description and negotiation language with a stepwise introduction of the various syntactical elements. Note that this section only provides examples accompanied by explanations -- a complete formal specification is provided in section 4. 3.1 Conceptual Outline The concept of a capability description language addresses various pieces of a full description of system and application capabilities in four separate "sections": Definitions (elementary and compound); see Section 3.1.1. Potential or Actual Configurations; see Section 3.1.2. Constraints; see Section 3.1.3. Session attributes; see Section 3.1.4. 3.1.1 Definitions The "Definitions" section specifies a number of basic abstractions that are later referenced to avoid repetitions in more complex specifications and allow for a concise representation. Definition elements are labelled with an identifier by which they may be referenced. They may be elementary or compound (i.e. combinations of elementary entities). Examples of definitions that could occur in "Definitions" sections include (but are not limited to) codec definitions, redundancy schemes, transport mechanisms and payload formats. Elementary definition elements do not reference other elements. Each elementary entity only consists of one of more attributes and their values. Default values specified in the definition section may be overridden in descriptions for potential (and later actual) configurations. A mechanism for overriding definitions is specified below. For the moment, elementary abstractions are defined for media types (i.e. codecs) and for media transport mechanisms. For each transport and for each codec to be used, the respective attributes need to be defined. This definition may either be provided within Kutscher, et al. Expires December 30, 2002 [Page 9] Internet-Draft SDPng July 2002 the "Definitions" section itself or in an external document (similar to the audio-video profile or an IANA registry that defines payload types and media stream identifiers). It is not required to define all codecs and transport mechanisms in a "Definitions" sections and reference them when specifying potential and actual configurations. Instead, a syntactic mechanism is defined that allows to provide some definitions directly in a configurations section. Examples for elementary definitions: The element type "audio:codec" is used in these examples to define audio codec configurations. The configuration parameters are given as attribute values. Definitions may have default values specified along with them for each attribute (as well as for their contents). Some of these default values may be overridden so that a codec definition can easily be re-used in a different context (e.g. by specifying a different sampling rate) without the need for a large number of base specifications. In the following example the definition of audio- L16-mono is re-used for the defintion of the corresponding stereo codec. Appendix A provides a complete set of corresponding audio:codec definitions of the codecs used in RFC 1890 [4]. The example shows how existing definitions can be referenced in new definitions. This approach allows to create simple as well as more complex definitions in an extensible set of reference documents. The attribute "use" is defined in Section 3.3. Section 3.4 specifies the mechanisms for external references. Besides definitions of audio codecs, other definitions such as RTP payload formats and specific transport mechanisms are suitable to be defined in a definition section for later referencing. The following example shows how RTP payload types are defined using a pre-defined codec. Kutscher, et al. Expires December 30, 2002 [Page 10] Internet-Draft SDPng July 2002 In this example, the payload type "rtp-avp-11" is defined with payload type number 11, referencing the codec "audio-L16-mono". Instead of referencing an existing definition it is also possible to define the format "inline": The "Definitions" section may be empty if all transport, codecs, and other pieces needed to specify the Potential and Actual Configurations (as detailed below) are either included by referencing external definitions or are explicitly described within the Configurations themselves. 3.1.2 Components & Configurations The "Configurations" section contains all the components that constitute the multimedia application (IP telephone call, real-time streaming application, multi-player gaming session etc.). For each of these components, the potential and, later, the actual configurations are given. Potential configurations are used during capability exchange and/or negotiation, actual configurations to configure media streams after negotiation (e.g. with RTSP) or in session announcements (e.g. via SAP). A potential and the actual configuration of a component may be identical. Each component is labelled with an identifier so that it can be referenced, e.g. to associate semantics with a particular media stream. For such a component, any number of configurations may be given with each configuration describing an alternative way to realize the functionality of the respective component. Each configuration (potential as well as actual) is labelled with an identifier. A configuration combines one or more (elementary and/or compound) entities from the "Definitions" section to describe a potential or an actual configuration. Within the specification of the configuration, default values from the referenced entities may be overwritten. In addition, it is also possible to provide definition elements inline, inside the definition of a configuration. Kutscher, et al. Expires December 30, 2002 [Page 11] Internet-Draft SDPng July 2002 Note: Not all protocol environments and their respective operation allow to explicitly distinguish between Potential and Actual Configurations. Therefore, SDPng so far does not provide for syntactical identification of a Configuration as being a Potential or an Actual one. The semantics of configurations are to be determined from the requirements of the specific protocol that uses SDPng to express capabilities and configurations. The following example shows how RTP sessions can be described by referencing payload definitions: For example, an IP telephone call may require just a single component "name=interactive-audio" with two possible ways of implementing it. The two corresponding configurations are "AVP-audio-0" without modification, the other ("AVP-audio-11") uses linear 16-bit encoding. Typically, transport address parameters such as the port number would also be provided. In this example, this information is given by the "rtp:udp" element. Of course, it must be possible to specify other transport mechanisms as well. See Section 3.2 for a discussion of extension mechanisms that allow applications to use non-standard transport (or other) specifications. During/after the negotiation phase, an actual configuration is chosen out of a number of alternative potential configurations, the actual configuration may refer to the potential configuration just by its "id", possibly allowing for some parameter modifications. Alternatively, the full actual configuration may be given. Instead of referencing existing payload type definitions it is also possible to provide the required information directly in the rtp:pt Kutscher, et al. Expires December 30, 2002 [Page 12] Internet-Draft SDPng July 2002 element. The following example illustrates this: The UDP/IPv4 multicast transport that is used in the examples is a simple variant of a transport specification. More complex ones are conceivable. For example, it must also be possible to specify the usage of source filters (inclusion and exclusion), Source Specific Multicast, the usage of multi-unicast, or other parameters such as QoS parameters. Therefore it is possible to extend the definition of transport mechanisms by providing the required information in the element content. An example: Additional transport mechanisms and options will be defined in future SDPng profile definition, not in the base specification. 3.1.3 Constraints Definitions specify media, transport, and other capabilities, whereas configurations indicate which combinations of these could be used to provide the desired functionality in a certain setting. There may, however, be further constraints within a system (such as Kutscher, et al. Expires December 30, 2002 [Page 13] Internet-Draft SDPng July 2002 CPU cycles, DSP resources available, dedicated hardware, etc.) that limit which of these configurations can be instantiated in parallel (and how many instances of these may exist). We deliberately do not couple this aspect of system resource limitations to the various application semantics as the constraints may exist across application boundaries. Also, in many cases, expressing such constraints is simply not necessary (as many uses of the current SDP show), so additional overhead can be avoided where this is not needed. Therefore, we introduce a "Constraints" section to contain these additional limitations. Constraints refer to potential configurations and to entity definitions and express and use simple logic to express mutual exclusion, limit the number of instantiations, and allow only certain combinations. The following example shows the definition of a constraints that restricts the maximum number of instantiation of two alternatives (that would have to be defined in the configuration section before) when they are used in parallel: As the example shows, constraints are defined by defining limits on simultaneous instantiations of alternatives. They are not defined by expressing abstract end-system resources, such as CPU speed or memory size. By default, the "Constraints" section is empty (or missing) which means that no further restrictions apply. 3.1.4 Session Attributes The fourth and final section of the SDPng syntax is used to specify meta information such as session layer attributes. These attributes largely include those defined by SDP [RFC2327] (which are explicitly indicated in the following specification) to describe originator, purpose, and timing of a multimedia session among other characteristics. Furthermore, SDPng includes attributes indicating the semantics of the various Components in a teleconference or other session. A session-level specification for connection information (SDP "c=" line), bandwidth information (SDP "b=" line), and encryption keys (SDP "k=" lines) is deliberately not provided for in SDPng. The Kutscher, et al. Expires December 30, 2002 [Page 14] Internet-Draft SDPng July 2002 relevant information can be specified directly in the Configuration section for individual alternatives. 3.1.4.1 Owner The owner refers to the creator of a session as defined in RFC2327 ("o=" line). The syntax is as follows: The owner element must be present if SDPng is used with SAP. For all other protocols, the owner element is not necessarily required. The attributes listed above match those from the SDP specification; all attributes must be present and they are used following the rules of RFC2327. The owner element is an empty element. 3.1.4.2 Session Identification The "session" element is used to identify the session and to provide a description and possible further references. It provides the following attributes: name: The session name as it is to appear e.g. in a session directory. This is equivalent to the SDP "s=" line. The session element can contain arbitrary text of any length (but authors are encouraged to keep the inline description brief and provide additional information via URLs using the info element described below. This text is used to provide a description of the session; it is the equivalent of the SDP "i=" lines. Additionally, the session element can contain other elements of the following types to provide further information about the session and its creator: info: The info element is intended to provide a pointer to further information on the session itself. It is an empty element and provides the attribute xlink:href that is used to specify an URI. Info elements are optional, they may occur any number of times. contact: The contact element provides contact information on the creator of the session. It is an empty element and provides an attribute xlink:href that is used to specify an URI. Any URI scheme suitable to reach a person or a group of persons is acceptable (e.g. sip:, mailto:, tel:). Contact elements are Kutscher, et al. Expires December 30, 2002 [Page 15] Internet-Draft SDPng July 2002 optional, they may occur any number of times. And here comes a long description of the seminar indicating what this might be about and so forth. But we also include further information -- as additional elements: 3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) The time specification for a session follows the same rules as in SDP. Time specifications are usually only meaningful when used in conjunction with SAP and are optional. SDPng uses the following elements and attributes to specify timing: The element "time" is used to indicate a schedule for the session; time has two optional attributes: start: The starting time of the first occurrence of the session as defined in RFC2327. end: The ending time of the last occurrence of the session as defined in RFC2327. The time element can contain the following elements: repeat: This element specifies the repetition pattern for the schedule. There may be zero or more occurrences of this element within the time element. "repeat" has two mandatory and one optional attribute and is an empty element; the attributes are as defined in SDP: interval: The duration between two start times of the session. This attribute is always present. duration: The duration for which the session will be active starting at each repetition interval. This attribute is always present. offset: The offset relative to "start" attribute at which this Kutscher, et al. Expires December 30, 2002 [Page 16] Internet-Draft SDPng July 2002 repetition of the session is start. This attribute is optional; if it is absent, a default value of "0" is assumed. Formatting of the attribute values follows the rules defined in RFC2327. zone: The zone element specifies one or more time zone adjustments as defined in RFC2327. This element has zero or more occurrences in the time element. It is an empty element and has two attributes as defined in SDP: adjtime: The time at which the next adjustment will take place. delta: The adjustment offset (typically +/- 1 hours). The example from RFC2327, page 16, expressed in SDPng: The time element can occur multiple times. 3.1.4.4 Component Semantic Specification Another important session parameter is to specify - ideally in a machine-readable way but at least understandable for humans - the function of the various components in a session. Typically, the semantics of the streams are implicitly assumed (e.g. a video stream goes together with the only audio stream in a session). There are, however, scenarios in which such intuitive understanding is not sufficient and the semantics must be made explicit. Audio stream for the different speakers The above example shows a simple definition of the semantics for the component "audio-interactive". Further options may be added to provide additional information, e.g. language, and other functions may be specified (e.g. "panel", "audience", "chair", etc.). 3.2 Syntax Definition Mechanisms In order to allow for the possibility to validate session descriptions and in order to allow for structured extensibility, Kutscher, et al. Expires December 30, 2002 [Page 17] Internet-Draft SDPng July 2002 SDPng relies on a syntax framework that provides concepts as well as concrete procedures for document validation and extending the set of allowed syntax elements. SGML/XML technologies allow for the creation of Document Type Definitions (DTDs) that can define the allowed content models for the elements of conforming documents. Documents can be formally validated against a given DTD to check their conformance and correctness. XML DTDs however, cannot easily be extended. It is not possible to alter to content models of element types or to add new element types by third-party definition packages without creating the possibility of name collisions. For SDPng, a mechanism is needed that allows the specification of a base syntax -- for example basic elements for the high level structure of description documents -- while allowing extensions, for example elements and attributes for new transport mechanisms, new media types etc. to be added on demand. Still, it has to be ensured that extensions do not result in name collisions. Furthermore, it must be possible for applications that process descriptions documents to distinguish extensions from base definitions. For XML, mechanisms have been defined that allow for structured extensibility of document schemata: XML Namespace and XML Schema. XML Schema mechanisms allow to constrain the allowed document content, e.g. for documents that contain structured data and also provide the possibility that document instances can conform to several XML Schema definitions at the same time, while allowing Schema validators to check the conformance of these documents. Extensions of the session description language, say for allowing to express the parameters of a new media type, would require the creation of a corresponding XML schema definition that contains the specification of element types that can be used to describe configurations of components for the new media type. Session description documents have to reference the extension Schema module, thus enabling parsers and validators to identify the elements of the new extension module and to either ignore them (if they are not supported) or to consider them for processing the session/capability description. It is important to note that the functionality of validating capability and session description documents is not necessarily required to generate or process them. For example, endpoints would be configured to understand only those parts of description documents that are conforming to the baseline specification and simply ignore extensions they cannot support. The usage of XML and XML Schema is Kutscher, et al. Expires December 30, 2002 [Page 18] Internet-Draft SDPng July 2002 thus rather motivated by the need to allow for extensions being defined and added to the language in a structured way that does not preclude the possibility to have applications to identify and process the extensions elements they might support. The baseline specification of XML Schema definitions and profiles must be well- defined and targeted to the set of parameters that are relevant for the protocols and algorithms of the Internet Multimedia Conferencing Architecture, i.e. transport over RTP/UDP/IP, the audio video profile of RFC1890 etc. Section 3.4 describes profile definitions and library definition. A detailed definition of how the formal SDPng syntax and the corresponding extension mechanisms is provided in Section 5. The example below is a complete SDPng document. It shows how the definition of codecs, transport-variants and configuration of components as well as a conference description are realized in SDPng: Kutscher, et al. Expires December 30, 2002 [Page 19] Internet-Draft SDPng July 2002 This seminar is about SDPng... Audio stream for the different speakers Section 5 specifies the formal Schema definition that this example is conforming to. 3.3 Referencing Definitions This section specifies some generic mechanisms for referencing existing definitions. Referencing existing definitions allows to contruct definitions without having to include all parameters inline. By using these mechanisms, complex definitions can be derived by combining multiple basic mechanisms. Common parameters that occur in different configurations do not have to be repeated but can be defined once and then be referenced as often as they are needed. Kutscher, et al. Expires December 30, 2002 [Page 20] Internet-Draft SDPng July 2002 3.3.1 The attribute "ref" The attribute "ref" is a generic reference mechanism that is used in referencing elements to reference an existing element of the same element type. An example: In this example, an element of the type "rtp:udp" is specified in the definitions section of an SDPng document that is named "endpoint- addr-1" in its "name" attribute. The element is referenced in the definition of the alternative "alt-avp-audio-10", within the "rtp:session" element. The "rtp:session" provides an child element "rtp:udp" that does not provide content or attributes on its own. Instead, it references the "rtp:udp" element named "endpoint-addr-1" by using this identifier in its "ref" attribute. The requirements for implementation concerning the processing of the "ref" attribute are as follows: 1. The parsing application MUST try to locate an element of the element type as the referencing element. 2. If such an element is found, the attributes of the referencing element MUST be augmented with the attributes of the referenced element. Only those attributes that are not specified by the referencing element MUST be considered. 3. The content of referenced element, i.e., child elements or character content, MUST be added to the content of the referencing element. The content of the referenced element MUST be added before the content of the referencing element. For example, if a referenced element A provides the child elements a1 and a2, and a referencing element B provides the child elements b1 and b2, the resulting content will consists of the following child elements in this order; a1,a2,b1,b2. The semantics of the Kutscher, et al. Expires December 30, 2002 [Page 21] Internet-Draft SDPng July 2002 resulting content are completely application dependent, i.e., an profile SHOULD specify corresponding content models and define the semantics, for example for multiple occurenced of an element of a certain type. The following example provides an example of an reference to an existing element by an refering element that overwrites an attribute of the referenced element. Open Issue: Should overwriting of child elements be allowed as well? 3.4 External Definition Packages There are two types of external definitions: Profile Definitions (Section 3.4.1) define rules for specifying parameters that are not covered by the base SDPng specification. Library Definitions (Section 3.4.2) contain definitions that can be referenced in SDPng documents. 3.4.1 Profile Definitions In order to allow for extensibility it must be possible to define extensions to the basic SDPng configuration options. For example, if some application requires the use of a new transport protocol, endpoints must be able to describe their configuration with respect to the parameters of that transport protocol. The mandatory and optional parameters that can be configured and negotiated when using the transport protocol will be specified in a definition document. Such a definition document is called a "profile". Kutscher, et al. Expires December 30, 2002 [Page 22] Internet-Draft SDPng July 2002 A profile contains rules that specify how SDPng is used to describe conferences or end-system capabilities with respect to the parameters of the profile. The specific properties of the profile definitions mechanism are still to be defined. An example of such a profile would be the RTP profile that defines how to specify RTP parameters. Another example would be the audio codec profiles that defines how specify audio codec parameters. SDPng documents can reference profiles and provide specific definitions, for example the definition for the GSM audio codec. (This would be done in the "Definitions" section of an SDPng document.) An SDPng document that references a profile and provides specific definitions of configurations can be validated against the profile definition. 3.4.2 Library Definitions While profile definitions specify the allowed parameters for a given profile, SDPng "Definitions" sections refer to profile definitions and define concrete configurations based on a specific profile. In order for such definitions to be imported into SDPng documents, "SDPng libraries" may be defined and referenced in SDPng documents. A library is a set of definitions that is conforming to one or more profile definitions. The purpose of the library concept is to allow certain common definitions to be factored-out so that not every SDPng document has to include the basic definitions, for example the PCMU codec definition. SDP [2] uses a similar concept by relying on the well known static payload types (defined in RFC1890 [4]) that are also just referenced but never defined in SDP documents. An SPDng document that references definitions from an external library has to declare the use of the external library. The external library, being a set of configuration definitions for a given profile, again needs to declare the use of the profile that it is conforming to. A library itself can make reference to other external libraries. There are different possibilities of how profiles definitions and libraries can be used in SDPng documents: o In an SPDng document, a profile definition can be referenced and all the configuration definitions are provided within the document itself. The SDPng document is self-contained with respect to the definitions it uses. Kutscher, et al. Expires December 30, 2002 [Page 23] Internet-Draft SDPng July 2002 o In an SPDng document, the use of an external library can be declared. The library references a profile definition and the SDPng document references the library. There are two alternatives how external libraries can be referenced: by name: Referencing libraries by names implies the use of a registration authority where definitions and reference names can be registered with. It is conceivable that the most common SDPng definitions be registered that way and that there will be a baseline set of definitions that minimal implementations must understand. Secondly, a registration procedure will be defined, that allows vendors to register frequently used definitions with a registration authority (e.g., IANA) and to declare the use of registered definition packages in conforming SDPng documents. Of course, care should be taken not to make the external references too complex and thus require too much a priori knowledge in a protocol engine implementing SDPng. Relying on this mechanism in general is also problematic because it impedes the extensibility, as it requires implementors to provide support for new extensions in their products before they can inter-operate. Registration is not useful for spontaneous or experimental extensions that are defined in an SDPng library. by address: An alternative to referencing libraries by name is to declare the use of an external library by providing an address, i.e., an URL, that specifies where the library can be obtained. While this allows the use of arbitrary third-party libraries that can extend the basic SDPng set of configuration options in many ways, in introduces additional complexity that could result in in higher latency for the processing of a description document with references to external libraries. In addition, there are problems if the referenced libraries cannot be accessed by all communication partners. o Because of these problematic properties of external libraries, the final SDPng specification will have to provide a set of recommendations under which circumstances the different mechanisms of referring to external definitions should be used. 3.5 Mappings A mapping needs to be defined in particular to SDP that allows to translate final session descriptions (i.e. the result of capability negotiation processes) to SDP documents. In principle, this can be done in a rather schematic fashion for the base specification and a set of basic profiles. Kutscher, et al. Expires December 30, 2002 [Page 24] Internet-Draft SDPng July 2002 In addition, mappings to H.245 will be defined in order to support applications like SIP-H.323 gateways. Kutscher, et al. Expires December 30, 2002 [Page 25] Internet-Draft SDPng July 2002 4. Capability Negotiation SDPng is a description language for both potential configurations (i.e. capabilities) of participants in multimedia conferencers and for actual configurations (i.e. final specifications of parameters). Capability negotiation is the process of generating a usable set of potential configurations and finally an actual configuration from a set of potential configurations provided by each potential participant in a multimedia conference. SDPng supports the specification of endpoint capabilities and defines a negotiation process: In a negotiation process, capability descriptions are exchanged between participants. These descriptions are processed in a "collapsing" step which results in a set of commonly supported potential configurations. In a second step, the final actual configuration is determined that is used for a conference. This section specifies the usage of SDPng for capability negotiation. It defines the collapsing algorithm and the procedures for exchanging SDPng documents in a negotiation phase. The description language and the rules for the negotiation phase that are defined here are (in general) independent of the means by which descriptions are conveyed during a negotiation phase (a reliable transport service with causal ordering is assumed). There are however properties and requirements of call signalling protocols that have been considered to allow for a seamless integration of the negotiation into the call setup process. For example, in order to be usable with SIP, it must be possible to negotiate the conference configuration within the three-way-handshake of the call setup phase. In order to use SDPng instead of SDP according to the offer/answer model defined in [16] it must be possible to determine an actual configuration in a single request/response cycle. 4.1 Outline of the Negotiation Process Conceptually, the negotiation process comprises the following individual steps (considering two parties, A and B, where A tries to invite B to a conference). Please note that this describes the steps of the negotiation process conceptually -- it does not specify requirements for implementations. Specific procedures that MUST be followed by implementations are given below. 1. A determines its potential configurations for the components that should be used in the conference (e.g. "interactive audio" and "shared whiteboard") and sends a corresponding SDPng instance to B. This SDPng instances is denoted "CAP(A)". 2. B receives A's SDPng instance and analyzes the set of components Kutscher, et al. Expires December 30, 2002 [Page 26] Internet-Draft SDPng July 2002 (sdpng:c elements) in the description. For each component that B wishes to support it generates a list of potential configurations corresponding to B's capabilities, denoted "CAP(B)". 3. B applies the collapsing function and obtains a list of potential configurations that both A and B can support, denoted "CAP(A)xCAP(B) = CAP(AB)". 4. B sends CAP(B) to A. 5. A also applies the collapsing function and obtains "CAP(AB)". At this step, both A and B know the capabilities of each other and the potential configurations that both can support. 6. In order to obtain an actual configuration from the potential configuration that has been obtained, both particpants have to pick a subset of the potential configurations that should actually be used in the conference and generate the actual configuration. It should be noted that it depends on the specific application whether each component must be assigned exactly one actual configuration (one sdpng:alt element) or whether it is allowed to list multiple actual configurations. In this model we assume that A selects the actual configuration, denoted CFG(AB). 7. A augments CFG(AB) with the transport parameters it intends to use, e.g., on which endpoint addresses A wishes to receive data, obtaining CFG_T(A). A sends CFG_T(A) to A. 8. B receives CFG_T(A) and adds its own transport parameters, resulting in CFG_T(AB). CFG_T(AB) contains the selected actual configurations and the transport parameters of both A and B (plus any other SDPng data, e.g., meta-information on the conference). CFG_T(AB) is the complete conference description. Both A and B now have the following information: CAP(A) A's supported potential configurations CAP(B) B's supported potential configurations CAP(AB) The set of potential configurations supported by both A and B. CFG(AB) The set of actual configurations to be used. CFG_T(AB) The set of actual configurations to be used augmented with all required parameters. Kutscher, et al. Expires December 30, 2002 [Page 27] Internet-Draft SDPng July 2002 In this model, the capability negotiation and configuration exchange process leads to a description that represents a global view of the configuration that should be used. This means, it contains the complete configuration for all participants including per-participant information like transport parameters. Note that the model presented here results in four SDPng exchanges. As an optimization, this procedure can be abbreviated to two exchanges by including the transport (and other) parameters into the potential configurations. A embeds its desired transport parameters into the list of potential configurations and B also sends all required parameters in the response together with B's potential configurations. Both A and B can then derive CFG_T(AB). Transport parameters are usually not negotiable, therefor they have to be distingiushed from other configuration information. Specific procedures for re-negotiation and multi-party negotiation will be defined in a future version of this document. 4.2 The Collapsing Algorithm The following procedure MUST be used for the collapsing of two SDPng document instances into one: CAP(A) and CAP(B) are the two SDPng description document instances. For each component (sdpng:c element) in CAP(A) there is a corresponding component in CAP(B). Components MAY be empty (containing no sdpng:alt elements) which means that there is no potential configuration and the component should not be used in the conference. Let cfg_AB be the result configuration element, initialized to an empty sdpng:cfg element. 1. For each component (sdpng:c element) in CAP(A) named c_A * Let c_AB be the current result component, initialized to an empty sdpng:c element. * For each alternative (sdpng:alt element) in c_A named a_A + For each session element (name depends on the profile being used) in a_A named s_A - Resolve any reference to definition elements recursively and obtain s1_A, the standalone media session description. (Refer to Section 4.2.1 for a description of how to resolve references.) Kutscher, et al. Expires December 30, 2002 [Page 28] Internet-Draft SDPng July 2002 - Locate the component element that matches c_A in CAP(B) named (c_B). - Let a_AB be the current result alternative, initialized to an empty sdpng:alt element. - For each alternative (sdpng:alt element) in c_B named a_B o For each session element (name depends on the profile being used) in a_B named s_B * Let s1_AB be the computed result media session configuration. * Resolve any reference to definition elements recursively and obtain s1_B, the standalone media session description. * Apply collapse(s1_A,s2_B) to compute s1_AB, the collapsed media session configuration. * If s1_AB is not empty, add s1_AB to a_AB, the set of sessions for the current result alternative. - If a_AB is not empty, add a_AB to c_AB. * If c_AB is not empty, add c_AB to cfg_AB. The collapsing function for collapsing two elements is specified in Section 4.2.1. 4.2.1 Collapsing Two Configurations Before two media session configuration element can be collapsed as described in Section 4.2 all references to definitions MUST be resolved. This MUST be performed recursively, i.e. references in definitions MUST also be resolved. For resolving references, the algorithm specified in Section 3.3 MUST be used. By resolving all references two intermediate session configuration elements are obtained that can then be collapsed according to the algorithm specified in the following sections. 4.2.1.1 Collapsing of Attributes In SDPng, capabilities are specified in attributs of XML elements. Three different types of capabilities with different collapsing rules Kutscher, et al. Expires December 30, 2002 [Page 29] Internet-Draft SDPng July 2002 are defined. The type of a capability is encoded in the attribute value. Set of symbols: An attribute can specify a set of symbols. When two attributes are collapsed, the result is the intersection of the two sets. The following examples shows how two elements (with one attribute representing a set of symbols) originated from two capability descriptions from participants A and B are collapsed: Element x in A's capability description: Element x in B's capability description: Result: If the intersection result in an empty set the collapsing process has failed and there is no common set of values. If the collapsing of one of an element's attributes with the type "set of symbols" has failed, the collapsing process of the element itself MUST be considered to have failed as well. Numerical ranges: An attribute can also specify a numercial range. When two attributes are collapsed the result is the range of values that represents the intersection of the set of values that is included in both ranges. The following examples shows how two elements (with one attribute representing a numerical range) originated from two capability descriptions from participants A and B are collapsed: Element x in A's capability description: Element x in B's capability description: Result: A numerical range is represented by a tuple of comma-separated Kutscher, et al. Expires December 30, 2002 [Page 30] Internet-Draft SDPng July 2002 numbers in brackets. The first number represents the lower bound of the range and the second number represents the upper bound. Let MIN(a,b) be a function that returns the minimum of a and b and MAX(a,b) be a function that returns the maximum of a and b. Given two ranges (minA, maxA) and (minB, maxB), the collapsed new range MUST be calculated using this algorithm: (MAX(minA, minB), MIN(maxA, maxB)) If this process results in a range with a smaller second value, the range is invalid and the collapsing has failed since there is no common range. If the collapsing of one of an element's attributes with the type "numerical range" has failed, the collapsing process of the element itself MUST be considered to have failed as well. Optional parameters: A failure of collapsing attributes of the types "set of symbols" and "numerical range" results in a failure of collapsing the corresponding element. There is a third type named "optional parameter" defined, that provides different collapsing rules. An optional parameter is an attribute with an arbitrary value. When collapsing two attributes of this type, their values MUST be tested for equality. If they are equal, the collapsing has been successful and the attribute MUST appear as is in the result description. If the attributes' values are different, the collapsing is considered to have failed and the attribute MUST not appear in the result description. However, a failure in collapsing an attribute of type "optional parameter" does not affect the collapsing of the containing element. An example for a successful collapsing: Element x in A's capability description: Element x in B's capability description: Result: An example for an unsuccessful collapsing: Kutscher, et al. Expires December 30, 2002 [Page 31] Internet-Draft SDPng July 2002 Element x in A's capability description: Element x in B's capability description: Result: 4.2.1.2 Collapsing two Elements In order to collapse two elements with multiple attributes, the following algorithm specified below MUST be applied. In general, the collapsing of two elements (if successful) yields a result element that contains the collapsed attributes. If the collapsing of two elements has failed, no result element is generated. 1. For each attribute, determine the type and collapse the attribute by applying the algorithm for the corresponding attribute type. 2. If an attribute with a different type than "optional parameter" does not occur in both elements, the collapsing for this element MUST be considered to have failed. 3. If the collapsing of any attribute with a different type than "optional parameter" has failed, the collapsing of the element itself MUST be considered to have failed. 4. If the collapsing has been successful, obtain the result element by using the same element name (GI) and the attributes with their collapsed values. Exclude any attribute of type "optional parameter" that has failed to collapse. An example: Element x in A's capability description: Element x in B's capability description: Result: Kutscher, et al. Expires December 30, 2002 [Page 32] Internet-Draft SDPng July 2002 4.2.1.3 Collapsing nested Elements In order to collapse nested elements the following algorithm MUST be applied: In analogy to attributes representing optional parameters there is also the possibility to mark elements as optional for the negotiation process. Elements MAY provide an attribute named "status" that contains a symbol or a comma-separated list of symbols as its value. If the value "opt" occurs in the list of a "status" attribute of both elements to be collapsed, the elements to be collapsed MUST be treated as optional. This means, if the collapsing of the attributes has failed (according to the rules specified in Section 4.2.1.2), the collapsing process MUST NOT not yield a result element but MUST still be treated as "successful", i.e., further collapsing operation on other elements can continue. The semantics of optional elements are that they describe optional features that may be supported and selected during a negotiation phase but do not neccessarily have to be supported by all participants in order to achieve interoperability. The example below shows how to generate a result element in the presence of optional child elements that have failed to collapse. The collapsing algorithm for nested elements: 1. Let x be an element that occurs in the capability description of two participants A and B and that should be collapsed. 2. Collapse the attributes of the element x using the algorithm specified in Section 4.2.1.2. If the collapsing has failed according to the rules of Section 4.2.1.2 and if the elements to be collapsed are not marked as optional, the collapsing of the element and all of its children MUST be considered to have failed. The collapsing MUST be stopped. If the collapsing has failed and both elements have been marked as optional, the child elements MUST NOT be processed. In this case, the collapsing process does not yield a result element but the collapsing of other elements (sibling or parent elements) MUST be continued. 3. If the collapsing has been successful according to the rules of Section 4.2.1.2, the child elements of A's and B's x element MUST be processed. If there are no child elements in both A's and B's content the collapsing has been successful and can be terminated. If either A's or B's x element provides child elements, apply the following algorithm to each child element named c of participant A's element x: 1. Find a corresponding element (same GI) in the set of Kutscher, et al. Expires December 30, 2002 [Page 33] Internet-Draft SDPng July 2002 participant B's child elements. If no matching element has been found, the collapsing of element x MUST be considered to have failed. 2. If a matching element has been found, apply the collapsing algorithm recursively. As long as the collapsing is successful, the result of collapsing each element is transferred to the result element, such that the resulting element tree is isomorphic to both A's and B's element tree. If there are elements in B's x element that have not been processed (because there is no corresponding element in A's x element), the collapsing MUST be considered to have failed and MUST be stopped. An example: Element x in A's capability description: Element x in B's capability description: Result: An example for collapsing optional elements: Element x in A's capability description: Element x in B's capability description: Result: Kutscher, et al. Expires December 30, 2002 [Page 34] Internet-Draft SDPng July 2002 4.2.2 Deriving an actual Configuration The result of a capability negotiation process is a potential configuration, i.e., a description potentially containing multiple alternatives per component. The alternative themselves may provide elements that represent collapsed capabilities. In order to derive an actual configuration, the following problems must be addressed: 1. For each component (sdpng:c element) an appropriate alternative (sdpng:alt element) has to be selected. It is conceivable that the order of the alternatives in the description is used as a preference indicator. More details have to be specified in a future version of this document. 2. If the description of the selected alternatives contains attributes with numerical ranges or sets of symbols with more than one entry, those attributes either have to be transformed that they represent a single value or participants have to agree that an actual configuration may contain ranges and sets of symbols. The semantics of these variable actual configurations will have to specified in later versions of this document. For example, for certain applications it may be desireable to agree on ranges of values for certain attributes during a capability negotiating meaning that any of the values of the range are supported (and have to be supported). The specific procedures to determine an actual configuration have to be defined in a later version on this document. Kutscher, et al. Expires December 30, 2002 [Page 35] Internet-Draft SDPng July 2002 5. Formal Specification This section defines the SDPng syntax and the use of XML mechanisms, such as XML Namespace and XML Schema. Section 5.1 defines the relation between SDPng and XML Schema, Section 5.2 specifies general requirements for documents and profile definitions that are conforming to the SDPng schema, Section 5.3 list requirements for profile definitions, Section 5.4 specifies specific requirements for conforming documents and Section 5.5 lists requirements for the definition of SDPng libraries. Section 5.7 defines the SDPng base schema, Appendix A.1 defines the profile for audio codec definitions and Appendix B defines the profile for RTP payload type definitions. 5.1 XML Schema as a Definition Mechanism SDPng documents reference profile schema definitions and libraries. Profile schema definitions contain schema definitions of SDPng document elements. For example, the general structure is specified by a schema definition and extensions to SDPng for specific applications are specified as schema definitions as well. SDPng uses XML-Schema [13][14] for defining the possible logical structures of SDPng documents for the following reasons: Extensibility: XML-Schema provides mechanisms that allow to extend existing definitions allowing to uniquely identify element types (by relying on XML namespaces [11]). Modularity: XML-Schema provide mechanisms that allow to organize schema definitions in multiple components. Expressiveness: XML-Schema provides many data types, that can be refined by user-supplied definitions. SDPng documents MUST be schema instances of the SDPng schema as defined in Section 5.7. The following example shows how a Schema definition can be referenced in a document instance. Beginning of an SDPng-document: XML-Schema specifies that documents can assign a namespace when Kutscher, et al. Expires December 30, 2002 [Page 36] Internet-Draft SDPng July 2002 referencing a schema definition. A SDPng namespace is defined for this purpose. The name of this namespace is "http://www.iana.org/sdpng". SDPng documents MUST use this namespace as their default namespace. For SDPng documents, this initial declaration can be added implicitly by applications, so that declarations like the one above do not have to be included in every description document. Details are to be defined in a later version of this document. 5.2 SDPng Schema The basic SDPng schema definitions specifies the general document structures, e.g., one "Definitions" section followed by one "Configurations" sections, followed by one "Constraints" sections followed by a "Conference" section (for meta-information). Each document MUST provide the elements for definitions, configurations, constraints and conference information in exactly this order, whereby only the configurations section is MANDATORY. Refer to Section 5.7 for a formal definition of the SDPng base schema and the specific element types for definitions, configurations, constraints and conference information. The SDPng base schema also specifies "abstract" base data types (by means of XML-Schema type definitions) for elements that MUST be used by documents in the corresponding sections. The base data types provide common required attributes, e.g. a "name" attribute for naming definition elements. Example: The following example shows the definition of the base type for definition elements: Profiles can then define specific types that augment the base type definitions. Common attributes or content models, that have been defined by this base definition, do not have to be provided by those specific type definitions. The type definitions can be identified as allowed element types for the content models that are specified in the base SDPng schema definition. This allows for automatic validation of profile definitions and facilitates the extension of SDPng. Kutscher, et al. Expires December 30, 2002 [Page 37] Internet-Draft SDPng July 2002 5.3 Profiles The baseline SDPng specification consists of a profile (a schema definition) and a library of commonly used definitions. The library of commonly used definitions provides data types for IP (and other) addresses. A profile definition MUST import (using the XML-Schema import mechanism) the base SDPng schema definition and MUST provide an extension definition, e.g., specializations of base element types. A profile definition MUST also provide a target namespace name for its definitions. For well-known (registered) profiles, the namespace name will be registered by IANA. Proprietary profiles will use other namespace names, for example, based on domain names, that are registered by vendors providing a profile. Example: The following example shows such a declaration at the beginning of a profile definition: In this example, the namespace prefix "audio" is defined and later used in schema definitions. (The example profile provides definition mechanisms for audio codecs.) The following example shows, how a derived type for "definition" elements can be specified with XML-Schema mechanisms. In this case, the abstract type "Definition" (fully qualified as "sdpng:Definition") is augmented by three attributes that are useful for defining audio codecs. Example: Kutscher, et al. Expires December 30, 2002 [Page 38] Internet-Draft SDPng July 2002 This type definition is then used to define an XML element type called "codec". Example: When used by SDPng documents, the general identifier is qualified with a namespace prefix, for example as in: "audio:codec". 5.4 SDPng Documents SDPng documents MUST reference the employed profiles and provide namespace prefixes for the namespace names of the profiles as shown in the following example. Example: For well-known registered profiles, the namespace name AND the used namespace prefix SHOULD be registered to allow for simple basic implementations that can match identifiers by using fixed fully qualified names without having to interpret namespace declarations (see Section 5.6.3). There is one issue with declaring used XML- Schema definitions in documents (see Section 6 below). The general structure of an SDPng documents MUST conform to the basic SDPng schema definition and MAY provide a "def" element for definitions; it MUST provide a "cfg" element for the configuration section; it MAY provide a "constraints" and a "conf" element. Example: The following example shows a sample definition section where the Kutscher, et al. Expires December 30, 2002 [Page 39] Internet-Draft SDPng July 2002 element "codec" of the "audio codec profile" is used (plus the element type "pt" of an "RTP profile"): It can be seen how the attribute name (provided by the base type for definition elements) and the profile specific attributes "encoding", "channels" and "sampling" are used together. The element "rtp:pt" is used to defined a payload type. "rtp:pt" would have been defined in another profile, again using a type derived from the base definition type. "rtp:pt" provides attribute for referencing other definitions, e.g., the definition of audio- codes as seen before. 5.5 Libraries SDPng libraries are collections of definitions that are referenced by documents. Libraries are thus independent, valid SDPng documents. For example, the definition of the different audio codecs as shown in the previous example could be provided by a library that can be referenced by documents without having to define such common codecs in every document. The XML mechanism XInclude [12] is used for referencing libraries in SDPng documents. XInlcude works at the XML Information Set ("infoset") level, i.e. the mechanisms allows to have an integrating document reference fragment documents, while these fragments are well-formed (and, if applicable, valid) documents themselves. By resolving XInclude directives in integrating documents the documents' infosets are "merged" together, enabling applications to operate on the resulting infosets as if it had been generated by parsing a single, monolithic document. Inclusion at the XML infoset level has the advantage that documents are standalone -- they can be validated independently. Another Kutscher, et al. Expires December 30, 2002 [Page 40] Internet-Draft SDPng July 2002 advantage is that is relatively easy to generate a "merged" infoset for applications that are not able to resolve references to libraries themselves. 5.6 Details on the use of specific XML Mechanisms This section specifies the use of specific XML mechanisms for SDPng. In order to allow for efficient parsing and processing, not all features of XML Schema are allowed. Some variable information is set to fixed values to allow the development of simplistic servers. 5.6.1 Default Namespace SDPng document instances MUST use the SDPng namespace "http://www.iana.org/sdpng" as their default namespace. That means, the general SDPng identifiers can be used without namespace prefixes. 5.6.2 Qualified Locals XML Schema allows to specify qualification of elements and attributes. It is possible to use non-qualified element and attribute names in Schema definitions and document instances for so- called "local definitions" (this is the default setting). "Local Definitions" are contained within "global definitions" in an XML schema definition. In order to simplify parsing and processing of SDPng document instances, all elements MUST be fully qualified. Attribute names MUST NOT be fully qualified, they are considered to have the same namespace as their corresponding elements. This means, the SDPng Schema definition contains the following attributes for the "schema" element, that MUST also be used by SDPng profiles: o elementFormDefault="qualified" This means that "locally defined" elements that are used within the scope of fully-qualified elements MUST always be fully qualified as well. o attributeFormDefault="unqualified" This means that attribute names do not have to be fully qualified. Implementations MUST infer the namespace for attributes from the namespace of the element that the attribute belongs to. Note that the specification of XML Namespaces [11] defines that default namespaces do not apply to attributes. In profile definitions, all attributes MUST be defined locally. The same holds for the base SDPng schema. These rules make SDPng document instances processable by non-Schema- Kutscher, et al. Expires December 30, 2002 [Page 41] Internet-Draft SDPng July 2002 aware XML parsers by requiring all element names to be fully qualified (no "local elements"). 5.6.3 Fixed Namespace Prefixes In order to facilitate the development of basic implementations, a few commonly used namespace names are associated with fixed prefixes, i.e. document instances and libraries MUST always use these prefixes. These prefixes MUST NOT be used for namespaces names than the ones that are assigned to them. In order to ensure the uniqueness of namespace prefixes, namespace prefixes will be have to registered together with the corresponding namespace names. The namespace prefix for the SDPng namespace is "sdpng". 5.7 SDPng Schema Definitions This section provides the definition of the base SDPng XML Schema. 1. Section 5.7.1 contains the base definition that provides the general element types for SDPng. 2. Appendix A.1 contains a profile for audio codecs. 3. Appendix B contains a profile for RTP payload type definitions. 5.7.1 SDPng Base Definition This schema definition defines the general structure of SDPng document instances. It defines the top-level element type "desc" that can have a sequence of "def", "cfg", "constraints" and "conf" elements as element content. In addition, "extensions hooks" are provided that can be used by extension profiles providing definitions for specific applications. In general, these extension are implemented by deriving profile definitions from SDPng base definitions. The deployed XML Schema mechanisms are "deriving by extension" and "substitution groups". The SDPng base definition provides different base types (as complexType definitions) for elements that are to be used in "def", "cfg" and "conf" sections. In addition, it also defines specific element types as "head elements" with assigned types that are used for defining the content model of, e.g., the "def" element type. Profiles that provide new element types for specific applications will define types that are derived from the base types and provide the additional attributes and element content definitions that are Kutscher, et al. Expires December 30, 2002 [Page 42] Internet-Draft SDPng July 2002 required for the application. The XML element types that are defined in a profile are declared as valid substitutes for the base elements ("head elements") by setting the "substitutionGroup" attribute to the name of the "head element" type. For an extension profile that provides new definition element types, e.g. for codec definitions, a new complexType would be defined that extends sdpng:Definition (see below). An element type definition that assigns that new type must then be declared to be in the substitutionGroup "sdpng:definition". This mechanism allows common rules for attributes and content models to be defined in base element definition and re-used by extension profiles and it also allows validating parsers to identify the correct type of elements that have been defined by profile definitions. The SDPng Base Definition: This schema definition defines the general structure of SDPng document instances. It provides base type and base element definition for elements to occur in the different sections (def, cfg, constraints, conf) to be derived from in extension-profile definitions. For an extension-profile that provides new definition element types, e.g. for codec definitions, a new complexType would be defined that extends sdpng:Definition (see below). An element type definition that assigns that new type must then be declared to be in the substitutionGroup "sdpng:definition". Kutscher, et al. Expires December 30, 2002 [Page 43] Internet-Draft SDPng July 2002 The top-level element of an SDPng document. It defines the overall structure of an SPDng document. The definitions section The configurations section The constraints section Kutscher, et al. Expires December 30, 2002 [Page 44] Internet-Draft SDPng July 2002 The conference section Placeholder base element for a definition element in the definitions section. To be derived from by specific definition element type definitions. The configuration element in the configurations section. Placeholder base element for a contraint element in the contraints section. To be derived from by specific constraint element type definitions. Kutscher, et al. Expires December 30, 2002 [Page 45] Internet-Draft SDPng July 2002 The base type for definition. Defines a attribute "name" for naming definitions. The attribute 'name' MUST be used for specifying a name in a definiton. The attribute 'ref' MUST be used for referencing a previously defined definition. The specification of a component consists of a sequence of alternatives. Each alternative consists of a "sessionConfig" (session configuration) element. The "sessionConfig" element is a base element of base type "sdpng:Session" that is used to derive specific session types in extension profiles. Kutscher, et al. Expires December 30, 2002 [Page 46] Internet-Draft SDPng July 2002 The (abstract) base type for session elements. To be derived from in extension profiles. The current content model for constraints is a sequence of "sdpng:par" elements. In each "par" element a sequence of "use-alt" elements may be used to specific the definitions that may used in parallel. Each "use-alt" element can define the number of minimum and maximum instantiations. Kutscher, et al. Expires December 30, 2002 [Page 47] Internet-Draft SDPng July 2002 The base type for conference meta inforformation element. Currently, there is no common content model defined. Kutscher, et al. Expires December 30, 2002 [Page 48] Internet-Draft SDPng July 2002 The SDPng XML schema definition references some attribute definition for Xlink attributes (as defined by the Xlink specification [15]): Kutscher, et al. Expires December 30, 2002 [Page 49] Internet-Draft SDPng July 2002 6. Open Issues Definition of baseline libraries Libraries provide partially specified definitions, i.e. without transport parameters. How can SDPng documents reference the definitions and augment them with specific transport parameters? Referencing extension profiles: XML-Schema does not support the declaration of multiple schemas via the schemaLocation attribute. Conceivable solution: When extension profiles are used, the SDPng description is a "multi-part" object, that consists of an integrating schema definition (that references all necessary profiles and the base definition) and the actual description document that is a schema instance of the integrating schema. Uniqueness of attribute values: When libraries are used they will contain definition elements with "name" attributes for later referencing. How to avoid name clashes for those identifiers? When an SDPng document uses libraries from different sources they could be incompatible because of name collisions. Possible solution: Prefix such IDs with a namespace name (either explicitly or implicitly by interpreting applications). The explicit prefixes have the advantage that no special knowledge would be required to resolve links at the cost of very long ID values. A registry (reuse of SDP mechanisms and names etc.) needs to be set up. Negotiation mechanisms for multiparty conferencing need to be formalized. Mapping to other media description formats (SDP, H.245, ...) should be provided. For H.245, this is probably a different document (belonging to the SIP-H.323 inter-working group). Implicit declaration of SDPng schema and default profiles Should overwriting of child elements be allowed for referencing existing definitions with the "ref" attribute? Kutscher, et al. Expires December 30, 2002 [Page 50] Internet-Draft SDPng July 2002 7. Acknowledgements The authors would like to thank Teodora Guenkova, Goran Petrovic and Markus Nosse for their feedback and detailed comments. Kutscher, et al. Expires December 30, 2002 [Page 51] Internet-Draft SDPng July 2002 References [1] Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements for Session Description and Capability Negotiation", Internet Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001. [2] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998. [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996. [5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", draft-ietf-avt-profile-new- 10.txt (work in progress), March 2001. [6] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997. [7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999. [8] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998. [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [10] World Wide Web Consortium (W3C), "Extensible Markup Language (XML) 1.0 (Second Edition)", Status W3C Recommendation, Version http://www.w3.org/TR/2000/REC-xml-20001006, October 2000. [11] World Wide Web Consortium (W3C), "Namespaces in XML", Status W3C Recommendation, Version http://www.w3.org/TR/1999/REC-xml- names-19990114, January 1999. [12] World Wide Web Consortium (W3C), "XML Inclusions (XInclude) Version 1.0", Status W3C Candidate Recommendation, Version http://www.w3.org/TR/2002/CR-xinclude-20020221, February 2002. [13] World Wide Web Consortium (W3C), "XML Schema Part 1: Structures", Version http://www.w3.org/TR/2001/REC-xmlschema-1- 20010502/, Status W3C Recommendation, May 2001. Kutscher, et al. Expires December 30, 2002 [Page 52] Internet-Draft SDPng July 2002 [14] World Wide Web Consortium (W3C), "XML Schema Part 2: Datatypes", Version http://www.w3.org/TR/2001/REC-xmlschema-2- 20010502/, Status W3C Recommendation, May 2001. [15] World Wide Web Consortium (W3C), "XML Linking Language (XLink) Version 1.0", Version http://www.w3.org/TR/2001/REC-xlink- 20010627/, Status W3C Recommendation, June 2001. [16] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", draft-ietf-mmusic-sdp-offer-answer-02.txt (work in progress), February 2002. [17] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for The Use of XML within IETF Protocols", draft-hollenbeck-ietf-xml- guidelines-05.txt (work in progress), June 2002. Authors' Addresses Dirk Kutscher TZI, Universitaet Bremen Bibliothekstr. 1 Bremen 28359 Germany Phone: +49.421.218-7595, sip:dku@tzi.org Fax: +49.421.218-7000 EMail: dku@tzi.uni-bremen.de Joerg Ott TZI, Universitaet Bremen Bibliothekstr. 1 Bremen 28359 Germany Phone: +49.421.201-7028, sip:jo@tzi.org Fax: +49.421.218-7000 EMail: jo@tzi.uni-bremen.de Kutscher, et al. Expires December 30, 2002 [Page 53] Internet-Draft SDPng July 2002 Carsten Bormann TZI, Universitaet Bremen Bibliothekstr. 1 Bremen 28359 Germany Phone: +49.421.218-7024, sip:cabo@tzi.org Fax: +49.421.218-7000 EMail: cabo@tzi.org Kutscher, et al. Expires December 30, 2002 [Page 54] Internet-Draft SDPng July 2002 Appendix A. SDPng Audio Codec Profile and Audio Codec Library This section defines an SDPng profile for audio codec definitions and a corresponding library of SDPng definitions of specific audio codecs. A.1 Audio Codec Profile [5] specifies a number of audio codecs including short name to be used as reference by session description protocols such as SDP and SDPng. Those codec names, as listed in the first column of the above table, are used to identify codecs in SDPng. The following sections indicate the default values that are assumed if nothing else than the codec reference is specified. The following audio:codec attributes are defined for audio codecs: name: the identifier to be later used for referencing the codec spec encoding: the RTP/AVP profile identifier as registered with IANA mime: the MIME type; may alternatively be specified instead of "encoding" channels: the number of independent media channels pattern: the media channel pattern for mapping channels to payload sampling: the sample rate for the codec (which in most cases equals the RTP clock) Furthermore, options may be defined of the following format: if a value is associated with the option (note that arbitrary complex values are allowed), or alternatively: