MMUSIC Working Group F. Andreasen
Internet-Draft Cisco Systems
Document: draft-andreasen-mmusic-sdp-simcap-00.txt November 2000
Category: Informational
SDP Simple Capability Negotiation
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 proposes a set of Session Description Protocol (SDP)
attributes that 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
Andreasen Informational - Expires May 2001 [Page 1]
Internet-Draft SDP Simple Capability Negotiation November 2000
"next generation SDP" (SDPng) [4] that supports both session
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). Unless the endpoint is willing
to support two media streams at the same time, this can not
currently be expressed in SDP. 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 propose a minimal and backwards compatible
capability negotiation feature in SDP by defining a set of new SDP
attributes. It should be noted, that the mechanism is not intended
to solve the general capability negotiation problem targeted by
SDPng. It is merely intended as a simple and limited solution to the
most urgent problems facing current users of SDP.
4. Requirements
In the following sections, we list and discuss requirements for the
simple capability negotiation.
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 capability negotiation problems
encountered by current users of SDP.
A more precise definition of this particular requirement is
desirable, however the details of it will invariably be subjective.
Andreasen Informational - Expires May 2001 [Page 2]
Internet-Draft SDP Simple Capability Negotiation November 2000
Nevertheless, the following provides some additional detail based on
[4], [7] and previous discussion within the MMUSIC working group:
The following are considered minimum requirements:
* It must be possible to describe each capability independently.
* Lists of alternative values for a capability must be supported.
* Supplying a capability should simply imply a willingness to
support that capability, but not an actual commitment.
* The description of a capability should be straightforward from its
representation in the session description itself (do not want to
come up with elaborate new syntax).
The following list a set of requirements that were considered, but
where further discussion is felt to be needed:
* The ability to express ranges of values for a particular
capability, possibly with "step" values within the range, e.g.
"between 10 and 100 in increments of 10".
The following list a set of requirements that were considered, but
seen as non-essential:
* Capability interdependence, incl.
- grouping capabilities,
- expressing simultaneous capability sets,
- expressing alternative capability sets
- constraining the number of uses of a certain capability (set)
5. Simple Capability Negotiation Attributes
In this section, we provide a list of SDP attributes enabling the
simple SDP capability negotiation we are looking for. The attributes
form a capability set which describes the media capabilities of the
endpoint.
The capability set begins with a single sequence number followed by
one or more capability descriptions listing all media formats the
endpoint is currently able and willing to support. A subsequent
request to use one of these media formats is however not guaranteed
to succeed, e.g. due to limited DSP processing power, or bandwidth
constraints.
The sequence number is on the form
a=sqn: <sqn-num>
where <sqn-num> is an integer between 0 and 255 (both included). The
initial sequence number is 0 and increments by 1 modulo 256 with
each new capability set from the endpoint. The sequence number may
either be provided as a session- or media-level attribute.
Each capability description in the capability set is on the form:
a=cdsc: <cap-num> <media> <transport> <fmt list>
Andreasen Informational - Expires May 2001 [Page 3]
Internet-Draft SDP Simple Capability Negotiation November 2000
where <cap-num> is an integer between 1 and 255 (both included)
identifying the capability, and <media>, <transport>, and <fmt
list> are defined as in the SDP ôm=ö line. The capability number
should start with 1 in the first capability description, and be
incremented by the number of capabilities in the <fmt list> for each
subsequent capability description.
A capability description may include one or more capability
parameter lines on the form:
a=cpar: <cap-par>
where <cap-par> is either bandwidth information (ôb=ö) or an
attribute (ôa=ö). A capability parameter line provides additional
parameters for the preceding capability description.
Capability parameter lines MUST immediately follow the "cdsc" line
they refer to, thus a capability description ends at the first non
"cpar" line that follows the "cdsc" attribute line.
Capability descriptions may be provided at the session- or media-
level. A capability description provided at the session-level
applies to all the media streams specified, where as a capability
description provided at the media-level only applies to that
particular media stream.
Below we show an example session description using the above
capability negotiation attributes:
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 18 96
a=rtpmap:96 telephone-event
a=fmtp:96 0-15,32-35
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18 96
a=cpar: a=fmtp:96 0-16,32-35
a=cdsc: 4 image udptl t38
a=cdsc: 5 image tcp t38
The sender of this session description is currently prepared to send
and receive G.729 audio as well as telephone-events 0-15 and 32-35.
The sender is furthermore capable of supporting:
* media streams using PCMU encoding
* telephone events 0-16 and 32-35
* T.38 fax relay using udp or tcp (see [8])
Andreasen Informational - Expires May 2001 [Page 4]
Internet-Draft SDP Simple Capability Negotiation November 2000
Note, that the first capability number is 1, where as the next is 4,
since three media formats were included in the first capability.
Also note, that the rtpmap for payload type 96 was not included in
the capability description again, as it was already specified for
the media (m=) line.
6. Security Considerations
The addition of the simple capability negotiation attributes to SDP
is not believed to affect security.
7. 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/Dra
ft_T38_Annex_D.txt)
9 Beser, B., "Codec Capabilities Attribute for SDP", Internet
Draft, draft-beser-mmusic-capabilities-00.txt, March 2000.
8. Acknowledgments
Andreasen Informational - Expires May 2001 [Page 5]
Internet-Draft SDP Simple Capability Negotiation November 2000
This work draws upon the ongoing work on SDPng; in particular [4].
Furthermore, this work was inspired by [7] and the CableLabs
PacketCable project. Related work can be found in [9] as well.
9. Author's Addresses
Flemming Andreasen
Cisco Systems
499 Thornall Street, 8th floor
Edison, NJ
Email: fandreas@cisco.com
Andreasen Informational - Expires May 2001 [Page 6]
Internet-Draft SDP Simple Capability Negotiation November 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 May 2001 [Page 7]
