draft-ietf-mmusic-sdpng-00.txt   draft-ietf-mmusic-sdpng-01.txt 
Network Working Group Kutscher Network Working Group Kutscher
Internet-Draft Ott Internet-Draft Ott
Expires: October 18, 2001 Bormann Expires: January 18, 2002 Bormann
TZI, Universitaet Bremen TZI, Universitaet Bremen
April 19, 2001 July 20, 2001
Session Description and Capability Negotiation Session Description and Capability Negotiation
draft-ietf-mmusic-sdpng-00.txt draft-ietf-mmusic-sdpng-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at To view the entire list of Internet-Draft Shadow Directories, see
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 18, 2001.
This Internet-Draft will expire on January 18, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document defines a language for describing multimedia sessions This document defines a language for describing multimedia sessions
with respect to configuration parameters and capabilities of end with respect to configuration parameters and capabilities of end
systems. systems.
This document is a product of the Multiparty Multimedia Session This document is a product of the Multiparty Multimedia Session
Control (MMUSIC) working group of the Internet Engineering Task Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the working Force. Comments are solicited and should be addressed to the working
group's mailing list at confctrl@isi.edu and/or the authors. group's mailing list at confctrl@isi.edu and/or the authors.
Document Revision Document Revision
$Revision: 1.8 $ $Revision: 2.0 $
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and System Model . . . . . . . . . . . . . . . . 5 2. Terminology and System Model . . . . . . . . . . . . . . . 6
3. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. SDPng . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . . 8 3.1 Conceptual Outline . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Components & Configurations . . . . . . . . . . . . . . . . 10 3.1.2 Components & Configurations . . . . . . . . . . . . . . . 11
3.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.4 Session . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.4 Session Attributes . . . . . . . . . . . . . . . . . . . . 14
3.2 Syntax Proposal . . . . . . . . . . . . . . . . . . . . . . 12 3.1.4.1 Owner . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 External Definition Packages . . . . . . . . . . . . . . . . 14 3.1.4.2 Session Identification . . . . . . . . . . . . . . . . . . 15
3.3.1 Profile Definitions . . . . . . . . . . . . . . . . . . . . 15 3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines) . . . 16
3.3.2 Library Definitions . . . . . . . . . . . . . . . . . . . . 15 3.1.4.4 Component Semantic Specification . . . . . . . . . . . . . 17
3.4 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Syntax Definition Mechanisms . . . . . . . . . . . . . . . 18
4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3 External Definition Packages . . . . . . . . . . . . . . . 20
References . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.1 Profile Definitions . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 3.3.2 Library Definitions . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 3.4 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 22
4. Formal Specification . . . . . . . . . . . . . . . . . . . 24
5. Use of SDPng in conjunction with other IETF Signaling
Protocols . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 The Session Announcement Protocol (SAP) . . . . . . . . . 25
5.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . 26
5.3 Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . 26
5.4 Media Gateway Control Protocol (MEGACOP) . . . . . . . . . 27
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 28
References . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 30
A. Base SDPng Specifications for Audio Codec Descriptions . . 31
A.1 DVI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.2 G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.3 G.726 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.4 G.728 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.5 G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.6 G.729 Annex D and E . . . . . . . . . . . . . . . . . . . 33
A.7 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.7.1 GSM Full Rate . . . . . . . . . . . . . . . . . . . . . . 33
A.7.2 GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . 33
A.7.3 GSM Enhanced Full Rate . . . . . . . . . . . . . . . . . . 33
A.8 L8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.9 L16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.10 LPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.11 MPA . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.12 PCMA and PCMU . . . . . . . . . . . . . . . . . . . . . . 34
A.13 QCELP . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.14 VDVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Full Copyright Statement . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Multiparty multimedia conferencing is one application that requires Multiparty multimedia conferencing is one of the applications that
the dynamic interchange of end system capabilities and the require dynamic interchange of end system capabilities and the
negotiation of a parameter set that is appropriate for all sending negotiation of a parameter set that is appropriate for all sending
and receiving end systems in a conference. For some applications, and receiving end systems in a conference. For some applications,
e.g. for loosely coupled conferences, it may be sufficient to simply e.g. for loosely coupled conferences or for broadcast scenarios, it
have session parameters be fixed by the initiator of a conference. may be sufficient to simply have session parameters be fixed by the
In such a scenario no negotiation is required because only those initiator of a conference. In such a scenario no negotiation is
participants with media tools that support the predefined settings required because only those participants with media tools that
can join a media session and/or a conference. support the predefined settings can join a media session and/or a
conference.
This approach is applicable for conferences that are announced some This approach is applicable for conferences that are announced some
time ahead of the actual start date of the conference. Potential time ahead of the actual start date of the conference. Potential
participants can check the availability of media tools in advance participants can check the availability of media tools in advance
and tools like session directories can configure media tools on and tools like session directories can configure media tools on
startup. This procedure however fails to work for conferences startup. This procedure however fails to work for conferences
initiated spontaneously like Internet phone calls or ad-hoc initiated spontaneously like Internet phone calls or ad-hoc
multiparty conferences. Fixed settings for parameters like media multiparty conferences. Fixed settings for parameters like media
types, their encoding etc. can easily inhibit the initiation of types, their encoding etc. can easily inhibit the initiation of
conferences, for example in situations where a caller insists on a conferences, for example in situations where a caller insists on a
skipping to change at page 3, line 45 skipping to change at page 3, line 46
conferences with TV-broadcast or lecture characteristics (one main conferences with TV-broadcast or lecture characteristics (one main
active source) it is usually not desired to re-negotiate parameters active source) it is usually not desired to re-negotiate parameters
every time a new participant with an exotic configuration joins every time a new participant with an exotic configuration joins
because it may inconvenience existing participants or even exclude because it may inconvenience existing participants or even exclude
the main source from media sessions. But conferences with equal the main source from media sessions. But conferences with equal
"rights" for participants that are open for new participants on the "rights" for participants that are open for new participants on the
other hand would need a different model of dynamic capability other hand would need a different model of dynamic capability
negotiation, for example a telephone call that is extended to a negotiation, for example a telephone call that is extended to a
3-parties conference at some time during the session. 3-parties conference at some time during the session.
SDP [1] allows to specify multimedia sessions (i.e. conferences, SDP [2] allows to specify multimedia sessions (i.e. conferences,
"session" as used here is not to be confused with "RTP session"!) "session" as used here is not to be confused with "RTP session"!)
by providing general information about the session as a whole and by providing general information about the session as a whole and
specifications for all the media streams (RTP sessions and others) specifications for all the media streams (RTP sessions and others)
to be used to exchange information within the multimedia session. to be used to exchange information within the multimedia session.
Currently, media descriptions in SDP are used for two purposes: Currently, media descriptions in SDP are used for two purposes:
o to describe session parameters for announcements and invitations o to describe session parameters for announcements and invitations
(the original purpose of SDP) (the original purpose of SDP) and
o to describe the capabilities of a system (and possibly provide a o to describe the capabilities of a system and possibly provide a
choice between a number of alternatives). Note that SDP was not choice between a number of alternatives (which SDP was not
designed to facilitate this. designed for).
A distinction between these two "sets of semantics" is only made A distinction between these two "sets of semantics" is only made
implicitly. implicitly.
In the following we first introduce a model for session description This document is based upon a set of requirements specified in a
and capability negotiation and define some terms that are later used companion document [1] In the following we first introduce a model
to express some requirements. Note that this list of requirements is for session description and capability negotiation and introduce the
possibly incomplete. The purpose of this document is to initiate the basic terms used throughout this specification (section 2). Then we
development of a session description and capability negotiation outline the concept for the concepts underlying SDPng and introduce
framework. the syntactical components step by step in section 3. In section 4,
we provide a formal definition of the SDPng session description
language. Finally, we overview aspects of using SDPng with various
IETF signaling protocols in section 5. In Appendix A, we introduce
basic audio codec and payload type definitions.
2. Terminology and System Model 2. Terminology and System Model
Any (computer) system has, at a time, a number of rather fixed Any (computer) system has, at a time, a number of rather fixed
hardware as well as software resources. These resources ultimately hardware as well as software resources. These resources ultimately
define the limitations on what can be captured, displayed, rendered, define the limitations on what can be captured, displayed, rendered,
replayed, etc. with this particular device. We term features enabled replayed, etc. with this particular device. We term features enabled
and restricted by these resources "system capabilities". and restricted by these resources "system capabilities".
Example: System capabilities may include: a limitation of the Example: System capabilities may include: a limitation of the
skipping to change at page 7, line 24 skipping to change at page 7, line 24
To decide on a certain actual configuration, a negotiation process To decide on a certain actual configuration, a negotiation process
needs to take place between the involved peers: needs to take place between the involved peers:
1. to determine which potential configuration(s) they have in 1. to determine which potential configuration(s) they have in
common, and common, and
2. to select one of this shared set of common potential 2. to select one of this shared set of common potential
configurations to be used for information exchange (e.g. based configurations to be used for information exchange (e.g. based
upon preferences, external constraints, etc.). upon preferences, external constraints, etc.).
In SAP [9] -based session announcements on the Mbone, for which SDP In SAP-based [11] session announcements on the Mbone, for which SDP
was originally developed, the negotiation procedure is non-existent. was originally developed, the negotiation procedure is non-existent.
Instead, the announcement contains the media stream description sent Instead, the announcement contains the media stream description sent
out (i.e. the actual configurations) which implicitly describe what out (i.e. the actual configurations) which implicitly describe what
a receiver must understand to participate. a receiver must understand to participate.
In point-to-point scenarios, the negotiation procedure is typically In point-to-point scenarios, the negotiation procedure is typically
carried out implicitly: each party informs the other about what it carried out implicitly: each party informs the other about what it
can receive and the respective sender chooses from this set a can receive and the respective sender chooses from this set a
configuration that it can transmit. configuration that it can transmit.
Capability negotiation must not only work for 2-party conferences Capability negotiation must not only work for 2-party conferences
but is also required for multi-party conferences. Especially for the but is also required for multi-party conferences. Especially for the
latter case it is required that the process of determining the latter case it is required that the process of determining the
subset of allowable potential configurations is deterministic to subset of allowable potential configurations is deterministic to
reduce the number of required round trips before a session can be reduce the number of required round trips before a session can be
established. established.
In the following, we elaborate on requirements for an SDPng The requirements for the SDPng specification, subdivided into
specification, subdivided into general requirements and requirements general requirements and requirements for session descriptions,
for session descriptions, potential and actual configurations as potential and actual configurations as well as negotiation rules,
well as negotiation rules. are captured in a companion document [1].
3. SDPng 3. SDPng
This section outlines a proposed solution for describing This section introduces the underlying concepts of the Session
capabilities that meets most of the above requirements. Note that at Description Protocol - next generation (SDPng) that is to meet most
this early point in time not all of the details are completely of the above requirements. The focus of this section is on the
filled in; rather, the focus is on the concepts of such a capability concepts of such a capability description and negotiation language
description and negotiation language. with a stepwise introduction of the various syntactical elements; a
full formal specification is provided in section 4.
3.1 Conceptual Outline 3.1 Conceptual Outline
Our concept for the description language follows the system model The description language follows the system model introduced in the
introduced in the beginning of this document. We use a rather beginning of this document. We use a rather abstract language to
abstract language to avoid misinterpretations due to different avoid misinterpretations due to different intuitive understanding of
intuitive understanding of terms as far as possible. terms as far as possible.
Our concept of a capability description language addresses various The concept of a capability description language addresses various
pieces of a full description of system and application capabilities pieces of a full description of system and application capabilities
in four separate "sections": in four separate "sections":
Definitions (elementary and compound) Definitions (elementary and compound); see Section 3.1.1.
Potential or Actual Configurations Potential or Actual Configurations; see Section 3.1.2.
Constraints Constraints; see Section 3.1.3.
Session attributes Session attributes; see Section 3.1.4.
3.1.1 Definitions 3.1.1 Definitions
The definition section specifies a number of basic abstractions that The definition section specifies a number of basic abstractions that
are later referenced to avoid repetitions in more complex are later referenced to avoid repetitions in more complex
specifications and allow for a concise representation. Definition specifications and allow for a concise representation. Definition
elements are labelled with an identifier by which they may be elements are labelled with an identifier by which they may be
referenced. They may be elementary or compound (i.e. combinations of referenced. They may be elementary or compound (i.e. combinations of
elementary entities). Examples of definitions of that sections elementary entities). Examples of definitions of that sections
include (but are not limited to) codec definitions, redundancy include (but are not limited to) codec definitions, redundancy
schemes, transport mechanisms and payload formats. schemes, transport mechanisms and payload formats.
Elementary definition elements do not reference other elements. Each Elementary definition elements do not reference other elements. Each
elementary entity only consists of one of more attributes and their elementary entity only consists of one of more attributes and their
values. Default values specified in the definition section may be values. Default values specified in the definition section may be
overridden in descriptions for potential (and later actual) overridden in descriptions for potential (and later actual)
configurations. The concrete mechanisms for overriding definitions configurations. A mechanisms for overriding definitions is specified
are still to be defined. below.
For the moment, elementary elements are defined for media types For the moment, elementary elements are defined for media types
(i.e. codecs) and for media transports. For each transport and for (i.e. codecs) and for media transports. For each transport and for
each codec to be used, the respective attributes need to be defined. each codec to be used, the respective attributes need to be defined.
This definition may either be provided within the "Definition"
This definition may either be provided within the "Definitions"
section itself or in an external document (similar to the section itself or in an external document (similar to the
audio-video profile or an IANA registry that define payload types audio-video profile or an IANA registry that define payload types
and media stream identifiers. and media stream identifiers.
It is not required to define all codec, transport mechanisms in a
definitions sections and reference them in the definition of
potential and actual configurations. Instead, a syntactic mechanism
is defined that allows to specify some definitions directly in a
configurations section.
Examples for elementary definitions: Examples for elementary definitions:
<audio-codec name="audio-basic" encoding="PCMU sampling_rate="8000 channels="1"/> <audio-codec name="audio-basic" encoding="PCMU"
sampling="8000 channels="1"/>
<audio-codec name="audio-L16-mono" encoding="L16 sampling_rate="44100 channels="1"/> <audio-codec name="audio-L16-mono" encoding="L16"
sampling="44100 channels="1"/>
The element type "audio-codec" is used in these examples to define The element type "audio-codec" is used in these examples to define
audio codec configurations. The configuration parameters are given audio codec configurations. The configuration parameters are given
as attribute values. as attribute values.
Compound elements combine a number of elementary and/or other Definitions may have default values specified along with them for
compound elements for more complex descriptions. This mechanism can each attribute (as well as for their contents). Some of these
be used for simple standard configurations such as G.711 over default values may be overridden so that a codec definition can
RTP/AVP as well as to express more complex coding schemes including easily be re-used in a different context (e.g. by specifying a
e.g. FEC schemes, redundancy coding, and layered coding. Again, such different sampling rate) without the need for a large number of base
definitions may be standardized and externalized so that there is no specifications. In the following example the definition of
need to repeat them in every specification. audio-L16-mono is re-used for the defintion of the corresponding
stereo codec. Appendix A provides a complete set of corresponding
audio-codec definitions of the codec used in RFC 1890 [4].
An example for the definition of a audio-redundancy format: <audio-codec name="audio-L16-stereo" ref="audio-L16-mono"
channels="2"/>
<audio-red name="red-pcm-gsm-fec"> The example shows how exisiting defintions can be referenced in new
<use ref="audio-basic"/> <use ref="audio-gsm"/> <use ref="parityfec"/> definitiones. This approach allows to have simple as well as more
</audio-red> complex definitions which are commonly used be available in an
extensible set of reference documents. Section 3.3 specifies the
mechanisms for external references.
In this example, the element type "audio-red" is used to define a Besides definitions of audio codecs there will be other definitions
redundant audio configuration that is labelled "red-pcm-gsm-fec" for like RTP payload format and specific transport mechanisms that are
later referencing. In the definition itself, the element type "use" suitable to be defined in a defintion section for later referencing.
is used to reference other definitions. The following example shows how RTP payload types are defined using
a pre-defined codec.
Definitions may have default values specified along with them for <rtp-pt name="rtp-avp-0" pt="0" format="audio-basic"/>
each attribute. Some of these default values may be overridden so <rtp-pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/>
that a codec definition can easily be re-used in a different context
(e.g. by specifying a different sampling rate) without the need for
a large number of base specifications.
This approach allows to have simple as well as more complex In this example, the payload type "rtp-avp-11" is defined with
definitions which are commonly used be available in an extensible payload type number 11, referencing the codec "audio-L16-mono".
set of reference documents. Section 3.3 specifies the mechanisms for Instead of referencing an existing definition it is also possible to
external references. define the format "inline":
<rtp-pt name="rtp-avp-10" pt="10">
<audio-codec encoding="L16" sampling="44100 channels="2"/>
</rtp-pt>
Note: For negotiation between endpoints, it may be helpful to define Note: For negotiation between endpoints, it may be helpful to define
two modes of operation: explicit and implicit. Implicit two modes of operation: explicit and implicit. Implicit
specifications may refer to externally defined entities to minimize specifications may refer to externally defined entities to minimize
traffic volume, explicit specifications would list all external traffic volume, explicit specifications would list all external
definitions used in a description in the "Definitions" section. definitions used in a description in the "Definitions" section.
Again, please see Section 3.3 for complete discussion of external Again, see Section 3.3 for complete discussion of external
definitions. definitions.
The "Definitions" section may be empty if all transport, codecs, and
other pieces needed to the specify Potential and Actual
Configurations (as detailed below) are either included by
referencing external definitions or are explicitly described within
the Configurations themselves.
3.1.2 Components & Configurations 3.1.2 Components & Configurations
The "Configurations" section contains all the components that The "Configurations" section contains all the components that
constitute the multimedia conference (IP telephone call, multiplayer constitute the multimedia conference (IP telephone call, multiplayer
gaming session etc.). For each of these components, the potential gaming session etc.). For each of these components, the potential
and, later, the actual configurations are given. Potential and, later, the actual configurations are given. Potential
configurations are used during capability exchange and/or configurations are used during capability exchange and/or
negotiation, actual configurations to configure media streams after negotiation, actual configurations to configure media streams after
negotiation or in session announcements (e.g. via SAP). A potential negotiation (e.g. with RTSP) or in session announcements (e.g. via
and the actual configuration of a component may be identical. SAP). A potential and the actual configuration of a component may be
identical.
Each component is labelled with an identifier so that it can be Each component is labelled with an identifier so that it can be
referenced, e.g. to associate semantics with a particular media referenced, e.g. to associate semantics with a particular media
stream. For such a component, any number of configurations may be stream. For such a component, any number of configurations may be
given with each configuration describing an alternate way to realize given with each configuration describing an alternate way to realize
the functionality of the respective component. the functionality of the respective component.
Each configuration (potential as well as actual) is labelled with an Each configuration (potential as well as actual) is labelled with an
identifier. A configuration combines one or more (elementary and/or identifier. A configuration combines one or more (elementary and/or
compound) entities from the "Definitions" section to describe a compound) entities from the "Definitions" section to describe a
potential or an actual configuration. Within the specification of potential or an actual configuration. Within the specification of
the configuration, default values from the referenced entities may the configuration, default values from the referenced entities may
be overwritten. be overwritten.
Note: Not all protocol environments and their respective operation
allow to explicitly distinguish between Potential and Actual
Configurations. Therefore, SDPng so far does not provide for
syntactical identification of a Configurations as being a Potential
or an Actual one.
The following example shows how RTP sessions can be described by
referencing payload definitions.
<cfg> <cfg>
<component name="audio1" media="audio"> <component name="interactive-audio" media="audio">
<alt name= AVP-audio-0"> <alt name="AVP-audio-0">
<rtp transport="udp-ip" format="audio-basic"> <rtp format="rtp-avp-0">
<addr type="mc"> <udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
<ipv4>239.239.239.239</ipv4> <port>30000</port>
</addr>
</rtp> </rtp>
</alt> </alt>
<alt name="AVP-audio-11"> <alt name= AVP-audio-11">
<rtp transport="udp-ip" format="audio-L16-mono"> <rtp format="rtp-avp-11">
<addr type="mc"> <udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
<ipv4>239.239.239.239</ipv4> <port>30000</port>
</addr>
</rtp> </rtp>
</alt> </alt>
</component> </component>
</cfg> </cfg>
For example, an IP telephone call may require just a single For example, an IP telephone call may require just a single
component id=interactive-audio with two possible ways of component "name=interactive-audio" with two possible ways of
implementing it. The two corresponding configurations are implementing it. The two corresponding configurations are
"AVP-audio-0" without modification, the other ("AVP-audio-11") uses "AVP-audio-0" without modification, the other ("AVP-audio-11") uses
linear 16-bit encoding. Typically, transport address parameters such linear 16-bit encoding. Typically, transport address parameters such
as the port number would also be provided. In this example, this as the port number would also be provided. In this example, this
information is given by the "addr" element. information is given by the "udp" element. Of course, it must be
possible to specify other transport mechanisms as well. See Section
3.2 for a discussion of extension mechanisms that allow applications
to use non-standard transport (or other) specifications.
During/after the negotiation phase, an actual configuration is During/after the negotiation phase, an actual configuration is
chosen out of a number of alternative potential configurations, the chosen out of a number of alternative potential configurations, the
actual configuration may refer to the potential configuration just actual configuration may refer to the potential configuration just
by its "id", possibly allowing for some parameter modifications. by its "id", possibly allowing for some parameter modifications.
Alternatively, the full actual configuration may be given. Alternatively, the full actual configuration may be given.
Instead of referencing existing payload type definitions it is also
possible to provide the required information "inline". The following
example illustrates this:
<cfg>
<component name="audio1" media="audio">
<alt name= AVP-audio-0">
<rtp>
<rtp-pt pt="0">
<audio-codec name="audio-basic" encoding="PCMU"
sampling="8000 channels="1"/>
</rtp-pt>
<udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
</rtp>
</alt>
</component>
</cfg>
The UDP/IPv4 multicast transport that is used in the examples is a
simple variant of a transport specification. More complex ones are
conceivable. For example, it must also be possible to specify the
usage of source filters (inclusion and exclusion), Source Specific
Multicast, the usage of multi-unicast, or other parameters.
Therefore it is possible to extend the definition of transport
mechanisms by providing the required information in the element
content. An example:
<cfg>
<component name="audio1" media="audio">
<alt name= AVP-audio-0">
<rtp format="rtp-avp-0">
<udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801">
<option name="ssm" sender="sender.example.com"/>
</udp>
</rtp>
</alt>
</component>
</cfg>
More transport mechanisms and options will be defined in future
versions of this document.
3.1.3 Constraints 3.1.3 Constraints
Definitions specify media, transport, and other capabilities, Definitions specify media, transport, and other capabilities,
whereas configurations indicate which combinations of these could be whereas configurations indicate which combinations of these could be
used to provide the desired functionality in a certain setting. used to provide the desired functionality in a certain setting.
There may, however, be further constraints within a system (such as There may, however, be further constraints within a system (such as
CPU cycles, DSP available, dedicated hardware, etc.) that limit CPU cycles, DSP available, dedicated hardware, etc.) that limit
which of these configurations can be instantiated in parallel (and which of these configurations can be instantiated in parallel (and
how many instances of these may exist). We deliberately do not how many instances of these may exist). We deliberately do not
skipping to change at page 11, line 45 skipping to change at page 13, line 21
configurations and to entity definitions and express and use simple configurations and to entity definitions and express and use simple
logic to express mutual exclusion, limit the number of logic to express mutual exclusion, limit the number of
instantiations, and allow only certain combinations. The following instantiations, and allow only certain combinations. The following
example shows the definition of a constraints that restricts the example shows the definition of a constraints that restricts the
maximum number of instantiation of two alternatives (that would have maximum number of instantiation of two alternatives (that would have
to be defined in the configuration section before) when they are to be defined in the configuration section before) when they are
used in parallel: used in parallel:
<constraints> <constraints>
<par> <par>
<use ref="AVP-audio-11" max="5"> <use ref="AVP-video-32" max="1"> <use-alt ref="AVP-audio-11" max="5">
<use-alt ref="AVP-video-32" max="1">
</par> </par>
</constraints> </constraints>
As the example shows, contraints are defined by defining limits on As the example shows, contraints are defined by defining limits on
simultaneous instantiations of alternatives. They are not defined by simultaneous instantiations of alternatives. They are not defined by
expressing abstract endsystem resources, such as CPU speed or memory expressing abstract endsystem resources, such as CPU speed or memory
size. size.
By default, the "Constraints" section is empty (or missing) which By default, the "Constraints" section is empty (or missing) which
means that no further restrictions apply. means that no further restrictions apply.
3.1.4 Session 3.1.4 Session Attributes
The "Session" section is used to describe general meta-information The fourth and final section of the SDPng syntax addresses session
parameters of the communication relationship to be invoked or layer attributes. These attributes largely include those defined by
modified. It contains most (if not all) of the general parameters of SDP [RFC2327] (which are explicitly indicated in the following
SDP (and thus will easily be usable with SAP for session specification) to describe originator, purpose, and timing of a
announcements). multimedia session among other characteristics. Furthermore, SDPng
includes attributes indicating the semantics of the various
Components in a teleconference or other session. This part of the
specification is open ended with an IANA registry to be set up to
register further types of components; only a few of the examples are
listed here.
In addition to the session description parameters, the "Session" A session-level specification for connection information (SDP "c="
section also ties the various components to certain semantics. If, line), bandwidth information (SDP "b=" line), and encryption keys
in current SDP, two audio streams were specified (possibly even (SDP "k=" lines) is deliberately not provided for in SDPng.
using the same codecs), there was little way to differentiate
between their uses (e.g. live audio from an event broadcast vs. the
commentary from the TV studio).
This section also allows to tie together different media streams or Session level attributes as defined by SDP still have to be examined
provide a more elaborate description of alternatives (e.g. subtitles and adopted for SDPng in a future revision of this specification.
or not, which language, etc.).
<conf> 3.1.4.1 Owner
<subject>SDPng test</subject>
<originator>joe@example.com</originator>
<about>A test conference</about>
<info name="audio1" function="speaker">
Video stream for the different speakers
<info>
</conf>
Further uses are envisaged but need to be defined in future versions The owner refers to the creator of a session as defined in RFC2327
of this document. ("o=" line). The syntax is as follows:
3.2 Syntax Proposal <owner user="username" id="session-id" version="version" nettype="IN"
addrtype="IP4" addr="130.149.25.97"/>
The owner field MUST be present if SDPng is used with SAP. For all
other protocols, the owner field MAY be specified. The attributes
listed above match those from the SDP specification; all attributes
MUST be present and they MUST be created following the rules of
RFC2327.
Note: There are several possible ways ahead on this part: "owner"
could stand as it is right now, but the various values of the
various attributes could be concatenated (separated by blanks) the
result being identical to the contents of the SDP "o=" line -- which
then could be represented as either a single attribute or as
contents of the "owner" element. Alternatively, the owner element
could become part of the "session" element described below. Or the
contents of the owner element could become an attribute of the
"session" element below.
3.1.4.2 Session Identification
The "session" element is used to identify the session and to provide
a description and possible further references. The following
attributes are defined:
name: The session name as it is to appear e.g. in a session
directory. This is equivalent to the SDP "s=" line. This
attribute MUST be present.
info: A pointer to further information about the session; this
attribute MUST contain a URI. The attribute itself is OPTIONAL.
The session element MAY contain arbitrary text of any length (but
authors are encouraged to keep the inline description brief and
provide additional information via URLs. This text is used to
provide a description of the session; it is the equivalent of the
SDP "i=" lines.
Furthermore, the session element MAY contain other elements of the
following types to provide further information about the session and
its creator:
info: The info element is intended to provide a pointer to further
information on the session itself. Its contents MUST be exactly
one URI. If both the info attribute and one or more info elements
are present, the union of the respective values is used. Info
elements are OPTIONAL, they MAY be repeated any number of times.
contact: The contact element provides contact information on the
creator of the session; its contents MUST be exactly one URI. Any
URI scheme suitable to reach a person or a group of persons is
acceptable (e.g. sip:, mailto:, tel:). Contact elements are
OPTIONAL, they MAY be repeated any number of times.
<session name="An SDPng seminar" info="http://www.dmn.tzi.org/ietf/mmusic/">
And here comes a long description of the seminar indicating what
this might be about and so forth. But we also include further
information -- as additional elements:
<info>http://www.ietf.org/</info>
<contact>mailto:joe@example.com</contact>
<contact>mailto:bob@example.com</contact>
<contact>tel:+49421281</contact>
<contact>sip:joe@example.com</contact>
<contact>sip:bob@example.com</contact>
</session>
3.1.4.3 Time Specification (SDP 't=', 'r=', and 'z=' lines)
The time specification for a session follows the same rules as in
SDP. Time specifications are usually only meaningful when used in
conjunction with SAP and hence are OPTIONAL. SDPng uses the
following elements and attributes to specify timing:
The element "time" is used to indicate a schedule for the session;
time has two optional attributes:
start: The starting time of the first occurrence of the session as
defined in RFC2327.
end: The ending time of the last occurrence of the session as
defined in RFC2327.
The time element MAY contain the following elements but otherwise
MUST be empty:
repeat: This element specifies the repetition pattern for the
schedule. There MAY be zero or more occurrences of this element
within the time element. "repeat" has two MANDATORY and one
OPTIONAL attribute and no further contents; the attributes are as
defined in SDP:
interval: The duration between two start times of the session.
This attribute MUST be present.
duration: The duration for which the session will be active
starting at each repetition interval. This attribute MUST be
present.
offset: The offset relative to "start" attribute at which this
repetition of the session is start. This attribute is
OPTIONAL; if it is absent, a default value of "0" is assumed.
Formatting of the attribute values MUST follow the rules defined
in RFC2327.
zone: The zone element specifies one or more time zone adjustments
as defined in RFC2327. This element MAY have zero or more
occurrences in the time element. It has two attributes as defined
in SDP:
adjtime: The time at which the next adjustment will take place.
delta: The adjustment offset (typically +/- 1 hours).
The example from RFC2327, page 16, expressed in SDPng:
<time start="3034423619" stop="3042462419">
<repeat interval="7d" duration="1h"/>
<repeat interval="7d" duration="1h" offset="25h"/>
</time>
3.1.4.4 Component Semantic Specification
Another important session parameter is to specify - ideally in a
machine-readable way but at least understandable for humans - the
function of the various components in a session. Typically, the
semantics of the streams are implicitly assumed (e.g. a video stream
goes together with the only audio stream in a session). There are,
however, scenarios in which such intuitive understanding is not
sufficient and the semantics must be made explicit.
<info name="audio-interactive" function="speaker">
Audio stream for the different speakers
</info>
The above example shows a simple definition of the semantics for a
the component "interactive-audio". Further options may be added to
provide additional information, e.g. language, and other functions
may be specified (e.g. "panel", "audience", "chair", etc.).
3.2 Syntax Definition Mechanisms
In order to allow for the possibility to validate session In order to allow for the possibility to validate session
descriptions and in order to allow for structured extensibility it descriptions and in order to allow for structured extensibility it
is proposed to rely on a syntax framework that provides concepts as is proposed to rely on a syntax framework that provides concepts as
well as concrete procedures for document validation and extending well as concrete procedures for document validation and extending
the set of allows syntax elements. the set of allowed syntax elements.
SGML/XML technologies allow for the preparation of Document Type SGML/XML technologies allow for the preparation of Document Type
Definitions (DTDs) that can define the allowed content models for Definitions (DTDs) that can define the allowed content models for
the elements of conforming documents. Documents can be formally the elements of conforming documents. Documents can be formally
validated against a given DTD to check their conformance and validated against a given DTD to check their conformance and
correctness. For XML, mechanisms have been defined that allow for correctness. XML DTDs however, cannot easily be extended. It is not
structured extensibility of a model of allowed syntax: XML Namespace possible to alter to content models of element types or to add new
and XML Schema. element types after the DTD has been specified.
For SDPng a mechanism is needed that allows the specification of a
base syntax -- for example basic elements for the high level
structure of description documents -- while allowing extensions, for
example elements and attributes for new transport mechanisms, new
media types etc. to added on demand. Still, it has to be ensured
that extensions do not result in name collisions. Furthermore, it
must be possible for applications that process descriptios documents
to disinguish extensions from base definitions.
For XML, mechanisms have been defined that allow for structured
extensibility of a model of allowed syntax: XML Namespace and XML
Schema.
XML Schema mechanisms allows to constrain the allowed document XML Schema mechanisms allows to constrain the allowed document
content, e.g. for documents that contain structured data and also content, e.g. for documents that contain structured data and also
provide the possibility that document instances can conform to provide the possibility that document instances can conform to
several XML Schema definitions at the same time, while allowing several XML Schema definitions at the same time, while allowing
Schema validators to check the conformance of these documents. Schema validators to check the conformance of these documents.
Extensions of the session description language, say for allowing to Extensions of the session description language, say for allowing to
express the parameters of a new media type, would require the express the parameters of a new media type, would require the
creation of a corresponding XML schema definition that contains the creation of a corresponding XML schema definition that contains the
skipping to change at page 13, line 38 skipping to change at page 18, line 17
XML Schema is thus rather motivated by the need to allow for XML Schema is thus rather motivated by the need to allow for
extensions being defined and added to the language in a structured extensions being defined and added to the language in a structured
way that does not preclude the possibility to have applications to way that does not preclude the possibility to have applications to
identify and process the extensions elements they might support. The identify and process the extensions elements they might support. The
baseline specification of XML Schema definitions and profiles must baseline specification of XML Schema definitions and profiles must
be well-defined and targeted to the set of parameters that are be well-defined and targeted to the set of parameters that are
relevant for the protocols and algorithms of the Internet Multimedia relevant for the protocols and algorithms of the Internet Multimedia
Conferencing Architecture, i.e. transport over RTP/UDP/IP, the audio Conferencing Architecture, i.e. transport over RTP/UDP/IP, the audio
video profile of RFC1890 etc. video profile of RFC1890 etc.
Section 3.3 describes profile definitions and library definition. A
detailed definition of how the formal SDPng syntax and the
corresponding extension mechanisms is to be provided in future
versions of this document.
The example below shows how the definition of codecs, The example below shows how the definition of codecs,
transport-variants and configuration of components could be transport-variants and configuration of components could be
realized. Please note that this is not a complete example and that realized. Please note that this is not a complete example and that
identifiers have been chosen arbitrarily. identifiers have been chosen arbitrarily.
<def> <def>
<audio-codec name="audio-basic" encoding="PCMU sampling_rate="8000 channels="1"/> <audio-codec name="audio-basic" encoding="PCMU"
sampling="8000 channels="1"/>
<audio-codec name="audio-L16-mono" encoding="L16 sampling_rate="44100 channels="1"/> <audio-codec name="audio-L16-mono" encoding="L16"
sampling="44100 channels="1"/>
<fec name="parityfec"/> <rtp-pt name="rtp-avp-0" pt="0" format="audio-basic"/>
<rtp-pt name="rtp-avp-11" pt="11" format="audio-L16-mono"/>
<audio-red name="red-pcm-gsm-fec">
<use ref="audio-basic"/> <use ref="audio-gsm"/> <use ref="parityfec"/>
</audio-red>
</def> </def>
<cfg> <cfg>
<component name="audio1" media="audio"> <component name="interactive-audio" media="audio">
<alt name= AVP-audio-0"> <alt name= AVP-audio-0">
<rtp transport="udp-ip" format="audio-basic"> <rtp format="rtp-avp-0">
<addr type="mc"> <udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
<ipv4>239.239.239.239</ipv4> <port>30000</port>
</addr>
</rtp> </rtp>
</alt> </alt>
<alt name="AVP-audio-11"> <alt name= AVP-audio-11">
<rtp transport="udp-ip" format="audio-L16-mono"> <rtp format="rtp-avp-11">
<addr type="mc"> <udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
<ipv4>239.239.239.239</ipv4> <port>30000</port>
</addr>
</rtp> </rtp>
</alt> </alt>
</component> </component>
</cfg> </cfg>
<constraints> <constraints>
<par> <par>
<use ref="AVP-audio-11" max="5"> <use ref="AVP-video-32" max="1"> <use-alt ref="AVP-audio-11" max="1">
</par> </par>
</constraints> </constraints>
<conf> <conf>
<subject>SDPng test</subject> <owner user="joe@example.com" id="foobar" version="1" nettype="IN"
<originator>joe@example.com</originator> addrtype="IP4" addr="130.149.25.97"/>
<about>A test conference</about> <session name="An SDPng seminar" info="http://www.dmn.tzi.org/ietf/mmusic/">
<info name="audio1" function="speaker"> This seminar is about SDPng...
Video stream for the different speakers <info>http://www.ietf.org/</info>
<contact>mailto:joe@example.comg</contact>
<contact>sip:joe@example.com</contact>
</session>
<time start="3034423619" stop="3042462419">
<repeat interval="7d" duration="1h"/>
<repeat interval="7d" duration="1h" offset="25h"/>
</time>
<info name="interactive-audio" function="speaker">
Audio stream for the different speakers
<info> <info>
</conf> </conf>
The example does also not include specifications of XML Schema The example does also not include specifications of XML Schema
definitions or references to such definitions. This will be provided definitions or references to such definitions. This will be provided
in a future version of this draft. in a future version of this draft.
A real-world capability description would likely be shorter than the A real-world capability description would likely be shorter than the
presented example because the codec and transport definitions can be presented example because the codec and transport definitions can be
factored-out to profile definition documents that would only be factored-out to profile definition documents that would only be
referenced in capability description documents. referenced in capability description documents.
skipping to change at page 15, line 27 skipping to change at page 20, line 18
A profile contains rules that specify how SDPng is used to describe A profile contains rules that specify how SDPng is used to describe
conferences or endsystem capabilities with respect to the parameters conferences or endsystem capabilities with respect to the parameters
of the profile. The concrete properties of the profile definitions of the profile. The concrete properties of the profile definitions
mechanism are still to be defined. mechanism are still to be defined.
An example of such a profile would be the RTP profile that defines An example of such a profile would be the RTP profile that defines
how to specify RTP parameters. Another example would be the audio how to specify RTP parameters. Another example would be the audio
codec profiles that defines how specify audio codec parameters. codec profiles that defines how specify audio codec parameters.
SDPng document can reference profiles and provide concrete SDPng documents can reference profiles and provide concrete
definitions, for example the definition for the GSM audio codec. definitions, for example the definition for the GSM audio codec.
(This would be done in the "Definitions" section of a SDPng (This would be done in the "Definitions" section of a SDPng
document.) A SDPng document that references a profile and provides document.) A SDPng document that references a profile and provides
concrete defintions of configurations can be validated against the concrete defintions of configurations can be validated against the
profile definition. profile definition.
3.3.2 Library Definitions 3.3.2 Library Definitions
While profile definitions specify the allowed parameters for a given While profile definitions specify the allowed parameters for a given
profile SDPng definition sections refer to profile definitions and profile SDPng definition sections refer to profile definitions and
define concrete configurations based on a specific profile. define concrete configurations based on a specific profile.
In order to such definitions to be imported into SDPng documents, In order for such definitions to be imported into SDPng documents,
there will be the notion of "SDPng libraries". A library is a set of there will be the notion of "SDPng libraries". A library is a set of
definitions that is conforming to a certain profile definition (or definitions that is conforming to a certain profile definition (or
to more than one profile definition -- this needs to be defined). to more than one profile definition -- this needs to be defined).
The purpose of the library concept is to allow certain common The purpose of the library concept is to allow certain common
definitions to be factored-out so that not every SDPng document has definitions to be factored-out so that not every SDPng document has
to include the basic definitions, for example the PCMU codec to include the basic definitions, for example the PCMU codec
definition. SDP [1] uses a similar concept by relying on the well definition. SDP [2] uses a similar concept by relying on the well
known static payload types (defined in RFC1890 [3]) that are also known static payload types (defined in RFC1890 [4]) that are also
just referenced but never defined in SDP documents. just referenced but never defined in SDP documents.
An SPDng document that references definitions from an external An SPDng document that references definitions from an external
library has to declare the use of the external library. The external library has to declare the use of the external library. The external
library, being a set of configuration definitions for a given library, being a set of configuration definitions for a given
profile, again needs to declare the use of the profile that it is profile, again needs to declare the use of the profile that it is
conformant to. conformant to.
There are different possibilities of how profiles definitions and There are different possibilities of how profiles definitions and
libraries can be used in SDPng documents: libraries can be used in SDPng documents:
skipping to change at page 16, line 31 skipping to change at page 21, line 23
by name: Referencing libraries by names implies the use of a by name: Referencing libraries by names implies the use of a
registration authority where definitions and reference names registration authority where definitions and reference names
can be registered with. It is conceivable that the most common can be registered with. It is conceivable that the most common
SDPng definitions be registered that way and that there will SDPng definitions be registered that way and that there will
be a baseline set of definitions that minimal implementations be a baseline set of definitions that minimal implementations
must understand. Secondly, a registration procedure will be must understand. Secondly, a registration procedure will be
defined, that allows vendors to register frequently used defined, that allows vendors to register frequently used
definitions with a registration authority (e.g., IANA) and to definitions with a registration authority (e.g., IANA) and to
declare the use of registered definition packages in declare the use of registered definition packages in
conforming SDPng documents. Of course, care should be taken conforming SDPng documents. Of course, care should be taken
though not to make the external references too complex and not to make the external references too complex and thus
thus require too much a priori knowledge in a protocol engine require too much a priori knowledge in a protocol engine
implementing SDPng. Relying on this mechanism in general is implementing SDPng. Relying on this mechanism in general is
also problematic because it impedes the extensiblity, because also problematic because it impedes the extensiblity, because
it requires implementors to provide support for new extensions it requires implementors to provide support for new extensions
in their products before they can interoperate. Registration in their products before they can interoperate. Registration
is not useful for spontaneous or experimental extensions that is not useful for spontaneous or experimental extensions that
are defined in an SDPng library. are defined in an SDPng library.
by address: An alternative to referencing libraries by name is to by address: An alternative to referencing libraries by name is to
declare the use of an external library by providing an declare the use of an external library by providing an
address, i.e., an URL, that specifies where the library can be address, i.e., an URL, that specifies where the library can be
skipping to change at page 18, line 5 skipping to change at page 23, line 5
3.4 Mappings 3.4 Mappings
A mapping needs to be defined in particular to SDP that allows to A mapping needs to be defined in particular to SDP that allows to
translate final session descriptions (i.e. the result of capability translate final session descriptions (i.e. the result of capability
negotiation processes) to SDP documents. In principle, this can be negotiation processes) to SDP documents. In principle, this can be
done in a rather schematic fashion. done in a rather schematic fashion.
Furthermore, to accommodate SIP-H.323 gateways, a mapping from SDPng Furthermore, to accommodate SIP-H.323 gateways, a mapping from SDPng
to H.245 needs to be specified at some point. to H.245 needs to be specified at some point.
4. Open Issues 4. Formal Specification
Overriding To be provided.
Sytnax for referencing profiles and libraries 5. Use of SDPng in conjunction with other IETF Signaling Protocols
Registry (reuse of SDP mechanisms and names etc.) SDPng defines the notion of Components to indicate the intended
types of collaboration between the users in e.g. a teleconferencing
scenario.
Negotiation For the means conceivable to realize a particular Component, SDPng
conceptually distinguishes three levels of support:
a Capapility refers to the fact that one of the involved parties
supports one particular way of exchanging media -- defined in
terms of transport, codec, and other parameters -- as part of the
teleconference.
a Potential Configuration denotes a set of matching Capabilities
from all those involved parties required to successfully realize
one particular Component.
an Actual Configuration indicates the Potential Configuration
which was chosen by the involved parties to realize a certain
Component at one particular point in time.
As mentioned before, this abstract notion of the interactions
between a number of communicating systems needs to be mapped to the
application scenarios of SDPng in conjunction with the various IETF
signaling protocols: SAP, SIP, RTSP, and MEGACO.
5.1 The Session Announcement Protocol (SAP)
SAP is used to disseminate a previously created (and typically
fixed) session description to a potentially large audience. An
interested member of the audience will use the SDPng description
contained in SAP to join the announced media sessions.
This means that a SAP announcements contains the Actual
Configurations of all Components that are part of the overall
teleconference or broadcast.
A SAP announcement may contain multiple Actual Configurations for
the same Component. In this case, the "same" (i.e. semantically
equivalent) media data from one configuration must be available from
each of the Actual Configurations. In practice, this limits the use
of multiple Actual Configurations to single-source multicast or
broadcast scenarios.
Each receiver of a SAP announcement with SDPng compares its locally
stored Capabiities to realize a certain Component against the Actual
Configurations contained in the announcement. If the intersection
yields one or more Potential Configurations for the receiver, it
chooses the one it sees fit best. If the intersection is empty, the
receiver cannot participate in the announced session.
SAP may be substituted by HTTP (in the general case, at least),
SMTP, NNTP, or other IETF protocols suitable for conveying a media
description from one entity to one or more other without the intend
for further negotiation of the session parameters.
Example from the SAP spec. to be provided.
5.2 Session Initiation Protocol (SIP)
SIP is used to establish and modify multimedia sessions, and SDPng
may be carried at least in SIP INVITE and ACK messages as well as in
a number of responses. From dealing with legacy SDP (and its
essential non-suitability for capability negotiation), a particular
use and interpretation of SDP has been defined for SIP.
One of the important flexibilities introduced by SIP's usage of SDP
is that a sender can change dynamically between all codecs that a
receiver has indicated support (and has provided an address) for.
Codec changes are not signaled out-of-band but only indicated by the
payload type within the media stream. From this arises one important
consequence to the conceptual view of a Component within SDPng.
There is no clear distinction between Potential and Actual
Configurations. There need not be a single Actual Configuration be
chosen at setup time within the SIP signaling. Instead, a number of
Potential Configurations is signaled in SIP (with all transport
parameters required for carrying media streams) and the Actual
Configuration is only identified by the paylaod type which is
actually being transmitted at any point in time.
Note that since SDPng does not explicitly distinguish between
Potential and Actual Configurations, this has no implications on the
SDPng signaling itself.
SIP Examples to be defined.
5.3 Real-Time Streaming Protocol (RTSP)
In contrast to SIP, RTSP has, from its intended usage, a clear
distinction between offering Potential Configurations (typically by
the server) and choosing one out of these (by the client), and, in
some cases; some parameters (such as multicast addresses) may be
dictated by the server. Hence with RTSP, there is a clear
distinguish between Potential Configurations during the negotiation
phase and a finally chosen Actual Configuration according to which
streaming will take place.
Example from the RTSP spec to be provided.
5.4 Media Gateway Control Protocol (MEGACOP)
The MEGACO architecture also follows the SDPng model of a clear
separation between Potential and Actual Configurations. Upon
startup, a Media Gateway (MG) will "register" with its Media Gateway
Controller (MGC) and the latter will audit the MG for its
Capabilities. Those will be provided as Potential Configurations,
possibly with extensive Constraints specifications. Whenever a media
path needs to be set up by the MGC between two MGs or an MG needs to
be reconfigured internally, the MGC will use (updated) Actual
Configurations.
Details and examples to be defined.
6. Open Issues
The precise sytnax for referencing profiles and libraries needs
to be worked out.
A registry (reuse of SDP mechanisms and names etc.) needs to be
set up.
Transport and Payload type specifications need to be defined as
additional appendices.
Negotiation mechanisms for multiparty conferencing need to be
formalized.
Further details on the signaling protocols need to be filled in.
Mapping to other media description formats (SDP, H.245, ...)
should be provided. For H.245, this is probably a different
document (beloning to the SIP-H.323 interworking group).
References References
[1] Handley, M. and V. Jacobsen, "SDP: Session Description [1] Kutscher, D., Ott, J., Bormann, C. and I. Curcio, "Requirements
for Session Description and Capability Negotiation", Internet
Draft draft-ietf-mmusic-sdpng-req-01.txt, April 2001.
[2] Handley, M. and V. Jacobsen, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996. 1889, January 1996.
[3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences [4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996. with Minimal Control", RFC 1890, January 1996.
[4] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, [5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", Internet-Draft
draft-ietf-avt-profile-new-10.txt , March 2001.
[6] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP
Payload for Redundant Audio Data", RFC 2198, September 1997. Payload for Redundant Audio Data", RFC 2198, September 1997.
[5] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC [7] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
2533, March 1999. 2533, March 1999.
[6] Klyne, G., "Protocol-independent Content Negotiation [8] Klyne, G., "Protocol-independent Content Negotiation
Framework", RFC 2703, September 1999. Framework", RFC 2703, September 1999.
[7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for [9] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999. Generic Forward Error Correction", RFC 2733, December 1999.
[8] Perkins, C. and O. Hodson, "Options for Repair of Streaming [10] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998. Media", RFC 2354, June 1998.
[9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement [11] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
Authors' Addresses Authors' Addresses
Dirk Kutscher Dirk Kutscher
TZI, Universitaet Bremen TZI, Universitaet Bremen
Bibliothekstr. 1 Bibliothekstr. 1
Bremen 28359 Bremen 28359
Germany Germany
Phone: +49.421.218-7595 Phone: +49.421.218-7595, sip:dku@tzi.org
Fax: +49.421.218-7000 Fax: +49.421.218-7000
EMail: dku@tzi.uni-bremen.de EMail: dku@tzi.uni-bremen.de
Joerg Ott Joerg Ott
TZI, Universitaet Bremen TZI, Universitaet Bremen
Bibliothekstr. 1 Bibliothekstr. 1
Bremen 28359 Bremen 28359
Germany Germany
Phone: +49.421.201-7028 Phone: +49.421.201-7028, sip:jo@tzi.org
Fax: +49.421.218-7000 Fax: +49.421.218-7000
EMail: jo@tzi.uni-bremen.de EMail: jo@tzi.uni-bremen.de
Carsten Bormann Carsten Bormann
TZI, Universitaet Bremen TZI, Universitaet Bremen
Bibliothekstr. 1 Bibliothekstr. 1
Bremen 28359 Bremen 28359
Germany Germany
Phone: +49.421.218-7024 Phone: +49.421.218-7024, sip:cabo@tzi.org
Fax: +49.421.218-7000 Fax: +49.421.218-7000
EMail: cabo@tzi.org EMail: cabo@tzi.org
Appendix A. Base SDPng Specifications for Audio Codec Descriptions
[5] specifies a number of audio codecs including short name to be
used as reference by session description protocols such as SDP and
SDPng. Those codec names, as listed in the first column of the above
table, are used to identify codecs in SDPng.
The following sections indicate the default values that are assumed
if nothing else than the codec reference is specified.
The following audio-codec attributes are defined for audio codecs:
name: the identifier to be later used for referencing the codec spec
encoding: the RTP/AVP profile identifier as registered with IANA
mime: the MIME type; may alternatively be specified instead of
"encoding"
channels: the number of independent media channels
pattern: the media channel pattern for mapping channels to payload
sampling: the sample rate for the codec (which in most cases equals
the RTP clock)
Furthermode, options may be defined of the following format:
<option id="name">value</option>
if a value is associated with the option (note that arbitrary
complex values are allowed), or alternatively:
<option id="name"/>
if the option is just a boolean indicator.
Attributes for the "option" tag are the following:
id: the identifier for the option (variable name)
collaps: the collapsing rules for this optional element, defined as
follows:
min: for numeric values only
max: for numeric values only
x: intersection of enumerated values, value lists
A.1 DVI4
<audio-codec name="dvi4" encoding="DVI4" channels="1" sampling="8000">
<rtp-pt name="rtp-avp-5" pt="5" format="dvi4"/>
<rtp-pt name="rtp-avp-6" pt="6">
<audio-codec encoding="DVI4" channels="1" sampling="16000">
</rtp-pt>
Note that there is no default sampling rate specified for DVI4 and
hence a sampling rate MUST be specified.
A.2 G.722
<audio-codec name="g722" encoding="G722" channels="1" sampling="16000"/>
<rtp-pt name="rtp-avp-9" pt="9" format="g722"/>
Note as per [5] that the RTP clock rate is 8000Hz rather than 16000
Hz.
A.3 G.726
<audio-codec name="g726-40" encoding="G726-40" channels="1" sampling="8000"/>
<audio-codec name="g726-32" encoding="G726-32" channels="1" sampling="8000"/>
<audio-codec name="g726-24" encoding="G726-24" channels="1" sampling="8000"/>
<audio-codec name="g726-16" encoding="G726-16" channels="1" sampling="8000"/>
<rtp-pt name="rtp-avp-5" pt="5" format="g726-32"/>
A.4 G.728
<audio-codec name="g728" encoding="G728" channels="1" sampling="8000"/>
<rtp-pt name="rtp-avp-15" pt="15" format="g728"/>
A.5 G.729
G.729 Annex A: reduced complexity of G.729
G.729 Annex B: comfort noise
<audio-codec name="g729" encoding="G729" channels="1" sampling="8000"/>
<rtp-pt name="rtp-avp-18" pt="18" format="g729"/>
For further codec description, the following options (which carry no
values associated with them) MAY be included:
<option id="annexA"/>
<!-- to indicate the use of Annex A reduced complexity -->
<option id="annexB"/>
<!-- to indicate the use of Annex B comfort noise -->
As stated in [5], the use of these options can be detected within
the media stream.
A.6 G.729 Annex D and E
<audio-codec name="g729d" encoding="G729D" channels="1" sampling="8000"/>
<audio-codec name="g729e" encoding="G729E" channels="1" sampling="8000"/>
The following option MAY be used with both Annexes D and E:
<option id="annexB"/>
<!-- to indicate the use of Annex B comfort noise -->
A.7 GSM
A.7.1 GSM Full Rate
The GSM Full Rate codec is indicated as follows:
<audio-codec name="gsm" encoding="GSM" channels="1" sampling="8000"/>
<rtp-pt name="rtp-avp-3" pt="3" format="gsm"/>
A.7.2 GSM Half Rate
The GSM Half Rate codec is indicated as follows:
<audio-codec name="gsm-hr" encoding="GSM-HR" channels="1" sampling="8000"/>
A.7.3 GSM Enhanced Full Rate
The GSM Enhanced Full Rate codec is indicated as follows:
<audio-codec name="gsm-efr" encoding="GSM-EFR" channels="1" sampling="8000"/>
A.8 L8
<audio-codec name="l8" encoding="L8" channels="1" sampling="8000"/>
A.9 L16
<audio-codec name="l16" encoding="L16" channels="1" sampling="8000"/>
<rtp-pt name="rtp-avp-11" pt="11" format="gsm"/>
<rtp-pt name="rtp-avp-10" pt="11" format="gsm">
<audio-codec encoding="L16" channels="2" sampling="8000"/>
</rtp-pt>
A.10 LPC
<audio-codec name="lpc" encoding="LPC" channels="1" sampling="8000"/>
A.11 MPA
<audio-codec name="mpa" encoding="MPA" channels="1" sampling="8000"/>
<rtp-pt name="rtp-avp-14" pt="14" format="mpa"/>
A.12 PCMA and PCMU
<audio-codec name="pcmu" encoding="PCMU" channels="1" sampling="8000"/>
<audio-codec name="pcma" encoding="PCMA" channels="1" sampling="8000"/>
<rtp-pt name="rtp-avp-0" pt="0" format="pcmu"/>
<rtp-pt name="rtp-avp-8" pt="8" format="pcma"/>
A.13 QCELP
<audio-codec name="qcelp" encoding="QCELP" channels="1" sampling="8000"/>
<rtp-pt name="rtp-avp-12" pt="12" format="qcelp"/>
A.14 VDVI
<audio-codec name="vdvi" encoding="VDVI" channels="1" sampling="8000"/>
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/