draft-ietf-mmusic-sdp-capability-negotiation-12.txt   draft-ietf-mmusic-sdp-capability-negotiation-13.txt 
MMUSIC Working Group F. Andreasen MMUSIC Working Group F. Andreasen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended Status: Proposed Standard February 28, 2010 Intended Status: Proposed Standard March 24, 2010
Expires: August 2010 Expires: September 2010
SDP Capability Negotiation SDP Capability Negotiation
draft-ietf-mmusic-sdp-capability-negotiation-12.txt draft-ietf-mmusic-sdp-capability-negotiation-13.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 31
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 28, 2010. This Internet-Draft will expire on September 24, 2010.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 48 skipping to change at page 2, line 45
The document defines a general SDP Capability Negotiation framework. The document defines a general SDP Capability Negotiation framework.
It also specifies how to provide attributes and transport protocols It also specifies how to provide attributes and transport protocols
as capabilities and negotiate them using the framework. Extensions as capabilities and negotiate them using the framework. Extensions
for other types of capabilities (e.g. media types and media formats) for other types of capabilities (e.g. media types and media formats)
may be provided in other documents. may be provided in other documents.
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
2. Conventions used in this document..............................7 2. Conventions used in this document..............................7
3. SDP Capability Negotiation Solution............................8 3. SDP Capability Negotiation Solution............................7
3.1. SDP Capability Negotiation Model..........................8 3.1. SDP Capability Negotiation Model..........................7
3.2. Solution Overview........................................11 3.2. Solution Overview........................................11
3.3. Version and Extension Indication Attributes..............15 3.3. Version and Extension Indication Attributes..............15
3.3.1. Supported Capability Negotiation Extensions Attribute15 3.3.1. Supported Capability Negotiation Extensions Attribute15
3.3.2. Required Capability Negotiation Extensions Attribute17 3.3.2. Required Capability Negotiation Extensions Attribute17
3.4. Capability Attributes....................................19 3.4. Capability Attributes....................................19
3.4.1. Attribute Capability Attribute......................19 3.4.1. Attribute Capability Attribute......................19
3.4.2. Transport Protocol Capability Attribute.............21 3.4.2. Transport Protocol Capability Attribute.............21
3.4.3. Extension Capability Attributes.....................23 3.4.3. Extension Capability Attributes.....................23
3.5. Configuration Attributes.................................24 3.5. Configuration Attributes.................................24
3.5.1. Potential Configuration Attribute...................24 3.5.1. Potential Configuration Attribute...................24
3.5.2. Actual Configuration Attribute......................32 3.5.2. Actual Configuration Attribute......................31
3.6. Offer/Answer Model Extensions............................34 3.6. Offer/Answer Model Extensions............................33
3.6.1. Generating the Initial Offer........................34 3.6.1. Generating the Initial Offer........................34
3.6.2. Generating the Answer...............................37 3.6.2. Generating the Answer...............................37
3.6.2.1. Example Views of Potential Configurations......44 3.6.2.1. Example Views of Potential Configurations......44
3.6.3. Offerer Processing of the Answer....................46 3.6.3. Offerer Processing of the Answer....................46
3.6.4. Modifying the Session...............................48 3.6.4. Modifying the Session...............................47
3.7. Interactions with ICE....................................48 3.7. Interactions with ICE....................................48
3.8. Interactions with SIP Option Tags........................50 3.8. Interactions with SIP Option Tags........................49
3.9. Processing Media before Answer...........................50 3.9. Processing Media before Answer...........................50
3.10. Indicating Bandwidth Usage..............................51 3.10. Indicating Bandwidth Usage..............................51
3.11. Dealing with Large Number of Potential Configurations...53 3.11. Dealing with Large Number of Potential Configurations...52
3.12. SDP Capability Negotiation and Intermediaries...........54 3.12. SDP Capability Negotiation and Intermediaries...........53
3.13. Considerations for Specific Attribute Capabilities......55 3.13. Considerations for Specific Attribute Capabilities......55
3.13.1. The rtpmap and fmtp Attributes.....................55 3.13.1. The rtpmap and fmtp Attributes.....................55
3.13.2. Direction Attributes...............................56 3.13.2. Direction Attributes...............................56
3.14. Relationship to RFC 3407................................57 3.14. Relationship to RFC 3407................................56
4. Examples......................................................57 4. Examples......................................................57
4.1. Multiple Transport Protocols.............................57 4.1. Multiple Transport Protocols.............................57
4.2. DTLS-SRTP or SRTP with Media Level Security Descriptions.61 4.2. DTLS-SRTP or SRTP with Media Level Security Descriptions.60
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.........................................64 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..................................69 Descriptions as Alternatives..................................68
5. Security Considerations.......................................72 5. Security Considerations.......................................71
6. IANA Considerations...........................................75 6. IANA Considerations...........................................74
6.1. New SDP Attributes.......................................75 6.1. New SDP Attributes.......................................74
6.2. New SDP Capability Negotiation Option Tag Registry.......77 6.2. New SDP Capability Negotiation Option Tag Registry.......76
6.3. New SDP Capability Negotiation Potential Configuration 6.3. New SDP Capability Negotiation Potential Configuration
Parameter Registry............................................77 Parameter Registry............................................76
7. Acknowledgments...............................................78 7. Acknowledgments...............................................77
8. Change Log....................................................78 8. Change Log....................................................77
8.1. draft-ietf-mmusic-sdp-capability-negotiation-12..........78 8.1. draft-ietf-mmusic-sdp-capability-negotiation-13..........77
8.2. draft-ietf-mmusic-sdp-capability-negotiation-11..........78 8.2. draft-ietf-mmusic-sdp-capability-negotiation-12..........77
8.3. draft-ietf-mmusic-sdp-capability-negotiation-10..........79 8.3. draft-ietf-mmusic-sdp-capability-negotiation-11..........78
8.4. draft-ietf-mmusic-sdp-capability-negotiation-09..........80 8.4. draft-ietf-mmusic-sdp-capability-negotiation-10..........79
8.5. draft-ietf-mmusic-sdp-capability-negotiation-08..........80 8.5. draft-ietf-mmusic-sdp-capability-negotiation-09..........79
8.6. draft-ietf-mmusic-sdp-capability-negotiation-07..........81 8.6. draft-ietf-mmusic-sdp-capability-negotiation-08..........79
8.7. draft-ietf-mmusic-sdp-capability-negotiation-06..........81 8.7. draft-ietf-mmusic-sdp-capability-negotiation-07..........80
8.8. draft-ietf-mmusic-sdp-capability-negotiation-05..........83 8.8. draft-ietf-mmusic-sdp-capability-negotiation-06..........80
8.9. draft-ietf-mmusic-sdp-capability-negotiation-04..........84 8.9. draft-ietf-mmusic-sdp-capability-negotiation-05..........82
8.10. draft-ietf-mmusic-sdp-capability-negotiation-03.........84 8.10. draft-ietf-mmusic-sdp-capability-negotiation-04.........83
8.11. draft-ietf-mmusic-sdp-capability-negotiation-02.........84 8.11. draft-ietf-mmusic-sdp-capability-negotiation-03.........83
8.12. draft-ietf-mmusic-sdp-capability-negotiation-01.........85 8.12. draft-ietf-mmusic-sdp-capability-negotiation-02.........84
8.13. draft-ietf-mmusic-sdp-capability-negotiation-00.........86 8.13. draft-ietf-mmusic-sdp-capability-negotiation-01.........84
9. References....................................................87 8.14. draft-ietf-mmusic-sdp-capability-negotiation-00.........85
9.1. Normative References.....................................87 9. References....................................................86
9.2. Informative References...................................87 9.1. Normative References.....................................86
Author's Address.................................................90 9.2. Informative References...................................86
Author's Address.................................................89
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. A SDP session description contains one or more media initiation. A SDP session description contains one or more media
stream descriptions with information such as IP-address and port, stream descriptions with information such as IP-address and port,
type of media stream (e.g. audio or video), transport protocol type of media stream (e.g. audio or video), transport protocol
(possibly including profile information, e.g. RTP/AVP or RTP/SAVP), (possibly including profile information, e.g. RTP/AVP or RTP/SAVP),
skipping to change at page 14, line 42 skipping to change at page 14, line 42
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
capabilities as well is she wanted to): capabilities as well if she wanted to):
v=0 v=0
o=- 25678 753850 IN IP4 192.0.2.1 o=- 25678 753850 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/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
skipping to change at page 35, line 8 skipping to change at page 34, line 28
in attribute capabilities only at the session-level, whereas in attribute capabilities only at the session-level, whereas
media-level attributes and associated values can be provided in media-level attributes and associated values can be provided in
attribute capabilities at either the media-level or session- attribute capabilities at either the media-level or session-
level. Attributes that are allowed at either the session- or level. Attributes that are allowed at either the session- or
media-level can be provided in attribute capabilities at either media-level can be provided in attribute capabilities at either
level. level.
o Zero or more transport protocol capability attributes. There MUST o Zero or more transport protocol capability attributes. There MUST
be transport protocol capabilities as defined in Section 3.4.2. be transport protocol capabilities as defined in Section 3.4.2.
with values for each transport protocol that needs to be with values for each transport protocol that needs to be
indicated as a capability in the offer. Transport protocol indicated as a capability in the offer.
capabilities may be included irrespective of whether they are
referenced by a potential configuration or not.
Transport protocol capabilities that apply to multiple media Transport protocol capabilities may be included irrespective of
descriptions SHOULD be provided at the session-level whereas whether they are referenced by a potential configuration or not.
transport protocol capabilities that apply only to a specific Transport protocols that apply to multiple media descriptions
media description ("m=" line), SHOULD be provided within that SHOULD be provided as transport protocol capabilities at the
particular media description. In either case, there MUST NOT be session-level whereas transport protocols that apply only to a
more than a single "a=tcap" attribute at the session-level and a specific media description ("m=" line), SHOULD be provided as
single "a=tcap" attribute in each media description. transport protocol capabilities within that particular media
description. In either case, there MUST NOT be more than a single
"a=tcap" attribute at the session-level and a single "a=tcap"
attribute in each media description.
o Zero or more extension capability attributes. There MUST be one o Zero or more extension capability attributes. There MUST be one
or more extension capability attributes (as outlined in Section or more extension capability attributes (as outlined in Section
3.4.3. ) for each extension capability that is referenced by a 3.4.3. ) for each extension capability that is referenced by a
potential configuration. Extension capability attributes that are potential configuration. Extension capability attributes that are
not referenced by a potential configuration can be provided as not referenced by a potential configuration can be provided as
well. well.
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
skipping to change at page 39, line 8 skipping to change at page 38, line 37
1. It is in accordance with the syntax and semantics provided in 1. It is in accordance with the syntax and semantics provided in
Section 3.5.1. Section 3.5.1.
2. It contains a configuration number that is unique within that 2. It contains a configuration number that is unique within that
media description. media description.
3. All attribute capabilities referenced by the potential 3. All attribute capabilities referenced by the potential
configuration are valid themselves (as defined in Section 3.4.1. configuration are valid themselves (as defined in Section 3.4.1.
) and each of them is provided either at the session-level or ) and each of them is provided either at the session-level or
within this particular media description. For session-level within this particular media description.
attribute capabilities referenced, the attributes contained
inside them MUST NOT be media-level only attributes. For session-level attribute capabilities referenced, the
attributes contained inside them MUST NOT be media-level only
attributes. Note that the answerer can only determine this for
attributes supported by the answerer. If an attribute is not
supported, it will simply be ignored by the answerer and hence
will not trigger an "invalid" potential configuration.
4. All transport protocol capabilities referenced by the potential 4. All transport protocol capabilities referenced by the potential
configuration are valid themselves (as defined in Section 3.4.2. configuration are valid themselves (as defined in Section 3.4.2.
) and each of them is furthermore provided either at the session- ) and each of them is furthermore provided either at the session-
level or within this particular media description. level or within this particular media description.
5. All extension capabilities referenced by the potential 5. All extension capabilities referenced by the potential
configuration and supported by the answerer are valid themselves configuration and supported by the answerer are valid themselves
(as defined by that particular extension) and each of them are (as defined by that particular extension) and each of them are
furthermore provided either at the session-level or within this furthermore provided either at the session-level or within this
skipping to change at page 44, line 14 skipping to change at page 43, line 38
offer, however it MUST NOT send media based on that actual offer, however it MUST NOT send media based on that actual
configuration if it selects an alternative potential configuration. configuration if it selects an alternative potential configuration.
If the answerer selects one of the potential configurations, then If the answerer selects one of the potential configurations, then
the answerer MAY immediately start to send media to the offerer in the answerer MAY immediately start to send media to the offerer in
accordance with the selected potential configuration, however the accordance with the selected potential configuration, however the
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 answerer 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 session description as soon as possible. This back an answer SDP session description as soon as possible. This
minimizes the risk of having media discarded or played out as minimizes the risk of having media discarded or played out as
garbage by the offerer. In the case of SIP [RFC3261] without any garbage by the offerer. In the case of SIP [RFC3261] without any
extensions, this implies that if the offer was received in an INVITE extensions, this implies that if the offer was received in an INVITE
message, then the answer SDP session description should be provided message, then the answer SDP session description should be provided
in the first non-100 provisional response sent back (per RFC3261, in the first non-100 provisional response sent back (per RFC3261,
the answer would need to be repeated in the 200 response as well, the answer would need to be repeated in the 200 response as well,
unless a relevant extension such as [RFC3262] is being used). unless a relevant extension such as [RFC3262] is being used).
skipping to change at page 73, line 44 skipping to change at page 72, line 51
description. In simple architectures where the two UA's proxies description. In simple architectures where the two UA's proxies
communicate directly, the security provided by this method is communicate directly, the security provided by this method is
roughly comparable to that provided by the previously discussed roughly comparable to that provided by the previously discussed
signature-based mechanisms. 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 answerer, 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
RTP as the actual configuration and secure RTP as an alternative RTP as the actual configuration and secure RTP as an alternative
potential configuration. Even though the answerer selects secure potential configuration. Even though the answerer selects secure
RTP, the offerer will not know that until he receives the answer, RTP, the offerer will not know that until he receives the answer,
and hence an attacker will be able to send media to the offerer and hence an attacker will be able to send media to the offerer
meanwhile. The easiest protection against such an attack is to not meanwhile. The easiest protection against such an attack is to not
offer use of the non-secure media stream in the actual offer use of the non-secure media stream in the actual
configuration, however that may in itself have undesirable side- configuration, however that may in itself have undesirable side-
skipping to change at page 78, line 27 skipping to change at page 77, line 27
Stach, and Dan Wing. Stach, and Dan Wing.
General Area review comments were provided by Christian Vogt, and General Area review comments were provided by Christian Vogt, and
Stephen Kent provided Security Directorate review comments. Eric Stephen Kent provided Security Directorate review comments. Eric
Rescorla provided textual input to the Security Considerations. Rescorla provided textual input to the Security Considerations.
Alexey Melnikov, Robert Sparks, and Magnus Westerlund provided Alexey Melnikov, Robert Sparks, and Magnus Westerlund provided
several review comments as well. several review comments as well.
8. Change Log 8. Change Log
8.1. draft-ietf-mmusic-sdp-capability-negotiation-12 8.1. draft-ietf-mmusic-sdp-capability-negotiation-13
o Clarified that unsupported media-level attributes in session-
level attribute capabilities do not trigger an "invalid"
potential configuration, since such attributes will be ignored
per normal SDP rules.
o Clarified text in Section 3.6.1. to more clearly distinguish
between transport protocols and transport protocol capabilities.
o A couple of editorial nit fixes
8.2. draft-ietf-mmusic-sdp-capability-negotiation-12
Addressing IESG review comments as follows: Addressing IESG review comments as follows:
o Clarified processing rules for "creq" in Section 3.3.2. o Clarified processing rules for "creq" in Section 3.3.2.
o Removed "iptv_rtsp" example in Section 3.4.2. o Removed "iptv_rtsp" example in Section 3.4.2.
o Fixed ABNF error in "attribute-config-list". o Fixed ABNF error in "attribute-config-list".
o Changed ICE [ICE] reference from informative to normative. o Changed ICE [ICE] reference from informative to normative.
o Minor editorial changes. o Minor editorial changes.
8.2. draft-ietf-mmusic-sdp-capability-negotiation-11 8.3. draft-ietf-mmusic-sdp-capability-negotiation-11
Addressing IESG review comments as follows: Addressing IESG review comments as follows:
o Changed att-cap-num and trpr-cap-num ABNF rules throughout to o Changed att-cap-num and trpr-cap-num ABNF rules throughout to
allow for no more than 10 digits. allow for no more than 10 digits.
o Disallowed base framework only implementations from generating o Disallowed base framework only implementations from generating
media-level attribute capabilities at the session-level, and media-level attribute capabilities at the session-level, and
added explicit rules for how to process them if received. added explicit rules for how to process them if received.
skipping to change at page 79, line 43 skipping to change at page 79, line 7
o Changed IANA rules for new option tags and potential o Changed IANA rules for new option tags and potential
configuration parameters to follow "IETF Review" policy, and configuration parameters to follow "IETF Review" policy, and
clarified that potential configuration parameters must be clarified that potential configuration parameters must be
registered with IANA. registered with IANA.
o Changed numerous instances of "SDP" with the more accurate "SDP o Changed numerous instances of "SDP" with the more accurate "SDP
session description" to avoid terminology overload. session description" to avoid terminology overload.
o Various editorial clarifications throughout. o Various editorial clarifications throughout.
8.3. draft-ietf-mmusic-sdp-capability-negotiation-10 8.4. draft-ietf-mmusic-sdp-capability-negotiation-10
Addressing General Area and Security Directorate review comments as Addressing General Area and Security Directorate review comments as
follows: follows:
o Explained and motivated the preference order between potential o Explained and motivated the preference order between potential
and actual configurations earlier in the document. and actual configurations earlier in the document.
o Added DTLS-SRTP example use in several places, as well as a new o Added DTLS-SRTP example use in several places, as well as a new
example call flow for DTLS-SRTP. example call flow for DTLS-SRTP.
skipping to change at page 80, line 19 skipping to change at page 79, line 29
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.4. draft-ietf-mmusic-sdp-capability-negotiation-09 8.5. 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.5. draft-ietf-mmusic-sdp-capability-negotiation-08 8.6. 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 81, line 9 skipping to change at page 80, line 20
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.6. draft-ietf-mmusic-sdp-capability-negotiation-07 8.7. draft-ietf-mmusic-sdp-capability-negotiation-07
o Removed the ability to have attribute capabilities provide o Removed the ability to have attribute capabilities provide
attribute names without values, when those attributes otherwise attribute names without values, when those attributes otherwise
require an associated value. require an associated value.
o Document no longer obsoletes RFC 3407 but instead recommends that o Document no longer obsoletes RFC 3407 but instead recommends that
it is being used instead of RFC 3407. it is being used instead of RFC 3407.
o Added ability to specific that specific extensions in a potential o Added ability to specific that specific extensions in a potential
configuration are mandatory. configuration are mandatory.
skipping to change at page 81, line 34 skipping to change at page 80, line 45
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.7. draft-ietf-mmusic-sdp-capability-negotiation-06 8.8. draft-ietf-mmusic-sdp-capability-negotiation-06
o Added additional background text on terminology used, and a new o Added additional background text on terminology used, and a new
section on the negotiation model. section on the negotiation model.
o Allowed for session-level attribute capabilities to contain o Allowed for session-level attribute capabilities to contain
media-level only attributes, albeit the base framework does not media-level only attributes, albeit the base framework does not
define (or allow) them to be used in a potential configuration define (or allow) them to be used in a potential configuration
(extensions may change that) (extensions may change that)
o Disallowing multiple "a=tcap" attributes at the session-level o Disallowing multiple "a=tcap" attributes at the session-level
skipping to change at page 83, line 5 skipping to change at page 82, line 18
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.8. draft-ietf-mmusic-sdp-capability-negotiation-05 8.9. 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 84, line 9 skipping to change at page 83, line 22
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.9. draft-ietf-mmusic-sdp-capability-negotiation-04 8.10. 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.10. draft-ietf-mmusic-sdp-capability-negotiation-03 8.11. 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
skipping to change at page 84, line 38 skipping to change at page 84, line 4
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.11. draft-ietf-mmusic-sdp-capability-negotiation-02 8.12. draft-ietf-mmusic-sdp-capability-negotiation-02
The following are the major changes compared to version -01: The following are the major changes compared to version -01:
o Potential configurations are no longer allowed at the session o Potential configurations are no longer allowed at the session
level level
o Renamed capability attributes ("capar" to "acap" and "ctrpr" to o Renamed capability attributes ("capar" to "acap" and "ctrpr" to
"tcap") "tcap")
o Changed name and semantics of the initial number (now called o Changed name and semantics of the initial number (now called
skipping to change at page 85, line 28 skipping to change at page 84, line 39
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.12. draft-ietf-mmusic-sdp-capability-negotiation-01 8.13. draft-ietf-mmusic-sdp-capability-negotiation-01
The following are the major changes compared to version -00: The following are the major changes compared to version -00:
o Media capabilities are no longer considered a core capability and o Media capabilities are no longer considered a core capability and
hence have been removed. This leaves transport protocols and hence have been removed. This leaves transport protocols and
attributes as the only capabilities defined by the core. attributes as the only capabilities defined by the core.
o Version attribute has been removed and an option tag to indicate o Version attribute has been removed and an option tag to indicate
the actual version has been defined instead. the actual version has been defined instead.
skipping to change at page 86, line 13 skipping to change at page 85, line 26
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.13. draft-ietf-mmusic-sdp-capability-negotiation-00 8.14. 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.
 End of changes. 34 change blocks. 
70 lines changed or deleted 88 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/