< draft-ietf-mmusic-sdp-media-capabilities-14.txt | draft-ietf-mmusic-sdp-media-capabilities-15.txt > | |||
---|---|---|---|---|
MMUSIC R. Gilman | MMUSIC R. Gilman | |||
Internet-Draft Independent | Internet-Draft Independent | |||
Intended status: Standards Track R. Even | Updates: 5939 (if approved) R. Even | |||
Expires: January 10, 2013 Gesher Erove Ltd | Intended status: Standards Track Gesher Erove Ltd | |||
F. Andreasen | Expires: April 4, 2013 F. Andreasen | |||
Cisco Systems | Cisco Systems | |||
July 9, 2012 | October 1, 2012 | |||
SDP Media Capabilities Negotiation | Session Description Protocol (SDP) Media Capabilities Negotiation | |||
draft-ietf-mmusic-sdp-media-capabilities-14 | draft-ietf-mmusic-sdp-media-capabilities-15 | |||
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 | |||
transport protocols and attributes. In this document, we extend the | transport protocols and attributes. In this document, we extend the | |||
framework by defining media capabilities that can be used to | framework by defining media capabilities that can be used to | |||
negotiate media types and their associated parameters. | negotiate media types and their associated parameters. | |||
This document updates the IANA Considerations of RFC 5939. | ||||
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). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
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." | |||
This Internet-Draft will expire on January 10, 2013. | This Internet-Draft will expire on April 4, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 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 3, line 34 | skipping to change at page 3, line 34 | |||
3.4.2. Generating the Answer . . . . . . . . . . . . . . . . 39 | 3.4.2. Generating the Answer . . . . . . . . . . . . . . . . 39 | |||
3.4.3. Offerer Processing of the Answer . . . . . . . . . . . 43 | 3.4.3. Offerer Processing of the Answer . . . . . . . . . . . 43 | |||
3.4.4. Modifying the Session . . . . . . . . . . . . . . . . 43 | 3.4.4. Modifying the Session . . . . . . . . . . . . . . . . 43 | |||
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 | 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
4.1. Alternative Codecs . . . . . . . . . . . . . . . . . . . . 45 | 4.1. Alternative Codecs . . . . . . . . . . . . . . . . . . . . 45 | |||
4.2. Alternative Combinations of Codecs (Session | 4.2. Alternative Combinations of Codecs (Session | |||
Configurations) . . . . . . . . . . . . . . . . . . . . . 48 | Configurations) . . . . . . . . . . . . . . . . . . . . . 48 | |||
4.3. Latent Media Streams . . . . . . . . . . . . . . . . . . . 48 | 4.3. Latent Media Streams . . . . . . . . . . . . . . . . . . . 48 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 | |||
5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 51 | 5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 51 | |||
5.2. New SDP Option Tag . . . . . . . . . . . . . . . . . . . . 52 | 5.2. New SDP Capability Negotiation Option Tag . . . . . . . . 52 | |||
5.3. New SDP Capability Negotiation Parameters . . . . . . . . 52 | 5.3. SDP Capability Negotiation Configuration Parameters | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 53 | Registry . . . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
7. Changes from previous versions . . . . . . . . . . . . . . . . 54 | 5.4. SDP Capability Negotiation Configuration Parameter | |||
7.1. Changes from version 13 . . . . . . . . . . . . . . . . . 54 | Registrations . . . . . . . . . . . . . . . . . . . . . . 53 | |||
7.2. Changes from version 12 . . . . . . . . . . . . . . . . . 54 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 55 | |||
7.3. Changes from version 11 . . . . . . . . . . . . . . . . . 54 | 7. Changes from previous versions . . . . . . . . . . . . . . . . 56 | |||
7.4. Changes from version 10 . . . . . . . . . . . . . . . . . 54 | 7.1. Changes from version 14 . . . . . . . . . . . . . . . . . 56 | |||
7.5. Changes from version 09 . . . . . . . . . . . . . . . . . 55 | 7.2. Changes from version 13 . . . . . . . . . . . . . . . . . 56 | |||
7.6. Changes from version 08 . . . . . . . . . . . . . . . . . 55 | 7.3. Changes from version 12 . . . . . . . . . . . . . . . . . 56 | |||
7.7. Changes from version 04 . . . . . . . . . . . . . . . . . 55 | 7.4. Changes from version 11 . . . . . . . . . . . . . . . . . 56 | |||
7.8. Changes from version 03 . . . . . . . . . . . . . . . . . 56 | 7.5. Changes from version 10 . . . . . . . . . . . . . . . . . 56 | |||
7.9. Changes from version 02 . . . . . . . . . . . . . . . . . 56 | 7.6. Changes from version 09 . . . . . . . . . . . . . . . . . 57 | |||
7.10. Changes from version 01 . . . . . . . . . . . . . . . . . 57 | 7.7. Changes from version 08 . . . . . . . . . . . . . . . . . 57 | |||
7.11. Changes from version 00 . . . . . . . . . . . . . . . . . 57 | 7.8. Changes from version 04 . . . . . . . . . . . . . . . . . 57 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58 | 7.9. Changes from version 03 . . . . . . . . . . . . . . . . . 58 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 | 7.10. Changes from version 02 . . . . . . . . . . . . . . . . . 58 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 59 | 7.11. Changes from version 01 . . . . . . . . . . . . . . . . . 59 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 59 | 7.12. Changes from version 00 . . . . . . . . . . . . . . . . . 59 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 60 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 | ||||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 61 | ||||
9.2. Informative References . . . . . . . . . . . . . . . . . . 61 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63 | ||||
1. Introduction | 1. Introduction | |||
Session Description Protocol (SDP) capability negotiation [RFC5939] | Session Description Protocol (SDP) capability negotiation [RFC5939] | |||
provides a general framework for indicating and negotiating | provides a general framework for indicating and negotiating | |||
capabilities in SDP[RFC4566]. The base framework defines only | capabilities in SDP[RFC4566]. The base framework defines only | |||
capabilities for negotiating transport protocols and attributes. | capabilities for negotiating transport protocols and attributes. | |||
The [RFC5939] document lists some of the issues with the current SDP | The [RFC5939] document lists some of the issues with the current SDP | |||
capability negotiation process. An additional real life case is to | capability negotiation process. An additional real life case is to | |||
skipping to change at page 6, line 5 | skipping to change at page 5, line 33 | |||
configurations as combinations of media stream configurations. The | configurations as combinations of media stream configurations. The | |||
definitions of new attributes for media capability negotiation are | definitions of new attributes for media capability negotiation are | |||
chosen to make the translation from these attributes to | chosen to make the translation from these attributes to | |||
"conventional" SDP [RFC4566] media attributes as straightforward as | "conventional" SDP [RFC4566] media attributes as straightforward as | |||
possible in order to simplify implementation. This goal is intended | possible in order to simplify implementation. This goal is intended | |||
to reduce processing in two ways: each proposed configuration in an | to reduce processing in two ways: each proposed configuration in an | |||
offer may be easily translated into a conventional SDP media stream | offer may be easily translated into a conventional SDP media stream | |||
record for processing by the receiver; and the construction of an | record for processing by the receiver; and the construction of an | |||
answer based on a selected proposed configuration is straightforward. | answer based on a selected proposed configuration is straightforward. | |||
This document updates [RFC5939] by updating the IANA Considerations. | ||||
All other extensions defined in this document are considered | ||||
extensions above and beyond [RFC5939]. | ||||
2. Terminology | 2. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC2119 [RFC2119] and | document are to be interpreted as described in RFC2119 [RFC2119] and | |||
indicate requirement levels for compliant RTP implementations. | indicate requirement levels for compliant RTP implementations. | |||
"Actual Configuration": An actual configuration specifies which | "Actual Configuration": An actual configuration specifies which | |||
combinations of SDP session parameters and media stream components | combinations of SDP session parameters and media stream components | |||
can be used in the current offer/answer exchange and with what | can be used in the current offer/answer exchange and with what | |||
skipping to change at page 6, line 35 | skipping to change at page 6, line 35 | |||
or any other capability negotiation document. In an offer SDP, the | or any other capability negotiation document. In an offer SDP, the | |||
base configuration corresponds to the actual configuration as defined | base configuration corresponds to the actual configuration as defined | |||
in [RFC5939]. | in [RFC5939]. | |||
"Conventional Attribute": Any SDP attribute other than those defined | "Conventional Attribute": Any SDP attribute other than those defined | |||
by the series of capability negotiation specifications. | by the series of capability negotiation specifications. | |||
"Conventional SDP": An SDP record devoid of capability negotiation | "Conventional SDP": An SDP record devoid of capability negotiation | |||
attributes. | attributes. | |||
"Media Capability": A media format, typically a media subtype such as | "Media Format Capability": A media format, typically a media subtype | |||
PCMU, H263-1998, or T38. The media capability may also include media | such as PCMU, H263-1998, or T38, expressed in the form of a | |||
format parameters and associated attributes. | capability. | |||
"Media Format Parameter Capability": A media format parameter | ||||
("a=fmtp" in conventional SDP) expressed in the form of a capability. | ||||
The media format parameter capability is associated with a media | ||||
format capability. | ||||
"Media Capability": The combined set of capabilities associated with | ||||
expressing a media format and its relevant parameters (e.g. media | ||||
format parameters and media specific parameters). | ||||
"Potential Configuration": A potential configuration indicates which | "Potential Configuration": A potential configuration indicates which | |||
combinations of capabilities can be used for the session and its | combinations of capabilities can be used for the session and its | |||
associated media stream components. Potential configurations are not | associated media stream components. Potential configurations are not | |||
ready for use, however they are offered for potential use in the | ready for use, however they are offered for potential use in the | |||
current offer/answer exchange. They provide an alternative that may | current offer/answer exchange. They provide an alternative that may | |||
be used instead of the actual configuration, subject to negotiation | be used instead of the actual configuration, subject to negotiation | |||
in the current offer/answer exchange. See [RFC5939] for further | in the current offer/answer exchange. See [RFC5939] for further | |||
details. | details. | |||
skipping to change at page 10, line 5 | skipping to change at page 10, line 5 | |||
The solution consists of new capability attributes corresponding to | The solution consists of new capability attributes corresponding to | |||
conventional SDP line types, new parameters for the pcfg, acfg, and | conventional SDP line types, new parameters for the pcfg, acfg, and | |||
the new lcfg attributes extending the base attributes from [RFC5939], | the new lcfg attributes extending the base attributes from [RFC5939], | |||
and a use of the pcfg attribute to return capability information in | and a use of the pcfg attribute to return capability information in | |||
the SDP answer. | the SDP answer. | |||
Several new attributes are defined in a manner that can be related to | Several new attributes are defined in a manner that can be related to | |||
the capabilities specified in a media line, and its corresponding | the capabilities specified in a media line, and its corresponding | |||
rtpmap and fmtp attributes. | rtpmap and fmtp attributes. | |||
o A new media attribute ("a=rmcap") defines RTP-based media | o A new attribute ("a=rmcap") defines RTP-based media format | |||
capabilities in the form of a media subtype (e.g. "PCMU"), and | capabilities in the form of a media subtype (e.g. "PCMU"), and | |||
its encoding parameters (e.g. "/8000/2"). Each resulting media | its encoding parameters (e.g. "/8000/2"). Each resulting media | |||
format type/subtype capability has an associated handle called a | format type/subtype capability has an associated handle called a | |||
media capability number. The encoding parameters are as specified | media capability number. The encoding parameters are as specified | |||
for the rtpmap attribute defined in [RFC4566], without the payload | for the rtpmap attribute defined in [RFC4566], without the payload | |||
type number part. | type number part. | |||
o A new media attribute ("a=omcap") defines other (non RTP-based) | o A new attribute ("a=omcap") defines other (non RTP-based) media | |||
media capabilities in the form of a media subtype only (e.g. | format capabilities in the form of a media subtype only (e.g. | |||
"T38"). Each resulting media format type/subtype capability has | "T38"). Each resulting media format type/subtype capability has | |||
an associated handle called a media capability number. | an associated handle called a media capability number. | |||
o A new attribute ("a=mfcap") specifies media format parameters | o A new attribute ("a=mfcap") specifies media format parameters | |||
associated with one or more media capabilities. The mfcap | associated with one or more media format capabilities. The mfcap | |||
attribute is used primarily to associate the formatting | attribute is used primarily to associate the media format | |||
capabilities normally carried in the fmtp attribute. Note that | parameters normally carried in the fmtp attribute. Note that | |||
media format parameters can be used with RTP and non-RTP based | media format parameters can be used with RTP and non-RTP based | |||
media formats. | media formats. | |||
o A new attribute ("a=mscap") that specifies media parameters | o A new attribute ("a=mscap") that specifies media parameters | |||
associated with one or more media capabilities. The mscap | associated with one or more media format capabilities. The mscap | |||
attribute is used to associate capabilities with attributes other | attribute is used to associate capabilities with attributes other | |||
than fmtp or rtpmap, for example, the rtcp-fb attribute defined in | than fmtp or rtpmap, for example, the rtcp-fb attribute defined in | |||
[RFC4585]. | [RFC4585]. | |||
o A new attribute ("a=lcfg") specifies latent media stream | o A new attribute ("a=lcfg") specifies latent media stream | |||
configurations when no corresponding media line ("m=") is offered. | configurations when no corresponding media line ("m=") is offered. | |||
An example is the offer of latent configurations for video even | An example is the offer of latent configurations for video even | |||
though no video is currently offered. If the peer indicates | though no video is currently offered. If the peer indicates | |||
support for one or more offered latent configurations, the | support for one or more offered latent configurations, the | |||
corresponding media stream(s) may be added via a new offer/answer | corresponding media stream(s) may be added via a new offer/answer | |||
skipping to change at page 11, line 13 | skipping to change at page 11, line 13 | |||
of media capabilities (including their associated parameters) and | of media capabilities (including their associated parameters) and | |||
combinations thereof for the configuration. For example, the | combinations thereof for the configuration. For example, the | |||
"a=pcfg:" line might specify PCMU and telephone events [RFC4733] | "a=pcfg:" line might specify PCMU and telephone events [RFC4733] | |||
or G.729B and telephone events as acceptable configurations. The | or G.729B and telephone events as acceptable configurations. The | |||
"a=acfg:" line in the answer would specify the configuration | "a=acfg:" line in the answer would specify the configuration | |||
chosen. | chosen. | |||
o A new parameter type ("pt=") is added to the potential | o A new parameter type ("pt=") is added to the potential | |||
configuration, actual configuration, and latent configuration | configuration, actual configuration, and latent configuration | |||
attributes. This parameter associates RTP payload type numbers | attributes. This parameter associates RTP payload type numbers | |||
with the referenced RTP-based media capabilities, and is | with the referenced RTP-based media format capabilities, and is | |||
appropriate only when the transport protocol uses RTP. | appropriate only when the transport protocol uses RTP. | |||
o A new parameter type ("mt=") is used to specify the media type for | o A new parameter type ("mt=") is used to specify the media type for | |||
latent configurations. | latent configurations. | |||
Special processing rules are defined for capability attribute | Special processing rules are defined for capability attribute | |||
arguments in order to reduce the need to replicate essentially- | arguments in order to reduce the need to replicate essentially- | |||
identical attribute lines for the base configuration and potential | identical attribute lines for the base configuration and potential | |||
configurations. | configurations. | |||
skipping to change at page 11, line 38 | skipping to change at page 11, line 38 | |||
o Replacement rules are defined for the conventional SDP equivalents | o Replacement rules are defined for the conventional SDP equivalents | |||
of the mfcap and mscap capability attributes. This reduces the | of the mfcap and mscap capability attributes. This reduces the | |||
necessity to use the deletion qualifier in the a=pcfg parameter in | necessity to use the deletion qualifier in the a=pcfg parameter in | |||
order to ignore rtpmap, fmtp, and certain other attributes in the | order to ignore rtpmap, fmtp, and certain other attributes in the | |||
base configuration. | base configuration. | |||
o An argument concatenation rule is defined for mfcap attributes | o An argument concatenation rule is defined for mfcap attributes | |||
which refer to the same media capability number. This makes it | which refer to the same media capability number. This makes it | |||
convenient to combine format options concisely by associating | convenient to combine format options concisely by associating | |||
multiple mfcap lines with multiple media capabilities. | multiple mfcap lines with multiple media format capabilities. | |||
This document extends the base protocol extensions to the offer/ | This document extends the base protocol extensions to the offer/ | |||
answer model that allow for capabilities and potential configurations | answer model that allow for capabilities and potential configurations | |||
to be included in an offer. Media capabilities constitute | to be included in an offer. Media capabilities constitute | |||
capabilities that can be used in potential and latent configurations. | capabilities that can be used in potential and latent configurations. | |||
Whereas potential configurations constitute alternative offers that | Whereas potential configurations constitute alternative offers that | |||
may be accepted by the answerer instead of the actual | may be accepted by the answerer instead of the actual | |||
configuration(s) included in the "m=" line(s) and associated | configuration(s) included in the "m=" line(s) and associated | |||
parameters, latent configurations merely inform the other side of | parameters, latent configurations merely inform the other side of | |||
possible configurations supported by the entity. Those latent | possible configurations supported by the entity. Those latent | |||
skipping to change at page 13, line 43 | skipping to change at page 13, line 43 | |||
The "a=acap:1" line specified in the base protocol provides the | The "a=acap:1" line specified in the base protocol provides the | |||
"crypto" attribute which provides the keying material for SRTP using | "crypto" attribute which provides the keying material for SRTP using | |||
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, attribute capabilities and specified payload | transport capabilities, attribute capabilities and specified payload | |||
type number mappings. Three explicit alternatives are provided; the | type number mappings. Three explicit alternatives are provided; the | |||
lowest-numbered one is the preferred one. The "a=pcfg:1 ..." line | lowest-numbered one is the preferred one. The "a=pcfg:1 ..." line | |||
specifies media capabilities 4 and 5, i.e., G.729B and DTMF, or media | specifies media capabilities 4 and 5, i.e., G.729B and DTMF (incl. | |||
capability 1 and 5, i.e., G.729 and DTMF. Furthermore, it specifies | their associated media format parameters), or media capability 1 and | |||
transport protocol capability 1 (i.e. the RTP/SAVP profile - secure | 5, i.e., G.729 and DTMF (incl. their associated media format | |||
RTP), and the attribute capability 1, i.e. the crypto attribute | parameters). Furthermore, it specifies transport protocol capability | |||
provided. Lastly, it specifies a payload type number mapping for | 1 (i.e. the RTP/SAVP profile - secure RTP), and the attribute | |||
(RTP-based) media capabilities 1, 4, and 5, thereby permitting the | capability 1, i.e. the crypto attribute provided. Lastly, it | |||
offerer to distinguish between encrypted media and unencrypted media | specifies a payload type number mapping for (RTP-based) media | |||
received prior to receipt of the answer. | capabilities 1, 4, and 5, thereby permitting the offerer to | |||
distinguish between encrypted media and unencrypted media received | ||||
prior to receipt of the answer. | ||||
Use of unique payload type numbers in alternative configurations is | Use of unique payload type numbers in alternative configurations is | |||
not required; codecs such as AMR-WB [RFC4867] have the potential for | not required; codecs such as AMR-WB [RFC4867] have the potential for | |||
so many combinations of options that it may be impractical to define | so many combinations of options that it may be impractical to define | |||
unique payload type numbers for all supported combinations. If | unique payload type numbers for all supported combinations. If | |||
unique payload type numbers cannot be specified, then the offerer | unique payload type numbers cannot be specified, then the offerer | |||
will be obliged to wait for the SDP answer before rendering received | will be obliged to wait for the SDP answer before rendering received | |||
media. For SRTP using SDES inline keying [RFC4568], the offerer will | media. For SRTP using SDES inline keying [RFC4568], the offerer will | |||
still need to receive the answer before being able to decrypt the | still need to receive the answer before being able to decrypt the | |||
stream. | stream. | |||
skipping to change at page 15, line 25 | skipping to change at page 15, line 27 | |||
negotiation. The approach taken is to keep things similar to the | negotiation. The approach taken is to keep things similar to the | |||
existing media capabilities defined by the existing media | existing media capabilities defined by the existing media | |||
descriptions ("m=" lines) and the associated "rtpmap" and "fmtp" | descriptions ("m=" lines) and the associated "rtpmap" and "fmtp" | |||
attributes. We use media subtypes and "media capability numbers" to | attributes. We use media subtypes and "media capability numbers" to | |||
link the relevant media capability parameters. This permits the | link the relevant media capability parameters. This permits the | |||
capabilities to be defined at the session level and be used for | capabilities to be defined at the session level and be used for | |||
multiple streams, if desired. For RTP-based media formats, payload | multiple streams, if desired. For RTP-based media formats, payload | |||
types are then specified at the media level (see Section 3.3.4.2). | types are then specified at the media level (see Section 3.3.4.2). | |||
A media capability merely indicates possible support for the media | A media capability merely indicates possible support for the media | |||
type and media format(s) in question. In order to actually use a | type and media format(s) and parameters in question. In order to | |||
media capability in an offer/answer exchange, it MUST be referenced | actually use a media capability in an offer/answer exchange, it MUST | |||
in a potential configuration. | be referenced in a potential configuration. | |||
Media capabilities can be provided at the session-level and/or the | Media capabilities, i.e. the attributes associated with expressing | |||
media-level. Media capabilities provided at the session level may be | media capability formats, parameters, etc., can be provided at the | |||
referenced in any pcfg or lcfg attribute at the media level | session-level and/or the media-level. Media capabilities provided at | |||
(consistent with the media type), whereas media capabilities provided | the session level may be referenced in any pcfg or lcfg attribute at | |||
at the media level may be referenced only by the pcfg or lcfg | the media level (consistent with the media type), whereas media | |||
attribute within that media stream only. In either case, the scope | capabilities provided at the media level may be referenced only by | |||
of the <med-cap-num> is the entire session description. This enables | the pcfg or lcfg attribute within that media stream. In either case, | |||
each media capability to be uniquely referenced across the entire | the scope of the <med-cap-num> is the entire session description. | |||
session description (e.g. in a potential configuration). | This enables each media capability to be uniquely referenced across | |||
the entire session description (e.g. in a potential configuration). | ||||
3.3.1. The Media Format Capability Attributes | 3.3.1. The Media Format Capability Attributes | |||
Media subtypes can be expressed as media format capabilities by use | Media subtypes can be expressed as media format capabilities by use | |||
of the "a=rmcap" and "a=omcap" attributes. The "a=rmcap" attribute | of the "a=rmcap" and "a=omcap" attributes. The "a=rmcap" attribute | |||
MUST be used for RTP-based media whereas the "a=omcap" attribute MUST | MUST be used for RTP-based media whereas the "a=omcap" attribute MUST | |||
be used for non-RTP-based (other) media formats. The two attributes | be used for non-RTP-based (other) media formats. The two attributes | |||
are defined as follows: | are defined as follows: | |||
a=rmcap:<media-cap-num-list> <encoding-name>/<clock-rate> | a=rmcap:<media-cap-num-list> <encoding-name>/<clock-rate> | |||
skipping to change at page 16, line 14 | skipping to change at page 16, line 20 | |||
where <media-cap-num-list> is a (list of) media capability number(s) | where <media-cap-num-list> is a (list of) media capability number(s) | |||
used to number a media format capability, the <encoding name> or | used to number a media format capability, the <encoding name> or | |||
<format name> is the media subtype, e.g., H263-1998, PCMU, or T38, | <format name> is the media subtype, e.g., H263-1998, PCMU, or T38, | |||
<clock rate> is the encoding rate, and <encoding parms> are the media | <clock rate> is the encoding rate, and <encoding parms> are the media | |||
encoding parameters for the media subtype. All media format | encoding parameters for the media subtype. All media format | |||
capabilities in the list are assigned to the same media type/subtype. | capabilities in the list are assigned to the same media type/subtype. | |||
Each occurrence of the rmcap and omcap attribute MUST use unique | Each occurrence of the rmcap and omcap attribute MUST use unique | |||
values in their <media-cap-num-list>; the media capability numbers | values in their <media-cap-num-list>; the media capability numbers | |||
are shared between the two attributes and the numbers MUST be unique | are shared between the two attributes and the numbers MUST be unique | |||
across the entire SDP session. In short, the rmcap and omcap | across the entire SDP session. In short, the rmcap and omcap | |||
attributes define media capabilities and associate them with a media | attributes define media format capabilities and associate them with a | |||
capability number in the same manner as the rtpmap attribute defines | media capability number in the same manner as the rtpmap attribute | |||
them and associates them with a payload type number. Additionally, | defines them and associates them with a payload type number. | |||
the attributes allow multiple capability numbers to be defined for | Additionally, the attributes allow multiple capability numbers to be | |||
the media format in question. This permits the media format to be | defined for the media format in question. This permits the media | |||
associated with different media parameters in different | format to be associated with different media parameters in different | |||
configurations. | configurations. | |||
In ABNF, we have: | In ABNF [RFC5234], we have: | |||
media-capability-line = rtp-mcap / non-rtp-mcap | media-capability-line = rtp-mcap / non-rtp-mcap | |||
rtp-mcap = "a=rmcap:" media-cap-num-list | rtp-mcap = "a=rmcap:" media-cap-num-list | |||
1*WSP encoding-name "/" clock-rate | 1*WSP encoding-name "/" clock-rate | |||
["/" encoding-parms] | ["/" encoding-parms] | |||
non-rtp-mcap = "a=omcap:" media-cap-num-list 1*WSP format-name | non-rtp-mcap = "a=omcap:" media-cap-num-list 1*WSP format-name | |||
media-cap-num-list = media-cap-num-element | media-cap-num-list = media-cap-num-element | |||
*["," media-cap-num-element] | *("," media-cap-num-element) | |||
media-cap-num-element = media-cap-num | media-cap-num-element = media-cap-num | |||
/ media-cap-num-range | / media-cap-num-range | |||
media-cap-num-range = media-cap-num "-" media-cap-num | media-cap-num-range = media-cap-num "-" media-cap-num | |||
media-cap-num = 1*10(DIGIT) | media-cap-num = 1*10(DIGIT) | |||
encoding-name = token ; defined in RFC4566 | encoding-name = token ;defined in RFC4566 | |||
clock-rate = 1*10(DIGIT) | clock-rate = 1*10(DIGIT) | |||
encoding-parms = token | encoding-parms = token | |||
format-name = token ;defined in RFC4566 | format-name = token ;defined in RFC4566 | |||
The encoding-name, clock-rate and encoding-params are as defined to | The encoding-name, clock-rate and encoding-params are as defined to | |||
appear in an rtpmap attribute for each media type/subtype. Thus, it | appear in an rtpmap attribute for each media type/subtype. Thus, it | |||
is easy to convert an rmcap attribute line into one or more rtpmap | is easy to convert an rmcap attribute line into one or more rtpmap | |||
attribute lines, once a payload type number is assigned to a media- | attribute lines, once a payload type number is assigned to a media- | |||
cap-num (see Section 3.3.5). | cap-num (see Section 3.3.5). | |||
skipping to change at page 17, line 44 | skipping to change at page 17, line 50 | |||
m=audio 54320 RTP/AVP 0 | m=audio 54320 RTP/AVP 0 | |||
a=pcfg:1 m=1|2, pt=1:99,2:98 | a=pcfg:1 m=1|2, pt=1:99,2:98 | |||
m=video 66544 RTP/AVP 100 | m=video 66544 RTP/AVP 100 | |||
a=rtpmap:100 H264/90000 | a=rtpmap:100 H264/90000 | |||
a=pcfg:10 m=3 pt=3:101 | a=pcfg:10 m=3 pt=3:101 | |||
a=tcap:1 TCP | a=tcap:1 TCP | |||
a=pcfg:11 m=4 t=1 | a=pcfg:11 m=4 t=1 | |||
3.3.2. The Media Format Parameter Capability Attribute | 3.3.2. The Media Format Parameter Capability Attribute | |||
This attribute is used to associate media format specific format | This attribute is used to associate media format specific parameters | |||
parameters with one or more media capabilities. The form of the | with one or more media format capabilities. The form of the | |||
attribute is: | attribute is: | |||
a=mfcap:<media-caps> <list of parameters> | a=mfcap:<media-caps> <list of parameters> | |||
where <media-caps> permits the list of parameters to be associated | where <media-caps> permits the list of parameters to be associated | |||
with one or more media capabilities and the format parameters are | with one or more media format capabilities and the format parameters | |||
specific to the type of media format. The mfcap lines map to a | are specific to the type of media format. The mfcap lines map to a | |||
single traditional SDP fmtp attribute line (one for each entry in | single traditional SDP fmtp attribute line (one for each entry in | |||
<media-caps>) of the form | <media-caps>) of the form | |||
a=fmtp:<fmt> <list of parameters> | a=fmtp:<fmt> <list of parameters> | |||
where <fmt> is the media format description defined in RFC 4566 | where <fmt> is the media format parameter defined in RFC 4566 | |||
[RFC4566], as appropriate for the particular media stream. The mfcap | [RFC4566], as appropriate for the particular media stream. The mfcap | |||
attribute MUST be used to encode attributes for media capabilities, | attribute MUST be used to encode attributes for media capabilities, | |||
which would conventionally appear in an fmtp attribute. The existing | which would conventionally appear in an fmtp attribute. The existing | |||
acap attribute MUST NOT be used to encode fmtp attributes. | acap attribute MUST NOT be used to encode fmtp attributes. | |||
The mfcap attribute adheres to [RFC4566] attribute production rules | The mfcap attribute adheres to [RFC4566] attribute production rules | |||
with | with | |||
media-format-capability = "a=mfcap:" media-cap-num-list 1*WSP | media-format-parameter-capability = | |||
fmt-specific-param-list | "a=mfcap:" media-cap-num-list 1*WSP fmt-specific-param-list | |||
fmt-specific-param-list = text ; defined in RFC4566 | fmt-specific-param-list = text ; defined in RFC4566 | |||
Note that media format parameters can be used with RTP-based and non- | Note that media format parameters can be used with RTP-based and non- | |||
RTP based media formats. | RTP based media formats. | |||
3.3.2.1. Media Format Parameter Concatenation Rule | 3.3.2.1. Media Format Parameter Concatenation Rule | |||
The appearance of media subtypes with a large number of formatting | The appearance of media subtypes with a large number of formatting | |||
options (e.g., AMR-WB [RFC4867]) coupled with the restriction that | options (e.g., AMR-WB [RFC4867]) coupled with the restriction that | |||
only a single fmtp attribute can appear per media format, suggests | only a single fmtp attribute can appear per media format, suggests | |||
skipping to change at page 19, line 29 | skipping to change at page 19, line 33 | |||
session or media level. The unique media-cap-num is used to | session or media level. The unique media-cap-num is used to | |||
associate the parameters with a media capability. | associate the parameters with a media capability. | |||
As a simple example, a G.729 capability is, by default, considered to | As a simple example, a G.729 capability is, by default, considered to | |||
support comfort noise as defined by Annex B. Capabilities for G.729 | support comfort noise as defined by Annex B. Capabilities for G.729 | |||
with and without comfort noise support may thus be defined by: | with and without comfort noise support may thus be defined by: | |||
a=rmcap:1,2 G729/8000 | a=rmcap:1,2 G729/8000 | |||
a=mfcap:2 annexb:no | a=mfcap:2 annexb:no | |||
Media format capability 1 supports G.729 with Annex B, whereas media | Media capability 1 supports G.729 with Annex B, whereas media | |||
format capability 2 supports G.729 without Annex B. | capability 2 supports G.729 without Annex B. | |||
Example for H.263 video: | Example for H.263 video: | |||
a=rmcap:1 H263-1998/90000 | a=rmcap:1 H263-1998/90000 | |||
a=rmcap:2 H263-2000/90000 | a=rmcap:2 H263-2000/90000 | |||
a=mfcap:1 CIF=4;QCIF=2;F=1;K=1 | a=mfcap:1 CIF=4;QCIF=2;F=1;K=1 | |||
a=mfcap:2 profile=2;level=2.2 | a=mfcap:2 profile=2;level=2.2 | |||
Finally, for six format combinations of the Adaptive MultiRate codec: | Finally, for six format combinations of the Adaptive MultiRate codec: | |||
skipping to change at page 20, line 49 | skipping to change at page 21, line 5 | |||
attribute defined in [RFC4585]. Such media-specific attributes, | attribute defined in [RFC4585]. Such media-specific attributes, | |||
beyond the rtpmap and fmtp attributes, may be associated with media | beyond the rtpmap and fmtp attributes, may be associated with media | |||
capability numbers via a new media-specific attribute, mscap, of the | capability numbers via a new media-specific attribute, mscap, of the | |||
following form: | following form: | |||
a=mscap:<media caps star> <att field> <att value> | a=mscap:<media caps star> <att field> <att value> | |||
where <media caps star> is a (list of) media capability number(s), | where <media caps star> is a (list of) media capability number(s), | |||
<att field> is the attribute name, and <att value> is the value field | <att field> is the attribute name, and <att value> is the value field | |||
for the named attribute. Note that the media capability numbers | for the named attribute. Note that the media capability numbers | |||
refer to media capabilities specified elsewhere in the SDP ("rmcap" | refer to media format capabilities specified elsewhere in the SDP | |||
and/or "omcap"). The media capability numbers may include a wildcard | ("rmcap" and/or "omcap"). The media capability numbers may include a | |||
("*"), which will be used instead of any payload type mappings in the | wildcard ("*"), which will be used instead of any payload type | |||
resulting SDP (see, e.g. [RFC4585] and the example below). In ABNF, | mappings in the resulting SDP (see, e.g. [RFC4585] and the example | |||
we have: | below). In ABNF, we have: | |||
media-specific-capability = "a=mscap:" | media-specific-capability = "a=mscap:" | |||
media-caps-star | media-caps-star | |||
1*WSP att-field ; from RFC4566 | 1*WSP att-field ; from RFC4566 | |||
1*WSP att-value ; from RFC4566 | 1*WSP att-value ; from RFC4566 | |||
media-caps-star = media-cap-star-element | media-caps-star = media-cap-star-element | |||
*["," media-cap-star-element] | *("," media-cap-star-element) | |||
media-cap-star-element = media-cap-num [wildcard] | media-cap-star-element = (media-cap-num [wildcard]) | |||
/ media-cap-num-range [wildcard] | / (media-cap-num-range [wildcard]) | |||
wildcard = "*" | wildcard = "*" | |||
Given an association between a media capability and a payload type | Given an association between a media capability and a payload type | |||
number as specified by the pt= parameters in a pcfg attribute line, a | number as specified by the pt= parameters in a pcfg attribute line, a | |||
mscap line may be translated easily into a conventional SDP attribute | mscap line may be translated easily into a conventional SDP attribute | |||
line of the form | line of the form | |||
a=<att field>":"<fmt> <att value> ; <fmt> defined in [RFC4566] | a=<att field>":"<fmt> <att value> ; <fmt> defined in [RFC4566] | |||
A resulting attribute that is not a legal SDP attribute as specified | A resulting attribute that is not a legal SDP attribute as specified | |||
skipping to change at page 22, line 32 | skipping to change at page 22, line 35 | |||
3.3.4. New Configuration Parameters | 3.3.4. New Configuration Parameters | |||
Along with the new attributes for media capabilities, new extension | Along with the new attributes for media capabilities, new extension | |||
parameters are defined for use in the potential configuration, the | parameters are defined for use in the potential configuration, the | |||
actual configuration, and/or the new latent configuration defined in | actual configuration, and/or the new latent configuration defined in | |||
Section 3.3.5. | Section 3.3.5. | |||
3.3.4.1. The Media Configuration Parameter (m=) | 3.3.4.1. The Media Configuration Parameter (m=) | |||
The media configuration parameter is used to specify the media | The media configuration parameter is used to specify the media | |||
encoding(s) and related parameters for a potential, actual, or latent | format(s) and related parameters for a potential, actual, or latent | |||
configuration. Adhering to the ABNF for extension-config-list in | configuration. Adhering to the ABNF for extension-config-list in | |||
[RFC5939] with | [RFC5939] with | |||
ext-cap-name = "m" | ext-cap-name = "m" | |||
ext-cap-list = media-cap-num-list | ext-cap-list = media-cap-num-list | |||
[*(BAR media-cap-num-list)] | [*(BAR media-cap-num-list)] | |||
we have | we have | |||
media-config-list = ["+"]"m=" media-cap-num-list | media-config-list = ["+"] "m=" media-cap-num-list | |||
[*(BAR media-cap-num-list)] | *(BAR media-cap-num-list) | |||
; BAR is defined in RFC5939 | ;BAR is defined in RFC5939 | |||
; media-cap-num-list is defined above | ;media-cap-num-list is defined above | |||
Alternative media configurations are separated by a vertical bar | Alternative media configurations are separated by a vertical bar | |||
("|"). The alternatives are ordered by preference, most-preferred | ("|"). The alternatives are ordered by preference, most-preferred | |||
first. When media capabilities are not included in a potential | first. When media capabilities are not included in a potential | |||
configuration at the media level, the media type and media format | configuration at the media level, the media type and media format | |||
from the associated "m=" line will be used. The use of the plus sign | from the associated "m=" line will be used. The use of the plus sign | |||
("+") is described in RFC5939. | ("+") is described in RFC5939. | |||
3.3.4.2. The Payload Type Number Mapping Parameter (pt=) | 3.3.4.2. The Payload Type Number Mapping Parameter (pt=) | |||
The payload type number mapping parameter is used to specify the | The payload type number mapping parameter is used to specify the | |||
payload type number to be associated with each media type in a | payload type number to be associated with each RTP-based media format | |||
potential, actual, or latent configuration. We define the payload | in a potential, actual, or latent configuration. We define the | |||
type number mapping parameter, payload-number-config-list, in | payload type number mapping parameter, payload-number-config-list, in | |||
accordance with the extension-config-list format defined in | accordance with the extension-config-list format defined in | |||
[RFC5939]. In ABNF: | [RFC5939]. In ABNF: | |||
payload-number-config-list = ["+"]"pt=" media-map-list | payload-number-config-list = ["+"] "pt=" media-map-list | |||
media-map-list = media-map *["," media-map] | media-map-list = media-map *("," media-map) | |||
media-map = media-cap-num ":" payload-type-number | media-map = media-cap-num ":" payload-type-number | |||
; media-cap-num is defined in 3.3.1 | ; media-cap-num is defined in 3.3.1 | |||
payload-type-number = 1*3(DIGIT) ; RTP payload type number | payload-type-number = 1*3(DIGIT) ; RTP payload type number | |||
The example in Section 3.3.7 shows how the parameters from the rmcap | The example in Section 3.3.7 shows how the parameters from the rmcap | |||
line are mapped to payload type numbers from the pcfg "pt" parameter. | line are mapped to payload type numbers from the pcfg "pt" parameter. | |||
The use of the plus sign ("+") is described in [RFC5939]. | The use of the plus sign ("+") is described in [RFC5939]. | |||
A latent configuration represents a future capability, hence the pt= | A latent configuration represents a future capability, hence the pt= | |||
parameter is not directly meaningful in the lcfg attribute because no | parameter is not directly meaningful in the lcfg attribute because no | |||
actual media session is being offered or accepted; it is permitted in | actual media session is being offered or accepted; it is permitted in | |||
order to tie any payload type number parameters within attributes to | order to tie any payload type number parameters within attributes to | |||
skipping to change at page 25, line 18 | skipping to change at page 25, line 20 | |||
The latent configuration attribute is of the form: | The latent configuration attribute is of the form: | |||
a=lcfg:<config-number> <latent-cfg-list> | a=lcfg:<config-number> <latent-cfg-list> | |||
which adheres to the [RFC4566] "attribute" production with att-field | which adheres to the [RFC4566] "attribute" production with att-field | |||
and att-value defined as: | and att-value defined as: | |||
att-field = "lcfg" | att-field = "lcfg" | |||
att-value = config-number 1*WSP lcfg-cfg-list | att-value = config-number 1*WSP lcfg-cfg-list | |||
config-number = 1*10(DIGIT) ; defined in RFC5234 | config-number = 1*10(DIGIT) ; defined in RFC5234 | |||
lcfg-cfg-list = media-type 1*WSP pot-cfg-list | lcfg-cfg-list = media-type 1*WSP pot-cfg-list | |||
; as defined in RFC5939 | ; as defined in RFC5939 | |||
; and extended herein | ; and extended herein | |||
The media-type (mt=) parameter identifies the media type (audio, | The media-type (mt=) parameter identifies the media type (audio, | |||
video, etc.) to be associated with the latent media stream, and MUST | video, etc.) to be associated with the latent media stream, and MUST | |||
be present. The pot-cfg-list MUST contain a transport-protocol- | be present. The pot-cfg-list MUST contain a transport-protocol- | |||
config-list (t=) parameter and a media-config-list (m=) parameter. | config-list (t=) parameter and a media-config-list (m=) parameter. | |||
The pot-cfg-list MUST NOT contain more than one instance of each type | The pot-cfg-list MUST NOT contain more than one instance of each type | |||
of parameter list. As specified in [RFC5939], the use of the "+" | of parameter list. As specified in [RFC5939], the use of the "+" | |||
skipping to change at page 27, line 51 | skipping to change at page 28, line 7 | |||
included by the offerer, these capabilities MUST NOT be used to form | included by the offerer, these capabilities MUST NOT be used to form | |||
any base level media description in the answer. For this reason, it | any base level media description in the answer. For this reason, it | |||
is advisable for the offerer to include most, if not all, potential | is advisable for the offerer to include most, if not all, potential | |||
and latent configurations it can support in the initial offer, unless | and latent configurations it can support in the initial offer, unless | |||
the size of the resulting SDP is a concern. Either party MAY later | the size of the resulting SDP is a concern. Either party MAY later | |||
announce additional capabilities by renegotiating the session in a | announce additional capabilities by renegotiating the session in a | |||
second offer/answer exchange. | second offer/answer exchange. | |||
3.3.6.2. Payload Type Number Mapping | 3.3.6.2. Payload Type Number Mapping | |||
When media capabilities defined in rmcap attributes are used in | When media format capabilities defined in rmcap attributes are used | |||
potential configuration lines, the transport protocol uses RTP and it | in potential configuration lines, the transport protocol uses RTP and | |||
is necessary to assign payload type numbers. In some cases, it is | it is necessary to assign payload type numbers. In some cases, it is | |||
desirable to assign different payload type numbers to the same media | desirable to assign different payload type numbers to the same media | |||
capability when used in different potential configurations. One | format capability when used in different potential configurations. | |||
example is when configurations for AVP and SAVP are offered: the | One example is when configurations for AVP and SAVP are offered: the | |||
offerer would like the answerer to use different payload type numbers | offerer would like the answerer to use different payload type numbers | |||
for encrypted and unencrypted media so that it (the offerer) can | for encrypted and unencrypted media, so the offerer can decide | |||
decide whether or not to render early media which arrives before the | whether or not to render early media which arrives before the answer | |||
answer is received. | is received. | |||
For example, if use of AVP was selected by the answerer, then | For example, if use of AVP was selected by the answerer, then | |||
media received by the offerer is not encrypted and hence can be | media received by the offerer is not encrypted and hence can be | |||
played out prior to receiving the answer. Conversely, if SAVP was | played out prior to receiving the answer. Conversely, if SAVP was | |||
selected, cryptographic parameters and keying material present in | selected, cryptographic parameters and keying material present in | |||
the answer may be needed to decrypt received media. If the offer | the answer may be needed to decrypt received media. If the offer | |||
configuration indicated that AVP media uses one set of payload | configuration indicated that AVP media uses one set of payload | |||
types and SAVP a different set, then the offerer will know whether | types and SAVP a different set, then the offerer will know whether | |||
media received prior to the answer is encrypted or not by simply | media received prior to the answer is encrypted or not by simply | |||
looking at the RTP payload type number in the received packet. | looking at the RTP payload type number in the received packet. | |||
This association of distinct payload type number(s) with different | This association of distinct payload type number(s) with different | |||
transport protocols requires a separate pcfg line for each protocol. | transport protocols requires a separate pcfg line for each protocol. | |||
Clearly, this technique cannot be used if the number of potential | Clearly, this technique cannot be used if the number of potential | |||
configurations exceeds the number of possible payload type numbers. | configurations exceeds the number of possible payload type numbers. | |||
3.3.6.3. Processing of Media-Format-Related Conventional Attributes for | 3.3.6.3. Processing of Media-Format-Related Conventional Attributes for | |||
Potential Configurations | Potential Configurations | |||
In cases in which media capabilities negotiation is employed, SDP | When media capabilities negotiation is employed, SDP records are | |||
records are likely to contain conventional attributes such as rtpmap, | likely to contain conventional attributes such as rtpmap, fmtp, and | |||
fmtp, and other media-format-related lines, as well as capability | other media-format-related lines, as well as capability attributes | |||
attributes such as rmcap, omcap, mfcap, and mscap which map into | such as rmcap, omcap, mfcap, and mscap which map into those | |||
those conventional attributes when invoked by a potential | conventional attributes when invoked by a potential configuration. | |||
configuration. In such cases, it MAY be appropriate to employ the | In such cases, it MAY be appropriate to employ the delete-attributes | |||
delete-attributes option [RFC5939] in the attribute configuration | option [RFC5939] in the attribute configuration list parameter in | |||
list parameter in order to avoid the generation of conflicting fmtp | order to avoid the generation of conflicting fmtp attributes for a | |||
attributes for a particular configuration. Any media-specific | particular configuration. Any media-specific attributes in the media | |||
attributes in the media block which refer to media formats not used | block which refer to media formats not used by the potential | |||
by the potential configuration MUST be ignored. | configuration MUST be ignored. | |||
For example: | For example: | |||
v=0 | v=0 | |||
o=- 25678 753849 IN IP4 192.0.2.1 | o=- 25678 753849 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 | |||
a=creq:med-v0 | a=creq:med-v0 | |||
m=audio 3456 RTP/AVP 0 18 100 | m=audio 3456 RTP/AVP 0 18 100 | |||
skipping to change at page 31, line 29 | skipping to change at page 31, line 32 | |||
described by: | described by: | |||
"a=sescap:" <session num> <list of configs> | "a=sescap:" <session num> <list of configs> | |||
which corresponds to the standard value attribute definition with | which corresponds to the standard value attribute definition with | |||
att-field = "sescap" | att-field = "sescap" | |||
att-value = session-num 1*WSP list-of-configs | att-value = session-num 1*WSP list-of-configs | |||
[1*WSP optional-configs] | [1*WSP optional-configs] | |||
session-num = 1*10(DIGIT) ; defined in RFC5234 | session-num = 1*10(DIGIT) ; defined in RFC5234 | |||
list-of-configs = alt-config *["," alt-config] | list-of-configs = alt-config *("," alt-config) | |||
optional-configs = "[" list-of-configs "]" | optional-configs = "[" list-of-configs "]" | |||
alt-config = config-number *["|" config-number] | alt-config = config-number *("|" config-number) | |||
; config-number defined in RFC5939 | ; config-number defined in RFC5939 | |||
The session-num identifies the session; a lower-number session is | The session-num identifies the session; a lower-number session is | |||
preferred over a higher-numbered session. Each alt-config list | preferred over a higher-numbered session. Each alt-config list | |||
specifies alternative media configurations within the session; | specifies alternative media configurations within the session; | |||
preference is based on config-num as specified in [RFC5939]. Note | preference is based on config-num as specified in [RFC5939]. Note | |||
that the session preference order, when present, takes precedence | that the session preference order, when present, takes precedence | |||
over the individual media stream configuration preference order. | over the individual media stream configuration preference order. | |||
Use of session capability attributes requires that configuration | Use of session capability attributes requires that configuration | |||
skipping to change at page 35, line 22 | skipping to change at page 35, line 22 | |||
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. | |||
3.4. Offer/Answer Model Extensions | 3.4. Offer/Answer Model Extensions | |||
In this section, we define extensions to the offer/answer model | In this section, we define extensions to the offer/answer model | |||
defined in RFC 3264 [RFC3264] and RFC 5939 [RFC5939] to allow for | defined in RFC 3264 [RFC3264] and RFC 5939 [RFC5939] to allow for | |||
media capabilities and parameters, latent configurations and | media format and associated parameter capabilities, latent | |||
acceptable combinations of media stream configurations to be used | configurations and acceptable combinations of media stream | |||
with the SDP Capability Negotiation framework. Note that the | configurations to be used with the SDP Capability Negotiation | |||
procedures defined in this section extend the offer/answer procedures | framework. Note that the procedures defined in this section extend | |||
defined in [RFC5939] Section 6; those procedures form a baseline set | the offer/answer procedures defined in [RFC5939] Section 6; those | |||
of capability negotiation offer/answer procedures that MUST be | procedures form a baseline set of capability negotiation offer/answer | |||
followed, subject to the extensions defined here. | procedures that MUST be followed, subject to the extensions defined | |||
here. | ||||
The [RFC5939] provides a relatively compact means to offer the | The [RFC5939] provides a relatively compact means to offer the | |||
equivalent of an ordered list of alternative configurations for | equivalent of an ordered list of alternative configurations for | |||
offered media streams (as would be described by separate m= lines and | offered media streams (as would be described by separate m= lines and | |||
associated attributes). The attributes acap, mscap, mfcap and rmcap | associated attributes). The attributes acap, mscap, mfcap, omcap and | |||
are designed to map somewhat straightforwardly into equivalent m= | rmcap are designed to map somewhat straightforwardly into equivalent | |||
lines and conventional attributes when invoked by a pcfg, lcfg, or | m= lines and conventional attributes when invoked by a pcfg, lcfg, or | |||
acfg attribute with appropriate parameters. The a=pcfg: lines, along | acfg attribute with appropriate parameters. The a=pcfg: lines, along | |||
with the m= line itself, represent offered media configurations. The | with the m= line itself, represent offered media configurations. The | |||
a=lcfg: lines represent alternative capabilities for future use. | a=lcfg: lines represent alternative capabilities for future use. | |||
3.4.1. Generating the Initial Offer | 3.4.1. Generating the Initial Offer | |||
The Media Capabilities negotiation extensions defined in this | The Media Capabilities negotiation extensions defined in this | |||
document cover the following categories of features: | document cover the following categories of features: | |||
o Media Capabilities and associated parameters (rmcap, omcap, mfcap, | o Media Format Capabilities and associated parameters (rmcap, omcap, | |||
and mscap attributes) | mfcap, and mscap attributes) | |||
o Potential configurations using those media capabilities and | o Potential configurations using those media format capabilities and | |||
associated parameters | associated parameters | |||
o Latent media streams (lcfg attribute) | o Latent media streams (lcfg attribute) | |||
o Acceptable combinations of media stream configurations (sescap | o Acceptable combinations of media stream configurations (sescap | |||
attribute). | attribute). | |||
The high-level description of the operation is as follows: | The high-level description of the operation is as follows: | |||
When an endpoint generates an initial offer and wants to use the | When an endpoint generates an initial offer and wants to use the | |||
skipping to change at page 36, line 47 | skipping to change at page 36, line 47 | |||
required only for specific media descriptions, the "med-v0" value | required only for specific media descriptions, the "med-v0" value | |||
MUST be provided only in creq attributes within those media | MUST be provided only in creq attributes within those media | |||
descriptions, as described in [RFC5939]. | descriptions, as described in [RFC5939]. | |||
Below, we provide a more detailed description of how to construct the | Below, we provide a more detailed description of how to construct the | |||
offer SDP. | offer SDP. | |||
3.4.1.1. Offer with Media Capabilities | 3.4.1.1. Offer with Media Capabilities | |||
For each RTP-based media format the offerer wants to include as a | For each RTP-based media format the offerer wants to include as a | |||
media capability, the offer MUST include an "rmcap" attribute for the | media format capability, the offer MUST include an "rmcap" attribute | |||
media format as defined in Section 3.3.1. | for the media format as defined in Section 3.3.1. | |||
For each non RTP-based media format the offer wants to include as a | For each non RTP-based media format the offer wants to include as a | |||
media capability, the offer MUST include an "omcap" attribute for the | media format capability, the offer MUST include an "omcap" attribute | |||
media format as defined in Section 3.3.1. | for the media format as defined in Section 3.3.1. | |||
Since the media format capability number space is shared between the | Since the media capability number space is shared between the rmcap | |||
rmcap and omcap attributes, each media capability number provided | and omcap attributes, each media capability number provided | |||
(including ranges) MUST be unique in the entire SDP. | (including ranges) MUST be unique in the entire SDP. | |||
If an "fmtp" parameter value is needed for a media format (whether | If an "fmtp" parameter value is needed for a media format (whether | |||
RTP-based or not) in a media capability, then the offer MUST include | RTP-based or not) in a media capability, then the offer MUST include | |||
one or more "mfcap" parameters with the relevant fmtp parameter | one or more "mfcap" parameters with the relevant fmtp parameter | |||
values for that media format as defined in Section 3.3.2. When | values for that media format as defined in Section 3.3.2. When | |||
multiple "mfcap" parameters are provided for a given media | multiple "mfcap" parameters are provided for a given media | |||
capability, they MUST be provided in accordance with the | capability, they MUST be provided in accordance with the | |||
concatenation rules in Section 3.3.2.1. | concatenation rules in Section 3.3.2.1. | |||
For each of the media capabilities above, the offer MAY include one | For each of the media format capabilities above, the offer MAY | |||
or more "mscap" parameters with attributes needed for those specific | include one or more "mscap" parameters with attributes needed for | |||
media formats as defined in Section 3.3.3. Such attributes will be | those specific media formats as defined in Section 3.3.3. Such | |||
instantiated at the media-level, and hence session-level only | attributes will be instantiated at the media-level, and hence | |||
attributes MUST NOT be used in the "mscap" parameter. The "mscap" | session-level only attributes MUST NOT be used in the "mscap" | |||
parameter MUST NOT include an "rtpmap" or "fmtp" attribute (rmcap and | parameter. The "mscap" parameter MUST NOT include an "rtpmap" or | |||
mfcap are used instead). | "fmtp" attribute (rmcap and mfcap are used instead). | |||
If the offerer wants to limit the relevance (and use of) a media | If the offerer wants to limit the relevance (and use) of a media | |||
capability or parameter to a particular media stream, the media | format capability or parameter to a particular media stream, the | |||
capability or parameter MUST be provided within the corresponding | media format capability or parameter MUST be provided within the | |||
media description. Otherwise, the media capabilities and parameters | corresponding media description. Otherwise, the media format | |||
MUST be provided at the session level. Note however, that the | capabilities and parameters MUST be provided at the session level. | |||
attribute or parameter embedded in these will always be instantiated | Note however, that the attribute or parameter embedded in these will | |||
at the media-level. | always be instantiated at the media-level. | |||
This is due to those parameters being effectively media-level | This is due to those parameters being effectively media-level | |||
parameters. If session-level attributes are needed, the "acap" | parameters. If session-level attributes are needed, the "acap" | |||
attribute defined in [RFC5939] can be used, however it does not | attribute defined in [RFC5939] can be used, however it does not | |||
provide for media format-specific instantiation. | provide for media format-specific instantiation. | |||
Inclusion of the above does not constitute an offer to use the | Inclusion of the above does not constitute an offer to use the | |||
capabilities; a potential configuration is needed for that. If the | capabilities; a potential configuration is needed for that. If the | |||
offerer wants to offer one or more of the media capabilities above, | offerer wants to offer one or more of the media capabilities above, | |||
they MUST be included as part of a potential configuration (pcfg) | they MUST be included as part of a potential configuration (pcfg) | |||
skipping to change at page 39, line 32 | skipping to change at page 39, line 32 | |||
3.4.2. Generating the Answer | 3.4.2. Generating the Answer | |||
When receiving an offer, the answerer MUST check the offer for creq | When receiving an offer, the answerer MUST check the offer for creq | |||
attributes containing the value "med-v0"; answerers compliant with | attributes containing the value "med-v0"; answerers compliant with | |||
this specification will support this value in accordance with the | this specification will support this value in accordance with the | |||
procedures specified in [RFC5939]. | procedures specified in [RFC5939]. | |||
The SDP MAY contain | The SDP MAY contain | |||
o Media capabilities and associated parameters (rmcap, omcap, mfcap, | o Media format capabilities and associated parameters (rmcap, omcap, | |||
and mscap attributes) | mfcap, and mscap attributes) | |||
o Potential configurations using those media capabilities and | o Potential configurations using those media format capabilities and | |||
associated parameters | associated parameters | |||
o Latent media streams (lcfg attribute) | o Latent media streams (lcfg attribute) | |||
o Acceptable combinations of media stream configurations (sescap | o Acceptable combinations of media stream configurations (sescap | |||
attribute) | attribute) | |||
The high-level informative description of the operation is as | The high-level informative description of the operation is as | |||
follows: | follows: | |||
skipping to change at page 40, line 21 | skipping to change at page 40, line 21 | |||
of those configurations it might wish to offer in the future. | of those configurations it might wish to offer in the future. | |||
Below we provide a more detailed normative description of how the | Below we provide a more detailed normative description of how the | |||
answerer processes the offer SDP and generates an answer SDP. | answerer processes the offer SDP and generates an answer SDP. | |||
3.4.2.1. Processing Media Capabilities and Potential Configurations | 3.4.2.1. Processing Media Capabilities and Potential Configurations | |||
The answerer MUST first determine if it needs to perform media | The answerer MUST first determine if it needs to perform media | |||
capability negotiation by examining the SDP for valid and preferred | capability negotiation by examining the SDP for valid and preferred | |||
potential configuration attributes that include media configuration | potential configuration attributes that include media configuration | |||
parameters (i.e. an "m" parameter in the pcfg attribute). | parameters (i.e., an "m" parameter in the pcfg attribute). | |||
Such a potential configuration is valid if: | Such a potential configuration is valid if: | |||
1. It is valid according to the rules defined in [RFC5939] | 1. It is valid according to the rules defined in [RFC5939] | |||
2. It contains a config-number that is unique in the entire SDP and | 2. It contains a config-number that is unique in the entire SDP and | |||
does not overlap with any latent configuration config-numbers | does not overlap with any latent configuration config-numbers | |||
3. All media format capabilities (rmcap or omcap), media format | 3. All media format capabilities (rmcap or omcap), media format | |||
parameter capabilities (mfcap), and media-specific capabilities | parameter capabilities (mfcap), and media-specific capabilities | |||
(mscap) referenced by the potential configuration ("m" parameter) | (mscap) referenced by the potential configuration ("m" parameter) | |||
are valid themselves (as defined in Section 3.3.1, 3.3.2, and | are valid themselves (as defined in Section 3.3.1, 3.3.2, and | |||
3.3.3) and each of them is provided either at the session level | 3.3.3) and each of them is provided either at the session level | |||
or within this particular media description. | or within this particular media description. | |||
4. All RTP-based media capabilities (rmcap) have a corresponding | 4. All RTP-based media format capabilities (rmcap) have a | |||
payload type ("pt") parameter in the potential configuration that | corresponding payload type ("pt") parameter in the potential | |||
results in mapping to a valid payload type that is unique within | configuration that result in mapping to a valid payload type that | |||
the resulting SDP. | is unique within the resulting SDP. | |||
5. Any concatenation (see Section 3.3.2.1) and substitution (see | 5. Any concatenation (see Section 3.3.2.1) and substitution (see | |||
Section 3.3.7) applied to any capability (mfcap, mscap, or acap) | Section 3.3.7) applied to any capability (mfcap, mscap, or acap) | |||
referenced by this potential configuration results in a valid | referenced by this potential configuration results in a valid | |||
SDP. | SDP. | |||
Note that, since SDP does not interpret the value of fmtp parameters, | Note that, since SDP does not interpret the value of fmtp parameters, | |||
any resulting fmtp parameter value will be considered valid. | any resulting fmtp parameter value will be considered valid. | |||
Secondly, the answerer MUST determine the order in which potential | Secondly, the answerer MUST determine the order in which potential | |||
skipping to change at page 49, line 32 | skipping to change at page 49, line 32 | |||
a=lcfg:3 mt=message t=2 m=20 | a=lcfg:3 mt=message t=2 m=20 | |||
a=tcap:2 TCP/MSRP | a=tcap:2 TCP/MSRP | |||
a=omcap:20 * | a=omcap:20 * | |||
The first lcfg attribute line ("lcfg:2") announces support for H.263 | The first lcfg attribute line ("lcfg:2") announces support for H.263 | |||
and H.264 video (H.263 preferred) for future negotiation. The second | and H.264 video (H.263 preferred) for future negotiation. The second | |||
lcfg attribute line ("lcfg:3") announces support for MSRP for future | lcfg attribute line ("lcfg:3") announces support for MSRP for future | |||
negotiation. The m-line and the rtpmap attribute offer an audio | negotiation. The m-line and the rtpmap attribute offer an audio | |||
stream and provide the lowest precedence configuration (PCMU without | stream and provide the lowest precedence configuration (PCMU without | |||
any DTMF encoding). The rmcap lines define the RTP-based media | any DTMF encoding). The rmcap lines define the RTP-based media | |||
capabilities (PCMU, G729, telephone-event, H263-1998 and H264) and | format capabilities (PCMU, G729, telephone-event, H263-1998 and H264) | |||
the omcap line defines the non-RTP based media capability (wildcard). | and the omcap line defines the non-RTP based media format capability | |||
The mfcap attribute provides the format parameters for telephone- | (wildcard). The mfcap attribute provides the format parameters for | |||
events, specifying the 12 commercial DTMF 'digits'. The pcfg | telephone-events, specifying the 12 commercial DTMF 'digits'. The | |||
attribute line defines the most-preferred media configuration as PCMU | pcfg attribute line defines the most-preferred media configuration as | |||
plus DTMF events and the next-most-preferred configuration as G.729B | PCMU plus DTMF events and the next-most-preferred configuration as | |||
plus DTMF events. | G.729B plus DTMF events. | |||
If the answerer is able to support all the potential configurations, | If the answerer is able to support all the potential configurations, | |||
and also support H.263 video (but not H.264), it would reply with an | and also support H.263 video (but not H.264), it would reply with an | |||
answer like: | answer like: | |||
v=0 | v=0 | |||
o=- 24351 621814 IN IP4 192.0.2.2 | o=- 24351 621814 IN IP4 192.0.2.2 | |||
s= | s= | |||
c=IN IP4 192.0.2.2 | c=IN IP4 192.0.2.2 | |||
t=0 0 | t=0 0 | |||
skipping to change at page 51, line 12 | skipping to change at page 51, line 12 | |||
reconfiguration of the media stream to use G.729 in order to reduce | reconfiguration of the media stream to use G.729 in order to reduce | |||
packet sizes. | packet sizes. | |||
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: rmcap | Attribute name: rmcap | |||
Long form name: RTP-based media capability | Long form name: RTP-based media format capability | |||
Type of attribute: session-level and media-level | Type of attribute: session-level and media-level | |||
Subject to charset: no | Subject to charset: no | |||
Purpose: associate RTP-based media capability number(s) | Purpose: associate RTP-based media capability number(s) with | |||
with | media subtype and encoding parameters | |||
media subtype and encoding parameters | Appropriate Values: see Section 3.3.1 | |||
Appropriate Values: see Section 3.3.1 | Contact name: Flemming Andreasen, fandres@cisco.com | |||
Attribute name: omcap | Attribute name: omcap | |||
Long form name: Non RTP-based media capability | Long form name: Non RTP-based media format capability | |||
Type of attribute: session-level and media-level | Type of attribute: session-level and media-level | |||
Subject to charset: no | Subject to charset: no | |||
Purpose: associate non RTP-based media capability number(s) | Purpose: associate non RTP-based media capability number(s) with | |||
with | media subtype and encoding parameters | |||
media subtype and encoding parameters | Appropriate Values: see Section 3.3.1 | |||
Appropriate Values: see Section 3.3.1 | Contact name: Flemming Andreasen, fandreas@cisco.com | |||
Attribute name: mfcap | Attribute name: mfcap | |||
Long form name: media format capability | Long form name: media format parameter capability | |||
Type of attribute: session-level and media-level | Type of attribute: session-level and media-level | |||
Subject to charset: no | Subject to charset: no | |||
Purpose: associate media format attributes and | Purpose: associate media format attributes and | |||
parameters with media format capabilities | parameters with media format capabilities | |||
Appropriate Values: see Section 3.3.2 | Appropriate Values: see Section 3.3.2 | |||
Contact name: Flemming Andreasen, fandreas@cisco.com | ||||
Attribute name: mscap | Attribute name: mscap | |||
Long form name: media-specific capability | Long form name: media-specific capability | |||
Type of attribute: session-level and media-level | Type of attribute: session-level and media-level | |||
Subject to charset: no | Subject to charset: no | |||
Purpose: associate media-specific attributes and | Purpose: associate media-specific attributes and | |||
parameters with media capabilities | parameters with media capabilities | |||
Appropriate Values: see Section 3.3.3 | Appropriate Values: see Section 3.3.3 | |||
Contact name: Flemming Andreasen, fandreas@cisco.com | ||||
Attribute name: lcfg | Attribute name: lcfg | |||
Long form name: latent configuration | Long form name: latent configuration | |||
Type of attribute: media-level | Type of attribute: media-level | |||
Subject to charset: no | Subject to charset: no | |||
Purpose: to announce supportable media streams | Purpose: to announce supportable media streams | |||
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 | Contact name: Flemming Andreasen, fandreas@cisco.com | |||
Long form name: session capability | ||||
Type of attribute: session-level | ||||
Subject to charset: no | ||||
Purpose: to specify and prioritize acceptable | ||||
combinations of media stream configurations. | ||||
Appropriate Values: see Section 3.3.8 | ||||
5.2. New SDP Option Tag | Attribute name: sescap | |||
Long form name: session capability | ||||
Type of attribute: session-level | ||||
Subject to charset: no | ||||
Purpose: to specify and prioritize acceptable | ||||
combinations of media stream configurations. | ||||
Appropriate Values: see Section 3.3.8 | ||||
Contact name: Flemming Andreasen, fandreas@cisco.com | ||||
5.2. New SDP Capability Negotiation Option Tag | ||||
The IANA is hereby requested to add the new option tag "med-v0", | The IANA is hereby requested to add the new option tag "med-v0", | |||
defined in this document, to the SDP Capability Option Negotiation | defined in this document, to the SDP Capability Negotiation Option | |||
Capability registry created for [RFC5939]. | Capability registry created for [RFC5939]. | |||
5.3. New SDP Capability Negotiation Parameters | 5.3. SDP Capability Negotiation Configuration Parameters Registry | |||
The IANA is hereby requested to expand the SDP Capability Negotiation | The IANA is hereby requested to change the "SDP Capability | |||
Potential Configuration Parameter Registry established by [RFC5939] | Negotiation Potential Configuration Parameters" registry currently | |||
to become the SDP Capability Negotiation Configuration Parameter | registered and defined by [RFC5939] as follows: | |||
Registry and to include parameters for the potential, actual and | ||||
latent configuration attributes. The new parameters to be registered | The name of the registry should be "SDP Capability Negotiation | |||
are the "m" for "media", "pt" for "payload type number", and "mt" for | Configuration Parameters Registry" and it should contain a table with | |||
"media type" parameters. Note that the "mt" parameter is defined for | the following column headings: | |||
use only in the latent configuration attribute. | ||||
o Encoding Name: The syntactical value used for the capability | ||||
negotiation configuration parameter, as defined in [RFC5939], | ||||
Section 3.5. | ||||
o Descriptive Name: The name commonly used to refer to the | ||||
capability negotiation configuration parameter. | ||||
o Potential Configuration Definition: A reference to the RFC that | ||||
defines the configuration parameter in the context of a potential | ||||
configuration attribute. If the configuration parameter is not | ||||
defined for potential configurations, the string "N/A" (Not | ||||
Applicable) MUST be present instead. | ||||
o Actual Configuration Definition: A reference to the RFC that | ||||
defines the configuration parameter in the context of an actual | ||||
configuration attribute. If the configuration parameter is not | ||||
defined for actual configurations, the string "N/A" (Not | ||||
Applicable) MUST be present instead. | ||||
o Latent Configuration Definition: A reference to the RFC that | ||||
defines the configuration parameter in the context of a latent | ||||
configuration attribute. If the configuration parameter is not | ||||
defined for latent configurations, the string "N/A" (Not | ||||
Applicable) MUST be present instead. | ||||
An IANA SDP Capability Negotiation Configuration registration MUST be | ||||
documented in an RFC in accordance with the [RFC5226] IETF Review | ||||
policy. Furthermore: | ||||
o The RFC MUST define the syntax and semantics of each new potential | ||||
configuration parameter. | ||||
o The syntax MUST adhere to the syntax provided for extension | ||||
configuration lists in [RFC5939] Section 3.5.1 and the semantics | ||||
MUST adhere to the semantics provided for extension configuration | ||||
lists in [RFC5939] Section 3.5.1 and 3.5.2. | ||||
o Configuration parameters that apply to latent configurations MUST | ||||
furthermore adhere to the syntax provided in Section 3.3.5 and the | ||||
semantics defined overall in this document. | ||||
o Associated with each registration MUST be the encoding name for | ||||
the parameter as well as a short descriptive name for it. | ||||
o Each registration MUST specify if it applies to | ||||
* Potential configurations | ||||
* Actual configurations | ||||
* Latent configurations | ||||
5.4. SDP Capability Negotiation Configuration Parameter Registrations | ||||
The IANA is hereby requested to register the following capability | ||||
negotiation configuration parameters: | ||||
Encoding Name: a | ||||
Descriptive Name: Attribute Configuration | ||||
Potential Configuration Definition: [RFC5939] | ||||
Actual Configuration Definition: [RFC5939] | ||||
Latent Configuration Definition: [Note to RFC Editor: This RFC] | ||||
Encoding Name: t | ||||
Descriptive Name: Transport Protocol Configuration | ||||
Potential Configuration Definition: [RFC5939] | ||||
Actual Configuration Definition: [RFC5939] | ||||
Latent Configuration Definition: [Note to RFC Editor: This RFC] | ||||
Encoding Name: m | ||||
Descriptive Name: Media Configuration | ||||
Potential Configuration Definition: [Note to RFC Editor: This | ||||
RFC] | ||||
Actual Configuration Definition: [Note to RFC Editor: This RFC] | ||||
Latent Configuration Definition: [Note to RFC Editor: This RFC] | ||||
Encoding Name: pt | ||||
Descriptive Name: Payload Type Number Mapping | ||||
Potential Configuration Definition: [Note to RFC Editor: This | ||||
RFC] | ||||
Actual Configuration Definition: [Note to RFC Editor: This RFC] | ||||
Latent Configuration Definition: [Note to RFC Editor: This RFC] | ||||
Encoding Name: mt | ||||
Descriptive Name: Media Type | ||||
Potential Configuration Definition: N/A | ||||
Actual Configuration Definition: N/A | ||||
Latent Configuration Definition: [Note to RFC Editor: This RFC] | ||||
6. Security Considerations | 6. Security Considerations | |||
The security considerations of [RFC5939] apply for this document. | The security considerations of [RFC5939] apply for this document. | |||
In [RFC5939], it was noted that negotiation of transport protocols | In [RFC5939], it was noted that negotiation of transport protocols | |||
(e.g. secure and non-secure) and negotiation of keying methods and | (e.g. secure and non-secure) and negotiation of keying methods and | |||
material are potential security issues that warrant integrity | material are potential security issues that warrant integrity | |||
protection to remedy. Latent configuration support provides hints to | protection to remedy. Latent configuration support provides hints to | |||
the other side about capabilities supported for further offer/answer | the other side about capabilities supported for further offer/answer | |||
skipping to change at page 54, line 7 | skipping to change at page 56, line 7 | |||
feature. As for the initial CapNeg work [RFC5939], the SDP answer is | feature. As for the initial CapNeg work [RFC5939], the SDP answer is | |||
formulated in such a way that it always carries the selected media | formulated in such a way that it always carries the selected media | |||
encoding for every media stream selected. Pending an understanding | encoding for every media stream selected. Pending an understanding | |||
of capabilities negotiation, the middlebox should examine the answer | of capabilities negotiation, the middlebox should examine the answer | |||
SDP to obtain the best picture of the media streams being | SDP to obtain the best picture of the media streams being | |||
established. As always, middleboxes can best do their job if they | established. As always, middleboxes can best do their job if they | |||
fully understand media capabilities negotiation. | fully understand media capabilities negotiation. | |||
7. Changes from previous versions | 7. Changes from previous versions | |||
7.1. Changes from version 13 | 7.1. Changes from version 14 | |||
o Updated IANA Considerations to fix configuration parameter | ||||
registry. Document now updates [RFC5939] (IANA considerations | ||||
only) | ||||
o Minor ABNF updates to fix errors. | ||||
o Editorial nit fixes to address protocol write-up review. | ||||
7.2. Changes from version 13 | ||||
o Various editorial clarifications and updates to address review | o Various editorial clarifications and updates to address review | |||
comments. | comments. | |||
7.2. Changes from version 12 | 7.3. Changes from version 12 | |||
o Removed "dummy" form in the pcfg payload-type-number, since the | o Removed "dummy" form in the pcfg payload-type-number, since the | |||
functionality is redundant with the non-RTP media capability | functionality is redundant with the non-RTP media capability | |||
(omcap) and it was inconsistent with other RTP payload type | (omcap) and it was inconsistent with other RTP payload type | |||
operation. | operation. | |||
o Clarified that latent configuration attribute (lcfg) can only be | o Clarified that latent configuration attribute (lcfg) can only be | |||
used at the media level and hence (technically) as part of a media | used at the media level and hence (technically) as part of a media | |||
description | description | |||
o Rewrote offer/answer sections and expanded significantly on offer/ | o Rewrote offer/answer sections and expanded significantly on offer/ | |||
answer operation. | answer operation. | |||
o Updated security considerations | o Updated security considerations | |||
o Various minor editorial clarifications and changes. | o Various minor editorial clarifications and changes. | |||
7.3. Changes from version 11 | 7.4. Changes from version 11 | |||
o Corrected several statements implying lcfg was a session-level | o Corrected several statements implying lcfg was a session-level | |||
attribute. | attribute. | |||
o Added non-RTP based media format capabilities ("a=omcap") and | o Added non-RTP based media format capabilities ("a=omcap") and | |||
renamed "mcap" to "rmcap" | renamed "mcap" to "rmcap" | |||
7.4. Changes from version 10 | 7.5. Changes from version 10 | |||
o Defined the latent configuration attribute as a media-level | o Defined the latent configuration attribute as a media-level | |||
attribute because it specifies a possible future media stream. | attribute because it specifies a possible future media stream. | |||
Added text to clarify how to specify alternative configurations of | Added text to clarify how to specify alternative configurations of | |||
a single latent stream and/or multiple streams. | a single latent stream and/or multiple streams. | |||
o Improved the definition of the session capability attribute to | o Improved the definition of the session capability attribute to | |||
permit both required configurations and optional configurations - | permit both required configurations and optional configurations - | |||
latent configurations cannot be required because they have not yet | latent configurations cannot be required because they have not yet | |||
been offered. | been offered. | |||
skipping to change at page 55, line 17 | skipping to change at page 57, line 27 | |||
o Changed various "must", etc., terms to normative terms ("MUST", | o Changed various "must", etc., terms to normative terms ("MUST", | |||
etc.) as appropriate, in Section 3.3.5Section 3.3.6.1 | etc.) as appropriate, in Section 3.3.5Section 3.3.6.1 | |||
Section 3.3.6.3 and Section 3.3.8 | Section 3.3.6.3 and Section 3.3.8 | |||
o Attempted to clarify the substitution mechanism in Section 3.3.7 | o Attempted to clarify the substitution mechanism in Section 3.3.7 | |||
and improve its uniqueness. | and improve its uniqueness. | |||
o Made various editorial changes, including changing the title in | o Made various editorial changes, including changing the title in | |||
the header, and removing numbering from some SDP examples. | the header, and removing numbering from some SDP examples. | |||
7.5. Changes from version 09 | 7.6. Changes from version 09 | |||
o Additional corrections to latent media stream example in | o Additional corrections to latent media stream example in | |||
Section 4.3 | Section 4.3 | |||
o Fixed up attribute formatting examples and corresponding ABNF. | o Fixed up attribute formatting examples and corresponding ABNF. | |||
o Removed preference rule for latent configurations. | o Removed preference rule for latent configurations. | |||
o Various spelling and other editorial changes were made. | o Various spelling and other editorial changes were made. | |||
o updated cross-references. | o updated cross-references. | |||
7.6. Changes from version 08 | 7.7. Changes from version 08 | |||
The major change is in Section 4.3, Latent Media Streams, fixing the | The major change is in Section 4.3, Latent Media Streams, fixing the | |||
syntax of the answer. All the other changes are editorial. | syntax of the answer. All the other changes are editorial. | |||
7.7. Changes from version 04 | 7.8. 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 [RFC5939] | conform to extension-config-list form defined in [RFC5939] | |||
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.8. Changes from version 03 | 7.9. 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 56, line 38 | skipping to change at page 58, line 47 | |||
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.9. Changes from version 02 | 7.10. 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 57, line 19 | skipping to change at page 59, line 30 | |||
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.10. Changes from version 01 | 7.11. 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 parameter to list in the potential configuration. | capability and a parameter to list in the potential configuration. | |||
Other changes are to align the document with the terminology and | Other changes are to align the document with the terminology 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.11. Changes from version 00 | 7.12. 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 explicitly defined in the "cmed" | of "pcfg". Media subtype need to explicitly defined 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 59, line 19 | skipping to change at page 61, line 19 | |||
[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. | |||
[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, | with Session Description Protocol (SDP)", RFC 3264, | |||
June 2002. | June 2002. | |||
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | |||
Description Protocol", RFC 4566, July 2006. | Description Protocol", RFC 4566, July 2006. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | ||||
May 2008. | ||||
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
[RFC5939] Andreasen, F., "SDP Capability Negotiation", RFC 5939, | [RFC5939] Andreasen, F., "Session Description Protocol (SDP) | |||
September 2010. | Capability Negotiation", RFC 5939, September 2010. | |||
9.2. Informative References | 9.2. Informative References | |||
[RFC2198] "RTP Payload for Redundant Audio Data", September 1997. | [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., | |||
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- | ||||
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, | ||||
September 1997. | ||||
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session | [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session | |||
Description Protocol (SDP) Security Descriptions for Media | Description Protocol (SDP) Security Descriptions for Media | |||
Streams", RFC 4568, July 2006. | Streams", RFC 4568, July 2006. | |||
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | |||
"Extended RTP Profile for Real-time Transport Control | "Extended RTP Profile for Real-time Transport Control | |||
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | |||
July 2006. | July 2006. | |||
End of changes. 77 change blocks. | ||||
236 lines changed or deleted | 369 lines changed or added | |||
This html diff was produced by rfcdiff 1.39p1. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |