One document matched: draft-garcia-mmusic-sdp-misc-cap-00.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="full3978">
<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>NDCI</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="27" month="October" year="2008" />
<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>
<!-- rrg: removed
<t>
In addition, we define extensions to the potential
configuration ("a=pcfg"), actual configuration ("a=acfg"),
and latent configuration ("a=lcfg") attributes necessary to
reference the new capabilities.
</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>
<!-- Simo: duplicate text, this was mentioned already above
<t>
Extensions are also defined for the potential configuration
("a=pcfg") and actual configuration ("a=acfg") attributes
defined in <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation">SDP
Capability Negotiation Framework</xref>
and extended in <xref
target="I-D.ietf-mmusic-sdp-media-capabilities">SDP Media
Capabilities Negotiation</xref>, and for the latent
configuration (a="lcfg") introduced in <xref
target="I-D.ietf-mmusic-sdp-media-capabilities"></xref>.
</t>
-->
<!-- Miguel: We need to rephrase the following sentence and put it
into active format.
-->
<!-- Following text removed: now we have an option tag per bcap and
ccap attributes
<t>
Use of the features described herein MUST be indicated by
including the option tag "mcap-v0" in a "a=creq" and
"a=csup" attributes, as described in <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation"></xref>.
Support for "mcap-v0" implies support for "cap-v0". For
example, an SDP record that supports media capability
negotiation, but requires the miscellaneous capabilties,
would include the following lines at the session level:
</t>
<t><list>
<t>a=csup:med-v0</t>
<t>a=creq:mcap-v0</t>
</list></t>
<t><list style="hanging">
<t>OPEN ISSUE: It is not clear what is the exact semantic of
this option tag. Does it express support for each of these
unconnected attributes? What is the use case for requiring
the support of the option tag?
</t>
</list></t>
-->
<!-- In a conversation with Flemming, he clarified the use of the
extension-type lists (it applies to everything not defined in SDPCapNeg.)
With the individual option tags, I think your issue above is moot - if
not, let's talk.
-->
<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>
<!-- rrg: deleted
<t>
The potential configuration attribute, "a=pcfg" is
originally defined in the <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation">SDP
Capabilities Negotiation Framework</xref>, according to
which the 'pcfg' attribute has the following definition:
</t>
<t><list>
<t>a=pcfg: <config-number> [<pot-cfg-list>]</t>
<t>pot-cfg-list =
</list></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>
<!-- rrg: the following is redundant (and partially incorrect)
<t>
In this document we define a new capability attribute: the
connection address capability attribute, "a=ccap". The
connection address capability lists connection addresses
as capabilities, and is defined as follows:
</t>
<t>
<list>
<t>a=ccap:<c-cap-num> <c-cap-attr></t>
</list>
</t>
<t>
where <c-cap-num> is an integer between 1 and 2^31-1
(both included) used to number the connection address
capability attribute.
</t>
<t>
The <c-cap-attr> field consists of network
type, address type and a connection address, as specified for
a "c=" line in <xref target="RFC4566">SDP</xref>.
</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>
<!-- rrg: deleted
<t>
The potential configuration attribute, "a=pcfg" is
originally defined in the <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation">SDP
Capabilities Negotiation Framework</xref>, according to
which the 'pcfg' attribute has the following definition:
</t>
<t><list>
<t>a=pcfg: <config-number> [<pot-cfg-list>]</t>
</list></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">
<!-- ################################################################ -->
<!-- First, let's add a background introduction on the i= line in SDP -->
<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 label the media stream it is
related to, so that it indicates the purpose of the media
stream. In this case, it is foreseen that applications
declaring capabilities related to different media lines
also need to provide different labels to media streams
that are substantially different. For example, if two
media streams are offered one as alternative to the other,
most likely their associated labels are different. Hence,
there is value in defining a mechanism to provide labels
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>
<!-- rrg: I used info-cap-num everywhere and got rid of title-cap-num -->
<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>
<!-- rrg: delete the following as redundant.
<t>
The potential configuration attribute, "a=pcfg" is
originally defined in the <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation">SDP
Capabilities Negotiation Framework</xref>, according to
which the 'pcfg' attribute has the following definition:
</t>
<t><list>
<t>a=pcfg: <config-number> [<pot-cfg-list>]</t>
</list></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">
<!-- rrg: I think the following argument is incorrect. For example,
a party might offer a list of media streams as latent configurations,
each with it's own descriptive information, and a list of acceptable
session capabilities or media stream combinations (via "a=sescap").
Perhaps the the latent configurations represent alternative media
streams within the session. It may be up to the other user to
select the stream it wants to use. Examples might be audio feeds
from microphones located at various points, or cameras focused on
various locations or objects. In these cases, the receiver must
be able to process the icap attribute, or it couldn't give its user
the proper info to make a selection. In any case, it doesn't hurt
a thing to define an option for icap.
-->
<t>
The information field ("i=") in SDP, rather than
providing information for a software application,
provides information for a human user. Therefore, it is
questionable whether the text in the information field
or the information capability is relevant for
negotiating SDP capabilities. In particular, unlike the
bandwidth and the connection data capabilities, there
are no compelling use cases that hint for the
definition of an option tag for the information
capability. This is because it is not expected that an
endpoint would declare that the negotiation should fail
if the information field (which is for human
consumption) is not understood. As a consequence, we do
not define an option tag associated to the information
capability.
</t>
</section>
</section>
</section>
<section title="Session Level versus Media Level"
anchor="sec-session-media-level">
<!-- Miguel: I need to think a bit more about this text below. I
suspect we are going against RFC 4566 when we say: we do not care
where these attributes appear, we will interpret only at the media
level. This sounds strange -->
<!-- rrg: The practical reason is that I think it's awkward to let
two different potential configurations invoke two different capability
attributes, both of the same type (e.g., icap), and appearing at the
session level, but with different values - and interpret both of the
resulting fields as session level in the resulting session. More
importantly, the latent configuations must appear at the session
level (they aren't part of any m-line block), so their capabilities
must appear there also - but those caps, when invoked, shouldn't
necessarily appear at the session level. Saying this another way,
it doesn't seem right to negotiate a session-level value at the
media level. If we want to negotiate session-level attributes,
we should do so with a different configuration attribute (which
we haven't defined).
Does this make sense?
-->
<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>
<!-- Question: would it be more simple if configuration b-fields replaced all
conventional b-fields at the base media level? This makes processing easier,
but may require an extra bcap line to replace a deleted one. -->
<!-- Miguel: Since RFC 4566 allows the presence of more than one
bandwidth field (b=), then, theoretically, it is possible to
create an SDP with two or more of this fields, for example, one
with a CT and the other with AS modifiers. Therefore, I support
the current text: the potential or latent configuration can
replace a bandwidth of the same type at the same media
level.. -->
<!-- rrg: The above text is the way it was stated in the SDPMediaCapNeg draft,
but it does require special processing of the b= lines to match the
bandwidth type before deletion. Perhaps we should inquire at the meeting
to see what folks think better. -->
</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 -->
<!-- Do we need to register something related to the potential
configuration? -->
<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: No</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">
<!-- rrg: I think we need to add "icap-v0" here as well. -->
<t>
IANA is hereby requested to add the new option tags
"ccap-v0" and "bcap-v0", defined herein, to the SDP
Capability Negotiation Option Tag Registry.
</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="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.I-D.ietf-mmusic-ice" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:43:56 |