RFC 3407

Session Description Protocol (SDP) Simple Capability Declaration

📅 published October 2002, from ietf

RFC 3407: Session Description Protocol (SDP) Simple Capability Declaration 🎀

Okay bestie, this is RFC 3407 💖 and the official title is Session Description Protocol (SDP) Simple Capability Declaration. Here's the title block tea ☕:

  • From: F. Andreasen at Cisco Systems, in the Network Working Group 🧚
  • Category: Standards Track, so this is an actual official standard, not just a vibe 👑
  • Date: October 2002 📅
  • Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🙈

Status of this Memo ✨

This doc is an Internet standards track protocol for the Internet community, and the community is literally invited to discuss it and suggest improvements 🫶. For the standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🌸

So this doc defines a set of Session Description Protocol (SDP) attributes that let SDP do a minimal and backwards compatible capability declaration 🎀. These declarations can be used as input to a later session negotiation, which happens by means outside the scope of this document 🔥. It's a simple and limited solution to the general capability negotiation problem that the next generation of SDP, also known as SDPng, is going to tackle ✨.

1. Conventions Used in this Document 🌈

Whenever you see the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc, they're to be read as described in RFC-2119 [2]. These are the official rule-words, so they carry real weight 💀.

2. Introduction 🦋

Okay so SDP [3] describes multimedia sessions for session announcement, session invitation, and other forms of multimedia session initiation 🎬. SDP was never meant to do capability negotiation 🙈. But as that need got more and more important, work started on a "next generation SDP" (SDPng) [4,5] that handles both session description and capability negotiation 💖. SDPng isn't expected to be backwards compatible with SDP, and it's still in the early stages 🧪. Still, several other protocols, e.g. SIP [6] and Media Gateway Control Protocol (MGCP) [7], use SDP and are likely to keep doing so for the foreseeable future 👀. In a lot of cases, these signaling protocols have an urgent need for some limited form of capability negotiation 😭.

For example, an endpoint might 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't currently be expressed in SDP 💀. Another example is multiple codecs. An endpoint shows this by including all the codecs in the m= line of the session description. But here's the catch: the endpoint is also committing to support each of those codecs at the same time 😬. In practice, Digital Signal Processor (DSP) memory and processing power limits may make that not 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 🍑.

So in this doc, we define a minimal and backwards compatible capability declaration feature for SDP by defining a set of new SDP attributes 🧚. Together, these attributes make up a capability set. That's a capability set sequence number followed by one or more capability descriptions 📋. Each capability description has info about supported media formats, but the endpoint is not committing to use any of them ✨. To actually use a declared capability, session negotiation will have to happen by means outside the scope of this document, for example using the offer/answer model [8] 🤝.

It should be noted that this mechanism is not meant to solve the general capability negotiation problem that SDPng is targeting 🙅‍♀️. It's merely a simple and limited solution to the most urgent problems facing current SDP users right now 🌟

(to be continued in part 2 🧚✨)

3. Simple Capability Declaration Attributes ✨

okay so the SDP Simple Capability Declaration (simcap) is a set of SDP attributes that work together 🧚 Together they make a capability set that describes the endpoint's complete media capabilities. Any earlier capability sets the endpoint issued for that session are now ghosted 👻 💀 A capability set has a sequence number plus one or more capability descriptions. Each description says which media type and media formats are supported, and it can include capability parameters to define the capability more precisely 💅

A session description MUST NOT contain more than one capability set, but that one set can describe capabilities at both the session and the media level 🎀 Session-level capability descriptions apply to all media streams of the indicated media type, and media-level ones apply to that one media stream only. We call these session capabilities and media stream capabilities 🦋 A media stream capability may or may not be the same media type as the stream it applies to, iykyk 🌸

The capability set MUST begin with a single sequence number, followed by one or more capability descriptions listing every media format the endpoint is currently able and willing to support 🫶 More specifically, if a media format shows up in a media ("m=") line, then by definition it MUST be included in either a session capability or a media stream capability for that media line. Main character energy: the endpoint MAY include additional media formats in a capability if it can support them in a session with its peer ✨ But an endpoint MUST NOT include capabilities it knows it cannot use in a particular session 🙅‍♀️ An endpoint that receives a capability set from another endpoint MAY use any of the media formats in that set later on when trying to negotiate media streams with the other endpoint, e.g., using the offer/answer model [8] 🍓 If a new capability set arrives from the other endpoint, the old capability set MUST NOT be used any longer 🫠 Session capabilities can be used for any media streams of the indicated media type, while media stream capabilities can only be used for their associated media line. Still, an endpoint receiving a capability set with a given media format MUST NOT assume that a later attempt to negotiate a media stream using just that media format will succeed 😭 no cap, it's not a guarantee!

The individual capability descriptions in a capability set can be provided contiguously, or they can be scattered throughout the session description 🌈 The first capability description MUST, however, follow immediately after the sequence number 💜

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 MUST be 0 (zero), and it MUST be incremented by 1 modulo 256 with each new capability set the endpoint issues 🔥 Receivers may not necessarily see all the capability sets that were issued, so they 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 attribute in the session description, since there cannot be more than one capability set 🙈

Each capability description in the capability set is on the form:

a=cdsc: <cap-num> <media> <transport> <fmt list>

