draft-ietf-mmusic-sdp-media-capabilities-16.txt   draft-ietf-mmusic-sdp-media-capabilities-17.txt 
MMUSIC R. Gilman MMUSIC R. Gilman
Internet-Draft Independent Internet-Draft Independent
Updates: 5939 (if approved) R. Even Updates: 5939 (if approved) R. Even
Intended status: Standards Track Gesher Erove Ltd Intended status: Standards Track Gesher Erove Ltd
Expires: June 15, 2013 F. Andreasen Expires: July 8, 2013 F. Andreasen
Cisco Systems Cisco Systems
December 12, 2012 January 4, 2013
Session Description Protocol (SDP) Media Capabilities Negotiation Session Description Protocol (SDP) Media Capabilities Negotiation
draft-ietf-mmusic-sdp-media-capabilities-16 draft-ietf-mmusic-sdp-media-capabilities-17
Abstract Abstract
Session Description Protocol (SDP) capability negotiation provides a Session Description Protocol (SDP) capability negotiation provides a
general framework for indicating and negotiating capabilities in SDP. general framework for indicating and negotiating capabilities in SDP.
The base framework defines only capabilities for negotiating The base framework defines only capabilities for negotiating
transport protocols and attributes. In this document, we extend the transport protocols and attributes. In this document, we extend the
framework by defining media capabilities that can be used to framework by defining media capabilities that can be used to
negotiate media types and their associated parameters. negotiate media types and their associated parameters.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 June 15, 2013. This Internet-Draft will expire on July 8, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. SDP Media Capabilities . . . . . . . . . . . . . . . . . . . . 8 3. SDP Media Capabilities . . . . . . . . . . . . . . . . . . . . 8
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Solution Overview . . . . . . . . . . . . . . . . . . . . 9 3.2. Solution Overview . . . . . . . . . . . . . . . . . . . . 9
3.3. New Capability Attributes . . . . . . . . . . . . . . . . 15 3.3. New Capability Attributes . . . . . . . . . . . . . . . . 15
3.3.1. The Media Format Capability Attributes . . . . . . . . 15 3.3.1. The Media Format Capability Attributes . . . . . . . . 15
3.3.2. The Media Format Parameter Capability Attribute . . . 17 3.3.2. The Media Format Parameter Capability Attribute . . . 18
3.3.3. The Media-Specific Capability Attribute . . . . . . . 20 3.3.3. The Media-Specific Capability Attribute . . . . . . . 20
3.3.4. New Configuration Parameters . . . . . . . . . . . . . 22 3.3.4. New Configuration Parameters . . . . . . . . . . . . . 22
3.3.5. The Latent Configuration Attribute . . . . . . . . . . 24 3.3.5. The Latent Configuration Attribute . . . . . . . . . . 24
3.3.6. Enhanced Potential Configuration Attribute . . . . . . 26 3.3.6. Enhanced Potential Configuration Attribute . . . . . . 26
3.3.7. Substitution of Media Payload Type Numbers in 3.3.7. Substitution of Media Payload Type Numbers in
Capability Attribute Parameters . . . . . . . . . . . 30 Capability Attribute Parameters . . . . . . . . . . . 30
3.3.8. The Session Capability Attribute . . . . . . . . . . . 31 3.3.8. The Session Capability Attribute . . . . . . . . . . . 31
3.4. Offer/Answer Model Extensions . . . . . . . . . . . . . . 35 3.4. Offer/Answer Model Extensions . . . . . . . . . . . . . . 35
3.4.1. Generating the Initial Offer . . . . . . . . . . . . . 36 3.4.1. Generating the Initial Offer . . . . . . . . . . . . . 36
3.4.2. Generating the Answer . . . . . . . . . . . . . . . . 39 3.4.2. Generating the Answer . . . . . . . . . . . . . . . . 39
skipping to change at page 3, line 41 skipping to change at page 3, line 41
4.3. Latent Media Streams . . . . . . . . . . . . . . . . . . . 48 4.3. Latent Media Streams . . . . . . . . . . . . . . . . . . . 48
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 51 5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 51
5.2. New SDP Capability Negotiation Option Tag . . . . . . . . 52 5.2. New SDP Capability Negotiation Option Tag . . . . . . . . 52
5.3. SDP Capability Negotiation Configuration Parameters 5.3. SDP Capability Negotiation Configuration Parameters
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 52 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4. SDP Capability Negotiation Configuration Parameter 5.4. SDP Capability Negotiation Configuration Parameter
Registrations . . . . . . . . . . . . . . . . . . . . . . 53 Registrations . . . . . . . . . . . . . . . . . . . . . . 53
6. Security Considerations . . . . . . . . . . . . . . . . . . . 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 55
7. Changes from previous versions . . . . . . . . . . . . . . . . 56 7. Changes from previous versions . . . . . . . . . . . . . . . . 56
7.1. Changes from version 15 . . . . . . . . . . . . . . . . . 56 7.1. Changes from version 16 . . . . . . . . . . . . . . . . . 56
7.2. Changes from version 14 . . . . . . . . . . . . . . . . . 56 7.2. Changes from version 15 . . . . . . . . . . . . . . . . . 56
7.3. Changes from version 13 . . . . . . . . . . . . . . . . . 56 7.3. Changes from version 14 . . . . . . . . . . . . . . . . . 56
7.4. Changes from version 12 . . . . . . . . . . . . . . . . . 56 7.4. Changes from version 13 . . . . . . . . . . . . . . . . . 56
7.5. Changes from version 11 . . . . . . . . . . . . . . . . . 56 7.5. Changes from version 12 . . . . . . . . . . . . . . . . . 56
7.6. Changes from version 10 . . . . . . . . . . . . . . . . . 57 7.6. Changes from version 11 . . . . . . . . . . . . . . . . . 57
7.7. Changes from version 09 . . . . . . . . . . . . . . . . . 57 7.7. Changes from version 10 . . . . . . . . . . . . . . . . . 57
7.8. Changes from version 08 . . . . . . . . . . . . . . . . . 58 7.8. Changes from version 09 . . . . . . . . . . . . . . . . . 58
7.9. Changes from version 04 . . . . . . . . . . . . . . . . . 58 7.9. Changes from version 08 . . . . . . . . . . . . . . . . . 58
7.10. Changes from version 03 . . . . . . . . . . . . . . . . . 58 7.10. Changes from version 04 . . . . . . . . . . . . . . . . . 58
7.11. Changes from version 02 . . . . . . . . . . . . . . . . . 59 7.11. Changes from version 03 . . . . . . . . . . . . . . . . . 58
7.12. Changes from version 01 . . . . . . . . . . . . . . . . . 59 7.12. Changes from version 02 . . . . . . . . . . . . . . . . . 59
7.13. Changes from version 00 . . . . . . . . . . . . . . . . . 60 7.13. Changes from version 01 . . . . . . . . . . . . . . . . . 60
7.14. Changes from version 00 . . . . . . . . . . . . . . . . . 60
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.1. Normative References . . . . . . . . . . . . . . . . . . . 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 62
9.2. Informative References . . . . . . . . . . . . . . . . . . 62 9.2. Informative References . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
Session Description Protocol (SDP) capability negotiation [RFC5939] Session Description Protocol (SDP) capability negotiation [RFC5939]
provides a general framework for indicating and negotiating provides a general framework for indicating and negotiating
skipping to change at page 16, line 24 skipping to change at page 16, line 24
encoding parameters for the media subtype. All media format encoding parameters for the media subtype. All media format
capabilities in the list are assigned to the same media type/subtype. capabilities in the list are assigned to the same media type/subtype.
Each occurrence of the rmcap and omcap attribute MUST use unique Each occurrence of the rmcap and omcap attribute MUST use unique
values in their <media-cap-num-list>; the media capability numbers values in their <media-cap-num-list>; the media capability numbers
are shared between the two attributes and the numbers MUST be unique are shared between the two attributes and the numbers MUST be unique
across the entire SDP session. In short, the rmcap and omcap across the entire SDP session. In short, the rmcap and omcap
attributes define media format capabilities and associate them with a attributes define media format capabilities and associate them with a
media capability number in the same manner as the rtpmap attribute media capability number in the same manner as the rtpmap attribute
defines them and associates them with a payload type number. defines them and associates them with a payload type number.
Additionally, the attributes allow multiple capability numbers to be Additionally, the attributes allow multiple capability numbers to be
defined for the media format in question. This permits the media defined for the media format in question by specifying a range of
format to be associated with different media parameters in different media capability numbers. This permits the media format to be
configurations. associated with different media parameters in different
configurations. When a range of capability numbers is specified, the
first (leftmost) capability number MUST be strictly smaller than the
second (rightmost), i.e. the range increases and covers at least two
numbers.
In ABNF [RFC5234], we have: In ABNF [RFC5234], we have:
media-capability-line = rtp-mcap / non-rtp-mcap media-capability-line = rtp-mcap / non-rtp-mcap
rtp-mcap = "a=rmcap:" media-cap-num-list rtp-mcap = "a=rmcap:" media-cap-num-list
1*WSP encoding-name "/" clock-rate 1*WSP encoding-name "/" clock-rate
["/" encoding-parms] ["/" encoding-parms]
non-rtp-mcap = "a=omcap:" media-cap-num-list 1*WSP format-name non-rtp-mcap = "a=omcap:" media-cap-num-list 1*WSP format-name
media-cap-num-list = media-cap-num-element media-cap-num-list = media-cap-num-element
*("," media-cap-num-element) *("," media-cap-num-element)
media-cap-num-element = media-cap-num media-cap-num-element = media-cap-num
/ media-cap-num-range / media-cap-num-range
media-cap-num-range = media-cap-num "-" media-cap-num media-cap-num-range = media-cap-num "-" media-cap-num
media-cap-num = 1*10(DIGIT) media-cap-num = NonZeroDigit *9(DIGIT)
encoding-name = token ;defined in RFC4566 encoding-name = token ;defined in RFC4566
clock-rate = 1*10(DIGIT) clock-rate = NonZeroDigit *9(DIGIT)
encoding-parms = token encoding-parms = token
format-name = token ;defined in RFC4566 format-name = token ;defined in RFC4566
NonZeroDigit = %x31-39 ; 1-9
The encoding-name, clock-rate and encoding-params are as defined to The encoding-name, clock-rate and encoding-params are as defined to
appear in an rtpmap attribute for each media type/subtype. Thus, it appear in an rtpmap attribute for each media type/subtype. Thus, it
is easy to convert an rmcap attribute line into one or more rtpmap is easy to convert an rmcap attribute line into one or more rtpmap
attribute lines, once a payload type number is assigned to a media- attribute lines, once a payload type number is assigned to a media-
cap-num (see Section 3.3.5). cap-num (see Section 3.3.5).
The format-name is a media format description for non-RTP based media The format-name is a media format description for non-RTP based media
as defined for the <fmt> part of the media description ("m=" line) in as defined for the <fmt> part of the media description ("m=" line) in
SDP [RFC4566]. In simple terms, it is the name of the media format, SDP [RFC4566]. In simple terms, it is the name of the media format,
e.g. "t38". This form can also be used in cases such as BFCP e.g. "t38". This form can also be used in cases such as BFCP
[RFC4585] where the fmt list in the m-line is effectively ignored [RFC4585] where the fmt list in the m-line is effectively ignored
(BFCP uses "*"). (BFCP uses "*").
The "rmcap" and "omcap" attributes can be provided at the session- The "rmcap" and "omcap" attributes can be provided at the session-
level and/or the media-level. There can be more than one rmcap and level and/or the media-level. There can be more than one rmcap and
more than one omcap attribute at both the session and media level more than one omcap attribute at both the session and media level
(i.e., more than one of each at the session-level and more than one (i.e., more than one of each at the session-level and more than one
of each in each media description). Each media-cap-num MUST be of each in each media description). Media capability numbers cannot
unique within the entire SDP record; it is used to identify that include leading zeroes, and each media-cap-num MUST be unique within
media capability in potential, latent and actual configurations, and the entire SDP record; it is used to identify that media capability
in other attribute lines as explained below. Note that the media- in potential, latent and actual configurations, and in other
cap-num values are shared between the rmcap and omcap attributes, and attribute lines as explained below. Note that the media-cap-num
hence the uniqueness requirement applies to the union of them. When values are shared between the rmcap and omcap attributes, and hence
the media capabilities are used in a potential, latent or actual the uniqueness requirement applies to the union of them. When the
media capabilities are used in a potential, latent or actual
configuration, the media formats referred by those configurations configuration, the media formats referred by those configurations
apply at the media level, irrespective of whether the media apply at the media level, irrespective of whether the media
capabilities themselves were specified at the session or media level. capabilities themselves were specified at the session or media level.
In other words, the media capability applies to the specific media In other words, the media capability applies to the specific media
description associated with the configuration which invokes it. description associated with the configuration which invokes it.
For example: For example:
v=0 v=0
o=- 24351 621814 IN IP4 192.0.2.2 o=- 24351 621814 IN IP4 192.0.2.2
skipping to change at page 21, line 6 skipping to change at page 21, line 12
attributes, beyond the rtpmap and fmtp attributes, may be associated attributes, beyond the rtpmap and fmtp attributes, may be associated
with media capability numbers via a new media-specific attribute, with media capability numbers via a new media-specific attribute,
mscap, of the following form: mscap, of the following form:
a=mscap:<media caps star> <att field> <att value> a=mscap:<media caps star> <att field> <att value>
where <media caps star> is a (list of) media capability number(s), where <media caps star> is a (list of) media capability number(s),
<att field> is the attribute name, and <att value> is the value field <att field> is the attribute name, and <att value> is the value field
for the named attribute. Note that the media capability numbers for the named attribute. Note that the media capability numbers
refer to media format capabilities specified elsewhere in the SDP refer to media format capabilities specified elsewhere in the SDP
("rmcap" and/or "omcap"). The media capability numbers may include a ("rmcap" and/or "omcap"). If a range of capability numbers is
wildcard ("*"), which will be used instead of any payload type specified, the first (leftmost) capability number MUST be strictly
mappings in the resulting SDP (see, e.g. RFC 4585 [RFC4585] and the smaller than the second (rightmost). The media capability numbers
example below). In ABNF, we have: may include a wildcard ("*"), which will be used instead of any
payload type mappings in the resulting SDP (see, e.g. RFC 4585
[RFC4585] and the example below). In ABNF, we have:
media-specific-capability = "a=mscap:" media-specific-capability = "a=mscap:"
media-caps-star media-caps-star
1*WSP att-field ; from RFC4566 1*WSP att-field ; from RFC4566
1*WSP att-value ; from RFC4566 1*WSP att-value ; from RFC4566
media-caps-star = media-cap-star-element media-caps-star = media-cap-star-element
*("," media-cap-star-element) *("," media-cap-star-element)
media-cap-star-element = (media-cap-num [wildcard]) media-cap-star-element = (media-cap-num [wildcard])
/ (media-cap-num-range [wildcard]) / (media-cap-num-range [wildcard])
wildcard = "*" wildcard = "*"
skipping to change at page 21, line 39 skipping to change at page 21, line 47
A resulting attribute that is not a legal SDP attribute as specified A resulting attribute that is not a legal SDP attribute as specified
by RFC4566 MUST be ignored by the receiver. by RFC4566 MUST be ignored by the receiver.
If a media capability number (or range) contains a wildcard character If a media capability number (or range) contains a wildcard character
at the end, any payload type mapping specified for that media at the end, any payload type mapping specified for that media
specific capability (or range of capabilities) will use the wildcard specific capability (or range of capabilities) will use the wildcard
character in the resulting SDP instead of the payload type specified character in the resulting SDP instead of the payload type specified
in the payload type mapping ("pt" parameter) in the configuration in the payload type mapping ("pt" parameter) in the configuration
attribute. attribute.
A single mscap line may refer to multiple media capabilities; this is A single mscap line may refer to multiple media capabilities by use
equivalent to multiple mscap lines, each with the same attribute of a capability number range; this is equivalent to multiple mscap
values (but different media capability numbers), one line per media lines, each with the same attribute values (but different media
capability. capability numbers), one line per media capability.
Multiple mscap lines may refer to the same media capability, but, Multiple mscap lines may refer to the same media capability, but,
unlike the mfcap attribute, no concatenation operation is defined. unlike the mfcap attribute, no concatenation operation is defined.
Hence, multiple mscap lines applied to the same media capability is Hence, multiple mscap lines applied to the same media capability is
equivalent to multiple lines of the specified attribute in a equivalent to multiple lines of the specified attribute in a
conventional media record. conventional media record.
Here is an example with the rtcp-fb attribute, modified from an Here is an example with the rtcp-fb attribute, modified from an
example in RFC 5104 [RFC5104] (with the session-level and audio media example in RFC 5104 [RFC5104] (with the session-level and audio media
omitted). If the offer contains a media block like the following omitted). If the offer contains a media block like the following
skipping to change at page 23, line 23 skipping to change at page 23, line 29
payload type number to be associated with each RTP-based media format payload type number to be associated with each RTP-based media format
in a potential, actual, or latent configuration. We define the in a potential, actual, or latent configuration. We define the
payload type number mapping parameter, payload-number-config-list, in payload type number mapping parameter, payload-number-config-list, in
accordance with the extension-config-list format defined in RFC 5939 accordance with the extension-config-list format defined in RFC 5939
[RFC5939]. In ABNF: [RFC5939]. In ABNF:
payload-number-config-list = ["+"] "pt=" media-map-list payload-number-config-list = ["+"] "pt=" media-map-list
media-map-list = media-map *("," media-map) media-map-list = media-map *("," media-map)
media-map = media-cap-num ":" payload-type-number media-map = media-cap-num ":" payload-type-number
; media-cap-num is defined in 3.3.1 ; media-cap-num is defined in 3.3.1
payload-type-number = 1*3(DIGIT) ; RTP payload type number payload-type-number = NonZeroDigit *2(DIGIT) ; RTP payload
; type number
The example in Section 3.3.7 shows how the parameters from the rmcap The example in Section 3.3.7 shows how the parameters from the rmcap
line are mapped to payload type numbers from the pcfg "pt" parameter. line are mapped to payload type numbers from the pcfg "pt" parameter.
The use of the plus sign ("+") is described in RFC 5939 [RFC5939]. The use of the plus sign ("+") is described in RFC 5939 [RFC5939].
A latent configuration represents a future capability, hence the pt= A latent configuration represents a future capability, hence the pt=
parameter is not directly meaningful in the lcfg attribute because no parameter is not directly meaningful in the lcfg attribute because no
actual media session is being offered or accepted; it is permitted in actual media session is being offered or accepted; it is permitted in
order to tie any payload type number parameters within attributes to order to tie any payload type number parameters within attributes to
the proper media format. A primary example is the case of format the proper media format. A primary example is the case of format
parameters for the Redundant Audio Data (RED) payload, which are parameters for the Redundant Audio Data (RED) payload, which are
payload type numbers. Specific payload type numbers used in a latent payload type numbers. Specific payload type numbers used in a latent
configuration MAY be interpreted as suggestions to be used in any configuration MAY be interpreted as suggestions to be used in any
future offer based on the latent configuration, but they are not future offer based on the latent configuration, but they are not
binding; the offerer and/or answerer may use any payload type numbers binding; the offerer and/or answerer may use any payload type numbers
each deems appropriate. The use of explicit payload type numbers for each deems appropriate. The use of explicit payload type numbers for
latent configurations can be avoided by use of the parameter latent configurations can be avoided by use of the parameter
substitution rule of Section 3.3.7. Future extensions are also substitution rule of Section 3.3.7. Future extensions are also
permitted. permitted. Note that leading zeroes are not permitted.
3.3.4.3. The Media Type Parameter 3.3.4.3. The Media Type Parameter
When a latent configuration is specified (always at the media level), When a latent configuration is specified (always at the media level),
indicating the ability to support an additional media stream, it is indicating the ability to support an additional media stream, it is
necessary to specify the media type (audio, video, etc.) as well as necessary to specify the media type (audio, video, etc.) as well as
the format and transport type. The media type parameter is defined the format and transport type. The media type parameter is defined
in ABNF as in ABNF as
media-type = ["+"] "mt=" media; media defined in RFC4566 media-type = ["+"] "mt=" media; media defined in RFC4566
At present, the media-type parameter is used only in the latent At present, the media-type parameter is used only in the latent
configuration attribute, and the use of the "+" prefix to specify configuration attribute, and the use of the "+" prefix to specify
that the entire attribute line is to be ignored if the mt= parameter that the entire attribute line is to be ignored if the mt= parameter
is not understood, is unnecessary. However, if the media-type is not understood, is unnecessary. However, if the media-type
parameter is later added to an existing capability attribute such as parameter is later added to an existing capability attribute such as
pcfg, then the "+" would be useful. The media format(s) and pcfg, then the "+" would be useful. The media format(s) and
transport type(s) are specified using the media configuration transport type(s) are specified using the media configuration
parameter ("+m=") defined above, and the transport parameter ("t=") parameter ("+m=") defined above, and the transport parameter ("t=")
skipping to change at page 25, line 21 skipping to change at page 25, line 29
for an additional simultaneous stream or to reconfigure an existing for an additional simultaneous stream or to reconfigure an existing
stream in a subsequent offer/answer exchange. stream in a subsequent offer/answer exchange.
The latent configuration attribute is of the form: The latent configuration attribute is of the form:
a=lcfg:<config-number> <latent-cfg-list> a=lcfg:<config-number> <latent-cfg-list>
which adheres to the SDP [RFC4566] "attribute" production with att- which adheres to the SDP [RFC4566] "attribute" production with att-
field and att-value defined as: field and att-value defined as:
att-field = "lcfg" att-field = "lcfg"
att-value = config-number 1*WSP lcfg-cfg-list att-value = config-number 1*WSP lcfg-cfg-list
config-number = 1*10(DIGIT) ; defined in RFC5234 config-number = NonZeroDigit *9(DIGIT) ; DIGIT defined in RFC5234
lcfg-cfg-list = media-type 1*WSP pot-cfg-list lcfg-cfg-list = media-type 1*WSP pot-cfg-list
; as defined in RFC5939 ; as defined in RFC5939
; and extended herein ; and extended herein
The media-type (mt=) parameter identifies the media type (audio, The media-type (mt=) parameter identifies the media type (audio,
video, etc.) to be associated with the latent media stream, and MUST video, etc.) to be associated with the latent media stream, and MUST
be present. The pot-cfg-list MUST contain a transport-protocol- be present. The pot-cfg-list MUST contain a transport-protocol-
config-list (t=) parameter and a media-config-list (m=) parameter. config-list (t=) parameter and a media-config-list (m=) parameter.
The pot-cfg-list MUST NOT contain more than one instance of each type The pot-cfg-list MUST NOT contain more than one instance of each type
of parameter list. As specified in RFC 5939 [RFC5939], the use of of parameter list. As specified in RFC 5939 [RFC5939], the use of
the "+" prefix with a parameter indicates that the entire the "+" prefix with a parameter indicates that the entire
configuration MUST be ignored if the parameter is not understood; configuration MUST be ignored if the parameter is not understood;
otherwise, the parameter itself may be ignored. otherwise, the parameter itself may be ignored.
skipping to change at page 26, line 25 skipping to change at page 26, line 33
could be specified by including "a=sescap:1 1,2|3". One audio stream could be specified by including "a=sescap:1 1,2|3". One audio stream
and two video streams could be specified by including "a=sescap:2 and two video streams could be specified by including "a=sescap:2
1,2,3" in the offer. In order to permit combinations of latent and 1,2,3" in the offer. In order to permit combinations of latent and
potential configurations in session capabilities, latent potential configurations in session capabilities, latent
configuration numbers MUST be different from those used for potential configuration numbers MUST be different from those used for potential
configurations. This restriction is especially important if the configurations. This restriction is especially important if the
offerer does not require cmed-v0 capability and the recipient of the offerer does not require cmed-v0 capability and the recipient of the
offer doesn't support it. If the lcfg attribute is not recognized, offer doesn't support it. If the lcfg attribute is not recognized,
the capability attributes intended to be associated with it may be the capability attributes intended to be associated with it may be
confused with those associated with a potential configuration of some confused with those associated with a potential configuration of some
other media stream. other media stream. Note also that leading zeroes are not permitted
in configuration numbers.
If a cryptographic attribute, such as the SDES "a=crypto:" attribute If a cryptographic attribute, such as the SDES "a=crypto:" attribute
[RFC4568], is referenced by a latent configuration through an acap [RFC4568], is referenced by a latent configuration through an acap
attribute, any keying material required in the conventional attribute, any keying material required in the conventional
attribute, such as the SDES key/salt string, MUST be included in attribute, such as the SDES key/salt string, MUST be included in
order to satisfy formatting rules for the attribute. Since the order to satisfy formatting rules for the attribute. Since the
keying material will be visible but not actually used at this stage keying material will be visible but not actually used at this stage
(since it's a latent configuration), the value(s) of the keying (since it's a latent configuration), the value(s) of the keying
material SHOULD NOT be a real value used for real exchange of media, material MUST NOT be a real value used for real exchange of media,
and the receiver of the lcfg attribute MUST ignore the values. and the receiver of the lcfg attribute MUST ignore the values.
3.3.6. Enhanced Potential Configuration Attribute 3.3.6. Enhanced Potential Configuration Attribute
The present work requires new extensions (parameters) for the pcfg The present work requires new extensions (parameters) for the pcfg
attribute defined in the SDP Capability Negotiation base protocol attribute defined in the SDP Capability Negotiation base protocol
[RFC5939]. The parameters and their definitions are "borrowed" from [RFC5939]. The parameters and their definitions are "borrowed" from
the definitions provided for the latent configuration attribute in the definitions provided for the latent configuration attribute in
Section 3.3.5. The expanded ABNF definition of the pcfg attribute is Section 3.3.5. The expanded ABNF definition of the pcfg attribute is
a=pcfg: <config-number> [<pot-cfg-list>] a=pcfg: <config-number> [<pot-cfg-list>]
where where
config-number = 1*DIGIT ;defined in [RFC5234] config-number = 1*DIGIT ;defined in [RFC5234]
pot-cfg-list = pot-config *(1*WSP pot-config) pot-cfg-list = pot-config *(1*WSP pot-config)
pot-config = attribute-config-list / ;def in [RFC5939] pot-config = attribute-config-list / ;def in [RFC5939]
transport-protocol-config-list / ;defined in [RFC5939] transport-protocol-config-list / ;defined in [RFC5939]
extension-config-list / ;[RFC5939] extension-config-list / ;[RFC5939]
media-config-list / ; Section 3.3.4.1 media-config-list / ; Section 3.3.4.1
payload-number-config-list ; Section 3.3.4.2 payload-number-config-list ; Section 3.3.4.2
Except for the extension-config-list, the pot-cfg-list MUST NOT Except for the extension-config-list, the pot-cfg-list MUST NOT
contain more than one instance of each parameter list. contain more than one instance of each parameter list.
skipping to change at page 31, line 41 skipping to change at page 31, line 41
The session capability attribute is a session-level attribute The session capability attribute is a session-level attribute
described by: described by:
"a=sescap:" <session num> <list of configs> "a=sescap:" <session num> <list of configs>
which corresponds to the standard value attribute definition with which corresponds to the standard value attribute definition with
att-field = "sescap" att-field = "sescap"
att-value = session-num 1*WSP list-of-configs att-value = session-num 1*WSP list-of-configs
[1*WSP optional-configs] [1*WSP optional-configs]
session-num = 1*10(DIGIT) ; defined in RFC5234 session-num = NonZeroDigit *9(DIGIT) ; DIGIT defined
; in RFC5234
list-of-configs = alt-config *("," alt-config) list-of-configs = alt-config *("," alt-config)
optional-configs = "[" list-of-configs "]" optional-configs = "[" list-of-configs "]"
alt-config = config-number *("|" config-number) alt-config = config-number *("|" config-number)
; config-number defined in RFC5939
The session-num identifies the session; a lower-number session is The session-num identifies the session: a lower-number session is
preferred over a higher-numbered session. Each alt-config list preferred over a higher-number session, and leading zeroes are not
specifies alternative media configurations within the session; permitted. Each alt-config list specifies alternative media
preference is based on config-num as specified in RFC 5939 [RFC5939]. configurations within the session; preference is based on config-num
Note that the session preference order, when present, takes as specified in RFC 5939 [RFC5939]. Note that the session preference
precedence over the individual media stream configuration preference order, when present, takes precedence over the individual media
order. stream configuration preference order.
Use of session capability attributes requires that configuration Use of session capability attributes requires that configuration
numbers assigned to potential and latent configurations MUST be numbers assigned to potential and latent configurations MUST be
unique across the entire session; RFC 5939 [RFC5939] requires only unique across the entire session; RFC 5939 [RFC5939] requires only
that pcfg configuration numbers be unique within a media description. that pcfg configuration numbers be unique within a media description.
Also, leading zeroes are not permitted.
As an example, consider an endpoint that is capable of supporting an As an example, consider an endpoint that is capable of supporting an
audio stream with either one H.264 video stream or two H.263 video audio stream with either one H.264 video stream or two H.263 video
streams with a floor control stream. In the latter case, the second streams with a floor control stream. In the latter case, the second
video stream is optional. The SDP offer might look like the video stream is optional. The SDP offer might look like the
following (offering audio, an H.263 video streams, BFCP and another following (offering audio, an H.263 video streams, BFCP and another
optional H.263 video stream)- the empty lines are added for optional H.263 video stream)- the empty lines are added for
readability only (not part of valid SDP): readability only (not part of valid SDP):
v=0 v=0
skipping to change at page 38, line 6 skipping to change at page 38, line 10
This is due to those parameters being effectively media-level This is due to those parameters being effectively media-level
parameters. If session-level attributes are needed, the "acap" parameters. If session-level attributes are needed, the "acap"
attribute defined in RFC 5939 [RFC5939] can be used, however it attribute defined in RFC 5939 [RFC5939] can be used, however it
does not provide for media format-specific instantiation. does not provide for media format-specific instantiation.
Inclusion of the above does not constitute an offer to use the Inclusion of the above does not constitute an offer to use the
capabilities; a potential configuration is needed for that. If the capabilities; a potential configuration is needed for that. If the
offerer wants to offer one or more of the media capabilities above, offerer wants to offer one or more of the media capabilities above,
they MUST be included as part of a potential configuration (pcfg) they MUST be included as part of a potential configuration (pcfg)
attribute as defined in Section 3.3.4. Each potential configuration attribute as defined in Section 3.3.4. Each potential configuration
MUST include a config-number that is unique in the entire SDP (note MUST include a config-number, and each config-number MUST be unique
that this differs from RFC 5939 [RFC5939], which only requires in the entire SDP (note that this differs from RFC 5939 [RFC5939],
uniqueness within a media description). Also, the config-number MUST which only requires uniqueness within a media description). Also,
NOT overlap with any config-number used by a latent configuration in the config-number MUST NOT overlap with any config-number used by a
the SDP. As described in RFC 5939 [RFC5939], lower config-numbers latent configuration in the SDP. As described in RFC 5939 [RFC5939],
indicate a higher preference; the ordering still applies within a lower config-numbers indicate a higher preference; the ordering still
given media description only though. applies within a given media description only though.
For a media capability to be included in a potential configuration, For a media capability to be included in a potential configuration,
there MUST be an "m=" parameter in the pcfg attribute referencing the there MUST be an "m=" parameter in the pcfg attribute referencing the
media capability number in question. When one or more media media capability number in question. When one or more media
capabilities are included in an offered potential configuration capabilities are included in an offered potential configuration
(pcfg), they completely replace the list of media formats offered in (pcfg), they completely replace the list of media formats offered in
the actual configuration (m= line). Any attributes included for the actual configuration (m= line). Any attributes included for
those formats remain in the SDP though (e.g., rtpmap, fmtp, etc.). those formats remain in the SDP though (e.g., rtpmap, fmtp, etc.).
For non-RTP based media formats, the format-name (from the "omcap" For non-RTP based media formats, the format-name (from the "omcap"
media capability) is simply added to the "m=" line as a media format media capability) is simply added to the "m=" line as a media format
skipping to change at page 56, line 7 skipping to change at page 56, line 7
feature. As for the initial SDP Capability Negotiation work feature. As for the initial SDP Capability Negotiation work
[RFC5939], the SDP answer is formulated in such a way that it always [RFC5939], the SDP answer is formulated in such a way that it always
carries the selected media encoding for every media stream selected. carries the selected media encoding for every media stream selected.
Pending an understanding of capabilities negotiation, the middlebox Pending an understanding of capabilities negotiation, the middlebox
should examine the answer SDP to obtain the best picture of the media should examine the answer SDP to obtain the best picture of the media
streams being established. As always, middleboxes can best do their streams being established. As always, middleboxes can best do their
job if they fully understand media capabilities negotiation. job if they fully understand media capabilities negotiation.
7. Changes from previous versions 7. Changes from previous versions
7.1. Changes from version 15 7.1. Changes from version 16
o Changed grammer covering numeric values to forbid use of leading
zeroes, and added text to that effect as well.
o Clarified that all numerical ranges must be strictly increasing
(from leftmost number to rightmost number).
o Now mandating against (rather than recommending against) using
real keying material in a crypto attribute when it is used for a
latent configuration only.
o Reworded Offer section description of config-number use in
potential configurations to make it clear that all config-numbers
must be unique.
7.2. Changes from version 15
o Fixed style of RFC references to be consistent in body of o Fixed style of RFC references to be consistent in body of
document. document.
o Minor updates to address Gen-ART review comments. o Minor updates to address Gen-ART review comments.
7.2. Changes from version 14 7.3. Changes from version 14
o Updated IANA Considerations to fix configuration parameter o Updated IANA Considerations to fix configuration parameter
registry. Document now updates RFC 5939 [RFC5939] (IANA registry. Document now updates RFC 5939 [RFC5939] (IANA
considerations only) considerations only)
o Minor ABNF updates to fix errors. o Minor ABNF updates to fix errors.
o Editorial nit fixes to address protocol write-up review. o Editorial nit fixes to address protocol write-up review.
7.3. Changes from version 13 7.4. Changes from version 13
o Various editorial clarifications and updates to address review o Various editorial clarifications and updates to address review
comments. comments.
7.4. Changes from version 12 7.5. Changes from version 12
o Removed "dummy" form in the pcfg payload-type-number, since the o Removed "dummy" form in the pcfg payload-type-number, since the
functionality is redundant with the non-RTP media capability functionality is redundant with the non-RTP media capability
(omcap) and it was inconsistent with other RTP payload type (omcap) and it was inconsistent with other RTP payload type
operation. operation.
o Clarified that latent configuration attribute (lcfg) can only be o Clarified that latent configuration attribute (lcfg) can only be
used at the media level and hence (technically) as part of a media used at the media level and hence (technically) as part of a media
description description
o Rewrote offer/answer sections and expanded significantly on offer/ o Rewrote offer/answer sections and expanded significantly on offer/
answer operation. answer operation.
o Updated security considerations o Updated security considerations
o Various minor editorial clarifications and changes. o Various minor editorial clarifications and changes.
7.5. Changes from version 11 7.6. Changes from version 11
o Corrected several statements implying lcfg was a session-level o Corrected several statements implying lcfg was a session-level
attribute. attribute.
o Added non-RTP based media format capabilities ("a=omcap") and o Added non-RTP based media format capabilities ("a=omcap") and
renamed "mcap" to "rmcap" renamed "mcap" to "rmcap"
7.6. Changes from version 10 7.7. Changes from version 10
o Defined the latent configuration attribute as a media-level o Defined the latent configuration attribute as a media-level
attribute because it specifies a possible future media stream. attribute because it specifies a possible future media stream.
Added text to clarify how to specify alternative configurations of Added text to clarify how to specify alternative configurations of
a single latent stream and/or multiple streams. a single latent stream and/or multiple streams.
o Improved the definition of the session capability attribute to o Improved the definition of the session capability attribute to
permit both required configurations and optional configurations - permit both required configurations and optional configurations -
latent configurations cannot be required because they have not yet latent configurations cannot be required because they have not yet
been offered. been offered.
skipping to change at page 57, line 36 skipping to change at page 58, line 5
o Changed various "must", etc., terms to normative terms ("MUST", o Changed various "must", etc., terms to normative terms ("MUST",
etc.) as appropriate, in Section 3.3.5Section 3.3.6.1 etc.) as appropriate, in Section 3.3.5Section 3.3.6.1
Section 3.3.6.3 and Section 3.3.8 Section 3.3.6.3 and Section 3.3.8
o Attempted to clarify the substitution mechanism in Section 3.3.7 o Attempted to clarify the substitution mechanism in Section 3.3.7
and improve its uniqueness. and improve its uniqueness.
o Made various editorial changes, including changing the title in o Made various editorial changes, including changing the title in
the header, and removing numbering from some SDP examples. the header, and removing numbering from some SDP examples.
7.7. Changes from version 09 7.8. Changes from version 09
o Additional corrections to latent media stream example in o Additional corrections to latent media stream example in
Section 4.3 Section 4.3
o Fixed up attribute formatting examples and corresponding ABNF. o Fixed up attribute formatting examples and corresponding ABNF.
o Removed preference rule for latent configurations. o Removed preference rule for latent configurations.
o Various spelling and other editorial changes were made. o Various spelling and other editorial changes were made.
o updated cross-references. o updated cross-references.
7.8. Changes from version 08 7.9. Changes from version 08
The major change is in Section 4.3, Latent Media Streams, fixing the The major change is in Section 4.3, Latent Media Streams, fixing the
syntax of the answer. All the other changes are editorial. syntax of the answer. All the other changes are editorial.
7.9. Changes from version 04 7.10. Changes from version 04
o The definitions for bcap, ccap, icap, and kcap attributes have o The definitions for bcap, ccap, icap, and kcap attributes have
been removed, and are to be defined in another document. been removed, and are to be defined in another document.
o Corrected formatting of m= and p= configuration parameters to o Corrected formatting of m= and p= configuration parameters to
conform to extension-config-list form defined in RFC 5939 conform to extension-config-list form defined in RFC 5939
[RFC5939] [RFC5939]
o Reorganized definitions of new parameters to make them easier to o Reorganized definitions of new parameters to make them easier to
find in document. find in document.
o Added ability to renegotiate capabilities when modifying the o Added ability to renegotiate capabilities when modifying the
session (Section 3.4.4). session (Section 3.4.4).
o Made various editorial changes, clarifications, and typo o Made various editorial changes, clarifications, and typo
corrections. corrections.
7.10. Changes from version 03 7.11. Changes from version 03
o A new session capability attribute (sescap) has been added to o A new session capability attribute (sescap) has been added to
permit specification of acceptable media stream combinations. permit specification of acceptable media stream combinations.
o Capability attribute definitions corresponding to the i, c, b, and o Capability attribute definitions corresponding to the i, c, b, and
k SDP line types have been added for completeness. k SDP line types have been added for completeness.
o Use of the pcfg: attribute in SDP answers has been included in o Use of the pcfg: attribute in SDP answers has been included in
order to conveniently return information in the answer about order to conveniently return information in the answer about
acceptable configurations in the media stream offer. acceptable configurations in the media stream offer.
skipping to change at page 59, line 12 skipping to change at page 59, line 26
o The description of the mscap attribute has been modified to make o The description of the mscap attribute has been modified to make
it clear that it should not be used to generate undefined SDP it clear that it should not be used to generate undefined SDP
attributes, or to "extend" existing attributes. attributes, or to "extend" existing attributes.
o <ms-parameters> are made optional in the mscap attribute o <ms-parameters> are made optional in the mscap attribute
definition. definition.
o "AMR" changed to "AMR-WB" in cases in which the sample rate is o "AMR" changed to "AMR-WB" in cases in which the sample rate is
16000. 16000.
7.11. Changes from version 02 7.12. Changes from version 02
This version contains several detail changes intended to simplify This version contains several detail changes intended to simplify
capability processing and mapping into conventional SDP media blocks. capability processing and mapping into conventional SDP media blocks.
o The "mcap" attribute is enhanced to include the role of the "ecap" o The "mcap" attribute is enhanced to include the role of the "ecap"
attribute; the latter is eliminated. attribute; the latter is eliminated.
o The "fcap" attribute has been renamed "mfcap". New replacement o The "fcap" attribute has been renamed "mfcap". New replacement
rules vis-a-vis fmtp attributes in the base media specification rules vis-a-vis fmtp attributes in the base media specification
have been added. have been added.
skipping to change at page 59, line 42 skipping to change at page 60, line 9
attribute. attribute.
o A new parameter, "mt=" is added to the latent configuration o A new parameter, "mt=" is added to the latent configuration
attribute (lcfg) to specify the media stream type (audio, video, attribute (lcfg) to specify the media stream type (audio, video,
etc.) when the lcfg is declared at the session level. etc.) when the lcfg is declared at the session level.
o The examples are expanded. o The examples are expanded.
o Numerous typos and misspellings have been corrected. o Numerous typos and misspellings have been corrected.
7.12. Changes from version 01 7.13. Changes from version 01
The documents adds a new attribute for specifying bandwidth The documents adds a new attribute for specifying bandwidth
capability and a parameter to list in the potential configuration. capability and a parameter to list in the potential configuration.
Other changes are to align the document with the terminology and Other changes are to align the document with the terminology and
attribute names from draft-ietf-mmusic-sdp-capability-negotiation-07. attribute names from draft-ietf-mmusic-sdp-capability-negotiation-07.
The document also clarifies some previous open issues. The document also clarifies some previous open issues.
7.13. Changes from version 00 7.14. Changes from version 00
The major changes include taking out the "mcap" and "cptmap" The major changes include taking out the "mcap" and "cptmap"
parameter. The mapping of payload type is now in the "pt" parameter parameter. The mapping of payload type is now in the "pt" parameter
of "pcfg". Media subtype need to explicitly defined in the "cmed" of "pcfg". Media subtype need to explicitly defined in the "cmed"
attribute if referenced in the "pcfg" attribute if referenced in the "pcfg"
8. Acknowledgements 8. Acknowledgements
This document is heavily influenced by the discussions and work done This document is heavily influenced by the discussions and work done
by the SDP Capability Negotiation Design team. The following people by the SDP Capability Negotiation Design team. The following people
 End of changes. 40 change blocks. 
79 lines changed or deleted 108 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/