One document matched: draft-ietf-mmusic-sdp-miscellaneous-caps-03.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="trust200902" category="std">
<front>
<title abbrev="SDP Misc. Capabilities Negotiation">
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="12" month="December" 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>
Since the three added capabilities are independent, it is not
expected that implementations will necessarily support all of
them at the same time. Instead, it is expected that
applications will choose their needed capability for their
specific purpose. 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 SDP capability negotiation 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 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 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 capabilities may be referenced in potential
configurations ('a=pcfg') or in latent configurations
('a=lcfg'), as productions conforming to the
<extension-config-list> as respectively defined in <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
particular configuration.
</t>
<t>
The new capabilities may also be referenced in actual
configurations ('a=acfg') as productions conforming to the
<sel-extension-config> defined in <xref
target="RFC5939">RFC 5939</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 at the SDP session and/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 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 an RTP-based
media capability for H.263 video ('rmcap' numbered 3). The
RTP-based media capabilities all appear at the media
level. The example also contains a single bandwidth
capability ('bcap') and a single title capability ('icap'),
both defined at session level. According to the definition
above, when the capabilities defined in the 'bcap' and
'icap' attributes are referenced from the potential
configuration, in the resulting SDP they are to be
interpreted as session level attributes (but the RTP-based
media capabilities are to be interpreted as media level
attributes).
</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
at the SDP session and/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 within all
the bandwidth capabilities in the entire SDP, which is
used to number the bandwidth capability, and can take a
value between 1 and 2^31-1 (both included). The other
elements are as defined for the 'b=' field in <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 SDP session and/or media level. In
order to permit negotiation of connection data at the
media level, we define the connection data capability
attribute ('a=ccap') in the form:</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 integer within all
the connection capabilities in the entire SDP, which is
used to identify the connection data capability, and can
take a value between 1 and 2^31-1 (both included). The
other elements are as defined in <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*10(DIGIT) ; 1 to 2^31-1, inclusive
; DIGIT defined in RFC 5234
</artwork></figure>
<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 (e.g. "IN" and "PSTN"). 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 (e.g. "IP4" and "IP6" or different
IP addresses within the same IP address family).
</t>
<t>
<xref target="example-ccap"/> is an example of an SDP
offer that includes a 'ccap' capability attribute. An
audio stream can be setup with an RTP flow or
establishing a circuit-switched audio stream:
</t>
<figure title="Example SDP offer with a ccap attribute" anchor="example-ccap"><artwork type="ABNF">
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
a=creq:med-v0,ccap-v0
m=audio 38902 RTP/AVP 0 8
c=IN IP4 198.51.100.7
a=ccap:1 PSTN E164 +15555556666
a=tcap:2 PSTN
a=omcap:1 -
a=acap:1 setup:actpass
a=acap:2 connection:new
a=acap:3 cs-correlation:callerid:+15555556666
a=pcfg:1 c=1 t=2 m=1 a=1,2,3
</artwork></figure>
<t>
The example in <xref target="example-ccap"/> represents
an SDP offer indicating an audio flow using RTP, such as
the one represented in <xref target="example-ccap-rtp"/>
or an audio flow using a circuit-switched connection,
such as the one represented in <xref
target="example-ccap-cs"/>.
</t>
<figure title="Equivalent SDP offer with the RTP flow" anchor="example-ccap-rtp"><artwork type="ABNF">
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
m=audio 38902 RTP/AVP 0 8
c=IN IP4 198.51.100.7
</artwork></figure>
<figure title="Equivalent SDP offer with the circuit-switched flow" anchor="example-ccap-cs"><artwork type="ABNF">
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
m=audio 9 PSTN -
c=PSTN E164 +15555556666
a=setup:actpass
a=connection:new
a=cs-correlation:callerid:+15555556666
</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, which can
convey one or more configurations to be
negotiated. The concept is extended by 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*10(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 the
configuration attribute to mandate support for this
extension. An endpoint that receives this parameter
prefixed with a plus sign and does not support this
extension MUST treat that potential configuration as not
valid.
</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 at the SDP
session and/or media level. An 'i=' line that is
present at the session level is known as the "session
name", and its purpose is to convey human-readable
textual information about the session.
</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>
As defined in <xref target="RFC4566">SDP </xref>, the
session information field ("i=", referred to as "title"
in this document) is subject to the "a=charset" attribute
in order to support different character sets and hence
internationalization. The title capability attribute
itself ("a=icap") is however not subject to the
"a=charset" attribute as this would preclude the inclusion
of alternative session/title information each using
different character sets. Instead, the session/title value
embedded in an "a=icap" attribute (title capability) will
be subject to the "a=charset" value used within a
configuration that includes that title capability. This
provides for consistent SDP operation while allowing for
capabilities and configurations with different
session/title information values with different character
set encodings (with each such configuration including an
"a=charset" value with the relevant character set for the
session/title information in question).
</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 within
all the connection capabilities in the entire SDP, which is
used to identify the particular title capability, and can
take a value between 1 and 2^31-1 (both
included). <text> is a human-readable text that
indicates the purpose of the session or media stream it is
supposed to characterize.</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 a <title-config-list>
parameter to be used to convey title capabilities
in a potential or latent configuration. This parameter
is defined as an <extension-config-list> with the
following associations:
</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 the
configuration attribute to mandate support for this
extension. An endpoint that receives this parameter
prefixed with a plus sign and does not support this
extension MUST treat that potential configuration as not
valid.
</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
SDP session and/or media level. Endpoints MUST interpret
capabilities declared at session level as part of the
session level in the resulting SDP for that particular
configuration. Endpoints MUST interpret capabilities
declared at media description as part of the media level in the
resulting SDP for that particular configuration.
</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,
connection, 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 the 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="I-D.ietf-mmusic-sdp-media-capabilities">SDP Media
Capabilities </xref>.
</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, as defined in Section 3.6.3 of the <xref
target="RFC5939">SDP Capability Negotiation</xref>. The
'acfg' attribute, if present, MUST be used to verify the
proposed configuration used to form the answer, and to
infer the lack of acceptability of higher-preference
configurations that were not chosen.
</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> and in
accordance with the procedures defined in Section 3.6.4 of
the <xref target="RFC5939">SDP Capability Negotiation
</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, but not at the session level.
</t>
</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-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) Parameters" registry, according
to the following registration form:
</t>
<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 Section 3.1.1
[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 Section 3.1.2
[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 Section 3.1.3
[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 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-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:57:52 |