One document matched: draft-garcia-mmusic-sdp-misc-cap-01.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 category="std" ipr="noModificationTrust200902">
<front>
<title abbrev="Miscellaneous Capabilities in SDP">Miscellaneous
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="8" month="July" year="2009" />
<area>RAI</area>
<workgroup>MMUSIC WG</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</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 a number of miscellaneous SDP
capabilities. In particular, this memo provides a mechanism to
negotiate media titles ("i=" line for each media), connection
data ("c=" line), and media bandwidth ("b=" line).
</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="I-D.ietf-mmusic-sdp-capability-negotiation">capability
negotiation mechanism framework </xref> that allows the
endpoints to negotiate capabilities, such as support for <xref
target="RFC3550">Realtime Transport Protocol (RTP) </xref> and
<xref target="RFC3711">Secure Realtime 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>
This negotiation is embedded into the widely used <xref
target="RFC3264"> SDP offer/answer procedures </xref>. This
memo provides the means to negotiate further capabilities than
those specified in the <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation"> SDP
capability negotiation mechanism framework </xref> and the
<xref target="I-D.ietf-mmusic-sdp-media-capabilities"> SDP
media capabilities </xref>. In particular, this memo provides
a mechanism to negotiate media titles ("i="), connection data
("c="), and media bandwidth ("b="). 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 three 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. In particular, <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 information 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="I-D.ietf-mmusic-sdp-capability-negotiation">SDP
Capability Negotiation Framework </xref> and the <xref
target="I-D.ietf-mmusic-sdp-media-capabilities"> SDP media
capabilities </xref> specify attributes for negotiating SDP
capabilities. These documents specify new attributes (e.g.,
'acap', 'tcap', 'mcap') for achieving their purpose. In this
document we define a number of new additional capability
attributes for SDP lines of the the general form:
</t>
<t><list>
<t>type=value</t>
</list></t>
<t>
for types "i", "c", and "b". The corresponding
capability attributes are defined as "icap", "ccap", and
"bcap", respectively.
</t>
<t>
From the sub-rules of "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 defined in <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation"></xref>.</t>
<figure><artwork type="abnf">
extension-config-list = ["+"] ext-cap-name "="
ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT)
ext-cap-list = 1*VCHAR ; defined in [RFC4234]
</artwork></figure>
<t>The optional "+" is used to indicate that the entire
configuration, not just the parameter, must be ignored if the
parameter is not supported.
The attributes may be referenced in actual configurations as
productions conforming to the sel-extension-config defined in
<xref target="I-D.ietf-mmusic-sdp-capability-negotiation"></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>
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 information 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. For what it concerns this memo,
we focus on the bandwidth at the media level. This
bandwidth field is specified in <xref target="RFC4566">RFC
4566</xref> according to 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 ordinal identifier
of the bandwidth capability, and the other elements are as
defined for the "b=" field in <xref
target="RFC4566"></xref>.
</t>
<t>
This format satisfies the general attribute production rules in
<xref target="RFC4566"></xref> according to the following <xref target="RFC5234">
Augmented Backus-Naur Form (ABNF) </xref> syntax:
</t>
<figure><artwork type="abnf">
att-field = "bcap"
att-value = bw-cap-num 1*WSP bwtype ":" bandwidth
bw-cap-num = 1*DIGIT ; integer between 1 and 2^31-1, inclusive
</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="I-D.ietf-mmusic-sdp-capability-negotiation">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. 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 <xref
target="I-D.ietf-mmusic-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 b-cap-list)
bw-cap-list = bw-cap-num *("," b-cap-num)
bw-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive
</artwork>
</figure>
<t>
Each bandwidth capability configuration is a
comma-separated list of bandwidth capability attribute
numbers where 'b-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 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="I-D.ietf-mmusic-sdp-capability-negotiation">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
"bcap-v0" that identifies support for the bandwidth
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="I-D.ietf-mmusic-sdp-capability-negotiation">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, the only network type defined is "IN", which
indicates Internet network type. The address types "IP4" and
"IP6" indicate the type of IP addresses.
</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><artwork type="abnf">
att-field = "ccap"
att-value = conn-cap-num 1*WSP nettype SP addrtype
SP connection-address
conn-cap-num = 1*DIGIT ; integer between 1 and 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>
<section title="Configuration Parameters">
<t>
The <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation">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>
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="I-D.ietf-mmusic-sdp-capability-negotiation">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="I-D.ietf-mmusic-sdp-capability-negotiation">SDP
Capability Negotiation Framework </xref>.
</t>
</section>
</section>
<section anchor="sec-info-cap" title="Information Capability">
<!-- ################################################################ -->
<t>
<xref target="RFC4566">RFC 4566</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. We don't see much
usage of capabilities related to the "i=" line at the
session level.
</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 information field 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 information 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 information
of media streams as capabilities.
</t>
<t>
According to <xref target="RFC4566">SDP </xref>, the
media label 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 media stream.
</t>
<t>
In this document we define a new capability attribute: the
information media capability, "icap". This attribute
lists information media labels as capabilities, according
to the following definition:
</t>
<t><list>
<t>"a=icap:" info-cap-num 1*WSP text</t>
</list></t>
<t> where <info-cap-num> is the ordinal identifier of
the particular media information capability and <text>
is a human-readable text that indicates the purpose of the
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 represent a purpose of a media stream identified with
the capability number 1.</t>
<t>
The media information capability attribute satisfies the
general attribute production rules in <xref
target="RFC4566"></xref> according to the following <xref target="RFC5234">
Augmented Backus-Naur Form (ABNF) </xref> syntax:
</t>
<figure><artwork type="abnf">
att-field = "icap"
att-value = info-cap-num 1*WSP text
; text is defined in RFC 4566
info-cap-num = 1*DIGIT ; integer between 1 and 2^31-1
</artwork></figure>
<section title="Configuration Parameters">
<t>
The <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation">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 an <info-config-list>
parameter to be used to convey information 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 = info-cap-list</t>
</list></t>
<t>
This leads to the following definition for the information capability
parameter:
</t>
<figure anchor="fig-info-cfg-syntax"
title="Syntax of the information capability parameter in lcfg and pcfg attributes">
<artwork type="abnf">
extension-config-list = info-config-list
info-config-list = "i=" info-cap-list
info-cap-list = info-cap-num *(BAR info-cap-num)
info-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive
; BAR defined in SDP capabilities
; negotiation
</artwork>
</figure>
<t>
Each potential capability configuration contains a
single information capability attribute number where
'info-cap-num' is the information
capability number defined explicitly earlier in this
document, and hence must be between 1 and 2^31-1 (both
included). The information capability allows the
expression of only a single capability in each alternative,
since no more than a
single information field is permitted per media
block. Nevertheless, it is still allowed to express
alternative potential information configurations
separated by a vertical bar ("|").
</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 media information
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="I-D.ietf-mmusic-sdp-capability-negotiation">SDP
Capability Negotiation Framework </xref>. The discusion
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 icap, ccap, and bcap attributes can appear at
the session level and/or at the media level, but MUST be
interpreted as a media-level capability. To avoid
confusion, the <type-attr-num> for each line must be
unique across all capability attributes of the same type
within the entire session description. As described
below, these capability attributes may be referenced by
acfg, pcfg and/or lcfg attributes.
</t>
</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 at the base level 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-field or c-field invoked by a
configuration MUST replace the corresponding field, if
present at the base media level. Any b-field invoked by
a configuration MUST replace any b-field 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 the following new SDP
attributes:
</t>
<!-- Are these attribute really "session and media level"? -->
<!-- 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).
-->
<t><list>
<t>Attribute name: icap</t>
<t>Long form name: Information Capability</t>
<t>Type of attribute: Media-level</t>
<t>Subject to charset: Yes</t>
<t>Purpose: Negotiate human-readable media information</t>
<t>Appropriate values: See <xref target="sec-info-cap"></xref></t>
<t>Attribute name: ccap</t>
<t>Long form name: Connection Data Capability</t>
<t>Type of attribute: Media-level</t>
<t>Subject to charset: No</t>
<t>Purpose: Negotiate media-level connection data</t>
<t>Appropriate values: See <xref target="sec-conn-cap"></xref></t>
<t>Attribute name: bcap</t>
<t>Long form name: Bandwidth Capability</t>
<t>Type of attribute: Media-level</t>
<t>Subject to charset: No</t>
<t>Purpose: Negotiate media-level bandwidths</t>
<t>Appropriate values: See <xref target="sec-bw-cap"></xref></t>
</list></t>
</section>
<section anchor="sec-iana-opt" title="New Option Tags">
<t>
IANA is hereby requested to add the new option tags
"ccap-v0", "icap-v0", and "bcap-v0", defined herein, to the SDP
Capability Negotiation Option Tag Registry.
</t>
</section>
<section anchor="sec-iana-parm" title="New SDP Capability Negotiation
Configuration Parameters">
IANA is hereby requested to add the new parameter identifiers
"i" for "information", "c" for "connection data", and "b" for
"bandwidth" to the Potential Configuration Parameter Registry.
These parameters are permitted in 'lcfg', 'acfg', and 'pcfg'
attributes.
</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="I-D.ietf-mmusic-sdp-capability-negotiation">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>
</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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-mmusic-sdp-capability-negotiation" ?>
<?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.I-D.ietf-mmusic-ice" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:29:17 |