draft-ietf-mmusic-sdp-media-capabilities-08.txt   draft-ietf-mmusic-sdp-media-capabilities-09.txt 
MMUSIC R. Gilman MMUSIC R. Gilman
Internet-Draft NDCI Internet-Draft Independent
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: January 11, 2010 Gesher Erove Ltd Expires: August 30, 2010 Gesher Erove Ltd
F. Andreasen F. Andreasen
Cisco Systems Cisco Systems
July 10, 2009 February 26, 2010
SDP media capabilities Negotiation SDP media capabilities Negotiation
draft-ietf-mmusic-sdp-media-capabilities-08 draft-ietf-mmusic-sdp-media-capabilities-09
Abstract
Session Description Protocol (SDP) capability negotiation provides a
general framework for indicating and negotiating capabilities in SDP.
The base framework defines only capabilities for negotiating
transport protocols and attributes. In this document, we extend the
framework by defining media capabilities that can be used to
negotiate media types and their associated parameters. This
extension is designed to map easily to existing and future SDP media
attributes, but not encodings or formatting.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 January 11, 2010. This Internet-Draft will expire on August 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Session Description Protocol (SDP) capability negotiation provides a This document may contain material from IETF Documents or IETF
general framework for indicating and negotiating capabilities in SDP. Contributions published or made publicly available before November
The base framework defines only capabilities for negotiating 10, 2008. The person(s) controlling the copyright in some of this
transport protocols and attributes. In this document, we extend the material may not have granted the IETF Trust the right to allow
framework by defining media capabilities that can be used to modifications of such material outside the IETF Standards Process.
negotiate media types and their associated parameters. This Without obtaining an adequate license from the person(s) controlling
extension is designed to map easily to existing and future SDP media the copyright in such materials, this document may not be modified
attributes, but not encodings or formatting. outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SDP Media Capabilities . . . . . . . . . . . . . . . . . . . . 7 3. SDP Media Capabilities . . . . . . . . . . . . . . . . . . . . 6
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Solution Overview . . . . . . . . . . . . . . . . . . . . 8 3.2. Solution Overview . . . . . . . . . . . . . . . . . . . . 7
3.3. New Capability Attributes . . . . . . . . . . . . . . . . 14 3.3. New Capability Attributes . . . . . . . . . . . . . . . . 13
3.3.1. The Media Encoding Capability Attribute . . . . . . . 14 3.3.1. The Media Encoding Capability Attribute . . . . . . . 13
3.3.2. The Media Format Parameter Capability Attribute . . . 15 3.3.2. The Media Format Parameter Capability Attribute . . . 14
3.3.3. The Media-Specific Capability Attribute . . . . . . . 18 3.3.3. The Media-Specific Capability Attribute . . . . . . . 17
3.3.4. New Configuration Parameters . . . . . . . . . . . . . 19 3.3.4. New Configuration Parameters . . . . . . . . . . . . . 18
3.3.5. The Latent Configuration Attribute . . . . . . . . . . 21 3.3.5. The Latent Configuration Attribute . . . . . . . . . . 20
3.3.6. Enhanced Potential Configuration Attribute . . . . . . 23 3.3.6. Enhanced Potential Configuration Attribute . . . . . . 22
3.3.7. Substitution of Media Payload Type Numbers in 3.3.7. Substitution of Media Payload Type Numbers in
Capability Attribute Parameters . . . . . . . . . . . 26 Capability Attribute Parameters . . . . . . . . . . . 25
3.3.8. The Session Capability Attribute . . . . . . . . . . . 28 3.3.8. The Session Capability Attribute . . . . . . . . . . . 27
3.4. Offer/Answer Model Extensions . . . . . . . . . . . . . . 32 3.4. Offer/Answer Model Extensions . . . . . . . . . . . . . . 30
3.4.1. Generating the Initial Offer . . . . . . . . . . . . . 32 3.4.1. Generating the Initial Offer . . . . . . . . . . . . . 31
3.4.2. Generating the Answer . . . . . . . . . . . . . . . . 33 3.4.2. Generating the Answer . . . . . . . . . . . . . . . . 31
3.4.3. Offerer Processing of the Answer . . . . . . . . . . . 33 3.4.3. Offerer Processing of the Answer . . . . . . . . . . . 32
3.4.4. Modifying the Session . . . . . . . . . . . . . . . . 33 3.4.4. Modifying the Session . . . . . . . . . . . . . . . . 32
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. a= . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1. Alternative Codecs . . . . . . . . . . . . . . . . . . . . 33
4.2. Alternative Combinations of Codecs (Session 4.2. Alternative Combinations of Codecs (Session
Configurations) . . . . . . . . . . . . . . . . . . . . . 37 Configurations) . . . . . . . . . . . . . . . . . . . . . 36
4.3. Latent Media Streams . . . . . . . . . . . . . . . . . . . 37 4.3. Latent Media Streams . . . . . . . . . . . . . . . . . . . 36
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 40 5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 39
5.2. New SDP Option Tag . . . . . . . . . . . . . . . . . . . . 41 5.2. New SDP Option Tag . . . . . . . . . . . . . . . . . . . . 40
5.3. New SDP Capability Negotiation Parameters . . . . . . . . 41 5.3. New SDP Capability Negotiation Parameters . . . . . . . . 40
6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41
7. Changes from previous versions . . . . . . . . . . . . . . . . 43 7. Changes from previous versions . . . . . . . . . . . . . . . . 42
7.1. Changes from version 04 . . . . . . . . . . . . . . . . . 43 7.1. Changes from version 08 . . . . . . . . . . . . . . . . . 42
7.2. Changes from version 03 . . . . . . . . . . . . . . . . . 43 7.2. Changes from version 04 . . . . . . . . . . . . . . . . . 42
7.3. Changes from version 02 . . . . . . . . . . . . . . . . . 44 7.3. Changes from version 03 . . . . . . . . . . . . . . . . . 42
7.4. Changes from version 01 . . . . . . . . . . . . . . . . . 44 7.4. Changes from version 02 . . . . . . . . . . . . . . . . . 43
7.5. Changes from version 00 . . . . . . . . . . . . . . . . . 44 7.5. Changes from version 01 . . . . . . . . . . . . . . . . . 43
7.6. Changes from version 00 . . . . . . . . . . . . . . . . . 44
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.1. Normative References . . . . . . . . . . . . . . . . . . . 46 9.1. Normative References . . . . . . . . . . . . . . . . . . . 46
9.2. Informative References . . . . . . . . . . . . . . . . . . 46 9.2. Informative References . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
Session Description Protocol (SDP) capability negotiation [SDPCapNeg] Session Description Protocol (SDP) capability negotiation [SDPCapNeg]
provides a general framework for indicating and negotiating provides a general framework for indicating and negotiating
skipping to change at page 31, line 38 skipping to change at page 30, line 38
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=acfg:1 a=acfg:1
m=video 0 RTP/AVP 102 m=video 0 RTP/AVP 102
a=pcfg:2 a=pcfg:2
This exchange supports immediate establishment of an audio stream for This exchange supports immediate establishment of an audio stream for
preliminary conversation. This exchange would presumably be followed preliminary conversation. This exchange would presumably be followed
at the appropriate time with a "reconfiguration" offer/answer at the appropriate time with a "reconfiguration" offer/answer
exchange to add the video and chair control streams. exchange to add the video and chair control streams.
[Editors' note: We have considered a form of the lcfg: attribute that
would permit an offerer to indicate that the configuration is
available for immediate acceptance via an answer with a corresponding
(new) m-line in the answer. This would permit the establishment of
the media streams to take place in one SDP exchange; at the same
time, non-negotiating endpoints could be offered a simple
configuration as in the above example. Ultimately, when all
endpoints understand the current specification, this would permit an
offer with latent configurations only, and an answer with the m-lines
for the accepted media streams.]
The choices of session capabilities may be based on processing load, The choices of session capabilities may be based on processing load,
total bandwidth, or any other criteria of importance to the total bandwidth, or any other criteria of importance to the
communicating parties. If the answerer supports media capabilities communicating parties. If the answerer supports media capabilities
negotiation, and session configurations are offered, it must accept negotiation, and session configurations are offered, it must accept
one of the offered configurations, or it must refuse the session. one of the offered configurations, or it must refuse the session.
Therefore, if the offer includes any session capabilities, it should Therefore, if the offer includes any session capabilities, it should
include all the session capabilities the offerer is willing to include all the session capabilities the offerer is willing to
support. support.
3.4. Offer/Answer Model Extensions 3.4. Offer/Answer Model Extensions
skipping to change at page 34, line 10 skipping to change at page 33, line 10
Alternatively, the initiator may perform a new capabilities exchange Alternatively, the initiator may perform a new capabilities exchange
as part of the reconfiguration. In such a case, the new capabilities as part of the reconfiguration. In such a case, the new capabilities
will replace the previously-negotiated capabilities. This may be will replace the previously-negotiated capabilities. This may be
useful if conditions change on the endpoint. useful if conditions change on the endpoint.
4. Examples 4. Examples
In this section, we provide examples showing how to use the Media In this section, we provide examples showing how to use the Media
Capabilities with the SDP Capability Negotiation. Capabilities with the SDP Capability Negotiation.
4.1. a= 4.1. Alternative Codecs
This example provide a choice of one of six variations of the This example provide a choice of one of six variations of the
adaptive multirate codec. In this example, the default configuration adaptive multirate codec. In this example, the default configuration
as specified by the media line is the same as the most preferred as specified by the media line is the same as the most preferred
configuration. Each configuration uses a different payload type configuration. Each configuration uses a different payload type
number so the offeror can interpret early media. number so the offeror can interpret early media.
1. v=0 1. v=0
2. o=- 25678 753849 IN IP4 192.0.2.1 2. o=- 25678 753849 IN IP4 192.0.2.1
3. s= 3. s=
skipping to change at page 38, line 49 skipping to change at page 37, line 49
4. c=IN IP4 192.0.2.2 4. c=IN IP4 192.0.2.2
5. t=0 0 5. t=0 0
6. a=csup:med-v0 6. a=csup:med-v0
7. a=mcap:10 H263-1998/90000 7. a=mcap:10 H263-1998/90000
8. a=lcfg:1 mt=video m=10 8. a=lcfg:1 mt=video m=10
9. m=audio 54322 RTP/AVP 0 100 9. m=audio 54322 RTP/AVP 0 100
10. a=rtpmap:0 PCMU/8000 10. a=rtpmap:0 PCMU/8000
11. a=rtpmap:100 telephone-event/8000 11. a=rtpmap:100 telephone-event/8000
12. a=fmtp:100 0-11 12. a=fmtp:100 0-11
13. a=acfg:1 m=1,3 pt=1:0,3:100 13. a=acfg:1 m=1,3 pt=1:0,3:100
14. a=mcap:1 G729/8000 14. a=pcfg:1 m=2,3 pt=2:18,3:100
15. a=mcap:2 telephone-event/8000
16. a=mfcap:2 0-11
17. a=pcfg:2 m=1,2 pt=1:18,2:100
Lines 7 and 8 announce the capability to support H.263 video at a Lines 7 and 8 announce the capability to support H.263 video at a
later time. Lines 9-12 of the answer present the selected later time. Lines 9-12 of the answer present the selected
configuration for the media stream. Line 13 identifies the potential configuration for the media stream. Line 13 identifies the potential
configuration from which it was taken, and lines 14-17 announce the configuration from which it was taken, and line 14 announces the
potential capability to support G.729 with DTMF events as well. If, potential capability to support G.729 with DTMF events as well. If,
at some later time, congestion becomes a problem in the network, at some later time, congestion becomes a problem in the network,
either party may offer a reconfiguration of the media stream to use either party may offer a reconfiguration of the media stream to use
G.729 in order to reduce packet sizes. Note that line 13 uses media G.729 in order to reduce packet sizes.
capability numbering as provided in the original offer, whereas lines
14-17 must use their own numbering.
5. IANA Considerations 5. IANA Considerations
5.1. New SDP Attributes 5.1. New SDP Attributes
The IANA is hereby requested to register the following new SDP The IANA is hereby requested to register the following new SDP
attributes: attributes:
Attribute name: mcap Attribute name: mcap
Long form name: media capability Long form name: media capability
skipping to change at page 43, line 7 skipping to change at page 42, line 7
encoding and bandwidth parameters for every media stream selected. encoding and bandwidth parameters for every media stream selected.
Pending an understanding of capabilities negotiation, the middlebox Pending an understanding of capabilities negotiation, the middlebox
should examine the answer SDP to obtain the best picture of the media should examine the answer SDP to obtain the best picture of the media
streams being established. streams being established.
As always, middleboxes can best do their job if they fully understand As always, middleboxes can best do their job if they fully understand
media capabilities negotiation. media capabilities negotiation.
7. Changes from previous versions 7. Changes from previous versions
7.1. Changes from version 04 7.1. Changes from version 08
The major change is in section 4.3 Latent Media Streams fixing the
syntax of the answer. All the other changes are editorial.
7.2. Changes from version 04
o The definitions for bcap, ccap, icap, and kcap attributes have o The definitions for bcap, ccap, icap, and kcap attributes have
been removed, and are to be defined in another document. been removed, and are to be defined in another document.
o Corrected formatting of m= and p= configuration parameters to o Corrected formatting of m= and p= configuration parameters to
conform to extension-config-list form defined in [SDPCapNeg] conform to extension-config-list form defined in [SDPCapNeg]
o Reorganized definitions of new parameters to make them easier to o Reorganized definitions of new parameters to make them easier to
find in document. find in document.
o Added ability to renegotiate capabilities when modifying the o Added ability to renegotiate capabilities when modifying the
session (Section 3.4.4). session (Section 3.4.4).
o Made various editorial changes, clarifications, and typo o Made various editorial changes, clarifications, and typo
corrections. corrections.
7.2. Changes from version 03 7.3. Changes from version 03
o A new session capability attribute (sescap) has been added to o A new session capability attribute (sescap) has been added to
permit specification of acceptable media stream combinations. permit specification of acceptable media stream combinations.
o Capability attribute definitions corresponding to the i, c, b, and o Capability attribute definitions corresponding to the i, c, b, and
k SDP line types have been added for completeness. k SDP line types have been added for completeness.
o Use of the pcfg: attribute in SDP answers has been included in o Use of the pcfg: attribute in SDP answers has been included in
order to conveniently return information in the answer about order to conveniently return information in the answer about
acceptable configurations in the media stream offer. acceptable configurations in the media stream offer.
skipping to change at page 44, line 8 skipping to change at page 43, line 15
o The description of the mscap attribute has been modified to make o The description of the mscap attribute has been modified to make
it clear that it should not be used to generate undefined SDP it clear that it should not be used to generate undefined SDP
attributes, or to "extend" existing attributes. attributes, or to "extend" existing attributes.
o <ms-parameters> are made optional in the mscap attribute o <ms-parameters> are made optional in the mscap attribute
definition. definition.
o "AMR" changed to "AMR-WB" in cases in which the sample rate is o "AMR" changed to "AMR-WB" in cases in which the sample rate is
16000. 16000.
7.3. Changes from version 02 7.4. Changes from version 02
This version contains several detail changes intended to simplify This version contains several detail changes intended to simplify
capability processing and mapping into conventional SDP media blocks. capability processing and mapping into conventional SDP media blocks.
o The "mcap" attribute is enhanced to include the role of the "ecap" o The "mcap" attribute is enhanced to include the role of the "ecap"
attribute; the latter is eliminated. attribute; the latter is eliminated.
o The "fcap" attribute has been renamed "mfcap". New replacement o The "fcap" attribute has been renamed "mfcap". New replacement
rules vis-a-vis fmtp attributes in the base media specification rules vis-a-vis fmtp attributes in the base media specification
have been added. have been added.
skipping to change at page 44, line 38 skipping to change at page 43, line 45
attribute. attribute.
o A new parameter, "mt=" is added to the latent configuration o A new parameter, "mt=" is added to the latent configuration
attribute (lcfg) to specify the media stream type (audio, video, attribute (lcfg) to specify the media stream type (audio, video,
etc.) when the lcfg is declared at the session level. etc.) when the lcfg is declared at the session level.
o The examples are expanded. o The examples are expanded.
o Numerous typos and misspellings have been corrected. o Numerous typos and misspellings have been corrected.
7.4. Changes from version 01 7.5. Changes from version 01
The documents adds a new attribute for specifying bandwidth The documents adds a new attribute for specifying bandwidth
capability and a parametr to list in the potential configuration. capability and a parametr to list in the potential configuration.
Other changes are to align the document with the terminolgy and Other changes are to align the document with the terminolgy and
attribute names from draft-ietf-mmusic-sdp-capability-negotiation-07. attribute names from draft-ietf-mmusic-sdp-capability-negotiation-07.
The document also clarifies some previous open issues. The document also clarifies some previous open issues.
7.5. Changes from version 00 7.6. Changes from version 00
The major changes include taking out the "mcap" and "cptmap" The major changes include taking out the "mcap" and "cptmap"
parameter. The mapping of payload type is now in the "pt" parameter parameter. The mapping of payload type is now in the "pt" parameter
of "pcfg". Media subtype need to explictly definesd in the "cmed" of "pcfg". Media subtype need to explictly definesd in the "cmed"
attribute if referenced in the "pcfg" attribute if referenced in the "pcfg"
8. Acknowledgements 8. Acknowledgements
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
skipping to change at page 47, line 8 skipping to change at page 47, line 8
Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
(AMR-WB) Audio Codecs", RFC 4867, April 2007. (AMR-WB) Audio Codecs", RFC 4867, April 2007.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
Authors' Addresses Authors' Addresses
Robert R Gilman Robert R Gilman
NDCI Independent
3243 W. 11th Ave. Dr.
Broomfield, CO 80020 Broomfield, CO 80020
USA USA
Email: bob_gilman@comcast.net Email: bob_gilman@comcast.net
Roni Even Roni Even
Gesher Erove Ltd Gesher Erove Ltd
14 David Hamelech 14 David Hamelech
Tel Aviv 64953 Tel Aviv 64953
Israel Israel
 End of changes. 23 change blocks. 
92 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/