mmusic                                                          Kutscher
Internet-Draft                                                       Ott
Expires: April 26, 2004 August 21, 2005                                         Bormann
                                                TZI, Universitaet Bremen
                                                        October 27, 2003
                                                       February 20, 2005

             Session Description and Capability Negotiation
                     draft-ietf-mmusic-sdpng-07.txt
                     draft-ietf-mmusic-sdpng-08.txt

Status of this Memo

   This document

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is an Internet-Draft aware
   have been or will be disclosed, and is any of which he or she becomes
   aware will be disclosed, in full conformance accordance with
   all provisions of Section 10 of RFC2026. RFC 3668.

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

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The
   http://www.ietf.org/ietf/1id-abstracts.txt

   To view the list of Internet-Draft Shadow Directories can be accessed at Directories, see
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2004.

Copyright Notice

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

Abstract

   This document defines a language for describing multimedia sessions
   with respect to configuration parameters and capabilities of
   end-systems. The description language is independent of specific
   application scenarios (session announcement, session setup for
   interactive communication etc.) and is not limited to specific media
   types, capabilities, or configuration parameters.

   This document is a product of the Multiparty Multimedia Session
   Control (MMUSIC) working group of the Internet Engineering Task
   Force. Comments are solicited and should be addressed to the working
   group's mailing list at mmusic@ietf.org and/or the authors.

Document Revision

   $Revision: 6.18 6.21 $

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4  3
   2.    Terminology and System Model . . . . . . . . . . . . . . . .  6  7
   3.    Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11
   3.1   Outline of the Negotiation Process . . . . . . . . . . . . . 10 11
   3.2   Capability   SDPng Data Types . . . . . . . . . . . . . . . . . . . . . . 12 13
   3.3   Application-specific Vocabulary  . . . . . . . . . . . . . . 14 15
   4.    SDPng Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 16
   4.1   SDPng Base Syntax  . . . . . . . . . . . . . . . . . . . . . 15 16
   4.2   Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 17 18
   4.2.1 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 19
   4.2.2 Token Sets . . . . . . . . . . . . . . . . . . . . . . . . . 18 19
   4.2.3 Numerical Values . . . . . . . . . . . . . . . . . . . . . . 18 19
   4.2.4 Numerical Ranges . . . . . . . . . . . . . . . . . . . . . . 18 19
   4.2.5 Sample SDPng cap Element . . . . . . . . . . . . . . . . . . 19 20
   4.2.6 Referencing Capability Elements  . . . . . . . . . . . . . . 20 21
   4.3   Definitions  . . . . . . . . . . . . . . . . . . . . . . . . 20 21
   4.4   Configurations . . . . . . . . . . . . . . . . . . . . . . . 22 23
   4.5   Constraints  . . . . . . . . . . . . . . . . . . . . . . . . 24 25
   4.6   Session Information  . . . . . . . . . . . . . . . . . . . . 24 25
   4.7   Summary of SDPng XML-Syntax  . . . . . . . . . . . . . . . . 24 26
   5.    Specification    Usage of the Capability Negotiation  . . . SDPng in Different Application Scenarios  . . . . . 26 28
   5.1   Offer/Answer . . . . . . . . .   Broadcast/Announcement Scenarios . . . . . . . . . . . . . . . 26 28
   5.2   RFC2533 Negotiation  . . . . . . . . . . . .   Real-Time-Streaming  . . . . . . . . 28
   5.2.1 Translating SDPng to RFC 2533 Expressions . . . . . . . . . 28
   5.2.2 Applying RFC 2533 Canonicalization . . . . . . 29
   5.3   Two-Way Session Setup  . . . . . . . 31
   5.2.3 Integrating Feature Sets into SDPng . . . . . . . . . . . . 31
   5.2.4 Processing
   5.4   Multi-Party-Conferencing with Negotiation Results . . .  . . . . . . . . . . . . 32 38
   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 33 39
   7.    Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . 34 40
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 41
         References . . . . . . . . . . . . . . . . . . . . . . . . . 36 42
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 43
   A.    Formal Syntax Specifications . . . . . . . . . . . . . . . . 38 44
   A.1   SDPng Base DTD . . . . . . . . . . . . . . . . . . . . . . . 38 44
   A.2   SDPng XML-Schema Specification . . . . . . . . . . . . . . . 38 45
   B.    Sample Package Definitions . . . . . . . . . . . . . . . . . 45 51
   B.1   Sample RTP Package Definition  . . . . . . . . . . . . . . . 45 51
   B.2   Sample Audio Package Definition  . . . . . . . . . . . . . . 46 52
   B.3   Sample Video Package Definition  . . . . . . . . . . . . . . 46 52
   C.    Sample SDPng Description . . . . . . . . . . . . . . . . . . 48 54
   D.    Use of SDPng in Conjunction with other IETF Signaling
         Protocols  . . . . . . . . . . . . . . . . . . . . . . . . . 52
   D.1   The Session Announcement Protocol (SAP)  . . . . . . . . . . 52
   D.2   Session Initiation Protocol (SIP)  . .    Change History . . . . . . . . . . . 53
   D.3   Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . . 58
   D.4   Media Gateway Control Protocol (MEGACOP) . . . . . . . . . . 59
   E.    Change History . . . . . . . . . . . . . . . .
         Intellectual Property and Copyright Statements . . . . . . . 61
         Intellectual Property and Copyright Statements . . . . . . . 64

1. Introduction

   Multiparty multimedia conferencing is one of the

   Different applications that
   require dynamic interchange of end-system capabilities and in the
   negotiation of multimedia realtime communication
   domain require a parameter set that is appropriate means for all sending session description and receiving end-systems in a conference. capability
   negotiation. For some applications,
   e.g. for loosely coupled conferences or example, for broadcast scenarios, it
   may establishing an interactive audio
   communication session between two participants, end-systems must be sufficient
   dynamically configured with respect to simply have session codec types, codec parameters,
   transport protocol parameters and other configuration details. All
   these parameters can be fixed by viewed as the
   initiator of configuration for a conference. In such session,
   and a scenario no negotiation session description language is
   required because only those participants with media tools that
   support used to describe this
   configuration unambiguously.

   While the predefined settings can join a media fundamental requirement to describe session and/or a
   conference.

   This approach is applicable for conferences parameters
   applies to all application scenarios, there are differences in how
   configurations are obtained and distributed among participants. For
   broadcast applications, e.g., sessions that are announced some
   time ahead of the actual start date of the conference. Potential
   participants can check using SAP
   or IMG protocols, the availability of media tools in advance and
   tools such as sender is typically distributing a session directories can configure media tools upon
   startup. This procedure however fails
   description to work for conferences
   initiated spontaneously including Internet phone calls or ad-hoc
   multiparty conferences. Fixed settings for potential receivers, describing the technical
   parameters (e.g., multicast addresses, port numbers, codecs etc.) and
   providing additional information about the session such as media
   types, their encoding etc. can easily inhibit
   meta-information (about the initiation content) and scheduling information.
   While a sender might provide alternative variants of one specific
   broadcast event (different language versions, different media codec
   configurations for different quality levels etc.) there is typically
   no negotiation process between sender and receiver in order to obtain
   the optimal configuration for a specific receiver. Instead, the
   sender may provide different potential configurations and the
   receiver would select the most appropriate one.

   Real-time-streaming applications such as "video-on-demand" provide
   similar but slightly different requirements. Still the sender is
   typically providing a set of different potential configurations, out
   of which the receiver may select the most appropriate one, so there
   is not really a negotiation of content and its representation (on the
   session description level). But, differently to the aforementioned
   scenarios, the receiver must tell the sender the endpoint address,
   i.e., where media data should be sent to. Depending on the control
   protocol, this may be specified using the session description
   language or other means (as it is done with RTSP).

   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 spontaneously
   initiated conferences including Internet phone calls or ad-hoc
   multiparty conferences, fixed settings for parameters such as media
   types, their encoding etc. can easily inhibit the initiation of
   conferences, for example in situations where a caller insists on a
   fixed audio encoding that is not available at the callee's
   end-system.

   To allow for spontaneous conferences, the process of defining a
   conference's parameter set must therefore be performed either at
   conference start (for closed conferences) conferences with a fixed set of participants)
   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 was initially
   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  While numerous extensions to SDP were
   developed to account for various aspects of interactive session description
   establishment (the offer/answer model in RFC 3264, grouping of media
   sessions in RFC 3388, and simple capability negotiation as well as the
   basic terms used throughout declaration in RFC 3407,
   among others), their expressiveness is naturally constrained by the
   simple (and veru limited) SDP syntax.

   SDPng, the session description languages specified in this specification (Section 2). In
   Section 3, we document,
   provide an overview of options a common, XML-based framework for session description and
   capability
   negotiation. Next, we outline the concept description for the concepts underlying
   SDPng and introduce the syntactical components step by step aforementioned application scenarios.
   It allows for distributing "fixed" configuration descriptions in
   Section 4.

   Appendix A provide formal specifications of SDPng such as XML DTD and
   Schema definitions, Appendix D describes
   broadcast application scenarios but also supports the usage dynamic
   negotiation of SDPng in
   conjunction with IETF control protocol session parameters for interactive multimedia communication
   and Appendix E lists the change history.

