One document matched: draft-ietf-mmusic-sdp-miscellaneous-caps-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc sortrefs="yes"?>
<?rfc linkmailto="no"?>
<?rfc strict="no"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<rfc ipr="pre5378Trust200902" category="std">
<front>
<title abbrev="SDP Misc. Capabilities Negotiation">
Miscellanoues Capabilities Negotiation in the Session
Description Protocol (SDP)
</title>
<author fullname="Miguel A. Garcia-Martin" initials="M"
surname="Garcia-Martin">
<organization>Ericsson</organization>
<address>
<postal>
<street>Calle Via de los Poblados 13</street>
<city>Madrid</city>
<region></region>
<code>28033</code>
<country>Spain</country>
</postal>
<phone>+34 91 339 1000</phone>
<email>miguel.a.garcia@ericsson.com</email>
</address>
</author>
<author fullname="Simo Veikkolainen" initials="S" surname="Veikkolainen">
<organization>Nokia</organization>
<address>
<postal>
<street>P.O. Box 407</street>
<city>NOKIA GROUP</city>
<region>FI</region>
<code>00045</code>
<country>Finland</country>
</postal>
<phone>+358 50 486 4463</phone>
<email>simo.veikkolainen@nokia.com</email>
</address>
</author>
<author fullname="Robert R. Gilman" initials="R." surname="Gilman">
<organization></organization>
<address>
<postal>
<street>3243 W. 11th Ave. Dr.</street>
<city>Broomfield</city>
<region>Colorado</region>
<code>80020</code>
<country>U.S.A.</country>
</postal>
<phone>+1 303 898 9780</phone>
<email>bob_gilman@comcast.net</email>
</address>
</author>
<date day="14" month="October" year="2012" />
<area>RAI</area>
<workgroup>MMUSIC WG</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-raft</keyword>
<keyword>sdp capability negotiation</keyword>
<abstract>
<t>
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.
</t>
<t>
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 titles ('i=' line for each session or media).
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
The <xref target="RFC4566">Session Description Protocol
(SDP)</xref> 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 a <xref target="RFC5939">capability negotiation
mechanism framework </xref> which allows the endpoints to
negotiate capabilities, such as support for <xref
target="RFC3550">Real-time Transport Protocol (RTP) </xref>
and <xref target="RFC3711">Secure Real-time Transport Protocol
(SRTP) </xref>. The <xref
target="I-D.ietf-mmusic-sdp-media-capabilities">SDP media
capabilities </xref> provides negotiation capabilities to
media lines as well.
</t>
<t>
The capability negotiation is embedded into the widely used
<xref target="RFC3264"> SDP offer/answer procedure
</xref>. This memo provides the means to negotiate further
capabilities than those specified in the <xref
target="RFC5939"> SDP capability negotiation mechanism
framework </xref> and the <xref
target="I-D.ietf-mmusic-sdp-media-capabilities"> SDP media
capabilities negotiation</xref>. In particular, this memo provides a
mechanism to negotiate bandwidth
('b='), connection data ('c='), and session or media titles ('i=').
</t>
<!--
<t>
It would have been possible to define a mechanism to
negotiate media encryption keys ("k="). However, the usage of
the media encryption keys ("k=") is highly discouraged in
favour of other existing more sophisticated
mechanisms. Therefore, we are not providing a mechanism to
provide capabilities for media encryption keys ("k=") at this
stage.
</t>
-->
<t>
Since the three added capabilities are highly unconnected, it is
not expected that implementations will support all of them at the
same time. Instead, it is expected that applications will
choose their needed capability for their specific purpose. Due
to this, we are writing the normative part pertaining to each
capability in a self-contained section: <xref
target="sec-bw-cap"/> describes the bandwidth capability
extension, <xref target="sec-conn-cap"/> describes the
connection data capability extension, and <xref
target="sec-info-cap"/> describes the title capability
extension. Separate option tags are defined for each
capability.
</t>
</section>
<section anchor="sec-conventions"
title="Conventions Used in This Document">
<t>
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 BCP 14, <xref target="RFC2119">RFC 2119</xref> and indicate
requirement levels for compliant implementations.
</t>
</section>
<section anchor="sec-protocol-description" title="Protocol Description">
<section anchor="sec-sdp-extensions" title="Extensions to SDP">
<t>
The <xref target="RFC5939">SDP Capability Negotiation
Framework </xref> and the <xref
target="I-D.ietf-mmusic-sdp-media-capabilities"> SDP media
capabilities negotiation</xref> specify attributes for negotiating SDP
capabilities. These documents specify new attributes (e.g.,
'acap', 'tcap', 'rmcap', 'omcap') for achieving their purpose. In this
document we define three new additional capability attributes
for SDP lines of the the general form:
</t>
<t><list>
<t>type=value</t>
</list></t>
<t>
for types 'b', 'c', and 'i'. The corresponding
capability attributes are respectively defined defined as:
</t>
<t>
<list style="symbols">
<t>'bcap': bandwidth capability</t>
<t>'ccap': connection data capability</t>
<t>'icap': title capability</t>
</list>
</t>
<t>
From the sub-rules of attribute ('a=') line in <xref
target="RFC4566">SDP</xref>, SDP attributes are of the
form:</t>
<figure><artwork type="abnf">
attribute = (att-field ":" att-value) / att-field
att-field = token
att-value = byte-string
</artwork></figure>
<t>
Capability attributes use only the 'att-field:att-value'
form.
</t>
<t>
The new attributes 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 <xref
target="RFC5939">RFC 5939</xref> and <xref
target="I-D.ietf-mmusic-sdp-media-capabilities">the SDP media
capabilities specification</xref>.
</t>
<figure><artwork type="abnf">
extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT)
; ALPHA and DIGIT defined in RFC 5234
ext-cap-list = 1*VCHAR ; VCHAR defined in RFC 5234
</artwork></figure>
<t>
The optional "+" is used to indicate that the extension is
mandatory and MUST be supported in order to use that
potential configuration.
</t>
<t>
The new attributes may also be referenced in actual configurations
('a=acfg') as productions conforming to the
<sel-extension-config> defined in <xref
target="RFC5939"></xref>.
</t>
<figure><artwork type="abnf">
sel-extension-config = ext-cap-name "=" 1*VCHAR
</artwork></figure>
<t>
The specific parameters are defined in the individual description
of each capability, below.
</t>
<t>
The 'bcap', 'ccap', and 'icap' capability attributes can be provided
either at the session or media level. According to <xref
target="RFC5939">the SDP Capability Negotiation</xref>, each
extension capability must specify the implication of making
it part of a configuration at the media level.
</t>
<t>
According to <xref target="RFC4566">SDP</xref>, 'b=', 'c=',
and 'i=' lines may appear either at 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.
</t>
<t>
For example, extending the example in <xref
target="I-D.ietf-mmusic-sdp-media-capabilities"/> with
'icap' and 'bcap' capability attributes, we get the
following SDP:
</t>
<figure title="Example SDP offer with bcap and icap defined at
session level" anchor="example-1"><artwork type="ABNF">
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,4 H263-1998/90000
a=rtpmap:100 H264/90000
a=pcfg:10 m=3 pt=3:101 b=1 i=1
</artwork></figure>
<t>
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 L16 audio at
8 kbps and 16 kbps, respectively, as well as two RTP-based
media capabilities for H.263 video ('rmcap' numbered 3 and
4). 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).
</t>
<!--
<t>
The 'icap' and 'bcap' capability attributes MUST appear only
at the media level. Hence, bandwidth and media title
capabilities referenced by any configuration attribute MUST
be interpreted as media level attributes. (For this reason,
we call the 'icap' attribute the "media title capability"
instead of "session title capability").
</t>
-->
<!--
<t>
It is not the intention of this work to negotiate these new
capabilities at the session level, rather only at the media
level. Therefore, capabilities referenced by any
configuration attribute MUST appear at the media level when
a configuration is "converted" to a corresponding media
block. For this reason, the 'icap' attribute is called the
"media title capability". Specific values for each new
attribute are described below.
</t>
-->
<section anchor="sec-bw-cap" title="Bandwidth Capability">
<!-- ################################################################ -->
<t>
According to <xref target="RFC4566">RFC 4566</xref> 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
either at session or media level. The bandwidth field is
specified in <xref target="RFC4566">RFC 4566</xref> with
the following syntax:
</t>
<t><list>
<t>b=<bwtype>:<bandwidth></t>
</list></t>
<t>
where <bwtype> is an alphanumeric modifier giving
the meaning of the <bandwidth> figure.
</t>
<t>
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:
</t>
<t><list>
<t>"a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF</t>
</list></t>
<t>
where <bw-cap-num> is a unique integer between 1 and
2^31-1 (both included) user to number the bandwidth
capability, and the other elements are as defined for the
'b=' field in <xref target="RFC4566">SDP</xref>.
</t>
<t>
This format satisfies the general attribute production
rules in <xref target="RFC4566">SDP</xref> according to the
following <xref target="RFC5234"> Augmented Backus-Naur
Form (ABNF) </xref> syntax:
</t>
<figure anchor="bcap-syntax" title="Syntax of the bcap attribute"><artwork type="abnf">
att-field =/ "bcap"
att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
</artwork></figure>
<t>
Negotiation of bandwidth per media stream can be useful
when negotiating media encoding capabilities with
different bandwidths.
</t>
<section title="Configuration Parameters">
<t>
The <xref target="RFC5939">SDP capability negotiation
framework</xref> provides for the existence of the
'pcfg' and 'acfg' attributes. The concept is extended by
the <xref
target="I-D.ietf-mmusic-sdp-media-capabilities"> SDP
media capabilities negotiation</xref> with an 'lcfg'
attribute that conveys latent configurations.
</t>
<t>
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 <xref
target="RFC5939">SDP Capability Negotiation</xref>.
</t>
<t>
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
<xref target="RFC5234">Augmented Backus-Naur Form
(ABNF)</xref> syntax:
</t>
<figure anchor="fig-pot-cfg-bw-syntax"
title="Syntax of the bandwidth parameter in 'lcfg' and 'pcfg' attributes">
<artwork type="abnf">
extension-config-list =/ bandwidth-config-list
bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR bw-cap-list)
; BAR defined in RFC 5939
bw-cap-list = bw-cap-num *("," bw-cap-num)
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
</artwork>
</figure>
<t>
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 ("|").
</t>
<t>
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 <xref target="RFC4566">SDP</xref> either.
</t>
<t>
The bandwidth parameter to the actual configuration
attribute ('a=acfg') is formulated as a
<sel-extension-config> with
</t>
<t>
<list>
<t>ext-cap-name = "b"</t>
</list>
</t>
<t>hence
<figure anchor="fig-act-cfg-bw-syntax"
title="Syntax of the bandwidth parameter in 'acfg' attributes">
<artwork type="abnf">
sel-extension-config =/ sel-bandwidth-config
sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above.
</artwork>
</figure>
</t>
</section>
<section title="Option tag">
<t>
The <xref target="RFC5939">SDP Capability Negotiation
Framework</xref> 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 <xref
target="RFC5939">SDP Capability Negotiation Framework
</xref>.
</t>
</section>
</section>
<section anchor="sec-conn-cap" title="Connection Data Capability">
<!-- ################################################################## -->
<t>
According to <xref target="RFC4566">SDP</xref>, the
connection data field in SDP contains the connection
data, and it has the following syntax:
</t>
<t><list>
<t>
c=<nettype> <addrtype> <connection-address>
</t>
</list></t>
<t>
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.
</t>
<t>
At the moment, network types already defined include "IN",
which indicates Internet network type, and "ATM" (see
<xref target="RFC3108">RFC 3108 </xref>), used for
describing Asynchronous Transfer Mode (ATM) bearer
connections. The <xref
target="I-D.ietf-mmusic-sdp-cs">Circuit-Switched (CS)
descriptions in SDP document </xref> adds a "PSTN" network
type for expressing a Public Switched Telephone Network
(PSTN) circuit switch.
</t>
<t>
<xref target="RFC4566">SDP</xref> permits specification of
connection data at the session or at the 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:</t>
<t><list>
<t>"a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP connection-address CRLF</t>
</list></t>
<t>
where <conn-cap-num> is a unique ordinal identifier of the connection
data capability, and the other elements are as defined in
<xref target="RFC4566"></xref>.
</t>
<t>
This format corresponds to the <xref target="RFC4566"></xref> attribute
production rules according to the following <xref target="RFC5234">
Augmented Backus-Naur Form (ABNF) </xref> syntax:
</t>
<figure anchor="ccap-syntax" title="Syntax of the ccap attribute"><artwork type="abnf" >
att-field =/ "ccap"
att-value =/ conn-cap-num 1*WSP nettype SP addrtype
SP connection-address
conn-cap-num = 1*DIGIT ; 1 to 2^31-1, inclusive
</artwork></figure>
<!--
<t>
The connection information capability can be used to
negotiate the use of IPv4 or IPv6 addresses without resort
to <xref target="I-D.ietf-mmusic-ice">Interactive
Connectivity Establishment(ICE)</xref>. Note, however,
that ICE provides for real-time reachability testing of
multiple addresses, whereas use of the connection
capability forces an early choice of connection address.
</t>
-->
<t>
The 'ccap' capability attribute allows for expressing
alternative connection address ('c=') lines in SDP as
part of the SDP capability negotiation process. The
'ccap' capability attribute is intended to be used only
when there is no other mechanism available for
negotiating alternative connection address information,
such as when the <nettype> is different among the
alternative addresses. The 'ccap' attribute MUST NOT be
used in situations where an existing mechanism (such as
<xref target="RFC5245">Interactive Connectivity
Establishment (ICE)</xref>) can be used to select
between different connection addresses.
</t>
<section title="Configuration Parameters">
<t>
The <xref
target="RFC5939">SDP
Capability Negotiation Framework</xref> provides for the
existence of the 'pcfg' and 'acfg' attributes, which can
carry one or more potential configurations to be
negotiated. The concept is extended by the the <xref
target="I-D.ietf-mmusic-sdp-media-capabilities"> Media
Capabilities Negotiation</xref> with an 'lcfg' attribute
that conveys latent configurations.
</t>
<t>
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
</t>
<t><list>
<t>ext-cap-name = "c"</t>
<t>ext-cap-list = conn-cap-list</t>
</list></t>
<t>where, according to the following <xref target="RFC5234">
Augmented Backus-Naur Form (ABNF) </xref> syntax:
</t>
<figure anchor="fig-pot-cfg-c-syntax"
title="Syntax of the connection data parameter in
'lcfg' and 'pcfg' attributes">
<artwork type="abnf">
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*DIGIT ; 1 to 2^32-1 inclusive
</artwork>
</figure>
<t>
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, and hence 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 permitted per media
block. Nevertheless, it is still allowed to express
alternative potential connection configurations
separated by a vertical bar ("|").
</t>
<t>
An endpoint includes a plus sign ("+") in this
configuration attribute to mandate support for this
extension. An endpoint that receives this attribute
prefixed with a plus sign and does not support this
extension MUST treat that potential configuration as not
valid.
</t>
<t>
The connection data parameter to the actual configuration
attribute ('a=acfg') is formulated as a
<sel-extension-config> with
</t>
<t><list>
<t>ext-cap-name = "c"</t>
</list></t>
<t>
hence
<figure anchor="fig-act-cfg-conn-syntax"
title="Syntax of the connection data parameter in 'acfg' attributes">
<artwork type="abnf">
sel-extension-config =/ sel-connection-config
sel-connection-config = "c=" conn-cap-num ; as defined above.
</artwork>
</figure>
</t>
</section>
<section title="Option tag">
<t>
The <xref
target="RFC5939">SDP
Capability Negotiation Framework</xref> 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 <xref
target="RFC5939">SDP
Capability Negotiation Framework </xref>.
</t>
</section>
</section>
<section anchor="sec-info-cap" title="Title Capability">
<!-- ################################################################ -->
<t>
<xref target="RFC4566">SDP</xref> provides for the
existence of an information field expressed in the format
of the 'i=' line, which can appear either at the
session level or at the media level. An 'i=' line that is
present at the session level is known as the "session
name", and its purpose is to convey a human-readable
textual information about the session.
</t>
<t>
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,
e.g., it may indicate the purpose of the media stream.
The 'i=' line is not to be confused with the label
attribute ('a=label:', <xref target="RFC4574"> </xref>)
which provides a machine-readable tag. It is foreseen
that applications declaring capabilities related to
different configurations of a media stream 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.
</t>
<t>
According to <xref target="RFC4566">SDP</xref>, the
session information ('i=') line has the following syntax:
</t>
<t><list>
<t>"i=" text</t>
</list></t>
<t>
where "text" represents a human-readable text indicating
the purpose of the session or media stream.
</t>
<t>
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:
</t>
<t><list>
<t>"a=icap:" title-cap-num 1*WSP text</t>
</list></t>
<t> where <title-cap-num> is a unique integer between
1 and 2^31-1 (both included) user to number the unique
ordinal identifier of the particular title capability
and <text> is a human-readable text that indicates the
purpose of the session or media stream it is supposed to
characterize.</t>
<t>As an example, one might use:</t>
<t><list>
<t>a=icap:1 Document Camera</t>
</list></t>
<t>
to define a title capability number 1 to identify a
particular source of a media stream.
</t>
<t>
The title capability attribute satisfies the
general attribute production rules in <xref
target="RFC4566">SDP</xref> according to the following <xref
target="RFC5234"> Augmented Backus-Naur Form (ABNF)
</xref> syntax:
</t>
<figure anchor="icap-syntax" title="Syntax of the icap attribute"><artwork type="abnf" >
att-field =/ "icap"
att-value =/ title-cap-num 1*WSP text
; text defined in RFC 4566
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
</artwork></figure>
<section title="Configuration Parameters">
<t>
The <xref target="RFC5939">SDP Capability Negotiation
Framework</xref> provides for the existence of the
'pcfg' and 'acfg' attributes. The concept is extended by
the <xref
target="I-D.ietf-mmusic-sdp-media-capabilities"> SDP
media capabilities negotiation</xref> with an 'lcfg'
attribute that conveys latent configurations.
</t>
<t>
In this document, we define an <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:
</t>
<t>
<list>
<t>ext-cap-name = "i"</t>
<t>ext-cap-list = title-cap-list</t>
</list>
</t>
<t>
This leads to the following definition for the title
capability parameter:
</t>
<figure anchor="fig-info-cfg-syntax"
title="Syntax of the title capability
parameter in 'lcfg' and 'pcfg' attributes">
<artwork type="abnf">
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 RFC 5939
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
</artwork>
</figure>
<t>
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 ("|").
</t>
<t>
An endpoint includes a plus sign ("+") in this
configuration attribute to mandate support for this
extension. An endpoint that receives this attribute
prefixed with a plus sign and does not support this
extension MUST treat that potential configuration as not
valid.
</t>
<t>
The title parameter to the actual configuration attribute
('a=acfg') is formulated as a <sel-extension-config> with</t>
<t><list>
<t>ext-cap-name = "i"</t>
</list></t>
<t>hence
<figure anchor="fig-act-cfg-title-syntax"
title="Syntax of the title parameter in 'acfg' attributes">
<artwork type="abnf">
sel-extension-config =/ sel-title-config
sel-title-config = "i=" title-cap-num ; as defined above.
</artwork>
</figure>
</t>
</section>
<section title="Option Tag">
<t>
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 <xref target="RFC5939">SDP
Capability Negotiation Framework </xref>. The discussion
above suggests that "icap-v0" will typically appear in a
'csup' attribute, but rarely in a 'creq' attribute.
</t>
</section>
</section>
</section>
<section title="Session Level versus Media Level"
anchor="sec-session-media-level">
<t>
The 'bcap', 'ccap' and 'icap' attributes can appear at the
session level and/or at the 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 level as part of the media level in the
resulting SDP for that particular configuration.
</t>
<t>
If a 'bcap' capability for the same
bwtype is declared at both session and media level, the
media level attribute overrides the value of the session
level attribute.
</t>
<t>
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.
</t>
</section>
<section title="Offer/Answer model extensions" anchor="sec-offer-answer-extensions">
<t>
In this section, we define extensions to the offer/answer
model defined in <xref target="RFC3264">SDP Offer/Answer
Model</xref> and extended in <xref target="RFC5939">the SDP
Capability Negotiation</xref> to allow for bandwidth and
title capabilities to be used with the SDP Capability
Negotiation framework.
</t>
<section title="Generating the Initial Offer">
<t>
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 rules defined in <xref target="RFC4566"/> 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, defined in <xref target="RFC5939"/>.
</t>
<t>
The offer SHOULD include the level of capability negotiation
extensions needed to support this functionality in a
'creq' attribute.
</t>
</section>
<section title="Generating the Answer">
<t>
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 Section 3.6.2 of <xref
target="RFC5939">the SDP Capability Negotiation</xref>.
</t>
</section>
<section title="Offerer Processing of the Answer">
<t>
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. The 'acfg' attribute, if present, may 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.
</t>
</section>
<section title="Modifying the Session">
<t>
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 <xref target="RFC3264">SDP offer/answer</xref>.
</t>
</section>
</section>
</section>
<section anchor="sec-replace-rules" title="Field Replacement Rules">
<t>
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=' line 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.
</t>
</section>
<section anchor="sec-iana" title="IANA Considerations">
<section anchor="sec-iana-attr" title="New SDP Attributes">
<t>
IANA is hereby requested to register new attributes in the
"att-field (both session and media level)" of the "Session
Description Protocol (SDP) Parameteres" registry, according
to the following registration form:
</t>
<!-- Are these attribute really "session and media level"? -->
<!-- rrg: yes -->
<!-- Check if icap is subject to charset -->
<!-- rrg: the i-field is, so the icap attribute should be as well, I'd think.
Things could get interesting if both "a=icap:nn" and "a=acap:nn charset"
are negotiated! -->
<!-- Do we need to register something related to the potential
configuration? -->
<!-- rrg: yes we do!, and I overlooked this in the SDPMedCapNeg draft,
so I'll go back and see what needs to be done. I think it would
be most simple to add all parameter names to one list, but there
is one parameter (mt) that's unique to the lcfg attribute. Everything
else is common to all: pcfg, acfg, lcfg). -->
<figure><artwork type="abnf">
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 RFC XXXX
[Note to the RFC Editor: Please replace the above RFC XXXX
with the RFC number of this specification.
Contact name: Miguel A. Garcia,
Miguel.A.Garcia@ericsson.com
</artwork></figure>
<figure><artwork type="abnf">
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 RFC XXXX
[Note to the RFC Editor: Please replace the above RFC XXXX
with the RFC number of this specification.
Contact name: Miguel A. Garcia,
Miguel.A.Garcia@ericsson.com
</artwork></figure>
<figure><artwork type="abnf">
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 RFC XXXX
[Note to the RFC Editor: Please replace the above RFC XXXX
with the RFC number of this specification.
Contact name: Miguel A. Garcia,
Miguel.A.Garcia@ericsson.com
</artwork></figure>
</section>
<section anchor="sec-iana-opt" title="New Option Tags">
<t>
IANA is hereby requested to add 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.
</t>
</section>
<section anchor="sec-iana-parm" title="New SDP Capability Negotiation
Configuration Parameters">
<t>
IANA is hereby requested to add the new parameter identifiers
"b" for "bandwidth", "c" for "connection data", and "i" for
"title" to the "SDP Capability Negotiation Potential
Configuration Parameters" subregistry of the "Session
Description Protocol (SDP) Parameters" registry. These
parameters are permitted in 'lcfg', 'acfg', and 'pcfg'
attributes.
</t>
</section>
</section>
<section anchor="sec-security" title="Security Considerations">
<t>
This document provides an extension on top of <xref
target="RFC4566">RFC 4566 </xref>, <xref target="RFC3264">RFC
3264 </xref>, <xref target="RFC5939">SDP Capability
Negotiation Framework</xref>, and <xref
target="I-D.ietf-mmusic-sdp-media-capabilities">SDP media
capabilities negotiation</xref>. As such, the security
considerations of those documents apply.
</t>
<t>
The bandwidth capability attribute may be used for reserving
resources at endpoints and intermediaries which inspect the
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). In case it is
essential to protect the bandwidth value, one of the security
mechanisms proposed in <xref target="RFC5939"/> should be used.
</t>
<t>
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.
</t>
</section>
<section anchor="sec-acks" title="Acknowledgments">
<t>
Thanks to Christer Holmberg, Alf Heidermark, and Ingemar
Johansson for arguing for the existence of this document and
early reviewing it. Thanks to Flemming Andreasen, Andrew
Allen, and Jonathan Lennox for a detailed review and many
improvement suggestions.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.5939" ?>
<?rfc include="reference.I-D.ietf-mmusic-sdp-media-capabilities"
?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3264" ?>
<?rfc include="reference.RFC.4566" ?>
<?rfc include="reference.RFC.5234" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3550" ?>
<?rfc include="reference.RFC.3711" ?>
<?rfc include="reference.RFC.4574" ?>
<?rfc include="reference.RFC.5245" ?>
<?rfc include="reference.RFC.3108" ?>
<?rfc include="reference.I-D.ietf-mmusic-sdp-cs" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:59:24 |