where <cap-num> is an integer between 1 and 255 (both included) used to number the capabilities, and <media>, <transport>, and <fmt list> are defined as in the SDP "m=" line. By default, the capability description refers to a send and receive capability 🎀 When generating a capability set, the capability number MUST start with 1 in the first capability description, and it MUST be incremented by the number of media formats in the <fmt list> for each subsequent capability description. The media formats in the <fmt list> are numbered from left to right. Receivers of a capability set MUST NOT, however, reject capability descriptions due to gaps in the capability numbers 💖 The capability number is a handy little handle within the context of the capability set (as referenced by the sequence number), and it 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: <cap-par>
a=cparmin: <cap-par>
a=cparmax: <cap-par>

where <cap-par> is either bandwidth information ("b=") or an attribute ("a=") in its full '<type>=<value>' form (see [3]). A capability parameter line gives extra parameters for the "cdsc" attribute line right before it 🍓 Capability parameter lines for a capability description SHOULD immediately follow the "cdsc" line they refer to. Even so, the capability description includes all capability parameter lines until the next capability description ("cdsc") or media ("m=") line in the session description 🌸

The "cpar" attribute should normally be used when capability parameter values are to be specified 🦋 When it's provided, it means the endpoint is declaring that it supports the media formats in the preceding "cdsc" line in accordance with the <cap-par> value specified. This can be used to specify "fmtp" parameters, for example 💅 If a session negotiation is attempted without considering the <cap-par> value, it may fail due to lack of endpoint support 💀 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 🙅‍♀️

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 the media level. A capability description at the session level applies to all the media streams of the indicated media type in the session description. A capability description at the media level only applies to that particular media stream (regardless of media type) 🫶 If a capability description with media type X is provided at the session level, and there are no media streams of type X in the session description, then it is undefined which of the media streams the capability description applies to (except if there is only one media stream). It is therefore RECOMMENDED that such capabilities are provided at the media level instead 🎀

Here's an example session description using the above simple capability declaration 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, plus telephone-events 0-15 and 32-35. The sender is also 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 [9]).

Note that the first capability number is 1, and the next one 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, because it was already specified for the media ("m=") line. On the flip side, it would of course not have been valid to provide the rtpmap in the capability description and then omit the "a=rtpmap" line 🙈

Here's another example of the simple capability declaration mechanism, this time with multiple media streams 💜

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 also capable of supporting:

  • PCMU encoding for the audio media stream,
  • H.263 for the video media stream.

Note that the first capability number is 1, and the next one 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, so it is only supplied once. Finally, note that the media formats 18 and 31 are listed in both the media lines and the capability set, as required 🦋 The above session description could have equally 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 🌸

4. Security Considerations 🔐

Capability negotiation of security-sensitive parameters is a delicate process 😱 It should not be done without careful evaluation of the design, including the possible susceptibility to downgrade attacks. Use of capability re-negotiation may make the session susceptible to denial of service, without design care as to authentication 💀

5. IANA Considerations ✨

okay so bestie, this section is basically the registry paperwork 📋💅 IANA gets told about five brand new SDP attribute names, all of type "att-field" (that's the SDP attribute-name flavor). Every single one of them is session-level AND media-level, and none of them are subject to charset. Main character energy, honestly 👑

Here's the whole lineup 🎀

Attribute name:      sqn
Long form name:      Sequence number.
Type of attribute:   Session-level and media-level.
Subject to charset:  No.
Purpose:             Capability set numbering.
Appropriate values:  See Section 3.

Attribute name:      cdsc
Long form name:      Capability description.
Type of attribute:   Session-level and media-level.
Subject to charset:  No.
Purpose:             Describe capabilities in a capability set.
Appropriate values:  See Section 3.

Attribute name:      cpar
Long form name:      Capability parameter line.
Type of attribute:   Session-level and media-level.
Subject to charset:  No.
Purpose:             Provide capability description parameters.
Appropriate values:  See Section 3.

Attribute name:      cparmin
Long form name:      Minimum capability parameter line.
Type of attribute:   Session-level and media-level.
Subject to charset:  No.
Purpose:             Provide minimum capability description
                     parameters.
Appropriate values:  See Section 3.

Attribute name:      cparmax
Long form name:      Maximum capability parameter line.
Type of attribute:   Session-level and media-level.
Subject to charset:  No.
Purpose:             Provide maximum capability description
                     parameters.
Appropriate values:  See Section 3.

Every "appropriate values" entry just points you back to Section 3, so that's where the real juice is 🧃🫶

6. Normative References 📚

okay the homework list 🤓 These are the must-reads.

  • [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] Handley, M. and V. Jacobson, "SDP: session description protocol", Request for Comments 2327, April 1998.

7. Informative References 🦋

these are the extra-credit reads, bestie, not required but lowkey useful 🌸

  • [4] Kutscher, Ott, Bormann and Curcio, "Requirements for Session Description and Capability Negotiation", Work in Progress.
  • [5] Kutscher, Ott and Borman, "Session Description and Capability Negotiation", Work in Progress.
  • [6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: session initiation protocol", RFC 2543, March 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] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", Work in Progress.
  • [9] ITU-T Recommendation T.38 Annex D, "SIP/SDP Call Establishment Procedures".

8. Acknowledgments 💖

this work draws on the ongoing SDPng work in the IETF MMUSIC Working Group, especially [4] 🫶 It was also inspired by the CableLabs PacketCable project ✨ The author wants to give a huge thank-you to Joerg Ott and Jonathan Rosenberg, who left so many detailed comments and suggestions to make the spec better 💅 Colin Perkins, Orit Levin and Tom Taylor gave valuable feedback too 🌈

9. Author's Address 🎀

Flemming Andreasen Cisco Systems 499 Thornall Street, 8th floor Edison, NJ EMail: fandreas@cisco.com

Copyright (C) The Internet Society (2002). 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. 🌸💜

📦 where this page comes from