draft-ietf-mmusic-sdpng-req-00.txt   draft-ietf-mmusic-sdpng-req-01.txt 
Network Working Group Kutscher Network Working Group Kutscher
Internet-Draft Ott Internet-Draft Ott
Expires: August 20, 2001 Bormann Expires: October 16, 2001 Bormann
TZI, Universitaet Bremen TZI, Universitaet Bremen
February 19, 2001 Curcio
Nokia Mobile Phones
April 17, 2001
Requirements for Session Description and Capability Negotiation Requirements for Session Description and Capability Negotiation
draft-ietf-mmusic-sdpng-req-00.txt draft-ietf-mmusic-sdpng-req-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."
To view the entire list of Internet-Draft Shadow Directories, see To view the entire list of Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 20, 2001. This Internet-Draft will expire on October 16, 2001.
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 some terminology and lists a set of This document defines some terminology and lists a set of
requirements that are relevant for a framework for session requirements that are relevant for a framework for session
description and endpoint capability negotiation in multiparty description and endpoint capability negotiation in multiparty
multimedia conferencing scenarios. multimedia conferencing scenarios.
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 Force. Comments are solicited and should be addressed to the working
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
$Revision: 2.1 $
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . 6
4. General Requirements . . . . . . . . . . . . . . . . . . . . 9 4. General Requirements . . . . . . . . . . . . . . . . . . 9
4.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . 9
4.3 Firewall Friendliness . . . . . . . . . . . . . . . . . . . 9 4.3 Firewall Friendliness . . . . . . . . . . . . . . . . . 9
4.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4 Authentication, Authorization, Media Keys . . . . . . . 9
4.5 Text encoding . . . . . . . . . . . . . . . . . . . . . . . 9 4.5 Text encoding . . . . . . . . . . . . . . . . . . . . . 10
4.6 Session vs. Media Description . . . . . . . . . . . . . . . 10 4.6 Session vs. Media Description . . . . . . . . . . . . . 10
4.7 Mapping (of a Subset) to SDP . . . . . . . . . . . . . . . . 10 4.7 Mapping (of a Subset) to SDP . . . . . . . . . . . . . . 10
5. Session Description Requirements . . . . . . . . . . . . . . 11 5. Session Description Requirements . . . . . . . . . . . . 11
5.1 Media Description . . . . . . . . . . . . . . . . . . . . . 11 5.1 Media Description . . . . . . . . . . . . . . . . . . . 11
5.1.1 Medium Type . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1 Medium Type . . . . . . . . . . . . . . . . . . . . . . 11
5.1.2 Media Stream Packetization . . . . . . . . . . . . . . . . . 11 5.1.2 Media Stream Packetization . . . . . . . . . . . . . . . 11
5.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.4 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.4 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.5 Resource Utilization . . . . . . . . . . . . . . . . . . . . 12 5.1.5 Resource Utilization . . . . . . . . . . . . . . . . . . 12
5.1.6 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.6 Dependencies . . . . . . . . . . . . . . . . . . . . . . 13
5.1.7 Other parameters (media-specific) . . . . . . . . . . . . . 13 5.1.7 Other parameters (media-specific) . . . . . . . . . . . 13
5.1.8 Naming Hierarchy and/or Scoping . . . . . . . . . . . . . . 13 5.1.7.1 Media Codec Bit Rates . . . . . . . . . . . . . . . . . 13
5.1.9 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.7.2 Advanced codec modes . . . . . . . . . . . . . . . . . . 13
6. Requirements for Capability Description and Negotiation . . 14 5.1.8 Naming Hierarchy and/or Scoping . . . . . . . . . . . . 13
6.1 Capability Constraints . . . . . . . . . . . . . . . . . . . 14 5.1.9 Profiles . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2 Processing Rules . . . . . . . . . . . . . . . . . . . . . . 15 5.1.10 Registrations of Names . . . . . . . . . . . . . . . . . 14
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.11 Meta-Information . . . . . . . . . . . . . . . . . . . . 14
8. Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.11.1 Scheduling . . . . . . . . . . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.11.2 Optional Meta-Information Packages . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 6. Requirements for Capability Description and Negotiation 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 6.1 Capability Description . . . . . . . . . . . . . . . . . 16
6.2 Capability Constraints . . . . . . . . . . . . . . . . . 16
6.3 Processing Rules . . . . . . . . . . . . . . . . . . . . 17
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . 19
8. Remarks . . . . . . . . . . . . . . . . . . . . . . . . 20
References . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Multiparty multimedia conferencing is one application that requires Multiparty multimedia conferencing is one application that requires
the dynamic interchange of end system capabilities and the the 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, it may be sufficient to
have session parameters be fixed by the initiator of a conference. simply have session parameters be fixed by the initiator of a
In such a scenario no negotiation is required because only those conference. In such a scenario no negotiation is required because
participants with media tools that support the predefined settings only those participants with media tools that support the predefined
can join a media session and/or a conference. 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 40 skipping to change at page 3, line 40
conference's parameter set must therefore be performed either at conference's parameter set must therefore be performed either at
conference start (for closed conferences) or maybe (potentially) conference start (for closed conferences) or maybe (potentially)
even repeatedly every time a new participant joins an active even repeatedly every time a new participant joins an active
conference. The latter approach may not be appropriate for every conference. The latter approach may not be appropriate for every
type of conference without applying certain policies: For type of conference without applying certain policies: For
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 "rights" for participants that are open for new participants on the
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 [1] 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:
skipping to change at page 5, line 7 skipping to change at page 5, line 7
In the following we first introduce a model for session description In the following we first introduce a model for session description
and capability negotiation and define some terms that are later used and capability negotiation and define some terms that are later used
to express some requirements. Note that this list of requirements is to express some requirements. Note that this list of requirements is
possibly incomplete. The purpose of this document is to initiate the possibly incomplete. The purpose of this document is to initiate the
development of a session description and capability negotiation development of a session description and capability negotiation
framework. framework.
2. Use Cases 2. Use Cases
TBD: use cases This is an initial list of use cases:
And endpoint is a device attached to an IP network via a fixed or
wireless connection (LAN, WLAN, GPRS, IMT-2000, etc.).
Case 1: Point-to-point connection
Case 2: Point-to-point connection with use of proxy/CPS
Case 3: 1-to-n connection (multicast distribution such as a lecture
or video streaming or music)
Case 4: n-party connection (such as a speech and/or video and/or
data call with a variable number of participants over time)
3. Terminology 3. Terminology
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 replayed, etc. with this particular device. We term features enabled
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
screen resolution for true color by the graphics board; available screen resolution for true color by the graphics board; available
audio hardware or software may offer only certain media encodings audio hardware or software may offer only certain media encodings
(e.g. G.711 and G.723.1 but not GSM); and CPU processing power (e.g. G.711 and G.723.1 but not GSM); and CPU processing power
and quality of implementation may constrain the possible video and quality of implementation may constrain the possible video
encoding algorithms. encoding algorithms.
In multiparty multimedia conferences, participants employ different In multiparty multimedia conferences, participants employ different
"components" in conducting the conference. "components" in conducting the conference.
skipping to change at page 7, line 33 skipping to change at page 7, line 33
(a set of any number of configurations per component) indicating (a set of any number of configurations per component) indicating
a system's functional capabilities as constrained by the intended a system's functional capabilities as constrained by the intended
use of the various components; use of the various components;
o actual configurations o actual configurations
(exactly one per instance of a component) reflecting the mode of (exactly one per instance of a component) reflecting the mode of
operation of this component's particular instantiation. operation of this component's particular instantiation.
Example: The potential configuration of the aforementioned video Example: The potential configuration of the aforementioned video
component may indicate support for JPEG, H.261/CIF, and component may indicate support for JPEG, H.261/CIF, and
H.261/QCIF. A particular instantiation for a video conference H.261/QCIF. A particular instantiation for a video conference may
may use the actual configuration of H.261/CIF for exchanging use the actual configuration of H.261/CIF for exchanging video
video streams. streams.
In summary, the key terms of this model are: In summary, the key terms of this model are:
o A multimedia session (streaming or conference) consists of one or o A multimedia session (streaming or conference) consists of one or
more conference components for multimedia "interaction". more conference components for multimedia "interaction".
o A component describes a particular type of interaction (e.g. o A component describes a particular type of interaction (e.g.
audio conversation, slide presentation) that can be realized by audio conversation, slide presentation) that can be realized by
means of different applications (possibly using different means of different applications (possibly using different
protocols). protocols).
skipping to change at page 8, line 24 skipping to change at page 8, 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 [11] -based session announcements on the Mbone, for which SDP In SAP [11] based 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.
skipping to change at page 9, line 26 skipping to change at page 9, line 26
SDPng shall be extensible in a backward compatible fashion. SDPng shall be extensible in a backward compatible fashion.
Extensions should be doable without modifying the SDPng Extensions should be doable without modifying the SDPng
specification itself. The spec should preclude two independent specification itself. The spec should preclude two independent
extensions from clashing with each other (e.g. in the naming of extensions from clashing with each other (e.g. in the naming of
attributes). attributes).
Along with extensibility comes the requirement to identify certain Along with extensibility comes the requirement to identify certain
extensions as mandatory in a given context while others as optional. extensions as mandatory in a given context while others as optional.
It should be possible to define subsets or profiles of the SDPng so
that simple implementations understands only minimal parts of SDPng,
and are able to interwork with more refined and complex SDPng
implementations.
4.3 Firewall Friendliness 4.3 Firewall Friendliness
It should be theoretically possible for firewalls (and other network It should be theoretically possible for firewalls (and other network
infrastructure elements) to process announcements etc. that contain infrastructure elements) to process announcements etc. that contain
SDPng content. The concrete procedures have to be defined but if SDPng content. The concrete procedures have to be defined but if
possible the processing of the SDPng content should be doable possible the processing of the SDPng content should be doable
without interpretation of the textual descriptions. without interpretation of the textual descriptions.
4.4 Security In general, there should not be any problem for a gateway or a proxy
server to execute the capability computation, and this operation has
not to be limited to the endpoints only.
4.4 Authentication, Authorization, Media Keys
SDPng should allow independent security attributes for parts of a SDPng should allow independent security attributes for parts of a
session description. In particular, signing and/or encrypting parts session description. In particular, signing and/or encrypting parts
of a session description should be supported. of a session description should be supported.
The originator of the session may authenticate the session
description or parts of it, or encrypt it so that only authorized
users may access it.
In addition to the media encryption keys, the session description
should include also authentication keys, or include ways for
authorized session participants to derive these keys.
In order to support rapid re-keying, the session description should
include way to specify multiple encryption contexts and indicate how
and when these encryption contexts will be used. For instance, the
session description would indicate the current key and destination
group, and then that the key will be changed at 20010401Z084000, and
the media encoded with the new key will be sent to group
243.243.12.8.
4.5 Text encoding 4.5 Text encoding
A concise text representation is desirable in order to enhance A concise text representation is desirable in order to enhance
portability and allow for simple implementations. At run time, size portability and allow for simple implementations. At run time, size
of encoded packets should be minimized, processing as well. of encoded packets should be minimized, processing as well.
A language that allows specifications to be formally validated is A language that allows specifications to be formally validated is
desirable. desirable.
A tendency to use XML as basis for the specification language has
been expressed repeatedly.
4.6 Session vs. Media Description 4.6 Session vs. Media Description
In many application scenarios (particularly with SIP and In many application scenarios (particularly with SIP and
MEGACO/H.248), only media descriptions are needed and there is no MEGACO/H.248), only media descriptions are needed and there is no
need for session description parameters. SDPng should make need for session description parameters. SDPng should make parameter
parameter sets optional where it is conceivable that not all sets optional where it is conceivable that not all application will
application will need them. need them.
4.7 Mapping (of a Subset) to SDP 4.7 Mapping (of a Subset) to SDP
It shall be possible to translate a subset of SDPng into standard It shall be possible to translate a subset of SDPng into standard
SDP session description to enable a certain minimal degree of SDP session description to enable a certain minimal degree of
interoperability between SDP-based and SDPng-based systems. interoperability between SDP-based and SDPng-based systems. However,
However, as SDPng will provide enhanced functionality compared to as SDPng will provide enhanced functionality compared to SDP, a full
SDP, a full mapping to SDP is not possible. mapping to SDP is not possible.
Note: Backwards compatibility to the SDP syntax has been discussed Note: Backwards compatibility to the SDP syntax has been discussed
and it was found that this is not goal for SDPng, as it is felt that and it was found that this is not goal for SDPng, as it is felt that
RFC 2327 is too limiting. RFC 2327 is too limiting.
Since several flavors of SDP have been developed (e.g., the MEGACO Since several flavors of SDP have been developed (e.g., the MEGACO
WG uses certain non-SDP enhancements) it needs to be discussed which WG uses certain non-SDP enhancements) it needs to be discussed which
of these flavors need to be considered for some kind of mapping. of these flavors need to be considered for some kind of mapping.
5. Session Description Requirements 5. Session Description Requirements
skipping to change at page 12, line 6 skipping to change at page 12, line 6
Finally, a separation of the media encoding scheme, the Finally, a separation of the media encoding scheme, the
packetization format, and possible repair schemes (and their packetization format, and possible repair schemes (and their
respective parameters) is required. respective parameters) is required.
5.1.3 Transport 5.1.3 Transport
Since session descriptions are not only used to describe sessions Since session descriptions are not only used to describe sessions
that use IPv4/RTP for media transport it must be possible to specify that use IPv4/RTP for media transport it must be possible to specify
different transport protocols (and their corresponding mandatory different transport protocols (and their corresponding mandatory
parameters). This means SDPng must support different address parameters). This means SDPng must support different address formats
formats (IPv4, IPv6, E.164, NSAP, ...), multiplexing schemes (e.g. (IPv4, IPv6, E.164, NSAP, ...), multiplexing schemes (e.g. to
to identify a channel on a TDM link), and different transport identify a channel on a TDM link), and different transport protocol
protocol stacks (RTP/UDP/IP, RTP/AAL5/ATM, ...). Potential further stacks (RTP/UDP/IP, RTP/AAL5/ATM, ...). Potential further parameters
parameters and interdependencies for multiplexed transports should and interdependencies for multiplexed transports should be
be considered. considered.
Additionally the requirement for expressing multiple addresses per Additionally the requirement for expressing multiple addresses per
actual configuration (layered coding support) has emerged, as well actual configuration (layered coding support) has emerged, as well
as the requirement for expressing multiple addresses per potential as the requirement for expressing multiple addresses per potential
configuration (one port per payload type to simplify processing at configuration (one port per payload type to simplify processing at
the receiver). the receiver). See also Section 6.1 for a requirement to separate
alternative configurations and simultaneous media sessions.
In multi-unicast-scenarios it must be possible to specify more than In multi-unicast-scenarios it must be possible to specify more than
one transport address for a single media stream in an actual one transport address for a single media stream in an actual
configuration, i.e. by specifying address lists. configuration, i.e. by specifying address lists.
In "broadcast"- or "lecture"-like sessions source filters might be In "broadcast"- or "lecture"-like sessions source filters might be
needed that allow receivers to verify the source and apply filters needed that allow receivers to verify the source and apply filters
in multicast sessions. Similarly, for SSM, the transport address in multicast sessions. Similarly, for SSM, the transport address
includes an (Sender,Group) pair of IP addresses. includes an (Sender,Group) pair of IP addresses.
skipping to change at page 12, line 43 skipping to change at page 12, line 44
QoS-Parameters for different protocol domains (e.g. traffic QoS-Parameters for different protocol domains (e.g. traffic
specification and flow specification or TOS bits for IP QoS) need to specification and flow specification or TOS bits for IP QoS) need to
be specified. draft-ietf-mmusic-sdp-qos-00.txt [10] has provided a be specified. draft-ietf-mmusic-sdp-qos-00.txt [10] has provided a
proposal for a syntax that can be used with SDP to describe network proposal for a syntax that can be used with SDP to describe network
and security preconditions that have to be met in order to establish and security preconditions that have to be met in order to establish
a session. a session.
5.1.5 Resource Utilization 5.1.5 Resource Utilization
A requirement debated (but not yet agreed upon) was whether abstract Capability descriptions should not be based on available resources
terms should be found to describe resource requirements (in terms of and resource requirements (in terms of CPU cycles, DSPs, etc.) for
CPU cycles, DSPs, etc.) the following reasons:
o Device manufacturers might not like to let hardware information
go out from their devices.
o The resource utilization function is not bijective since, for
example, to support a certain media, a device A could require a
quantity X of resources, while another device B of a different
manufacturer could require a quantity Y of resource, where X <>
Y. This is an implementation dependent issue, and it is related
with how efficiently/inefficiently a manufacturer is able to
implement a feature in its device.
5.1.6 Dependencies 5.1.6 Dependencies
Certain codes may depend on other resources being available (e.g. a Certain codes may depend on other resources being available (e.g. a
G.723.1 audio codec may need a DTMF codec as well while a G.711 G.723.1 audio codec may need a DTMF codec as well while a G.711
codec does not). Such interdependencies need to be expressed. codec does not). Such interdependencies need to be expressed.
5.1.7 Other parameters (media-specific) 5.1.7 Other parameters (media-specific)
Extension mechanisms that allow to describe arbitrary other Extension mechanisms that allow to describe arbitrary other
parameters of media codecs and formats are mandatory. It is possibly parameters of media codecs and formats are mandatory. It is possibly
required to distinguish between mandatory and optional extension required to distinguish between mandatory and optional extension
parameters. parameters.
In particular, it must be possible to introduce new (optional) In particular, it must be possible to introduce new (optional)
parameters for a payload format and have old implementations still parameters for a payload format and have old implementations still
parse the parameters correctly. parse the parameters correctly.
Some audio/video specific parameters can be defined as suggested in
[16].
5.1.7.1 Media Codec Bit Rates
There should be the possibility to configure ranges of bit rates
(for example 32-64 kbps) or a discrete set of rates (i.e. 24, 32,
48, 64, 128, ... kbps). This is to allow an efficient resource
allocation and allow as well interworking with systems where only a
number of discrete bit rates is available. Resource reservation and
QoS configuration mechanisms in general should available as optional
packages (see Section 5.1.4). It is conceivable that there be a
separation into generic and transport specific QoS packages.
5.1.7.2 Advanced codec modes
Special advanced codec modes may be announced depending, for
example, on the network conditions, to activate special settings in
order to preserve good quality of media and to reduce the
probability of call dropping.
5.1.8 Naming Hierarchy and/or Scoping 5.1.8 Naming Hierarchy and/or Scoping
Parameter names should be constructed in a way to avoid clashes and Parameter names should be constructed in a way to avoid clashes and
thereby simplify independent development of e.g. codec parameter thereby simplify independent development of e.g. codec parameter
descriptions in different groups. descriptions in different groups.
5.1.9 Profiles 5.1.9 Profiles
The configuration options for the different aspects of session The configuration options for the different aspects of session
descriptions (codec definitions, transport parameters etc.) should descriptions (codec definitions, transport parameters etc.) should
be defined in different orthogonal profiles in order to allow for be defined in different orthogonal profiles ("packages"). Two
combining different aspects to a final description. different types of profiles are required:
o A profile can define the data structures and collapsing rules for
a specific function, e.g., for transport parameters. Capability
and session descriptions can refer to such a profile and define
concrete values for the profile parameters.
o Instantiations of such profiles, that already contain concrete
parameters, say for specific codec definitions, can be referenced
by capability and session descriptions in order to allow for
combining different aspects to a final description that is
synthetic and of lower computational complexity.
An open issue is the question whether profiles should be referenced
by name, i.e., by creating a well-known registry, or whether
profiles should be referenced by address, i.e., by creating the
possibility to retrieve them on demand. It is conceivable that a
combination of both is useful: Some basic definitions are registered
and well known and some other, uncommon definitions can be
referenced by URIs.
5.1.10 Registrations of Names
SDP uses top-level MIME content types [15] for media names. These
convention should be adopted in order to avoid the unneccessary
creation of a new namespace.
SDP also defines a registration procedure that allows to register
new names for "media", "proto", "fmt", "bwtype", "nettype", or
"addrtype" field names (defined in [1]). If possible, the names that
are already defined should be re-used. The definition of SDPng
should contain a specification that states the registration
procedures for SDPng.
5.1.11 Meta-Information
5.1.11.1 Scheduling
In order to be usable for conference announcements, e.g. by means of
SAP [11] it also required to provide a means for expressing
scheduling information, i.e. to express the date (or the recurring
dates) when a conference is taking place.
Two alternatives for implementing scheduling functions are
conceivable:
o SDP-style (using the SDP model that is implemented as t= and r=
lines); and
o Using ICalender [14].
5.1.11.2 Optional Meta-Information Packages
Location Meta-Information: In case of usage of SAP [11] as content
or channel directory, the session description should include the
location information, including physical location and the L1/L2
addressing information required to access the session. L1/L2
info may include things like transmission media used,
frequencies, L2 multiplexing information etc. This makes it
possible to broadcast session descriptions sent using broadband
radio on, e.g., narrowband radio network. The recipients can
derive their location from the location sent in the SAP session
description, and then decide if and how they can receive the
media sessions.
Pricing Information: The session description need to specify the
pricing information for the session, if participating in the
session requires payment.
6. Requirements for Capability Description and Negotiation 6. Requirements for Capability Description and Negotiation
6.1 Capability Constraints 6.1 Capability Description
When describing the capabilities of endsystem by providing a list of
different potential configurations, it must be possible to
distinguish alternatives (different potential configuration) from
different simlutaneous sessions of a conference. A clear separation
of these two concepts must be made that should also be realized in
the description language.
6.2 Capability Constraints
Capability negotiation is used to gain a session description (an Capability negotiation is used to gain a session description (an
actual configuration) that is compatible with the different end actual configuration) that is compatible with the different end
system capabilities and user preferences of the potential system capabilities and user preferences of the potential
participants of a conference. participants of a conference.
A media capability description is the same as a potential A media capability description is the same as a potential
configuration, as it contains a set of allowable configurations for configuration, as it contains a set of allowable configurations for
different components that could be used to implement the different components that could be used to implement the
corresponding component. A capability description should allow corresponding component. A capability description should allow
skipping to change at page 14, line 50 skipping to change at page 17, line 9
specification of SDPng (and which extension mechanisms for certain specification of SDPng (and which extension mechanisms for certain
applications or for future revisions should be allowed). applications or for future revisions should be allowed).
Examples are known where complex capability descriptions are Examples are known where complex capability descriptions are
available but are simply not used (at least not at the level of available but are simply not used (at least not at the level of
sophistication that would be possible). This strongly calls for sophistication that would be possible). This strongly calls for
keeping requirements on capability constraints rather modest (KISS). keeping requirements on capability constraints rather modest (KISS).
The description of capabilities and the specification of capacity The description of capabilities and the specification of capacity
limits (maximum numbers of instantiations at a time) should be limits (maximum numbers of instantiations at a time) should be
separated. separated. This allows for greater modularity, since the common
descriptions of capabilities can be referenced and imported, while
the constraints (that are usually unique for a specific endsystem)
can be provided inline and can be applied across singe capability
definitions. In order to allow for simple basic implementations,
this also allows to treat the constraints as optional sections that
do not have to be processed by an implementations.
The capabilities should be expressed as limitations on codec The capabilities should be expressed as limitations on codec
support, transport capability restrictions but not implicitely as support, transport capability restrictions but not implicitely as
limitations on machine resources, such as CPU type, clock rates, limitations on machine resources, such as CPU type, clock rates,
memory etc., that describe internal limitations in order to infer memory etc., that describe internal limitations in order to infer
the supported capabilities. the supported capabilities.
6.2 Processing Rules 6.3 Processing Rules
The processing of potential configurations includes the process of The processing of potential configurations includes the process of
"collapsing" sets of potential configurations offered by "collapsing" sets of potential configurations offered by
participants, i.e. the computation of the intersection of these participants, i.e. the computation of the intersection of these
potential configurations. potential configurations.
The processing (i.e. collapsing, forwarding etc.) of different The processing (i.e. collapsing, forwarding etc.) of different
potential configurations in order to find a compatible subset must potential configurations in order to find a compatible subset must
work without having to know the semantics of the individual work without having to know the semantics of the individual
parameters. This is a key requirement for extensibility. parameters. This is a key requirement for extensibility. Endsystems,
conference bridges, proxies and gateways are thus only required to
understand the basic SDPng semantics of session and capability
description in order to compute the supported subset of capablities
for a conference.
Additionally it must be possible to make use of different Additionally it must be possible to make use of different
negotiation policies in order to reflect different conference types. negotiation policies in order to reflect different conference types.
For example in a lecture-style conference the policy might be to For example in a lecture-style conference the policy might be to
ensure that a capability collapsing process does not yield an actual ensure that a capability collapsing process does not yield an actual
configuration that excludes the main source (i.e. the lecturer and configuration that excludes the main source (i.e. the lecturer and
her end system) from the conference. her end system) from the conference.
Preferences may also be considered in the negotiation process. This Preferences may also be considered in the negotiation process. This
may need to be considered at the SDPng level (e.g. to express may need to be considered at the SDPng level (e.g. to express
preferences, priorities). preferences, priorities).
Of course, the negotiation of configurations must not only work in Of course, the negotiation of configurations must not only work in
peer-to-peer-conference scenarios but also be usable in multi party peer-to-peer-conference scenarios but also be usable in multi party
scenarios. The collapsing rules should work commutatively, that scenarios. The collapsing rules should work commutatively and
means if given 3 end systems A,B,C the result for computing the associatively, that means if given 3 end systems A,B,C the result
supported configurations should be same when computing A*B*C and for computing the supported configurations should be same when
A*C*B (let "*" be the collapsing function). computing (A*B)*C and (B*C)*A (let "*" be the collapsing function).
Negotiation of capabilities should take no longer than two or three Negotiation of capabilities should take no longer than two or three
message exchanges. The description format must enable such message exchanges. The description format must enable such
efficiency. efficiency.
In order to allow for concise capability specification it will In order to allow for concise capability specification it will
probably be required to group descriptions of, say, codecs and to probably be required to group descriptions of, say, codecs and to
establish a kind of hierarchy that allows to attach a certain establish a kind of hierarchy that allows to attach a certain
attribute or parameter to a whole group of codecs. attribute or parameter to a whole group of codecs.
It might then also be required to have a naming scheme that allows It might then also be required to have a naming scheme that allows
to name definitions in order to be able to later reference them in to name definitions in order to be able to later reference them in
subsequent definitions. This is useful in situations where some subsequent definitions. This is useful in situations where some
definition extends a previous definition by just one parameter or in definition extends a previous definition by just one parameter or in
situations where codecs are combined, for example for expressing situations where codecs are combined, for example for expressing
redundancy or layered codings. Different models of re-use are redundancy or layered codings. Different models of re-use are
conceivable. conceivable.
7. Open Issues 7. Open Issues
This section contains a list of items that need further discussion This section contains a list of items that need further work and/or
and are currently not considered to be requirements: discussion:
Scheduling: The possibility to express scheduling information such It needs to distinguished more precisely between mandatory baseline
as start time, duration etc. in session descriptions. functionality and optional extensions.
8. Remarks 8. Remarks
Explicitly addressing the issue of capability negotiation when Explicitly addressing the issue of capability negotiation when
drafting the new session description language generates new sets of drafting the new session description language generates new sets of
requirements, some of which might conflict with other important requirements, some of which might conflict with other important
goals, such as simplicity, conciseness and SDP-compatibility. goals, such as simplicity, conciseness and SDP-compatibility.
However, we think that it's worthwhile to sketch a reasonably However, we think that it's worthwhile to sketch a reasonably
complete and powerful solution first and then later develop a complete and powerful solution first and then later develop a
skipping to change at page 20, line 5 skipping to change at page 21, line 52
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[12] Kumar, R. and M. Mostafa, "Conventions for the use of the [12] Kumar, R. and M. Mostafa, "Conventions for the use of the
Session Description Protocol (SDP) for ATM Bearer Session Description Protocol (SDP) for ATM Bearer
Connections", Internet Draft draft-ietf-mmusic-sdp-atm-05.txt, Connections", Internet Draft draft-ietf-mmusic-sdp-atm-05.txt,
February 2001. February 2001.
[13] Casner, S., "SDP Bandwidth Modifiers for RTCP Bandwidth", [13] Casner, S., "SDP Bandwidth Modifiers for RTCP Bandwidth",
Internet Draft draft-ietf-avt-rtcp-bw-02.txt, November 2000. Internet Draft draft-ietf-avt-rtcp-bw-02.txt, November 2000.
[14] Dawson, F., Stenerson, D., MISSING ORGANIZATION and ,
"Internet Calendaring and Scheduling Core Object Specification
(iCalendar)", RFC 2445, November 1998.
[15] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 2048, November 1996.
[16] Levin, O., "SIP Requirements for support of Multimedia and
Video", Internet Draft draft-levin-sip-for-video-00.txt,
February 2001.
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
Fax: +49.421.218-7000 Fax: +49.421.218-7000
skipping to change at page 21, line 4 skipping to change at page 23, line 4
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
Fax: +49.421.218-7000 Fax: +49.421.218-7000
EMail: cabo@tzi.org EMail: cabo@tzi.org
Igor Curcio
Nokia Mobile Phones
P.O. Box 83 (Visiokatu 1)
33721 Tampere
Finland
Phone: +358.3.272.5372
Fax: +358.10.505.7662
EMail: igor.curcio@nokia.com
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/