Network Working Group                                           Kutscher
Internet-Draft                                                       Ott
Expires: January 18, February 22, 2002                                       Bormann
                                                TZI, Universitaet Bremen
                                                           July 20,
                                                         August 24, 2001

             Session Description and Capability Negotiation
                     draft-ietf-mmusic-sdpng-01.txt
                     draft-ietf-mmusic-sdpng-02.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.

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

   To view the entire

   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, see Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 18, February 22, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001).  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 confctrl@isi.edu and/or the authors.

Document Revision
   $Revision: 2.0 2.7 $

Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  4
   2.      Terminology and System Model . . . . . . . . . . . . . . .  6
   3.      SDPng  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.1     Conceptual Outline . . . . . . . . . . . . . . . . . . . .  9
   3.1.1   Definitions  . . . . . . . . . . . . . . . . . . . . . . .  9
   3.1.2   Components & Configurations  . . . . . . . . . . . . . . . 11
   3.1.3   Constraints  . . . . . . . . . . . . . . . . . . . . . . . 13
   3.1.4   Session Attributes . . . . . . . . . . . . . . . . . . . . 14
   3.1.4.1 Owner  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   3.1.4.2 Session Identification . . . . . . . . . . . . . . . . . . 15
   3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines)  . . . 16
   3.1.4.4 Component Semantic Specification . . . . . . . . . . . . . 17
   3.2     Syntax Definition Mechanisms . . . . . . . . . . . . . . . 18
   3.3     External Definition Packages . . . . . . . . . . . . . . . 20 21
   3.3.1   Profile Definitions  . . . . . . . . . . . . . . . . . . . 20 21
   3.3.2   Library Definitions  . . . . . . . . . . . . . . . . . . . 21
   3.4     Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 22 23
   4.      Formal Specification . . . . . . . . . . . . . . . . . . . 24
   5.      Use of SDPng in conjunction with other IETF Signaling
           Protocols
   4.1     XML Schema as a Definition Mechanism . . . . . . . . . . . 24
   4.2     SDPng Schema . . . . . . . . . . . . . . 25
   5.1     The Session Announcement Protocol (SAP) . . . . . . . . . 25
   5.2     Session Initiation Protocol (SIP)
   4.3     Profiles . . . . . . . . . . . . 26
   5.3     Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . 26
   5.4     Media Gateway Control Protocol (MEGACOP) . . 25
   4.4     SDPng Documents  . . . . . . . 27
   6.      Open Issues . . . . . . . . . . . . . . 26
   4.5     Libraries  . . . . . . . . . 28
           References . . . . . . . . . . . . . . . 27
   4.6     Details on the use of specific XML Mechanisms  . . . . . . 28
   4.6.1   Default Namespace  . . . 29
           Authors' Addresses . . . . . . . . . . . . . . . . . 28
   4.6.2   Qualified Locals . . . 30
   A.      Base SDPng Specifications for Audio Codec Descriptions . . 31
   A.1     DVI4 . . . . . . . . . . . . . . . . 29
   4.6.3   Fixed Namespace Prefixes . . . . . . . . . . . 32
   A.2     G.722 . . . . . . 29
   4.7     SDPng Schema Definitions . . . . . . . . . . . . . . . . . 29
   4.7.1   SDPng Base Definition  . . . 32
   A.3     G.726 . . . . . . . . . . . . . . . 30
   4.7.2   Audio Codec Profile  . . . . . . . . . . . 32
   A.4     G.728 . . . . . . . . 36
   4.7.3   RTP profile  . . . . . . . . . . . . . . . . . . 32
   A.5     G.729 . . . . . 37
   4.8     Issues . . . . . . . . . . . . . . . . . . . . . 32
   A.6     G.729 Annex D and E . . . . . 39
   5.      Use of SDPng in conjunction with other IETF Signaling
           Protocols  . . . . . . . . . . . . . . 33
   A.7     GSM . . . . . . . . . . 41
   5.1     The Session Announcement Protocol (SAP)  . . . . . . . . . 41
   5.2     Session Initiation Protocol (SIP)  . . . . . . . . 33
   A.7.1   GSM Full Rate . . . . 42
   5.3     Real-Time Streaming Protocol (RTSP)  . . . . . . . . . . . 42
   5.4     Media Gateway Control Protocol (MEGACOP) . . . . . . . 33
   A.7.2   GSM Half Rate . . 43
   6.      Open Issues  . . . . . . . . . . . . . . . . . . . . 33
   A.7.3   GSM Enhanced Full Rate . . . 44
           References . . . . . . . . . . . . . . . 33
   A.8     L8 . . . . . . . . . 45
           Authors' Addresses . . . . . . . . . . . . . . . . . . . 33
   A.9     L16 . 46
   A.      Base SDPng Specifications for Audio Codec Descriptions . . 47
   A.1     DVI4 . . . . . . . . . . . . . . . . . . . . . . . . 34
   A.10    LPC . . . 48
   A.2     G.722  . . . . . . . . . . . . . . . . . . . . . . . . 34
   A.11    MPA . . 48
   A.3     G.726  . . . . . . . . . . . . . . . . . . . . . . . . . 34
   A.12    PCMA and PCMU . 48
   A.4     G.728  . . . . . . . . . . . . . . . . . . . . . 34
   A.13    QCELP . . . . . 48
   A.5     G.729  . . . . . . . . . . . . . . . . . . . . . 34
   A.14    VDVI . . . . . 48
   A.6     G.729 Annex D and E  . . . . . . . . . . . . . . . . . . . 49
   A.7     GSM  . . . 34
           Full Copyright Statement . . . . . . . . . . . . . . . . . 35

1. Introduction

   Multiparty multimedia conferencing is one of the applications that
   require dynamic interchange of end system capabilities and the . . . . . . . 49
   A.7.1   GSM Full Rate  . . . . . . . . . . . . . . . . . . . . . . 49
   A.7.2   GSM Half Rate  . . . . . . . . . . . . . . . . . . . . . . 49
   A.7.3   GSM Enhanced Full Rate . . . . . . . . . . . . . . . . . . 49
   A.8     L8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
   A.9     L16  . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
   A.10    LPC  . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
   A.11    MPA  . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
   A.12    PCMA and PCMU  . . . . . . . . . . . . . . . . . . . . . . 50
   A.13    QCELP  . . . . . . . . . . . . . . . . . . . . . . . . . . 50
   A.14    VDVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
   B.      Change History . . . . . . . . . . . . . . . . . . . . . . 51
           Full Copyright Statement . . . . . . . . . . . . . . . . . 52

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 like session directories can configure media tools on startup.
   This procedure however fails to work for conferences initiated
   spontaneously like Internet phone calls or ad-hoc multiparty
   conferences.  Fixed settings for parameters like 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 and introduce the
   basic terms used throughout this specification (section 2).  Then 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 introduce
   basic audio codec and payload type definitions.

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 "deployment" of these components.

   Each component can be characterized at least by (a) its intended use
   (i.e.  the function it shall provide) and (b) a 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
      whiteboard.  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 parameter A-law
      or u-Law, packetization and redundancy parameters, etc.

   In this system model, 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 appropriate for all sending a set of parameters that are required to
      implement a certain variation (realization) of a certain
      component.  There are actual and receiving potential configurations.

      *  Potential configurations describe possible configurations that
         are supported by an end systems 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 conference. For some applications,
   e.g. for loosely coupled conferences or for broadcast scenarios, it
   may be sufficient negotiation process
   needs to simply take place between the involved peers:

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

   2.  to select one of this shared set of common potential
       configurations to be fixed by used for information exchange (e.g.  based
       upon preferences, external constraints, etc.).

   In SAP-based [11] session announcements on the
   initiator of 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 conference. receiver must understand to participate.

   In such a scenario no point-to-point scenarios, the negotiation procedure is
   required because only those participants with media tools that
   support typically
   carried out implicitly: each party informs the predefined settings other about what it
   can join a media session and/or receive and the respective sender chooses from this set a
   conference.

   This approach is applicable
   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 are announced some
   time ahead the process of determining the subset
   of allowable potential configurations is deterministic to reduce the
   number of required round trips before a session can be established.

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

3. SDPng

   This section introduces the underlying concepts of the conference. Potential
   participants can check Session
   Description Protocol - next generation (SDPng) that is to meet most
   of the availability above requirements.  The focus of media tools in advance
   and tools like session directories can configure media tools this section is on
   startup. This procedure however fails to work for conferences
   initiated spontaneously like Internet phone calls or ad-hoc
   multiparty conferences. Fixed settings for parameters like media
   types, their encoding etc. can easily inhibit the initiation
   concepts of
   conferences, for example in situations where such a caller insists on capability description and negotiation language
   with a
   fixed audio encoding that stepwise introduction of the various syntactical elements; a
   full formal specification is not available at provided in section 4.

