draft-ietf-mmusic-sdp-miscellaneous-caps-05.txt   draft-ietf-mmusic-sdp-miscellaneous-caps-06.txt 
MMUSIC WG M. Garcia-Martin MMUSIC WG M. Garcia-Martin
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track S. Veikkolainen Intended status: Standards Track S. Veikkolainen
Expires: November 04, 2013 Nokia Expires: December 07, 2013 Nokia
R. Gilman R. Gilman
May 03, 2013
June 05, 2013
Miscellaneous Capabilities Negotiation in the Session Description Miscellaneous Capabilities Negotiation in the Session Description
Protocol (SDP) Protocol (SDP)
draft-ietf-mmusic-sdp-miscellaneous-caps-05 draft-ietf-mmusic-sdp-miscellaneous-caps-06
Abstract Abstract
SDP has been extended with a capability negotiation mechanism SDP has been extended with a capability negotiation mechanism
framework that allows the endpoints to negotiate transport protocols framework that allows the endpoints to negotiate transport protocols
and attributes. This framework has been extended with a media and attributes. This framework has been extended with a media
capabilities negotiation mechanism that allows endpoints to negotiate capabilities negotiation mechanism that allows endpoints to negotiate
additional media-related capabilities. This negotiation is embedded additional media-related capabilities. This negotiation is embedded
into the widely-used SDP offer/answer procedures. into the widely-used SDP offer/answer procedures.
skipping to change at page 1, line 44 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 04, 2013. This Internet-Draft will expire on December 07, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 21 skipping to change at page 2, line 23
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Protocol Description . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 3
3.1. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 3 3.1. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Bandwidth Capability . . . . . . . . . . . . . . . . 6 3.1.1. Bandwidth Capability . . . . . . . . . . . . . . . . 5
3.1.2. Connection Data Capability . . . . . . . . . . . . . 8 3.1.2. Connection Data Capability . . . . . . . . . . . . . 7
3.1.3. Title Capability . . . . . . . . . . . . . . . . . . 12 3.1.3. Title Capability . . . . . . . . . . . . . . . . . . 12
3.2. Session Level versus Media Level . . . . . . . . . . . . 15 3.2. Session Level versus Media Level . . . . . . . . . . . . 15
3.3. Offer/Answer model extensions . . . . . . . . . . . . . . 15 3.3. Offer/Answer model extensions . . . . . . . . . . . . . . 15
3.3.1. Generating the Initial Offer . . . . . . . . . . . . 16 3.3.1. Generating the Initial Offer . . . . . . . . . . . . 15
3.3.2. Generating the Answer . . . . . . . . . . . . . . . . 16 3.3.2. Generating the Answer . . . . . . . . . . . . . . . . 16
3.3.3. Offerer Processing of the Answer . . . . . . . . . . 16 3.3.3. Offerer Processing of the Answer . . . . . . . . . . 16
3.3.4. Modifying the Session . . . . . . . . . . . . . . . . 17 3.3.4. Modifying the Session . . . . . . . . . . . . . . . . 16
4. Field Replacement Rules . . . . . . . . . . . . . . . . . . . 17 4. Field Replacement Rules . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . 18 6.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . 18
6.2. New Option Tags . . . . . . . . . . . . . . . . . . . . . 18 6.2. New Option Tags . . . . . . . . . . . . . . . . . . . . . 19
6.3. New SDP Capability Negotiation Configuration Parameters 19 6.3. New SDP Capability Negotiation Configuration Parameters 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [RFC4566] is intended for The Session Description Protocol (SDP) [RFC4566] is intended for
describing multimedia sessions for the purposes of session describing multimedia sessions for the purposes of session
announcement, session invitation, and other forms of multimedia announcement, session invitation, and other forms of multimedia
session initiation. SDP has been extended with a capability session initiation. SDP has been extended with a SDP Capability
negotiation mechanism framework [RFC5939] which allows the endpoints Negotiation Mechanism Framework [RFC5939] which allows the endpoints
to negotiate capabilities, such as support for Real-time Transport to negotiate capabilities, such as support for Real-time Transport
Protocol (RTP) [RFC3550] and Secure Real-time Transport Protocol Protocol (RTP) [RFC3550] and Secure Real-time Transport Protocol
(SRTP) [RFC3711]. The SDP media capabilities (SRTP) [RFC3711]. The SDP Media Capabilities Negotiation [RFC6871]
[I-D.ietf-mmusic-sdp-media-capabilities] provides negotiation provides negotiation capabilities to media lines as well.
capabilities to media lines as well.
The capability negotiation is embedded into the widely used SDP offer The capability negotiation is embedded into the widely used SDP offer
/answer procedure [RFC3264]. This memo provides the means to /answer procedure [RFC3264]. This memo provides the means to
negotiate further capabilities than those specified in the SDP negotiate further capabilities than those specified in the SDP
capability negotiation mechanism framework [RFC5939] and the SDP Capability Negotiation Mechanism Framework [RFC5939] and the SDP
media capabilities negotiation Media Capabilities Negotiation [RFC6871]. In particular, this memo
[I-D.ietf-mmusic-sdp-media-capabilities]. In particular, this memo
provides a mechanism to negotiate bandwidth ('b='), connection data provides a mechanism to negotiate bandwidth ('b='), connection data
('c='), and session or media titles ('i='). ('c='), and session or media titles ('i=').
Since the three added capabilities are independent, it is not Since the three added capabilities are independent, it is not
expected that implementations will necessarily support all of them at expected that implementations will necessarily support all of them at
the same time. Instead, it is expected that applications will choose the same time. Instead, it is expected that applications will choose
their needed capability for their specific purpose. Due to this, we their needed capability for their specific purpose. Due to this, we
are writing the normative part pertaining to each capability in a are writing the normative part pertaining to each capability in a
self-contained section: Section 3.1.1 describes the bandwidth self-contained section: Section 3.1.1 describes the bandwidth
capability extension, Section 3.1.2 describes the connection data capability extension, Section 3.1.2 describes the connection data
skipping to change at page 4, line 4 skipping to change at page 3, line 38
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant [RFC2119] and indicate requirement levels for compliant
implementations. implementations.
3. Protocol Description 3. Protocol Description
3.1. Extensions to SDP 3.1. Extensions to SDP
The SDP Capability Negotiation Framework [RFC5939] and the SDP media
capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities] The SDP Capability Negotiation Framework [RFC5939] and the SDP Media
specify attributes for negotiating SDP capabilities. These documents Capabilities Negotiation [RFC6871] specify attributes for negotiating
specify new attributes (e.g., 'acap', 'tcap', 'rmcap', 'omcap') for SDP capabilities. These documents specify new attributes (e.g.,
achieving their purpose. In this document we define three new 'acap', 'tcap', 'rmcap', 'omcap') for achieving their purpose. In
additional capability attributes for SDP lines of the general form: this document we define three new additional capability attributes
for SDP lines of the general form:
type=value type=value
for types 'b', 'c', and 'i'. The corresponding capability attributes for types 'b', 'c', and 'i'. The corresponding capability attributes
are respectively defined as: are respectively defined as:
o 'bcap': bandwidth capability o 'bcap': bandwidth capability
o 'ccap': connection data capability o 'ccap': connection data capability
o 'icap': title capability o 'icap': title capability
From the sub-rules of attribute ('a=') line in SDP [RFC4566], SDP From the sub-rules of attribute ('a=') line in SDP [RFC4566], SDP
attributes are of the form: attributes are of the form:
attribute = (att-field ":" att-value) / att-field attribute = (att-field ":" att-value) / att-field
att-field = token att-field = token
att-value = byte-string att-value = byte-string
skipping to change at page 4, line 34 skipping to change at page 4, line 20
attribute = (att-field ":" att-value) / att-field attribute = (att-field ":" att-value) / att-field
att-field = token att-field = token
att-value = byte-string att-value = byte-string
Capability attributes use only the 'att-field:att-value' form. Capability attributes use only the 'att-field:att-value' form.
The new capabilities may be referenced in potential configurations The new capabilities may be referenced in potential configurations
('a=pcfg') or in latent configurations ('a=lcfg'), as productions ('a=pcfg') or in latent configurations ('a=lcfg'), as productions
conforming to the <extension-config-list> as respectively defined in conforming to the <extension-config-list> as respectively defined in
RFC 5939 [RFC5939] and the SDP media capabilities specification RFC 5939 [RFC5939] and RFC6871 [RFC6871].
[I-D.ietf-mmusic-sdp-media-capabilities].
extension-config-list = ["+"] ext-cap-name "=" ext-cap-list extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT) ext-cap-name = 1*(ALPHA / DIGIT)
; ALPHA and DIGIT defined in RFC 5234 ; ALPHA and DIGIT defined in RFC 5234
ext-cap-list = 1*VCHAR ; VCHAR defined in RFC 5234 ext-cap-list = 1*VCHAR ; VCHAR defined in RFC 5234
The optional "+" is used to indicate that the extension is mandatory The optional "+" is used to indicate that the extension is mandatory
and MUST be supported in order to use that particular configuration. and MUST be supported in order to use that particular configuration.
The new capabilities may also be referenced in actual configurations The new capabilities may also be referenced in actual configurations
skipping to change at page 5, line 24 skipping to change at page 5, line 8
media level. media level.
According to SDP [RFC4566], 'b=', 'c=', and 'i=' lines may appear According to SDP [RFC4566], 'b=', 'c=', and 'i=' lines may appear
either at session or media level. In line with this, the 'bcap', either at session or media level. In line with this, the 'bcap',
'ccap', and 'icap' capability attributes, when declared at session 'ccap', and 'icap' capability attributes, when declared at session
level, are to be interpreted as-if that attribute was provided with level, are to be interpreted as-if that attribute was provided with
that value at the session level. The 'bcap', 'ccap' and 'icap' that value at the session level. The 'bcap', 'ccap' and 'icap'
capability attributes declared at media level, are to be interpreted capability attributes declared at media level, are to be interpreted
as-if that capability attribute was declared at the media level. as-if that capability attribute was declared at the media level.
For example, extending the example in For example, extending the example in [RFC6871] with 'icap' and
[I-D.ietf-mmusic-sdp-media-capabilities] with 'icap' and 'bcap' 'bcap' capability attributes, we get the following SDP:
capability attributes, we get the following SDP:
v=0 v=0
o=- 25678 753849 IN IP4 192.0.2.1 o=- 25678 753849 IN IP4 192.0.2.1
s= s=
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
t=0 0 t=0 0
a=bcap:1 CT:200 a=bcap:1 CT:200
a=icap:1 Video conference a=icap:1 Video conference
m=audio 54320 RTP/AVP 0 m=audio 54320 RTP/AVP 0
a=rmcap:1 L16/8000/1 a=rmcap:1 L16/8000/1
skipping to change at page 7, line 7 skipping to change at page 6, line 37
att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
Figure 2: Syntax of the bcap attribute Figure 2: Syntax of the bcap attribute
Negotiation of bandwidth per media stream can be useful when Negotiation of bandwidth per media stream can be useful when
negotiating media encoding capabilities with different bandwidths. negotiating media encoding capabilities with different bandwidths.
3.1.1.1. Configuration Parameters 3.1.1.1. Configuration Parameters
The SDP capability negotiation framework [RFC5939] provides for the The SDP Capability Negotiation Framework [RFC5939] provides for the
existence of the 'pcfg' and 'acfg' attributes. The concept is existence of the 'pcfg' and 'acfg' attributes. The concept is
extended by the SDP media capabilities negotiation extended by the SDP Media Capabilities Negotiation [RFC6871] with an
[I-D.ietf-mmusic-sdp-media-capabilities] with an 'lcfg' attribute 'lcfg' attribute that conveys latent configurations.
that conveys latent configurations.
Extensions to the 'pcfg' and 'lcfg' attributes are defined through Extensions to the 'pcfg' and 'lcfg' attributes are defined through
<extension-config-list>, and extensions to the 'acfg' attribute are <extension-config-list>, and extensions to the 'acfg' attribute are
defined through the <sel-extension-config> as defined in the SDP defined through the <sel-extension-config> as defined in the SDP
Capability Negotiation [RFC5939]. Capability Negotiation [RFC5939].
In this document we extend the <extension-config-list> field to be In this document we extend the <extension-config-list> field to be
able to convey lists of bandwidth capabilities in latent or potential able to convey lists of bandwidth capabilities in latent or potential
configurations, according to the following Augmented Backus-Naur Form configurations, according to the following Augmented Backus-Naur Form
(ABNF) [RFC5234] syntax: (ABNF) [RFC5234] syntax:
skipping to change at page 9, line 17 skipping to change at page 8, line 49
SP connection-address SP connection-address
conn-cap-num = 1*10(DIGIT) ; 1 to 2^31-1, inclusive conn-cap-num = 1*10(DIGIT) ; 1 to 2^31-1, inclusive
; DIGIT defined in RFC 5234 ; DIGIT defined in RFC 5234
Figure 5: Syntax of the ccap attribute Figure 5: Syntax of the ccap attribute
The 'ccap' capability attribute allows for expressing alternative The 'ccap' capability attribute allows for expressing alternative
connections address ("c=") lines in SDP as part of the SDP capability connections address ("c=") lines in SDP as part of the SDP capability
negotiation process. One of the primary use cases for this is negotiation process. One of the primary use cases for this is
offering alternative connection addresses where the <nettype> is "IN" offering alternative connection addresses where the <nettype> is "IN"
or "PSTN", i.e. selecting between IP based bearer or a circuit- or "PSTN", i.e. selecting between IP based bearer or a circuit-
switched bearer. switched bearer.
By supporting the "IN" <nettype>, the 'ccap' attribute enables the By supporting the "IN" <nettype>, the 'ccap' attribute enables the
signaling of multiple IPv4 and IPv6 addresses, however the Standards signaling of multiple IPv4 and IPv6 addresses, however the Standards
Track mechanism for negotiation of alternative IP addresses in SDP is Track mechanism for negotiation of alternative IP addresses in SDP is
Interactive Connectivity Establishment (ICE) [RFC5245]. The 'ccap' Interactive Connectivity Establishment (ICE) [RFC5245]. The 'ccap'
attribute does not change that and hence the combined set of actual attribute does not change that and hence the combined set of actual
and potential configurations (as defined in [RFC5939]) for any given and potential configurations (as defined in [RFC5939]) for any given
media description MUST NOT use the 'ccap' attribute to negotiate more media description MUST NOT use the 'ccap' attribute to negotiate more
than one address with an IN network type (i.e., it is not permissible than one address with an IN network type (i.e., it is not permissible
skipping to change at page 10, line 45 skipping to change at page 10, line 31
This draft defines an exception when the network type is "PSTN", in This draft defines an exception when the network type is "PSTN", in
which case the port number is replaced with 9 (the "discard" port) as which case the port number is replaced with 9 (the "discard" port) as
described in Session Decription Protocol (SDP) Extension For Setting described in Session Decription Protocol (SDP) Extension For Setting
Up Audio and Video Media Streams over Circuit-Switched Bearers in the Up Audio and Video Media Streams over Circuit-Switched Bearers in the
Public Switched Telephone Network (PSTN) [I-D.ietf-mmusic-sdp-cs]. Public Switched Telephone Network (PSTN) [I-D.ietf-mmusic-sdp-cs].
An endpoint offering alternative IP and PSTN bearers MUST include the An endpoint offering alternative IP and PSTN bearers MUST include the
IP media description in the actual configuration (IP address in the IP media description in the actual configuration (IP address in the
"c=" line and port number in the "m=" line), and the PSTN media "c=" line and port number in the "m=" line), and the PSTN media
description in the potential configuration. description in the potential configuration.
Exceptions for other network types, such as for the "ATM" network
type defined in [RFC3108], require additional specifications.
3.1.2.1. Configuration Parameters 3.1.2.1. Configuration Parameters
The SDP Capability Negotiation Framework [RFC5939] provides for the The SDP Capability Negotiation Framework [RFC5939] provides for the
existence of the 'pcfg' and 'acfg' attributes, which can convey one existence of the 'pcfg' and 'acfg' attributes, which can convey one
or more configurations to be negotiated. The concept is extended by or more configurations to be negotiated. The concept is extended by
the Media Capabilities Negotiation the SDP Media Capabilities Negotiation [RFC6871] with an 'lcfg'
[I-D.ietf-mmusic-sdp-media-capabilities] with an 'lcfg' attribute attribute that conveys latent configurations.
that conveys latent configurations.
In this document we define a <connection-config> parameter to be used In this document we define a <connection-config> parameter to be used
to specify a connection data capability in a potential or latent to specify a connection data capability in a potential or latent
configuration attribute. The parameter follows the form of an configuration attribute. The parameter follows the form of an
<extension-config-list>, with <extension-config-list>, with
ext-cap-name = "c" ext-cap-name = "c"
ext-cap-list = conn-cap-list ext-cap-list = conn-cap-list
skipping to change at page 13, line 27 skipping to change at page 13, line 17
In this document we define a new capability attribute: the Title In this document we define a new capability attribute: the Title
capability 'icap'. This attribute lists session or media titles as capability 'icap'. This attribute lists session or media titles as
capabilities, according to the following definition: capabilities, according to the following definition:
"a=icap:" title-cap-num 1*WSP text "a=icap:" title-cap-num 1*WSP text
where <title-cap-num> is a unique integer within all the connection where <title-cap-num> is a unique integer within all the connection
capabilities in the entire SDP, which is used to identify the capabilities in the entire SDP, which is used to identify the
particular title capability, and can take a value between 1 and particular title capability, and can take a value between 1 and
2^31-1 (both included). <text> is a human-readable text that 2^31-1 (both included). <text> is a human-readable text that
indicates the purpose of the session or media stream it is supposed indicates the purpose of the session or media stream it is supposed
to characterize. to characterize.
As an example, one might use: As an example, one might use:
a=icap:1 Document Camera a=icap:1 Document Camera
to define a title capability number 1 to identify a particular source to define a title capability number 1 to identify a particular source
of a media stream. of a media stream.
skipping to change at page 14, line 4 skipping to change at page 13, line 40
Augmented Backus-Naur Form (ABNF) [RFC5234] syntax: Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
att-field =/ "icap" att-field =/ "icap"
att-value =/ title-cap-num 1*WSP text att-value =/ title-cap-num 1*WSP text
; text defined in RFC 4566 ; text defined in RFC 4566
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
Figure 11: Syntax of the icap attribute Figure 11: Syntax of the icap attribute
3.1.3.1. Configuration Parameters 3.1.3.1. Configuration Parameters
The SDP Capability Negotiation Framework [RFC5939] provides for the The SDP Capability Negotiation Framework [RFC5939] provides for the
existence of the 'pcfg' and 'acfg' attributes. The concept is existence of the 'pcfg' and 'acfg' attributes. The concept is
extended by the SDP media capabilities negotiation extended by the SDP Media Capabilities Negotiation [RFC6871] with an
[I-D.ietf-mmusic-sdp-media-capabilities] with an 'lcfg' attribute 'lcfg' attribute that conveys latent configurations.
that conveys latent configurations.
In this document, we define a <title-config-list> parameter to be In this document, we define a <title-config-list> parameter to be
used to convey title capabilities in a potential or latent used to convey title capabilities in a potential or latent
configuration. This parameter is defined as an <extension-config- configuration. This parameter is defined as an <extension-config-
list> with the following associations: list> with the following associations:
ext-cap-name = "i" ext-cap-name = "i"
ext-cap-list = title-cap-list ext-cap-list = title-cap-list
This leads to the following definition for the title capability This leads to the following definition for the title capability
parameter: parameter:
extension-config-list =/ title-config-list extension-config-list =/ title-config-list
title-config-list = ["+"] "i=" title-cap-list title-config-list = ["+"] "i=" title-cap-list
title-cap-list = title-cap-num *(BAR title-cap-num) title-cap-list = title-cap-num *(BAR title-cap-num)
; BAR defined in RFC 5939 ; BAR defined in RFC 5939
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
skipping to change at page 16, line 22 skipping to change at page 16, line 8
When an endpoint generates an initial offer and wants to use the When an endpoint generates an initial offer and wants to use the
functionality described in the current document, it first defines functionality described in the current document, it first defines
appropriate values for the bandwidth, connection data, and/or title appropriate values for the bandwidth, connection data, and/or title
capability attributes according to the rules defined in [RFC4566] for capability attributes according to the rules defined in [RFC4566] for
'b=', 'c=' and 'i=' lines. The endpoint then MUST include the 'b=', 'c=' and 'i=' lines. The endpoint then MUST include the
respective capability attributes and associated values in the SDP respective capability attributes and associated values in the SDP
offer. The preferred configurations for each media stream are offer. The preferred configurations for each media stream are
identified following the media line in a 'pcfg' attribute. Bandwidth identified following the media line in a 'pcfg' attribute. Bandwidth
and title capabilities may also be referenced in latent and title capabilities may also be referenced in latent
configurations in an 'lcfg' attribute, defined in SDP Media configurations in an 'lcfg' attribute, defined in SDP Media
Capabilities [I-D.ietf-mmusic-sdp-media-capabilities]. Capabilities Negotiation [RFC6871].
Implementations are advised to pay attention to the port number that Implementations are advised to pay attention to the port number that
is used in the "m=" line. By default, a potential configuration that is used in the "m=" line. By default, a potential configuration that
includes a connection data capability will use the port number from includes a connection data capability will use the port number from
the "m=" line, unless the network type is "PSTN", in which case the the "m=" line, unless the network type is "PSTN", in which case the
default port number used will be 9. default port number used will be 9.
The offer SHOULD include the level of capability negotiation The offer SHOULD include the level of capability negotiation
extensions needed to support this functionality in a 'creq' extensions needed to support this functionality in a 'creq'
attribute. attribute.
skipping to change at page 16, line 45 skipping to change at page 16, line 31
When the answering party receives the offer, and if it supports the When the answering party receives the offer, and if it supports the
required capability negotiation extensions, it SHOULD select the most required capability negotiation extensions, it SHOULD select the most
preferred configuration it can support for each media stream, and preferred configuration it can support for each media stream, and
build the answer accordingly, as defined in Section 3.6.2 of the SDP build the answer accordingly, as defined in Section 3.6.2 of the SDP
Capability Negotiation [RFC5939]. Capability Negotiation [RFC5939].
If the connection data capability is used in a selected potential If the connection data capability is used in a selected potential
configuration chosen by the answerer, that offer configuration MUST configuration chosen by the answerer, that offer configuration MUST
by default use the port number from the actual offer configuration by default use the port number from the actual offer configuration
(i.e. the "m=" line), unless the network type is "PSTN", in which (i.e. the "m=" line), unless the network type is "PSTN", in which
case the default port MUST be assumed to be 9. Extensions may be case the default port MUST be assumed to be 9. Extensions may be
defined to negotiate the port number explicitly instead. defined to negotiate the port number explicitly instead.
3.3.3. Offerer Processing of the Answer 3.3.3. Offerer Processing of the Answer
When the offerer receives the answer, it MUST process the media lines When the offerer receives the answer, it MUST process the media lines
according to normal SDP processing rules to identify the media 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 stream(s) accepted by the answer, if any, as defined in Section 3.6.3
of the SDP Capability Negotiation [RFC5939]. The 'acfg' attribute, of the SDP Capability Negotiation [RFC5939]. The 'acfg' attribute,
if present, MUST be used to verify the proposed configuration used to if present, MUST be used to verify the proposed configuration used to
form the answer, and to infer the lack of acceptability of higher- form the answer, and to infer the lack of acceptability of higher-
preference configurations that were not chosen. preference configurations that were not chosen.
3.3.4. Modifying the Session 3.3.4. Modifying the Session
If, at a later time, one of the parties wishes to modify the 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 operating parameters of a session, e.g. by adding a new media stream,
stream, or by changing the properties used on an existing stream, it or by changing the properties used on an existing stream, it may do
may do so via the mechanisms defined for SDP offer/answer [RFC3264] so via the mechanisms defined for SDP offer/answer [RFC3264] and in
and in accordance with the procedures defined in Section 3.6.4 of the accordance with the procedures defined in Section 3.6.4 of the SDP
SDP Capability Negotiation [RFC5939]. Capability Negotiation [RFC5939].
4. Field Replacement Rules 4. Field Replacement Rules
To simplify the construction of SDP records, given the need to To simplify the construction of SDP records, given the need to
include fields within the media description in question for endpoints include fields within the media description in question for endpoints
that do not support capabilities negotiation, we define some simple that do not support capabilities negotiation, we define some simple
field-replacement rules for those fields invoked by potential or field-replacement rules for those fields invoked by potential or
latent configurations. In particular, any 'i=' or 'c=' line invoked latent configurations. In particular, any 'i=' or 'c=' line invoked
by a configuration MUST replace the corresponding line, if present by a configuration MUST replace the corresponding line, if present
within the media description in question. Any 'b=' line invoked by a within the media description in question. Any 'b=' line invoked by a
configuration MUST replace any 'b=' of the same bandwidth type at the configuration MUST replace any 'b=' of the same bandwidth type at the
media level, but not at the session level. media level, but not at the session level.
5. Security Considerations 5. Security Considerations
This document provides an extension on top of RFC 4566 [RFC4566], RFC This document provides an extension on top of RFC 4566 [RFC4566], RFC
3264 [RFC3264], SDP Capability Negotiation Framework [RFC5939], and 3264 [RFC3264], SDP Capability Negotiation Framework [RFC5939], and
SDP media capabilities negotiation SDP Media Capabilities Negotiation [RFC6871]. As such, the security
[I-D.ietf-mmusic-sdp-media-capabilities]. As such, the security
considerations of those documents apply. considerations of those documents apply.
The bandwidth capability attribute may be used for reserving The bandwidth capability attribute may be used for reserving
resources at endpoints and intermediaries which inspect the SDP. resources at endpoints and intermediaries which inspect the SDP.
Modification of the bandwidth value by an attacker can lead to the Modification of the bandwidth value by an attacker can lead to the
network being underutilized (too high bandwidth value) or congested network being underutilized (too high bandwidth value) or congested
(too low bandwidth value). In case it is essential to protect the (too low bandwidth value).
bandwidth value, one of the security mechanisms proposed in [RFC5939]
SHOULD be used. Similarly, by modifying the alternative connection address(es), an
attacker would be able direct media streams to a desired endpoint,
thus launching a version of the well known voice hammer attack (see
Section 18.5.1 of [RFC5245].
The title capability provides for alternative "i=" line information,
which is intended for human consumption. However, manipulating the
textual information could be misused to provide false information,
leading to bad user experience or the person using the service making
wrong the choice regarding the available media streams.
In case it is essential to protect the capability attribute values,
one of the security mechanisms proposed in [RFC5939] SHOULD be used.
The 'i=' line and thus the value carried in the title capability The 'i=' line and thus the value carried in the title capability
attribute is intended for human-readable description only. It should attribute is intended for human-readable description only. It should
not be parsed programmatically. not be parsed programmatically.
6. IANA Considerations 6. IANA Considerations
6.1. New SDP Attributes 6.1. New SDP Attributes
IANA is hereby requested to register new attributes in the "att-field IANA is hereby requested to register new attributes in the "att-field
skipping to change at page 19, line 28 skipping to change at page 19, line 43
Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson
for arguing for the existence of this document and early reviewing for arguing for the existence of this document and early reviewing
it. Thanks to Flemming Andreasen, Andrew Allen, and Jonathan Lennox it. Thanks to Flemming Andreasen, Andrew Allen, and Jonathan Lennox
for a detailed review and many improvement suggestions. for a detailed review and many improvement suggestions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-mmusic-sdp-media-capabilities]
Gilman, R., Even, R., and F. Andreasen, "Session
Description Protocol (SDP) Media Capabilities
Negotiation", draft-ietf-mmusic-sdp-media-capabilities-17
(work in progress), January 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) [RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, September 2010. Capability Negotiation", RFC 5939, September 2010.
[RFC6871] Gilman, R., Even, R., and F. Andreasen, "Session
Description Protocol (SDP) Media Capabilities
Negotiation", RFC 6871, February 2013.
8.2. Informative References 8.2. Informative References
[I-D.ietf-mmusic-sdp-cs] [I-D.ietf-mmusic-sdp-cs]
Garcia, M. and S. Veikkolainen, "Session Description Garcia, M. and S. Veikkolainen, "Session Description
Protocol (SDP) Extension For Setting Up Audio and Video Protocol (SDP) Extension For Setting Audio and Video Media
Media Streams Over Circuit-Switched Bearers In The Public Streams Over Circuit-Switched Bearers In The Public
Switched Telephone Network (PSTN)", draft-ietf-mmusic-sdp- Switched Telephone Network (PSTN)", draft-ietf-mmusic-sdp-
cs-18 (work in progress), April 2013. cs-19 (work in progress), June 2013.
[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the
Session Description Protocol (SDP) for ATM Bearer Session Description Protocol (SDP) for ATM Bearer
Connections", RFC 3108, May 2001. Connections", RFC 3108, May 2001.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
 End of changes. 38 change blocks. 
66 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/