Network Working Group                                           Kutscher
Internet-Draft                                                       Ott
Expires: December 30, 2002 September 1, 2003                                       Bormann
                                                TZI, Universitaet Bremen
                                                           July 01, 2002
                                                          March 03, 2003

             Session Description and Capability Negotiation
                     draft-ietf-mmusic-sdpng-05.txt
                     draft-ietf-mmusic-sdpng-06.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. September 1, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002). (2003).  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
   $Revision: 4.12 6.9 $

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . .  4 .  3
   2.    Terminology and System Model . . . . . . . . . . . . . . .  6
   3.      SDPng  . . . . . . . . . . . . . . . . . . . . .  5
   3.    Capability Negotiation: Overview and Requirements  . . . . .  9
   3.1     Conceptual   Outline of the Negotiation Process . . . . . . . . . . . . .  9
   3.2   The Negotiation Process  . . . . . . .  9
   3.1.1   Definitions . . . . . . . . . . . 11
   4.    SDPng  . . . . . . . . . . . .  9
   3.1.2   Components & Configurations . . . . . . . . . . . . . . . 11
   3.1.3   Constraints 12
   4.1   Conceptual Outline . . . . . . . . . . . . . . . . . . . . . 12
   4.1.1 Potential Configurations . . 13
   3.1.4   Session Attributes . . . . . . . . . . . . . . . . 13
   4.1.2 Actual Configurations  . . . . 14
   3.1.4.1 Owner . . . . . . . . . . . . . . . 15
   4.1.3 Constraints  . . . . . . . . . . . 15
   3.1.4.2 Session Identification . . . . . . . . . . . . . 18
   4.1.4 Meta Information . . . . . 15
   3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) . . . 16
   3.1.4.4 Component Semantic Specification . . . . . . . . . . . . . 17
   3.2 . 18
   4.2   Syntax Definition Mechanisms . . . . . . . . . . . . . . . 17
   3.3 . 18
   4.3   Referencing Definitions  . . . . . . . . . . . . . . . . . 20
   3.3.1   The attribute "ref"  . . . . . . . . . . . . . . . . . . . 21
   3.4 20
   4.4   External Definition Packages . . . . . . . . . . . . . . . 22
   3.4.1   Profile . 20
   4.4.1 Package Definitions  . . . . . . . . . . . . . . . . . . . 22
   3.4.2 . 20
   4.4.2 Library Definitions  . . . . . . . . . . . . . . . . . . . 23
   3.5     Mappings . . . . . . . 21
   4.5   Mappings . . . . . . . . . . . . . . . . . . 24
   4.      Capability Negotiation . . . . . . . . 22
   5.    Syntax Definition  . . . . . . . . . . 26
   4.1     Outline of the Negotiation Process . . . . . . . . . . . 23
   5.1   Potential Configurations . 26
   4.2     The Collapsing Algorithm . . . . . . . . . . . . . . . . . 28
   4.2.1   Collapsing Two Configurations 23
   6.    Specification of the Capability Negotiation  . . . . . . . . 26
   6.1   Offer/Answer . . . . . . 29
   4.2.1.1 Collapsing of Attributes . . . . . . . . . . . . . . . . . 29
   4.2.1.2 Collapsing two Elements . 26
   6.2   RFC2533 Negotiation  . . . . . . . . . . . . . . . . 32
   4.2.1.3 Collapsing nested Elements . . . . 27
   6.2.1 Translating SDPng to RFC 2533 Expressions  . . . . . . . . . 27
   6.2.2 Applying RFC 2533 Canonicalization . . . 33
   4.2.2   Deriving an actual Configuration . . . . . . . . . . 29
   6.2.3 Integrating Feature Sets into SDPng  . . . 35
   5.      Formal Specification . . . . . . . . . 30
   7.    Open Issues  . . . . . . . . . . 36
   5.1     XML Schema as a Definition Mechanism . . . . . . . . . . . 36
   5.2     SDPng Schema . . . 31
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . 37
   5.3     Profiles . . 32
         References . . . . . . . . . . . . . . . . . . . . . . . 38
   5.4     SDPng Documents . . 33
         Authors' Addresses . . . . . . . . . . . . . . . . . . . 39
   5.5     Libraries . . 34
   A.    Use of SDPng in conjunction with other IETF Signaling
         Protocols  . . . . . . . . . . . . . . . . . . . . . . 40
   5.6     Details on the use of specific XML Mechanisms . . . 36
   A.1   The Session Announcement Protocol (SAP)  . . . 41
   5.6.1   Default Namespace . . . . . . . 36
   A.2   Session Initiation Protocol (SIP)  . . . . . . . . . . . . . 41
   5.6.2   Qualified Locals 37
   A.3   Real-Time Streaming Protocol (RTSP)  . . . . . . . . . . . . 44
   A.4   Media Gateway Control Protocol (MEGACOP) . . . . . . . . . 41
   5.6.3   Fixed Namespace Prefixes . 44
   B.    Change History . . . . . . . . . . . . . . . . 42
   5.7     SDPng Schema Definitions . . . . . . . 45
         Full Copyright Statement . . . . . . . . . . 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
   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

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:

   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.

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
      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.

      *  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].

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
   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:

   <audio:codec name="audio-basic" encoding="PCMU"
                sampling="8000" channels="1"/>

   <audio:codec name="audio-L16-mono" encoding="L16"
                sampling="44100" channels="1"/>

   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].

   <audio:codec name="audio-L16-stereo" ref="audio-L16-mono"
                channels="2"/>

   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.

   <rtp:pt name="rtp-avp-0" pt="0">
     <audio:codec ref="audio-basic"/>
   </rtp:pt>

   <rtp:pt name="rtp-avp-11" pt="11">
     <audio:codec ref="audio-L16-mono"/>
   </rtp:pt>

   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":

   <rtp:pt name="rtp-avp-10" pt="10">
    <audio:codec encoding="L16" sampling="44100" channels="2"/>
   </rtp:pt>

   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.

   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:

   <cfg>
     <component name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session>
          <rtp:pt ref="rtp-avp-0"/>
          <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp:session>
       </alt>

       <alt name= AVP-audio-11">
         <rtp:session>
          <rtp:pt ref="rtp-avp-11"/>
          <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp:session>
       </alt>
      </component>
   </cfg>

   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
   element.  The following example illustrates this:

   <cfg>
     <component name="audio1" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session>
          <rtp:pt pt="0">
           <audio:codec name="audio-basic" encoding="PCMU"
                        sampling="8000" channels="1"/>
          </rtp:pt>
          <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp:session>
       </alt>
      </component>
   </cfg>

   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:

   <cfg>
     <component name="audio1" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session>
          <rtp:pt ref="rtp-avp-0"/>
          <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801">
           <option name="ssm" sender="sender.example.com"/>
          </rtp:udp>
         </rtp:session>
       </alt>
      </component>
   </cfg>

   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
   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:

   <constraints>
     <par>
       <use-alt ref="AVP-audio-11" max="5">
       <use-alt ref="AVP-video-32" max="1">
     </par>
   </constraints>

   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
   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:

   <owner user="username" session-id="session-id" version="version"
          nettype="IN" addrtype="IP4" addr="192.168.1.1"/>

   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
      optional, they may occur any number of times.

   <session name="An SDPng seminar">
       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:
       <info xlink:href="http://www.ietf.org/"/>
       <contact xlink:href="mailto:joe@example.com"/>
       <contact xlink:href="mailto:bob@example.com"/>
       <contact xlink:href="tel:+49421218"/>
       <contact xlink:href="sip:joe@example.com"/>
       <contact xlink:href="sip:bob@example.com"/>
   </session>

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
         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:

   <time start="3034423619" stop="3042462419">
     <repeat interval="7d" duration="1h"/>
     <repeat interval="7d" duration="1h" offset="25h"/>
   </time>

   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.

   <info name="audio-interactive" function="speaker">
       Audio stream for the different speakers
   </info>

   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,
   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
   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:

   <def>
    <audio:codec name="audio-basic" encoding="PCMU"
                 sampling="8000" channels="1"/>

    <audio:codec name="audio-L16-mono" encoding="L16"
                 sampling="44100" channels="1"/>

    <rtp:pt name="rtp-avp-0" pt="0"/>
      <audio:codec ref="audio-basic"/>
    </rtp:pt

    <rtp:pt name="rtp-avp-11" pt="11">
      <audio:codec ref="audio-L16-mono"/>
    </rtp:pt

   </def>

   <cfg>
     <component name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session>
          <rtp:pt ref="rtp-avp-0"/>
          <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp:session>
       </alt>

       <alt name="AVP-audio-11">
         <rtp:session>
          <rtp:pt ref="rtp-avp-11"/>
          <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp:session>
       </alt>
      </component>
   </cfg>

   <constraints>
     <par>
       <use-alt ref="AVP-audio-11" max="1">
     </par>
   </constraints>

   <conf>
    <owner user="joe@example.com" id="foobar" version="1" nettype="IN"
                         addrtype="IP4" addr="130.149.25.97"/>
    <session name="An SDPng seminar">
     This seminar is about SDPng...
     <info xlink:href="http://www.ietf.org/"/>
     <contact xlink:href="mailto:joe@example.com"/>
     <contact xlink:href="sip:joe@example.com"/>
    </session>

    <time start="3034423619" stop="3042462419">
     <repeat interval="7d" duration="1h"/>
     <repeat interval="7d" duration="1h" offset="25h"/>
    </time>

    <info name="interactive-audio" function="speaker">
       Audio stream for the different speakers
    <info>

   </conf>

   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.

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:

   <def>
      <rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/>
   </def>
   <cfg>
     <component name="interactive-audio" media="audio">
       <alt name="alt-avp-audio-10">
         <rtp:session>
           <rtp:udp ref="endpoint-addr-1"/>
         </rtp:session>
       </alt>
     </component>
   <cfg>

   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
       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 47

1. Introduction

   Multiparty multimedia conferencing is one of an reference to an
   existing element by an refering element the applications that overwrites an attribute
   require dynamic interchange of end-system capabilities and the referenced element.

   <def>
      <rtp:udp name="endpoint-addr-1" rtp-port="7800" addr="224.2.0.53"/>
   </def>
   <cfg>
     <component name="interactive-audio" media="audio">
       <alt name="alt-avp-audio-10">
         <rtp:session>
           <rtp:udp ref="endpoint-addr-1" rtp-port="8000"/>
         </rtp:session>
       </alt>
     </component>
   <cfg>

   Open Issue: Should overwriting of child elements be allowed as well?

3.4 External Definition Packages

   There are two types
   negotiation 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 a parameter set that can be
      referenced is appropriate for all sending
   and receiving end-systems in SDPng documents.

3.4.1 Profile Definitions

   In order to allow a conference.  For some applications,
   e.g.  for extensibility loosely coupled conferences or for broadcast scenarios, it must
   may be possible to define
   extensions sufficient to simply have session parameters be fixed by the basic SDPng configuration options.

   For example, if some application requires the use
   initiator of a new transport
   protocol, endpoints must be able to describe their configuration conference.  In such a scenario no negotiation is
   required because only those participants with
   respect to media tools that
   support the parameters of predefined settings can join a media session and/or a
   conference.

   This approach is applicable for conferences that transport protocol.  The mandatory 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 optional
   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 that such as media
   types, their encoding etc.  can be configured and negotiated when
   using easily inhibit the transport protocol will be specified initiation of
   conferences, for example in situations where a definition
   document.  Such a definition document is called caller insists on a "profile".

   A profile contains rules
   fixed audio encoding that specify how SDPng is used to describe
   conferences or end-system capabilities with respect to the parameters
   of not available at the profile.  The specific properties of callee's end-
   system.

   To allow for spontaneous conferences, the profile definitions
   mechanism are still to be defined.

   An example process of such defining a profile would
   conference's parameter set must therefore be the RTP profile that defines
   how to specify RTP parameters.  Another example would 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 the audio
   codec profiles that defines how specify audio codec parameters.

   SDPng documents can reference profiles and provide specific
   definitions, for example the definition appropriate for the GSM audio codec.
   (This would be done in the "Definitions" section every type of an SDPng
   document.) An SDPng document that references
   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 profile and provides
   specific definitions of configurations can be validated against the
   profile definition.

3.4.2 Library Definitions

   While profile definitions specify new
   participant with an exotic configuration joins because it may
   inconvenience existing participants or even exclude the allowed parameters main source
   from media sessions.  But conferences with equal "rights" for a given
   profile, SDPng "Definitions" sections refer to profile definitions
   and define concrete configurations based
   participants that are open for new participants on the other hand
   would need a specific profile.

   In order different model of dynamic capability negotiation, for such definitions to be imported into SDPng documents,
   "SDPng libraries" may be defined and referenced in SDPng documents.
   A library is
   example a set of definitions telephone call that is conforming extended to one or more
   profile definitions.

   The purpose of a 3-parties conference
   at some time during the library concept is to allow certain common
   definitions session.

   SDP [2] allows to be factored-out so that specify multimedia sessions (i.e.  conferences,
   "session" as used here is not every SDPng document has to include be confused with "RTP session"!)  by
   providing general information about the basic definitions, session as a whole and
   specifications for example all the PCMU codec
   definition.  SDP [2] uses a similar concept by relying on media streams (RTP sessions and others) to
   be used to exchange information within the well
   known static payload types (defined in RFC1890 [4]) that are also
   just referenced but never defined multimedia session.

   Currently, media descriptions in SDP documents.

   An SPDng document that references definitions from an external
   library has are used for two purposes:

   o  to declare the use describe session parameters for announcements and invitations
      (the original purpose of SDP) and

   o  to describe the external library.  The external
   library, being 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 configuration definitions for requirements specified in a given
   profile, again needs to declare the use of
   companion document [1].  In 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 following, we first introduce a model
   for session description and
   libraries can be capability negotiation as well as the
   basic terms used in SDPng documents:

   o throughout this specification (Section 2).  In
   Section 3, we provide an SPDng document, overview of options for capability
   negotiation.  Next, we outline the concept for the concepts
   underlying SDPng and introduce the syntactical components step by
   step in Section 4.

   Appendix B lists the change history.