3.1 Conceptual Outline

   The description language follows the callee's end
   system.

   To allow for spontaneous conferences, system model introduced in the process
   beginning 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 this document.  We use a new participant joins an active
   conference. rather abstract language to
   avoid misinterpretations due to different intuitive understanding of
   terms as far as possible.

   The latter approach may not be appropriate for every
   type concept of conference without applying certain policies: For
   conferences with TV-broadcast 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 lecture characteristics (one main
   active source) it is usually not desired 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 definition section specifies a number of basic abstractions that
   are later referenced to re-negotiate parameters
   every time avoid repetitions in more complex
   specifications and allow for a new participant concise representation.  Definition
   elements are labelled with an exotic configuration joins
   because it identifier by which they may inconvenience existing participants be
   referenced.  They may be elementary or even exclude
   the main source from media sessions. But conferences with equal
   "rights" for participants compound (i.e.  combinations
   of elementary entities).  Examples of definitions of that sections
   include (but are open for new participants on the not limited to) codec definitions, redundancy
   schemes, transport mechanisms and payload formats.

   Elementary definition elements do not reference other hand would need a different model elements.  Each
   elementary entity only consists of dynamic capability
   negotiation, one of more attributes and their
   values.  Default values specified in the definition section may be
   overridden in descriptions for example a telephone call that potential (and later actual)
   configurations.  A mechanisms for overriding definitions is extended specified
   below.

   For the moment, elementary elements are defined for media types (i.e.

   codecs) and for media transports.  For each transport and for each
   codec to a
   3-parties conference at some time during be used, the session.

   SDP [2] allows respective attributes need to specify multimedia sessions (i.e. conferences,
   "session" as used here 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 define payload types and media stream
   identifiers.

   It is not required to be confused with "RTP session"!)
   by providing general information about the session as define all codec, transport mechanisms in a whole
   definitions sections and
   specifications for all reference them in the media streams (RTP sessions definition of
   potential and others)
   to be used actual configurations.  Instead, a syntactic mechanism
   is defined that allows to exchange information within the multimedia session.

   Currently, media descriptions specify some definitions directly in SDP are used a
   configurations section.

   Examples for two purposes:

   o 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 describe session define
   audio codec configurations.  The configuration parameters are given
   as attribute values.

   Definitions may have default values specified along with them for announcements and invitations
      (the original purpose of SDP) and

   o  to describe the capabilities
   each attribute (as well as for their contents).  Some of these
   default values may be overridden so that a system and possibly provide codec definition can
   easily be re-used in a
      choice between different context (e.g.  by specifying a
   different sampling rate) without the need for a large number of alternatives (which SDP was not
      designed for).

   A distinction between these two "sets base
   specifications.  In the following example the definition of semantics" is only made
   implicitly.

   This document audio-
   L16-mono is based upon a set re-used for the defintion of requirements specified in a
   companion document [1] In the following we first introduce corresponding stereo
   codec.  Appendix A provides a model
   for session description and capability negotiation and introduce complete set of corresponding
   audio:codec definitions of the
   basic terms codec used in RFC 1890 [4].

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

   The example shows how exisiting defintions can be referenced in new
   definitiones.  This approach allows to have simple as well as more
   complex definitions which are commonly used throughout this specification (section 2). Then we
   outline be available in an
   extensible set of reference documents.  Section 3.3 specifies the concept
   mechanisms for the concepts underlying SDPng external references.

   Besides definitions of audio codecs there will be other definitions
   like RTP payload format and introduce
   the syntactical components step by step specific transport mechanisms that are
   suitable to be defined in a defintion section 3. In section 4,
   we provide for later referencing.

   The following example shows how RTP payload types are defined using a formal definition of
   pre-defined codec.

   <rtp:pt name="rtp-avp-0" pt="0" format="audio-basic"/>
   <rtp:pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/>

   In this example, the SDPng session description
   language. Finally, we overview aspects of using SDPng payload type "rtp-avp-11" is defined with various
   IETF signaling protocols in section 5. In Appendix A, we introduce
   basic audio codec and
   payload type definitions.

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 11, referencing 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 codec "audio-L16-mono".
   Instead of referencing an existing definition it is also possible to
   define the
      screen resolution for true color by the graphics board; available
      audio hardware or software format "inline":

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

   Note: For negotiation between endpoints, it may offer only certain media encodings
      (e.g. G.711 and G.723.1 but not GSM); and CPU processing power
      and quality be helpful to define
   two modes of implementation operation: explicit and implicit.  Implicit
   specifications may constrain the possible video
      encoding algorithms.

   In multiparty multimedia conferences, participants employ different
   "components" refer to externally defined entities to minimize
   traffic volume, explicit specifications would list all external
   definitions used in a description in conducting the conference.

      Example: In lecture multicast conferences one component might be the voice transmission "Definitions" section.
   Again, see Section 3.3 for the lecturer, another the transmission complete discussion of video pictures showing external
   definitions.

   The "Definitions" section may be empty if all transport, codecs, and
   other pieces needed to the lecturer specify Potential and Actual
   Configurations (as detailed below) are either included by referencing
   external definitions or are explicitly described within the third
   Configurations themselves.

3.1.2 Components & Configurations

   The "Configurations" section contains all the
      transmission components that
   constitute the multimedia conference (IP telephone call, multiplayer
   gaming session etc.).  For each of presentation material.

   Depending on system capabilities, user preferences and other
   technical and political constraints, different these components, the potential
   and, later, the actual configurations are given.  Potential
   configurations are used during capability exchange and/or
   negotiation, actual configurations can be
   chosen to accomplish configure media streams after
   negotiation (e.g.  with RTSP) or in session announcements (e.g.  via
   SAP).  A potential and the "deployment" actual configuration of these components. a component may be
   identical.

   Each component is labelled with an identifier so that it can be characterized at least by (a) its intended use
   (i.e. the function it shall provide) and (b)
   referenced, e.g.  to associate semantics with a one or more possible
   ways particular media
   stream.  For such a component, any number of configurations may be
   given with each configuration describing an alternate way to realize this function. Each way
   the functionality of realizing a particular
   function the respective component.

   Each configuration (potential as well as actual) is referred labelled with an
   identifier.  A configuration combines one or more (elementary and/or
   compound) entities from the "Definitions" section to as describe a "configuration".

      Example: A conference component's intended use
   potential or an actual configuration.  Within the specification of
   the configuration, default values from the referenced entities may be
   overwritten.

   Note: Not all protocol environments and their respective operation
   allow to make
      transparencies explicitly distinguish between Potential and Actual
   Configurations.  Therefore, SDPng so far does not provide for
   syntactical identification of a presentation visible to the audience on the
      Mbone. This Configurations as being a Potential
   or an Actual one.

   The following example shows how RTP sessions can be achieved either described by
   referencing payload definitions.

   <cfg>
     <component name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session format="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 format="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 video camera capturing single component
   "name=interactive-audio" with two possible ways of implementing it.
   The two corresponding configurations are "AVP-audio-0" without
   modification, the image and transmitting a video stream via some video tool or 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 loading the
   "udp" element.  Of course, it must be possible to specify other
   transport mechanisms as well.  See Section 3.2 for a copy discussion of
   extension mechanisms that allow applications to use non-standard
   transport (or other) specifications.

   During/after the slides into negotiation phase, an actual configuration is chosen
   out of a distributed electronic
      whiteboard. For each number of these cases, additional parameters alternative potential configurations, the actual
   configuration may
      exist, variations of which lead refer 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 potential configuration just by its
   "id", possibly allowing for some parameter modifications.
   Alternatively, the same and differ only in a
   single parameter.

      Example: In case of video transmission, a JPEG-based still image
      protocol full actual configuration 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 given.

   Instead of referencing existing payload type definitions it is also
   possible to provide the participating
   system's capabilities. In addition, required information "inline".  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 intended use examples is a
   simple variant of a component
   may constrain the transport specification.  More complex ones are
   conceivable.  For example, it must also be possible configurations further to a subset
   suitable for the particular component's purpose.

      Example: In a system for highly interactive audio communication specify the component responsible for audio may decide not to use
   usage of source filters (inclusion and exclusion), Source Specific
   Multicast, the
      available G.723.1 audio codec usage of multi-unicast, or other parameters.
   Therefore it is possible to avoid extend the additional latency but
      only use G.711. This would 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 format="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>

   More transport mechanisms and options will be reflected defined in future
   versions of this component only
      showing configurations based upon G.711. Still, multiple document.

