7006
PROPOSED STANDARD
Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)
Authors: M. Garcia-Martin, S. Veikkolainen, R. Gilman
Date: September 2013
Area: rai
Working Group: mmusic
Stream: IETF
Abstract
The Session Description Protocol (SDP) has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely used SDP offer/answer procedures.
This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ("b=" line), connection data ("c=" line), and session or media titles ("i=" line for each session or media).
RFC 7006
PROPOSED STANDARD
Errata Exist
Internet Engineering Task Force (IETF) M. Garcia-Martin
Request for Comments: 7006 Ericsson
Category: Standards Track S. Veikkolainen
ISSN: 2070-1721 Nokia
R. Gilman
September 2013
<span class="h1">Miscellaneous Capabilities Negotiation in the</span>
<span class="h1">Session Description Protocol (SDP)</span>
Abstract
The Session Description Protocol (SDP) has been extended with a
capability negotiation mechanism framework that allows the endpoints
to negotiate transport protocols and attributes. This framework has
been extended with a media capabilities negotiation mechanism that
allows endpoints to negotiate additional media-related capabilities.
This negotiation is embedded into the widely used SDP offer/answer
procedures.
This memo extends the SDP capability negotiation framework to allow
endpoints to negotiate three additional SDP capabilities. In
particular, this memo provides a mechanism to negotiate bandwidth
("b=" line), connection data ("c=" line), and session or media titles
("i=" line for each session or media).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc7006">http://www.rfc-editor.org/info/rfc7006</a>.
<span class="grey">Garcia-Martin, et al. Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Protocol Description ............................................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Extensions to SDP ..........................................<a href="#page-4">4</a>
<a href="#section-3.1.1">3.1.1</a>. Bandwidth Capability ................................<a href="#page-6">6</a>
<a href="#section-3.1.2">3.1.2</a>. Connection Data Capability ..........................<a href="#page-8">8</a>
<a href="#section-3.1.3">3.1.3</a>. Title Capability ...................................<a href="#page-12">12</a>
<a href="#section-3.2">3.2</a>. Session Level versus Media Level ..........................<a href="#page-16">16</a>
<a href="#section-3.3">3.3</a>. Offer/Answer Model Extensions .............................<a href="#page-17">17</a>
<a href="#section-3.3.1">3.3.1</a>. Generating the Initial Offer .......................<a href="#page-17">17</a>
<a href="#section-3.3.2">3.3.2</a>. Generating the Answer ..............................<a href="#page-17">17</a>
<a href="#section-3.3.3">3.3.3</a>. Offerer Processing of the Answer ...................<a href="#page-18">18</a>
<a href="#section-3.3.4">3.3.4</a>. Modifying the Session ..............................<a href="#page-18">18</a>
<a href="#section-4">4</a>. Field Replacement Rules ........................................<a href="#page-18">18</a>
<a href="#section-5">5</a>. Security Considerations ........................................<a href="#page-18">18</a>
<a href="#section-6">6</a>. IANA Considerations ............................................<a href="#page-19">19</a>
<a href="#section-6.1">6.1</a>. New SDP Attributes ........................................<a href="#page-19">19</a>
<a href="#section-6.2">6.2</a>. New Option Tags ...........................................<a href="#page-20">20</a>
<a href="#section-6.3">6.3</a>. New SDP Capability Negotiation Configuration Parameters ...<a href="#page-20">20</a>
<a href="#section-7">7</a>. Acknowledgments ................................................<a href="#page-20">20</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-20">20</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-20">20</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-21">21</a>
<span class="grey">Garcia-Martin, et al. Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Session Description Protocol (SDP) [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] is intended for
describing multimedia sessions for the purposes of session
announcement, session invitation, and other forms of multimedia
session initiation. SDP has been extended with an SDP Capability
Negotiation Mechanism Framework [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>] that allows the endpoints
to negotiate capabilities, such as support for the Real-time
Transport Protocol (RTP) [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] and the Secure Real-time Transport
Protocol (SRTP) [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>]. The SDP Media Capabilities Negotiation
[<a href="./rfc6871" title=""Session Description Protocol (SDP) Media Capabilities Negotiation"">RFC6871</a>] provides negotiation capabilities to media lines as well.
The capability negotiation is embedded into the widely used SDP
offer/answer procedure [<a href="./rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>]. This memo provides the means to
negotiate further capabilities than those specified in the SDP
Capability Negotiation Mechanism Framework [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>] and the SDP
Media Capabilities Negotiation [<a href="./rfc6871" title=""Session Description Protocol (SDP) Media Capabilities Negotiation"">RFC6871</a>]. In particular, this memo
provides a mechanism to negotiate bandwidth ("b="), connection data
("c="), and session or media titles ("i=").
Since the three added capabilities are independent, it is not
expected that implementations will necessarily support all of them at
the same time. Instead, it is expected that applications will choose
their needed capability for their specific purpose. For this reason,
the normative part pertaining to each capability is in a self-
contained section: <a href="#section-3.1.1">Section 3.1.1</a> describes the bandwidth capability
extension, <a href="#section-3.1.2">Section 3.1.2</a> describes the connection data capability
extension, and <a href="#section-3.1.3">Section 3.1.3</a> describes the title capability
extension. Separate SDP Capability Negotiation option tags are
defined for each capability, allowing endpoints to indicate and/or
require support for these extensions according to procedures defined
in SDP Capability Negotiation [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] and indicate requirement levels for compliant
implementations.
<span class="grey">Garcia-Martin, et al. Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Protocol Description</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Extensions to SDP</span>
The SDP Capability Negotiation Framework [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>] and the SDP Media
Capabilities Negotiation [<a href="./rfc6871" title=""Session Description Protocol (SDP) Media Capabilities Negotiation"">RFC6871</a>] specify attributes for negotiating
SDP capabilities. These documents specify new attributes (e.g.,
"acap", "tcap", "rmcap", and "omcap") for achieving their purpose.
In this document, we define three new additional capability
attributes for SDP lines of the general form:
type=value
for types "b", "c", and "i". The corresponding capability attributes
are respectively defined as:
o "bcap": bandwidth capability
o "ccap": connection data capability
o "icap": title capability
From the sub-rules of the attribute ("a=") line in SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>], SDP
attributes are of the form:
attribute = (att-field ":" att-value) / att-field
att-field = token
att-value = byte-string
Capability attributes use only the "att-field:att-value" form.
The new capabilities may be referenced in potential configurations
("a=pcfg") or in latent configurations ("a=lcfg") as productions
conforming to the <extension-config-list>, as respectively defined in
<a href="./rfc5939">RFC 5939</a> [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>] and <a href="./rfc6871">RFC 6871</a> [<a href="./rfc6871" title=""Session Description Protocol (SDP) Media Capabilities Negotiation"">RFC6871</a>].
extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT)
; ALPHA and DIGIT defined in <a href="./rfc5234">RFC 5234</a>
ext-cap-list = 1*VCHAR ; VCHAR defined in <a href="./rfc5234">RFC 5234</a>
The optional "+" is used to indicate that the extension is mandatory
and MUST be supported in order to use that particular configuration.
<span class="grey">Garcia-Martin, et al. Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
The new capabilities may also be referenced in actual configurations
("a=acfg") as productions conforming to the <sel-extension-config>
defined in <a href="./rfc5939">RFC 5939</a> [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>].
sel-extension-config = ext-cap-name "=" 1*VCHAR
The specific parameters are defined in the individual description of
each capability below.
The "bcap", "ccap", and "icap" capability attributes can be provided
at the SDP session and/or media level. According to the SDP
Capability Negotiation [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>], each extension capability must
specify the implication of making it part of a configuration at the
media level.
According to SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>], "b=", "c=", and "i=" lines may appear at
either session or media level. In line with this, the "bcap",
"ccap", and "icap" capability attributes, when declared at session
level, are to be interpreted as if that attribute was provided with
that value at the session level. The "bcap", "ccap", and "icap"
capability attributes declared at media level are to be interpreted
as if that capability attribute was declared at the media level.
For example, extending the example in [<a href="./rfc6871" title=""Session Description Protocol (SDP) Media Capabilities Negotiation"">RFC6871</a>] with "icap" and
"bcap" capability attributes, we get the following SDP:
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=bcap:1 CT:200
a=icap:1 Video conference
m=audio 54320 RTP/AVP 0
a=rmcap:1 L16/8000/1
a=rmcap:2 L16/16000/2
a=pcfg:1 m=1|2 pt=1:99,2:98
m=video 66544 RTP/AVP 100
a=rmcap:3 H263-1998/90000
a=rtpmap:100 H264/90000
a=pcfg:10 m=3 pt=3:101 b=1 i=1
Figure 1: Example SDP offer with bcap and icap
efined at session level
<span class="grey">Garcia-Martin, et al. Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
The above SDP defines one PCMU audio stream and one H.264 video
stream. It also defines two RTP-based media capabilities ("rmcap"
numbered 1 and 2), using 16-bit linear (L16) audio at 8 kbps and 16
kbps, respectively, as well as an RTP-based media capability for
H.263 video ("rmcap" numbered 3). The RTP-based media capabilities
all appear at the media level. The example also contains a single
bandwidth capability ("bcap") and a single title capability ("icap"),
both defined at session level. According to the definition above,
when the capabilities defined in the "bcap" and "icap" attributes are
referenced from the potential configuration, in the resulting SDP
they are to be interpreted as session-level attributes (but the
RTP-based media capabilities are to be interpreted as media-level
attributes).
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Bandwidth Capability</span>
According to <a href="./rfc4566">RFC 4566</a> [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>], the bandwidth field denotes the
proposed bandwidth to be used by the session or media. In this memo,
we specify the bandwidth capability attribute, which can also appear
at the SDP session and/or media level. The bandwidth field is
specified in <a href="./rfc4566">RFC 4566</a> [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] with the following syntax:
b=<bwtype>:<bandwidth>
where <bwtype> is an alphanumeric modifier giving the meaning of the
<bandwidth> figure.
In this document, we define a new capability attribute: the bandwidth
capability attribute "bcap". This attribute lists bandwidth as
capabilities, according to the following definition:
"a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF
where <bw-cap-num> is a unique integer within all the bandwidth
capabilities in the entire SDP, which is used to number the bandwidth
capability and can take a value between 1 and 2^31-1 (both included).
The other elements are as defined for the "b=" field in SDP
[<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>].
This format satisfies the general attribute production rules in SDP
[<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>], according to the following Augmented Backus-Naur Form
(ABNF) [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] syntax:
att-field =/ "bcap"
att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in <a href="./rfc5234">RFC 5234</a>
Figure 2: Syntax of the "bcap" attribute
<span class="grey">Garcia-Martin, et al. Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
Negotiation of bandwidth per media stream can be useful when
negotiating media encoding capabilities with different bandwidths.
<span class="h5"><a class="selflink" id="section-3.1.1.1" href="#section-3.1.1.1">3.1.1.1</a>. Configuration Parameters</span>
The SDP Capability Negotiation Framework [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>] provides for the
existence of the "pcfg" and "acfg" attributes. The concept is
extended by the SDP Media Capabilities Negotiation [<a href="./rfc6871" title=""Session Description Protocol (SDP) Media Capabilities Negotiation"">RFC6871</a>] with an
"lcfg" attribute that conveys latent configurations.
Extensions to the "pcfg" and "lcfg" attributes are defined through
<extension-config-list>, and extensions to the "acfg" attribute are
defined through the <sel-extension-config>, as defined in the SDP
Capability Negotiation [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>].
In this document, we extend the <extension-config-list> field to be
able to convey lists of bandwidth capabilities in latent or potential
configurations, according to the following Augmented Backus-Naur Form
(ABNF) [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] syntax:
extension-config-list =/ bandwidth-config-list
bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR bw-cap-list)
; BAR defined in <a href="./rfc5939">RFC 5939</a>
bw-cap-list = bw-cap-num *("," bw-cap-num)
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in <a href="./rfc5234">RFC 5234</a>
Figure 3: Syntax of the bandwidth parameter
in "lcfg" and "pcfg" attributes
Each bandwidth capability configuration is a comma-separated list of
bandwidth capability attribute numbers where <bw-cap-num> refers to
the <bw-cap-num> bandwidth capability numbers defined explicitly
earlier in this document, and hence MUST be between 1 and 2^31-1
(both included). Alternative bandwidth configurations are separated
by a vertical bar ("|").
The above syntax is very flexible, allowing referencing to multiple
"b=" lines per configuration, even for the same <bwtype>. While the
need for such definitions is not seen, we have not restricted this,
as it is not restricted in SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] either.
<span class="grey">Garcia-Martin, et al. Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
The bandwidth parameter to the actual configuration attribute
("a=acfg") is formulated as a <sel-extension-config> with
ext-cap-name = "b"
hence
sel-extension-config =/ sel-bandwidth-config
sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above.
Figure 4: Syntax of the bandwidth parameter in "acfg" attributes
<span class="h5"><a class="selflink" id="section-3.1.1.2" href="#section-3.1.1.2">3.1.1.2</a>. Option Tag</span>
The SDP Capability Negotiation Framework [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>] allows for
capability negotiation extensions to be defined. Associated with
each such extension is an option tag that identifies the extension in
question. Hereby, we define a new option tag "bcap-v0" that
identifies support for the bandwidth capability. The endpoints using
the "bcap" capability attribute SHOULD add the option tag to other
existing option tags present in the "csup" and "creq" attributes in
SDP, according to the procedures defined in the SDP Capability
Negotiation Framework [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>].
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Connection Data Capability</span>
According to SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>], the connection data field in SDP contains
the connection data, and it has the following syntax:
c=<nettype> <addrtype> <connection-address>
where <nettype> indicates the network type, <addrtype> indicates the
address type, and the <connection-address> is the connection address,
which is dependent on the address type.
At the moment, network types already defined include "IN", which
indicates Internet network type, and "ATM" (see <a href="./rfc3108">RFC 3108</a> [<a href="./rfc3108" title=""Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections"">RFC3108</a>]),
used for describing Asynchronous Transfer Mode (ATM) bearer
connections. The Circuit-Switched (CS) descriptions in the SDP
document [<a href="#ref-SDP-CS" title=""Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)"">SDP-CS</a>] adds a "PSTN" network type for expressing a Public
Switched Telephone Network (PSTN) circuit switch.
<span class="grey">Garcia-Martin, et al. Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] permits specification of connection data at the SDP
session and/or media level. In order to permit negotiation of
connection data at the media level, we define the connection data
capability attribute ("a=ccap") in the form:
"a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP
connection-address CRLF
where <conn-cap-num> is a unique integer within all the connection
capabilities in the entire SDP, which is used to identify the
connection data capability and can take a value between 1 and 2^31-1
(both included). The other elements are as defined in [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>].
This format corresponds to the [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] attribute production rules,
according to the following Augmented Backus-Naur Form (ABNF)
[<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] syntax:
att-field =/ "ccap"
att-value =/ conn-cap-num 1*WSP nettype SP addrtype
SP connection-address
conn-cap-num = 1*10(DIGIT) ; 1 to 2^31-1, inclusive
; DIGIT defined in <a href="./rfc5234">RFC 5234</a>
Figure 5: Syntax of the "ccap" attribute
The "ccap" capability attribute allows for expressing alternative
connections address ("c=") lines in SDP as part of the SDP Capability
Negotiation process. One of the primary use cases for this is
offering alternative connection addresses where the <nettype> is "IN"
or "PSTN", i.e., selecting between an IP-based bearer or a
circuit-switched bearer.
By supporting the "IN" <nettype>, the "ccap" attribute enables the
signaling of multiple IPv4 and IPv6 addresses; however, the Standards
Track mechanism for negotiation of alternative IP addresses in SDP is
Interactive Connectivity Establishment (ICE) [<a href="./rfc5245" title=""Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols"">RFC5245</a>]. The "ccap"
attribute does not change that; hence, the combined set of actual and
potential configurations (as defined in [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>]) for any given
media description MUST NOT use the "ccap" attribute to negotiate more
than one address with an IN network type (i.e., it is not permissible
to select between "IPv4" and "IPv6" address families or different IP
addresses within the same IP address family.
Figure 6 is an example of an SDP offer that includes a "ccap"
capability attribute. An audio stream can be set up with an RTP flow
or by establishing a circuit-switched audio stream:
<span class="grey">Garcia-Martin, et al. Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
a=creq:med-v0,ccap-v0
m=audio 38902 RTP/AVP 0 8
c=IN IP4 198.51.100.7
a=ccap:1 PSTN E164 +15555556666
a=tcap:2 PSTN
a=omcap:1 -
a=acap:1 setup:actpass
a=acap:2 connection:new
a=acap:3 cs-correlation:callerid:+15555556666
a=pcfg:1 c=1 t=2 m=1 a=1,2,3
Figure 6: Example SDP offer with a "ccap" attribute
The example in Figure 6 represents an SDP offer indicating an audio
flow using RTP, such as the one represented in Figure 7, or an audio
flow using a circuit-switched connection, such as the one represented
in Figure 8.
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
m=audio 38902 RTP/AVP 0 8
c=IN IP4 198.51.100.7
Figure 7: Equivalent SDP offer with the RTP flow
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
m=audio 9 PSTN -
c=PSTN E164 +15555556666
a=setup:actpass
a=connection:new
a=cs-correlation:callerid:+15555556666
Figure 8: Equivalent SDP offer with the circuit-switched flow
This document does not define any mechanism for negotiating or
describing different port numbers; hence, the port number from the
"m=" line MUST be used by default. Exceptions to this default can be
provided by extension mechanisms or network type specific rules.
This document defines an exception when the network type is "PSTN",
<span class="grey">Garcia-Martin, et al. Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
in which case the port number is replaced with 9 (the "discard"
port), as described in "Session Description Protocol (SDP) Extension
for Setting Audio and Video Media Streams over Circuit-Switched
Bearers in the Public Switched Telephone Network (PSTN)" [<a href="#ref-SDP-CS" title=""Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)"">SDP-CS</a>].
An endpoint offering alternative IP and PSTN bearers MUST include the
IP media description in the actual configuration (IP address in the
"c=" line and port number in the "m=" line) and the PSTN media
description in the potential configuration.
Exceptions for other network types, such as for the "ATM" network
type defined in [<a href="./rfc3108" title=""Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections"">RFC3108</a>], require additional specifications.
<span class="h5"><a class="selflink" id="section-3.1.2.1" href="#section-3.1.2.1">3.1.2.1</a>. Configuration Parameters</span>
The SDP Capability Negotiation Framework [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>] provides for the
existence of the "pcfg" and "acfg" attributes, which can convey one
or more configurations to be negotiated. The concept is extended by
the SDP Media Capabilities Negotiation [<a href="./rfc6871" title=""Session Description Protocol (SDP) Media Capabilities Negotiation"">RFC6871</a>] with an "lcfg"
attribute that conveys latent configurations.
In this document, we define a <connection-config> parameter to be
used to specify a connection data capability in a potential or latent
configuration attribute. The parameter follows the form of an
<extension-config-list> with
ext-cap-name = "c"
ext-cap-list = conn-cap-list
where, according to the following Augmented Backus-Naur Form (ABNF)
[<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] syntax:
extension-config-list =/ conn-config-list
conn-config-list = ["+"] "c=" conn-cap-list
conn-cap-list = conn-cap-num *(BAR conn-cap-num)
conn-cap-num = 1*10(DIGIT) ; 1 to 2^32-1 inclusive
Figure 9: Syntax of the connection data
parameter in "lcfg" and "pcfg" attributes
Each capability configuration alternative contains a single
connection data capability attribute number and refers to the
conn-cap-num capability number defined explicitly earlier in this
document; hence, the values MUST be between 1 and 2^31-1 (both
included). The connection data capability allows the expression of
only a single capability in each alternative, rather than a list of
capabilities, since no more than a single connection data field is
<span class="grey">Garcia-Martin, et al. Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
permitted per media block. Nevertheless, it is still allowed to
express alternative potential connection configurations separated by
a vertical bar ("|").
An endpoint includes a plus sign ("+") in the configuration attribute
to mandate support for this extension. An endpoint that receives
this parameter prefixed with a plus sign and does not support this
extension MUST treat that potential configuration as not valid.
The connection data parameter to the actual configuration attribute
("a=acfg") is formulated as a <sel-extension-config> with
ext-cap-name = "c"
hence
sel-extension-config =/ sel-connection-config
sel-connection-config = "c=" conn-cap-num ; as defined above.
Figure 10: Syntax of the connection data parameter
in "acfg" attributes
<span class="h5"><a class="selflink" id="section-3.1.2.2" href="#section-3.1.2.2">3.1.2.2</a>. Option Tag</span>
The SDP Capability Negotiation Framework [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>] solution allows
for capability negotiation extensions to be defined. Associated with
each such extension is an option tag that identifies the extension in
question. Hereby, we define a new option tag of "ccap-v0" that
identifies support for the connection data capability. This option
tag SHOULD be added to other existing option tags present in the
"csup" and "creq" attributes in SDP, according to the procedures
defined in the SDP Capability Negotiation Framework [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>].
<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>. Title Capability</span>
SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] provides for the existence of an information field
expressed in the format of the "i=" line, which can appear at the SDP
session and/or media level. An "i=" line that is present at the
session level is known as the "session name", and its purpose is to
convey human-readable textual information about the session.
The "i=" line in SDP can also appear at the media level, in which
case it is used to provide human-readable information about the media
stream to which it is related; for example, it may indicate the
purpose of the media stream. The "i=" line is not to be confused
with the label attribute ("a=label:", [<a href="./rfc4574" title=""The Session Description Protocol (SDP) Label Attribute"">RFC4574</a>]), which provides a
machine-readable tag. It is foreseen that applications declaring
capabilities related to different configurations of a media stream
<span class="grey">Garcia-Martin, et al. Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
may need to provide different identifying information for each of
those configurations. That is, a party might offer alternative media
configurations for a stream, each of which represents a different
presentation of the same or similar information. For example, an
audio stream might offer English or Spanish configurations, or a
video stream might offer a choice of video source such as speaker
camera, group camera, or document viewer. The title capability is
needed to inform the answering user in order to select the proper
choice, and the label is used to inform the offering machine which
choice the answerer has selected. Hence, there is value in defining
a mechanism to provide titles of media streams as capabilities.
As defined in SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>], the session information field ("i=",
referred to as "title" in this document) is subject to the
"a=charset" attribute in order to support different character sets
and hence internationalization. The title capability attribute
itself ("a=icap") is, however, not subject to the "a=charset"
attribute as this would preclude the inclusion of alternative
session/title information each using different character sets.
Instead, the session/title value embedded in an "a=icap" attribute
(title capability) will be subject to the "a=charset" value used
within a configuration that includes that title capability. This
provides for consistent SDP operation while allowing for capabilities
and configurations with different session/title information values
with different character set encodings (with each such configuration
including an "a=charset" value with the relevant character set for
the session/title information in question).
According to SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>], the session information ("i=") line has
the following syntax:
"i=" text
where "text" represents a human-readable text indicating the purpose
of the session or media stream.
In this document, we define a new capability attribute: the title
capability "icap". This attribute lists session or media titles as
capabilities, according to the following definition:
"a=icap:" title-cap-num 1*WSP text
where <title-cap-num> is a unique integer within all the connection
capabilities in the entire SDP, which is used to identify the
particular title capability and can take a value between 1 and 2^31-1
(both included). <text> is a human-readable text that indicates the
purpose of the session or media stream it is supposed to
characterize.
<span class="grey">Garcia-Martin, et al. Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
As an example, one might use:
a=icap:1 Document Camera
to define a title capability number 1 to identify a particular source
of a media stream.
Or, in another example, one might offer two title capabilities with
different character encodings (using the charset attribute defined in
"SDP: Session Description Protocol" [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] and the generic
attribute capability attribute ("a=acap:") defined in "Session
Description Protocol (SDP) Capability Negotiation" [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>]).
a=icap:1 [Text encoded in ISO-8859-1]
a=acap:1 charset:ISO-8859-1
a=icap:2 [Text encoded in UTF-8]
a=acap:2 charset:UTF-8
NOTE: Due to limitations of the ASCII encoding of RFCs, the actual
text with non-printable characters cannot be represented in the text.
See the PDF format of this RFC for a figure with non-printable
characters.
The title capability attribute satisfies the general attribute
production rules in SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>], according to the following
Augmented Backus-Naur Form (ABNF) [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] syntax:
att-field =/ "icap"
att-value =/ title-cap-num 1*WSP text
; text defined in <a href="./rfc4566">RFC 4566</a>
title-cap-num = 1*10(DIGIT) ; DIGIT defined in <a href="./rfc5234">RFC 5234</a>
Figure 11: Syntax of the "icap" attribute
<span class="h5"><a class="selflink" id="section-3.1.3.1" href="#section-3.1.3.1">3.1.3.1</a>. Configuration Parameters</span>
The SDP Capability Negotiation Framework [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>] provides for the
existence of the "pcfg" and "acfg" attributes. The concept is
extended by the SDP Media Capabilities Negotiation [<a href="./rfc6871" title=""Session Description Protocol (SDP) Media Capabilities Negotiation"">RFC6871</a>] with an
"lcfg" attribute that conveys latent configurations.
<span class="grey">Garcia-Martin, et al. Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
In this document, we define a <title-config-list> parameter to be
used to convey title capabilities in a potential or latent
configuration. This parameter is defined as an
<extension-config-list> with the following associations:
ext-cap-name = "i"
ext-cap-list = title-cap-list
This leads to the following definition for the title capability
parameter:
extension-config-list =/ title-config-list
title-config-list = ["+"] "i=" title-cap-list
title-cap-list = title-cap-num *(BAR title-cap-num)
; BAR defined in <a href="./rfc5939">RFC 5939</a>
title-cap-num = 1*10(DIGIT) ; DIGIT defined in <a href="./rfc5234">RFC 5234</a>
Figure 12: Syntax of the title capability parameter
in "lcfg" and "pcfg" attributes
Each potential capability configuration contains a single title
capability attribute number where "title-cap-num" is the title
capability number defined explicitly earlier in this document, and
hence must be between 1 and 2^31-1 (both included). The title
capability allows the expression of only a single capability in each
alternative, since no more than a single-title field is permitted per
block. Nevertheless, it is still allowed to express alternative
potential title configurations separated by a vertical bar ("|").
An endpoint includes a plus sign ("+") in the configuration attribute
to mandate support for this extension. An endpoint that receives
this parameter prefixed with a plus sign and does not support this
extension MUST treat that potential configuration as not valid.
The title parameter to the actual configuration attribute ("a=acfg")
is formulated as a <sel-extension-config> with
ext-cap-name = "i"
hence
sel-extension-config =/ sel-title-config
sel-title-config = "i=" title-cap-num ; as defined above.
Figure 13: Syntax of the title parameter in "acfg" attributes
<span class="grey">Garcia-Martin, et al. Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
<span class="h5"><a class="selflink" id="section-3.1.3.2" href="#section-3.1.3.2">3.1.3.2</a>. Option Tag</span>
At present, it is difficult to envision a scenario in which the
"icap" attribute must be supported or the offer must be rejected. In
most cases, if the icap attribute or its contents were to be ignored,
an offered configuration could still be chosen based on other
criteria such as configuration numbering. However, one might imagine
an SDP offer that contained English and Spanish potential
configurations for an audio stream. The session might be
unintelligible if the choice is based on configuration numbering,
rather than informed user selection. Based on such considerations,
it may well prove useful to announce the ability to use the icap
attribute and its contents to select media configurations, or to
inform the user about the selected configuration(s). Therefore, we
define a new option tag of "icap-v0" that identifies support for the
title capability. This option tag SHOULD be added to other existing
option tags present in the "csup" and/or "creq" attributes in SDP,
according to the procedures defined in the SDP Capability Negotiation
Framework [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>]. The discussion above suggests that "icap-v0"
will typically appear in a "csup" attribute, but rarely in a "creq"
attribute.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Session Level versus Media Level</span>
The "bcap", "ccap", and "icap" attributes can appear at the SDP
session and/or media level. Endpoints MUST interpret capabilities
declared at session level as part of the session level in the
resulting SDP for that particular configuration. Endpoints MUST
interpret capabilities declared at media description as part of the
media level in the resulting SDP for that particular configuration.
The presence of the "bcap" capability for the same <bwtype> at both
the session and media level is subject to the same constraints and
restrictions specified in <a href="./rfc4566">RFC 4566</a> [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] for the bandwidth
attribute "b=".
To avoid confusion, the <type-attr-num> for each "a=bcap", "a=ccap",
and "a=icap" line MUST be unique across all capability attributes of
the same type within the entire session description.
<span class="grey">Garcia-Martin, et al. Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Offer/Answer Model Extensions</span>
In this section, we define extensions to the offer/answer model
defined in SDP Offer/Answer Model [<a href="./rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>] and extended in the SDP
Capability Negotiation [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>] to allow for bandwidth, connection,
and title capabilities to be used with the SDP Capability Negotiation
Framework.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Generating the Initial Offer</span>
When an endpoint generates an initial offer and wants to use the
functionality described in the current document, it first defines
appropriate values for the bandwidth, connection data, and/or title
capability attributes according to the rules defined in [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] for
"b=", "c=", and "i=" lines. The endpoint then MUST include the
respective capability attributes and associated values in the SDP
offer. The preferred configurations for each media stream are
identified following the media line in a "pcfg" attribute. Bandwidth
and title capabilities may also be referenced in latent
configurations in an "lcfg" attribute, as defined in the SDP Media
Capabilities Negotiation [<a href="./rfc6871" title=""Session Description Protocol (SDP) Media Capabilities Negotiation"">RFC6871</a>].
Implementations are advised to pay attention to the port number that
is used in the "m=" line. By default, a potential configuration that
includes a connection data capability will use the port number from
the "m=" line, unless the network type is "PSTN", in which case the
default port number used will be 9.
The offer SHOULD include the level of capability negotiation
extensions needed to support this functionality in a "creq"
attribute.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Generating the Answer</span>
When the answering party receives the offer, and if it supports the
required capability negotiation extensions, it SHOULD select the most
preferred configuration it can support for each media stream and
build the answer accordingly, as defined in <a href="#section-3.6.2">Section 3.6.2</a> of the SDP
Capability Negotiation [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>].
If the connection data capability is used in a selected potential
configuration chosen by the answerer, that offer configuration MUST
by default use the port number from the actual offer configuration
(i.e., the "m=" line), unless the network type is "PSTN", in which
case the default port MUST be assumed to be 9. Extensions may be
defined to negotiate the port number explicitly instead.
<span class="grey">Garcia-Martin, et al. Standards Track [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>. Offerer Processing of the Answer</span>
When the offerer receives the answer, it MUST process the media lines
according to normal SDP processing rules to identify the media
stream(s) accepted by the answer, if any, as defined in <a href="#section-3.6.3">Section 3.6.3</a>
of the SDP Capability Negotiation [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>]. The "acfg" attribute,
if present, MUST be used to verify the proposed configuration used to
form the answer and to infer the lack of acceptability of
higher-preference configurations that were not chosen.
<span class="h4"><a class="selflink" id="section-3.3.4" href="#section-3.3.4">3.3.4</a>. Modifying the Session</span>
If, at a later time, one of the parties wishes to modify the
operating parameters of a session, e.g., by adding a new media stream
or by changing the properties used on an existing stream, it may do
so via the mechanisms defined for SDP offer/answer [<a href="./rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>] and in
accordance with the procedures defined in <a href="#section-3.6.4">Section 3.6.4</a> of the SDP
Capability Negotiation [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Field Replacement Rules</span>
To simplify the construction of SDP records, given the need to
include fields within the media description in question for endpoints
that do not support capabilities negotiation, we define some simple
field-replacement rules for those fields invoked by potential or
latent configurations. In particular, any "i=" or "c=" lines invoked
by a configuration MUST replace the corresponding line, if present
within the media description in question. Any "b=" line invoked by a
configuration MUST replace any "b=" of the same bandwidth type at the
media level, but not at the session level.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This document provides an extension on top of the SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>], SDP
Offer/Answer Model [<a href="./rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>], SDP Capability Negotiation Framework
[<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>], and SDP Media Capabilities Negotiation [<a href="./rfc6871" title=""Session Description Protocol (SDP) Media Capabilities Negotiation"">RFC6871</a>]. As
such, the security considerations of those documents apply.
The bandwidth capability attribute may be used for reserving
resources at endpoints and intermediaries that inspect SDP.
Modification of the bandwidth value by an attacker can lead to the
network being underutilized (too high bandwidth value) or congested
(too low bandwidth value).
<span class="grey">Garcia-Martin, et al. Standards Track [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
Similarly, by modifying the alternative connection address(es), an
attacker would be able to direct media streams to a desired endpoint,
thus launching a version of the well-known voice hammer attack (see
<a href="./rfc5245#section-18.5.1">Section 18.5.1 of [RFC5245]</a>).
The title capability provides for alternative "i=" line information,
which is intended for human consumption. However, manipulating the
textual information could be misused to provide false information,
leading to a bad user experience or the person using the service
making a wrong choice regarding the available media streams.
In case it is essential to protect the capability attribute values,
one of the security mechanisms proposed in [<a href="./rfc5939" title=""Session Description Protocol (SDP) Capability Negotiation"">RFC5939</a>] SHOULD be used.
The "i=" line, and thus the value carried in the title capability
attribute, is intended for human-readable description only. It
should not be parsed programmatically.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. New SDP Attributes</span>
IANA has registered new attributes in the "att-field (both session
and media level)" subregistry of the "Session Description Protocol
(SDP) Parameters" registry, according to the following registration
form:
Attribute name: bcap
Long form name: Bandwidth Capability
Type of attribute: Both media and session level
Subject to charset: No
Purpose: Negotiate session or media-level bandwidths
Appropriate values: See <a href="./rfc7066#section-3.1.1">RFC 7066, Section 3.1.1</a>
Contact name: Miguel A. Garcia
[email protected]
Attribute name: ccap
Long form name: Connection Data Capability
Type of attribute: Both media and session level
Subject to charset: No
Purpose: Negotiate media-level connection data
Appropriate values: See <a href="./rfc7066#section-3.1.2">RFC 7066, Section 3.1.2</a>
Contact name: Miguel A. Garcia
[email protected]
<span class="grey">Garcia-Martin, et al. Standards Track [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
Attribute name: icap
Long form name: Title Capability
Type of attribute: Both media and session level
Subject to charset: Yes
Purpose: Negotiate human-readable information
describing the session or media
Appropriate values: See <a href="./rfc7066#section-3.1.3">RFC 7066, Section 3.1.3</a>
Contact name: Miguel A. Garcia
[email protected]
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. New Option Tags</span>
IANA has added the new option tags "bcap-v0", "ccap-v0", and "icap-
v0", defined herein, to the "SDP Capability Negotiation Option Tag"
subregistry of the "Session Description Protocol (SDP) Parameters"
registry.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. New SDP Capability Negotiation Configuration Parameters</span>
IANA has added the new parameter identifiers "b" for "Bandwidth", "c"
for "Connection Data", and "i" for "Title" to the "SDP Capability
Negotiation Configuration Parameters" subregistry of the "Session
Description Protocol (SDP) Parameters" registry. These parameters
are permitted in "lcfg", "acfg", and "pcfg" attributes.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgments</span>
Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson
for arguing for the existence of this document and reviewing it in
the early stages. Thanks to Flemming Andreasen, Andrew Allen, and
Jonathan Lennox for a detailed review and many suggestions for
improvement.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3264">RFC3264</a>] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", <a href="./rfc3264">RFC 3264</a>, June
2002.
[<a id="ref-RFC4566">RFC4566</a>] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", <a href="./rfc4566">RFC 4566</a>, July 2006.
<span class="grey">Garcia-Martin, et al. Standards Track [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008.
[<a id="ref-RFC5939">RFC5939</a>] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", <a href="./rfc5939">RFC 5939</a>, September 2010.
[<a id="ref-RFC6871">RFC6871</a>] Gilman, R., Even, R., and F. Andreasen, "Session
Description Protocol (SDP) Media Capabilities
Negotiation", <a href="./rfc6871">RFC 6871</a>, February 2013.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC3108">RFC3108</a>] Kumar, R. and M. Mostafa, "Conventions for the use of the
Session Description Protocol (SDP) for ATM Bearer
Connections", <a href="./rfc3108">RFC 3108</a>, May 2001.
[<a id="ref-RFC3550">RFC3550</a>] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, <a href="./rfc3550">RFC 3550</a>, July 2003.
[<a id="ref-RFC3711">RFC3711</a>] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
<a href="./rfc3711">RFC 3711</a>, March 2004.
[<a id="ref-RFC4574">RFC4574</a>] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", <a href="./rfc4574">RFC 4574</a>, August 2006.
[<a id="ref-RFC5245">RFC5245</a>] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", <a href="./rfc5245">RFC 5245</a>, April
2010.
[<a id="ref-SDP-CS">SDP-CS</a>] Garcia, M. and S. Veikkolainen, "Session Description
Protocol (SDP) Extension for Setting Audio and Video Media
Streams over Circuit-Switched Bearers in the Public
Switched Telephone Network (PSTN)", Work in Progress, June
2013.
<span class="grey">Garcia-Martin, et al. Standards Track [Page 21]</span><span id="page-22" ></span>
<span class="grey"><a href="./rfc7006">RFC 7006</a> SDP Misc. Capabilities Negotiation September 2013</span>
Authors' Addresses
Miguel A. Garcia-Martin
Ericsson
Calle Via de los Poblados 13
Madrid 28033
Spain
Phone: +34 91 339 1000
EMail: [email protected]
Simo Veikkolainen
Nokia
P.O. Box 226
NOKIA GROUP, FI 00045
Finland
Phone: +358 50 486 4463
EMail: [email protected]
Robert R. Gilman
3243 W. 11th Ave. Dr.
Broomfield, Colorado 80020
U.S.A.
Phone: +1 303 898 9780
EMail: [email protected]
Garcia-Martin, et al. Standards Track [Page 22]
Annotations
Select text to annotate