draft-ietf-mmusic-sdp-capability-negotiation-08.txt   draft-ietf-mmusic-sdp-capability-negotiation-09.txt 
MMUSIC Working Group F. Andreasen MMUSIC Working Group F. Andreasen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended Status: Proposed Standard December 11, 2007 Intended Status: Proposed Standard July 11, 2008
Expires: January 2009
SDP Capability Negotiation SDP Capability Negotiation
draft-ietf-mmusic-sdp-capability-negotiation-08.txt draft-ietf-mmusic-sdp-capability-negotiation-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 33 skipping to change at page 1, line 35
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 June 11, 2008. This Internet-Draft will expire on January 11, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
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
initiation. SDP was not intended to provide capability indication or initiation. SDP was not intended to provide capability indication or
capability negotiation, however over the years, SDP has seen capability negotiation, however over the years, SDP has seen
widespread adoption and as a result it has been gradually extended widespread adoption and as a result it has been gradually extended
to provide limited support for these, notably in the form of the to provide limited support for these, notably in the form of the
offer/answer model defined in RFC 3264. SDP and its current offer/answer model defined in RFC 3264. SDP does not define how to
extensions do not define how to negotiate one or more alternative negotiate one or more alternative transport protocols (e.g. RTP
transport protocols (e.g. RTP profiles) or attributes. This makes it profiles) or attributes. This makes it difficult to deploy new RTP
difficult to deploy new RTP profiles such as secure RTP or RTP with profiles such as secure RTP or RTP with RTCP-based feedback,
RTCP-based feedback, negotiate use of different security keying negotiate use of different security keying mechanisms, etc. It also
mechanisms, etc. It also presents problems for some forms of media presents problems for some forms of media negotiation.
negotiation.
The purpose of this document is to address these shortcomings by The purpose of this document is to address these shortcomings by
extending SDP with capability negotiation parameters and associated extending SDP with capability negotiation parameters and associated
offer/answer procedures to use those parameters in a backwards offer/answer procedures to use those parameters in a backwards
compatible manner. compatible manner.
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)
skipping to change at page 2, line 36 skipping to change at page 2, line 35
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............................7
3.1. SDP Capability Negotiation Model..........................7 3.1. SDP Capability Negotiation Model..........................7
3.2. Solution Overview........................................10 3.2. Solution Overview........................................10
3.3. Version and Extension Indication Attributes..............14 3.3. Version and Extension Indication Attributes..............14
3.3.1. Supported Capability Negotiation Extensions Attribute14 3.3.1. Supported Capability Negotiation Extensions Attribute14
3.3.2. Required Capability Negotiation Extensions Attribute15 3.3.2. Required Capability Negotiation Extensions Attribute15
3.4. Capability Attributes....................................17 3.4. Capability Attributes....................................17
3.4.1. Attribute Capability Attribute......................17 3.4.1. Attribute Capability Attribute......................17
3.4.2. Transport Protocol Capability Attribute.............19 3.4.2. Transport Protocol Capability Attribute.............19
3.4.3. Extension Capability Attributes.....................20 3.4.3. Extension Capability Attributes.....................21
3.5. Configuration Attributes.................................21 3.5. Configuration Attributes.................................21
3.5.1. Potential Configuration Attribute...................21 3.5.1. Potential Configuration Attribute...................21
3.5.2. Actual Configuration Attribute......................28 3.5.2. Actual Configuration Attribute......................29
3.6. Offer/Answer Model Extensions............................30 3.6. Offer/Answer Model Extensions............................31
3.6.1. Generating the Initial Offer........................31 3.6.1. Generating the Initial Offer........................31
3.6.2. Generating the Answer...............................34 3.6.2. Generating the Answer...............................34
3.6.2.1. Example Views of Potential Configurations......40 3.6.2.1. Example Views of Potential Configurations......40
3.6.3. Offerer Processing of the Answer....................42 3.6.3. Offerer Processing of the Answer....................42
3.6.4. Modifying the Session...............................43 3.6.4. Modifying the Session...............................43
3.7. Interactions with ICE....................................43 3.7. Interactions with ICE....................................44
3.8. Interactions with SIP Option Tags........................45 3.8. Interactions with SIP Option Tags........................45
3.9. Processing Media before Answer...........................46 3.9. Processing Media before Answer...........................46
3.10. Indicating Bandwidth Usage..............................47 3.10. Indicating Bandwidth Usage..............................47
3.11. Dealing with Large Number of Potential Configurations...47 3.11. Dealing with Large Number of Potential Configurations...48
3.12. SDP Capability Negotiation and Intermediaries...........48 3.12. SDP Capability Negotiation and Intermediaries...........49
3.13. Considerations for Specific Attribute Capabilities......50 3.13. Considerations for Specific Attribute Capabilities......51
3.13.1. The rtpmap and fmtp Attributes.....................50 3.13.1. The rtpmap and fmtp Attributes.....................51
3.13.2. Direction Attributes...............................51 3.13.2. Direction Attributes...............................52
3.14. Relationship to RFC 3407................................52 3.14. Relationship to RFC 3407................................52
4. Examples......................................................52 4. Examples......................................................52
4.1. Multiple Transport Protocols.............................52 4.1. Multiple Transport Protocols.............................53
4.2. Best-Effort SRTP with Session-Level MIKEY and Media Level 4.2. Best-Effort SRTP with Session-Level MIKEY and Media Level
Security Descriptions.........................................56 Security Descriptions.........................................56
4.3. SRTP with Session-Level MIKEY and Media Level Security 4.3. SRTP with Session-Level MIKEY and Media Level Security
Descriptions as Alternatives..................................61 Descriptions as Alternatives..................................61
5. Security Considerations.......................................63 5. Security Considerations.......................................64
6. IANA Considerations...........................................66 6. IANA Considerations...........................................67
6.1. New SDP Attributes.......................................66 6.1. New SDP Attributes.......................................67
6.2. New SDP Capability Negotiation Option Tag Registry.......67 6.2. New SDP Capability Negotiation Option Tag Registry.......68
6.3. New SDP Capability Negotiation Potential Configuration 6.3. New SDP Capability Negotiation Potential Configuration
Parameter Registry............................................68 Parameter Registry............................................69
7. Acknowledgments...............................................68 7. Acknowledgments...............................................69
8. Change Log....................................................68 8. Change Log....................................................70
8.1. draft-ietf-mmusic-sdp-capability-negotiation-08..........68 8.1. draft-ietf-mmusic-sdp-capability-negotiation-09..........70
8.2. draft-ietf-mmusic-sdp-capability-negotiation-07..........69 8.2. draft-ietf-mmusic-sdp-capability-negotiation-08..........70
8.3. draft-ietf-mmusic-sdp-capability-negotiation-06..........70 8.3. draft-ietf-mmusic-sdp-capability-negotiation-07..........70
8.4. draft-ietf-mmusic-sdp-capability-negotiation-05..........71 8.4. draft-ietf-mmusic-sdp-capability-negotiation-06..........71
8.5. draft-ietf-mmusic-sdp-capability-negotiation-04..........72 8.5. draft-ietf-mmusic-sdp-capability-negotiation-05..........72
8.6. draft-ietf-mmusic-sdp-capability-negotiation-03..........72 8.6. draft-ietf-mmusic-sdp-capability-negotiation-04..........73
8.7. draft-ietf-mmusic-sdp-capability-negotiation-02..........73 8.7. draft-ietf-mmusic-sdp-capability-negotiation-03..........74
8.8. draft-ietf-mmusic-sdp-capability-negotiation-01..........73 8.8. draft-ietf-mmusic-sdp-capability-negotiation-02..........74
8.9. draft-ietf-mmusic-sdp-capability-negotiation-00..........74 8.9. draft-ietf-mmusic-sdp-capability-negotiation-01..........75
9. References....................................................76 8.10. draft-ietf-mmusic-sdp-capability-negotiation-00.........76
9.1. Normative References.....................................76 9. References....................................................77
9.2. Informative References...................................76 9.1. Normative References.....................................77
Author's Addresses...............................................78 9.2. Informative References...................................77
Intellectual Property Statement..................................78 Author's Addresses...............................................79
Full Copyright Statement.........................................79 Intellectual Property Statement..................................79
Acknowledgment...................................................79 Full Copyright Statement.........................................80
Acknowledgment...................................................80
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
initiation. The SDP contains one or more media stream descriptions initiation. The SDP contains one or more media stream descriptions
with information such as IP-address and port, type of media stream with information such as IP-address and port, type of media stream
(e.g. audio or video), transport protocol (possibly including (e.g. audio or video), transport protocol (possibly including
profile information, e.g. RTP/AVP or RTP/SAVP), media formats (e.g. profile information, e.g. RTP/AVP or RTP/SAVP), media formats (e.g.
skipping to change at page 6, line 11 skipping to change at page 6, line 11
process was intentionally not defined. Instead, work on a "next process was intentionally not defined. Instead, work on a "next
generation" of a protocol to provide session description and generation" of a protocol to provide session description and
capability negotiation was initiated [SDPng]. SDPng defined a capability negotiation was initiated [SDPng]. SDPng defined a
comprehensive capability negotiation framework and protocol that was comprehensive capability negotiation framework and protocol that was
not bound by existing SDP constraints. SDPng was not designed to be not bound by existing SDP constraints. SDPng was not designed to be
backwards compatible with existing SDP and hence required both sides backwards compatible with existing SDP and hence required both sides
to support it, with a graceful fallback to legacy operation when to support it, with a graceful fallback to legacy operation when
needed. This, combined with lack of ubiquitous multipart MIME needed. This, combined with lack of ubiquitous multipart MIME
support in the protocols that would carry SDP or SDPng, made it support in the protocols that would carry SDP or SDPng, made it
challenging to migrate towards SDPng. In practice, SDPng has not challenging to migrate towards SDPng. In practice, SDPng has not
gained traction but rather remained as work in progress for an gained traction and as of the time of publication of this document,
extended period of time. Existing real-time multimedia work on SDPng has stopped. Existing real-time multimedia
communication protocols such as SIP, RTSP, Megaco, and MGCP continue communication protocols such as SIP, RTSP, Megaco, and MGCP continue
to use SDP. However, SDP and its current extensions do not address to use SDP. However, SDP does not address an increasingly important
an increasingly important problem: the ability to negotiate one or problem: the ability to negotiate one or more alternative transport
more alternative transport protocols (e.g., RTP profiles) and protocols (e.g., RTP profiles) and associated parameters (e.g. SDP
associated parameters (e.g. SDP attributes). This makes it attributes). This makes it difficult to deploy new RTP profiles
difficult to deploy new RTP profiles such as secure RTP (SRTP) such as secure RTP (SRTP) [RFC3711], RTP with RTCP-Based Feedback
[RFC3711], RTP with RTCP-Based Feedback [RFC4585], etc. The problem [RFC4585], etc. The problem is exacerbated by the fact that RTP
is exacerbated by the fact that RTP profiles are defined profiles are defined independently. When a new profile is defined
independently. When a new profile is defined and N other profiles and N other profiles already exist, there is a potential need for
already exist, there is a potential need for defining N additional defining N additional profiles, since profiles cannot be combined
profiles, since profiles cannot be combined automatically. For automatically. For example, in order to support the plain and
example, in order to support the plain and secure RTP version of RTP secure RTP version of RTP with and without RTCP-based feedback, four
with and without RTCP-based feedback, four separate profiles (and separate profiles (and hence profile definitions) are needed:
hence profile definitions) are needed: RTP/AVP [RFC3551], RTP/SAVP RTP/AVP [RFC3551], RTP/SAVP [RFC3711], RTP/AVPF [RFC4585], and
[RFC3711], RTP/AVPF [RFC4585], and RTP/SAVPF [SAVPF]. In addition RTP/SAVPF [SAVPF]. In addition to the pressing profile negotiation
to the pressing profile negotiation problem, other important real- problem, other important real-life limitations have been found as
life limitations have been found as well. Keying material and other well. Keying material and other parameters for example need to be
parameters for example need to be negotiated with some of the negotiated with some of the transport protocols, but not others.
transport protocols, but not others. Similarly, some media formats Similarly, some media formats and types of media streams need to
and types of media streams need to negotiate a variety of different negotiate a variety of different parameters.
parameters.
The purpose of this document is to define a mechanism that enables The purpose of this document is to define a mechanism that enables
SDP to provide limited support for indicating capabilities and their SDP to provide limited support for indicating capabilities and their
associated potential configurations, and negotiate the use of those associated potential configurations, and negotiate the use of those
potential configurations as actual configurations. It is not the potential configurations as actual configurations. It is not the
intent to provide a full-fledged capability indication and intent to provide a full-fledged capability indication and
negotiation mechanism along the lines of SDPng or ITU-T H.245. negotiation mechanism along the lines of SDPng or ITU-T H.245.
Instead, the focus is on addressing a set of well-known real-life Instead, the focus is on addressing a set of well-known real-life
limitations. More specifically, the solution provided in this limitations. More specifically, the solution provided in this
document provides a general SDP Capability Negotiation framework document provides a general SDP Capability Negotiation framework
skipping to change at page 7, line 46 skipping to change at page 7, line 46
o Capabilities o Capabilities
o Potential Configurations o Potential Configurations
o Actual Configurations o Actual Configurations
o Negotiation Process o Negotiation Process
as defined in Section 1. Conceptually, we want to offer not just the as defined in Section 1. Conceptually, we want to offer not just the
actual configuration SDP (which is done with the current actual configuration SDP (which is done with the offer/answer model
offer/answer model), but the actual configuration SDP as well as one defined in [RFC3264]), but the actual configuration SDP as well as
or more alternative SDPs, i.e. potential configurations. The one or more alternative SDPs, i.e. potential configurations. The
answerer must choose either the actual configuration, or one of the answerer must choose either the actual configuration, or one of the
potential configurations, and generate an answer SDP based on that. potential configurations, and generate an answer SDP based on that.
The offerer may need to perform processing on the answer, which The offerer may need to perform processing on the answer, which
depends on the offer that was chosen (actual or potential depends on the offer that was chosen (actual or potential
configuration). The answerer therefore informs the offerer which configuration). The answerer therefore informs the offerer which
configuration the answerer chose. The process can be viewed configuration the answerer chose. The process can be viewed
*conceptually* as follows: *conceptually* as follows:
Offerer Answerer Offerer Answerer
skipping to change at page 8, line 48 skipping to change at page 8, line 48
Answer | (actual | Answer | (actual |
<----- | config,o2)| <----- | config,o2)|
| | | |
5) Process answer based on +------------+ 5) Process answer based on +------------+
the configuration that was the configuration that was
chosen (o2), as indicated in chosen (o2), as indicated in
the answer the answer
The above illustrates the conceptual model: The actual solution uses The above illustrates the conceptual model: The actual solution uses
a single SDP, which contains the actual configuration (as with a single SDP, which contains the actual configuration (as with
current SDP and the current offer/answer model) and several new existing SDP and the offer/answer model defined in [RFC3264]) and
attributes and associated procedures, that encode the capabilities several new attributes and associated procedures, that encode the
and potential configurations. A more accurate depiction of the capabilities and potential configurations. A more accurate depiction
actual offer SDP is therefore as follows: of the actual offer SDP is therefore as follows:
+--------------------+ +--------------------+
| SDP o1 | | SDP o1 |
| (actual | | (actual |
| config | | config |
| | | |
| +-------------+ | | +-------------+ |
| | capability 1| | | | capability 1| |
| | capability 2| | | | capability 2| |
| | ... | | | | ... | |
skipping to change at page 10, line 9 skipping to change at page 10, line 9
easily end up with large messages. By providing a more compact easily end up with large messages. By providing a more compact
encoding, we get more efficient message sizes. encoding, we get more efficient message sizes.
In the next section, we describe the exact structure and specific In the next section, we describe the exact structure and specific
SDP parameters used to represent this. SDP parameters used to represent this.
3.2. Solution Overview 3.2. Solution Overview
The solution consists of the following: The solution consists of the following:
o Two new attributes to support extensions to the framework itself o Two new SDP attributes to support extensions to the framework
as follows: itself as follows:
o A new attribute ("a=csup") that lists the supported base o A new attribute ("a=csup") that lists the supported base
(optionally) and any supported extension options to the (optionally) and any supported extension options to the
framework. framework.
o A new attribute ("a=creq") that lists the extensions to the o A new attribute ("a=creq") that lists the extensions to the
framework that are required to be supported by the entity framework that are required to be supported by the entity
receiving the SDP in order to do capability negotiation. receiving the SDP in order to do capability negotiation.
o Two new attributes used to express capabilities as follows o Two new SDP attributes used to express capabilities as follows
(additional attributes can be defined as extensions): (additional attributes can be defined as extensions):
o A new attribute ("a=acap") that defines how to list an o A new attribute ("a=acap") that defines how to list an
attribute name and its associated value (if any) as a attribute name and its associated value (if any) as a
capability. capability.
o A new attribute ("a=tcap") that defines how to list transport o A new attribute ("a=tcap") that defines how to list transport
protocols (e.g. "RTP/AVP") as capabilities. protocols (e.g. "RTP/AVP") as capabilities.
o Two new attributes to negotiate configurations as follows: o Two new SDP attributes to negotiate configurations as follows:
o A new attribute ("a=pcfg") that lists potential o A new attribute ("a=pcfg") that lists potential
configurations supported. This is done by reference to the configurations supported. This is done by reference to the
capabilities from the SDP in question. Extension capabilities capabilities from the SDP in question. Extension capabilities
can be defined and referenced in the potential can be defined and referenced in the potential
configurations. Alternative potential configurations have an configurations. Alternative potential configurations have an
explicit ordering associated with them. Also, potential explicit ordering associated with them. Also, potential
configurations are preferred over the actual configuration configurations are preferred over the actual configuration
included in the "m=" line and its associated parameters. included in the "m=" line and its associated parameters.
skipping to change at page 14, line 24 skipping to change at page 14, line 24
The SDP Capability Negotiation solution allows for capability The SDP Capability Negotiation solution allows for capability
negotiation extensions to be defined. Associated with each such negotiation extensions to be defined. Associated with each such
extension is an option tag that identifies the extension in extension is an option tag that identifies the extension in
question. Option-tags MUST be registered with IANA per the question. Option-tags MUST be registered with IANA per the
procedures defined in Section 6. procedures defined in Section 6.
The Supported Capability Negotiation Extensions attribute ("a=csup") The Supported Capability Negotiation Extensions attribute ("a=csup")
contains a comma-separated list of option tags identifying the SDP contains a comma-separated list of option tags identifying the SDP
Capability Negotiation extensions supported by the entity that Capability Negotiation extensions supported by the entity that
generated the SDP. The attribute is defined as follows: generated the SDP. The attribute can be provided at the session-
level and the media-level, and it is defined as follows:
a=csup: <option-tag-list> a=csup: <option-tag-list>
RFC 4566, Section 9, provides the ABNF [RFC4234] for SDP attributes. RFC 4566, Section 9, provides the ABNF [RFC5234] for SDP attributes.
The "csup" attribute adheres to the RFC 4566 "attribute" production, The "csup" attribute adheres to the RFC 4566 "attribute" production,
with an att-value defined as follows: with an att-value defined as follows:
att-value = option-tag-list att-value = option-tag-list
option-tag-list = option-tag *("," option-tag) option-tag-list = option-tag *("," option-tag)
option-tag = token ; defined in [RFC4566] option-tag = token ; defined in [RFC4566]
A special base option tag with a value of "cap-v0" is defined for A special base option tag with a value of "cap-v0" is defined for
the basic SDP Capability Negotiation framework defined in this the basic SDP Capability Negotiation framework defined in this
document. Entities can use this option tag with the "a=csup" document. Entities can use this option tag with the "a=csup"
skipping to change at page 15, line 12 skipping to change at page 15, line 12
a=csup:foo a=csup:foo
a=csup:bar a=csup:bar
a=csup:cap-v0,foo,bar a=csup:cap-v0,foo,bar
The "a=csup" attribute can be provided at the session and the media- The "a=csup" attribute can be provided at the session and the media-
level. When provided at the session-level, it applies to the entire level. When provided at the session-level, it applies to the entire
SDP. When provided at the media-level, it applies to the media SDP. When provided at the media-level, it applies to the media
description in question only (option-tags provided at the session description in question only (option-tags provided at the session
level apply as well). There can be at most one "a=csup" attribute at level apply as well). There MUST NOT be more than one "a=csup"
the session-level and at most one at the media-level (one per media attribute at the session-level and one at the media-level (one per
description in the latter case). media description in the latter case).
Whenever an entity that supports one or more extensions to the SDP Whenever an entity that supports one or more extensions to the SDP
Capability Negotiation framework generates an SDP, it SHOULD include Capability Negotiation framework generates an SDP, it SHOULD include
the "a=csup" attribute with the option tags for the extensions it the "a=csup" attribute with the option tags for the extensions it
supports at the session and/or media-level, unless those option tags supports at the session and/or media-level, unless those option tags
are already provided in one or more "a=creq" attribute (see Section are already provided in one or more "a=creq" attribute (see Section
3.3.2. ) at the relevant levels. Inclusion of the base option tag is 3.3.2. ) at the relevant levels. Inclusion of the base option tag is
OPTIONAL; support for the base framework can be inferred from OPTIONAL; support for the base framework can be inferred from
presence of the "a=pcfg" attribute defined in Section 3.5.1. presence of the "a=pcfg" attribute defined in Section 3.5.1.
skipping to change at page 15, line 45 skipping to change at page 15, line 45
supported by the entity receiving the SDP, in order for that entity supported by the entity receiving the SDP, in order for that entity
to properly process the SDP Capability Negotiation attributes and to properly process the SDP Capability Negotiation attributes and
associated procedures. There is no need to include the base option- associated procedures. There is no need to include the base option-
tag ("cap-v0") with the "creq" attribute, since any entity that tag ("cap-v0") with the "creq" attribute, since any entity that
supports the "creq" attribute in the first place also supports the supports the "creq" attribute in the first place also supports the
base option-tag. Still, it is permissible to do so. base option-tag. Still, it is permissible to do so.
Such functionality may be important if a future version of the Such functionality may be important if a future version of the
capability negotiation framework were not backwards compatible. capability negotiation framework were not backwards compatible.
The attribute is defined as follows: The attribute can be provided at the session-level and the media-
level, and it is defined as follows:
a=creq: <option-tag-list> a=creq: <option-tag-list>
The "creq" attribute adheres to the RFC 4566 "attribute" production, The "creq" attribute adheres to the RFC 4566 "attribute" production,
with an att-value defined as follows: with an att-value defined as follows:
att-value = option-tag-list att-value = option-tag-list
The following examples illustrate use of the "a=creq" attribute with The following examples illustrate use of the "a=creq" attribute with
the "cap-v0" base option tag and two hypothetical option tags, "foo" the "cap-v0" base option tag and two hypothetical option tags, "foo"
and "bar" (note the lack of white space): and "bar" (note the lack of white space):
skipping to change at page 16, line 25 skipping to change at page 16, line 25
a=creq:foo a=creq:foo
a=creq:bar a=creq:bar
a=creq:cap-v0,foo,bar a=creq:cap-v0,foo,bar
The "a=creq" attribute can be provided at the session and the media- The "a=creq" attribute can be provided at the session and the media-
level. When provided at the session-level, it applies to the entire level. When provided at the session-level, it applies to the entire
SDP. When provided at the media-level, it applies to the media SDP. When provided at the media-level, it applies to the media
description in question only (required option tags provided at the description in question only (required option tags provided at the
session level apply as well). There can be at most one "a=creq" session level apply as well). There MUST NOT be more than one
attribute at the session-level and at most one "a=creq" attribute at "a=creq" attribute at the session-level and one "a=creq" attribute
the media-level (one per media description in the latter case). at the media-level (one per media description in the latter case).
When an entity generates an SDP and it requires the recipient of When an entity generates an SDP and it requires the recipient of
that SDP to support one or more SDP Capability Negotiation that SDP to support one or more SDP Capability Negotiation
extensions (except for the base) at the session or media level in extensions (except for the base) at the session or media level in
order to properly process the SDP Capability Negotiation, the order to properly process the SDP Capability Negotiation, the
"a=creq" attribute MUST be included with option-tags that identify "a=creq" attribute MUST be included with option-tags that identify
the required extensions at the session and/or media level. If the required extensions at the session and/or media level. If
support for an extension is needed only in one or more specific support for an extension is needed only in one or more specific
potential configurations, the potential configuration provides a way potential configurations, the potential configuration provides a way
to indicate that instead (see Section 3.5.1. ). Support for the to indicate that instead (see Section 3.5.1. ). Support for the
skipping to change at page 17, line 16 skipping to change at page 17, line 16
An entity that does not support the SDP Capability Negotiation An entity that does not support the SDP Capability Negotiation
framework at all, will ignore these attributes (as well as the framework at all, will ignore these attributes (as well as the
other SDP Capability Negotiation attributes) and not perform any other SDP Capability Negotiation attributes) and not perform any
SDP Capability Negotiation in the first place. SDP Capability Negotiation in the first place.
When an SDP recipient does not support one or more required SDP When an SDP recipient does not support one or more required SDP
Capability Negotiation extensions listed in the option tags, the Capability Negotiation extensions listed in the option tags, the
recipient MUST proceed as if the SDP Capability Negotiation recipient MUST proceed as if the SDP Capability Negotiation
attributes were not included in the first place, i.e. all the attributes were not included in the first place, i.e. all the
capability negotiation attributes should be ignored. If the SDP capability negotiation attributes should be ignored. In that case,
recipient is an SDP answerer [RFC3264], the recipient SHOULD include if the SDP recipient is an SDP answerer [RFC3264], the recipient
a "csup" attribute in the resulting SDP answer listing the SDP SHOULD include a "csup" attribute in the resulting SDP answer
Capability Negotiation extensions it actually supports. listing the SDP 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.
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.
skipping to change at page 17, line 41 skipping to change at page 17, line 42
Attributes and their associated values can be expressed as Attributes and their associated values can be expressed as
capabilities by use of a new attribute capability attribute capabilities by use of a new attribute capability attribute
("a=acap"), which is defined as follows: ("a=acap"), which is defined as follows:
a=acap: <att-cap-num> <att-par> a=acap: <att-cap-num> <att-par>
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]). form, i.e., excluding the "a=" part (see [RFC4566]). The attribute
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*DIGIT ;defined in [RFC4234] att-cap-num = 1*DIGIT ;defined in [RFC5234]
att-par = attribute ;defined in RFC 4566 att-par = attribute ;defined in RFC 4566
Note that white space is not permitted before the att-cap-num. Note that white space is not permitted before the att-cap-num.
The "acap" attribute can be provided at the session level only when The "acap" attribute can be provided at the session level only when
the attribute capability contains session-level attributes, whereas the attribute capability contains session-level attributes, whereas
media level attributes can be provided in attribute capabilities at media level attributes can be provided in attribute capabilities at
either the media level or session-level. The base SDP Capability either the media level or session-level. The base SDP Capability
Negotiation framework however only defines procedures for use of Negotiation framework however only defines procedures for use of
media-level attribute capabilities at the media level (extensions media-level attribute capabilities at the media level (extensions
may define use at the session level). may define use at the session level).
skipping to change at page 19, line 25 skipping to change at page 19, line 27
Transport Protocols can be expressed as capabilities by use of a new Transport Protocols can be expressed as capabilities by use of a new
Transport Protocol Capability attribute ("a=tcap") defined as Transport Protocol Capability attribute ("a=tcap") defined as
follows: follows:
a=tcap: <trpr-cap-num> <proto-list> a=tcap: <trpr-cap-num> <proto-list>
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. white space, as defined in the SDP "m=" line. The attribute can be
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*DIGIT ;defined in [RFC4234] trpr-cap-num = 1*DIGIT ;defined in [RFC5234]
proto-list = proto *(1*WSP proto) ; defined in RFC 4566 proto-list = proto *(1*WSP proto) ; defined in RFC 4566
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 can be at most one "a=tcap" attribute at the media-level. There MUST NOT be more than one "a=tcap" attribute at
session-level and at most 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
second one with the value one higher, etc. There MUST NOT be any second one with the value one higher, etc. There MUST NOT be any
capability number overlap between different "tcap" attributes in the capability number overlap between different "tcap" attributes in the
entire SDP. The <trpr-cap-num> values provided are independent of entire SDP. The <trpr-cap-num> values provided are independent of
similar <cap-num> values provided for other capability attributes, similar <cap-num> values provided for other capability attributes,
i.e., they form a separate name-space for transport protocol i.e., they form a separate name-space for transport protocol
capabilities. Consecutive numbering of the <trpr-cap-num> values in capabilities. Consecutive numbering of the <trpr-cap-num> values in
skipping to change at page 21, line 10 skipping to change at page 21, line 17
The SDP Capability Negotiation framework allows for new types of The SDP Capability Negotiation framework allows for new types of
capabilities to be defined as extensions and used with the general capabilities to be defined as extensions and used with the general
capability negotiation framework. The syntax and semantics of such capability negotiation framework. The syntax and semantics of such
new capability attributes are not defined here, however in order to new capability attributes are not defined here, however in order to
be used with potential configurations, they SHOULD allow for a be used with potential configurations, they SHOULD allow for a
numeric handle to be associated with each capability. This handle numeric handle to be associated with each capability. This handle
can be used as a reference within the potential and actual can be used as a reference within the potential and actual
configuration attributes (see Section 3.5.1. and 3.5.2. ). The configuration attributes (see Section 3.5.1. and 3.5.2. ). The
definition of such extension capability attributes MUST also state definition of such extension capability attributes MUST also state
whether they can be applied at the session-level, media-level, or whether they can be applied at the session-level, media-level, or
both. both. Note that extensions can have option tags defined for them,
which can be registered with the IANA in accordance with the
procedures specified in Section 6.2.
3.5. Configuration Attributes 3.5. Configuration Attributes
3.5.1. Potential Configuration Attribute 3.5.1. Potential Configuration Attribute
Potential Configurations can be expressed by use of a new Potential Potential Configurations can be expressed by use of a new Potential
Configuration Attribute ("a=pcfg") defined as follows: Configuration Attribute ("a=pcfg") defined as follows:
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). included). The attribute can be provided at the media-level only.
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*DIGIT ;defined in [RFC4234] 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 / 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 at the media- The potential configuration attribute can be provided at the media-
level only and there can be multiple instances of it within a given level only and there can be multiple instances of it within a given
skipping to change at page 23, line 30 skipping to change at page 23, line 47
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*DIGIT ;defined in [RFC4234] att-cap-num = 1*DIGIT ;defined in [RFC5234]
BAR = "|" BAR = "|"
DELETE = "-" DELETE = "-"
Note that white space is not permitted within this production. Note that white space is not permitted within this production.
Each attribute configuration list can optionally begin with Each attribute configuration list can optionally begin with
instructions for how to handle attributes that are part of the instructions for how to handle attributes that are part of the
actual configuration SDP (i.e., the "a=" lines present in the actual configuration SDP (i.e., the "a=" lines present in the
original SDP). By default, such attributes will remain as part of original SDP). By default, such attributes will remain as part of
the configuration in question. However, if delete-attributes the configuration in question. However, if delete-attributes
indicates "-m", then all attribute lines within the media indicates "-m", then all attribute lines within the media
description in question will be deleted (i.e., all "a=" lines under description in question will be deleted (i.e., all "a=" lines under
the "m=" line in question). If delete-attributes indicates "-s", the "m=" line in question). If delete-attributes indicates "-s",
skipping to change at page 25, line 26 skipping to change at page 25, line 42
lists MUST be selected in its entirety. This requires that all lists MUST be selected in its entirety. This requires that all
mandatory attribute capabilities referenced by the potential mandatory attribute capabilities referenced by the potential
configuration are supported with the attribute values provided. configuration are supported with the attribute values provided.
Transport protocol configuration lists are included in a potential Transport protocol configuration lists are included in a potential
configuration by use of the transport-protocol-config-list configuration by use of the transport-protocol-config-list
parameter, which is defined by the following ABNF: parameter, which is defined by the following ABNF:
transport-protocol-config-list = transport-protocol-config-list =
"t=" trpr-cap-num *(BAR trpr-cap-num) "t=" trpr-cap-num *(BAR trpr-cap-num)
trpr-cap-num = 1*DIGIT ; defined in [RFC4234] trpr-cap-num = 1*DIGIT ; defined in [RFC5234]
Note that white space is not permitted within this production. Note that white space is not permitted within this production.
The trpr-cap-num refers to transport protocol capability numbers The trpr-cap-num refers to transport protocol capability numbers
defined above and hence MUST be between 1 and 2^31-1 (both defined above and hence MUST be between 1 and 2^31-1 (both
included). Alternative transport protocol capabilities are separated included). Alternative transport protocol capabilities are separated
by a vertical bar ("|"). The alternatives are ordered by preference by a vertical bar ("|"). The alternatives are ordered by preference
with the most preferred listed first. If there are no transport with the most preferred listed first. If there are no transport
protocol capabilities included in a potential configuration at the protocol capabilities included in a potential configuration at the
media level, the transport protocol information from the associated media level, the transport protocol information from the associated
skipping to change at page 26, line 8 skipping to change at page 26, line 25
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. Such extension as well by use of extension configuration lists. Such 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 [RFC4234] ext-cap-list = 1*VCHAR ; defined in [RFC5234]
Note that white space is not permitted within this production. Note that white space is not permitted within this production.
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 27, line 17 skipping to change at page 27, line 36
Individual media streams perform capability negotiation Individual media streams perform capability negotiation
individually, and hence it is possible that one media stream (where individually, and hence it is possible that one media stream (where
the attribute was part of a potential configuration) chose a the attribute was part of a potential configuration) chose a
configuration without a session level attribute that was chosen by configuration without a session level attribute that was chosen by
another media stream. The session-level attribute however remains another media stream. The session-level attribute however remains
"active" and applies to the entire resulting potential configuration "active" and applies to the entire resulting potential configuration
SDP. In theory, this is problematic if one or more session-level SDP. In theory, this is problematic if one or more session-level
attributes either conflicts with or potentially interacts with attributes either conflicts with or potentially interacts with
another session-level or media-level attribute in an undefined another session-level or media-level attribute in an undefined
manner. In practice, such examples seem to be rare (at least with manner. In practice, such examples seem to be rare (at least with
the currently defined SDP attributes). the SDP attributes that had been defined at time of publication of
this document).
A related set of problems can occur if we need coordination A related set of problems can occur if we need coordination
between session-level attributes from multiple media streams in between session-level attributes from multiple media streams in
order for a particular functionality to work. The grouping order for a particular functionality to work. The grouping
framework [RFC3388] is an example of this. If we use the SDP framework [RFC3388] is an example of this. If we use the SDP
Capability Negotiation framework to select a session-level group Capability Negotiation framework to select a session-level group
attribute (provided as an attribute capability), and we require attribute (provided as an attribute capability), and we require
two media descriptions to do this consistently, we could have a two media descriptions to do this consistently, we could have a
problem. The FEC grouping semantics [RFC4756] is one example where problem. The FEC grouping semantics [RFC4756] is one example where
this in theory could cause problems, however in practice, it is this in theory could cause problems, however in practice, it is
unclear that there is a significant problem with the currently unclear that there is a significant problem with the grouping
defined grouping semantics. semantics that had been defined at time of publication of this
document.
Resolving the above issues in general requires inter-media stream Resolving the above issues in general requires inter-media stream
constraints and synchronized potential configuration processing; constraints and synchronized potential configuration processing;
this would add considerable complexity to the overall solution. In this would add considerable complexity to the overall solution. In
practice, with the currently defined SDP attributes, it does not practice, with the SDP attributes defined at time of publication of
seem to be a significant problem, and hence the core SDP Capability this document, it does not seem to be a significant problem, and
Negotiation solution does not provide a solution to this issue. hence the core SDP Capability Negotiation solution does not provide
Instead, it is RECOMMENDED that use of session-level attributes in a a solution to this issue. Instead, it is RECOMMENDED that use of
potential configuration is avoided when possible, and when not, that session-level attributes in a potential configuration is avoided
such use is examined closely for any potential interaction issues. when possible, and when not, that such use is examined closely for
If interaction is possible, the entity generating the SDP SHOULD NOT any potential interaction issues. If interaction is possible, the
assume that well-defined operation will occur at the receiving entity generating the SDP SHOULD NOT assume that well-defined
entity. operation will occur at the receiving entity.
The session-level operation of extension capabilities is undefined: The session-level operation of extension capabilities is undefined:
Consequently, each new session-level extension capability defined Consequently, each new session-level extension capability defined
MUST specify the implication of making it part of a configuration at MUST specify the implication of making it part of a configuration at
the media level. the media level.
Below, we provide an example of the "a=pcfg" attribute in a complete Below, we provide an example of the "a=pcfg" attribute in a complete
media description in order to properly indicate the supporting media description in order to properly indicate the supporting
attributes: attributes:
skipping to change at page 29, line 35 skipping to change at page 30, line 4
to those from the offer; not the answer. to those from the offer; not the answer.
The answer may for example include capabilities as well to inform The answer may for example include capabilities as well to inform
the offerer of the answerers capabilities above and beyond the the offerer of the answerers capabilities above and beyond the
negotiated configuration. The actual configuration attribute does negotiated configuration. The actual configuration attribute does
not refer to any of those answer capabilities though. not refer to any of those answer capabilities though.
The Actual Configuration Attribute ("a=acfg") is defined as follows: The Actual Configuration Attribute ("a=acfg") is defined as follows:
a=acfg: <config-number> [<sel-cfg-list>] a=acfg: <config-number> [<sel-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). included). The attribute can be provided at the media-level only.
The "acfg" attribute adheres to the RFC 4566 "attribute" production, The "acfg" 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 sel-cfg-list] att-value = config-number [1*WSP sel-cfg-list]
;config-number defined in Section 3.5.1. ;config-number defined in Section 3.5.1.
sel-cfg-list = sel-cfg *(1*WSP sel-cfg) sel-cfg-list = sel-cfg *(1*WSP sel-cfg)
sel-cfg = sel-attribute-config / sel-cfg = sel-attribute-config /
sel-transport-protocol-config / sel-transport-protocol-config /
sel-extension-config sel-extension-config
skipping to change at page 35, line 23 skipping to change at page 35, line 38
extensions attribute ("a=csup") in that media description with extensions attribute ("a=csup") in that media description with
option tags for the capability negotiation extensions supported option tags for the capability negotiation extensions supported
by the answerer for that media description. by the answerer for that media description.
Assuming all required capability negotiation extensions are Assuming all required capability negotiation extensions are
supported, the answerer now proceeds as follows. supported, the answerer now proceeds as follows.
For each media description where capability negotiation is to be For each media description where capability negotiation is to be
performed (i.e. all required capability negotiation extensions are performed (i.e. all required capability negotiation extensions are
supported and at least one valid potential configuration attribute supported and at least one valid potential configuration attribute
is present), the answerer MUST attempt to perform capability is present), the answerer MUST perform capability negotiation by
negotiation by using the most preferred potential configuration that using the most preferred potential configuration that is valid to
is valid to the answerer. A potential configuration is valid to the the answerer, subject to any local policies. A potential
answerer if: configuration is valid to the answerer if:
1. It is in accordance with the syntax and semantics provided in 1. It is in accordance with the syntax and semantics provided in
Section 3.5.1. Section 3.5.1.
2. It contains a configuration number that is unique within that 2. It contains a configuration number that is unique within that
media description. media description.
3. All attribute capabilities referenced by the potential 3. All attribute capabilities referenced by the potential
configuration are valid themselves (as defined in Section 3.4.1. configuration are valid themselves (as defined in Section 3.4.1.
) and each of them is provided either at the session-level or ) and each of them is provided either at the session-level or
skipping to change at page 39, line 35 skipping to change at page 39, line 47
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 supports one or more capability negotiation extensions for
particular media descriptions only, then a supported capability particular media descriptions only, then a supported capability
negotiation attribute with those option-tags SHOULD be included negotiation attribute with those option-tags SHOULD be included
within each relevant media description. within each relevant media description. The required capability
negotiation attribute ("a=creq") MUST NOT be used in an answer.
The offerer's originally provided actual configuration is contained The offerer's originally provided actual configuration is contained
in the offer media description's "m=" line (and associated in the offer media description's "m=" line (and associated
parameters). The answerer MAY send media to the offerer in parameters). The answerer MAY send media to the offerer in
accordance with that actual configuration as soon as it receives the accordance with that actual configuration as soon as it receives the
offer, however it MUST NOT send media based on that actual offer, however it MUST NOT send media based on that actual
configuration if it selects an alternative potential configuration. configuration if it selects an alternative potential configuration.
If the answerer selects one of the potential configurations, then If the answerer selects one of the potential configurations, then
the answerer MAY immediately start to send media to the offerer in the answerer MAY immediately start to send media to the offerer in
accordance with the selected potential configuration, however the accordance with the selected potential configuration, however the
skipping to change at page 45, line 11 skipping to change at page 45, line 28
configurations (for example candidate attributes for UDP only for configurations (for example candidate attributes for UDP only for
potential configurations that are restricted to UDP, whereas there potential configurations that are restricted to UDP, whereas there
could be candidate attributes for UDP, TCP, and TCP/TLS for could be candidate attributes for UDP, TCP, and TCP/TLS for
potential configurations that can use all three). Furthermore, use potential configurations that can use all three). Furthermore, use
of the delete-attributes in a potential configuration can be used to of the delete-attributes in a potential configuration can be used to
ensure that ICE will not end up using a transport protocol that is ensure that ICE will not end up using a transport protocol that is
not desired for a particular configuration. not desired for a particular configuration.
SDP Capability Negotiation recommends use of a second offer/answer SDP Capability Negotiation recommends use of a second offer/answer
exchange when the negotiated actual configuration was one of the exchange when the negotiated actual configuration was one of the
potential configurations from the offer. Similarly, ICE requires use potential configurations from the offer (see Section 3.6.3. ).
of a second offer/answer exchange if the chosen candidate is not the Similarly, ICE requires use of a second offer/answer exchange if the
same as the one in the m/c-line from the offer. When ICE and chosen candidate is not the same as the one in the m/c-line from the
capability negotiation are used at the same time, the two secondary offer. When ICE and capability negotiation are used at the same
offer/answer exchanges should be combined to a single one. time, the two secondary offer/answer exchanges SHOULD be combined to
a single one.
3.8. Interactions with SIP Option Tags 3.8. Interactions with SIP Option Tags
SIP [RFC3261] allows for SIP extensions to define a SIP option tag SIP [RFC3261] allows for SIP extensions to define a SIP option tag
that identifies the SIP extension. Support for one or more such that identifies the SIP extension. Support for one or more such
extensions can be indicated by use of the SIP Supported header, and extensions can be indicated by use of the SIP Supported header, and
required support for one or more such extensions can be indicated by required support for one or more such extensions can be indicated by
use of the SIP Require header. The "a=csup" and "a=creq" attributes use of the SIP Require header. The "a=csup" and "a=creq" attributes
defined by the SDP Capability Negotiation framework are similar, defined by the SDP Capability Negotiation framework are similar,
except that support for these two attributes by themselves cannot be except that support for these two attributes by themselves cannot be
skipping to change at page 47, line 7 skipping to change at page 47, line 23
proposed for best-effort SRTP in [BESRTP] is to provide different proposed for best-effort SRTP in [BESRTP] is to provide different
RTP payload type mappings for different transport protocols used, RTP payload type mappings for different transport protocols used,
outside of the actual configuration, while still allowing them to be outside of the actual configuration, while still allowing them to be
used by the answerer (exchange of keying material is still needed, used by the answerer (exchange of keying material is still needed,
e.g. inband). The basic SDP Capability Negotiation framework defined e.g. inband). The basic SDP Capability Negotiation framework defined
here does not include the ability to do so, however extensions that here does not include the ability to do so, however extensions that
enable that may be defined. enable that may be defined.
3.10. Indicating Bandwidth Usage 3.10. Indicating Bandwidth Usage
The amount of bandwidth to use for a particular media stream depends The amount of bandwidth used for a particular media stream depends
on the codecs, transport protocol and other parameters being used. on the negotiated codecs, transport protocol and other parameters.
For example use of Secure RTP [RFC3711] with integrity protection For example use of Secure RTP [RFC3711] with integrity protection
requires more bandwidth than plain RTP [RFC3551]. SDP defines the requires more bandwidth than plain RTP [RFC3551]. SDP defines the
bandwidth ("b=") parameter to indicate the proposed bandwidth for bandwidth ("b=") parameter to indicate the proposed bandwidth for
the session or media stream. the session or media stream.
In current SDP, each media description contains one transport In SDP as defined by [RFC4566], each media description contains one
protocol and one or more codecs. When specifying the proposed transport protocol and one or more codecs. When specifying the
bandwidth, the worst case scenario must be taken into account, i.e., proposed bandwidth, the worst case scenario must be taken into
use of the highest bandwidth codec provided, the transport protocol account, i.e., use of the highest bandwidth codec provided, the
indicated, and the worst case (bandwidth-wise) parameters that can transport protocol indicated, and the worst case (bandwidth-wise)
be negotiated (e.g., a 32-bit HMAC or an 80-bit HMAC). parameters that can be negotiated (e.g., a 32-bit HMAC or an 80-bit
HMAC).
The core SDP capability negotiation framework does not provide a way The core SDP capability negotiation framework does not provide a way
to negotiate bandwidth parameters. The issue thus remains, however to negotiate bandwidth parameters. The issue thus remains, however
it is potentially worse than with current SDP, since it is easier to it is potentially worse than with SDP per [RFC4566], since it is
negotiate additional codecs, and furthermore possible to negotiate easier to negotiate additional codecs, and furthermore possible to
different transport protocols. The recommended approach for negotiate different transport protocols. The recommended approach
addressing this is the same as for plain SDP; the worst case (now for addressing this is the same as for plain SDP; the worst case
including potential configurations) needs to be taken into account (now including potential configurations) needs to be taken into
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 current SDP (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. Also, the Transport Independent address this shortcoming. Also, the Transport Independent
Application Specific Maximum (TIAS) bandwidth type defined in Application Specific Maximum (TIAS) bandwidth type defined in
[RFC3890] can be used to alleviate bandwidth variability concerns [RFC3890] can be used to alleviate bandwidth variability concerns
due to different transport protocols. due to different transport protocols.
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 non-feedback based protocol is offered as an multiplexing. If a feedback based protocol is offered as the actual
alternative transport protocol, it is possible that the bandwidth configuration transport protocol, a non-feedback based protocol is
indication should have been lower. offered as a potential configuration transport protocol and ends up
being used, the actual bandwidth usage may be lower than the
indicated bandwidth value in the offer (and vice versa).
3.11. Dealing with Large Number of Potential Configurations 3.11. Dealing with Large Number of Potential Configurations
When using the SDP Capability Negotiation, it is easy to generate When using the SDP Capability Negotiation, it is easy to generate
offers that contain a large number of potential configurations. For offers that contain a large number of potential configurations. For
example, in the offer: example, in the offer:
v=0 v=0
o=- 25678 753849 IN IP4 192.0.2.1 o=- 25678 753849 IN IP4 192.0.2.1
s= s=
skipping to change at page 49, line 13 skipping to change at page 49, line 34
agent A and a SIP user agent B, that need to perform some kind of agent A and a SIP user agent B, that need to perform some kind of
processing on the SDP exchanged between A and B, in order for the processing on the SDP exchanged between A and B, in order for the
session establishment to operate as intended. Examples of such session establishment to operate as intended. Examples of such
intermediaries include Session Border Controllers (SBCs) that may intermediaries include Session Border Controllers (SBCs) that may
perform media relaying, Proxy Call Session Control Functions (P- perform media relaying, Proxy Call Session Control Functions (P-
CSCF) that may authorize use of a certain amount of network CSCF) that may authorize use of a certain amount of network
resources (bandwidth), etc. The presence and design of such resources (bandwidth), etc. The presence and design of such
intermediaries may not follow the "Internet" model or the SIP intermediaries may not follow the "Internet" model or the SIP
requirements for proxies (which are not supposed to look in message requirements for proxies (which are not supposed to look in message
bodies such as SDP), however they are a fact of life in some bodies such as SDP), however they are a fact of life in some
deployment scenarios currently and hence deserve consideration. deployment scenarios and hence deserve consideration.
If the intermediary needs to understand the characteristics of the If the intermediary needs to understand the characteristics of the
media sessions being negotiated, e.g. the amount of bandwidth used media sessions being negotiated, e.g. the amount of bandwidth used
or the transport protocol negotiated, then use of the SDP Capability or the transport protocol negotiated, then use of the SDP Capability
Negotiation framework may impact them. For example, some Negotiation framework may impact them. For example, some
intermediaries are known to disallow answers where the transport intermediaries are known to disallow answers where the transport
protocol differs from the one in the offer. Use of the SDP protocol differs from the one in the offer. Use of the SDP
Capability Negotiation framework in the presence of such Capability Negotiation framework in the presence of such
intermediaries could lead to session failures. Intermediaries that intermediaries could lead to session failures. Intermediaries that
need to authorize use of network resources based on the negotiated need to authorize use of network resources based on the negotiated
skipping to change at page 66, line 11 skipping to change at page 66, line 43
first discarding all potential configurations that contain first discarding all potential configurations that contain
unsupported transport protocols, unsupported or invalid mandatory unsupported transport protocols, unsupported or invalid mandatory
attribute capabilities, or unsupported mandatory extension attribute capabilities, or unsupported mandatory extension
configurations. The answerer SHOULD also look out for potential configurations. The answerer SHOULD also look out for potential
configurations that are designed to pass the above test, but configurations that are designed to pass the above test, but
nevertheless produce a large number of potential configuration SDPs nevertheless produce a large number of potential configuration SDPs
that cannot be supported. that cannot be supported.
A possible way of achieving that is for an attacker to find a A possible way of achieving that is for an attacker to find a
valid session-level attribute that causes conflicts or otherwise valid session-level attribute that causes conflicts or otherwise
interferes with individual media description configurations. interferes with individual media description configurations. At
Currently, we do not know of such an SDP attribute, however this time of publication of this document, we do not know of such an
does not mean it does not exist, or that it will not exist in the SDP attribute, however this does not mean it does not exist, or
future. If such attributes are found to exist, implementers should that it will not exist in the future. If such attributes are found
explicitly protect against them. to exist, implementers should explicitly protect against them.
A significant number of valid and supported potential configurations A significant number of valid and supported potential configurations
may remain. However, since all of those contain only valid and may remain. However, since all of those contain only valid and
supported transport protocols and attributes, it is expected that supported transport protocols and attributes, it is expected that
only a few of them will need to be processed on average. Still, the only a few of them will need to be processed on average. Still, the
answerer MUST ensure that it does not needlessly consume large answerer MUST ensure that it does not needlessly consume large
amounts of memory or CPU resources when processing those as well as amounts of memory or CPU resources when processing those as well as
be prepared to handle the case where a large number of potential be prepared to handle the case where a large number of potential
configurations still need to be processed. configurations still need to be processed.
skipping to change at page 66, line 39 skipping to change at page 67, line 27
The IANA is hereby requested to register the following new SDP The IANA is hereby requested to register the following new SDP
attributes as follows: attributes as follows:
Attribute name: csup Attribute name: csup
Long form name: Supported capability negotiation extensions Long form name: Supported capability negotiation extensions
Type of attribute: Session-level and media-level Type of attribute: Session-level and media-level
Subject to charset: No Subject to charset: No
Purpose: Option tags for supported SDP capability Purpose: Option tags for supported SDP capability
negotiation extensions negotiation extensions
Appropriate values: See Section 3.3.1. Appropriate values: See Section 3.3.1. of RFCXXXX
-- Note to RFC editor:
-- replace RFCXXXX by this RFC number
Contact name: Flemming Andreasen, fandreas@cisco.com
Attribute name: creq Attribute name: creq
Long form name: Required capability negotiation extensions Long form name: Required capability negotiation extensions
Type of attribute: Session-level and media-level Type of attribute: Session-level and media-level
Subject to charset: No Subject to charset: No
Purpose: Option tags for required SDP capability Purpose: Option tags for required SDP capability
negotiation extensions negotiation extensions
Appropriate values: See Section 3.3.2. Appropriate values: See Section 3.3.2. of RFCXXXX
-- Note to RFC editor:
-- replace RFCXXXX by this RFC number
Contact name: Flemming Andreasen, fandreas@cisco.com
Attribute name: acap Attribute name: acap
Long form name: Attribute capability Long form name: Attribute capability
Type of attribute: Session-level and media-level Type of attribute: Session-level and media-level
Subject to charset: No Subject to charset: No
Purpose: Attribute capability containing an attribute Purpose: Attribute capability containing an attribute
name and associated value name and associated value
Appropriate values: See Section 3.4.1. Appropriate values: See Section 3.4.1. of RFCXXXX
-- Note to RFC editor:
-- replace RFCXXXX by this RFC number
Contact name: Flemming Andreasen, fandreas@cisco.com
Attribute name: tcap Attribute name: tcap
Long form name: Transport Protocol Capability Long form name: Transport Protocol Capability
Type of attribute: Session-level and media-level Type of attribute: Session-level and media-level
Subject to charset: No Subject to charset: No
Purpose: Transport protocol capability listing one or Purpose: Transport protocol capability listing one or
more transport protocols more transport protocols
Appropriate values: See Section 3.4.2. Appropriate values: See Section 3.4.2. of RFCXXXX
-- Note to RFC editor:
-- replace RFCXXXX by this RFC number
Contact name: Flemming Andreasen, fandreas@cisco.com
Attribute name: pcfg Attribute name: pcfg
Long form name: Potential Configuration Long form name: Potential Configuration
Type of attribute: Media-level Type of attribute: Media-level
Subject to charset: No Subject to charset: No
Purpose: Potential configuration for SDP capability Purpose: Potential configuration for SDP capability
negotiation negotiation
Appropriate values: See Section 3.5.1. Appropriate values: See Section 3.5.1. of RFCXXXX
-- Note to RFC editor:
-- replace RFCXXXX by this RFC number
Contact name: Flemming Andreasen, fandreas@cisco.com
Attribute name: acfg Attribute name: acfg
Long form name: Actual configuration Long form name: Actual configuration
Type of attribute: Media-level Type of attribute: Media-level
Subject to charset: No Subject to charset: No
Purpose: Actual configuration for SDP capability Purpose: Actual configuration for SDP capability
negotiation negotiation
Appropriate values: See Section 3.5.2. Appropriate values: See Section 3.5.2. of RFCXXXX
-- Note to RFC editor:
-- replace RFCXXXX by this RFC number
Contact name: Flemming Andreasen, fandreas@cisco.com
6.2. New SDP Capability Negotiation Option Tag Registry 6.2. New SDP Capability Negotiation Option Tag Registry
The IANA is hereby requested to create a new SDP Capability The IANA is hereby requested to create a new SDP Capability
Negotiation Option Tag registry. An IANA SDP Capability Negotiation Negotiation Option Tag registry. An IANA SDP Capability Negotiation
option tag registration MUST be documented in an RFC in accordance option tag registration MUST be documented in an RFC in accordance
with the [RFC2434] Specification Required policy. The RFC MUST with the [RFC5226] Specification Required policy. The RFC MUST
provide the name of the option tag, a syntax and a semantic provide the name of the option tag, a syntax and a semantic
specification of any new SDP attributes and any extensions to the specification of any new SDP attributes and any extensions to the
potential and actual configuration attributes provided in this potential and actual configuration attributes provided in this
document. New SDP attributes that are intended to be capabilities document. New SDP attributes that are intended to be capabilities
for use by the capability negotiation framework MUST adhere to the for use by the capability negotiation framework MUST adhere to the
guidelines provided in Section 3.4.3. Extensions to the potential guidelines provided in Section 3.4.3. Extensions to the potential
and actual configuration attributes MUST adhere to the syntax and actual configuration attributes MUST adhere to the syntax
provided in Section 3.5.1. and 3.5.2. provided in Section 3.5.1. and 3.5.2.
The option tag "cap-v0" is defined in this document and the IANA is The option tag "cap-v0" is defined in this document and the IANA is
hereby requested to register this option tag. hereby requested to register this option tag.
6.3. New SDP Capability Negotiation Potential Configuration Parameter 6.3. New SDP Capability Negotiation Potential Configuration Parameter
Registry Registry
The IANA is hereby requested to create a new SDP Capability The IANA is hereby requested to create a new SDP Capability
Negotiation Potential Configuration Parameter registry. An IANA SDP Negotiation Potential Configuration Parameter registry. An IANA SDP
Capability Negotiation potential configuration registration MUST be Capability Negotiation potential configuration registration MUST be
documented in an RFC in accordance with the [RFC2434] Specification documented in an RFC in accordance with the [RFC5226] Specification
Required policy. The RFC MUST define the syntax and semantics of Required policy. The RFC MUST define the syntax and semantics of
each new potential configuration parameter. The syntax MUST adhere each new potential configuration parameter. The syntax MUST adhere
to the syntax provided for extensions in Section 3.5.1. and the to the syntax provided for extensions in Section 3.5.1. and the
semantics MUST adhere to the semantics provided for extensions in semantics MUST adhere to the semantics provided for extensions in
Section 3.5.1. and 3.5.2. Associated with each registration MUST be Section 3.5.1. and 3.5.2. Associated with each registration MUST be
the encoding name for the parameter as well as a short descriptive the encoding name for the parameter as well as a short descriptive
name for it. name for it.
The potential configuration parameters "a" for "attribute" and "t" The potential configuration parameters "a" for "attribute" and "t"
for "transport protocol" are defined in this document and the IANA for "transport protocol" are defined in this document and the IANA
skipping to change at page 68, line 36 skipping to change at page 69, line 42
7. Acknowledgments 7. Acknowledgments
The SDP Capability Negotiation solution defined in this document The SDP Capability Negotiation solution defined in this document
draws on the overall capability negotiation framework that was draws on the overall capability negotiation framework that was
defined by [SDPng]. Also, the SDP Capability Negotiation solution is defined by [SDPng]. Also, the SDP Capability Negotiation solution is
heavily influenced by the discussions and work done by the SDP heavily influenced by the discussions and work done by the SDP
Capability Negotiation Design Team. The following people in Capability Negotiation Design Team. The following people in
particular provided useful comments and suggestions to either the particular provided useful comments and suggestions to either the
document itself or the overall direction of the solution defined in document itself or the overall direction of the solution defined in
here: Francois Audet, John Elwell, Roni Even, Robert Gilman, Cullen here: Francois Audet, John Elwell, Roni Even, Miguel Garcia, Robert
Jennings, Jonathan Lennox, Matt Lepinski, Joerg Ott, Colin Perkins, Gilman, Cullen Jennings, Jonathan Lennox, Matt Lepinski, Jean-
Jonathan Rosenberg, Thomas Stach, and Dan Wing. Francois Mule, Joerg Ott, Colin Perkins, Jonathan Rosenberg, Thomas
Stach, and Dan Wing.
8. Change Log 8. Change Log
8.1. draft-ietf-mmusic-sdp-capability-negotiation-08 8.1. draft-ietf-mmusic-sdp-capability-negotiation-09
Incorporated Working Group Chair review comments and a few additional
comments as follows:
o Clarified that the "a=creq" attribute MUST NOT be used in an
answer (Section 3.6.2. ).
o Various editorial changes throughout.
8.2. 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 69, line 23 skipping to change at page 70, line 43
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.2. draft-ietf-mmusic-sdp-capability-negotiation-07 8.3. 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 70, line 5 skipping to change at page 71, line 21
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.3. draft-ietf-mmusic-sdp-capability-negotiation-06 8.4. 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 71, line 23 skipping to change at page 72, line 40
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.4. draft-ietf-mmusic-sdp-capability-negotiation-05 8.5. 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 72, line 27 skipping to change at page 73, line 45
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.5. draft-ietf-mmusic-sdp-capability-negotiation-04 8.6. 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.6. draft-ietf-mmusic-sdp-capability-negotiation-03 8.7. 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.7. draft-ietf-mmusic-sdp-capability-negotiation-02 8.8. 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 73, line 46 skipping to change at page 75, line 16
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.8. draft-ietf-mmusic-sdp-capability-negotiation-01 8.9. 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 74, line 33 skipping to change at page 76, line 5
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.9. draft-ietf-mmusic-sdp-capability-negotiation-00 8.10. 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 76, line 12 skipping to change at page 77, line 12
o Some terminology change throughout to more clearly indicate what o Some terminology change throughout to more clearly indicate what
constitutes capabilities and what constitutes configurations. constitutes capabilities and what constitutes configurations.
9. References 9. References
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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[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.
[RFC4234] Crocker, D., and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. 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
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
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 79, line 20 skipping to change at page 80, line 20
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
 End of changes. 75 change blocks. 
179 lines changed or deleted 222 lines changed or added

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