3.1.3 Constraints

   Definitions specify media, transport, and other capabilities, whereas
   configurations are possible, e.g. depending on the use indicate which combinations of A-law
      or u-Law, packetization and redundancy parameters, etc.

   In this these could be used to
   provide the desired functionality in a certain setting.

   There may, however, be further constraints within a system model, we distinguish two types (such as
   CPU cycles, DSP available, dedicated hardware, etc.) that limit which
   of configurations:

   o  potential these configurations
      (a set of any number can be instantiated in parallel (and how many
   instances of configurations per component) indicating
      a system's functional capabilities as constrained by the intended
      use these may exist).  We deliberately do not couple this
   aspect of system resource limitations to the various components;

   o  actual configurations
      (exactly one per instance of a component) reflecting application
   semantics as the mode of
      operation of this component's particular instantiation.

      Example: The potential configuration constraints exist across application boundaries.
   Also, in many cases, expressing such constraints is simply not
   necessary (as many uses of the aforementioned video
      component may indicate support for JPEG, H.261/CIF, and
      H.261/QCIF. A particular instantiation for current SDP show), so additional
   overhead can be avoided where this is not needed.

   Therefore, we introduce a video conference may "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 actual configuration number of H.261/CIF for exchanging video
      streams.

   In summary,
   instantiations, and allow only certain combinations.  The following
   example shows the key terms of this model are:

   o  A multimedia session (streaming or conference) consists definition of one or
      more conference components for multimedia "interaction".

   o  A component describes a particular type of interaction (e.g.
      audio conversation, slide presentation) constraints that can be realized by
      means restricts the
   maximum number of different applications (possibly using different
      protocols).

   o  A configuration is a set instantiation of parameters that are required two alternatives (that would have
   to
      implement a certain variation (realization) of a certain
      component. There be defined in the configuration section before) when they are actual and potential configurations.

      *  Potential configurations describe possible configurations that 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, contraints are supported defined by an end system.

      *  An actual configuration is an "instantiation" defining limits on
   simultaneous instantiations of one alternatives.  They are not defined by
   expressing abstract endsystem 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
         potential configurations, i.e. a decision how SDPng syntax addresses session
   layer attributes.  These attributes largely include those defined by
   SDP [RFC2327] (which are explicitly indicated in the following
   specification) to realize a
         certain component.

      In less abstract words, potential configurations describe what a
      system can do ("capabilities") originator, purpose, and actual configurations describe
      how a system is configured to operate at timing of a certain point
   multimedia session among other characteristics.  Furthermore, SDPng
   includes attributes indicating the semantics of the various
   Components in time
      (media stream spec).

   To decide on a certain actual configuration, a negotiation process
   needs to take place between teleconference or other session.  This part of the involved peers:

   1.
   specification is open ended with an IANA registry to determine which potential configuration(s) they have in
       common, and

   2. be set up to select one
   register further types of this shared set components; only a few of common potential
       configurations the examples are
   listed here.

   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.

   Session level attributes as defined by SDP still have to be used examined
   and adopted for information exchange (e.g. based
       upon preferences, external constraints, etc.).

   In SAP-based [11] SDPng in a future revision of this specification.

3.1.4.1 Owner

   The owner refers to the creator of a session announcements as defined in RFC2327
   ("o=" line).  The syntax is as follows:

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

   The owner field MUST be present if SDPng is used with SAP.  For all
   other protocols, the owner field MAY be specified.  The attributes
   listed above match those from the SDP specification; all attributes
   MUST be present and they MUST be created following the rules of
   RFC2327.

   Note: There are several possible ways ahead on this part: "owner"
   could stand as it is right now, but the Mbone, for which SDP
   was originally developed, various values of the negotiation procedure is non-existent.
   Instead, various
   attributes could be concatenated (separated by blanks) the announcement contains result
   being identical to the media stream description sent
   out (i.e. contents of the actual configurations) SDP "o=" line -- which implicitly describe what then
   could be represented as either a receiver must understand single attribute or as contents of
   the "owner" element.  Alternatively, the owner element could become
   part of the "session" element described below.  Or the contents of
   the owner element could become an attribute of the "session" element
   below.

3.1.4.2 Session Identification

   The "session" element is used to participate.

   In point-to-point scenarios, identify the negotiation procedure session and to provide
   a description and possible further references.  The following
   attributes are defined:

   name: The session name as it is typically
   carried out implicitly: each party informs to appear e.g.  in a session
      directory.  This is equivalent to the other SDP "s=" line.  This
      attribute MUST be present.

   info: A pointer to further information about what it
   can receive and the respective sender chooses from session; this set
      attribute MUST contain a
   configuration that it can transmit.

   Capability negotiation must not only work for 2-party conferences
   but URI.  The attribute itself is also required for multi-party conferences. Especially for OPTIONAL.

   The session element MAY contain arbitrary text of any length (but
   authors are encouraged to keep the
   latter case inline description brief and
   provide additional information via URLs.  This text is used to
   provide a description of the session; it is required that the process equivalent of determining the
   subset SDP
   "i=" lines.

   Furthermore, the session element MAY contain other elements of allowable potential configurations is deterministic the
   following types to
   reduce provide further information about the number of required round trips before session and
   its creator:

   info: The info element is intended to provide a pointer to further
      information on the session can itself.  Its contents MUST be
   established. exactly
      one URI.  If both the info attribute and one or more info elements
      are present, the union of the respective values is used.  Info
      elements are OPTIONAL, they MAY be repeated any number of times.

   contact: The requirements for contact element provides contact information on the
      creator of the session; its contents MUST be exactly one 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 be repeated any number of times.

   <session name="An SDPng specification, subdivided into
   general requirements seminar" info="http://www.dmn.tzi.org/ietf/mmusic/">
       And here comes a long description of the seminar indicating what
       this might be about and requirements so forth. But we also include further
       information -- as additional elements:
       <info>http://www.ietf.org/</info>
       <contact>mailto:joe@example.com</contact>
       <contact>mailto:bob@example.com</contact>
       <contact>tel:+49421281</contact>
       <contact>sip:joe@example.com</contact>
       <contact>sip:bob@example.com</contact>
   </session>

3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines)

   The time specification for a session descriptions,
   potential and actual configurations as well follows the same rules as negotiation rules, in
   SDP.  Time specifications are captured usually only meaningful when used in a companion document [1].

3.
   conjunction with SAP and hence are OPTIONAL.  SDPng

   This section introduces the underlying concepts of uses the Session
   Description Protocol - next generation (SDPng) that
   following elements and attributes to specify timing:

   The element "time" is used to meet most
   of indicate a schedule for the above requirements. session;
   time has two optional attributes:

   start: The focus starting time of this section is on the
   concepts of such a capability description and negotiation language
   with a stepwise introduction first occurrence of the various syntactical elements; a
   full formal specification is provided session as
      defined in section 4.

