MMUSIC Working Group F. Andreasen Internet-Draft Cisco Systems Document: draft-andreasen-mmusic-sdp-simcap-02.txt May 2001 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 defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability negotiation mechanism. The mechanism can be used as a simple and limited solution to the general capability negotiation problem being addressed by 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,5] that supports both session Andreasen Informational - Expires November 2001 [Page 1] Internet-Draft SDP Simple Capability Negotiation May 2001 description and capability negotiation. SDPng is not anticipated to be backwards compatible with SDP and work on SDPng is currently in the early stages. However, several other protocols, e.g. SIP [6] and MGCP [7], use SDP and are likely to continue doing so for the foreseeable future. Nevertheless, in many cases these signaling 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 these 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 define 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. Simple Capability Negotiation Attributes The SDP Simple Capability Negotiation (simcap) is defined by a set of SDP attributes. Together, these attributes form a capability set which describes the media capabilities of the endpoint. The capability set MUST begin 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 individual capability descriptions may be provided contiguously or they may be scattered throughout the session description. The sequence number is on the form a=sqn: where is an integer between 0 and 255 (both included). The initial sequence number MUST be 0 (zero) and it MUST be incremented by 1 modulo 256 with each new capability set issued by the endpoint. Receivers however may not necessarily see all capability sets issued Andreasen Informational - Expires November 2001 [Page 2] Internet-Draft SDP Simple Capability Negotiation May 2001 and hence MUST NOT reject a capability set due to gaps in sequence numbers. The sequence number MUST either be provided as a session- level or media-level attribute, however there MUST NOT be more than one occurrence of the sequence number in the session description. Each capability description in the capability set is on the form: a=cdsc: where is an integer between 1 and 255 (both included) identifying the capability, and , , and are defined as in the SDP "m=" line. The capability description refers to a send and receive capability by default. When generating a capability set, the capability number MUST start with 1 in the first capability description, and be incremented by the number of capabilities in the for each subsequent capability description. Receivers of a capability set however MUST NOT reject capability descriptions due to gaps in the capability numbers. The capability number provides a convenient handle within the context of the capability set (as referenced by the sequence number) which may be used to reference a particular capability by means outside of this specification. A capability description can include one or more capability parameter lines on the form: a=cpar: a=cparmin: a=cparmax: where is either bandwidth information ("b=") or an attribute ("a=") in its full '=' form (see [3]). A capability parameter line provides additional parameters for the preceding "cdsc" attribute line. Capability parameter lines for a capability description SHOULD immediately follow the "cdsc" line they refer to. Nevertheless, the capability description includes all capability parameter lines until the next capability description ("cdsc") or media description ("m=") line in the session description. The "cpar" attribute should normally be used when parameter values are to be specified. A capability description may contain zero, one, or more "cpar" attribute lines describing either the same or different parameters. Describing the same parameter more than once can be used to specify alternatives. Where a minimum numerical value is to be specified, the "cparmin" attribute should be used. There may be zero, one, or more "cparmin" attribute lines in a capability description, however a given parameter MUST NOT be described by a "cparmin" attribute more than once. Andreasen Informational - Expires November 2001 [Page 3] Internet-Draft SDP Simple Capability Negotiation May 2001 Where a maximum numerical value is to be specified, the "cparmax" attribute should be used. There may be zero, one, or more "cparmax" attribute lines in a capability description, however a given parameter MUST NOT be described by a "cparmax" attribute more than once. Ranges of numerical values can be expressed by using a "cparmin" and a "cparmax" attribute for a given parameter. It follows from the previous rules, that only a single range can be specified for a given parameter. Capability descriptions may be provided at both the session-level and media-level. A capability description provided at the session- level applies to all the media streams in the session description, whereas a capability description provided at the media-level only applies to that particular media stream. The first capability description MUST follow immediately after the sequence number. Below we show an example session description using the above simple capability negotiation mechanism: 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: * PCMU encoding for the audio media stream, * telephone events 0-16 and 32-35, * T.38 fax relay using udp or tcp (see [8]). Note, that the first capability number specified is 1, whereas the next is 4 since three media formats were included in the first capability description. Also note, that the rtpmap for payload type 96 was not included in the capability description, as it was already specified for the media ("m=") line. Below, we show another example of the simple capability negotiation mechanism, this time with multiple media streams: Andreasen Informational - Expires November 2001 [Page 4] Internet-Draft SDP Simple Capability Negotiation May 2001 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 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 0 18 m=video 3458 RTP/AVP 31 a=cdsc: 3 video RTP/AVP 31 34 The sender of this session description is currently prepared to send and receive G.729 audio and H.261 video. The sender is furthermore capable of supporting: * PCMU encoding for the audio media stream, * H.263 for the video media stream. Note, that the first capability number specified is 1, whereas the next is 3 since two media formats were included in the first capability description. Also note, that the sequence number applies to the entire capability set, i.e. both audio and video, and hence is only supplied once. The above session description could equally well have been supplied as follows: v=0 o=- 25678 753849 IN IP4 128.96.41.1 s=- c=IN IP4 128.96.41.1 t=0 0 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 0 18 a=cdsc: 3 video RTP/AVP 31 34 m=audio 3456 RTP/AVP 18 m=video 3458 RTP/AVP 31 i.e., with the capability set provided at the session-level. 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 Andreasen Informational - Expires November 2001 [Page 5] Internet-Draft SDP Simple Capability Negotiation May 2001 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, Curcio, "Requirements for Session Description and Capability Negotiation", Internet-Draft, Internet Engineering Task Force, April 2001. Work in Progress. 5 Kutscher, Ott, Borman, "Session Description and Capability Negotiation", Internet-Draft, Internet Engineering Task Force, April 2001. Work in Progress. 6 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. 7 Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 1999. 8 ITU-T Recommendation T.38 ANNEX D, "SIP/SDP Call Establishment Procedures". 8. Acknowledgments This work draws upon the ongoing work on SDPng in the IETF MMUSIC Working Group; in particular [4]. Furthermore this work was inspired by the CableLabs PacketCable project. The author would like to thank the following individuals for their valuable comments and suggestions: Joerg Ott, Orit Levin, and Tom Taylor. 9. Author's Addresses Flemming Andreasen Cisco Systems 499 Thornall Street, 8th floor Edison, NJ Email: fandreas@cisco.com Andreasen Informational - Expires November 2001 [Page 6] Internet-Draft SDP Simple Capability Negotiation May 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 November 2001 [Page 7]