2. Terminology and System Model

   Any (computer) system has, at a time,
   conferences.

   In order to support a number broad range of rather fixed
   hardware as well as software resources. These resources ultimately different applications, SDPng
   itself is completely application-agnostic. The base specification
   does not 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 any application-specific vocabulary, e.g., media encodings
      (e.g. G.711
   types, codecs and G.723.1 their configuration parameters etc., but not GSM); is
   intended as an extensible framework that provides the necessary
   extensibility mechanisms for supporting both future applications and CPU processing power
   future transport 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 mechanisms.

   With respect to capability negotiation, SDPng is based on the voice transmission
   following principles:

      Capability negotiation is an optional feature, which MAY be
      employed for specific applications, e.g., session setup for
      interactive communication.

      SDPng provides 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 framework for describing capabilities and political constraints, different configurations can be
   chosen
      linking them to accomplish the use configurations of these components in a conference.

   Each component can be characterized at least by (a) its intended use
   (i.e. application sessions, but the function it shall provide) and (b)
      base specification does not prescribe negotiation algorithms such
      as feature matching.

      The SDPng base specification provides the necessary support for
      application-independent capability negotiation, i.e., an SDPng
      processor that receives capability descriptions from one or more possible
   ways
      multiple participants does not need to realize this function. Each way of realizing a particular
   function is referred understand the capability
      semantics in order to as process the different capability
      descriptions. For this purpose, SDPng provides a "configuration".

      Example: A conference component's intended use may be to make
      transparencies well-defined set
      of data types and defines a presentation visible value representation that allows SDPng
      processors to infer data types without requiring access to schema
      definitions and without requiring application-specific knowledge.

   For most application classes, especially for broadcast applications,
   the audience on session description will have to provide information about the
      Mbone.
   session that is not used to configure end-systems but rather to
   facilitate content navigation for human users. For example, This
   meta-information can be achieved either by a video camera capturing include author/source details, additional
   information about the
      image and transmitting a video stream via some video tool whole session or by
      loading a copy of individual media sessions,
   scheduling information and other, arbitrary information that is
   related to the slides into a distributed electronic
      white-board. For each of these cases, additional parameters may
      exist, variations of which lead session but not directly required to additional configurations (see
      below).

   Two configurations are considered different regardless of whether
   they employ entirely different achieve
   interoperability between end-systems. SDPng provides fundamental
   mechanisms and protocols (as in the
   previous example) or they choose that support the same inclusion of meta-information:

      Descriptions of application components (media sessions) and differ only
      alternative configurations can be labeled to enable later
      referencing, i.e., for associating meta-information. For example,
      in a single
   parameter.

      Example: In case of video transmission, multi-language TV broadcast session, the language information
      could be provided by a JPEG-based still image
      protocol meta-information fragment that assigns
      language tags to media session descriptions by referencing them.

      SDPng itself does not define vocabulary for specifying
      meta-information, but allows for including arbitrary
      meta-information fragments, e.g., MPEG-7 descriptions. These
      description may either be used, H.261 encoded CIF images could included or inline or 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 referenced by the participating
   system's capabilities.
      URIs.

   In addition, the intended use of a component
   may constrain the possible configurations further to following, we first introduce a subset
   suitable model for session description
   and capability negotiation as well as the particular component's purpose.

      Example: basic terms used throughout
   this specification (Section 2). In a system Section 3, we provide an overview
   of options for highly interactive audio communication capability negotiation. Next, we outline the component responsible concept
   for audio may decide not to use the
      available G.723.1 audio codec to avoid concepts underlying SDPng and introduce the additional latency but
      only use G.711. This would syntactical
   components step by step in Section 4.  Section 5 describes how SDPng
   can be reflected used in this component only
      showing configurations based upon G.711. Still, multiple
      configurations are possible, e.g. depending on the use different application scenarios.

   Appendix A provide formal specifications of A-law or
      u-Law, packetization SDPng such as XML DTD and redundancy parameters, etc.

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

   o  potential configurations
      (a set of any number of configurations per component) indicating
   Schema definitions, Appendix B provides some sample package
   definitions, Appendix C provides a
      system's functional capabilities as constrained by the intended
      use of sample SDPng description, and
   Appendix D lists the various components;

   o  actual configurations
      (exactly one per instance of change history.

2. Terminology and System Model

   Any (computer) system has, at a component) reflecting the mode of
      operation 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 component's particular instantiation. device. We term features enabled
   and restricted by these resources "system capabilities".

      Example: The potential configuration of the aforementioned video
      component System capabilities may indicate support for JPEG, H.261/CIF, and H.261/
      QCIF. A particular instantiation for include: a video conference may use
      the actual configuration limitation of H.261/CIF the
      screen resolution for exchanging video
      streams.

   In summary, true color by the key terms of this model are:

   o  A multimedia session (streaming or conference) consists of one graphics board; available
      audio hardware or
      more conference components for software may offer only certain media encodings
      (e.g. G.711 and G.723.1 but not GSM); and CPU processing power,
      available licenses, and quality of implementation may constrain
      the possible video encoding algorithms.

   In multiparty multimedia "interaction".

   o  A component describes conferences, participants employ different
   "components" in conducting the conference; similarly, a particular type of interaction (e.g. audio
      conversation, slide presentation) multimedia
   (rather than plain TV) broadcast may comprise several components that can
   make up the full presentation.

      Example: In lecture multicast conferences one component might be realized by means
      the voice transmission for the lecturer, another the transmission
      of
      different applications (possibly using different protocols).

   o  A configuration is a set video pictures showing the lecturer and the third the
      transmission of parameters that are required presentation material.

   Depending on system capabilities, user preferences and other
   technical and policy constraints, different configurations can be
   chosen to
      implement a certain variation (realization) accomplish the use of these components in a certain
      component. There are actual and potential configurations.

      *  Potential configurations describe possible configurations that
         are supported conference.

   Each component can be characterized at least by an end-system.

      *  An actual configuration is an "instantiation" of (a) its intended use
   (i.e. the function it shall provide) and (b) one or more possible
   ways to realize this function. Each way of the
         potential configurations, i.e. realizing a decision how particular
   function is referred to realize as a
         certain component.

      In less abstract words, potential configurations describe what "configuration".

      Example: A conference component's intended use may be to make
      transparencies of a
      system presentation visible to the audience on the
      Mbone. This can do ("capabilities") and actual configurations describe
      how be achieved either by a system is configured to operate at video camera capturing the
      image and transmitting a certain point in time
      (media video stream spec).

   To decide on a certain actual configuration, via some video tool or by
      loading a negotiation process
   needs to take place between copy of the involved peers:

   1.  to determine slides into a distributed electronic
      white-board. For each of these cases, additional parameters may
      exist, variations of which potential configuration(s) lead to additional configurations (see
      below).

   Two configurations are considered different regardless of whether
   they have employ entirely different mechanisms and protocols (as in
       common, the
   previous example) or they choose the same and

   2.  to select one of this shared set differ only in a single
   parameter.

      Example: In case of common potential
       configurations to video transmission, a JPEG-based still image
      protocol may be used for information exchange (e.g. based
       upon preferences, external constraints, etc.).

   Note that 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 meaning participating
   system's capabilities. In addition, the intended use of a component
   may constrain the term "actual configuration" is highly
   application-specific. For example, for audio transport using RTP, an
   actual configuration is equivalent possible configurations further to a payload format (potentially
   plus format parameters), whereas subset
   suitable for other applications it may be a
   MIME type. the particular component's purpose.

      Example: In SAP-based [8] session announcements on a system for highly interactive audio communication
      the Mbone, component responsible for which SDP
   was originally developed, audio may decide not to use the negotiation procedure is non-existent.
   Instead, the announcement contains the media stream description sent
   out (i.e. the actual configurations) which implicitly describe what a
   receiver must understand
      available G.723.1 audio codec to participate.

   In point-to-point scenarios, the negotiation procedure is typically
   carried out implicitly: each party informs the other about what it
   can receive and avoid the respective sender chooses from additional latency but
      only use G.711. This would be reflected in this set a
   configuration that it can transmit.

   Capability negotiation must not component only work for 2-party conferences but
   is also required for multi-party conferences. Especially for the
   latter case it is required that the process to determine
      showing configurations based upon G.711. Still, multiple
      configurations are possible, e.g. depending on the subset use of allowable A-law or
      u-Law, packetization and redundancy parameters, etc.

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

   o  potential configurations is deterministic to reduce the
      (a set of any number of required round trips before configurations per component) indicating a session can be established.
   For instance, in order to be used with SIP, the capability
   negotiation is required to work with the offer/answer model that is
   for session initiation with SIP -- limiting
      system's functional capabilities as constrained by the negotiation to
   exactly one round trip.

   The requirements for intended
      use of the SDPng specification, subdivided into general
   requirements and requirements for session descriptions, potential and various components;

   o  actual configurations as well as negotiation rules, are captured in a
   companion document [1].

   The following list explains some terms used in this document:

   Actual Configuration
      An actual configuration is an "instantiation" of
      (exactly one per instance of the
      potential configurations, i.e. a decision how to realize 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 certain
      component.

   Component 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 (broadcast, 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).

   Package

   o  A package configuration is application specific data schema for expressing
      potential and a set of parameters that are required to
      implement a certain variation (realization) of a certain
      component. There are actual and potential configurations. For example, an audio package
      specifies the data schema for audio codecs.

   Potential Configuration

      *  Potential configurations describe possible configurations that
         are supported by an end-system ("capabilities").

3. Overview

   SDPng end-system.

      *  An actual configuration is a description language for both potential configurations
   (i.e. capabilities) an "instantiation" of participants in multimedia conferences and for
   actual configurations (i.e. final specifications one of parameters).
   Capability negotiation is the process of generating
         potential configurations, i.e. a usable set of decision how to realize a
         certain component.

      In less abstract words, potential configurations describe what a
      system can do ("capabilities") and finally an actual configuration from a
   set of potential configurations provided by each potential
   participant in describe
      how a multimedia conference.

   SDPng itself system is an application-independent framework that defines a
   description syntax and processing rules that are applied configured to the
   capability operate at a certain point in time
      (media stream spec).

   To decide on a certain actual configuration, a negotiation process. The rules specify how to process two
   or more capability description in general
   needs to take place between the involved peers:

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

   2.  to obtain an
   interworking configuration.

   A capability description for an endpoint is a select one of this shared set of individual
   capabilities, each common potential
       configurations to be used for information exchange (e.g. based
       upon preferences, external constraints, etc.).

   Note that the meaning of which provides a fixed type, e.g., the term "actual configuration" is highly
   application-specific. For example, for audio transport using RTP, an
   actual configuration is equivalent to a numeric
   value or payload format (potentially
   plus format parameters), whereas for other applications it may be a list value. The set of types and the corresponding
   negotiation rules are defined in this memo.
   MIME type.

   In SAP-based [8] session announcements on the following, we provide an overview of Mbone, for which SDP
   was originally developed, the negotiation process
   in Section 3.1 and describe the different capability types and procedure is non-existent.
   Instead, the
   corresponding negotiation rules in Section 3.2.

3.1 Outline of announcement contains the Negotiation Process

   SDPng supports media stream description sent
   out (i.e. the specification of endpoint capabilities and defines actual configurations) which implicitly describe what a negotiation process:
   receiver must understand to participate.

   In a point-to-point scenarios, the negotiation process, capability
   descriptions are exchanged between participants. These descriptions
   are processed in a "collapsing" step which results in a procedure is typically
   carried out implicitly: each party informs the other about what it
   can receive and the respective sender chooses from this set of
   commonly supported potential configurations. In a second step, the
   final actual
   configuration is determined that it can transmit.

   Capability negotiation must not only work for 2-party conferences but
   is used also required for a
   conference. This section specifies the usage of SDPng multi-party conferences. Especially for capability
   negotiation. It defines the collapsing algorithm and the procedures
   for exchanging SDPng documents in a negotiation phase.

   The description language and
   latter case it is required that the rules for process to determine the negotiation phase that
   are defined here are (in general) independent subset
   of the means by which
   descriptions are conveyed during a negotiation phase (a reliable
   transport service with causal ordering allowable potential configurations is assumed). There are however
   properties and requirements of call signaling protocols that have
   been considered deterministic to allow for a seamless integration of the
   negotiation into reduce the call setup process.
   number of required round trips before a session can be established.
   For example, instance, in order to be
   usable used with SIP, it must be possible to negotiate the conference
   configuration within the two-way-handshake of the call setup phase.
   In order to use SDPng instead of SDP according capability
   negotiation is required to work with the offer/answer model defined in [13] it must be possible that is
   for session initiation with SIP -- limiting the negotiation to determine an
   exactly one round trip.

   The following list explains some terms used in this document:

   Actual Configuration
      An actual configuration in a single request/response cycle.

   Conceptually, the negotiation process comprises is an "instantiation" of one of the following
   individual steps (considering two parties, A and B, where A tries to
   invite B
      potential configurations, i.e. a decision how to realize a conference). Please note that this certain
      component.

   Component
      A component describes the steps
   of the negotiation process conceptually -- it does not specify
   requirements for implementations. Specific procedures a particular type of interaction (e.g. audio
      conversation, slide presentation) that MUST can be
   followed realized by implementations are given below.

   1. means of
      different applications (possibly using different protocols).

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

   Potential Configuration
      Potential configurations describe possible configurations that
       should be used in the conference (e.g. "interactive audio" and
       "shared whiteboard") and sends a corresponding SDPng instance to
       B. This are
      supported by an end-system ("capabilities").

3. Overview

   SDPng instances is denoted "CAP(A)".

   2.  B receives A's SDPng instance and analyzes the set of components
       in the description. For each component that B wishes to support
       it generates a list of description language for both potential configurations corresponding to
       B's capabilities, denoted "CAP(B)".

   3.  B applies the collapsing function and obtains a list
   (i.e. capabilities) of potential
       configurations that both A and B can support, denoted
       "CAP(A)xCAP(B) = CAP(AB)".

   4.  B sends CAP(B) to A.

   5.  A also applies the collapsing function and obtains "CAP(AB)". At
       this step, both A participants in multimedia conference and B know the capabilities for
   actual configurations (i.e. final specifications of each other and parameters).
   Capability negotiation is the process of generating a usable set of
   potential configurations that both can support.

   6.  In order to obtain and finally an actual configuration from the potential
       configuration that has been obtained, both participants have to
       pick a subset
   set of the potential configurations that should
       actually be used provided by each potential
   participant in the conference and generate the actual
       configuration. a multimedia conference.

   SDPng itself is an application-independent framework that defines a
   description syntax that are enable an (optional) capability
   negotiation process. It should be noted noted, that SDPng can be used
   without capability negotiation and that it depends on the specific
       application whether each component must be assigned exactly one
       actual configuration or whether it negotiation
   algorithm is allowed to list multiple
       actual configurations. In not specified in this model we assume that A selects the
       actual configuration, denoted CFG(AB).

   7. document.

   A augments CFG(AB) with the transport parameters it intends to
       use, e.g., on which capability description for an endpoint addresses A wishes to receive data,
       obtaining CFG_T(A). A sends CFG_T(A) to A.

   8.  B receives CFG_T(A) and adds its own transport parameters,
       resulting in CFG_T(AB). CFG_T(AB) contains the selected actual
       configurations and the transport parameters of both A and B (plus
       any other SDPng data, e.g., meta-information on the conference).
       CFG_T(AB) is the complete conference description. Both A and B
       now have the following information:

       CAP(A) A's supported potential configurations

       CAP(B) B's supported potential configurations

       CAP(AB) The a set of potential configurations supported by both A
          and B.

       CFG(AB) The set individual
   capabilities, each of actual configurations to be used.

       CFG_T(AB) which provides a fixed type, e.g., a numeric
   value or a list value. The set of actual configurations to be used augmented
          with all required parameters.

   Note that types and the model presented here results corresponding
   abstract negotiation rules are defined in four SDPng messages. As
   an optimization, this procedure can be abbreviated memo. The SDPng data
   types are relevant to two exchanges
   by including all SDPng application domains, while the transport (and other) parameters into the potential
   configurations. A embeds its desired transport parameters into the
   list of potential configurations and B also sends all required
   parameters in the response together with B's potential
   configurations. Both A and B can then derive CFG_T(AB). Transport
   parameters
   processing rules are usually not negotiable, therefor they have only applicable to be
   distinguished from other configuration information.

   The SDPng application domains that rely
   on capability negotiation.

   In the following, we provide a conceptual overview of the negotiation
   process is specified in Section 5.

3.2 Capability Types

   The 3.1 and describe the different capability types
   and the corresponding abstract negotiation process relies on rules in Section 3.2.

3.1 Outline of the Negotiation Process

   SDPng supports the specification of endpoint capabilities and defines
   a negotiation process: In a negotiation process, capability
   descriptions are exchanged between participants. These descriptions
   are processed in a "collapsing" step which results in a fixed set of
   processing rules
   commonly supported potential configurations. In a second step, the
   final actual configuration is determined that is used for different types a
   conference. This section specifies the usage of capabilities. The following
   types are defined:

   1.  Tokens (text strings)

          Example:

   <audio:encoding>PCMU</audio:encoding>

          Processing rule:
          Ascertain identity

   2.  Token lists

          Example:

   <audio:sampling-rate>8000 16000</audio:sampling-rate>
          Processing rule:
          Determine common subset

   3.  Numbers

          Example:

   <audio:bitrate val="64"/>

          Processing rule:
          Ascertain equality

   4.  Numerical ranges

          Example:

   <audio:bitrate min="6" max="64"/>

          Processing rule:
          Determine common subrange SDPng distinguishes between optional and mandatory for capability
   definitions, with different processing
   negotiation. It defines the collapsing algorithm and the procedures
   for exchanging SDPng documents in a negotiation phase.

   The description language and the rules for the negotiation
   process. Optional definitions are used for capabilities phase that can be
   provided by an entity but do not have to be supported by all
   participants. For example, an audio codec could provide optional
   codec parameters. The use
   are defined here are (in general) independent of these parameters needs to be declared by
   a session description, but if the parameter is not understood means by all
   implementations, a session can be established nevertheless.  As which
   descriptions are conveyed during a
   result, the failure negotiation phase (a reliable
   transport service with causal ordering is assumed). There are however
   properties and requirements of a single processing step for a definition call signaling protocols that
   has have
   been marked as "optional" does not lead considered to allow for a failure seamless integration of the
   capability
   negotiation as a whole.

   A mandatory capability on into the other hand has to be supported by all
   participants. call setup process. For example, the specification of an audio codec for an
   audio capability is mandatory, and for obtaining an interoperable
   configuration, all participants in order to be
   usable with SIP, it must support be possible to negotiate the same audio codec or
   set conference
   configuration within the two-way-handshake of audio codecs. the call setup phase.
   In addition order to capabilities, a use SDPng description can also provide
   parameters that are not negotionable, e.g., transport parameters. In
   SDPng, there is a distinction between capability definitions (that
   are subject instead of SDP according to the offer/answer
   model defined in [13] it must be possible to determine an actual
   configuration in a single request/response cycle.

   Conceptually, the negotiation process) process comprises the following
   individual steps (considering two parties, A and parameters that are
   specified by each participant. In a description of alternative
   configurations for a specific component, capabilities and parameters
   can be referred B, where A tries to
   invite B to and describe the configurations.

3.3 Application-specific Vocabulary

   While the SDPng specification defines the fundamental definition
   types, processing rules and the syntax definition for SDPng
   descriptions, it does not define any application-specific vocabulary.
   Application-specific vocabulary is defined in SDPng packages. An
   SDPng package defines a schema for application specific capability
   and parameter descriptions. Based on the description types specified
   by the SDPng base specification, a package definition specifies the
   capability and parameter definitions allowed for a specific
   application, conference). Please note that this describes the types steps
   of definitions and additional attributes,
   e.g., whether a definition element is optional with respect to the
   capability negotiation or not.

   The SDPng base specification process conceptually -- it does define some fundamental not specify
   requirements for definition elements implementations. Specific procedures that MUST be
   followed by implementations are specified in package
   definitions, for example XML attributes given below.

   1.  A determines its potential configurations for elements. Appendix A.2
   provides an XML Schema definition that specifies some base types the components that
   to
       should be used for package definitions.

   In order to allow for an application independent processing of SDPng
   description documents, SDPng descriptions are standalone, i.e., in the
   package definition is not required to process conference (e.g. "interactive audio" and
       "shared whiteboard") and sends a corresponding SDPng
   document. All information, e.g., instance to
       B. This SDPng instances is denoted "CAP(A)".

   2.  B receives A's SDPng instance and analyzes the type set of definitions and
   additional attributes are contained components
       in the SDPng document itself. An
   SDPng implementation can thus be processed without access description. For each component that B wishes to the
   package definition.

4. SDPng Syntax

   This section specifies the SDPng base syntax. An SDPng description is
   an XML document consisting support
       it generates a list of up potential configurations corresponding to five parts:

      Capabilities

      Definitions

      Configurations

      Constraints

      Session Information

   The Capabilities section provides
       B's capabilities, denoted "CAP(B)".

   3.  B applies the collapsing function and obtains a list of individual capabilities.
   In a capability negotiation process, these potential
       configurations that both A and B can support, denoted
       "CAP(A)xCAP(B) = CAP(AB)".

   4.  B sends CAP(B) to A.

   5.  A also applies the collapsing function and obtains "CAP(AB)". At
       this step, both A and B know the capabilities are matched
   against corresponding definitions of each other participants' capability
   descriptions. This section MUST be present in any SDPng description.

   The Definitions section provides definitions of commonly used
   parameters for later referencing. This section is OPTIONAL for SDPng
   descriptions.

   The Configurations section provides the description of and
       the different
   conference components (applications in a conference). Each component
   description potential configurations that both can provide support.

   6.  In order to obtain an actual configuration from the potential
       configuration that has been obtained, both participants have to
       pick a list subset of alternative configurations. This
   section MUST the potential configurations that should
       actually be present used in any SDPng description.

   The Constraints section provides contraints on combinations of
   configurations. This section is OPTIONAL for SDPng descriptions.

   The Session Information section provides meta information on the
   conferences conference and generate the actual
       configuration. It should be noted that it depends on individual components. This section is OPTIONAL
   for SDPng documents.

4.1 SDPng Base Syntax

   An SDPng description is an XML document.  The document root element
   MUST be an element of type "sdpng". The XML vocabulary for the SDPng
   base specification resides in the XML namespace "http://www.iana.org/
   sdpng". The root element of an SDPng description MUST define an XML
   default namespace "http://www.iana.org/sdpng". specific
       application whether each component must be assigned exactly one
       actual configuration or whether it is allowed to list multiple
       actual configurations. In addition, this model we assume that A selects the
   "sdpng" element MUST map
       actual configuration, denoted CFG(AB).

   7.  A augments CFG(AB) with the namespace prefix "sdpng" transport parameters it intends to
       use, e.g., on which endpoint addresses A wishes to receive data,
       obtaining CFG_T(A). A sends CFG_T(A) to A.

   8.  B receives CFG_T(A) and adds its own transport parameters,
       resulting in CFG_T(AB). CFG_T(AB) contains the
   namespace name "http://www.iana.org/sdpng". The "sdpng" element type
   provides the child elements "cap", "def", "cfg", "constraints", selected actual
       configurations and
   "info" for the different sections transport parameters of the both A and B (plus
       any other SDPng data, e.g., meta-information on the conference).
       CFG_T(AB) is the complete conference description. Both A and B
       now have the following information:

       CAP(A) A's supported potential configurations

       CAP(B) B's supported potential configurations

       CAP(AB) The
   default namespace is also applied to these elements. set of potential configurations supported by both A
          and B.

       CFG(AB) The encoding set of the XML document MUST actual configurations to be UTF-8 (RFC2279, [16]). used.

       CFG_T(AB) The following figure depicts set of actual configurations to be used augmented
          with all required parameters.

   Note that the overall model presented here results in four SDPng document structure.

   <?xml version="1.0" encoding="UTF-8"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng">
     <cap>
       [...]
     </cap>
     <def>
       [...]
     </def>
     <cfg>
       [...]
     </cfg>
     <constraints>
       [...]
     </constraints>
     <info>
       [...]
     </info>
   </sdpng>

   Appendix A.1 provides a XML DTD that defines a corresponding document
   type.

   Note that the elements for the optional sections "Definitions",
   "Contraints", and "Session-Level Information" are OPTIONAL.

   Application-specific vocabulary resides in its own namespace. For
   each namespace name of messages. As
   an SDPng package, a namespace prefix MUST optimization, this procedure can be
   declared in abbreviated to two exchanges
   by including the start tag of transport (and other) parameters into the "sdpng" element. The following
   figure depicts potential
   configurations. A embeds its desired transport parameters into the declaration
   list of namespace prefixes for two package
   namespaces:

   <?xml version="1.0" encoding="UTF-8"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng"
          xmlns:rtp="http://www.iana.org/sdpng/rtp"
          xmlns:audio="http://www.iana.org/sdpng/audio">
       [...]
   </sdpng>

4.2 Capabilities potential configurations and B also sends all required
   parameters in the response together with B's potential
   configurations. Both A section for capability descriptions is an XML element that and B can
   provide a list then derive CFG_T(AB). Transport
   parameters are usually not negotiable, therefor they have to be
   distinguished from other configuration information.

   Note also that, in case of child elements. The element type is called "cap"(in multicast/broadcast scenarios, the "sdpng" namespace). Each child element represents an individual
   capability.

   Each capability element MUST sender
   may simply provide an attribute "name". The value the full description of the alternative
   configurations including (transport) parameters. The potential
   receivers will decide based upon this attribute SHOULD be composed information whether or not they
   are capable of a prefix (representing a
   namespace-name) receiving the respective media sessions and a unique name for pick the corresponding capability
   within that namespace.
   most suitable configuration.

3.2 SDPng Data Types

   The namespace-name designates a namespace for
   the source description of actual configurations and the capability definition, e.g.,
   negotiation process rely on a fixed set of data types with
   corresponding processing rules. The following types are defined:

   1.  Tokens (text strings)

          Example:

   		      <audio:encoding>PCMU</audio:encoding>

          Processing rule:
          Ascertain identity (compare strings)
   2.  Token lists

          Example:

   		      <audio:sampling-rate>8000 16000</audio:sampling-rate>

          Processing rule:
          Determine common subset

   3.  Numbers

          Example:

   		      <audio:bitrate val="64"/>

          Processing rule:
          Ascertain equality

   4.  Numerical ranges

          Example:

   		      <audio:bitrate min="6" max="64"/>

          Processing rule:
          Determine common subrange

   SDPng distinguishes between optional and mandatory capability
   definitions, with different processing rules for the participant of
   a conference. If a prefix is specified, it MUST negotiation
   process. Optional definitions are used for capabilities that can be separated
   provided by a
   colon (':') from the name. an entity but do not have to be supported by all
   participants. For example, an audio codec could provide optional
   codec parameters. The namespace MUST use of these parameters needs to be declared in by
   a session description, but if the
   respective element or in ancestor elements, e.g., parameter is not understood by all
   implementations, a session can be established nevertheless.  As a
   result, the root "sdpng"
   element. The following figure depicts failure of a capability element inside single processing step for a
   "cap" element. Note definition that the child elements
   has been marked as "optional" does not lead to a failure of "audio:codec" and the
   capability negotiation as a whole.

   A mandatory capability on the other sections hand has to be supported by all
   participants. For example, the specification of an audio codec for an
   audio capability is mandatory, and for obtaining an interoperable
   configuration, all participants must support the SDPng description are not shown.

   <?xml version="1.0"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng">
     <cap>
       <audio:codec name="avp:pcmu">
         [One same audio codec or more feature elements]
       </audio:codec>

       [...]
     </cap>
   </sdpng>

   Each capability element provides a
   set of features.  Each feature is
   represented by a child element.  The element types are defined in
   package definitions. XML Namespaces are used to disambiguate element
   types and audio codecs.

   In addition to allow for extensibility.  Each feature element capabilities, a SDPng description can also provide a "range" of values --
   parameters that are not only negotionable, e.g., transport parameters. In
   SDPng, there is a single value. For example, distinction between capability definitions (that
   are subject to a feature element can specify negotiation process) and parameters that are
   specified by each participant. In a set description of supported alternative values
   configurations for a given property, e.g., for specific component, capabilities and parameters
   can be referred to and describe the configurations.

3.3 Application-specific Vocabulary

   While the sampling rate of an audio codec. SDPng provides two different ways specification defines the fundamental types, abstract
   processing rules and the syntax definition for representing "value ranges": A
   feature element can specify a set of tokens or a numerical range.

   Each feature that SDPng descriptions, it
   does not define any application-specific vocabulary.
   Application-specific vocabulary is represented by an XML feature element has defined in SDPng packages. An
   SDPng package defines a
   well-defined type that is schema for application specific capability
   and parameter descriptions. Based on the description types specified in
   by the SDPng base specification, a package definition. The
   type determines definition specifies the representation of
   capability and parameter definitions allowed for a specific
   application, the types of definitions and additional attributes,
   e.g., whether a definition element values so that type
   information is encoded implicitly in optional with respect to the description document. Each
   feature element MAY provide
   capability negotiation or not.

   The SDPng base specification does define some fundamental
   requirements for definition elements that are specified in package
   definitions, for example XML attributes for elements. Appendix A.2
   provides an attribute "status". If this attribute
   is present it MUST provide one XML Schema definition that specifies some base types to
   be used for package definitions.

   In order to allow for an application independent processing of SDPng
   description documents, SDPng descriptions are standalone, i.e., the following values:

      opt:
      This element describes an optional feature (as described by
      Section 3.2).

   The three different features types (as described in Section 3.2)
   package definition is not required to process a corresponding SDPng
   document. All information, e.g., the type of definitions and
   additional attributes are
   represented as described contained in the following sections. Section 4.2.5
   provides a complete example.

4.2.1 Tokens

   Token elements provide a single token as element content. The token SDPng document itself. An
   SDPng implementation can thus be processed without access to the
   package definition.

4. SDPng Syntax

   This section specifies the SDPng base syntax. An SDPng description is
   an XML document consisting of type Nmtoken (name token) as defined by [9]. up to five parts:

      Capabilities

      Definitions

      Configurations

      Constraints

      Session Information

   The following
   example depicts Capabilities section provides a feature element list of type token.

   <audio:encoding>PCMU</audio:encoding>

   Boolean values SHOULD be represented as token elements with individual capabilities.
   In a values capability negotiation process, these capabilities are matched
   against corresponding definitions of either "true" or "false".

4.2.2 Token Sets

   Token set elements provide a token list as element content. The token other participants' capability
   descriptions. This section is of type Nmtokens (name tokens) as defined by [9]. The following
   example depicts a feature element of type token set.

   <audio:sampling>8000 16000</audio:sampling>

4.2.3 Numerical Values

   Elements OPTIONAL for numbers provide an attribute "val" with a numerical
   value. SDPng description
   document.

   The following example depicts a feature element Definitions section provides definitions of type
   numerical value.

   <audio:bitrate val="64"/>

4.2.4 Numerical Ranges

   Elements commonly used
   parameters for numerical ranges later referencing. This section is OPTIONAL for SDPng
   descriptions.

   The Configurations section provides the description of the different
   conference components (applications in a conference). Each component
   description can provide an attribute "min" and an
   attribute "max". Both attributes provide a numerical value. At least
   one list of these attributes alternative configurations. This
   section MUST be present. present in any SDPng description.

   The following example
   depicts a feature element Constraints section provides contraints on combinations of type numerical range.

   <audio:bitrate min="6" max="64"/>

4.2.5 Sample
   configurations. This section is OPTIONAL for SDPng cap Element

   <?xml version="1.0"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng">
     <cap>
       <audio:codec name="avp:pcmu">
         <audio:encoding>PCMU</audio:encoding>
         <audio:channels>1 2</audio:channels>
         <audio:sampling>8000 16000</audio:sampling>
         <audio:bitrate min="6" max="64"/>
         <audio:silence-suppression status="opt">
           true
         </audio:silence-suppression>
       </audio:codec>

       [...]
     </cap>
   </sdpng>

   Capability elements MAY also provide elements from different descriptions.

   The Session Information section provides meta information on the
   conferences and on individual components. This section is OPTIONAL
   for SDPng documents.

4.1 SDPng Base Syntax

   An SDPng description is an XML
   namespaces. For example, a video-codec capability MAY document.  The document root element
   MUST be described
   with elements declaring general video capabilities, and this an element
   MAY provide a list of additional codec specific feature elements, as
   depicted in type "sdpng". The XML vocabulary for the SDPng
   base specification resides in the XML namespace "http://www.iana.org/
   sdpng". The root element of an SDPng description MUST define an XML
   default namespace "http://www.iana.org/sdpng". In addition, the
   "sdpng" element MUST map the namespace prefix "sdpng" to the
   namespace name "http://www.iana.org/sdpng". The "sdpng" element type
   provides the child elements "cap", "def", "cfg", "constraints", and
   "info" for the different sections of the SDPng description. The
   default namespace is also applied to these elements.

   The encoding of the XML document MUST be UTF-8 (RFC2279, [16]).

   The following example: figure depicts the overall SDPng document structure.

   <?xml version="1.0"?> version="1.0" encoding="UTF-8"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng">
     <cap>
       <video:codec name="h263+-enhanced">
         <video:encoding>H.263+</video:encoding>
         <video:resolution>QCIF</video:resolution>
         <video:framerate max="30"/>
         <h263plus:A>foo</h263plus:A>
         <h263plus:B>bar</h263plus:B>
       </video:codec>
       [...]
     </cap>
     <def>
       [...]
     </def>
     <cfg>
       [...]
     </cfg>
     <constraints>
       [...]
     </constraints>
     <info>
       [...]
     </info>
   </sdpng>

4.2.6 Referencing Capability Elements

   The capablity elements of

   Appendix A.1 provides a "cap" element can be referenced in later
   sections of the SDPng document. The fundamental model is XML DTD that
   capability elements specify individual capabilities (without
   transport and other non-negotionable parameters) and defines a corresponding document
   type.

   Note that these the elements for the optional sections "Capabilities",
   "Definitions", "Contraints", and "Session-Level Information" are later augmented
   OPTIONAL.

   Application-specific vocabulary resides in Definitions and Configurations
   sections.

   When referencing a capability element, e.g., the element video:codec,
   the same element its own namespace. For
   each namespace name (general identifier) is used. The referencing
   element MUST provide an attribute "ref", and the value of this
   attribute SHOULD provide the value of an SDPng package, a namespace prefix MUST be
   declared in the attribute "name" start tag of the
   referenced "sdpng" element. The referencing element MAY also provide additional feature elements
   (that have not been provided by the referenced capability element).
   The referencing element MAY also provide feature elements that have
   already been provided by following
   figure depicts the referenced element.

   The referencing element MAY provide an attribute "name". The
   semantics declaration of a reference are defined in the corresponding sections
   where references to definitions are used, i.e., in Section 4.3 and in
   Section 4.4.

   Section 5.2.4 provides implementation requirements namespace prefixes for dealing with
   references to capability elements after a capability negotiation
   process.

4.3 Definitions

   The Definitions two package
   namespaces:

   <?xml version="1.0" encoding="UTF-8"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng"
          xmlns:rtp="http://www.iana.org/sdpng/rtp"
          xmlns:audio="http://www.iana.org/sdpng/audio">
       [...]
   </sdpng>

4.2 Capabilities

   A section for capability descriptions is an optional section that can provide
   definitions of fixed parameters that are not negotionable such as
   transport parameters. An SDPng description document MAY provide a
   "def" XML element that can
   provide a set list of definitions as child elements. The element type is called "cap"(in
   the "sdpng" namespace). Each child element of a "def" element provides represents an individual
   capability.

   Each capability element type
   specified in a package definition. Such child elements are referred
   to as "definition elements". Definition elements can MUST provide a set of
   child elements, each an attribute "name". The value
   of which specifies a specific configuration
   value. Syntactically, these child elements MUST this attribute SHOULD be "feature elements"
   as specified in Section 4.2. Child elements composed of a definition element
   MUST be of type Token or of type Numerical Value. A definition
   element MUST provide an attribute "name" that is used to specify prefix (representing a
   namespace-name) and a unique name in for the scope corresponding capability
   within that namespace. The namespace-name designates a namespace for
   the source of the current SDPng description. A
   definition element MAY provide an attribute "ref" that capability definition, e.g., for the participant of
   a conference. If a prefix is used to
   reference specified, it MUST be separated by a capability
   colon (':') from the name. The namespace MUST be declared in the
   respective element as specified or in Section 4.2. ancestor elements, e.g., the root "sdpng"
   element. The following example figure depicts a def element with one definition capability element inside a
   "cap" element. Note that the child elements of type "rtp:udp". This element is used to specify fixed
   parameters "audio:codec" and the
   other sections of an RTP session -- the allowable parameters would have
   been specified in a corresponding SDPng RTP package. description are not shown.

   <?xml version="1.0"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng">
     <cap>
       <audio:codec name="avp:pcmu">[...]</audio:codec>
       <rtp:udp name="rtpudpip6">[...]</rtp:udp>
     </cap>

     <def>
      <rtp:udp name="rtp-cfg1" ref="rtp:rtpudpip6">
        <rtp:ip-addr>::1</rtp:ip-addr>
        <rtp:rtp-port>9456</rtp:rtp-port>
        <rtp:pt>1</rtp:pt>
      </rtp:udp>
     </def>

     <cfg>
       [...]
     </cfg>
     <constraints>
       [...]
     </constraints>
     <info> name="avp:pcmu">
         [One or more feature elements]
       </audio:codec>

       [...]
     </info>
     </cap>
   </sdpng>

   A definition element SHOULD reference a

   Each capability element provided
   in the "cap" element, as depicted in the example. In the example, the
   definition named "rtp-cfg1" provides RTP transport parameters and
   references the RTP capability named "rtp:rtpudpip6". The semantics a set of
   referencing the capability features.  Each feature is
   represented by a child element.  The element types are as follows:

   o  An implementation MUST process the newly defined in
   package definitions. XML Namespaces are used to disambiguate element by
      adopting the individual
   types and to allow for extensibility.  Each feature elements element can
   provide a "range" of the referenced
      capability element.

   o values -- not only a single value. For example,
   a feature elements that are present in both the capability element and the description element, the feature elements can specify a set of supported alternative values
   for a given property, e.g., for the
      definition element take precedence over the feature elements sampling rate of
      the capability element.

   Please note the implementation requirements an audio codec.
   SDPng provides two different ways for dealing with
   references to capability elements after representing "value ranges": A
   feature element can specify a capability negotiation
   process provided set of tokens or a numerical range.

   Each feature that is represented by an XML feature element has a
   well-defined type that is specified in Section 5.2.4.

4.4 Configurations

   The Configurations section lists all the components that constitute package definition. The
   type determines the multimedia application (IP telephone call, real-time streaming
   application, multi-player gaming session etc.). For each representation of these
   components, the actual configurations are given.

   An SDPng document MUST provide a "cfg" element values in XML so
   that represents type information is encoded implicitly in the
   Configurations section. The "cfg" element provides one or more
   "component" element describing alternative configurations for description
   document. For example, a token set can be identified by the
   component. The "cfg" presence
   of whitespace separated list of token as element SHOULD provide at least one "component" content of the
   respective feature element. Each "component" feature element MUST MAY provide an
   attribute "name"
   that identifies the component uniquely in the scope of the SDPng
   description.

   Each "component" element "status". If this attribute is present it MUST provide one or more "alt" element, each
   of which describes an alternative configuration for the component.
   Each "alt" following values:

      opt:
      This element MUST provide describes an attribute "name" that provides a
   unique identification for the alternative optional feature (as described by
      Section 3.2).

   The three different features types (as described in Section 3.2) are
   represented as described in the scope of the SDPng
   description.  In addition, each "alt" element MUST also following sections. Section 4.2.5
   provides a complete example.

4.2.1 Tokens

   Token elements provide an
   attribute "media" for specifying the media a single token as element content. The token
   is of type for this particular
   alternative. Currently Nmtoken (name token) as defined values for this attribute are "audio",
   "video", "application", "data", and "control". by [9]. The semantics following
   example depicts a feature element of these type token.

   		<audio:encoding>PCMU</audio:encoding>

   Boolean values are described in [2].

   Each "alt" element MUST provide one SHOULD be represented as token elements with a values
   of either "true" or more XML "false".

4.2.2 Token Sets

   Token set elements that
   describe the configuration parameters for the particular alternative
   configuration. provide a token list as element content. The elements are token
   is of type Nmtokens (name tokens) as defined by SDPng package
   specification and definition from different packages can be mixed. [9]. The type of the elements and their order is application dependent.

   Each definition element that is contained in an "alt" following
   example depicts a feature element SHOULD of type token set.

   		<audio:sampling>8000 16000 32000</audio:sampling>

4.2.3 Numerical Values

   Elements for numbers provide an attribute "ref". The "ref" attribute is used to specify a
   reference to a capability element (from "val" with a "cap" section) or to numerical
   value. The following example depicts a
   definition feature element (from a "def" section). The value of an "ref"
   element MUST type
   numerical value.

   		<audio:bitrate val="64"/>

4.2.4 Numerical Ranges

   Elements for numerical ranges can provide the value of a "name" an attribute of "min" and an existing
   capability or definition element. A definition element MAY
   attribute "max". Both attributes provide
   child elements (for the specification a numerical value. At least
   one of additional feature and
   configuration parameters) but it MAY also these attributes MUST be an empty element. present.  The
   semantics following example
   depicts a feature element of referencing the type numerical range.

   		<audio:bitrate min="6" max="64"/>

4.2.5 Sample SDPng cap Element

   <?xml version="1.0"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng">
     <cap>
       <audio:codec name="avp:pcmu">
         <audio:encoding>PCMU</audio:encoding>
         <audio:channels>1 2</audio:channels>
         <audio:sampling>8000 16000</audio:sampling>
         <audio:bitrate min="6" max="64"/>
         <audio:silence-suppression status="opt">
           true
         </audio:silence-suppression>
       </audio:codec>

       [...]
     </cap>
   </sdpng>

   Capability elements MAY also provide elements from different XML
   namespaces. For example, a video-codec capability MAY be described
   with elements declaring general video capabilities, and this element are
   MAY provide a list of additional codec specific feature elements, as follows:

   o  An implementation MUST process the newly defined element by
      adopting
   depicted in the individual feature following example:

   <?xml version="1.0"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng">
     <cap>
       <video:codec name="h263+-enhanced">
         <video:encoding>H.263+</video:encoding>
         <video:resolution>QCIF</video:resolution>
         <video:framerate max="30"/>
         <h263plus:A>foo</h263plus:A>
         <h263plus:B>bar</h263plus:B>
       </video:codec>

       [...]
     </cap>
   </sdpng>

4.2.6 Referencing Capability Elements

   The capablity elements of the a "cap" element can be referenced in later
   sections of the SDPng document. The fundamental model is that
   capability or definition element.

   o  For feature elements specify individual capabilities (without
   transport and other non-negotionable parameters) and that these
   elements are present later augmented in both Definitions and Configurations
   sections.

   When referencing a capability element, e.g., the capability/
      definition element and video:codec,
   the current definition element, same element name (general identifier) is used. The referencing
   element MUST provide an attribute "ref", and the feature
      elements value of this
   attribute SHOULD provide the current definition element take precedence over value of the feature elements attribute "name" of the
   referenced element.

   Please note the implementation requirements for dealing with
   references to capability

   The referencing element MAY also provide additional feature elements after a capability negotiation
   process
   (that have not been provided in Section 5.2.4.

   The following example depicts by the description of a single
   configuration for a component named "interactive-audio". referenced capability element).
   The
   description of the configuration references the "avp:pcmu" audio
   codec definition from the "cap" element and the "rtp-cfg1" RTP
   session definition from the "def" element. In this example, both
   elements of the "alt" referencing element are empty MAY also provide feature elements that adopt the
   specified values from have
   already been provided by the referenced elements.

   <?xml version="1.0"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng">

     <cap>
       <audio:codec name="avp:pcmu">[...]</audio:codec>
       <rtp:udp name="rtpudpip6">[...]</rtp:udp>
     </cap>

     <def>
      <rtp:udp name="rtp-cfg1" ref="rtp:rtpudpip6">
        <rtp:ip-addr>::1</rtp:ip-addr>
        <rtp:rtp-port>9456</rtp:rtp-port>
        <rtp:pt>1</rtp:pt>
      </rtp:udp>
     </def>

     <cfg>
       <component name="interactive-audio" media="audio">
        <alt name"alt1">
          <audio:codec ref="avp:pcmu"/>
          <rtp:udp ref="rtp-cfg1"/>
        </alt>
      </component>

     </cfg>
     <constraints>
       [...]
     </constraints>
     <info>
       [...]
     </info>

   </sdpng>

4.5 Constraints

   The Constraints section allows to express constraints on the
   combination of configurations that apply across different components. element.

   The "constraints" referencing element of MAY provide an SDPng description is OPTIONAL. attribute "name". The usage
   semantics of constraints will be specified in a separate document.

4.6 Session Information

   The Session Information section is represented by an "info" element
   and is intended for meta information on reference are defined in the conference itself corresponding sections
   where references to definitions are used, i.e., in Section 4.3 and on
   the individual components. in
   Section 4.4.

4.3 Definitions

   The "info" element is OPTIONAL and, if it Definitions section is present, it an optional section that can provide
   definitions of fixed parameters that are not negotionable such as
   transport parameters. An SDPng description document MAY provide a list
   "def" element that can provide a set of information definitions as child
   elements. The

   Each child element types are specified in
   package definitions.

4.7 Summary of SDPng XML-Syntax

   The SDPng base specification defines the following XML a "def" element types
   that reside in the SDPng namespace designated by the namespace name
   "http://www.iana.org/sdpng":

   o  sdpng

   o  cap

   o  def

   o  cfg

   o  component

   o  alt
   o  constraints

   o  info

   Appendix A.1 provides an XML DTD that element type
   specified in a package definition. Such child elements are referred
   to as "definition elements". Definition elements can provide a set of
   child elements, each of which specifies the content model a specific configuration
   value. Syntactically, these child elements MUST be "feature elements"
   as specified in Section 4.2. Child elements of
   the SDPng base elements.

5. Specification a definition element
   MUST be of the Capability Negotiation

   The SDPng specification defines the syntax and the semantics type Token or of
   capability descriptions. The algorithms that are used for processing
   descriptions and for comparing capability descriptions from different
   participants are application specific.

   In this section, we specify two alternative algorithms for
   implementations: type Numerical Value. A model definition
   element MUST provide an attribute "name" that is based on the SDP offer/answer scheme
   (Section 5.1 and used to specify a model that is based on
   unique name in the feature matching
   algorithm scope of the current SDPng description. A
   definition element MAY provide an attribute "ref" that is used to
   reference a capability element as specified in RFC 2533 [15] (Section 5.2).

5.1 Offer/Answer Section 4.2.

   The offer/answer model allows communicating peers to determine following example depicts a
   (common) mode def element with one definition
   element of operation type "rtp:udp". This element is used to exchange media streams in a single
   round-trip.  Basically, the offerer proposes a set specify fixed
   parameters of components,
   providing one or more alternatives ("potential configurations") for
   each of these. From this offer, the answerer learns which components
   may be used and which configurations are applicable to realize these
   components.  The answerer indicates which components it supports
   (e.g. receiving a offer including audio and video, it may disallow
   the video session and go with an audio-only conversation) and also
   provides possible configurations to implement those components.
   Along with RTP session -- the media types and codec parameters, offerer and answerer
   specify which transport addresses to use and, allowable parameters would have
   been specified in case of RTP, which
   payload types they want to use for sending. Offerer and answerer
   agree on a common set of media streams ("components") and on corresponding SDPng RTP package.

   <?xml version="1.0"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng">

     <cap>
       <audio:codec name="avp:pcmu">[...]</audio:codec>
       <rtp:udp name="rtpudpip6">[...]</rtp:udp>
     </cap>

     <def>
      <rtp:udp name="rtp-cfg1" ref="rtp:rtpudpip6">
        <rtp:ip-addr>::1</rtp:ip-addr>
        <rtp:rtp-port>9456</rtp:rtp-port>
        <rtp:pt>1</rtp:pt>
      </rtp:udp>
     </def>

     <cfg>
       [...]
     </cfg>
     <constraints>
       [...]
     </constraints>
     <info>
       [...]
     </info>

   </sdpng>

   A definition element SHOULD reference a
   possible set of codecs for each of these ("configurations") as well capability element provided
   in the "cap" element, as depicted in the example. In the example, the
   definition named "rtp-cfg1" provides RTP transport addresses and other parameters to be used.  However,
   they do not fix a certain configuration (unless only a single one is
   exchanged in each direction).  Instead, for each selected media
   stream, either peer may choose and dynamically switch to any
   references the RTP capability named "rtp:rtpudpip6". The semantics of
   referencing the
   configurations indicated by capability element are as follows:

   o  An implementation MUST process the other side in newly defined element by
      adopting the respective offer or
   answer.

   For using SDPng with the offer/answer model (RFC 3264), the basic
   defined in RFC 3264 for generating offers and answers apply.  The
   following considerations specifically apply when using offer/answer
   with SDPng (instead individual feature elements of SDP) documents:

   o  For each component to be used, all necessary parameters MUST be
      given for at least one configuration per component, i.e. transport
      addresses and payload formats MUST be specified along with the
      capabilities. referenced
      capability element.

   o  Matching of components is done based upon their identification  For feature elements that are present in both the session part of capability
      element and the SDPng document using predefined
      identifiers for certain session types.
      For simple sessions, where applications can implicitly derive description element, the
      semantics feature elements of the the offered components, no such explicit mapping
      is necessary.  In this case, i.e. if the entire "<info>"
      definition element
      or take precedence over the respective feature elements in the "<info>" element are absent, the
      order of appearance in the SDPng document is relevant as it is
      with SDP.

   o  For each component,
      the answerer performs a capability matching
      process as per then application's requirements
      For element.

4.4 Configurations

   The Configurations section lists all the components that are acceptable, the answerer determines
      whether or not to accept the offer.
      If the answerer decides to accept constitute
   the offer for a certain
      component, it MUST accept at least one multimedia application (IP telephone call, real-time streaming
   application, multi-player gaming session etc.). For each of these
   components, the potential actual configurations for the respective component.  It SHOULD indicate
      this by setting are given.

   An SDPng document MUST provide a "cfg" element that represents the "status"
   Configurations section. The "cfg" element provides one or more
   "component" element describing alternative configurations for the
   component. The "cfg" element SHOULD provide at least one "component"
   element. Each "component" element MUST provide an attribute of "name"
   that identifies the component and uniquely in the scope of the
      selected configuration(s) to "active" (but it SDPng
   description. Each "component" element MAY also omit the
      status provide an attribute in both cases).
      It is RECOMMENDED status
   of type CDATA that the answerer selects exactly MAY be used to specify application specific status
   information.

   Each "component" element MUST provide one
      configuration for or more "alt" element, each component as "active".

   o  The answerer MAY refuse individual configurations
   of which describes an alternative configuration for a component
      from the offer in two ways.
      If the configuration shall not be used at all during component.
   Each "alt" element MUST provide an attribute "name" that provides a session,
      e.g. because
   unique identification for the answerer does not support it or because alternative in the
      answere does not want to use this configuration at all, scope of the
      answerer SDPng
   description.  In addition, each "alt" element MUST set also provide an
   attribute "media" for specifying the "status" media type for this particular
   alternative. Currently defined values for this attribute are "audio",
   "video", "application", "data", and "control". The semantics of these
   values are described in [2].

   Each "alt" element MUST provide one or more XML elements that
   describe the respective
      component to "unused".  In this case, configuration parameters for the answerer MAY omit all particular alternative
   configuration. The elements are defined by SDPng package
   specification and definitions from different packages can be mixed.
   The type of the elements and their order is application dependent.

   Each definition element that is contained in the respective configuration's elements.
      This an "alt" element MAY
   provide an attribute "ref". The "ref" attribute is equivalent used to setting the port parameter specify a
   reference to "0" in SDP.
      If a configuration shall be accepted (i.e. the respective capability shall be indicated) but no media session shall be
      instantiated (not even on hold!), the answerer element (from a "cap" section) or to a
   definition element (from a "def" section). The value of an "ref"
   element MUST set provide the
      "status" value of a "name" attribute of an existing
   capability or definition element. A definition element MAY provide
   child elements (for the respective configuration to "available" specification of additional feature and omit all media-session-specific parameters
   configuration parameters) but it MAY also be an empty element.  The
   semantics of referencing the configuration. capability element are as follows:

   o  The answerer MAY refuse entire components that  An implementation MUST process the offerer has
      included in two ways.
      If a component shall not be used at all during a session -- e.g.
      because newly defined element by
      adopting the answerer does not support any individual feature elements of the configurations
      listed referenced
      capability or because definition element.

   o  For feature elements that are present in both the answere does not want to use this component
      at all -- capability/
      definition element and the answerer MUST set current definition element, the "status" attribute feature
      elements of the
      respective component's to "unused".  In this case, the answerer
      MAY omit all current definition element take precedence over
      the feature elements contained in the respective component
      elements.  This is equivalent to setting of the port parameter to "0"
      in SDP.
      If a component shall referenced element.

   It should be accepted (i.e. noted that the respective capability
      shall be indicated) but no media inclusion of definition by reference is
   NOT MANDATORY. For certain applications such as session shall announcement,
   it may be instantiated
      (not even on hold!), the answerer MUST set the "status" attribute
      of the respective component sufficient to "available", omit all
      media-session-specific parameters from all acceptable
      configurations for the respective component.

   o  For each component, provide the alternative potential configurations MUST
      be listed in configuration data directly
   inside an "alt" element.

   The following example depicts the order description of preference.
      Within a configuration, alternatives (e.g. different codecs) MUST
      also be listed in the order of preference. single
   configuration for a component named "interactive-audio". The considerations
   description of RFC 3264 to simply arriving at symmetric the configuration references the "avp:pcmu" audio
   codec use apply.

   If a component shall be put on hold, definition from the status attribute of "cap" element and the
   component MUST be set to "sendonly", "recvonly", or "inactive", as
   appropriate. "rtp-cfg1" RTP
   session definition from the "def" element. In this case, the status attributes example, both
   elements of all the
   contained configurations "alt" element are empty elements that were previously active MUST be set to
   indicate "sendonly", "recvonly", or "inactive", as appropriate.  The
   rules from RFC 3264 for putting media streams on hold SHALL apply.

5.2 RFC2533 Negotiation

   SDPng potential configurations can be processed using the RFC 2533
   algorithm as defined in [15]. This involves the following steps:

      Translating SDPng capability descriptions to RFC 2533 feature set
      expressions;

      Applying the RFC 2533 feature match algorithm; and

      Integrating adopt the resulting feature set expressions into
   specified values from the SDPng
      selection of conference configurations.

5.2.1 Translating SDPng to RFC 2533 Expressions

   SDPng capability descriptions can be translated referenced elements.

   <?xml version="1.0"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng">

     <cap>
       <audio:codec name="avp:pcmu">[...]</audio:codec>
       <rtp:udp name="rtpudpip6">[...]</rtp:udp>
     </cap>

     <def>
      <rtp:udp name="rtp-cfg1" ref="rtp:rtpudpip6">
        <rtp:ip-addr>::1</rtp:ip-addr>
        <rtp:rtp-port>9456</rtp:rtp-port>
        <rtp:pt>1</rtp:pt>
      </rtp:udp>
     </def>

     <cfg>
       <component name="interactive-audio" media="audio" status="active">
        <alt name"alt1">
          <audio:codec ref="avp:pcmu"/>
          <rtp:udp ref="rtp-cfg1"/>
        </alt>
      </component>

     </cfg>
     <constraints>
       [...]
     </constraints>
     <info>
       [...]
     </info>

   </sdpng>

4.5 Constraints

   The Constraints section allows to RFC 2533 express constraints on the
   combination of configurations that apply across different components.
   This feature
   sets in a straightforward way, because is intended for specialized devices with strict
   limitations on, e.g., parallel codec instantiations due to limited
   DSP resources. The SDPng uses a subset base specification does not define the use
   of constraints. Instead, the
   mechanisms provided by RFC 2533 with usage of constraints will be specified
   in a different syntax.

   Each capability separate document.

   The "constraints" element of an SDPng description is OPTIONAL.

4.6 Session Information

   The Session Information section is represented as by an XML element with a set of child
   elements. We first describe how to translate a single capability "info" element into a RFC 2533 feature set,
   and then consider is intended for meta information on the
   combination of conference itself and on
   the individual components. In an SDPng description document, the
   "info" element MAY provide one or multiple capability elements.

   Basically, all attributes "part" element, each of
   which may contain arbitrary meta-description content.

   The "info" element is OPTIONAL in an SDPng capability description document.

   Each "part" element and its
   child elements MUST be transformed to inside an RFC 2533 expression, whereas
   each child "info" element MUST provide a "type"
   attribute that specifies the type of the meta-information content,
   e.g., "MPEG-7", "TV-Anytime", "MPEG-21", "SDP".

   Each "part" element inside an "info" element MAY provide a "ref"
   attribute that can be translated used to specify an URI for the meta-information
   content. If a feature predicate. The
   resulting feature predicates are combined using "ref" attribute is provided the '&' (AND)
   operator. The name attributes "part" element MUST NOT be considered.

   Each predicate MUST be encapsulated by brackets ('(', ')'). The value
   or value range of each feature element is taken as a feature
   predicate value. Each feature element name is directly adopted as a
   feature tag, including
   empty.

   <?xml version="1.0"?>
   <sdpng xmlns="http://www.iana.org/sdpng"
          xmlns:sdpng="http://www.iana.org/sdpng">

     <cap>
       <audio:codec name="avp:pcmu">[...]</audio:codec>
       <rtp:udp name="rtpudpip6">[...]</rtp:udp>
     </cap>
     <def>
      <rtp:udp name="rtp-cfg1" ref="rtp:rtpudpip6">
        <rtp:ip-addr>::1</rtp:ip-addr>
        <rtp:rtp-port>9456</rtp:rtp-port>
        <rtp:pt>1</rtp:pt>
      </rtp:udp>
     </def>

     <cfg>
       <component name="interactive-audio" media="audio" status="active">
        <alt name"alt1">
          <audio:codec ref="avp:pcmu"/>
          <rtp:udp ref="rtp-cfg1"/>
        </alt>
      </component>

     </cfg>
     <constraints>
       [...]
     </constraints>
     <info>
       <part type="SDP">
         o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
         s=SDP Seminar
         i=A Seminar on the namespace name. session description protocol
         u=http://www.example.com/seminars/sdp.pdf
         e=j.doe@example.com (Jane Doe)
         t=2873397496 2873404696
       </part>
     </info>

   </sdpng>

4.7 Summary of SDPng XML-Syntax

   The SDPng data types map to RFC 2533 feature base specification defines the following XML element types as follows:

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

   Token set
      A token set MUST be adopted as an RFC 2533 set (a comma-separated
      token list inside square brackets, such as
      "video:channels=[1,2]").

   Number
      A single number
   that reside in a "val" attribute of a feature elements of type
      number MUST be adopted as the SDPng namespace designated by the namespace name
   "http://www.iana.org/sdpng":

   o  sdpng

   o  cap

   o  def

   o  cfg
   o  component

   o  alt

   o  constraints

   o  info

   Appendix A.1 provides an RFC 2533 number.

   Numerical Ranges
      A numerical range MUST be transformed to a feature set expression
      with two feature predicates XML DTD that are combined using the "&" (AND)
      operator. The first predicate specifies the lower limit and the
      second predicate specified the upper limit.
      For example, the element <bitrate min="64" max="128"/> would be
      transformed to content model of
   the following feature set:

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

      A numerical range without a lower limit MUST SDPng base elements.

5. Usage of SDPng in Different Application Scenarios

   This informative section describes how SDPng can be transformed to a
      corresponding predicate used in different
   application scenarios, namely broadcast/announcement,
   real-time-streaming, two-way-session-setup, and multiparty
   conferencing with a '<=' operator negotiation.

5.1 Broadcast/Announcement Scenarios

   Broadcast and a numerical range
      without a upper limit MUST be transformed to a corresponding
      predicate with a '>=' operator.
      For example, the element <bitrate max="128"/> would be transformed multicast application scenarios rely on session
   announcements to communicate information about multimedia sessions
   and their associated parameters. Historically, in the following feature set:

   (bitrate<=128)

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

   Original SDPng expression:

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

   Transforming feature elements Mbone, the
   Session Announcement Protocol (SAP) [RF2974] was used to feature predicates:

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

   RFC 2533 uses convey
   static session descriptions via multicast but the syntax rules same information
   could also be advertized by means of RFC 2506 [17] for feature tags.
   Note that in example above, the namespace name is not email, NetNews, or web pages.
   For some years, digital television used Electronic Program Guides
   (EPGs) to convey programming information (movie schedule, metadata,
   channel information) to large audiences. More recently, streaming
   services for
   feature tags, instead we (3G and beyond) mobile networks make use of similar
   concepts to announce streaming services.  As a response to these
   needs, the namespace prefix (for abbreviation).
   It should be noted, that implementations MUST replace generalized framework of Internet Media Guides (IMGs) has
   been devised to address conveying scheduling and media information to
   potentially large receiver groups.  This subsection addresses the namespace
   prefix use
   of SDPng elements with SAP and IMG-based session announcements.

   SAP and IMGs are used to disseminate a previously created (and
   typically fixed) session description to a potentially large audience.
   An interested member of the namespace name when performing audience will use the
   translation SDPng description
   communicated via SAP or IMGs to an RFC 2533 expression. The following figure depicts
   an corresponding expression for join the previous example:

   (& (http://www.iana.org/sdpng/video:resolution=QCIF)
      (http://www.iana.org/sdpng/video:frame-rate<=24)
      (http://www.example.com/h263plus:A=foo)
      (http://www.example.com/h263plus:B=bar))

   For announced media sessions.
   While this example, we assume that is supported by MIME types identifying SDPng contents with
   implied semantics, the prefix "video" IMG framework explicitly suggests interactive
   retrieval using HTTP.  Furthermore, IMG has been assigned
   to the namespace name "http://www.iana.org/sdpng/video" and concept of
   asynchronous notifications/updates to existing SDPng descriptions: it
   makes use of a (SIP-based) notification mechanism that the
   prefix "h263plus" has been assigned allows
   interested parties to monitor the namespace name "http://
   www.example.com/h263plus". In state of session descriptions and
   receive asynchronous updates whenever the following examples, we will description changes.

   SAP makes extensive use of the
   abbreviated form (using SDP session level attributes to
   provide a (limited) set of descriptive metadata for the namespace prefix only).

   Multiple independent capability elements MUST each be transformed
   using the specification above session,
   including scheduling and then combined into subject information. Quite a single RFC
   2533 feature set by connecting the individual feature sets using the
   '|' (OR) operator. For example, bit of this
   information is application-specific and is therefore not defined in
   the following sample SDPng potential
   configuration would be transformed as follows:

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

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

   Transforming feature elements to feature predicates:

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

5.2.2 Applying RFC 2533 Canonicalization

   After transforming different baseline SDPng capability descriptions from
   different participants into their equivalent RFC 2533 form, the
   following steps MUST be performed spec.  In particular, IMGs are expected to calculate the common subset of
   capabilities:

   1.  The individual feature sets MUST be combined into a single
       expression by creating a conjunction of the feature sets, i.e.,
       the feature sets MUST be connected by used
   with more encompassing metadata description formats (such as MPEG-7)
   which will carry the '&' (AND) operator.

   2.  The resulting expression MUST respective information so that these need not be reduced
   replicated in SDPng itself.

   While SAP only supports full SDP descriptions (which are minimal in
   size), IMGs allows in addition to disjunctive normal
       form, i.e., the canonical from as specified by RFC 2533 [15].

5.2.3 Integrating Feature Sets into (potentially large)
   (collections of) SDPng

   A feature set that has been created by combining multiple independent
   feature sets descriptions and by reducing the result for canonical form does not
   indicate directly which associated metadata to carry
   delta information or pointers to contents (URIs).  The structured
   format of the capability elements belong XML-based SDP goes well with both concepts and allows
   to the
   common subset identify subparts of capabilities. SDPng uses messages where and perform operations
   on them via well-defined means.

5.2 Real-Time-Streaming

   Real-time streaming provides an interactive way to offer real-time
   media to users.  In contrast to the following approach:
   After a "collapsing process" that has determined announcement/broadcast based
   described in the commonly
   supported capabilities, previous section, where the resulting RFC 2533 expression communication is compared
   to mostly
   unidirectional and interested receivers just "tune" into the original SDPng capability description. For this purpose, each
   SDPng capability element is transformed to
   respective media session, with RTSP an RFC 2533 expression and
   matched against interactive session setup
   exists.  This also informs the negotiation result (by constructing media server that there are parties
   interested in a conjunction
   of particular media stream and provides the two feature sets). If opportunity
   to the resulting canonical disjunctive form
   is non-empty, client to obtain the respective capability element represents most appropriate variant of a commonly
   supported capability media
   stream.

   Similar to SAP and can be adopted for IMGs, RTSP has, from its intended usage, a clear
   distinction between offering a set of Potential Configurations (by
   the conference
   configuration.

   A future version server) and choosing one out of this document will specify how to adopt
   individual values from these (by the client).  There is
   no capability negotiation result for process involved: the server provides a
   complete SDPng
   capability element. document describing all Components making up a
   presentation and includes detailed codec and transport parameters for
   each of there.  The following steps MUST be performed to determine whether an
   individual capability element (e.g., from client may only pick one out of the contributing
   SDPng capability descriptions) belongs to the result feature set.

   Let R be the result feature set obtained from the canonicalization as
   specified in Section 5.2.2.

   1.  For alternatives for
   each capability element, generate the equivalent RFC 2533
       feature set by applying the steps specified in Section 5.2.1. Let
       C be the resulting feature set.

   2.  Combine R and C into a single feature set by building a
       conjunction of the two feature sets (& R C). Let the result be
       the feature set T.

   3.  Reduce T offered Components but has no further option to disjunctive normal form by applying the
       canonicalization as defined negotiate
   parameters in RFC 2533 [15].

   4.  If the remaining disjunction depth.  Where some additional exchange is non-empty, necesary --
   e.g. for the constraints
       specified by capability element (the origin of C) can be
       satisfied by R, i.e., C represents a commonly supported
       capability.

5.2.4 Processing Negotiation Results

   The capability negotiation results in an updated list of capability
   elements of the SDPng "cap" element. The capability elements describe client's transport addresses and security parameters --,
   the commonly supported capabilities. Capabilities that respective parameters are not
   supported by all end-systems have been removed.

   Definition elements (inside the SDPng "def" element) no encoded in SDPng; instead,
   additional RTSP header fields and
   configuration descriptions (inside the parameters are field for this
   purpose.

   Hence, SDPng "alt" element) that
   reference capability elements that have been removed after is only used to describe alternatives to gain access to
   streaming media out of which the
   negotiation process, MUST be removed as well. Configuration
   description (inside client has to choose.  No
   interaction takes place at the SDPng "alt" element) level.

   It should be noted that reference
   non-existing definition elements (inside the SDPng "def" element")
   MUST SAP or IMG-based announcements may also be removed.

6. IANA Considerations

   The IANA should set up a registry for XML namespaces for SDPng and
   SDPng package definitions.

   The SDP parameter registry (http://www.iana.org/assignments/
   sdp-parameters) should be converted
   used to SDPng package definitions.

7. Open Issues

      Revise usage of terminology (potential configuration, actual
      configuration)

      Do we need an explicit mechanism point users to declare RTSP servers.  In such a case, the used packages?
      E.g., <pkg ref="http://www.iana.org/sdpng/audio"/>

      Data model for audio package: sampling-rate vs. RTP clock rate

      Bib. references: distinguish normative and informational

      A registry (reuse of SDP mechanisms
   "negotiation" is a two-stage process: the media discovery takes place
   using SAP or IMG and names etc.) needs leads to be
      set up (IANA considerations).

8. Acknowledgements the RTSP server.  The authors would like to thank Teodora Guenkova, Goran Petrovic and
   Markus Nosse for their feedback and detailed comments.

References

   [1]   Kutscher, D., Ott, J., Bormann, C. actual streaming
   invocation process then takes place interactively between the RTSP
   client and I. Curcio, "Requirements
         for server as described in this section.

        C->M: DESCRIBE rtsp://foo/audio-play RTSP/1.0
              CSeq: 1

        M->C: RTSP/1.0 200 OK
              CSeq: 1
              Content-Type: application/sdp
              Content-Length: ...

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

   	  owner="A@example.com" id="98765432" version="1"
      >

      	<cap>
      		<audio:codec name="avp:pcmu">
      			<audio:encoding>PCMU</audio:encoding>
      			<audio:channels>1</audio:channels>
      			<audio:sampling>8000</audio:sampling>
      		</audio:codec>
      		<audio:codec name="avp:gsm">
      			<audio:encoding>GSM</audio:encoding>
      			<audio:channels>1</audio:channels>
      			<audio:sampling>8000</audio:sampling>
      		</audio:codec>
   	</cap>
   	<def>
              	<rtp:udp name="rtp-cfg1" ref="rtpudpip4">
              	  <rtp:ip-addr>192.168.47.11</rtp:ip-addr>
              	  <rtp:rtp-port>51400</rtp:rtp-port>
              	</rtp:udp>
   	</def>
      	<cfg>
      		<component>
      			<alt>
      				<audio:codec ref="avp:pcmu"/>
      				<rtp:udp ref="rtp-cfg1">
      					<rtp:pt>0</rtp:pt>
      				</rtp:udp>
      			</alt>
      			<alt>
   				<audio:codec ref="avp:gsm"/>
      				<rtp:udp ref="rtp-cfg1">
      					<rtp:pt>3</rtp:pt>
      				</rtp:udp>
      			</alt>
      		</component>
      	</cfg>
      </sdpng>

        C->M: SETUP rtsp://foo/audio-play RTSP/1.0
              CSeq: 2
              Transport: RTP/AVP;unicast;client_port=8000-8001

        M->C: RTSP/1.0 200 OK
              CSeq: 2
              Transport: RTP/AVP;unicast;client_port=8000-8001;
                         server_port=51400-51401
              Session: 12345678

   To be continued with PLAY and, after the audio track has completed,
   finished with TEARDOWN.

5.3 Two-Way Session Description and Capability Negotiation", Internet
         Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001.

   [2]   Handley, M. and V. Jacobsen, "SDP: Setup

   The major application of SDP today is its use with the Session Description
         Protocol", RFC 2327, April 1998.

   [3]   Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
         "RTP: A Transport
   Initiation Protocol for Real-Time Applications", RFC
         3550, July 2003.

   [4]   Schulzrinne, H. (SIP) [RFC3261].  Session descriptions are used
   configure the media streams between two parties involved in a
   multimedia call.

   SIP is used to establish and S. Casner, "RTP Profile for Audio modify multimedia sessions, and Video
         Conferences SDPng
   may be carried at least in SIP INVITE, ACK and UPDATE messages as
   well as in a number of responses. From dealing with Minimal Control", RFC 3551, July 2003.

   [5]   Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
         M., Bolot, J., Vega-Garcia, A. legacy SDP (and
   its essential non-suitability for capability negotiation), a
   particular use and S. Fosse-Parisis, "RTP
         Payload interpretation of SDP has been defined for Redundant Audio Data", SIP,
   generalized in the offer/answer model documented in RFC 2198, September 1997.

   [6]   Rosenberg, J. 3264.

   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 H. Schulzrinne, "An RTP Payload Format Actual
   Configurations. There need not be a single Actual Configuration
   chosen at setup time within the SIP signaling. Instead, a number of
   Potential Configurations is signaled in SIP (with all transport
   parameters required for
         Generic Forward Error Correction", RFC 2733, December 1999.

   [7]   Perkins, C. carrying media streams) and O. Hodson, "Options the Actual
   Configuration is only identified by the payload type which is
   actually being transmitted at any point in time.

   Note that since SDPng does not distinguish between Potential and
   Actual Configurations at the syntax, this has no implications on the
   SDPng signaling itself but is merely up to interpretation.

   SIP relies on an "offer/answer" model for Repair the exchange of Streaming
         Media", RFC 2354, June 1998.

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

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

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

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

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

   [13]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         SDP", RFC 3264, June 2002.

   [14]  Hollenbeck, S., Rose, M. configuration information. Either the caller or the callee sends
   an initial session description that is processed by the other side
   and L. Masinter, "Guidelines for returned. For capability negotiation, this means that the
         Use of Extensible Markup Language (XML) within IETF Protocols",
         BCP 70, RFC 3470, January 2003.

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

   [16]  Yergeau, F., "UTF-8,
   negotiation follows a transformation format of ISO 10646", RFC
         2279, January 1998.

   [17]  Holtman, K., Mutz, A. two-stage-process: The "offerer" sends its
   capability description to the receiver. The receiver processes the
   offerers capabilities and T. Hardie, "Media Feature Tag
         Registration Procedure", BCP 31, RFC 2506, March 1999.

Authors' Addresses

   Dirk Kutscher
   TZI, Universitaet Bremen
   Bibliothekstr. 1
   Bremen  28359
   Germany

   Phone: +49.421.218-7595, sip:dku@tzi.org
   Fax:   +49.421.218-7000
   EMail: dku@tzi.uni-bremen.de

   Joerg Ott
   TZI, Universitaet Bremen
   Bibliothekstr. 1
   Bremen  28359
   Germany

   Phone: +49.421.201-7028, sip:jo@tzi.org
   Fax:   +49.421.218-7000
   EMail: jo@tzi.uni-bremen.de

   Carsten Bormann
   TZI, Universitaet Bremen
   Bibliothekstr. 1
   Bremen  28359
   Germany

   Phone: +49.421.218-7024, sip:cabo@tzi.org
   Fax:   +49.421.218-7000
   EMail: cabo@tzi.org

Appendix A. Formal Syntax Specifications

A.1 SDPng Base DTD

   The following DTD specifies the SDPng base syntax. DTDs are not
   XML-Namespace aware, therefore the following DTD his own capabilities and generates a result
   capability description that is for informational
   purposes only. Moreover, sent back to the content models for offerer. Both sides
   now know the element types
   "cap" commonly supported configurations and "def" have to be empty in this DTD as the specific element
   types for can initiate the allowed child elements are not defined by
   media sessions.

   Because of this strict "offer/answer" model, the base
   specification but by independent package definitions. Common
   requirements for these element types such as offerer must already
   send complete configurations (i.e. include transport addresses) along
   with the "name" attribute
   cannot capability descriptions. The answer must also contain
   complete configuration parameters. The following figure shows, how
   SDPng content can be expressed used in an INVITE request with XML DTDs.

   <!ELEMENT sdpng (cap, def?, cfg, constraints?, info?)>

   <!ELEMENT cap ANY>

   <!ELEMENT def ANY>

   <!ELEMENT cfg (component+)>

   <!ELEMENT component (alt+)>
   <!ATTLIST component
     name CDATA #REQUIRED
     media CDATA #IMPLIED
   >

   <!ELEMENT alt ANY>
   <!ATTLIST alt
     name CDATA #REQUIRED
   >

A.2 SDPng XML-Schema Specification

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

   <!-- a corresponding
   200 OK message.

   Simple description document with only one alternative:

         F1 INVITE A data type for the "status" attribute
     status=mandatory: feature match MUST be successful
     status=opt:       optional feature, feature match MAY fail
   -->

     <xsd:simpleType name="status">
       <xsd:restriction base="xsd:string">
         <xsd:enumeration value="mandatory"/>
         <xsd:enumeration value="opt"/>
       </xsd:restriction>
     </xsd:simpleType>

   <!-- Base type for definition elements -->

     <xsd:complexType name="Definition" abstract="true">
       <xsd:attribute name="name" type="xsd:string" use="optional"/>
       <xsd:attribute name="ref" type="xsd:string" use="optional"/>
     </xsd:complexType>

   <!--
   Data type for -> B

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

      <?xml version="1.0" encoding="UTF-8"?>

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

   	  owner="A@example.com" id="98765432" version="1"
      >

      	<cap>
      		<audio:codec name="avp:pcmu">
      			<audio:encoding>PCMU</audio:encoding>
      			<audio:channels>1</audio:channels>
      			<audio:sampling>8000</audio:sampling>
      		</audio:codec>
      		<audio:codec name="avp:gsm">
      			<audio:encoding>GSM</audio:encoding>
      			<audio:channels>1</audio:channels>
      			<audio:sampling>8000</audio:sampling>
      		</audio:codec>
   	</cap>
   	<def>
              	<rtp:udp name="rtp-cfg1" ref="rtpudpip4">
              	  <rtp:ip-addr>192.168.47.11</rtp:ip-addr>
              	  <rtp:rtp-port>51400</rtp:rtp-port>
              	</rtp:udp>
   	</def>
      	<cfg>
      		<component>
      			<alt>
      				<audio:codec ref="avp:pcmu"/>
      				<rtp:udp ref="rtp-cfg1">
      					<rtp:pt>0</rtp:pt>
      				</rtp:udp>
      			</alt>
      			<alt>
   				<audio:codec ref="avp:gsm"/>
      				<rtp:udp ref="rtp-cfg1">
      					<rtp:pt>3</rtp:pt>
      				</rtp:udp>
      			</alt>
      		</component>
      	</cfg>
      </sdpng>

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

         F2 (100 Trying) B -> A

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

      ==================================================
         F3 180 Ringing B -> A

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

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

         F4 200 OK B -> A

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

      <?xml version="1.0" encoding="UTF-8"?>

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

   	  owner="B@example.com" id="4595647" version="1"
      >

      	<cap>
      		<audio:codec name="avp:pcmu">
      			<audio:encoding>PCMU</audio:encoding>
      			<audio:channels>1</audio:channels>
      			<audio:sampling>8000</audio:sampling>
      		</audio:codec>
      		<audio:codec name="avp:gsm">
      			<audio:encoding>GSM</audio:encoding>
      			<audio:channels>1</audio:channels>
      			<audio:sampling>8000</audio:sampling>
      		</audio:codec>
   	</cap>
   	<def>
              	<rtp:udp name="rtp-cfg1" ref="rtpudpip4">
              	  <rtp:ip-addr>192.168.47.12</rtp:ip-addr>
              	  <rtp:rtp-port>60006</rtp:rtp-port>
              	</rtp:udp>
   	</def>
      	<cfg>
      		<component>
      			<alt>
   				<audio:codec ref="avp:gsm"/>
      				<rtp:udp ref="rtp-cfg1">
      					<rtp:pt>3</rtp:pt>
      				</rtp:udp>
      			</alt>
      		</component>
      	</cfg>
      </sdpng>

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

      ACK from A to B omitted

   In the content model of mandatory feature elements of type
   token
    -->

     <xsd:complexType name="token">
       <xsd:simpleContent>
         <xsd:extension base="xsd:NMTOKEN">
   	<xsd:attribute name="status" type="sdpng:status" fixed="mandatory"/>
         </xsd:extension>
       </xsd:simpleContent>
     </xsd:complexType>

   <!--
   Data type for INVITE message, A sends B a description document that
   specifies exactly one component with two alternatives (the PCMU and
   GSM audio streams).  The alternatives make reference to the content model of optional feature elements of
   type token
    -->

     <xsd:complexType name="opttoken">
       <xsd:simpleContent>
         <xsd:extension base="xsd:NMTOKEN">
   	<xsd:attribute name="status" type="sdpng:status" fixed="opt"/>
         </xsd:extension>
       </xsd:simpleContent>
     </xsd:complexType>
   <!--
   Data type for
   capability section where the content model of mandatory feature elements of type
   token list
   -->

     <xsd:complexType name="tokenlist">
       <xsd:simpleContent>
         <xsd:extension base="xsd:NMTOKENS">
   	<xsd:attribute name="status" type="sdpng:status" fixed="mandatory"/>
         </xsd:extension>
       </xsd:simpleContent>
     </xsd:complexType>

   <!--
   Data type for two codec types are defined.  All
   required transport parameters are already contained in the content model of optional feature elements of type
   token list
   -->

     <xsd:complexType name="opttokenlist">
       <xsd:simpleContent>
         <xsd:extension base="xsd:NMTOKENS">
   	<xsd:attribute name="status" type="sdpng:status" fixed="opt"/>
         </xsd:extension>
       </xsd:simpleContent>
     </xsd:complexType>

   <!--
   Data type for respective
   descriptions but they are kept separate from the content model of mandatory feature elements of type
   numerical value
   -->

     <xsd:complexType name="numval">
       <xsd:attribute name="status" type="sdpng:status" fixed="mandatory"/>
       <xsd:attribute name="val" type="xsd:decimal"/>
     </xsd:complexType>

   <!--
   Data type capability part.
   The <def> element contains a definition for the content model of optional feature elements of
   type numerical value
   -->

     <xsd:complexType name="optnumval">
       <xsd:attribute name="status" type="sdpng:status" fixed="opt"/>
       <xsd:attribute name="val" type="xsd:decimal"/>
     </xsd:complexType>
   <!--
   Data type for RTP media sessions so
   that this needs not be repeated in the content model of mandatory feature elements configuration of type
   numerical range
   -->

     <xsd:complexType name="numrange">
       <xsd:attribute name="status" type="sdpng:status" fixed="mandatory"/>
       <xsd:attribute name="min" type="xsd:decimal"/>
       <xsd:attribute name="max" type="xsd:decimal"/>
     </xsd:complexType>

   <!--
   Data type for the content model of optional feature elements single
   component.  Note that the semantics of
   type numerical range
   -->

     <xsd:complexType name="optnumrange">
       <xsd:attribute name="status" type="sdpng:status" fixed="opt"/>
       <xsd:attribute name="min" type="xsd:decimal"/>
       <xsd:attribute name="max" type="xsd:decimal"/>
     </xsd:complexType>

   <!-- Base type for definition elements -->

     <xsd:complexType name="Constraint" abstract="true">
       <xsd:attribute name="name" type="xsd:string" use="optional"/>
     </xsd:complexType>

   <!-- The base element for constraint element -->
   <!-- FIXME: substitutionGroup? -->

     <xsd:element name="constraint" type="sdpng:Constraint" abstract="true">
     </xsd:element>

   <!-- Base type for information elements -->

     <xsd:complexType name="Information" abstract="true">
       <xsd:attribute name="name" type="xsd:string" use="optional"/>
     </xsd:complexType>

   <!-- The base element for constraint element -->
   <!-- FIXME: substitutionGroup? -->
     <xsd:element name="information" type="sdpng:Information" abstract="true">
     </xsd:element>

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

   <!--
   SDPng the component is not
   explicitly specified (in an <info> element) but rather implied.

   In the 200 OK message, B sends an updated description document structure
   -->

     <xsd:element name="sdpng">
       <xsd:complexType>
         <xsd:sequence>
   	<xsd:element ref="sdpng:cap"/>
   	<xsd:element ref="sdpng:def" minOccurs="0"/>
   	<xsd:element ref="sdpng:cfg"/>
   	<xsd:element ref="sdpng:constraints" minOccurs="0"/>
   	<xsd:element ref="sdpng:info" minOccurs="0"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   <!-- to A.
   B supports the payload format that A has offered and adds his own
   transport parameters to the configuration information, specifying the
   endpoint address where B wants to receive media data. In order to
   disambiguate its transport configurations from A's, B sets the
   attribute "endpoint" to the value "B". The base element specific value of the
   "endpoint" attribute is not important, the only requirements are that
   a party that contributes to the session description, must use a
   unique name for capability the endpoint attribute and definition that a contributing party
   must use the same value for the endpoint attributes of all elements -->
   <!-- FIXME: substitutionGroup? -->

     <xsd:element name="definition" type="sdpng:Definition" abstract="true">
     </xsd:element>

   <!-- The mandatory "cap" element -->

     <xsd:element name="cap">
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   <!--
   it adds to the session description.

   The optional "def" element -->

     <xsd:element name="def">
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   <!-- The mandatory "cfg" element -->

     <xsd:element name="cfg">
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:component" maxOccurs="unbounded"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   <!-- The "component" element -->

     <xsd:element name="component">
       <xsd:complexType>
         <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>

     <xsd:element name="alt">
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
         </xsd:sequence>
         <xsd:attribute name="name" type="xsd:string"/>
       </xsd:complexType>
     </xsd:element>

   <!-- The optional "constraints" element -->

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

   <!-- offer/answer model allows communicating peers to determine a
   (common) mode of operation to exchange media streams in a single
   round-trip.  Basically, the offerer proposes a set of components,
   providing one or more alternatives ("potential configurations") for
   each of these. From this offer, the answerer learns which components
   may be used and which configurations are applicable to realize these
   components.  The optional "info" element -->
     <xsd:element name="info">
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:information" maxOccurs="unbounded"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   </xsd:schema>

Appendix B. Sample Package Definitions

B.1 Sample RTP Package Definition

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

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

     <xsd:complexType name="IPVersion">
       <xsd:simpleContent>
         <xsd:restriction base="sdpng:tokenlist">
   	<xsd:enumeration value="IP4"/>
   	<xsd:enumeration value="IP6"/>
         </xsd:restriction>
       </xsd:simpleContent>
     </xsd:complexType>

     <xsd:complexType name="RTPUDP">
       <xsd:complexContent>
         <xsd:extension base="sdpng:Definition">
   	<xsd:all>
   	  <xsd:element name="network" type="rtp:IPVersion" minOccurs="0"/>
   	  <xsd:element name="ip-addr" type="sdpng:opttoken" minOccurs="0"/>
   	  <xsd:element name="rtp-port" type="sdpng:opttoken" minOccurs="0"/>
   	  <xsd:element name="rtcp-port" type="sdpng:opttoken" minOccurs="0"/>
   	  <xsd:element name="pt" type="sdpng:opttoken" minOccurs="0"/>
   	</xsd:all>
         </xsd:extension>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:element name="udp" type="rtp:RTPUDP" substitutionGroup="sdpng:definition"/>

   </xsd:schema>

B.2 Sample Audio Package Definition

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

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

     <xsd:complexType name="Codec">
       <xsd:complexContent>
         <xsd:restriction base="sdpng:Definition">
   	<xsd:all>
   	  <xsd:element name="encoding" type="sdpng:token" minOccurs="0"/>
   	  <xsd:element name="channels" type="sdpng:tokenlist" minOccurs="0"/>
   	  <xsd:element name="sampling" type="sdpng:tokenlist" minOccurs="0"/>
   	</xsd:all>
         </xsd:restriction>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:element name="codec" type="audio:Codec" substitutionGroup="sdpng:definition"/>

   </xsd:schema>

B.3 Sample Video Package Definition

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

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

     <xsd:complexType name="Codec">
       <xsd:complexContent>
         <xsd:restriction base="sdpng:Definition">
   	<xsd:all>
   	  <xsd:element name="encoding" type="sdpng:token" minOccurs="0"/>
   	  <xsd:element name="sampling" type="sdpng:tokenlist" minOccurs="0"/>
   	  <xsd:element name="framerate" type="sdpng:opttokenlist" minOccurs="0"/>
   	  <xsd:element name="size" type="sdpng:opttokenlist" minOccurs="0"/>
   	  <xsd:element name="bitrate" type="sdpng:optnumrange" minOccurs="0"/>
   	  <xsd:element name="min-quant" type="sdpng:optnum" minOccurs="0"/>
   	  <xsd:element name="max-quant" type="sdpng:optnum" minOccurs="0"/>
   	  <xsd:element name="gop-size" type="sdpng:optnum" minOccurs="0"/>
   	</xsd:all>
         </xsd:restriction>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:element name="codec" type="video:Codec" substitutionGroup="sdpng:definition"/>

   </xsd:schema>

Appendix C. Sample answerer indicates which components it supports
   (e.g. receiving a offer including audio and video, it may disallow
   the video session and go with an audio-only conversation) and also
   provides possible configurations to implement those components.
   Along with the media types and codec parameters, offerer and answerer
   specify which transport addresses to use and, in case of RTP, which
   payload types they want to use for sending. Offerer and answerer
   agree on a common set of media streams ("components") and on a
   possible set of codecs for each of these ("configurations") as well
   as the transport addresses and other parameters to be used.  However,
   they do not fix a certain configuration (unless only a single one is
   exchanged in each direction).  Instead, for each selected media
   stream, either peer may choose and dynamically switch to any of the
   configurations indicated by the other side in the respective offer or
   answer.

   For using SDPng Description

   <?xml version="1.0" encoding="UTF-8"?>

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

   	<cap>
   		<audio:codec name="avp:pcmu">
   			<audio:encoding>PCMU</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:gsm">
   			<audio:encoding>GSM</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g723">
   			<audio:encoding>G723</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:dvi4">
   			<audio:encoding>DVI4</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000 11025 16000 22050</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:lpc">
   			<audio:encoding>LPC</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g722">
   			<audio:encoding>G722</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:l16">
   			<audio:encoding>L16</audio:encoding>
   			<audio:channels>1 2</audio:channels>
   			<audio:sampling>44100</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:qcelp">
   			<audio:encoding>QCELP</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:cn">
   			<audio:encoding>CN</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:mpa">
   			<audio:encoding>MPA</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>32000 44100 48000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g728">
   			<audio:encoding>G728</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g729">
   			<audio:encoding>G728</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g726-40">
   			<audio:encoding>G726-40</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g726-32">
   			<audio:encoding>G726-32</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g726-24">
   			<audio:encoding>G726-24</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g726-16">
   			<audio:encoding>G726-16</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g729d">
   			<audio:encoding>G729D</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g729e">
   			<audio:encoding>G729E</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:gsm-efr">
   			<audio:encoding>GSM-EFR</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:l8">
   			<audio:encoding>L8</audio:encoding>
   			<audio:channels>1 2</audio:channels>
   			<audio:sampling>8000 16000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:red">
   			<audio:encoding>RED</audio:encoding>
   			<audio:channels>1 2</audio:channels>
   			<audio:sampling>8000 16000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:vdvi">
   			<audio:encoding>RED</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>var</audio:sampling>
   		</audio:codec>

   		<video:codec name="avp:celb">
   		 <video:encoding>CelB</video:encoding>
   		 <video:framerate>4 6 8 12 16 20 24 30</video:framerate>
   		</video:codec>

   		<rtp:udp name="rtpudpip6">
   			<rtp:network>IP6</rtp:network>
   		</rtp:udp>

   	</cap>
           <def>
           	<rtp:udp name="rtp-cfg1" ref="rtpudpip6">
           	  <rtp:ip-addr>::1</rtp:ip-addr>
           	  <rtp:rtp-port>9546</rtp:rtp-port>
           	</rtp:udp>
           </def>
   	<cfg>
   		<component>
   			<alt>
   				<audio:codec ref="avp:pcmu"/>
   				<rtp:udp ref="rtp-cfg1">
   					<rtp:pt>0</rtp:pt>
   				</rtp:udp>
   			</alt>
   		</component>
   	</cfg>
   </sdpng>

Appendix D. Use of SDPng in Conjunction with other IETF Signaling
            Protocols

   This appendix is included temporarily and the offer/answer model (RFC 3264), the basic
   defined in RFC 3264 for informational purposes
   only.  Ultimately, it is up to each existing generating offers and evolving application
   protocol to specify its use of SDPng. answers apply.  The
   following considerations specifically apply when using offer/answer
   with SDPng model provides the notion (instead of Components SDP) documents:

   o  For each component to indicate the
   intended types of collaboration between the users in e.g. a
   teleconferencing scenario.

   Three different abstractions are defined that are used be used, all necessary parameters MUST be
      given for describing at least one configuration per component, i.e. transport
      addresses and payload formats MUST be specified along with the properties of a specific Component:
      capabilities.

   o  a Capability refers to  Matching of components is done based upon their identification in
      the fact that one info part of the involved parties
      supports one particular way SDPng document using predefined identifiers
      for certain session types.
      For simple sessions, where applications can implicitly derive the
      semantics of exchanging media -- defined the the offered components, no such explicit mapping
      is necessary.  In this case, i.e. if the entire "<info>" element
      or the respective elements in
      terms of transport, codec, and other parameters -- as part the "<info>" element are absent, the
      order of appearance in the
      media session. SDPng document is relevant as it is
      with SDP.

   o  For each component, the answerer performs a Potential Configuration denotes a set of capability matching Capabilities
      from
      process as per then application's requirements
      For all those involved parties components that may be used for one
      particular Component.

   o  an Actual Configuration indicates are acceptable, the Potential Configuration(s)
      and its associated media session parameters which was/were chosen
      by answerer determines
      whether or not to accept the involved parties offer.
      If the answerer decides to instantiate accept the offer for a certain Component.

   As mentioned before,
      component, it MUST accept at least one of the potential
      configurations for the respective component.  It SHOULD indicate
      this abstract notion by setting the "status" attribute of the interactions between
   a number component and of communicating systems needs to be mapped the
      selected configuration(s) to "active" (but it MAY also omit the
   application scenarios of SDPng
      status attribute in conjunction with both cases).
      It is RECOMMENDED that the various IETF
   signaling protocols, including (but not limited to) SAP, SIP, RTSP,
   and MEGACO.

   In general, this section provides recommendations and possible
   scenarios answerer selects exactly one
      configuration for each component as "active".

   o  The answerer MAY refuse individual configurations for a component
      from the use of SDPng within specific protocols and
   applications. Is does offer in two ways.
      If the configuration shall not specify normative requirements.

D.1 The Session Announcement Protocol (SAP)

   SAP is be used to disseminate a previously created (and typically fixed)
   session description to at all during a potentially large audience. An interested
   member of session,
      e.g. because the audience will use answerer does not support it or because the SDPng description contained in
   SAP
      answere does not want to join use this configuration at all, the announced media sessions.

   This means that a SAP announcement contains
      answerer MUST set the Actual Configurations
   of all Components that are part "status" attribute of the overall teleconference or
   broadcast.

   A SAP announcement may contain multiple Actual Configurations for the
   same Component. respective
      component to "unused".  In this case, the "same" (i.e. semantically
   equivalent) media data from one configuration must be available from
   each of the Actual Configurations.

   Each receiver of a SAP announcement with SDPng compares its locally
   stored Capabilities to realize a certain Component against answerer MAY omit all
      the Actual
   Configurations elements 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 respective configuration's elements.
      This is empty, equivalent to setting the
   receiver cannot participate port parameter to "0" in the announced session.

   SAP may SDP.
      If a configuration shall be substituted by HTTP (in accepted (i.e. the general case, at least), SMTP,
   NNTP, or other IETF protocols suitable for conveying a respective
      capability shall be indicated) but no media
   description from one entity to one or more other without session shall be
      instantiated (not even on hold!), the intend
   for further negotiation answerer MUST set the
      "status" attribute of the respective configuration to "available"
      and omit all media-session-specific parameters the configuration.

   o  The answerer MAY refuse entire components that the offerer has
      included in two ways.
      If a component shall not be used at all during a session parameters.

   SAP makes extensive use -- e.g.
      because the answerer does not support any of the SDP session level attributes configurations
      listed or because the answere does not want to
   provide a (limited) use this component
      at all -- the answerer MUST set of descriptive metadata for the session,
   including scheduling and subject information. Quite a bit "status" attribute of the
      respective component's to "unused".  In this
   information is application-specific and is therefore not defined case, the answerer
      MAY omit all the elements contained in the baseline SDPng spec.

D.2 Session Initiation Protocol (SIP)

   SIP respective component
      elements.  This is used equivalent to establish and modify multimedia sessions, and SDPng
   may be carried at least in SIP INVITE, ACK and UPDATE messages as
   well as setting the port parameter to "0"
      in SDP.
      If a number of responses. From dealing with legacy SDP (and
   its essential non-suitability for component shall be accepted (i.e. the respective capability negotiation), a
   particular use and interpretation
      shall be indicated) but no media session shall be instantiated
      (not even on hold!), the answerer MUST set the "status" attribute
      of SDP has been defined the respective component to "available", omit all
      media-session-specific parameters from all acceptable
      configurations for SIP,
   generalized the respective component.

   o  For each component, the alternative potential configurations MUST
      be listed in the offer/answer model documented in RFC 3264.

   One of the important flexibilities introduced by SIP's usage order of SDP
   is that a sender can change dynamically between all codecs that preference.
      Within 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 configuration, alternatives (e.g. different codecs) MUST
      also be listed in the media stream.  From this arises one important
   consequence order of preference.
      The considerations of RFC 3264 to simply arriving at symmetric
      codec use apply.

   If a component shall be put on hold, the conceptual view status attribute of a Component within SDPng.

   There is no clear distinction between Potential and Actual
   Configurations. There need not the
   component MUST be a single Actual Configuration
   chosen at setup time within set to "sendonly", "recvonly", or "inactive", as
   appropriate.  In this case, the SIP signaling. Instead, a number status attributes of
   Potential Configurations is signaled in SIP (with all transport
   parameters required for carrying media streams) and the Actual
   Configuration is only identified by the payload type which is
   actually being transmitted at any point in time.

   Note
   contained configurations that since SDPng does not distinguish between Potential and
   Actual Configurations at the syntax, this has no implications were previously active MUST be set to
   indicate "sendonly", "recvonly", or "inactive", as appropriate.  The
   rules from RFC 3264 for putting media streams on the hold SHALL apply.

5.4 Multi-Party-Conferencing with Negotiation

   The indipendent capability collapsing properties of SDPng signaling itself.

   SIP relies on an "offer/answer" model for allow to
   calculate the exchange "intersection" of capability any number of SDPng documents
   independently and configuration information. Either the caller or the callee sends
   an initial session description that is processed by the other side
   and returned. For capability negotiation, this means that the
   negotiation follows easily derive a two-stage-process: The "offerer" sends its
   capability description to the receiver. common subset. Details are TBD in a
   separate document.

6. IANA Considerations

   The receiver processes the
   offerers capabilities and his own capabilities and generates IANA should set up a result
   capability registry for XML namespaces for SDPng and
   SDPng package definitions.

   The SDP parameter registry (http://www.iana.org/assignments/
   sdp-parameters) should be converted to SDPng package definitions.

7. Open Issues

      Meta-Information for SDPng description that is sent back (author, version etc.)?

      Revise usage of terminology (potential configuration, actual
      configuration)

      Do we need an explicit mechanism to declare the offerer. Both sides
   now know the commonly supported configurations used packages?
      E.g., <pkg ref="http://www.iana.org/sdpng/audio"/>

      Data model for audio package: sampling-rate vs. RTP clock rate

      Bib. references: distinguish normative and can initiate the
   media sessions.

   Because informational

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

   Simple description document with only one alternative:

         F1 INVITE A -> B

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

      <?xml version="1.0" encoding="UTF-8"?>

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

   	  owner="A@example.com" id="98765432" version="1"
      >
      	<cap>
      		<audio:codec name="avp:pcmu">
      			<audio:encoding>PCMU</audio:encoding>
      			<audio:channels>1</audio:channels>
      			<audio:sampling>8000</audio:sampling>
      		</audio:codec>
      		<audio:codec name="avp:gsm">
      			<audio:encoding>GSM</audio:encoding>
      			<audio:channels>1</audio:channels>
      			<audio:sampling>8000</audio:sampling>
      		</audio:codec>
   	</cap>
   	<def>
              	<rtp:udp name="rtp-cfg1" ref="rtpudpip4">
              	  <rtp:ip-addr>192.168.47.11</rtp:ip-addr>
              	  <rtp:rtp-port>51400</rtp:rtp-port>
              	</rtp:udp>
   	</def>
      	<cfg>
      		<component>
      			<alt>
      				<audio:codec ref="avp:pcmu"/>
      				<rtp:udp ref="rtp-cfg1">
      					<rtp:pt>0</rtp:pt>
      				</rtp:udp>
      			</alt>
      			<alt>
   				<audio:codec ref="avp:gsm"/>
      				<rtp:udp ref="rtp-cfg1">
      					<rtp:pt>3</rtp:pt>
      				</rtp:udp>
      			</alt>
      		</component>
      	</cfg>
      </sdpng>

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

         F2 (100 Trying) B -> A

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

         F3 180 Ringing B -> A

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

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

         F4 200 OK B -> A

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

      <?xml version="1.0" encoding="UTF-8"?>

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

   	  owner="B@example.com" id="4595647" version="1"
      >

      	<cap>
      		<audio:codec name="avp:pcmu">
      			<audio:encoding>PCMU</audio:encoding>
      			<audio:channels>1</audio:channels>
      			<audio:sampling>8000</audio:sampling>
      		</audio:codec>
      		<audio:codec name="avp:gsm">
      			<audio:encoding>GSM</audio:encoding>
      			<audio:channels>1</audio:channels>
      			<audio:sampling>8000</audio:sampling>
      		</audio:codec>
   	</cap>
   	<def>
              	<rtp:udp name="rtp-cfg1" ref="rtpudpip4">
              	  <rtp:ip-addr>192.168.47.12</rtp:ip-addr>
              	  <rtp:rtp-port>60006</rtp:rtp-port>
              	</rtp:udp>
   	</def>
      	<cfg>
      		<component>
      			<alt>
   				<audio:codec ref="avp:gsm"/>
      				<rtp:udp ref="rtp-cfg1">
      					<rtp:pt>3</rtp:pt>
      				</rtp:udp>
      			</alt>
      		</component>
      	</cfg>
      </sdpng>

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

      ACK from A to B omitted

   In the INVITE message, A sends B a description document that
   specifies exactly one component with two alternatives (the PCMU and
   GSM audio streams).
      set up (IANA considerations).

8. Acknowledgements

   The alternatives make reference authors would like to the
   capability section where the two codec types are defined.  All
   required transport parameters all already contained in the respective
   descriptions.  The <def> element contains a definition for the RTP
   media sessions so that this needs not be repeated in the
   configuration of the single component.  Note that the semantics of
   the component is not explicitly specified (in an <info> element) but
   rather implied.

   In the 200 OK message, B sends an updated description document to A.
   B supports the payload format that A has offered thank Teodora Guenkova, Goran Petrovic and adds his own
   transport parameters to the configuration information, specifying the
   endpoint address where B wants to receive media data. In order to
   disambiguate its transport configurations from A's, B sets the
   attribute "endpoint" to the value "B". The specific value of the
   "endpoint" attribute is not important, the only requirements are that
   a party that contributes to the session description, must use a
   unique name
   Markus Nosse for the endpoint attribute their feedback and that a contributing party
   must use the same value detailed comments.

References

   [1]   Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements
         for the endpoint attributes of all elements
   it adds to the session description.

D.3 Real-Time Streaming Protocol (RTSP)

   In contrast to SIP, RTSP has, from its intended usage, a clear
   distinction between offering a set of Potential Configurations (by
   the server) Session Description and choosing one out of these (by the client).  However,
   there is no capability negotiation process involved: the server
   provides a complete SDPng document describing all Components making
   up a presentation Capability Negotiation", Internet
         Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001.

   [2]   Handley, M. and includes detailed codec V. Jacobsen, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

   [3]   Schulzrinne, H., Casner, S., Frederick, R. and transport
   parameters V. Jacobson,
         "RTP: A Transport Protocol for each of there.  The client may only pick one out of
   alternatives Real-Time Applications", RFC
         3550, July 2003.

   [4]   Schulzrinne, H. and S. Casner, "RTP Profile for each of the offered Components but has no further
   option to negotiate parameters in depth. Where some additional
   exchange is necesary -- e.g. Audio and Video
         Conferences with Minimal Control", RFC 3551, July 2003.

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

   [6]   Rosenberg, J. and
   security parameters --, the respective parameters are no encoded in
   SDPng; instead, additional RTSP header fields H. Schulzrinne, "An RTP Payload Format for
         Generic Forward Error Correction", RFC 2733, December 1999.

   [7]   Perkins, C. and parameters are
   field O. Hodson, "Options for this purpose.

   Hence, SDPng is only used to describe alternatives to gain access to
   streaming media out Repair of which the client has to choose.  No
   interaction takes place at the Streaming
         Media", RFC 2354, June 1998.

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

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

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

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

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

   [13]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         SDP", RFC 3264, June 2002.

   [14]  Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the
         Use of Extensible Markup Language (XML) within IETF Protocols",
         BCP 70, RFC 3470, January 2003.

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

   [16]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         2279, January 1998.

   [17]  Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
         Registration Procedure", BCP 31, RFC 2506, March 1999.

Authors' Addresses

   Dirk Kutscher
   TZI, Universitaet Bremen
   Bibliothekstr. 1
   Bremen  28359
   Germany

   Phone: +49.421.218-7595, sip:dku@tzi.org
   Fax:   +49.421.218-7000
   EMail: dku@tzi.uni-bremen.de

   Joerg Ott
   TZI, Universitaet Bremen
   Bibliothekstr. 1
   Bremen  28359
   Germany

   Phone: +49.421.201-7028, sip:jo@tzi.org
   Fax:   +49.421.218-7000
   EMail: jo@tzi.uni-bremen.de

   Carsten Bormann
   TZI, Universitaet Bremen
   Bibliothekstr. 1
   Bremen  28359
   Germany

   Phone: +49.421.218-7024, sip:cabo@tzi.org
   Fax:   +49.421.218-7000
   EMail: cabo@tzi.org

Appendix A. Formal Syntax Specifications

A.1 SDPng Base DTD

   The following DTD specifies the SDPng base syntax. DTDs are not
   XML-Namespace aware, therefore the following DTD is for informational
   purposes only. Moreover, the content models for the element types
   "cap" and "def" have to be empty in this DTD as the specific element
   types for the allowed child elements are not defined by the base
   specification but by independent package definitions. Common
   requirements for these element types such as the "name" attribute
   cannot be expressed with XML DTDs.

   <!ELEMENT sdpng (cap?, def?, cfg, constraints?, info?)>

   <!ELEMENT cap ANY>

   <!ELEMENT def ANY>

   <!ELEMENT cfg (component+)>

   <!ELEMENT component (alt+)>
   <!ATTLIST component
     name   CDATA #REQUIRED
     media  CDATA #IMPLIED
     status CDATA #IMPLIED
   >

   <!ELEMENT alt ANY>
   <!ATTLIST alt
     name CDATA   #REQUIRED
     status CDATA #IMPLIED
   >

   <!ELEMENT constraints ANY>

   <!ELEMENT info (part+)>

   <!ELEMENT part ANY>
   <!ATTLIST part
     type CDATA #REQUIRED
     ref  CDATA #IMPLIED
   >

A.2 SDPng XML-Schema Specification

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

   <!--

   A data type for the "status" attribute

     status=mandatory: feature match MUST be successful
     status=opt:       optional feature, feature match MAY fail
   -->

     <xsd:simpleType name="status">
       <xsd:restriction base="xsd:string">
         <xsd:enumeration value="mandatory"/>
         <xsd:enumeration value="opt"/>
       </xsd:restriction>
     </xsd:simpleType>

   <!-- Base type for definition elements -->

     <xsd:complexType name="Definition" abstract="true">
       <xsd:attribute name="name" type="xsd:string" use="optional"/>
       <xsd:attribute name="ref" type="xsd:string" use="optional"/>
     </xsd:complexType>

   <!--
   Data type for the content model of mandatory feature elements of type
   token
    -->

     <xsd:complexType name="token">
       <xsd:simpleContent>
         <xsd:extension base="xsd:NMTOKEN">
   	<xsd:attribute name="status" type="sdpng:status" fixed="mandatory"/>
         </xsd:extension>
       </xsd:simpleContent>
     </xsd:complexType>
   <!--
   Data type for the content model of optional feature elements of
   type token
    -->

     <xsd:complexType name="opttoken">
       <xsd:simpleContent>
         <xsd:extension base="xsd:NMTOKEN">
   	<xsd:attribute name="status" type="sdpng:status" fixed="opt"/>
         </xsd:extension>
       </xsd:simpleContent>
     </xsd:complexType>

   <!--
   Data type for the content model of mandatory feature elements of type
   token list
   -->

     <xsd:complexType name="tokenlist">
       <xsd:simpleContent>
         <xsd:extension base="xsd:NMTOKENS">
   	<xsd:attribute name="status" type="sdpng:status" fixed="mandatory"/>
         </xsd:extension>
       </xsd:simpleContent>
     </xsd:complexType>

   <!--
   Data type for the content model of optional feature elements of type
   token list
   -->

     <xsd:complexType name="opttokenlist">
       <xsd:simpleContent>
         <xsd:extension base="xsd:NMTOKENS">
   	<xsd:attribute name="status" type="sdpng:status" fixed="opt"/>
         </xsd:extension>
       </xsd:simpleContent>
     </xsd:complexType>

   <!--
   Data type for the content model of mandatory feature elements of type
   numerical value
   -->

     <xsd:complexType name="numval">
       <xsd:attribute name="status" type="sdpng:status" fixed="mandatory"/>
       <xsd:attribute name="val" type="xsd:decimal"/>
     </xsd:complexType>

   <!--
   Data type for the content model of optional feature elements of
   type numerical value
   -->

     <xsd:complexType name="optnumval">
       <xsd:attribute name="status" type="sdpng:status" fixed="opt"/>
       <xsd:attribute name="val" type="xsd:decimal"/>
     </xsd:complexType>

   <!--
   Data type for the content model of mandatory feature elements of type
   numerical range
   -->

     <xsd:complexType name="numrange">
       <xsd:attribute name="status" type="sdpng:status" fixed="mandatory"/>
       <xsd:attribute name="min" type="xsd:decimal"/>
       <xsd:attribute name="max" type="xsd:decimal"/>
     </xsd:complexType>

   <!--
   Data type for the content model of optional feature elements of
   type numerical range
   -->

     <xsd:complexType name="optnumrange">
       <xsd:attribute name="status" type="sdpng:status" fixed="opt"/>
       <xsd:attribute name="min" type="xsd:decimal"/>
       <xsd:attribute name="max" type="xsd:decimal"/>
     </xsd:complexType>

   <!-- Base type for definition elements -->

     <xsd:complexType name="Constraint" abstract="true">
       <xsd:attribute name="name" type="xsd:string" use="optional"/>
     </xsd:complexType>

   <!-- The base element for constraint element -->
   <!-- FIXME: substitutionGroup? -->

     <xsd:element name="constraint" type="sdpng:Constraint" abstract="true">
     </xsd:element>

   <!-- Base type for information elements -->

     <xsd:complexType name="Information" abstract="true">
       <xsd:attribute name="type" type="xsd:string"/>
       <xsd:attribute name="ref" type="xsd:string" use="optional"/>
     </xsd:complexType>

   <!-- The nformation part element -->

     <xsd:element name="part" type="sdpng:Information" abstract="true">
     </xsd:element>

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

   <!--
   SDPng document structure
   -->

     <xsd:element name="sdpng">
       <xsd:complexType>
         <xsd:sequence>
   	<xsd:element ref="sdpng:cap" minOccurs="0"/>
   	<xsd:element ref="sdpng:def" minOccurs="0"/>
   	<xsd:element ref="sdpng:cfg"/>
   	<xsd:element ref="sdpng:constraints" minOccurs="0"/>
   	<xsd:element ref="sdpng:info" minOccurs="0"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   <!-- The base element for capability and definition elements -->
   <!-- FIXME: substitutionGroup? -->

     <xsd:element name="definition" type="sdpng:Definition" abstract="true">
     </xsd:element>

   <!-- The optional "cap" element -->

     <xsd:element name="cap">
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   <!-- The optional "def" element -->

     <xsd:element name="def">
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   <!-- The mandatory "cfg" element -->

     <xsd:element name="cfg">
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:component" maxOccurs="unbounded"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   <!-- The "component" element -->

     <xsd:element name="component">
       <xsd:complexType>
         <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" use="optional"/>
         <xsd:attribute name="status" type="xsd:string" use="optional"/>
       </xsd:complexType>
     </xsd:element>

     <xsd:element name="alt">
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:definition" maxOccurs="unbounded"/>
         </xsd:sequence>
         <xsd:attribute name="name" type="xsd:string"/>
         <xsd:attribute name="status" type="xsd:string" use="optional"/>
       </xsd:complexType>
     </xsd:element>

   <!-- The optional "constraints" element -->

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

   <!-- The optional "info" element -->

     <xsd:element name="info">
       <xsd:complexType mixed="false">
         <xsd:sequence>
   	<xsd:element ref="sdpng:part" maxOccurs="unbounded"/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

   </xsd:schema>

Appendix B. Sample Package Definitions

B.1 Sample RTP Package Definition

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

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

     <xsd:complexType name="IPVersion">
       <xsd:simpleContent>
         <xsd:restriction base="sdpng:tokenlist">
   	<xsd:enumeration value="IP4"/>
   	<xsd:enumeration value="IP6"/>
         </xsd:restriction>
       </xsd:simpleContent>
     </xsd:complexType>

     <xsd:complexType name="RTPUDP">
       <xsd:complexContent>
         <xsd:extension base="sdpng:Definition">
   	<xsd:all>
   	  <xsd:element name="network" type="rtp:IPVersion" minOccurs="0"/>
   	  <xsd:element name="ip-addr" type="sdpng:opttoken" minOccurs="0"/>
   	  <xsd:element name="rtp-port" type="sdpng:opttoken" minOccurs="0"/>
   	  <xsd:element name="rtcp-port" type="sdpng:opttoken" minOccurs="0"/>
   	  <xsd:element name="pt" type="sdpng:opttoken" minOccurs="0"/>
   	</xsd:all>
         </xsd:extension>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:element name="udp" type="rtp:RTPUDP" substitutionGroup="sdpng:definition"/>

   </xsd:schema>

B.2 Sample Audio Package Definition

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

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

     <xsd:complexType name="Codec">
       <xsd:complexContent>
         <xsd:restriction base="sdpng:Definition">
   	<xsd:all>
   	  <xsd:element name="encoding" type="sdpng:token" minOccurs="0"/>
   	  <xsd:element name="channels" type="sdpng:tokenlist" minOccurs="0"/>
   	  <xsd:element name="sampling" type="sdpng:tokenlist" minOccurs="0"/>
   	</xsd:all>
         </xsd:restriction>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:element name="codec" type="audio:Codec" substitutionGroup="sdpng:definition"/>

   </xsd:schema>

B.3 Sample Video Package Definition

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

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

     <xsd:complexType name="Codec">
       <xsd:complexContent>
         <xsd:restriction base="sdpng:Definition">
   	<xsd:all>
   	  <xsd:element name="encoding" type="sdpng:token" minOccurs="0"/>
   	  <xsd:element name="sampling" type="sdpng:tokenlist" minOccurs="0"/>
   	  <xsd:element name="framerate" type="sdpng:opttokenlist" minOccurs="0"/>
   	  <xsd:element name="size" type="sdpng:opttokenlist" minOccurs="0"/>
   	  <xsd:element name="bitrate" type="sdpng:optnumrange" minOccurs="0"/>
   	  <xsd:element name="min-quant" type="sdpng:optnum" minOccurs="0"/>
   	  <xsd:element name="max-quant" type="sdpng:optnum" minOccurs="0"/>
   	  <xsd:element name="gop-size" type="sdpng:optnum" minOccurs="0"/>
   	</xsd:all>
         </xsd:restriction>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:element name="codec" type="video:Codec" substitutionGroup="sdpng:definition"/>

   </xsd:schema>

Appendix C. Sample SDPng level.

        C->M: DESCRIBE rtsp://foo/audio-play RTSP/1.0
              CSeq: 1

        M->C: RTSP/1.0 200 OK
              CSeq: 1
              Content-Type: application/sdp
              Content-Length: ... Description

   <?xml version="1.0" encoding="UTF-8"?>

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

   	  owner="A@example.com" id="98765432" version="1"
   >

   	<cap>
   		<audio:codec name="avp:pcmu">
   			<audio:encoding>PCMU</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:gsm">
   			<audio:encoding>GSM</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g723">
   			<audio:encoding>G723</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:dvi4">
   			<audio:encoding>DVI4</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000 11025 16000 22050</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:lpc">
   			<audio:encoding>LPC</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g722">
   			<audio:encoding>G722</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:l16">
   			<audio:encoding>L16</audio:encoding>
   			<audio:channels>1 2</audio:channels>
   			<audio:sampling>44100</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:qcelp">
   			<audio:encoding>QCELP</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:cn">
   			<audio:encoding>CN</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:mpa">
   			<audio:encoding>MPA</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>32000 44100 48000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g728">
   			<audio:encoding>G728</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g729">
   			<audio:encoding>G728</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g726-40">
   			<audio:encoding>G726-40</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g726-32">
   			<audio:encoding>G726-32</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g726-24">
   			<audio:encoding>G726-24</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g726-16">
   			<audio:encoding>G726-16</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g729d">
   			<audio:encoding>G729D</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:g729e">
   			<audio:encoding>G729E</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:gsm-efr">
   			<audio:encoding>GSM-EFR</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>8000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:l8">
   			<audio:encoding>L8</audio:encoding>
   			<audio:channels>1 2</audio:channels>
   			<audio:sampling>8000 16000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:red">
   			<audio:encoding>RED</audio:encoding>
   			<audio:channels>1 2</audio:channels>
   			<audio:sampling>8000 16000</audio:sampling>
   		</audio:codec>
   		<audio:codec name="avp:vdvi">
   			<audio:encoding>RED</audio:encoding>
   			<audio:channels>1</audio:channels>
   			<audio:sampling>var</audio:sampling>
   		</audio:codec>

   		<video:codec name="avp:celb">
   		 <video:encoding>CelB</video:encoding>
   		 <video:framerate>4 6 8 12 16 20 24 30</video:framerate>
   		</video:codec>

   		<rtp:udp name="rtpudpip6">
   			<rtp:network>IP6</rtp:network>
   		</rtp:udp>

   	</cap>
           <def>
           	<rtp:udp name="rtp-cfg1" ref="rtpudpip4">
              	  <rtp:ip-addr>192.168.47.11</rtp:ip-addr>
              	  <rtp:rtp-port>51400</rtp:rtp-port> ref="rtpudpip6">
           	  <rtp:ip-addr>::1</rtp:ip-addr>
           	  <rtp:rtp-port>9546</rtp:rtp-port>
           	</rtp:udp>
           </def>
   	<cfg>
   		<component>
   			<alt>
   				<audio:codec ref="avp:pcmu"/>
   				<rtp:udp ref="rtp-cfg1">
   					<rtp:pt>0</rtp:pt>
   				</rtp:udp>
   			</alt>
      			<alt>
   				<audio:codec ref="avp:gsm"/>
      				<rtp:udp ref="rtp-cfg1">
      					<rtp:pt>3</rtp:pt>
      				</rtp:udp>
      			</alt>
   		</component>
   	</cfg>
   </sdpng>

        C->M: SETUP rtsp://foo/audio-play RTSP/1.0
              CSeq: 2
              Transport: RTP/AVP;unicast;client_port=8000-8001

        M->C: RTSP/1.0 200 OK
              CSeq: 2
              Transport: RTP/AVP;unicast;client_port=8000-8001;
                         server_port=51400-51401
              Session: 12345678

   To be continued with PLAY and, after the audio track has completed,
   finished with TEARDOWN.

D.4 Media Gateway Control Protocol (MEGACOP)

   The MEGACO architecture also follows the SDPng model

Appendix D. Change History

   draft-ietf-mmusic-sdpng-08.txt

      *  Changed introduction: emphasis on non-negotiation scenarios
         (broadcast etc.), describe main concepts

      *  element "cap" is now OPTIONAL.

      *  new "status" attribute for "component" element type

      *  new "part" element for "info" element (meta-information)

      *  Removed section "Specification 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 Capability Negotiation"

      *  Removed appendix "Use of SDPng in Conjunction 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 other IETF
         Signaling Protocols"

      *  Added section "Usage of SDPng in Different Application
         Scenarios"

      *  Updated DTD and examples XML-Schema-Definition wrt to be defined in a separate document.

Appendix E. Change History afore-mentioned
         changes

   draft-ietf-mmusic-sdpng-07.txt

      *  New document structure:

         1.  Intro

         2.  Terminology and System Model

         3.  Overview

         4.  SDPng Syntax Specification

         5.  Negotiation Process

      *  Changes to Section 3: Describe all concepts

      *  Section 4 provides complete specification

      *  Changed XML syntax: Represent tokens and token list as element
         content (not attributes)

      *  a new element "def" for reusable definitions

      *  Adapted secion 5 accordingly
      *  Sample DTD, schema definition and same SDPng document in
         appendix

      *  Updated section 5.1 (Offer/Answer)

      *  Updated appendix D (Use of SDPng in conjunction with other IETF
         Signaling Protocols)

   draft-ietf-mmusic-sdpng-06.txt

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

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

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

      *  Changed "profile" to "package".

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

      *  Removed audio and RTP packages from appendix.

      *  Added a section "Syntax Definition".

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

   draft-ietf-mmusic-sdpng-05.txt

      *  Moved audio and RTP packages to appendix.

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

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

      *  Corrections to schema definitions and examples

   draft-ietf-mmusic-sdpng-04.txt

      *  New section on capability negotiation.

      *  New section on referencing definitions.

      *  New section on properties.

      *  New section on definition groups.

   draft-ietf-mmusic-sdpng-03.txt

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

      *  Clarification in the text

      *  Fixed examples

      *  Added example libraries as appendices

      *  More details on usage with SIP, including examples.

   draft-ietf-mmusic-sdpng-02.txt

      *  Added a  section on formal specification mechanisms.

   draft-ietf-mmusic-sdpng-01.txt

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

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

      *  section "Session Attributes" replaces section "Session"

      *  new appendix on audio codec definitions

Intellectual Property Statement
   IPR Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which that may cover technology that may be required to practice implement
   this standard. Please address the information to the IETF Executive
   Director. at ietf-
   ipr@ietf.org.

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved. (2005). This document and translations of it may be copied and furnished is subject
   to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies rights, licenses and derivative works. However, this
   document itself may not be modified restrictions contained in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, BCP 78, and
   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 set forth therein, the Internet Society or its successors or assignees. authors retain all their rights.

   This document and the information contained herein is are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIMS DISCLAIM 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.

Acknowledgment

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