2. Terminology and System Model

   Any (computer) system has, at a profile definition time, a number of rather fixed
   hardware as well as software resources.  These resources ultimately
   define the limitations on what can be referenced captured, displayed, rendered,
   replayed, etc.  with this particular device.  We term features
   enabled and
      all restricted by these resources "system capabilities".

      Example: System capabilities may include: a limitation of the configuration definitions are provided within
      screen resolution for true color by the document
      itself.  The SDPng document is self-contained with respect to 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
      definitions it uses.

   o possible video
      encoding algorithms.

   In an SPDng document, multiparty multimedia conferences, participants employ different
   "components" in conducting the use of an external library can conference.

      Example: In lecture multicast conferences one component might be
      declared.  The library references a profile definition and
      the
      SDPng document references voice transmission for the library.  There are two alternatives
      how external libraries can be referenced:

      by name: Referencing libraries by names implies lecturer, another the use transmission
      of a
         registration authority where definitions and reference names
         can be registered with.  It is conceivable that video pictures showing the most common
         SDPng definitions be registered that way lecturer and that there will be
         a baseline set the third the
      transmission 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) presentation material.

   Depending on system capabilities, user preferences and other
   technical and political constraints, different configurations can be
   chosen to
         declare accomplish 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 these components in a protocol engine implementing SDPng.
         Relying on this mechanism in general is also problematic
         because it impedes conference.

   Each component can be characterized at least by (a) its intended use
   (i.e.  the extensibility, as function it requires
         implementors to provide support for new extensions in their
         products before they can inter-operate.  Registration is not
         useful for spontaneous shall provide) and (b) one or experimental extensions that are
         defined in an SDPng library.

      by address: An alternative more possible
   ways to referencing libraries by name realize this function.  Each way of realizing a particular
   function is referred to
         declare the as a "configuration".

      Example: A conference component's intended use may be to make
      transparencies of an external library by providing an address,
         i.e., an URL, that specifies where a presentation visible to the library audience on the
      Mbone.  This can be obtained.
         While this allows achieved either by a video camera capturing
      the use image and transmitting a video stream via some video tool or
      by loading a copy of arbitrary third-party libraries
         that can extend the basic SDPng set slides into a distributed electronic
      white-board.  For each of configuration options in
         many ways, in introduces these cases, additional complexity that could
         result in 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 higher latency for the processing of
   previous example) or they choose the same and differ only in a description
         document with references to external libraries. single
   parameter.

      Example: In addition, case of video transmission, a JPEG-based still image
      protocol may be used, H.261 encoded CIF images could be sent, as
      could H.261 encoded QCIF images.  All three cases constitute
      different configurations.  Of course there are problems if the referenced libraries cannot be
         accessed many more detailed
      protocol parameters.

   Each component's configurations are limited 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 participating
   system's capabilities.  In addition, the different mechanisms intended use 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. a component
   may constrain the result of capability
   negotiation processes) possible configurations further to SDP documents.  In principle, this can be
   done in a rather schematic fashion subset
   suitable for the base specification and a
   set of basic profiles. particular component's purpose.

      Example: In addition, mappings a system for highly interactive audio communication
      the component responsible for audio may decide not to H.245 will use the
      available G.723.1 audio codec to avoid the additional latency but
      only use G.711.  This would be defined reflected in order to support
   applications like SIP-H.323 gateways.

4. Capability Negotiation

   SDPng is a description language for both potential this component only
      showing configurations
   (i.e.  capabilities) of participants in multimedia conferencers and
   for actual based upon G.711.  Still, multiple
      configurations (i.e.  final specifications of parameters).
   Capability negotiation is are possible, e.g.  depending on the process use of generating a usable set A-law
      or u-Law, packetization and redundancy parameters, etc.

   In modeling multimedia sessions, we distinguish two types of
   configurations:

   o  potential configurations and finally an actual configuration from a
      (a set of potential any number of configurations provided by each potential
   participant in per component) indicating a multimedia conference.

   SDPng supports
      system's functional capabilities as constrained by the specification intended
      use 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 the various components;

   o  actual configurations
      (exactly one per instance of
   commonly supported potential configurations.  In a second step, component) reflecting the
   final actual mode of
      operation of this component's particular instantiation.

      Example: The potential configuration is determined that is used of the aforementioned video
      component may indicate support for JPEG, H.261/CIF, and
      H.261/QCIF.  A particular instantiation for a
   conference.  This section specifies video conference may
      use the usage actual configuration of SDPng for capability
   negotiation.  It defines the collapsing algorithm and the procedures H.261/CIF for exchanging SDPng documents in a negotiation phase.

   The description language and video
      streams.

   In summary, the rules key terms of this model are:

   o  A multimedia session (streaming or conference) consists of one or
      more conference components for the negotiation phase that
   are defined here are (in general) independent multimedia "interaction".

   o  A component describes a particular type of the means interaction (e.g.
      audio conversation, slide presentation) that can be realized by which
   descriptions are conveyed during a negotiation phase (a reliable
   transport service with causal ordering
      means of different applications (possibly using different
      protocols).

   o  A configuration is assumed).  There are
   however properties and requirements a set of call signalling protocols parameters that
   have been considered are required to allow for
      implement a seamless integration certain variation (realization) of the
   negotiation into the call setup process.  For example, in order to be
   usable with SIP, it must be a certain
      component.  There are actual and potential configurations.

      *  Potential configurations describe possible to negotiate the conference configurations that
         are supported by an end-system.

      *  An actual configuration within the three-way-handshake is an "instantiation" of the call setup phase.
   In order to use SDPng instead one of SDP according to the offer/answer
   model defined in [16] it must be possible
         potential configurations, i.e.  a decision how to determine an realize a
         certain component.

      In less abstract words, potential configurations describe what a
      system can do ("capabilities") and actual
   configuration 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 single request/response cycle.

4.1 Outline of the Negotiation Process

   Conceptually, the negotiation process comprises
   needs to take place between the following
   individual steps (considering two parties, A and B, where A tries involved peers:

   1.  to
   invite B determine which potential configuration(s) they have in
       common, and

   2.  to a conference).  Please note that select one of this describes the steps shared set 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 common potential
       configurations for the components that
       should to be used in the conference for information exchange (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  based
       upon preferences, external constraints, etc.).

   Note that the set meaning of components
       (sdpng:c elements) in the description. term "actual configuration" is highly
   application-specific.  For each component that B
       wishes example, for audio transport using RTP, an
   actual configuration is equivalent to support a payload format (potentially
   plus format parameters), whereas for other applications it generates may be a list of potential configurations
       corresponding to B's capabilities, denoted "CAP(B)".

   3.  B applies
   MIME type.

   In SAP-based [9] session announcements on 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 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 collapsing function and obtains "CAP(AB)".  At
       this step, both A and B know actual configurations) which implicitly describe what
   a receiver must understand to participate.

   In point-to-point scenarios, the capabilities of negotiation procedure is typically
   carried out implicitly: each party informs the other about what it
   can receive and the potential configurations respective sender chooses from this set a
   configuration that both it can support.

   6.  In order to obtain an actual configuration from transmit.

   Capability negotiation must not only work for 2-party conferences but
   is also required for multi-party conferences.  Especially for the potential
       configuration
   latter case it is required that has been obtained, both particpants have the process to
       pick a determine the subset
   of the allowable potential configurations that should
       actually is deterministic to reduce the
   number of required round trips before a session can be used established.
   For instance, in the conference and generate the actual
       configuration.  It should order to be noted that it depends on used with SIP, the
       specific application whether each component must be assigned
       exactly one actual configuration (one sdpng:alt element) or
       whether it capability
   negotiation is allowed required to list multiple actual configurations.  In
       this work with the offer/answer model we assume that A selects the actual configuration,
       denoted CFG(AB).

   7.  A augments CFG(AB) is
   for session initiation with SIP -- limiting 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) negotiation to A.

   8.  B receives CFG_T(A) and adds its own transport parameters,
       resulting in CFG_T(AB).  CFG_T(AB) contains
   exactly one round trip.

   The requirements for the selected SDPng specification, subdivided into general
   requirements and requirements for session descriptions, potential and
   actual configurations and as well as negotiation rules, are captured in a
   companion document [1].

   The following list explains some terms used in this document:

   Actual Configuration
      An actual configuration is an "instantiation" of one of the transport parameters
      potential configurations, i.e.  a decision how to realize a
      certain component.

   Component
      A component describes a particular type of both interaction (e.g.
      audio conversation, slide presentation) that can be realized by
      means of different applications (possibly using different
      protocols).

   Library
      A and B (plus
       any other SDPng data, e.g., meta-information on the conference).
       CFG_T(AB) library is a application specific collection of potential
      configuration definition.  For example, the complete conference description.  Both A RTP-AVP library would
      include definitions for the audio and B
       now have video codecs of the following information:

       CAP(A) A's supported RTP
      audio/video profile (AVP).

   Package
      A package is application specific data schema for expressing
      potential and actual configurations.  For example, an audio
      package specifies the data schema for audio codecs.

   Potential Configuration
      Potential configurations

       CAP(B) B's describe possible configurations that are
      supported by an end-system ("capabilities").

3. Capability Negotiation: Overview and Requirements

   SDPng is a description language for both potential configurations

       CAP(AB) The
   (i.e.  capabilities) of participants in multimedia conferences and
   for actual configurations (i.e.  final specifications of parameters).
   Capability negotiation is the process of generating a usable set of
   potential configurations supported by both A and B.

       CFG(AB) The finally an actual configuration from a
   set of actual potential configurations to be used.

       CFG_T(AB) The 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 configurations to be configuration is determined that is used augmented
          with all required parameters.

   In this model, for a
   conference.  This section specifies the usage of SDPng for capability negotiation
   negotiation.  It defines the collapsing algorithm and configuration exchange
   process leads to the procedures
   for exchanging SDPng documents in a negotiation phase.

   The description language and the rules for the negotiation phase that represents a global view
   are defined here are (in general) independent of the
   configuration 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 signaling protocols that should
   have been considered to allow for a seamless integration of the
   negotiation into the call setup process.  For example, in order to be used.  This means,
   usable with SIP, it contains must be possible to negotiate the
   complete conference
   configuration for all participants including per-participant
   information like transport parameters.

   Note that within the two-way-handshake of the call setup phase.
   In order to use SDPng instead of SDP according to the offer/answer
   model presented here results defined in four SDPng exchanges.
   As an optimization, this procedure can [16] it must be abbreviated possible to two
   exchanges by including the transport (and other) parameters into determine an actual
   configuration in a single request/response cycle.

3.1 Outline of the
   potential configurations.  A embeds its desired transport parameters
   into Negotiation Process

   Conceptually, the list of potential configurations and B also sends all
   required parameters in negotiation process comprises the response together with B's potential
   configurations.  Both following
   individual steps (considering two parties, A and B, where A tries to
   invite 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 conference).  Please note that this document.

4.2 The Collapsing Algorithm

   The following procedure MUST be used for describes the collapsing steps
   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 negotiation process conceptually -- it does not specify
   requirements for implementations.  Specific procedures that there is no MUST be
   followed by implementations are given below.

   1.  A determines its potential configuration and configurations for the component components that
       should not be used in the
   conference.

   Let cfg_AB be the result configuration element, initialized conference (e.g.  "interactive audio" and
       "shared whiteboard") and sends a corresponding SDPng instance to an
   empty sdpng:cfg element.

   1.  For each component
       B.  This SDPng instances is denoted "CAP(A)".

   2.  B receives A's SDPng instance and analyzes the set of components
       (sdpng:c element) elements) in CAP(A) named c_A

       *  Let c_AB be the current result component, initialized to an
          empty sdpng:c element.

       * description.  For each alternative (sdpng:alt element) in c_A named a_A

          +  For 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 session element (name depends on other and
       the profile being
             used) in a_A named s_A

             -  Resolve any reference potential configurations that both can support.

   6.  In order to definition elements recursively
                and obtain s1_A, an actual configuration from the standalone media session
                description.  (Refer potential
       configuration that has been obtained, both participants have to Section 4.2.1 for
       pick a description subset of how to resolve references.)
             -  Locate the component element potential configurations that matches c_A in CAP(B)
                named (c_B).

             -  Let a_AB should
       actually 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) used in a_B named s_B

                   *  Let s1_AB be the computed result media session
                      configuration.

                   *  Resolve any reference to definition elements
                      recursively conference and obtain s1_B, the standalone media
                      session description.

                   *  Apply collapse(s1_A,s2_B) to compute s1_AB, generate the
                      collapsed media session actual
       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  It should be resolved.  For resolving references, noted that it depends on the
   algorithm specified in Section 3.3 MUST
       specific application whether each component must be used.

   By resolving all references two intermediate session assigned
       exactly one actual configuration
   elements are obtained (one sdpng:alt element) or
       whether it is allowed to list multiple actual configurations.  In
       this model we assume that can then be collapsed according 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 the
   algorithm specified 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 following sections.

4.2.1.1 Collapsing of Attributes

   In SDPng, capabilities are specified in attributs of XML elements.
   Three different types of capabilities with different collapsing rules
   are defined.  The type of a capability is encoded in selected actual
       configurations and the attribute
   value.

   Set of symbols:
      An attribute can specify a set transport parameters of symbols.  When two attributes
      are collapsed, both A and B (plus
       any other SDPng data, e.g., meta-information on the result conference).
       CFG_T(AB) 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 complete conference description.  Both A and B are collapsed:

   		      Element x in
       now have the following information:

       CAP(A) A's capability description:
   		      <x a="[FOO, BAR, 3, 5, 8]"/>

   		      Element x in supported potential configurations

       CAP(B) B's capability description:
   		      <x a="[3, 6, 8]"/>

   		      Result:
   		      <x a="[3, 8]"/>

      If the intersection result in an empty supported potential configurations

       CAP(AB) The set the collapsing process
      has failed of potential configurations supported by both A
          and there is no common B.

       CFG(AB) The set of values.  If the
      collapsing of one actual configurations to be used.

       CFG_T(AB) The set of an element's attributes actual configurations to be used augmented
          with all required parameters.

   In this model, the type "set of
      symbols" has failed, the collapsing capability negotiation and configuration exchange
   process leads to a description that represents a global view of the element itself
      MUST
   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 messages.
   As an optimization, this procedure can be considered abbreviated to have failed as well.

   Numerical ranges:
      An attribute can also specify a numercial range.  When two
      attributes are collapsed the result is
   exchanges by including the range of values that
      represents transport (and other) parameters into the intersection of
   potential configurations.  A embeds its desired transport parameters
   into the set list of values that is included potential configurations and B also sends all
   required parameters in both ranges.

      The following examples shows how two elements (with one attribute
      representing a numerical range) originated from two capability
      descriptions from participants the response together with B's potential
   configurations.  Both A and B can then derive CFG_T(AB).  Transport
   parameters are collapsed:

   		      Element x in A's capability description:
   		      <x a="(2,8)"/>

   		      Element x usually not negotiable, therefor they have to be
   distinguished from other configuration information.

   Specific procedures for re-negotiation and multi-party negotiation
   will be defined in B's capability description:
   		      <x a="(5,10)"/>

   		      Result:
   		      <x a="(5,8)"/>

      A numerical range is represented by a tuple future version of comma-separated
      numbers in brackets. this document.

