draft-ietf-mmusic-sdp-capability-negotiation-reqts-00.txt   draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.txt 
MMUSIC Working Group F. Andreasen MMUSIC Working Group F. Andreasen
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expires: June 2007 December 17, 2006 Expires: September 2007 March 4, 2007
SDP Capability Negotiation: SDP Capability Negotiation:
Requirements and Review of Existing Work Requirements and Review of Existing Work
draft-ietf-mmusic-sdp-capability-negotiation-reqts-00.txt draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.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 36 skipping to change at page 1, line 35
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 June 17, 2007. This Internet-Draft will expire on September 4, 2007.
Copyright Notice
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
not intended to provide capability indication or capability not intended to provide capability indication or capability
negotiation, however over the years, SDP has seen widespread adoption negotiation, however over the years, SDP has seen widespread adoption
and as a result it has been gradually extended to provide limited and as a result it has been gradually extended to provide limited
support for these. SDP and its current extensions however do not support for these. SDP and its current extensions however do not
skipping to change at page 2, line 30 skipping to change at page 2, line 34
1. Introduction...................................................3 1. Introduction...................................................3
2. Requirements...................................................5 2. Requirements...................................................5
3. Review of Existing Work.......................................10 3. Review of Existing Work.......................................10
3.1. Grouping of Media Lines..................................10 3.1. Grouping of Media Lines..................................10
3.2. Session Description Protocol (SDP) Simple Capability 3.2. Session Description Protocol (SDP) Simple Capability
Declaration...................................................11 Declaration...................................................11
3.3. Session Description and Capability Negotiation (SDPng)...12 3.3. Session Description and Capability Negotiation (SDPng)...12
3.4. Multipart/alternative....................................14 3.4. Multipart/alternative....................................14
3.5. Sharing Ports Between "m=" Lines.........................15 3.5. Sharing Ports Between "m=" Lines.........................15
3.6. Opportunistic Encryption Using a Session Attribute.......16 3.6. Opportunistic Encryption Using a Session Attribute.......16
3.7. Best-Effort Secure Real-Time Transport Protocol..........16 3.7. Best-Effort Secure Real-Time Transport Protocol..........17
3.8. Opportunistic Encryption using Probing...................17 3.8. Opportunistic Encryption using Probing...................18
4. Security Considerations.......................................18 4. Security Considerations.......................................18
5. IANA Considerations...........................................18 5. IANA Considerations...........................................18
6. Acknowledgments...............................................18 6. Acknowledgments...............................................18
7. Change Log....................................................18 7. Change Log....................................................18
7.1. draft-ietf-mmusic-sdp-capability-negotiation-reqts-00.txt18 7.1. draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.txt18
7.2. draft-andreasen-mmusic-sdp-capability-negotiation-reqts- 7.2. draft-ietf-mmusic-sdp-capability-negotiation-reqts-00.txt19
7.3. draft-andreasen-mmusic-sdp-capability-negotiation-reqts-
00.txt........................................................19 00.txt........................................................19
8. References....................................................20 8. References....................................................20
8.1. Normative References.....................................20 8.1. Normative References.....................................20
8.2. Informative References...................................20 8.2. Informative References...................................20
Author's Addresses...............................................22 Author's Addresses...............................................22
Intellectual Property Statement..................................22 Intellectual Property Statement..................................22
Disclaimer of Validity...........................................23 Full Copyright Statement.........................................22
Copyright Statement..............................................23
Acknowledgment...................................................23 Acknowledgment...................................................23
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
session and media stream parameters that define the session. session and media stream parameters that define the session.
skipping to change at page 6, line 22 skipping to change at page 6, line 22
For example, "RTP/AVP" and "RTP/SAVP" may be alternatives. For example, "RTP/AVP" and "RTP/SAVP" may be alternatives.
REQ-50: It MUST be possible to indicate and negotiate alternative REQ-50: It MUST be possible to indicate and negotiate alternative
transport protocol and media type combinations on a per media stream transport protocol and media type combinations on a per media stream
basis. basis.
For example, an entity may support a fax call using either T.38 For example, an entity may support a fax call using either T.38
fax relay ("m=image <port> udptl t38") or PCMU ("m=audio <port> fax relay ("m=image <port> udptl t38") or PCMU ("m=audio <port>
RTP/AVP 0"). RTP/AVP 0").
[Editor's note: This requirement may have interactions with ICE -
need to consider those further]
REQ-80: The mechanism MUST be backwards compatible for SIP endpoints; REQ-80: The mechanism MUST be backwards compatible for SIP endpoints;
an entity that does not support the mechanism should behave as if the an entity that does not support the mechanism should behave as if the
mechanism was not present in the signaling the first place. mechanism was not present in the signaling the first place.
The above is referred to as "best-case" backwards compatibility. The above is referred to as "best-case" backwards compatibility.
Another form of backwards compatibility could result in an error Another form of backwards compatibility could result in an error
message indicating the extension is not supported, however this message indicating the extension is not supported, however this
has undesirable side-effects for SIP (heterogeneous error has undesirable side-effects for SIP (heterogeneous error
response forking problem - HERFP) and leads to additional response forking problem - HERFP) and leads to additional
signaling. Another form of backwards compatibility would have an signaling. Another form of backwards compatibility would have an
skipping to change at page 7, line 5 skipping to change at page 6, line 49
in a session, that may or may not have the media associated with the in a session, that may or may not have the media associated with the
SIP session traverse through it. In either case, the middle box may SIP session traverse through it. In either case, the middle box may
have a need to understand the details of the media streams for the have a need to understand the details of the media streams for the
session. session.
For example, a SIP middle-box may inspect the SDP exchanged to For example, a SIP middle-box may inspect the SDP exchanged to
determine what Quality of Service to authorize for the associated determine what Quality of Service to authorize for the associated
media streams. While such middle boxes are not part of the SIP media streams. While such middle boxes are not part of the SIP
architecture or the Internet per se, they do exist in many real architecture or the Internet per se, they do exist in many real
life scenarios, and we have a desire to provide a solution for life scenarios, and we have a desire to provide a solution for
those. those. A SIP middle-box such as the above, may be affected by a
solution to the requirements provided above. For example, if the
SDP exchanged appears to negotiate use of plain RTP, but in
reality, extensions are being used that result in Secure RTP with
an added authentication tag being used, then the middle-box above
may authorize less bandwidth than necessary. Similarly, if it
tries to process media, unexpected results may occur. This is why
such middle-boxes in theory should not pass SDP through them, if
said SDP contains one or more attributes they do not understand
or support. However, in practice, many SIP middle-boxes
nevertheless do in an attempt to be as minimally invasive as
possible. The alternative would be for a new extensions to either
never make it through such middle-boxes or have SIP methods using
them be rejected. The requirement provided here is to try and aid
such middle-boxes under the assumption that they will be upgraded
to support the extensions that will be defined, and hence the aid
provided need not be optimal.
REQ-90: The mechanism MUST either be backwards compatible for Megaco REQ-90: The mechanism MUST either be backwards compatible for Megaco
and MGCP or it MUST be possible to interwork it with Megaco and MGCP and MGCP or it MUST be possible to interwork it with Megaco and MGCP
without any additional signaling between the MGC and its peer (e.g. without any additional signaling between the MGC and its peer (e.g.
another SIP UA as opposed to a media gateway). another SIP UA as opposed to a media gateway).
For example, if a media gateway controller (MGC) uses SIP to For example, if a media gateway controller (MGC) uses SIP to
communicate with peers, and the MGC uses Megaco or MGCP to communicate with peers, and the MGC uses Megaco or MGCP to
control a media gateway, it must be possible to translate between control a media gateway, it must be possible to translate between
the mechanism and normal SDP. Avoiding interworking requirements the mechanism and normal SDP. Avoiding interworking requirements
skipping to change at page 9, line 26 skipping to change at page 9, line 38
supported by the answerer (and vice versa), in order to correctly supported by the answerer (and vice versa), in order to correctly
process the SDP capability negotiation in the offer (or answer). process the SDP capability negotiation in the offer (or answer).
Note that this requirement applies to the SDP capability Note that this requirement applies to the SDP capability
negotiation part of the SDP only - other SDP extensions are negotiation part of the SDP only - other SDP extensions are
unaffected by this. unaffected by this.
REQ-310: The following requirements are considered enhancements as REQ-310: The following requirements are considered enhancements as
defined in REQ-300: defined in REQ-300:
* REQ-50 (alternative combinations of transport protocol and media o REQ-10 (alternative media formats)
type)
* REQ-150 (valid combinations of media lines) o REQ-30 (alternative fmtp parameters)
* REQ-160 (valid combinations of media formats between media o REQ-50 (alternative combinations of transport protocol and media
streams) type)
[Editor's Note: Should we have any security requirements - see e.g. o REQ-122 (additional media streams as latent configurations)
Section 4.
o REQ-150 (valid combinations of media lines)
o REQ-160 (valid combinations of media formats between media
streams)
[Editor's Note: Need to consider layered codecs and how they may [Editor's Note: Need to consider layered codecs and how they may
impact the requirements] impact the requirements]
Above, we presented the requirements for the capability negotiation Above, we presented the requirements for the capability negotiation
mechanism. Below, we provide a set of features that were considered mechanism. Below, we provide a set of features that were considered
and then explicitly deemed to be out-of-scope: and then explicitly deemed to be out-of-scope:
o Support for negotiation of unicast and multicast addresses as o Support for negotiation of unicast and multicast addresses as
alternatives. It was suggested as a requirement initially, but alternatives. It was suggested as a requirement initially, but
subsequent discussion led to its removal. subsequent discussion led to its removal.
skipping to change at page 14, line 23 skipping to change at page 14, line 32
support negotiation of transport parameters as individual support negotiation of transport parameters as individual
capabilities. It is however still possible to negotiate different capabilities. It is however still possible to negotiate different
transport parameters by providing alternative configurations. transport parameters by providing alternative configurations.
o Verbose Encoding and Large Message Size: SDPng descriptions are o Verbose Encoding and Large Message Size: SDPng descriptions are
XML documents, which are fairly verbose and result in descriptions XML documents, which are fairly verbose and result in descriptions
that are substantially larger than existing SDP. that are substantially larger than existing SDP.
3.4. Multipart/alternative 3.4. Multipart/alternative
In [I-D.jenning-sipping-multipart], the use of multipart/alternative In [I-D.jennings-sipping-multipart], the use of multipart/alternative
MIME is proposed as a way to support multiple alternative offers. MIME is proposed as a way to support multiple alternative offers.
Each alternative offer has an id associated with it by use of a new Each alternative offer has an id associated with it by use of a new
MIME header field called Content-Answering-CID. The answerer chooses MIME header field called Content-Answering-CID. The answerer chooses
one of the offers and performs normal offer/answer operation on that one of the offers and performs normal offer/answer operation on that
offer, and then sends back a single answer which includes the offer, and then sends back a single answer which includes the
Content-Answering-CID value of the offer chosen. Content-Answering-CID value of the offer chosen.
The main advantages of this approach are: The main advantages of this approach are:
o It allows for use of alternative encodings of the offer, e.g. SDP o It allows for use of alternative encodings of the offer, e.g. SDP
skipping to change at page 18, line 20 skipping to change at page 18, line 34
best-effort SRTP negotiation, i.e. an offer/answer exchange offering best-effort SRTP negotiation, i.e. an offer/answer exchange offering
both a secure and a non-secure version of RTP. The answerer in turn both a secure and a non-secure version of RTP. The answerer in turn
will select one of these. Such a negotiation where the offerer is will select one of these. Such a negotiation where the offerer is
willing to accept either a secure or insecure RTP profile, and willing to accept either a secure or insecure RTP profile, and
possibly with more or less strong security algorithms as a result of possibly with more or less strong security algorithms as a result of
the negotiation opens up for a range of possible security attacks. It the negotiation opens up for a range of possible security attacks. It
is important that any solution for SDP capability negotiation is important that any solution for SDP capability negotiation
properly addresses such security risks and/or notes any security properly addresses such security risks and/or notes any security
threats inherent in the proposed solution. threats inherent in the proposed solution.
[Editor's note: This almost sounds like we should have some
specific requirements around all of this].
5. IANA Considerations 5. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
6. Acknowledgments 6. Acknowledgments
Thanks to the MMUSIC WG for comments on the requirements in this Thanks to the MMUSIC WG for comments on the requirements in this
document. Also, Francois Audet, Paul Jones and Dan Wing provided document. Also, Francois Audet, Paul Jones and Dan Wing provided
specific comments on a precursor to this document. specific comments on a precursor to this document.
7. Change Log 7. Change Log
7.1. draft-ietf-mmusic-sdp-capability-negotiation-reqts-00.txt 7.1. draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.txt
o Moved REQ-10, REQ-30, and REQ-122 from core to enhancements
o Elaborated on note around middle-boxes passing unknown attributes
through them, and the potential implication of doing so with
respect to this framework.
7.2. draft-ietf-mmusic-sdp-capability-negotiation-reqts-00.txt
Version -00 is based on draft-andreasen-mmusic-sdp-capability- Version -00 is based on draft-andreasen-mmusic-sdp-capability-
negotiation-reqts-00.txt with the following changes: negotiation-reqts-00.txt with the following changes:
* Noted that REQ-50 may have interactions with ICE o Noted that REQ-50 may have interactions with ICE
* Clarified requirements REQ-80, REQ-130. o Clarified requirements REQ-80, REQ-130.
* Added new requirements REQ-85, REQ-121, REQ-122, REQ-301, and REQ- o Added new requirements REQ-85, REQ-121, REQ-122, REQ-301, and REQ-
302. 302.
* Reduced requirements REQ-150 and REQ-160 to "SHOULD" strength. o Reduced requirements REQ-150 and REQ-160 to "SHOULD" strength.
* Minor updates to Section 3.7. and 3.8. o Minor updates to Section 3.7. and 3.8.
7.2. draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00.txt 7.3. draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00.txt
Version -00 is the initial version. The requirements provided in this Version -00 is the initial version. The requirements provided in this
initial version were taken from an earlier version of [SDPCapNeg] initial version were taken from an earlier version of [SDPCapNeg]
with additional requirements added (from REQ-150 and up). with additional requirements added (from REQ-150 and up).
The ability to indicate capabilities as either mandatory or optional The ability to indicate capabilities as either mandatory or optional
is no longer explicitly out of scope (in order to support modularity is no longer explicitly out of scope (in order to support modularity
and extensibility per the newly added requirements), and neither is and extensibility per the newly added requirements), and neither is
the ability to indicate constraints on combinations of the ability to indicate constraints on combinations of
configurations. configurations.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002. Capability Declaration", RFC 3407, October 2002.
[RFC3605] C. Huitema, "Real Time Control Protocol (RTCP) attribute in [RFC3605] C. Huitema, "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October Session Description Protocol (SDP)", RFC 3605, October
2003. 2003.
skipping to change at page 23, line 5 skipping to change at page 22, line 44
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Full Copyright Statement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 28 change blocks. 
48 lines changed or deleted 65 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/