draft-ietf-mmusic-sdp-capability-negotiation-11.txt   draft-ietf-mmusic-sdp-capability-negotiation-12.txt 
MMUSIC Working Group F. Andreasen MMUSIC Working Group F. Andreasen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended Status: Proposed Standard February 14, 2010 Intended Status: Proposed Standard February 28, 2010
Expires: August 2010 Expires: August 2010
SDP Capability Negotiation SDP Capability Negotiation
draft-ietf-mmusic-sdp-capability-negotiation-11.txt draft-ietf-mmusic-sdp-capability-negotiation-12.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 14, 2010. This Internet-Draft will expire on August 28, 2010.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 48 skipping to change at page 2, line 48
The document defines a general SDP Capability Negotiation framework. The document defines a general SDP Capability Negotiation framework.
It also specifies how to provide attributes and transport protocols It also specifies how to provide attributes and transport protocols
as capabilities and negotiate them using the framework. Extensions as capabilities and negotiate them using the framework. Extensions
for other types of capabilities (e.g. media types and media formats) for other types of capabilities (e.g. media types and media formats)
may be provided in other documents. may be provided in other documents.
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
2. Conventions used in this document..............................7 2. Conventions used in this document..............................7
3. SDP Capability Negotiation Solution............................7 3. SDP Capability Negotiation Solution............................8
3.1. SDP Capability Negotiation Model..........................8 3.1. SDP Capability Negotiation Model..........................8
3.2. Solution Overview........................................11 3.2. Solution Overview........................................11
3.3. Version and Extension Indication Attributes..............15 3.3. Version and Extension Indication Attributes..............15
3.3.1. Supported Capability Negotiation Extensions Attribute15 3.3.1. Supported Capability Negotiation Extensions Attribute15
3.3.2. Required Capability Negotiation Extensions Attribute17 3.3.2. Required Capability Negotiation Extensions Attribute17
3.4. Capability Attributes....................................19 3.4. Capability Attributes....................................19
3.4.1. Attribute Capability Attribute......................19 3.4.1. Attribute Capability Attribute......................19
3.4.2. Transport Protocol Capability Attribute.............21 3.4.2. Transport Protocol Capability Attribute.............21
3.4.3. Extension Capability Attributes.....................23 3.4.3. Extension Capability Attributes.....................23
3.5. Configuration Attributes.................................24 3.5. Configuration Attributes.................................24
skipping to change at page 3, line 45 skipping to change at page 3, line 45
4.4. SRTP with Session-Level MIKEY and Media Level Security 4.4. SRTP with Session-Level MIKEY and Media Level Security
Descriptions as Alternatives..................................69 Descriptions as Alternatives..................................69
5. Security Considerations.......................................72 5. Security Considerations.......................................72
6. IANA Considerations...........................................75 6. IANA Considerations...........................................75
6.1. New SDP Attributes.......................................75 6.1. New SDP Attributes.......................................75
6.2. New SDP Capability Negotiation Option Tag Registry.......77 6.2. New SDP Capability Negotiation Option Tag Registry.......77
6.3. New SDP Capability Negotiation Potential Configuration 6.3. New SDP Capability Negotiation Potential Configuration
Parameter Registry............................................77 Parameter Registry............................................77
7. Acknowledgments...............................................78 7. Acknowledgments...............................................78
8. Change Log....................................................78 8. Change Log....................................................78
8.1. draft-ietf-mmusic-sdp-capability-negotiation-11..........78 8.1. draft-ietf-mmusic-sdp-capability-negotiation-12..........78
8.2. draft-ietf-mmusic-sdp-capability-negotiation-10..........79 8.2. draft-ietf-mmusic-sdp-capability-negotiation-11..........78
8.3. draft-ietf-mmusic-sdp-capability-negotiation-09..........80 8.3. draft-ietf-mmusic-sdp-capability-negotiation-10..........79
8.4. draft-ietf-mmusic-sdp-capability-negotiation-08..........80 8.4. draft-ietf-mmusic-sdp-capability-negotiation-09..........80
8.5. draft-ietf-mmusic-sdp-capability-negotiation-07..........80 8.5. draft-ietf-mmusic-sdp-capability-negotiation-08..........80
8.6. draft-ietf-mmusic-sdp-capability-negotiation-06..........81 8.6. draft-ietf-mmusic-sdp-capability-negotiation-07..........81
8.7. draft-ietf-mmusic-sdp-capability-negotiation-05..........82 8.7. draft-ietf-mmusic-sdp-capability-negotiation-06..........81
8.8. draft-ietf-mmusic-sdp-capability-negotiation-04..........83 8.8. draft-ietf-mmusic-sdp-capability-negotiation-05..........83
8.9. draft-ietf-mmusic-sdp-capability-negotiation-03..........84 8.9. draft-ietf-mmusic-sdp-capability-negotiation-04..........84
8.10. draft-ietf-mmusic-sdp-capability-negotiation-02.........84 8.10. draft-ietf-mmusic-sdp-capability-negotiation-03.........84
8.11. draft-ietf-mmusic-sdp-capability-negotiation-01.........85 8.11. draft-ietf-mmusic-sdp-capability-negotiation-02.........84
8.12. draft-ietf-mmusic-sdp-capability-negotiation-00.........86 8.12. draft-ietf-mmusic-sdp-capability-negotiation-01.........85
8.13. draft-ietf-mmusic-sdp-capability-negotiation-00.........86
9. References....................................................87 9. References....................................................87
9.1. Normative References.....................................87 9.1. Normative References.....................................87
9.2. Informative References...................................87 9.2. Informative References...................................87
Author's Address.................................................90 Author's Address.................................................90
1. Introduction 1. Introduction
The Session Description Protocol (SDP) was intended for describing The Session Description Protocol (SDP) was intended for describing
multimedia sessions for the purposes of session announcement, multimedia sessions for the purposes of session announcement,
session invitation, and other forms of multimedia session session invitation, and other forms of multimedia session
skipping to change at page 12, line 31 skipping to change at page 12, line 31
session description. Extension capabilities can be included session description. Extension capabilities can be included
as well. as well.
o Extensions to the offer/answer model that allow for capabilities o Extensions to the offer/answer model that allow for capabilities
and potential configurations to be included in an offer. and potential configurations to be included in an offer.
Capabilities can be provided at the session level and the media Capabilities can be provided at the session level and the media
level. Potential configurations can be included only at the media level. Potential configurations can be included only at the media
level, where they constitute alternative offers that may be level, where they constitute alternative offers that may be
accepted by the answerer instead of the actual configuration(s) accepted by the answerer instead of the actual configuration(s)
included in the "m=" line(s) and associated parameters. The included in the "m=" line(s) and associated parameters. The
mechanisms defined in this document enables potential mechanisms defined in this document enable potential
configurations to change the transport protocol, add new configurations to change the transport protocol, add new
attributes, as well as remove all existing attributes from the attributes as well as remove all existing attributes from the
actual configuration. The answerer indicates which (if any) of actual configuration. The answerer indicates which (if any) of
the potential configurations it used to form the answer by the potential configurations it used to form the answer by
including the actual configuration attribute ("a=acfg") in the including the actual configuration attribute ("a=acfg") in the
answer. Capabilities may be included in answers as well, where answer. Capabilities may be included in answers as well, where
they can aid in guiding a subsequent new offer. they can aid in guiding a subsequent new offer.
The mechanism is illustrated by the offer/answer exchange below, The mechanism is illustrated by the offer/answer exchange below,
where Alice sends an offer to Bob: where Alice sends an offer to Bob:
Alice Bob Alice Bob
skipping to change at page 18, line 42 skipping to change at page 18, line 42
and/or media level. If support for an extension is needed only in and/or media level. If support for an extension is needed only in
one or more specific potential configurations, the potential one or more specific potential configurations, the potential
configuration provides a way to indicate that instead (see Section configuration provides a way to indicate that instead (see Section
3.5.1. ). Support for the basic negotiation framework is implied by 3.5.1. ). Support for the basic negotiation framework is implied by
the presence of an "a=pcfg" attribute (see Section 3.5.1. ) and the presence of an "a=pcfg" attribute (see Section 3.5.1. ) and
hence it is not required to include the "a=creq" attribute with the hence it is not required to include the "a=creq" attribute with the
base option-tag ("cap-v0"). base option-tag ("cap-v0").
A recipient that receives an SDP session description and does not A recipient that receives an SDP session description and does not
support one or more of the required extensions listed in a "creq" support one or more of the required extensions listed in a "creq"
attribute, MUST NOT perform the SDP Capability Negotiation defined attribute MUST NOT perform the SDP Capability Negotiation defined in
in this document. For non-supported extensions provided at the this document; instead the recipient MUST proceed as if the SDP
session-level, this implies that SDP Capability Negotiation MUST NOT Capability Negotiation attributes were not included in the first
be performed at all. For non-supported extensions at the media- place, i.e. the capability negotiation attributes are ignored. In
level, this implies that SDP Capability Negotiation MUST NOT be
performed for the media stream in question.
An entity that does not support the SDP Capability Negotiation
framework at all, will ignore these attributes (as well as the
other SDP Capability Negotiation attributes) and not perform any
SDP Capability Negotiation in the first place.
When an SDP session description recipient does not support one or
more required SDP Capability Negotiation extensions listed in the
option tags, the recipient MUST proceed as if the SDP Capability
Negotiation attributes were not included in the first place, i.e.
all the capability negotiation attributes should be ignored. In
that case, if the SDP session description recipient is an SDP that case, if the SDP session description recipient is an SDP
answerer [RFC3264], the recipient SHOULD include a "csup" attribute answerer [RFC3264], the recipient SHOULD include a "csup" attribute
in the resulting SDP session description answer listing the SDP in the resulting SDP session description answer listing the SDP
Capability Negotiation extensions it actually supports. Capability Negotiation extensions it actually supports.
This ensures that introduction of the SDP Capability Negotiation This ensures that introduction of the SDP Capability Negotiation
mechanism by itself does not lead to session failures. mechanism by itself does not lead to session failures
For non-supported extensions provided at the session-level, this
implies that SDP Capability Negotiation MUST NOT be performed at
all. For non-supported extensions at the media-level, this implies
that SDP Capability Negotiation MUST NOT be performed for the media
stream in question.
An entity that does not support the SDP Capability Negotiation
framework at all, will ignore these attributes (as well as the
other SDP Capability Negotiation attributes) and not perform any
SDP Capability Negotiation in the first place.
3.4. Capability Attributes 3.4. Capability Attributes
In this section, we present the new attributes associated with In this section, we present the new attributes associated with
indicating the capabilities for use by the SDP Capability indicating the capabilities for use by the SDP Capability
Negotiation. Negotiation.
3.4.1. Attribute Capability Attribute 3.4.1. Attribute Capability Attribute
Attributes and their associated values can be expressed as Attributes and their associated values can be expressed as
skipping to change at page 19, line 44 skipping to change at page 19, line 43
where <att-cap-num> is an integer between 1 and 2^31-1 (both where <att-cap-num> is an integer between 1 and 2^31-1 (both
included) used to number the attribute capability and <att-par> is included) used to number the attribute capability and <att-par> is
an attribute ("a=") in its "<attribute>" or <attribute>:<value>" an attribute ("a=") in its "<attribute>" or <attribute>:<value>"
form, i.e., excluding the "a=" part (see [RFC4566]). The attribute form, i.e., excluding the "a=" part (see [RFC4566]). The attribute
can be provided at the session-level and the media-level. can be provided at the session-level and the media-level.
The "acap" attribute adheres to the RFC 4566 "attribute" production, The "acap" attribute adheres to the RFC 4566 "attribute" production,
with an att-value defined as follows: with an att-value defined as follows:
att-value = att-cap-num 1*WSP att-par att-value = att-cap-num 1*WSP att-par
att-cap-num = 1*10(DIGIT) ;defined in [RFC5234] att-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
att-par = attribute ;defined in RFC 4566 att-par = attribute ;defined in [RFC4566]
Note that white space is not permitted before the att-cap-num. Note that white space is not permitted before the att-cap-num.
When the attribute capability contains a session-level attribute, When the attribute capability contains a session-level attribute,
that "acap" attribute can only be provided at the session level. that "acap" attribute can only be provided at the session level.
Conversely, media level attributes can be provided in attribute Conversely, media level attributes can be provided in attribute
capabilities at either the media level or session-level. The base capabilities at either the media level or session-level. The base
SDP Capability Negotiation framework however only defines procedures SDP Capability Negotiation framework however only defines procedures
for use of media-level attribute capabilities at the media level. for use of media-level attribute capabilities at the media level.
Implementations that conform only to the base framework MUST NOT Implementations that conform only to the base framework MUST NOT
skipping to change at page 20, line 49 skipping to change at page 20, line 47
a=acap:4 crypto:1 AES_CM_128_HMAC_SHA1_32 a=acap:4 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
The first two attribute capabilities provide attribute values for The first two attribute capabilities provide attribute values for
the ptime attribute. The third provides SRTP parameters by using the ptime attribute. The third provides SRTP parameters by using
MIKEY [RFC3830] with the key-mgmt attribute [RFC4567]. The fourth MIKEY [RFC3830] with the key-mgmt attribute [RFC4567]. The fourth
provides SRTP parameters by use of security descriptions with the provides SRTP parameters by use of security descriptions with the
crypto attribute [RFC4568]. Note that the line-wrapping and new- crypto attribute [RFC4568]. Note that the line-wrapping and new-
lines in example three and four are provided for formatting reasons lines in example three and four are provided for formatting reasons
only - they are not permitted in actual SDP session description. only - they are not permitted in actual SDP session descriptions.
Readers familiar with RFC 3407 may notice the similarity between Readers familiar with RFC 3407 may notice the similarity between
the RFC 3407 "cpar" attribute and the above. There are however a the RFC 3407 "cpar" attribute and the above. There are however a
couple of important differences, notably that the "acap" attribute couple of important differences, notably that the "acap" attribute
contains a handle that enables referencing it and it furthermore contains a handle that enables referencing it and it furthermore
supports only attributes (the "cpar" attribute defined in RFC 3407 supports only attributes (the "cpar" attribute defined in RFC 3407
supports bandwidth information as well). The "acap" attribute also supports bandwidth information as well). The "acap" attribute also
is not automatically associated with any particular capabilities. is not automatically associated with any particular capabilities.
See Section 3.14. for the relationship to RFC 3407. See Section 3.14. for the relationship to RFC 3407.
Attribute capabilities MUST NOT embed any capability negotiation Attribute capabilities MUST NOT embed any capability negotiation
parameters. This restriction applies to all the capability parameters. This restriction applies to all the capability
negotiation parameters defined in this document ("csup", "creq", negotiation parameters defined in this document ("csup", "creq",
"acap", "pcfg", and "acfg") as well as any extensions defined. The "acap", "tcap", "pcfg", and "acfg") as well as any capability
following examples are thus invalid attribute capabilities and MUST negotiation extensions defined. The following examples are thus
NOT be used: invalid attribute capabilities and MUST NOT be used:
a=acap:1 acap:2 foo:a ;Not allowed to embed "acap" a=acap:1 acap:2 foo:a ;Not allowed to embed "acap"
a=acap:2 a=pcfg:1 t=1 a=1 ;Not allowed to embed "pcfg" a=acap:2 a=pcfg:1 t=1 a=1 ;Not allowed to embed "pcfg"
The reason for this restriction is to avoid overly complex The reason for this restriction is to avoid overly complex
processing rules resulting from the expansion of such capabilities processing rules resulting from the expansion of such capabilities
into potential configurations (see Section 3.6.2. for further into potential configurations (see Section 3.6.2. for further
details). details).
skipping to change at page 21, line 48 skipping to change at page 21, line 48
where <trpr-cap-num> is an integer between 1 and 2^31-1 (both where <trpr-cap-num> is an integer between 1 and 2^31-1 (both
included) used to number the transport address capability for later included) used to number the transport address capability for later
reference, and <proto-list> is one or more <proto>, separated by reference, and <proto-list> is one or more <proto>, separated by
white space, as defined in the SDP "m=" line. The attribute can be white space, as defined in the SDP "m=" line. The attribute can be
provided at the session-level and the media-level. provided at the session-level and the media-level.
The "tcap" attribute adheres to the RFC 4566 "attribute" production, The "tcap" attribute adheres to the RFC 4566 "attribute" production,
with an att-value defined as follows: with an att-value defined as follows:
att-value = trpr-cap-num 1*WSP proto-list att-value = trpr-cap-num 1*WSP proto-list
trpr-cap-num = 1*10(DIGIT) ;defined in [RFC5234] trpr-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
proto-list = proto *(1*WSP proto) ; defined in RFC 4566 proto-list = proto *(1*WSP proto) ;defined in [RFC4566]
Note that white space is not permitted before the trpr-cap-num. Note that white space is not permitted before the trpr-cap-num.
The "tcap" attribute can be provided at the session-level and the The "tcap" attribute can be provided at the session-level and the
media-level. There MUST NOT be more than one "a=tcap" attribute at media-level. There MUST NOT be more than one "a=tcap" attribute at
the session-level and one at the media-level (one per media the session-level and one at the media-level (one per media
description in the latter case). Each occurrence of the "tcap" description in the latter case). Each occurrence of the "tcap"
attribute in the entire session description MUST use a different attribute in the entire session description MUST use a different
value of <trpr-cap-num>. When multiple <proto> values are provided, value of <trpr-cap-num>. When multiple <proto> values are provided,
the first one is associated with the value <trpr-cap-num>, the the first one is associated with the value <trpr-cap-num>, the
skipping to change at page 22, line 47 skipping to change at page 22, line 47
capability number 4). The last one provides capabilities for capability number 4). The last one provides capabilities for
"UDP/TLS/RTP/SAVP", i.e. DTLS-SRTP [DTLS-SRTP](transport capability "UDP/TLS/RTP/SAVP", i.e. DTLS-SRTP [DTLS-SRTP](transport capability
number 5). number 5).
The "tcap" attribute by itself can only specify transport protocols The "tcap" attribute by itself can only specify transport protocols
as defined by <proto> in [RFC4566], however full specification of a as defined by <proto> in [RFC4566], however full specification of a
media stream requires further qualification of the transport media stream requires further qualification of the transport
protocol by one or more media format descriptions, which themselves protocol by one or more media format descriptions, which themselves
often depend on the transport protocol. As an example, [RFC3551] often depend on the transport protocol. As an example, [RFC3551]
defines the "RTP/AVP" transport for use with audio and video codecs defines the "RTP/AVP" transport for use with audio and video codecs
(media formats), whereas [RFC4145] for example defines the "TCP" (media formats), whereas [RFC4145] defines the "TCP" transport which
transport protocol which may be used to negotiate, e.g. image/t38, for example may be used to negotiate T.38 fax ("image/t38"), etc. In
application/iptv_rtsp, etc. In a non-SDP context, some of these a non-SDP context, some media formats could be viewed as transports
media formats could be viewed as transports themselves (e.g. T.38) themselves (e.g. T.38) however in the context of SDP and SDP
however in the context of SDP and SDP Capability Negotiation, they Capability Negotiation, they are not. If capability negotiation is
are not. If capability negotiation is required for such media required for such media formats, they MUST all either be valid under
formats, they MUST all either be valid under the transport protocol the transport protocol indicated in the "m=" line included for the
indicated in the "m=" line included for the media stream media stream description, or a suitable extension must be used, e.g.
description, or a suitable extension must be used, e.g. SDP Media SDP Media Capabilities [SDPMedCap].
Capabilities [SDPMedCap].
The ability to use a particular transport protocol is inherently The ability to use a particular transport protocol is inherently
implied by including it in the "m=" line, regardless of whether it implied by including it in the "m=" line, regardless of whether it
is provided in a "tcap" attribute or not. However, if a potential is provided in a "tcap" attribute or not. However, if a potential
configuration needs to reference that transport protocol as a configuration needs to reference that transport protocol as a
capability, the transport protocol MUST be included explicitly in a capability, the transport protocol MUST be included explicitly in a
"tcap" attribute. "tcap" attribute.
This may seem redundant (and indeed it is from the offerer's point This may seem redundant (and indeed it is from the offerer's point
of view), however it is done to protect against intermediaries of view), however it is done to protect against intermediaries
skipping to change at page 24, line 33 skipping to change at page 24, line 31
a=pcfg: <config-number> [<pot-cfg-list>] a=pcfg: <config-number> [<pot-cfg-list>]
where <config-number> is an integer between 1 and 2^31-1 (both where <config-number> is an integer between 1 and 2^31-1 (both
included). The attribute can be provided only at the media-level. included). The attribute can be provided only at the media-level.
The "pcfg" attribute adheres to the RFC 4566 "attribute" production, The "pcfg" attribute adheres to the RFC 4566 "attribute" production,
with an att-value defined as follows: with an att-value defined as follows:
att-value = config-number [1*WSP pot-cfg-list] att-value = config-number [1*WSP pot-cfg-list]
config-number = 1*10(DIGIT) ;defined in [RFC5234] config-number = 1*10(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 / pot-config = attribute-config-list /
transport-protocol-config-list / transport-protocol-config-list /
extension-config-list extension-config-list
The missing productions are defined below. Note that white space is The missing productions are defined below. Note that white space is
not permitted before the config-number. not permitted before the config-number.
The potential configuration attribute can be provided only at the The potential configuration attribute can be provided only at the
media-level and there can be multiple instances of it within a given media-level and there can be multiple instances of it within a given
skipping to change at page 26, line 31 skipping to change at page 26, line 31
contains a transport protocol configuration list that references contains a transport protocol configuration list that references
transport capability 2 ("RTP/SAVPF") and an attribute configuration transport capability 2 ("RTP/SAVPF") and an attribute configuration
list that references attribute capability 1 ("a=crypto:..."). list that references attribute capability 1 ("a=crypto:...").
Attribute capabilities are used in a potential configuration by use Attribute capabilities are used in a potential configuration by use
of the attribute-config-list parameter, which is defined by the of the attribute-config-list parameter, which is defined by the
following ABNF: following ABNF:
attribute-config-list = "a=" delete-attributes attribute-config-list = "a=" delete-attributes
attribute-config-list =/ "a=" [delete-attributes ":"] attribute-config-list =/ "a=" [delete-attributes ":"]
mo-att-cap-list *(BAR mo-att-cap-list)) mo-att-cap-list *(BAR mo-att-cap-list)
delete-attributes = DELETE ( "m" ; media attributes delete-attributes = DELETE ( "m" ; media attributes
/ "s" ; session attributes / "s" ; session attributes
/ "ms" ) ; media and session attributes / "ms" ) ; media and session attributes
mo-att-cap-list = mandatory-optional-att-cap-list / mo-att-cap-list = mandatory-optional-att-cap-list /
mandatory-att-cap-list / mandatory-att-cap-list /
optional-att-cap-list optional-att-cap-list
mandatory-optional-att-cap-list = mandatory-att-cap-list mandatory-optional-att-cap-list = mandatory-att-cap-list
"," optional-att-cap-list "," optional-att-cap-list
mandatory-att-cap-list = att-cap-list mandatory-att-cap-list = att-cap-list
optional-att-cap-list = "[" att-cap-list "]" optional-att-cap-list = "[" att-cap-list "]"
att-cap-list = att-cap-num *("," att-cap-num) att-cap-list = att-cap-num *("," att-cap-num)
att-cap-num = 1*10(DIGIT) ;defined in [RFC5234] att-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
skipping to change at page 29, line 24 skipping to change at page 29, line 24
In the presence of intermediaries (the existence of which may not In the presence of intermediaries (the existence of which may not
be known), care should be taken with assuming that the transport be known), care should be taken with assuming that the transport
protocol in the "m=" line will not be modified by an intermediary. protocol in the "m=" line will not be modified by an intermediary.
Use of an explicit transport protocol capability will guard Use of an explicit transport protocol capability will guard
against capability negotiation implications of that. against capability negotiation implications of that.
Extension capabilities can be included in a potential configuration Extension capabilities can be included in a potential configuration
as well by use of extension configuration lists. Extension as well by use of extension configuration lists. Extension
configuration lists MUST adhere to the following ABNF: configuration lists MUST adhere to the following ABNF:
extension-config-list= ["+"] ext-cap-name "=" extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
ext-cap-list ext-cap-name = 1*(ALPHA / DIGIT)
ext-cap-name = 1*(ALPHA / DIGIT) ext-cap-list = 1*VCHAR ; defined in [RFC5234]
ext-cap-list = 1*VCHAR ; defined in [RFC5234]
Note that white space is not permitted within this rule. Note that white space is not permitted within this rule.
The ext-cap-name refers to the name of the extension capability and The ext-cap-name refers to the name of the extension capability and
the ext-cap-list is here merely defined as a sequence of visible the ext-cap-list is here merely defined as a sequence of visible
characters. The actual extension supported MUST refine both of these characters. The actual extension supported MUST refine both of these
further. For extension capabilities that merely need to be further. For extension capabilities that merely need to be
referenced by a capability number, it is RECOMMENDED to follow a referenced by a capability number, it is RECOMMENDED to follow a
structure similar to what has been specified above. Unsupported or structure similar to what has been specified above. Unsupported or
unknown potential extension configuration lists in a potential unknown potential extension configuration lists in a potential
skipping to change at page 39, line 38 skipping to change at page 39, line 38
The most preferred valid potential configuration in a media The most preferred valid potential configuration in a media
description is the valid potential configuration with the lowest description is the valid potential configuration with the lowest
configuration number. The answerer MUST now process the offer for configuration number. The answerer MUST now process the offer for
that media stream based on the most preferred valid potential that media stream based on the most preferred valid potential
configuration. Conceptually, this entails the answerer constructing configuration. Conceptually, this entails the answerer constructing
an (internal) offer as follows. First, all capability negotiation an (internal) offer as follows. First, all capability negotiation
parameters from the offer SDP session description are removed, parameters from the offer SDP session description are removed,
thereby yielding an offer SDP session description with the actual thereby yielding an offer SDP session description with the actual
configuration as if SDP capability negotiation was not done in the configuration as if SDP capability negotiation was not done in the
first place. Secondly, this actual configuration SDP session first place. Secondly, this actual configuration SDP session
description is then modified as follows for each media stream description is modified as follows for each media stream offered,
offered based on the capability negotiation parameters included based on the capability negotiation parameters included originally:
originally:
o If a transport protocol capability is included in the potential o If a transport protocol capability is included in the potential
configuration, then it replaces the transport protocol provided configuration, then it replaces the transport protocol provided
in the "m=" line for that media description. in the "m=" line for that media description.
o If attribute capabilities are present with a delete-attributes o If attribute capabilities are present with a delete-attributes
session indication ("-s") or media and session indication ("- session indication ("-s") or media and session indication ("-
ms"), then all session-level attributes from the actual ms"), then all session-level attributes from the actual
configuration SDP session description MUST be deleted in the configuration SDP session description MUST be deleted in the
resulting potential configuration SDP session description in resulting potential configuration SDP session description in
skipping to change at page 40, line 44 skipping to change at page 40, line 44
the media description in question. Furthermore, the added media- the media description in question. Furthermore, the added media-
level attributes MUST be added in the order they were provided in level attributes MUST be added in the order they were provided in
the potential configuration (see also Section 3.5.1. ). the potential configuration (see also Section 3.5.1. ).
o If a supported extension capability is included, then it MUST be o If a supported extension capability is included, then it MUST be
processed in accordance with the rules provided for that processed in accordance with the rules provided for that
particular extension capability. particular extension capability.
The above steps MUST be performed exactly once per potential The above steps MUST be performed exactly once per potential
configuration, i.e. there MUST NOT be any recursive processing of configuration, i.e. there MUST NOT be any recursive processing of
any additional capability negotiation parameters that may have been any additional capability negotiation parameters that may
nested inside capabilities themselves. (illegally) have been nested inside capabilities themselves.
As an example of this, consider the attribute capability As an example of this, consider the (illegal) attribute capability
a=acap:1 acap:2 foo:a a=acap:1 acap:2 foo:a
The resulting potential configuration SDP session description The resulting potential configuration SDP session description
will, after the above processing has been done, contain the will, after the above processing has been done, contain the
attribute capability attribute capability
a=acap:2 foo:a a=acap:2 foo:a
However, since we do not perform any recursive processing of However, since we do not perform any recursive processing of
skipping to change at page 43, line 19 skipping to change at page 43, line 19
RECOMMENDED not to use session-level attribute capabilities in RECOMMENDED not to use session-level attribute capabilities in
potential configurations, unless absolutely necessary. potential configurations, unless absolutely necessary.
Once the answerer has selected a valid and supported offered Once the answerer has selected a valid and supported offered
potential configuration for all of the media streams (or has fallen potential configuration for all of the media streams (or has fallen
back to the actual configuration plus any added session attributes), back to the actual configuration plus any added session attributes),
the answerer MUST generate a valid virtual answer SDP session the answerer MUST generate a valid virtual answer SDP session
description based on the selected potential configuration SDP description based on the selected potential configuration SDP
session description, as "seen" by the answerer using normal session description, as "seen" by the answerer using normal
offer/answer rules (see Section 3.6.2.1. for examples). The actual offer/answer rules (see Section 3.6.2.1. for examples). The actual
answer is formed from the virtual answer as follows: If the answerer answer SDP session description is formed from the virtual answer SDP
selected one of the potential configurations in a media description, session description as follows: If the answerer selected one of the
the answerer MUST include an actual configuration attribute potential configurations in a media description, the answerer MUST
("a=acfg") within that media description. The "a=acfg" attribute include an actual configuration attribute ("a=acfg") within that
MUST identify the configuration number for the selected potential media description. The "a=acfg" attribute MUST identify the
configuration as well as the actual parameters that were used from configuration number for the selected potential configuration as
that potential configuration; if the potential configuration well as the actual parameters that were used from that potential
included alternatives, the selected alternatives only MUST be configuration; if the potential configuration included alternatives,
included. Only the known and supported parameters will be included. the selected alternatives only MUST be included. Only the known and
Unknown or unsupported parameters MUST NOT be included in the actual supported parameters will be included. Unknown or unsupported
configuration attribute. In the case of attribute capabilities, only parameters MUST NOT be included in the actual configuration
the known and supported capabilities are included; unknown or attribute. In the case of attribute capabilities, only the known and
unsupported attribute capabilities MUST NOT be included. supported capabilities are included; unknown or unsupported
attribute capabilities MUST NOT be included.
If the answerer supports one or more capability negotiation If the answerer supports one or more capability negotiation
extensions that were not included in a required capability extensions that were not included in a required capability
negotiation extensions attribute in the offer, then the answerer negotiation extensions attribute in the offer, then the answerer
SHOULD furthermore include a supported capability negotiation SHOULD furthermore include a supported capability negotiation
attribute ("a=csup") at the session-level with option tags for the attribute ("a=csup") at the session-level with option tags for the
extensions supported across media streams. Also, if the answerer extensions supported across media streams. Also, if the answerer
supports one or more capability negotiation extensions for only supports one or more capability negotiation extensions for only
particular media descriptions, then a supported capability particular media descriptions, then a supported capability
negotiation attribute with those option-tags SHOULD be included negotiation attribute with those option-tags SHOULD be included
skipping to change at page 46, line 39 skipping to change at page 46, line 39
3.6.3. Offerer Processing of the Answer 3.6.3. Offerer Processing of the Answer
When the offerer attempted to use SDP Capability Negotiation in the When the offerer attempted to use SDP Capability Negotiation in the
offer, the offerer MUST examine the answer for actual use of SDP offer, the offerer MUST examine the answer for actual use of SDP
Capability Negotiation. Capability Negotiation.
For each media description where the offerer included a potential For each media description where the offerer included a potential
configuration attribute ("a=pcfg"), the offerer MUST first examine configuration attribute ("a=pcfg"), the offerer MUST first examine
that media description for the presence of a valid actual that media description for the presence of a valid actual
configuration attribute ("a=acfg"). An actual configuration configuration attribute ("a=acfg"). An actual configuration
attribute is valid if attribute is valid if:
o it refers to a potential configuration that was present in the o it refers to a potential configuration that was present in the
corresponding offer, and corresponding offer, and
o it contains the actual parameters that were used from that o it contains the actual parameters that were used from that
potential configuration; if the potential configuration included potential configuration; if the potential configuration included
alternatives, the selected alternatives only MUST be included. alternatives, the selected alternatives only MUST be included.
Note that the answer will include only parameters and attribute Note that the answer will include only parameters and attribute
capabilities that are known and supported by the answerer, as capabilities that are known and supported by the answerer, as
described in Section 3.6.2. described in Section 3.6.2.
If a valid actual configuration attribute is not present in a media If a valid actual configuration attribute is not present in a media
description, then the offerer MUST process the answer SDP session description, then the offerer MUST process the answer SDP session
description for that media stream per the normal offer/answer rules description for that media stream per the normal offer/answer rules
defined in [RFC3264]. However, if one is found, the offerer MUST defined in [RFC3264]. However, if a valid one is found, the offerer
instead process the answer as follows: MUST instead process the answer as follows:
o The actual configuration attribute specifies which of the o The actual configuration attribute specifies which of the
potential configurations was used by the answerer to generate the potential configurations was used by the answerer to generate the
answer for this media stream. This includes all the supported answer for this media stream. This includes all the supported
attribute capabilities and the transport capabilities referenced attribute capabilities and the transport capabilities referenced
by the potential configuration selected, where the attribute by the potential configuration selected, where the attribute
capabilities have any associated delete-attributes included. capabilities have any associated delete-attributes included.
Extension capabilities supported by the answerer are included as Extension capabilities supported by the answerer are included as
well. well.
skipping to change at page 52, line 32 skipping to change at page 52, line 32
(now including potential configurations) needs to be taken into (now including potential configurations) needs to be taken into
account when specifying the bandwidth parameters in the actual account when specifying the bandwidth parameters in the actual
configuration. This can make the bandwidth value less accurate than configuration. This can make the bandwidth value less accurate than
in SDP per [RFC4566] (due to potential greater variability in the in SDP per [RFC4566] (due to potential greater variability in the
potential configuration bandwidth use). Extensions can be defined to potential configuration bandwidth use). Extensions can be defined to
address this shortcoming. address this shortcoming.
The Transport Independent Application Specific Maximum (TIAS) The Transport Independent Application Specific Maximum (TIAS)
bandwidth type as defined in [RFC3890] SHOULD NOT be used to try and bandwidth type as defined in [RFC3890] SHOULD NOT be used to try and
alleviate bandwidth variability concerns due to different transport alleviate bandwidth variability concerns due to different transport
protocols since there are some inconsistencies between [RFC3264] and protocols, since there are some inconsistencies between [RFC3264]
[RFC3890]. More specifically, [RFC3264] defines the bandwidth and [RFC3890]. More specifically, [RFC3264] defines the bandwidth
parameter to apply to the receive direction for unicast streams, parameter to apply to the receive direction for unicast streams,
whereas [RFC3890] intends to use bandwidth in the send direction. whereas [RFC3890] intends to use bandwidth in the send direction.
Implementers are encouraged to look for an expected future solution Implementers are encouraged to look for an expected future solution
to this. to this.
Note, that when using RTP retransmission [RFC4588] with the RTCP- Note, that when using RTP retransmission [RFC4588] with the RTCP-
based feedback profile [RFC4585] (RTP/AVPF), the retransmitted based feedback profile [RFC4585] (RTP/AVPF), the retransmitted
packets are part of the media stream bandwidth when using SSRC- packets are part of the media stream bandwidth when using SSRC-
multiplexing. If a feedback based protocol is offered as the actual multiplexing. If a feedback based protocol is offered as the actual
configuration transport protocol, a non-feedback based protocol is configuration transport protocol, a non-feedback based protocol is
skipping to change at page 54, line 46 skipping to change at page 54, line 46
Negotiation framework. Negotiation framework.
The SDP Capability Negotiation framework itself attempts to help out The SDP Capability Negotiation framework itself attempts to help out
these intermediaries as well, by recommending a second offer/answer these intermediaries as well, by recommending a second offer/answer
exchange when use of a potential configuration has been negotiated exchange when use of a potential configuration has been negotiated
(see Section 3.6.3. ). However, there are several limitations with (see Section 3.6.3. ). However, there are several limitations with
this approach. First of all, although the second offer/answer this approach. First of all, although the second offer/answer
exchange is RECOMMENDED, it is not required and hence may not be exchange is RECOMMENDED, it is not required and hence may not be
performed. Secondly, the intermediary may refuse the initial answer, performed. Secondly, the intermediary may refuse the initial answer,
e.g. due to perceived transport protocol mismatch. Thirdly, the e.g. due to perceived transport protocol mismatch. Thirdly, the
strategy is not foolproof, since the offer/answer procedures strategy is not foolproof since the offer/answer procedures
[RFC3264] leave the original offer/answer exchange in effect when a [RFC3264] leave the original offer/answer exchange in effect when a
subsequent one fails; consider the following example: subsequent one fails. Consider the following example:
1. Offerer generates an SDP session description offer with the 1. Offerer generates an SDP session description offer with the
actual configuration specifying a low bandwidth configuration actual configuration specifying a low bandwidth configuration
(e.g. plain RTP) and a potential configuration specifying a (e.g. plain RTP) and a potential configuration specifying a
high(er) bandwidth configuration (e.g. secure RTP with high(er) bandwidth configuration (e.g. secure RTP with
integrity). integrity).
2. An intermediary (e.g. an SBC or P-CSCF), that does not support 2. An intermediary (e.g. an SBC or P-CSCF), that does not support
SDP Capability Negotiation, authorizes the session based on the SDP Capability Negotiation, authorizes the session based on the
actual configuration it sees in the SDP session description. actual configuration it sees in the SDP session description.
skipping to change at page 78, line 27 skipping to change at page 78, line 27
Stach, and Dan Wing. Stach, and Dan Wing.
General Area review comments were provided by Christian Vogt, and General Area review comments were provided by Christian Vogt, and
Stephen Kent provided Security Directorate review comments. Eric Stephen Kent provided Security Directorate review comments. Eric
Rescorla provided textual input to the Security Considerations. Rescorla provided textual input to the Security Considerations.
Alexey Melnikov, Robert Sparks, and Magnus Westerlund provided Alexey Melnikov, Robert Sparks, and Magnus Westerlund provided
several review comments as well. several review comments as well.
8. Change Log 8. Change Log
8.1. draft-ietf-mmusic-sdp-capability-negotiation-11 8.1. draft-ietf-mmusic-sdp-capability-negotiation-12
Addressing IESG review comments as follows:
o Clarified processing rules for "creq" in Section 3.3.2.
o Removed "iptv_rtsp" example in Section 3.4.2.
o Fixed ABNF error in "attribute-config-list".
o Changed ICE [ICE] reference from informative to normative.
o Minor editorial changes.
8.2. draft-ietf-mmusic-sdp-capability-negotiation-11
Addressing IESG review comments as follows: Addressing IESG review comments as follows:
o Changed att-cap-num and trpr-cap-num ABNF rules throughout to o Changed att-cap-num and trpr-cap-num ABNF rules throughout to
allow for no more than 10 digits. allow for no more than 10 digits.
o Disallowed base framework only implementations from generating o Disallowed base framework only implementations from generating
media-level attribute capabilities at the session-level, and media-level attribute capabilities at the session-level, and
added explicit rules for how to process them if received. added explicit rules for how to process them if received.
skipping to change at page 79, line 29 skipping to change at page 79, line 43
o Changed IANA rules for new option tags and potential o Changed IANA rules for new option tags and potential
configuration parameters to follow "IETF Review" policy, and configuration parameters to follow "IETF Review" policy, and
clarified that potential configuration parameters must be clarified that potential configuration parameters must be
registered with IANA. registered with IANA.
o Changed numerous instances of "SDP" with the more accurate "SDP o Changed numerous instances of "SDP" with the more accurate "SDP
session description" to avoid terminology overload. session description" to avoid terminology overload.
o Various editorial clarifications throughout. o Various editorial clarifications throughout.
8.2. draft-ietf-mmusic-sdp-capability-negotiation-10 8.3. draft-ietf-mmusic-sdp-capability-negotiation-10
Addressing General Area and Security Directorate review comments as Addressing General Area and Security Directorate review comments as
follows: follows:
o Explained and motivated the preference order between potential o Explained and motivated the preference order between potential
and actual configurations earlier in the document. and actual configurations earlier in the document.
o Added DTLS-SRTP example use in several places, as well as a new o Added DTLS-SRTP example use in several places, as well as a new
example call flow for DTLS-SRTP. example call flow for DTLS-SRTP.
skipping to change at page 80, line 5 skipping to change at page 80, line 19
configurations, which do not provide well-defined operation on configurations, which do not provide well-defined operation on
the receiving side, cannot be used in security critical contexts. the receiving side, cannot be used in security critical contexts.
o Updated Security Considerations section. o Updated Security Considerations section.
o Rephrased several sentences containing the word "only" to improve o Rephrased several sentences containing the word "only" to improve
readability. readability.
o Minor editorial nit fixes, especially in the example call flows. o Minor editorial nit fixes, especially in the example call flows.
8.3. draft-ietf-mmusic-sdp-capability-negotiation-09 8.4. draft-ietf-mmusic-sdp-capability-negotiation-09
Incorporated Working Group Chair review comments and a few additional Incorporated Working Group Chair review comments and a few additional
comments as follows: comments as follows:
o Clarified that the "a=creq" attribute MUST NOT be used in an o Clarified that the "a=creq" attribute MUST NOT be used in an
answer (Section 3.6.2. ). answer (Section 3.6.2. ).
o Various editorial changes throughout. o Various editorial changes throughout.
8.4. draft-ietf-mmusic-sdp-capability-negotiation-08 8.5. draft-ietf-mmusic-sdp-capability-negotiation-08
Incorporated Working Group Last Call comments as follows: Incorporated Working Group Last Call comments as follows:
o Added second offer/answer exchange to introductory example, fixed o Added second offer/answer exchange to introductory example, fixed
minor error in that example, and deleted similar example in the minor error in that example, and deleted similar example in the
Examples Section. Examples Section.
o Fixed "type=value" semantic error in the attribute capability o Fixed "type=value" semantic error in the attribute capability
definition. definition.
skipping to change at page 80, line 41 skipping to change at page 81, line 9
o Changed second offer/answer exchange from MAY to SHOULD strength. o Changed second offer/answer exchange from MAY to SHOULD strength.
o Clarified there should be a combined second offer/exchange when o Clarified there should be a combined second offer/exchange when
using ICE. using ICE.
o Moved RFC 3407 to informative references. o Moved RFC 3407 to informative references.
o Various editorial clarifications. o Various editorial clarifications.
8.5. draft-ietf-mmusic-sdp-capability-negotiation-07 8.6. draft-ietf-mmusic-sdp-capability-negotiation-07
o Removed the ability to have attribute capabilities provide o Removed the ability to have attribute capabilities provide
attribute names without values, when those attributes otherwise attribute names without values, when those attributes otherwise
require an associated value. require an associated value.
o Document no longer obsoletes RFC 3407 but instead recommends that o Document no longer obsoletes RFC 3407 but instead recommends that
it is being used instead of RFC 3407. it is being used instead of RFC 3407.
o Added ability to specific that specific extensions in a potential o Added ability to specific that specific extensions in a potential
configuration are mandatory. configuration are mandatory.
skipping to change at page 81, line 21 skipping to change at page 81, line 34
o Removed the redundant "a=" part of attribute capabilities. o Removed the redundant "a=" part of attribute capabilities.
o Clarified what it means to support an attribute capability in the o Clarified what it means to support an attribute capability in the
offer/answer procedures. offer/answer procedures.
o Changed "a=acap" attribute and offer/answer procedures to include o Changed "a=acap" attribute and offer/answer procedures to include
only the known and supported attribute capabilities. only the known and supported attribute capabilities.
o Added new section on indicating bandwidth usage. o Added new section on indicating bandwidth usage.
8.6. draft-ietf-mmusic-sdp-capability-negotiation-06 8.7. draft-ietf-mmusic-sdp-capability-negotiation-06
o Added additional background text on terminology used, and a new o Added additional background text on terminology used, and a new
section on the negotiation model. section on the negotiation model.
o Allowed for session-level attribute capabilities to contain o Allowed for session-level attribute capabilities to contain
media-level only attributes, albeit the base framework does not media-level only attributes, albeit the base framework does not
define (or allow) them to be used in a potential configuration define (or allow) them to be used in a potential configuration
(extensions may change that) (extensions may change that)
o Disallowing multiple "a=tcap" attributes at the session-level o Disallowing multiple "a=tcap" attributes at the session-level
skipping to change at page 82, line 40 skipping to change at page 83, line 5
o Updated examples in accordance with other changes and to o Updated examples in accordance with other changes and to
illustrate use of mandatory and optional attribute capabilities illustrate use of mandatory and optional attribute capabilities
in a potential configuration. in a potential configuration.
o Updated security considerations to address potential denial of o Updated security considerations to address potential denial of
service attack caused by large number of potential service attack caused by large number of potential
configurations. configurations.
o Various editorial updates throughout. o Various editorial updates throughout.
8.7. draft-ietf-mmusic-sdp-capability-negotiation-05 8.8. draft-ietf-mmusic-sdp-capability-negotiation-05
o Allowed for '<type>=<value>' attributes to be listed as attribute o Allowed for '<type>=<value>' attributes to be listed as attribute
capabilities the attribute name only. capabilities the attribute name only.
o Changed IP-address to conform to RFC 3330 guidelines. o Changed IP-address to conform to RFC 3330 guidelines.
o Added section on relationship to RFC 3407 and "Obsoletes: 3407" o Added section on relationship to RFC 3407 and "Obsoletes: 3407"
in the front. in the front.
o Disallowed use of white space in a number of places for more o Disallowed use of white space in a number of places for more
skipping to change at page 83, line 46 skipping to change at page 84, line 9
o Updated rtpmap and fmtp section to allow potential configurations o Updated rtpmap and fmtp section to allow potential configurations
to use remapped payload types in attribute capabilities for to use remapped payload types in attribute capabilities for
rtpmaps and fmtp parameters. rtpmaps and fmtp parameters.
o Added section on direction attributes. o Added section on direction attributes.
o Added another example showing SRTP with session-level MIKEY and o Added another example showing SRTP with session-level MIKEY and
SDP Security Descriptions using the attribute capability DELETE SDP Security Descriptions using the attribute capability DELETE
operator. operator.
8.8. draft-ietf-mmusic-sdp-capability-negotiation-04 8.9. draft-ietf-mmusic-sdp-capability-negotiation-04
The following are the major changes compared to version -03: The following are the major changes compared to version -03:
o Added explicit ordering rules for attributes added by potential o Added explicit ordering rules for attributes added by potential
configurations. configurations.
o Noted that ICE interaction issues (ice-tcp specifically) may not o Noted that ICE interaction issues (ice-tcp specifically) may not
be as clear as originally thought. be as clear as originally thought.
o Added considerations on using rtpmap and fmtp attributes as o Added considerations on using rtpmap and fmtp attributes as
attribute capabilities. attribute capabilities.
o Added multiple transport protocol example. o Added multiple transport protocol example.
o Added session-level MIKEY and media level security descriptions o Added session-level MIKEY and media level security descriptions
example. example.
8.9. draft-ietf-mmusic-sdp-capability-negotiation-03 8.10. draft-ietf-mmusic-sdp-capability-negotiation-03
The following are the major changes compared to version -02: The following are the major changes compared to version -02:
o Base option tag name changed from "v0" to "cap-v0". o Base option tag name changed from "v0" to "cap-v0".
o Added new section on extension capability attributes o Added new section on extension capability attributes
o Firmed up offer/answer procedures. o Firmed up offer/answer procedures.
o Added security considerations o Added security considerations
o Added IANA considerations o Added IANA considerations
8.10. draft-ietf-mmusic-sdp-capability-negotiation-02 8.11. draft-ietf-mmusic-sdp-capability-negotiation-02
The following are the major changes compared to version -01: The following are the major changes compared to version -01:
o Potential configurations are no longer allowed at the session o Potential configurations are no longer allowed at the session
level level
o Renamed capability attributes ("capar" to "acap" and "ctrpr" to o Renamed capability attributes ("capar" to "acap" and "ctrpr" to
"tcap") "tcap")
o Changed name and semantics of the initial number (now called o Changed name and semantics of the initial number (now called
skipping to change at page 85, line 18 skipping to change at page 85, line 28
selected a potential configuration selected a potential configuration
o Updated rules (and added restrictions) for referencing media- and o Updated rules (and added restrictions) for referencing media- and
session-level capabilities in potential configurations (at the session-level capabilities in potential configurations (at the
media level) media level)
o Added initial section on ICE interactions o Added initial section on ICE interactions
o Added initial section on receiving media before answer o Added initial section on receiving media before answer
8.11. draft-ietf-mmusic-sdp-capability-negotiation-01 8.12. draft-ietf-mmusic-sdp-capability-negotiation-01
The following are the major changes compared to version -00: The following are the major changes compared to version -00:
o Media capabilities are no longer considered a core capability and o Media capabilities are no longer considered a core capability and
hence have been removed. This leaves transport protocols and hence have been removed. This leaves transport protocols and
attributes as the only capabilities defined by the core. attributes as the only capabilities defined by the core.
o Version attribute has been removed and an option tag to indicate o Version attribute has been removed and an option tag to indicate
the actual version has been defined instead. the actual version has been defined instead.
skipping to change at page 86, line 5 skipping to change at page 86, line 13
configuration attributes. configuration attributes.
o Potential configurations at the session level now limited to o Potential configurations at the session level now limited to
indicate latent capability configurations. Consequently, an indicate latent capability configurations. Consequently, an
actual configuration attribute can no longer be provided at the actual configuration attribute can no longer be provided at the
session level. session level.
o Cleaned up capability and potential configuration terminology - o Cleaned up capability and potential configuration terminology -
they are now two clearly different things. they are now two clearly different things.
8.12. draft-ietf-mmusic-sdp-capability-negotiation-00 8.13. draft-ietf-mmusic-sdp-capability-negotiation-00
Version 00 is the initial version. The solution provided in this Version 00 is the initial version. The solution provided in this
initial version is based on an earlier (individual submission) initial version is based on an earlier (individual submission)
version of [SDPCapNeg]. The following are the major changes compared version of [SDPCapNeg]. The following are the major changes compared
to that document: to that document:
o Solution no longer based on RFC 3407, but defines a set of o Solution no longer based on RFC 3407, but defines a set of
similar attributes (with some differences). similar attributes (with some differences).
o Various minor changes to the previously defined attributes. o Various minor changes to the previously defined attributes.
skipping to change at page 87, line 16 skipping to change at page 87, line 16
9.1. Normative References 9.1. Normative References
[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.
[RFC5234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
[ICE] J. Rosenberg, "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", work in progress,
October 2007.
9.2. Informative References 9.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3312] G. Camarillo, W. Marshall, and J. Rosenberg, "Integration [RFC3312] G. Camarillo, W. Marshall, and J. Rosenberg, "Integration
of Resource Management and Session Initiation Protocol of Resource Management and Session Initiation Protocol
(SIP)", RFC 3312, October 2002. (SIP)", RFC 3312, October 2002.
skipping to change at page 89, line 27 skipping to change at page 89, line 34
[DTLS-SRTP] McGrew, D. and E. Rescorla, "Datagram Transport Layer [DTLS-SRTP] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)", work in progress, Real-time Transport Protocol (SRTP)", work in progress,
February 2009. February 2009.
[DTLS-SRTP-FRAMEWORK] Fischl, J., Tschofenig, H., and E. Rescorla, [DTLS-SRTP-FRAMEWORK] Fischl, J., Tschofenig, H., and E. Rescorla,
"Framework for Establishing an SRTP Security Context using "Framework for Establishing an SRTP Security Context using
DTLS", work in progress, March 2009. DTLS", work in progress, March 2009.
[ICE] J. Rosenberg, "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", work in progress,
October 2007.
[ICETCP] J. Rosenberg, "TCP Candidates with Interactive [ICETCP] J. Rosenberg, "TCP Candidates with Interactive
Connectivity Establishment (ICE)", work in progress, Connectivity Establishment (ICE)", work in progress,
October 2009. October 2009.
[SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", (draft- [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", (draft-
andreasen-mmusic-sdp-capability-negotiation-01.txt), work andreasen-mmusic-sdp-capability-negotiation-01.txt), work
in progress, December 2006. in progress, December 2006.
[SDPMedCap] Gilman, R, Even, R., and F. Andreasen "SDP Media [SDPMedCap] Gilman, R, Even, R., and F. Andreasen "SDP Media
Capabilities Negotiation", work in progress, July 2009. Capabilities Negotiation", work in progress, July 2009.
 End of changes. 43 change blocks. 
108 lines changed or deleted 119 lines changed or added

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