3.2 The first number represents the lower bound
      of the range Negotiation Process

   The algorithm for comparing two potential configurations and the second number represents the upper bound.
      Let MIN(a,b) be for
   obtaining a function that returns the minimum of commonly supported subset is application specific.  For
   some limited application scenarios, a and b and
      MAX(a,b) application specific
   offer/answer process may be employed such as the SDP offer/answer
   model [16].

   More advanced implementations require a function generic capability
   negotiation mechanism that returns the maximum allows for application-independent
   negotiation 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 potential configuration with a smaller second value,
      the range is invalid and the collapsing has failed since there is
      no common range.  If the collapsing parameters from different
   application domains.  Capability negotiation frameworks such as RFC
   2533 [18] can be employed for this purpose.  In a future version of one
   this document, we will discuss of an element's
      attributes with the type "numerical range" has failed, the
      collapsing employing a RFC 2533 based
   negotiation process of for comparing and matching capability
   descriptions in SDPng documents.

4. SDPng

   This section introduces the element itself MUST be considered to
      have failed as well.

   Optional parameters:
      A failure underlying concepts of collapsing attributes the Session
   Description Protocol - next generation (SDPng).  The focus of this
   section is on the types "set concepts of symbols"
      and "numerical range" results in the capability description language
   with a failure stepwise introduction of collapsing the
      corresponding element.  There is a third type named "optional
      parameter" defined, various syntactical elements.
   Note that this section only provides different collapsing rules.  An
      optional parameter is an attribute with an arbitrary value.  When
      collapsing two attributes of examples accompanied by
   explanations.  The description elements used in this type, their values MUST be
      tested for equality.  If they section are equal, the collapsing has been
      successful not
   normative.

4.1 Conceptual Outline

   In Section 2 we have distinguished between potential configurations
   ("capabilities") and actual configurations ("session descriptions").
   SDPng provides the attribute MUST appear as is possibility to express potential configurations
   and actual configurations in the result
      description.  If the attributes' values are different, the
      collapsing one document.  A potential configuration
   list is considered used to have failed declare capabilities and the attribute MUST not
      appear in the result description.  However, a failure in
      collapsing an attribute actual configuration list
   is used to declare concrete configurations.

   Potential configurations are described independently of type "optional parameter" does not
      affect the collapsing actual
   configurations.  In a "potential configurations" section, a user
   agent lists its capabilities as a list of named definitions.  For
   negotiating capabilities from different user agents, the containing element.

      An example for a successful collapsing:

   		      Element x individual
   definitions are matched in A's capability description:
   		      <x a="foo"/>

   		      Element x order to determine a commonly supported
   subset of capabilities.  The data schema for potential configurations
   is defined in B's capability description:
   		      <x a="foo"/>

   		      Result:
   		      <x a="foo"/> "package definitions".  An example for an unsuccessful collapsing:

   		      Element x in A's capability description:
   		      <x a="foo"/>

   		      Element x in B's capability description:
   		      <x a="bar"/>

   		      Result:
   		      <x/>

4.2.1.2 Collapsing two Elements

   In order to collapse two elements with multiple attributes, the
   following algorithm specified below MUST be applied.  In general, the
   collapsing element of two elements (if successful) yields a result element
   that contains the collapsed attributes.  If
   potential configuration would be the collapsing definition of two
   elements has failed, no result element is generated.

   1.  For each attribute, determine the type a supported audio
   codec.

   Actual configurations can refer to capabilities and collapse the attribute
       by applying the algorithm specify concrete
   parameters for application protocol sessions, including transport
   parameters.  Actual configurations cannot be negotiated.

   When defining potential configurations, capabilities are never
   expressed with respect to other potential configuration elements,
   e.g., the corresponding attribute type.

   2.  If definition of an attribute with a different type than "optional parameter" audio codec capability does not occur in both elements, the collapsing for this element
       MUST be considered to have failed.

   3.  If limit the collapsing
   capability of any attribute with a different type than
       "optional parameter" has failed, using other audio codec.  Constraints like the collapsing
   simultaneous usage of the element
       itself MUST capabilities can be considered to have failed.

   4.  If expressed separately from
   the collapsing has been successful, obtain capabilities themselves.

   In addition, information about the result element
       by using communication session itself, such
   as scheduling, information on the same element name (GI) semantics of application protocol
   sessions and information on the attributes with their
       collapsed values.  Exclude any attribute of type "optional
       parameter" that user who has failed to collapse.

   An example:

   		  Element x initiated a conference.
   This information is expressed separately from the definition of
   potential and actual configurations.

   These different elements of session description are discussed in A's capability description:
   		  <x a="[FOO, BAR, 3, 5, 8]" b="(2,8)" c="foo"/>

   		  Element x
   detail in the following sections.  There are four different elements:

      Potential Configurations; see Section 4.1.1.

      Actual Configurations; see Section 4.1.2.

      Constraints; see Section 4.1.3.

      Session meta information; see Section 4.1.4.

4.1.1 Potential Configurations

   A "Potential Configurations" section in B's capability description:
   		  <x a="[3, 6, 8]" b="(5,10)" c="bar"/>

   		  Result:
   		  <x a="[3, 8]" b="(5,8)"/>

4.2.1.3 Collapsing nested Elements an SDPng document lists
   individual capabilities, e.g., codec capabilities.  In order to collapse nested elements the following algorithm MUST a capability
   negotiation process these potential configurations may be
   applied:

   In analogy to attributes representing optional parameters there is
   also the possibility compared to mark elements as optional for
   the negotiation
   process.  Elements MAY provide an attribute named "status" potential configurations that
   contains a symbol or a comma-separated list are defined in an SDPng document
   from another participant.  The outline of symbols as its value.
   If the value "opt" occurs such a negotiation process
   is presented in Section 3.

   Please note, that in the list of following examples, we use a "status" attribute of both
   elements straw-man
   syntax in order to be collapsed, discuss the concepts.  A final syntax will be
   formally defined in a future version of this document.

   These are two examples of elements to in a potential configurations
   section:

                 audio:codec
                   name=audio-basic
                   encoding="PCMU"
                   sampling="8000"
                   channels="[1]"

                 audio:codec
                   name="audio-L16-mono"
                   encoding="L16"
                   sampling="44100"
                   channels="[1,2,4]"

   The following requirements can be collapsed MUST stated for expressing potential
   configurations:

   o  It must be
   treated as optional.  This means, if the collapsing of the attributes
   has failed (according possible to name potential configuration elements.  In
      the rules specified in Section 4.2.1.2), example above, this is achieved by the
   collapsing process property "name".  Names
      MUST NOT not yield a result element but MUST still be treated as "successful", i.e., further collapsing operation on
   other elements can continue. considered in a capability negotiation process.

   o  The semantics of optional potential configuration elements are
   that they describe optional features that may be supported and
   selected during a negotiation phase but do not neccessarily have referred to
   be supported by all participants this name
      for specifying actual configurations.  It MUST be ensured that
      names that originate from different description documents reside
      in separate namespaces in order to achieve
   interoperability.  The example below shows how to generate avoid collisions.

   o  The properties of a result given potential configuration element in the presence of optional child elements that MUST
      have failed
   to collapse.

   The collapsing algorithm a well-defined type.  For example, codec type names are
      expressed as strings, and for nested elements:

   1.  Let x be an element that occurs in the capability description of negotiation, two participants codec
      names can be processed by applying a string comparison.  A and B and that should maximum
      frame-rate would 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 expressed as a number that represents an upper
      limit, and if for capability negotiation, the elements to minimum of two numbers
      would be collapsed are not marked used as optional, the collapsing of a commonly supported value for the
       element and all of its children frame-rate.

   o  User agents MUST be considered able to have
       failed.  The collapsing MUST be stopped.  If infer the collapsing has
       failed and both elements have been marked as optional, type of a given property
      without referring to an external schema definition, i.e., the child
       elements MUST NOT type
      must be processed.  In this case, specified either implicitly or explicitly.  Note, that in
      the collapsing
       process does example above, the type is not yield a result element but specified.

   o  In addition to the collapsing of data type and its value a property can provide
      other elements (sibling or parent elements) MUST characteristics: Some properties that a package definition
      defines for a certain application are mandatory, i.e., they must
      be continued.

   3.  If specified in configuration descriptions.  In the collapsing has been successful according example above,
      this would apply to the rules of
       Section 4.2.1.2, encoding, the child elements sampling-rate and the number
      of A's channels.  For this single potential configuration elements
      these properties serve as constraints for a negotiation: The
      capability description matches only those description from other
      participants that provide the same encoding, the same sampling-
      rate and B's x element MUST
       be processed. either 1,2 or 4 channels.  If there are no child elements in both A's and B's
       content a description did not
      provide one of these properties, the collapsing has been successful and negotiation would fail.
      There are however properties that can represent optional
      parameters, such as a codec parameter that can optionally be terminated. used.
      If either A's or B's x element provides child elements, apply the
       following algorithm to each child element named c of one participant
       A's element x:

       1.  Find specified such a corresponding element (same GI) in the set of property and another
      participant B's child elements.  If no matching element has
           been found, did not, we would expect the collapsing resulting configuration
      to not include that property, however, the negotiation itself
      should be successful.

   o  Some capabilities such as codec capabilities may be associated
      with additional constraints, e.g., the directionality of element x MUST media
      streams ('send-only', 'receive-only').  It will be considered to
           have failed.

       2.  If defined in a matching element has been found, apply
      future version of this document whether the collapsing
           algorithm recursively.  As long directionality is
      specified as the collapsing a capability (in a potential configuration) or
      whether it is
           successful, the result rather specified as an attribute of collapsing each element is
           transferred an actual
      configuration.

   With these requirements in mind, we add additional characteristics to
   the result element, such that properties in potential configuration descriptions (and change
   the resulting
           element tree is isomorphic to both A's and B's element tree.

       If there are elements encoding for the second potential configuration element):

                 audio:codec
                   name=audio-basic;type=name
                   encoding="PCMU";type=string
                   sampling="8000";type=maximum-limit
                   channels="[1]";type=set
                   featureX="200";type=maximum-limit;optional

                 audio:codec
                   name="audio-PCMU-44khz";type=name
                   encoding="PCMU";type=string
                   sampling="44100";type=maximum-limit
                   channels="[1,2,4]";type=set
                   featureY="200";type=string;optional

   Note again, that these descriptions merely present examples in B's x element order
   to present the data model that have not been
       processed (because there we use for potential configurations --
   this is no corresponding element in A's x
       element), not the collapsing MUST be considered to SDPng syntax.  In these examples, we have failed added the
   optional features 'featureX' and
       MUST be stopped.

   An example:

   		  Element x in A's capability description:
   		  <x a="[FOO, BAR, 3, 5, 8]" b="(2,8)" c="foo">
   		    <y b="[UVW, XYZ]"/>
   		  </a>

   		  Element x in B's capability description:
   		  <x a="[3, 6, 8]" b="(5,10)" c="bar">
    		    <y b="[RST, XYZ]"/>
   		  </a>

   		  Result:
   		  <x a="[3, 8]" b="(5,8)">
    		    <y b="[XYZ]"/>
   		  </a>

   An example 'featureY'.

   If we assume, that the two potential configurations are contributions
   from different participants for collapsing optional elements:

   		  Element x in A's capability description:
   		  <x a="[FOO, BAR, 3, 5, 8]" b="(2,8)" c="foo">
   		    <y status="opt" b="[UVW, XYZ]"/>
   		  </a>

   		  Element x in B's capability description:
   		  <x a="[3, 6, 8]" b="(5,10)" c="bar">
    		    <y status="opt" b="[RST]"/>
   		  </a>

   		  Result:
   		  <x a="[3, 8]" b="(5,8)"/>

4.2.2 Deriving an actual Configuration

   The result of a capability negotiation process is negotiation, a resulting
   potential configuration, i.e., after a description potentially containing multiple
   alternatives per component. negotiation process as outlined in
   Section 3, could look like this:

                 audio:codec
                   encoding="PCMU";type=string
                   sampling="8000";type=maximum-limit
                   channels="[1]";type=set

   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 name cannot be selected.  It is conceivable that
       the order of considered for a capability negotiation, the alternatives in
   optional properties 'featureX' and 'featureY' have only been provided
   by one participant each and the description is used as a
       preference indicator.  More details other properties have to been processed
   by the negotiation algorithms (that will be specified in a future
   version of this document.

   2.  If document in Section 3).

   So far, we have only considered codec capabilities.  Other
   capabilities would include transport mechanisms, e.g., RTP/UDP/IPv4:

                 rtp-udp:transport
                   name="rtp-udp-ipv4";type=name
                   network="IP4;type=string

4.1.2 Actual Configurations

   The "Actual Configurations" section lists all the description of components that
   constitute the selected alternatives contains
       attributes with numerical ranges or sets multimedia application (IP telephone call, real-time
   streaming application, multi-player gaming session etc.).  For each
   of symbols with more
       than one entry, those attributes either have these components, the actual configurations are given.  Potential
   configurations are used during capability exchange and/or
   negotiation, actual configurations to be transformed
       that they represent a single value configure media streams after
   negotiation (e.g.  with RTSP) or participants have to agree
       that in session announcements (e.g.  via
   SAP).

   Each component is labeled with an actual configuration may contain ranges and sets of
       symbols.  The identifier so that it can be
   referenced, e.g.  to associate semantics with a particular media
   stream.  For such a component, any number of these variable actual configurations
       will have
   may be given with each configuration describing an alternative way to specified in later versions
   realize the functionality of the respective component.

   The semantics of this document. are application dependent.  For example, for certain
   SIP applications it may be desireable to agree
       on ranges of values using the SDP offer/answer model, providing multiple
   alternatives for certain attributes during a capability
       negotiating meaning component (a media type in SDP) means that the
   offerer is prepared to receive at any of the values specified addresses any
   of the range are
       supported (and have specified payload formats (for RTP applications).  In this
   example, the order of alternatives is used to be supported). specify a preference,
   i.e., the first alternative is the most preferred one.

   The specific procedures to determine an actual configuration have to
   be defined in following example provides two alternative configurations for a later version on this document.

5. Formal Specification

   This section defines
   component named "interactive-audio".  Each alternative refers to the SDPng syntax
   RTP-transport capability named "rtp-udp-ipv4" and to an audio-codec
   capability.

                 component
                   name="interactive-audio"
                   alt
                     name="AVP-audio-0"
                     rtp-udp:transport
                       ref="rtp-udp-ipv4"
                       pt="96"
                       direction="send-receive"
                       addr="224.2.0.53"
                       rtp-port="7800"
                       rtcp-port="7801"
                     audio-codec
                       ref="audio-basic"

                   alt
                     name="AVP-audio-11"
                       rtp-udp:transport
                       ref="rtp-udp-ipv4"
                       pt="97"
                       direction="send-receive"
                       addr="224.2.0.53"
                       rtp-port="7800"
                       rtcp-port="7801"
                     audio-codec
                       ref="audio-L16-stereo"

   For the use of XML mechanisms, RTP transport configuration, additional required parameters
   are provided, 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 payload type number to be used (pt="97"),
   the SDPng schema, Section 5.3 list requirements for
   profile definitions, Section 5.4 specifies specific requirements for
   conforming documents IP address and Section 5.5 lists requirements UDP port numbers for RTP and RTCP and the
   definition of SDPng libraries.

   Section 5.7 defines
   directionality.

   Note that in the example above, the SDPng base schema, Appendix A.1 defines actual configuration of the
   profile RTP
   transport is identical for audio codec definitions and Appendix B defines both alternatives -- with the exception of
   the
   profile for RTP payload type definitions.

