draft-ietf-mmusic-sdp-capability-negotiation-09.txt   draft-ietf-mmusic-sdp-capability-negotiation-10.txt 
MMUSIC Working Group F. Andreasen MMUSIC Working Group F. Andreasen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended Status: Proposed Standard July 11, 2008 Intended Status: Proposed Standard May 19, 2009
Expires: January 2009 Expires: November 2009
SDP Capability Negotiation SDP Capability Negotiation
draft-ietf-mmusic-sdp-capability-negotiation-09.txt draft-ietf-mmusic-sdp-capability-negotiation-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance with
any applicable patent or other IPR claims of which he or she is the provisions of BCP 78 and BCP 79.
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
BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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 January 11, 2009. This Internet-Draft will expire on November 19, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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
skipping to change at page 2, line 24 skipping to change at page 2, line 41
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)
may be provided in other documents. may be provided in other documents.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................4
2. Conventions used in this document..............................7 2. Conventions used in this document..............................7
3. SDP Capability Negotiation Solution............................7 3. SDP Capability Negotiation Solution............................7
3.1. SDP Capability Negotiation Model..........................7 3.1. SDP Capability Negotiation Model..........................7
3.2. Solution Overview........................................10 3.2. Solution Overview........................................11
3.3. Version and Extension Indication Attributes..............14 3.3. Version and Extension Indication Attributes..............15
3.3.1. Supported Capability Negotiation Extensions Attribute14 3.3.1. Supported Capability Negotiation Extensions Attribute15
3.3.2. Required Capability Negotiation Extensions Attribute15 3.3.2. Required Capability Negotiation Extensions Attribute17
3.4. Capability Attributes....................................17 3.4. Capability Attributes....................................19
3.4.1. Attribute Capability Attribute......................17 3.4.1. Attribute Capability Attribute......................19
3.4.2. Transport Protocol Capability Attribute.............19 3.4.2. Transport Protocol Capability Attribute.............20
3.4.3. Extension Capability Attributes.....................21 3.4.3. Extension Capability Attributes.....................22
3.5. Configuration Attributes.................................21 3.5. Configuration Attributes.................................23
3.5.1. Potential Configuration Attribute...................21 3.5.1. Potential Configuration Attribute...................23
3.5.2. Actual Configuration Attribute......................29 3.5.2. Actual Configuration Attribute......................30
3.6. Offer/Answer Model Extensions............................31 3.6. Offer/Answer Model Extensions............................32
3.6.1. Generating the Initial Offer........................31 3.6.1. Generating the Initial Offer........................32
3.6.2. Generating the Answer...............................34 3.6.2. Generating the Answer...............................36
3.6.2.1. Example Views of Potential Configurations......40 3.6.2.1. Example Views of Potential Configurations......42
3.6.3. Offerer Processing of the Answer....................42 3.6.3. Offerer Processing of the Answer....................44
3.6.4. Modifying the Session...............................43 3.6.4. Modifying the Session...............................45
3.7. Interactions with ICE....................................44 3.7. Interactions with ICE....................................46
3.8. Interactions with SIP Option Tags........................45 3.8. Interactions with SIP Option Tags........................47
3.9. Processing Media before Answer...........................46 3.9. Processing Media before Answer...........................48
3.10. Indicating Bandwidth Usage..............................47 3.10. Indicating Bandwidth Usage..............................49
3.11. Dealing with Large Number of Potential Configurations...48 3.11. Dealing with Large Number of Potential Configurations...50
3.12. SDP Capability Negotiation and Intermediaries...........49 3.12. SDP Capability Negotiation and Intermediaries...........51
3.13. Considerations for Specific Attribute Capabilities......51 3.13. Considerations for Specific Attribute Capabilities......53
3.13.1. The rtpmap and fmtp Attributes.....................51 3.13.1. The rtpmap and fmtp Attributes.....................53
3.13.2. Direction Attributes...............................52 3.13.2. Direction Attributes...............................54
3.14. Relationship to RFC 3407................................52 3.14. Relationship to RFC 3407................................54
4. Examples......................................................52 4. Examples......................................................54
4.1. Multiple Transport Protocols.............................53 4.1. Multiple Transport Protocols.............................55
4.2. Best-Effort SRTP with Session-Level MIKEY and Media Level 4.2. DTLS-SRTP or SRTP with Media Level Security Descriptions.58
Security Descriptions.........................................56 4.3. Best-Effort SRTP with Session-Level MIKEY and Media Level
4.3. SRTP with Session-Level MIKEY and Media Level Security Security Descriptions.........................................62
Descriptions as Alternatives..................................61 4.4. SRTP with Session-Level MIKEY and Media Level Security
5. Security Considerations.......................................64 Descriptions as Alternatives..................................67
6. IANA Considerations...........................................67 5. Security Considerations.......................................69
6.1. New SDP Attributes.......................................67 6. IANA Considerations...........................................72
6.2. New SDP Capability Negotiation Option Tag Registry.......68 6.1. New SDP Attributes.......................................72
6.2. New SDP Capability Negotiation Option Tag Registry.......74
6.3. New SDP Capability Negotiation Potential Configuration 6.3. New SDP Capability Negotiation Potential Configuration
Parameter Registry............................................69 Parameter Registry............................................74
7. Acknowledgments...............................................69 7. Acknowledgments...............................................75
8. Change Log....................................................70 8. Change Log....................................................75
8.1. draft-ietf-mmusic-sdp-capability-negotiation-09..........70 8.1. draft-ietf-mmusic-sdp-capability-negotiation-10..........75
8.2. draft-ietf-mmusic-sdp-capability-negotiation-08..........70 8.2. draft-ietf-mmusic-sdp-capability-negotiation-09..........76
8.3. draft-ietf-mmusic-sdp-capability-negotiation-07..........70 8.3. draft-ietf-mmusic-sdp-capability-negotiation-08..........76
8.4. draft-ietf-mmusic-sdp-capability-negotiation-06..........71 8.4. draft-ietf-mmusic-sdp-capability-negotiation-07..........76
8.5. draft-ietf-mmusic-sdp-capability-negotiation-05..........72 8.5. draft-ietf-mmusic-sdp-capability-negotiation-06..........77
8.6. draft-ietf-mmusic-sdp-capability-negotiation-04..........73 8.6. draft-ietf-mmusic-sdp-capability-negotiation-05..........78
8.7. draft-ietf-mmusic-sdp-capability-negotiation-03..........74 8.7. draft-ietf-mmusic-sdp-capability-negotiation-04..........79
8.8. draft-ietf-mmusic-sdp-capability-negotiation-02..........74 8.8. draft-ietf-mmusic-sdp-capability-negotiation-03..........80
8.9. draft-ietf-mmusic-sdp-capability-negotiation-01..........75 8.9. draft-ietf-mmusic-sdp-capability-negotiation-02..........80
8.10. draft-ietf-mmusic-sdp-capability-negotiation-00.........76 8.10. draft-ietf-mmusic-sdp-capability-negotiation-01.........81
9. References....................................................77 8.11. draft-ietf-mmusic-sdp-capability-negotiation-00.........82
9.1. Normative References.....................................77 9. References....................................................83
9.2. Informative References...................................77 9.1. Normative References.....................................83
Author's Addresses...............................................79 9.2. Informative References...................................83
Intellectual Property Statement..................................79 Author's Addresses...............................................85
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 10, line 38 skipping to change at page 11, line 38
protocols (e.g. "RTP/AVP") as capabilities. protocols (e.g. "RTP/AVP") as capabilities.
o Two new SDP 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 by default preferred over the actual
included in the "m=" line and its associated parameters. configuration included in the "m=" line and its associated
parameters.
This preference order was chosen to provide maximum
backwards compatibility for the capability negotiation
framework and the possible values offered for a session.
For example, an entity that wants to establish a secure
RTP media stream but is willing to accept a plain RTP
media stream (assumed to be the least common denominator
for most endpoints), can offer plain RTP in the actual
configuration and use the capability negotiation
extensions to indicate the preference for secure RTP.
Entities that do not support the capability negotiation
extensions or secure RTP will then default to plain RTP.
o A new attribute ("a=acfg") to be used in an answer SDP. The o A new attribute ("a=acfg") to be used in an answer SDP. The
attribute identifies a potential configuration from an offer attribute identifies a potential configuration from an offer
SDP which was used as an actual configuration to form the SDP which was used as an actual configuration to form the
answer SDP. Extension capabilities can be included as well. answer SDP. Extension capabilities can be included as well.
o Extensions to the offer/answer model that allow for capabilities o Extensions to the offer/answer model that allow for capabilities
and potential configurations to be included in an offer. and potential configurations to be included in an offer.
Capabilities can be provided at the session level and the media Capabilities can be provided at the session level and the media
level. Potential configurations can be included at the media level. Potential configurations can be included only at the media
level only, where they constitute alternative offers that may be level, where they constitute alternative offers that may be
accepted by the answerer instead of the actual configuration(s) accepted by the answerer instead of the actual configuration(s)
included in the "m=" line(s) and associated parameters. The included in the "m=" line(s) and associated parameters. The
answerer indicates which (if any) of the potential configurations answerer indicates which (if any) of the potential configurations
it used to form the answer by including the actual configuration it used to form the answer by including the actual configuration
attribute ("a=acfg") in the answer. Capabilities may be included attribute ("a=acfg") in the answer. Capabilities may be included
in answers as well, where they can aid in guiding a subsequent in answers as well, where they can aid in guiding a subsequent
new offer. new offer.
The mechanism is illustrated by the offer/answer exchange below, The mechanism is illustrated by the offer/answer exchange below,
where Alice sends an offer to Bob: where Alice sends an offer to Bob:
skipping to change at page 15, line 4 skipping to change at page 16, line 34
attribute to indicate support for the SDP Capability Negotiation attribute to indicate support for the SDP Capability Negotiation
framework specified in this document. framework specified in this document.
The following examples illustrate use of the "a=csup" attribute with The following examples illustrate use of the "a=csup" attribute with
the "cap-v0" option tag and two hypothetical option tags, "foo" and the "cap-v0" option tag and two hypothetical option tags, "foo" and
"bar" (note the lack of white space): "bar" (note the lack of white space):
a=csup:cap-v0 a=csup:cap-v0
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 only to the media
description in question only (option-tags provided at the session description in question (option-tags provided at the session level
level apply as well). There MUST NOT be more than one "a=csup" apply as well). There MUST NOT be more than one "a=csup" attribute
attribute at the session-level and one at the media-level (one per at the session-level and one at the media-level (one per media
media description in the latter case). 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 16, line 20 skipping to change at page 18, line 4
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):
a=creq:cap-v0 a=creq:cap-v0
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 only to the media
description in question only (required option tags provided at the description in question (required option tags provided at the
session level apply as well). There MUST NOT be more than one session level apply as well). There MUST NOT be more than one
"a=creq" attribute at the session-level and one "a=creq" attribute "a=creq" attribute at the session-level and one "a=creq" attribute
at 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
skipping to change at page 18, line 11 skipping to change at page 19, line 37
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 [RFC5234] 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 When the attribute capability contains session-level attributes, the
the attribute capability contains session-level attributes, whereas "acap" attribute can only be provided at the session level.
media level attributes can be provided in attribute capabilities at Conversely, media level attributes can be provided in attribute
either the media level or session-level. The base SDP Capability capabilities at either the media level or session-level. The base
Negotiation framework however only defines procedures for use of SDP Capability Negotiation framework however only defines procedures
media-level attribute capabilities at the media level (extensions for use of media-level attribute capabilities at the media level
may define use at the session level). (extensions may define use at the session level).
Each occurrence of the "acap" attribute in the entire session Each occurrence of the "acap" attribute in the entire session
description MUST use a different value of <att-cap-num>. description MUST use a different value of <att-cap-num>.
Consecutive numbering of the <att-cap-num> values is not required. Consecutive numbering of the <att-cap-num> values is not required.
There is a need to be able to reference both session-level and There is a need to be able to reference both session-level and
media-level attributes in potential configurations at the media media-level attributes in potential configurations at the media
level, and this provides for a simple solution to avoiding overlap level, and this provides for a simple solution to avoiding overlap
between the references (handles) to each attribute capability. between the references (handles) to each attribute capability.
skipping to change at page 19, line 11 skipping to change at page 20, line 37
MIKEY [RFC3830] with the key-mgmt attribute [RFC4567]. The fourth MIKEY [RFC3830] with the key-mgmt attribute [RFC4567]. The fourth
provides SRTP parameters by use of security descriptions with the provides SRTP parameters by use of security descriptions with the
crypto attribute [RFC4568]. Note that the line-wrapping and new- crypto attribute [RFC4568]. Note that the line-wrapping and new-
lines in example three and four are provided for formatting reasons lines in example three and four are provided for formatting reasons
only - they are not permitted in actual SDP. only - they are not permitted in actual SDP.
Readers familiar with RFC 3407 may notice the similarity between Readers familiar with RFC 3407 may notice the similarity between
the RFC 3407 "cpar" attribute and the above. There are however a the RFC 3407 "cpar" attribute and the above. There are however a
couple of important differences, notably that the "acap" attribute couple of important differences, notably that the "acap" attribute
contains a handle that enables referencing it and it furthermore contains a handle that enables referencing it and it furthermore
supports attributes only (the "cpar" attribute defined in RFC 3407 supports only attributes (the "cpar" attribute defined in RFC 3407
supports bandwidth information as well). The "acap" attribute also supports bandwidth information as well). The "acap" attribute also
is not automatically associated with any particular capabilities. is not automatically associated with any particular capabilities.
See Section 3.14. for the relationship to RFC 3407. See Section 3.14. for the relationship to RFC 3407.
3.4.2. Transport Protocol Capability Attribute 3.4.2. Transport Protocol Capability Attribute
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:
skipping to change at page 20, line 16 skipping to change at page 21, line 42
different "tcap" attributes is not required. different "tcap" attributes is not required.
Below, we provide examples of the "a=tcap" attribute: Below, we provide examples of the "a=tcap" attribute:
a=tcap:1 RTP/AVP a=tcap:1 RTP/AVP
a=tcap:2 RTP/AVPF a=tcap:2 RTP/AVPF
a=tcap:3 RTP/SAVP RTP/SAVPF a=tcap:3 RTP/SAVP RTP/SAVPF
a=tcap:5 UDP/TLS/RTP/SAVP
The first one provides a capability for the "RTP/AVP" profile The first one provides a capability for the "RTP/AVP" profile
defined in [RFC3551] and the second one provides a capability for defined in [RFC3551] and the second one provides a capability for
the RTP with RTCP-Based Feedback profile defined in [RFC4585]. The the RTP with RTCP-Based Feedback profile defined in [RFC4585]. The
third one provides capabilities for the "RTP/SAVP" (transport third one provides capabilities for the "RTP/SAVP" (transport
capability number 3) and "RTP/SAVPF" profiles (transport protocol capability number 3) and "RTP/SAVPF" profiles (transport protocol
capability number 4). capability number 4). The last one provides capabilities for
"UDP/TLS/RTP/SAVP", i.e. DTLS-SRTP [DTLS-SRTP](transport capability
number 5).
The ability to use a particular transport protocol is inherently The ability to use a particular transport protocol is inherently
implied by including it in the "m=" line, regardless of whether it implied by including it in the "m=" line, regardless of whether it
is provided in a "tcap" attribute or not. However, if a potential is provided in a "tcap" attribute or not. However, if a potential
configuration needs to reference that transport protocol as a configuration needs to reference that transport protocol as a
capability, the transport protocol MUST be included explicitly in a capability, the transport protocol MUST be included explicitly in a
"tcap" attribute. "tcap" attribute.
This may seem redundant (and indeed it is from the offerer's point This may seem redundant (and indeed it is from the offerer's point
of view), however it is done to protect against intermediaries of view), however it is done to protect against intermediaries
skipping to change at page 21, line 31 skipping to change at page 23, line 15
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). The attribute can be provided at the media-level only. included). The attribute can be provided only at the media-level.
The "pcfg" attribute adheres to the RFC 4566 "attribute" production, The "pcfg" attribute adheres to the RFC 4566 "attribute" production,
with an att-value defined as follows: with an att-value defined as follows:
att-value = config-number [1*WSP pot-cfg-list] att-value = config-number [1*WSP pot-cfg-list]
config-number = 1*DIGIT ;defined in [RFC5234] config-number = 1*DIGIT ;defined in [RFC5234]
pot-cfg-list = pot-config *(1*WSP pot-config) pot-cfg-list = pot-config *(1*WSP pot-config)
pot-config = attribute-config-list / 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 only at the
level only and there can be multiple instances of it within a given media-level and there can be multiple instances of it within a given
media description. The attribute includes a configuration number, media description. The attribute includes a configuration number,
which is an integer between 1 and 2^31-1 (both included). The which is an integer between 1 and 2^31-1 (both included). The
configuration number MUST be unique within the media description configuration number MUST be unique within the media description
(i.e. it has media level scope only). The configuration number also (i.e. it has only media level scope). The configuration number also
indicates the relative preference of potential configurations; lower indicates the relative preference of potential configurations; lower
numbers are preferred over higher numbers. Consecutive numbering of numbers are preferred over higher numbers. Consecutive numbering of
the configuration numbers in different "pcfg" attributes in a media the configuration numbers in different "pcfg" attributes in a media
description is not required. description is not required.
A potential configuration list is normally provided after the A potential configuration list is normally provided after the
configuration number. When the potential configuration list is configuration number. When the potential configuration list is
omitted, the potential configuration equals the actual omitted, the potential configuration equals the actual
configuration. The potential configuration list contains one or more configuration. The potential configuration list contains one or more
of attribute, transport and extension configuration lists. A of attribute, transport and extension configuration lists. A
skipping to change at page 26, line 44 skipping to change at page 28, line 20
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
configuration attribute MUST be ignored, unless they are prefixed configuration attribute MUST be ignored, unless they are prefixed
with the plus ("+") sign, which indicates that the extension is with the plus ("+") sign, which indicates that the extension is
mandatory and MUST be supported in order to use that potential mandatory and MUST be supported in order to use that potential
configuration. configuration.
The "creq" attribute and its associated rules can be used to The "creq" attribute and its associated rules can be used to
ensure that required extensions are supported in the first place. ensure that required extensions are supported in the first place.
Potential configuration attributes can be provided at the media Potential configuration attributes can be provided only at the media
level only, however it is possible to reference capabilities level, however it is possible to reference capabilities provided at
provided at either the session or media level. There are certain either the session or media level. There are certain semantic rules
semantic rules and restrictions associated with this: and restrictions associated with this:
A (media level) potential configuration attribute in a given media A (media level) potential configuration attribute in a given media
description MUST NOT reference a media-level capability provided in description MUST NOT reference a media-level capability provided in
a different media description; doing so invalidates that potential a different media description; doing so invalidates that potential
configuration (note that a potential configuration attribute can configuration (note that a potential configuration attribute can
contain more than one potential configuration by use of contain more than one potential configuration by use of
alternatives). A potential configuration attribute can however alternatives). A potential configuration attribute can however
reference a session-level capability. The semantics of doing so reference a session-level capability. The semantics of doing so
depends on the type of capability. In the case of transport protocol depends on the type of capability. In the case of transport protocol
capabilities it has no particular implication. In the case of capabilities it has no particular implication. In the case of
skipping to change at page 28, line 16 skipping to change at page 29, line 36
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 SDP attributes defined at time of publication of practice, with the SDP attributes defined at time of publication of
this document, it does not seem to be a significant problem, and this document, it does not seem to be a significant problem, and
hence the core SDP Capability Negotiation solution does not provide hence the core SDP Capability Negotiation solution does not provide
a solution to this issue. Instead, it is RECOMMENDED that use of a solution to this issue. Instead, it is RECOMMENDED that use of
session-level attributes in a potential configuration is avoided session-level attributes in a potential configuration is avoided
when possible, and when not, that such use is examined closely for when possible, and when not, that such use is examined closely for
any potential interaction issues. If interaction is possible, the any potential interaction issues. If interaction is possible, the
entity generating the SDP SHOULD NOT assume that well-defined entity generating the SDP SHOULD NOT assume that well-defined
operation will occur at the receiving entity. operation will occur at the receiving entity. This implies that
mechanisms which might have such interactions cannot be used in
security critical contexts.
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 30, line 4 skipping to change at page 31, line 27
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). The attribute can be provided at the media-level only. included). The attribute can be provided only at the media-level.
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 30, line 29 skipping to change at page 32, line 7
; defined in Section 3.5.1. ; defined in Section 3.5.1.
sel-transport-protocol-config = sel-transport-protocol-config =
"t=" trpr-cap-num ; defined in Section 3.5.1. "t=" trpr-cap-num ; defined in Section 3.5.1.
sel-extension-config = sel-extension-config =
ext-cap-name "=" 1*VCHAR ; defined in Section 3.5.1. ext-cap-name "=" 1*VCHAR ; defined in Section 3.5.1.
Note that white space is not permitted before the config-number. Note that white space is not permitted before the config-number.
The actual configuration ("a=acfg") attribute can be provided at the The actual configuration ("a=acfg") attribute can be provided only
media-level only. There MUST NOT be more than one occurrence of an at the media-level. There MUST NOT be more than one occurrence of an
actual configuration attribute within a given media description. actual configuration attribute within a given media description.
Below, we provide an example of the "a=acfg" attribute (building on Below, we provide an example of the "a=acfg" attribute (building on
the previous example with the potential configuration attribute): the previous example with the potential configuration attribute):
v=0 v=0
o=- 24351 621814 IN IP4 192.0.2.2 o=- 24351 621814 IN IP4 192.0.2.2
s= s=
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
t=0 0 t=0 0
skipping to change at page 31, line 31 skipping to change at page 33, line 13
in this document MUST include the following in the offer: in this document MUST include the following in the offer:
o Zero or more attribute capability attributes. There MUST be an o Zero or more attribute capability attributes. There MUST be an
attribute capability attribute ("a=acap") as defined in Section attribute capability attribute ("a=acap") as defined in Section
3.4.1. for each attribute name and associated value (if any) that 3.4.1. for each attribute name and associated value (if any) that
needs to be indicated as a capability in the offer. Attribute needs to be indicated as a capability in the offer. Attribute
capabilities may be included irrespective of whether they are capabilities may be included irrespective of whether they are
referenced by a potential configuration or not. referenced by a potential configuration or not.
Session-level attributes and associated values MUST be provided Session-level attributes and associated values MUST be provided
in attribute capabilities at the session-level only, whereas in attribute capabilities only at the session-level, whereas
media-level attributes and associated values can be provided in media-level attributes and associated values can be provided in
attribute capabilities at either the media-level or session- attribute capabilities at either the media-level or session-
level. Attributes that are allowed at either the session- or level. Attributes that are allowed at either the session- or
media-level can be provided in attribute capabilities at either media-level can be provided in attribute capabilities at either
level. level.
o Zero or more transport protocol capability attributes. There MUST o Zero or more transport protocol capability attributes. There MUST
be transport protocol capabilities as defined in Section 3.4.2. be transport protocol capabilities as defined in Section 3.4.2.
with values for each transport protocol that needs to be with values for each transport protocol that needs to be
indicated as a capability in the offer. Transport protocol indicated as a capability in the offer. Transport protocol
capabilities may be included irrespective of whether they are capabilities may be included irrespective of whether they are
referenced by a potential configuration or not. referenced by a potential configuration or not.
Transport protocol capabilities that apply to multiple media Transport protocol capabilities that apply to multiple media
descriptions SHOULD be provided at the session-level whereas descriptions SHOULD be provided at the session-level whereas
transport protocol capabilities that apply to a specific media transport protocol capabilities that apply only to a specific
description ("m=" line) only, SHOULD be provided within that media description ("m=" line), SHOULD be provided within that
particular media description. In either case, there MUST NOT be particular media description. In either case, there MUST NOT be
more than a single "a=tcap" attribute at the session-level and a more than a single "a=tcap" attribute at the session-level and a
single "a=tcap" attribute in each media description. single "a=tcap" attribute in each media description.
o Zero or more extension capability attributes. There MUST be one o Zero or more extension capability attributes. There MUST be one
or more extension capability attributes (as outlined in Section or more extension capability attributes (as outlined in Section
3.4.3. ) for each extension capability that is referenced by a 3.4.3. ) for each extension capability that is referenced by a
potential configuration. Extension capability attributes that are potential configuration. Extension capability attributes that are
not referenced by a potential configuration can be provided as not referenced by a potential configuration can be provided as
well. well.
skipping to change at page 33, line 19 skipping to change at page 34, line 34
The offerer SHOULD furthermore include the following: The offerer SHOULD furthermore include the following:
o A supported capability negotiation extension attribute ("a=csup") o A supported capability negotiation extension attribute ("a=csup")
at the session-level and/or media-level as defined in Section at the session-level and/or media-level as defined in Section
3.3.2. for each capability negotiation extension supported by the 3.3.2. for each capability negotiation extension supported by the
offerer and not included in a corresponding "a=creq" attribute offerer and not included in a corresponding "a=creq" attribute
(i.e., at the session-level or in the same media description). (i.e., at the session-level or in the same media description).
Option tags provided in a "a=csup" attribute at the session-level Option tags provided in a "a=csup" attribute at the session-level
indicate extensions supported for the entire session description, indicate extensions supported for the entire session description,
whereas option tags provided in a "a=csup" attribute in a media whereas option tags provided in a "a=csup" attribute in a media
description indicate extensions supported for that particular description indicate extensions supported for only that
media description only. particular media description.
Capabilities provided in an offer merely indicate what the offerer Capabilities provided in an offer merely indicate what the offerer
is capable of doing. They do not constitute a commitment or even an is capable of doing. They do not constitute a commitment or even an
indication to use them. In contrast, each potential configuration indication to use them. In contrast, each potential configuration
constitutes an alternative offer that the offerer would like to use. constitutes an alternative offer that the offerer would like to use.
The potential configurations MUST be used by the answerer to The potential configurations MUST be used by the answerer to
negotiate and establish the session. negotiate and establish the session.
The offerer MUST include one or more potential configuration The offerer MUST include one or more potential configuration
attributes ("a=pcfg") in each media description where the offerer attributes ("a=pcfg") in each media description where the offerer
wants to provide alternative offers (in the form of potential wants to provide alternative offers (in the form of potential
configurations). Each potential configuration attribute in a given configurations). Each potential configuration attribute in a given
media description MUST contain a unique configuration number and one media description MUST contain a unique configuration number and
or more potential configuration lists, as described in Section zero, one or more potential configuration lists, as described in
3.5.1. Each potential configuration list MUST refer to capabilities Section 3.5.1. Each potential configuration list MUST refer to
that are provided at the session-level or within that particular capabilities that are provided at the session-level or within that
media description; otherwise, the potential configuration is particular media description; otherwise, the potential configuration
considered invalid. The base SDP Capability Negotiation framework is considered invalid. The base SDP Capability Negotiation framework
REQUIRES that potential configurations do not reference any session- REQUIRES that potential configurations do not reference any session-
level attribute capabilities that contain media-level only level attribute capabilities that contain media-level only
attributes, however extensions may modify this behavior, as long as attributes, however extensions may modify this behavior, as long as
it is fully backwards compatible with the base specification. it is fully backwards compatible with the base specification.
Furthermore, it is RECOMMENDED that potential configurations avoid Furthermore, it is RECOMMENDED that potential configurations avoid
use of session-level capabilities whenever possible; refer to use of session-level capabilities whenever possible; refer to
Section 3.5.1. Section 3.5.1.
The current actual configuration is included in the "m=" line (as The current actual configuration is included in the "m=" line (as
defined by [RFC3264]) and any associated parameters for the media defined by [RFC3264]) and any associated parameters for the media
skipping to change at page 34, line 21 skipping to change at page 35, line 44
This can either be done implicitly (by not referencing any This can either be done implicitly (by not referencing any
capabilities), or explicitly (by providing and using capabilities capabilities), or explicitly (by providing and using capabilities
for the transport protocol and all the attributes that are part of for the transport protocol and all the attributes that are part of
the actual configuration). The latter may help detect the actual configuration). The latter may help detect
intermediaries that modify the actual configuration but are not intermediaries that modify the actual configuration but are not
SDP Capability Negotiation aware. SDP Capability Negotiation aware.
Per [RFC3264], once the offerer generates the offer, he must be Per [RFC3264], once the offerer generates the offer, he must be
prepared to receive incoming media in accordance with that offer. prepared to receive incoming media in accordance with that offer.
That rule applies here as well, but for the actual configurations That rule applies here as well, but only for the actual
provided in the offer only: Media received by the offerer according configurations provided in the offer: Media received by the offerer
to one of the potential configurations MAY be discarded, until the according to one of the potential configurations MAY be discarded,
offerer receives an answer indicating what the actual selected until the offerer receives an answer indicating what the actual
configuration is. Once that answer is received, incoming media MUST selected configuration is. Once that answer is received, incoming
be processed in accordance with the actual selected configuration media MUST be processed in accordance with the actual selected
indicated and the answer received (provided the offer/answer configuration indicated and the answer received (provided the
exchange completed successfully). offer/answer exchange completed successfully).
The above rule assumes that the offerer can determine whether The above rule assumes that the offerer can determine whether
incoming media adheres to the actual configuration offered or one of incoming media adheres to the actual configuration offered or one of
the potential configurations instead; this may not always be the the potential configurations instead; this may not always be the
case. If the offerer wants to ensure he does not play out any case. If the offerer wants to ensure he does not play out any
garbage, the offerer SHOULD discard all media received before the garbage, the offerer SHOULD discard all media received before the
answer SDP is received. Conversely, if the offerer wants to avoid answer SDP is received. Conversely, if the offerer wants to avoid
clipping, he should attempt to play any incoming media as soon as it clipping, he should attempt to play any incoming media as soon as it
is received (at the risk of playing out garbage). For further is received (at the risk of playing out garbage). For further
details, please refer to Section 3.9. details, please refer to Section 3.9.
skipping to change at page 39, line 44 skipping to change at page 41, line 32
attribute. In the case of attribute capabilities, only the known and attribute. In the case of attribute capabilities, only the known and
supported capabilities are included; unknown or unsupported supported capabilities are included; unknown or unsupported
attribute capabilities MUST NOT be included. attribute capabilities MUST NOT be included.
If the answerer supports one or more capability negotiation If the answerer supports one or more capability negotiation
extensions that were not included in a required capability extensions that were not included in a required capability
negotiation extensions attribute in the offer, then the answerer negotiation extensions attribute in the offer, then the answerer
SHOULD furthermore include a supported capability negotiation SHOULD furthermore include a supported capability negotiation
attribute ("a=csup") at the session-level with option tags for the attribute ("a=csup") at the session-level with option tags for the
extensions supported across media streams. Also, if the answerer extensions supported across media streams. Also, if the answerer
supports one or more capability negotiation extensions for supports one or more capability negotiation extensions for only
particular media descriptions only, then a supported capability particular media descriptions, then a supported capability
negotiation attribute with those option-tags SHOULD be included negotiation attribute with those option-tags SHOULD be included
within each relevant media description. The required capability within each relevant media description. The required capability
negotiation attribute ("a=creq") MUST NOT be used in an answer. 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.
skipping to change at page 44, line 15 skipping to change at page 46, line 10
If the answer indicates use of a potential configuration from the If the answer indicates use of a potential configuration from the
offer, then the guidelines provided in Section 3.6.3. for doing a offer, then the guidelines provided in Section 3.6.3. for doing a
second offer/answer exchange using that potential configuration as second offer/answer exchange using that potential configuration as
the actual configuration apply. the actual configuration apply.
3.7. Interactions with ICE 3.7. Interactions with ICE
Interactive Connectivity Establishment (ICE) [ICE] provides a Interactive Connectivity Establishment (ICE) [ICE] provides a
mechanism for verifying connectivity between two endpoints by mechanism for verifying connectivity between two endpoints by
sending STUN messages directly between the media endpoints. The sending STUN messages directly between the media endpoints. The
basic ICE specification [ICE] is defined to support UDP-based basic ICE specification [ICE] is only defined to support UDP-based
connectivity only, however it allows for extensions to support other connectivity, however it allows for extensions to support other
transport protocols, such as TCP, which is being specified in transport protocols, such as TCP, which is being specified in
[ICETCP]. ICE defines a new "a=candidate" attribute, which, among [ICETCP]. ICE defines a new "a=candidate" attribute, which, among
other things, indicates the possible transport protocol(s) to use other things, indicates the possible transport protocol(s) to use
and then associates a priority with each of them. The most preferred and then associates a priority with each of them. The most preferred
transport protocol that *successfully* verifies connectivity will transport protocol that *successfully* verifies connectivity will
end up being used. end up being used.
When using ICE, it is thus possible that the transport protocol that When using ICE, it is thus possible that the transport protocol that
will be used differs from what is specified in the "m=" line. Since will be used differs from what is specified in the "m=" line. Since
both ICE and SDP Capability Negotiation may specify alternative both ICE and SDP Capability Negotiation may specify alternative
skipping to change at page 45, line 10 skipping to change at page 47, line 6
transport protocols (e.g. UDP, or TCP). The ICE procedures transport protocols (e.g. UDP, or TCP). The ICE procedures
essentially cover the capability negotiation required (by having the essentially cover the capability negotiation required (by having the
answerer select something it supports and then use of trial and answerer select something it supports and then use of trial and
error connectivity checks). error connectivity checks).
Scenario 2 does not require a need to support or use ICE. Instead, Scenario 2 does not require a need to support or use ICE. Instead,
we simply use transport protocol capabilities and potential we simply use transport protocol capabilities and potential
configuration attributes to indicate the desired outcome. configuration attributes to indicate the desired outcome.
The scenarios may be combined, e.g. by offering potential The scenarios may be combined, e.g. by offering potential
configuration alternatives where some of them can support one configuration alternatives where some of them can support only one
transport protocol only (e.g. UDP), whereas others can support transport protocol (e.g. UDP), whereas others can support multiple
multiple transport protocols (e.g. UDP or TCP). In that case, there transport protocols (e.g. UDP or TCP). In that case, there is a need
is a need for tight control over the ICE candidates that will be for tight control over the ICE candidates that will be used for a
used for a particular configuration, yet the actual configuration particular configuration, yet the actual configuration may want to
may want to use all of the ICE candidates. In that case, the ICE use all of the ICE candidates. In that case, the ICE candidate
candidate attributes can be defined as attribute capabilities and attributes can be defined as attribute capabilities and the relevant
the relevant ones should then be included in the proper potential ones should then be included in the proper potential configurations
configurations (for example candidate attributes for UDP only for (for example candidate attributes for UDP only for potential
potential configurations that are restricted to UDP, whereas there configurations that are restricted to UDP, whereas there could be
could be candidate attributes for UDP, TCP, and TCP/TLS for candidate attributes for UDP, TCP, and TCP/TLS for potential
potential configurations that can use all three). Furthermore, use configurations that can use all three). Furthermore, use of the
of the delete-attributes in a potential configuration can be used to delete-attributes in a potential configuration can be used to ensure
ensure that ICE will not end up using a transport protocol that is that ICE will not end up using a transport protocol that is not
not desired for a particular configuration. 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 (see Section 3.6.3. ). potential configurations from the offer (see Section 3.6.3. ).
Similarly, ICE requires use of a second offer/answer exchange if the Similarly, ICE requires use of a second offer/answer exchange if the
chosen candidate is not the same as the one in the m/c-line from the chosen candidate is not the same as the one in the m/c-line from the
offer. When ICE and capability negotiation are used at the same offer. When ICE and capability negotiation are used at the same
time, the two secondary offer/answer exchanges SHOULD be combined to time, the two secondary offer/answer exchanges SHOULD be combined to
a single one. a single one.
skipping to change at page 53, line 33 skipping to change at page 55, line 33
| | | |
| (3) Offer (RTP/AVPF) | | (3) Offer (RTP/AVPF) |
|--------------------------------->| |--------------------------------->|
| | | |
| (4) Answer (RTP/AVPF) | | (4) Answer (RTP/AVPF) |
|<---------------------------------| |<---------------------------------|
| | | |
Alice's offer includes plain RTP (RTP/AVP), RTP with RTCP-based Alice's offer includes plain RTP (RTP/AVP), RTP with RTCP-based
feedback (RTP/AVPF), Secure RTP (RTP/SAVP), and Secure RTP with feedback (RTP/AVPF), Secure RTP (RTP/SAVP), and Secure RTP with
RTCP-based feedback (RTP/SAVPF) and SRTP as alternatives. RTP is the RTCP-based feedback (RTP/SAVPF) as alternatives. RTP is the default,
default, with RTP/SAVPF, RTP/SAVP, and RTP/AVPF as the alternatives with RTP/SAVPF, RTP/SAVP, and RTP/AVPF as the alternatives and
and preferred in the order listed: preferred in the order listed:
v=0 v=0
o=- 25678 753849 IN IP4 192.0.2.1 o=- 25678 753849 IN IP4 192.0.2.1
s= s=
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
t=0 0 t=0 0
m=audio 53456 RTP/AVP 0 18 m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
skipping to change at page 56, line 22 skipping to change at page 58, line 22
accepted the offer to use normal RTP. In that case, the following accepted the offer to use normal RTP. In that case, the following
answer would have been generated in step 2 instead: answer would have been generated in step 2 instead:
v=0 v=0
o=- 24351 621814 IN IP4 192.0.2.2 o=- 24351 621814 IN IP4 192.0.2.2
s= s=
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
t=0 0 t=0 0
m=audio 54568 RTP/AVP 0 18 m=audio 54568 RTP/AVP 0 18
4.2. Best-Effort SRTP with Session-Level MIKEY and Media Level Security 4.2. DTLS-SRTP or SRTP with Media Level Security Descriptions
The following example illustrates how to use the SDP Capability
Negotiation framework to negotiate use of SRTP using either SDP
Security Descriptions or DTLS-SRTP. The offerer (Alice) wants to
establish a secure RTP audio stream but is willing to use plain RTP.
Alice prefers to use DTLS-SRTP as the key management protocol, but
supports SDP security descriptions as well (note that [DTLS-SRTP-
FRAMEWORK] contains additional DTLS-SRTP examples).
The example is illustrated by the offer/answer exchange below, where
Alice sends an offer to Bob:
Alice Bob
| (1) Offer (RTP/[S]AVP,SDES | DTLS-SRTP)|
|--------------------------------------->|
| |
|<--------- DTLS-SRTP handshake -------->|
| |
| (2) Answer (DTLS-SRTP) |
|<---------------------------------------|
| |
| (3) Offer (DTLS-SRTP) |
|--------------------------------------->|
| |
| (4) Answer (DTLS-SRTP) |
|<---------------------------------------|
| |
Alice's offer includes an audio stream which offers use of plain RTP
and secure RTP as alternatives. For the secure RTP stream, it can be
established using either DTLS-SRTP or SDP Security Descriptions:
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 setup:actpass
a=acap:2 fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tcap:1 UDP/TLS/RTP/SAVP RTP/SAVP
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1,2
a=pcfg:2 t=2 a=3
The first (and preferred) potential configuration for the audio
stream specifies use of transport capability 1 (UDP/TLS/RTP/SAVP),
i.e. DTLS-SRTP, and attribute capabilities 1 and 2 (active/passive
mode and certificate fingerprint), both of which must be supported
to choose this potential configuration. The second (and less
preferred) potential configuration specifies use of transport
capability 2 (RTP/SAVP) and mandatory attribute capability 3, i.e.
the SDP security description.
Bob receives the SDP offer from Alice. Bob supports DTLS-SRTP as
preferred by Alice and Bob now initiates the DTLS-SRTP handshake to
establish the DTLS-SRTP session (see [DTLS-SRTP] for details).
Bob also sends back an answer to Alice as follows:
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 UDP/TLS/RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=1 a=1,2
For the audio stream, Bob accepted the use of DTLS-SRTP, and hence
the profile in the "m=" line is "UDP/TLS/RTP/SAVP". Bob also includes
a "setup:active" attribute to indicate he is the active endpoint for
the DTLS-SRTP session as well as the fingerprint for Bob's
certificate. Bob's "acfg" attribute indicates that he chose potential
configuration 1 from Alice's offer.
When Alice receives Bob's answer, session negotiation has completed
(and Alice can verify the DTLS handshake using Bob's certificate
fingerprint in the answer), however Alice nevertheless chooses to
generate a new offer using the actual configuration. This is done
purely to assist any intermediaries that may reside between Alice
and Bob but do not support the capability negotiation extensions
(and hence may not understand the negotiation that just took place):
Alice's updated offer includes only DTLS-SRTP for the audio stream,
and it is not using the SDP Capability Negotiation framework (Alice
could have included the capabilities as well if she wanted to):
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
m=audio 59000 UDP/TLS/RTP/AVP 98
a=rtpmap:98 AMR/8000
The "m=" line for the audio stream now indicates that Alice is
offering to use DTLS-SRTP in active/passive mode using her
certificate fingerprint provided.
Bob receives the SDP offer from Alice, which he accepts, and then
generates an answer to Alice:
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 UDP/TLS/RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=1 a=1,2
Bob includes the same "setup:active" and fingerprint attributes as
before, and the session proceeds without change. Although Bob did
not include any capabilities in his answer, he could have done so if
he wanted to.
Note that in this particular example, the answerer supported the
capability extensions defined here, however had he not, the answerer
would simply have ignored the new attributes received in step 1 and
accepted the offer to use normal RTP. In that case, the following
answer would have been generated in step 2 instead:
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/AVP 98
a=rtpmap:98 AMR/8000
Finally, if Bob had chosen to use SDP Security Descriptions instead
of DTLS-SRTP, the following answer would have been generated:
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:2 t=2 a=3
4.3. Best-Effort SRTP with Session-Level MIKEY and Media Level Security
Descriptions Descriptions
The following example illustrates how to use the SDP Capability The following example illustrates how to use the SDP Capability
Negotiation extensions to support so-called Best-Effort Secure RTP Negotiation extensions to support so-called Best-Effort Secure RTP
as well as alternative keying mechanisms, more specifically MIKEY as well as alternative keying mechanisms, more specifically MIKEY
[RFC3830] and SDP Security Descriptions. The offerer (Alice) wants [RFC3830] and SDP Security Descriptions. The offerer (Alice) wants
to establish an audio and video session. Alice prefers to use to establish an audio and video session. Alice prefers to use
session-level MIKEY as the key management protocol, but supports SDP session-level MIKEY as the key management protocol, but supports SDP
security descriptions as well. security descriptions as well.
skipping to change at page 59, line 30 skipping to change at page 65, line 8
intermediaries that may reside between Alice and Bob but do not intermediaries that may reside between Alice and Bob but do not
support the capability negotiation extensions (and hence may not support the capability negotiation extensions (and hence may not
understand the negotiation that just took place): understand the negotiation that just took place):
Alice's updated offer includes only SRTP for the audio stream SRTP Alice's updated offer includes only SRTP for the audio stream SRTP
with RTCP-based feedback for the video stream, and it is not using with RTCP-based feedback for the video stream, and it is not using
the SDP Capability Negotiation framework (Alice could have included the SDP Capability Negotiation framework (Alice could have included
the capabilities as well is she wanted to): the capabilities as well is she wanted to):
v=0 v=0
o=- 25678 753849 IN IP4 192.0.2.1 o=- 25678 753850 IN IP4 192.0.2.1
s= s=
t=0 0 t=0 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
m=audio 59000 RTP/SAVP 98 m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32 a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=video 52000 RTP/SAVPF 31 m=video 52000 RTP/SAVPF 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
skipping to change at page 60, line 9 skipping to change at page 65, line 33
offering to use secure RTP with PCMU or G.729, whereas the "m=" line offering to use secure RTP with PCMU or G.729, whereas the "m=" line
for the video stream indicates that Alice is offering to use secure for the video stream indicates that Alice is offering to use secure
RTP with RTCP-based feedback and H.261. Each media stream includes a RTP with RTCP-based feedback and H.261. Each media stream includes a
"crypto" attribute, which provides the SRTP keying material, with "crypto" attribute, which provides the SRTP keying material, with
the same value again. the same value again.
Bob receives the SDP offer from Alice, which he accepts, and then Bob receives the SDP offer from Alice, which he accepts, and then
generates an answer to Alice: generates an answer to Alice:
v=0 v=0
o=- 24351 621814 IN IP4 192.0.2.2 o=- 24351 621815 IN IP4 192.0.2.2
s= s=
t=0 0 t=0 0
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98 m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32 a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32 inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
m=video 55468 RTP/SAVPF 31 m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
skipping to change at page 60, line 45 skipping to change at page 66, line 23
s= s=
t=0 0 t=0 0
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
m=audio 54568 RTP/AVP 98 m=audio 54568 RTP/AVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
m=video 55468 RTP/AVP 31 m=video 55468 RTP/AVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtcp-fb:* nack a=rtcp-fb:* nack
Finally, if Bob had chosen to use session-level MIKEY instead of SDP Finally, if Bob had chosen to use session-level MIKEY instead of SDP
security descriptions instead, the following answer would have been security descriptions, the following answer would have been
generated: generated:
v=0 v=0
o=- 25678 753849 IN IP4 192.0.2.1 o=- 24351 621814 IN IP4 192.0.2.2
s= s=
t=0 0 t=0 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.2
a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyO... a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyO...
m=audio 59000 RTP/AVP 98 m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
a=acfg:1 t=2 a=1 a=acfg:1 t=2 a=1
m=video 52000 RTP/SAVPF 31 m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtcp-fb:* nack a=rtcp-fb:* nack
a=acfg:1 t=1 a=1,4 a=acfg:1 t=1 a=1,4
It should be noted, that although Bob could have chosen session- It should be noted, that although Bob could have chosen session-
level MIKEY for one media stream, and SDP Security Descriptions for level MIKEY for one media stream, and SDP Security Descriptions for
another media stream, there are no well-defined offerer processing another media stream, there are no well-defined offerer processing
rules of the resulting answer for this, and hence the offerer may rules of the resulting answer for this, and hence the offerer may
incorrectly assume use of MIKEY for both streams. To avoid this, if incorrectly assume use of MIKEY for both streams. To avoid this, if
the answerer chooses session-level MIKEY, then all secure RTP based the answerer chooses session-level MIKEY, then all secure RTP based
media streams SHOULD use MIKEY (this applies irrespective of whether media streams SHOULD use MIKEY (this applies irrespective of whether
SDP Capability Negotiation is being used or not). Use of media-level SDP Capability Negotiation is being used or not). Use of media-level
MIKEY does not have a similar constraint. MIKEY does not have a similar constraint.
4.3. SRTP with Session-Level MIKEY and Media Level Security 4.4. SRTP with Session-Level MIKEY and Media Level Security
Descriptions as Alternatives Descriptions as Alternatives
The following example illustrates how to use the SDP Capability The following example illustrates how to use the SDP Capability
Negotiation framework to negotiate use of either MIKEY or SDP Negotiation framework to negotiate use of either MIKEY or SDP
Security Descriptions, when one of them is included as part of the Security Descriptions, when one of them is included as part of the
actual configuration, and the other one is being selected. The actual configuration, and the other one is being selected. The
offerer (Alice) wants to establish an audio and video session. Alice offerer (Alice) wants to establish an audio and video session. Alice
prefers to use session-level MIKEY as the key management protocol, prefers to use session-level MIKEY as the key management protocol,
but supports SDP security descriptions as well. but supports SDP security descriptions as well.
skipping to change at page 62, line 44 skipping to change at page 68, line 12
Alice does not know whether Bob supports MIKEY or SDP Security Alice does not know whether Bob supports MIKEY or SDP Security
Descriptions. She could include attributes for both, however the Descriptions. She could include attributes for both, however the
resulting procedures and potential interactions are not well- resulting procedures and potential interactions are not well-
defined. Instead, she places a session-level key-mgmt attribute for defined. Instead, she places a session-level key-mgmt attribute for
MIKEY in the actual configuration with SDP security descriptions as MIKEY in the actual configuration with SDP security descriptions as
an alternative in the potential configuration. The potential an alternative in the potential configuration. The potential
configuration for the audio stream specifies that all session level configuration for the audio stream specifies that all session level
attributes are to be deleted (i.e. the session-level "a=key-mgmt" attributes are to be deleted (i.e. the session-level "a=key-mgmt"
attribute) and that mandatory attribute capability 2 is to be used attribute) and that mandatory attribute capability 2 is to be used
(i.e. the crypto attribute). The potential configuration for the (i.e. the crypto attribute). The potential configuration for the
video stream is similar, except it uses it's own mandatory crypto video stream is similar, except it uses its own mandatory crypto
attribute capability (2). Note how deletion of the session-level attribute capability (2). Note how deletion of the session-level
attributes does not affect the media-level attributes. attributes does not affect the media-level attributes.
Bob receives the SDP offer from Alice. Bob supports Secure RTP and Bob receives the SDP offer from Alice. Bob supports Secure RTP and
the SDP Capability Negotiation framework. Bob also supports both SDP the SDP Capability Negotiation framework. Bob also supports both SDP
Security Descriptions and MIKEY. Since the potential configuration Security Descriptions and MIKEY. Since the potential configuration
is more preferred than the actual configuration, Bob (conceptually) is more preferred than the actual configuration, Bob (conceptually)
generates an internal potential configuration SDP that contains the generates an internal potential configuration SDP that contains the
crypto attributes for the audio and video stream, but not the key- crypto attributes for the audio and video stream, but not the key-
mgmt attribute for MIKEY, thereby avoiding any ambiguity between the mgmt attribute for MIKEY, thereby avoiding any ambiguity between the
skipping to change at page 64, line 30 skipping to change at page 69, line 43
attributes from the actual configuration SDP, including the rtpmaps attributes from the actual configuration SDP, including the rtpmaps
provided, are removed. Consequently, we had to include these rtpmaps provided, are removed. Consequently, we had to include these rtpmaps
as capabilities as well, and then include them in the potential as capabilities as well, and then include them in the potential
configuration, thereby effectively recreating the original rtpmap configuration, thereby effectively recreating the original rtpmap
attributes in the resulting potential configuration SDP. attributes in the resulting potential configuration SDP.
5. Security Considerations 5. Security Considerations
The SDP Capability Negotiation Framework is defined to be used The SDP Capability Negotiation Framework is defined to be used
within the context of the offer/answer model, and hence all the within the context of the offer/answer model, and hence all the
offer/answer security considerations apply here as well. Similarly, offer/answer security considerations apply here as well [RFC3264].
the Session Initiation Protocol (SIP) uses SDP and the offer/answer Similarly, the Session Initiation Protocol (SIP) uses SDP and the
model, and hence, when used in that context, the SIP security offer/answer model, and hence, when used in that context, the SIP
considerations apply as well. security considerations apply as well [RFC3261].
However, SDP Capability Negotiation introduces additional security However, SDP Capability Negotiation introduces additional security
issues. Its use as a mechanism to enable alternative transport issues. Its use as a mechanism to enable alternative transport
protocol negotiation (secure and non-secure) as well as its ability protocol negotiation (secure and non-secure) as well as its ability
to negotiate use of more or less secure keying methods and material to negotiate use of more or less secure keying methods and material
warrant further security considerations. Also, the (continued) warrant further security considerations. Also, the (continued)
support for receiving media before answer combined with negotiation support for receiving media before answer combined with negotiation
of alternative transport protocols (secure and non-secure) warrant of alternative transport protocols (secure and non-secure) warrant
further security considerations. We discuss these issues below. further security considerations. We discuss these issues below.
skipping to change at page 65, line 20 skipping to change at page 70, line 34
media stream (e.g. plain RTP) as a valid (but less preferred) media stream (e.g. plain RTP) as a valid (but less preferred)
alternative, then an attacker that can modify the offered SDP will alternative, then an attacker that can modify the offered SDP will
be able to force the establishment of an insecure media stream. The be able to force the establishment of an insecure media stream. The
solution to both of these problems involves the use of integrity solution to both of these problems involves the use of integrity
protection over the SDP. Ideally, this integrity protection provides protection over the SDP. Ideally, this integrity protection provides
end-to-end integrity protection in order to protect from any man-in- end-to-end integrity protection in order to protect from any man-in-
the-middle attack; secure multiparts such as S/MIME [RFC3851] the-middle attack; secure multiparts such as S/MIME [RFC3851]
provide one such solution, however S/MIME requires use and provide one such solution, however S/MIME requires use and
availability of a Public Key Infrastructure (PKI). A slightly less availability of a Public Key Infrastructure (PKI). A slightly less
secure alternative when using SIP, but generally much easier to secure alternative when using SIP, but generally much easier to
deploy in practice (since it does not require a PKI), is to use SIP deploy in practice, is to use SIP Identity [RFC4474]; this requires
Identity [RFC4474]; this requires the existence of an authentication the existence of an authentication service (see [RFC4474]). Although
service (see [RFC4474]). Yet another, and considerably less secure, this mechanism still requires a PKI, it only requires that servers
alternative is to use hop-by-hop security only, e.g. TLS or IPSec (as opposed to end-users) have third party validatable certificates,
thereby ensuring the integrity of the offered SDP on a hop-by-hop which significantly reduces the barrier to entry by ordinary users.
basis. Note however that SIP proxies or other intermediaries Yet another, and considerably less secure, alternative is to use
processing the SIP request at each hop are able to perform a man-in- hop-by-hop security only, e.g. TLS or IPsec thereby ensuring the
the-middle attack by modifying the offered SDP. integrity of the offered SDP on a hop-by-hop basis. This is less
secure because SIP allows partially trusted intermediaries on the
signaling path, and such intermediaries processing the SIP request
at each hop would be able to perform a man-in- the-middle attack by
modifying the offered SDP. In simple architectures where the two
UA's proxies communicate directly, the security provided by this
method is roughly comparable to that provided by the previously
discussed signature-based mechanisms.
Per the normal offer/answer procedures, as soon as the offerer has Per the normal offer/answer procedures, as soon as the offerer has
generated an offer, the offerer must be prepared to receive media in generated an offer, the offerer must be prepared to receive media in
accordance with that offer. The SDP Capability Negotiation preserves accordance with that offer. The SDP Capability Negotiation preserves
that behavior for the actual configuration in the offer, however the that behavior for the actual configuration in the offer, however the
offerer has no way of knowing which configuration (actual or offerer has no way of knowing which configuration (actual or
potential) configuration was selected by the offerer, until an potential) configuration was selected by the offerer, until an
answer indication is received. This opens up a new security issue answer indication is received. This opens up a new security issue
where an attacker may be able to interject media towards the offerer where an attacker may be able to interject media towards the offerer
until the answer is received. For example, the offerer may use plain until the answer is received. For example, the offerer may use plain
skipping to change at page 66, line 31 skipping to change at page 72, line 6
end integrity protection, SIP identity, or hop-by-hop protection. end integrity protection, SIP identity, or hop-by-hop protection.
The mechanism to use depends on the mechanisms supported by the The mechanism to use depends on the mechanisms supported by the
offerer as well as the acceptable security trade-offs. offerer as well as the acceptable security trade-offs.
As described in Section 3.1. , SDP Capability Negotiation As described in Section 3.1. , SDP Capability Negotiation
conceptually allows an offerer to include many different offers in a conceptually allows an offerer to include many different offers in a
single SDP. This can cause the answerer to process a large number of single SDP. This can cause the answerer to process a large number of
alternative potential offers, which can consume significant memory alternative potential offers, which can consume significant memory
and CPU resources. An attacker can use this amplification feature to and CPU resources. An attacker can use this amplification feature to
launch a denial of service attack against the answerer. The answerer launch a denial of service attack against the answerer. The answerer
MUST protect itself from such attacks. As explained in Section 3.10. must protect itself from such attacks. As explained in Section 3.10.
, the answerer can help reduce the effects of such an attack by , the answerer can help reduce the effects of such an attack by
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. At interferes with individual media description configurations. At
time of publication of this document, we do not know of such an time of publication of this document, we do not know of such an
SDP attribute, however this does not mean it does not exist, or SDP attribute, however this does not mean it does not exist, or
that it will not exist in the future. If such attributes are found that it will not exist in the future. If such attributes are found
to exist, implementers should 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.
6. IANA Considerations 6. IANA Considerations
6.1. New SDP Attributes 6.1. New SDP Attributes
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:
skipping to change at page 70, line 5 skipping to change at page 75, line 23
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, Miguel Garcia, Robert here: Francois Audet, John Elwell, Roni Even, Miguel Garcia, Robert
Gilman, Cullen Jennings, Jonathan Lennox, Matt Lepinski, Jean- Gilman, Cullen Jennings, Jonathan Lennox, Matt Lepinski, Jean-
Francois Mule, Joerg Ott, Colin Perkins, Jonathan Rosenberg, Thomas Francois Mule, Joerg Ott, Colin Perkins, Jonathan Rosenberg, Thomas
Stach, and Dan Wing. Stach, and Dan Wing.
General Area review comments were provided by Christian Vogt, and
Stephen Kent provided Security Directorate review comments. Eric
Rescorla provided textual input to the Security Considerations.
8. Change Log 8. Change Log
8.1. draft-ietf-mmusic-sdp-capability-negotiation-09 8.1. draft-ietf-mmusic-sdp-capability-negotiation-10
Addressing General Area and Security Directorate review comments as
follows:
o Explained and motivated the preference order between potential
and actual configurations earlier in the document.
o Added DTLS-SRTP example use in several places, as well as a new
example call flow for DTLS-SRTP.
o Added that interacting session-level attributes in potential
configurations, which do not provide well-defined operation on
the receiving side, cannot be used in security critical contexts.
o Updated Security Considerations section.
o Rephrased several sentences containing the word "only" to improve
readability.
o Minor editorial nit fixes, especially in the example call flows.
8.2. draft-ietf-mmusic-sdp-capability-negotiation-09
Incorporated Working Group Chair review comments and a few additional Incorporated Working Group Chair review comments and a few additional
comments as follows: comments as follows:
o Clarified that the "a=creq" attribute MUST NOT be used in an o Clarified that the "a=creq" attribute MUST NOT be used in an
answer (Section 3.6.2. ). answer (Section 3.6.2. ).
o Various editorial changes throughout. o Various editorial changes throughout.
8.2. draft-ietf-mmusic-sdp-capability-negotiation-08 8.3. 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 70, line 43 skipping to change at page 76, line 41
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.3. draft-ietf-mmusic-sdp-capability-negotiation-07 8.4. 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 71, line 21 skipping to change at page 77, 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.4. draft-ietf-mmusic-sdp-capability-negotiation-06 8.5. 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 72, line 40 skipping to change at page 78, 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.5. draft-ietf-mmusic-sdp-capability-negotiation-05 8.6. 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 73, line 45 skipping to change at page 79, 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.6. draft-ietf-mmusic-sdp-capability-negotiation-04 8.7. 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.7. draft-ietf-mmusic-sdp-capability-negotiation-03 8.8. 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.8. draft-ietf-mmusic-sdp-capability-negotiation-02 8.9. 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 75, line 16 skipping to change at page 81, 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.9. draft-ietf-mmusic-sdp-capability-negotiation-01 8.10. 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 76, line 5 skipping to change at page 82, 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.10. draft-ietf-mmusic-sdp-capability-negotiation-00 8.11. 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 79, line 10 skipping to change at page 85, line 10
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol Media Streams", RFC 5027, Session Description Protocol Media Streams", RFC 5027,
October 2007. October 2007.
[BESRTP] Kaplan, H., and F. Audet, "Session Description Protocol [BESRTP] Kaplan, H., and F. Audet, "Session Description Protocol
(SDP) Offer/Answer Negotiation for Best-Effort Secure (SDP) Offer/Answer Negotiation for Best-Effort Secure
Real-Time Transport Protocol, Work in progress, August Real-Time Transport Protocol, Work in progress, August
2006. 2006.
[DTLS-SRTP] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)", draft-ietf-avt-dtls-
srtp-07 (work in progress), February 2009.
[DTLS-SRTP-FRAMEWORK] Fischl, J., Tschofenig, H., and E. Rescorla,
"Framework for Establishing an SRTP Security Context using
DTLS", draft-ietf-sip-dtls-srtp-framework-07 (work in
progress), October 2008.
[ICE] J. Rosenberg, "Interactive Connectivity Establishment [ICE] J. Rosenberg, "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT) (ICE): A Methodology for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", work in progress, Traversal for Offer/Answer Protocols", work in progress,
September 2007. September 2007.
[ICETCP] J. Rosenberg, "TCP Candidates with Interactive [ICETCP] J. Rosenberg, "TCP Candidates with Interactive
Connectivity Establishment (ICE)", work in progress, July Connectivity Establishment (ICE)", work in progress, July
2007. 2007.
[SAVPF] Ott, J., and E Carrara, "Extended Secure RTP Profile for [SAVPF] Ott, J., and E Carrara, "Extended Secure RTP Profile for
skipping to change at page 79, line 37 skipping to change at line 3755
Description and Capability Negotiation", Work in Progress, Description and Capability Negotiation", Work in Progress,
February 2005. February 2005.
Author's Addresses Author's Addresses
Flemming Andreasen Flemming Andreasen
Cisco Systems Cisco Systems
Edison, NJ Edison, NJ
Email: fandreas@cisco.com Email: fandreas@cisco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 63 change blocks. 
177 lines changed or deleted 415 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/