Internet DRAFT - draft-andreasen-mmusic-sdp-simcap-reqts
draft-andreasen-mmusic-sdp-simcap-reqts
MMUSIC Working Group F. Andreasen
Internet-Draft Cisco Systems
Document: draft-andreasen-mmusic-sdp-simcap-reqts-00.txt February 2001
Category: Informational
SDP Simple Capability Negotiation Requirements
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document presents a set of requirements for defining Session
Description Protocol (SDP) attributes that will allow SDP to provide
a minimal and backwards compatible capability negotiation mechanism.
The mechanism is intended as a simple and limited solution to the
general capability negotiation problem being addressed by ongoing
work on the next generation of SDP, also known as SDPng.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. Introduction
The Session Description Protocol (SDP) [3] describes multimedia
sessions for the purposes of session announcement, session
invitation, and other forms of multimedia session initiation. SDP
was not intended to provide capability negotiation, however as the
need for this has become increasingly important, work has begun on a
"next generation SDP" (SDPng) [4] that supports both session
Andreasen Informational - Expires August 2001 [Page 1]
Internet-Draft SDP Simple Capability Negotiation Reqts. February 2001
description and capability negotiation. SDPng is not anticipated to
be backwards compatible with SDP and work on SDPng is currently only
in the requirements phase. However, several other protocols, e.g.
SIP [5] and MGCP [6], use SDP, and are likely to continue doing so
for the foreseeable future. Nevertheless, in many cases these
protocols have an urgent need for some limited form of capability
negotiation.
For example, an endpoint may support G.711 audio (over RTP) as well
as T.38 fax relay (over UDP or TCP [8]). However, with current SDP,
this can only be expressed by describing two separate media streams,
which the endpoint must then support at the same time. Another
example involves support for multiple codecs. An endpoint indicates
this by including all the codecs in the "m=" line in the session
description. However, the endpoint thereby also commits to
simultaneous support for each of those codecs. In practice, DSP
memory and processing power limitations may not make this feasible.
As noted in [4], the problem with SDP is, that media descriptions
are used to describe session parameters as well as capabilities
without a clear distinction between the two.
In this document, we provide a set of requirements for providing a
minimal and backwards compatible capability negotiation feature in
SDP. It should be noted, that this mechanism is not intended to
solve the general capability negotiation problem targeted by SDPng.
It is only intended as a simple and limited solution to the most
urgent real world problems facing current users of SDP.
4. Requirements
In the following sections, we provide requirements for the simple
capability negotiation mechanism.
4.1 Backwards Compatibility
The solution must be backwards compatible with SDP. In particular,
it must adhere to the current SDP grammar. Furthermore,
implementations that do not support it must be able to ignore and
skip capability information provided without affecting the semantics
of the remaining SDP.
4.2 Simplicity and Limited Scope
The solution must be simple both in terms of syntax and semantics.
In line with this, the scope of the solution should only be to solve
the most common and pressing real world capability negotiation
problems encountered by current users of SDP.
4.3 Capabilities and Capability Set
The following provides a set of more detailed requirements.
Andreasen Informational - Expires August 2001 [Page 2]
Internet-Draft SDP Simple Capability Negotiation Reqts. February 2001
In order to do capability negotiation, it must be possible to
provide one or more capabilities. Each capability must be
independent and the capabilities provided form the capability set.
It must be possible to provide a capability set at the session-level
and the media level. A capability set provided at the session-level
must apply to the entire session where as a capability set provided
at the media level must only apply to the particular media stream
within which the capability set was provided.
Providing a capability must imply a willingness and ability to
support that capability, but not an actual commitment. In line with
this principle and for reasons of simplicity, it must be permissible
to provide a (potentially static) capability set that is independent
of the actual media stream parameters provided for the session. It
is thus possible that a subsequent attempt to use a given capability
can not be honored, e.g. due to a change in available resources.
A capability set should contain a handle that allows for easy
referencing of the capability set. Each capability within the
capability set should similarly contain a handle that allows for
easy referencing of the capability within that capability set.
Each capability must at a minimum contain a media description with
the media type, transport protocol, and media format for the
capability as defined in [3].
Furthermore, it must be possible to provide additional capability
parameters for each capability provided. In particular, it must be
possible to provide one or more of the following capability
parameters:
* Bandwidth information for the capability.
* Attribute information for the capability.
For each capability parameter, it must be possible to provide:
* One or more alternative values for the capability parameter.
* One or more allowable numerical ranges for capability parameters
that otherwise contain a single numerical value.
Finally, the encoding of a capability should be straightforward and
well-defined based on its encoding in the session description
itself. Neither the syntax nor semantics of a particular parameter
should thus affect this encoding, although of course only numerical
value attributes can use the numerical range description.
4.4 Rejected Requirements
In addition to the requirements provided above, the following
requirements were considered and rejected, as they are seen as non-
essential:
* Capability interdependence, incl.
- grouping capabilities,
Andreasen Informational - Expires August 2001 [Page 3]
Internet-Draft SDP Simple Capability Negotiation Reqts. February 2001
- expressing simultaneous capability sets,
- expressing alternative capability sets
- constraining the number of uses of a certain capability (set)
5. Security Considerations
The addition of the simple capability negotiation attributes to SDP
is not believed to affect security.
6. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[3] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments (Proposed Standard) 2327, Internet
Engineering Task Force, Apr. 1998.
[4] Kutscher, Ott, Bormann, "Requirements for Session Description
and Capability Negotiation", draft-kutscher-mmusic-sdpng-req-
00.txt, July 14, 2000
[5] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments (Proposed
Standard) 2543, Internet Engineering Task Force, Mar. 1999.
[6] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett,
"Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705,
October 1999.
[7] J. Ott, J. Kutscher, C. Bormann, "Capability description for
group cooperation", draft-ott-mmusic-cap-00.txt, June 1999
[8] PROPOSED T.38 AMENDMENT û REC. T.38 ANNEX D, Geneva, 2-10
February, 2000, (available from
ftp://standards.nortelnetworks.com/itu_to_ietf/SG8/February00/Dr
aft_T38_Annex_D.txt)
[9] Beser, B., "Codec Capabilities Attribute for SDP", Internet
Draft, draft-beser-mmusic-capabilities-00.txt, March 2000.
Andreasen Informational - Expires August 2001 [Page 4]
Internet-Draft SDP Simple Capability Negotiation Reqts. February 2001
7. Acknowledgments
This work draws upon the ongoing work on SDPng; in particular [4],
as well as discussions in the MMUSIC working group. Furthermore,
this work was inspired by [7] and the CableLabs PacketCable project.
Related work can be found in [9] as well.
8. Author's Addresses
Flemming Andreasen
Cisco Systems
499 Thornall Street, 8th floor
Edison, NJ
Email: fandreas@cisco.com
Andreasen Informational - Expires August 2001 [Page 5]
Internet-Draft SDP Simple Capability Negotiation Reqts. February 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Andreasen Informational - Expires August 2001 [Page 6]
