draft-ietf-mmusic-sdp-capability-negotiation-03.txt   draft-ietf-mmusic-sdp-capability-negotiation-04.txt 
MMUSIC Working Group F. Andreasen MMUSIC Working Group F. Andreasen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended Status: Proposed Standard February 19, 2007 Intended Status: Proposed Standard February 25, 2007
Expires: August 2007 Expires: August 2007
SDP Capability Negotiation SDP Capability Negotiation
draft-ietf-mmusic-sdp-capability-negotiation-03.txt draft-ietf-mmusic-sdp-capability-negotiation-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 19, 2007. This Internet-Draft will expire on August 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Session Description Protocol (SDP) was intended for describing The Session Description Protocol (SDP) was intended for describing
multimedia sessions for the purposes of session announcement, session multimedia sessions for the purposes of session announcement, session
invitation, and other forms of multimedia session initiation. SDP was invitation, and other forms of multimedia session initiation. SDP was
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions used in this document..............................6 2. Conventions used in this document..............................6
3. SDP Capability Negotiation Solution............................6 3. SDP Capability Negotiation Solution............................6
3.1. Solution Overview.........................................6 3.1. Solution Overview.........................................6
3.2. Version and Extension Indication Attributes...............9 3.2. Version and Extension Indication Attributes...............9
3.2.1. Supported Capability Negotiation Extensions Attribute9 3.2.1. Supported Capability Negotiation Extensions Attribute9
3.2.2. Required Capability Negotiation Extension Attribute.10 3.2.2. Required Capability Negotiation Extension Attribute.10
3.3. Capability Attributes....................................12 3.3. Capability Attributes....................................12
3.3.1. Attribute Capability Attribute......................12 3.3.1. Attribute Capability Attribute......................12
3.3.2. Transport Protocol Capability Attribute.............14 3.3.2. Transport Protocol Capability Attribute.............13
3.3.3. Extension Capability Attributes.....................15 3.3.3. Extension Capability Attributes.....................15
3.4. Configuration Attributes.................................15 3.4. Configuration Attributes.................................15
3.4.1. Potential Configuration Attribute...................15 3.4.1. Potential Configuration Attribute...................15
3.4.2. Actual Configuration Attribute......................19 3.4.2. Actual Configuration Attribute......................19
3.5. Offer/Answer Model Extensions............................20 3.5. Offer/Answer Model Extensions............................20
3.5.1. Generating the Initial Offer........................20 3.5.1. Generating the Initial Offer........................20
3.5.2. Generating the Answer...............................23 3.5.2. Generating the Answer...............................22
3.5.2.1. Example Views of Potential Configurations......26 3.5.2.1. Example Views of Potential Configurations......26
3.5.3. Offerer Processing of the Answer....................28 3.5.3. Offerer Processing of the Answer....................28
3.5.4. Modifying the Session...............................29 3.5.4. Modifying the Session...............................29
3.6. Interactions with ICE....................................29 3.6. Interactions with ICE....................................29
3.7. Processing Media before Answer...........................31 3.7. Processing Media before Answer...........................31
4. Examples......................................................31 3.8. Attribute Capabilities Using rtpmap or fmtp..............31
4.1. Best-Effort Secure RTP...................................31 4. Examples......................................................32
4.2. Multiple Transport Protocols.............................34 4.1. Best-Effort Secure RTP...................................32
4.3. Session-Level MIKEY and Media Level Security Descriptions37 4.2. Multiple Transport Protocols.............................35
4.3. Session-Level MIKEY and Media Level Security Descriptions39
4.4. Capability Negotiation with Interactive Connectivity 4.4. Capability Negotiation with Interactive Connectivity
Establishment.................................................37 Establishment.................................................43
5. Security Considerations.......................................37 5. Security Considerations.......................................43
6. IANA Considerations...........................................39 6. IANA Considerations...........................................45
6.1. New SDP Attributes.......................................39 6.1. New SDP Attributes.......................................45
6.2. New SDP Capability Negotiation Option Tag Registry.......40 6.2. New SDP Capability Negotiation Option Tag Registry.......47
6.3. New SDP Capability Negotiation Potential Configuration 6.3. New SDP Capability Negotiation Potential Configuration
Parameter Registry............................................40 Parameter Registry............................................47
7. To Do and Open Issues.........................................41 7. To Do and Open Issues.........................................47
8. Acknowledgments...............................................41 8. Acknowledgments...............................................47
Change Log......................................................41 9. Change Log....................................................48
9................................................................41 9.1. draft-ietf-mmusic-sdp-capability-negotiation-04..........48
9.1. draft-ietf-mmusic-sdp-capability-negotiation-03..........41 9.2. draft-ietf-mmusic-sdp-capability-negotiation-03..........48
9.2. draft-ietf-mmusic-sdp-capability-negotiation-02..........41 9.3. draft-ietf-mmusic-sdp-capability-negotiation-02..........48
9.3. draft-ietf-mmusic-sdp-capability-negotiation-01..........42 9.4. draft-ietf-mmusic-sdp-capability-negotiation-01..........49
9.4. draft-ietf-mmusic-sdp-capability-negotiation-00..........43 9.5. draft-ietf-mmusic-sdp-capability-negotiation-00..........50
10. References...................................................44 10. References...................................................51
10.1. Normative References....................................44 10.1. Normative References....................................51
10.2. Informative References..................................44 10.2. Informative References..................................51
Author's Addresses...............................................47 Author's Addresses...............................................54
Intellectual Property Statement..................................47 Intellectual Property Statement..................................54
Full Copyright Statement.........................................47 Full Copyright Statement.........................................54
Acknowledgment...................................................48 Acknowledgment...................................................55
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, session multimedia sessions for the purposes of session announcement, session
invitation, and other forms of multimedia session initiation. The SDP invitation, and other forms of multimedia session initiation. The SDP
contains one or more media stream descriptions with information such contains one or more media stream descriptions with information such
as IP-address and port, type of media stream (e.g. audio or video), as IP-address and port, type of media stream (e.g. audio or video),
transport protocol (possibly including profile information, e.g. transport protocol (possibly including profile information, e.g.
RTP/AVP or RTP/SAVP), media formats (e.g. codecs), and various other RTP/AVP or RTP/SAVP), media formats (e.g. codecs), and various other
skipping to change at page 4, line 12 skipping to change at page 4, line 13
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. We here make a distinction between the protocols and codecs. We here 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 be capabilities can be supported and the parameters that can actually be
used for the session. More generally, we can say that we have the 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. stream components, supported by each side.
o A set of potential configurations indicating which of those o A set of potential configurations indicating which combinations of
capabilities can be used for the session and its associated media those capabilities can be used for the session and its associated
stream components. media stream components.
o A set of actual configurations for the session and its associated o An actual configuration for the session and its associated media
media stream components, which specifies which combinations of stream components, which specifies which combinations of session
session parameters and media stream components to use and with parameters and media stream components to use and with what
what parameters. parameters.
o A negotiation process that takes the set of potential o A negotiation process that takes the set of potential
configurations (combinations of capabilities) as input and configurations (combinations of capabilities) as input and
provides the actual configurations as output. provides the actual configurations as output.
SDP by itself was designed to provide only one of these, namely the SDP by itself was designed to provide only one of these, namely the
actual configurations, however over the years, use of SDP has been actual configurations, however over the years, use of SDP has been
extended beyond its original scope. Session negotiation semantics extended beyond its original scope. Session negotiation semantics
were defined by the offer/answer model in RFC 3264. It defines how were defined by the offer/answer model in RFC 3264. It defines how
two entities, an offerer and an answerer, exchange session two entities, an offerer and an answerer, exchange session
skipping to change at page 6, line 22 skipping to change at page 6, line 24
In this section we first provide an overview of the SDP Capability In this section we first provide an overview of the SDP Capability
negotiation solution. This is followed by definitions of new SDP negotiation solution. This is followed by definitions of new SDP
attributes for the solution and its associated updated offer/answer attributes for the solution and its associated updated offer/answer
procedures. procedures.
3.1. Solution Overview 3.1. Solution Overview
The solution consists of the following: The solution consists of the following:
o Two new attributes to support versioning and extensions to the o Two new attributes to support extensions to the framework itself
framework itself as follows: as follows:
o A new attribute ("a=csup") that lists the supported base and o A new attribute ("a=csup") that lists the supported base and
extension options to the framework. extension options to the framework.
o A new attribute ("a=creq") that lists the base and or o A new attribute ("a=creq") that lists the base and or
extensions to the framework that are required to be supported extensions to the framework that are required to be supported
by the entity receiving the SDP in order to do capability by the entity receiving the SDP in order to do capability
negotiation. negotiation.
o Two new attributes used to express capabilities as follows o Two new 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 attribute o A new attribute ("a=acap") that defines how to list an
parameter values ("a=" values) as capabilities. attribute name and its associated value as a capability.
o A new attribute ("a=tcap") that defines how to list transport o A new attribute ("a=tcap") that defines how to list transport
protocols (e.g. "RTP/AVP") as capabilities. protocols (e.g. "RTP/AVP") as capabilities.
o Two new attributes to negotiate configurations as follows: o Two new attributes to negotiate configurations as follows:
o A new attribute ("a=pcfg") that lists the potential o A new attribute ("a=pcfg") that lists the 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. Multiple potential capabilities from the SDP in question. Multiple potential
configurations have an explicitly indicated ordering configurations have an explicitly indicated ordering
associated with them. Extension capabilities can be defined associated with them. Extension capabilities can be defined
and referenced in the potential configurations. and referenced in the potential configurations.
o A new attribute ("a=acfg") to be used in an answer SDP. The o A new attribute ("a=acfg") to be used in an answer SDP. The
attribute identifies which of the potential configurations attribute identifies a potential configuration from an offer
from an offer SDP were used as actual configurations to form SDP which were used as an actual configuration to form the
the answer SDP. Extension capabilities can be included as answer SDP. Extension capabilities can be included as well.
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 or the media Capabilities can be provided at the session level or the media
level. Potential configurations can be included at the media level level. Potential configurations can be included at the media level
only, where they constitute alternative offers that may be only, 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). The answerer indicates which (if included in the "m=" line(s). The answerer indicates which (if
any) of the potential configurations it used to form the answer by any) of the potential configurations it used to form the answer by
including the actual configuration attribute ("a=acfg") in the including the actual configuration attribute ("a=acfg") in the
skipping to change at page 8, line 20 skipping to change at page 8, line 25
the AVP profile ("RTP/SAVP") is supported with an associated the AVP profile ("RTP/SAVP") is supported with an associated
transport capability handle of 1. The "acap" attribute provides an transport capability handle of 1. The "acap" attribute provides an
attribute capability with a handle of 1. The attribute capability is attribute capability with a handle of 1. The attribute capability is
a "crypto" attribute, which provides the keying material for SRTP a "crypto" attribute, which provides the keying material for SRTP
using SDP security descriptions [SDES]. The "a=pcfg" attribute using SDP security descriptions [SDES]. The "a=pcfg" attribute
provides the potential configuration included in the offer by provides the potential configuration included in the offer by
reference to the capability parameters. One alternative is provided; reference to the capability parameters. One alternative is provided;
it has a configuration number of 1 and it consists of transport it has a configuration number of 1 and it consists of transport
protocol capability 1 (i.e. the RTP/SAVP profile - secure RTP), and protocol capability 1 (i.e. the RTP/SAVP profile - secure RTP), and
the attribute capability 1, i.e. the crypto attribute provided. the attribute capability 1, i.e. the crypto attribute provided.
Potential configurations are always preferred over actual Potential configurations are always preferred over the actual
configurations, and hence Alice is expressing a preference for using configuration included in the offer SDP, and hence Alice is
secure RTP. expressing a preference for using secure RTP.
Bob receives the SDP offer from Alice. Bob supports SRTP and the SDP Bob receives the SDP offer from Alice. Bob supports SRTP and the SDP
Capability Negotiation framework, and hence he accepts the Capability Negotiation framework, and hence he accepts the
(preferred) potential configuration for Secure RTP provided by Alice: (preferred) potential configuration for Secure RTP provided by Alice:
v=0 v=0
o=- 24351 621814 IN IP4 128.96.41.2 o=- 24351 621814 IN IP4 128.96.41.2
s= s=
c=IN IP4 128.96.41.2 c=IN IP4 128.96.41.2
t=0 0 t=0 0
m=audio 4567 RTP/SAVP 0 18 m=audio 4568 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 containing the potential that he based his answer on an offer containing the potential
configuration with transport protocol capability 1 and attribute configuration with transport protocol capability 1 and attribute
capability 1 from the offer SDP (i.e. the RTP/SAVP profile using the capability 1 from the offer SDP (i.e. the RTP/SAVP profile using the
keying material provided). Bob also includes his keying material in keying material provided). Bob also includes his keying material in
a crypto attribute. If Bob supported one or more extensions to the a crypto attribute. If Bob supported one or more extensions to the
skipping to change at page 9, line 12 skipping to change at page 9, line 16
capability negotiation extensions defined here, however had he not, capability negotiation extensions defined here, however had he not,
the answerer would simply have ignored the new attributes and the answerer would simply have ignored the new attributes and
accepted the (actual configuration) offer to use normal RTP. In that accepted the (actual configuration) offer to use normal RTP. In that
case, the following answer would have been generated instead: case, the following answer would have been generated instead:
v=0 v=0
o=- 24351 621814 IN IP4 128.96.41.2 o=- 24351 621814 IN IP4 128.96.41.2
s= s=
c=IN IP4 128.96.41.2 c=IN IP4 128.96.41.2
t=0 0 t=0 0
m=audio 4567 RTP/AVP 0 18 m=audio 4568 RTP/AVP 0 18
3.2. Version and Extension Indication Attributes 3.2. Version and Extension Indication Attributes
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.2.1. Supported Capability Negotiation Extensions Attribute 3.2.1. Supported Capability Negotiation Extensions Attribute
The SDP Capability negotiation solution allows for capability The SDP Capability negotiation solution allows for capability
skipping to change at page 10, line 33 skipping to change at page 10, line 36
Whenever an entity that supports one or more extensions to the SDP Whenever an entity that supports one or more extensions to the SDP
Capability Negotiation framework generates an SDP, it SHOULD include Capability Negotiation framework generates an SDP, it SHOULD include
the "a=csup" attribute with the option tags for the extensions it the "a=csup" attribute with the option tags for the extensions it
supports at the session and/or media-level, unless those option tags supports at the session and/or media-level, unless those option tags
are already provided in one or more "a=creq" attribute (see Section are already provided in one or more "a=creq" attribute (see Section
3.2.2. ) at the relevant levels. The base option tag MAY be included. 3.2.2. ) at the relevant levels. The base option tag MAY be included.
3.2.2. Required Capability Negotiation Extension Attribute 3.2.2. Required Capability Negotiation Extension Attribute
The SDP Capability negotiation solution allows for capability
negotiation extensions to be defined. Associated with each such
extension is an option tag that identifies the extension in question.
Option-tags MUST be registered with IANA per the procedures defined
in Section 6.
The Required Capability Negotiation Extensions attribute ("a=creq") The Required Capability Negotiation Extensions attribute ("a=creq")
contains a comma-separated list of option tags identifying the SDP contains a comma-separated list of option tags (see Section 3.2.1. )
Capability negotiation extensions that MUST be supported by the identifying the SDP Capability negotiation extensions that MUST be
entity receiving the SDP in order for that entity to properly process supported by the entity receiving the SDP in order for that entity to
the SDP Capability negotiation. The attribute is defined as follows: properly process the SDP Capability negotiation. The attribute is
defined as follows:
a=creq: <option-tag-list> a=creq: <option-tag-list>
The "creq" attribute adheres to the RFC 4566 "attribute" production, The "creq" attribute adheres to the RFC 4566 "attribute" production,
with an att-value defined as follows: with an att-value defined as follows:
att-value = *WSP option-tag-list att-value = *WSP option-tag-list
where "option-tag-list" is defined in Section 3.2.1. Note that where "option-tag-list" is defined in Section 3.2.1. Note that
white-space is permitted before the option-tag-list. white-space is permitted before the option-tag-list.
skipping to change at page 19, line 19 skipping to change at page 19, line 8
preferred over RTP/SAVP since its capability number (4) is listed preferred over RTP/SAVP since its capability number (4) is listed
first in the preferred potential configuration. The second potential first in the preferred potential configuration. The second potential
configuration indicates that the RTP/AVPF of RTP/AVP profile can be configuration indicates that the RTP/AVPF of RTP/AVP profile can be
used, with RTP/AVPF being the preferred one. This non secure RTP used, with RTP/AVPF being the preferred one. This non secure RTP
alternative is the less preferred one since its configuration number alternative is the less preferred one since its configuration number
is "8". is "8".
3.4.2. Actual Configuration Attribute 3.4.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 were used as actual configurations configurations from an offer SDP were used as an actual configuration
in an answer SDP. This is done by reference to the configuration in an answer SDP. This is done by reference to the configuration
number and the attribute capabilities and transport protocol number and the attribute capabilities and transport protocol
capabilities from the offer that were actually used by the answerer capabilities from the offer that were actually used by the answerer
in his offer/answer procedure. If extension capabilities were used, in his offer/answer procedure. If extension capabilities were used,
those will be included by reference as well. Note that the those will be included by reference as well. Note that the
configuration number and all capability numbers used are those from configuration number and all capability numbers used are those from
the offer; not the answer. the offer; not the answer.
The Actual Configuration Attribute ("a=acfg") is defined as follows: The Actual Configuration Attribute ("a=acfg") is defined as follows:
skipping to change at page 20, line 18 skipping to change at page 20, line 5
actual configuration attribute within a given media description. actual configuration attribute within a given media description.
Below, we provide an example of the "a=acfg" attribute (building on Below, we provide an example of the "a=acfg" attribute (building on
the previous example with the potential configuration attribute): the previous example with the potential configuration attribute):
v=0 v=0
o=- 24351 621814 IN IP4 128.96.41.2 o=- 24351 621814 IN IP4 128.96.41.2
s= s=
c=IN IP4 128.96.41.2 c=IN IP4 128.96.41.2
t=0 0 t=0 0
m=audio 4567 RTP/SAVPF 0 m=audio 4568 RTP/SAVPF 0
a=creq: 0 a=creq: 0
a=acfg:1 t=4 a=1 a=acfg:1 t=4 a=1
It indicates that the answerer used an offer consisting of potential It indicates that the answerer used an offer consisting of potential
configuration number 1 with transport protocol capability 4 from the configuration number 1 with transport protocol capability 4 from the
offer (RTP/SAVPF) and attribute capability 1 (the "crypto" offer (RTP/SAVPF) and attribute capability 1 (the "crypto"
attribute). attribute).
3.5. Offer/Answer Model Extensions 3.5. Offer/Answer Model Extensions
skipping to change at page 22, line 17 skipping to change at page 21, line 46
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.4.1. and the additional rules provided provided in Section 3.4.1. and the additional rules provided
below. below.
The offerer SHOULD furthermore include the following: The offerer SHOULD furthermore include the following:
o One or more supported capability negotiation extension attributes o One or more supported capability negotiation extension attributes
("a=csup") as defined in Section 3.2.2. if the offerer supports ("a=csup") as defined in Section 3.2.2. if the offerer supports
one or more capability negotiation extensions not included in a one or more capability negotiation extensions not included in a
corresponding "a=creq" attribute (i.e. at the session-level or om corresponding "a=creq" attribute (i.e. at the session-level or in
the same media description). Option tags provided in "a=csup" the same media description). Option tags provided in "a=csup"
attributes at the session-level indicate extensions supported for attributes at the session-level indicate extensions supported for
the entire session description whereas option tags provided in the entire session description whereas option tags provided in
"a=csup" attributes in a media description indicate extensions "a=csup" attributes in a media description indicate extensions
supported for that particular media description only. supported for that particular media description only.
Capabilities provided in an offer merely indicate what the offerer is Capabilities provided in an offer merely indicate what the offerer is
capable of doing. They do not constitute a commitment or even an capable of doing. They do not constitute a commitment or even an
indication to actually use them. Each potential configuration however indication to actually use them. Each potential configuration however
constitutes an alternative offer that the offerer would like to use. constitutes an alternative offer that the offerer would like to use.
skipping to change at page 23, line 13 skipping to change at page 22, line 42
actual configuration. actual configuration.
Per [RFC3264], once the offerer generates the offer, he must be Per [RFC3264], once the offerer generates the offer, he must be
prepared to receive incoming media in accordance with that offer. prepared to receive incoming media in accordance with that offer.
That rule applies here as well, but for the actual configurations That rule applies here as well, but for the actual configurations
provided in the offer only: Media received by the offerer according provided in the offer only: Media received by the offerer according
to one of the potential configurations MAY be discarded, until the to one of the potential configurations MAY be discarded, until the
offerer receives an answer indicating what the actual configuration offerer receives an answer indicating what the actual configuration
is. Once that answer is received, incoming media MUST be processed in is. Once that answer is received, incoming media MUST be processed in
accordance with the actual configuration indicated and the answer accordance with the actual configuration indicated and the answer
received (provided the offer/answer exchange completed succesfully). received (provided the offer/answer exchange completed successfully).
3.5.2. Generating the Answer 3.5.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 and containing the option tag "cap-v0". provided at the session level and containing the option tag "cap-v0".
If one is found, then capability negotiation MUST be performed for If one is found, then capability negotiation MUST be performed for
each media description that contains a potential configuration each media description that contains a potential configuration
attribute ("a=pcfg"). If none is found, then the answerer MUST check attribute ("a=pcfg"). If none is found, then the answerer MUST check
each offered media description for a required capability negotiation each offered media description for a required capability negotiation
skipping to change at page 25, line 7 skipping to change at page 24, line 36
configuration. Conceptually, this entails the answerer constructing configuration. Conceptually, this entails the answerer constructing
an (internal) offer that consists of the offer SDP, with the an (internal) offer that consists of the offer SDP, with the
following changes: following changes:
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 in configuration, then it replaces the transport protocol provided in
the "m=" line for that media description. the "m=" line for that media description.
o If a session-level attribute capability is included, then it is o If a session-level attribute capability is included, then it is
added to the list of session-level attributes for the session added to the list of session-level attributes for the session
description. description. The resulting SDP MUST have all such added session-
level attributes listed before the session-level attributes that
were initially present in the SDP. Furthermore, the added session-
level attributes MUST be added in the order they were provided in
the potential configuration.
o If a media-level attribute capability is included, then it is o If a media-level attribute capability is included, then it is
added to the list of media-level attributes for that particular added to the list of media-level attributes for that particular
media description. media description. The resulting SDP MUST have all such added
media-level attributes listed before the media-level attributes
that were initially present in the SDP for that media description.
Furthermore, the added media-level attributes MUST be added in the
order they were provided in the potential configuration
o If a supported extension capability is included, then it is o If a supported extension capability is included, then it is
processed in accordance with the rules provided for that processed in accordance with the rules provided for that
particular extension capability. particular extension capability.
Note that whereas a transport protocol from the potential Note that whereas a transport protocol from the potential
configuration replaces the transport protocol in the actual configuration replaces the transport protocol in the actual
configuration, an attribute capability from the potential configuration, an attribute capability from the potential
configuration is instead added to the actual configuration. In some configuration is instead added to the actual configuration. In some
cases, this may result in having one or more meaningless attributes cases, this may result in having one or more meaningless attributes
from the actual configuration; such meaningless attributes SHOULD from the actual configuration; such meaningless attributes SHOULD
simply be ignored. simply be ignored.
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. Rather than requiring make the "crypto" attribute meaningless. Rather than requiring
the actual configuration attributes to be present as attribute the actual configuration attributes to be present as attribute
capabilities as well (which would increase the message size) and capabilities as well (which would increase the message size) and
then have the potential configuration completely replace the then have the potential configuration completely replace the
actual configuration, we instead make the use of attribute actual configuration, we instead make the use of attribute
capabilities additive to the session description. capabilities additive to the session description. The answerer
may want to note (internally) which attributes came from the
potential configuration and which came from the actual
configuration in order to better resolve such issues.
Please refer to Section 3.5.2.1. for examples of how the answerer may Please refer to Section 3.5.2.1. for examples of how the answerer may
conceptuall "see" the resulting offered alternative potential conceptually "see" the resulting offered alternative potential
configurations. configurations.
If the answerer is not able to support the most preferred valid If the answerer is not able to support the most preferred valid
potential configuration for the media description, the answerer MUST potential configuration for the media description, the answerer MUST
proceed to the second-most preferred valid potential configuration proceed to the second-most preferred valid potential configuration
for the media description, etc. If the answerer is not able to for the media description, etc. If the answerer is not able to
support any of the valid potential configurations, the answerer MUST support any of the valid potential configurations, the answerer MUST
process the offer per normal offer/answer rules, i.e. the actual process the offer per normal offer/answer rules, i.e. the actual
configuration provided will be used as the least preferred configuration provided will be used as the least preferred
alternative. alternative.
skipping to change at page 26, line 24 skipping to change at page 26, line 19
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 particular supports one or more capability negotiation extensions for particular
media descriptions only, then a supported capability negotiation media descriptions only, then a supported capability negotiation
attribute with those option-tags SHOULD be included within each attribute with those option-tags SHOULD be included within each
relevant media description. relevant media description.
The actual configuration is contained in the media description's "m=" The offerer's originally provided actual configuration is contained
line. The answerer can send media to the offerer in accordance with in the media description's "m=" line (and associated parameters). The
the actual configuration as soon as it receives the offer, however it answerer can send media to the offerer in accordance with that actual
MUST NOT do so if it chooses an alternative potential configuration. configuration as soon as it receives the offer, however it MUST NOT
If the answerer chooses one of the potential configurations, then the send media based on that actual configuration if it chooses an
answerer MAY start to send media to the offerer in accordance with alternative potential configuration. If the answerer chooses one of
the selected potential configuration, however the offerer MAY discard the potential configurations, then the answerer MAY start to send
such media until the offerer receives the answer. media to the offerer in accordance with the selected potential
configuration, however the offerer MAY discard such media until the
offerer receives the answer.
3.5.2.1. Example Views of Potential Configurations 3.5.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:
v=0 v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=Secret discussion s=Secret discussion
t=0 0 t=0 0
c=IN IP4 lost.example.com c=IN IP4 lost.example.com
a=tool:foo
a=creq: cap-v0 a=creq: cap-v0
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 39000 RTP/AVP 98 m=audio 39000 RTP/AVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
a=acap:2 a=crypto:1 AES_CM_128_HMAC_SHA1_32 a=acap:2 a=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 42000 RTP/AVP 31 m=video 42000 RTP/AVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
skipping to change at page 27, line 27 skipping to change at page 27, line 25
one the answerer "sees" when using potential configuration 1 for both one the answerer "sees" when using potential configuration 1 for both
audio and video, and furthermore using attribute capability 1 (MIKEY) audio and video, and furthermore using attribute capability 1 (MIKEY)
for both (we have removed all the capability negotiation attributes for both (we have removed all the capability negotiation attributes
for clarity): 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=Secret discussion s=Secret discussion
t=0 0 t=0 0
c=IN IP4 lost.example.com c=IN IP4 lost.example.com
a=tool:foo
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 39000 RTP/SAVP 98 m=audio 39000 RTP/SAVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
m=video 42000 RTP/SAVP 31 m=video 42000 RTP/SAVP 31
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
Note that the transport protocol in the media descriptions indicate Note that the transport protocol in the media descriptions indicate
use of secure RTP. use of secure RTP.
Below, we show the offer the answerer "sees" when using potential Below, we show the offer the answerer "sees" when using potential
configuration 1 for both audio and video and furthermore using configuration 1 for both audio and video and furthermore using
attribute capability 2 and 3 respectively (SDP security descriptions) attribute capability 2 and 3 respectively (SDP security descriptions)
for the audio and media stream: for the audio and media stream - note the order in which the
resulting attributes are provided:
v=0 v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=Secret discussion s=Secret discussion
t=0 0 t=0 0
c=IN IP4 lost.example.com c=IN IP4 lost.example.com
a=tool:foo
m=audio 39000 RTP/SAVP 98 m=audio 39000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32 a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=video 42000 RTP/SAVP 31 a=rtpmap:98 AMR/8000
a=rtpmap:31 H261/90000 m=video 42000 RTP/SAVP 31 a=crypto:1 AES_CM_128_HMAC_SHA1_80
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtpmap:31 H261/90000
Again, note that the transport protocol in the media descriptions Again, note that the transport protocol in the media descriptions
indicate use of secure RTP. indicate use of secure RTP.
And finally, we show the offer the answerer "sees" when using And finally, we show the offer the answerer "sees" when using
potential configuration 1 with attribute capability 1 (MIKEY) for the potential configuration 1 with attribute capability 1 (MIKEY) for the
audio stream, and potential configuration 1 with attribute capability audio stream, and potential configuration 1 with attribute capability
3 (SDP security descriptions) for the video stream: 3 (SDP security descriptions) for the video stream:
v=0 v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=Secret discussion s=Secret discussion
t=0 0 t=0 0
c=IN IP4 lost.example.com c=IN IP4 lost.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tool:foo
m=audio 39000 RTP/SAVP 98 m=audio 39000 RTP/SAVP 98
a=rtpmap:98 AMR/8000 a=rtpmap:98 AMR/8000
m=video 42000 RTP/SAVP 31 m=video 42000 RTP/SAVP 31 a=crypto:1 AES_CM_128_HMAC_SHA1_80
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtpmap:31 H261/90000
3.5.3. Offerer Processing of the Answer 3.5.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 offer, the offerer MUST examine the answer for actual use of
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, the offerer MUST first examine the media configuration attribute, the offerer MUST first examine the media
description for the presence of an actual configuration attribute description for the presence of an actual configuration attribute
skipping to change at page 29, line 18 skipping to change at page 29, line 18
configuration offered, i.e. the attribute capabilities ("a=acap"), configuration offered, i.e. the attribute capabilities ("a=acap"),
transport protocol capabilities ("a=tcap"), and any extension transport protocol capabilities ("a=tcap"), and any extension
capability parameters included. capability parameters included.
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
had contained the potential configuration as the actual had contained the potential configuration as the actual
configuration in the media description ("m=" line) and relevant configuration in the media description ("m=" line) and relevant
attributes in the offer. attributes in the offer.
If the offer/answer exchange was succesful, 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, then the offerer SHOULD perform another actual configuration, then the offerer SHOULD perform another
offer/answer exchange: The new offer should contain the selected offer/answer exchange: The new offer should contain the selected
potential configuration as the actual configuration, i.e. with the potential configuration as the actual configuration, i.e. with the
actual configuration used in the "m=" line and any other relevant actual configuration used in the "m=" line and any other relevant
attributes. This second offer/answer exchange will not modify the attributes. This second offer/answer exchange will not modify the
session in any way, however it will help intermediaries that look at session in any way, however it will help intermediaries that look at
the SDP, but do not understand or support the capability negotiation the SDP, but do not understand or support the capability negotiation
extensions, to understand the details of the media stream(s) that extensions, to understand the details of the media stream(s) that
were actually negotiated. were actually negotiated.
skipping to change at page 30, line 16 skipping to change at page 30, line 16
used. used.
When using ICE, it is thus possible that the transport protocol that When using ICE, it is thus possible that the transport protocol that
will be used differs from what is specified in the "m=" line. will be used differs from what is specified in the "m=" line.
Furthermore, since both ICE and SDP Capability Negotiation may now Furthermore, since both ICE and SDP Capability Negotiation may now
specify alternative transport protocols, there is a potentially specify alternative transport protocols, there is a potentially
unintended interaction when using these together. unintended interaction when using these together.
We provide the following guidelines for addressing that. We provide the following guidelines for addressing that.
[EDITOR'S NOTE: This requires more work]
There are two basic scenarios to consider here: There are two basic scenarios to consider here:
1) A particular media stream can run over different transport 1) A particular media stream can run over different transport
protocols (e.g. UDP, TCP, or TCP/TLS), and the intent is simply to protocols (e.g. UDP, TCP, or TCP/TLS), and the intent is simply to
use the one that works (in the preference order specified). use the one that works (in the preference order specified).
2) A particular media stream can run over different transport 2) A particular media stream can run over different transport
protocols (e.g. UDP, TCP, or TCP/TLS) and the intent is to have the protocols (e.g. UDP, TCP, or TCP/TLS) and the intent is to have the
negotiation process decide which one to use (e.g. T.38 over TCP or negotiation process decide which one to use (e.g. T.38 over TCP or
UDP). UDP).
skipping to change at page 31, line 5 skipping to change at page 31, line 5
configuration alternatives where some of them can support one configuration alternatives where some of them can support one
transport protocol only (e.g. UDP), whereas others can support transport protocol only (e.g. UDP), whereas others can support
multiple transport protocols (e.g. UDP or TCP). In that case, the ICE multiple transport protocols (e.g. UDP or TCP). In that case, the ICE
candidate attributes should be defined as attribute capabilities and candidate attributes should be defined as attribute capabilities and
the relevant ones should then be included in the proper potential the relevant ones should then be included in the proper potential
configurations (for example candidate attributes for UDP only for configurations (for example candidate attributes for UDP only for
potential configurations that are restricted to UDP, whereas there potential configurations that are restricted to UDP, whereas there
could be candidate attributes for UDP, TCP, and TCP/TLS for potential could be candidate attributes for UDP, TCP, and TCP/TLS for potential
configurations that can use all three). configurations that can use all three).
[EDITOR'S NOTE: Not clear this is sufficient. It seems ICE is
essentially providing potential transport configurations when it
comes to use of UDP, TCP, or TLS as transport protocols. If that is
the case, then we will have a hard time expressing constraints on
some transport protocols in a potential configuration, but not the
actual configuration, at least with the current additive attribute
capability rules.]
3.7. Processing Media before Answer 3.7. Processing Media before Answer
The offer/answer model requires an offerer to be able to receive The offer/answer model requires an offerer to be able to receive
media in accordance with the offer prior to receiving the answer. media in accordance with the offer prior to receiving the answer.
This property is retained with the SDP capability negotiation This property is retained with the SDP capability negotiation
extensions defined here, but only when the actual configuration is extensions defined here, but only when the actual configuration is
selected by the answerer. If a potential configuration is chosen, it selected by the answerer. If a potential configuration is chosen, it
is permissible for the offerer to not process any media received is permissible for the offerer to not process any media received
before the answer is received. This however may lead to clipping. before the answer is received. This however may lead to clipping.
skipping to change at page 31, line 29 skipping to change at page 31, line 37
offer/answer exchange. An alternative is therefore desirable. offer/answer exchange. An alternative is therefore desirable.
The SDP capability negotiation framework does not define such an The SDP capability negotiation framework does not define such an
alternative, however extensions may do so. For example, one technique alternative, however extensions may do so. For example, one technique
proposed for best-effort SRTP in [BESRTP] is to provide different RTP proposed for best-effort SRTP in [BESRTP] is to provide different RTP
payload type mappings for different transport protocols used. The payload type mappings for different transport protocols used. The
basic SDP capability negotiation framework defined here does not basic SDP capability negotiation framework defined here does not
include the ability to do so, however extensions that enable that may include the ability to do so, however extensions that enable that may
be defined. be defined.
3.8. Attribute Capabilities Using rtpmap or fmtp
The core SDP Capability Negotiation framework defines transport
capabilities and attribute capabilities. Media capabilities, which
can be used to describe media formats and their associated
parameters, are not defined in this document, however the "rtpmap"
and "fmtp" attributes can nevertheless be used as attribute
capabilities. Using such attribute capabilities in a potential
configuration requires a bit of care though.
The rtpmap parameter binds an RTP payload type to a media format
(codec). While it is possible to provide rtpmaps for payload types
not found in the corresponding "m=" line, such rtpmaps provide no
value in normal offer/answer exchanges, since only the payload types
found in the "m=" line is part of the offer (or answer). This applies
to the core SDP capability negotiation framework as well: Only the
media formats (e.g. RTP payload types) provided in the "m=" line are
actually offered; inclusion of rtpmap attributes with other RTP
payload types in a potential configuration does not change this fact
and hence they do not provide any useful information. They may still
be useful as pure capabilities though (outside a potential
configuration).
It is possible to provide an rtpmap attribute capability with a
payload type mapping to a different codec than a corresponding actual
configuration "rtpmap" attribute for the media description has. Such
practice is permissible as a way of indicating a capability, however,
if that capability is included in a potential configuration, the core
SDP capability negotiation framework does not provide a well-defined
outcome. Recall that attribute capabilities are additive to the media
description, and hence the result will be two different payload type
mappings for a single RTP payload type. This is not allowed by SDP
[RFC4566].
Similar considerations and rules apply to the "fmtp" attribute. An
fmtp attribute capability for a media format not included in the "m="
line is useless in a potential configuration. An fmtp attribute
capability in a potential configuration for a media format that
already has an fmtp attribute in the actual configuration may lead to
multiple fmtp format parameters for that media format. This is not
allowed by SDP [RFC4566]. Still, use of it as a capability only may
be useful.
Extensions to the core SDP capability negotiation framework of course
may change the above behavior.
4. Examples 4. Examples
In this section, we provide examples showing how to use the SDP In this section, we provide examples showing how to use the SDP
Capability Negotiation. Capability Negotiation.
4.1. Best-Effort Secure RTP 4.1. Best-Effort Secure RTP
The following example illustrates how to use the SDP Capability The following example illustrates how to use the SDP Capability
negotiation extensions to support so-called Best-Effort Secure RTP. negotiation extensions to support so-called Best-Effort Secure RTP.
In that scenario, the offerer supports both RTP and Secure RTP. If In that scenario, the offerer supports both RTP and Secure RTP. If
skipping to change at page 32, line 42 skipping to change at page 33, line 45
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP FEC_ORDER=FEC_SRTP
a=pcfg:1 t=1 a=1 a=pcfg:1 t=1 a=1
The "m=" line indicates that Alice is offering to use plain RTP with The "m=" line indicates that Alice is offering to use plain RTP with
PCMU or G.729. Alice indicates that support for the base protocol PCMU or G.729. Alice indicates that support for the base protocol
defined here is required by including the "a=creq" attribute defined here is required by including the "a=creq" attribute
containing the value "cap-v0". The capabilities are provided by the containing the value "cap-v0". The capabilities are provided by the
"a=tcap" and "a=acap" attributes. The "tcap" capability indicates "a=tcap" and "a=acap" attributes. The "tcap" capability indicates
that both Secure RTP and normal RTP are supported. The "acap" that both Secure RTP and normal RTP are supported. The "acap"
attribute provides a capability parameter with a handle of 1. The attribute provides an attribute capability with a handle of 1. The
capability parameter is a "crypto" attribute, which provides the capability is a "crypto" attribute, which provides the keying
keying material for SRTP using SDP security descriptions [SDES]. The material for SRTP using SDP security descriptions [SDES]. The
"a=pcfg" attribute provides the potential configurations included in "a=pcfg" attribute provides the potential configurations included in
the offer by reference to the capabilities. A single potential the offer by reference to the capabilities. A single potential
configuration with a configuration number of "1" is provided. It configuration with a configuration number of "1" is provided. It
includes is transport protocol capability 1 (RTP/SAVP, i.e. secure includes is transport protocol capability 1 (RTP/SAVP, i.e. secure
RTP) together with the attribute capability 1, i.e. the crypto RTP) together with the attribute capability 1, i.e. the crypto
attribute provided. attribute provided.
Bob receives the SDP offer from Alice. Bob supports SRTP and the SDP Bob receives the SDP offer from Alice. Bob supports SRTP and the SDP
Capability Negotiation extensions, and hence he accepts the potential Capability Negotiation extensions, and hence he accepts the potential
configuration for Secure RTP provided by Alice: configuration for Secure RTP provided by Alice:
v=0 v=0
o=- 24351 621814 IN IP4 128.96.41.2 o=- 24351 621814 IN IP4 128.96.41.2
s= s=
c=IN IP4 128.96.41.2 c=IN IP4 128.96.41.2
t=0 0 t=0 0
m=audio 4567 RTP/SAVP 0 18 m=audio 4568 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 containing the potential that he based his answer on an offer containing the potential
configuration with transport protocol capability 1 and attribute configuration with transport protocol capability 1 and attribute
capability 1 from the offer SDP (i.e. the RTP/SAVP profile using the capability 1 from the offer SDP (i.e. the RTP/SAVP profile using the
keying material provided). Bob also includes his keying material in keying material provided). Bob also includes his keying material in
a crypto attribute. a crypto attribute.
skipping to change at page 34, line 13 skipping to change at page 35, line 16
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 offer from Alice, which he accepts, and then
generates an answer to Alice: generates an answer to Alice:
v=0 v=0
o=- 24351 621815 IN IP4 128.96.41.2 o=- 24351 621815 IN IP4 128.96.41.2
s= s=
c=IN IP4 128.96.41.2 c=IN IP4 128.96.41.2
t=0 0 t=0 0
m=audio 4567 RTP/SAVP 0 18 m=audio 4568 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
Bob includes the same crypto attribute as before, and the session Bob includes the same crypto attribute as before, and the session
proceeds without change. Although Bob did not include any proceeds without change. Although Bob did not include any
capabilities in his answer, he could of course have done so if he capabilities in his answer, he could of course have done so if he
wanted to. wanted to.
Note that in this particular example, the answerer supported the Note that in this particular example, the answerer supported the
capability extensions defined here, however had he not, the answerer capability extensions defined here, however had he not, the answerer
would simply have ignored the new attributes received in step 1 and would simply have ignored the new attributes received in step 1 and
accepted the offer to use normal RTP. In that case, the following accepted the offer to use normal RTP. In that case, the following
answer would have been generated in step 2 instead: answer would have been generated in step 2 instead:
v=0 v=0
o=- 24351 621814 IN IP4 128.96.41.2 o=- 24351 621814 IN IP4 128.96.41.2
s= s=
c=IN IP4 128.96.41.2 c=IN IP4 128.96.41.2
t=0 0 t=0 0
m=audio 4567 RTP/AVP 0 18 m=audio 4568 RTP/AVP 0 18
4.2. Multiple Transport Protocols 4.2. Multiple Transport Protocols
[EDITOR'S NOTE: Example to be updated - old copy below]
The following example illustrates how to use the SDP Capability The following example illustrates how to use the SDP Capability
negotiation extensions to support so-called Best-Effort Secure RTP. negotiation extensions to negotiate use of one out of several
In that scenario, the offerer supports both RTP and Secure RTP. If possible transport protocols. As in the previous example, the offerer
the answerer does not support secure RTP (or the SDP capability uses the expected least-common-denominator (plain RTP) as the actual
negotiation extensions), an RTP session will be established. However, configuration, and the alternative transport protocols as the
if the answerer supports Secure RTP and the SDP Capability potential configurations.
Negotiation extensions, a Secure RTP session will be established.
The best-effort Secure RTP negotiation is illustrated by the The example is illustrated by the offer/answer exchange below, where
offer/answer exchange below, where Alice sends an offer to Bob: Alice sends an offer to Bob:
Alice Bob Alice Bob
| (1) Offer (SRTP and RTP) | | (1) Offer (RTP/[S]AVP[F]) |
|--------------------------------->| |--------------------------------->|
| | | |
| (2) Answer (SRTP) | | (2) Answer (RTP/AVPF) |
|<---------------------------------| |<---------------------------------|
| | | |
| (3) Offer (SRTP) | | (3) Offer (RTP/AVPF) |
|--------------------------------->| |--------------------------------->|
| | | |
| (4) Answer (SRTP) | | (4) Answer (RTP/AVPF) |
|<---------------------------------| |<---------------------------------|
Alice's offer includes RTP and SRTP as alternatives. RTP is the | |
default, but SRTP is the preferred one:
Alice's offer includes plain RTP (RTP/AVP), RTP with RTCP-based
feedback (RTP/AVPF), Secure RTP (RTP/SAVP), and Secure RTP with RTCP-
based feedback (RTP/SAVPF) and SRTP as alternatives. RTP is the
default, with RTP/SAVPF, RTP/SAVP, and RTP/AVPF as the alternatives
and preferred in the order listed:
v=0 v=0
o=- 25678 753849 IN IP4 128.96.41.1 o=- 25678 753849 IN IP4 128.96.41.1
s= s=
c=IN IP4 128.96.41.1 c=IN IP4 128.96.41.1
t=0 0 t=0 0
m=audio 3456 RTP/AVP 0 18 m=audio 3456 RTP/AVP 0 18
a=creq: cap-v0 a=creq: cap-v0
a=tcap:1 RTP/SAVP RTP/AVP a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=acap:1 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP FEC_ORDER=FEC_SRTP
a=pcfg:5 t=1 a=1 a=acap:2 a=rtcp-fb:0 nack
a=pcfg:10 t=2 a=pcfg:1 t=1 a=1,2
a=pcfg:2 t=2 a=1
a=pcfg:3 t=3 a=2
The "m=" line indicates that Alice is offering to use plain RTP with The "m=" line indicates that Alice is offering to use plain RTP with
PCMU or G.729. Alice indicates that support for the base protocol PCMU or G.729. Alice indicates that support for the base protocol
defined here is required by including the "a=creq" attribute defined here is required by including the "a=creq" attribute
containing the value "cap-v0". The capabilities are provided by the containing the value "cap-v0". The capabilities are provided by the
"a=tcap" and "a=acap" attributes. The capabilities indicate that "a=tcap" and "a=acap" attributes. The "tcap" capability indicates
both Secure RTP and normal RTP are supported. The "acap" attribute that Secure RTP with RTCP-Based feedback (RTP/SAVPF), Secure RTP
provides a capability parameter with a handle of 1. The capability (RTP/SAVP), and RTP with RTCP-Based feedback are supported. The first
parameter is a "crypto" attribute in the capability set, which "acap" attribute provides an attribute capability with a handle of 1.
provides the keying material for SRTP using SDP security descriptions The capability is a "crypto" attribute, which provides the keying
[SDES]. The "a=pcfg" attribute provides the potential configurations material for SRTP using SDP security descriptions [SDES]. The second
included in the offer by reference to the capabilities. Two "acap" attribute provides an attribute capability with a handle of 2.
alternatives are provided; the first one with preference "5" (and The capability is an "rtcp-fb" attribute, which is used by the RTCP-
hence the preferred one since the preference on the second one is based feedback profiles to indicate that payload type 0 (PCMU)
"10") is transport protocol capability 1 (RTP/SAVP, i.e. secure RTP) supports feedback type "nack". The "a=pcfg" attributes provide the
together with the attribute capability 1, i.e. the crypto attribute potential configurations included in the offer by reference to the
provided. The second one is using transport protocol capability 2. capabilities. There are three potential configurations:
Note that we could have omitted the second potential configuration
since it equals the actual configuration (which is always the least
preferred configuration).
Bob receives the SDP offer from Alice. Bob supports SRTP and the SDP o Potential configuration 1, which is the most preferred potential
Capability Negotiation extensions, and hence he accepts the potential configuration specifies use of transport protocol capability 1
configuration for Secure RTP provided by Alice: (RTP/SAVPF) and attribute capabilities 1 (the "crypto" attribute)
and 2 (the "rtcp-fb" attribute).
o Potential configuration 2, which is the second most preferred
potential configuration specifies use of transport protocol
capability 2 (RTP/SAVP) and attribute capability 1 (the "crypto"
attribute).
o Potential configuration 3, which is the least preferred potential
configuration (but the second least preferred configuration
overall, since the actual configuration provided by the "m=" line
is always the least preferred configuration), specifies use of
transport protocol capability 3 (RTP/AVPF) and attribute
capability 2 (the "rtcp-fb" attribute).
Bob receives the SDP offer from Alice. Bob does not support any
secure RTP profiles, however he supports plain RTP and RTP with RTCP-
based feedback, as well as the SDP Capability Negotiation extensions,
and hence he accepts the potential configuration for RTP with RTCP-
based feedback provided by Alice:
v=0 v=0
o=- 24351 621814 IN IP4 128.96.41.2 o=- 24351 621814 IN IP4 128.96.41.2
s= s=
c=IN IP4 128.96.41.2 c=IN IP4 128.96.41.2
t=0 0 t=0 0
m=audio 4567 RTP/SAVP 0 18 m=audio 4568 RTP/AVPF 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=rtcp-fb:0 nack
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 a=acfg:1 t=3 a=2
a=csup: foo
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 containing the potential that he based his answer on an offer containing the potential
configuration with transport protocol capability 1 and attribute configuration with transport protocol capability 3 and attribute
capability 1 from the offer SDP (i.e. the RTP/SAVP profile using the capability 2 from the offer SDP (i.e. the RTP/AVPF profile using the
keying material provided). Bob also includes his keying material in "rtcp-fb" value provided). Bob also includes an "rtcp-fb" attribute
a crypto attribute. Finally, Bob supports an SDP capability with the value "nack" value for RTP payload type 0.
negotiation extension with the option tag "foo" and hence he includes
the "a=csup" parameter containing value "foo" in the answer. When Alice receives Bob's answer, session negotiation has completed,
however Alice nevertheless generates a new offer using the actual
configuration. This is done purely to assist any middle-boxes that
may reside between Alice and Bob but do not support the capability
negotiation extensions (and hence may not understand the negotiation
that just took place):
Alice's updated offer includes only RTP/AVPF, and it is not using the
SDP capability negotiation extensions (Alice could have included the
capabilities as well is she wanted to):
v=0
o=- 25678 753850 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVPF 0 18
a=rtcp-fb:0 nack
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" attribute
provides the feedback type "nack" for payload type 0 again (but as
part of the actual configuration).
Bob receives the SDP offer from Alice, which he accepts, and then
generates an answer to Alice:
v=0
o=- 24351 621815 IN IP4 128.96.41.2
s=
c=IN IP4 128.96.41.2
t=0 0
m=audio 4568 RTP/AVPF 0 18
a=rtcp-fb:0 nack
Bob includes the same "rtcp-fb" attribute as before, and the session
proceeds without change. Although Bob did not include any
capabilities in his answer, he could of course have done so if he
wanted to.
Note that in this particular example, the answerer supported the Note that in this particular example, the answerer supported the
capability extensions defined here, however had he not, the answerer capability extensions defined here, however had he not, the answerer
would simply have ignored the new attributes and accepted the offer would simply have ignored the new attributes received in step 1 and
to use normal RTP. In that case, the following answer would have been accepted the offer to use normal RTP. In that case, the following
generated instead: answer would have been generated in step 2 instead:
v=0 v=0
o=- 24351 621814 IN IP4 128.96.41.2 o=- 24351 621814 IN IP4 128.96.41.2
s= s=
c=IN IP4 128.96.41.2 c=IN IP4 128.96.41.2
t=0 0 t=0 0
m=audio 4567 RTP/AVP 0 18 m=audio 4568 RTP/AVP 0 18
4.3. Session-Level MIKEY and Media Level Security Descriptions 4.3. Session-Level MIKEY and Media Level Security Descriptions
[EDITOR'S NOTE: Example to be added] The following example illustrates how to use the SDP Capability
negotiation extensions to support so-called Best-Effort Secure RTP as
well as alternative keying mechanisms, more specifically MIKEY and
SDP Security Descriptions. The offerer (Alice) wants to establish an
audio and video session. Alice prefers to use session-level MIKEY as
the key management protocol, but supports SDP security descriptions
as well.
The example is illustrated by the offer/answer exchange below, where
Alice sends an offer to Bob:
Alice Bob
| (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) |
|--------------------------------------->|
| |
| (2) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |
| (3) Offer (RTP/SAVP, SDES) |
|--------------------------------------->|
| |
| (4) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |
Alice's offer includes an audio and a video stream. The audio stream
offers use of plain RTP and secure RTP as alternatives, whereas the
video stream offers use plain RTP, RTP with RTCP-based feedback,
Secure RTP, and Secure RTP with RTCP-based feedback as alternatives:
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
t=0 0
c=IN IP4 128.96.41.1
a=creq: cap-v0
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
m=audio 39000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:2 a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=2 a=1|2
m=video 42000 RTP/AVP 31
a=rtpmap:31 H261/90000
a=acap:3 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=acap:4 a=rtcp-fb:* nack
a=pcfg:1 t=1 a=1,4|3,4
a=pcfg:2 t=2 a=1|3
a=pcfg:3 t=3 a=4
The potential configuration for the audio stream specifies use of
transport capability 2 (RTP/SAVP) and either attribute capability 1
(session-level MIKEY as the keying mechanism) or 2 (SDP Security
Descriptions as the keying mechanism). There are three potential
configurations for the video stream.
o The first configuration with configuration number 1 uses transport
capability 1 (RTP/SAVPF) with either attribute capabilities 1 and
4 (session-level MIKEY and the "rtcp-fb" attribute) or attribute
capabilities 3 and 4 (SDP security descriptions and the "rtcp-fb"
attribute).
o The second configuration with configuration number 2 uses
transport capability 2 (RTP/SAVP) and either attribute capability
1 (session-level MIKEY) or attribute capability 3 (SDP security
descriptions).
o The third configuration with configuration number 3 uses transport
capability 3 (RTP/AVPF) and attribute capability 4 (the "rtcp-fb"
attribute).
Bob receives the SDP offer from Alice. Bob supports Secure RTP,
Secure RTP with RTCP-based feedback and the SDP Capability
Negotiation extensions. Bob also supports SDP Security Descriptions,
but not MIKEY, and hence he generates the following answer:
v=0
o=- 24351 621814 IN IP4 128.96.41.2
s=
t=0 0
c=IN IP4 128.96.41.2
m=audio 4568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:1 t=2 a=2
m=video 5468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=rtcp-fb:* nack
a=acfg:1 t=1 a=3,4
For the audio stream, Bob accepted the use of secure RTP, and hence
the profile in the "m=" line is "RTP/SAVP". Bob also includes a
"crypto" attribute with his own keying material, and an "acfg"
attribute identifying actual configuration 1 for the audio media
stream from the offer, using transport capability 2 (RTP/SAVP) and
attribute capability 2 (the crypto attribute from the offer). For the
video stream, Bob accepted the use of secure RTP with RTCP-based
feedback, and hence the profile in the "m=" line is "RTP/SAVPF". Bob
also includes a "crypto" attribute with his own keying material, and
an "acfg" attribute identifying actual configuration 1 for the video
stream from the offer, using transport capability 1 (RTP/SAVPF) and
attribute capabilities 3 (the crypto attribute from the offer) and 4
(the "rtcp-fb" attribute from the offer).
When Alice receives Bob's answer, session negotiation has completed,
however Alice nevertheless generates a new offer using the actual
configuration. This is done purely to assist any middle-boxes that
may reside between Alice and Bob but do not support the capability
negotiation extensions (and hence may not understand the negotiation
that just took place):
Alice's updated offer includes only SRTP for the audio stream SRTP
with RTCP-based feedback for the video stream, and it is not using
the SDP capability negotiation extensions (Alice could have included
the capabilities as well is she wanted to):
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
t=0 0
c=IN IP4 128.96.41.1
m=audio 39000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=video 42000 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtcp-fb:* nack
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
for the video stream now indicates that Alice is offering to use
secure RTP with RTCP-based feedback with H.261. Each media stream
includes a "crypto" attribute, which provides the SRTP keying
material, with the same value again.
Bob receives the SDP offer from Alice, which he accepts, and then
generates an answer to Alice:
v=0
o=- 24351 621814 IN IP4 128.96.41.2
s=
t=0 0
c=IN IP4 128.96.41.2
m=audio 4568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
m=video 5468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=rtcp-fb:* nack
Bob includes the same crypto attribute as before, and the session
proceeds without change. Although Bob did not include any
capabilities in his answer, he could of course have done so if he
wanted to.
Note that in this particular example, the answerer supported the
capability extensions defined here, however had he not, the answerer
would simply have ignored the new attributes received in step 1 and
accepted the offer to use normal RTP. In that case, the following
answer would have been generated in step 2 instead:
v=0
o=- 24351 621814 IN IP4 128.96.41.2
s=
t=0 0
c=IN IP4 128.96.41.2
m=audio 4568 RTP/AVP 98
a=rtpmap:98 AMR/8000
m=video 5468 RTP/AVP 31
a=rtpmap:31 H261/90000
a=rtcp-fb:* nack
Finally, if Bob had chosen to use session-level MIKEY instead of SDP
security descriptions instead, the following answer would have been
generated:
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
t=0 0
c=IN IP4 128.96.41.1
a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyO...
m=audio 39000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=2 a=1
m=video 42000 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=rtcp-fb:* nack
a=acfg:1 t=1 a=1,4
It should be noted, that although Bob could have chosen session-level
MIKEY for one media stream, and SDP Security Descriptions for another
media stream, there are no well-defined offerer processing rules of
the resulting answer for this, and hence the offerer may incorrectly
assume use of MIKEY for both streams. To avoid this, if the answerer
chooses session-level MIKEY, then all secure RTP based media streams
SHOULD use MIKEY (this applies irrespective of whether SDP capability
negotiation is being used or not). Use of media-level MIKEY does not
have a similar constraint.
4.4. Capability Negotiation with Interactive Connectivity Establishment 4.4. Capability Negotiation with Interactive Connectivity Establishment
[EDITOR'S NOTE: Example to be added] [EDITOR'S NOTE: Example to be added]
5. Security Considerations 5. Security Considerations
The SDP Capability Negotiation Framework is defined to be used within The SDP Capability Negotiation Framework is defined to be used within
the context of the offer/answer model, and hence all the offer/answer the context of the offer/answer model, and hence all the offer/answer
security considerations apply here as well. Similarly, the Session security considerations apply here as well. Similarly, the Session
skipping to change at page 41, line 21 skipping to change at page 48, line 4
7. To Do and Open Issues 7. To Do and Open Issues
o Look for "EDITOR'S NOTE" throughout the document. o Look for "EDITOR'S NOTE" throughout the document.
8. Acknowledgments 8. Acknowledgments
This document is heavily influenced by the discussions and work done This document is heavily influenced by the discussions and work done
by the SDP Capability Negotiation Design team. The following people by the SDP Capability Negotiation Design team. The following people
in particular provided useful comments and suggestions to either the in 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: Roni Even, Robert Gilman, Cullen Jennings, Matt Lepinski, Joerg here: Francois Audet, John Elwell, Roni Even, Robert Gilman, Cullen
Ott, Colin Perkins, and Thomas Stach. Jennings, Matt Lepinski, Joerg Ott, Colin Perkins, Thomas Stach, and
Dan Wing.
Francois Audet and Dan Wing provided useful comments on earlier
versions of this document.
9. Change Log 9. Change Log
9.1. draft-ietf-mmusic-sdp-capability-negotiation-03 9.1. draft-ietf-mmusic-sdp-capability-negotiation-04
The following are the major changes compared to version -03:
o Added explicit ordering rules for attributes added by potential
configurations.
o Noted that ICE interaction issues (ice-tcp specifically) may not
be as clear as originally thought.
o Added considerations on using rtpmap and fmtp attributes as
attribute capabilities.
o Added multiple transport protocol example.
o Added session-level MIKEY and media level security descriptions
example.
9.2. 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
9.2. draft-ietf-mmusic-sdp-capability-negotiation-02 9.3. 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
configuration number) in potential configuration attributes; must configuration number) in potential configuration attributes; must
now be unique and can be used as a handle now be unique and can be used as a handle
o Actual configuration attribute now includes configuration number o Actual configuration attribute now includes configuration number
from the selected potential configuration attribute from the selected potential configuration attribute
o Added ABNF throughout o Added ABNF throughout
o Specified that answerer should include "a=csup" in case of o Specified that answerer should include "a=csup" in case of
skipping to change at page 42, line 30 skipping to change at page 49, line 27
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
9.3. draft-ietf-mmusic-sdp-capability-negotiation-01 9.4. 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 43, line 16 skipping to change at page 50, line 13
configuration attributes. configuration attributes.
o Potential configurations at the session level now limited to o Potential configurations at the session level now limited to
indicate latent capability configurations. Consequently, an actual indicate latent capability configurations. Consequently, an actual
configuration attribute can no longer be provided at the session configuration attribute can no longer be provided at the session
level. 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.
9.4. draft-ietf-mmusic-sdp-capability-negotiation-00 9.5. 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 similar o Solution no longer based on RFC 3407, but defines a set of similar
attributes (with some differences). attributes (with some differences).
o Various minor changes to the previously defined attributes. o Various minor changes to the previously defined attributes.
 End of changes. 69 change blocks. 
157 lines changed or deleted 501 lines changed or added

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