draft-ietf-mmusic-sdp-capability-negotiation-10.txt   draft-ietf-mmusic-sdp-capability-negotiation-11.txt 
MMUSIC Working Group F. Andreasen MMUSIC Working Group F. Andreasen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended Status: Proposed Standard May 19, 2009 Intended Status: Proposed Standard February 14, 2010
Expires: November 2009 Expires: August 2010
SDP Capability Negotiation SDP Capability Negotiation
draft-ietf-mmusic-sdp-capability-negotiation-10.txt draft-ietf-mmusic-sdp-capability-negotiation-11.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted in full conformance with the
the provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 November 19, 2009. This Internet-Draft will expire on August 14, 2010.
Copyright Notice Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your publication of this document. Please review these documents
rights and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Abstract Abstract
The Session Description Protocol (SDP) was intended for describing The Session Description Protocol (SDP) was intended for describing
skipping to change at page 2, line 44 skipping to change at page 2, line 49
It also specifies how to provide attributes and transport protocols It also specifies how to provide attributes and transport protocols
as capabilities and negotiate them using the framework. Extensions as capabilities and negotiate them using the framework. Extensions
for other types of capabilities (e.g. media types and media formats) for other types of capabilities (e.g. media types and media formats)
may be provided in other documents. may be provided in other documents.
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
2. Conventions used in this document..............................7 2. Conventions used in this document..............................7
3. SDP Capability Negotiation Solution............................7 3. SDP Capability Negotiation Solution............................7
3.1. SDP Capability Negotiation Model..........................7 3.1. SDP Capability Negotiation Model..........................8
3.2. Solution Overview........................................11 3.2. Solution Overview........................................11
3.3. Version and Extension Indication Attributes..............15 3.3. Version and Extension Indication Attributes..............15
3.3.1. Supported Capability Negotiation Extensions Attribute15 3.3.1. Supported Capability Negotiation Extensions Attribute15
3.3.2. Required Capability Negotiation Extensions Attribute17 3.3.2. Required Capability Negotiation Extensions Attribute17
3.4. Capability Attributes....................................19 3.4. Capability Attributes....................................19
3.4.1. Attribute Capability Attribute......................19 3.4.1. Attribute Capability Attribute......................19
3.4.2. Transport Protocol Capability Attribute.............20 3.4.2. Transport Protocol Capability Attribute.............21
3.4.3. Extension Capability Attributes.....................22 3.4.3. Extension Capability Attributes.....................23
3.5. Configuration Attributes.................................23 3.5. Configuration Attributes.................................24
3.5.1. Potential Configuration Attribute...................23 3.5.1. Potential Configuration Attribute...................24
3.5.2. Actual Configuration Attribute......................30 3.5.2. Actual Configuration Attribute......................32
3.6. Offer/Answer Model Extensions............................32 3.6. Offer/Answer Model Extensions............................34
3.6.1. Generating the Initial Offer........................32 3.6.1. Generating the Initial Offer........................34
3.6.2. Generating the Answer...............................36 3.6.2. Generating the Answer...............................37
3.6.2.1. Example Views of Potential Configurations......42 3.6.2.1. Example Views of Potential Configurations......44
3.6.3. Offerer Processing of the Answer....................44 3.6.3. Offerer Processing of the Answer....................46
3.6.4. Modifying the Session...............................45 3.6.4. Modifying the Session...............................48
3.7. Interactions with ICE....................................46 3.7. Interactions with ICE....................................48
3.8. Interactions with SIP Option Tags........................47 3.8. Interactions with SIP Option Tags........................50
3.9. Processing Media before Answer...........................48 3.9. Processing Media before Answer...........................50
3.10. Indicating Bandwidth Usage..............................49 3.10. Indicating Bandwidth Usage..............................51
3.11. Dealing with Large Number of Potential Configurations...50 3.11. Dealing with Large Number of Potential Configurations...53
3.12. SDP Capability Negotiation and Intermediaries...........51 3.12. SDP Capability Negotiation and Intermediaries...........54
3.13. Considerations for Specific Attribute Capabilities......53 3.13. Considerations for Specific Attribute Capabilities......55
3.13.1. The rtpmap and fmtp Attributes.....................53 3.13.1. The rtpmap and fmtp Attributes.....................55
3.13.2. Direction Attributes...............................54 3.13.2. Direction Attributes...............................56
3.14. Relationship to RFC 3407................................54 3.14. Relationship to RFC 3407................................57
4. Examples......................................................54 4. Examples......................................................57
4.1. Multiple Transport Protocols.............................55 4.1. Multiple Transport Protocols.............................57
4.2. DTLS-SRTP or SRTP with Media Level Security Descriptions.58 4.2. DTLS-SRTP or SRTP with Media Level Security Descriptions.61
4.3. Best-Effort SRTP with Session-Level MIKEY and Media Level 4.3. Best-Effort SRTP with Session-Level MIKEY and Media Level
Security Descriptions.........................................62 Security Descriptions.........................................64
4.4. SRTP with Session-Level MIKEY and Media Level Security 4.4. SRTP with Session-Level MIKEY and Media Level Security
Descriptions as Alternatives..................................67 Descriptions as Alternatives..................................69
5. Security Considerations.......................................69 5. Security Considerations.......................................72
6. IANA Considerations...........................................72 6. IANA Considerations...........................................75
6.1. New SDP Attributes.......................................72 6.1. New SDP Attributes.......................................75
6.2. New SDP Capability Negotiation Option Tag Registry.......74 6.2. New SDP Capability Negotiation Option Tag Registry.......77
6.3. New SDP Capability Negotiation Potential Configuration 6.3. New SDP Capability Negotiation Potential Configuration
Parameter Registry............................................74 Parameter Registry............................................77
7. Acknowledgments...............................................75 7. Acknowledgments...............................................78
8. Change Log....................................................75 8. Change Log....................................................78
8.1. draft-ietf-mmusic-sdp-capability-negotiation-10..........75 8.1. draft-ietf-mmusic-sdp-capability-negotiation-11..........78
8.2. draft-ietf-mmusic-sdp-capability-negotiation-09..........76 8.2. draft-ietf-mmusic-sdp-capability-negotiation-10..........79
8.3. draft-ietf-mmusic-sdp-capability-negotiation-08..........76 8.3. draft-ietf-mmusic-sdp-capability-negotiation-09..........80
8.4. draft-ietf-mmusic-sdp-capability-negotiation-07..........76 8.4. draft-ietf-mmusic-sdp-capability-negotiation-08..........80
8.5. draft-ietf-mmusic-sdp-capability-negotiation-06..........77 8.5. draft-ietf-mmusic-sdp-capability-negotiation-07..........80
8.6. draft-ietf-mmusic-sdp-capability-negotiation-05..........78 8.6. draft-ietf-mmusic-sdp-capability-negotiation-06..........81
8.7. draft-ietf-mmusic-sdp-capability-negotiation-04..........79 8.7. draft-ietf-mmusic-sdp-capability-negotiation-05..........82
8.8. draft-ietf-mmusic-sdp-capability-negotiation-03..........80 8.8. draft-ietf-mmusic-sdp-capability-negotiation-04..........83
8.9. draft-ietf-mmusic-sdp-capability-negotiation-02..........80 8.9. draft-ietf-mmusic-sdp-capability-negotiation-03..........84
8.10. draft-ietf-mmusic-sdp-capability-negotiation-01.........81 8.10. draft-ietf-mmusic-sdp-capability-negotiation-02.........84
8.11. draft-ietf-mmusic-sdp-capability-negotiation-00.........82 8.11. draft-ietf-mmusic-sdp-capability-negotiation-01.........85
9. References....................................................83 8.12. draft-ietf-mmusic-sdp-capability-negotiation-00.........86
9.1. Normative References.....................................83 9. References....................................................87
9.2. Informative References...................................83 9.1. Normative References.....................................87
Author's Addresses...............................................85 9.2. Informative References...................................87
Author's Address.................................................90
1. Introduction 1. Introduction
The Session Description Protocol (SDP) was intended for describing The Session Description Protocol (SDP) was intended for describing
multimedia sessions for the purposes of session announcement, multimedia sessions for the purposes of session announcement,
session invitation, and other forms of multimedia session session invitation, and other forms of multimedia session
initiation. The SDP contains one or more media stream descriptions initiation. A SDP session description contains one or more media
with information such as IP-address and port, type of media stream stream descriptions with information such as IP-address and port,
(e.g. audio or video), transport protocol (possibly including type of media stream (e.g. audio or video), transport protocol
profile information, e.g. RTP/AVP or RTP/SAVP), media formats (e.g. (possibly including profile information, e.g. RTP/AVP or RTP/SAVP),
codecs), and various other session and media stream parameters that media formats (e.g. codecs), and various other session and media
define the session. stream parameters that define the session.
Simply providing media stream descriptions is sufficient for session Simply providing media stream descriptions is sufficient for session
announcements for a broadcast application, where the media stream announcements for a broadcast application, where the media stream
parameters are fixed for all participants. When a participant wants parameters are fixed for all participants. When a participant wants
to join the session, he obtains the session announcement and uses to join the session, he obtains the session announcement and uses
the media descriptions provided, e.g., joins a multicast group and the media descriptions provided, e.g., joins a multicast group and
receives media packets in the encoding format specified. If the receives media packets in the encoding format specified. If the
media stream description is not supported by the participant, he is media stream description is not supported by the participant, he is
unable to receive the media. unable to receive the media.
Such restrictions are not generally acceptable to multimedia session Such restrictions are not generally acceptable to multimedia session
invitations, where two or more entities attempt to establish a media invitations, where two or more entities attempt to establish a media
session, that uses a set of media stream parameters acceptable to session, that uses a set of media stream parameters acceptable to
all participants. First of all, each entity must inform the other of all participants. First of all, each entity must inform the other of
its receive address, and secondly, the entities need to agree on the its receive address, and secondly, the entities need to agree on the
media stream parameters to use for the session, e.g. transport media stream parameters to use for the session, e.g. transport
protocols and codecs. To solve this, RFC 3264 [RFC3264] defined the protocols and codecs. To solve this, RFC 3264 [RFC3264] defined the
offer/answer model, whereby an offerer constructs an offer SDP that offer/answer model, whereby an offerer constructs an offer SDP
lists the media streams, codecs, and other SDP parameters that the session description that lists the media streams, codecs, and other
offerer is willing to use. This offer SDP is sent to the answerer, SDP parameters that the offerer is willing to use. This offer
which chooses from among the media streams, codecs and other SDP session description is sent to the answerer, which chooses from
parameters provided, and generates an answer SDP with his among the media streams, codecs and other session description
parameters, based on that choice. The answer SDP is sent back to the parameters provided, and generates an answer session description
offerer thereby completing the session negotiation and enabling the with his parameters, based on that choice. The answer session
establishment of the negotiated media streams. description is sent back to the offerer thereby completing the
session negotiation and enabling the establishment of the negotiated
media streams.
Taking a step back, we can make a distinction between the Taking a step back, we can make a distinction between the
capabilities supported by each participant, the way in which those capabilities supported by each participant, the way in which those
capabilities can be supported, and the parameters that can actually capabilities can be supported, and the parameters that can actually
be used for the session. More generally, we can say that we have the be used for the session. More generally, we can say that we have the
following: following:
o A set of capabilities for the session and its associated media o A set of capabilities for the session and its associated media
stream components, supported by each side. The capability stream components, supported by each side. The capability
indications by themselves do not imply a commitment to use the indications by themselves do not imply a commitment to use the
skipping to change at page 6, line 41 skipping to change at page 6, line 49
attributes). This makes it difficult to deploy new RTP profiles attributes). This makes it difficult to deploy new RTP profiles
such as secure RTP (SRTP) [RFC3711], RTP with RTCP-Based Feedback such as secure RTP (SRTP) [RFC3711], RTP with RTCP-Based Feedback
[RFC4585], etc. The problem is exacerbated by the fact that RTP [RFC4585], etc. The problem is exacerbated by the fact that RTP
profiles are defined independently. When a new profile is defined profiles are defined independently. When a new profile is defined
and N other profiles already exist, there is a potential need for and N other profiles already exist, there is a potential need for
defining N additional profiles, since profiles cannot be combined defining N additional profiles, since profiles cannot be combined
automatically. For example, in order to support the plain and automatically. For example, in order to support the plain and
secure RTP version of RTP with and without RTCP-based feedback, four secure RTP version of RTP with and without RTCP-based feedback, four
separate profiles (and hence profile definitions) are needed: separate profiles (and hence profile definitions) are needed:
RTP/AVP [RFC3551], RTP/SAVP [RFC3711], RTP/AVPF [RFC4585], and RTP/AVP [RFC3551], RTP/SAVP [RFC3711], RTP/AVPF [RFC4585], and
RTP/SAVPF [SAVPF]. In addition to the pressing profile negotiation RTP/SAVPF [RFC5124]. In addition to the pressing profile
problem, other important real-life limitations have been found as negotiation problem, other important real-life limitations have been
well. Keying material and other parameters for example need to be found as well. Keying material and other parameters for example need
negotiated with some of the transport protocols, but not others. to be negotiated with some of the transport protocols, but not
Similarly, some media formats and types of media streams need to others. Similarly, some media formats and types of media streams
negotiate a variety of different parameters. need to negotiate a variety of different parameters.
The purpose of this document is to define a mechanism that enables The purpose of this document is to define a mechanism that enables
SDP to provide limited support for indicating capabilities and their SDP to provide limited support for indicating capabilities and their
associated potential configurations, and negotiate the use of those associated potential configurations, and negotiate the use of those
potential configurations as actual configurations. It is not the potential configurations as actual configurations. It is not the
intent to provide a full-fledged capability indication and intent to provide a full-fledged capability indication and
negotiation mechanism along the lines of SDPng or ITU-T H.245. negotiation mechanism along the lines of SDPng or ITU-T H.245.
Instead, the focus is on addressing a set of well-known real-life Instead, the focus is on addressing a set of well-known real-life
limitations. More specifically, the solution provided in this limitations. More specifically, the solution provided in this
document provides a general SDP Capability Negotiation framework document provides a general SDP Capability Negotiation framework
skipping to change at page 8, line 4 skipping to change at page 8, line 12
capability negotiation framework followed by an overview of the SDP capability negotiation framework followed by an overview of the SDP
Capability Negotiation solution. We then define new SDP attributes Capability Negotiation solution. We then define new SDP attributes
for the solution and provide its associated updated offer/answer for the solution and provide its associated updated offer/answer
procedures. procedures.
3.1. SDP Capability Negotiation Model 3.1. SDP Capability Negotiation Model
Our model uses the concepts of Our model uses the concepts of
o Capabilities o Capabilities
o Potential Configurations o Potential Configurations
o Actual Configurations o Actual Configurations
o Negotiation Process o Negotiation Process
as defined in Section 1. Conceptually, we want to offer not just the as defined in Section 1. Conceptually, we want to offer not just the
actual configuration SDP (which is done with the offer/answer model actual configuration SDP session description (which is done with the
defined in [RFC3264]), but the actual configuration SDP as well as offer/answer model defined in [RFC3264]), but the actual
one or more alternative SDPs, i.e. potential configurations. The configuration SDP session description as well as one or more
answerer must choose either the actual configuration, or one of the alternative SDP session descriptions, i.e. potential configurations.
potential configurations, and generate an answer SDP based on that. The answerer must choose either the actual configuration, or one of
The offerer may need to perform processing on the answer, which the potential configurations, and generate an answer SDP session
depends on the offer that was chosen (actual or potential description based on that. The offerer may need to perform
configuration). The answerer therefore informs the offerer which processing on the answer, which depends on the offer that was chosen
configuration the answerer chose. The process can be viewed (actual or potential configuration). The answerer therefore informs
*conceptually* as follows: the offerer which configuration the answerer chose. The process can
be viewed *conceptually* as follows:
Offerer Answerer Offerer Answerer
======= ======== ======= ========
1) Generate offer with actual 1) Generate offer with actual
configuration and alternative configuration and alternative
potential configurations potential configurations
2) Send offer with all configurations 2) Send offer with all configurations
+------------+ +------------+
skipping to change at page 9, line 41 skipping to change at page 9, line 41
| SDP a1 | | SDP a1 |
Answer | (actual | Answer | (actual |
<----- | config,o2)| <----- | config,o2)|
| | | |
5) Process answer based on +------------+ 5) Process answer based on +------------+
the configuration that was the configuration that was
chosen (o2), as indicated in chosen (o2), as indicated in
the answer the answer
The above illustrates the conceptual model: The actual solution uses The above illustrates the conceptual model: The actual solution uses
a single SDP, which contains the actual configuration (as with a single SDP session description, which contains the actual
existing SDP and the offer/answer model defined in [RFC3264]) and configuration (as with existing SDP session descriptions and the
several new attributes and associated procedures, that encode the offer/answer model defined in [RFC3264]) and several new attributes
capabilities and potential configurations. A more accurate depiction and associated procedures, that encode the capabilities and
of the actual offer SDP is therefore as follows: potential configurations. A more accurate depiction of the actual
offer SDP session description is therefore as follows:
+--------------------+ +--------------------+
| SDP o1 | | SDP o1 |
| (actual | | (actual |
| config | | config |
| | | |
| +-------------+ | | +-------------+ |
| | capability 1| | | | capability 1| |
| | capability 2| | | | capability 2| |
| | ... | | | | ... | |
skipping to change at page 10, line 31 skipping to change at page 10, line 31
| | ... | | | | ... | |
| +-------------+ | | +-------------+ |
| | | |
+--------------------+ +--------------------+
The above structure is used for two reasons: The above structure is used for two reasons:
o Backwards compatibility: As noted above, support for multipart o Backwards compatibility: As noted above, support for multipart
MIME is not ubiquitous. By encoding both capabilities and MIME is not ubiquitous. By encoding both capabilities and
potential configurations in SDP attributes, we can represent potential configurations in SDP attributes, we can represent
everything in a single SDP thereby avoiding any multipart MIME everything in a single SDP session description thereby avoiding
support issues. Furthermore, since unknown SDP attributes are any multipart MIME support issues. Furthermore, since unknown SDP
ignored by the SDP recipient, we ensure that entities that do not attributes are ignored by the SDP recipient, we ensure that
support the framework simply perform the regular RFC 3264 entities that do not support the framework simply perform the
offer/answer procedures. This provides us with seamless backwards regular RFC 3264 offer/answer procedures. This provides us with
compatibility. seamless backwards compatibility.
o Message size efficiency: When we have multiple media streams, o Message size efficiency: When we have multiple media streams,
each of which may potentially use two or more different transport each of which may potentially use two or more different transport
protocols with a variety of different associated parameters, the protocols with a variety of different associated parameters, the
number of potential configurations can be large. If each possible number of potential configurations can be large. If each possible
alternative is represented as a complete SDP in an offer, we can alternative is represented as a complete SDP session description
easily end up with large messages. By providing a more compact in an offer, we can easily end up with large messages. By
encoding, we get more efficient message sizes. providing a more compact encoding, we get more efficient message
sizes.
In the next section, we describe the exact structure and specific In the next section, we describe the exact structure and specific
SDP parameters used to represent this. SDP parameters used to represent this.
3.2. Solution Overview 3.2. Solution Overview
The solution consists of the following: The solution consists of the following:
o Two new SDP attributes to support extensions to the framework o Two new SDP attributes to support extensions to the framework
itself as follows: itself as follows:
o A new attribute ("a=csup") that lists the supported base o A new attribute ("a=csup") that lists the supported base
(optionally) and any supported extension options to the (optionally) and any supported extension options to the
framework. framework.
o A new attribute ("a=creq") that lists the extensions to the o A new attribute ("a=creq") that lists the extensions to the
framework that are required to be supported by the entity framework that are required to be supported by the entity
receiving the SDP in order to do capability negotiation. receiving the SDP session description in order to do
capability negotiation.
o Two new SDP attributes used to express capabilities as follows o Two new SDP attributes used to express capabilities as follows
(additional attributes can be defined as extensions): (additional attributes can be defined as extensions):
o A new attribute ("a=acap") that defines how to list an o A new attribute ("a=acap") that defines how to list an
attribute name and its associated value (if any) as a attribute name and its associated value (if any) as a
capability. capability.
o A new attribute ("a=tcap") that defines how to list transport o A new attribute ("a=tcap") that defines how to list transport
protocols (e.g. "RTP/AVP") as capabilities. protocols (e.g. "RTP/AVP") as capabilities.
o Two new 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 session description in question.
can be defined and referenced in the potential Extension capabilities can be defined and referenced in the
configurations. Alternative potential configurations have an potential configurations. Alternative potential
explicit ordering associated with them. Also, potential configurations have an explicit ordering associated with
configurations are by default preferred over the actual them. Also, potential configurations are by default preferred
configuration included in the "m=" line and its associated over the actual configuration included in the "m=" line and
parameters. its associated parameters.
This preference order was chosen to provide maximum This preference order was chosen to provide maximum
backwards compatibility for the capability negotiation backwards compatibility for the capability negotiation
framework and the possible values offered for a session. framework and the possible values offered for a session.
For example, an entity that wants to establish a secure For example, an entity that wants to establish a secure
RTP media stream but is willing to accept a plain RTP RTP media stream but is willing to accept a plain RTP
media stream (assumed to be the least common denominator media stream (assumed to be the least common denominator
for most endpoints), can offer plain RTP in the actual for most endpoints), can offer plain RTP in the actual
configuration and use the capability negotiation configuration and use the capability negotiation
extensions to indicate the preference for secure RTP. extensions to indicate the preference for secure RTP.
Entities that do not support the capability negotiation Entities that do not support the capability negotiation
extensions or secure RTP will then default to plain RTP. 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
attribute identifies a potential configuration from an offer session description. The attribute identifies a potential
SDP which was used as an actual configuration to form the configuration from an offer SDP session description which was
answer SDP. Extension capabilities can be included as well. used as an actual configuration to form the answer SDP
session description. 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 only at the media level. Potential configurations can be included only at the media
level, where they constitute alternative offers that may be level, where they constitute alternative offers that may be
accepted by the answerer instead of the actual configuration(s) accepted by the answerer instead of the actual configuration(s)
included in the "m=" line(s) and associated parameters. The included in the "m=" line(s) and associated parameters. The
answerer indicates which (if any) of the potential configurations mechanisms defined in this document enables potential
it used to form the answer by including the actual configuration configurations to change the transport protocol, add new
attribute ("a=acfg") in the answer. Capabilities may be included attributes, as well as remove all existing attributes from the
in answers as well, where they can aid in guiding a subsequent actual configuration. The answerer indicates which (if any) of
new offer. the potential configurations it used to form the answer by
including the actual configuration attribute ("a=acfg") in the
answer. Capabilities may be included in answers as well, where
they can aid in guiding a subsequent new offer.
The mechanism is illustrated by the offer/answer exchange below, The mechanism is illustrated by the offer/answer exchange below,
where Alice sends an offer to Bob: where Alice sends an offer to Bob:
Alice Bob Alice Bob
| (1) Offer (SRTP and RTP) | | (1) Offer (SRTP and RTP) |
|--------------------------------->| |--------------------------------->|
| | | |
| (2) Answer (SRTP) | | (2) Answer (SRTP) |
skipping to change at page 14, line 4 skipping to change at page 14, line 4
"acap" attribute provides an attribute capability with a handle of "acap" attribute provides an attribute capability with a handle of
1. The attribute capability is a "crypto" attribute, which provides 1. The attribute capability is a "crypto" attribute, which provides
the keying material for SRTP using SDP security descriptions the keying material for SRTP using SDP security descriptions
[RFC4568]. The "a=pcfg" attribute provides the potential [RFC4568]. The "a=pcfg" attribute provides the potential
configuration included in the offer by reference to the capability configuration included in the offer by reference to the capability
parameters. One alternative is provided; it has a configuration parameters. One alternative is provided; it has a configuration
number of 1 and it consists of transport protocol capability 1 number of 1 and it consists of transport protocol capability 1
(i.e., the RTP/SAVP profile - secure RTP), and the attribute (i.e., the RTP/SAVP profile - secure RTP), and the attribute
capability 1 (i.e., the crypto attribute provided). Potential capability 1 (i.e., the crypto attribute provided). Potential
configurations are preferred over the actual configuration included configurations are preferred over the actual configuration included
in the offer SDP, and hence Alice is expressing a preference for in the offer SDP session description, and hence Alice is expressing
using secure RTP. a preference for using secure RTP.
Bob receives the SDP offer from Alice. Bob supports SRTP and the SDP Bob receives the SDP session description offer from Alice. Bob
Capability Negotiation framework, and hence he accepts the supports SRTP and the SDP Capability Negotiation framework, and
(preferred) potential configuration for Secure RTP provided by Alice hence he accepts the (preferred) potential configuration for Secure
and generates the following answer SDP: RTP provided by Alice and generates the following answer SDP session
description:
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/SAVP 0 18 m=audio 54568 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
a=acfg:1 t=1 a=1 a=acfg:1 t=1 a=1
Bob includes the "a=acfg" attribute in the answer to inform Alice Bob includes the "a=acfg" attribute in the answer to inform Alice
that he based his answer on an offer using potential configuration 1 that he based his answer on an offer using potential configuration 1
with transport protocol capability 1 and attribute capability 1 from with transport protocol capability 1 and attribute capability 1 from
the offer SDP (i.e., the RTP/SAVP profile using the keying material the offer SDP session description (i.e., the RTP/SAVP profile using
provided). Bob also includes his keying material in a "crypto" the keying material provided). Bob also includes his keying
attribute. If Bob supported one or more extensions to the capability material in a "crypto" attribute. If Bob supported one or more
negotiation framework, he would have included option tags for those extensions to the capability negotiation framework, he would have
in the answer as well (in an "a=csup" attribute). included option tags for those in the answer as well (in an "a=csup"
attribute).
When Alice receives Bob's answer, session negotiation has completed, When Alice receives Bob's answer, session negotiation has completed,
however Alice nevertheless generates a new offer using the however Alice nevertheless generates a new offer using the
negotiated configuration as the actual configuration. This is done negotiated configuration as the actual configuration. This is done
purely to assist any intermediaries that may reside between Alice purely to assist any intermediaries that may reside between Alice
and Bob but do not support the SDP Capability Negotiation framework, and Bob but do not support the SDP Capability Negotiation framework,
and hence may not understand the negotiation that just took place. and hence may not understand the negotiation that just took place.
Alice's updated offer includes only SRTP, and it is not using the Alice's updated offer includes only SRTP, and it is not using the
SDP Capability Negotiation framework (Alice could have included the SDP Capability Negotiation framework (Alice could have included the
skipping to change at page 15, line 9 skipping to change at page 15, line 11
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
t=0 0 t=0 0
m=audio 53456 RTP/SAVP 0 18 m=audio 53456 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
The "m=" line now indicates that Alice is offering to use secure RTP The "m=" line now indicates that Alice is offering to use secure RTP
with PCMU or G.729. The "crypto" attribute, which provides the SRTP with PCMU or G.729. The "crypto" attribute, which provides the SRTP
keying material, is included with the same value again. keying material, is included with the same value again.
Bob receives the SDP offer from Alice, which he accepts, and then Bob receives the SDP session description offer from Alice, which he
generates an answer to Alice: accepts, and then generates an answer to Alice:
v=0 v=0
o=- 24351 621815 IN IP4 192.0.2.2 o=- 24351 621815 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/SAVP 0 18 m=audio 54568 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
skipping to change at page 15, line 50 skipping to change at page 16, line 6
In this section, we present the new attributes associated with In this section, we present the new attributes associated with
indicating the SDP Capability Negotiation extensions supported and indicating the SDP Capability Negotiation extensions supported and
required. required.
3.3.1. Supported Capability Negotiation Extensions Attribute 3.3.1. Supported Capability Negotiation Extensions Attribute
The SDP Capability Negotiation solution allows for capability The SDP Capability Negotiation solution allows for capability
negotiation extensions to be defined. Associated with each such negotiation extensions to be defined. Associated with each such
extension is an option tag that identifies the extension in extension is an option tag that identifies the extension in
question. Option-tags MUST be registered with IANA per the question. Option-tags MUST be registered with IANA per the
procedures defined in Section 6. procedures defined in Section 6.2.
The Supported Capability Negotiation Extensions attribute ("a=csup") The Supported Capability Negotiation Extensions attribute ("a=csup")
contains a comma-separated list of option tags identifying the SDP contains a comma-separated list of option tags identifying the SDP
Capability Negotiation extensions supported by the entity that Capability Negotiation extensions supported by the entity that
generated the SDP. The attribute can be provided at the session- generated the SDP session description. The attribute can be provided
level and the media-level, and it is defined as follows: at the session-level and the media-level, and it is defined as
follows:
a=csup: <option-tag-list> a=csup: <option-tag-list>
RFC 4566, Section 9, provides the ABNF [RFC5234] for SDP attributes. RFC 4566, Section 9, provides the ABNF [RFC5234] for SDP attributes.
The "csup" attribute adheres to the RFC 4566 "attribute" production, The "csup" attribute adheres to the RFC 4566 "attribute" production,
with an att-value defined as follows: with an att-value defined as follows:
att-value = option-tag-list att-value = option-tag-list
option-tag-list = option-tag *("," option-tag) option-tag-list = option-tag *("," option-tag)
option-tag = token ; defined in [RFC4566] option-tag = token ; defined in [RFC4566]
A special base option tag with a value of "cap-v0" is defined for A special base option tag with a value of "cap-v0" is defined for
the basic SDP Capability Negotiation framework defined in this the basic SDP Capability Negotiation framework defined in this
document. Entities can use this option tag with the "a=csup" document. Entities can use this option tag with the "a=csup"
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. Please note that white space
is not allowed in this rule.
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 only to the media SDP session description. When provided at the media-level, it
description in question (option-tags provided at the session level applies only to the media description in question (option-tags
apply as well). There MUST NOT be more than one "a=csup" attribute provided at the session level apply as well). There MUST NOT be more
at the session-level and one at the media-level (one per media than one "a=csup" attribute at the session-level and one at the
description in the latter case). media-level (one per media description in the latter case).
Whenever an entity that supports one or more extensions to the SDP Whenever an entity that supports one or more extensions to the SDP
Capability Negotiation framework generates an SDP, it SHOULD include Capability Negotiation framework generates an SDP session
the "a=csup" attribute with the option tags for the extensions it description, it SHOULD include the "a=csup" attribute with the
supports at the session and/or media-level, unless those option tags option tags for the extensions it supports at the session and/or
are already provided in one or more "a=creq" attribute (see Section media-level, unless those option tags are already provided in one or
3.3.2. ) at the relevant levels. Inclusion of the base option tag is more "a=creq" attribute (see Section 3.3.2. ) at the relevant
OPTIONAL; support for the base framework can be inferred from levels. Inclusion of the base option tag is OPTIONAL; support for
presence of the "a=pcfg" attribute defined in Section 3.5.1. the base framework can be inferred from presence of the "a=pcfg"
attribute defined in Section 3.5.1.
Use of the base option tag may still be useful in some scenarios, Use of the base option tag may still be useful in some scenarios,
e.g. when using SIP OPTIONS [RFC3261] or generating an answer to e.g. when using SIP OPTIONS [RFC3261] or generating an answer to
an offer that did not use the SDP Capability Negotiation an offer that did not use the SDP Capability Negotiation
framework. framework.
3.3.2. Required Capability Negotiation Extensions Attribute 3.3.2. Required Capability Negotiation Extensions Attribute
The Required Capability Negotiation Extensions attribute ("a=creq") The Required Capability Negotiation Extensions attribute ("a=creq")
contains a comma-separated list of option tags (see Section 3.3.1. ) contains a comma-separated list of option tags (see Section 3.3.1. )
specifying the SDP Capability Negotiation extensions that MUST be specifying the SDP Capability Negotiation extensions that MUST be
supported by the entity receiving the SDP, in order for that entity supported by the entity receiving the SDP session description, in
to properly process the SDP Capability Negotiation attributes and order for that entity to properly process the SDP Capability
associated procedures. There is no need to include the base option- Negotiation attributes and associated procedures. There is no need
tag ("cap-v0") with the "creq" attribute, since any entity that to include the base option-tag ("cap-v0") with the "creq" attribute,
supports the "creq" attribute in the first place also supports the since any entity that supports the "creq" attribute in the first
base option-tag. Still, it is permissible to do so. place also supports the base option-tag. Still, it is permissible to
do so.
Such functionality may be important if a future version of the Such functionality may be important if a future version of the
capability negotiation framework were not backwards compatible. capability negotiation framework were not backwards compatible.
The attribute can be provided at the session-level and the media- The attribute can be provided at the session-level and the media-
level, and it is defined as follows: level, and it is defined as follows:
a=creq: <option-tag-list> a=creq: <option-tag-list>
The "creq" attribute adheres to the RFC 4566 "attribute" production, The "creq" attribute adheres to the RFC 4566 "attribute" production,
skipping to change at page 18, line 7 skipping to change at page 18, line 19
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 only to the media SDP session description. When provided at the media-level, it
description in question (required option tags provided at the applies only to the media description in question (required option
session level apply as well). There MUST NOT be more than one tags provided at the session level apply as well). There MUST NOT be
"a=creq" attribute at the session-level and one "a=creq" attribute more than one "a=creq" attribute at the session-level and one
at the media-level (one per media description in the latter case). "a=creq" attribute 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 session description and it requires
that SDP to support one or more SDP Capability Negotiation the recipient of that SDP session description to support one or more
extensions (except for the base) at the session or media level in SDP Capability Negotiation extensions (except for the base) at the
order to properly process the SDP Capability Negotiation, the session or media level in order to properly process the SDP
"a=creq" attribute MUST be included with option-tags that identify Capability Negotiation, the "a=creq" attribute MUST be included with
the required extensions at the session and/or media level. If option-tags that identify the required extensions at the session
support for an extension is needed only in one or more specific and/or media level. If support for an extension is needed only in
potential configurations, the potential configuration provides a way one or more specific potential configurations, the potential
to indicate that instead (see Section 3.5.1. ). Support for the configuration provides a way to indicate that instead (see Section
basic negotiation framework is implied by the presence of an 3.5.1. ). Support for the basic negotiation framework is implied by
"a=pcfg" attribute (see Section 3.5.1. ) and hence it is not the presence of an "a=pcfg" attribute (see Section 3.5.1. ) and
required to include the "a=creq" attribute with the base option-tag hence it is not required to include the "a=creq" attribute with the
("cap-v0"). base option-tag ("cap-v0").
A recipient that receives an SDP and does not support one or more of A recipient that receives an SDP session description and does not
the required extensions listed in a "creq" attribute, MUST NOT support one or more of the required extensions listed in a "creq"
perform the SDP Capability Negotiation defined in this document. For attribute, MUST NOT perform the SDP Capability Negotiation defined
non-supported extensions provided at the session-level, this implies in this document. For non-supported extensions provided at the
that SDP Capability Negotiation MUST NOT be performed at all. For session-level, this implies that SDP Capability Negotiation MUST NOT
non-supported extensions at the media-level, this implies that SDP be performed at all. For non-supported extensions at the media-
Capability Negotiation MUST NOT be performed for the media stream in level, this implies that SDP Capability Negotiation MUST NOT be
question. performed for the media stream in question.
An entity that does not support the SDP Capability Negotiation An entity that does not support the SDP Capability Negotiation
framework at all, will ignore these attributes (as well as the framework at all, will ignore these attributes (as well as the
other SDP Capability Negotiation attributes) and not perform any other SDP Capability Negotiation attributes) and not perform any
SDP Capability Negotiation in the first place. SDP Capability Negotiation in the first place.
When an SDP recipient does not support one or more required SDP When an SDP session description recipient does not support one or
Capability Negotiation extensions listed in the option tags, the more required SDP Capability Negotiation extensions listed in the
recipient MUST proceed as if the SDP Capability Negotiation option tags, the recipient MUST proceed as if the SDP Capability
attributes were not included in the first place, i.e. all the Negotiation attributes were not included in the first place, i.e.
capability negotiation attributes should be ignored. In that case, all the capability negotiation attributes should be ignored. In
if the SDP recipient is an SDP answerer [RFC3264], the recipient that case, if the SDP session description recipient is an SDP
SHOULD include a "csup" attribute in the resulting SDP answer answerer [RFC3264], the recipient SHOULD include a "csup" attribute
listing the SDP Capability Negotiation extensions it actually in the resulting SDP session description answer listing the SDP
supports. Capability Negotiation extensions it actually supports.
This ensures that introduction of the SDP Capability Negotiation This ensures that introduction of the SDP Capability Negotiation
mechanism by itself does not lead to session failures. mechanism by itself does not lead to session failures.
3.4. Capability Attributes 3.4. Capability Attributes
In this section, we present the new attributes associated with In this section, we present the new attributes associated with
indicating the capabilities for use by the SDP Capability indicating the capabilities for use by the SDP Capability
Negotiation. Negotiation.
skipping to change at page 19, line 32 skipping to change at page 19, line 44
where <att-cap-num> is an integer between 1 and 2^31-1 (both where <att-cap-num> is an integer between 1 and 2^31-1 (both
included) used to number the attribute capability and <att-par> is included) used to number the attribute capability and <att-par> is
an attribute ("a=") in its "<attribute>" or <attribute>:<value>" an attribute ("a=") in its "<attribute>" or <attribute>:<value>"
form, i.e., excluding the "a=" part (see [RFC4566]). The attribute form, i.e., excluding the "a=" part (see [RFC4566]). The attribute
can be provided at the session-level and the media-level. can be provided at the session-level and the media-level.
The "acap" attribute adheres to the RFC 4566 "attribute" production, The "acap" attribute adheres to the RFC 4566 "attribute" production,
with an att-value defined as follows: with an att-value defined as follows:
att-value = att-cap-num 1*WSP att-par att-value = att-cap-num 1*WSP att-par
att-cap-num = 1*DIGIT ;defined in [RFC5234] att-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
att-par = attribute ;defined in RFC 4566 att-par = attribute ;defined in 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.
When the attribute capability contains session-level attributes, the When the attribute capability contains a session-level attribute,
"acap" attribute can only be provided at the session level. that "acap" attribute can only be provided at the session level.
Conversely, media level attributes can be provided in attribute Conversely, media level attributes can be provided in attribute
capabilities at either the media level or session-level. The base capabilities at either the media level or session-level. The base
SDP Capability Negotiation framework however only defines procedures SDP Capability Negotiation framework however only defines procedures
for use of media-level attribute capabilities at the media level for use of media-level attribute capabilities at the media level.
(extensions may define use at the session level). Implementations that conform only to the base framework MUST NOT
generate media-level attribute capabilities at the session-level,
however extensions may change this (see, e.g., [SDPMedCap] for one
such extension) and hence all implementations MUST still be prepared
to receive such capabilities (see Section 3.6.2. for processing
rules).
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 20, line 31 skipping to change at page 20, line 49
a=acap:4 crypto:1 AES_CM_128_HMAC_SHA1_32 a=acap:4 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
The first two attribute capabilities provide attribute values for The first two attribute capabilities provide attribute values for
the ptime attribute. The third provides SRTP parameters by using the ptime attribute. The third provides SRTP parameters by using
MIKEY [RFC3830] with the key-mgmt attribute [RFC4567]. The fourth MIKEY [RFC3830] with the key-mgmt attribute [RFC4567]. The fourth
provides SRTP parameters by use of security descriptions with the provides SRTP parameters by use of security descriptions with the
crypto attribute [RFC4568]. Note that the line-wrapping and new- crypto attribute [RFC4568]. Note that the line-wrapping and new-
lines in example three and four are provided for formatting reasons lines in example three and four are provided for formatting reasons
only - they are not permitted in actual SDP. only - they are not permitted in actual SDP session description.
Readers familiar with RFC 3407 may notice the similarity between Readers familiar with RFC 3407 may notice the similarity between
the RFC 3407 "cpar" attribute and the above. There are however a the RFC 3407 "cpar" attribute and the above. There are however a
couple of important differences, notably that the "acap" attribute couple of important differences, notably that the "acap" attribute
contains a handle that enables referencing it and it furthermore contains a handle that enables referencing it and it furthermore
supports only attributes (the "cpar" attribute defined in RFC 3407 supports only attributes (the "cpar" attribute defined in RFC 3407
supports bandwidth information as well). The "acap" attribute also supports bandwidth information as well). The "acap" attribute also
is not automatically associated with any particular capabilities. is not automatically associated with any particular capabilities.
See Section 3.14. for the relationship to RFC 3407. See Section 3.14. for the relationship to RFC 3407.
Attribute capabilities MUST NOT embed any capability negotiation
parameters. This restriction applies to all the capability
negotiation parameters defined in this document ("csup", "creq",
"acap", "pcfg", and "acfg") as well as any extensions defined. The
following examples are thus invalid attribute capabilities and MUST
NOT be used:
a=acap:1 acap:2 foo:a ;Not allowed to embed "acap"
a=acap:2 a=pcfg:1 t=1 a=1 ;Not allowed to embed "pcfg"
The reason for this restriction is to avoid overly complex
processing rules resulting from the expansion of such capabilities
into potential configurations (see Section 3.6.2. for further
details).
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:
a=tcap: <trpr-cap-num> <proto-list> a=tcap: <trpr-cap-num> <proto-list>
where <trpr-cap-num> is an integer between 1 and 2^31-1 (both where <trpr-cap-num> is an integer between 1 and 2^31-1 (both
included) used to number the transport address capability for later included) used to number the transport address capability for later
reference, and <proto-list> is one or more <proto>, separated by reference, and <proto-list> is one or more <proto>, separated by
white space, as defined in the SDP "m=" line. The attribute can be white space, as defined in the SDP "m=" line. The attribute can be
provided at the session-level and the media-level. provided at the session-level and the media-level.
The "tcap" attribute adheres to the RFC 4566 "attribute" production, The "tcap" attribute adheres to the RFC 4566 "attribute" production,
with an att-value defined as follows: with an att-value defined as follows:
att-value = trpr-cap-num 1*WSP proto-list att-value = trpr-cap-num 1*WSP proto-list
trpr-cap-num = 1*DIGIT ;defined in [RFC5234] trpr-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
proto-list = proto *(1*WSP proto) ; defined in RFC 4566 proto-list = proto *(1*WSP proto) ; defined in RFC 4566
Note that white space is not permitted before the trpr-cap-num. Note that white space is not permitted before the trpr-cap-num.
The "tcap" attribute can be provided at the session-level and the The "tcap" attribute can be provided at the session-level and the
media-level. There MUST NOT be more than one "a=tcap" attribute at media-level. There MUST NOT be more than one "a=tcap" attribute at
the session-level and one at the media-level (one per media the session-level and one at the media-level (one per media
description in the latter case). Each occurrence of the "tcap" description in the latter case). Each occurrence of the "tcap"
attribute in the entire session description MUST use a different attribute in the entire session description MUST use a different
value of <trpr-cap-num>. When multiple <proto> values are provided, value of <trpr-cap-num>. When multiple <proto> values are provided,
the first one is associated with the value <trpr-cap-num>, the the first one is associated with the value <trpr-cap-num>, the
second one with the value one higher, etc. There MUST NOT be any second one with the value one higher, etc. There MUST NOT be any
capability number overlap between different "tcap" attributes in the capability number overlap between different "tcap" attributes in the
entire SDP. The <trpr-cap-num> values provided are independent of entire SDP session description. The <trpr-cap-num> values provided
similar <cap-num> values provided for other capability attributes, are independent of similar <cap-num> values provided for other
i.e., they form a separate name-space for transport protocol capability attributes, i.e., they form a separate name-space for
capabilities. Consecutive numbering of the <trpr-cap-num> values in transport protocol capabilities. Consecutive numbering of the <trpr-
different "tcap" attributes is not required. cap-num> values in 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 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). The last one provides capabilities for capability number 4). The last one provides capabilities for
"UDP/TLS/RTP/SAVP", i.e. DTLS-SRTP [DTLS-SRTP](transport capability "UDP/TLS/RTP/SAVP", i.e. DTLS-SRTP [DTLS-SRTP](transport capability
number 5). number 5).
The "tcap" attribute by itself can only specify transport protocols
as defined by <proto> in [RFC4566], however full specification of a
media stream requires further qualification of the transport
protocol by one or more media format descriptions, which themselves
often depend on the transport protocol. As an example, [RFC3551]
defines the "RTP/AVP" transport for use with audio and video codecs
(media formats), whereas [RFC4145] for example defines the "TCP"
transport protocol which may be used to negotiate, e.g. image/t38,
application/iptv_rtsp, etc. In a non-SDP context, some of these
media formats could be viewed as transports themselves (e.g. T.38)
however in the context of SDP and SDP Capability Negotiation, they
are not. If capability negotiation is required for such media
formats, they MUST all either be valid under the transport protocol
indicated in the "m=" line included for the media stream
description, or a suitable extension must be used, e.g. SDP Media
Capabilities [SDPMedCap].
The ability to use a particular transport protocol is inherently The ability to use a particular transport protocol is inherently
implied by including it in the "m=" line, regardless of whether it implied by including it in the "m=" line, regardless of whether it
is provided in a "tcap" attribute or not. However, if a potential is provided in a "tcap" attribute or not. However, if a potential
configuration needs to reference that transport protocol as a configuration needs to reference that transport protocol as a
capability, the transport protocol MUST be included explicitly in a capability, the transport protocol MUST be included explicitly in a
"tcap" attribute. "tcap" attribute.
This may seem redundant (and indeed it is from the offerer's point This may seem redundant (and indeed it is from the offerer's point
of view), however it is done to protect against intermediaries of view), however it is done to protect against intermediaries
(e.g. middle-boxes) that may modify "m=" lines while passing (e.g. middle-boxes) that may modify "m=" lines while passing
skipping to change at page 22, line 45 skipping to change at page 24, line 4
capabilities to be defined as extensions and used with the general capabilities to be defined as extensions and used with the general
capability negotiation framework. The syntax and semantics of such capability negotiation framework. The syntax and semantics of such
new capability attributes are not defined here, however in order to new capability attributes are not defined here, however in order to
be used with potential configurations, they SHOULD allow for a be used with potential configurations, they SHOULD allow for a
numeric handle to be associated with each capability. This handle numeric handle to be associated with each capability. This handle
can be used as a reference within the potential and actual can be used as a reference within the potential and actual
configuration attributes (see Section 3.5.1. and 3.5.2. ). The configuration attributes (see Section 3.5.1. and 3.5.2. ). The
definition of such extension capability attributes MUST also state definition of such extension capability attributes MUST also state
whether they can be applied at the session-level, media-level, or whether they can be applied at the session-level, media-level, or
both. Note that extensions can have option tags defined for them, both. Note that extensions can have option tags defined for them,
which can be registered with the IANA in accordance with the and option tags MUST be registered with the IANA in accordance with
procedures specified in Section 6.2. the procedures specified in Section 6.2.
Extension capabilities SHOULD NOT embed any capability negotiation
parameters. This applies to all the capability negotiation
parameters defined in this document as well as any extensions
defined. The reason for this restriction is to avoid overly complex
processing rules resulting from the expansion of such capabilities
into potential configurations (see Section 3.6.2. for further
details). If an extension does not follow the above "SHOULD NOT"
recommendation, the extension MUST provide a careful analysis of why
such behavior is both necessary and safe.
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 only at the media-level. included). The attribute can be provided only at the media-level.
The "pcfg" attribute adheres to the RFC 4566 "attribute" production, The "pcfg" attribute adheres to the RFC 4566 "attribute" production,
with an att-value defined as follows: with an att-value defined as follows:
att-value = config-number [1*WSP pot-cfg-list] att-value = config-number [1*WSP pot-cfg-list]
config-number = 1*DIGIT ;defined in [RFC5234] config-number = 1*10(DIGIT) ;defined in [RFC5234]
pot-cfg-list = pot-config *(1*WSP pot-config) pot-cfg-list = pot-config *(1*WSP pot-config)
pot-config = attribute-config-list / pot-config = attribute-config-list /
transport-protocol-config-list / transport-protocol-config-list /
extension-config-list extension-config-list
The missing productions are defined below. Note that white space is The missing productions are defined below. Note that white space is
not permitted before the config-number. not permitted before the config-number.
The potential configuration attribute can be provided only at the The potential configuration attribute can be provided only at the
media-level and there can be multiple instances of it within a given media-level and there can be multiple instances of it within a given
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 only media level scope). 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
potential configuration may for example include attribute potential configuration may for example include attribute
capabilities and transport capabilities, transport capabilities capabilities and transport capabilities, transport capabilities
only, or some other combination of capabilities. only, or some other combination of capabilities. If transport
capabilities are not included in a potential configuration, the
default transport for that media stream is used.
The configuration lists generally reference one or more capabilities The potential configuration lists generally reference one or more
(extension configuration lists MAY use a different format). Those capabilities (extension configuration lists MAY use a different
capabilities are (conceptually) used to construct a new internal format). Those capabilities are (conceptually) used to construct a
version of the SDP by use of purely syntactic add and (possibly) new internal version of the SDP session description by use of purely
delete operations on the original SDP (actual configuration). This syntactic add and (possibly) delete operations on the original SDP
provides an alternative potential configuration SDP that can be used session description (actual configuration). This provides an
by conventional SDP and offer/answer procedures if selected. alternative potential configuration SDP session description that can
be used by conventional SDP and offer/answer procedures if selected.
This document defines attribute configuration lists and transport This document defines attribute configuration lists and transport
protocol configuration lists. Each of these MUST NOT be present protocol configuration lists. Each of these MUST NOT be present
more than once in a particular potential configuration attribute. more than once in a particular potential configuration attribute.
Extension configuration lists can be included as well. There can be Attribute capabilities referenced by the attribute configuration
more than one extension configuration list, however each particular list (if included) are added to the actual configuration, whereas a
extension MUST NOT be present more than once in a given "a=pcfg" transport capability referenced by the transport protocol
attribute. Together, the various configuration lists define a configuration list (if included) replaces the default transport
potential configuration. protocol from the actual configuration. Extension configuration
lists can be included as well. There can be more than one extension
configuration list, however each particular extension MUST NOT be
present more than once in a given "a=pcfg" attribute. Together, the
various configuration lists define a potential configuration.
There can be multiple potential configurations in a media There can be multiple potential configurations in a media
description. Each of these indicates not only a willingness, but in description. Each of these indicates not only a willingness, but in
fact a desire to use the potential configuration. fact a desire to use the potential configuration.
The example SDP below contains two potential configurations: The example SDP session description below contains two potential
configurations:
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/SAVP RTP/SAVPF a=tcap:1 RTP/SAVP RTP/SAVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
skipping to change at page 25, line 5 skipping to change at page 26, line 29
("RTP/SAVP") and an attribute configuration list that references ("RTP/SAVP") and an attribute configuration list that references
attribute capability 1 ("a=crypto:..."). Potential configuration 2 attribute capability 1 ("a=crypto:..."). Potential configuration 2
contains a transport protocol configuration list that references contains a transport protocol configuration list that references
transport capability 2 ("RTP/SAVPF") and an attribute configuration transport capability 2 ("RTP/SAVPF") and an attribute configuration
list that references attribute capability 1 ("a=crypto:..."). list that references attribute capability 1 ("a=crypto:...").
Attribute capabilities are used in a potential configuration by use Attribute capabilities are used in a potential configuration by use
of the attribute-config-list parameter, which is defined by the of the attribute-config-list parameter, which is defined by the
following ABNF: following ABNF:
attribute-config-list attribute-config-list = "a=" delete-attributes
= "a=" [delete-attributes ":"] attribute-config-list =/ "a=" [delete-attributes ":"]
mo-att-cap-list *(BAR mo-att-cap-list) mo-att-cap-list *(BAR mo-att-cap-list))
delete-attributes = DELETE ( "m" ; media attributes delete-attributes = DELETE ( "m" ; media attributes
/ "s" ; session attributes / "s" ; session attributes
/ "ms" ) ; media and session attributes / "ms" ) ; media and session attributes
mo-att-cap-list = mandatory-optional-att-cap-list | mo-att-cap-list = mandatory-optional-att-cap-list /
mandatory-att-cap-list | mandatory-att-cap-list /
optional-att-cap-list optional-att-cap-list
mandatory-optional-att-cap-list = mandatory-att-cap-list mandatory-optional-att-cap-list = mandatory-att-cap-list
"," optional-att-cap-list "," optional-att-cap-list
mandatory-att-cap-list = att-cap-list mandatory-att-cap-list = att-cap-list
optional-att-cap-list = "[" att-cap-list "]" optional-att-cap-list = "[" att-cap-list "]"
att-cap-list = att-cap-num *("," att-cap-num) att-cap-list = att-cap-num *("," att-cap-num)
att-cap-num = 1*DIGIT ;defined in [RFC5234] att-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
BAR = "|" BAR = "|"
DELETE = "-" DELETE = "-"
Note that white space is not permitted within this production. Note that white space is not permitted within the attribute-config-
list rule.
Each attribute configuration list can optionally begin with Each attribute configuration list can optionally begin with
instructions for how to handle attributes that are part of the instructions for how to handle attributes that are part of the
actual configuration SDP (i.e., the "a=" lines present in the actual configuration SDP session description (i.e., the "a=" lines
original SDP). By default, such attributes will remain as part of present in the original SDP session description). By default, such
the configuration in question. However, if delete-attributes attributes will remain as part of the potential configuration in
indicates "-m", then all attribute lines within the media question. However, if delete-attributes indicates "-m", then all
description in question will be deleted (i.e., all "a=" lines under attribute lines within the media description in question will be
the "m=" line in question). If delete-attributes indicates "-s", deleted in the resulting potential configuration SDP session
then all attribute lines at the session-level will be deleted (i.e., description (i.e., all "a=" lines under the "m=" line in question).
all "a=" lines before the first "m=" line). If delete-attributes If delete-attributes indicates "-s", then all attribute lines at the
indicates "-ms", then all attribute lines within this media session-level will be deleted (i.e., all "a=" lines before the first
description ("m=" line) and all attribute lines at the session-level "m=" line). If delete-attributes indicates "-ms", then all attribute
will be deleted. lines within this media description ("m=" line) and all attribute
lines at the session-level will be deleted.
The attribute capability list comes next. It contains one or more The attribute capability list comes next (if included). It contains
alternative lists of attribute capabilities. The alternative one or more alternative lists of attribute capabilities. The
attribute capability lists are separated by a vertical bar ("|"), alternative attribute capability lists are separated by a vertical
and each list contains one or more attribute capabilities separated bar ("|"), and each list contains one or more attribute capabilities
by commas (","). The attribute capabilities are either mandatory or separated by commas (","). The attribute capabilities are either
optional. Mandatory attribute capabilities MUST be supported in mandatory or optional. Mandatory attribute capabilities MUST be
order to use the potential configuration, whereas optional attribute supported in order to use the potential configuration, whereas
capabilities MAY be supported in order to use the potential optional attribute capabilities MAY be supported in order to use the
configuration. potential configuration.
Within each attribute capability list, all the mandatory attribute Within each attribute capability list, all the mandatory attribute
capabilities (if any) are listed first, and all the optional capabilities (if any) are listed first, and all the optional
attribute capabilities (if any) are listed last. The optional attribute capabilities (if any) are listed last. The optional
attribute capabilities are contained within a pair of square attribute capabilities are contained within a pair of square
brackets ("[" and "]"). Each attribute capability is merely an brackets ("[" and "]"). Each attribute capability is merely an
attribute capability number (att-cap-num) that identifies a attribute capability number (att-cap-num) that identifies a
particular attribute capability by referring to attribute capability particular attribute capability by referring to attribute capability
numbers defined above and hence MUST be between 1 and 2^31-1 (both numbers defined above and hence MUST be between 1 and 2^31-1 (both
included). The following example illustrates the above: included). The following example illustrates the above:
skipping to change at page 26, line 46 skipping to change at page 28, line 25
potential configurations (separated by a vertical bar). This is done potential configurations (separated by a vertical bar). This is done
for message size efficiency reasons, which is especially important for message size efficiency reasons, which is especially important
when we add other types of capabilities to the potential when we add other types of capabilities to the potential
configuration. If there is a need to provide a unique handle for configuration. If there is a need to provide a unique handle for
each, then separate "a=pcfg" attributes with different handles MUST each, then separate "a=pcfg" attributes with different handles MUST
be used instead. be used instead.
Each referenced attribute capability in the potential configuration Each referenced attribute capability in the potential configuration
will result in the corresponding attribute name and its associated will result in the corresponding attribute name and its associated
value (contained inside the attribute capability) being added to the value (contained inside the attribute capability) being added to the
resulting potential configuration SDP. resulting potential configuration SDP session description.
Alternative attribute capability lists are separated by a vertical Alternative attribute capability lists are separated by a vertical
bar ("|"), the scope of which extends to the next alternative (i.e., bar ("|"), the scope of which extends to the next alternative (i.e.,
"," has higher precedence than "|"). The alternatives are ordered by "," has higher precedence than "|"). The alternatives are ordered by
preference with the most preferred listed first. In order for a preference with the most preferred listed first. In order for a
recipient of the SDP (e.g., an answerer receiving this in an offer) recipient of the SDP session description (e.g., an answerer
to use this potential configuration, exactly one of the alternative receiving this in an offer) to use this potential configuration,
lists MUST be selected in its entirety. This requires that all exactly one of the alternative lists MUST be selected in its
mandatory attribute capabilities referenced by the potential entirety. This requires that all mandatory attribute capabilities
configuration are supported with the attribute values provided. referenced by the potential configuration are supported with the
attribute values provided.
Transport protocol configuration lists are included in a potential Transport protocol configuration lists are included in a potential
configuration by use of the transport-protocol-config-list configuration by use of the transport-protocol-config-list
parameter, which is defined by the following ABNF: parameter, which is defined by the following ABNF:
transport-protocol-config-list = transport-protocol-config-list =
"t=" trpr-cap-num *(BAR trpr-cap-num) "t=" trpr-cap-num *(BAR trpr-cap-num)
trpr-cap-num = 1*DIGIT ; defined in [RFC5234] trpr-cap-num = 1*10(DIGIT) ; defined in [RFC5234]
Note that white space is not permitted within this production. Note that white space is not permitted within this rule.
The trpr-cap-num refers to transport protocol capability numbers The trpr-cap-num refers to transport protocol capability numbers
defined above and hence MUST be between 1 and 2^31-1 (both defined above and hence MUST be between 1 and 2^31-1 (both
included). Alternative transport protocol capabilities are separated included). Alternative transport protocol capabilities are separated
by a vertical bar ("|"). The alternatives are ordered by preference by a vertical bar ("|"). The alternatives are ordered by preference
with the most preferred listed first. If there are no transport with the most preferred listed first. If there are no transport
protocol capabilities included in a potential configuration at the protocol capabilities included in a potential configuration at the
media level, the transport protocol information from the associated media level, the transport protocol information from the associated
"m=" line MUST be used. In order for a recipient of the SDP (e.g., "m=" line MUST be used. In order for a recipient of the SDP session
an answerer receiving this in an offer) to use this potential description (e.g., an answerer receiving this in an offer) to use
configuration, exactly one of the alternatives MUST be selected. this potential configuration, exactly one of the alternatives MUST
This requires that the transport protocol in question is supported. be selected. This requires that the transport protocol in question
is supported.
In the presence of intermediaries (the existence of which may not In the presence of intermediaries (the existence of which may not
be known), care should be taken with assuming that the transport be known), care should be taken with assuming that the transport
protocol in the "m=" line will not be modified by an intermediary. protocol in the "m=" line will not be modified by an intermediary.
Use of an explicit transport protocol capability will guard Use of an explicit transport protocol capability will guard
against capability negotiation implications of that. against capability negotiation implications of that.
Extension capabilities can be included in a potential configuration Extension capabilities can be included in a potential configuration
as well by use of extension configuration lists. Such extension as well by use of extension configuration lists. Extension
configuration lists MUST adhere to the following ABNF: configuration lists MUST adhere to the following ABNF:
extension-config-list= ["+"] ext-cap-name "=" extension-config-list= ["+"] ext-cap-name "="
ext-cap-list ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT) ext-cap-name = 1*(ALPHA / DIGIT)
ext-cap-list = 1*VCHAR ; defined in [RFC5234] ext-cap-list = 1*VCHAR ; defined in [RFC5234]
Note that white space is not permitted within this production. Note that white space is not permitted within this rule.
The ext-cap-name refers to the name of the extension capability and The ext-cap-name refers to the name of the extension capability and
the ext-cap-list is here merely defined as a sequence of visible the ext-cap-list is here merely defined as a sequence of visible
characters. The actual extension supported MUST refine both of these characters. The actual extension supported MUST refine both of these
further. For extension capabilities that merely need to be further. For extension capabilities that merely need to be
referenced by a capability number, it is RECOMMENDED to follow a referenced by a capability number, it is RECOMMENDED to follow a
structure similar to what has been specified above. Unsupported or structure similar to what has been specified above. Unsupported or
unknown potential extension configuration lists in a potential unknown potential extension configuration lists in a potential
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.
Extension configuration lists define new potential configuration
parameters and hence they MUST be registered with IANA per the
procedures defined in Section 6.3.
Potential configuration attributes can be provided only at the media Potential configuration attributes can be provided only at the media
level, however it is possible to reference capabilities provided at level, however it is possible to reference capabilities provided at
either the session or media level. There are certain semantic rules either the session or media level. There are certain 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
skipping to change at page 29, line 5 skipping to change at page 30, line 37
attributes (since that would place a media-level attribute at the attributes (since that would place a media-level attribute at the
session level). Extensions may modify this behavior, as long as it session level). Extensions may modify this behavior, as long as it
is fully backwards compatible with the base specification. is fully backwards compatible with the base specification.
Individual media streams perform capability negotiation Individual media streams perform capability negotiation
individually, and hence it is possible that one media stream (where individually, and hence it is possible that one media stream (where
the attribute was part of a potential configuration) chose a the attribute was part of a potential configuration) chose a
configuration without a session level attribute that was chosen by configuration without a session level attribute that was chosen by
another media stream. The session-level attribute however remains another media stream. The session-level attribute however remains
"active" and applies to the entire resulting potential configuration "active" and applies to the entire resulting potential configuration
SDP. In theory, this is problematic if one or more session-level SDP session description. In theory, this is problematic if one or
attributes either conflicts with or potentially interacts with more session-level attributes either conflicts with or potentially
another session-level or media-level attribute in an undefined interacts with another session-level or media-level attribute in an
manner. In practice, such examples seem to be rare (at least with undefined manner. In practice, such examples seem to be rare (at
the SDP attributes that had been defined at time of publication of least with the SDP attributes that had been defined at time of
this document). publication of this document).
A related set of problems can occur if we need coordination A related set of problems can occur if we need coordination
between session-level attributes from multiple media streams in between session-level attributes from multiple media streams in
order for a particular functionality to work. The grouping order for a particular functionality to work. The grouping
framework [RFC3388] is an example of this. If we use the SDP framework [RFC3388] is an example of this. If we use the SDP
Capability Negotiation framework to select a session-level group Capability Negotiation framework to select a session-level group
attribute (provided as an attribute capability), and we require attribute (provided as an attribute capability), and we require
two media descriptions to do this consistently, we could have a two media descriptions to do this consistently, we could have a
problem. The FEC grouping semantics [RFC4756] is one example where problem. The FEC grouping semantics [RFC4756] is one example where
this in theory could cause problems, however in practice, it is this in theory could cause problems, however in practice, it is
unclear that there is a significant problem with the grouping unclear that there is a significant problem with the grouping
semantics that had been defined at time of publication of this semantics that had been defined at time of publication of this
document. document.
Resolving the above issues in general requires inter-media stream Resolving the above issues in general requires inter-media stream
constraints and synchronized potential configuration processing; constraints and synchronized potential configuration processing;
this would add considerable complexity to the overall solution. In this would add considerable complexity to the overall solution. In
practice, with the 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 base 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 session description SHOULD NOT assume that
operation will occur at the receiving entity. This implies that well-defined operation will occur at the receiving entity. This
mechanisms which might have such interactions cannot be used in implies that mechanisms which might have such interactions cannot be
security critical contexts. 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 32 skipping to change at page 32, line 15
RTP/SAVPF is preferred over RTP/SAVP since its capability number (4) RTP/SAVPF is preferred over RTP/SAVP since its capability number (4)
is listed first in the preferred potential configuration. Note that is listed first in the preferred potential configuration. Note that
although we have a single potential configuration attribute and although we have a single potential configuration attribute and
associated handle, we have two potential configurations. associated handle, we have two potential configurations.
The second potential configuration attribute indicates that the The second potential configuration attribute indicates that the
RTP/AVPF or RTP/AVP profiles can be used, with RTP/AVPF being the RTP/AVPF or RTP/AVP profiles can be used, with RTP/AVPF being the
preferred one. This non secure RTP alternative is the less preferred preferred one. This non secure RTP alternative is the less preferred
one since its configuration number is "8". Again, note that we have one since its configuration number is "8". Again, note that we have
two potential configurations here and hence a total of four two potential configurations here and hence a total of four
potential configurations in the SDP above. potential configurations in the SDP session description above.
3.5.2. Actual Configuration Attribute 3.5.2. Actual Configuration Attribute
The actual configuration attribute identifies which of the potential The actual configuration attribute identifies which of the potential
configurations from an offer SDP was selected and used as the actual configurations from an offer SDP session description was selected
configuration to generate an answer SDP. This is done by including and used as the actual configuration to generate an answer SDP
the configuration number and the configuration lists (if any) from session description. This is done by including the configuration
the offer that were selected and used by the answerer in his number and the configuration lists (if any) from the offer that were
offer/answer procedure as follows: selected and used by the answerer in his offer/answer procedure as
follows:
o A selected attribute configuration MUST include the delete- o A selected attribute configuration MUST include the delete-
attributes and the known and supported parameters from the attributes and the known and supported parameters from the
selected alternative mo-att-cap-list (i.e., containing all selected alternative mo-att-cap-list (i.e., containing all
mandatory and all known and supported optional capability numbers mandatory and all known and supported optional capability numbers
from the potential configuration). If delete-attributes were not from the potential configuration). If delete-attributes were not
included in the potential configuration, they will of course not included in the potential configuration, they will of course not
be present here either. be present here either.
o A selected transport protocol configuration MUST include the o A selected transport protocol configuration MUST include the
skipping to change at page 31, line 29 skipping to change at page 33, line 15
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 only at the media-level. included) that refers to the selected potential configuration. 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 34, line 5 skipping to change at page 35, line 35
well. well.
o Zero or more potential configuration attributes. There MUST be o Zero or more potential configuration attributes. There MUST be
one or more potential configuration attributes ("a=pcfg"), as one or more potential configuration attributes ("a=pcfg"), as
defined in Section 3.5.1. , in each media description where defined in Section 3.5.1. , in each media description where
alternative potential configurations are to be negotiated. Each alternative potential configurations are to be negotiated. Each
potential configuration attribute MUST adhere to the rules potential configuration attribute MUST adhere to the rules
provided in Section 3.5.1. and the additional rules provided provided in Section 3.5.1. and the additional rules provided
below. below.
If the offerer requires support for more or extensions (besides the If the offerer requires support for one or more extensions (besides
base protocol defined here), then the offerer MUST include one or the base protocol defined here), then the offerer MUST include one
more "a=creq" attributes as follows: or more "a=creq" attributes as follows:
o If support for one or more capability negotiation extensions is o If support for one or more capability negotiation extensions is
required for the entire session description, then option tags for required for the entire session description, then option tags for
those extensions MUST be included in a single session-level those extensions MUST be included in a single session-level
"creq" attribute. "creq" attribute.
o For each media description that requires support for one or more o For each media description that requires support for one or more
capability negotiation extensions not listed at the session- capability negotiation extensions not listed at the session-
level, a single "creq" attribute containing all the required level, a single "creq" attribute containing all the required
extensions for that media description MUST be included within the extensions for that media description MUST be included within the
skipping to change at page 36, line 12 skipping to change at page 37, line 35
selected configuration is. Once that answer is received, incoming selected configuration is. Once that answer is received, incoming
media MUST be processed in accordance with the actual selected media MUST be processed in accordance with the actual selected
configuration indicated and the answer received (provided the configuration indicated and the answer received (provided the
offer/answer 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 session description is received. Conversely, if the
clipping, he should attempt to play any incoming media as soon as it offerer wants to avoid clipping, he SHOULD attempt to play any
is received (at the risk of playing out garbage). For further incoming media as soon as it is received (at the risk of playing out
details, please refer to Section 3.9. garbage). In either case, please note that this document does not
place any requirements on the offerer to process and play media
before answer. For further details, please refer to Section 3.9.
3.6.2. Generating the Answer 3.6.2. Generating the Answer
When receiving an offer, the answerer MUST check for the presence of When receiving an offer, the answerer MUST check for the presence of
a required capability negotiation extension attribute ("a=creq") a required capability negotiation extension attribute ("a=creq")
provided at the session level. If one is found, then capability provided at the session level. If one is found, then capability
negotiation MUST be performed. If none is found, then the answerer negotiation MUST be performed. If none is found, then the answerer
MUST check each offered media description for the presence of a MUST check each offered media description for the presence of a
required capability negotiation extension attribute ("a=creq") and required capability negotiation extension attribute ("a=creq") and
one or more potential configuration attributes ("a=pcfg"). one or more potential configuration attributes ("a=pcfg").
skipping to change at page 37, line 11 skipping to change at page 38, line 28
supported capability negotiation extensions attribute ("a=csup") supported capability negotiation extensions attribute ("a=csup")
with option tags for the capability negotiation extensions with option tags for the capability negotiation extensions
supported by the answerer. supported by the answerer.
o If a media-level "creq" attribute is provided, and it contains an o If a media-level "creq" attribute is provided, and it contains an
option tag that the answerer does not support, then the answerer option tag that the answerer does not support, then the answerer
MUST NOT use any of the potential configuration attributes MUST NOT use any of the potential configuration attributes
provided for that particular media description. Instead, the provided for that particular media description. Instead, the
offer/answer procedures for that media description MUST continue offer/answer procedures for that media description MUST continue
as per [RFC3264] (SDP Capability Negotiation is still performed as per [RFC3264] (SDP Capability Negotiation is still performed
for other media descriptions in the SDP). Furthermore, the for other media descriptions in the SDP session description).
answerer MUST include a supported capability negotiation Furthermore, the answerer MUST include a supported capability
extensions attribute ("a=csup") in that media description with negotiation extensions attribute ("a=csup") in that media
option tags for the capability negotiation extensions supported description with option tags for the capability negotiation
by the answerer for that media description. extensions supported by the answerer for that media description.
Assuming all required capability negotiation extensions are Assuming all required capability negotiation extensions are
supported, the answerer now proceeds as follows. supported, the answerer now proceeds as follows.
For each media description where capability negotiation is to be For each media description where capability negotiation is to be
performed (i.e. all required capability negotiation extensions are performed (i.e. all required capability negotiation extensions are
supported and at least one valid potential configuration attribute supported and at least one valid potential configuration attribute
is present), the answerer MUST perform capability negotiation by is present), the answerer MUST perform capability negotiation by
using the most preferred potential configuration that is valid to using the most preferred potential configuration that is valid to
the answerer, subject to any local policies. A potential the answerer, subject to any local policies. A potential
skipping to change at page 38, line 21 skipping to change at page 39, line 33
plus ("+") sign, which indicates that the extension MUST be plus ("+") sign, which indicates that the extension MUST be
supported in order to use that potential configuration. If the supported in order to use that potential configuration. If the
extension is not supported, that potential configuration is not extension is not supported, that potential configuration is not
valid to the answerer. valid to the answerer.
The most preferred valid potential configuration in a media The most preferred valid potential configuration in a media
description is the valid potential configuration with the lowest description is the valid potential configuration with the lowest
configuration number. The answerer MUST now process the offer for configuration number. The answerer MUST now process the offer for
that media stream based on the most preferred valid potential that media stream based on the most preferred valid potential
configuration. Conceptually, this entails the answerer constructing configuration. Conceptually, this entails the answerer constructing
an (internal) offer that consists of the actual configuration offer an (internal) offer as follows. First, all capability negotiation
SDP, with the following changes for each media stream offered: parameters from the offer SDP session description are removed,
thereby yielding an offer SDP session description with the actual
configuration as if SDP capability negotiation was not done in the
first place. Secondly, this actual configuration SDP session
description is then modified as follows for each media stream
offered based on the capability negotiation parameters included
originally:
o If a transport protocol capability is included in the potential o If a transport protocol capability is included in the potential
configuration, then it replaces the transport protocol provided configuration, then it replaces the transport protocol provided
in the "m=" line for that media description. in the "m=" line for that media description.
o If attribute capabilities are present with a delete-attributes o If attribute capabilities are present with a delete-attributes
session indication ("-s"), then all session-level attributes from session indication ("-s") or media and session indication ("-
the actual configuration SDP MUST be deleted in accordance with ms"), then all session-level attributes from the actual
the procedures in Section 3.5.1. If attribute capabilities are configuration SDP session description MUST be deleted in the
present with a delete-attributes media indication ("-m"), then resulting potential configuration SDP session description in
all attributes from the actual configuration SDP inside this accordance with the procedures in Section 3.5.1. If attribute
media description MUST be deleted. capabilities are present with a delete-attributes media
indication ("-m") or media and session indication ("-ms"), then
all attributes from the actual configuration SDP session
description inside this media description MUST be deleted.
o If a session-level attribute capability is included, the o If a session-level attribute capability is included, the
attribute (and its associated value, if any) contained in it MUST attribute (and its associated value, if any) contained in it MUST
be added to the resulting SDP. All such added session-level be added to the resulting SDP session description. All such added
attributes MUST be listed before the session-level attributes session-level attributes MUST be listed before the session-level
that were initially present in the SDP. Furthermore, the added attributes that were initially present in the SDP session
session-level attributes MUST be added in the order they were description. Furthermore, the added session-level attributes MUST
provided in the potential configuration (see also Section 3.5.1. be added in the order they were provided in the potential
). configuration (see also Section 3.5.1. ).
This allows for attributes with implicit preference ordering This allows for attributes with implicit preference ordering
to be added in the desired order; the "crypto" attribute to be added in the desired order; the "crypto" attribute
[RFC4568] is one such example. [RFC4568] is one such example.
o If a media-level attribute capability is included, then the o If a media-level attribute capability is included, then the
attribute (and its associated value, if any) MUST be added to the attribute (and its associated value, if any) MUST be added to the
resulting SDP within the media description in question. All such resulting SDP session description within the media description in
added media-level attributes MUST be listed before the media- question. All such added media-level attributes MUST be listed
level attributes that were initially present in the SDP in the before the media-level attributes that were initially present in
media description in question. Furthermore, the added media-level the media description in question. Furthermore, the added media-
attributes MUST be added in the order they were provided in the level attributes MUST be added in the order they were provided in
potential configuration (see also Section 3.5.1. ). the potential configuration (see also Section 3.5.1. ).
o If a supported extension capability is included, then it MUST be o If a supported extension capability is included, then it MUST be
processed in accordance with the rules provided for that processed in accordance with the rules provided for that
particular extension capability. particular extension capability.
The above steps MUST be performed exactly once per potential
configuration, i.e. there MUST NOT be any recursive processing of
any additional capability negotiation parameters that may have been
nested inside capabilities themselves.
As an example of this, consider the attribute capability
a=acap:1 acap:2 foo:a
The resulting potential configuration SDP session description
will, after the above processing has been done, contain the
attribute capability
a=acap:2 foo:a
However, since we do not perform any recursive processing of
capability negotiation parameters, this second attribute
capability parameter will not be processed by the offer/answer
procedure. Instead, it will simply appear as a (useless) attribute
in the SDP session description that will be ignored by further
processing.
Note that a transport protocol from the potential configuration Note that a transport protocol from the potential configuration
replaces the transport protocol in the actual configuration, but an replaces the transport protocol in the actual configuration, but an
attribute capability from the potential configuration is simply attribute capability from the potential configuration is simply
added to the actual configuration. In some cases, this can result in added to the actual configuration. In some cases, this can result in
having one or more meaningless attributes in the resulting potential having one or more meaningless attributes in the resulting potential
configuration SDP, or worse, ambiguous or potentially even illegal configuration SDP session description, or worse, ambiguous or
attributes. Use of delete-attributes for the session and/or media potentially even illegal attributes. Use of delete-attributes for
level attributes MUST be done to avoid such scenarios. Nevertheless, the session and/or media level attributes MUST be done to avoid such
it is RECOMMENDED that implementations ignore meaningless attributes scenarios. Nevertheless, it is RECOMMENDED that implementations
that may result from potential configurations. ignore meaningless attributes that may result from potential
configurations.
For example, if the actual configuration was using Secure RTP and For example, if the actual configuration was using Secure RTP and
included an "a=crypto" attribute for the SRTP keying material, included an "a=crypto" attribute for the SRTP keying material,
then use of a potential configuration that uses plain RTP would then use of a potential configuration that uses plain RTP would
make the "crypto" attribute meaningless. The answerer may or may make the "crypto" attribute meaningless. The answerer may or may
not ignore such a meaningless attribute. The offerer can here not ignore such a meaningless attribute. The offerer can here
ensure correct operation by using delete-attributes to remove the ensure correct operation by using delete-attributes to remove the
crypto attribute (but will then need to provide attribute crypto attribute (but will then need to provide attribute
capabilities to reconstruct the SDP with the necessary attributes capabilities to reconstruct the SDP session description with the
deleted, e.g. rtpmaps). necessary attributes deleted, e.g. rtpmaps).
Also note, that while it is permissible to include media-level
attribute capabilities at the session-level, the base SDP Capability
Negotiation framework defined here does not define any procedures
for use of them, i.e. the answerer effectively ignores them.
Please refer to Section 3.6.2.1. for examples of how the answerer Please refer to Section 3.6.2.1. for examples of how the answerer
may conceptually "see" the resulting offered alternative potential may conceptually "see" the resulting offered alternative potential
configurations. configurations.
The answerer MUST check that he supports all mandatory attribute The answerer MUST check that he supports all mandatory attribute
capabilities from the potential configuration (if any), the capabilities from the potential configuration (if any), the
transport protocol capability (if any) from the potential transport protocol capability (if any) from the potential
configuration, and all mandatory extension capabilities from the configuration, and all mandatory extension capabilities from the
potential configuration (if any). If he does not, the answerer MUST potential configuration (if any). If he does not, the answerer MUST
skipping to change at page 40, line 37 skipping to change at page 42, line 42
o In the case of extension capabilities, the extension MUST define o In the case of extension capabilities, the extension MUST define
the rules for when the extension capability is considered the rules for when the extension capability is considered
supported and those rules MUST be satisfied. supported and those rules MUST be satisfied.
If the answerer has exhausted all potential configurations for the If the answerer has exhausted all potential configurations for the
media description, without finding a valid one that is also media description, without finding a valid one that is also
supported, then the answerer MUST process the offered media stream supported, then the answerer MUST process the offered media stream
based on the actual configuration plus any session-level attributes based on the actual configuration plus any session-level attributes
added by a valid and supported potential configuration from another added by a valid and supported potential configuration from another
media description in the offered SDP. media description in the offered SDP session description.
The above process describes potential configuration selection as a The above process describes potential configuration selection as a
per media stream process. Inter-media stream coordination of per media stream process. Inter-media stream coordination of
selected potential configurations however is required in some cases. selected potential configurations however is required in some cases.
First of all, session-level attributes added by a potential First of all, session-level attributes added by a potential
configuration for one media description MUST NOT cause any problems configuration for one media description MUST NOT cause any problems
for potential configurations selected by other media descriptions in for potential configurations selected by other media descriptions in
the offer SDP. If the session-level attributes are mandatory, then the offer SDP session description. If the session-level attributes
those session-level attributes MUST furthermore be supported by the are mandatory, then those session-level attributes MUST furthermore
session as a whole (i.e., all the media descriptions if relevant). be supported by the session as a whole (i.e., all the media
As mentioned earlier, this adds additional complexity to the overall descriptions if relevant). As mentioned earlier, this adds
processing and hence it is RECOMMENDED not to use session-level additional complexity to the overall processing and hence it is
attribute capabilities in potential configurations, unless RECOMMENDED not to use session-level attribute capabilities in
absolutely necessary. potential configurations, unless absolutely necessary.
Once the answerer has selected a valid and supported offered Once the answerer has selected a valid and supported offered
potential configuration for all of the media streams (or has fallen potential configuration for all of the media streams (or has fallen
back to the actual configuration plus any added session attributes), back to the actual configuration plus any added session attributes),
the answerer MUST generate a valid answer SDP based on the selected the answerer MUST generate a valid virtual answer SDP session
potential configuration SDP, as "seen" by the answerer (see Section description based on the selected potential configuration SDP
3.6.2.1. for examples). Furthermore, if the answerer selected one of session description, as "seen" by the answerer using normal
the potential configurations in a media description, the answerer offer/answer rules (see Section 3.6.2.1. for examples). The actual
MUST include an actual configuration attribute ("a=acfg") within answer is formed from the virtual answer as follows: If the answerer
that media description. The "a=acfg" attribute MUST identify the selected one of the potential configurations in a media description,
configuration number for the selected potential configuration as the answerer MUST include an actual configuration attribute
well as the actual parameters that were used from that potential ("a=acfg") within that media description. The "a=acfg" attribute
configuration; if the potential configuration included alternatives, MUST identify the configuration number for the selected potential
the selected alternatives only MUST be included. Only the known and configuration as well as the actual parameters that were used from
supported parameters will be included. Unknown or unsupported that potential configuration; if the potential configuration
parameters MUST NOT be included in the actual configuration included alternatives, the selected alternatives only MUST be
attribute. In the case of attribute capabilities, only the known and included. Only the known and supported parameters will be included.
supported capabilities are included; unknown or unsupported Unknown or unsupported parameters MUST NOT be included in the actual
attribute capabilities MUST NOT be included. configuration attribute. In the case of attribute capabilities, only
the known and supported capabilities are included; unknown or
unsupported attribute capabilities MUST NOT be included.
If the answerer supports one or more capability negotiation If the answerer supports one or more capability negotiation
extensions that were not included in a required capability extensions that were not included in a required capability
negotiation extensions attribute in the offer, then the answerer negotiation extensions attribute in the offer, then the answerer
SHOULD furthermore include a supported capability negotiation SHOULD furthermore include a supported capability negotiation
attribute ("a=csup") at the session-level with option tags for the attribute ("a=csup") at the session-level with option tags for the
extensions supported across media streams. Also, if the answerer extensions supported across media streams. Also, if the answerer
supports one or more capability negotiation extensions for only supports one or more capability negotiation extensions for only
particular media descriptions, then a supported capability particular media descriptions, then a supported capability
negotiation attribute with those option-tags SHOULD be included negotiation attribute with those option-tags SHOULD be included
skipping to change at page 42, line 9 skipping to change at page 44, line 15
If the answerer selects one of the potential configurations, then If the answerer selects one of the potential configurations, then
the answerer MAY immediately start to send media to the offerer in the answerer MAY immediately start to send media to the offerer in
accordance with the selected potential configuration, however the accordance with the selected potential configuration, however the
offerer MAY discard such media or play out garbage until the offerer offerer MAY discard such media or play out garbage until the offerer
receives the answer. Please refer to section 3.9. for additional receives the answer. Please refer to section 3.9. for additional
considerations and possible alternative solutions outside the base considerations and possible alternative solutions outside the base
SDP Capability Negotiation framework. SDP Capability Negotiation framework.
If the offerer selected a potential configuration instead of the If the offerer selected a potential configuration instead of the
actual configuration, then it is RECOMMENDED that the answerer sends actual configuration, then it is RECOMMENDED that the answerer sends
back an answer SDP as soon as possible. This minimizes the risk of back an answer SDP session description as soon as possible. This
having media discarded or played out as garbage by the offerer. In minimizes the risk of having media discarded or played out as
the case of SIP [RFC3261] without any extensions, this implies that garbage by the offerer. In the case of SIP [RFC3261] without any
if the offer was received in an INVITE message, then the answer SDP extensions, this implies that if the offer was received in an INVITE
should be provided in the first non-100 provisional response sent message, then the answer SDP session description should be provided
back (per RFC3261, the answer would need to be repeated in the 200 in the first non-100 provisional response sent back (per RFC3261,
response as well, unless a relevant extension such as [RFC3262] is the answer would need to be repeated in the 200 response as well,
being used). unless a relevant extension such as [RFC3262] is being used).
3.6.2.1. Example Views of Potential Configurations 3.6.2.1. Example Views of Potential Configurations
The following examples illustrate how the answerer may conceptually The following examples illustrate how the answerer may conceptually
"see" a potential configuration. Consider the following offered SDP: "see" a potential configuration. Consider the following offered SDP
session description:
v=0 v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com o=alice 2891092738 2891092738 IN IP4 lost.example.com
s= s=
t=0 0 t=0 0
c=IN IP4 lost.example.com c=IN IP4 lost.example.com
a=tool:foo a=tool:foo
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tcap:1 RTP/SAVP RTP/AVP a=tcap:1 RTP/SAVP RTP/AVP
m=audio 59000 RTP/AVP 98 m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32 a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1|2 a=pcfg:1 t=1 a=1|2
m=video 52000 RTP/AVP 31 m=video 52000 RTP/AVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=pcfg:1 t=1 a=1|3 a=pcfg:1 t=1 a=1|3
This particular SDP offers an audio stream and a video stream, each This particular SDP session description offers an audio stream and a
of which can either use plain RTP (actual configuration) or secure video stream, each of which can either use plain RTP (actual
RTP (potential configuration). Furthermore, two different keying configuration) or secure RTP (potential configuration). Furthermore,
mechanisms are offered, namely session-level Key Management two different keying mechanisms are offered, namely session-level
Extensions using MIKEY (attribute capability 1) and media-level SDP Key Management Extensions using MIKEY (attribute capability 1) and
Security Descriptions (attribute capabilities 2 and 3). There are media-level SDP Security Descriptions (attribute capabilities 2 and
several potential configurations here, however, below we show the 3). There are several potential configurations here, however, below
one the answerer "sees" when using potential configuration 1 for we show the one the answerer "sees" when using potential
both audio and video, and furthermore using attribute capability 1 configuration 1 for both audio and video, and furthermore using
(MIKEY) for both (we have removed all the capability negotiation attribute capability 1 (MIKEY) for both (we have removed all the
attributes for clarity): capability negotiation attributes for clarity):
v=0 v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com o=alice 2891092738 2891092738 IN IP4 lost.example.com
s= s=
t=0 0 t=0 0
c=IN IP4 lost.example.com c=IN IP4 lost.example.com
a=tool:foo a=tool:foo
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98 m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
skipping to change at page 44, line 29 skipping to change at page 46, line 37
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
3.6.3. Offerer Processing of the Answer 3.6.3. Offerer Processing of the Answer
When the offerer attempted to use SDP Capability Negotiation in the When the offerer attempted to use SDP Capability Negotiation in the
offer, the offerer MUST examine the answer for actual use of SDP offer, the offerer MUST examine the answer for actual use of SDP
Capability Negotiation. Capability Negotiation.
For each media description where the offerer included a potential For each media description where the offerer included a potential
configuration attribute ("a=pcfg"), the offerer MUST first examine configuration attribute ("a=pcfg"), the offerer MUST first examine
that media description for the presence of an actual configuration that media description for the presence of a valid actual
attribute ("a=acfg"). If an actual configuration attribute is not configuration attribute ("a=acfg"). An actual configuration
present in a media description, then the offerer MUST process the attribute is valid if
answer SDP for that media stream per the normal offer/answer rules
o it refers to a potential configuration that was present in the
corresponding offer, and
o it contains the actual parameters that were used from that
potential configuration; if the potential configuration included
alternatives, the selected alternatives only MUST be included.
Note that the answer will include only parameters and attribute
capabilities that are known and supported by the answerer, as
described in Section 3.6.2.
If a valid actual configuration attribute is not present in a media
description, then the offerer MUST process the answer SDP session
description for that media stream per the normal offer/answer rules
defined in [RFC3264]. However, if one is found, the offerer MUST defined in [RFC3264]. However, if one is found, the offerer MUST
instead process the answer as follows: instead process the answer as follows:
o The actual configuration attribute specifies which of the o The actual configuration attribute specifies which of the
potential configurations was used by the answerer to generate the potential configurations was used by the answerer to generate the
answer for this media stream. This includes all the supported answer for this media stream. This includes all the supported
attribute capabilities and the transport capabilities referenced attribute capabilities and the transport capabilities referenced
by the potential configuration selected, where the attribute by the potential configuration selected, where the attribute
capabilities have any associated delete-attributes included. capabilities have any associated delete-attributes included.
Extension capabilities supported by the answerer are included as Extension capabilities supported by the answerer are included as
well. well.
o The offerer MUST now process the answer in accordance with the o The offerer MUST now process the answer in accordance with the
rules in [RFC3264], except that it must be done as if the offer rules in [RFC3264], except that it must be done as if the offer
consisted of the selected potential configuration instead of the consisted of the selected potential configuration instead of the
original actual configuration, including any transport protocol original actual configuration, including any transport protocol
changes in the media ("m=") line(s), attributes added and deleted changes in the media ("m=") line(s), attributes added and deleted
by the potential configuration at the media and session level, by the potential configuration at the media and session level,
and any extensions used. and any extensions used. If this derived answer is not a valid
answer to the potential configuration offer selected by the
answerer, the offerer MUST instead continue further processing as
it would have for a regular offer/answer exchange, where the
answer received does not adhere to the rules of [RFC3264].
If the offer/answer exchange was successful, and if the answerer If the offer/answer exchange was successful, and if the answerer
selected one of the potential configurations from the offer as the selected one of the potential configurations from the offer as the
actual configuration, and the selected potential configuration actual configuration, and the selected potential configuration
differs from the actual configuration in the offer (the "m=", "a=", differs from the actual configuration in the offer (the "m=", "a=",
etc. lines), then the offerer SHOULD initiate another offer/answer etc. lines), then the offerer SHOULD initiate another offer/answer
exchange. This second offer/answer exchange will not modify the exchange. This second offer/answer exchange will not modify the
session in any way, however it will help intermediaries (e.g. session in any way, however it will help intermediaries (e.g.
middleboxes), that look at the SDP but do not support the capability middleboxes), that look at the SDP session description but do not
negotiation extensions, understand the details of the media support the capability negotiation extensions, understand the
stream(s) that were actually negotiated. This new offer MUST contain details of the media stream(s) that were actually negotiated. This
the selected potential configuration as the actual configuration, new offer MUST contain the selected potential configuration as the
i.e., with the actual configuration used in the "m=" line and any actual configuration, i.e., with the actual configuration used in
other relevant attributes, bandwidth parameters, etc. the "m=" line and any other relevant attributes, bandwidth
parameters, etc.
Note that, per normal offer/answer rules, the second offer/answer Note that, per normal offer/answer rules, the second offer/answer
exchange still needs to update the version number in the "o=" line exchange still needs to update the version number in the "o=" line
((<sess-version> in [RFC4566]). Attribute lines carrying keying ((<sess-version> in [RFC4566]). Attribute lines carrying keying
material SHOULD repeat the keys from the previous offer, unless re- material SHOULD repeat the keys from the previous offer, unless re-
keying is necessary, e.g. due to a previously forked SIP INVITE keying is necessary, e.g. due to a previously forked SIP INVITE
request. Please refer to Section 3.12. for additional considerations request. Please refer to Section 3.12. for additional considerations
related to intermediaries. related to intermediaries.
3.6.4. Modifying the Session 3.6.4. Modifying the Session
skipping to change at page 48, line 22 skipping to change at page 50, line 43
however cases where permissible SDP values are tied to the use of however cases where permissible SDP values are tied to the use of
the SIP Require header. SIP preconditions [RFC3312] is one such the SIP Require header. SIP preconditions [RFC3312] is one such
example, where preconditions with a "mandatory" strength-tag can example, where preconditions with a "mandatory" strength-tag can
only be used when a SIP Require header with the SIP option tag only be used when a SIP Require header with the SIP option tag
"precondition" is included. Future SIP extensions that may want to "precondition" is included. Future SIP extensions that may want to
use the SDP Capability Negotiation framework should avoid such use the SDP Capability Negotiation framework should avoid such
coupling. coupling.
3.9. Processing Media before Answer 3.9. Processing Media before Answer
The offer/answer model requires an offerer to be able to receive The offer/answer model [RFC3264] requires an offerer to be able to
media in accordance with the offer prior to receiving the answer. receive media in accordance with the offer prior to receiving the
This property is retained with the SDP Capability Negotiation answer. This property is retained with the SDP Capability
extensions defined here, but only when the actual configuration is Negotiation extensions defined here, but only when the actual
selected by the answerer. If a potential configuration is chosen, it configuration is selected by the answerer. If a potential
is permissible for the offerer to not process any media received configuration is chosen, the offerer may decide to not process any
before the answer is received. This may lead to clipping. media received before the answer is received. This may lead to
Consequently, the SDP Capability Negotiation framework recommends clipping. Consequently, the SDP Capability Negotiation framework
sending back an answer SDP as soon as possible. recommends sending back an answer SDP session description as soon as
possible.
The issue can be resolved by introducing a three-way handshake. In The issue can be resolved by introducing a three-way handshake. In
the case of SIP, this can for example be done by defining a the case of SIP, this can for example be done by defining a
precondition [RFC3312] for capability negotiation (or use an precondition [RFC3312] for capability negotiation (or use an
existing precondition that is known to generate a second existing precondition that is known to generate a second
offer/answer exchange before proceeding with the session). However, offer/answer exchange before proceeding with the session). However,
preconditions are often viewed as complicated to implement and they preconditions are often viewed as complicated to implement and they
may add to overall session establishment delay by requiring an extra may add to overall session establishment delay by requiring an extra
offer/answer exchange. offer/answer exchange.
An alternative three-way handshake can be performed by use of ICE An alternative three-way handshake can be performed by use of ICE
[ICE]. When ICE is being used, and the answerer receives a STUN [ICE]. When ICE is being used, and the answerer receives a STUN
Binding Request for any one of the accepted media streams from the Binding Request for any one of the accepted media streams from the
offerer, the answerer knows the offer has received his answer. At offerer, the answerer knows the offer has received his answer. At
that point, the answerer knows that the offerer will be able to that point, the answerer knows that the offerer will be able to
process incoming media according to the negotiated configuration and process incoming media according to the negotiated configuration and
hence he can start sending media without the risk of the offerer hence he can start sending media without the risk of the offerer
either discarding it or playing garbage. either discarding it or playing garbage.
Please note that, the above considerations notwithstanding, this
document does not place any requirements on the offerer to process
and play media before answer; it merely provides recommendations for
how to ensure that media sent by the answerer and received by the
offerer prior to receiving the answer, can in fact be rendered by
the offerer.
In some use cases a three-way handshake is not needed. An example is In some use cases a three-way handshake is not needed. An example is
when the offerer does not need information from the answer, such as when the offerer does not need information from the answer, such as
keying material in the SDP, in order to process incoming media. The keying material in the SDP session description, in order to process
SDP Capability Negotiation framework does not define any such incoming media. The SDP Capability Negotiation framework does not
solutions, however extensions may do so. For example, one technique define any such solutions, however extensions may do so. For
proposed for best-effort SRTP in [BESRTP] is to provide different example, one technique proposed for best-effort SRTP in [BESRTP] is
RTP payload type mappings for different transport protocols used, to provide different RTP payload type mappings for different
outside of the actual configuration, while still allowing them to be transport protocols used, outside of the actual configuration, while
used by the answerer (exchange of keying material is still needed, still allowing them to be used by the answerer (exchange of keying
e.g. inband). The basic SDP Capability Negotiation framework defined material is still needed, e.g. inband). The basic SDP Capability
here does not include the ability to do so, however extensions that Negotiation framework defined here does not include the ability to
enable that may be defined. do so, however extensions that enable that may be defined.
3.10. Indicating Bandwidth Usage 3.10. Indicating Bandwidth Usage
The amount of bandwidth used for a particular media stream depends The amount of bandwidth used for a particular media stream depends
on the negotiated codecs, transport protocol and other parameters. on the negotiated codecs, transport protocol and other parameters.
For example use of Secure RTP [RFC3711] with integrity protection For example use of Secure RTP [RFC3711] with integrity protection
requires more bandwidth than plain RTP [RFC3551]. SDP defines the requires more bandwidth than plain RTP [RFC3551]. SDP defines the
bandwidth ("b=") parameter to indicate the proposed bandwidth for bandwidth ("b=") parameter to indicate the proposed bandwidth for
the session or media stream. the session or media stream.
In SDP as defined by [RFC4566], each media description contains one In SDP as defined by [RFC4566], each media description contains one
transport protocol and one or more codecs. When specifying the transport protocol and one or more codecs. When specifying the
proposed bandwidth, the worst case scenario must be taken into proposed bandwidth, the worst case scenario must be taken into
account, i.e., use of the highest bandwidth codec provided, the account, i.e., use of the highest bandwidth codec provided, the
transport protocol indicated, and the worst case (bandwidth-wise) transport protocol indicated, and the worst case (bandwidth-wise)
parameters that can be negotiated (e.g., a 32-bit HMAC or an 80-bit parameters that can be negotiated (e.g., a 32-bit HMAC or an 80-bit
HMAC). HMAC).
The core SDP capability negotiation framework does not provide a way The base SDP Capability Negotiation framework does not provide a way
to negotiate bandwidth parameters. The issue thus remains, however to negotiate bandwidth parameters. The issue thus remains, however
it is potentially worse than with SDP per [RFC4566], since it is it is potentially worse than with SDP per [RFC4566], since it is
easier to negotiate additional codecs, and furthermore possible to easier to negotiate additional codecs, and furthermore possible to
negotiate different transport protocols. The recommended approach negotiate different transport protocols. The recommended approach
for addressing this is the same as for plain SDP; the worst case for addressing this is the same as for plain SDP; the worst case
(now including potential configurations) needs to be taken into (now including potential configurations) needs to be taken into
account when specifying the bandwidth parameters in the actual account when specifying the bandwidth parameters in the actual
configuration. This can make the bandwidth value less accurate than configuration. This can make the bandwidth value less accurate than
in SDP per [RFC4566] (due to potential greater variability in the in SDP per [RFC4566] (due to potential greater variability in the
potential configuration bandwidth use). Extensions can be defined to potential configuration bandwidth use). Extensions can be defined to
address this shortcoming. Also, the Transport Independent address this shortcoming.
Application Specific Maximum (TIAS) bandwidth type defined in
[RFC3890] can be used to alleviate bandwidth variability concerns The Transport Independent Application Specific Maximum (TIAS)
due to different transport protocols. bandwidth type as defined in [RFC3890] SHOULD NOT be used to try and
alleviate bandwidth variability concerns due to different transport
protocols since there are some inconsistencies between [RFC3264] and
[RFC3890]. More specifically, [RFC3264] defines the bandwidth
parameter to apply to the receive direction for unicast streams,
whereas [RFC3890] intends to use bandwidth in the send direction.
Implementers are encouraged to look for an expected future solution
to this.
Note, that when using RTP retransmission [RFC4588] with the RTCP- Note, that when using RTP retransmission [RFC4588] with the RTCP-
based feedback profile [RFC4585] (RTP/AVPF), the retransmitted based feedback profile [RFC4585] (RTP/AVPF), the retransmitted
packets are part of the media stream bandwidth when using SSRC- packets are part of the media stream bandwidth when using SSRC-
multiplexing. If a feedback based protocol is offered as the actual multiplexing. If a feedback based protocol is offered as the actual
configuration transport protocol, a non-feedback based protocol is configuration transport protocol, a non-feedback based protocol is
offered as a potential configuration transport protocol and ends up offered as a potential configuration transport protocol and ends up
being used, the actual bandwidth usage may be lower than the being used, the actual bandwidth usage may be lower than the
indicated bandwidth value in the offer (and vice versa). indicated bandwidth value in the offer (and vice versa).
skipping to change at page 51, line 4 skipping to change at page 53, line 40
number (to 10), and doing the equivalent with two media streams number (to 10), and doing the equivalent with two media streams
would again double that number (to 20). While it is easy (and would again double that number (to 20). While it is easy (and
inexpensive) for the offerer to generate such offers, processing inexpensive) for the offerer to generate such offers, processing
them at the answering side may not be. Consequently, it is them at the answering side may not be. Consequently, it is
RECOMMENDED that offerers do not create offers with unnecessarily RECOMMENDED that offerers do not create offers with unnecessarily
large number of potential configurations in them. large number of potential configurations in them.
On the answering side, implementers MUST take care to avoid On the answering side, implementers MUST take care to avoid
excessive memory and CPU consumption. For example, a naive excessive memory and CPU consumption. For example, a naive
implementation that first generates all the valid potential implementation that first generates all the valid potential
configuration SDPs internally, could find itself being memory configuration SDP session descriptions internally, could find itself
exhausted, especially if it supports a large number of endpoints. being memory exhausted, especially if it supports a large number of
Similarly, a naive implementation that simply performs iterative endpoints. Similarly, a naive implementation that simply performs
trial-and-error processing on each possible potential configuration iterative trial-and-error processing on each possible potential
SDP (in the preference order specified) could find itself being CPU configuration SDP session description (in the preference order
constrained. An alternative strategy is to prune the search space specified) could find itself being CPU constrained. An alternative
first by discarding the set of offered potential configurations strategy is to prune the search space first by discarding the set of
where the transport protocol indicated (if any) is not supported, offered potential configurations where the transport protocol
and/or one or more mandatory attribute capabilities (if any) are indicated (if any) is not supported, and/or one or more mandatory
either not supported or not valid. Potential configurations with attribute capabilities (if any) are either not supported or not
unsupported mandatory extension configurations in them can be valid. Potential configurations with unsupported mandatory extension
discarded as well. configurations in them can be discarded as well.
3.12. SDP Capability Negotiation and Intermediaries 3.12. SDP Capability Negotiation and Intermediaries
An intermediary is here defined as an entity between a SIP user An intermediary is here defined as an entity between a SIP user
agent A and a SIP user agent B, that need to perform some kind of agent A and a SIP user agent B, that need to perform some kind of
processing on the SDP exchanged between A and B, in order for the processing on the SDP session descriptions exchanged between A and
session establishment to operate as intended. Examples of such B, in order for the session establishment to operate as intended.
intermediaries include Session Border Controllers (SBCs) that may Examples of such intermediaries include Session Border Controllers
perform media relaying, Proxy Call Session Control Functions (P- (SBCs) that may perform media relaying, Proxy Call Session Control
CSCF) that may authorize use of a certain amount of network Functions (P-CSCF) that may authorize use of a certain amount of
resources (bandwidth), etc. The presence and design of such network resources (bandwidth), etc. The presence and design of such
intermediaries may not follow the "Internet" model or the SIP intermediaries may not follow the "Internet" model or the SIP
requirements for proxies (which are not supposed to look in message requirements for proxies (which are not supposed to look in message
bodies such as SDP), however they are a fact of life in some bodies such as SDP session descriptions), however they are a fact of
deployment scenarios and hence deserve consideration. life in some deployment scenarios and hence deserve consideration.
If the intermediary needs to understand the characteristics of the If the intermediary needs to understand the characteristics of the
media sessions being negotiated, e.g. the amount of bandwidth used media sessions being negotiated, e.g. the amount of bandwidth used
or the transport protocol negotiated, then use of the SDP Capability or the transport protocol negotiated, then use of the SDP Capability
Negotiation framework may impact them. For example, some Negotiation framework may impact them. For example, some
intermediaries are known to disallow answers where the transport intermediaries are known to disallow answers where the transport
protocol differs from the one in the offer. Use of the SDP protocol differs from the one in the offer. Use of the SDP
Capability Negotiation framework in the presence of such Capability Negotiation framework in the presence of such
intermediaries could lead to session failures. Intermediaries that intermediaries could lead to session failures. Intermediaries that
need to authorize use of network resources based on the negotiated need to authorize use of network resources based on the negotiated
media stream parameters are affected as well. If they inspect only media stream parameters are affected as well. If they inspect only
the offer, then they may authorize parameters assuming a different the offer, then they may authorize parameters assuming a different
transport protocol, codecs, etc. than what is actually being transport protocol, codecs, etc. than what is actually being
negotiated. For these, and other, reasons it is RECOMMENDED that negotiated. For these, and other, reasons it is RECOMMENDED that
implementers of intermediaries add support for the SDP Capability implementers of intermediaries add support for the SDP Capability
Negotiation framework. Negotiation framework.
The SDP Capability Negotiation framework itself attempts to help out The SDP Capability Negotiation framework itself attempts to help out
these intermediaries as well, by optionally performing a second these intermediaries as well, by recommending a second offer/answer
offer/answer exchange when use of a potential configuration has been exchange when use of a potential configuration has been negotiated
negotiated (see Section 3.6.3. ). However, there are several (see Section 3.6.3. ). However, there are several limitations with
limitations with this approach. First of all, the second this approach. First of all, although the second offer/answer
offer/answer exchange is not required and hence may not be exchange is RECOMMENDED, it is not required and hence may not be
performed. Secondly, the intermediary may refuse the initial answer, performed. Secondly, the intermediary may refuse the initial answer,
e.g. due to perceived transport protocol mismatch. Thirdly, the e.g. due to perceived transport protocol mismatch. Thirdly, the
strategy is not foolproof, since the offer/answer procedures strategy is not foolproof, since the offer/answer procedures
[RFC3264] leave the original offer/answer exchange in effect when a [RFC3264] leave the original offer/answer exchange in effect when a
subsequent one fails; consider the following example: subsequent one fails; consider the following example:
1. Offerer generates an SDP offer with the actual configuration 1. Offerer generates an SDP session description offer with the
specifying a low bandwidth configuration (e.g. plain RTP) and a actual configuration specifying a low bandwidth configuration
potential configuration specifying a high(er) bandwidth (e.g. plain RTP) and a potential configuration specifying a
configuration (e.g. secure RTP with integrity). high(er) bandwidth configuration (e.g. secure RTP with
integrity).
2. An intermediary (e.g. an SBC or P-CSCF), that does not support 2. An intermediary (e.g. an SBC or P-CSCF), that does not support
SDP Capability Negotiation, authorizes the session based on the SDP Capability Negotiation, authorizes the session based on the
actual configuration it sees in the SDP. actual configuration it sees in the SDP session description.
3. The answerer chooses the high(er) bandwidth potential 3. The answerer chooses the high(er) bandwidth potential
configuration and generates an answer SDP based on that. configuration and generates an answer SDP session description
based on that.
4. The intermediary passes through the answer SDP. 4. The intermediary passes through the answer SDP session
description.
5. The offerer sees the accepted answer, and generates an updated 5. The offerer sees the accepted answer, and generates an updated
offer that contains the selected potential configuration as the offer that contains the selected potential configuration as the
actual configuration. In other words, the high(er) bandwidth actual configuration. In other words, the high(er) bandwidth
configuration (which has already been negotiated successfully) is configuration (which has already been negotiated successfully) is
now the actual configuration in the offer SDP. now the actual configuration in the offer SDP session
description.
6. The intermediary sees the new offer, however it does not 6. The intermediary sees the new offer, however it does not
authorize the use of the high(er) bandwidth configuration, and authorize the use of the high(er) bandwidth configuration, and
consequently generates a rejection message to the offerer. consequently generates a rejection message to the offerer.
7. The offerer receives the rejected offer. 7. The offerer receives the rejected offer.
After step 7, per RFC 3264, the offer/answer exchange that completed After step 7, per RFC 3264, the offer/answer exchange that completed
in step 5 remains in effect, however the intermediary may not have in step 5 remains in effect, however the intermediary may not have
authorized the necessary network resources and hence the media authorized the necessary network resources and hence the media
stream may experience quality issues. The solution to this problem stream may experience quality issues. The solution to this problem
is to upgrade the intermediary to support the SDP Capability is to upgrade the intermediary to support the SDP Capability
Negotiation framework. Negotiation framework.
3.13. Considerations for Specific Attribute Capabilities 3.13. Considerations for Specific Attribute Capabilities
3.13.1. The rtpmap and fmtp Attributes 3.13.1. The rtpmap and fmtp Attributes
The core SDP Capability Negotiation framework defines transport The base SDP Capability Negotiation framework defines transport
capabilities and attribute capabilities. Media capabilities, which capabilities and attribute capabilities. Media capabilities, which
can be used to describe media formats and their associated can be used to describe media formats and their associated
parameters, are not defined in this document, however the "rtpmap" parameters, are not defined in this document, however the "rtpmap"
and "fmtp" attributes can nevertheless be used as attribute and "fmtp" attributes can nevertheless be used as attribute
capabilities. Using such attribute capabilities in a potential capabilities. Using such attribute capabilities in a potential
configuration requires a bit of care though. configuration requires a bit of care though.
The rtpmap parameter binds an RTP payload type to a media format The rtpmap parameter binds an RTP payload type to a media format
(e.g. codec). While it is possible to provide rtpmaps for payload (e.g. codec). While it is possible to provide rtpmaps for payload
types not found in the corresponding "m=" line, such rtpmaps provide types not found in the corresponding "m=" line, such rtpmaps provide
no value in normal offer/answer exchanges, since only the payload no value in normal offer/answer exchanges, since only the payload
types found in the "m=" line are part of the offer (or answer). This types found in the "m=" line are part of the offer (or answer). This
applies to the core SDP Capability Negotiation framework as well: applies to the base SDP Capability Negotiation framework as well:
Only the media formats (e.g. RTP payload types) provided in the "m=" Only the media formats (e.g. RTP payload types) provided in the "m="
line are actually offered; inclusion of rtpmap attributes with other line are actually offered; inclusion of rtpmap attributes with other
RTP payload types in a potential configuration does not change this RTP payload types in a potential configuration does not change this
fact and hence they do not provide any useful information there. fact and hence they do not provide any useful information there.
They may still be useful as pure capabilities though (outside a They may still be useful as pure capabilities though (outside a
potential configuration) in order to inform a peer of additional potential configuration) in order to inform a peer of additional
codecs supported. codecs supported.
It is possible to provide an rtpmap attribute capability with a It is possible to provide an rtpmap attribute capability with a
payload type mapping to a different codec than a corresponding payload type mapping to a different codec than a corresponding
skipping to change at page 54, line 5 skipping to change at page 56, line 42
fmtp attribute capability for a media format not included in the fmtp attribute capability for a media format not included in the
"m=" line is useless in a potential configuration (but may be useful "m=" line is useless in a potential configuration (but may be useful
as a capability by itself). An fmtp attribute capability in a as a capability by itself). An fmtp attribute capability in a
potential configuration for a media format that already has an fmtp potential configuration for a media format that already has an fmtp
attribute in the actual configuration may lead to multiple fmtp attribute in the actual configuration may lead to multiple fmtp
format parameters for that media format and that is not allowed by format parameters for that media format and that is not allowed by
SDP [RFC4566]. The delete-attributes MUST be used to ensure that SDP [RFC4566]. The delete-attributes MUST be used to ensure that
there is not multiple fmtp attributes for a given media format in a there is not multiple fmtp attributes for a given media format in a
media description. media description.
Extensions to the core SDP Capability Negotiation framework may Extensions to the base SDP Capability Negotiation framework may
change the above behavior. change the above behavior.
3.13.2. Direction Attributes 3.13.2. Direction Attributes
SDP defines the "inactive", "sendonly", "recvonly", and "sendrecv" SDP defines the "inactive", "sendonly", "recvonly", and "sendrecv"
direction attributes. The direction attributes can be applied at direction attributes. The direction attributes can be applied at
either the session-level or the media-level. In either case, it is either the session-level or the media-level. In either case, it is
possible to define attribute capabilities for these direction possible to define attribute capabilities for these direction
capabilities; if used by a potential configuration, the normal capabilities; if used by a potential configuration, the normal
offer/answer procedures still apply. For example, if an offered offer/answer procedures still apply. For example, if an offered
skipping to change at page 56, line 40 skipping to change at page 59, line 29
capability 2 (RTP/SAVP) and mandatory attribute capability 1 (the capability 2 (RTP/SAVP) and mandatory attribute capability 1 (the
"crypto" attribute). "crypto" attribute).
o Potential configuration 3, which is the least preferred potential o Potential configuration 3, which is the least preferred potential
configuration (but the second least preferred configuration configuration (but the second least preferred configuration
overall, since the actual configuration provided by the "m=" line overall, since the actual configuration provided by the "m=" line
is always the least preferred configuration), specifies use of is always the least preferred configuration), specifies use of
transport protocol capability 3 (RTP/AVPF) and optional attribute transport protocol capability 3 (RTP/AVPF) and optional attribute
capability 2 (the "rtcp-fb" attribute). capability 2 (the "rtcp-fb" attribute).
Bob receives the SDP offer from Alice. Bob does not support any Bob receives the SDP session description offer from Alice. Bob does
secure RTP profiles, however he supports plain RTP and RTP with not support any secure RTP profiles, however he supports plain RTP
RTCP-based feedback, as well as the SDP Capability Negotiation and RTP with RTCP-based feedback, as well as the SDP Capability
extensions, and hence he accepts the potential configuration for RTP Negotiation extensions, and hence he accepts the potential
with RTCP-based feedback provided by Alice: configuration for RTP with RTCP-based feedback provided by Alice:
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/AVPF 0 18 m=audio 54568 RTP/AVPF 0 18
a=rtcp-fb:0 nack a=rtcp-fb:0 nack
a=acfg:1 t=3 a=[2] a=acfg:1 t=3 a=[2]
Bob includes the "a=acfg" attribute in the answer to inform Alice Bob includes the "a=acfg" attribute in the answer to inform Alice
that he based his answer on an offer containing the potential that he based his answer on an offer containing the potential
configuration with transport protocol capability 3 and optional configuration with transport protocol capability 3 and optional
attribute capability 2 from the offer SDP (i.e. the RTP/AVPF profile attribute capability 2 from the offer SDP session description (i.e.
using the "rtcp-fb" value provided). Bob also includes an "rtcp-fb" the RTP/AVPF profile using the "rtcp-fb" value provided). Bob also
attribute with the value "nack" value for RTP payload type 0. includes an "rtcp-fb" attribute with the value "nack" value for RTP
payload type 0.
When Alice receives Bob's answer, session negotiation has completed, When Alice receives Bob's answer, session negotiation has completed,
however Alice nevertheless chooses to generate a new offer using the however Alice nevertheless chooses to generate a new offer using the
actual configuration. This is done purely to assist any actual configuration. This is done purely to assist any
intermediaries that may reside between Alice and Bob but do not intermediaries that may reside between Alice and Bob but do not
support the SDP Capability Negotiation framework (and hence may not support the SDP Capability Negotiation framework (and hence may not
understand the negotiation that just took place): understand the negotiation that just took place):
Alice's updated offer includes only RTP/AVPF, and it is not using Alice's updated offer includes only RTP/AVPF, and it is not using
the SDP Capability Negotiation framework (Alice could have included the SDP Capability Negotiation framework (Alice could have included
skipping to change at page 57, line 40 skipping to change at page 60, line 31
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
t=0 0 t=0 0
m=audio 53456 RTP/AVPF 0 18 m=audio 53456 RTP/AVPF 0 18
a=rtcp-fb:0 nack a=rtcp-fb:0 nack
The "m=" line now indicates that Alice is offering to use RTP with The "m=" line now indicates that Alice is offering to use RTP with
RTCP-based feedback and using PCMU or G.729. The "rtcp-fb" RTCP-based feedback and using PCMU or G.729. The "rtcp-fb"
attribute provides the feedback type "nack" for payload type 0 again attribute provides the feedback type "nack" for payload type 0 again
(but as part of the actual configuration). (but as part of the actual configuration).
Bob receives the SDP offer from Alice, which he accepts, and then Bob receives the SDP session description offer from Alice, which he
generates an answer to Alice: accepts, and then generates an answer to Alice:
v=0 v=0
o=- 24351 621815 IN IP4 192.0.2.2 o=- 24351 621815 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/AVPF 0 18 m=audio 54568 RTP/AVPF 0 18
a=rtcp-fb:0 nack a=rtcp-fb:0 nack
Bob includes the same "rtcp-fb" attribute as before, and the session Bob includes the same "rtcp-fb" attribute as before, and the session
skipping to change at page 60, line 5 skipping to change at page 62, line 30
The first (and preferred) potential configuration for the audio The first (and preferred) potential configuration for the audio
stream specifies use of transport capability 1 (UDP/TLS/RTP/SAVP), stream specifies use of transport capability 1 (UDP/TLS/RTP/SAVP),
i.e. DTLS-SRTP, and attribute capabilities 1 and 2 (active/passive i.e. DTLS-SRTP, and attribute capabilities 1 and 2 (active/passive
mode and certificate fingerprint), both of which must be supported mode and certificate fingerprint), both of which must be supported
to choose this potential configuration. The second (and less to choose this potential configuration. The second (and less
preferred) potential configuration specifies use of transport preferred) potential configuration specifies use of transport
capability 2 (RTP/SAVP) and mandatory attribute capability 3, i.e. capability 2 (RTP/SAVP) and mandatory attribute capability 3, i.e.
the SDP security description. the SDP security description.
Bob receives the SDP offer from Alice. Bob supports DTLS-SRTP as Bob receives the SDP session description offer from Alice. Bob
preferred by Alice and Bob now initiates the DTLS-SRTP handshake to supports DTLS-SRTP as preferred by Alice and Bob now initiates the
establish the DTLS-SRTP session (see [DTLS-SRTP] for details). DTLS-SRTP handshake to establish the DTLS-SRTP session (see [DTLS-
SRTP] for details).
Bob also sends back an answer to Alice as follows: Bob also sends back an answer to Alice as follows:
v=0 v=0
o=- 24351 621814 IN IP4 192.0.2.2 o=- 24351 621814 IN IP4 192.0.2.2
s= s=
a=setup:active a=setup:active
a=fingerprint: SHA-1 \ a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0 t=0 0
skipping to change at page 61, line 10 skipping to change at page 63, line 36
a=setup:actpass a=setup:actpass
a=fingerprint: SHA-1 \ a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 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 m=audio 59000 UDP/TLS/RTP/AVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
The "m=" line for the audio stream now indicates that Alice is The "m=" line for the audio stream now indicates that Alice is
offering to use DTLS-SRTP in active/passive mode using her offering to use DTLS-SRTP in active/passive mode using her
certificate fingerprint provided. certificate fingerprint provided.
Bob receives the SDP offer from Alice, which he accepts, and then Bob receives the SDP session description offer from Alice, which he
generates an answer to Alice: accepts, and then generates an answer to Alice:
v=0 v=0
o=- 24351 621814 IN IP4 192.0.2.2 o=- 24351 621814 IN IP4 192.0.2.2
s= s=
a=setup:active a=setup:active
a=fingerprint: SHA-1 \ a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0 t=0 0
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
m=audio 54568 UDP/TLS/RTP/SAVP 98 m=audio 54568 UDP/TLS/RTP/SAVP 98
skipping to change at page 64, line 5 skipping to change at page 66, line 32
o The second configuration with configuration number 2 uses o The second configuration with configuration number 2 uses
transport capability 2 (RTP/SAVP) and either attribute capability transport capability 2 (RTP/SAVP) and either attribute capability
1 (session-level MIKEY) or attribute capability 3 (SDP security 1 (session-level MIKEY) or attribute capability 3 (SDP security
descriptions). Both attribute capabilities are mandatory in this descriptions). Both attribute capabilities are mandatory in this
configuration. configuration.
o The third configuration with configuration number 3 uses o The third configuration with configuration number 3 uses
transport capability 3 (RTP/AVPF) and mandatory attribute transport capability 3 (RTP/AVPF) and mandatory attribute
capability 4 (the "rtcp-fb" attribute). capability 4 (the "rtcp-fb" attribute).
Bob receives the SDP offer from Alice. Bob supports Secure RTP, Bob receives the SDP session description offer from Alice. Bob
Secure RTP with RTCP-based feedback and the SDP Capability supports Secure RTP, Secure RTP with RTCP-based feedback and the SDP
Negotiation extensions. Bob also supports SDP Security Descriptions, Capability Negotiation extensions. Bob also supports SDP Security
but not MIKEY, and hence he generates the following answer: Descriptions, but not MIKEY, and hence he generates the following
answer:
v=0 v=0
o=- 24351 621814 IN IP4 192.0.2.2 o=- 24351 621814 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
skipping to change at page 65, line 29 skipping to change at page 68, line 12
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtcp-fb:* nack a=rtcp-fb:* nack
The "m=" line for the audio stream now indicates that Alice is The "m=" line for the audio stream now indicates that Alice is
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 session description offer from Alice, which he
generates an answer to Alice: accepts, and then generates an answer to Alice:
v=0 v=0
o=- 24351 621815 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
skipping to change at page 68, line 16 skipping to change at page 70, line 48
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 its 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 session description offer from Alice. Bob
the SDP Capability Negotiation framework. Bob also supports both SDP supports Secure RTP and the SDP Capability Negotiation framework.
Security Descriptions and MIKEY. Since the potential configuration
is more preferred than the actual configuration, Bob (conceptually) Bob also supports both SDP Security Descriptions and MIKEY. Since
generates an internal potential configuration SDP that contains the the potential configuration is more preferred than the actual
crypto attributes for the audio and video stream, but not the key- configuration, Bob (conceptually) generates an internal potential
mgmt attribute for MIKEY, thereby avoiding any ambiguity between the configuration SDP session description that contains the crypto
two keying mechanisms. As a result, he generates the following attributes for the audio and video stream, but not the key-mgmt
answer: attribute for MIKEY, thereby avoiding any ambiguity between the two
keying mechanisms. As a result, he generates the following answer:
v=0 v=0
o=- 24351 621814 IN IP4 192.0.2.2 o=- 24351 621814 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
skipping to change at page 69, line 8 skipping to change at page 71, line 41
with his own keying material, and an "acfg" attribute identifying with his own keying material, and an "acfg" attribute identifying
actual configuration 1 for the audio media stream from the offer, actual configuration 1 for the audio media stream from the offer,
with the delete-attributes ("-s") and attribute capability 1 (the with the delete-attributes ("-s") and attribute capability 1 (the
crypto attribute from the offer). For the video stream, Bob also crypto attribute from the offer). For the video stream, Bob also
accepted the use of secure RTP using SDP security descriptions. Bob accepted the use of secure RTP using SDP security descriptions. Bob
therefore includes a "crypto" attribute with his own keying therefore includes a "crypto" attribute with his own keying
material, and an "acfg" attribute identifying actual configuration 1 material, and an "acfg" attribute identifying actual configuration 1
for the video stream from the offer, with the delete-attributes ("- for the video stream from the offer, with the delete-attributes ("-
s") and attribute capability 2. s") and attribute capability 2.
Below, we illustrate the offer SDP, when Bob instead offers the Below, we illustrate the offer SDP session description, when Bob
"crypto" attribute as the actual configuration keying mechanism and instead offers the "crypto" attribute as the actual configuration
"key-mgmt" as the potential configuration: keying mechanism and "key-mgmt" as the potential configuration:
v=0 v=0
o=- 25678 753849 IN IP4 192.0.2.1 o=- 25678 753849 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
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
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
a=acap:2 rtpmap:98 AMR/8000 a=acap:2 rtpmap:98 AMR/8000
a=pcfg:1 a=-m:1,2 a=pcfg:1 a=-m:1,2
m=video 52000 RTP/SAVP 31 m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
skipping to change at page 69, line 33 skipping to change at page 72, line 20
a=pcfg:1 a=-m:1,2 a=pcfg:1 a=-m:1,2
m=video 52000 RTP/SAVP 31 m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80 a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=acap:4 rtpmap:31 H261/90000 a=acap:4 rtpmap:31 H261/90000
a=pcfg:1 a=-m:1,4 a=pcfg:1 a=-m:1,4
Note how we this time need to perform delete-attributes at the Note how we this time need to perform delete-attributes at the
media-level instead of the session-level. When doing that, all media-level instead of the session-level. When doing that, all
attributes from the actual configuration SDP, including the rtpmaps attributes from the actual configuration SDP session description,
provided, are removed. Consequently, we had to include these rtpmaps including the rtpmaps provided, are removed. Consequently, we had to
as capabilities as well, and then include them in the potential include these rtpmaps as capabilities as well, and then include them
configuration, thereby effectively recreating the original rtpmap in the potential configuration, thereby effectively recreating the
attributes in the resulting potential configuration SDP. original rtpmap attributes in the resulting potential configuration
SDP session description.
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 [RFC3264]. offer/answer security considerations apply here as well [RFC3264].
Similarly, the Session Initiation Protocol (SIP) uses SDP and the Similarly, the Session Initiation Protocol (SIP) uses SDP and the
offer/answer model, and hence, when used in that context, the SIP offer/answer model, and hence, when used in that context, the SIP
security considerations apply as well [RFC3261]. security considerations apply as well [RFC3261].
skipping to change at page 70, line 19 skipping to change at page 73, line 6
further security considerations. We discuss these issues below. further security considerations. We discuss these issues below.
The SDP Capability Negotiation framework allows for an offered media The SDP Capability Negotiation framework allows for an offered media
stream to both indicate and support various levels of security for stream to both indicate and support various levels of security for
that media stream. Different levels of security can for example be that media stream. Different levels of security can for example be
negotiated by use of alternative attribute capabilities each negotiated by use of alternative attribute capabilities each
indicating more or less secure keying methods as well as more or indicating more or less secure keying methods as well as more or
less strong ciphers. Since the offerer indicates support for each of less strong ciphers. Since the offerer indicates support for each of
these alternatives, he will presumably accept the answerer seemingly these alternatives, he will presumably accept the answerer seemingly
selecting any of the offered alternatives. If an attacker can modify selecting any of the offered alternatives. If an attacker can modify
the SDP offer, he can thereby force the negotiation of the weakest the SDP session description offer, he can thereby force the
security mechanism that the offerer is willing to accept. This may negotiation of the weakest security mechanism that the offerer is
enable the attacker to compromise the security of the negotiated willing to accept. This may enable the attacker to compromise the
media stream. Similarly, if the offerer wishes to negotiate use of a security of the negotiated media stream. Similarly, if the offerer
secure media stream (e.g. secure RTP), but includes a non-secure wishes to negotiate use of a secure media stream (e.g. secure RTP),
media stream (e.g. plain RTP) as a valid (but less preferred) but includes a non-secure media stream (e.g. plain RTP) as a valid
alternative, then an attacker that can modify the offered SDP will (but less preferred) alternative, then an attacker that can modify
be able to force the establishment of an insecure media stream. The the offered SDP session description will be able to force the
solution to both of these problems involves the use of integrity establishment of an insecure media stream. The solution to both of
protection over the SDP. Ideally, this integrity protection provides these problems involves the use of integrity protection over the SDP
session description. 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 [RFC5751]
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, is to use SIP Identity [RFC4474]; this requires deploy in practice, is to use SIP Identity [RFC4474]; this requires
the existence of an authentication service (see [RFC4474]). Although the existence of an authentication service (see [RFC4474]). Although
this mechanism still requires a PKI, it only requires that servers this mechanism still requires a PKI, it only requires that servers
(as opposed to end-users) have third party validatable certificates, (as opposed to end-users) have third party validatable certificates,
which significantly reduces the barrier to entry by ordinary users. which significantly reduces the barrier to entry by ordinary users.
Yet another, and considerably less secure, alternative is to use Yet another, and considerably less secure, alternative is to use
hop-by-hop security only, e.g. TLS or IPsec thereby ensuring the hop-by-hop security only, e.g. TLS or IPsec thereby ensuring the
integrity of the offered SDP on a hop-by-hop basis. This is less integrity of the offered SDP session description on a hop-by-hop
secure because SIP allows partially trusted intermediaries on the basis. This is less secure because SIP allows partially trusted
signaling path, and such intermediaries processing the SIP request intermediaries on the signaling path, and such intermediaries
at each hop would be able to perform a man-in- the-middle attack by processing the SIP request at each hop would be able to perform a
modifying the offered SDP. In simple architectures where the two man-in- the-middle attack by modifying the offered SDP session
UA's proxies communicate directly, the security provided by this description. In simple architectures where the two UA's proxies
method is roughly comparable to that provided by the previously communicate directly, the security provided by this method is
discussed signature-based mechanisms. 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 71, line 30 skipping to change at page 74, line 18
configuration, however that may in itself have undesirable side- configuration, however that may in itself have undesirable side-
effects: If the answerer does not support the secure media stream effects: If the answerer does not support the secure media stream
and also does not support the capability negotiation framework, then and also does not support the capability negotiation framework, then
negotiation of the media stream will fail. Alternatively, SDP negotiation of the media stream will fail. Alternatively, SDP
security preconditions [RFC5027] can be used. This will ensure that security preconditions [RFC5027] can be used. This will ensure that
media is not flowing until session negotiation has completed and media is not flowing until session negotiation has completed and
hence the selected configuration is known. Use of preconditions hence the selected configuration is known. Use of preconditions
however requires both sides to support them. If they don't, and use however requires both sides to support them. If they don't, and use
of them is required, the session will fail. As a (limited) work of them is required, the session will fail. As a (limited) work
around to this, it is RECOMMENDED that SIP entities generate an around to this, it is RECOMMENDED that SIP entities generate an
answer SDP and send it to the offerer as soon as possible, for answer SDP session description and send it to the offerer as soon as
example in a 183 Session Progress message. This will limit the time possible, for example in a 183 Session Progress message. This will
during which an attacker can send media to the offerer. Section 3.9. limit the time during which an attacker can send media to the
presents other alternatives as well. offerer. Section 3.9. presents other alternatives as well.
Additional security considerations apply to the answer SDP as well. Additional security considerations apply to the answer SDP session
The actual configuration attribute tells the offerer which potential description as well. The actual configuration attribute tells the
configuration the answer was based on, and hence an attacker that offerer which potential configuration the answer was based on, and
can either modify or remove the actual configuration attribute in hence an attacker that can either modify or remove the actual
the answer can cause session failure as well as extend the time configuration attribute in the answer can cause session failure as
window during which the offerer will accept incoming media that does well as extend the time window during which the offerer will accept
not conform to the actual answer. The solutions to this SDP answer incoming media that does not conform to the actual answer. The
integrity problem are the same as for the offer, i.e. use of end-to- solutions to this SDP session description answer integrity problem
end integrity protection, SIP identity, or hop-by-hop protection. are the same as for the offer, i.e. use of end-to-end integrity
The mechanism to use depends on the mechanisms supported by the protection, SIP identity, or hop-by-hop protection. The mechanism to
offerer as well as the acceptable security trade-offs. use depends on the mechanisms supported by the offerer as well as
the acceptable security trade-offs.
As described in Section 3.1. , SDP Capability Negotiation As described in Section 3.1. and 3.11. , 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 session description. This can cause the answerer to
alternative potential offers, which can consume significant memory process a large number of alternative potential offers, which can
and CPU resources. An attacker can use this amplification feature to consume significant memory and CPU resources. An attacker can use
launch a denial of service attack against the answerer. The answerer this amplification feature to launch a denial of service attack
must protect itself from such attacks. As explained in Section 3.10. against the answerer. The answerer must protect itself from such
, the answerer can help reduce the effects of such an attack by attacks. As explained in Section 3.11. , the answerer can help
first discarding all potential configurations that contain reduce the effects of such an attack by first discarding all
unsupported transport protocols, unsupported or invalid mandatory potential configurations that contain unsupported transport
attribute capabilities, or unsupported mandatory extension protocols, unsupported or invalid mandatory attribute capabilities,
configurations. The answerer should also look out for potential or unsupported mandatory extension configurations. The answerer
configurations that are designed to pass the above test, but should also look out for potential configurations that are designed
nevertheless produce a large number of potential configuration SDPs to pass the above test, but nevertheless produce a large number of
that cannot be supported. potential configuration SDP session descriptions 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
skipping to change at page 74, line 10 skipping to change at page 77, line 4
Contact name: Flemming Andreasen, fandreas@cisco.com Contact name: Flemming Andreasen, fandreas@cisco.com
Attribute name: acfg Attribute name: acfg
Long form name: Actual configuration Long form name: Actual configuration
Type of attribute: Media-level Type of attribute: Media-level
Subject to charset: No Subject to charset: No
Purpose: Actual configuration for SDP capability Purpose: Actual configuration for SDP capability
negotiation negotiation
Appropriate values: See Section 3.5.2. of RFCXXXX Appropriate values: See Section 3.5.2. of RFCXXXX
-- Note to RFC editor: -- Note to RFC editor:
-- replace RFCXXXX by this RFC number -- replace RFCXXXX by this RFC number
Contact name: Flemming Andreasen, fandreas@cisco.com Contact name: Flemming Andreasen, fandreas@cisco.com
6.2. New SDP Capability Negotiation Option Tag Registry 6.2. New SDP Capability Negotiation Option Tag Registry
The IANA is hereby requested to create a new SDP Capability The IANA is hereby requested to create a new SDP Capability
Negotiation Option Tag registry. An IANA SDP Capability Negotiation Negotiation Option Tag registry. An IANA SDP Capability Negotiation
option tag registration MUST be documented in an RFC in accordance option tag registration MUST be documented in an RFC in accordance
with the [RFC5226] Specification Required policy. The RFC MUST with the [RFC5226] IETF Review policy. The RFC MUST provide the name
provide the name of the option tag, a syntax and a semantic of the option tag, a syntax and a semantic specification of any new
specification of any new SDP attributes and any extensions to the SDP attributes and any extensions to the potential configuration
potential and actual configuration attributes provided in this ("a=pcfg") and actual configuration ("a=acfg") attributes provided
document. New SDP attributes that are intended to be capabilities in this document. If the extension defines any new SDP attributes
for use by the capability negotiation framework MUST adhere to the that are intended to be capabilities for use by the capability
guidelines provided in Section 3.4.3. Extensions to the potential negotiation framework (similar to e.g. "a=acap"), those capabilities
and actual configuration attributes MUST adhere to the syntax MUST adhere to the guidelines provided in Section 3.4.3. Extensions
provided in Section 3.5.1. and 3.5.2. to the potential and actual configuration attributes MUST adhere to
the syntax provided in Section 3.5.1. and 3.5.2.
The option tag "cap-v0" is defined in this document and the IANA is The option tag "cap-v0" is defined in this document and the IANA is
hereby requested to register this option tag. hereby requested to register this option tag.
6.3. New SDP Capability Negotiation Potential Configuration Parameter 6.3. New SDP Capability Negotiation Potential Configuration Parameter
Registry Registry
The IANA is hereby requested to create a new SDP Capability The IANA is hereby requested to create a new SDP Capability
Negotiation Potential Configuration Parameter registry. An IANA SDP Negotiation Potential Configuration Parameter registry. An IANA SDP
Capability Negotiation potential configuration registration MUST be Capability Negotiation potential configuration registration MUST be
documented in an RFC in accordance with the [RFC5226] Specification documented in an RFC in accordance with the [RFC5226] IETF Review
Required policy. The RFC MUST define the syntax and semantics of policy. The RFC MUST define the syntax and semantics of each new
each new potential configuration parameter. The syntax MUST adhere potential configuration parameter. The syntax MUST adhere to the
to the syntax provided for extensions in Section 3.5.1. and the syntax provided for extensions in Section 3.5.1. and the semantics
semantics MUST adhere to the semantics provided for extensions in MUST adhere to the semantics provided for extensions in Section
Section 3.5.1. and 3.5.2. Associated with each registration MUST be 3.5.1. and 3.5.2. Associated with each registration MUST be the
the encoding name for the parameter as well as a short descriptive encoding name for the parameter as well as a short descriptive name
name for it. for it.
The potential configuration parameters "a" for "attribute" and "t" The potential configuration parameters "a" for "attribute" and "t"
for "transport protocol" are defined in this document and the IANA for "transport protocol" are defined in this document and the IANA
is hereby requested to register these. is hereby requested to register these.
7. Acknowledgments 7. Acknowledgments
The SDP Capability Negotiation solution defined in this document The SDP Capability Negotiation solution defined in this document
draws on the overall capability negotiation framework that was draws on the overall capability negotiation framework that was
defined by [SDPng]. Also, the SDP Capability Negotiation solution is defined by [SDPng]. Also, the SDP Capability Negotiation solution is
skipping to change at page 75, line 26 skipping to change at page 78, line 22
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 General Area review comments were provided by Christian Vogt, and
Stephen Kent provided Security Directorate review comments. Eric Stephen Kent provided Security Directorate review comments. Eric
Rescorla provided textual input to the Security Considerations. Rescorla provided textual input to the Security Considerations.
Alexey Melnikov, Robert Sparks, and Magnus Westerlund provided
several review comments as well.
8. Change Log 8. Change Log
8.1. draft-ietf-mmusic-sdp-capability-negotiation-10 8.1. draft-ietf-mmusic-sdp-capability-negotiation-11
Addressing IESG review comments as follows:
o Changed att-cap-num and trpr-cap-num ABNF rules throughout to
allow for no more than 10 digits.
o Disallowed base framework only implementations from generating
media-level attribute capabilities at the session-level, and
added explicit rules for how to process them if received.
o Disallowed attribute capabilities from embedding capability
negotiation parameters and discouraged extension capabilities
from similar behavior. Also specified non-recursive processing of
capabilities on the receive side as a safeguard.
o Clarified that the "tcap" attribute specifies only the transport
protocol, however some MIME types can be viewed as transports as
well. The base framework does not define how to negotiate those
as transports, but rather only as media formats that must be
valid under the transport protocol for the media description.
o Changed definition (and ABNF) for attribute-config-list to allow
for only delete-attributes (i.e., no attribute capabilities)
o Clarified that playout of early media before answer is not a
requirement.
o Clarified various offer/answer aspects related to generation of
potential configuration offer SDP session descriptions and
virtual answer SDP session descriptions as well as operation of
delete-attributes.
o Defined the notion of a "valid" actual configuration and how it
affects offerer processing of the answer.
o Removed recommendation to use the TIAS bandwidth type [RFC3890]
and added note explaining why it should not be used.
o Changed IANA rules for new option tags and potential
configuration parameters to follow "IETF Review" policy, and
clarified that potential configuration parameters must be
registered with IANA.
o Changed numerous instances of "SDP" with the more accurate "SDP
session description" to avoid terminology overload.
o Various editorial clarifications throughout.
8.2. draft-ietf-mmusic-sdp-capability-negotiation-10
Addressing General Area and Security Directorate review comments as Addressing General Area and Security Directorate review comments as
follows: follows:
o Explained and motivated the preference order between potential o Explained and motivated the preference order between potential
and actual configurations earlier in the document. and actual configurations earlier in the document.
o Added DTLS-SRTP example use in several places, as well as a new o Added DTLS-SRTP example use in several places, as well as a new
example call flow for DTLS-SRTP. example call flow for DTLS-SRTP.
skipping to change at page 76, line 5 skipping to change at page 80, line 5
configurations, which do not provide well-defined operation on configurations, which do not provide well-defined operation on
the receiving side, cannot be used in security critical contexts. the receiving side, cannot be used in security critical contexts.
o Updated Security Considerations section. o Updated Security Considerations section.
o Rephrased several sentences containing the word "only" to improve o Rephrased several sentences containing the word "only" to improve
readability. readability.
o Minor editorial nit fixes, especially in the example call flows. o Minor editorial nit fixes, especially in the example call flows.
8.2. draft-ietf-mmusic-sdp-capability-negotiation-09 8.3. 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.3. draft-ietf-mmusic-sdp-capability-negotiation-08 8.4. 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 76, line 41 skipping to change at page 80, 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.4. draft-ietf-mmusic-sdp-capability-negotiation-07 8.5. 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 77, line 21 skipping to change at page 81, 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.5. draft-ietf-mmusic-sdp-capability-negotiation-06 8.6. 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
and/or on a per media description basis; at most one at the and/or on a per media description basis; at most one at the
session-level and per media description now. session-level and per media description now.
o Changed the "a=pcfg" attribute to make a potential configuration o Changed the "a=pcfg" attribute to make a potential configuration
list optional in order to allow for the actual configuration to list optional in order to allow for the actual configuration to
be referenced. be referenced.
o Removed the ability to delete and replace individual attributes o Removed the ability to delete and replace individual attributes
from the actual configuration SDP. from the actual configuration SDP session description.
o Introduced the notion of mandatory and optional attribute o Introduced the notion of mandatory and optional attribute
capabilities in a potential configuration and updated the capabilities in a potential configuration and updated the
"a=pcfg" attribute and associated procedures accordingly. "a=pcfg" attribute and associated procedures accordingly.
o Specified that mandatory attribute capabilities and the transport o Specified that mandatory attribute capabilities and the transport
protocol (if any) from a potential configuration need to be protocol (if any) from a potential configuration need to be
supported in order to select that potential configuration. supported in order to select that potential configuration.
Offer/answer procedures updated accordingly as well. Offer/answer procedures updated accordingly as well.
skipping to change at page 78, line 18 skipping to change at page 82, line 18
possible. possible.
o Fixed error in "a=acfg" grammar (missing config-number) and o Fixed error in "a=acfg" grammar (missing config-number) and
updated attribute definition in accordance with the "a=pcfg" updated attribute definition in accordance with the "a=pcfg"
attribute changes. attribute changes.
o Updated text associated with processing media before answer to o Updated text associated with processing media before answer to
allow for playing out garbage or discard until answer received. allow for playing out garbage or discard until answer received.
Additional detail on alternative solutions provided as well. Additional detail on alternative solutions provided as well.
o Added recommendation to send back answer SDP as soon as possible, o Added recommendation to send back answer SDP session description
when a potential configuration different from the actual as soon as possible, when a potential configuration different
configuration has been chosen. from the actual configuration has been chosen.
o Added new section on interactions with SIP option tags. o Added new section on interactions with SIP option tags.
o Added new section on dealing with large number of potential o Added new section on dealing with large number of potential
configurations. configurations.
o Added new section on SDP capability negotiation and o Added new section on SDP capability negotiation and
intermediaries. intermediaries.
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.6. draft-ietf-mmusic-sdp-capability-negotiation-05 8.7. 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 79, line 19 skipping to change at page 83, line 19
instances at the session-level and multiple instances per media instances at the session-level and multiple instances per media
description (only one for each now) description (only one for each now)
o Changed to not require use of "creq" with base option tag ("cap- o Changed to not require use of "creq" with base option tag ("cap-
v0"). v0").
o Relaxed restrictions on extension capabilities o Relaxed restrictions on extension capabilities
o Updated potential configuration attribute syntax and semantics. o Updated potential configuration attribute syntax and semantics.
In particular, potential configuration attributes can now replace In particular, potential configuration attributes can now replace
and delete various existing attributes in original SDP to better and delete various existing attributes in original SDP session
control potential attribute interactions with the actual descriptions to better control potential attribute interactions
configuration while preserving message size efficiency. with the actual configuration while preserving message size
efficiency.
o Updated actual configuration attribute to align with the updates o Updated actual configuration attribute to align with the updates
to the potential configuration attributes. to the potential configuration attributes.
o Updated offer/answer procedures to align with other changes. o Updated offer/answer procedures to align with other changes.
o Changed recommendation for second offer/answer exchange to "MAY" o Changed recommendation for second offer/answer exchange to "MAY"
strength, unless for the cases where it is known or suspected strength, unless for the cases where it is known or suspected
that it is needed. that it is needed.
skipping to change at page 79, line 45 skipping to change at page 83, line 46
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.7. draft-ietf-mmusic-sdp-capability-negotiation-04 8.8. 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.8. draft-ietf-mmusic-sdp-capability-negotiation-03 8.9. 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.9. draft-ietf-mmusic-sdp-capability-negotiation-02 8.10. 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 81, line 16 skipping to change at page 85, line 18
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.10. draft-ietf-mmusic-sdp-capability-negotiation-01 8.11. 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 82, line 5 skipping to change at page 86, 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.11. draft-ietf-mmusic-sdp-capability-negotiation-00 8.12. 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 84, line 13 skipping to change at page 88, line 13
2003. 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol Norrman, "The Secure Real-time Transport Protocol
(SRTP).", RFC 3711, March 2004. (SRTP).", RFC 3711, March 2004.
[RFC3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. [RFC3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
[RFC3890] M. Westerlund, "A Transport Independent Bandwidth Modifier [RFC3890] M. Westerlund, "A Transport Independent Bandwidth Modifier
for the Session Description Protocol (SDP).", RFC 3890, for the Session Description Protocol (SDP).", RFC 3890,
September 2004. September 2004.
[RFC4145] Yon, D., and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC4474] J. Peterson, and C. Jennings, "Enhancements for [RFC4474] J. Peterson, and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
skipping to change at page 85, line 5 skipping to change at page 89, line 5
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC4756] A. Li, "Forward Error Correction Grouping Semantics in [RFC4756] A. Li, "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, November 2006. Session Description Protocol", RFC 4756, November 2006.
[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.
[RFC5124] Ott, J., and E Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008.
[RFC5751] Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[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, October
2006. 2006.
[DTLS-SRTP] McGrew, D. and E. Rescorla, "Datagram Transport Layer [DTLS-SRTP] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)", draft-ietf-avt-dtls- Real-time Transport Protocol (SRTP)", work in progress,
srtp-07 (work in progress), February 2009. February 2009.
[DTLS-SRTP-FRAMEWORK] Fischl, J., Tschofenig, H., and E. Rescorla, [DTLS-SRTP-FRAMEWORK] Fischl, J., Tschofenig, H., and E. Rescorla,
"Framework for Establishing an SRTP Security Context using "Framework for Establishing an SRTP Security Context using
DTLS", draft-ietf-sip-dtls-srtp-framework-07 (work in DTLS", work in progress, March 2009.
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. October 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,
2007. October 2009.
[SAVPF] Ott, J., and E Carrara, "Extended Secure RTP Profile for [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", (draft-
RTCP-based Feedback (RTP/SAVPF)", Work in Progress, May andreasen-mmusic-sdp-capability-negotiation-01.txt), work
2007. in progress, December 2006.
[SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", work in [SDPMedCap] Gilman, R, Even, R., and F. Andreasen "SDP Media
progress, December 2006. Capabilities Negotiation", work in progress, July 2009.
[SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session [SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session
Description and Capability Negotiation", Work in Progress, Description and Capability Negotiation", Work in Progress,
February 2005. February 2005.
Author's Addresses Author's Address
Flemming Andreasen Flemming Andreasen
Cisco Systems Cisco Systems
Edison, NJ Iselin, NJ 08830
USA
Email: fandreas@cisco.com Email: fandreas@cisco.com
 End of changes. 158 change blocks. 
575 lines changed or deleted 815 lines changed or added

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