Internet Engineering Task Force (IETF) R. Gilman
Request for Comments: 6871 Independent
Updates: 5939 R. Even
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 F. Andreasen
Cisco Systems
February 2013
Internet Engineering Task Force (IETF) R. Gilman
Request for Comments: 6871 Independent
Updates: 5939 R. Even
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 F. Andreasen
Cisco Systems
February 2013
Session Description Protocol (SDP) Media Capabilities Negotiation
会话描述协议（SDP）媒体能力协商
Abstract
摘要
Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters.
会话描述协议（SDP）能力协商为SDP中的能力指示和协商提供了一个通用框架。基本框架仅定义协商传输协议和属性的功能。本文档通过定义可用于协商媒体类型及其相关参数的媒体功能扩展了框架。
This document updates the IANA Considerations of RFC 5939.
本文件更新了RFC 5939的IANA注意事项。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6871.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6871.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................4
3. SDP Media Capabilities ..........................................6
3.1. Requirements ...............................................6
3.2. Solution Overview ..........................................7
3.3. New Capability Attributes .................................13
3.3.1. The Media Format Capability Attributes .............13
3.3.2. The Media Format Parameter Capability Attribute ....16
3.3.3. The Media-Specific Capability Attribute ............19
3.3.4. New Configuration Parameters .......................21
3.3.5. The Latent Configuration Attribute .................23
3.3.6. Enhanced Potential Configuration Attribute .........25
3.3.7. Substitution of Media Payload Type Numbers
in Capability ......................................29
3.3.8. The Session Capability Attribute ...................30
3.4. Offer/Answer Model Extensions .............................35
3.4.1. Generating the Initial Offer .......................35
3.4.2. Generating the Answer ..............................39
3.4.3. Offerer Processing of the Answer ...................43
3.4.4. Modifying the Session ..............................43
4. Examples .......................................................44
4.1. Alternative Codecs ........................................44
4.2. Alternative Combinations of Codecs (Session
Configurations) ...........................................47
4.3. Latent Media Streams ......................................47
5. IANA Considerations ............................................49
5.1. New SDP Attributes ........................................49
5.2. New SDP Capability Negotiation Option Tag .................50
5.3. SDP Capability Negotiation Configuration
Parameters Registry .......................................50
5.4. SDP Capability Negotiation Configuration Parameter
Registrations .............................................52
6. Security Considerations ........................................52
7. Acknowledgements ...............................................53
8. References .....................................................54
8.1. Normative References ......................................54
8.2. Informative References ....................................54
1. Introduction ....................................................4
2. Terminology .....................................................4
3. SDP Media Capabilities ..........................................6
3.1. Requirements ...............................................6
3.2. Solution Overview ..........................................7
3.3. New Capability Attributes .................................13
3.3.1. The Media Format Capability Attributes .............13
3.3.2. The Media Format Parameter Capability Attribute ....16
3.3.3. The Media-Specific Capability Attribute ............19
3.3.4. New Configuration Parameters .......................21
3.3.5. The Latent Configuration Attribute .................23
3.3.6. Enhanced Potential Configuration Attribute .........25
3.3.7. Substitution of Media Payload Type Numbers
in Capability ......................................29
3.3.8. The Session Capability Attribute ...................30
3.4. Offer/Answer Model Extensions .............................35
3.4.1. Generating the Initial Offer .......................35
3.4.2. Generating the Answer ..............................39
3.4.3. Offerer Processing of the Answer ...................43
3.4.4. Modifying the Session ..............................43
4. Examples .......................................................44
4.1. Alternative Codecs ........................................44
4.2. Alternative Combinations of Codecs (Session
Configurations) ...........................................47
4.3. Latent Media Streams ......................................47
5. IANA Considerations ............................................49
5.1. New SDP Attributes ........................................49
5.2. New SDP Capability Negotiation Option Tag .................50
5.3. SDP Capability Negotiation Configuration
Parameters Registry .......................................50
5.4. SDP Capability Negotiation Configuration Parameter
Registrations .............................................52
6. Security Considerations ........................................52
7. Acknowledgements ...............................................53
8. References .....................................................54
8.1. Normative References ......................................54
8.2. Informative References ....................................54
"Session Description Protocol (SDP) Capability Negotiation" [RFC5939] provides a general framework for indicating and negotiating capabilities in SDP [RFC4566]. The base framework defines only capabilities for negotiating transport protocols and attributes.
“会话描述协议（SDP）能力协商”[RFC5939]提供了在SDP[RFC4566]中指示和协商能力的通用框架。基本框架仅定义协商传输协议和属性的功能。
RFC 5939 [RFC5939] lists some of the issues with the current SDP capability negotiation process. An additional real-life problem is to be able to offer one media stream (e.g., audio) but list the capability to support another media stream (e.g., video) without actually offering it concurrently.
RFC 5939[RFC5939]列出了当前SDP能力协商过程中的一些问题。另一个现实问题是能够提供一个媒体流（例如音频），但列出支持另一个媒体流（例如视频）的能力，而不实际同时提供它。
In this document, we extend the framework by defining media capabilities that can be used to indicate and negotiate media types and their associated format parameters. This document also adds the ability to declare support for media streams, the use of which can be offered and negotiated later, and the ability to specify session configurations as combinations of media stream configurations. The definitions of new attributes for media capability negotiation are chosen to make the translation from these attributes to "conventional" SDP [RFC4566] media attributes as straightforward as possible in order to simplify implementation. This goal is intended to reduce processing in two ways: each proposed configuration in an offer may be easily translated into a conventional SDP media stream record for processing by the receiver and the construction of an answer based on a selected proposed configuration would be straightforward.
在本文档中，我们通过定义可用于指示和协商媒体类型及其相关格式参数的媒体功能来扩展该框架。本文档还添加了声明对媒体流的支持的功能（以后可以提供和协商使用），以及将会话配置指定为媒体流配置组合的功能。选择用于媒体能力协商的新属性的定义，以尽可能简单地将这些属性转换为“传统”SDP[RFC4566]媒体属性，从而简化实现。该目标旨在以两种方式减少处理：要约中的每个提议的配置可以容易地转换为常规SDP媒体流记录以供接收机处理，并且基于所选择的提议的配置构造应答将是简单的。
This document updates RFC 5939 [RFC5939] by updating the IANA considerations. All other extensions defined in this document are considered extensions above and beyond RFC 5939 [RFC5939].
本文件通过更新IANA注意事项来更新RFC 5939[RFC5939]。本文件中定义的所有其他扩展均被视为RFC 5939[RFC5939]之上和之外的扩展。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指出符合性实施的要求级别。
Actual Configuration: An actual configuration specifies which combinations of SDP session parameters and media stream components can be used in the current offer/answer exchange and with what parameters. Use of an actual configuration does not require any further negotiation in the offer/answer exchange. See RFC 5939 [RFC5939] for further details.
实际配置：实际配置指定可在当前提供/应答交换中使用SDP会话参数和媒体流组件的哪些组合以及使用哪些参数。使用实际配置不需要在报价/应答交换中进行进一步协商。有关更多详细信息，请参阅RFC 5939[RFC5939]。
Base Attributes: Conventional SDP attributes appearing in the base configuration of a media block.
基本属性：出现在媒体块基本配置中的常规SDP属性。
Base Configuration: The media configuration represented by a media block exclusive of all the capability negotiation attributes defined in this document, the base capability negotiation document [RFC5939], or any other capability negotiation document. In an offer SDP, the base configuration corresponds to the actual configuration as defined in RFC 5939 [RFC5939].
基本配置：由媒体块表示的媒体配置，不包括本文档、基本能力协商文档[RFC5939]或任何其他能力协商文档中定义的所有能力协商属性。在报价SDP中，基本配置对应于RFC 5939[RFC5939]中定义的实际配置。
Conventional Attribute: Any SDP attribute other than those defined by the series of capability negotiation specifications.
常规属性：除一系列能力协商规范定义的属性外的任何SDP属性。
Conventional SDP: An SDP record devoid of capability negotiation attributes.
常规SDP：没有能力协商属性的SDP记录。
Media Format Capability: A media format, typically a media subtype such as PCMU, H263-1998, or T38, expressed in the form of a capability.
媒体格式能力：以能力的形式表示的媒体格式，通常是媒体子类型，如PCMU、H263-1998或T38。
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.
媒体格式参数能力：以能力的形式表示的媒体格式参数（传统SDP中的“A=fmtp”）。媒体格式参数功能与媒体格式功能相关联。
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 combinations of capabilities can be used for the session and its associated media stream components. Potential configurations are not ready for use; however, they are offered for potential use in the current offer/answer exchange. They provide an alternative that may be used instead of the actual configuration, subject to negotiation in the current offer/answer exchange. See RFC 5939 [RFC5939] for further details.
潜在配置：潜在配置指示会话及其相关媒体流组件可以使用哪些功能组合。潜在配置尚未准备好使用；但是，它们在当前的报价/应答交换中提供了潜在用途。它们提供了一种替代方案，可替代实际配置，但需在当前的报价/应答交换中协商。有关更多详细信息，请参阅RFC 5939[RFC5939]。
Latent Configuration: A latent configuration indicates which combinations of capabilities could be used in a future negotiation for the session and its associated media stream components. Latent configurations are neither ready for use nor offered for actual or potential use in the current offer/answer exchange. Latent configurations merely inform the other side of possible configurations supported by the entity. Those latent configurations may be used to guide subsequent offer/answer exchanges, but they are not offered for use as part of the current offer/answer exchange.
潜在配置：潜在配置指示在会话及其相关媒体流组件的未来协商中可以使用哪些功能组合。潜在配置既不准备使用，也不提供用于当前提供/应答交换中的实际或潜在使用。潜在配置仅通知另一方实体支持的可能配置。这些潜在配置可用于指导后续的报价/应答交换，但不作为当前报价/应答交换的一部分提供。
The SDP capability negotiation [RFC5939] discusses the use of any SDP [RFC4566] attribute (a=) under the attribute capability "acap". The limitations of using "acap" for "fmtp" and "rtpmap" in a potential configuration are described in RFC 5939 [RFC5939]; for example, they can be used only at the media level since they are media-level attributes. RFC 5939 [RFC5939] does not provide a way to exchange media-level capabilities prior to the actual offer of the associated media stream. This section provides an overview of extensions providing an SDP media capability negotiation solution offering more robust capabilities negotiation. This is followed by definitions of new SDP attributes for the solution and its associated updated offer/answer procedures [RFC3264].
SDP能力协商[RFC5939]讨论了在属性能力“acap”下使用任何SDP[RFC4566]属性（a=）。RFC 5939[RFC5939]中描述了在潜在配置中使用“acap”表示“fmtp”和“rtpmap”的局限性；例如，它们只能在媒体级别使用，因为它们是媒体级别的属性。RFC 5939[RFC5939]未提供在实际提供相关媒体流之前交换媒体级功能的方法。本节概述了提供SDP媒体能力协商解决方案的扩展，该解决方案提供了更强大的协商能力。随后是解决方案的新SDP属性定义及其相关更新的报价/应答过程[RFC3264]。
The capability negotiation extensions requirements considered herein are as follows.
本文考虑的能力协商扩展要求如下。
REQ-01: Support the specification of alternative (combinations of) media formats (codecs) in a single media block.
REQ-01：支持在单个媒体块中指定替代（组合）媒体格式（编解码器）。
REQ-02: Support the specification of alternative media format parameters for each media format.
REQ-02：支持为每种媒体格式指定替代媒体格式参数。
REQ-03: Retain backward compatibility with conventional SDP. Ensure that each and every offered configuration can be easily translated into a corresponding SDP media block expressed with conventional SDP lines.
REQ-03：保持与传统SDP的向后兼容性。确保所提供的每种配置都能轻松转换为相应的SDP介质块，用常规SDP线表示。
REQ-04: Ensure that the scheme operates within the offer/answer model in such a way that media formats and parameters can be agreed upon with a single exchange.
REQ-04：确保方案在报价/应答模式下运行，媒体格式和参数可通过单一交换达成一致。
REQ-05: Provide the ability to express offers in such a way that the offerer can receive media as soon as the offer is sent. (Note that the offerer may not be able to render received media prior to exchange of keying material.)
REQ-05：提供表达报价的能力，使报价人能够在报价发出后立即接收媒体。（请注意，在交换键控材料之前，报价人可能无法提供收到的媒体。）
REQ-06: Provide the ability to offer latent media configurations for future negotiation.
REQ-06：提供潜在媒体配置以供将来协商的能力。
REQ-07: Provide reasonable efficiency in the expression of alternative media formats and/or format parameters, especially in those cases in which many combinations of options are offered.
REQ-07：在替代媒体格式和/或格式参数的表达中提供合理的效率，特别是在提供多种选项组合的情况下。
REQ-08: Retain the extensibility of the base capability negotiation mechanism.
REQ-08：保留基本能力协商机制的可扩展性。
REQ-09: Provide the ability to specify acceptable combinations of media streams and media formats. For example, offer a PCMU audio stream with an H264 video stream or a G729 audio stream with an H263 video stream. This ability would give the offerer a means to limit processing requirements for simultaneous streams. This would also permit an offer to include the choice of an audio/T38 stream or an image/T38 stream, but not both.
REQ-09：提供指定媒体流和媒体格式的可接受组合的能力。例如，提供带有H264视频流的PCMU音频流或带有H263视频流的G729音频流。这种能力将使报价人能够限制同步流的处理要求。这也允许报价包括音频/T38流或图像/T38流的选择，但不能同时包括两者。
Other possible extensions have been discussed, but have not been treated in this document. They may be considered in the future. Three such extensions are:
其他可能的扩展已经讨论过，但在本文档中没有讨论。将来可能会考虑这些问题。其中三项扩展是：
FUT-01: Provide the ability to mix, or change, media types within a single media block. Conventional SDP does not support this capability explicitly; the usual technique is to define a media subtype that represents the actual format within the nominal media type. For example, T.38 FAX as an alternative to audio/PCMU within an audio stream is identified as audio/T38; a separate FAX stream would use image/T38.
FUT-01：提供在单个媒体块中混合或更改媒体类型的功能。传统SDP不明确支持此功能；通常的技术是定义一个媒体子类型，它表示标称媒体类型中的实际格式。例如，作为音频流中的音频/PCMU的替代方案的T.38 FAX被标识为音频/T38；单独的传真流将使用image/T38。
FUT-02: Provide the ability to support multiple transport protocols within an active media stream without reconfiguration. This is not explicitly supported by conventional SDP.
FUT-02：提供在活动媒体流中支持多种传输协议的能力，而无需重新配置。传统SDP并不明确支持这一点。
FUT-03: Provide capability negotiation attributes for all media-level SDP line types in the same manner as already done for the attribute type, with the exception of the media line type itself. The media line type is handled in a special way to permit compact expression of media coding/format options. The line types are bandwidth ("b="), information ("i="), connection data ("c="), and, possibly, the deprecated encryption key ("k=").
FUT-03：以与属性类型相同的方式为所有媒体级SDP线路类型提供能力协商属性，但媒体线路类型本身除外。媒体行类型以特殊方式处理，以允许媒体编码/格式选项的紧凑表达。线路类型包括带宽（“b=”）、信息（“i=”）、连接数据（“c=”），可能还有不推荐使用的加密密钥（“k=”）。
The solution consists of new capability attributes corresponding to conventional SDP line types, new parameters for the "pcfg", "acfg", and the new "lcfg" attributes extending the base attributes from RFC 5939 [RFC5939], and a use of the "pcfg" attribute to return capability information in the SDP answer.
该解决方案包括与传统SDP线型对应的新能力属性、“pcfg”、“acfg”的新参数以及扩展RFC 5939[RFC5939]基本属性的新“lcfg”属性，以及使用“pcfg”属性在SDP应答中返回能力信息。
Several new attributes are defined in a manner that can be related to the capabilities specified in a media line, and its corresponding "rtpmap" and "fmtp" attributes.
以与媒体行中指定的功能及其相应的“rtpmap”和“fmtp”属性相关的方式定义了几个新属性。
o A new attribute ("a=rmcap") defines RTP-based media format capabilities in the form of a media subtype (e.g., "PCMU"), and its encoding parameters (e.g., "/8000/2"). Each resulting media format type/subtype capability has an associated handle called a media capability number. The encoding parameters are as specified for the "rtpmap" attribute defined in SDP [RFC4566], without the payload type number part.
o 一个新属性（“A=rmcap”）以媒体子类型（例如，“PCMU”）及其编码参数（例如“/8000/2”）的形式定义基于RTP的媒体格式功能。每个生成的媒体格式类型/子类型功能都有一个称为媒体功能编号的关联句柄。编码参数为SDP[RFC4566]中定义的“rtpmap”属性指定，不包含有效负载类型编号部分。
o A new attribute ("a=omcap") defines other (non-RTP-based) media format capabilities in the form of a media subtype only (e.g., "T38"). Each resulting media format type/subtype capability has an associated handle called a media capability number.
o 一个新属性（“A=omcap”）定义了其他（非基于RTP的）媒体格式功能，其形式仅为媒体子类型（例如，“T38”）。每个生成的媒体格式类型/子类型功能都有一个称为媒体功能编号的关联句柄。
o A new attribute ("a=mfcap") specifies media format parameters associated with one or more media format capabilities. The "mfcap" attribute is used primarily to associate the media format parameters normally carried in the "fmtp" attribute. Note that media format parameters can be used with RTP and non-RTP-based media formats.
o 新属性（“A=mfcap”）指定与一个或多个媒体格式功能关联的媒体格式参数。“mfcap”属性主要用于关联通常在“fmtp”属性中携带的媒体格式参数。请注意，媒体格式参数可用于RTP和基于非RTP的媒体格式。
o A new attribute ("a=mscap") specifies media parameters associated with one or more media format capabilities. The "mscap" attribute is used to associate capabilities with attributes other than "fmtp" or "rtpmap", for example, the "rtcp-fb" attribute defined in RFC 4585 [RFC4585].
o 新属性（“A=mscap”）指定与一个或多个媒体格式功能关联的媒体参数。“mscap”属性用于将能力与“fmtp”或“rtpmap”以外的属性相关联，例如，RFC 4585[RFC4585]中定义的“rtcp fb”属性。
o A new attribute ("a=lcfg") specifies latent media stream configurations when no corresponding media line ("m=") is offered. An example is the offer of latent configurations for video even though no video is currently offered. If the peer indicates support for one or more offered latent configurations, the corresponding media stream(s) may be added via a new offer/answer exchange.
o 一个新属性（“A=lcfg”）指定在没有提供相应的媒体线（“m=”）时的潜在媒体流配置。一个例子是为视频提供潜在配置，即使当前没有提供视频。如果对等方指示支持一个或多个提供的潜在配置，则可通过新的提供/应答交换添加相应的媒体流。
o A new attribute ("a=sescap") is used to specify an acceptable combination of simultaneous media streams and their configurations as a list of potential and/or latent configurations.
o 新属性（“A=sescap”）用于指定同步媒体流及其配置的可接受组合，作为潜在和/或潜在配置的列表。
New parameters are defined for the potential configuration ("pcfg"), latent configuration ("lcfg"), and accepted configuration ("acfg") attributes to associate the new attributes with particular configurations.
为潜在配置（“pcfg”）、潜在配置（“lcfg”）和可接受配置（“acfg”）属性定义了新参数，以将新属性与特定配置相关联。
o A new parameter type ("m=") is added to the potential configuration ("a=pcfg:") attribute and the actual configuration ("a=acfg:") attribute defined in RFC 5939 [RFC5939] and to the new latent configuration ("a=lcfg:") attribute. This permits specification of media capabilities (including their associated
o 新的参数类型（“m=”）添加到RFC 5939[RFC5939]中定义的潜在配置（“A=pcfg:”）属性和实际配置（“A=acfg:”）属性以及新的潜在配置（“A=lcfg:”）属性中。这允许指定媒体功能（包括其相关功能）
parameters) and combinations thereof for the configuration. For example, the "a=pcfg:" line might specify PCMU and telephone events [RFC4733] or G.729B and telephone events as acceptable configurations. The "a=acfg:" line in the answer would specify the configuration chosen.
参数）及其配置组合。例如，“a=pcfg:”行可以将PCMU和电话事件[RFC4733]或G.729B和电话事件指定为可接受的配置。答案中的“a=acfg:”行将指定所选的配置。
o A new parameter type ("pt=") is added to the potential configuration, actual configuration, and latent configuration attributes. This parameter associates RTP payload type numbers with the referenced RTP-based media format capabilities and is appropriate only when the transport protocol uses RTP.
o 潜在配置、实际配置和潜在配置属性中添加了一个新的参数类型（“pt=”）。此参数将RTP有效负载类型编号与参考的基于RTP的媒体格式功能相关联，并且仅当传输协议使用RTP时才适用。
o A new parameter type ("mt=") is used to specify the media type for latent configurations.
o 新的参数类型（“mt=”）用于指定潜在配置的介质类型。
Special processing rules are defined for capability attribute arguments in order to reduce the need to replicate essentially identical attribute lines for the base configuration and potential configurations.
为能力属性参数定义了特殊的处理规则，以减少复制基本配置和潜在配置的基本相同属性行的需要。
o A substitution rule is defined for any capability attribute to permit the replacement of the (escaped) media capability number with the media format identifier (e.g., the payload type number in audio/video profiles).
o 为任何能力属性定义替换规则，以允许使用媒体格式标识符（例如，音频/视频配置文件中的有效负载类型编号）替换（转义）媒体能力编号。
o Replacement rules are defined for the conventional SDP equivalents of the "mfcap" and "mscap" capability attributes. This reduces the necessity to use the deletion qualifier in the "a=pcfg" parameter in order to ignore "rtpmap", "fmtp", and certain other attributes in the base configuration.
o 替换规则是为“mfcap”和“mscap”能力属性的传统SDP等价物定义的。这减少了在“a=pcfg”参数中使用删除限定符以忽略基本配置中的“rtpmap”、“fmtp”和某些其他属性的必要性。
o An argument concatenation rule is defined for "mfcap" attributes that refer to the same media capability number. This makes it convenient to combine format options concisely by associating multiple mfcap lines with multiple media format capabilities.
o 为引用相同媒体功能编号的“mfcap”属性定义了参数串联规则。通过将多个mfcap行与多个媒体格式功能相关联，可以方便地简洁地组合格式选项。
This document extends the base protocol extensions to the offer/answer model that allow for capabilities and potential configurations to be included in an offer. Media capabilities constitute capabilities that can be used in potential and latent configurations. Whereas potential configurations constitute alternative offers that may be accepted by the answerer instead of the actual configuration(s) included in the "m=" line(s) and associated parameters, latent configurations merely inform the other side of possible configurations supported by the entity. Those latent configurations may be used to guide subsequent offer/answer exchanges, but they are not part of the current offer/answer exchange.
本文档将基本协议扩展扩展扩展到提供/应答模型，允许在提供中包含功能和潜在配置。媒体功能构成可用于潜在和潜在配置的功能。鉴于潜在配置构成了回答者可能接受的备选方案，而不是“m=”行和相关参数中包含的实际配置，潜在配置仅告知对方实体支持的可能配置。这些潜在配置可用于指导后续的报价/应答交换，但它们不是当前报价/应答交换的一部分。
The mechanism is illustrated by the offer/answer exchange below, where Alice sends an offer to Bob:
下面的要约/应答交换说明了该机制，其中Alice向Bob发送要约：
Alice Bob
| (1) Offer (SRTP and RTP) |
|--------------------------------->|
| |
| (2) Answer (RTP) |
|<---------------------------------|
| |
Alice Bob
| (1) Offer (SRTP and RTP) |
|--------------------------------->|
| |
| (2) Answer (RTP) |
|<---------------------------------|
| |
Alice's offer includes RTP and Secure Real-time Transport Protocol (SRTP) as alternatives. RTP is the default, but SRTP is the preferred one (long lines are folded to fit the margins):
Alice提供RTP和安全实时传输协议（SRTP）作为替代方案。RTP是默认设置，但SRTP是首选设置（长线折叠以适应边距）：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
m=audio 3456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP RTP/AVP
a=rtpmap:0 PCMU/8000/1
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=yes
a=rmcap:1,4 G729/8000/1
a=rmcap:2 PCMU/8000/1
a=rmcap:5 telephone-event/8000
a=mfcap:1 annexb=no
a=mfcap:4 annexb=yes
a=mfcap:5 0-11
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 \
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 m=4,5|1,5 t=1 a=1 pt=1:100,4:101,5:102
a=pcfg:2 m=2 t=1 a=1 pt=2:103
a=pcfg:3 m=4 t=2 pt=4:18
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
m=audio 3456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP RTP/AVP
a=rtpmap:0 PCMU/8000/1
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=yes
a=rmcap:1,4 G729/8000/1
a=rmcap:2 PCMU/8000/1
a=rmcap:5 telephone-event/8000
a=mfcap:1 annexb=no
a=mfcap:4 annexb=yes
a=mfcap:5 0-11
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 \
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 m=4,5|1,5 t=1 a=1 pt=1:100,4:101,5:102
a=pcfg:2 m=2 t=1 a=1 pt=2:103
a=pcfg:3 m=4 t=2 pt=4:18
The required base and extensions are provided by the "a=creq" attribute defined in RFC 5939 [RFC5939], with the option tag "med-v0", which indicates that the extension framework defined here must be supported. The base-level capability negotiation support ("cap-v0" [RFC5939]) is implied since it is required for the extensions.
RFC 5939[RFC5939]中定义的“a=creq”属性提供了所需的基本和扩展，选项标记为“med-v0”，这表明必须支持此处定义的扩展框架。由于扩展需要基本级能力协商支持（“cap-v0”[RFC5939]）。
The "m=" line indicates that Alice is offering to use plain RTP with PCMU or G.729B. The media line implicitly defines the default
“m=”行表示Alice提供将普通RTP与PCMU或G.729B一起使用。媒体行隐式定义默认值
transport protocol (RTP/AVP in this case) and the default actual configuration.
传输协议（本例中为RTP/AVP）和默认的实际配置。
The "a=tcap:1" line, specified in the SDP capability negotiation base protocol [RFC5939], defines transport protocol capabilities, in this case Secure RTP (SAVP profile) as the first option and RTP (AVP profile) as the second option.
SDP能力协商基础协议[RFC5939]中指定的“a=tcap:1”行定义了传输协议能力，在这种情况下，安全RTP（SAVP配置文件）作为第一个选项，RTP（AVP配置文件）作为第二个选项。
The "a=rmcap:1,4" line defines two G.729 RTP-based media format capabilities, numbered 1 and 4, and their encoding rate. The capabilities are of media type "audio" and subtype G729. Note that the media subtype is explicitly specified here, rather than RTP payload type numbers. This permits the assignment of payload type numbers in the media stream configuration specification. In this example, two G.729 subtype capabilities are defined. This permits the declaration of two sets of formatting parameters for G.729.
“a=rmcap:1,4”行定义了两个基于G.729 RTP的媒体格式功能，编号为1和4，以及它们的编码速率。这些功能为媒体类型“音频”和子类型G729。请注意，此处明确指定了媒体子类型，而不是RTP有效负载类型编号。这允许在媒体流配置规范中分配有效负载类型号。在本例中，定义了两个G.729子类型功能。这允许为G.729声明两组格式化参数。
The "a=rmcap:2" line defines a G.711 mu-law capability, numbered 2.
“a=rmcap:2”行定义了编号为2的G.711 mu法律能力。
The "a=rmcap:5" line defines an audio telephone-event capability, numbered 5.
“a=rmcap:5”行定义了音频电话事件功能，编号为5。
The "a=mfcap:1" line specifies the "fmtp" formatting parameters for capability 1 (offerer will not accept G.729 Annex B packets).
“a=mfcap:1”行指定能力1的“fmtp”格式参数（报价人不接受G.729附录B数据包）。
The "a=mfcap:4" line specifies the "fmtp" formatting parameters for capability 4 (offerer will accept G.729 Annex B packets).
“a=mfcap:4”行指定能力4的“fmtp”格式参数（报价人将接受G.729附录B数据包）。
The "a=mfcap:5" line specifies the "fmtp" formatting parameters for capability 5 (the dual-tone multi-frequency (DTMF) touchtones 0-9,*,#).
“a=mfcap:5”行指定功能5（双音多频（DTMF）按键0-9、*、#）的“fmtp”格式参数。
The "a=acap:1" line specified in the base protocol provides the "crypto" attribute that provides the keying material for SRTP using SDP security descriptions.
基本协议中指定的“a=acap:1”行提供“crypto”属性，该属性使用SDP安全描述为SRTP提供密钥材料。
The "a=pcfg:" attributes provide the potential configurations included in the offer by reference to the media capabilities, transport capabilities, attribute capabilities, and specified payload type number mappings. Three explicit alternatives are provided; the lowest-numbered one is the preferred one. The "a=pcfg:1 ..." line specifies media capabilities 4 and 5, i.e., G.729B and DTMF (including their associated media format parameters), or media capability 1 and 5, i.e., G.729 and DTMF (including their associated media format parameters). Furthermore, it specifies transport protocol capability 1 (i.e., the RTP/SAVP profile - secure RTP), and the attribute capability 1, i.e., the "crypto" attribute provided. Last, it specifies a payload type number mapping for (RTP-based)
“a=pcfg:”属性通过参考媒体功能、传输功能、属性功能和指定的有效负载类型号映射，提供报价中包含的潜在配置。提供了三个明确的备选方案；编号最低的是首选的。“a=pcfg:1…”行指定媒体功能4和5，即G.729B和DTMF（包括其相关媒体格式参数），或媒体功能1和5，即G.729和DTMF（包括其相关媒体格式参数）。此外，它还指定了传输协议能力1（即RTP/SAVP配置文件-安全RTP）和属性能力1，即提供的“加密”属性。最后，它为（基于RTP的）指定有效负载类型编号映射
media capabilities 1, 4, and 5, thereby permitting the offerer to distinguish between encrypted media and unencrypted media received prior to receipt of the answer.
媒体功能1、4和5，从而允许报价人在收到答复之前区分加密媒体和未加密媒体。
Use of unique payload type numbers in alternative configurations is not required; codecs such as Adaptive Multi-Rate Wideband (AMR-WB) [RFC4867] have the potential for 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 cannot be specified, then the offerer will be obliged to wait for the SDP answer before rendering received media. For SRTP using Security Descriptions (SDES) inline keying [RFC4568], the offerer will still need to receive the answer before being able to decrypt the stream.
在替代配置中不需要使用唯一的有效负载类型编号；诸如自适应多速率宽带（AMR-WB）[RFC4867]之类的编解码器可能有太多的选项组合，因此为所有支持的组合定义唯一的有效负载类型编号可能不切实际。如果无法指定唯一的有效负载类型编号，则报价人必须等待SDP应答，然后才能呈现收到的媒体。对于使用安全描述（SDE）内联键控[RFC4568]的SRTP，报价人仍然需要在能够解密流之前收到答案。
The second alternative ("a=pcfg:2 ...") specifies media capability 2, i.e., PCMU, under the RTP/SAVP profile, with the same SRTP key material.
第二个备选方案（“a=pcfg:2…”）指定RTP/SAVP配置文件下具有相同SRTP密钥材料的媒体功能2，即PCMU。
The third alternative ("a=pcfg:3 ...") offers G.729B unsecured; its only purpose in this example is to show a preference for G.729B over PCMU.
第三种选择（“a=pcfg:3…”）提供G.729B无担保；在本例中，其唯一目的是显示G.729B优于PCMU。
Per RFC 5939 [RFC5939], the media line, with any qualifying attributes such as "fmtp" or "rtpmap", is itself considered a valid configuration (the current actual configuration); it has the lowest preference (per RFC 5939 [RFC5939]).
根据RFC 5939[RFC5939]，具有任何限定属性（如“fmtp”或“rtpmap”）的媒体线本身被视为有效配置（当前实际配置）；它的首选项最低（根据RFC 5939[RFC5939]）。
Bob receives the SDP offer from Alice. Bob supports G.729B, PCMU, and telephone events over RTP, but not SRTP, hence he accepts the potential configuration 3 for RTP provided by Alice. Bob generates the following answer:
Bob收到Alice提供的SDP。Bob支持RTP上的G.729B、PCMU和电话事件，但不支持SRTP，因此他接受Alice提供的RTP的潜在配置3。Bob生成以下答案：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
a=csup:med-v0
m=audio 4567 RTP/AVP 18
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=acfg:3 m=4 t=2 pt=4:18
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
a=csup:med-v0
m=audio 4567 RTP/AVP 18
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=acfg:3 m=4 t=2 pt=4:18
Bob includes the "a=csup" and "a=acfg" attributes in the answer to inform Alice that he can support the med-v0 level of capability negotiations. Note that in this particular example, the answerer supported the capability extensions defined here; however, had he not, he would simply have processed the offer based on the offered
Bob在回答中包括“a=csup”和“a=acfg”属性，以告知Alice他可以支持med-v0级别的能力协商。注意，在这个特定示例中，应答者支持此处定义的功能扩展；然而，如果他不这样做，他只会根据提供的信息处理该提议
PCMU and G.729 codecs under the RTP/AVP profile only. Consequently, the answer would have omitted the "a=csup" attribute line and chosen one or both of the PCMU and G.729 codecs instead. The answer carries the accepted configuration in the "m=" line along with corresponding "rtpmap" and/or "fmtp" parameters, as appropriate.
仅RTP/AVP配置文件下的PCMU和G.729编解码器。因此，答案将省略“a=csup”属性行，而选择PCMU和G.729编解码器中的一个或两个。答案在“m=”行中包含接受的配置以及相应的“rtpmap”和/或“fmtp”参数（视情况而定）。
Note that per the base protocol, after the above, Alice MAY generate a new offer with an actual configuration ("m=" line, etc.) corresponding to the actual configuration referenced in Bob's answer (not shown here).
请注意，根据基本协议，在上述操作之后，Alice可能会生成一个新的报价，其实际配置（“m=”line等）对应于Bob答案中引用的实际配置（此处未显示）。
In this section, we present the new attributes associated with indicating the media capabilities for use by the SDP capability negotiation. The approach taken is to keep things similar to the existing media capabilities defined by the existing media descriptions ("m=" lines) and the associated "rtpmap" and "fmtp" attributes. We use media subtypes and "media capability numbers" to link the relevant media capability parameters. This permits the capabilities to be defined at the session level and be used for multiple streams, if desired. For RTP-based media formats, payload types are then specified at the media level (see Section 3.3.4.2).
在本节中，我们将介绍与指示SDP能力协商使用的媒体能力相关的新属性。所采取的方法是保持与现有媒体描述（“m=”行）以及相关的“rtpmap”和“fmtp”属性所定义的现有媒体功能相似。我们使用媒体子类型和“媒体能力编号”链接相关媒体能力参数。这允许在会话级别定义功能，并在需要时用于多个流。对于基于RTP的媒体格式，然后在媒体级别指定有效负载类型（见第3.3.4.2节）。
A media capability merely indicates possible support for the media type and media format(s) and parameters in question. In order to actually use a media capability in an offer/answer exchange, it MUST be referenced in a potential configuration.
媒体功能仅表示可能支持所讨论的媒体类型、媒体格式和参数。为了在报价/应答交换中实际使用媒体功能，必须在潜在配置中引用它。
Media capabilities, i.e., the attributes associated with expressing media capability formats, parameters, etc., can be provided at the session level and/or the media level. Media capabilities provided at the session level may be referenced in any "pcfg" or "lcfg" attribute at the media level (consistent with the media type), whereas media capabilities provided at the media level may be referenced only by the "pcfg" or "lcfg" attribute within that media stream. In either case, the scope of the <med-cap-num> is the entire session description. This enables each media capability to be uniquely referenced across the entire session description (e.g., in a potential configuration).
媒体能力，即与表达媒体能力格式、参数等相关联的属性，可以在会话级别和/或媒体级别提供。在会话级别提供的媒体功能可以在媒体级别的任何“pcfg”或“lcfg”属性中引用（与媒体类型一致），而在媒体级别提供的媒体功能只能由该媒体流中的“pcfg”或“lcfg”属性引用。在任何一种情况下，<med cap num>的范围都是整个会话描述。这使得每个媒体功能都可以在整个会话描述中唯一引用（例如，在潜在配置中）。
Media subtypes can be expressed as media format capabilities by use 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 be used for non-RTP-based (other) media formats. The two attributes are defined as follows:
通过使用“a=rmcap”和“a=omcap”属性，可以将媒体子类型表示为媒体格式功能。“a=rmcap”属性必须用于基于RTP的媒体，而“a=omcap”属性必须用于非基于RTP的（其他）媒体格式。这两个属性定义如下：
a=rmcap:<media-cap-num-list> <encoding-name>/<clock-rate>
[/<encoding-parms>]
a=rmcap:<media-cap-num-list> <encoding-name>/<clock-rate>
[/<encoding-parms>]
a=omcap:<media-cap-num-list> <format-name>
a=omcap:<media-cap-num-list> <format-name>
where <media-cap-num-list> is a (list of) media capability number(s) used to number a media format capability, the <encoding name> or <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 encoding parameters for the media subtype. All media format capabilities in the list are assigned to the same media type/subtype. Each occurrence of the "rmcap" and "omcap" attribute MUST use unique values in their <media-cap-num-list>; the media capability numbers are shared between the two attributes and the numbers MUST be unique across the entire SDP session. In short, the "rmcap" and "omcap" attributes define media format capabilities and associate them with a media capability number in the same manner as the "rtpmap" attribute defines them and associates them with a payload type number. Additionally, the attributes allow multiple capability numbers to be defined for the media format in question by specifying a range of media capability numbers. This permits the media format to be associated with different media parameters in different configurations. When a range of capability numbers is specified, the first (leftmost) capability number MUST be strictly smaller than the second (rightmost), i.e., the range increases and covers at least two numbers.
其中，<media cap num list>是用于对媒体格式能力进行编号的（列表）媒体能力编号，<encoding name>或<format name>是媒体子类型，例如H263-1998、PCMU或T38，<clock rate>是编码率，<encoding parms>是媒体子类型的媒体编码参数。列表中的所有媒体格式功能都分配给相同的媒体类型/子类型。“rmcap”和“omcap”属性的每次出现都必须在其<media cap num list>中使用唯一的值；这两个属性之间共享媒体功能编号，并且这些编号在整个SDP会话中必须是唯一的。简而言之，“rmcap”和“omcap”属性定义媒体格式能力并将其与媒体能力编号关联，其方式与“rtpmap”属性定义它们并将它们与有效负载类型编号关联的方式相同。此外，这些属性允许通过指定一系列媒体功能编号，为所讨论的媒体格式定义多个功能编号。这允许媒体格式与不同配置中的不同媒体参数相关联。当指定了能力编号的范围时，第一个（最左侧）能力编号必须严格小于第二个（最右侧），即范围增加并至少覆盖两个编号。
In ABNF [RFC5234], we have:
在ABNF[RFC5234]中，我们有：
media-capability-line = rtp-mcap / non-rtp-mcap
media-capability-line = rtp-mcap / non-rtp-mcap
rtp-mcap = "a=rmcap:" media-cap-num-list
1*WSP encoding-name "/" clock-rate
["/" encoding-parms]
non-rtp-mcap = "a=omcap:" media-cap-num-list 1*WSP format-name
media-cap-num-list = media-cap-num-element
*("," media-cap-num-element)
media-cap-num-element = media-cap-num
/ media-cap-num-range
media-cap-num-range = media-cap-num "-" media-cap-num
media-cap-num = NonZeroDigit *9(DIGIT)
encoding-name = token ;defined in RFC 4566
clock-rate = NonZeroDigit *9(DIGIT)
encoding-parms = token
format-name = token ;defined in RFC 4566
NonZeroDigit = %x31-39 ; 1-9
rtp-mcap = "a=rmcap:" media-cap-num-list
1*WSP encoding-name "/" clock-rate
["/" encoding-parms]
non-rtp-mcap = "a=omcap:" media-cap-num-list 1*WSP format-name
media-cap-num-list = media-cap-num-element
*("," media-cap-num-element)
media-cap-num-element = media-cap-num
/ media-cap-num-range
media-cap-num-range = media-cap-num "-" media-cap-num
media-cap-num = NonZeroDigit *9(DIGIT)
encoding-name = token ;defined in RFC 4566
clock-rate = NonZeroDigit *9(DIGIT)
encoding-parms = token
format-name = token ;defined in RFC 4566
NonZeroDigit = %x31-39 ; 1-9
The encoding-name, clock-rate, and encoding-params are as defined to 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" attribute lines, once a payload type number is assigned to a media-cap-num (see Section 3.3.5).
编码名称、时钟频率和编码参数定义为显示在每个媒体类型/子类型的“rtpmap”属性中。因此，一旦有效负载类型编号分配给媒体cap num（见第3.3.5节），就可以很容易地将“rmcap”属性行转换为一个或多个“rtpmap”属性行。
The format-name is a media format description for non-RTP-based media as defined for the <fmt> part of the media description ("m=" line) in SDP [RFC4566]. In simple terms, it is the name of the media format, e.g., "t38". This form can also be used in cases such as Binary Floor Control Protocol (BFCP) [RFC4585] where the fmt list in the "m=" line is effectively ignored (BFCP uses "*").
格式名称是SDP[RFC4566]中介质描述（“m=”行）的<fmt>部分定义的非RTP介质的介质格式描述。简单来说，它是媒体格式的名称，例如“t38”。此表格也可用于二进制地板控制协议（BFCP）[RFC4585]等情况，其中“m=”行中的fmt列表被有效忽略（BFCP使用“*”）。
The "rmcap" and "omcap" attributes can be provided at the session level and/or the media level. There can be more than one "rmcap" and more than one "omcap" attribute at both the session and media levels (i.e., more than one of each at the session level and more than one of each in each media description). Media capability numbers cannot include leading zeroes, and each media-cap-num MUST be unique within the entire SDP record; it is used to identify that media capability in potential, latent, and actual configurations, and in other attribute lines as explained below. Note that the media-cap-num values are shared between the "rmcap" and "omcap" attributes; hence, the uniqueness requirement applies to the union of them. When the media capabilities are used in a potential, latent, or actual configuration, the media formats referred by those configurations apply at the media level, irrespective of whether the media capabilities themselves were specified at the session or media level. In other words, the media capability applies to the specific media description associated with the configuration that invokes it.
“rmcap”和“omcap”属性可以在会话级别和/或媒体级别提供。在会话和媒体级别上可以有多个“rmcap”和多个“omcap”属性（即，在会话级别上每个属性都有多个，在每个媒体描述中每个属性都有多个）。媒体容量编号不能包含前导零，并且在整个SDP记录中，每个媒体容量编号必须是唯一的；它用于识别潜在、潜在和实际配置中的媒体能力，以及其他属性行中的媒体能力，如下所述。注意，媒体cap num值在“rmcap”和“omcap”属性之间共享；因此，唯一性要求适用于它们的并集。当在潜在的、潜在的或实际的配置中使用媒体能力时，这些配置所指的媒体格式应用于媒体级别，而不管媒体能力本身是在会话或媒体级别指定的。换句话说，媒体功能适用于与调用它的配置相关联的特定媒体描述。
For example:
例如：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
a=rmcap:1 L16/8000/1
a=rmcap:2 L16/16000/2
a=rmcap:3 H263-1998/90000
a=omcap:4 example
m=audio 54320 RTP/AVP 0
a=pcfg:1 m=1|2, pt=1:99,2:98
m=video 66544 RTP/AVP 100
a=rtpmap:100 H264/90000
a=pcfg:10 m=3 pt=3:101
a=tcap:1 TCP
a=pcfg:11 m=4 t=1
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
a=rmcap:1 L16/8000/1
a=rmcap:2 L16/16000/2
a=rmcap:3 H263-1998/90000
a=omcap:4 example
m=audio 54320 RTP/AVP 0
a=pcfg:1 m=1|2, pt=1:99,2:98
m=video 66544 RTP/AVP 100
a=rtpmap:100 H264/90000
a=pcfg:10 m=3 pt=3:101
a=tcap:1 TCP
a=pcfg:11 m=4 t=1
This attribute is used to associate media format specific parameters with one or more media format capabilities. The form of the 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 with one or more media format capabilities and the format parameters 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 <media-caps>) of the form
其中<media caps>允许参数列表与一个或多个媒体格式功能关联，且格式参数特定于媒体格式的类型。mfcap行映射到表单的单个传统SDP“fmtp”属性行（每个条目对应一个<media caps>）
a=fmtp:<fmt> <list of parameters>
a=fmtp:<fmt> <list of parameters>
where <fmt> is the media format parameter defined in RFC 4566 [RFC4566], as appropriate for the particular media stream. The "mfcap" attribute MUST be used to encode attributes for media capabilities, which would conventionally appear in an "fmtp" attribute. The existing "acap" attribute MUST NOT be used to encode "fmtp" attributes.
其中<fmt>是RFC 4566[RFC4566]中定义的媒体格式参数，适用于特定媒体流。“mfcap”属性必须用于对媒体功能的属性进行编码，通常会出现在“fmtp”属性中。现有的“acap”属性不得用于编码“fmtp”属性。
The "mfcap" attribute adheres to SDP [RFC4566] attribute production rules with
“mfcap”属性遵循SDP[RFC4566]属性生成规则，并具有
media-format-parameter-capability =
"a=mfcap:" media-cap-num-list 1*WSP fmt-specific-param-list
fmt-specific-param-list = text ; defined in RFC 4566
media-format-parameter-capability =
"a=mfcap:" media-cap-num-list 1*WSP fmt-specific-param-list
fmt-specific-param-list = text ; defined in RFC 4566
Note that media format parameters can be used with RTP-based and non-RTP-based media formats.
请注意，媒体格式参数可用于基于RTP和非基于RTP的媒体格式。
The appearance of media subtypes with a large number of formatting options (e.g., AMR-WB [RFC4867]), coupled with the restriction that only a single "fmtp" attribute can appear per media format, suggests that it is useful to create a combining rule for "mfcap" parameters that are associated with the same media capability number. Therefore, different mfcap lines MAY include the same media-cap-num in their media-cap-num-list. When a particular media capability is selected for processing, the parameters from each mfcap line that references the particular capability number in its media-cap-num-list are concatenated together via ";", in the order the "mfcap" attributes appear in the SDP record, to form the equivalent of a single "fmtp" attribute line. This permits one to define a separate mfcap line for a single parameter and value that is to be applied to each media capability designated in the media-cap-num-list. This provides a compact method to specify multiple combinations of format parameters when using codecs with multiple format options. Note that order-dependent parameters SHOULD be placed in a single mfcap line to avoid possible problems with line rearrangement by a middlebox.
具有大量格式化选项（如AMR-WB[RFC4867]）的媒体子类型的出现，再加上每个媒体格式只能出现一个“fmtp”属性的限制，表明为与相同媒体功能编号关联的“mfcap”参数创建组合规则是有用的。因此，不同的mfcap行可能在其媒体cap num列表中包含相同的媒体cap num。当选择某个特定的媒体功能进行处理时，引用其媒体cap num列表中特定功能号的每个mfcap行的参数通过“；”连接在一起，按照“mfcap”属性在SDP记录中出现的顺序，形成单个“fmtp”属性行的等价物。这允许为单个参数和值定义单独的mfcap行，该参数和值将应用于介质cap num列表中指定的每个介质功能。这提供了一种紧凑的方法，可以在使用具有多个格式选项的编解码器时指定格式参数的多个组合。请注意，订单相关参数应放置在单个mfcap行中，以避免通过中间盒重新排列行可能出现的问题。
Format parameters are not parsed by SDP; their content is specific to the media type/subtype. When format parameters for a specific media capability are combined from multiple "a=mfcap" lines that reference that media capability, the format-specific parameters are concatenated together and separated by ";" for construction of the corresponding format attribute ("a=fmtp"). The resulting format attribute will look something like the following (without line breaks):
SDP不解析格式参数；其内容特定于媒体类型/子类型。当特定媒体能力的格式参数从引用该媒体能力的多个“a=mfcap”行组合时，格式特定参数被连接在一起并用“；”分隔，以构造相应的格式属性（“a=fmtp”）。生成的格式属性将如下所示（不带换行符）：
a=fmtp:<fmt> <fmt-specific-param-list1>;
<fmt-specific-param-list2>;
...
a=fmtp:<fmt> <fmt-specific-param-list1>;
<fmt-specific-param-list2>;
...
where <fmt> depends on the transport protocol in the manner defined in RFC 4566 [RFC4566]. SDP cannot assess the legality of the resulting parameter list in the "a=fmtp" line; the user must take care to ensure that legal parameter lists are generated.
其中，<fmt>以RFC 4566[RFC4566]中定义的方式取决于传输协议。SDP无法评估“a=fmtp”行中产生的参数列表的合法性；用户必须注意确保生成合法参数列表。
The "mfcap" attribute can be provided at the session level and the media level. There can be more than one "mfcap" attribute at the session or media level. The unique media-cap-num is used to associate the parameters with a media capability.
可以在会话级别和媒体级别提供“mfcap”属性。在会话或媒体级别可以有多个“mfcap”属性。唯一的媒体cap num用于将参数与媒体功能关联。
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 with and without comfort noise support may thus be defined by:
作为一个简单的例子，默认情况下，G.729的能力被视为支持附录B中定义的舒适性噪声。因此，G.729在有和没有舒适性噪声支持的情况下的能力可以通过以下方式定义：
a=rmcap:1,2 G729/8000
a=mfcap:2 annexb:no
a=rmcap:1,2 G729/8000
a=mfcap:2 annexb:no
Media capability 1 supports G.729 with Annex B, whereas media capability 2 supports G.729 without Annex B.
媒体能力1支持带有附件B的G.729，而媒体能力2支持不带附件B的G.729。
Example for H.263 video:
H.263视频示例：
a=rmcap:1 H263-1998/90000
a=rmcap:2 H263-2000/90000
a=mfcap:1 CIF=4;QCIF=2;F=1;K=1
a=mfcap:2 profile=2;level=2.2
a=rmcap:1 H263-1998/90000
a=rmcap:2 H263-2000/90000
a=mfcap:1 CIF=4;QCIF=2;F=1;K=1
a=mfcap:2 profile=2;level=2.2
Finally, for six format combinations of the Adaptive Multi-Rate codec:
最后，对于自适应多速率编解码器的六种格式组合：
a=rmcap:1-3 AMR/8000/1
a=rmcap:4-6 AMR-WB/16000/1
a=mfcap:1,2,3,4 mode-change-capability=1
a=mfcap:5,6 mode-change-capability=2
a=mfcap:1,2,3,5 max-red=220
a=mfcap:3,4,5,6 octet-align=1
a=mfcap:1,3,5 mode-set=0,2,4,7
a=mfcap:2,4,6 mode-set=0,3,5,6
a=rmcap:1-3 AMR/8000/1
a=rmcap:4-6 AMR-WB/16000/1
a=mfcap:1,2,3,4 mode-change-capability=1
a=mfcap:5,6 mode-change-capability=2
a=mfcap:1,2,3,5 max-red=220
a=mfcap:3,4,5,6 octet-align=1
a=mfcap:1,3,5 mode-set=0,2,4,7
a=mfcap:2,4,6 mode-set=0,3,5,6
So that AMR codec #1, when specified in a "pcfg" attribute within an audio stream block (and assigned payload type number 98) as in:
因此，AMR编解码器#1，当在音频流块内的“pcfg”属性中指定时（并分配有效负载类型编号98），如中所示：
a=pcfg:1 m=1 pt=1:98
a=pcfg:1 m=1 pt=1:98
is essentially equivalent to the following:
基本上等同于以下内容：
m=audio 49170 RTP/AVP 98
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-change-capability=1; \
max-red=220; mode-set=0,2,4,7
m=audio 49170 RTP/AVP 98
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-change-capability=1; \
max-red=220; mode-set=0,2,4,7
and AMR codec #4 with payload type number 99, depicted by the potential configuration:
和AMR编解码器#4，有效负载类型编号99，由潜在配置描述：
a=pcfg:4 m=4, pt=4:99
a=pcfg:4 m=4, pt=4:99
is equivalent to the following:
相当于以下内容：
m=audio 49170 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000/1
a=fmtp:99 mode-change-capability=1; octet-align=1; \
mode-set=0,3,5,6
m=audio 49170 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000/1
a=fmtp:99 mode-change-capability=1; octet-align=1; \
mode-set=0,3,5,6
and so on for the other four combinations. SDP could thus convert the media capabilities specifications into one or more alternative media stream specifications, one of which can be chosen for the answer.
对于其他四种组合，依此类推。因此，SDP可以将媒体能力规范转换为一个或多个备选媒体流规范，可以选择其中一个作为答案。
Attributes and parameters associated with a media format are typically specified using the "rtpmap" and "fmtp" attributes in SDP, and the similar "rmcap" and "mfcap" attributes in SDP media capabilities. Some SDP extensions define other attributes that need to be associated with media formats, for example, the "rtcp-fb" attribute defined in RFC 4585 [RFC4585]. Such media-specific attributes, beyond the "rtpmap" and "fmtp" attributes, may be associated with media capability numbers via a new media-specific attribute, "mscap", of the following form:
与媒体格式相关联的属性和参数通常使用SDP中的“rtpmap”和“fmtp”属性以及SDP媒体功能中类似的“rmcap”和“mfcap”属性来指定。一些SDP扩展定义了需要与媒体格式关联的其他属性，例如，RFC 4585[RFC4585]中定义的“rtcp fb”属性。除“rtpmap”和“fmtp”属性外，此类媒体特定属性可通过以下形式的新媒体特定属性“mscap”与媒体能力编号相关联：
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), <att field> is the attribute name, and <att value> is the value field for the named attribute. Note that the media capability numbers refer to media format capabilities specified elsewhere in the SDP ("rmcap" and/or "omcap"). If a range of capability numbers is specified, the first (leftmost) capability number MUST be strictly smaller than the second (rightmost). The media capability numbers may include a wildcard ("*"), which will be used instead of any payload type mappings in the resulting SDP (see, e.g., RFC 4585 [RFC4585] and the example below). In ABNF, we have:
其中，<media caps star>是一个（列表）媒体功能编号，<att field>是属性名称，<att value>是命名属性的值字段。请注意，媒体能力编号指SDP中其他地方指定的媒体格式能力（“rmcap”和/或“omcap”）。如果指定了能力编号的范围，则第一个（最左侧）能力编号必须严格小于第二个（最右侧）。媒体能力编号可包括通配符（“*”），该通配符将用于替代结果SDP中的任何有效负载类型映射（例如，参见RFC 4585[RFC4585]和下面的示例）。在ABNF，我们有：
media-specific-capability = "a=mscap:"
media-caps-star
1*WSP att-field ; from RFC 4566
1*WSP att-value ; from RFC 4566
media-caps-star = media-cap-star-element
*("," media-cap-star-element)
media-cap-star-element = (media-cap-num [wildcard])
/ (media-cap-num-range [wildcard])
wildcard = "*"
media-specific-capability = "a=mscap:"
media-caps-star
1*WSP att-field ; from RFC 4566
1*WSP att-value ; from RFC 4566
media-caps-star = media-cap-star-element
*("," media-cap-star-element)
media-cap-star-element = (media-cap-num [wildcard])
/ (media-cap-num-range [wildcard])
wildcard = "*"
Given an association between a media capability and a payload type number as specified by the "pt=" parameters in a "pcfg" attribute line, a mscap line may be translated easily into a conventional SDP attribute line of the form:
给定“pcfg”属性行中的“pt=”参数指定的媒体能力和有效负载类型号之间的关联，mscap行可以轻松转换为以下形式的常规SDP属性行：
a=<att field>":"<fmt> <att value> ; <fmt> defined in SDP [RFC4566]
a=<att field>":"<fmt> <att value> ; <fmt> defined in SDP [RFC4566]
A resulting attribute that is not a legal SDP attribute, as specified by RFC 4566, MUST be ignored by the receiver.
接收方必须忽略RFC 4566指定的非合法SDP属性的结果属性。
If a media capability number (or range) contains a wildcard character at the end, any payload type mapping specified for that media-specific capability (or range of capabilities) will use the wildcard character in the resulting SDP instead of the payload type specified in the payload type mapping ("pt" parameter) in the configuration attribute.
如果媒体能力编号（或范围）的末尾包含通配符，则为该媒体特定能力（或能力范围）指定的任何有效负载类型映射将在生成的SDP中使用通配符，而不是在配置属性的有效负载类型映射（“pt”参数）中指定的有效负载类型。
A single mscap line may refer to multiple media capabilities by use of a capability number range; this is equivalent to multiple mscap lines, each with the same attribute values (but different media capability numbers), one line per media capability.
单个mscap行可通过使用能力编号范围来引用多个媒体能力；这相当于多个mscap行，每个行具有相同的属性值（但不同的媒体功能号），每个媒体功能一行。
Multiple mscap lines may refer to the same media capability, but, unlike the "mfcap" attribute, no concatenation operation is defined. Hence, multiple mscap lines applied to the same media capability are equivalent to multiple lines of the specified attribute in a conventional media record.
多个mscap行可能引用相同的媒体功能，但与“mfcap”属性不同，没有定义连接操作。因此，应用于相同媒体功能的多个mscap行相当于传统媒体记录中指定属性的多行。
Here is an example with the "rtcp-fb" attribute, modified from an example in RFC 5104 [RFC5104] (with the session level and audio media omitted). If the offer contains a media block like the following (note the wildcard character),
下面是一个具有“rtcp fb”属性的示例，该属性是从RFC 5104[RFC5104]中的示例修改而来的（省略了会话级别和音频媒体）。如果报价包含如下所示的媒体块（请注意通配符），
m=video 51372 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=tcap:1 RTP/AVPF
a=rmcap:1 H263-1998/90000
a=mscap:1 rtcp-fb ccm tstr
a=mscap:1 rtcp-fb ccm fir
a=mscap:1* rtcp-fb ccm tmmbr smaxpr=120
a=pcfg:1 t=1 m=1 pt=1:98
m=video 51372 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=tcap:1 RTP/AVPF
a=rmcap:1 H263-1998/90000
a=mscap:1 rtcp-fb ccm tstr
a=mscap:1 rtcp-fb ccm fir
a=mscap:1* rtcp-fb ccm tmmbr smaxpr=120
a=pcfg:1 t=1 m=1 pt=1:98
and if the proposed configuration is chosen, then the equivalent media block would look like the following
如果选择了建议的配置，那么等效的媒体块将如下所示
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
a=rtcp-fb:* ccm tmmbr smaxpr=120
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
a=rtcp-fb:* ccm tmmbr smaxpr=120
Along with the new attributes for media capabilities, new extension parameters are defined for use in the potential configuration, the actual configuration, and/or the new latent configuration defined in Section 3.3.5.
除了媒体功能的新属性外，还定义了新的扩展参数，用于第3.3.5节中定义的潜在配置、实际配置和/或新的潜在配置。
The media configuration parameter is used to specify the media format(s) and related parameters for a potential, actual, or latent configuration. Adhering to the ABNF for extension-config-list in RFC 5939 [RFC5939] with
介质配置参数用于指定潜在、实际或潜在配置的介质格式和相关参数。遵循RFC 5939[RFC5939]中扩展配置列表的ABNF
ext-cap-name = "m" ext-cap-list = media-cap-num-list [*(BAR media-cap-num-list)]
ext cap name=“m”ext cap list=媒体cap num list[*（条形媒体cap num list）]
we have
我们有
media-config-list = ["+"] "m=" media-cap-num-list
*(BAR media-cap-num-list)
;BAR is defined in RFC 5939
;media-cap-num-list is defined above
media-config-list = ["+"] "m=" media-cap-num-list
*(BAR media-cap-num-list)
;BAR is defined in RFC 5939
;media-cap-num-list is defined above
Alternative media configurations are separated by a vertical bar ("|"). The alternatives are ordered by preference, most-preferred first. When media capabilities are not included in a potential configuration at the media level, the media type and media format from the associated "m=" line will be used. The use of the plus sign ("+") is described in RFC 5939.
备用介质配置由一个垂直条（“|”）分隔。备选方案按优先顺序排列，最优先。当媒体功能未包含在媒体级别的潜在配置中时，将使用相关“m=”行中的媒体类型和媒体格式。RFC 5939中描述了加号（“+”）的使用。
The payload type number mapping parameter is used to specify the payload type number to be associated with each RTP-based media format in a potential, actual, or latent configuration. We define the payload type number mapping parameter, payload-number-config-list, in accordance with the extension-config-list format defined in RFC 5939 [RFC5939]. In ABNF:
有效负载类型号映射参数用于指定与潜在、实际或潜在配置中的每个基于RTP的媒体格式关联的有效负载类型号。我们根据RFC 5939[RFC5939]中定义的扩展配置列表格式定义有效负载类型编号映射参数有效负载编号配置列表。在ABNF中：
payload-number-config-list = ["+"] "pt=" media-map-list
media-map-list = media-map *("," media-map)
media-map = media-cap-num ":" payload-type-number
; media-cap-num is defined in Section 3.3.1
payload-type-number = NonZeroDigit *2(DIGIT) ; RTP payload
; type number
payload-number-config-list = ["+"] "pt=" media-map-list
media-map-list = media-map *("," media-map)
media-map = media-cap-num ":" payload-type-number
; media-cap-num is defined in Section 3.3.1
payload-type-number = NonZeroDigit *2(DIGIT) ; RTP payload
; type number
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. The use of the plus sign ("+") is described in RFC 5939 [RFC5939].
第3.3.7节中的示例显示了rmcap行中的参数如何映射到“pcfg”“pt”参数中的有效负载类型编号。RFC 5939[RFC5939]中描述了加号（“+”）的使用。
A latent configuration represents a future capability; hence, the "pt=" parameter is not directly meaningful in the "lcfg" attribute because no actual media session is being offered or accepted. It is permitted in order to tie any payload type number parameters within attributes to the proper media format. A primary example is the case of format parameters for the Redundant Audio Data (RED) [RFC2198] payload, which are payload type numbers. Specific payload type numbers used in a latent configuration MAY be interpreted as suggestions to be used in any future offer based on the latent configuration, but they are not binding; the offerer and/or answerer may use any payload type numbers each deems appropriate. The use of explicit payload type numbers for latent configurations can be avoided by use of the parameter substitution rule of Section 3.3.7. Future extensions are also permitted. Note that leading zeroes are not permitted.
潜在配置代表未来能力；因此，“pt=”参数在“lcfg”属性中没有直接意义，因为没有提供或接受实际的媒体会话。允许将属性中的任何有效负载类型编号参数绑定到正确的媒体格式。主要示例是冗余音频数据（RED）[RFC2198]有效负载的格式参数的情况，其为有效负载类型号。潜在配置中使用的特定有效载荷类型编号可解释为基于潜在配置的任何未来报价中使用的建议，但它们不具有约束力；报价人和/或应答人可使用各自认为合适的任何有效载荷类型编号。通过使用第3.3.7节的参数替换规则，可以避免对潜在配置使用显式有效载荷类型号。今后也允许延期。请注意，不允许使用前导零。
When a latent configuration is specified (always at the media level), indicating the ability to support an additional media stream, it is necessary to specify the media type (audio, video, etc.) as well as the format and transport type. The media type parameter is defined in ABNF as
当指定潜在配置（始终在媒体级别）时，指示支持附加媒体流的能力，有必要指定媒体类型（音频、视频等）以及格式和传输类型。介质类型参数在ABNF中定义为
media-type = ["+"] "mt=" media; media defined in RFC 4566
media-type = ["+"] "mt=" media; media defined in RFC 4566
At present, the media-type parameter is used only in the latent configuration attribute, and the use of the "+" prefix to specify that the entire attribute line is to be ignored if the mt= parameter is not understood is unnecessary. However, if the media-type parameter is later added to an existing capability attribute such as "pcfg", then the "+" would be useful. The media format(s) and transport type(s) are specified using the media configuration parameter ("+m=") defined above, and the transport parameter ("t=") defined in RFC 5939 [RFC5939], respectively.
目前，媒体类型参数仅在潜在配置属性中使用，并且不需要使用“+”前缀来指定如果不理解mt=参数，则忽略整个属性行。但是，如果以后将媒体类型参数添加到现有功能属性（如“pcfg”）中，则“+”将非常有用。介质格式和传输类型分别使用上文定义的介质配置参数（“+m=”）和RFC 5939[RFC5939]中定义的传输参数（“t=”）指定。
One of the goals of this work is to permit the exchange of supportable media configurations in addition to those offered or accepted for immediate use. Such configurations are referred to as "latent configurations". For example, a party may offer to establish a session with an audio stream, and, at the same time, announce its ability to support a video stream as part of the same session. The offerer can supply its video capabilities by offering one or more latent video configurations along with the media stream for audio; the responding party may indicate its ability and willingness to support such a video session by returning a corresponding latent configuration.
这项工作的目标之一是，除了提供或接受立即使用的介质配置外，允许交换可支持的介质配置。这种配置被称为“潜在配置”。例如，一方可以提出用音频流建立会话，同时宣布其支持视频流作为同一会话的一部分的能力。要约人可以通过提供一个或多个潜在视频配置以及用于音频的媒体流来提供其视频能力；响应方可以通过返回相应的潜在配置来指示其支持这种视频会话的能力和意愿。
Latent configurations returned in SDP answers MUST match offered latent configurations (or parameter subsets thereof). Therefore, it is appropriate for the offering party to announce most, if not all, of its capabilities in the initial offer. This choice has been made in order to keep the size of the answer more compact by not requiring acap, rmcap, tcap, etc. lines in the answer.
SDP应答中返回的潜在配置必须与提供的潜在配置（或其参数子集）匹配。因此，发行方宜在首次发行中公布其大部分（如果不是全部）能力。选择此选项是为了通过不要求答案中的acap、rmcap、tcap等行来保持答案的大小更紧凑。
Latent configurations may be announced by use of the latent configuration attribute, which is defined in a manner very similar to the potential configuration attribute. The latent configuration attribute combines the properties of a media line and a potential configuration. A latent configuration MUST include a media type (mt=) and a transport protocol configuration parameter since the latent configuration is independent of any media line present. In most cases, the media configuration (m=) parameter needs to be present as well (see Section 4 for examples). The "lcfg" attribute is a media-level attribute.
潜在配置可以通过使用潜在配置属性来宣布，潜在配置属性以非常类似于潜在配置属性的方式定义。潜在配置属性结合了媒体线路和潜在配置的属性。潜在配置必须包括媒体类型（mt=）和传输协议配置参数，因为潜在配置独立于存在的任何媒体线路。在大多数情况下，还需要提供媒体配置（m=）参数（示例见第4节）。“lcfg”属性是媒体级属性。
The "lcfg" attribute is defined as a media-level attribute since it specifies a possible future media stream. However, the "lcfg" attribute is not necessarily related to the media description within which it is provided. Session capability attributes ("a=sescap") may be used to indicate supported media stream configurations.
“lcfg”属性被定义为媒体级属性，因为它指定了未来可能的媒体流。然而，“lcfg”属性不一定与提供该属性的媒体描述相关。会话能力属性（“a=sescap”）可用于指示支持的媒体流配置。
Each media line in an SDP description represents an offered simultaneous media stream, whereas each latent configuration represents an additional stream that may be negotiated in a future offer/answer exchange. Session capability attributes may be used to determine whether a latent configuration may be used to form an offer for an additional simultaneous stream or to reconfigure an existing stream in a subsequent offer/answer exchange.
SDP描述中的每个媒体行表示提供的同时媒体流，而每个潜在配置表示可在未来的提供/应答交换中协商的附加流。会话能力属性可用于确定潜在配置是否可用于形成附加同时流的要约或在后续要约/应答交换中重新配置现有流。
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 SDP [RFC4566] "attribute" production with att-field and att-value defined as:
符合SDP[RFC4566]“属性”生产，att字段和att值定义为：
att-field = "lcfg"
att-value = config-number 1*WSP lcfg-cfg-list
config-number = NonZeroDigit *9(DIGIT) ;DIGIT defined in RFC 5234
lcfg-cfg-list = media-type 1*WSP pot-cfg-list
; as defined in RFC 5939
; and extended herein
att-field = "lcfg"
att-value = config-number 1*WSP lcfg-cfg-list
config-number = NonZeroDigit *9(DIGIT) ;DIGIT defined in RFC 5234
lcfg-cfg-list = media-type 1*WSP pot-cfg-list
; as defined in RFC 5939
; and extended herein
The media-type (mt=) parameter identifies the media type (audio, video, etc.) to be associated with the latent media stream, and it MUST be present. The pot-cfg-list MUST contain a transport-protocol-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 of parameter list. As specified in RFC 5939 [RFC5939], the use of the "+" prefix with a parameter indicates that the entire configuration MUST be ignored if the parameter is not understood; otherwise, the parameter itself may be ignored.
媒体类型（mt=）参数标识要与潜在媒体流关联的媒体类型（音频、视频等），并且它必须存在。pot cfg列表必须包含传输协议配置列表（t=）参数和媒体配置列表（m=）参数。pot cfg列表不能包含每种类型参数列表的多个实例。按照RFC 5939[RFC5939]的规定，如果参数不被理解，则使用带参数的“+”前缀表示必须忽略整个配置；否则，参数本身可能会被忽略。
Media stream payload numbers are not assigned by a latent configuration. Assignment will take place if and when the corresponding stream is actually offered via an "m=" line in a later exchange. The payload-number-config-list is included as a parameter to the "lcfg" attribute in case it is necessary to tie payload numbers in attribute capabilities to specific media capabilities.
媒体流有效负载编号不由潜在配置分配。如果在以后的交换中通过“m=”行实际提供了相应的流，则将进行分配。有效负载编号配置列表作为“lcfg”属性的一个参数包括在内，以防需要将属性功能中的有效负载编号与特定媒体功能联系起来。
If an "lcfg" attribute invokes an "acap" attribute that appears at the session level, then that attribute will be expected to appear at the session level of a subsequent offer when and if a corresponding media stream is offered. Otherwise, "acap" attributes that appear at the media level represent media-level attributes. Note, however, that "rmcap", omcap, "mfcap", "mscap", and "tcap" attributes may appear at the session level because they always result in media-level attributes or "m=" line parameters.
如果“lcfg”属性调用出现在会话级别的“acap”属性，则当提供相应的媒体流时，该属性将出现在后续提供的会话级别。否则，出现在媒体级别的“acap”属性表示媒体级别属性。但是，请注意，“rmcap”、“omcap”、“mfcap”、“mscap”和“tcap”属性可能出现在会话级别，因为它们总是导致媒体级别属性或“m=”行参数。
The configuration numbers for latent configurations do not imply a preference; the offerer will imply a preference when actually offering potential configurations derived from latent configurations negotiated earlier. Note, however, that the offerer of latent configurations MAY specify preferences for combinations of potential and latent configurations by use of the "sescap" attribute defined in Section 3.3.8. For example, if an SDP offer contains, say, an audio
潜在配置的配置号并不意味着偏好；在实际提供源自先前协商的潜在配置的潜在配置时，报价人将暗示偏好。但是，请注意，潜在配置的报价人可使用第3.3.8节中定义的“sescap”属性指定潜在配置和潜在配置组合的偏好。例如，如果SDP产品包含（比如）音频
stream with "pcfg:1", and two latent video configurations, "lcfg:2" and "lcfg:3", then a session with one audio stream and one video stream could be specified by including "a=sescap:1 1,2|3". One audio stream and two video streams could be specified by including "a=sescap:2 1,2,3" in the offer. In order to permit combinations of latent and potential configurations in session capabilities, latent configuration numbers MUST be different from those used for potential configurations. This restriction is especially important if the offerer does not require cmed-v0 capability and the recipient of the offer doesn't support it. If the "lcfg" attribute is not recognized, the capability attributes intended to be associated with it may be confused with those associated with a potential configuration of some other media stream. Note also that leading zeroes are not permitted in configuration numbers.
具有“pcfg:1”和两个潜在视频配置“lcfg:2”和“lcfg:3”的流，则可以通过包括“a=sescap:1 1,2 | 3”来指定具有一个音频流和一个视频流的会话。一个音频流和两个视频流可以通过在报价中包含“a=sescap:2 1,2,3”来指定。为了允许会话功能中潜在配置和潜在配置的组合，潜在配置号必须与潜在配置号不同。如果要约人不需要cmed-v0能力，且要约接收人不支持，则此限制尤为重要。如果未识别“lcfg”属性，则打算与其关联的能力属性可能与与与某个其他媒体流的潜在配置关联的那些属性相混淆。还要注意，配置号中不允许前导零。
If a cryptographic attribute, such as the SDES "a=crypto:" attribute [RFC4568], is referenced by a latent configuration through an "acap" attribute, any keying material required in the conventional attribute, such as the SDES key/salt string, MUST be included in order to satisfy formatting rules for the attribute. Since the keying material will be visible but not actually used at this stage (since it's a latent configuration), the value(s) of the keying material MUST NOT be a real value used for real exchange of media, and the receiver of the "lcfg" attribute MUST ignore the value(s).
如果潜在配置通过“acap”属性引用加密属性，如SDES“a=crypto:”属性[RFC4568]，则必须包括常规属性中所需的任何键控材料，如SDES密钥/盐字符串，以满足属性的格式规则。由于键控材料在此阶段可见但未实际使用（因为它是一种潜在配置），因此键控材料的值不得是用于媒体真实交换的真实值，“lcfg”属性的接收者必须忽略该值。
The present work requires new extensions (parameters) for the "pcfg" attribute defined in the SDP capability negotiation base protocol [RFC5939]. The parameters and their definitions are "borrowed" from the definitions provided for the latent configuration attribute in Section 3.3.5. The expanded ABNF definition of the "pcfg" attribute is
目前的工作需要对SDP能力协商基础协议[RFC5939]中定义的“pcfg”属性进行新的扩展（参数）。参数及其定义“借用”了第3.3.5节中为潜在配置属性提供的定义。“pcfg”属性的扩展ABNF定义为
a=pcfg: <config-number> [<pot-cfg-list>]
a=pcfg: <config-number> [<pot-cfg-list>]
where
哪里
config-number = 1*DIGIT ;defined in [RFC5234]
pot-cfg-list = pot-config *(1*WSP pot-config)
pot-config = attribute-config-list / ;def in [RFC5939]
transport-protocol-config-list / ;defined in [RFC5939]
extension-config-list / ;[RFC5939]
media-config-list / ; Section 3.3.4.1
payload-number-config-list ; Section 3.3.4.2
config-number = 1*DIGIT ;defined in [RFC5234]
pot-cfg-list = pot-config *(1*WSP pot-config)
pot-config = attribute-config-list / ;def in [RFC5939]
transport-protocol-config-list / ;defined in [RFC5939]
extension-config-list / ;[RFC5939]
media-config-list / ; Section 3.3.4.1
payload-number-config-list ; Section 3.3.4.2
Except for the extension-config-list, the pot-cfg-list MUST NOT contain more than one instance of each parameter list.
除了扩展配置列表外，pot cfg列表不能包含每个参数列表的多个实例。
Potential and/or latent configuration attributes may be returned within an answer SDP to indicate the ability of the answerer to support alternative configurations of the corresponding stream(s). For example, an offer may include multiple potential configurations for a media stream and/or latent configurations for additional streams. The corresponding answer will indicate (via an "acfg" attribute) the configuration accepted and used to construct the base configuration for each active media stream in the reply, but the reply MAY also contain potential and/or latent configuration attributes, with parameters, to indicate which other offered configurations would be acceptable. This information is useful if it becomes desirable to reconfigure a media stream, e.g., to reduce resource consumption.
潜在和/或潜在配置属性可在应答SDP内返回，以指示应答者支持相应流的替代配置的能力。例如，要约可以包括用于媒体流的多个潜在配置和/或用于附加流的潜在配置。相应的应答将指示（通过“acfg”属性）被接受并用于为应答中的每个活动媒体流构造基本配置的配置，但是应答还可以包含潜在和/或潜在配置属性以及参数，以指示哪些其他提供的配置是可接受的。如果需要重新配置媒体流，例如减少资源消耗，则该信息是有用的。
When potential and/or latent configurations are returned in an answer, all numbering MUST refer to the configuration and capability attribute numbering of the offer. The offered capability attributes need not be returned in the answer. The answer MAY include additional capability attributes and/or configurations (with distinct numbering). The parameter values of any returned "pcfg" or "lcfg" attributes MUST be a subset of those included in the offered configurations and/or those added by the answerer; values MAY be omitted only if they were indicated as alternative sets, or optional, in the original offer. The parameter set indicated in the returned "acfg" attribute need not be repeated in a returned "pcfg" attribute. The answerer MAY return more than one "pcfg" attribute with the same configuration number if it is necessary to describe selected combinations of optional or alternative parameters.
当回答中返回潜在和/或潜在配置时，所有编号必须参考报价的配置和能力属性编号。回答中不需要返回提供的功能属性。答案可能包括额外的能力属性和/或配置（具有不同的编号）。任何返回的“pcfg”或“lcfg”属性的参数值必须是所提供配置中包含的和/或应答者添加的属性的子集；只有在原始报价中将这些值表示为备选集或可选集时，才可以省略这些值。返回的“acfg”属性中指示的参数集不需要在返回的“pcfg”属性中重复。如果有必要描述可选或备选参数的选定组合，应答者可以返回具有相同配置号的多个“pcfg”属性。
Similarly, one or more session capability attributes ("a=sescap") MAY be returned to indicate which of the offered session capabilities is/are supportable by the answerer (see Section 3.3.8).
类似地，可以返回一个或多个会话能力属性（“a=sescap”），以指示应答者可支持提供的会话能力中的哪些（见第3.3.8节）。
Note that, although the answerer MAY return capabilities beyond those included by the offerer, these capabilities MUST NOT be used to form any base level media description in the answer. For this reason, it is advisable for the offerer to include most, if not all, potential and latent configurations it can support in the initial offer, unless the size of the resulting SDP is a concern. Either party MAY later announce additional capabilities by renegotiating the session in a second offer/answer exchange.
请注意，尽管回答者可能会返回超出报价者所包含的能力，但这些能力不得用于在回答中形成任何基本媒体描述。因此，建议报价人在初始报价中包括其能够支持的大部分（如果不是全部的话）潜在和潜在配置，除非所产生的SDP的规模令人担忧。任何一方可在稍后通过第二次提供/应答交换重新协商会话来宣布附加功能。
When media format capabilities defined in "rmcap" attributes are used in potential configuration lines, the transport protocol uses RTP and it is necessary to assign payload type numbers. In some cases, it is desirable to assign different payload type numbers to the same media format capability when used in different potential configurations. One example is when configurations for AVP and SAVP are offered: the offerer would like the answerer to use different payload type numbers for encrypted and unencrypted media, so the offerer can decide whether or not to render early media that arrives before the answer is received.
当在潜在配置行中使用“rmcap”属性中定义的媒体格式功能时，传输协议使用RTP，并且有必要分配有效负载类型号。在某些情况下，当在不同的潜在配置中使用时，希望为相同的媒体格式功能分配不同的有效负载类型号。一个例子是，当提供AVP和SAVP配置时：报价人希望应答人对加密和未加密的媒体使用不同的有效负载类型编号，因此报价人可以决定是否呈现在收到答复之前到达的早期媒体。
For example, if use of AVP was selected by the answerer, then media received by the offerer is not encrypted; hence, it can be played out prior to receiving the answer. Conversely, if SAVP was selected, cryptographic parameters and keying material present in the answer may be needed to decrypt received media. If the offer configuration indicated that AVP media uses one set of payload types and SAVP a different set, then the offerer will know whether media received prior to the answer is encrypted or not by simply looking at the RTP payload type number in the received packet.
例如，如果回答者选择使用AVP，则报价人接收的媒体不加密；因此，可以在收到答案之前播放。相反，如果选择SAVP，则可能需要答案中存在的加密参数和密钥材料来解密接收到的媒体。如果要约配置指示AVP媒体使用一组有效负载类型，而SAVP使用另一组有效负载类型，则要约人将通过简单地查看所接收分组中的RTP有效负载类型号来知道在应答之前接收的媒体是否被加密。
This association of distinct payload type number(s) with different transport protocols requires a separate pcfg line for each protocol. Clearly, this technique cannot be used if the number of potential configurations exceeds the number of possible payload type numbers.
不同有效负载类型编号与不同传输协议的这种关联要求每个协议使用单独的pcfg线路。显然，如果潜在配置的数量超过可能的有效负载类型数量，则不能使用此技术。
3.3.6.3. Processing of Media-Format-Related Conventional Attributes for Potential Configurations
3.3.6.3. 潜在配置的媒体格式相关常规属性的处理
When media capabilities negotiation is employed, SDP records are likely to contain conventional attributes such as "rtpmap", "fmtp", and other media-format-related lines, as well as capability attributes such as "rmcap", omcap, "mfcap", and "mscap" that map into those conventional attributes when invoked by a potential configuration. In such cases, it MAY be appropriate to employ the delete-attributes option [RFC5939] in the attribute configuration list parameter in order to avoid the generation of conflicting "fmtp" attributes for a particular configuration. Any media-specific attributes in the media block that refer to media formats not used by the potential configuration MUST be ignored.
当采用媒体能力协商时，SDP记录可能包含常规属性，如“rtpmap”、“fmtp”和其他媒体格式相关行，以及由潜在配置调用时映射到这些常规属性的能力属性，如“rmcap”、“omcap”、“mfcap”和“mscap”。在这种情况下，可以在属性配置列表参数中使用删除属性选项[RFC5939]，以避免为特定配置生成冲突的“fmtp”属性。必须忽略媒体块中与潜在配置未使用的媒体格式相关的任何媒体特定属性。
For example:
例如：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
m=audio 3456 RTP/AVP 0 18 100
a=rtpmap:100 telephone-event
a=fmtp:100 0-11
a=rmcap:1 PCMU/8000
a=rmcap:2 G729/8000
a=rmcap:3 telephone-event/8000
a=mfcap:3 0-15
a=pcfg:1 m=2,3|1,3 a=-m pt=1:0,2:18,3:100
a=pcfg:2
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
m=audio 3456 RTP/AVP 0 18 100
a=rtpmap:100 telephone-event
a=fmtp:100 0-11
a=rmcap:1 PCMU/8000
a=rmcap:2 G729/8000
a=rmcap:3 telephone-event/8000
a=mfcap:3 0-15
a=pcfg:1 m=2,3|1,3 a=-m pt=1:0,2:18,3:100
a=pcfg:2
In this example, PCMU is media capability 1, G729 is media capability 2, and telephone-event is media capability 3. The a=pcfg:1 line specifies that the preferred configuration is G.729 with extended DTMF events, second is G.711 mu-law with extended DTMF events, and the base media-level attributes are to be deleted. Intermixing of G.729, G.711, and "commercial" DTMF events is least preferred (the base configuration provided by the "m=" line, which is, by default, the least preferred configuration). The "rtpmap" and "fmtp" attributes of the base configuration are replaced by the "rmcap" and "mfcap" attributes when invoked by the proposed configuration.
在此示例中，PCMU是媒体能力1，G729是媒体能力2，电话事件是媒体能力3。a=pcfg:1行指定首选配置为带有扩展DTMF事件的G.729，第二个配置为带有扩展DTMF事件的G.711 mu law，并且要删除基本媒体级属性。混合使用G.729、G.711和“商业”DTMF事件是最不可取的（基本配置由“m=”行提供，默认情况下，这是最不可取的配置）。当被提议的配置调用时，基本配置的“rtpmap”和“fmtp”属性被“rmcap”和“mfcap”属性替换。
If the preferred configuration is selected, the SDP answer will look like the following
如果选择首选配置，则SDP答案如下所示
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=csup:med-v0
m=audio 3456 RTP/AVP 18 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=acfg:1 m=2,3 pt=1:0,2:18,3:100
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=csup:med-v0
m=audio 3456 RTP/AVP 18 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=acfg:1 m=2,3 pt=1:0,2:18,3:100
3.3.7. Substitution of Media Payload Type Numbers in Capability Attribute Parameters
3.3.7. 在能力属性参数中替换媒体有效负载类型号
In some cases, for example, when an RFC 2198 [RFC2198] redundancy audio subtype (RED) capability is defined in an "mfcap" attribute, the parameters to an attribute may contain payload type numbers. Two options are available for specifying such payload type numbers. They may be expressed explicitly, in which case they are bound to actual payload types by means of the payload type number parameter (pt=) in the appropriate potential or latent configuration. For example, the following SDP fragment defines a potential configuration with redundant G.711 mu-law
在某些情况下，例如，当在“mfcap”属性中定义RFC 2198[RFC2198]冗余音频子类型（RED）能力时，属性的参数可能包含有效负载类型号。有两个选项可用于指定此类有效负载类型编号。它们可以显式表示，在这种情况下，它们通过适当潜在或潜在配置中的有效负载类型编号参数（pt=）绑定到实际有效负载类型。例如，以下SDP片段定义了具有冗余G.711 mu定律的潜在配置
m=audio 45678 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rmcap:1 PCMU/8000
a=rmcap:2 RED/8000
a=mfcap:2 0/0
a=pcfg:1 m=2,1 pt=2:98,1:0
m=audio 45678 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rmcap:1 PCMU/8000
a=rmcap:2 RED/8000
a=mfcap:2 0/0
a=pcfg:1 m=2,1 pt=2:98,1:0
The potential configuration is then equivalent to
然后，潜在配置相当于
m=audio 45678 RTP/AVP 98 0
a=rtpmap:0 PCMU/8000
a=rtpmap:98 RED/8000
a=fmtp:98 0/0
m=audio 45678 RTP/AVP 98 0
a=rtpmap:0 PCMU/8000
a=rtpmap:98 RED/8000
a=fmtp:98 0/0
A more general mechanism is provided via the parameter substitution rule. When an "mfcap", "mscap", or "acap" attribute is processed, its arguments will be scanned for a payload type number escape sequence of the following form (in ABNF):
通过参数替换规则提供了更通用的机制。当处理“mfcap”、“mscap”或“acap”属性时，将扫描其参数，以获得以下形式的有效负载类型编号转义序列（ABNF）：
ptn-esc = "%m=" media-cap-num "%" ; defined in Section 3.3.1
ptn-esc = "%m=" media-cap-num "%" ; defined in Section 3.3.1
If the sequence is found, the sequence is replaced by the payload type number assigned to the media capability number, as specified by the "pt=" parameter in the selected potential configuration; only actual payload type numbers are supported -- wildcards are excluded. The sequence "%%" (null digit string) is replaced by a single percent sign and processing continues with the next character, if any.
如果找到该序列，则该序列将替换为分配给媒体能力编号的有效负载类型编号，如所选潜在配置中的“pt=”参数所指定；只支持实际的有效负载类型编号——不包括通配符。序列“%%”（空数字字符串）替换为一个百分号，处理继续下一个字符（如果有）。
For example, the above offer sequence could have been written as
例如，上面的报价序列可以写成
m=audio 45678 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rmcap:1 PCMU/8000
a=rmcap:2 RED/8000
a=mfcap:2 %m=1%/%m=1%
a=pcfg:1 m=2,1 pt=2:98,1:0
m=audio 45678 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rmcap:1 PCMU/8000
a=rmcap:2 RED/8000
a=mfcap:2 %m=1%/%m=1%
a=pcfg:1 m=2,1 pt=2:98,1:0
and the equivalent SDP is the same as above.
等效SDP与上述相同。
Potential and latent configurations enable offerers and answerers to express a wide range of alternative configurations for current and future negotiation. However, in practice, it may not be possible to support all combinations of these configurations.
潜在配置和潜在配置使报价人和应答人能够为当前和未来的谈判表达广泛的替代配置。然而，在实践中，可能不可能支持这些配置的所有组合。
The session capability attribute provides a means for the offerer and/or the answerer to specify combinations of specific media stream configurations that it is willing and able to support. Each session capability in an offer or answer MAY be expressed as a list of required potential configurations, and MAY include a list of optional potential and/or latent configurations.
会话能力属性为报价人和/或应答人提供了一种方法，以指定其愿意并能够支持的特定媒体流配置的组合。要约或应答中的每个会话能力可以表示为所需潜在配置的列表，并且可以包括可选潜在和/或潜在配置的列表。
The choices of session capabilities may be based on processing load, total bandwidth, or any other criteria of importance to the communicating parties. If the answerer supports media capabilities negotiation, and session configurations are offered, it MUST accept one of the offered configurations, or it MUST refuse the session. Therefore, if the offer includes any session capabilities, it SHOULD include all the session capabilities the offerer is willing to support.
会话能力的选择可以基于处理负载、总带宽或对通信方重要的任何其他标准。如果应答者支持媒体功能协商，并且提供了会话配置，则应答者必须接受所提供的配置之一，或者必须拒绝会话。因此，如果报价包括任何会话功能，则应包括报价人愿意支持的所有会话功能。
The session capability attribute is a session-level attribute 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
对应于标准值属性定义的
att-field = "sescap"
att-value = session-num 1*WSP list-of-configs
[1*WSP optional-configs]
session-num = NonZeroDigit *9(DIGIT) ; DIGIT defined
; in RFC 5234
list-of-configs = alt-config *("," alt-config)
optional-configs = "[" list-of-configs "]"
alt-config = config-number *("|" config-number)
att-field = "sescap"
att-value = session-num 1*WSP list-of-configs
[1*WSP optional-configs]
session-num = NonZeroDigit *9(DIGIT) ; DIGIT defined
; in RFC 5234
list-of-configs = alt-config *("," alt-config)
optional-configs = "[" list-of-configs "]"
alt-config = config-number *("|" config-number)
The session-num identifies the session: a lower-number session is preferred over a higher-number session, and leading zeroes are not permitted. Each alt-config list specifies alternative media configurations within the session; preference is based on config-num as specified in RFC 5939 [RFC5939]. Note that the session preference order, when present, takes precedence over the individual media stream configuration preference order.
session num标识会话：数字较低的会话优先于数字较高的会话，并且不允许前导零。每个alt config列表指定会话中的备选媒体配置；首选项基于RFC 5939[RFC5939]中指定的配置编号。请注意，会话首选项顺序（如果存在）优先于单个媒体流配置首选项顺序。
Use of session capability attributes requires that configuration numbers assigned to potential and latent configurations MUST be unique across the entire session; RFC 5939 [RFC5939] requires only that "pcfg" configuration numbers be unique within a media description. Also, leading zeroes are not permitted.
会话能力属性的使用要求分配给潜在和潜在配置的配置号在整个会话中必须是唯一的；RFC 5939[RFC5939]仅要求“pcfg”配置号在介质描述中是唯一的。此外，不允许使用前导零。
As an example, consider an endpoint that is capable of supporting an audio stream with either one H.264 video stream or two H.263 video streams with a floor control stream. In the latter case, the second video stream is optional. The SDP offer might look like the following (offering audio, an H.263 video streams, BFCP and another optional H.263 video stream) -- the empty lines are added for readability only (not part of valid SDP):
作为一个例子，考虑能够支持具有H.264视频流或具有地板控制流的两个H.263视频流的音频流的端点。在后一种情况下，第二视频流是可选的。SDP产品可能如下所示（提供音频、H.263视频流、BFCP和另一可选的H.263视频流）——添加空行仅用于可读性（不是有效SDP的一部分）：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
a=sescap:2 1,2,5,[3]
a=sescap:1 1,4
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
a=sescap:2 1,2,5,[3]
a=sescap:1 1,4
m=audio 54322 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=pcfg:1
m=audio 54322 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=pcfg:1
m=video 22344 RTP/AVP 102
a=rtpmap:102 H263-1998/90000
a=fmtp:102 CIF=4;QCIF=2;F=1;K=1
i=main video stream
a=label:11
a=pcfg:2
a=rmcap:1 H264/90000
a=mfcap:1 profile-level-id=42A01E; packetization-mode=2
a=acap:1 label:13
a=pcfg:4 m=1 a=1 pt=1:104
m=video 22344 RTP/AVP 102
a=rtpmap:102 H263-1998/90000
a=fmtp:102 CIF=4;QCIF=2;F=1;K=1
i=main video stream
a=label:11
a=pcfg:2
a=rmcap:1 H264/90000
a=mfcap:1 profile-level-id=42A01E; packetization-mode=2
a=acap:1 label:13
a=pcfg:4 m=1 a=1 pt=1:104
m=video 33444 RTP/AVP 103
a=rtpmap:103 H263-1998/90000
a=fmtp:103 CIF=4;QCIF=2;F=1;K=1
i=secondary video (slides)
a=label:12
a=pcfg:3
m=video 33444 RTP/AVP 103
a=rtpmap:103 H263-1998/90000
a=fmtp:103 CIF=4;QCIF=2;F=1;K=1
i=secondary video (slides)
a=label:12
a=pcfg:3
m=application 33002 TCP/BFCP *
a=setup:passive
a=connection:new
a=floorid:1 m-stream:11 12
a=floor-control:s-only
a=confid:4321
a=userid:1234
a=pcfg:5
m=application 33002 TCP/BFCP *
a=setup:passive
a=connection:new
a=floorid:1 m-stream:11 12
a=floor-control:s-only
a=confid:4321
a=userid:1234
a=pcfg:5
If the answerer understands MediaCapNeg, but cannot support the Binary Floor Control Protocol, then it would respond with (invalid empty lines in SDP included again for readability):
如果应答者理解MediaCapNeg，但无法支持二进制地板控制协议，则应答者将使用（为可读性再次包括SDP中的无效空行）：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.22
t=0 0
a=csup:med-v0
a=sescap:1 1,4
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.22
t=0 0
a=csup:med-v0
a=sescap:1 1,4
m=audio 23456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=acfg:1
m=audio 23456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=acfg:1
m=video 41234 RTP/AVP 104
a=rtpmap:104 H264/90000
a=fmtp:104 profile-level-id=42A01E; packetization-mode=2
a=acfg:4 m=1 a=1 pt=1:104
m=video 41234 RTP/AVP 104
a=rtpmap:104 H264/90000
a=fmtp:104 profile-level-id=42A01E; packetization-mode=2
a=acfg:4 m=1 a=1 pt=1:104
m=video 0 RTP/AVP 103
a=acfg:3
m=video 0 RTP/AVP 103
a=acfg:3
m=application 0 TCP/BFCP *
a=acfg:5
m=application 0 TCP/BFCP *
a=acfg:5
An endpoint that doesn't support media capabilities negotiation, but does support H.263 video, would respond with one or two H.263 video streams. In the latter case, the answerer may issue a second offer to reconfigure the session to one audio and one video channel using H.264 or H.263.
不支持媒体功能协商但支持H.263视频的端点将使用一个或两个H.263视频流进行响应。在后一种情况下，应答者可发出第二要约以使用H.264或H.263将会话重新配置为一个音频和一个视频信道。
Session capabilities can include latent capabilities as well. Here's a similar example in which the offerer wishes to initially establish an audio stream, and prefers to later establish two video streams with chair control. If the answerer doesn't understand Media CapNeg, or cannot support the dual video streams or flow control, then it may support a single H.264 video stream. Note that establishment of the most favored configuration will require two offer/answer exchanges.
会话功能也可以包括潜在功能。这里是一个类似的示例，其中报价人希望最初建立一个音频流，并且更愿意在以后通过椅子控制建立两个视频流。如果回答者不理解Media CapNeg，或无法支持双视频流或流控制，则可能支持单个H.264视频流。请注意，建立最优惠配置将需要两次提供/应答交换。
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
a=sescap:1 1,3,4,5
a=sescap:2 1,2
a=sescap:3 1
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
a=sescap:1 1,3,4,5
a=sescap:2 1,2
a=sescap:3 1
a=rmcap:1 H263-1998/90000
a=mfcap:1 CIF=4;QCIF=2;F=1;K=1
a=tcap:1 RTP/AVP TCP/BFCP
m=audio 54322 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=pcfg:1
m=video 22344 RTP/AVP 102
a=rtpmap:102 H264/90000
a=fmtp:102 profile-level-id=42A01E; packetization-mode=2
a=label:11
a=content:main
a=pcfg:2
a=lcfg:3 mt=video t=1 m=1 a=31,32
a=acap:31 label:12
a=acap:32 content:main
a=lcfg:4 mt=video t=1 m=1 a=41,42
a=acap:41 label:13
a=acap:42 content:slides
a=rmcap:1 H263-1998/90000
a=mfcap:1 CIF=4;QCIF=2;F=1;K=1
a=tcap:1 RTP/AVP TCP/BFCP
m=audio 54322 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=pcfg:1
m=video 22344 RTP/AVP 102
a=rtpmap:102 H264/90000
a=fmtp:102 profile-level-id=42A01E; packetization-mode=2
a=label:11
a=content:main
a=pcfg:2
a=lcfg:3 mt=video t=1 m=1 a=31,32
a=acap:31 label:12
a=acap:32 content:main
a=lcfg:4 mt=video t=1 m=1 a=41,42
a=acap:41 label:13
a=acap:42 content:slides
a=lcfg:5 mt=application m=51 t=51
a=tcap:51 TCP/BFCP
a=omcap:51 *
a=acap:51 setup:passive
a=acap:52 connection:new
a=acap:53 floorid:1 m-stream:12 13
a=acap:54 floor-control:s-only
a=acap:55 confid:4321
a=acap:56 userid:1234
a=lcfg:5 mt=application m=51 t=51
a=tcap:51 TCP/BFCP
a=omcap:51 *
a=acap:51 setup:passive
a=acap:52 connection:new
a=acap:53 floorid:1 m-stream:12 13
a=acap:54 floor-control:s-only
a=acap:55 confid:4321
a=acap:56 userid:1234
In this example, the default offer, as seen by endpoints that do not understand capabilities negotiation, proposes a PCMU audio stream and an H.264 video stream. Note that the offered lcfg lines for the video streams don't carry "pt=" parameters because they're not needed (payload type numbers will be assigned in the offer/answer exchange that establishes the streams). Note also that the three "rmcap", "mfcap", and "tcap" attributes used by "lcfg:3" and "lcfg:4" are included at the session level so they may be referenced by both latent configurations. As per Section 3.3, the media attributes generated from the "rmcap", "mfcap", and "tcap" attributes are always media-level attributes. If the answerer supports Media CapNeg, and supports the most desired configuration, it would return the following SDP:
在本例中，如不理解能力协商的端点所见，默认提供建议PCMU音频流和H.264视频流。请注意，为视频流提供的lcfg行不携带“pt=”参数，因为它们不需要（有效负载类型编号将在建立流的提供/应答交换中分配）。还请注意，“lcfg:3”和“lcfg:4”使用的三个“rmcap”、“mfcap”和“tcap”属性包含在会话级别，因此它们可以被两个潜在配置引用。根据第3.3节，由“rmcap”、“mfcap”和“tcap”属性生成的媒体属性始终是媒体级属性。如果应答器支持Media CapNeg，并支持最理想的配置，它将返回以下SDP：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.22
t=0 0
a=csup:med-v0
a=sescap:1 1,3,4,5
a=sescap:2 1,2
a=sescap:3 1
m=audio 23456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=acfg:1
m=video 0 RTP/AVP 102
a=pcfg:2
a=lcfg:3 mt=video t=1 m=1 a=31,32
a=lcfg:4 mt=video t=1 m=1 a=41,42
a=lcfg:5 mt=application t=2
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.22
t=0 0
a=csup:med-v0
a=sescap:1 1,3,4,5
a=sescap:2 1,2
a=sescap:3 1
m=audio 23456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=acfg:1
m=video 0 RTP/AVP 102
a=pcfg:2
a=lcfg:3 mt=video t=1 m=1 a=31,32
a=lcfg:4 mt=video t=1 m=1 a=41,42
a=lcfg:5 mt=application t=2
This exchange supports immediate establishment of an audio stream for preliminary conversation. This exchange would presumably be followed at the appropriate time with a "reconfiguration" offer/answer exchange to add the video and chair control streams.
此交换支持为初步对话立即建立音频流。这种交换可能会在适当的时候进行“重新配置”提供/应答交换，以添加视频和椅子控制流。
In this section, we define extensions to the offer/answer model defined in RFC 3264 [RFC3264] and RFC 5939 [RFC5939] to allow for media format and associated parameter capabilities, latent configurations, and acceptable combinations of media stream configurations to be used with the SDP capability negotiation framework. Note that the procedures defined in this section extend the offer/answer procedures defined in RFC 5939 [RFC5939] Section 6; those procedures form a baseline set of capability negotiation offer/answer procedures that MUST be followed, subject to the extensions defined here.
在本节中，我们定义了RFC 3264[RFC3264]和RFC 5939[RFC5939]中定义的提供/应答模型的扩展，以允许媒体格式和相关参数功能、潜在配置以及可接受的媒体流配置组合与SDP能力协商框架一起使用。注意，本节中定义的程序扩展了RFC 5939[RFC5939]第6节中定义的报价/应答程序；这些程序构成了必须遵循的能力协商提供/应答程序的基线集，但需遵守此处定义的扩展。
SDP capability negotiation [RFC5939] provides a relatively compact means to offer the equivalent of an ordered list of alternative configurations for offered media streams (as would be described by separate "m=" lines and associated attributes). The attributes "acap", "mscap", "mfcap", "omcap", and "rmcap" are designed to map somewhat straightforwardly into equivalent "m=" lines and conventional attributes when invoked by a "pcfg", "lcfg", or "acfg" attribute with appropriate parameters. The "a=pcfg:" lines, along with the "m=" line itself, represent offered media configurations. The "a=lcfg:" lines represent alternative capabilities for future use.
SDP能力协商[RFC5939]提供了一种相对紧凑的方法，为所提供的媒体流提供了一个等效的替代配置有序列表（如单独的“m=”行和相关属性所述）。属性“acap”、“mscap”、“mfcap”、“omcap”和“rmcap”的设计目的是，当“pcfg”、“lcfg”或“acfg”属性使用适当的参数调用时，可以在某种程度上直接映射为等效的“m=”行和常规属性。“a=pcfg:”行以及“m=”行本身代表提供的介质配置。“a=lcfg:”行表示未来使用的替代功能。
The media capabilities negotiation extensions defined in this document cover the following categories of features:
本文档中定义的媒体功能协商扩展包括以下几类功能：
o Media format capabilities and associated parameters ("rmcap", "omcap", "mfcap", and "mscap" attributes)
o 媒体格式功能和相关参数（“rmcap”、“omcap”、“mfcap”和“mscap”属性）
o Potential configurations using those media format capabilities and associated parameters
o 使用这些媒体格式功能和相关参数的潜在配置
o Latent media streams ("lcfg" attribute)
o 潜在媒体流（“lcfg”属性）
o Acceptable combinations of media stream configurations ("sescap" attribute).
o 可接受的媒体流配置组合（“sescap”属性）。
The high-level description of the operation is as follows:
操作的高层描述如下：
When an endpoint generates an initial offer and wants to use the functionality described in the current document, it SHOULD identify and define the media formats and associated parameters it can support via the "rmcap", "omcap", "mfcap", and "mscap" attributes. The SDP media line(s) ("m=") should be made up with the actual configuration
当端点生成初始报价并希望使用当前文档中描述的功能时，它应该通过“rmcap”、“omcap”、“mfcap”和“mscap”属性识别并定义它可以支持的媒体格式和相关参数。SDP媒体行（“m=”）应与实际配置组成
to be used if the other party does not understand capability negotiations (by default, this is the least preferred configuration). Typically, the media line configuration will contain the minimum acceptable configuration from the offerer's point of view.
在另一方不了解能力协商时使用（默认情况下，这是最不首选的配置）。通常，媒体线路配置将包含从报价人的角度来看的最小可接受配置。
Preferred configurations for each media stream are identified following the media line. The present offer may also include latent configuration ("lcfg") attributes, at the media level, describing media streams and/or configurations the offerer is not now offering but that it is willing to support in a future offer/answer exchange. A simple example might be the inclusion of a latent video configuration in an offer for an audio stream.
每个媒体流的首选配置在媒体行之后标识。当前报价还可以包括媒体级别的潜在配置（“lcfg”）属性，描述报价人目前不提供但愿意在未来报价/应答交换中支持的媒体流和/或配置。一个简单的例子可能是在音频流的报价中包含潜在视频配置。
Lastly, if the offerer wishes to impose restrictions on the combinations of potential configurations to be used, it will include session capability ("sescap") attributes indicating those.
最后，如果报价人希望对将要使用的潜在配置组合施加限制，则将包括会话能力（“sescap”）属性，指示这些属性。
If the offerer requires the answerer to understand the media capability extensions, the offerer MUST include a "creq" attribute containing the value "med-v0". If media capability negotiation is required only for specific media descriptions, the "med-v0" value MUST be provided only in "creq" attributes within those media descriptions, as described in RFC 5939 [RFC5939].
如果报价人要求应答人理解媒体能力扩展，报价人必须包含一个包含值“med-v0”的“creq”属性。如果仅对特定介质描述要求介质能力协商，则“med-v0”值必须仅在这些介质描述中的“creq”属性中提供，如RFC 5939[RFC5939]所述。
Below, we provide a more detailed description of how to construct the offer SDP.
下面，我们将更详细地描述如何构建报价SDP。
For each RTP-based media format the offerer wants to include as a media format capability, the offer MUST include an "rmcap" attribute for the media format as defined in Section 3.3.1.
对于报价人希望包含作为媒体格式功能的每个基于RTP的媒体格式，报价必须包含第3.3.1节中定义的媒体格式的“rmcap”属性。
For each non-RTP-based media format the offer wants to include as a media format capability, the offer MUST include an "omcap" attribute for the media format as defined in Section 3.3.1.
对于报价想要包含的每种非RTP媒体格式作为媒体格式功能，报价必须包含第3.3.1节中定义的媒体格式的“omcap”属性。
Since the media capability number space is shared between the "rmcap" and "omcap" attributes, each media capability number provided (including ranges) MUST be unique in the entire SDP.
由于“rmcap”和“omcap”属性之间共享媒体能力编号空间，因此提供的每个媒体能力编号（包括范围）在整个SDP中必须是唯一的。
If an "fmtp" parameter value is needed for a media format (whether or not it is RTP based) in a media capability, then the offer MUST include one or more "mfcap" parameters with the relevant "fmtp" parameter values for that media format as defined in Section 3.3.2. When multiple "mfcap" parameters are provided for a given media capability, they MUST be provided in accordance with the concatenation rules in Section 3.3.2.1.
如果媒体功能中的媒体格式（无论是否基于RTP）需要“fmtp”参数值，则报价必须包括一个或多个“mfcap”参数以及第3.3.2节中定义的该媒体格式的相关“fmtp”参数值。当为给定媒体能力提供多个“mfcap”参数时，必须根据第3.3.2.1节中的连接规则提供这些参数。
For each of the media format capabilities above, the offer MAY include one or more "mscap" parameters with attributes needed for those specific media formats as defined in Section 3.3.3. Such attributes will be instantiated at the media level; hence, session-level-only attributes MUST NOT be used in the "mscap" parameter. The "mscap" parameter MUST NOT include an "rtpmap" or "fmtp" attribute ("rmcap" and "mfcap" are used instead).
对于上述每种媒体格式功能，报价可能包括一个或多个“mscap”参数，以及第3.3.3节中定义的特定媒体格式所需的属性。这些属性将在媒体级别实例化；因此，“mscap”参数中不能使用仅会话级属性。“mscap”参数不得包含“rtpmap”或“fmtp”属性（“使用rmcap”和“mfcap”）。
If the offerer wants to limit the relevance (and use) of a media format capability or parameter to a particular media stream, the media format capability or parameter MUST be provided within the corresponding media description. Otherwise, the media format capabilities and parameters MUST be provided at the session level. Note, however, that the attribute or parameter embedded in these will always be instantiated at the media level.
如果报价人希望将媒体格式功能或参数的相关性（和使用）限制为特定媒体流，则必须在相应的媒体描述中提供媒体格式功能或参数。否则，必须在会话级别提供媒体格式功能和参数。但是，请注意，嵌入其中的属性或参数将始终在媒体级别实例化。
This is due to those parameters being effectively media-level parameters. If session-level attributes are needed, the "acap" attribute defined in RFC 5939 [RFC5939] can be used; however, it does not provide for media-format-specific instantiation.
这是因为这些参数实际上是媒体级参数。如果需要会话级属性，可以使用RFC 5939[RFC5939]中定义的“acap”属性；但是，它不提供特定于媒体格式的实例化。
Inclusion of the above does not constitute an offer to use the capabilities; a potential configuration is needed for that. If the offerer wants to offer one or more of the media capabilities above, they MUST be included as part of a potential configuration ("pcfg") attribute as defined in Section 3.3.4. Each potential configuration MUST include a config-number, and each config-number MUST be unique in the entire SDP (note that this differs from RFC 5939 [RFC5939], which only requires uniqueness within a media description). Also, the config-number MUST NOT overlap with any config-number used by a latent configuration in the SDP. As described in RFC 5939 [RFC5939], lower config-numbers indicate a higher preference; the ordering still applies within a given media description only though.
包含上述内容并不构成使用这些能力的要约；这需要一个潜在的配置。如果报价人希望提供上述一种或多种媒体功能，则必须将其作为第3.3.4节中定义的潜在配置（“pcfg”）属性的一部分。每个可能的配置必须包括一个配置号，并且每个配置号在整个SDP中必须是唯一的（请注意，这与RFC 5939[RFC5939]不同，后者仅要求介质描述中的唯一性）。此外，配置号不得与SDP中潜在配置使用的任何配置号重叠。如RFC 5939[RFC5939]中所述，较低的配置号表示较高的偏好；但仅在给定的媒体描述中，排序仍然适用。
For a media capability to be included in a potential configuration, there MUST be an "m=" parameter in the "pcfg" attribute referencing the media capability number in question. When one or more media capabilities are included in an offered potential configuration ("pcfg"), they completely replace the list of media formats offered in the actual configuration ("m=" line). Any attributes included for those formats remain in the SDP though (e.g., "rtpmap", "fmtp", etc.). For non-RTP-based media formats, the format-name (from the "omcap" media capability) is simply added to the "m=" line as a media format (e.g., t38). For RTP-based media, payload type mappings MUST be provided by use of the "pt" parameter in the potential configuration (see Section 3.3.4.2); payload type escaping may be used in "mfcap", "mscap", and "acap" attributes as defined in Section 3.3.7.
对于要包含在潜在配置中的介质功能，“pcfg”属性中必须有一个“m=”参数，该参数引用了相关的介质功能编号。当提供的潜在配置（“pcfg”）中包含一个或多个媒体功能时，它们将完全取代实际配置（“m=”行）中提供的媒体格式列表。但这些格式包含的任何属性仍保留在SDP中（例如，“rtpmap”、“fmtp”等）。对于非基于RTP的媒体格式，格式名称（来自“omcap”媒体功能）仅作为媒体格式（例如t38）添加到“m=”行中。对于基于RTP的介质，必须通过在潜在配置中使用“pt”参数来提供有效负载类型映射（见第3.3.4.2节）；有效载荷类型转义可用于第3.3.7节中定义的“mfcap”、“mscap”和“acap”属性。
Note that the "mt" parameter MUST NOT be used with the "pcfg" attribute (since it is defined for the "lcfg" attribute only); the media type in a potential configuration cannot be changed from that of the encompassing media description.
请注意，“mt”参数不得与“pcfg”属性一起使用（因为它仅为“lcfg”属性定义）；潜在配置中的介质类型不能更改为包含介质描述的介质类型。
If the offerer wishes to offer one or more latent configurations for future use, the offer MUST include a latent configuration attribute ("lcfg") for each as defined in Section 3.3.6.
如果报价人希望提供一个或多个潜在配置供将来使用，报价必须包括第3.3.6节中定义的每个潜在配置属性（“lcfg”）。
Each "lcfg" attribute
每个“lcfg”属性
o MUST be specified at the media level
o 必须在媒体级别指定
o MUST include a config-number that is unique in the entire SDP (including for any potential configuration attributes). Note that config-numbers in latent configurations do not indicate any preference order
o 必须包括在整个SDP中唯一的配置号（包括任何潜在的配置属性）。请注意，潜在配置中的配置号并不表示任何优先顺序
o MUST include a media type ("mt")
o 必须包括媒体类型（“mt”）
o MUST reference a valid transport capability ("t")
o 必须引用有效的传输能力（“t”）
Each "lcfg" attribute MAY include additional capability references, which may refer to capabilities anywhere in the session description, subject to any restrictions normally associated with such capabilities. For example, a media-level attribute capability must be present at the media level in some media description in the SDP. Note that this differs from the potential configuration attribute, which cannot validly refer to media-level capabilities in another media description (per RFC 5939 [RFC5939], Section 3.5.1).
每个“lcfg”属性可以包括附加的功能引用，这些功能引用可以引用会话描述中的任何位置的功能，但受通常与这些功能相关联的任何限制的约束。例如，在SDP中的某些媒体描述中，媒体级别属性功能必须存在于媒体级别。请注意，这与潜在配置属性不同，潜在配置属性无法在另一介质描述中有效引用介质级功能（根据RFC 5939[RFC5939]，第3.5.1节）。
Potential configurations constitute an actual offer and may instantiate a referenced capability. Latent configurations are not actual offers; hence, they cannot instantiate a referenced capability. Therefore, it is safe for those to refer to capabilities in another media description.
潜在配置构成实际报价，并可能实例化引用的功能。潜在配置不是实际报价；因此，它们不能实例化引用的功能。因此，在另一个媒体描述中引用功能是安全的。
If the offerer wants to indicate restrictions or preferences among combinations of potential and/or latent configurations, a session capability ("sescap") attribute MUST be provided at the session level for each such combination as described in Section 3.3.8. Each "sescap" attribute MUST include a session-num that is unique in the
如果报价人希望指出潜在和/或潜在配置组合之间的限制或偏好，则必须在会话级别为每个此类组合提供会话能力（“sescap”）属性，如第3.3.8节所述。每个“sescap”属性都必须包含在
entire SDP; the lower the session-num the more preferred that combination is. Furthermore, "sescap" preference order takes precedence over any order specified in individual "pcfg" attributes.
整个SDP；会话数越低，该组合越受欢迎。此外，“sescap”优先顺序优先于单个“pcfg”属性中指定的任何顺序。
For example, if we have pcfg-1 and pcfg-2, and sescap-1 references pcfg-2, whereas sescap-2 references pcfg-1, then pcfg-2 will be the most preferred potential configuration. Without the sescap, pcfg-1 would be the most preferred.
例如，如果我们有pcfg-1和pcfg-2，且sescap-1参考pcfg-2，而sescap-2参考pcfg-1，则pcfg-2将是最首选的潜在配置。如果没有sescap，pcfg-1将是最首选的。
When receiving an offer, the answerer MUST check the offer for "creq" attributes containing the value "med-v0"; answerers compliant with this specification will support this value in accordance with the procedures specified in RFC 5939 [RFC5939].
当收到报价时，应答者必须检查报价中包含“med-v0”值的“creq”属性；符合本规范的应答者将根据RFC 5939[RFC5939]中规定的程序支持该值。
The SDP MAY contain
SDP可能包含
o Media format capabilities and associated parameters ("rmcap", "omcap", "mfcap", and "mscap" attributes)
o 媒体格式功能和相关参数（“rmcap”、“omcap”、“mfcap”和“mscap”属性）
o Potential configurations using those media format capabilities and associated parameters
o 使用这些媒体格式功能和相关参数的潜在配置
o Latent media streams ("lcfg" attribute)
o 潜在媒体流（“lcfg”属性）
o Acceptable combinations of media stream configurations ("sescap" attribute)
o 可接受的媒体流配置组合（“sescap”属性）
The high-level informative description of the operation is as follows:
操作的高级信息描述如下：
When the answering party receives the offer, if it supports the required capability negotiation extensions, it should select the most-preferred configuration it can support for each media stream, and build its answer accordingly. The configuration selected for each accepted media stream is placed into the answer as a media line with associated parameters and attributes. If a proposed configuration is chosen for a given media stream, the answer must contain an actual configuration ("acfg") attribute for that media stream to indicate which offered "pcfg" attribute was used to build the answer. The answer should also include any potential or latent configurations the answerer can support, especially any configurations compatible with other potential or latent configurations received in the offer. The answerer should make note of those configurations it might wish to offer in the future.
当应答方收到报价时，如果它支持所需的能力协商扩展，它应该为每个媒体流选择它可以支持的最首选配置，并相应地构建其应答。为每个接受的媒体流选择的配置作为带有相关参数和属性的媒体行放置在应答中。如果为给定媒体流选择了建议的配置，则答案必须包含该媒体流的实际配置（“acfg”）属性，以指示提供的“pcfg”属性用于生成答案。回答还应包括回答者可以支持的任何潜在或潜在配置，尤其是与报价中收到的其他潜在或潜在配置兼容的任何配置。回答者应注意其将来可能提供的配置。
Below we provide a more detailed normative description of how the answerer processes the offer SDP and generates an answer SDP.
下面，我们将对应答者如何处理报价SDP和生成应答SDP进行更详细的规范性描述。
The answerer MUST first determine if it needs to perform media capability negotiation by examining the SDP for valid and preferred potential configuration attributes that include media configuration parameters (i.e., an "m" parameter in the "pcfg" attribute).
应答者必须首先通过检查SDP中是否存在包含介质配置参数的有效和首选潜在配置属性（即“pcfg”属性中的“m”参数），确定是否需要执行介质能力协商。
Such a potential configuration is valid if
这种潜在配置在以下情况下有效：
1. It is valid according to the rules defined in RFC 5939 [RFC5939].
1. 根据RFC 5939[RFC5939]中定义的规则，它是有效的。
2. It contains a config-number that is unique in the entire SDP and does not overlap with any latent configuration config-numbers.
2. 它包含在整个SDP中唯一的配置号，并且不与任何潜在的配置号重叠。
3. All media format capabilities ("rmcap" or "omcap"), media format parameter capabilities ("mfcap"), and media-specific capabilities ("mscap") referenced by the potential configuration ("m" parameter) are valid themselves (as defined in Sections 3.3.1, 3.3.2, and 3.3.3) and each of them is provided either at the session level or within this particular media description.
3. 潜在配置（“m”参数）引用的所有媒体格式功能（“rmcap”或“omcap”）、媒体格式参数功能（“mfcap”）和媒体特定功能（“mscap”）本身有效（如第3.3.1、3.3.2和3.3.3节所定义）它们中的每一个都是在会话级别或在这个特定的媒体描述中提供的。
4. All RTP-based media format capabilities ("rmcap") have a corresponding payload type ("pt") parameter in the potential configuration that results in mapping to a valid payload type that is unique within the resulting SDP.
4. 所有基于RTP的媒体格式功能（“rmcap”）在可能的配置中都有一个对应的有效负载类型（“pt”）参数，该参数会导致映射到在生成的SDP中唯一的有效负载类型。
5. Any concatenation (see Section 3.3.2.1) and substitution (see Section 3.3.7) applied to any capability ("mfcap", "mscap", or "acap") referenced by this potential configuration results in a valid SDP.
5. 任何连接（见第3.3.2.1节）和替换（见第3.3.7节）应用于该潜在配置引用的任何能力（“mfcap”、“mscap”或“acap”），都会产生有效的SDP。
Note that since SDP does not interpret the value of "fmtp" parameters, any resulting "fmtp" parameter value will be considered valid.
注意，由于SDP不解释“fmtp”参数的值，因此任何产生的“fmtp”参数值都将被视为有效。
Secondly, the answerer MUST determine the order in which potential configurations are to be negotiated. In the absence of any session capability ("sescap") attributes, this simply follows the rules of RFC 5939 [RFC5939], with a lower config-number within a media description being preferred over a higher one. If a valid "sescap" attribute is present, the preference order provided in the "sescap" attribute MUST take precedence. A "sescap" attribute is considered valid if
其次，回答者必须确定潜在配置的谈判顺序。在没有任何会话能力（“sescap”）属性的情况下，这只是遵循RFC 5939[RFC5939]的规则，在媒体描述中，较低的配置号优先于较高的配置号。如果存在有效的“sescap”属性，“sescap”属性中提供的优先顺序必须优先。“sescap”属性在以下情况下被视为有效
1. It adheres to the rules provided in Section 3.3.8.
1. 它遵守第3.3.8节规定的规则。
2. All the configurations referenced by the "sescap" attribute are valid themselves (note that this can include the actual, potential, and latent configurations).
2. “sescap”属性引用的所有配置本身都是有效的（请注意，这可能包括实际配置、潜在配置和潜在配置）。
The answerer MUST now process the offer for each media stream based on the most preferred valid potential configuration in accordance with the procedures specified in RFC 5939 [RFC5939], Section 3.6.2, and further extended below:
应答者现在必须根据RFC 5939[RFC5939]第3.6.2节规定的程序，并进一步扩展到以下内容，基于最优选的有效潜在配置，处理每个媒体流的报价：
o If one or more media format capabilities are included in the potential configuration, then they replace all media formats provided in the "m=" line for that media description. For non-RTP-based media formats ("omcap"), the format-name is added. For RTP-based media formats ("rmcap"), the payload-type specified in the payload-type mapping ("pt") is added and a corresponding "rtpmap" attribute is added to the media description.
o 如果潜在配置中包含一个或多个媒体格式功能，则它们将替换“m=”行中为该媒体描述提供的所有媒体格式。对于非基于RTP的媒体格式（“omcap”），将添加格式名称。对于基于RTP的媒体格式（“rmcap”），将添加有效负载类型映射（“pt”）中指定的有效负载类型，并将相应的“rtpmap”属性添加到媒体描述中。
o If one or more media format parameter capabilities are included in the potential configuration, then the corresponding "fmtp" attributes are added to the media description. Note that this inclusion is done indirectly via the media format capability.
o 如果潜在配置中包含一个或多个媒体格式参数功能，则相应的“fmtp”属性将添加到媒体描述中。请注意，此包含是通过媒体格式功能间接完成的。
o If one or more media-specific capabilities are included in the potential configuration, then the corresponding attributes are added to the media description. Note that this inclusion is done indirectly via the media format capability.
o 如果潜在配置中包含一个或多个特定于介质的功能，则相应的属性将添加到介质描述中。请注意，此包含是通过媒体格式功能间接完成的。
o When checking to see if the answerer supports a given potential configuration that includes one or more media format capabilities, the answerer MUST support at least one of the media formats offered. If he does not, the answerer MUST proceed to the next potential configuration based on the preference order that applies.
o 当检查应答者是否支持包含一个或多个媒体格式功能的给定潜在配置时，应答者必须至少支持提供的一种媒体格式。如果没有，应答者必须根据适用的优先顺序进行下一个潜在配置。
o If session capability ("sescap") preference ordering is included, then the potential configuration selection process MUST adhere to the ordering provided. Note that this may involve coordinated selection of potential configurations between media descriptions. The answerer MUST accept one of the offered sescap combinations (i.e., all the required potential configurations specified) or it MUST reject the entire session.
o 如果包括会话能力（“sescap”）首选项排序，则潜在的配置选择过程必须遵循提供的排序。注意，这可能涉及媒体描述之间潜在配置的协调选择。回答者必须接受其中一种提供的sescap组合（即所有规定的所需潜在配置），或者必须拒绝整个会话。
Once the answerer has selected a valid and supported offered potential configuration for all of the media streams (or has fallen back to the actual configuration plus any added session attributes), the answerer MUST generate a valid answer SDP as described in RFC 5939 [RFC5939], Section 3.6.2, and further extended below:
一旦应答者为所有媒体流选择了有效且受支持的潜在配置（或返回到实际配置加上任何添加的会话属性），应答者必须生成RFC 5939[RFC5939]第3.6.2节所述的有效应答SDP，并进一步扩展如下：
o Additional answer capabilities and potential configurations MAY be returned in accordance with Section 3.3.6.1. Capability numbers and configuration numbers for those MUST be distinct from the ones used in the offer SDP.
o 根据第3.3.6.1节，可返回额外的应答能力和潜在配置。功能编号和配置编号必须与报价SDP中使用的编号不同。
o Latent configuration processing and answer generation MUST be performed, as specified below.
o 必须执行潜在配置处理和应答生成，如下所述。
o Session capability specification for the potential and latent configurations in the answer MAY be included (see Section 3.3.8).
o 答案中可能包括潜在和潜在配置的会话能力规范（见第3.3.8节）。
The answerer MUST determine if it needs to perform any latent configuration processing by examining the SDP for valid latent configuration attributes ("lcfg"). An "lcfg" attribute is considered valid if:
应答者必须通过检查SDP的有效潜在配置属性（“lcfg”）来确定是否需要执行任何潜在配置处理。在以下情况下，“lcfg”属性被视为有效：
o It adheres to the description in Section 3.3.5.
o 其符合第3.3.5节中的说明。
o It includes a config-number that is unique in the entire SDP and does not overlap with any potential configuration config-number.
o 它包括一个配置号，该配置号在整个SDP中是唯一的，并且不与任何潜在的配置号重叠。
o It includes a valid media type ("mt=").
o 它包括有效的媒体类型（“mt=”）。
o It references a valid transport capability ("t=").
o 它引用了一个有效的传输能力（“t=”）。
o All other capabilities referenced by it are valid.
o 它引用的所有其他功能都是有效的。
For each such valid latent configuration in the offer, the answerer checks to see if it could support the latent configuration in a subsequent offer/answer exchange. If so, it includes the latent configuration with the same configuration number in the answer, similar to the way potential configurations are processed and the selected one returned in an actual configuration attribute (see RFC 5939 [RFC5939]). If the answerer supports only a (non-mandatory) subset of the parameters offered in a latent configuration, the answer latent configuration will include only those parameters supported (similar to "acfg" processing). Note that latent configurations do not constitute an actual offer at this point in time; they merely indicate additional configurations that could be supported.
对于报价中的每个此类有效潜在配置，应答者都会进行检查，以确定其是否能够在随后的报价/应答交换中支持潜在配置。如果是，则在回答中包括具有相同配置编号的潜在配置，类似于潜在配置的处理方式，以及在实际配置属性中返回的所选配置（请参阅RFC 5939[RFC5939]）。如果应答者仅支持潜在配置中提供的参数子集（非强制性），则应答潜在配置将仅包括支持的参数（类似于“acfg”处理）。请注意，此时潜在配置并不构成实际报价；它们仅表示可以支持的其他配置。
If a session capability ("sescap") attribute is included and it references a latent configuration, then the answerer processing of that latent configuration must be done within the constraints specified by that session capability. That is, it must be possible to support it at the same time as any required (i.e., non-optional) potential configurations in the session capability. The answerer may in turn add his own sescap indications in the answer as well.
如果包含会话能力（“sescap”）属性，且该属性引用潜在配置，则应答者必须在该会话能力指定的约束范围内处理该潜在配置。也就是说，它必须能够与会话功能中的任何必需（即非可选）潜在配置同时支持它。回答者也可以在回答中添加自己的sescap指示。
The offerer MUST process the answer in accordance with Section 3.6.3 of RFC 5939 [RFC5939] and the further explanation below.
报价人必须根据RFC 5939[RFC5939]第3.6.3节和下文的进一步解释处理答案。
When the offerer processes the answer SDP based on a valid actual configuration attribute in the answer, and that valid configuration includes one or more media capabilities, the processing MUST furthermore be done as if the offer was sent using those media capabilities instead of the actual configuration. In particular, the media formats in the "m=" line, and any associated payload type mappings ("rtpmap"), "fmtp" parameters ("mfcap"), and media-specific attributes ("mscap") MUST be used. Note that this may involve use of concatenation and substitution rules (see Sections 3.3.2.1 and 3.3.7). The actual configuration attribute may also be used to infer the lack of acceptability of higher-preference configurations that were not chosen, subject to any constraints provided by a session capability ("sescap") attribute in the offer. Note that the SDP capability negotiation base specification [RFC5939] requires the answerer to choose the highest-preference configuration it can support, subject to local policies.
当报价人基于应答中的有效实际配置属性处理应答SDP，并且该有效配置包括一个或多个媒体功能时，还必须按照使用这些媒体功能而不是实际配置发送报价的方式进行处理。特别是，必须使用“m=”行中的媒体格式，以及任何相关的有效负载类型映射（“rtpmap”）、“fmtp”参数（“mfcap”）和媒体特定属性（“mscap”）。注意，这可能涉及使用连接和替换规则（见第3.3.2.1节和第3.3.7节）。实际配置属性还可用于推断未选择的更高偏好配置的可接受性不足，受要约中会话能力（“sescap”）属性提供的任何约束的约束。请注意，SDP能力协商基础规范[RFC5939]要求应答者根据本地策略选择其可以支持的最高首选配置。
When the offerer receives the answer, it SHOULD furthermore make note of any capabilities and/or latent configurations included for future use, and any constraints on how those may be combined.
当报价人收到答复时，还应注意未来使用的任何功能和/或潜在配置，以及如何组合这些功能和/或潜在配置的任何限制。
If, at a later time, one of the parties wishes to modify the operating parameters of a session, e.g., by adding a new media stream, or by changing the properties used on an existing stream, it can do so via the mechanisms defined for offer/answer [RFC3264]. If the initiating party has remembered the codecs, potential configurations, latent configurations, and session capabilities provided by the other party in the earlier negotiation, it MAY use this knowledge to maximize the likelihood of a successful modification of the session. Alternatively, the initiator MAY perform a new capabilities exchange as part of the reconfiguration.
如果一方希望在稍后修改会话的操作参数，例如，通过添加新媒体流，或通过更改现有流上使用的属性，则可通过为提供/应答[RFC3264]定义的机制来实现。如果发起方已记住另一方在先前协商中提供的编解码器、潜在配置、潜在配置和会话能力，则发起方可使用该知识来最大化会话成功修改的可能性。或者，作为重新配置的一部分，发起方可以执行新的能力交换。
In such a case, the new capabilities will replace the previously negotiated capabilities. This may be useful if conditions change on the endpoint.
在这种情况下，新能力将取代先前协商的能力。如果端点上的条件发生变化，这可能很有用。
In this section, we provide examples showing how to use the media capabilities with the SDP capability negotiation.
在本节中，我们将提供示例，说明如何在SDP能力协商中使用媒体能力。
This example provides a choice of one of six variations of the Adaptive Multi-Rate codec. In this example, the default configuration as specified by the media line is the same as the most preferred configuration. Each configuration uses a different payload type number so the offerer can interpret early media.
此示例提供了自适应多速率编解码器的六种变体之一的选择。在此示例中，媒体线路指定的默认配置与最首选配置相同。每个配置使用不同的有效负载类型编号，以便报价人能够解释早期媒体。
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
m=audio 54322 RTP/AVP 96
a=rtpmap:96 AMR-WB/16000/1
a=fmtp:96 mode-change-capability=1; max-red=220; \
mode-set=0,2,4,7
a=rmcap:1,3,5 audio AMR-WB/16000/1
a=rmcap:2,4,6 audio AMR/8000/1
a=mfcap:1,2,3,4 mode-change-capability=1
a=mfcap:5,6 mode-change-capability=2
a=mfcap:1,2,3,5 max-red=220
a=mfcap:3,4,5,6 octet-align=1
a=mfcap:1,3,5 mode-set=0,2,4,7
a=mfcap:2,4,6 mode-set=0,3,5,6
a=pcfg:1 m=1 pt=1:96
a=pcfg:2 m=2 pt=2:97
a=pcfg:3 m=3 pt=3:98
a=pcfg:4 m=4 pt=4:99
a=pcfg:5 m=5 pt=5:100
a=pcfg:6 m=6 pt=6:101
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
m=audio 54322 RTP/AVP 96
a=rtpmap:96 AMR-WB/16000/1
a=fmtp:96 mode-change-capability=1; max-red=220; \
mode-set=0,2,4,7
a=rmcap:1,3,5 audio AMR-WB/16000/1
a=rmcap:2,4,6 audio AMR/8000/1
a=mfcap:1,2,3,4 mode-change-capability=1
a=mfcap:5,6 mode-change-capability=2
a=mfcap:1,2,3,5 max-red=220
a=mfcap:3,4,5,6 octet-align=1
a=mfcap:1,3,5 mode-set=0,2,4,7
a=mfcap:2,4,6 mode-set=0,3,5,6
a=pcfg:1 m=1 pt=1:96
a=pcfg:2 m=2 pt=2:97
a=pcfg:3 m=3 pt=3:98
a=pcfg:4 m=4 pt=4:99
a=pcfg:5 m=5 pt=5:100
a=pcfg:6 m=6 pt=6:101
In the above example, media capability 1 could have been excluded from the first "rmcap" declaration and from the corresponding "mfcap" attributes, and the "pcfg:1" attribute line could have been simply "pcfg:1".
在上述示例中，媒体功能1可能已从第一个“rmcap”声明和相应的“mfcap”属性中排除，而“pcfg:1”属性行可能只是“pcfg:1”。
The next example offers a video stream with three options of H.264 and four transports. It also includes an audio stream with different audio qualities: four variations of AMR, or AC3. The offer looks something like the following:
下一个示例提供了一个具有三个选项的视频流，即H.264和四个传输。它还包括具有不同音频质量的音频流：AMR或AC3的四种变体。报价如下所示：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=An SDP Media NEG example
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
a=ice-pwd:speEc3QGZiNWpVLFJhQX
m=video 49170 RTP/AVP 100
c=IN IP4 192.0.2.56
a=maxprate:1000
a=rtcp:51540
a=sendonly
a=candidate 12345 1 UDP 9 192.0.2.56 49170 host
a=candidate 23456 2 UDP 9 192.0.2.56 51540 host
a=candidate 34567 1 UDP 7 198.51.100.1 41345 srflx raddr \
192.0.2.56 rport 49170
a=candidate 45678 2 UDP 7 198.51.100.1 52567 srflx raddr \
192.0.2.56 rport 51540
a=candidate 56789 1 UDP 3 192.0.2.100 49000 relay raddr \
192.0.2.56 rport 49170
a=candidate 67890 2 UDP 3 192.0.2.100 49001 relay raddr \
192.0.2.56 rport 51540
b=AS:10000
b=TIAS:10000000
b=RR:4000
b=RS:3000
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42A01E; packetization-mode=2; \
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==; \
sprop-interleaving-depth=45; sprop-deint-buf-req=64000; \
sprop-init-buf-time=102478; deint-buf-cap=128000
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
a=rmcap:1-3,7-9 H264/90000
a=rmcap:4-6 rtx/90000
a=mfcap:1-9 profile-level-id=42A01E
a=mfcap:1-9 aMljiA==
a=mfcap:1,4,7 packetization-mode=0
a=mfcap:2,5,8 packetization-mode=1
a=mfcap:3,6,9 packetization-mode=2
a=mfcap:1-9 sprop-parameter-sets=Z0IACpZTBYmI
a=mfcap:1,7 sprop-interleaving-depth=45; \
sprop-deint-buf-req=64000; sprop-init-buf-time=102478; \
deint-buf-cap=128000
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=An SDP Media NEG example
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
a=ice-pwd:speEc3QGZiNWpVLFJhQX
m=video 49170 RTP/AVP 100
c=IN IP4 192.0.2.56
a=maxprate:1000
a=rtcp:51540
a=sendonly
a=candidate 12345 1 UDP 9 192.0.2.56 49170 host
a=candidate 23456 2 UDP 9 192.0.2.56 51540 host
a=candidate 34567 1 UDP 7 198.51.100.1 41345 srflx raddr \
192.0.2.56 rport 49170
a=candidate 45678 2 UDP 7 198.51.100.1 52567 srflx raddr \
192.0.2.56 rport 51540
a=candidate 56789 1 UDP 3 192.0.2.100 49000 relay raddr \
192.0.2.56 rport 49170
a=candidate 67890 2 UDP 3 192.0.2.100 49001 relay raddr \
192.0.2.56 rport 51540
b=AS:10000
b=TIAS:10000000
b=RR:4000
b=RS:3000
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42A01E; packetization-mode=2; \
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==; \
sprop-interleaving-depth=45; sprop-deint-buf-req=64000; \
sprop-init-buf-time=102478; deint-buf-cap=128000
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
a=rmcap:1-3,7-9 H264/90000
a=rmcap:4-6 rtx/90000
a=mfcap:1-9 profile-level-id=42A01E
a=mfcap:1-9 aMljiA==
a=mfcap:1,4,7 packetization-mode=0
a=mfcap:2,5,8 packetization-mode=1
a=mfcap:3,6,9 packetization-mode=2
a=mfcap:1-9 sprop-parameter-sets=Z0IACpZTBYmI
a=mfcap:1,7 sprop-interleaving-depth=45; \
sprop-deint-buf-req=64000; sprop-init-buf-time=102478; \
deint-buf-cap=128000
a=mfcap:4 apt=100
a=mfcap:5 apt=99
a=mfcap:6 apt=98
a=mfcap:4-6 rtx-time=3000
a=mscap:1-6 rtcp-fb nack
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 \
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32
a=pcfg:1 t=1 m=1,4 a=1 pt=1:100,4:97
a=pcfg:2 t=1 m=2,5 a=1 pt=2:99,4:96
a=pcfg:3 t=1 m=3,6 a=1 pt=3:98,6:95
a=pcfg:4 t=2 m=7 a=1 pt=7:100
a=pcfg:5 t=2 m=8 a=1 pt=8:99
a=pcfg:6 t=2 m=9 a=1 pt=9:98
a=pcfg:7 t=3 m=1,3 pt=1:100,4:97
a=pcfg:8 t=3 m=2,4 pt=2:99,4:96
a=pcfg:9 t=3 m=3,6 pt=3:98,6:95
m=audio 49176 RTP/AVP 101 100 99 98
c=IN IP4 192.0.2.56
a=ptime:60
a=maxptime:200
a=rtcp:51534
a=sendonly
a=candidate 12345 1 UDP 9 192.0.2.56 49176 host
a=candidate 23456 2 UDP 9 192.0.2.56 51534 host
a=candidate 34567 1 UDP 7 198.51.100.1 41348 srflx \
raddr 192.0.2.56 rport 49176
a=candidate 45678 2 UDP 7 198.51.100.1 52569 srflx \
raddr 192.0.2.56 rport 51534
a=candidate 56789 1 UDP 3 192.0.2.100 49002 relay \
raddr 192.0.2.56 rport 49176
a=candidate 67890 2 UDP 3 192.0.2.100 49003 relay \
raddr 192.0.2.56 rport 51534
b=AS:512
b=TIAS:512000
b=RR:4000
b=RS:3000
a=maxprate:120
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2
a=rtpmap:100 AMR-WB/16000/2
a=fmtp:100 octet-align=1; interleaving=30
a=rtpmap:101 AMR-WB+/72000/2
a=fmtp:101 interleaving=50; int-delay=160000;
a=rmcap:14 ac3/48000/6
a=acap:23 crypto:1 AES_CM_128_HMAC_SHA1_80 \
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32
a=mfcap:4 apt=100
a=mfcap:5 apt=99
a=mfcap:6 apt=98
a=mfcap:4-6 rtx-time=3000
a=mscap:1-6 rtcp-fb nack
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 \
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32
a=pcfg:1 t=1 m=1,4 a=1 pt=1:100,4:97
a=pcfg:2 t=1 m=2,5 a=1 pt=2:99,4:96
a=pcfg:3 t=1 m=3,6 a=1 pt=3:98,6:95
a=pcfg:4 t=2 m=7 a=1 pt=7:100
a=pcfg:5 t=2 m=8 a=1 pt=8:99
a=pcfg:6 t=2 m=9 a=1 pt=9:98
a=pcfg:7 t=3 m=1,3 pt=1:100,4:97
a=pcfg:8 t=3 m=2,4 pt=2:99,4:96
a=pcfg:9 t=3 m=3,6 pt=3:98,6:95
m=audio 49176 RTP/AVP 101 100 99 98
c=IN IP4 192.0.2.56
a=ptime:60
a=maxptime:200
a=rtcp:51534
a=sendonly
a=candidate 12345 1 UDP 9 192.0.2.56 49176 host
a=candidate 23456 2 UDP 9 192.0.2.56 51534 host
a=candidate 34567 1 UDP 7 198.51.100.1 41348 srflx \
raddr 192.0.2.56 rport 49176
a=candidate 45678 2 UDP 7 198.51.100.1 52569 srflx \
raddr 192.0.2.56 rport 51534
a=candidate 56789 1 UDP 3 192.0.2.100 49002 relay \
raddr 192.0.2.56 rport 49176
a=candidate 67890 2 UDP 3 192.0.2.100 49003 relay \
raddr 192.0.2.56 rport 51534
b=AS:512
b=TIAS:512000
b=RR:4000
b=RS:3000
a=maxprate:120
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2
a=rtpmap:100 AMR-WB/16000/2
a=fmtp:100 octet-align=1; interleaving=30
a=rtpmap:101 AMR-WB+/72000/2
a=fmtp:101 interleaving=50; int-delay=160000;
a=rmcap:14 ac3/48000/6
a=acap:23 crypto:1 AES_CM_128_HMAC_SHA1_80 \
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32
a=tcap:4 RTP/SAVP
a=pcfg:10 t=4 a=23
a=pcfg:11 t=4 m=14 a=23 pt=14:102
a=tcap:4 RTP/SAVP
a=pcfg:10 t=4 a=23
a=pcfg:11 t=4 m=14 a=23 pt=14:102
This offer illustrates the advantage in compactness that arises if one can avoid deleting the base configuration attributes and recreating them in "acap" attributes for the potential configurations.
如果可以避免删除基本配置属性并在潜在配置的“acap”属性中重新创建它们，则此选项说明了紧凑性方面的优势。
If an endpoint has limited signal processing capacity, it might be capable of supporting, say, a G.711 mu-law audio stream in combination with an H.264 video stream, or a G.729B audio stream in combination with an H.263-1998 video stream. It might then issue an offer like the following:
如果端点具有有限的信号处理能力，则其可能能够支持，例如，与H.264视频流组合的G.711μ律音频流，或与H.263-1998视频流组合的G.729B音频流。然后，它可能会发布如下报价：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
a=sescap:1 2,4
a=sescap:2 1,3
m=audio 54322 RTP/AVP 18
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rmcap:1 PCMU/8000
a=pcfg:1 m=1 pt=1:0
a=pcfg:2
m=video 54344 RTP/AVP 100
a=rtpmap:100 H263-1998/90000
a=rmcap:2 H264/90000
a=mfcap:2 profile-level-id=42A01E; packetization-mode=2
a=pcfg:3 m=2 pt=2:101
a=pcfg:4
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
a=sescap:1 2,4
a=sescap:2 1,3
m=audio 54322 RTP/AVP 18
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rmcap:1 PCMU/8000
a=pcfg:1 m=1 pt=1:0
a=pcfg:2
m=video 54344 RTP/AVP 100
a=rtpmap:100 H263-1998/90000
a=rmcap:2 H264/90000
a=mfcap:2 profile-level-id=42A01E; packetization-mode=2
a=pcfg:3 m=2 pt=2:101
a=pcfg:4
Note that the preferred session configuration (and the default as well) is G.729B with H.263. This overrides the individual media stream preferences that are PCMU and H.264 by the potential configuration numbering rule.
请注意，首选的会话配置（以及默认配置）是带有H.263的G.729B。这将通过潜在的配置编号规则覆盖PCMU和H.264的各个媒体流首选项。
Consider a case in which the offerer can support either G.711 mu-law or G.729B, along with DTMF telephony events for the 12 common touchtone signals, but is willing to support simple G.711 mu-law
考虑这样一种情况，即发售方可以支持G.711MU定律或G.79B，以及DTMF电话事件，用于12种常见的触音信号，但愿意支持简单的G.711MU定律。
audio as a last resort. In addition, the offerer wishes to announce its ability to support video and Message Session Relay Protocol (MSRP) in the future, but does not wish to offer a video stream or an MSRP stream at present. The offer might look like the following:
音频作为最后手段。此外，报价人希望宣布其将来能够支持视频和消息会话中继协议（MSRP），但目前不希望提供视频流或MSRP流。报价可能如下所示：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
m=audio 23456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rmcap:1 PCMU/8000
a=rmcap:2 G729/8000
a=rmcap:3 telephone-event/8000
a=mfcap:3 0-11
a=pcfg:1 m=1,3|2,3 pt=1:0,2:18,3:100
a=lcfg:2 mt=video t=1 m=10|11
a=rmcap:10 H263-1998/90000
a=rmcap:11 H264/90000
a=tcap:1 RTP/AVP
a=lcfg:3 mt=message t=2 m=20
a=tcap:2 TCP/MSRP
a=omcap:20 *
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=creq:med-v0
m=audio 23456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rmcap:1 PCMU/8000
a=rmcap:2 G729/8000
a=rmcap:3 telephone-event/8000
a=mfcap:3 0-11
a=pcfg:1 m=1,3|2,3 pt=1:0,2:18,3:100
a=lcfg:2 mt=video t=1 m=10|11
a=rmcap:10 H263-1998/90000
a=rmcap:11 H264/90000
a=tcap:1 RTP/AVP
a=lcfg:3 mt=message t=2 m=20
a=tcap:2 TCP/MSRP
a=omcap:20 *
The first "lcfg" attribute line ("lcfg:2") announces support for H.263 and H.264 video (H.263 preferred) for future negotiation. The second "lcfg" attribute line ("lcfg:3") announces support for MSRP for future negotiation. The "m=" line and the "rtpmap" attribute offer an audio stream and provide the lowest precedence configuration (PCMU without any DTMF encoding). The rmcap lines define the RTP-based media format capabilities (PCMU, G729, telephone-event, H263-1998, and H264) and the omcap line defines the non-RTP-based media format capability (wildcard). The "mfcap" attribute provides the format parameters for telephone-event, specifying the 12 commercial DTMF 'digits'. The "pcfg" attribute line defines the most-preferred media configuration as PCMU plus DTMF events and the next-most-preferred configuration as G.729B plus DTMF events.
第一个“lcfg”属性行（“lcfg:2”）宣布支持用于未来协商的H.263和H.264视频（首选H.263）。第二个“lcfg”属性行（“lcfg:3”）宣布支持MSRP用于未来谈判。“m=”line和“rtpmap”属性提供音频流，并提供最低优先级配置（PCMU无任何DTMF编码）。rmcap行定义了基于RTP的媒体格式功能（PCMU、G729、电话事件、H263-1998和H264），omcap行定义了非基于RTP的媒体格式功能（通配符）。“mfcap”属性提供电话事件的格式参数，指定12个商用DTMF“数字”。“pcfg”属性行将最首选的媒体配置定义为PCMU加DTMF事件，下一个最首选的配置定义为G.729B加DTMF事件。
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 answer like the following:
如果回答者能够支持所有可能的配置，并且还支持H.263视频（但不支持H.264），那么回答者将给出如下回答：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
a=csup:med-v0
m=audio 54322 RTP/AVP 0 100
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-11
a=acfg:1 m=1,3 pt=1:0,3:100
a=pcfg:1 m=2,3 pt=2:18,3:100
a=lcfg:2 mt=video t=1 m=10
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
a=csup:med-v0
m=audio 54322 RTP/AVP 0 100
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-11
a=acfg:1 m=1,3 pt=1:0,3:100
a=pcfg:1 m=2,3 pt=2:18,3:100
a=lcfg:2 mt=video t=1 m=10
The "lcfg" attribute line announces the capability to support H.263 video at a later time. The media line and subsequent "rtpmap" and "fmtp" attribute lines present the selected configuration for the media stream. The "acfg" attribute line identifies the potential configuration from which it was taken, and the "pcfg" attribute line announces the potential capability to support G.729 with DTMF events as well. If, at some later time, congestion becomes a problem in the network, either party may, with expectation of success, offer a reconfiguration of the media stream to use G.729 in order to reduce packet sizes.
“lcfg”属性行宣布以后支持H.263视频的能力。媒体行和随后的“rtpmap”和“fmtp”属性行表示媒体流的选定配置。“acfg”属性行确定了采用它的潜在配置，“pcfg”属性行宣布了支持G.729和DTMF事件的潜在能力。如果在稍后的某个时间，拥塞成为网络中的问题，则任何一方都可以期望成功地提供媒体流的重新配置以使用G.729以减小分组大小。
IANA has registered the following new SDP attributes:
IANA已注册以下新的SDP属性：
Attribute name: rmcap Long form name: RTP-based media format capability Type of attribute: session-level and media-level Subject to charset: no Purpose: associate RTP-based media capability number(s) with media subtype and encoding parameters Appropriate Values: see Section 3.3.1 Contact name: Flemming Andreasen, fandres@cisco.com
属性名称：rmcap长格式名称：基于RTP的媒体格式功能属性类型：会话级别和媒体级别取决于字符集：无用途：将基于RTP的媒体功能编号与媒体子类型和编码参数关联适当的值：请参阅第3.3.1节联系人姓名：Flemming Andreasen，fandres@cisco.com
Attribute name: omcap Long form name: non-RTP-based media format capability Type of attribute: session-level and media-level Subject to charset: no Purpose: associate non-RTP-based media capability number(s) with media subtype and encoding parameters Appropriate Values: see Section 3.3.1 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名称：omcap长格式名称：基于非RTP的媒体格式功能属性类型：会话级别和媒体级别根据字符集：无目的：将基于非RTP的媒体功能编号与媒体子类型和编码参数关联适当的值：请参阅第3.3.1节联系人姓名：Flemming Andreasen，fandreas@cisco.com
Attribute name: mfcap Long form name: media format parameter capability Type of attribute: session-level and media-level Subject to charset: no Purpose: associate media format attributes and parameters with media format capabilities Appropriate Values: see Section 3.3.2 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名称：mfcap长格式名称：媒体格式参数功能属性类型：会话级别和媒体级别取决于字符集：无用途：将媒体格式属性和参数与媒体格式功能关联适当的值：请参阅第3.3.2节联系人姓名：Flemming Andreasen，fandreas@cisco.com
Attribute name: mscap Long form name: media-specific capability Type of attribute: session-level and media-level Subject to charset: no Purpose: associate media-specific attributes and parameters with media capabilities Appropriate Values: see Section 3.3.3 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名称：mscap长格式名称：媒体特定功能属性类型：会话级别和媒体级别取决于字符集：无用途：将媒体特定属性和参数与媒体功能关联适当的值：请参阅第3.3.3节联系人姓名：Flemming Andreasen，fandreas@cisco.com
Attribute name: lcfg Long form name: latent configuration Type of attribute: media-level Subject to charset: no Purpose: to announce supportable media streams without offering them for immediate use. Appropriate Values: see Section 3.3.5 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名称：lcfg长格式名称：属性的潜在配置类型：媒体级别取决于字符集：无目的：宣布可支持的媒体流，而不提供它们以供立即使用。适当值：见第3.3.5节联系人姓名：Flemming Andreasen，fandreas@cisco.com
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
属性名称：sescap长表单名称：会话功能属性类型：会话级别取决于字符集：无目的：指定可接受的媒体流配置组合并确定其优先级。适当值：见第3.3.8节联系人姓名：Flemming Andreasen，fandreas@cisco.com
IANA has added the new option tag "med-v0", defined in this document, to the "SDP Capability Negotiation Option Capability Tags" registry created for RFC 5939 [RFC5939].
IANA已将本文件中定义的新选项标签“med-v0”添加到为RFC 5939[RFC5939]创建的“SDP能力协商选项能力标签”注册表中。
IANA has changed the "SDP Capability Negotiation Potential Configuration Parameters" registry, currently registered and defined by RFC 5939 [RFC5939], as follows:
IANA已将RFC 5939[RFC5939]当前注册和定义的“SDP能力协商潜在配置参数”注册表更改如下：
The name of the registry should be "SDP Capability Negotiation Configuration Parameters Registry" and it should contain a table with the following column headings:
注册表的名称应为“SDP能力协商配置参数注册表”，并应包含具有以下列标题的表：
o Encoding Name: The syntactical value used for the capability negotiation configuration parameter, as defined in RFC 5939 [RFC5939], Section 3.5.
o 编码名称：用于能力协商配置参数的语法值，如RFC 5939[RFC5939]第3.5节所定义。
o Descriptive Name: The name commonly used to refer to the capability negotiation configuration parameter.
o 描述性名称：通常用于引用能力协商配置参数的名称。
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 潜在配置定义：对RFC的引用，在潜在配置属性的上下文中定义配置参数。如果未为潜在配置定义配置参数，则必须显示字符串“N/A”（不适用）。
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 实际配置定义：对RFC的引用，在实际配置属性的上下文中定义配置参数。如果未为实际配置定义配置参数，则必须显示字符串“N/A”（不适用）。
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.
o 潜在配置定义：对RFC的引用，在潜在配置属性的上下文中定义配置参数。如果未为潜在配置定义配置参数，则必须显示字符串“N/A”（不适用）。
An IANA SDP Capability Negotiation Configuration registration MUST be documented in an RFC in accordance with the IETF Review policy [RFC5226]. Furthermore:
IANA SDP能力协商配置注册必须根据IETF审查政策[RFC5226]记录在RFC中。此外：
o The RFC MUST define the syntax and semantics of each new potential configuration parameter.
o RFC必须定义每个新潜在配置参数的语法和语义。
o The syntax MUST adhere to the syntax provided for extension configuration lists in RFC 5939 [RFC5939], Section 3.5.1, and the semantics MUST adhere to the semantics provided for extension configuration lists in RFC 5939 [RFC5939], Sections 3.5.1 and 3.5.2.
o 语法必须符合RFC 5939[RFC5939]第3.5.1节中为扩展配置列表提供的语法，语义必须符合RFC 5939[RFC5939]第3.5.1和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 适用于潜在配置的配置参数还必须遵守第3.3.5节中提供的语法和本文档中总体定义的语义。
o Associated with each registration MUST be the encoding name for the parameter as well as a short descriptive name for it.
o 与每个注册关联的必须是参数的编码名称以及简短的描述性名称。
o Each registration MUST specify if it applies to
o 每次注册必须说明其是否适用于
* Potential configurations
* 潜在构型
* Actual configurations
* 实际配置
* Latent configurations
* 潜在构型
IANA has registered the following capability negotiation configuration parameters:
IANA已注册以下能力协商配置参数：
Encoding Name: a
Descriptive Name: Attribute Configuration
Potential Configuration Definition: [RFC5939]
Actual Configuration Definition: [RFC5939]
Latent Configuration Definition: [RFC6871]
Encoding Name: a
Descriptive Name: Attribute Configuration
Potential Configuration Definition: [RFC5939]
Actual Configuration Definition: [RFC5939]
Latent Configuration Definition: [RFC6871]
Encoding Name: t
Descriptive Name: Transport Protocol Configuration
Potential Configuration Definition: [RFC5939]
Actual Configuration Definition: [RFC5939]
Latent Configuration Definition: [RFC6871]
Encoding Name: t
Descriptive Name: Transport Protocol Configuration
Potential Configuration Definition: [RFC5939]
Actual Configuration Definition: [RFC5939]
Latent Configuration Definition: [RFC6871]
Encoding Name: m
Descriptive Name: Media Configuration
Potential Configuration Definition: [RFC6871]
Actual Configuration Definition: [RFC6871]
Latent Configuration Definition: [RFC6871]
Encoding Name: m
Descriptive Name: Media Configuration
Potential Configuration Definition: [RFC6871]
Actual Configuration Definition: [RFC6871]
Latent Configuration Definition: [RFC6871]
Encoding Name: pt
Descriptive Name: Payload Type Number Mapping
Potential Configuration Definition: [RFC6871]
Actual Configuration Definition: [RFC6871]
Latent Configuration Definition: [RFC6871]
Encoding Name: pt
Descriptive Name: Payload Type Number Mapping
Potential Configuration Definition: [RFC6871]
Actual Configuration Definition: [RFC6871]
Latent Configuration Definition: [RFC6871]
Encoding Name: mt
Descriptive Name: Media Type
Potential Configuration Definition: N/A
Actual Configuration Definition: N/A
Latent Configuration Definition: [RFC6871]
Encoding Name: mt
Descriptive Name: Media Type
Potential Configuration Definition: N/A
Actual Configuration Definition: N/A
Latent Configuration Definition: [RFC6871]
The security considerations of RFC 5939 [RFC5939] apply for this document.
RFC 5939[RFC5939]的安全注意事项适用于本文件。
In RFC 5939 [RFC5939], it was noted that negotiation of transport protocols (e.g., secure and non-secure) and negotiation of keying methods and material are potential security issues that warrant integrity protection to remedy. Latent configuration support provides hints to the other side about capabilities supported for further offer/answer exchanges, including transport protocols and attribute capabilities, e.g., for keying methods. If an attacker can remove or alter latent configuration information to suggest that only non-secure or less-secure alternatives are supported, then he may be able to force negotiation of a less secure session than would otherwise have occurred. While the specific attack, as described here, differs from those described in RFC 5939 [RFC5939], the considerations and mitigation strategies are similar to those described in RFC 5939 [RFC5939].
在RFC 5939[RFC5939]中，注意到传输协议的协商（例如，安全和非安全）以及密钥方法和材料的协商是潜在的安全问题，需要对完整性进行保护以进行补救。潜在配置支持向另一方提供关于支持进一步提供/应答交换的功能的提示，包括传输协议和属性功能，例如，键控方法。如果攻击者可以删除或更改潜在的配置信息，以表明只支持不安全或不太安全的替代方案，那么他可能能够强制协商不太安全的会话。虽然此处描述的特定攻击与RFC 5939[RFC5939]中描述的攻击不同，但注意事项和缓解策略与RFC 5939[RFC5939]中描述的类似。
Another variation on the above attack involves the session capability ("sescap") attribute defined in this document. The "sescap" enables a preference order to be specified for all the potential configurations, and that preference will take precedence over any preference indication provided in individual potential configuration attributes. Consequently, an attacker that can insert or modify a "sescap" attribute may be able to force negotiation of an insecure or less secure alternative than would otherwise have occurred. Again, the considerations and mitigation strategies are similar to those described in RFC 5939 [RFC5939].
上述攻击的另一个变体涉及本文档中定义的会话能力（“sescap”）属性。“sescap”允许为所有潜在配置指定首选项顺序，并且该首选项优先于单个潜在配置属性中提供的任何首选项指示。因此，可以插入或修改“sescap”属性的攻击者可能会强制协商不安全或不太安全的替代方案。同样，考虑因素和缓解策略与RFC 5939[RFC5939]中描述的类似。
The addition of negotiable media formats and their associated parameters, defined in this specification can cause problems for middleboxes that attempt to control bandwidth utilization, media flows, and/or processing resource consumption as part of network policy, but that do not understand the media capability negotiation feature. As for the initial SDP capability negotiation work [RFC5939], the SDP answer is formulated in such a way that it always carries the selected media encoding for every media stream selected. Pending an understanding of capabilities negotiation, the middlebox should examine the answer SDP to obtain the best picture of the media streams being established. As always, middleboxes can best do their job if they fully understand media capabilities negotiation.
本规范中定义的可协商媒体格式及其相关参数的添加可能会给试图控制带宽利用率、媒体流和/或处理资源消耗（作为网络策略的一部分）但不了解媒体能力协商功能的中间盒带来问题。对于初始SDP能力协商工作[RFC5939]，SDP应答的制定方式是，它始终为每个选择的媒体流携带选择的媒体编码。在理解能力协商之前，中间盒应检查答案SDP，以获得正在建立的媒体流的最佳图片。和往常一样，如果中间人充分了解媒体能力，他们就能最好地完成工作。
This document is heavily influenced by the discussions and work done by the SDP Capability Negotiation design team. The following people in particular provided useful comments and suggestions to either the document itself or the overall direction of the solution defined herein: Cullen Jennings, Matt Lepinski, Joerg Ott, Colin Perkins, and Thomas Stach.
本文件深受SDP能力谈判设计团队的讨论和工作的影响。以下人员尤其为本文件本身或本文定义的解决方案的总体方向提供了有用的意见和建议：Cullen Jennings、Matt Lepinski、Joerg Ott、Colin Perkins和Thomas Stach。
We thank Ingemar Johansson and Magnus Westerlund for examples that stimulated this work, and for critical reading of the document. We also thank Cullen Jennings, Christer Holmberg, and Miguel Garcia for their review of the document.
我们感谢英格马尔·约翰逊和马格纳斯·韦斯特隆德的例子，这些例子激发了这项工作，并对该文件进行了批判性阅读。我们还感谢Cullen Jennings、Christer Holmberg和Miguel Garcia对该文件的审查。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
[RFC5939]Andreasen，F.，“会话描述协议（SDP）能力协商”，RFC 59392010年9月。
[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.
[RFC2198]Perkins，C.，Kouvelas，I.，Hodson，O.，Hardman，V.，Handley，M.，Bolot，J.，Vega Garcia，A.，和S.Fosse Parisis，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568]Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 4568，2006年7月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC4733]Schulzrinne，H.和T.Taylor，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 47332006年12月。
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, April 2007.
[RFC4867]Sjoberg，J.，Westerlund，M.，Lakaniemi，A.，和Q.Xie，“自适应多速率（AMR）和自适应多速率宽带（AMR-WB）音频编解码器的RTP有效载荷格式和文件存储格式”，RFC 4867，2007年4月。
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5104]Wenger，S.，Chandra，U.，Westerlund，M.，和B.Burman，“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”，RFC 5104，2008年2月。
Authors' Addresses
作者地址
Robert R Gilman Independent 3243 W. 11th Ave. Dr. Broomfield, CO 80020 USA
美国科罗拉多州布鲁姆菲尔德博士第11大道西3243号罗伯特R吉尔曼独立学院，邮编80020
EMail: bob_gilman@comcast.net
EMail: bob_gilman@comcast.net
Roni Even Huawei Technologies 14 David Hamelech Tel Aviv 64953 Israel
Roni甚至华为技术14 David Hamelech特拉维夫64953以色列
EMail: roni.even@mail01.huawei.com
EMail: roni.even@mail01.huawei.com
Flemming Andreasen Cisco Systems Iselin, NJ USA
弗莱明·安德烈森思科系统公司，美国新泽西州伊塞林
EMail: fandreas@cisco.com
EMail: fandreas@cisco.com