5.1 XML Schema as number.  In a Definition Mechanism

   SDPng documents reference profile schema definitions and libraries.
   Profile schema definitions contain schema definitions final solution, this duplication
   should be avoided by another level of SDPng
   document elements.  For example, the general structure is specified indirection, i.e., by a schema definition defining
   these parameters once and extensions referencing this definition where needed.

   In order to SDPng determine the usable actual configurations after a
   capability negotiation, a user agent has to traverse the references
   in actual configurations to potential configurations and check
   whether each capability is still supported after a negotiation
   process.  Only those alternatives that reference supported
   capabilities can be considered for specific
   applications implementing the given component.

   The semantics of specifying multiple alternatives for a component are specified as schema definitions as well.

   SDPng uses XML-Schema [13][14]
   application specific -- for defining RTP configurations in SDP it means that
   the possible logical
   structures endpoint is willing to receive any of SDPng documents for the following reasons:

   Extensibility: XML-Schema provides mechanisms specified formats
   without further out-of-band signaling and that allow to extend
      existing definitions allowing the first
   configuration is preferred.

4.1.3 Constraints

   Potential configurations are media, transport, and other
   capabilities, whereas configurations indicate which combinations of
   these could be used to uniquely identify element types
      (by relying on XML namespaces [11]).

   Modularity: XML-Schema provide mechanisms that allow to organize
      schema definitions the desired functionality in multiple components.

   Expressiveness: XML-Schema provides many data types, a certain
   setting.

   There may, however, be further constraints within a system (such as
   CPU cycles, DSP resources available, dedicated hardware, etc.) that
   limit which of these configurations can be
      refined by user-supplied definitions.

   SDPng documents MUST be schema instantiated in parallel
   (and how many instances of these may exist).  We deliberately do not
   couple this aspect of system resource limitations to the SDPng schema various
   application semantics as
   defined the constraints may exist across application
   boundaries.  Also, in Section 5.7.  The following example shows how a Schema
   definition many cases, expressing such constraints is
   simply not necessary (as many uses of the current SDP show), so
   additional overhead can be referenced avoided where this is not needed.

   The usage of constraints will be specified in a document instance.

   Beginning future version of an SDPng-document:

   <?xml version="1.0" ?>
   <sdpng:desc xmlns="http://www.iana.org/sdpng"
   	    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   	    xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd">

   XML-Schema specifies that documents can assign a namespace when
   referencing a schema definition.  A SDPng namespace is defined for
   this purpose. document.

4.1.4 Meta Information

   The name fourth and final section of this namespace is
   "http://www.iana.org/sdpng". an SDPng documents MUST use this namespace description is used to
   specify meta information such as their default namespace.

   For SDPng documents, this initial declaration can be added implicitly session layer attributes.  These
   attributes largely include those defined by applications, so that declarations like SDP [RFC2327] (which are
   explicitly indicated in the one above do not have 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
   relevant information can be included specified directly in every description document. the Configuration
   section for individual alternatives.

   The section for meta information will provide for integrating and re-
   using existing meta-information frameworks such as MPEG-7.  Details are to
   will be
   defined specified in a later future 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

4.2 Syntax Definition Mechanisms

   In this section, we specify the elements syntax definition mechanisms for definitions, configurations,
   constraints
   SDPng.

   In order to allow for the possibility to validate session
   descriptions and conference information in exactly this order, whereby
   only the configurations section is MANDATORY.  Refer order to Section 5.7 allow for a formal definition of the structured extensibility,
   SDPng base schema relies on a syntax framework that provides concepts as well as
   concrete procedures for document validation and extending the specific
   element types set of
   allowed syntax elements.

   SGML/XML technologies allow for definitions, configurations, constraints and
   conference information.

   The SDPng base schema also specifies "abstract" base data types (by
   means the creation of XML-Schema type definitions) Document Type
   Definitions (DTDs) that can define the allowed content models for the
   elements that MUST of conforming documents.  Documents can be used 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 documents in third-party definition packages without creating the corresponding sections.  The base data types
   provide common required attributes, e.g.
   possibility of name collisions.

   For SDPng, a "name" attribute 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
   naming definition elements.

   Example:
   The following
   example shows the definition of the base type elements and attributes for
   definition elements:

   <xsd:complexType name="Definition" abstract="true" mixed="false">
   <xsd:attribute name="name" type="xsd:string"/>
   </xsd:complexType>

   Profiles can then define specific new transport mechanisms, new
   media types etc.  to be added on demand.  Still, it has to be ensured
   that augment the base type
   definitions.  Common attributes or content models, that have been
   defined by this base definition, extensions do not have to be provided by those
   specific type definitions.  The type definitions can result in name collisions.  Furthermore, it
   must be identified as
   allowed element types possible for the content models applications that are specified in
   the process descriptions documents
   to distinguish extensions from base SDPng schema definition.  This allows definitions.

   For XML, mechanisms have been defined that allow for automatic
   validation structured
   extensibility of profile definitions document schemata: XML Namespace and facilitates XML Schema.

   XML Schema mechanisms allow to constrain the extension of
   SDPng.

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 allowed document
   content, e.g.  for IP
   (and other) addresses.

   A profile definition MUST import (using the XML-Schema import
   mechanism) the base SDPng schema definition documents that contain structured data 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, possibility that are
   registered by vendors providing a profile.

   Example:
   The following example shows such a declaration document instances can conform to
   several XML Schema definitions at the beginning 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
   profile definition:

   <xsd:schema targetNamespace="http://www.iana.org/sdpng/audio"
   	    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   	    xmlns:sdpng="http://www.iana.org/sdpng"
   	    xmlns:audio="http://www.iana.org/sdpng/audio">

     <xsd:import namespace="http://www.iana.org/sdpng"
                 schemaLocation="sdpng.xsd"/>

   In this example, new media type, would require the namespace prefix "audio" is defined and later
   used in
   creation of a corresponding XML 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, that contains the abstract type "Definition" (fully qualified as
   "sdpng:Definition") is augmented by three attributes
   specification of element types that are useful
   for defining audio codecs.

   Example:

   <xsd:complexType name="AudioCodec" mixed="false">
     <xsd:complexContent>
       <xsd:extension base="sdpng:Definition">
        <xsd:attribute name="encoding" type="xsd:string"/>
        <xsd:attribute name="sampling" type="xsd:positiveInteger"/>
        <xsd:attribute name="channels" type="xsd:positiveInteger"/>
       </xsd:extension>
      </xsd:complexContent>
   </xsd:complexType>

   This type definition is then can be used to define an XML element type
   called "codec".

   Example:

   	    <xsd:element name="codec" type="AudioCodec"/>

   When used by SDPng documents, the general identifier is qualified
   with a namespace prefix, describe
   configurations of components for example as in: "audio:codec".

5.4 SDPng Documents

   SDPng the new media type.  Session
   description documents MUST have to reference the employed profiles extension Schema module,
   thus enabling parsers and provide
   namespace prefixes for validators to identify the namespace names elements of the profiles as shown
   in the following example.

   Example:

   <sdpng:desc xmlns="http://www.iana.org/sdpng"
   	    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   	    xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd"
   	    xmlns:audio="http://www.iana.org/sdpng/audio"
   	    xmlns:rtp="http://www.iana.org/sdpng/rtp">

   For well-known registered profiles,
   new extension module and to either ignore them (if they are not
   supported) or to consider them for processing the namespace name AND session/capability
   description.

   It is important to note that the used
   namespace prefix SHOULD functionality of validating
   capability and session description documents is not necessarily
   required to generate or process them.  For example, endpoints would
   be registered configured to allow for simple basic
   implementations understand only those parts of description documents
   that can match identifiers by using fixed fully
   qualified names without having are conforming to interpret namespace declarations
   (see Section 5.6.3).  There is one issue with declaring used XML- the baseline specification and simply ignore
   extensions they cannot support.  The usage of XML and XML Schema definitions is
   thus rather motivated by the need to allow for extensions being
   defined and added to the language in documents (see Section 6 below). a structured way that does not
   preclude the possibility to have applications to identify and process
   the extensions elements they might support.  The general structure baseline
   specification of an SDPng documents MUST conform XML Schema definitions and packages must be well-
   defined and targeted to the basic
   SDPng schema definition and MAY provide a "def" element for
   definitions; it MUST provide a "cfg" element set of parameters that are relevant for
   the configuration
   section; it MAY provide a "constraints" protocols and a "conf" element.

   Example:
   The following example shows a sample definition section where the
   element "codec" algorithms of the "audio codec profile" is used (plus Internet Multimedia Conferencing
   Architecture, i.e.  transport over RTP/UDP/IP, the
   element type "pt" audio video
   profile of RFC1890 etc.

   Section 4.4 describes package definitions and library definition.

4.3 Referencing Definitions

   SDPng provides a referencing concept for definitions.  For example,
   in the specification of an "RTP profile"):

       <def>
         <audio:codec name="dvi4" encoding="DVI4" channels="1"
   	              sampling="8000"/>
         <audio:codec name="g722" encoding="G722" channels="1"
   	              sampling="16000"/>
         <audio:codec name="g729" encoding="G729" channels="1"
   	              sampling="8000"/>

         <rtp:pt name="rtp-avp-18" pt="18">
           <audio:codec ref="g729"/>
         </rtp:pt
       </def>

   It can be seen how actual configuration, we reference the attribute name (provided by
   capabilities of the base type for
   definition elements) and potential configurations section.

   The concrete reference mechanism depends on the profile specific attributes "encoding",
   "channels" syntax in use and "sampling" are used together.

   The element "rtp:pt" is used to defined a payload type.  "rtp:pt"
   would have been defined
   will be specified in another profile, again using a type
   derived from the base definition type.  "rtp:pt" provides attribute future version of this document.

4.4 External Definition Packages

   There are two types of external definitions:

   Package Definitions (Section 4.4.1) define rules, i.e., a data
      schema, for referencing other definitions, e.g., specifying parameters that are not covered by the definition of audio-
   codes as seen before.

5.5 Libraries base
      SDPng libraries are collections of specification.

   Library Definitions (Section 4.4.2) contain definitions that are can be
      referenced by
   documents.  Libraries are thus independent, valid in SDPng documents.

4.4.1 Package 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 definition 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 different audio codecs as shown transport protocol will be specified in a definition
   document.  Such a definition document is called a "package".

   A package contains rules that specify how SDPng is used to describe
   conferences or end-system capabilities with respect to the previous example could parameters
   of the package.  The specific properties of the package definitions
   mechanism are still to be provided by defined.

   An example of such a library package would be the RTP package that can defines
   how to specify RTP parameters.  Another example would be
   referenced by documents without having the audio
   codec package that defines how specify audio codec parameters.

4.4.2 Library Definitions

   While package definitions specify the allowed parameters for a given
   profile, SDPng "Definitions" sections refer to package definitions
   and define such common codecs
   in every document.

   The XML mechanism XInclude [12] is used concrete configurations based on a specific package.

   In order for referencing libraries such definitions to be imported into SDPng documents,
   "SDPng libraries" may be defined and referenced in SDPng documents.  XInlcude works at the XML Information Set
   ("infoset") level, i.e.
   A library is a set of definitions that is conforming to one or more
   package definitions.

   The purpose of the mechanisms allows library concept is to have an integrating allow certain common
   definitions to be factored-out so that not every SDPng 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 has
   to operate on include the resulting infosets as if it had been generated by parsing a
   single, monolithic document.

   Inclusion at basic definitions, for example the XML infoset level has PCMU codec
   definition.  SDP [2] uses a similar concept by relying on the advantage well
   known static payload types (defined in RFC1890 [4]) that documents are standalone -- they can be validated independently.  Another
   advantage is that is relatively easy to generate a "merged" infoset
   for applications also
   just referenced but never defined in SDP documents.

   An SPDng document that are not able to resolve references definitions from an external
   library has to libraries
   themselves.

5.6 Details on declare the use of specific XML Mechanisms

   This section specifies the use external library.  The external
   library, being a set of specific XML mechanisms for SDPng.
   In order to allow configuration definitions for efficient parsing and processing, not all
   features of XML Schema are allowed.  Some variable information is set
   to fixed values a given
   package, again needs to allow declare the development of simplistic servers.

5.6.1 Default Namespace

   SDPng document instances MUST use of the SDPng namespace
   "http://www.iana.org/sdpng" as their default namespace.  That means,
   the general SDPng identifiers package that it is
   conforming to.  A library itself can be used without namespace prefixes.

5.6.2 Qualified Locals

   XML Schema allows make reference to specify qualification other external
   libraries.

   There are different possibilities of elements and
   attributes.  It is possible to use non-qualified element how package definitions and
   attribute names
   libraries can be used in Schema definitions SDPng documents:

   o  In an SPDng document, a package definition can be referenced and
      all the configuration definitions are provided within the document
      itself.  The SDPng document instances for so-
   called "local definitions" (this is self-contained with respect to the
      definitions it uses.

   o  In an SPDng document, the default setting).  "Local
   Definitions" are contained within "global definitions" in use of an XML
   schema definition.  In order to simplify parsing external library can be
      declared.  The library references a package definition and processing of the
      SDPng document instances, all elements MUST references the library.  There are two alternatives
      how external libraries can be fully qualified.
   Attribute referenced:

      by name: Referencing libraries by names MUST NOT be fully qualified, they are considered to
   have implies the same namespace as their corresponding elements.

   This means, use of a
         registration authority where definitions and reference names
         can be registered with.  It is conceivable that the most common
         SDPng Schema definition contains the following
   attributes for the "schema" element, definitions be registered that MUST also way and that there will be used by SDPng
   profiles:

   o  elementFormDefault="qualified"
      This means
         a baseline set of definitions that "locally defined" elements minimal implementations must
         understand.  Secondly, a registration procedure will be
         defined, that are allows vendors to register frequently used within
         definitions with a registration authority (e.g., IANA) and to
         declare the scope use of fully-qualified elements MUST always registered definition packages in conforming
         SDPng documents.  Of course, care should be fully
      qualified as well.

   o  attributeFormDefault="unqualified"
      This means that attribute names do taken not have to be fully qualified.
      Implementations MUST infer the namespace for attributes from the
      namespace of the element that make
         the attribute belongs to.  Note that 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 specification of XML Namespaces [11] defines 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 default
      namespaces do not apply to attributes.  In profile definitions,
      all attributes MUST be are
         defined locally.  The same holds for the
      base SDPng schema.

   These rules make in an SDPng document instances processable by non-Schema-
   aware XML parsers library.

      by requiring all element names address: An alternative to be fully
   qualified (no "local elements").

5.6.3 Fixed Namespace Prefixes

   In order referencing libraries by name is to facilitate
         declare 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 of an external library by providing an address,
         i.e., an URL, that are assigned to them.  In order to ensure specifies where the
   uniqueness of namespace prefixes, namespace prefixes will library can 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 obtained.
         While this allows the definition use of arbitrary third-party libraries
         that can extend the base basic SDPng XML Schema.

   1.  Section 5.7.1 contains the base definition set of configuration options in
         many ways, in introduces additional complexity that provides the
       general element types for SDPng.

   2.  Appendix A.1 contains a profile for audio codecs.

   3.  Appendix B contains a profile could
         result in in higher latency for RTP payload type definitions.

5.7.1 SDPng Base Definition

   This schema definition defines the general structure processing 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. description
         document with references to external libraries.  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
         there are "deriving problems if the referenced libraries cannot be
         accessed by extension" and "substitution groups".
   The all communication partners.

   o  Because of these problematic properties of external libraries, the
      final SDPng base definition provides specification will have to provide a set of
      recommendations under which circumstances the different base types (as
   complexType definitions) for elements mechanisms
      of referring to external definitions should be used.

4.5 Mappings

   A mapping needs to be defined in particular to SDP that are allows to
   translate final session descriptions (i.e.  the result of capability
   negotiation processes) to SDP documents.  In principle, this can be used
   done in "def",
   "cfg" a rather schematic fashion for the base specification and "conf" sections. a
   set of basic packages.

   In addition, it also defines specific
   element types as "head elements" mappings to H.245 will be defined in order to support
   applications like SIP-H.323 gateways.

5. Syntax Definition

   An SDPng description is an XML document with assigned types that are used
   for defining the content model of, e.g., the "def" element type.

   Profiles that provide new different element types
   for specific applications
   will define types that are derived from the different sections.  The SDPng base types and provide
   the additional attributes and element content definitions that are
   required syntax specification
   defines this overall document structure.

5.1 Potential Configurations

   A section for the application.  The potential configurations is an XML element types that are defined
   in can
   provide a profile are declared as valid substitutes for the base elements
   ("head elements") by setting the "substitutionGroup" attribute to the
   name list 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 child elements.  Each child element type definition
   that assigns that new type must then be declared to be represents an
   individual capability as described in the
   substitutionGroup "sdpng:definition".

   This mechanism allows common rules for attributes and content models
   to be Section 4.1.1.  Each property
   is represented by an XML attribute.  The element types are defined in base
   package definitions.  XML Namespaces are used to disambiguate element definition and re-used by extension
   profiles
   types and it also allows validating parsers to identify the
   correct type of elements that have been defined by profile
   definitions. allow for extensibility.

   Each element MUST provide an attribute "name".  The SDPng Base Definition:

   <xsd:schema targetNamespace="http://www.iana.org/sdpng"
   	    xmlns:sdpng="http://www.iana.org/sdpng"
   	    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   	    xmlns:xlink="http://www.w3.org/1999/xlink"
   	    elementFormDefault="qualified"
   	    attributeFormDefault="unqualified">

     <xsd:import namespace="http://www.w3.org/1999/xlink"
   	      schemaLocation="xlink.xsd"/>

     <xsd:annotation>
       <xsd:documentation>
         This schema definition defines the general structure value of SDPng
         document instances. It provides base type this
   attribute SHOULD be composed of a prefix (representing a namespace-
   name) and base element
         definition a unique name for elements to occur in the different sections (def,
         cfg, constraints, conf) to be derived from in extension-profile
         definitions.

         For an extension-profile corresponding capability within that provides new definition element
         types, e.g.
   namespace.  The namespace-name designates a namespace for codec definitions, the source
   of the capability definition.  If 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 prefix is specified, it MUST be in
   separated by a colon (':') from the substitutionGroup "sdpng:definition".
       </xsd:documentation>
     </xsd:annotation>

     <xsd:element name="desc">
       <xsd:annotation>
         <xsd:documentation>
   	The top-level name.

   Each element of an SDPng document. It defines represents a "feature set" (using the
   	overall structure terminology of
   [18]).  Therefore, each attribute can provide a "range" of values --
   not only a single value.  For example, an SPDng document.
         </xsd:documentation>
       </xsd:annotation>
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:def" minOccurs="0"/>
   	<xsd:element ref="sdpng:cfg"/>
   	<xsd:element ref="sdpng:constraints" minOccurs="0"/>
   	<xsd:element ref="sdpng:conf" minOccurs="0"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:element name="def">
       <xsd:annotation>
         <xsd:documentation>The definitions section</xsd:documentation>
       </xsd:annotation>
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:element name="cfg">
       <xsd:annotation>
         <xsd:documentation>The configurations section</xsd:documentation>
       </xsd:annotation>
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:component" maxOccurs="unbounded"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:element name="constraints">
       <xsd:annotation>
         <xsd:documentation>The constraints section</xsd:documentation>
       </xsd:annotation>
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:constraint" maxOccurs="unbounded"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:element name="conf" type="sdpng:Conference">
       <xsd:annotation>
         <xsd:documentation>The conference section</xsd:documentation>
       </xsd:annotation>
     </xsd:element>

   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:element name="definition" type="sdpng:Definition">
       <xsd:annotation>
         <xsd:documentation>
   	Placeholder base element attribute can specify a set
   of supported alternative values for a definition element in the
   	definitions section. To be derived from by specific definition
   	element type definitions.
         </xsd:documentation>
       </xsd:annotation>
     </xsd:element>

   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:element name="component" type="sdpng:Component">
       <xsd:annotation>
         <xsd:documentation>
   	The configuration element in given property, e.g., for the configurations section.
         </xsd:documentation>
       </xsd:annotation>
     </xsd:element>

   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:element name="constraint" type="sdpng:Constraint">
       <xsd:annotation>
         <xsd:documentation>
   	Placeholder base element
   sampling rate of an audio codec.  SDPng provides two different ways
   for representing "value ranges": An attribute can specify a set of
   tokens or a numerical range.

   Each property that is represented by an XML attribute has a contraint element well-
   defined type that is specified in the
   	contraints section. To be derived from by specific constraint
   	element type definitions.
         </xsd:documentation>
       </xsd:annotation>
     </xsd:element>
   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:complexType name="Definition" abstract="true" mixed="false">
       <xsd:annotation>
         <xsd:documentation> package definition.  The base type for definition. Defines a
   is encoded implicitly in the attribute "name" for
   	naming definitions. value (similar to the syntax
   in RFC 2533 [18]).  The following types are distinguished:

   Text strings, tokens
      An attribute 'name' MUST be used may provide a token (a symbolic name), e.g., for
   	specifying a name in
      codec name.
      An example for a definiton. The attribute 'ref' corresponding attribute:

   		  encoding="PCMU"

      Token MUST be
   	used for referencing a previously defined definition.
         </xsd:documentation>
       </xsd:annotation>
       <xsd:attribute name="name" type="xsd:string" use="optional"/>
       <xsd:attribute name="ref" type="xsd:string" use="optional"/>
     </xsd:complexType>

   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:complexType name="Component" mixed="false">
       <xsd:annotation>
         <xsd:documentation>  directly embedded into the attribute content, i.e.,
      the token is the attribute value.
      The specification complete formal syntax definition of tokens will be provided
      in a component consists later version of this document.

   Token sets
      An attribute can specify a set of tokens (representing a sequence list of
   	alternatives.
         </xsd:documentation>
       </xsd:annotation>
       <xsd:sequence>
         <xsd:element ref="sdpng:alt" minOccurs="1" maxOccurs="unbounded"/>
       </xsd:sequence>
       <xsd:attribute name="name" type="xsd:string"/>
       <xsd:attribute name="media" type="xsd:string"/>
     </xsd:complexType>

     <xsd:element name="alt">
       <xsd:annotation>
         <xsd:documentation>
   	Each
      alternative consists of values for a "sessionConfig" (session
   	configuration) element. The "sessionConfig" element is certain property).
      An example for a base
   	element corresponding attribute:

   		  sampling="[8000,16000,44100]"

      A token set MUST be specified as a list of base type "sdpng:Session" tokens that is used to derive
   	specific session types in extension profiles.
         </xsd:documentation>
       </xsd:annotation>
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:sessionConfig" minOccurs="1" maxOccurs="1"/>
         </xsd:sequence>
         <xsd:attribute name="name" type="xsd:string"/>
       </xsd:complexType>
     </xsd:element>
     <xsd:element name="sessionConfig" type="sdpng:SessionConfig"/>

     <xsd:complexType name="SessionConfig" abstract="true" mixed="false">
       <xsd:annotation>
         <xsd:documentation> are
      separated by commas (',') and are enclosed by square brackets
      ('[',']').
      The (abstract) base type complete formal syntax definition of token sets will be
      provided in a later version of this document.

   Numbers and Numerical ranges
      An attribute can specify a number or a range (minimum and maximum)
      for session elements. To numbers.
      An example for an attribute specifying a number:

   		  bitrate="(64)"

      A number MUST be derived
   	from specified as a literal value in extension profiles.
         </xsd:documentation>
       </xsd:annotation>
     </xsd:complexType>

   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:complexType name="Constraint" mixed="false">
       <xsd:annotation>
         <xsd:documentation>
   	The current content model brackets ('(',
      ')').
      An example for constraints is an attribute specifying a sequence of
   	"sdpng:par" elements. In each "par" element numerical range:

   		  bitrate="(64,128)"

      A numerical range MUST be specified as a sequence pair of
   	"use-alt" elements may be used to specific values.  The
      first value is the definitions
   	that may used minimum value (included in parallel. Each "use-alt" element can define the number of minimum range) and maximum instantiations.
         </xsd:documentation>
       </xsd:annotation>
       <xsd:sequence>
         <xsd:element ref="sdpng:par"/>
       </xsd:sequence>
     </xsd:complexType>

     <xsd:element name="par">
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:use-alt">
   	</xsd:element>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

     <xsd:element name="use-alt">
       <xsd:complexType mixed="false">
         <xsd:attribute name="ref" type="xsd:string"/>
         <xsd:attribute name="min" type="xsd:positiveInteger"
   		     use="optional"/>
         <xsd:attribute name="max" type="xsd:positiveInteger"
   		     use="optional"/>
       </xsd:complexType>
     </xsd:element>
   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:complexType name="Conference" mixed="false">
       <xsd:sequence>
         <xsd:element name="meta" type="sdpng:ConfItem"/>
       </xsd:sequence>
       <!-- TBD -->
     </xsd:complexType>

     <xsd:complexType name="ConfItem" abstract="true" mixed="false">
       <xsd:annotation>
         <xsd:documentation>
   	The base type for conference meta inforformation
   	element. Currently, there the
      seconds value is no common content model defined.
         </xsd:documentation>
       </xsd:annotation>
     </xsd:complexType>

     <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:element name="owner">
       <xsd:complexType mixed="false">
         <xsd:complexContent mixed="false">
   	<xsd:extension base="sdpng:ConfItem">
   	  <xsd:attribute name="user" type="xsd:string"/>
   	  <xsd:attribute name="session-id" type="xsd:string"/>
   	  <xsd:attribute name="version" type="xsd:string"/>
   	  <xsd:attribute name="nettype" type="xsd:string"/>
   	  <xsd:attribute name="addrtype" type="xsd:string"/>
   	  <xsd:attribute name="addr" type="xsd:string">
   	    <!-- FIXME: re-use common address type! -->
   	  </xsd:attribute>
   	</xsd:extension>
         </xsd:complexContent>
       </xsd:complexType>
     </xsd:element>

   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:complexType name="SimpleLink" mixed="false">
       <xsd:attribute ref="xlink:type" fixed="simple"/>
       <xsd:attribute ref="xlink:role"/>
       <xsd:attribute ref="xlink:arcrole"/>
       <xsd:attribute ref="xlink:title"/>
       <xsd:attribute ref="xlink:show" fixed="none"/>
       <xsd:attribute ref="xlink:actuate" fixed="none"/>
       <xsd:attribute ref="xlink:href"/>
     </xsd:complexType>
     <xsd:element name="session">
       <xsd:complexType mixed="false">
         <xsd:complexContent mixed="false">
   	<xsd:extension base="sdpng:ConfItem">
   	  <xsd:sequence>
   	    <xsd:element name="description" type="xsd:string"/>
   	    <xsd:element name="info" type="sdpng:SimpleLink"/>
   	    <xsd:sequence minOccurs="0">
   	      <xsd:element name="contact" type="sdpng:SimpleLink"/>
   	    </xsd:sequence>
   	  </xsd:sequence>
   	</xsd:extension>
         </xsd:complexContent>
       </xsd:complexType>
     </xsd:element>
   </xsd:schema> the maximum value (included in the range).  The SDPng XML schema definition references some attribute definition
   for Xlink attributes (as defined
      values are separated by the Xlink specification [15]):

   <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
     xmlns="http://www.w3.org/1999/xlink"
     targetNamespace="http://www.w3.org/1999/xlink"
   >

     <xsd:attribute name="type" type="xsd:string"/>
     <xsd:attribute name="role" type="xsd:string"/>
     <xsd:attribute name="arcrole" type="xsd:string"/>
     <xsd:attribute name="title" type="xsd:string"/>
     <xsd:attribute name="show" type="xsd:string"/>
     <xsd:attribute name="actuate" type="xsd:string"/>
     <xsd:attribute name="href" type="xsd:string"/>

   </xsd:schema>

6. Open Issues

      Definition a comma (',') and are enclosed in ('(',
      ')').  One 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 range limits MAY be omitted, i.e., either the
      declaration of multiple schemas via
      minimum or the schemaLocation attribute.
      Conceivable solution: When extension profiles are used, maximum value, e.g., if the SDPng
      description is range has no upper or
      lower limit.
      An example for an attribute specifying a "multi-part" object, that consists of numerical range without
      an
      integrating schema upper limit:

   		  bitrate="(64,)"

      The complete formal syntax definition (that references all necessary
      profiles and the base definition) of numbers and the actual description
      document that is numerical
      ranges (and a schema instance definition of the integrating schema.

      Uniqueness of attribute values: When libraries are used they exact number type) will
      contain definition elements with "name" attributes for be
      provided in a later
      referencing.  How to avoid name clashes version of this document.

   An example for those identifiers?
      When an SDPng document uses libraries XML element describing an individual capability:

   <audio:codec name="avp:pcmu" encoding="PCMU" channels="[1,2]" sampling="[8000,16000]"/>

   Capability elements MAY also provide attribute from different sources they
      could be incompatible because of name collisions.  Possible
      solution: Prefix such IDs with XML
   namespaces.  For example, a namespace name (either explicitly
      or implicitly by interpreting applications).  The explicit
      prefixes have the advantage that no special knowledge would video-codec capability MAY be
      required to resolve links at the cost described
   with attributes declaring general video capabilities, and this
   element MAY provide a list of very long ID values.

      A registry (reuse additional codec specific attributes,
   as depicted in the following example:

   <video:codec name="h263+-enhanced" resolution="QCIF" frame-rate="(,24)"
                   h263plus:A="foo" h263plus:B="bar" />

   The definition of SDP mechanisms and names etc.) needs to be
      set up.

      Negotiation mechanisms for multiparty conferencing need to be
      formalized.

      Mapping "optional properties" (properties that to other media description formats (SDP, H.245, ...)
      should do not
   constitute a constraint but not optional enhancement -- see Section
   4.1.1) will be provided.  For H.245, this is probably provided in a different
      document (belonging to the SIP-H.323 inter-working group).

      Implicit declaration future version of SDPng schema and default profiles

      Should overwriting this document.

6. Specification of child elements be allowed for referencing
      existing definitions with the "ref" attribute?

7. Acknowledgements Capability Negotiation

   The authors would like to thank Teodora Guenkova, Goran Petrovic SDPng specification defines the syntax and
   Markus Nosse the semantics of
   capability declarations (potential configurations).  The algorithms
   that are used for their feedback and detailed comments.

References

   [1]   Kutscher, D., Ott, J., Bormann, C. processing descriptions 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 comparing
   capability descriptions from different participants are application
   specific.

   In this section we discuss two alternative algorithms for Real-Time Applications",
   implementations: A model that is base on the SDP offer/answer scheme
   (Section 6.1 and a model that is based on the feature matching
   algorithm that is specified in RFC
         1889, January 1996.

   [4]   Schulzrinne, H., "RTP Profile 2533 [18] (Section 6.2).

6.1 Offer/Answer

   The offer/answer model allows to communicating peers to determine a
   (common) mode of operation to exchange media streams in a single
   round-trip.  Basically, the offerer proposes a set of components,
   providing one or more alternatives ("potential configurations") for Audio
   each of these.  From this offer, the answerer learns which components
   may be used and Video Conferences
         with Minimal Control", RFC 1890, January 1996.

   [5]   Schulzrinne, H. which configurations are conceivable to realize these
   components.  The answerer indicates which components it supports
   (e.g.  disallow a video session and S. Casner, "RTP Profile for Audio go with a audio-only
   conversation) and Video
         Conferences also provides possible configurations to implement
   those components.  Along 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. the media types and S. Fosse-Parisis, "RTP
         Payload for Redundant Audio Data", RFC 2198, September 1997.

   [7]   Rosenberg, J. codec parameters,
   offerer and H. Schulzrinne, "An RTP Payload Format answerer specify which transport addresses to use and, in
   case of RTP, which payload types they want to use for
         Generic Forward Error Correction", RFC 2733, December 1999.

   [8]   Perkins, C. sending.
   Offerer and O. Hodson, "Options for Repair answerer agree on a common set of Streaming
         Media", RFC 2354, June 1998.

   [9]   Handley, M., Perkins, C. media streams
   ("components") 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 on a possible set of codecs ("configurations") as
   well as the transport addresses and other parameters to be used.
   However, they do not fix a certain configuration (unless only a
   single one is exchanged in each direction).  Instead, for each
   selected media stream, either peer may choose and dynamically switch
   to any of the configurations indicated by the other side 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.

   [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. the
   respective offer or answer.

   For using SDPng with the offer/answer model (RFC 3264), the following
   considerations apply to the SDPng documents:

   o  For each component to be used, all necessary parameters for at
      least one actual configuration MUST be given, i.e.  transport
      addresses and H. Schulzrinne, "An Offer/Answer Model payload formats MUST be specified along with
         SDP", draft-ietf-mmusic-sdp-offer-answer-02.txt (work the
      capabilities.

   o  Matching of components is done based upon their identification in
      the session part of the SDPng document using predefined
      identifiers.

   o  Components that shall not be instantiated (i.e.  that are refused
      by the answerer) shall either be present but have all parameters
      of the actual configuration removed (i.e.  no transport addresses,
      etc.) if they may be (re-)instantiated at a later stage.  Or they
      shall be removed entirely from the answer if the respective
      component is not supported at all.  In the latter case, the
      corresponding configurations MUST be removed from both the
      configuration section and the session section of the SDPng
      document.

   o  For each component, the alternative potential configurations MUST
      be listed in the order of preference.  A certain preference
      indicator ("q=" value) may be included in
         progress), February 2002.

   [17]  Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for a future revision of
      this document.  The
         Use considerations of XML within IETF Protocols", draft-hollenbeck-ietf-xml-
         guidelines-05.txt (work RFC 3264 to simply arriving
      at symmetric codec use apply.

   The rules for matching properties and determining answers based upon
   the offers are similar to those specified 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
   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

Appendix A. RFC 3264.

   A future revision of this document will define the details for all
   the attributes discussed in RFC 3264 that require special
   considerations (e.g.  the directionality attribute for media
   streams).

6.2 RFC2533 Negotiation

   SDPng Audio Codec Profile and Audio Codec Library potential configurations can be processed using the RFC 2533
   algorithm as defined in [18].  This section defines an involves the following steps:

      Translating SDPng profile for audio codec definitions potential configurations to RFC 2533 feature set
      expressions;

      Applying the RFC 2533 feature match algorithm; and

      Integrating the resulting feature set expressions into the SDPng
      selection of actual configurations.

6.2.1 Translating SDPng to RFC 2533 Expressions

   SDPng potential configurations can be translated to RFC 2533 feature
   sets in a corresponding library straightforward way, because SDPng uses a subset of the
   mechanisms provided by RFC 2533 with a different syntax.

   Each capability in an SDPng definitions section for potential configurations is
   represented as an XML element with a set of specific audio
   codecs.

A.1 Audio Codec Profile

   [5] specifies attributes.  We first
   describe how to translate a number single capability element into a RFC 2533
   feature set, and then consider the combination of multiple capability
   elements.

   Basically, all attributes of audio codecs including short name an SDPng capability element and its
   child elements MUST be transformed to a RFC 2533 expression, whereas
   each attribute MUST be
   used as reference translated to a feature predicate.  The
   resulting feature predicate are combined using the '&' (AND)
   operator.  The name attributes MUST NOT be considered.

   Each predicate MUST be encapsulated by session description protocols such as SDP and
   SDPng.  Those codec names, brackets ('(', ')').  Each XML
   attribute value is taken as listed in the first column of a feature predicate value, i.e., the above
   table,
   quote are used not considered.  Each attribute name is directly adopted as
   a feature tag, including the namespace name.

   The SDPng data types map to identify codecs RFC 2533 feature types as follows:

   Token
      A token MUST be directly adopted as a RFC 2533 token.

   Token set
      A token set MUST be directly adopted as a RFC 2533 set.

   Number
      A single number in SDPng. round brackets MUST be adopted as a RFC 2533
      number.  The following sections indicate the default values brackets MUST be removed.

   Numerical Ranges
      A numerical range MUST be transformed to a feature set expression
      with two feature predicates that are assumed
   if nothing else than combined using the codec reference is specified. "&" (AND)
      operator.  The first predicate specifies the lower limit and the
      second predicate specified the upper limit.
      For example, the attribute bitrate="(64,128)" would be transformed
      to the following audio:codec attributes are defined for audio codecs:

   name: feature set:

   		    (& (bitrate>=64) (bitrate<=128))

      A numerical range without a lower limit MUST be transformed to a
      corresponding predicate with a '<=' operator and a numerical range
      without a upper limit MUST be transformed to a corresponding
      predicate with a '>=' operator.
      For example, the identifier attribute bitrate="(,128)" would be transformed
      to the following feature set:

   		    (bitrate<=128)

   The following sample SDPng potential configuration would be later
   transformed as follows:

   Original SDPng expression:

   <video:codec name="h263+-enhanced" resolution="QCIF" frame-rate="(,24)"
                   h263plus:A="foo" h263plus:B="bar" />

   Transforming attributes to feature predicates:

   (& (resolution=QCIF) (frame-rate<=24) (h263plus:A=foo) (h263plus:B=bar))

   Note that in example above, the namespace name is not used for referencing the codec spec

   encoding:
   feature tags, instead we use the RTP/AVP profile identifier as registered with IANA

   mime: namespace prefix (for abbreviation).
   RFC 2533 uses the MIME type; may alternatively syntax rules of RFC 2506 for feature tags.  An
   additional requirement for transforming fully-qualified attribute
   names (including namespace names) to feature tags will be specified instead of
      "encoding"

   channels: the number
   in a future version of this document.

   Multiple independent media channels

   pattern: capability elements MUST each be transformed
   using the media channel pattern for mapping channels to payload

   sampling: specification above and then combined into a single RFC
   2533 feature set by connecting the sample rate for individual feature sets using the codec (which in most cases equals
   '|' (OR) operator.  For example, the RTP clock)

   Furthermore, options may following sample SDPng potential
   configuration would be defined transformed as follows:

   <audio:codec name="avp:pcmu" encoding="PCMU" channels="[1,2]" sampling="[8000,16000]"/>
   <video:codec name="h263+-enhanced" resolution="QCIF" frame-rate="(,24)"
                   h263plus:A="foo" h263plus:B="bar" />

   Transforming attributes to feature predicates:

   (|
     (& (encoding=PCMU) (channels=[1,2]) (sampling=[8000,16000]))
     (& (resolution=QCIF) (frame-rate<=24) (h263plus:A=foo) (h263plus:B=bar))
   )

   Additional requirements for processing "optional" parameters (see
   Section 5) will be specified in a future version of this document.

6.2.2 Applying RFC 2533 Canonicalization

   After transforming different SDPng capability descriptions from
   different participants into their equivalent RFC 2533 form, the
   following format:

   <option id="name">value</option>

   if steps MUST be performed to calculate the common subset of
   capabilities:

   1.  The individual feature sets MUST be combined into a value is associated with single
       expression by creating conjunction of the option (note that arbitrary complex
   values are allowed), or alternatively:

   <option id="name"/>

   if feature sets, i.e., the option is just a boolean indicator.

   Attributes for
       feature sets MUST be connected by the "option" tag are '&' (AND) operator.

   2.  The resulting expression MUST be reduced to disjunctive normal
       form, i.e., the following:

   id: canonical from as specified by RFC 2533 [18].

6.2.3 Integrating Feature Sets into SDPng

   A feature set that has been created by combining multiple independent
   feature sets and by reducing the identifier result for canonical form does not
   indicate directly which of the option (variable name)

   collaps: capability elements belong the collapsing rules for this optional element, defined as
      follows:

      min: for numeric values only

      max: for numeric values only

      x: intersection common
   subset of enumerated values, value lists capabilities.  The following profile defines an element type that can steps MUST be used for
   specifying audio codec characteristics.  The performed to
   determine whether an individual capability element "audio:codec" is
   of type "audio:AudioCodec" which is derived (e.g., from one of
   the contributing SDPng base type
   "sdpng:Definition".  The element "audio:codec" is declared capability descriptions) belongs to have the substitution group "sdpng:d" (the "head element" of the SDPng
   base definition).

   This means, "audio:codec" element can result
   feature set.

   Let R be used the result feature set obtained from the canonicalization as child elements
   specified in
   "sdpng:def" elements.  In addition to Section 6.2.2.

   1.  For each capability element, generate the attributes equivalent RFC 2533
       feature set by applying the steps specified here
   "audio:codec" elements will also have to provide in Section 6.2.1.
       Let C be the resulting feature set.

   2.  Combine R and C into a "name" attribute
   as defined single feature set by "sdpng:Definition".

   <xsd:schema targetNamespace="http://www.iana.org/sdpng/audio"
   	    xmlns:audio="http://www.iana.org/sdpng/audio"
   	    xmlns:sdpng="http://www.iana.org/sdpng"
   	    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   	    elementFormDefault="qualified"
   	    attributeFormDefault="unqualified">

     <xsd:import namespace="http://www.iana.org/sdpng"
   	      schemaLocation="sdpng.xsd"/>

     <!-- AudioCodecs extends building a
       conjunction of the abstract type "Definition" -->
     <!-- The data types for two feature sets (& R C).  Let the attributes could result be more restrictive... -->
     <xsd:complexType name="AudioCodec" mixed="false">
       <xsd:complexContent mixed="false">
         <xsd:extension base="sdpng:Definition">
   	<xsd:attribute name="encoding" type="xsd:string"/>
   	<xsd:attribute name="sampling" type="xsd:positiveInteger"/>
   	<xsd:attribute name="channels" type="xsd:positiveInteger"/>
         </xsd:extension>
       </xsd:complexContent>
     </xsd:complexType>

   <xsd:element name="codec" substitutionGroup="sdpng:definition">
       <xsd:complexType>
         <xsd:complexContent>
   	<xsd:extension base="audio:AudioCodec"/>
         </xsd:complexContent>
       </xsd:complexType>
     </xsd:element>
   </xsd:schema>

A.2 SDPng Library for Audio Codec Definitions

   This section contains an SDPng library with
       the audio codec
   definitions from Appendix A.

A.2.1 DVI4

   <audio:codec name="dvi4" encoding="DVI4" channels="1" sampling="8000">

   <rtp:pt name="rtp-avp-5" pt="5">
     <audio:codec ref="dvi4"/>
   </rtp:pt>

   <rtp:pt name="rtp-avp-6" pt="6">
       <audio:codec ref="dvi4" sampling="16000"/>
   </rtp:pt>

   Note that there feature set T.

   3.  Reduce T to disjunctive normal form by applying the
       canonicalization as defined in RFC 2533 [18].

   4.  If the remaining disjunction is no default sampling rate non-empty, the constraints
       specified by capability element (the origin of C) can be
       satisfied by R, i.e., C represents a commonly supported
       capability.

   A future version of this document will specify requirements for DVI4
   exchanging calculated capabilities and
   hence a sampling rate MUST be specified.

A.2.2 G.722

   <audio:codec name="g722" encoding="G722" channels="1" sampling="16000"/>
   <rtp:pt name="rtp-avp-9" pt="9">
       <audio:codec ref="g722"/>
   </rtp:pt>

   Note as per [5] that the RTP clock rate is 8000Hz rather than 16000
   Hz.

A.2.3 G.726

   <audio:codec name="g726-40" encoding="G726-40" channels="1" sampling="8000"/>
   <audio:codec name="g726-32" encoding="G726-32" channels="1" sampling="8000"/>
   <audio:codec name="g726-24" encoding="G726-24" channels="1" sampling="8000"/>
   <audio:codec name="g726-16" encoding="G726-16" channels="1" sampling="8000"/>

   <rtp:pt name="rtp-avp-5" pt="5">
       <audio:codec ref="g726-32"/>
   </rtp:pt>

A.2.4 G.728

   <audio:codec name="g728" encoding="G728" channels="1" sampling="8000"/>
   <rtp:pt name="rtp-avp-15" pt="15">
       <audio:codec ref="g728"/>
   </rtp:pt>

A.2.5 G.729

   G.729 Annex A: reduced complexity for selecting appropriate
   actual configurations.

7. Open Issues

      Definition of G.729
   G.729 Annex B: comfort noise

   <audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/>
   <rtp:pt name="rtp-avp-18" pt="18">
       <audio:codec ref="g729"/>
   </rtp:pt>

   For further codec description, baseline libraries

      Libraries provide partially specified definitions, i.e.  without
      transport parameters.  How can SDPng documents reference the following options (which carry no
   values associated
      definitions and augment them with them) MAY be included:

   <option id="annexA"/>
   <!-- to indicate the use of Annex A reduced complexity -->

   <option id="annexB"/>
   <!-- to indicate specific transport parameters?

      Referencing extension packages: XML-Schema does not support the use
      declaration of Annex B comfort noise -->

   As stated in [5], multiple schemas via the use schemaLocation attribute.
      Conceivable solution: When extension packages are used, the SDPng
      description is a "multi-part" object, that consists of these options can be detected within an
      integrating schema definition (that references all necessary
      packages and the
   media stream.

A.2.6 G.729 Annex D base definition) and E

   <audio:codec name="g729d" encoding="G729D" channels="1" sampling="8000"/>
   <audio:codec name="g729e" encoding="G729E" channels="1" sampling="8000"/>

   The following option MAY be 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 both Annexes D and E:

   <option id="annexB"/>
   <!-- "name" attributes for later
      referencing.  How to indicate the use of Annex B comfort noise -->

A.2.7 GSM

A.2.7.1 GSM Full Rate

   The GSM Full Rate codec is indicated as follows:

   <audio:codec name="gsm" encoding="GSM" channels="1" sampling="8000"/>
   <rtp:pt name="rtp-avp-3" pt="3">
       <audio:codec ref="gsm"/>
   </rtp:pt>

A.2.7.2 GSM Half Rate

   The GSM Half Rate codec is indicated as follows:

   <audio:codec name="gsm-hr" encoding="GSM-HR" channels="1" sampling="8000"/>

A.2.7.3 GSM Enhanced Full Rate

   The GSM Enhanced Full Rate codec is indicated as follows:

   <audio:codec name="gsm-efr" encoding="GSM-EFR" channels="1" sampling="8000"/>

A.2.8 L8

   <audio:codec name="l8" encoding="L8" channels="1" sampling="8000"/>

A.2.9 L16

   <audio:codec name="l16" encoding="L16" channels="1" sampling="8000"/>
   <audio:codec name="l16-2" ref="l16" channels="2"/>

   <rtp:pt name="rtp-avp-10" pt="10">
     <audio:codec ref="l16"/>
   </rtp:pt>

   <rtp:pt name="rtp-avp-11" pt="11">
     <audio:codec ref="l16-2"/>
   </rtp:pt>

A.2.10 LPC

   <audio:codec name="lpc" encoding="LPC" channels="1" sampling="8000"/>

A.2.11 MPA

   <audio:codec name="mpa" encoding="MPA" channels="1" sampling="8000"/>
   <rtp:pt name="rtp-avp-14" pt="14">
     <audio:codec ref="mpa"/>
   </rtp:pt>

A.2.12 PCMA and PCMU

   <audio:codec name="pcmu" encoding="PCMU" channels="1" sampling="8000"/>
   <audio:codec name="pcma" encoding="PCMA" channels="1" sampling="8000"/>

   <rtp:pt name="rtp-avp-0" pt="0">
     <audio:codec ref="pcmu"/>
   </rtp:pt>

   <rtp:pt name="rtp-avp-8" pt="8">
     <audio:codec ref="pcma"/>
   </rtp:pt>

A.2.13 QCELP

   <audio:codec name="qcelp" encoding="QCELP" channels="1" sampling="8000"/>
   <rtp:pt name="rtp-avp-12" pt="12">
     <audio:codec ref="qcelp"/>
   </rtp:pt>

A.2.14 VDVI

   <audio:codec name="vdvi" encoding="VDVI" channels="1" sampling="8000"/>
   <def xmlns="http://www.iana.org/sdpng"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.iana.org/sdpng/int integrated.xsd"
         xmlns:audio="http://www.iana.org/sdpng/audio"
         xmlns:rtp="http://www.iana.org/sdpng/rtp">

       <audio:codec name="dvi4" encoding="DVI4" channels="1" sampling="8000"/>
       <audio:codec name="g722" encoding="G722" channels="1" sampling="16000"/>
       <audio:codec name="g726-40" encoding="G726-40" channels="1" sampling="8000"/>
       <audio:codec name="g726-32" encoding="G726-32" channels="1" sampling="8000"/>
       <audio:codec name="g726-24" encoding="G726-24" channels="1" sampling="8000"/>
       <audio:codec name="g726-16" encoding="G726-16" channels="1" sampling="8000"/>
       <audio:codec name="g728" encoding="G728" channels="1" sampling="8000"/>
       <audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/>
       <audio:codec name="g729d" encoding="G729D" channels="1" sampling="8000"/>
       <audio:codec name="g729e" encoding="G729E" channels="1" sampling="8000"/>
       <audio:codec name="gsm" encoding="GSM" channels="1" sampling="8000"/>
       <audio:codec name="gsm-hr" encoding="GSM-HR" channels="1" sampling="8000"/>
       <audio:codec name="gsm-efr" encoding="GSM-EFR" channels="1" sampling="8000"/>
       <audio:codec name="l8" encoding="L8" channels="1" sampling="8000"/>
       <audio:codec name="l16" encoding="L16" channels="1" sampling="8000"/>
       <audio:codec name="lpc" encoding="LPC" channels="1" sampling="8000"/>
       <audio:codec name="mpa" encoding="MPA" channels="1" sampling="8000"/>
       <audio:codec name="pcmu" encoding="PCMU" channels="1" sampling="8000"/>
       <audio:codec name="pcma" encoding="PCMA" channels="1" sampling="8000"/>
       <audio:codec name="qcelp" encoding="QCELP" channels="1" sampling="8000"/>
       <audio:codec name="vdvi" encoding="VDVI" channels="1" sampling="8000"/>

   </def>

Appendix B. avoid name clashes for those identifiers?
      When an SDPng Profile for RTP Profile and RTP Library

B.1 RTP profile

   The following profile defines element types that can document uses libraries from different sources they
      could be used for
   specifying RTP payload types and RTP session configurations.  The
   element "rtp:pt" is incompatible because of type "rtp:PayloadType" which is derived from
   the SDPng base type "sdpng:Definition". name collisions.  Possible
      solution: Prefix such IDs with a namespace name (either explicitly
      or implicitly by interpreting applications).  The element "rtp:pt" is
   declared to explicit
      prefixes have the substitution group "sdpng:d" (the "head element"
   of 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.

      Implicit declaration of SDPng base definition).

   The element "rtp:session" is schema and default package

      Should overwriting of type "rtp:Session" which is derived
   from child elements be allowed for referencing
      existing definitions with the SDPng base type "sdpng:SessionConfig".  The element
   "rtp:session" "ref" attribute?

      We need a package definition language.  XML-DTDs or XML-Schema is declared
      not sufficient as we need ways to have the substitution group "sdpng:sc"
   (the "head element" of specify the SDPng base definition). type (string/symbol,
      set, numerical range) and additional attributes (optional).

8. Acknowledgements

   The RTP profile authors would like to thank Teodora Guenkova, Goran Petrovic and
   Markus Nosse for their feedback and detailed comments.

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 turn defines base types 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 the specification of
   transport parameters that are to be derived from by profiles that
   define rules Redundant Audio Data", RFC 2198, September 1997.

   [7]   Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for elements that can be used to specify parameters
         Generic Forward Error Correction", RFC 2733, December 1999.

   [8]   Perkins, C. and O. Hodson, "Options for
   specific transport mechanisms.

   <xsd:schema targetNamespace="http://www.iana.org/sdpng/rtp"
   	    xmlns:rtp="http://www.iana.org/sdpng/rtp"
   	    xmlns:sdpng="http://www.iana.org/sdpng"
   	    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   	    elementFormDefault="qualified"
   	    attributeFormDefault="unqualified">

     <xsd:import namespace="http://www.iana.org/sdpng"
   	      schemaLocation="sdpng.xsd"/>

     <xsd:complexType name="PayloadType" mixed="false">
       <xsd:annotation>
         <xsd:documentation>
   	PayloadType, the element 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.

   [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", RFC 3264, June 2002.

   [17]  Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for payload type definitions is
   	derived from "sdpng:Definition". Inside an element The
         Use of this
   	type, more definitions may be given (derived from
   	sdpng:Definition themselves).
         </xsd:documentation>
       </xsd:annotation>
       <xsd:complexContent mixed="false">
         <xsd:extension base="sdpng:Definition">
   	<xsd:sequence>
   	  <xsd:element ref="sdpng:definition" minOccurs="0" maxOccurs="unbounded"/>
   	</xsd:sequence>
   	<xsd:attribute name="pt" type="xsd:unsignedByte"/>
         </xsd:extension>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:element name="pt" type="rtp:PayloadType" substitutionGroup="sdpng:definition"/>

   <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

     <xsd:element name="session" type="rtp:Session" substitutionGroup="sdpng:sessionConfig"/>

     <xsd:complexType name="Session" mixed="false">
       <xsd:complexContent mixed="false">
         <xsd:extension base="sdpng:SessionConfig">
   	<xsd:sequence>
   	  <xsd:element ref="rtp:pt"/>
   	  <xsd:element ref="rtp:transport"/>
   	</xsd:sequence>
         </xsd:extension>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:complexType name="Transport" abstract="true" mixed="false">
       <xsd:complexContent>
         <xsd:extension base="sdpng:Definition">
   	<xsd:attribute name="role" type="xsd:string"/>
   	<xsd:attribute name="endpoint" type="xsd:string"/>
   	<xsd:attribute name="rtp-port" type="xsd:unsignedShort" use="optional"/>
   	<xsd:attribute name="rtcp-port" type="xsd:unsignedShort" use="optional"/>
         </xsd:extension>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:element name="transport" type="rtp:Transport" substitutionGroup="sdpng:definition"/>

     <xsd:simpleType name="IPAddr">
       <xsd:restriction base="xsd:string"/>
     </xsd:simpleType>

     <xsd:simpleType name="IP4Addr">
       <xsd:restriction base="rtp:IPAddr"/>
     </xsd:simpleType>

     <xsd:simpleType name="IP6Addr">
       <xsd:restriction base="rtp:IPAddr"/>
     </xsd:simpleType>

     <xsd:complexType name="UDP" mixed="false">
       <xsd:complexContent mixed="false">
         <xsd:extension base="rtp:Transport">
   	<xsd:choice>
   	  <xsd:element name="option">
   	    <!-- define options -->
   	  </xsd:element>
   	</xsd:choice>
   	<xsd:attribute name="addr" type="rtp:IP4Addr"/>
         </xsd:extension>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:element name="udp" type="rtp:UDP" substitutionGroup="rtp:transport"/>

   </xsd:schema>

B.2 SDPng Library XML within IETF Protocols", draft-hollenbeck-ietf-xml-
         guidelines-05.txt (work in progress), June 2002.

   [18]  Klyne, G., "A Syntax for RTP Payload Format Definitions

   This section contains an SDPng library with the RTP payload format
   definitions from Describing Media Feature Sets", RFC
         2533, March 1999.

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
   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

Appendix A.

   <def xmlns="http://www.iana.org/sdpng"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.iana.org/sdpng/int integrated.xsd"
         xmlns:audio="http://www.iana.org/sdpng/audio"
         xmlns:rtp="http://www.iana.org/sdpng/rtp"
         xmlns:xi="http://www.w3.org/2001/XInclude">

   <!-- import audio codec definitions here: -->

       <xi:xinclude href="http://www.iana.org/sdpng/audio/audio.sdpng" parse="xml"/>

       <rtp:pt name="rtp-avp-5" pt="5">
        <audio:codec ref="dvi4"/>
       </rtp:pt>

       <rtp:pt name="rtp-avp-6" pt="6">
         <audio:codec ref="dvi4" sampling="16000">
       </rtp:pt>

       <rtp:pt name="rtp-avp-9" pt="9">
        <audio:codec ref="g722"/>
       </rtp:pt>

       <rtp:pt name="rtp-avp-5" pt="5">
        <audio:codec ref="g726-32"/>
       </rtp:pt>

       <rtp:pt name="rtp-avp-15" pt="15">
        <audio:codec ref="g728"/>
       </rtp:pt>

       <rtp:pt name="rtp-avp-18" pt="18">
        <audio:codec ref="g729"/>
       </rtp:pt>

       <rtp:pt name="rtp-avp-3" pt="3">
        <audio:codec ref="gsm"/>
       </rtp:pt>

       <rtp:pt name="rtp-avp-10" pt="10">
         <audio:codec ref="l16"/>
       </rtp:pt>

       <rtp:pt name="rtp-avp-11" pt="11">
         <audio:codec ref="l16-2"/>
       </rtp:pt>

       <rtp:pt name="rtp-avp-14" pt="14">
         <audio:codec ref="mpa"/>
       </rtp:pt>

       <rtp:pt name="rtp-avp-0" pt="0">
         <audio:codec ref="pcmu"/>
       </rtp:pt>

       <rtp:pt name="rtp-avp-8" pt="8">
         <audio:codec ref="pcma"/>
       </rtp:pt>

       <rtp:pt name="rtp-avp-12" pt="12">
         <audio:codec ref="qcelp"/>
       </rtp:pt>

   </def>

Appendix C. Use of SDPng in conjunction with other IETF Signaling
            Protocols

   The SDPng model provides the notion of Components to indicate the
   intended types of collaboration between the users in e.g.  a
   teleconferencing scenario.

   Three different abstractions are defined that are used for describing
   the properties of a specific Component:

   o  a Capability refers to the fact that one of the involved parties
      supports one particular way of exchanging media -- defined in
      terms of transport, codec, and other parameters -- as part of the
      media session.

   o  a Potential Configuration denotes a set of matching Capabilities
      from all those involved parties required to successfully realize
      one particular Component.

   o  an Actual Configuration indicates the Potential Configuration
      which was chosen by the involved parties to realize a certain
      Component at one particular point in time.

   As mentioned before, this abstract notion of the interactions between
   a number of communicating systems needs to be mapped to the
   application scenarios of SDPng in conjunction with the various IETF
   signaling protocols: SAP, SIP, RTSP, and MEGACO.

   In general, this section provides recommendations and possible
   scenarios for the use of SDPng within specific protocols and
   applications.  Is does not specify normative requirements.

C.1

A.1 The Session Announcement Protocol (SAP)

   SAP is used to disseminate a previously created (and typically fixed)
   session description to a potentially large audience.  An interested
   member of the audience will use the SDPng description contained in
   SAP to join the announced media sessions.

   This means that a SAP announcement contains the Actual Configurations
   of all Components that are part of the overall teleconference or
   broadcast.

   A SAP announcement may contain multiple Actual Configurations for the
   same Component.  In this case, the "same" (i.e.  semantically
   equivalent) media data from one configuration must be available from
   each of the Actual Configurations.  In practice, this limits the use
   of multiple Actual Configurations to single-source multicast or
   broadcast scenarios.

   Each receiver of a SAP announcement with SDPng compares its locally
   stored Capabilities to realize a certain Component against the Actual
   Configurations contained in the announcement.  If the intersection
   yields one or more Potential Configurations for the receiver, it
   chooses the one it sees fit best.  If the intersection is empty, the
   receiver cannot participate in the announced session.

   SAP may be substituted by HTTP (in the general case, at least), SMTP,
   NNTP, or other IETF protocols suitable for conveying a media
   description from one entity to one or more other without the intend
   for further negotiation of the session parameters.

   Example from the SAP spec.  to be provided.

C.2

A.2 Session Initiation Protocol (SIP)

   SIP is used to establish and modify multimedia sessions, and SDPng
   may be carried at least in SIP INVITE and ACK messages as well as in
   a number of responses.  From dealing with legacy SDP (and its
   essential non-suitability for capability negotiation), a particular
   use and interpretation of SDP has been defined for SIP.

   One of the important flexibilities introduced by SIP's usage of SDP
   is that a sender can change dynamically between all codecs that a
   receiver has indicated support (and has provided an address) for.
   Codec changes are not signaled out-of-band but only indicated by the
   payload type within the media stream.  From this arises one important
   consequence to the conceptual view of a Component within SDPng.

   There is no clear distinction between Potential and Actual
   Configurations.  There need not be a single Actual Configuration be
   chosen at setup time within the SIP signaling.  Instead, a number of
   Potential Configurations is signaled in SIP (with all transport
   parameters required for carrying media streams) and the Actual
   Configuration is only identified by the payload type which is
   actually being transmitted at any point in time.

   Note that since SDPng does not explicitly distinguish between
   Potential and Actual Configurations, this has no implications on the
   SDPng signaling itself.

   SIP relies on an "offer/answer" model for the exchange of capability
   and configuration information.  Either the caller or the callee sends
   an initial session description that is processed by the other side
   and returned.  For capability negotiation, this means that the
   negotiation follows a two-stage-process: The "offerer" sends its
   capability description to the receiver.  The receiver processes the
   offerers capabilities and his own capabilities and generates a result
   capability description that is sent back to the offerer.  Both sides
   now know the commonly supported configurations and can initiate the
   media sessions.

   Because of this strict "offer/answer" model, the offerer must already
   send complete configurations (i.e.  include transport addresses)
   along with the capability descriptions.  The answer must also contain
   complete configuration parameters.  The following figure shows, how
   SDPng content can be used in an INVITE request with a correspong 200
   OK message.

   Simple description document with only one alternative:

      F1 INVITE A -> B

      INVITE sip:B@example.com SIP/2.0
      Via: SIP/2.0/UDP hostA.example.com:5060
      From: A <sip:A@example.com>
      To: B <sip:B@example.com>
      Call-ID: 1234@hostA.example.com
      CSeq: 1 INVITE
      Contact: <sip:UserA@192.168.1.1>
      Content-Type: application/sdpng
      Content-Length: 685

   <def>
    <audio:codec name="audio-basic" encoding="PCMU"
                 sampling="8000" channels="1"/>

    <rtp:pt name="rtp-avp-0" pt="0">
     <audio:codec ref="audio-basic"/>
    </rtp:pt>
   </def>

   <cfg>
     <component name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session>
          <rtp:pt ref="rtp-avp-0"/>
          <rtp:udp role="receive" endpoint="A" addr="192.168.1.1"
   	        rtp-port="7800"/>
         </rtp:session>
       </alt>
      </component>
   </cfg>
   <conf>
    <owner user="A@example.com" id="98765432" version="1" nettype="IN"
                         addrtype="IP4" addr="192.168.1.1"/>
    <session name="SDPng questions">
    </session>

    <info name="interactive-audio" function="voice">
     Telephony media stream
    <info>
   </conf>

   ==================================================

      F2 (100 Trying) B -> A

      SIP/2.0 100 Trying
      Via: SIP/2.0/UDP hostA.example.com:5060
      From: A <sip:A@example.com>
      To: B <sip:B@example.com>
      Call-ID: 1234@hostA.example.com
      CSeq: 1 INVITE
      Content-Length: 0

   ==================================================

      F3 180 Ringing B -> A

      SIP/2.0 180 Ringing
      Via: SIP/2.0/UDP hostA.example.com:5060
      From: A <sip:A@example.com>
      To: B <sip:B@example.com>;tag=987654
      Call-ID: 1234@hostA.example.com
      CSeq: 1 INVITE
      Content-Length: 0

   ==================================================

      F4 200 OK B -> A

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP hostA.example.com:5060
      From: A <sip:A@example.com>
      To: B <sip:B@example.com>;tag=987654
      Call-ID: 1234@hostA.example.com
      CSeq: 1 INVITE
      Contact: <sip:B@192.168.1.2>
      Content-Type: application/sdpng
      Content-Length: 479
   <def>
    <audio:codec name="audio-basic" encoding="PCMU"
                 sampling="8000" channels="1"/>

    <rtp:pt name="rtp-avp-0" pt="0">
     <audio:codec ref="audio-basic"/>
    </rtp:pt>
   </def>

   <cfg>
     <component name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session>
          <rtp:pt ref="rtp-avp-0"/>
          <rtp:udp role="receive" endpoint="A" addr="192.168.1.1"
   	        rtp-port="7800"/>
          <rtp:udp role="receive" endpoint="B" addr="192.168.1.2"
   	        rtp-port="9410"/>
         </rtp:session>
       </alt>
      </component>
   </cfg>
   ==================================================

   ACK from A to B omitted

   In the INVITE message, A sends B a description document, that
   specifies exactly one component with one alternative (the PCMU audio
   stream).  All required transport parameters all already contained in
   the description.  The rtp:udp element provides an attribute "role"
   with a value of "receive", indicating that the specified endpoint
   address is used by the endpoint to receive media data.  The element
   also provides the attribute "endpoint" with a value of "A",
   denominating the endpoint that can receive data on the specified
   address.  This means, the semantics of specified transport addresses
   in configuration descriptions are the same as for SDP (when used with
   SIP): An endpoint specifies where it wants to receive data.

   In the 200 OK message, B sends an updated description document to A.
   For the sake of conciseness, the conf element (containing meta
   information about the conference) has been omitted.  B supports the
   payload format that A has offered and adds his own transport
   parameters to the configuration information, specifying the endpoint
   address where B wants to receive media data.  In order to
   disambiguate its transport configurations from A's, B sets the
   attribute "endpoint" to the value "B".  The specific value of the
   "endpoint" attribute is not important, the only requirements are that
   a party that contributes to the session description, must use a
   unique name for the endpoint attribute and that a contributing party
   must use the same value for the endpoint attributes of all elements
   it adds to the session description.

   The following example shows a capability description that provides
   two alternatives for the audio component.

   Description document with two alternatives:

      F1 INVITE A -> B

      INVITE sip:B@example.com SIP/2.0
      Via: SIP/2.0/UDP hostA.example.com:5060
      From: A <sip:A@example.com>
      To: B <sip:B@example.com>
      Call-ID: 1234@hostA.example.com
      CSeq: 1 INVITE
      Contact: <sip:UserA@192.168.1.1>
      Content-Type: application/sdpng
      Content-Length: 935

   <def>
    <audio:codec name="audio-basic" encoding="PCMU"
                 sampling="8000" channels="1"/>

    <audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/>

    <rtp:pt name="rtp-avp-0" pt="0">
      <audio:codec ref="audio-basic"/>
    </rtp:pt>

    <rtp:pt name="rtp-avp-18" pt="18">
      <audio:codec ref="g729"/>
    </rtp:pt>

    <rtp:udp name="A-rcv" role="receive" endpoint="A" addr="192.168.1.1"
   	  rtp-port="7800"/>
   </def>

   <cfg>
     <component name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session format="rtp-avp-0">
          <rtp:udp ref="A-rcv"/>
         </rtp:session>
       </alt>
       <alt name="AVP-audio-18">
         <rtp:session format="rtp-avp-18"/>
          <rtp:udp ref="A-rcv"/>
         </rtp:session>
       </alt>
      </component>
   </cfg>

   <conf>
    <owner user="A@example.com" id="98765432" version="1" nettype="IN"
                         addrtype="IP4" addr="192.168.1.1"/>
    <session name="SDPng questions">
    </session>

    <info name="interactive-audio" function="voice">
     Telephony media stream
    <info>
   </conf>

   ==================================================

      F2 (100 Trying) B -> A

      SIP/2.0 100 Trying
      Via: SIP/2.0/UDP hostA.example.com:5060
      From: A <sip:A@example.com>
      To: B <sip:B@example.com>
      Call-ID: 1234@hostA.example.com
      CSeq: 1 INVITE
      Content-Length: 0

   ==================================================

      F3 180 Ringing B -> A

      SIP/2.0 180 Ringing
      Via: SIP/2.0/UDP hostA.example.com:5060
      From: A <sip:A@example.com>
      To: B <sip:B@example.com>;tag=987654
      Call-ID: 1234@hostA.example.com
      CSeq: 1 INVITE
      Content-Length: 0

   ==================================================
      F4 200 OK B -> A

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP hostA.example.com:5060
      From: A <sip:A@example.com>
      To: B <sip:B@example.com>;tag=987654
      Call-ID: 1234@hostA.example.com
      CSeq: 1 INVITE
      Contact: <sip:B@192.168.1.2>
      Content-Type: application/sdpng
      Content-Length: 479

   <def>
    <audio:codec name="audio-basic" encoding="PCMU"
                 sampling="8000" channels="1"/>

    <audio:codec name="g729" encoding="G729" channels="1" sampling="8000"/>

    <rtp:pt name="rtp-avp-0" pt="0">
      <audio:codec ref="audio-basic"/>
    </rtp:pt>

    <rtp:pt name="rtp-avp-18" pt="18">
      <audio:codec ref="g729"/>
    </rtp:pt>

    <rtp:udp name="A-rcv" role="receive" endpoint="A" addr="192.168.1.1"
   	  rtp-port="7800"/>

    <rtp:udp name="B-rcv" role="receive" endpoint="B" addr="192.168.1.2"
   	  rtp-port="9410"/>
   </def>

   <cfg>
     <component name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session format="rtp-avp-0">
           <rtp:udp ref="A-rcv"/>
           <rtp:udp ref="B-rcv"/>
        </rtp:session>
       </alt>
      </component>
   </cfg>
   ==================================================

   ACK from A to B omitted
   In the INVITE message, A sends B a description document, that
   specifies one component with two alternatives for the audio stream
   (PCMU and G.729).  Since A wants to use the same transport address
   for receiving media data regardless of the payload format, A provides
   the transport specification in the def element and references this
   definition in the rtp:session elements for both alternatives by using
   the attribute "transport".

   In the 200 OK message, B sends an updated description document to A.
   B does only support PCMU, so it removes the alternative for G.729
   from the description.  B also defines its transport address in the
   def element and references this definition by referencing the rtp:udp
   element named "B-rcv".

C.3

A.3 Real-Time Streaming Protocol (RTSP)

   In contrast to SIP, RTSP has, from its intended usage, a clear
   distinction between offering Potential Configurations (typically by
   the server) and choosing one out of these (by the client), and, in
   some cases; some parameters (such as multicast addresses) may be
   dictated by the server.  Hence with RTSP, there is a clear
   distinguish between Potential Configurations during the negotiation
   phase and a finally chosen Actual Configuration according to which
   streaming will take place.

   Example from the RTSP spec to be provided.

C.4

A.4 Media Gateway Control Protocol (MEGACOP)

   The MEGACO architecture also follows the SDPng model of a clear
   separation between Potential and Actual Configurations.  Upon
   startup, a Media Gateway (MG) will "register" with its Media Gateway
   Controller (MGC) and the latter will audit the MG for its
   Capabilities.  Those will be provided as Potential Configurations,
   possibly with extensive Constraints specifications.  Whenever a media
   path needs to be set up by the MGC between two MGs or an MG needs to
   be reconfigured internally, the MGC will use (updated) Actual
   Configurations.

   Details and examples to be defined.

Appendix D. B. Change History

   draft-ietf-mmusic-sdpng-06.txt

      *  Removed section on capability negotiation algorithm and section
         on formal specification.  Added Section 3.

      *  Removed specification of concrete XML syntax from Section 4.
         Added requirements and theoretic considerations.

      *  Added clarification of term "actual configuration" in Section
         2.

      *  Changed "profile" to "package".

      *  Added introducing text to Section 4.1.

      *  Added a list of terms with explanation at the end of Section 2.

      *  Removed audio and RTP packages from appendix.

      *  Added Section 5 ("Syntax Definition").

      *  Added Section 6 ("Specification of the Capability
         Negotiation").

   draft-ietf-mmusic-sdpng-05.txt

      *  Moved audio and RTP profile packages to appendix.

      *  Moved section "Use of SDPng in conjunction with other IETF
         Signaling Protocols" to appendix.

      *  Changed mechanism for references to definitions: Definition
         elements provide an attribute "ref" that can be used to
         referenced existing definitions (Section 3.3). 4.3).  Removed other
         mechanisms for referencing (attributes "format" and
         "transport", element type "use").

      *  Corrections to schema definitions and examples

   draft-ietf-mmusic-sdpng-04.txt

      *  New section on capability negotiation (Section 4). negotiation.

      *  New section on referencing definitions (Section 3.3). 4.3).

      *  New section on properties.

      *  New section on definition groups.

   draft-ietf-mmusic-sdpng-03.txt

      *  Extension of the SDPng schema (use of Xlinks etc.)

      *  Clarification in the text

      *  Fixed examples

      *  Added example libraries as appendices

      *  More details on usage with SIP, including examples.

   draft-ietf-mmusic-sdpng-02.txt

      *  Added a  section on formal specification mechanisms (Section 5). mechanisms.

   draft-ietf-mmusic-sdpng-01.txt

      *  renamed section "Syntax Proposal" to "Syntax Definition
         Mechanisms".  More text on DTD vs.  schema.  Edited the example
         description.

      *  updated example definitions in section "Definitions" and
         "Components & Configurations"

      *  section "Session Attributes" replaces section "Session"

      *  new appendix on audio codec definitions

Full Copyright Statement

   Copyright (C) The Internet Society (2002). (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.