3.1 Conceptual Outline RFC2327.

   end: The description language follows the system model introduced in the
   beginning ending time of this document. We use a rather abstract language to
   avoid misinterpretations due to different intuitive understanding the last occurrence of
   terms as far the session as possible.

   The concept of a capability description language addresses various
   pieces of a full description of system and application capabilities defined
      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 RFC2327.

   The definition 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 time element MAY contain the following elements are labelled with an identifier by which they may be
   referenced. They may but otherwise
   MUST be elementary or compound (i.e. combinations of
   elementary entities). Examples of definitions of that 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 empty:

   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 of more attributes
      OPTIONAL attribute and their
   values. Default values specified no further contents; the attributes are as
      defined in SDP:

      interval: The duration between two start times of the definition section may session.
         This attribute MUST be
   overridden in descriptions for potential (and later actual)
   configurations. A mechanisms present.

      duration: The duration for overriding definitions is specified
   below.

   For which the moment, elementary elements are defined for media types
   (i.e. codecs) and for media transports. For each transport and for session will be active
         starting at each codec to repetition interval.  This attribute MUST be used, the respective attributes need
         present.

      offset: The offset relative to be defined. "start" attribute at which this
         repetition of the session is start.  This definition may either be provided within attribute is
         OPTIONAL; if it is absent, a default value of "0" is assumed.

      Formatting of the "Definitions"
   section itself attribute values MUST follow the rules defined
      in RFC2327.

   zone: The zone element specifies one or more time zone adjustments as
      defined in an external document (similar to the
   audio-video profile RFC2327.  This element MAY have zero or an IANA registry that define payload types
   and media stream identifiers. more
      occurrences in the time element.  It 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>

3.1.4.4 Component Semantic Specification

   Another important session parameter is not required to define all codec, transport mechanisms specify - ideally in a
   definitions sections and reference them in
   machine-readable way but at least understandable for humans - the definition
   function of
   potential and actual configurations. Instead, a syntactic mechanism
   is defined that allows to specify some definitions directly the various components 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 session.  Typically, the
   semantics of these
   default values may be overridden so that the streams are implicitly assumed (e.g.  a codec definition can
   easily be re-used video stream
   goes together with the only audio stream in a different context (e.g. by specifying a
   different sampling rate) without session).  There are,
   however, scenarios in which such intuitive understanding is not
   sufficient and the need semantics must be made explicit.

   <info name="audio-interactive" function="speaker">
       Audio stream for a large number of base
   specifications. In the following different speakers
   </info>

   The above example the shows a simple definition of
   audio-L16-mono is re-used for the defintion of the corresponding
   stereo codec. Appendix A provides semantics for a complete set of corresponding
   audio-codec definitions of
   the codec used in RFC 1890 [4].

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

   The example shows how exisiting defintions can component "interactive-audio".  Further options may be referenced 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 new
   definitiones. This approach allows order to have simple allow for structured extensibility it is
   proposed to rely on a syntax framework that provides concepts as well
   as more
   complex definitions which are commonly used be available in an
   extensible concrete procedures for document validation and extending the set
   of reference documents. Section 3.3 specifies allowed syntax elements.

   SGML/XML technologies allow for the
   mechanisms preparation of Document Type
   Definitions (DTDs) that can define the allowed content models for external references.

   Besides definitions the
   elements of audio codecs there will conforming documents.  Documents can be other definitions
   like RTP payload format and specific transport mechanisms that are
   suitable formally
   validated against a given DTD to check their conformance and
   correctness.  XML DTDs however, cannot easily be defined in a defintion section for later referencing.
   The following example shows how RTP payload extended.  It is not
   possible to alter to content models of element types are defined using
   a pre-defined codec.

   <rtp-pt name="rtp-avp-0" pt="0" format="audio-basic"/>
   <rtp-pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/>

   In this example, or to add new
   element types after the payload type "rtp-avp-11" DTD has been specified.

   For SDPng, a mechanism is defined with
   payload type number 11, referencing needed that allows the codec "audio-L16-mono".
   Instead specification of referencing an existing definition 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 is also possible has to
   define the format "inline":

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

   Note: For negotiation between endpoints, be ensured
   that extensions do not result in name collisions.  Furthermore, it may
   must be helpful to define
   two modes of operation: explicit and implicit. Implicit
   specifications may refer possible for applications that process descriptios documents
   to externally disinguish extensions from base definitions.

   For XML, mechanisms have been defined entities to minimize
   traffic volume, explicit specifications would list all external
   definitions used in a description in the "Definitions" section.
   Again, see Section 3.3 that allow for complete discussion structured
   extensibility of external
   definitions.

   The "Definitions" section may be empty if all transport, codecs, a model of allowed syntax: XML Namespace and
   other pieces needed XML
   Schema.

   XML Schema mechanisms allows to constrain the specify Potential allowed document
   content, e.g.  for documents that contain structured data 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 also
   provide the components possibility that
   constitute document instances can conform to
   several XML Schema definitions at the multimedia conference (IP telephone call, multiplayer
   gaming session etc.). For each same time, while allowing
   Schema validators to check the conformance of these components, the potential
   and, later, documents.

   Extensions of 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. description language, say for allowing to associate semantics with
   express the parameters of a particular new media
   stream. For such type, would require the
   creation of a component, any number corresponding XML schema definition that contains the
   specification of configurations may element types that can be
   given with each configuration describing an alternate way used to realize
   the functionality describe
   configurations of components for 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 new media type.  Session
   description documents have to reference the "Definitions" section non-standard Schema
   module, thus enabling parsers and validators to describe a
   potential or an actual configuration. Within identify the specification elements
   of the configuration, default values from the referenced entities may
   be overwritten.

   Note: Not all protocol environments new extension module and their respective operation
   allow to explicitly distinguish between Potential and Actual
   Configurations. Therefore, SDPng so far does either ignore them (if they are
   not provide for
   syntactical identification of a Configurations as being a Potential supported) or an Actual one.

   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 format="rtp-avp-0">
          <udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp>
       </alt>

       <alt name= AVP-audio-11">
         <rtp format="rtp-avp-11">
          <udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp>
       </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, to consider them for processing the other ("AVP-audio-11") uses
   linear 16-bit encoding. Typically, transport address parameters such
   as
   session/capability description.

   It is important to note that the port number functionality of validating
   capability and session description documents is not necessarily
   required to generate or process them.  For example, endpoints would also
   be provided. In this example, this
   information 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 given
   thus rather motivated by the "udp" element. Of course, it must be
   possible need to specify other transport mechanisms as well. See Section
   3.2 for a discussion of extension mechanisms that allow applications for extensions being
   defined and added to use non-standard transport (or other) specifications.

   During/after the negotiation phase, an actual configuration is
   chosen out of language in a number of alternative potential configurations, structured way that does not
   preclude the
   actual configuration may refer possibility to have applications to identify and process
   the potential configuration just
   by its "id", possibly allowing for some parameter modifications.
   Alternatively, the full actual configuration may be given.

   Instead extensions elements they might support.  The baseline
   specification of referencing existing payload type XML Schema definitions it is also
   possible and profiles must be well-
   defined and targeted to provide the required information "inline". The following
   example illustrates this:

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

   The UDP/IPv4 multicast transport set of parameters that is used in are relevant for
   the examples is a
   simple variant protocols and algorithms of a the Internet Multimedia Conferencing
   Architecture, i.e.  transport specification. More complex ones are
   conceivable. For example, it must also be possible to specify over RTP/UDP/IP, the
   usage audio video
   profile of RFC1890 etc.

   Section 3.3 describes profile definitions and library definition.  A
   detailed definition of source filters (inclusion how the formal SDPng syntax and exclusion), Source Specific
   Multicast, the usage of multi-unicast, or other parameters.
   Therefore it
   corresponding extension mechanisms is possible to extend provided in Section 4.

   The example below shows how the definition of transport
   mechanisms by providing the required information in the element
   content. An example: codecs, transport-
   variants and configuration of components could be realized.  Please
   note that this is not a complete example and that identifiers have
   been chosen arbitrarily.

   <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" format="audio-basic"/>
    <rtp:pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/>

   </def>

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

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

   More transport mechanisms and options

   <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" info="http://www.dmn.tzi.org/ietf/mmusic/">
     This seminar is about SDPng...
     <info>http://www.ietf.org/</info>
     <contact>mailto:joe@example.comg</contact>
     <contact>sip:joe@example.com</contact>
    </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>

   The example does also not include specifications of XML Schema
   definitions or references to such definitions.  This will be defined provided
   in a future
   versions version of this document.

3.1.3 Constraints

   Definitions specify media, transport, and other capabilities,
   whereas configurations indicate which combinations of these could draft.

   A real-world capability description would likely be
   used to provide shorter than the desired functionality in a certain setting.

   There may, however,
   presented example because the codec and transport definitions can be further constraints within a system (such as
   CPU cycles, DSP available, dedicated hardware, etc.)
   factored-out to profile definition documents that limit
   which of these configurations can would only be instantiated
   referenced in parallel (and
   how many instances of these may exist). We deliberately do not
   couple this aspect of system resource limitations capability description documents.

3.3 External Definition Packages

3.3.1 Profile Definitions

   In order to allow for extensibility it must be possible to define
   extensions to the various basic SDPng configuration options.

   For example, if some application semantics as requires the constraints exist across application
   boundaries. Also, in many cases, expressing such constraints is
   simply not necessary (as many uses use of a new esoteric
   transport protocol, endpoints must be able describe their
   configuration with respect to the current SDP show), so
   additional overhead parameters of that transport
   protocol.  The mandatory and optional parameters that can be avoided where this
   configured and negotiated when using the transport protocol will be
   specified in a definition document.  Such a definition document is not needed.

   Therefore, we introduce
   called a "Constraints" section to contain these
   additional limitations. Constraints refer to potential
   configurations and "profile".

   A profile contains rules that specify how SDPng is used to entity definitions and express and use simple
   logic describe
   conferences or endsystem capabilities with respect to express mutual exclusion, limit the number parameters
   of
   instantiations, and allow only certain combinations. the profile.  The following
   example shows concrete properties of the definition profile definitions
   mechanism are still to be defined.

   An example of such a constraints profile would be the RTP profile that restricts defines
   how to specify RTP parameters.  Another example would be the
   maximum number of instantiation of two alternatives (that audio
   codec profiles that defines how specify audio codec parameters.

   SDPng documents can reference profiles and provide concrete
   definitions, for example the definition for the GSM audio codec.
   (This would have
   to be defined done in the configuration "Definitions" 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, contraints are defined by defining limits on
   simultaneous instantiations of alternatives. They are not defined by
   expressing abstract endsystem resources, such as CPU speed or memory
   size.

   By default, the "Constraints" section is empty (or missing) which
   means a SDPng
   document.) A SDPng document that no further restrictions apply.

3.1.4 Session Attributes

   The fourth references a profile and final section provides
   concrete defintions of configurations can be validated against the SDPng syntax addresses session
   layer attributes. These attributes largely include those defined by
   SDP [RFC2327] (which are explicitly indicated in
   profile definition.

3.3.2 Library Definitions

   While profile definitions specify the following
   specification) allowed parameters for a given
   profile SDPng definition sections refer to describe originator, purpose, profile definitions and timing of
   define concrete configurations based on a
   multimedia session among other characteristics. Furthermore, specific profile.

   In order for such definitions to be imported into SDPng
   includes attributes indicating documents,
   there will be the semantics notion of the various
   Components in "SDPng libraries".  A library is a teleconference or other session. This part set of the
   specification
   definitions that is open ended with an IANA registry to be set up conforming to
   register further types of components; only a few of the examples are
   listed here.

   A session-level specification for connection information (SDP "c="
   line), bandwidth information (SDP "b=" line), and encryption keys
   (SDP "k=" lines) certain profile definition (or to
   more than one profile definition -- this needs to be defined).

   The purpose of the library concept is deliberately to allow certain common
   definitions to be factored-out so that not provided every SDPng document has
   to include the basic definitions, for example the PCMU codec
   definition.  SDP [2] uses a similar concept by relying on the well
   known static payload types (defined in SDPng.

   Session level attributes as RFC1890 [4]) that are also
   just referenced but never defined by in SDP still have documents.

   An SPDng document that references definitions from an external
   library has to be examined
   and adopted for SDPng in a future revision declare the use of this specification.

3.1.4.1 Owner the external library.  The owner refers external
   library, being a set of configuration definitions for a given
   profile, again needs to declare the creator use of a session as defined in RFC2327
   ("o=" line). The syntax the profile that it is as follows:

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

   The owner field MUST
   conforming to.

   There are different possibilities of how profiles definitions and
   libraries can be present if SDPng is used with SAP. For all
   other protocols, the owner field MAY be specified. The attributes
   listed above match those from the SDP specification; all attributes
   MUST in SDPng documents:

   o  In an SPDng document, a profile definition can be present referenced and they MUST be created following
      all the rules of
   RFC2327.

   Note: There configuration definitions are several possible ways ahead on this part: "owner"
   could stand as it is right now, but the various values of the
   various attributes could be concatenated (separated by blanks) provided within the
   result being identical document
      itself.  The SDPng document is self-contained with respect to the contents of
      definitions it uses.

   o  In an SPDng document, the SDP "o=" line -- which
   then could use of an external library can be represented as either
      declared.  The library references a single attribute or as
   contents of the "owner" element. Alternatively, the owner element
   could become part of profile definition and the "session" element described below. Or
      SDPng document references the
   contents of library.  There are two alternatives
      how external libraries can be referenced:

      by name: Referencing libraries by names implies the owner element could become an attribute use of the
   "session" element below.

3.1.4.2 Session Identification

   The "session" element a
         registration authority where definitions and reference names
         can be registered with.  It is used to identify conceivable that the session most common
         SDPng definitions be registered that way and to provide that there will be
         a description and possible further references. The following
   attributes are defined:

   name: The session name as it is baseline set of definitions that minimal implementations must
         understand.  Secondly, a registration procedure will be
         defined, that allows vendors to appear e.g. in register frequently used
         definitions with a session
      directory. This is equivalent registration authority (e.g., IANA) and to
         declare the SDP "s=" line. This
      attribute MUST use of registered definition packages in conforming
         SDPng documents.  Of course, care should be present.

   info: A pointer taken not to further information about make
         the session; this
      attribute MUST contain external references too complex and thus require too much a URI. The attribute itself
         priori knowledge in a protocol engine implementing SDPng.
         Relying on this mechanism in general is also problematic
         because it impedes the extensiblity, because it requires
         implementors to provide support for new extensions in their
         products before they can interoperate.  Registration is OPTIONAL.

   The session element MAY contain arbitrary text of any length (but
   authors not
         useful for spontaneous or experimental extensions that are encouraged
         defined in an SDPng library.

      by address: An alternative to keep the inline description brief and
   provide additional information via URLs. This text referencing libraries by name is used to
   provide a description
         declare the use of an external library by providing an address,
         i.e., an URL, that specifies where the session; it library can be obtained.
         While is allows the equivalent use of arbitrary third-party libraries that
         can extend the
   SDP "i=" lines.

   Furthermore, the session element MAY contain other elements basic SDPng set of configuration options in many
         ways there are problems if the
   following types to provide further information about referenced libraries cannot be
         accessed by all communication partners.

   o  Because of these problematic properties of external libraries, the session and
   its creator:

   info: The info element is intended
      final SDPng specification will have to provide a pointer to further
      information on the session itself. Its contents MUST be exactly
      one URI. If both the info attribute and one or more info elements
      are present, the union of the respective values is used. Info
      elements are OPTIONAL, they MAY be repeated any number set of times.

   contact: The contact element provides contact information on
      recommendations under which circumstances the
      creator different mechanisms
      of the session; its contents MUST externalizing definitions should be exactly one URI. Any
      URI scheme suitable used.

3.4 Mappings

   A mapping needs to be defined in particular to SDP that allows to
   translate final session descriptions (i.e.  the result of capability
   negotiation processes) to reach SDP documents.  In principle, this can be
   done in a person or rather schematic fashion for the basic definitions.

   Furthermore, to accommodate SIP-H.323 gateways, a group of persons is
      acceptable (e.g. sip:, mailto:, tel:). Contact elements are
      OPTIONAL, they MAY be repeated any number of times.

   <session name="An mapping from SDPng seminar" info="http://www.dmn.tzi.org/ietf/mmusic/">
       And here comes
   to H.245 needs to be specified at some point.

4. Formal Specification

4.1 XML Schema as a long description Definition Mechanism

   SDPng document reference profile schema definitions and libraries.
   Profile schema definitions contain schema definitions of SDPng
   document elements.  For example, the seminar indicating what
       this might be about general structure is specified
   by a schema definition and so forth. But we also include further
       information -- extensions to SDPng for specific
   applications are specified as additional elements:
       <info>http://www.ietf.org/</info>
       <contact>mailto:joe@example.com</contact>
       <contact>mailto:bob@example.com</contact>
       <contact>tel:+49421281</contact>
       <contact>sip:joe@example.com</contact>
       <contact>sip:bob@example.com</contact>
   </session>

3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) schema definitions as well.

   The time baseline SDPng specification for consists of a session follows the same rules as in
   SDP. Time specifications are usually only meaningful when used in
   conjunction with SAP profile (a schema
   definition) and hence are OPTIONAL. a library of commonly used definitions.

   SDPng uses XML-Schema [15][16] for defining the possible logical
   structures of SDPng documents for the following elements and attributes reasons:

   Extensibility: XML-Schema provides mechanisms that allow to specify timing:

   The extend
      exisiting definitions allowing to uniquely identify element "time" is used types
      (by relying on XML namespaces [13]).

   Modularity: XML-Schema provide mechanisms that allow to indicate a schedule for the session;
   time has two optional attributes:

   start: The starting time of the first occurrence organize
      schema definitions in multiple components.

   Expressiveness: XML-Schema provides many data types, that can be
      refined by user-supplied definitions.

   SDPng documents are schema instances of the session as
      defined in RFC2327.

   end: SDPng schema.  The ending time of the last occurrence
   following example shows, how a Schema definition can be referenced in
   a document instance.

   Beginning of the session as an SDPng-document:

   <?xml version="1.0" ?>
   <sdpng:desc xmlns:sdpng="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 will be defined in RFC2327.

   The time element MAY contain the following elements but otherwise
   MUST
   for this purpose (it has to be empty:

   repeat: This element specifies decided later which namespace name to
   use -- this can be a URI, as in the repetition pattern example, or a URN).  It is
   proposed that a commonly used namespace prefix is used (e.g.  fixed
   to "sdpng") for the
      schedule. There MAY SDPng schema definition.

   It will be zero or more occurrences worked-out, how much of this element
      within initial declaration can be
   added implicitely by applications, so that declarations like the time element.  "repeat" has two MANDATORY and one
      OPTIONAL attribute and no further contents; the attributes are as
      defined
   above do not have to be included in SDP:

      interval: every description document.

4.2 SDPng Schema

   The duration between two start times of basic SDPng schema definitions specifies the session.

         This attribute MUST be present.

      duration: The duration general document
   structures, e.g., "definitions" sections followed by "configurations"
   sections, followed by "constraints" sections followed by a "conf"
   section (for meta-information).

   It also specifies "abstract" base data types (by means of XML-Schema
   type definitions) for which the session will be active
         starting at each repetition interval. This attribute MUST elements that should be
         present.

      offset: The offset relative to "start" attribute at which this
         repetition of used by documents in
   the session is start. This attribute is
         OPTIONAL; if it is absent, corresponding sections.  The base data types can provide common
   required attributes, e.g.  a default value of "0" is assumed.

      Formatting "name" attribute for naming definition
   elements.

   The following example shows the definition of the attribute values MUST follow base type for
   definition elements:

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

   Profiles can then define concrete types that augment the rules base type
   definitions.  Common attributes or content models, that have been
   defined
      in RFC2327.

   zone: by this base definition, do not have to be provided by those
   concrete type definitions.  The zone element specifies one or more time zone adjustments type definitions can be identified as defined in RFC2327. This
   allowed element MAY have zero or more
      occurrences in types for the time element. It has two attributes as defined content models that are specified 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>

3.1.4.4 Component Semantic Specification

   Another important session parameter is to specify - ideally in a
   machine-readable way but at least understandable base SDPng schema definition.  This allows for humans - the
   function automatic
   validation of profile definitions and faciliates the various components in extension of
   SDPng.

4.3 Profiles

   The baseline SDPng specification consists of a session. Typically, the
   semantics profile (a schema
   definition) and a library of the streams are implicitly assumed (e.g. commonly used definitions.

   The library of commonly used definitions provides data types for IP
   (or other) addresses etc.  Details have to be provided at a video stream
   goes together with later
   time.

   A profile definition imports (using the only audio stream in a session). There are,
   however, scenarios in which such intuitive understanding is not
   sufficient XML-Schema import mechanism)
   the base SDPng schema definition and provided extension definition,
   e.g., specializations of base element types.  They also provide a
   target namespace name for the semantics must definitions of the corresponding
   profile.  For well-known (registered) profiles the namespace name
   will be made explicit.

   <info name="audio-interactive" function="speaker">
       Audio stream registered by IANA.  Proprietary profiles will use other
   namespace names, for the different speakers
   </info> example, based on domain names, that are
   registered by vendors providing a profile.

   The above following example shows such a simple definition of declaration at the semantics for beginning of a
   the component "interactive-audio". 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
   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">
     </xsd:import>

   In order to allow for this example the possibility to validate session
   descriptions namespace prefix "audio" is defined and later
   used in order to allow for structured extensibility it
   is proposed to rely on a syntax framework that schema definitions.  (The example profile provides concepts as
   well as concrete procedures for document validation and extending
   the set of allowed syntax elements.

   SGML/XML technologies allow definition
   mechanisms for the preparation of Document Type
   Definitions (DTDs) that can define the allowed content models audio codecs.)

   The following example shows, how a derived type for
   the "definition"
   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 after specified with XML-Schema mechanisms.  In this case
   the DTD has been specified.

   For SDPng a mechanism abstract type "Definition" (fully qualified as
   "sdpng:Definition") is needed augemented by three attributes that allows are useful
   for defining audio codecs.

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

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

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

   When used by SDPng documents, the specification of general identifier is qualified
   with a
   base syntax -- namespace prefix, for example basic elements for the high level
   structure of description like in: "audio:codec".

4.4 SDPng Documents

   SDPng documents -- while allowing extensions, for
   example elements have to reference the employed profiles and attributes provide
   namespace prefixes for new transport mechanisms, new
   media types etc. to added on demand. Still, it has to be ensured the namespace names of the profiles.  For
   example:

   <sdpng:desc xmlns:sdpng="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"
   >

   It is proposed that extensions do not result in name collisions. Furthermore, it
   must be possible for applications that process descriptios documents well-known registered profiles, the namespace
   name AND the used namespace prefix is registered to disinguish extensions from base definitions.

   For XML, mechanisms have been defined that allow for structured
   extensibility of a model simple
   basic implementations that can match identifiers by using fixed fully
   qualified names without having to interpret namespace declarations.
   There is one issue with declaring used XML-Schema definitions in
   documents (see section "Issues" below).

   The general structure of allowed syntax: XML Namespace and XML
   Schema.

   XML Schema mechanisms allows an SDPng would conform to constrain the allowed document
   content, e.g. for documents that contain structured data basic SDPng
   schema definition and also provide a "def" element for definitions, a
   "cfg" element for the possibility that document instances can conform to
   several XML Schema definitions at the same time, while allowing
   Schema validators to check configuration section etc.

   The following example shows a sample definition section where the conformance of these documents.

   Extensions
   element "codec" of the session description language, say for allowing to
   express "audio codec profile" is used (plus the parameters
   element type "pt" of a new media type, would require 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" format="g729"/>
       </def>

   It can be seen how the
   creation of a corresponding XML schema attribute name (provided by the base type for
   definition that contains elements) and the
   specification of profile specific attributes "encoding",
   "channels" and "sampling" are used together.

   The element types that can be "rtp:pt" is used to describe
   configurations of components for the new media defined a payload type. Session
   description documents  "rtp:pt"
   would have to reference been defined in another profile, again using a type
   derived from the non-standard Schema
   module, thus enabling parsers and validators to identify base definition type.  "rtp:pt" provides attribute
   for referencing other definitions, e.g., the
   elements definition of the new extension module and to either ignore them (if
   they audio-
   codes as seen before.

4.5 Libraries

   SDPng libraries are not supported) or to consider them for processing the
   session/capability description.

   It is important to note collections of definitions that are referenced by
   documents.  Libraries are thus independent, valid SDPng documents.

   For example, the functionality definition of validating
   capability and session description the different audio codecs as shown in
   the previous example could be provided by a library that can be
   referenced by documents is not necessarily
   required without having to generate or process them. For example, endpoints would define such common codecs
   in every document.

   The XML mechanism XIncludes [14] will be configured used for referencing
   libraries in SDPng documents.  XInlcude work at the "infoset" level,
   i.e.  the mechanisms allows to understand only those parts of description have an integrating document reference
   fragment document, while these fragment are well-formed (and, if
   applicable valid) document themselves.  By resolving XInclude
   directives in integrating documents that the documents' infosets are conforming
   "merged" together, enabling applications to operate on the baseline specification and
   simply ignore extensions they cannot support. The usage of XML and
   XML Schema is thus rather motivated resulting
   infosets as if it had been generated by parsing a single, monolithic
   document.

   Inclusion at the need to allow for
   extensions being defined and added XML infoset level has the advantage that documents
   are standalone -- they can be validated independently.  Another
   advantage is that is relatively easy to the language in generate a structured
   way "merged" infoset
   for applications that does are not preclude the possibility able to have applications resolve references to
   identify and process the extensions elements they might support. The
   baseline specification of XML Schema definitions and profiles must libraries
   themselves.

   An alternative for XInclude would be well-defined and targeted to the set of parameters use references that are
   relevant for the protocols and algorithms of the Internet Multimedia
   Conferencing Architecture, i.e. transport over RTP/UDP/IP,
   resolved by applications.  For XML, this would probably mean to use
   an XLink-based approach.  This solution would require the audio
   video profile of RFC1890 etc.

   Section 3.3 describes profile definitions and library definition. A
   detailed definition
   of how the formal an SDPng syntax link element type and the
   corresponding extension mechanisms is require applications to be provided in future
   versions of this document.

   The example below shows how the definition of codecs,
   transport-variants and configuration of components could be
   realized. Please note that this is not a complete example and that
   identifiers have been chosen arbitrarily.

   <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" format="audio-basic"/>
    <rtp-pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/>

   </def>

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

       <alt name= AVP-audio-11">
         <rtp format="rtp-avp-11">
          <udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp>
       </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" info="http://www.dmn.tzi.org/ietf/mmusic/">
     This seminar is about SDPng...
     <info>http://www.ietf.org/</info>
     <contact>mailto:joe@example.comg</contact>
     <contact>sip:joe@example.com</contact>
    </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 support
   XLink (or at least the different speakers
    <info>

   </conf> SDPng-relevant subset thereof).  The example inclusion
   at the application level is however problematic, because it does also not include specifications of
   result in a common integrated XML Schema
   definitions or references document infoset but would require
   applications to handle multiple infosets, i.e.  multiple documents.

   More details on library inclusion plus an example have to such definitions. This will be provided
   in
   at a future version of this draft.

   A real-world capability description would likely be shorter than later time.

4.6 Details on the
   presented example because use of specific XML Mechanisms

   This section specifies the codec use of specific XML mechanisms for SDPng.
   In order to allow for efficient parsing and transport definitions processing, not all
   features of XML Schema are allowed.  Some variable information is set
   to fixed values to allow the development of simplistic servers.

4.6.1 Default Namespace

   SDPng document instances MUST use the SDPng namespace
   "http://www.iana.org/sdpng" (tentative).  That means, the general
   SDPng identifiers can be
   factored-out used without namespace prefix.

4.6.2 Qualified Locals

   XML Schema allows to profile specify qualification of elements and
   attributes.  It is possible to use non-qualified element and
   attribute names in Schema definitions and document instances (this is
   the default setting).  In order to simplify parsing and processing of
   SDPng document instances, all element MUST be fully qualified.
   Attribute names MUST NOT be fully qualified.

   This means, the SDPng Schema definition documents contains the following
   attributes for the "schema" element, that would only MUST also be
   referenced in capability description documents.

3.3 External Definition Packages

3.3.1 Profile Definitions used by SDPng
   profiles:

   o  elementFormDefault="qualified"
      This means that "local" elements that used within the scope of
      fully-qualified elements MUST be fully qualified.

   o  attributeFormDefault="unqualified"
      This means, that attribute names do not have to be fully
      qualified.  Implementations MUST infer the namespace for
      attributes from the namespace of the element that the attribute is
      used in.  Note that the specification of XML Namespaces [13]
      defines that default namespaces do not apply to attributes.

   These rules make SDPng document instances processable by non-Schema-
   aware XML parsers by requiring all element names to be fully
   qualified (no "local elements").

4.6.3 Fixed Namespace Prefixes

   In order to allow for extensibility it must facilitate the development of basic implementations, a
   few commonly namespaces names may be associated with fixed prefixes,
   i.e.  document instances and libraries MUST always use these
   prefixes.  Theses prefixes MUST NOT be used for other namespaces
   names than the ones that are assigned to them.  A possible solution
   could be to define
   extensions provide the possibility to register namespace prefixes as
   well as namespace names.

   The tentative prefix for the basic SDPng configuration options.

   For example if some application requires the use namespace is "sdpng".

4.7 SDPng Schema Definitions

   This section provides an initial set of SDPng XML Schema definitions.

   1.  Section 4.7.1 contains the base definition that provide the
       general element types for SDPng.

   2.  Section 4.7.2 contains a new esoteric
   transport protocol endpoints must be able describe their
   configuration with respect to profile for audio codecs.

   3.  Section 4.7.3 contains a profile for RTP payload type
       definitions.

4.7.1 SDPng Base Definition

   This schema definition defines the parameters general structure of SDPng
   document instances.  It defines the top-level element type "desc"
   that transport
   protocol. The mandatory can have a sequence of "def", "cfg", "contraints" and optional parameters "conf"
   elements as element content.

   In addition, "extensions hooks" are provided that can be
   configured used by
   extension profiles providing definitions for specific applications.
   In general, these extension are implemented by deriving profile
   definitions from SDPng base definitions.  The deployed XML Schema
   mechanisms are "deriving by extension" and negotiated when using the transport protocol will be
   specified in a definition document. Such a "substitution groups".
   The SDPng base definition document is
   called a "profile".

   A profile contains rules provides different base types (as
   complexType definitions) for elements that specify how SDPng is used are to describe
   conferences or endsystem capabilities be used in "def",
   "cfg" and "conf" sections.  In addition, it also defines specific
   element types as "head elements" with respect to assigned types that are used
   for defining the content model of, e.g., the "def" element type.

   Profiles that provide new element types for specific applications
   will define types that are derived from the parameters
   of base types and provide
   the profile. The concrete properties of additional attributes and element content definitions that are
   required for the application.  The XML element types that are defined
   in a profile definitions
   mechanism are still declared as valid subsitutes for the base elements
   ("head elements") by setting the "substitutionGroup" attribute to be defined.

   An example the
   name of such the "head element" type.

   For an extension-profile definition, that defines new definition
   element types, e.g.  for codec definitions, a profile new complexType would
   be the RTP profile defined that defines
   how extends sdpng:Definition (see below).  An element
   type definition that assigns that new type must then be declared to specify RTP parameters. Another example would
   be in the audio
   codec substitutionGroup "sdpng:d".

   This mechanism allows common attribute and content model rules to be
   defined in base element definition and re-used by extension profiles
   and it also allows validating parsers to identify the correct type of
   elements that have been defined by profile definitions.

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

     <xsd:annotation>
       <xsd:documentation>
         This schema definition defines how specify audio codec parameters. the general structure of SDPng documents can reference profiles
         document instances. It provides base type and provide concrete
   definitions, base element
         definition for example elements to occur in the different sections (def,
         cfg, constraints, conf) to be derived from in extension-profile
         definitions.

         For an extension-profile definition, that defines new definition
         element types, e.g. for the GSM audio codec.
   (This codec definitions, a new complexType would
         be done defined that extends sdpng:Definition (see below). An element
         type definition that assigns that new type must then be declared
         to be in the "Definitions" section substitutionGroup "sdpng:d".
       </xsd:documentation>
     </xsd:annotation>

     <xsd:element name="desc">
       <xsd:annotation>
         <xsd:documentation>
   	The top-level element of a SDPng
   document.) A an SDPng document that references a profile and provides
   concrete defintions of configurations can be validated against document. It defines the
   profile definition.

3.3.2 Library Definitions

   While profile
   	overall structure of 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 specify the allowed parameters section</xsd:documentation>
       </xsd:annotation>
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:d" 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:c" 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:cn" 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="d" type="sdpng:Definition">
       <xsd:annotation>
         <xsd:documentation>
   	Placeholder base element for a given
   profile SDPng definition sections refer to profile element in the
   	definitions and
   define concrete configurations based on a section. To be derived from by specific profile.

   In order definition
   	element type definitions.
         </xsd:documentation>
       </xsd:annotation>
     </xsd:element>

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

     <xsd:element name="c" type="sdpng:Component">
       <xsd:annotation>
         <xsd:documentation>
   	Placeholder base element for such definitions to be imported into SDPng documents,
   there will a configuration element in the
   	configurations section. To be derived from by specific
   	configuration element type definitions.
         </xsd:documentation>
       </xsd:annotation>
     </xsd:element>

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

     <xsd:element name="cn" type="sdpng:Constraint">
       <xsd:annotation>
         <xsd:documentation>
   	Placeholder base element for a contraint element in the notion
   	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>
   	The base type for definition. Defines a attribute "name" for
   	naming definitions.
         </xsd:documentation>
       </xsd:annotation>
       <xsd:attribute name="name" type="xsd:string"/>
     </xsd:complexType>

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

     <xsd:complexType name="Component" mixed="false">
       <xsd:annotation>
         <xsd:documentation>
   	The specification of "SDPng libraries". A library is a set component consists of
   definitions that is conforming to a certain profile definition (or
   to more than one profile definition -- this needs to be defined).

   The purpose sequence of the library concept
   	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 a "sc" (session configuration)
   	element. The "sc" element is to allow certain common
   definitions to be factored-out so a base element of base type
   	"sdpng:Session" that not every SDPng document has is used to include the basic definitions, for example the PCMU codec
   definition. SDP [2] uses a similar concept by relying on the well
   known static payload derive specific session types (defined in RFC1890 [4]) that are also
   just referenced but never defined
   	in SDP documents.

   An SPDng document that references definitions extension profiles.
         </xsd:documentation>
       </xsd:annotation>
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:sc" minOccurs="1" maxOccurs="1"/>
         </xsd:sequence>
         <xsd:attribute name="name" type="xsd:string"/>
       </xsd:complexType>
     </xsd:element>

     <xsd:element name="sc" type="sdpng:SessionConfig"/>

     <xsd:complexType name="SessionConfig" abstract="true" mixed="false">
       <xsd:annotation>
         <xsd:documentation>
   	The (abstract) base type for session elements. To be derived
   	from an external
   library has to declare the use of the external library. in extension profiles.
         </xsd:documentation>
       </xsd:annotation>
     </xsd:complexType>

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

     <xsd:complexType name="Constraint" mixed="false">
       <xsd:annotation>
         <xsd:documentation>
   	The external
   library, being current content model for constraints is a set sequence of configuration definitions for
   	"sdpng:par" elements. In each "par" element a given
   profile, again needs to declare the use sequence of
   	"use-alt" elements may be used to specific the profile that it is
   conformant to.

   There are different possibilities of how profiles definitions and
   libraries can be
   	that may used in SDPng documents:

   o  In an SPDng document a profile definition parallel. Each "use-alt" element can be referenced and
      all the configuration definitions are provided within define
   	the
      document itself. number of minimum 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 SDPng document base type for conference meta inforformation
   	element. Currently, there is self-contained with
      respect to the definitions it uses.

   o  In an SPDng document the use of 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="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: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">
   	      <xsd:complexType mixed="false">
   		<xsd:attribute name="href" type="xsd:string"/>
   	      </xsd:complexType>
   	    </xsd:element>
   	    <xsd:sequence minOccurs="0">
   	      <xsd:element name="contact" type="xsd:string"/>
   	    </xsd:sequence>
   	  </xsd:sequence>
   	</xsd:extension>
         </xsd:complexContent>
       </xsd:complexType>
     </xsd:element>
   </xsd:schema>

4.7.2 Audio Codec Profile

   The following profile defines an external library element type that can be
      declared. used for
   specifying audio codec characteristics.  The library references a profile definition and element "audio:codec" is
   of type "audio:AudioCodec" which is derived from the SDPng document references the library. There are two alternatives
      how external libraries can be referenced:

      by name: Referencing libraries by names implies base type
   "sdpng:Definition".  The element "audio:codec" is declared to have
   the use subsitution group "sdpng:d" (the "head element" of a
         registration authority where definitions and reference names
         can be registered with. It is conceivable that the most common SDPng definitions base
   definition).

   This means, "audio:codec" element can be registered that way and that there used as child elements in
   "sdpng:def" elements.  In addition to the attributes specified here
   "audio:codec" elements will
         be a baseline set of definitions that minimal implementations
         must understand. Secondly, also have to provide a registration procedure will "name" attribute
   as defined 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 the abstract type "Definition" -->
     <!-- The data types for the attributes could be
         defined, 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:d">
       <xsd:complexType>
         <xsd:complexContent>
   	<xsd:extension base="audio:AudioCodec"/>
         </xsd:complexContent>
       </xsd:complexType>
     </xsd:element>
   </xsd:schema>

4.7.3 RTP profile

   The following profile defines element types that allows vendors to register frequently can be used
         definitions with a registration authority (e.g., IANA) for
   specifying RTP payload types and to
         declare the use RTP session configurations.  The
   element "rtp:pt" is of registered definition packages in
         conforming type "rtp:PayloadType" which is derived from
   the SDPng documents. Of course, care should be taken
         not base type "sdpng:Definition".  The element "rtp:pt" is
   declared to make have the external references too complex and thus
         require too much a priori knowledge in a protocol engine
         implementing SDPng. Relying on this mechanism in general subsitution group "sdpng:d" (the "head element"
   of the SDPng base definition).

   The element "rtp:session" is
         also problematic because it impedes of type "rtp:Session" which is derived
   from the extensiblity, because
         it requires implementors SDPng base type "sdpng:SessionConfig".  The element
   "rtp:session" is declared to provide support for new extensions have the subsitution group "sdpng:sc"
   (the "head element" of the SDPng base definition).

   The RTP profile in their products before they can interoperate. Registration
         is not useful turn defines base types for spontaneous or experimental extensions the specification of
   transport parameters that are defined in an SDPng library.

      by address: An alternative to referencing libraries be derived from by name is profiles that
   define rules for elements that can be used to
         declare specifiy parameters 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 use of an external library by providing an
         address, i.e., element for payload type definitions is
   	derived from "sdpng:Definition". Inside an URL, that specifies where the library can element of this
   	type, more definitions may be
         obtained. While given (derived from
   	sdpng:Definition themselves). If no definition is allows given in the use of arbitrary third-party
         libraries that
   	content, a definition may be referenced using the "format
   	attribute".
         </xsd:documentation>
       </xsd:annotation>
       <xsd:complexContent mixed="false">
         <xsd:extension base="sdpng:Definition">
   	<xsd:sequence>
   	  <xsd:element ref="sdpng:d" minOccurs="0" maxOccurs="unbounded"/>
   	</xsd:sequence>
   	<xsd:attribute name="pt" type="xsd:unsignedByte"/>
   	<xsd:attribute name="format" type="xsd:string">
   	  <!-- IDREF? Issue: unique names for definitions!-->
   	</xsd:attribute>
         </xsd:extension>
       </xsd:complexContent>
     </xsd:complexType>

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

   <!-- ______________________________________________________________________ -->

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

     <xsd:complexType name="Session" mixed="false">
       <xsd:complexContent mixed="false">
         <xsd:extension base="sdpng:SessionConfig">
   	<xsd:sequence>
   	  <xsd:element name="transport" type="rtp:Transport"/>
   	</xsd:sequence>
   	<xsd:attribute name="format" type="xsd:string"/>
         </xsd:extension>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:complexType name="Transport" abstract="true" mixed="false">
       <xsd:attribute name="rtp-port" type="xsd:unsignedShort" use="optional"/>
       <xsd:attribute name="rtcp-port" type="xsd:unsignedShort" use="optional"/>
     </xsd:complexType>

     <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"/>
   </xsd:schema>

4.8 Issues

   o  Libraries provide partially specified definitions, i.e.  without
      transport parameters.  How can extend the basic SDPng set of configuration
         options in many ways there are problems if documents reference the referenced
         libraries cannot be accessed by all communication partners.
      definitions and augment them with conrete transport parameters?

   o  Because of these problematic properties  Referencing extension profiles: XML-Schema does not support the
      declaration of external libraries, multiple schemas via the schemaLocation attribute.
      Conceivable solution: When extension profiles are used, the final SDPng specification will have to provide
      description is a set "multi-part" object, that consists of
      recommendations under which circumstances an
      integrating schema definition (that references all necessary
      profiles and the different
      mechanisms of externalizing definitions should be used.

3.4 Mappings

   A mapping needs to be defined in particular to SDP base definition) and the actual description
      document that allows to
   translate final session descriptions (i.e. is a schema instance of the result integrating schema.

   o  Uniqueness of capability
   negotiation processes) attribute values: When libraries are used they will
      contain definition elements with "name" attributes for later
      referencing.  How to SDP documents. In principle, this can avoid name clashes for those identifiers?
      When an SDPng document uses libraries from different sources they
      could be
   done in a rather schematic fashion.

   Furthermore, to accommodate SIP-H.323 gateways, incompatible because of name collisions.  Possible
      solution: Prefix such IDs with a mapping from SDPng
   to H.245 needs to namespace name (either
      explicitely or implicitely by interpreting applications).  The
      explicit prefixes have the advantage that no special knowledge
      would be specified required to ressolve links at some point.

4. Formal Specification

   To be provided. the cost of very long ID
      values.

5. Use of SDPng in conjunction with other IETF Signaling Protocols

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

   For the means conceivable to realize a particular Component, SDPng
   conceptually distinguishes three levels of support:

      a Capapility 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
      teleconference.

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

      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.

5.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 announcements 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 Capabiities 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.

5.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 paylaod 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 Examples to be defined.

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

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

6. Open Issues

      The precise sytnax for referencing profiles and libraries needs to
      be worked out.

      A registry (reuse of SDP mechanisms and names etc.) needs to be
      set up.

      Transport and Payload type specifications need to be defined as
      additional appendices.

      Negotiation mechanisms for multiparty conferencing need to be
      formalized.

      Further details on the signaling protocols need to be filled in.

      Mapping to other media description formats (SDP, H.245, ...)
      should be provided.  For H.245, this is probably a different
      document (beloning to the SIP-H.323 interworking group).

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", Internet-Draft
        draft-ietf-avt-profile-new-10.txt , draft-ietf-avt-profile-new-
         10.txt  (work in progress), March 2001.

   [6]   Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
         M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP
         Payload for Redundant Audio Data", RFC 2198, September 1997.

   [7]   Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
         2533, March 1999.

   [8]   Klyne, G., "Protocol-independent Content Negotiation
         Framework", RFC 2703, September 1999.

   [9]   Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
         Generic Forward Error Correction", RFC 2733, December 1999.

   [10]  Perkins, C. and O. Hodson, "Options for Repair of Streaming
         Media", RFC 2354, June 1998.

   [11]  Handley, M., Perkins, C. and E. Whelan, "Session Announcement
         Protocol", RFC 2974, October 2000.

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

   [13]  World Wide Web Consortium (W3C), "Namespaces in XML", Status
         W3C Recommendation, Version http://www.w3.org/TR/1999/REC-xml-
         names-19990114, January 1999.

   [14]  World Wide Web Consortium (W3C), "XML Inclusions (XInclude)
         Version 1.0", Status W3C Working Draft, Version
         http://www.w3.org/TR/2001/WD-xinclude-20010516, May 2001.

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

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

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. Base SDPng Specifications for Audio Codec Descriptions

   [5] specifies a number of audio codecs including short name to be
   used as reference by session description protocols such as SDP and
   SDPng.  Those codec names, as listed in the first column of the above
   table, are used to identify codecs in SDPng.

   The following sections indicate the default values that are assumed
   if nothing else than the codec reference is specified.

   The following audio-codec audio:codec attributes are defined for audio codecs:

   name: the identifier to be later used for referencing the codec spec

   encoding: the RTP/AVP profile identifier as registered with IANA

   mime: the MIME type; may alternatively be specified instead of
      "encoding"

   channels: the number of independent media channels

   pattern: the media channel pattern for mapping channels to payload

   sampling: the sample rate for the codec (which in most cases equals
      the RTP clock)

   Furthermode, options may be defined of the following format:

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

   if a value is associated with the option (note that arbitrary complex
   values are allowed), or alternatively:

   <option id="name"/>

   if the option is just a boolean indicator.

   Attributes for the "option" tag are the following:

   id: the identifier for the option (variable name)

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

      min: for numeric values only

      max: for numeric values only
      x: intersection of enumerated values, value lists

A.1 DVI4

   <audio-codec

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

   <rtp-pt

   <rtp:pt name="rtp-avp-5" pt="5" format="dvi4"/>
   <rtp-pt
   <rtp:pt name="rtp-avp-6" pt="6">
       <audio-codec
       <audio:codec encoding="DVI4" channels="1" sampling="16000">
   </rtp-pt>
   </rtp:pt>

   Note that there is no default sampling rate specified for DVI4 and
   hence a sampling rate MUST be specified.

A.2 G.722

   <audio-codec

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

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

A.3 G.726

   <audio-codec

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

   <rtp-pt

   <rtp:pt name="rtp-avp-5" pt="5" format="g726-32"/>

A.4 G.728

   <audio-codec

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

A.5 G.729

   G.729 Annex A: reduced complexity of G.729
   G.729 Annex B: comfort noise

   <audio-codec

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

   For further codec description, the following options (which carry no
   values associated with them) MAY be included:

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

   <option id="annexB"/>
   <!-- to indicate the use of Annex B comfort noise -->

   As stated in [5], the use of these options can be detected within the
   media stream.

A.6 G.729 Annex D and E

   <audio-codec

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

   The following option MAY be used with both Annexes D and E:

   <option id="annexB"/>
   <!-- to indicate the use of Annex B comfort noise -->

A.7 GSM

A.7.1 GSM Full Rate

   The GSM Full Rate codec is indicated as follows:

   <audio-codec

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

A.7.2 GSM Half Rate

   The GSM Half Rate codec is indicated as follows:

   <audio-codec

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

A.7.3 GSM Enhanced Full Rate

   The GSM Enhanced Full Rate codec is indicated as follows:

   <audio-codec

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

A.8 L8

   <audio-codec

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

A.9 L16

   <audio-codec

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

   <rtp-pt

   <rtp:pt name="rtp-avp-11" pt="11" format="gsm"/>
   <rtp-pt
   <rtp:pt name="rtp-avp-10" pt="11" format="gsm">
     <audio-codec
     <audio:codec encoding="L16" channels="2" sampling="8000"/>
   </rtp-pt>
   </rtp:pt>

A.10 LPC

   <audio-codec

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

A.11 MPA

   <audio-codec

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

A.12 PCMA and PCMU

   <audio-codec

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

   <rtp-pt

   <rtp:pt name="rtp-avp-0" pt="0" format="pcmu"/>
   <rtp-pt
   <rtp:pt name="rtp-avp-8" pt="8" format="pcma"/>

A.13 QCELP

   <audio-codec

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

A.14 VDVI

   <audio-codec

   <audio:codec name="vdvi" encoding="VDVI" channels="1" sampling="8000"/>

Appendix B. Change History

   draft-ietf-mmusic-sdpng-02.txt

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

   draft-ietf-mmusic-sdpng-01.txt

      *  renamed section "Syntax Propsal" 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 Atrributes" replaces section "Session"

      *  new appendix on audio codec definitions

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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 implmentation 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 Editor function is currently provided by the
   Internet Society.