draft-ietf-mmusic-sdp-media-capabilities-04.txt   draft-ietf-mmusic-sdp-media-capabilities-05.txt 
MMUSIC R. Gilman MMUSIC R. Gilman
Internet-Draft NDCI Internet-Draft NDCI
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: January 13, 2009 Polycom Expires: January 15, 2009 Polycom
F. Andreasen F. Andreasen
Cisco Systems Cisco Systems
July 12, 2008 July 14, 2008
SDP media capabilities Negotiation SDP media capabilities Negotiation
draft-ietf-mmusic-sdp-media-capabilities-04.txt draft-ietf-mmusic-sdp-media-capabilities-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 13, 2009. This Internet-Draft will expire on January 15, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Session Description Protocol (SDP) capability negotiation provides a Session Description Protocol (SDP) capability negotiation provides a
general framework for indicating and negotiating capabilities in SDP. general framework for indicating and negotiating capabilities in SDP.
The base framework defines only capabilities for negotiating The base framework defines only capabilities for negotiating
skipping to change at page 6, line 47 skipping to change at page 6, line 47
REQ-04: Insure the scheme operates within the offer/answer model in REQ-04: Insure the scheme operates within the offer/answer model in
such a way that media formats and parameters can be agreed upon such a way that media formats and parameters can be agreed upon
with a single exchange. with a single exchange.
REQ-05: Provide the ability to express offers in such a way that REQ-05: Provide the ability to express offers in such a way that
the offerer can receive media as soon as the offer is sent. (Note the offerer can receive media as soon as the offer is sent. (Note
that the offerer may not be able to render received media prior to that the offerer may not be able to render received media prior to
exchange of keying material.) exchange of keying material.)
REQ-06: Provide the ability to offer latent media configurations REQ-06: Provide the ability to offer latent media configurations
for future negotiation or acceptance in the current offer/answer for future negotiation.
exchange.
REQ-07: Provide reasonable efficiency in the expression of REQ-07: Provide reasonable efficiency in the expression of
alternative media formats and/or format parameters, especially in alternative media formats and/or format parameters, especially in
those cases in which many combinations of options are offered. those cases in which many combinations of options are offered.
REQ-08: Retain the extensibility of the base capability negotiation REQ-08: Retain the extensibility of the base capability negotiation
mechanism. mechanism.
REQ-09: Provide the ability to specify acceptable combinations of REQ-09: Provide the ability to specify acceptable combinations of
media streams and encodings. For example, offer a PCMU audio media streams and encodings. For example, offer a PCMU audio
skipping to change at page 7, line 30 skipping to change at page 7, line 30
REQ-10: Provide capability negotiation attributes for all media- REQ-10: Provide capability negotiation attributes for all media-
level SDP line types in the same manner as already done for the level SDP line types in the same manner as already done for the
attribute type, with the exception of the media line type itself. attribute type, with the exception of the media line type itself.
The media line type is handled in a special way to permit compact The media line type is handled in a special way to permit compact
expression of media coding/format options. expression of media coding/format options.
Other possible extensions have been discussed, but have not been Other possible extensions have been discussed, but have not been
treated in this document. They may be considered in the future. Two treated in this document. They may be considered in the future. Two
such extensions are: such extensions are:
FUT-01: Provide the ability to mix, or change, MIMEmedia types FUT-01: Provide the ability to mix, or change, media types within a
within a single media block. Conventional SDP does not support single media block. Conventional SDP does not support this
this capability explicitly; the usual technique is to define a capability explicitly; the usual technique is to define a media
media subtype that represents the actual format within the nominal subtype that represents the actual format within the nominal media
media type. For example, T.38 FAX as an alternative to audio/PCMU type. For example, T.38 FAX as an alternative to audio/PCMU
within an audio stream is identified as audio/T38; a separate FAX within an audio stream is identified as audio/T38; a separate FAX
stream would use image/T38. stream would use image/T38.
FUT-02: Provide the ability to support multiple transport protocols FUT-02: Provide the ability to support multiple transport protocols
within an active media stream without reconfiguration. This is within an active media stream without reconfiguration. This is
not explicitly supported by conventional SDP. not explicitly supported by conventional SDP.
3.2. Solution Overview 3.2. Solution Overview
The solution consists of new capability attributes corresponding to The solution consists of new capability attributes corresponding to
skipping to change at page 10, line 51 skipping to change at page 10, line 51
attribute defined in [SDPCapNeg], with the option tag "med-v0", which attribute defined in [SDPCapNeg], with the option tag "med-v0", which
indicates that the extension framework defined here, must be indicates that the extension framework defined here, must be
supported. The Base level support is implied since it is required supported. The Base level support is implied since it is required
for the extensions. for the extensions.
The "m=" line indicates that Alice is offering to use plain RTP with The "m=" line indicates that Alice is offering to use plain RTP with
PCMU or G.729B. The media line implicitly defines the default PCMU or G.729B. The media line implicitly defines the default
transport protocol (RTP/AVP in this case) and the default actual transport protocol (RTP/AVP in this case) and the default actual
configuration. configuration.
The "a=tcap:1" line, specified in the base protocol, defines a The "a=tcap:1" line, specified in the base protocol, defines
transport protocol capabilities, in this case Secure RTP (SAVP transport protocol capabilities, in this case Secure RTP (SAVP
profile) as the first option and RTP (AVP profile) as the second profile) as the first option and RTP (AVP profile) as the second
option. option.
The "a=mcap:1,4" line defines two G.729 media format capabilities, The "a=mcap:1,4" line defines two G.729 media format capabilities,
numbered 1 and 4, and their encoding rate. The capabilities are of numbered 1 and 4, and their encoding rate. The capabilities are of
media type "audio" and subtype G729. Note that the media subtype is media type "audio" and subtype G729. Note that the media subtype is
explicitly specified here, rather than RTP payload type numbers. In explicitly specified here, rather than RTP payload type numbers. In
this example, two G.729 subtype capabilities are defined. This this example, two G.729 subtype capabilities are defined. This
permits the declaration of two sets of formatting parameters for permits the declaration of two sets of formatting parameters for
skipping to change at page 11, line 41 skipping to change at page 11, line 41
SDP security descriptions. SDP security descriptions.
The "a=pcfg:" attributes provide the potential configurations The "a=pcfg:" attributes provide the potential configurations
included in the offer by reference to the media capabilities, included in the offer by reference to the media capabilities,
transport capabilities, and associated payload type number mappings. transport capabilities, and associated payload type number mappings.
Three explicit alternatives are provided; the first one, numbered 1 Three explicit alternatives are provided; the first one, numbered 1
is the preferred one. It specifies media capabilities 4 and 5, i.e., is the preferred one. It specifies media capabilities 4 and 5, i.e.,
G.729B and DTMF, or media capability 1 and 5, i.e., G.729 and DTMF. G.729B and DTMF, or media capability 1 and 5, i.e., G.729 and DTMF.
Furthermore, it specifies transport protocol capability 1 (i.e. the Furthermore, it specifies transport protocol capability 1 (i.e. the
RTP/SAVP profile - secure RTP), and the attribute capability 1, i.e. RTP/SAVP profile - secure RTP), and the attribute capability 1, i.e.
the crypto attribute provided. Lastly, it specifies, a payload type the crypto attribute provided. Lastly, it specifies a payload type
number mapping for media capabilities 1, 4, and 5, thereby permitting number mapping for media capabilities 1, 4, and 5, thereby permitting
the offeror to distinguish between encrypted media and unencrypted the offeror to distinguish between encrypted media and unencrypted
media received prior to receipt of the answer. Use of unique payload media received prior to receipt of the answer. Use of unique payload
type numbers is not required; codecs such as AMR-WB [RFC4867] have type numbers is not required; codecs such as AMR-WB [RFC4867] have
the potential for so many combinations of options that it may be the potential for so many combinations of options that it may be
impractical to define unique payload type numbers for all supported impractical to define unique payload type numbers for all supported
combinations. If unique payload type numbers cannot be specified, combinations. If unique payload type numbers cannot be specified,
then the offerer will be obliged to wait for the SDP answer before then the offerer will be obliged to wait for the SDP answer before
rendering received media. For SRTP using SDES inline keying rendering received media. For SRTP using SDES inline keying
[RFC4568], the offeror will still need to receive the answer before [RFC4568], the offeror will still need to receive the answer before
skipping to change at page 14, line 30 skipping to change at page 14, line 30
The "mcap" attribute can be provided at the session-level and/or the The "mcap" attribute can be provided at the session-level and/or the
media-level. There can be more than one mcap attribute at the media-level. There can be more than one mcap attribute at the
session or media level. Each media-cap-num must be unique within the session or media level. Each media-cap-num must be unique within the
entire SDP record; it is used to identify that media capability in entire SDP record; it is used to identify that media capability in
potential, latent and actual configurations, and in other attribute potential, latent and actual configurations, and in other attribute
lines as explained below. When used in a potential, latent or actual lines as explained below. When used in a potential, latent or actual
configuration it is, in effect, a media level attribute regardless if configuration it is, in effect, a media level attribute regardless if
it is specified at the session or media level. In other words, the it is specified at the session or media level. In other words, the
media capability applies to the specific media description associated media capability applies to the specific media description associated
with the configuration which invoke it. with the configuration which invokes it.
For example: For example:
v=0 v=0
a=mcap:1 L16/8000/1 a=mcap:1 L16/8000/1
a=mcap:2 L16/16000/2 a=mcap:2 L16/16000/2
a=mcap:3,4 H263-1998/90000 a=mcap:3,4 H263-1998/90000
m=audio 54320 RTP/AVP 0 m=audio 54320 RTP/AVP 0
pcfg:1 m=1|2, pt=1:99,2:98 pcfg:1 m=1|2, pt=1:99,2:98
m=video 66544 RTP/AVP 100 m=video 66544 RTP/AVP 100
skipping to change at page 18, line 11 skipping to change at page 18, line 11
A single mscap line may refer to multiple media capabilities; this is A single mscap line may refer to multiple media capabilities; this is
equivalent to multiple mscap lines, each with the same attribute equivalent to multiple mscap lines, each with the same attribute
values, one line per media capability. values, one line per media capability.
Multiple mscap lines may refer to the same media capability, but, Multiple mscap lines may refer to the same media capability, but,
unlike the mfcap attribute, no concatenation operation is defined. unlike the mfcap attribute, no concatenation operation is defined.
Hence, multiple mscap lines applied to the same media capability is Hence, multiple mscap lines applied to the same media capability is
equivalent to multiple lines of the specified attribute in a equivalent to multiple lines of the specified attribute in a
conventional media record. conventional media record.
Here is example with the rtcp-fb attribute, modified from an example Here is an example with the rtcp-fb attribute, modified from an
in [RFC5104] (with the session-level and audio media omitted). If example in [RFC5104] (with the session-level and audio media
the offer contains a media block like the following, omitted). If the offer contains a media block like the following,
m=video 51372 RTP/AVP 98 m=video 51372 RTP/AVP 98
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=tcap:1 RTP/AVPF a=tcap:1 RTP/AVPF
a=mcap:1 H263-1998/90000 a=mcap:1 H263-1998/90000
a=mscap:1 rtcp-fb ccm tstr a=mscap:1 rtcp-fb ccm tstr
a=mscap:1 rtcp-fb ccm fir a=mscap:1 rtcp-fb ccm fir
a=mscap:* rtcp-fb ccm tmmbr smaxpr=120 a=mscap:* rtcp-fb ccm tmmbr smaxpr=120
a=pcfg:1 t=1 m=1 pt=1:98 a=pcfg:1 t=1 m=1 pt=1:98
skipping to change at page 19, line 37 skipping to change at page 19, line 37
<type> = <value> <type> = <value>
we define the corresponding capability attribute as we define the corresponding capability attribute as
a=<type-cap-attr> ":" <type-attr-num> 1*WSP <value> a=<type-cap-attr> ":" <type-attr-num> 1*WSP <value>
where where
<type-cap-attr> = <type> "cap" <type-cap-attr> = <type> "cap"
<type> = %x69 / ;"i"
<type> = %x69 / ; "i"
%x63 / ; "c" %x63 / ; "c"
%x62 / ; "b" %x62 / ; "b"
%x6b / ; "k" %x6b / ; "k"
%x61 / ; "a" %x61 / ; "a"
<type-attr-num> = 1*DIGIT ; integer, 1 to 2^31, inclusive <type-attr-num> = 1*DIGIT ; integer, 1 to 2^31, inclusive
where <value> is as defined specifically for each <type> in [RFC4566] where <value> is as defined specifically for each <type> in [RFC4566]
and, possibly, extended in other RFCs. The definitions above and, possibly, extended in other RFCs. The definitions above
correspond to the acap definition in [SDPCapNeg] and the ccap correspond to the acap definition in [SDPCapNeg] and the ccap
skipping to change at page 21, line 10 skipping to change at page 21, line 11
supportable media configurations in addition to those offered or supportable media configurations in addition to those offered or
accepted for immediate use. Such configurations are referred to as accepted for immediate use. Such configurations are referred to as
"latent configurations". For example, a party may offer to establish "latent configurations". For example, a party may offer to establish
a session with an audio stream, and, at the same time, announce its a session with an audio stream, and, at the same time, announce its
ability to support a video stream as part of the same session. The ability to support a video stream as part of the same session. The
offerer can supply its video capabilities by offering a latent video offerer can supply its video capabilities by offering a latent video
configuration along with the media stream for audio; the responding configuration along with the media stream for audio; the responding
party may indicate its ability and willingness to support such a party may indicate its ability and willingness to support such a
video session by returning a corresponding latent configuration. video session by returning a corresponding latent configuration.
Latent configurations returned in SDP answers must match latent Latent configurations returned in SDP answers must match offered
configurations (or parameter subsets thereof). Therefore, it is latent configurations (or parameter subsets thereof). Therefore, it
appropriate for the offering party to announce most, if not all, of is appropriate for the offering party to announce most, if not all,
its capabilities in the initial offer. [Editor's note: this choice of its capabilities in the initial offer. [Editor's note: this
has been made in order to keep the size of the answer more compact by choice has been made in order to keep the size of the answer more
not requiring acap, mcap, tcap, etc. lines in the answer. However, compact by not requiring acap, mcap, tcap, etc. lines in the answer.
this restriction can be changed if it seems desirable.] However, this restriction can be changed if it seems desirable.]
Latent configurations may be announced by use of the latent Latent configurations may be announced by use of the latent
configuration attribute, which is defined in a manner very similar to configuration attribute, which is defined in a manner very similar to
the potential configuration attribute. The media type (mt=) and the the potential configuration attribute. The media type (mt=) and the
transport protocol(s) (t=) MUST be specified since there is no transport protocol(s) (t=) MUST be specified since there is no
corresponding m-line for defaults. In most cases, the media corresponding m-line for defaults. In most cases, the media
configuration (m=) parameter must be present as well (see section configuration (m=) parameter must be present as well (see section
3.3.8 for examples). The lcfg attribute is a session level 3.3.8 for examples). The lcfg attribute is a session level
attribute, and all capability attributes referenced by lcfg attribute attribute, and all capability attributes referenced by lcfg attribute
parameters must appear at the session level in the SDP record. parameters must appear at the session level in the SDP record.
skipping to change at page 22, line 24 skipping to change at page 22, line 26
media-config-list = "m=" med-cap-list *(BAR med-cap-list) media-config-list = "m=" med-cap-list *(BAR med-cap-list)
; BAR is defined in [SDPCapNeg] ; BAR is defined in [SDPCapNeg]
med-cap-list = med-cap-num *("," med-cap-num) med-cap-list = med-cap-num *("," med-cap-num)
med-cap-num = 1*DIGIT ; defined in SDP med-cap-num = 1*DIGIT ; defined in SDP
Each potential media configuration is a comma-separated list of media Each potential media configuration is a comma-separated list of media
capability numbers where med-cap-num refers to media capability capability numbers where med-cap-num refers to media capability
numbers defined explicitly by a=mcap attributes and hence MUST be numbers defined explicitly by a=mcap attributes and hence MUST be
between 1 and 2^31-1 (both included). Alternative potential media between 1 and 2^31-1 (both included). Alternative potential media
configurations are separated by a vertical bar ("|"). The configurations are separated by a vertical bar ("|"). The
alternatives are ordered by preference. When media capabilities are alternatives are ordered by preference.
not included in a potential configuration at the media level, the
media type and media format from the associated "m=" line will be
used.
The attribute parameter (a=) is identical in format and meaning as The attribute parameter (a=) is identical in format and meaning as
defined for the pcfg attribute in [SDPCapNeg]. defined for the pcfg attribute in [SDPCapNeg].
We define the payload type number mapping parameter, pt-media-map, in We define the payload type number mapping parameter, pt-media-map, in
accordance with the following format: accordance with the following format:
payload-number-config-list = "pt=" med-map-list payload-number-config-list = "pt=" med-map-list
med-map-list = med-map *["," med-map] med-map-list = med-map *["," med-map]
med-map = med-cap-num ":" payload-type-number med-map = med-cap-num ":" payload-type-number
skipping to change at page 25, line 11 skipping to change at page 25, line 9
transport-protocol-config-list / ;defined in [SDPCapNeg] transport-protocol-config-list / ;defined in [SDPCapNeg]
extension-config-list / ;[SDPCapNeg] extension-config-list / ;[SDPCapNeg]
media-config-list / ;sect. 3.3.5 media-config-list / ;sect. 3.3.5
payload-number-config-list / ; 3.3.5 payload-number-config-list / ; 3.3.5
info-cap / ;defined in section 3.3.5 info-cap / ;defined in section 3.3.5
connection-config-list / ; 3.3.5 connection-config-list / ; 3.3.5
bandwidth-config-list / ; 3.3.5 bandwidth-config-list / ; 3.3.5
key-config-list ;section 3.3.5 key-config-list ;section 3.3.5
The pot-cfg-list MUST NOT contain more than one instance of each The pot-cfg-list MUST NOT contain more than one instance of each
parameter list other than the extension-config-list. parameter list other than the extension-config-list. When media
capabilities are not included in a potential configuration at the
media level, the media type and media format from the associated "m="
line will be used.
3.3.6.1. Returning Capabilities in the Answer 3.3.6.1. Returning Capabilities in the Answer
Potential configuration attributes may be returned within the media Potential configuration attributes may be returned within the media
block(s) of an answer SDP to indicate the ability of the answerer to block(s) of an answer SDP to indicate the ability of the answerer to
to support alternative configurations of the corresponding stream(s). to support alternative configurations of the corresponding stream(s).
For example, an offer may include multiple potential configurations For example, an offer may include multiple potential configurations
for a media stream; the corresponding answer will indicate (via an for a media stream; the corresponding answer will indicate (via an
acfg attribute) which configuration is accepted, but it MAY also acfg attribute) which configuration is accepted, but it MAY also
contain potential configuration attributes, with parameters, to contain potential configuration attributes, with parameters, to
skipping to change at page 27, line 17 skipping to change at page 27, line 17
s= s=
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
t=0 0 t=0 0
a=creq:med-v0 a=creq:med-v0
m=audio 3456 RTP/AVP 0 18 100 m=audio 3456 RTP/AVP 0 18 100
a=rtpmap:100 telephone-events a=rtpmap:100 telephone-events
a=fmtp:100 0-11 a=fmtp:100 0-11
a=mcap:1 PCMU/8000 a=mcap:1 PCMU/8000
a=mcap:2 g729/8000 a=mcap:2 g729/8000
a=mcap:3 telephone-event/8000 a=mcap:3 telephone-event/8000
a=mscap:3 fmtp 0-15 a=mfcap:3 0-15
a=pcfg:1 m=2,3|1,3 pt=1:0,2:18,3:100 a=pcfg:1 m=2,3|1,3 pt=1:0,2:18,3:100
In this example, PCMU is media capability 1, G729 is media capability In this example, PCMU is media capability 1, G729 is media capability
2, and telephone-event is media capability 3. The a=pcfg: line 2, and telephone-event is media capability 3. The a=pcfg: line
specifies that the preferred configuration is G.729 with extended specifies that the preferred configuration is G.729 with extended
dtmf events, second is G.711 mu-law with extended dtmf events. dtmf events, second is G.711 mu-law with extended dtmf events.
Intermixing of G.729, G.711, and "commercial" dtmf events is least Intermixing of G.729, G.711, and "commercial" dtmf events is least
preferred (the base configuration provided by the "m=" line, which is preferred (the base configuration provided by the "m=" line, which is
always the least preferred configuration). The rtpmap and fmtp always the least preferred configuration). The rtpmap and fmtp
attributes of the base configuration are replaced by the mcap and attributes of the base configuration are replaced by the mcap and
mscap attributes when invoked by the proposed configuration. mfcap attributes when invoked by the proposed configuration.
3.3.7. Substitution of Media Payload Type Numbers in Capability 3.3.7. Substitution of Media Payload Type Numbers in Capability
Attribute Parameters Attribute Parameters
In some cases, for example, when an RFC 2198 redundancy audio subtype In some cases, for example, when an RFC 2198 redundancy audio subtype
(RED) capability is defined in an mfcap attribute, the parameters to (RED) capability is defined in an mfcap attribute, the parameters to
an attribute may contain payload type numbers. Two options are an attribute may contain payload type numbers. Two options are
available for specifying such payload type numbers. They may be available for specifying such payload type numbers. They may be
expressed explicitly, in which case they are bound to actual payload expressed explicitly, in which case they are bound to actual payload
types by means of the payload type number parameter (pt=) in the types by means of the payload type number parameter (pt=) in the
skipping to change at page 32, line 37 skipping to change at page 32, line 37
[Editors' note: We have considered a form of the lcfg: attribute that [Editors' note: We have considered a form of the lcfg: attribute that
would permit an offerer to indicate that the configuration is would permit an offerer to indicate that the configuration is
available for immediate acceptance via an answer with a corresponding available for immediate acceptance via an answer with a corresponding
(new) m-line in the answer. This would permit the establishment of (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 the media streams to take place in one SDP exchange; at the same
time, non-negotiating endpoints could be offered a simple time, non-negotiating endpoints could be offered a simple
configuration as in the above example. Ultimately, when all configuration as in the above example. Ultimately, when all
endpoints understand the current specification, this would permit an endpoints understand the current specification, this would permit an
offer with latent configurations only, and an answer with the m-lines offer with latent configurations only, and an answer with the m-lines
for the accepted media streams. 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.
skipping to change at page 35, line 5 skipping to change at page 34, line 33
operating parameters of a session, e.g., by adding a new media operating parameters of a session, e.g., by adding a new media
stream, or by changing the properties used on an existing stream, it stream, or by changing the properties used on an existing stream, it
may do so via the mechanisms defined for offer/answer[RFC3264]. If may do so via the mechanisms defined for offer/answer[RFC3264]. If
the initiating party has remembered the codecs, potential the initiating party has remembered the codecs, potential
configurations, and latent configurations announced by the other configurations, and latent configurations announced by the other
party in the earlier negotiation, it may use this knowledge to party in the earlier negotiation, it may use this knowledge to
maximize the likelihood of a successful modification of the session. maximize the likelihood of a successful modification of the session.
Alternatively, it may perform a new capabilities exchange as part of Alternatively, it may perform a new capabilities exchange as part of
the reconfiguration. the reconfiguration.
"[Editors note: should a new offer/answer exchange replace all caps
from previous exchange(s)? This would permit an endpoint to remove
caps it can no longer support.]
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. Alternative Codecs 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
skipping to change at page 39, line 52 skipping to change at page 39, line 52
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=mcap:1 G729/8000
15. a=mcap:2 telephone-event/8000 15. a=mcap:2 telephone-event/8000
16. a=mfcap:2 0-11 16. a=mfcap:2 0-11
17. a=lcfg:2 m=1,2 pt=1:18,2:100 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 lines 14-17 announce the
latent capability to support G.711 mu-law with DTMF events as well. potential capability to support G.729 with DTMF events as well. If,
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. Note that line 13 uses media
capability numbering as provided in the original offer, whereas lines capability numbering as provided in the original offer, whereas lines
14-17 must use their own numbering. 14-17 must use their own numbering.
5. IANA Considerations 5. IANA Considerations
The IANA is hereby requested to register the following new SDP The IANA is hereby requested to register the following new SDP
attributes: attributes:
skipping to change at page 42, line 19 skipping to change at page 42, line 19
Attribute name: kcap Attribute name: kcap
Long form name: encryption key capability Long form name: encryption key capability
Type of attribute: media-level Type of attribute: media-level
Subject to charset: no Subject to charset: no
Purpose: associate encryption key with potential Purpose: associate encryption key with potential
or latent configurations. or latent configurations.
Appropriate Values: see Section 3.3.4 Appropriate Values: see Section 3.3.4
Attribute name: lcfg Attribute name: lcfg
Long form name: latent configuration Long form name: latent configuration
Type of attribute: session-level or media-level Type of attribute: session-level
Subject to charset: no Subject to charset: no
Purpose: to announce supportable media configurations Purpose: to announce supportable media configurations
without offering them for immediate use. without offering them for immediate use.
Appropriate Values: see Section 3.3.5 Appropriate Values: see Section 3.3.5
Attribute name: sescap Attribute name: sescap
Long form name: session capability Long form name: session capability
Type of attribute: session-level Type of attribute: session-level
Subject to charset: no Subject to charset: no
Purpose: to specify and prioritize acceptable Purpose: to specify and prioritize acceptable
 End of changes. 22 change blocks. 
37 lines changed or deleted 40 lines changed or added

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