Internet Engineering Task Force (IETF) F. Andreasen
Request for Comments: 5939 Cisco Systems
Category: Standards Track September 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Andreasen
Request for Comments: 5939 Cisco Systems
Category: Standards Track September 2010
ISSN: 2070-1721
Session Description Protocol (SDP) Capability Negotiation
会话描述协议（SDP）能力协商
Abstract
摘要
The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation.
会话描述协议（SDP）旨在描述多媒体会话，用于会话公告、会话邀请和其他形式的多媒体会话启动。SDP无意提供能力指示或能力谈判；然而，多年来，SDP已被广泛采用，因此，SDP已逐渐扩展，以提供有限的支持，尤其是以RFC 3264中定义的提供/应答模型的形式。SDP未定义如何协商一个或多个备选传输协议（例如RTP配置文件）或属性。这使得部署新的RTP配置文件（如基于RTCP的反馈的安全RTP或RTP）、协商使用不同的安全密钥机制等变得困难。这也给某些形式的媒体协商带来了问题。
The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner.
本文件的目的是通过使用能力协商参数和相关的报价/应答程序扩展SDP，以向后兼容的方式使用这些参数，从而解决这些缺点。
The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents.
该文件定义了通用SDP能力协商框架。它还指定了如何提供属性和传输协议作为功能，并使用框架协商它们。其他文档中可能会提供其他类型功能（例如，媒体类型和媒体格式）的扩展。
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/rfc5939.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5939.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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. Conventions Used in This Document ...............................7
3. SDP Capability Negotiation Solution .............................7
3.1. SDP Capability Negotiation Model ...........................7
3.2. Solution Overview .........................................10
3.3. Version and Extension Indication Attributes ...............14
3.4. Capability Attributes .....................................17
3.5. Configuration Attributes ..................................22
3.6. Offer/Answer Model Extensions .............................32
3.7. Interactions with ICE .....................................45
3.8. Interactions with SIP Option Tags .........................47
3.9. Processing Media before Answer ............................48
3.10. Indicating Bandwidth Usage ...............................49
3.11. Dealing with Large Number of Potential Configurations ....50
3.12. SDP Capability Negotiation and Intermediaries ............51
3.13. Considerations for Specific Attribute Capabilities .......52
3.14. Relationship to RFC 3407 .................................54
4. Examples .......................................................54
4.1. Multiple Transport Protocols ..............................54
4.2. DTLS-SRTP or SRTP with Media-Level Security Descriptions...58
4.3. Best-Effort SRTP with Session-Level MIKEY and Media-Level
Security Descriptions .....................................61
4.4. SRTP with Session-Level MIKEY and Media-Level Security
Descriptions as Alternatives ..............................66
5. Security Considerations ........................................69
6. IANA Considerations ............................................72
6.1. New SDP Attributes ........................................72
6.2. New SDP Capability Negotiation Option Tag Registry ........73
6.3. New SDP Capability Negotiation Potential
Configuration Parameter Registry ..........................74
7. Acknowledgments ................................................74
8. References .....................................................75
8.1. Normative References ......................................75
8.2. Informative References ....................................75
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................7
3. SDP Capability Negotiation Solution .............................7
3.1. SDP Capability Negotiation Model ...........................7
3.2. Solution Overview .........................................10
3.3. Version and Extension Indication Attributes ...............14
3.4. Capability Attributes .....................................17
3.5. Configuration Attributes ..................................22
3.6. Offer/Answer Model Extensions .............................32
3.7. Interactions with ICE .....................................45
3.8. Interactions with SIP Option Tags .........................47
3.9. Processing Media before Answer ............................48
3.10. Indicating Bandwidth Usage ...............................49
3.11. Dealing with Large Number of Potential Configurations ....50
3.12. SDP Capability Negotiation and Intermediaries ............51
3.13. Considerations for Specific Attribute Capabilities .......52
3.14. Relationship to RFC 3407 .................................54
4. Examples .......................................................54
4.1. Multiple Transport Protocols ..............................54
4.2. DTLS-SRTP or SRTP with Media-Level Security Descriptions...58
4.3. Best-Effort SRTP with Session-Level MIKEY and Media-Level
Security Descriptions .....................................61
4.4. SRTP with Session-Level MIKEY and Media-Level Security
Descriptions as Alternatives ..............................66
5. Security Considerations ........................................69
6. IANA Considerations ............................................72
6.1. New SDP Attributes ........................................72
6.2. New SDP Capability Negotiation Option Tag Registry ........73
6.3. New SDP Capability Negotiation Potential
Configuration Parameter Registry ..........................74
7. Acknowledgments ................................................74
8. References .....................................................75
8.1. Normative References ......................................75
8.2. Informative References ....................................75
The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. An SDP session description contains one or more media stream descriptions with information such as IP address and port, type of media stream (e.g., audio or video), transport protocol (possibly including profile information, e.g., RTP/AVP or RTP/SAVP), media formats (e.g., codecs), and various other session and media stream parameters that define the session.
会话描述协议（SDP）旨在描述多媒体会话，用于会话公告、会话邀请和其他形式的多媒体会话启动。SDP会话描述包含一个或多个媒体流描述，其中包含诸如IP地址和端口、媒体流类型（例如，音频或视频）、传输协议（可能包括简档信息，例如，RTP/AVP或RTP/SAVP）、媒体格式（例如，编解码器）等信息，以及定义会话的各种其他会话和媒体流参数。
Simply providing media stream descriptions is sufficient for session announcements for a broadcast application, where the media stream parameters are fixed for all participants. When a participant wants to join the session, he obtains the session announcement and uses the media descriptions provided, e.g., joins a multicast group and receives media packets in the encoding format specified. If the media stream description is not supported by the participant, he is unable to receive the media.
仅提供媒体流描述就足以用于广播应用程序的会话公告，其中媒体流参数对于所有参与者都是固定的。当参与者想要加入会话时，他获得会话公告并使用提供的媒体描述，例如，加入多播组并接收指定编码格式的媒体分组。如果参与者不支持媒体流描述，则无法接收媒体。
Such restrictions are not generally acceptable to multimedia session invitations, where two or more entities attempt to establish a media session, that uses a set of media stream parameters acceptable to all participants. First of all, each entity must inform the other of its receive address, and secondly, the entities need to agree on the media stream parameters to use for the session, e.g., transport protocols and codecs. To solve this, RFC 3264 [RFC3264] defined the offer/answer model, whereby an offerer constructs an offer SDP session description that lists the media streams, codecs, and other SDP parameters that the offerer is willing to use. This offer session description is sent to the answerer, which chooses from among the media streams, codecs and other session description parameters provided, and generates an answer session description with his parameters, based on that choice. The answer session description is sent back to the offerer thereby completing the session negotiation and enabling the establishment of the negotiated media streams.
这种限制通常不被多媒体会话邀请所接受，其中两个或多个实体试图建立一个媒体会话，该媒体会话使用一组所有参与者都能接受的媒体流参数。首先，每个实体必须将其接收地址通知另一个实体，其次，实体需要商定用于会话的媒体流参数，例如，传输协议和编解码器。为了解决这个问题，RFC 3264[RFC3264]定义了要约/应答模型，其中要约人构造要约SDP会话描述，该描述列出了要约人愿意使用的媒体流、编解码器和其他SDP参数。此报价会话描述发送给应答者，应答者从提供的媒体流、编解码器和其他会话描述参数中进行选择，并基于该选择生成带有其参数的应答会话描述。应答会话描述被发送回报价人，从而完成会话协商并能够建立协商的媒体流。
Taking a step back, we can make a distinction between the capabilities supported by each participant, the way in which those capabilities can be supported, and the parameters that can actually be used for the session. More generally, we can say that we have the following:
退一步说，我们可以区分每个参与者支持的功能、支持这些功能的方式以及会话实际使用的参数。更一般地说，我们可以说有以下几点：
o A set of capabilities for the session and its associated media stream components, supported by each side. The capability indications by themselves do not imply a commitment to use the capabilities in the session.
o 会话及其相关媒体流组件的一组功能，由各方支持。能力指示本身并不意味着承诺在会话中使用这些能力。
Capabilities can, for example, be that the "RTP/SAVP" profile is supported, that the "PCMU" (Pulse Code Modulation mu-law) codec is supported, or that the "crypto" attribute is supported with a particular value.
例如，功能可以是支持“RTP/SAVP”配置文件，支持“PCMU”（脉冲编码调制mu法则）编解码器，或者支持具有特定值的“crypto”属性。
o A set of potential configurations indicating which combinations of those capabilities can be used for the session and its associated media stream components. Potential configurations are not ready for use. Instead, they provide an alternative that may be used, subject to further negotiation.
o 一组潜在的配置，指示这些功能的哪些组合可用于会话及其关联的媒体流组件。潜在配置尚未准备好使用。相反，它们提供了一种可供使用的替代方案，有待进一步协商。
A potential configuration can, for example, indicate that the "PCMU" codec and the "RTP/SAVP" transport protocol are not only supported (i.e., listed as capabilities), but they are offered for potential use in the session.
例如，潜在的配置可以指示不仅支持“PCMU”编解码器和“RTP/SAVP”传输协议（即，作为功能列出），而且还提供它们以供会话中的潜在使用。
o An actual configuration for the session and its associated media stream components, that specifies which combinations of session parameters and media stream components can be used currently and with what parameters. Use of an actual configuration does not require any further negotiation.
o 会话及其关联媒体流组件的实际配置，指定当前可以使用会话参数和媒体流组件的哪些组合以及使用哪些参数。使用实际配置不需要进一步协商。
An actual configuration can, for example, be that the "PCMU" codec and the "RTP/SAVP" transport protocol are offered for use currently.
例如，实际配置可以是提供“PCMU”编解码器和“RTP/SAVP”传输协议以供当前使用。
o A negotiation process that takes the set of actual and potential configurations (combinations of capabilities) as input and provides the negotiated actual configurations as output.
o 一种协商过程，将一组实际和潜在配置（能力组合）作为输入，并将协商后的实际配置作为输出。
SDP by itself was designed to provide only one of these, namely listing of the actual configurations; however, over the years, use of SDP has been extended beyond its original scope. Of particular importance are the session negotiation semantics that were defined by the offer/answer model in RFC 3264. In this model, both the offer and the answer contain actual configurations; separate capabilities and potential configurations are not supported.
SDP本身只提供其中一种，即实际配置的列表；然而，多年来，SDP的使用已经超出了其原来的范围。特别重要的是由RFC3264中的提供/应答模型定义的会话协商语义。在该模型中，报价和应答都包含实际配置；不支持单独的功能和潜在配置。
Other relevant extensions have been defined as well. RFC 3407 [RFC3407] defined simple capability declarations, which extends SDP with a simple and limited set of capability descriptions. Grouping of media lines, which defines how media lines in SDP can have other semantics than the traditional "simultaneous media streams" semantics, was defined in RFC 5888 [RFC5888], etc.
还定义了其他相关的扩展。RFC 3407[RFC3407]定义了简单的功能声明，它用一组简单且有限的功能描述扩展了SDP。媒体行分组定义了SDP中的媒体行如何具有传统“同步媒体流”语义以外的其他语义，在RFC 5888[RFC5888]等中进行了定义。
Each of these extensions was designed to solve a specific limitation of SDP. Since SDP had already been stretched beyond its original intent, a more comprehensive capability declaration and negotiation
每个扩展都是为了解决SDP的特定限制而设计的。由于SDP已经超出了其初衷，因此需要进行更全面的能力声明和谈判
process was intentionally not defined. Instead, work on a "next
generation" of a protocol to provide session description and
capability negotiation was initiated [SDPng]. SDPng defined a
comprehensive capability negotiation framework and protocol that was
not bound by existing SDP constraints. SDPng was not designed to be
backwards compatible with existing SDP and hence required both sides
to support it, with a graceful fallback to legacy operation when
needed. This, combined with lack of ubiquitous multipart MIME
support in the protocols that would carry SDP or SDPng, made it
challenging to migrate towards SDPng. In practice, SDPng has not
gained traction and, as of the time of publication of this document,
work on SDPng has stopped. Existing real-time multimedia
communication protocols such as SIP, Real Time Streaming Protocol
(RTSP), Megaco, and Media Gateway Control Protocol (MGCP) continue to
use SDP. However, SDP does not address an increasingly important
problem: the ability to negotiate one or more alternative transport
protocols (e.g., RTP profiles) and associated parameters (e.g., SDP
attributes). This makes it difficult to deploy new RTP profiles such
as Secure RTP (SRTP) [RFC3711], RTP with RTCP-based feedback
[RFC4585], etc. The problem is exacerbated by the fact that RTP
profiles are defined independently. When a new profile is defined
and N other profiles already exist, there is a potential need for
defining N additional profiles, since profiles cannot be combined
automatically. For example, in order to support the plain and Secure
RTP version of RTP with and without RTCP-based feedback, four
separate profiles (and hence profile definitions) are needed: RTP/AVP
[RFC3551], RTP/SAVP [RFC3711], RTP/AVPF [RFC4585], and RTP/SAVPF
[RFC5124]. In addition to the pressing profile negotiation problem,
other important real-life limitations have been found as well.
Keying material and other parameters, for example, need to be
negotiated with some of the transport protocols, but not others.
Similarly, some media formats and types of media streams need to
negotiate a variety of different parameters.
process was intentionally not defined. Instead, work on a "next
generation" of a protocol to provide session description and
capability negotiation was initiated [SDPng]. SDPng defined a
comprehensive capability negotiation framework and protocol that was
not bound by existing SDP constraints. SDPng was not designed to be
backwards compatible with existing SDP and hence required both sides
to support it, with a graceful fallback to legacy operation when
needed. This, combined with lack of ubiquitous multipart MIME
support in the protocols that would carry SDP or SDPng, made it
challenging to migrate towards SDPng. In practice, SDPng has not
gained traction and, as of the time of publication of this document,
work on SDPng has stopped. Existing real-time multimedia
communication protocols such as SIP, Real Time Streaming Protocol
(RTSP), Megaco, and Media Gateway Control Protocol (MGCP) continue to
use SDP. However, SDP does not address an increasingly important
problem: the ability to negotiate one or more alternative transport
protocols (e.g., RTP profiles) and associated parameters (e.g., SDP
attributes). This makes it difficult to deploy new RTP profiles such
as Secure RTP (SRTP) [RFC3711], RTP with RTCP-based feedback
[RFC4585], etc. The problem is exacerbated by the fact that RTP
profiles are defined independently. When a new profile is defined
and N other profiles already exist, there is a potential need for
defining N additional profiles, since profiles cannot be combined
automatically. For example, in order to support the plain and Secure
RTP version of RTP with and without RTCP-based feedback, four
separate profiles (and hence profile definitions) are needed: RTP/AVP
[RFC3551], RTP/SAVP [RFC3711], RTP/AVPF [RFC4585], and RTP/SAVPF
[RFC5124]. In addition to the pressing profile negotiation problem,
other important real-life limitations have been found as well.
Keying material and other parameters, for example, need to be
negotiated with some of the transport protocols, but not others.
Similarly, some media formats and types of media streams need to
negotiate a variety of different parameters.
The purpose of this document is to define a mechanism that enables SDP to provide limited support for indicating capabilities and their associated potential configurations, and negotiate the use of those potential configurations as actual configurations. It is not the intent to provide a full-fledged capability indication and negotiation mechanism along the lines of SDPng or ITU-T H.245. Instead, the focus is on addressing a set of well-known real-life limitations. More specifically, the solution provided in this document provides a general SDP Capability Negotiation framework that is backwards compatible with existing SDP. It also defines specifically how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and formats) may be provided in other documents.
本文件的目的是定义一种机制，使SDP能够提供有限的支持，以指示能力及其相关的潜在配置，并协商将这些潜在配置用作实际配置。其目的不是按照SDPng或ITU-T H.245提供一个全面的能力指示和协商机制。相反，重点是解决一系列众所周知的现实生活限制。更具体地说，本文档中提供的解决方案提供了一个通用的SDP能力协商框架，该框架向后兼容现有SDP。它还具体定义了如何提供属性和传输协议作为功能，并使用该框架进行协商。其他文档中可能会提供其他类型功能（例如，媒体类型和格式）的扩展。
As mentioned above, SDP is used by several protocols, and hence the mechanism should be usable by all of these. One particularly important protocol for this problem is the Session Initiation Protocol (SIP) [RFC3261]. SIP uses the offer/answer model [RFC3264] (which is not specific to SIP) to negotiate sessions and hence the mechanism defined here provides the offer/answer procedures to use for the capability negotiation framework.
如上所述，SDP由多个协议使用，因此该机制应可供所有这些协议使用。对于这个问题，一个特别重要的协议是会话启动协议（SIP）[RFC3261]。SIP使用提供/应答模型[RFC3264]（不特定于SIP）来协商会话，因此此处定义的机制提供了用于能力协商框架的提供/应答过程。
The rest of the document is structured as follows. In Section 3, we present the SDP Capability Negotiation solution, which consists of new SDP attributes and associated offer/answer procedures. In Section 4, we provide examples illustrating its use. In Section 5, we provide the security considerations.
文档的其余部分的结构如下所示。在第3节中，我们介绍了SDP能力协商解决方案，它包括新的SDP属性和相关的报价/应答过程。在第4节中，我们提供了示例来说明它的使用。在第5节中，我们提供了安全注意事项。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In this section, we first present the conceptual model behind the SDP Capability Negotiation framework followed by an overview of the SDP Capability Negotiation solution. We then define new SDP attributes for the solution and provide its associated updated offer/answer procedures.
在本节中，我们首先介绍SDP能力协商框架背后的概念模型，然后概述SDP能力协商解决方案。然后，我们为解决方案定义新的SDP属性，并提供其相关的更新的报价/应答过程。
Our model uses the concepts of
我们的模型使用了
o Capabilities
o 能力
o Potential Configurations
o 潜在构型
o Actual Configurations
o 实际配置
o Negotiation Process
o 谈判过程
as defined in Section 1. Conceptually, we want to offer not just the actual configuration SDP session description (which is done with the offer/answer model defined in [RFC3264]), but the actual configuration SDP session description as well as one or more alternative SDP session descriptions, i.e., potential configurations. The answerer must choose either the actual configuration or one of the potential configurations, and generate an answer SDP session description based on that. The offerer may need to perform
如第1节所定义。从概念上讲，我们不仅要提供实际配置SDP会话描述（使用[RFC3264]中定义的提供/应答模型完成），还要提供实际配置SDP会话描述以及一个或多个备选SDP会话描述，即潜在配置。应答者必须选择实际配置或一种潜在配置，并基于此生成应答SDP会话描述。要约人可能需要履行义务
processing on the answer, which depends on the offer that was chosen (actual or potential configuration). The answerer therefore informs the offerer which configuration the answerer chose. The process can be viewed *conceptually* as follows:
根据答案进行处理，这取决于选择的报价（实际或潜在配置）。因此，应答者通知报价者应答者选择的配置。该过程可以*概念性地*如下所示：
Offerer Answerer
======= ========
Offerer Answerer
======= ========
1) Generate offer with actual configuration and alternative potential configurations 2) Send offer with all configurations
1) 使用实际配置和备选潜在配置生成报价2）使用所有配置发送报价
+------------+
| SDP o1 |
| (actual |
| config |
| |-+ Offer
+------------+ | -----> 3) Process offered configurations
| SDP o2 | in order of preference indicated
| (potential | 4) Generate answer based on chosen
| config 1) |-+ configuration (e.g., o2), and
+------------+ | inform offerer which one was
| SDP o3 | chosen
| (potential |
| config 2) |-+
+------------+ |
| SDP ... |
: :
+------------+
| SDP o1 |
| (actual |
| config |
| |-+ Offer
+------------+ | -----> 3) Process offered configurations
| SDP o2 | in order of preference indicated
| (potential | 4) Generate answer based on chosen
| config 1) |-+ configuration (e.g., o2), and
+------------+ | inform offerer which one was
| SDP o3 | chosen
| (potential |
| config 2) |-+
+------------+ |
| SDP ... |
: :
+------------+
| SDP a1 |
Answer | (actual |
<----- | config,o2)|
| |
5) Process answer based on +------------+
the configuration that was
chosen (o2), as indicated in
the answer
+------------+
| SDP a1 |
Answer | (actual |
<----- | config,o2)|
| |
5) Process answer based on +------------+
the configuration that was
chosen (o2), as indicated in
the answer
The above illustrates the conceptual model: the actual solution uses a single SDP session description, which contains the actual configuration (as with existing SDP session descriptions and the offer/answer model defined in [RFC3264]) and several new attributes and associated procedures, that encode the capabilities and potential configurations. A more accurate depiction of the actual offer SDP session description is therefore as follows:
以上说明了概念模型：实际解决方案使用单个SDP会话描述，其中包含实际配置（与现有SDP会话描述和[RFC3264]中定义的提供/应答模型一样）以及几个新属性和相关过程，这些属性和过程对功能和潜在配置进行编码。因此，实际报价SDP会话描述的更准确描述如下：
+--------------------+
| SDP o1 |
| (actual |
| config |
| |
| +-------------+ |
| | capability 1| |
| | capability 2| |
| | ... | |
| +-------------+ | Offer
| | ----->
| +-------------+ |
| | potential | |
| | config 1 | |
| | potential | |
| | config 2 | |
| | ... | |
| +-------------+ |
| |
+--------------------+
+--------------------+
| SDP o1 |
| (actual |
| config |
| |
| +-------------+ |
| | capability 1| |
| | capability 2| |
| | ... | |
| +-------------+ | Offer
| | ----->
| +-------------+ |
| | potential | |
| | config 1 | |
| | potential | |
| | config 2 | |
| | ... | |
| +-------------+ |
| |
+--------------------+
The above structure is used for two reasons:
使用上述结构有两个原因：
o Backwards compatibility: As noted above, support for multipart MIME is not ubiquitous. By encoding both capabilities and potential configurations in SDP attributes, we can represent everything in a single SDP session description thereby avoiding any multipart MIME support issues. Furthermore, since unknown SDP attributes are ignored by the SDP recipient, we ensure that entities that do not support the framework simply perform the regular RFC 3264 offer/answer procedures. This provides us with seamless backwards compatibility.
o 向后兼容性：如上所述，对多部分MIME的支持并不普遍。通过在SDP属性中编码功能和潜在配置，我们可以在单个SDP会话描述中表示所有内容，从而避免任何多部分MIME支持问题。此外，由于未知的SDP属性被SDP接收者忽略，因此我们确保不支持框架的实体只执行常规的RFC 3264提供/应答过程。这为我们提供了无缝的向后兼容性。
o Message size efficiency: When we have multiple media streams, each of which may potentially use two or more different transport protocols with a variety of different associated parameters, the number of potential configurations can be large. If each possible alternative is represented as a complete SDP session description in an offer, we can easily end up with large messages. By providing a more compact encoding, we get more efficient message sizes.
o 消息大小效率：当我们有多个媒体流时，每个媒体流可能使用两个或多个具有各种不同关联参数的不同传输协议，潜在配置的数量可能会很大。如果每个可能的备选方案都在报价中表示为完整的SDP会话描述，那么我们很容易得到大量消息。通过提供更紧凑的编码，我们可以获得更有效的消息大小。
In the next section, we describe the exact structure and specific SDP parameters used to represent this.
在下一节中，我们将描述用于表示这一点的确切结构和特定SDP参数。
The solution consists of the following:
解决方案包括以下内容：
o Two new SDP attributes to support extensions to the framework itself as follows:
o 两个新的SDP属性支持对框架本身的扩展，如下所示：
o A new attribute ("a=csup") that lists the supported base (optionally) and any supported extension options to the framework.
o 一个新属性（“A=csup”），列出框架的受支持基本（可选）和任何受支持的扩展选项。
o A new attribute ("a=creq") that lists the extensions to the framework that are required to be supported by the entity receiving the SDP session description in order to do capability negotiation.
o 一个新属性（“A=creq”），列出了接收SDP会话描述的实体为了进行能力协商而需要支持的框架扩展。
o Two new SDP attributes used to express capabilities as follows (additional attributes can be defined as extensions):
o 两个新的SDP属性用于表示以下功能（其他属性可以定义为扩展）：
o A new attribute ("a=acap") that defines how to list an attribute name and its associated value (if any) as a capability.
o 一个新属性（“A=acap”），定义如何将属性名称及其关联值（如果有）列为功能。
o A new attribute ("a=tcap") that defines how to list transport protocols (e.g., "RTP/AVP") as capabilities.
o 一个新属性（“A=tcap”），定义如何将传输协议（如“RTP/AVP”）列为功能。
o Two new SDP attributes to negotiate configurations as follows:
o 用于协商配置的两个新SDP属性如下：
o A new attribute ("a=pcfg") that lists potential configurations supported. This is done by reference to the capabilities from the SDP session description in question. Extension capabilities can be defined and referenced in the potential configurations. Alternative potential configurations have an explicit ordering associated with them. Also, potential configurations are by default preferred over the actual configuration included in the "m=" line and its associated parameters.
o 一个新属性（“A=pcfg”），列出了支持的潜在配置。这是通过参考相关SDP会话描述中的功能来完成的。扩展功能可以在潜在配置中定义和引用。备选潜在配置具有与其关联的明确顺序。此外，默认情况下，潜在配置优先于“m=”行及其相关参数中包含的实际配置。
This preference order was chosen to provide maximum backwards compatibility for the capability negotiation framework and the possible values offered for a session. For example, an entity that wants to establish a Secure RTP media stream but is willing to accept a plain RTP media stream (assumed to be the least common denominator for most endpoints), can offer plain RTP in the actual configuration and use the capability negotiation extensions to indicate the preference for Secure RTP. Entities that do not support the capability negotiation extensions or Secure RTP will then default to plain RTP.
选择此优先顺序是为了为能力协商框架和会话提供的可能值提供最大的向后兼容性。例如，想要建立安全RTP媒体流但愿意接受普通RTP媒体流（假定为大多数端点的最小公分母）的实体可以在实际配置中提供普通RTP，并使用能力协商扩展来指示对安全RTP的偏好。不支持能力协商扩展或安全RTP的实体将默认为普通RTP。
o A new attribute ("a=acfg") to be used in an answer SDP session description. The attribute identifies a potential configuration from an offer SDP session description that was used as an actual configuration to form the answer SDP session description. Extension capabilities can be included as well.
o 将在应答SDP会话描述中使用的新属性（“A=acfg”）。该属性从报价SDP会话描述中标识潜在配置，该会话描述用作形成应答SDP会话描述的实际配置。扩展功能也可以包括在内。
o Extensions to the offer/answer model that allow for capabilities and potential configurations to be included in an offer. Capabilities can be provided at the session level and the media level. Potential configurations can be included only at the media level, where they 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. The mechanisms defined in this document enable potential configurations to change the transport protocol, add new attributes, as well as remove all existing attributes from the actual configuration. The answerer indicates which (if any) of the potential configurations it used to form the answer by including the actual configuration attribute ("a=acfg") in the answer. Capabilities may be included in answers as well, where they can aid in guiding a subsequent new offer.
o 提供/应答模型的扩展，允许在提供中包含功能和潜在配置。可以在会话级别和媒体级别提供功能。潜在配置只能包含在媒体级别，这些配置构成应答者可以接受的备选方案，而不是“m=”行和相关参数中包含的实际配置。本文档中定义的机制允许潜在配置更改传输协议、添加新属性以及从实际配置中删除所有现有属性。回答者通过在回答中包含实际配置属性（“a=acfg”）来指示其用于形成回答的潜在配置（如果有）。回答中也可能包含这些能力，它们可以帮助指导后续的新报价。
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 (SRTP) |
|<---------------------------------|
| |
| (3) Offer (SRTP) |
|--------------------------------->|
| |
| (4) Answer (SRTP) |
|<---------------------------------|
| |
| (1) Offer (SRTP and RTP) |
|--------------------------------->|
| |
| (2) Answer (SRTP) |
|<---------------------------------|
| |
| (3) Offer (SRTP) |
|--------------------------------->|
| |
| (4) Answer (SRTP) |
|<---------------------------------|
| |
Alice's offer includes RTP and SRTP as alternatives, where RTP is the default (actual configuration), but SRTP is the preferred one (potential configuration):
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
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
a=pcfg:1 t=1 a=1
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
a=pcfg:1 t=1 a=1
The "m=" line indicates that Alice is offering to use plain RTP with PCMU or G.729. The capabilities are provided by the "a=tcap" and "a=acap" attributes. The transport capability attribute ("a=tcap") indicates that Secure RTP under the AVP profile ("RTP/SAVP") is supported with an associated transport capability handle of 1. The "acap" attribute provides an attribute capability with a handle of 1. The attribute capability is a "crypto" attribute, which provides the keying material for SRTP using SDP security descriptions [RFC4568]. The "a=pcfg" attribute provides the potential configuration included in the offer by reference to the capability parameters. One alternative is provided; it has a configuration number of 1 and it consists of transport protocol capability 1 (i.e., the RTP/SAVP profile -- Secure RTP), and the attribute capability 1 (i.e., the "crypto" attribute provided). Potential configurations are preferred over the actual configuration included in the offer SDP session description, and hence Alice is expressing a preference for using Secure RTP.
“m=”行表示Alice提供将普通RTP与PCMU或G.729一起使用。这些功能由“a=tcap”和“a=acap”属性提供。传输能力属性（“a=tcap”）表示AVP配置文件（“RTP/SAVP”）下的安全RTP受相关传输能力句柄1的支持。“acap”属性提供句柄为1的属性功能。属性能力是一个“加密”属性，它使用SDP安全描述为SRTP提供密钥材料[RFC4568]。“a=pcfg”属性通过引用功能参数提供报价中包含的潜在配置。提供了一种替代方案；它的配置号为1，由传输协议能力1（即RTP/SAVP配置文件——安全RTP）和属性能力1（即提供的“加密”属性）组成。潜在配置优先于要约SDP会话描述中包含的实际配置，因此Alice表示更倾向于使用安全RTP。
Bob receives the SDP session description offer from Alice. Bob supports SRTP and the SDP Capability Negotiation framework, and hence he accepts the (preferred) potential configuration for Secure RTP provided by Alice and generates the following answer SDP session description:
Bob收到Alice提供的SDP会话描述。Bob支持SRTP和SDP能力协商框架，因此他接受Alice提供的安全RTP（首选）潜在配置，并生成以下应答SDP会话描述：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
a=acfg:1 t=1 a=1
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
a=acfg:1 t=1 a=1
Bob includes the "a=acfg" attribute in the answer to inform Alice that he based his answer on an offer using potential configuration 1 with transport protocol capability 1 and attribute capability 1 from the offer SDP session description (i.e., the RTP/SAVP profile using the keying material provided). Bob also includes his keying material in a "crypto" attribute. If Bob supported one or more extensions to the Capability Negotiation framework, he would have included option tags for those in the answer as well (in an "a=csup" attribute).
Bob在回答中包含“a=acfg”属性，以告知Alice，他基于一个报价，使用潜在配置1，传输协议能力1和报价SDP会话描述中的属性能力1（即，使用提供的键控材料的RTP/SAVP配置文件）。Bob还在一个“crypto”属性中包含他的键控材料。如果Bob支持对能力协商框架的一个或多个扩展，那么他也会在答案中包含选项标签（在“a=csup”属性中）。
When Alice receives Bob's answer, session negotiation has completed; however, Alice nevertheless generates a new offer using the negotiated configuration as the actual configuration. This is done purely to assist any intermediaries that may reside between Alice and Bob but do not support the SDP Capability Negotiation framework, and hence may not understand the negotiation that just took place.
当Alice收到Bob的回答时，会话协商已完成；然而，Alice仍然使用协商的配置作为实际配置生成新的报价。这样做纯粹是为了帮助可能位于Alice和Bob之间但不支持SDP能力协商框架的任何中介机构，因此可能不理解刚刚发生的协商。
Alice's updated offer includes only SRTP, and it is not using the SDP Capability Negotiation framework (Alice could have included the capabilities as well if she wanted):
Alice的更新产品仅包括SRTP，并且未使用SDP能力协商框架（如果Alice愿意，也可以包括这些能力）：
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
The "m=" line now indicates that Alice is offering to use Secure RTP with PCMU or G.729. The "crypto" attribute, which provides the SRTP keying material, is included with the same value again.
“m=”行现在表示Alice提供将安全RTP与PCMU或G.729一起使用。提供SRTP键控材料的“crypto”属性再次包含相同的值。
Bob receives the SDP session description offer from Alice, which he accepts, and then generates an answer to Alice:
Bob收到Alice提供的SDP会话描述，并接受该服务，然后生成Alice的答案：
v=0
o=- 24351 621815 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
v=0
o=- 24351 621815 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/SAVP 0 18
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
Bob includes the same "crypto" attribute as before, and the session proceeds without change. Although Bob did not include any capabilities in his answer, he could have done so if he wanted.
Bob包含与前面相同的“crypto”属性，会话继续进行而不做任何更改。虽然Bob的回答中没有包含任何能力，但如果他愿意，他可以这样做。
Note that in this particular example, the answerer supported the capability negotiation extensions defined here. Had he not, he would simply have ignored the new attributes and accepted the (actual configuration) offer to use normal RTP. In that case, the following answer would have been generated instead:
请注意，在这个特定示例中，应答者支持此处定义的功能协商扩展。如果他没有，他只会忽略新属性并接受（实际配置）使用普通RTP的提议。在这种情况下，将生成以下答案：
v=0 o=- 24351 621814 IN IP4 192.0.2.2 s= c=IN IP4 192.0.2.2 t=0 0 m=audio 54568 RTP/AVP 0 18
v=0 o=-24351 621814在IP4 192.0.2.2中s=c=IP4 192.0.2.2中t=0 0 m=音频54568 RTP/AVP 0 18
In this section, we present the new attributes associated with indicating the SDP Capability Negotiation extensions supported and required.
在本节中，我们将介绍与指示支持和需要的SDP能力协商扩展相关的新属性。
The SDP Capability Negotiation solution allows for capability negotiation extensions to be defined. Associated with each such extension is an option tag that identifies the extension in question. Option tags MUST be registered with IANA per the procedures defined in Section 6.2.
SDP能力协商解决方案允许定义能力协商扩展。与每个这样的扩展相关联的是一个选项标记，用于标识有问题的扩展。必须按照第6.2节规定的程序向IANA注册选项标签。
The Supported Capability Negotiation Extensions attribute ("a=csup") contains a comma-separated list of option tags identifying the SDP Capability Negotiation extensions supported by the entity that generated the SDP session description. The attribute can be provided at the session level and the media level, and it is defined as follows:
Supported Capability Negotiation Extensions属性（“a=csup”）包含一个逗号分隔的选项标记列表，标识生成SDP会话描述的实体所支持的SDP能力协商扩展。该属性可以在会话级和媒体级提供，定义如下：
a=csup: <option-tag-list>
a=csup: <option-tag-list>
RFC 4566, Section 9, provides the ABNF [RFC5234] for SDP attributes. The "csup" attribute adheres to the RFC 4566 "attribute" production, with an att-value defined as follows:
RFC 4566第9节提供了SDP属性的ABNF[RFC5234]。“csup”属性符合RFC 4566“属性”产品，att值定义如下：
att-value = option-tag-list
option-tag-list = option-tag *("," option-tag)
option-tag = token ; defined in [RFC4566]
att-value = option-tag-list
option-tag-list = option-tag *("," option-tag)
option-tag = token ; defined in [RFC4566]
A special base option tag with a value of "cap-v0" is defined for the basic SDP Capability Negotiation framework defined in this document. Entities can use this option tag with the "a=csup" attribute to
对于本文件中定义的基本SDP能力协商框架，定义了一个值为“cap-v0”的特殊基本选项标签。实体可以将此选项标记与“a=csup”属性一起使用，以
indicate support for the SDP Capability Negotiation framework specified in this document. Please note that white space is not allowed in this rule.
表示支持本文件中规定的SDP能力协商框架。请注意，此规则中不允许使用空格。
The following examples illustrate use of the "a=csup" attribute with the "cap-v0" option tag and two hypothetical option tags, "foo" and "bar" (note the lack of white space):
以下示例说明了“a=csup”属性与“cap-v0”选项标记以及两个假设的选项标记“foo”和“bar”的使用（注意缺少空格）：
a=csup:cap-v0
a=csup:cap-v0
a=csup:foo
a=csup:foo
a=csup:bar
a=csup:bar
a=csup:cap-v0,foo,bar
a=csup:cap-v0，foo，巴
The "a=csup" attribute can be provided at the session and the media level. When provided at the session level, it applies to the entire SDP session description. When provided at the media level, it applies only to the media description in question (option tags provided at the session level apply as well). There MUST NOT be more than one "a=csup" attribute at the session level and one at the media level (one per media description in the latter case).
可以在会话和媒体级别提供“a=csup”属性。在会话级别提供时，它适用于整个SDP会话描述。在媒体级别提供时，它仅适用于相关媒体描述（会话级别提供的选项标记也适用）。会话级别和媒体级别的“a=csup”属性不得超过一个（后一种情况下，每个媒体描述一个）。
Whenever an entity that supports one or more extensions to the SDP Capability Negotiation framework generates an SDP session description, it SHOULD include the "a=csup" attribute with the option tags for the extensions it supports at the session and/or media level, unless those option tags are already provided in one or more "a=creq" attribute (see Section 3.3.2) at the relevant levels. Inclusion of the base option tag is OPTIONAL; support for the base framework can be inferred from presence of the "a=pcfg" attribute defined in Section 3.5.1.
每当支持SDP能力协商框架的一个或多个扩展的实体生成SDP会话描述时，该实体应包括“a=csup”属性以及其在会话和/或媒体级别支持的扩展的选项标记，除非这些选项标记已在一个或多个“a=creq”属性中提供（参见第3.3.2节）在相关级别。包含基本选项标签是可选的；可以从第3.5.1节中定义的“a=pcfg”属性的存在推断对基本框架的支持。
Use of the base option tag may still be useful in some scenarios, e.g., when using SIP OPTIONS [RFC3261] or generating an answer to an offer that did not use the SDP Capability Negotiation framework.
在某些情况下，使用基本选项标签可能仍然有用，例如，当使用SIP选项[RFC3261]或生成对未使用SDP能力协商框架的报价的答复时。
The Required Capability Negotiation Extensions attribute ("a=creq") contains a comma-separated list of option tags (see Section 3.3.1) specifying the SDP Capability Negotiation extensions that MUST be supported by the entity receiving the SDP session description, in order for that entity to properly process the SDP Capability Negotiation attributes and associated procedures. There is no need to include the base option tag ("cap-v0") with the "creq" attribute,
所需能力协商扩展属性（“a=creq”）包含以逗号分隔的选项标签列表（见第3.3.1节），指定接收SDP会话描述的实体必须支持的SDP能力协商扩展，以便该实体正确处理SDP能力协商属性和相关程序。无需将基本选项标签（“cap-v0”）包含在“creq”属性中，
since any entity that supports the "creq" attribute in the first place also supports the base option tag. Still, it is permissible to do so.
因为首先支持“creq”属性的任何实体也支持基本选项标记。不过，这样做是允许的。
Such functionality may be important if a future version of the Capability Negotiation framework were not backwards compatible.
如果能力协商框架的未来版本不向后兼容，则此类功能可能很重要。
The attribute can be provided at the session level and the media level, and it is defined as follows:
该属性可以在会话级和媒体级提供，定义如下：
a=creq: <option-tag-list>
a=creq: <option-tag-list>
The "creq" attribute adheres to the RFC 4566 "attribute" production, with an att-value defined as follows:
“creq”属性符合RFC 4566“属性”产品，att值定义如下：
att-value = option-tag-list
att-value = option-tag-list
The following examples illustrate use of the "a=creq" attribute with the "cap-v0" base option tag and two hypothetical option tags, "foo" and "bar" (note the lack of white space):
以下示例说明了“a=creq”属性与“cap-v0”基本选项标记和两个假设选项标记“foo”和“bar”的使用（注意缺少空格）：
a=creq:cap-v0
a=creq:foo
a=creq:cap-v0
a=creq:foo
a=creq:bar
a=creq:bar
a=creq:cap-v0,foo,bar
a=creq:cap-v0，foo，bar
The "a=creq" attribute can be provided at the session and the media level. When provided at the session level, it applies to the entire SDP session description. When provided at the media level, it applies only to the media description in question (required option tags provided at the session level apply as well). There MUST NOT be more than one "a=creq" attribute at the session level and one "a=creq" attribute at the media level (one per media description in the latter case).
“a=creq”属性可以在会话和媒体级别提供。在会话级别提供时，它适用于整个SDP会话描述。在媒体级别提供时，它仅适用于相关媒体描述（会话级别提供的必需选项标记也适用）。会话级别不得有多个“a=creq”属性，媒体级别不得有多个“a=creq”属性（后一种情况下，每个媒体描述一个）。
When an entity generates an SDP session description and it requires the recipient of that SDP session description to support one or more SDP Capability Negotiation extensions (except for the base) at the session or media level in order to properly process the SDP Capability Negotiation, the "a=creq" attribute MUST be included with option tags that identify the required extensions at the session and/or media level. If support for an extension is needed only in one or more specific potential configurations, the potential configuration provides a way to indicate that instead (see Section 3.5.1). Support for the basic negotiation framework is implied by
当实体生成SDP会话描述，并且它要求该SDP会话描述的接收者在会话或媒体级别支持一个或多个SDP能力协商扩展（基本除外），以便正确处理SDP能力协商时，“a=creq”属性必须包含在选项标记中，选项标记用于标识会话和/或媒体级别所需的扩展。如果仅在一个或多个特定的潜在配置中需要对扩展的支持，则潜在配置提供了一种方式来表示（参见第3.5.1节）。对基本谈判框架的支持由
the presence of an "a=pcfg" attribute (see Section 3.5.1) and hence it is not required to include the "a=creq" attribute with the base option tag ("cap-v0").
存在“a=pcfg”属性（见第3.5.1节），因此无需在基本选项标签（“cap-v0”）中包含“a=creq”属性。
A recipient that receives an SDP session description and does not support one or more of the required extensions listed in a "creq" attribute MUST NOT perform the SDP Capability Negotiation defined in this document; instead the recipient MUST proceed as if the SDP Capability Negotiation attributes were not included in the first place, i.e., the capability negotiation attributes are ignored. In that case, if the SDP session description recipient is an SDP answerer [RFC3264], the recipient SHOULD include a "csup" attribute in the resulting SDP session description answer listing the SDP Capability Negotiation extensions it actually supports.
接收SDP会话描述且不支持“creq”属性中列出的一个或多个所需扩展的收件人不得执行本文档中定义的SDP能力协商；相反，接收方必须继续，就好像SDP能力协商属性没有包含在第一位一样，即忽略能力协商属性。在这种情况下，如果SDP会话描述接收者是SDP应答者[RFC3264]，则接收者应在生成的SDP会话描述应答中包含“csup”属性，列出其实际支持的SDP能力协商扩展。
This ensures that introduction of the SDP Capability Negotiation mechanism by itself does not lead to session failures
这确保了SDP能力协商机制的引入本身不会导致会话失败
For non-supported extensions provided at the session level, this implies that SDP Capability Negotiation MUST NOT be performed at all. For non-supported extensions at the media level, this implies that SDP Capability Negotiation MUST NOT be performed for the media stream in question.
对于在会话级别提供的不受支持的扩展，这意味着根本不能执行SDP能力协商。对于媒体级别不受支持的扩展，这意味着不能对所讨论的媒体流执行SDP能力协商。
An entity that does not support the SDP Capability Negotiation framework at all, will ignore these attributes (as well as the other SDP Capability Negotiation attributes) and not perform any SDP Capability Negotiation in the first place.
完全不支持SDP能力协商框架的实体将忽略这些属性（以及其他SDP能力协商属性），并且不会首先执行任何SDP能力协商。
In this section, we present the new attributes associated with indicating the capabilities for use by the SDP Capability Negotiation.
在本节中，我们将介绍与指示SDP能力协商使用的能力相关的新属性。
Attributes and their associated values can be expressed as capabilities by use of a new attribute capability attribute ("a=acap"), which is defined as follows:
属性及其相关值可通过使用新属性能力属性（“a=acap”）表示为能力，该属性定义如下：
a=acap: <att-cap-num> <att-par>
a=acap: <att-cap-num> <att-par>
where <att-cap-num> is an integer between 1 and 2^31-1 (both included) used to number the attribute capability and <att-par> is an attribute ("a=") in its "<attribute>" or "<attribute>:<value>" form, i.e., excluding the "a=" part (see [RFC4566]). The attribute can be provided at the session level and the media level.
其中，<att cap num>是一个介于1和2之间的整数^31-1（均包括在内），用于对属性能力进行编号，<att par>是其“<attribute>”或“<attribute>：<value>”形式中的属性（“a=”），即不包括“a=”部分（参见[RFC4566]）。该属性可以在会话级别和媒体级别提供。
The "acap" attribute adheres to the RFC 4566 "attribute" production, with an att-value defined as follows:
“acap”属性符合RFC 4566“属性”产品，att值定义如下：
att-value = att-cap-num 1*WSP att-par
att-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
att-par = attribute ;defined in [RFC4566]
att-value = att-cap-num 1*WSP att-par
att-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
att-par = attribute ;defined in [RFC4566]
Note that white space is not permitted before the att-cap-num.
请注意，att-cap-num之前不允许有空格。
When the attribute capability contains a session-level attribute, that "acap" attribute can only be provided at the session level. Conversely, media-level attributes can be provided in attribute capabilities at either the media level or session level. The base SDP Capability Negotiation framework however only defines procedures for use of media-level attribute capabilities at the media level. Implementations that conform only to the base framework MUST NOT generate media-level attribute capabilities at the session level; however, extensions may change this (see, e.g., [SDPMedCap] for one such extension) and hence all implementations MUST still be prepared to receive such capabilities (see Section 3.6.2 for processing rules).
当属性功能包含会话级属性时，该“acap”属性只能在会话级提供。相反，可以在媒体级或会话级的属性功能中提供媒体级属性。但是，基本SDP能力协商框架仅定义了在媒体级别使用媒体级别属性能力的过程。仅符合基本框架的实现不得在会话级别生成媒体级属性功能；但是，扩展可能会改变这一点（例如，请参阅[SDPMedCap]了解一个此类扩展），因此所有实现都必须准备好接收此类功能（请参阅第3.6.2节了解处理规则）。
Each occurrence of the "acap" attribute in the entire session description MUST use a different value of <att-cap-num>. Consecutive numbering of the <att-cap-num> values is not required.
整个会话描述中每次出现“acap”属性都必须使用不同的值<att cap num>。不需要对<att cap num>值进行连续编号。
There is a need to be able to reference both session-level and media-level attributes in potential configurations at the media level, and this provides for a simple solution to avoiding overlap between the references (handles) to each attribute capability.
需要能够在媒体级别的潜在配置中引用会话级别和媒体级别属性，这提供了一个简单的解决方案，以避免每个属性功能的引用（句柄）之间的重叠。
The <att-cap-num> values provided are independent of similar <cap-num> values provided for other types of capabilities, i.e., they form a separate name-space for attribute capabilities.
提供的<att cap num>值独立于为其他类型的功能提供的类似<cap num>值，即，它们为属性功能形成单独的名称空间。
The following examples illustrate use of the "acap" attribute:
以下示例说明了“acap”属性的使用：
a=acap:1 ptime:20
a=acap:1 ptime:20
a=acap:2 ptime:30
a=acap:2 ptime:30
a=acap:3 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAA AAAGEEoo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0 JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUO SrzKTAv9zV
a=acap:3关键管理：mikey AQAFGM0xFlabaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaagageoo2pee4hp2uadx8ze22ywkaaapzg9uywxkqgr1y2suy29taqaaaaak0 jkpgavkdawi9whvbtbt0kz14ymnu62+Nv3ozPLygwK/gbav9iemnguiz19fquo SrzKTAv9zV
a=acap:4 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=acap:4 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
The first two attribute capabilities provide attribute values for the ptime attribute. The third provides SRTP parameters by using Multimedia Internet KEYing (MIKEY) [RFC3830] with the "key-mgmt" attribute [RFC4567]. The fourth provides SRTP parameters by use of security descriptions with the "crypto" attribute [RFC4568]. Note that the line-wrapping and new-lines in example three and four are provided for formatting reasons only -- they are not permitted in actual SDP session descriptions.
前两个属性功能为ptime属性提供属性值。第三个通过使用具有“密钥管理”属性[RFC4567]的多媒体互联网密钥（MIKEY）[RFC3830]来提供SRTP参数。第四个通过使用带有“crypto”属性[RFC4568]的安全描述来提供SRTP参数。请注意，示例3和示例4中的换行和新行仅出于格式化原因提供——在实际的SDP会话描述中不允许使用它们。
Readers familiar with RFC 3407 may notice the similarity between the RFC 3407 "cpar" attribute and the above. There are however a couple of important differences, notably that the "acap" attribute contains a handle that enables referencing it and it furthermore supports only attributes (the "cpar" attribute defined in RFC 3407 supports bandwidth information as well). The "acap" attribute also is not automatically associated with any particular capabilities. See Section 3.14 for the relationship to RFC 3407.
熟悉RFC3407的读者可能会注意到RFC3407“cpar”属性与上述属性之间的相似性。然而，有两个重要的区别，值得注意的是，“acap”属性包含一个允许引用它的句柄，并且它还只支持属性（rfc3407中定义的“cpar”属性也支持带宽信息）。“acap”属性也不会自动与任何特定功能关联。有关与RFC 3407的关系，请参见第3.14节。
Attribute capabilities MUST NOT embed any capability negotiation parameters. This restriction applies to all the capability negotiation parameters defined in this document ("csup", "creq", "acap", "tcap", "pcfg", and "acfg") as well as any capability negotiation extensions defined. The following examples are thus invalid attribute capabilities and MUST NOT be used:
属性功能不得嵌入任何功能协商参数。此限制适用于本文件中定义的所有能力协商参数（“csup”、“creq”、“acap”、“tcap”、“pcfg”和“acfg”）以及定义的任何能力协商扩展。因此，以下示例是无效的属性功能，不得使用：
a=acap:1 acap:2 foo:a ;Not allowed to embed "acap"
a=acap:1 acap:2 foo:a ;Not allowed to embed "acap"
a=acap:2 a=pcfg:1 t=1 a=1 ;Not allowed to embed "pcfg"
a=acap:2 a=pcfg:1 t=1 a=1 ;Not allowed to embed "pcfg"
The reason for this restriction is to avoid overly complex processing rules resulting from the expansion of such capabilities into potential configurations (see Section 3.6.2 for further details).
此限制的原因是为了避免将此类功能扩展到潜在配置时产生过于复杂的处理规则（更多详细信息，请参见第3.6.2节）。
Transport protocols can be expressed as capabilities by use of a new Transport Protocol Capability attribute ("a=tcap") defined as follows:
通过使用新的传输协议能力属性（“a=tcap”），传输协议可以表示为能力，定义如下：
a=tcap: <trpr-cap-num> <proto-list>
a=tcap: <trpr-cap-num> <proto-list>
where <trpr-cap-num> is an integer between 1 and 2^31-1 (both included) used to number the transport address capability for later reference, and <proto-list> is one or more <proto>, separated by white space, as defined in the SDP "m=" line. The attribute can be provided at the session level and the media level.
其中<trpr cap num>是一个介于1和2之间的整数^31-1（均包括在内），用于对传输地址能力进行编号以供以后参考，<proto list>是一个或多个<proto>，由空格分隔，如SDP“m=”行中所定义。该属性可以在会话级别和媒体级别提供。
The "tcap" attribute adheres to the RFC 4566 "attribute" production, with an att-value defined as follows:
“tcap”属性符合RFC 4566“属性”产品，att值定义如下：
att-value = trpr-cap-num 1*WSP proto-list
trpr-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
proto-list = proto *(1*WSP proto) ;defined in [RFC4566]
att-value = trpr-cap-num 1*WSP proto-list
trpr-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
proto-list = proto *(1*WSP proto) ;defined in [RFC4566]
Note that white space is not permitted before the trpr-cap-num.
请注意，trpr-cap-num之前不允许有空格。
The "tcap" attribute can be provided at the session level and the media level. There MUST NOT be more than one "a=tcap" attribute at the session level and one at the media level (one per media description in the latter case). Each occurrence of the "tcap" attribute in the entire session description MUST use a different value of <trpr-cap-num>. When multiple <proto> values are provided, the first one is associated with the value <trpr-cap-num>, the second one with the value one higher, etc. There MUST NOT be any capability number overlap between different "tcap" attributes in the entire SDP session description. The <trpr-cap-num> values provided are independent of similar <cap-num> values provided for other capability attributes, i.e., they form a separate name-space for transport protocol capabilities. Consecutive numbering of the <trpr-cap-num> values in different "tcap" attributes is not required.
“tcap”属性可以在会话级别和媒体级别提供。会话级别和媒体级别的“a=tcap”属性不得超过一个（后一种情况下，每个媒体描述一个）。整个会话描述中每次出现“tcap”属性都必须使用不同的值<trpr cap num>。当提供多个<proto>值时，第一个值与<trpr cap num>值关联，第二个值与更高的值关联，等等。在整个SDP会话描述中，不同的“tcap”属性之间不得有任何能力编号重叠。提供的<trpr cap num>值独立于为其他功能属性提供的类似<cap num>值，即，它们为传输协议功能形成单独的名称空间。不同“tcap”属性中的<trpr cap num>值不需要连续编号。
Below, we provide examples of the "a=tcap" attribute:
下面，我们提供了“a=tcap”属性的示例：
a=tcap:1 RTP/AVP
a=tcap:1 RTP/AVP
a=tcap:2 RTP/AVPF
a=tcap:2 RTP/AVPF
a=tcap:3 RTP/SAVP RTP/SAVPF
a=tcap:3 RTP/SAVP RTP/SAVPF
a=tcap:5 UDP/TLS/RTP/SAVP
a=tcap:5 UDP/TLS/RTP/SAVP
The first one provides a capability for the "RTP/AVP" profile defined in [RFC3551] and the second one provides a capability for the RTP with RTCP-based feedback profile defined in [RFC4585]. The third one provides capabilities for the "RTP/SAVP" (transport capability number 3) and "RTP/SAVPF" profiles (transport protocol capability number 4). The last one provides capabilities for "UDP/TLS/RTP/SAVP", i.e., DTLS-SRTP [RFC5764] (transport capability number 5).
第一个提供了[RFC3551]中定义的“RTP/AVP”配置文件的功能，第二个提供了[RFC4585]中定义的基于RTCP的反馈配置文件的RTP功能。第三个为“RTP/SAVP”（传输能力编号3）和“RTP/SAVPF”配置文件（传输协议能力编号4）提供功能。最后一个提供“UDP/TLS/RTP/SAVP”功能，即DTLS-SRTP[RFC5764]（传输能力编号5）。
The "tcap" attribute by itself can only specify transport protocols as defined by <proto> in [RFC4566]; however, full specification of a media stream requires further qualification of the transport protocol by one or more media format descriptions, which themselves often depend on the transport protocol. As an example, [RFC3551] defines the "RTP/AVP" transport for use with audio and video codecs (media
“tcap”属性本身只能指定[RFC4566]中<proto>定义的传输协议；然而，媒体流的完整规范要求通过一个或多个媒体格式描述对传输协议进行进一步限定，媒体格式描述本身通常取决于传输协议。例如，[RFC3551]定义了用于音频和视频编解码器（媒体）的“RTP/AVP”传输
formats), whereas [RFC4145] defines the "TCP" transport, which, for example, may be used to negotiate T.38 fax ("image/t38"), etc. In a non-SDP context, some media formats could be viewed as transports themselves (e.g., T.38); however, in the context of SDP and SDP Capability Negotiation, they are not. If capability negotiation is required for such media formats, they MUST all either be valid under the transport protocol indicated in the "m=" line included for the media stream description, or a suitable extension must be used, e.g., SDP Media Capabilities [SDPMedCap].
格式），而[RFC4145]定义了“TCP”传输，例如，可用于协商T.38传真（“图像/t38”）等。在非SDP上下文中，一些媒体格式可被视为传输本身（例如T.38）；然而，在SDP和SDP能力谈判的背景下，它们并非如此。如果此类媒体格式需要能力协商，则它们必须在媒体流描述中包含的“m=”行中指示的传输协议下有效，或者必须使用适当的扩展，例如SDP媒体能力[SDPMedCap]。
The ability to use a particular transport protocol is inherently implied by including it in the "m=" line, regardless of whether or not it is provided in a "tcap" attribute. However, if a potential configuration needs to reference that transport protocol as a capability, the transport protocol MUST be included explicitly in a "tcap" attribute.
通过将特定传输协议包含在“m=”行中，无论是否在“tcap”属性中提供，使用特定传输协议的能力本质上都是隐含的。但是，如果潜在配置需要将该传输协议作为功能引用，则必须在“tcap”属性中明确包含该传输协议。
This may seem redundant (and indeed it is from the offerer's point of view), however it is done to protect against intermediaries (e.g., middleboxes) that may modify "m=" lines while passing unknown attributes through. If an implicit transport capability were used instead (e.g., a reserved transport capability number could be used to refer to the transport protocol in the "m=" line), and an intermediary were to modify the transport protocol in the "m=" line (e.g., to translate between plain RTP and Secure RTP), then the potential configuration referencing that implicit transport capability may no longer be correct. With explicit capabilities, we avoid this pitfall; however, the potential configuration preference (see Section 3.5.1) may not reflect that of the intermediary (which some may view as a feature).
这似乎是多余的（事实上，从报价人的角度来看），但这样做是为了防止中间商（如中间商）在传递未知属性时修改“m=”行。如果改为使用隐式传输能力（例如，可以使用保留传输能力编号来引用“m=”行中的传输协议），并且中间层要修改“m=”行中的传输协议（例如，在普通RTP和安全RTP之间转换），然后，潜在的配置引用隐式传输能力可能不再正确。有了明确的能力，我们就避免了这个陷阱；然而，潜在的配置偏好（见第3.5.1节）可能不反映中间层的配置偏好（有些人可能将其视为特征）。
Note that a transport protocol capability may be provided, irrespective of whether or not it is referenced in a potential configuration (just like any other capability).
请注意，可以提供传输协议功能，而不管它是否在潜在配置中被引用（就像任何其他功能一样）。
The SDP Capability Negotiation framework allows for new types of capabilities to be defined as extensions and used with the general capability negotiation framework. The syntax and semantics of such new capability attributes are not defined here; however, in order to be used with potential configurations, they SHOULD allow for a numeric handle to be associated with each capability. This handle can be used as a reference within the potential and actual configuration attributes (see Sections 3.5.1 and 3.5.2). The definition of such extension capability attributes MUST also state whether they can be applied at the session level, media level, or
SDP能力协商框架允许将新类型的能力定义为扩展，并与通用能力协商框架一起使用。此处未定义此类新功能属性的语法和语义；但是，为了与潜在的配置一起使用，它们应该允许一个数字句柄与每个功能相关联。该句柄可用作潜在和实际配置属性中的参考（见第3.5.1和3.5.2节）。此类扩展能力属性的定义还必须说明它们是否可以应用于会话级别、媒体级别或其他级别
both. Note that extensions can have option tags defined for them, and option tags MUST be registered with the IANA in accordance with the procedures specified in Section 6.2.
二者都请注意，扩展可以为其定义选项标签，并且必须按照第6.2节规定的程序向IANA注册选项标签。
Extension capabilities SHOULD NOT embed any capability negotiation parameters. This applies to all the capability negotiation parameters defined in this document as well as any extensions defined. The reason for this restriction is to avoid overly complex processing rules resulting from the expansion of such capabilities into potential configurations (see Section 3.6.2 for further details). If an extension does not follow the above "SHOULD NOT" recommendation, the extension MUST provide a careful analysis of why such behavior is both necessary and safe.
扩展功能不应嵌入任何功能协商参数。这适用于本文件中定义的所有能力协商参数以及定义的任何扩展。此限制的原因是为了避免将此类功能扩展到潜在配置时产生过于复杂的处理规则（更多详细信息，请参见第3.6.2节）。如果扩展没有遵循上述“不应该”的建议，那么扩展必须仔细分析为什么这样的行为既必要又安全。
Potential configurations can be expressed by use of a new Potential Configuration Attribute ("a=pcfg") defined as follows:
潜在配置可通过使用新的潜在配置属性（“a=pcfg”）表示，定义如下：
a=pcfg: <config-number> [<pot-cfg-list>]
a=pcfg: <config-number> [<pot-cfg-list>]
where <config-number> is an integer between 1 and 2^31-1 (both included). The attribute can be provided only at the media level.
其中<config number>是一个介于1和2^31-1之间的整数（均包含在内）。该属性只能在媒体级别提供。
The "pcfg" attribute adheres to the RFC 4566 "attribute" production, with an att-value defined as follows:
“pcfg”属性符合RFC 4566“属性”产品，att值定义如下：
att-value = config-number [1*WSP pot-cfg-list]
config-number = 1*10(DIGIT) ;defined in [RFC5234]
pot-cfg-list = pot-config *(1*WSP pot-config)
pot-config = attribute-config-list /
transport-protocol-config-list /
extension-config-list
att-value = config-number [1*WSP pot-cfg-list]
config-number = 1*10(DIGIT) ;defined in [RFC5234]
pot-cfg-list = pot-config *(1*WSP pot-config)
pot-config = attribute-config-list /
transport-protocol-config-list /
extension-config-list
The missing productions are defined below. Note that white space is not permitted before the config-number.
缺少的产品定义如下。请注意，配置编号前不允许有空格。
The potential configuration attribute can be provided only at the media level and there can be multiple instances of it within a given media description. The attribute includes a configuration number, which is an integer between 1 and 2^31-1 (both included). The configuration number MUST be unique within the media description (i.e., it has only media-level scope). The configuration number also indicates the relative preference of potential configurations; lower
潜在配置属性只能在媒体级别提供，并且在给定的媒体描述中可以有多个实例。该属性包括一个配置号，它是介于1和2^31-1之间的整数（两者都包括）。配置号在介质描述中必须是唯一的（即，它只有介质级别的作用域）。配置编号还表示潜在配置的相对偏好；降低
numbers are preferred over higher numbers. Consecutive numbering of the configuration numbers in different "pcfg" attributes in a media description is not required.
数字优先于更高的数字。介质描述中不同“pcfg”属性中的配置编号不需要连续编号。
A potential configuration list is normally provided after the configuration number. When the potential configuration list is omitted, the potential configuration equals the actual configuration. The potential configuration list contains one or more of attribute, transport, and extension configuration lists. A potential configuration may for example include attribute capabilities and transport capabilities, transport capabilities only, or some other combination of capabilities. If transport capabilities are not included in a potential configuration, the default transport for that media stream is used.
潜在配置列表通常在配置编号后提供。当省略潜在配置列表时，潜在配置等于实际配置。潜在配置列表包含一个或多个属性、传输和扩展配置列表。例如，潜在配置可包括属性能力和传输能力、仅传输能力或一些其他能力组合。如果潜在配置中不包括传输功能，则使用该媒体流的默认传输。
The potential configuration lists generally reference one or more capabilities (extension configuration lists MAY use a different format). Those capabilities are (conceptually) used to construct a new internal version of the SDP session description by use of purely syntactic add and (possibly) delete operations on the original SDP session description (actual configuration). This provides an alternative potential configuration SDP session description that can be used by conventional SDP and offer/answer procedures if selected.
潜在配置列表通常引用一个或多个功能（扩展配置列表可能使用不同的格式）。这些功能（概念上）用于通过对原始SDP会话描述（实际配置）使用纯语法的添加和（可能）删除操作来构建SDP会话描述的新内部版本。这提供了一种替代的潜在配置SDP会话描述，可供传统SDP和提供/应答程序（如果选择）使用。
This document defines attribute configuration lists and transport protocol configuration lists. Each of these MUST NOT be present more than once in a particular potential configuration attribute. Attribute capabilities referenced by the attribute configuration list (if included) are added to the actual configuration, whereas a transport capability referenced by the transport protocol configuration list (if included) replaces the default transport protocol from the actual configuration. Extension configuration lists can be included as well. There can be more than one extension configuration list; however, each particular extension MUST NOT be present more than once in a given "a=pcfg" attribute. Together, the various configuration lists define a potential configuration.
本文档定义了属性配置列表和传输协议配置列表。在特定的潜在配置属性中，这些属性不能出现多次。属性配置列表（如果包括）引用的属性功能将添加到实际配置中，而传输协议配置列表（如果包括）引用的传输功能将替换实际配置中的默认传输协议。也可以包括扩展配置列表。可以有多个扩展配置列表；但是，在给定的“a=pcfg”属性中，每个特定扩展不能出现一次以上。各种配置列表一起定义了潜在的配置。
There can be multiple potential configurations in a media description. Each of these indicates not only a willingness, but in fact a desire to use the potential configuration.
介质描述中可能有多个潜在配置。其中的每一项都不仅表明了使用潜在配置的意愿，事实上也表明了使用潜在配置的愿望。
The example SDP session description below contains two potential configurations:
下面的示例SDP会话描述包含两种可能的配置：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP RTP/SAVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1
a=pcfg:2 t=2 a=1
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP RTP/SAVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1
a=pcfg:2 t=2 a=1
Potential configuration 1 contains a transport protocol configuration list that references transport capability 1 ("RTP/SAVP") and an attribute configuration list that references attribute capability 1 ("a=crypto:..."). Potential configuration 2 contains a transport protocol configuration list that references transport capability 2 ("RTP/SAVPF") and an attribute configuration list that references attribute capability 1 ("a=crypto:...").
潜在配置1包含引用传输能力1的传输协议配置列表（“RTP/SAVP”）和引用属性能力1的属性配置列表（“a=crypto:…”）。潜在配置2包含引用传输能力2（“RTP/SAVPF”）的传输协议配置列表和引用属性能力1（“a=crypto:…”）的属性配置列表。
Attribute capabilities are used in a potential configuration by use of the attribute-config-list parameter, which is defined by the following ABNF:
属性功能通过使用属性配置列表参数在潜在配置中使用，该参数由以下ABNF定义：
attribute-config-list = "a=" delete-attributes
attribute-config-list =/ "a=" [delete-attributes ":"]
mo-att-cap-list *(BAR mo-att-cap-list)
attribute-config-list = "a=" delete-attributes
attribute-config-list =/ "a=" [delete-attributes ":"]
mo-att-cap-list *(BAR mo-att-cap-list)
delete-attributes = DELETE ( "m" ; media attributes
/ "s" ; session attributes
/ "ms" ) ; media and session attributes
delete-attributes = DELETE ( "m" ; media attributes
/ "s" ; session attributes
/ "ms" ) ; media and session attributes
mo-att-cap-list = mandatory-optional-att-cap-list / mandatory-att-cap-list / optional-att-cap-list
mo att cap list=强制性可选att cap list/强制性att cap list/可选att cap list
mandatory-optional-att-cap-list = mandatory-att-cap-list "," optional-att-cap-list mandatory-att-cap-list = att-cap-list optional-att-cap-list = "[" att-cap-list "]"
强制性可选附件上限列表=强制性附件上限列表”，“选择性附件上限列表强制性附件上限列表=附件上限列表可选附件上限列表=“[“附件上限列表”]”
att-cap-list = att-cap-num *("," att-cap-num)
att-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
BAR = "|"
DELETE = "-"
att-cap-list = att-cap-num *("," att-cap-num)
att-cap-num = 1*10(DIGIT) ;defined in [RFC5234]
BAR = "|"
DELETE = "-"
Note that white space is not permitted within the attribute-config-list rule.
请注意，属性配置列表规则中不允许使用空格。
Each attribute configuration list can optionally begin with instructions for how to handle attributes that are part of the actual configuration SDP session description (i.e., the "a=" lines present in the original SDP session description). By default, such attributes will remain as part of the potential configuration in question. However, if delete-attributes indicates "-m", then all attribute lines within the media description in question will be deleted in the resulting potential configuration SDP session description (i.e., all "a=" lines under the "m=" line in question). If delete-attributes indicates "-s", then all attribute lines at the session level will be deleted (i.e., all "a=" lines before the first "m=" line). If delete-attributes indicates "-ms", then all attribute lines within this media description ("m=" line) and all attribute lines at the session level will be deleted.
每个属性配置列表可以选择从如何处理作为实际配置SDP会话描述一部分的属性的说明开始（即原始SDP会话描述中的“a=”行）。默认情况下，这些属性将保留为所讨论的潜在配置的一部分。但是，如果delete attributes（删除属性）指示“-m”，则在生成的潜在配置SDP会话描述中，将删除相关媒体描述中的所有属性行（即“m=”相关行下的所有“a=”行）。如果删除属性指示“-s”，则将删除会话级别的所有属性行（即，第一个“m=”行之前的所有“a=”行）。如果删除属性指示“-ms”，则此媒体描述中的所有属性行（“m=”行）以及会话级别的所有属性行都将被删除。
The attribute capability list comes next (if included). It contains one or more alternative lists of attribute capabilities. The alternative attribute capability lists are separated by a vertical bar ("|"), and each list contains one or more attribute capabilities separated by commas (","). The attribute capabilities are either mandatory or optional. Mandatory attribute capabilities MUST be supported in order to use the potential configuration, whereas optional attribute capabilities MAY be supported in order to use the potential configuration.
接下来是属性能力列表（如果包括）。它包含一个或多个可选的属性功能列表。可选属性功能列表由一个垂直条（“|”）分隔，每个列表包含一个或多个由逗号（“，”）分隔的属性功能。属性功能是强制性的或可选的。必须支持强制属性功能才能使用潜在配置，而支持可选属性功能才能使用潜在配置。
Within each attribute capability list, all the mandatory attribute capabilities (if any) are listed first, and all the optional attribute capabilities (if any) are listed last. The optional attribute capabilities are contained within a pair of square brackets ("[" and "]"). Each attribute capability is merely an attribute capability number (att-cap-num) that identifies a particular attribute capability by referring to attribute capability numbers defined above and hence MUST be between 1 and 2^31-1 (both included). The following example illustrates the above:
在每个属性能力列表中，首先列出所有强制属性能力（如果有），最后列出所有可选属性能力（如果有）。可选属性功能包含在一对方括号（“[”和“]”）中。每个属性能力仅是一个属性能力编号（att cap num），通过参考上文定义的属性能力编号来识别特定属性能力，因此必须介于1和2^31-1之间（两者均包括）。以下示例说明了上述内容：
a=pcfg:1 a=-m:1,2,[3,4]|1,7,[5]
a=pcfg:1 a=-m:1,2,[3,4]|1,7,[5]
where
哪里
o "a=-m:1,2,[3,4]|1,7,[5]" is the attribute configuration list
o “a=-m:1,2[3,4]| 1,7[5]”是属性配置列表
o "-m" indicates to delete all attributes from the media description of the actual configuration
o “-m”表示从实际配置的介质描述中删除所有属性
o "1,2,[3,4]" and "1,7,[5]" are both attribute capability lists. The two lists are alternatives, since they are separated by a vertical bar above
o “1,2、[3,4]”和“1,7、[5]”都是属性能力列表。这两个列表是可选的，因为它们由上面的竖线分隔
o "1", "2", and "7" are mandatory attribute capabilities
o “1”、“2”和“7”是强制属性能力
o "3", "4", and "5" are optional attribute capabilities
o “3”、“4”和“5”是可选属性能力
Note that in the example above, we have a single handle ("1") for the potential configuration(s), but there are actually two different potential configurations (separated by a vertical bar). This is done for message size efficiency reasons, which is especially important when we add other types of capabilities to the potential configuration. If there is a need to provide a unique handle for each, then separate "a=pcfg" attributes with different handles MUST be used instead.
请注意，在上面的示例中，我们有一个用于潜在配置的单手柄（“1”），但实际上有两个不同的潜在配置（由垂直条分隔）。这样做是为了提高消息大小和效率，当我们向潜在配置中添加其他类型的功能时，这一点尤为重要。如果需要为每个属性提供唯一的句柄，则必须使用具有不同句柄的单独“a=pcfg”属性。
Each referenced attribute capability in the potential configuration will result in the corresponding attribute name and its associated value (contained inside the attribute capability) being added to the resulting potential configuration SDP session description.
潜在配置中的每个引用属性功能将导致相应的属性名称及其关联值（包含在属性功能中）添加到生成的潜在配置SDP会话描述中。
Alternative attribute capability lists are separated by a vertical bar ("|"), the scope of which extends to the next alternative (i.e., "," has higher precedence than "|"). The alternatives are ordered by preference with the most preferred listed first. In order for a recipient of the SDP session description (e.g., an answerer receiving this in an offer) to use this potential configuration, exactly one of the alternative lists MUST be selected in its entirety. This requires that all mandatory attribute capabilities referenced by the potential configuration are supported with the attribute values provided.
备选属性能力列表由一个垂直条（“|”）分隔，其范围扩展到下一个备选属性（即“，”的优先级高于“|”）。备选方案按优先顺序排列，最优先的列在第一位。为了让SDP会话描述的接收者（例如，在报价中收到此描述的应答者）使用此潜在配置，必须完全选择一个备选列表。这要求提供的属性值支持潜在配置引用的所有强制属性功能。
Transport protocol configuration lists are included in a potential configuration by use of the transport-protocol-config-list parameter, which is defined by the following ABNF:
传输协议配置列表通过使用传输协议配置列表参数包含在潜在配置中，该参数由以下ABNF定义：
transport-protocol-config-list =
"t=" trpr-cap-num *(BAR trpr-cap-num)
trpr-cap-num = 1*10(DIGIT) ; defined in [RFC5234]
transport-protocol-config-list =
"t=" trpr-cap-num *(BAR trpr-cap-num)
trpr-cap-num = 1*10(DIGIT) ; defined in [RFC5234]
Note that white space is not permitted within this rule.
请注意，此规则中不允许使用空格。
The trpr-cap-num refers to transport protocol capability numbers defined above and hence MUST be between 1 and 2^31-1 (both included). Alternative transport protocol capabilities are separated by a vertical bar ("|"). The alternatives are ordered by preference with the most preferred listed first. If there are no transport protocol
trpr cap num是指上面定义的传输协议能力编号，因此必须介于1和2^31-1之间（两者都包括在内）。替代传输协议功能由竖条（“|”）分隔。备选方案按优先顺序排列，最优先的列在第一位。如果没有传输协议
capabilities included in a potential configuration at the media level, the transport protocol information from the associated "m=" line MUST be used. In order for a recipient of the SDP session description (e.g., an answerer receiving this in an offer) to use this potential configuration, exactly one of the alternatives MUST be selected. This requires that the transport protocol in question is supported.
在媒体级别的潜在配置中包括的功能，必须使用来自相关“m=”行的传输协议信息。为了让SDP会话描述的接收者（例如，在报价中收到此描述的应答者）使用此潜在配置，必须选择其中一个备选方案。这要求支持所讨论的传输协议。
In the presence of intermediaries (the existence of which may not be known), care should be taken with assuming that the transport protocol in the "m=" line will not be modified by an intermediary. Use of an explicit transport protocol capability will guard against capability negotiation implications of that.
在存在中间层（可能不知道是否存在）的情况下，应注意假设“m=”行中的传输协议不会被中间层修改。使用显式传输协议能力将防止由此带来的能力协商影响。
Extension capabilities can be included in a potential configuration as well by use of extension configuration lists. Extension configuration lists MUST adhere to the following ABNF:
通过使用扩展配置列表，扩展功能也可以包含在潜在配置中。扩展配置列表必须符合以下ABNF：
extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT)
ext-cap-list = 1*VCHAR ; defined in [RFC5234]
extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT)
ext-cap-list = 1*VCHAR ; defined in [RFC5234]
Note that white space is not permitted within this rule.
请注意，此规则中不允许使用空格。
The ext-cap-name refers to the name of the extension capability and the ext-cap-list is here merely defined as a sequence of visible characters. The actual extension supported MUST refine both of these further. For extension capabilities that merely need to be referenced by a capability number, it is RECOMMENDED to follow a structure similar to what has been specified above. Unsupported or unknown potential extension configuration lists in a potential configuration attribute MUST be ignored, unless they are prefixed with the plus ("+") sign, which indicates that the extension is mandatory and MUST be supported in order to use that potential configuration.
ext cap名称是指扩展功能的名称，ext cap列表在此仅定义为一系列可见字符。支持的实际扩展必须进一步完善这两个方面。对于只需要由能力编号引用的扩展能力，建议遵循类似于上面指定的结构。必须忽略潜在配置属性中不受支持或未知的潜在扩展配置列表，除非它们以加号（“+”）作为前缀，这表示扩展是必需的，并且必须受支持才能使用该潜在配置。
The "creq" attribute and its associated rules can be used to ensure that required extensions are supported in the first place.
“creq”属性及其关联规则可用于确保首先支持所需的扩展。
Extension configuration lists define new potential configuration parameters and hence they MUST be registered with IANA per the procedures defined in Section 6.3.
扩展配置列表定义了新的潜在配置参数，因此必须按照第6.3节中定义的程序向IANA注册这些参数。
Potential configuration attributes can be provided only at the media level; however, it is possible to reference capabilities provided at either the session or media level. There are certain semantic rules and restrictions associated with this:
只能在媒体级别提供潜在配置属性；但是，可以参考在会话或媒体级别提供的功能。与此相关的语义规则和限制如下：
A (media-level) potential configuration attribute in a given media description MUST NOT reference a media-level capability provided in a different media description; doing so invalidates that potential configuration (note that a potential configuration attribute can contain more than one potential configuration by use of alternatives). A potential configuration attribute can however reference a session-level capability. The semantics of doing so depends on the type of capability. In the case of transport protocol capabilities, it has no particular implication. In the case of attribute capabilities, however, it does. More specifically, the attribute name and value (provided within that attribute capability) will be considered part of the resulting SDP for that particular configuration at the *session* level. In other words, it will be as-if that attribute was provided with that value at the session level in the first place. As a result, the base SDP Capability Negotiation framework REQUIRES that potential configurations do not reference any session-level attribute capabilities that contain media-level attributes (since that would place a media-level attribute at the session level). Extensions may modify this behavior, as long as it is fully backwards compatible with the base specification.
给定媒体描述中的（媒体级别）潜在配置属性不得引用不同媒体描述中提供的媒体级别功能；这样做会使该潜在配置无效（请注意，通过使用备选方案，潜在配置属性可以包含多个潜在配置）。但是，潜在的配置属性可以引用会话级功能。这样做的语义取决于功能的类型。在传输协议能力的情况下，它没有特别的含义。但是，在属性功能的情况下，它确实如此。更具体地说，属性名称和值（在该属性功能中提供）将被视为该特定配置在*会话*级别的结果SDP的一部分。换句话说，就好像该属性首先在会话级别提供了该值一样。因此，基本SDP能力协商框架要求潜在配置不引用任何包含媒体级属性的会话级属性能力（因为这将在会话级放置媒体级属性）。扩展可以修改此行为，只要它与基本规范完全向后兼容。
Individual media streams perform capability negotiation individually, and hence it is possible that one media stream (where the attribute was part of a potential configuration) chose a configuration without a session-level attribute that was chosen by another media stream. The session-level attribute however remains "active" and applies to the entire resulting potential configuration SDP session description. In theory, this is problematic if one or more session-level attributes either conflicts with or potentially interacts with another session-level or media-level attribute in an undefined manner. In practice, such examples seem to be rare (at least with the SDP attributes that had been defined at time of publication of this document).
单个媒体流单独执行能力协商，因此一个媒体流（其中该属性是潜在配置的一部分）可能选择了一个配置，而没有另一个媒体流选择的会话级属性。但是，会话级别属性保持“活动”，并应用于生成的整个潜在配置SDP会话描述。从理论上讲，如果一个或多个会话级属性与另一个会话级或媒体级属性以未定义的方式冲突或可能相互作用，则这是有问题的。在实践中，这样的例子似乎很少（至少对于本文档发布时定义的SDP属性而言）。
A related set of problems can occur if we need coordination between session-level attributes from multiple media streams in order for a particular functionality to work. The grouping framework [RFC5888] is an example of this. If we use the SDP Capability Negotiation framework to select a session-level group attribute (provided as an attribute capability), and we require two media descriptions to do this consistently, we could have a problem. The Forward Error Correction (FEC) grouping semantics [RFC4756] is one example where this in theory could cause problems, however in practice, it is unclear that there is a significant problem with the grouping semantics that had been defined at time of publication of this document.
如果我们需要协调来自多个媒体流的会话级属性以使特定功能正常工作，则可能会出现一组相关的问题。分组框架[RFC5888]就是一个例子。如果我们使用SDP能力协商框架来选择会话级组属性（作为属性能力提供），并且我们需要两个媒体描述来一致地执行此操作，那么我们可能会遇到问题。前向纠错（FEC）分组语义[RFC4756]是理论上可能导致问题的一个例子，但是在实践中，不清楚在本文档发布时定义的分组语义是否存在重大问题。
Resolving the above issues in general requires inter-media stream constraints and synchronized potential configuration processing; this would add considerable complexity to the overall solution. In practice, with the SDP attributes defined at time of publication of this document, it does not seem to be a significant problem, and hence the base SDP Capability Negotiation solution does not provide a solution to this issue. Instead, it is RECOMMENDED that use of session-level attributes in a potential configuration is avoided when possible, and when not, that such use is examined closely for any potential interaction issues. If interaction is possible, the entity generating the SDP session description SHOULD NOT assume that well-defined operation will occur at the receiving entity. This implies that mechanisms that might have such interactions cannot be used in security critical contexts.
解决上述问题通常需要媒体间流约束和同步的潜在配置处理；这将给整个解决方案增加相当大的复杂性。实际上，在本文档发布时定义了SDP属性，这似乎不是一个重大问题，因此基本SDP能力协商解决方案无法解决此问题。相反，建议尽可能避免在可能的配置中使用会话级属性，否则，应仔细检查此类使用是否存在任何潜在的交互问题。如果可以进行交互，则生成SDP会话描述的实体不应假定在接收实体上将发生定义良好的操作。这意味着可能具有此类交互的机制不能在安全关键上下文中使用。
The session-level operation of extension capabilities is undefined. Consequently, each new session-level extension capability defined MUST specify the implication of making it part of a configuration at the media level.
扩展功能的会话级操作未定义。因此，定义的每个新会话级扩展功能必须指定使其成为媒体级配置一部分的含义。
Below, we provide an example of the "a=pcfg" attribute in a complete media description in order to properly indicate the supporting attributes:
下面，我们在完整的媒体描述中提供了一个“a=pcfg”属性的示例，以正确指示支持属性：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVPF 0 18
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=tcap:1 RTP/AVPF RTP/AVP RTP/SAVP RTP/SAVPF
a=pcfg:1 t=4|3 a=1
a=pcfg:8 t=1|2
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVPF 0 18
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=tcap:1 RTP/AVPF RTP/AVP RTP/SAVP RTP/SAVPF
a=pcfg:1 t=4|3 a=1
a=pcfg:8 t=1|2
We have two potential configuration attributes listed here. The first one (and most preferred, since its configuration number is "1") indicates that either of the profiles RTP/SAVPF or RTP/SAVP (specified by the transport protocol capability numbers 4 and 3) can be supported with attribute capability 1 (the "crypto" attribute); RTP/SAVPF is preferred over RTP/SAVP since its capability number (4) is listed first in the preferred potential configuration. Note that although we have a single potential configuration attribute and associated handle, we have two potential configurations.
这里列出了两个潜在的配置属性。第一个（也是最优选的，因为其配置号为“1”）表示属性能力1（“加密”属性）可以支持配置文件RTP/SAVPF或RTP/SAVP（由传输协议能力号4和3指定）；RTP/SAVPF优先于RTP/SAVP，因为其能力编号（4）列在首选潜在配置的第一位。注意，尽管我们有一个潜在的配置属性和关联的句柄，但我们有两个潜在的配置。
The second potential configuration attribute indicates that the RTP/AVPF or RTP/AVP profiles can be used, with RTP/AVPF being the preferred one. This non-secure RTP alternative is the less preferred one since its configuration number is "8". Again, note that we have two potential configurations here and hence a total of four potential configurations in the SDP session description above.
第二个潜在配置属性表示可以使用RTP/AVPF或RTP/AVP配置文件，RTP/AVPF是首选配置文件。由于其配置号为“8”，因此该非安全RTP替代方案不是首选方案。再次注意，这里有两种可能的配置，因此在上面的SDP会话描述中总共有四种可能的配置。
The actual configuration attribute identifies which of the potential configurations from an offer SDP session description was selected and used as the actual configuration to generate an answer SDP session description. This is done by including the configuration number and the configuration lists (if any) from the offer that were selected and used by the answerer in his offer/answer procedure as follows:
“实际配置”属性标识从报价SDP会话描述中选择了哪些潜在配置，并将其用作生成应答SDP会话描述的实际配置。这是通过将应答者在其报价/应答程序中选择和使用的报价中的配置编号和配置列表（如有）包括在内来实现的，如下所示：
o A selected attribute configuration MUST include the delete-attributes and the known and supported parameters from the selected alternative mo-att-cap-list (i.e., containing all mandatory and all known and supported optional capability numbers from the potential configuration). If delete-attributes were not included in the potential configuration, they will of course not be present here either.
o 所选属性配置必须包括所选备选mo att cap列表中的删除属性以及已知和支持的参数（即，包含潜在配置中的所有强制性和所有已知和支持的可选功能编号）。如果删除属性未包含在潜在配置中，那么它们当然也不会出现在这里。
o A selected transport protocol configuration MUST include the selected transport protocol capability number.
o 选定的传输协议配置必须包括选定的传输协议能力编号。
o A selected potential extension configuration MUST include the selected extension configuration parameters as specified for that particular extension.
o 选定的潜在扩展配置必须包括为该特定扩展指定的选定扩展配置参数。
o When a configuration list contains alternatives (separated by "|"), the selected configuration only MUST be provided.
o 当配置列表包含备选方案（以“|”分隔）时，必须仅提供所选配置。
Note that the selected configuration number and all selected capability numbers used in the actual configuration attribute refer to those from the offer: not the answer.
请注意，实际配置属性中使用的所选配置编号和所有所选功能编号都是指报价中的编号：而不是答案。
The answer may for example include capabilities as well to inform the offerer of the answerers capabilities above and beyond the negotiated configuration. The actual configuration attribute does not refer to any of those answer capabilities though.
例如，答案可能包括告知报价人在协商配置之上和之外的应答者能力的能力。不过，“实际配置”属性并不引用这些应答功能中的任何一个。
The Actual Configuration Attribute ("a=acfg") is defined as follows:
实际配置属性（“a=acfg”）定义如下：
a=acfg: <config-number> [<sel-cfg-list>]
a=acfg: <config-number> [<sel-cfg-list>]
where <config-number> is an integer between 1 and 2^31-1 (both included) that refers to the selected potential configuration. The attribute can be provided only at the media level.
其中，<config number>是一个介于1和2^31-1之间的整数（均包含），表示所选的潜在配置。该属性只能在媒体级别提供。
The "acfg" attribute adheres to the RFC 4566 "attribute" production, with an att-value defined as follows:
“acfg”属性符合RFC 4566“属性”产品，att值定义如下：
att-value = config-number [1*WSP sel-cfg-list]
;config-number defined in Section 3.5.1.
sel-cfg-list = sel-cfg *(1*WSP sel-cfg)
sel-cfg = sel-attribute-config /
sel-transport-protocol-config /
sel-extension-config
att-value = config-number [1*WSP sel-cfg-list]
;config-number defined in Section 3.5.1.
sel-cfg-list = sel-cfg *(1*WSP sel-cfg)
sel-cfg = sel-attribute-config /
sel-transport-protocol-config /
sel-extension-config
sel-attribute-config = "a=" [delete-attributes ":"] mo-att-cap-list ; defined in Section 3.5.1.
sel attribute config=“a=“[delete attributes”：“]mo att cap列表；定义见第3.5.1节。
sel-transport-protocol-config = "t=" trpr-cap-num ; defined in Section 3.5.1.
sel传输协议config=“t=”trpr cap num；定义见第3.5.1节。
sel-extension-config = ext-cap-name "=" 1*VCHAR ; defined in Section 3.5.1.
sel扩展配置=外部cap名称“=”1*VCHAR；定义见第3.5.1节。
Note that white space is not permitted before the config-number.
请注意，配置编号前不允许有空格。
The actual configuration ("a=acfg") attribute can be provided only at the media level. There MUST NOT be more than one occurrence of an actual configuration attribute within a given media description.
实际配置（“a=acfg”）属性只能在媒体级别提供。在给定的媒体描述中，实际配置属性的出现次数不得超过一次。
Below, we provide an example of the "a=acfg" attribute (building on the previous example with the potential configuration attribute):
下面，我们提供了一个“a=acfg”属性的示例（基于上一个具有潜在配置属性的示例）：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/SAVPF 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:1 t=4 a=1
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/SAVPF 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:1 t=4 a=1
It indicates that the answerer used an offer consisting of potential configuration number 1 with transport protocol capability 4 from the offer (RTP/SAVPF) and attribute capability 1 (the "crypto" attribute). The answerer includes his own "crypto" attribute as well.
这表明应答者使用了一个报价，该报价包括潜在配置编号1、报价中的传输协议能力4（RTP/SAVPF）和属性能力1（“加密”属性）。回答者还包括他自己的“加密”属性。
In this section, we define extensions to the offer/answer model defined in [RFC3264] to allow for potential configurations to be included in an offer, where they constitute alternative offers that may be accepted by the answerer instead of the actual configuration(s) included in the "m=" line(s).
在本节中，我们定义了[RFC3264]中定义的报价/应答模型的扩展，以允许报价中包含潜在配置，其中这些配置构成了可被应答者接受的备选报价，而不是“m=”行中包含的实际配置。
The procedures defined in the following subsections apply to both unicast and multicast streams.
以下小节中定义的过程适用于单播和多播流。
An offerer that wants to use the SDP Capability Negotiation defined in this document MUST include the following in the offer:
想要使用本文件中定义的SDP能力谈判的报价人必须在报价中包括以下内容：
o Zero or more attribute capability attributes. There MUST be an attribute capability attribute ("a=acap") as defined in Section 3.4.1 for each attribute name and associated value (if any) that needs to be indicated as a capability in the offer. Attribute capabilities may be included irrespective of whether or not they are referenced by a potential configuration.
o 零个或多个属性功能属性。对于需要在报价中指明为能力的每个属性名称和相关值（如有），必须有第3.4.1节中定义的属性能力属性（“a=acap”）。无论潜在配置是否引用属性功能，都可以包含属性功能。
Session-level attributes and associated values MUST be provided in attribute capabilities only at the session level, whereas media-level attributes and associated values can be provided in attribute capabilities at either the media level or session level. Attributes that are allowed at either the session or media level can be provided in attribute capabilities at either level.
会话级属性和关联值只能在会话级的属性功能中提供，而媒体级属性和关联值可以在媒体级或会话级的属性功能中提供。会话或媒体级别允许的属性可以在任一级别的属性功能中提供。
o Zero or more transport protocol capability attributes. There MUST be transport protocol capabilities as defined in Section 3.4.2 with values for each transport protocol that needs to be indicated as a capability in the offer.
o 零个或多个传输协议功能属性。必须具有第3.4.2节中定义的传输协议能力，每个传输协议的值需要在报价中表示为能力。
Transport protocol capabilities may be included irrespective of whether or not they are referenced by a potential configuration. Transport protocols that apply to multiple media descriptions SHOULD be provided as transport protocol capabilities at the session level whereas transport protocols that apply only to a specific media description ("m=" line), SHOULD be provided as transport protocol capabilities within that particular media description. In either case, there MUST NOT be more than a single "a=tcap" attribute at the session level and a single "a=tcap" attribute in each media description.
无论潜在配置是否引用传输协议功能，都可以包括传输协议功能。应用于多个媒体描述的传输协议应作为会话级别的传输协议功能提供，而仅应用于特定媒体描述（“m=”行）的传输协议应作为该特定媒体描述中的传输协议功能提供。在任何一种情况下，会话级别的“a=tcap”属性和每个媒体描述中的“a=tcap”属性不得超过一个。
o Zero or more extension capability attributes. There MUST be one or more extension capability attributes (as outlined in Section 3.4.3) for each extension capability that is referenced by a potential configuration. Extension capability attributes that are not referenced by a potential configuration can be provided as well.
o 零个或多个扩展功能属性。对于潜在配置引用的每个扩展能力，必须有一个或多个扩展能力属性（如第3.4.3节所述）。还可以提供潜在配置未引用的扩展能力属性。
o Zero or more potential configuration attributes. There MUST be one or more potential configuration attributes ("a=pcfg"), as defined in Section 3.5.1, in each media description where alternative potential configurations are to be negotiated. Each potential configuration attribute MUST adhere to the rules provided in Section 3.5.1 and the additional rules provided below.
o 零个或多个潜在配置属性。如第3.5.1节所定义，在需要协商备选潜在配置的每个介质描述中，必须有一个或多个潜在配置属性（“a=pcfg”）。每个潜在配置属性必须遵守第3.5.1节中提供的规则和下面提供的附加规则。
If the offerer requires support for one or more extensions (besides the base protocol defined here), then the offerer MUST include one or more "a=creq" attributes as follows:
如果报价人需要支持一个或多个扩展（除此处定义的基本协议外），则报价人必须包括一个或多个“a=creq”属性，如下所示：
o If support for one or more capability negotiation extensions is required for the entire session description, then option tags for those extensions MUST be included in a single session-level "creq" attribute.
o 如果整个会话描述需要支持一个或多个功能协商扩展，那么这些扩展的选项标记必须包含在单个会话级别的“creq”属性中。
o For each media description that requires support for one or more capability negotiation extensions not listed at the session level, a single "creq" attribute containing all the required extensions for that media description MUST be included within the media description (in accordance with Section 3.3.2).
o 对于需要支持一个或多个未在会话级别列出的功能协商扩展的每个媒体描述，必须在媒体描述中包含包含该媒体描述所需扩展的单个“creq”属性（根据第3.3.2节）。
Note that extensions that only need to be supported by a particular potential configuration can use the "mandatory" extension prefix ("+") within the potential configuration (see Section 3.5.1).
请注意，仅需要特定潜在配置支持的扩展可以在潜在配置中使用“强制”扩展前缀（“+”）（请参见第3.5.1节）。
The offerer SHOULD furthermore include the following:
报价人还应包括以下内容：
o A supported capability negotiation extension attribute ("a=csup") at the session level and/or media level as defined in Section 3.3.2 for each capability negotiation extension supported by the offerer and not included in a corresponding "a=creq" attribute (i.e., at the session level or in the same media description). Option tags provided in a "a=csup" attribute at the session level indicate extensions supported for the entire session description, whereas option tags provided in a "a=csup" attribute in a media description indicate extensions supported for only that particular media description.
o 第3.3.2节中定义的会话级和/或媒体级受支持的能力谈判扩展属性（“A=csup”），用于报价人支持的每个能力谈判扩展，但不包括在相应的“A=creq”属性中（即会话级或同一媒体描述中）。会话级别的“a=csup”属性中提供的选项标记表示整个会话描述支持的扩展，而媒体描述中的“a=csup”属性中提供的选项标记表示仅该特定媒体描述支持的扩展。
Capabilities provided in an offer merely indicate what the offerer is capable of doing. They do not constitute a commitment or even an indication to use them. In contrast, each potential configuration constitutes an alternative offer that the offerer would like to use. The potential configurations MUST be used by the answerer to negotiate and establish the session.
报价中提供的能力仅表明报价人的能力。它们并不构成使用它们的承诺或指示。相比之下，每个潜在的配置构成了发盘人希望使用的备选报价。回答者必须使用潜在配置来协商和建立会话。
The offerer MUST include one or more potential configuration attributes ("a=pcfg") in each media description where the offerer wants to provide alternative offers (in the form of potential configurations). Each potential configuration attribute in a given media description MUST contain a unique configuration number and zero, one or more potential configuration lists, as described in Section 3.5.1. Each potential configuration list MUST refer to capabilities that are provided at the session level or within that particular media description; otherwise, the potential configuration is considered invalid. The base SDP Capability Negotiation framework REQUIRES that potential configurations not reference any session-level attribute capabilities that contain media-level-only attributes; however, extensions may modify this behavior, as long as it is fully backwards compatible with the base specification. Furthermore, it is RECOMMENDED that potential configurations avoid use of session-level capabilities whenever possible; refer to Section 3.5.1.
如果报价人希望提供备选报价（以潜在配置的形式），报价人必须在每个媒体描述中包括一个或多个潜在配置属性（“a=pcfg”）。如第3.5.1节所述，给定介质描述中的每个潜在配置属性必须包含唯一的配置编号和零个、一个或多个潜在配置列表。每个潜在的配置列表必须提及会话级别或特定媒体描述中提供的功能；否则，潜在配置将被视为无效。基本SDP能力协商框架要求潜在配置不引用任何仅包含媒体级属性的会话级属性能力；但是，扩展可以修改此行为，只要它与基本规范完全向后兼容。此外，建议潜在配置尽可能避免使用会话级功能；参考第3.5.1节。
The current actual configuration is included in the "m=" line (as defined by [RFC3264]) and any associated parameters for the media description (e.g., attribute ("a=") and bandwidth ("b=") lines). Note that the actual configuration is by default the least-preferred configuration, and hence the answerer will seek to negotiate use of one of the potential configurations instead. If the offerer wishes a different preference for the actual configuration, the offerer MUST include a corresponding potential configuration with the relevant configuration number (which indicates the relative preference between potential configurations); this corresponding potential configuration should simply duplicate the actual configuration.
当前实际配置包含在“m=”行（由[RFC3264]定义）和媒体描述的任何相关参数（例如属性（“a=”）和带宽（“b=”）行）中。请注意，默认情况下，实际配置是最不首选的配置，因此应答者将寻求协商使用其中一种潜在配置。如果发盘人希望对实际配置有不同的偏好，发盘人必须包括相应的潜在配置和相关配置编号（表明潜在配置之间的相对偏好）；此对应的潜在配置应与实际配置完全相同。
This can either be done implicitly (by not referencing any capabilities), or explicitly (by providing and using capabilities for the transport protocol and all the attributes that are part of the actual configuration). The latter may help detect intermediaries that modify the actual configuration but are not SDP Capability Negotiation aware.
这可以隐式地（不引用任何功能）完成，也可以显式地（通过提供和使用传输协议的功能以及作为实际配置一部分的所有属性）完成。后者可能有助于检测修改实际配置但不支持SDP能力协商的中介。
Per [RFC3264], once the offerer generates the offer, he must be prepared to receive incoming media in accordance with that offer. That rule applies here as well, but only for the actual configurations provided in the offer: Media received by the offerer
根据[RFC3264]，一旦报价人生成报价，他必须准备好根据该报价接收传入媒体。该规则也适用于此处，但仅适用于报价中提供的实际配置：报价人收到的媒体
according to one of the potential configurations MAY be discarded, until the offerer receives an answer indicating what the actual selected configuration is. Once that answer is received, incoming media MUST be processed in accordance with the actual selected configuration indicated and the answer received (provided the offer/answer exchange completed successfully).
根据本发明，可以丢弃其中一种潜在配置，直到报价人收到指示实际选择的配置是什么的应答为止。收到应答后，必须根据指示的实际选定配置和收到的应答处理传入介质（前提是报价/应答交换成功完成）。
The above rule assumes that the offerer can determine whether incoming media adheres to the actual configuration offered or one of the potential configurations instead; this may not always be the case. If the offerer wants to ensure he does not play out any garbage, the offerer SHOULD discard all media received before the answer SDP session description is received. Conversely, if the offerer wants to avoid clipping, he SHOULD attempt to play any incoming media as soon as it is received (at the risk of playing out garbage). In either case, please note that this document does not place any requirements on the offerer to process and play media before answer. For further details, please refer to Section 3.9.
上述规则假设，发盘方可以确定传入媒体是遵循实际提供的配置，还是遵循其中一种潜在配置；情况可能并非总是如此。如果发盘人希望确保他不播放任何垃圾，发盘人应在收到应答SDP会话描述之前丢弃所有收到的媒体。相反，如果发盘人希望避免剪辑，他应该尝试在收到任何传入媒体后立即播放（冒着播放垃圾的风险）。无论哪种情况，请注意，本文件均未对报价人在回答前处理和播放媒体提出任何要求。有关更多详细信息，请参阅第3.9节。
When receiving an offer, the answerer MUST check for the presence of a required capability negotiation extension attribute ("a=creq") provided at the session level. If one is found, then capability negotiation MUST be performed. If none is found, then the answerer MUST check each offered media description for the presence of a required capability negotiation extension attribute ("a=creq") and one or more potential configuration attributes ("a=pcfg"). Capability negotiation MUST be performed for each media description where either of those is present in accordance with the procedures described below.
当收到报价时，应答者必须检查会话级别提供的所需能力协商扩展属性（“a=creq”）是否存在。如果找到一个，则必须进行能力协商。如果没有找到，则应答者必须检查每个提供的媒体描述是否存在所需的能力协商扩展属性（“a=creq”）和一个或多个潜在配置属性（“a=pcfg”）。必须根据以下所述程序，对每种介质描述（其中一种存在）进行能力协商。
The answerer MUST first ensure that it supports any required capability negotiation extensions:
应答者必须首先确保其支持任何所需的能力协商扩展：
o If a session-level "creq" attribute is provided, and it contains an option tag that the answerer does not support, then the answerer MUST NOT use any of the potential configuration attributes provided for any of the media descriptions. Instead, the normal offer/answer procedures MUST continue as per [RFC3264]. Furthermore, the answerer MUST include a session-level supported capability negotiation extensions attribute ("a=csup") with option tags for the capability negotiation extensions supported by the answerer.
o 如果提供了会话级“creq”属性，并且该属性包含应答者不支持的选项标记，则应答者不得使用为任何媒体描述提供的任何潜在配置属性。相反，必须按照[RFC3264]继续正常的报价/应答程序。此外，应答者必须包含会话级支持的能力协商扩展属性（“a=csup”），并带有应答者支持的能力协商扩展的选项标记。
o If a media-level "creq" attribute is provided, and it contains an option tag that the answerer does not support, then the answerer MUST NOT use any of the potential configuration attributes
o 如果提供了媒体级“creq”属性，并且该属性包含应答者不支持的选项标记，则应答者不得使用任何潜在的配置属性
provided for that particular media description. Instead, the offer/answer procedures for that media description MUST continue as per [RFC3264] (SDP Capability Negotiation is still performed for other media descriptions in the SDP session description). Furthermore, the answerer MUST include a supported capability negotiation extensions attribute ("a=csup") in that media description with option tags for the capability negotiation extensions supported by the answerer for that media description.
为特定的媒体描述提供。相反，该媒体描述的提供/应答过程必须按照[RFC3264]继续（SDP会话描述中的其他媒体描述仍将执行SDP能力协商）。此外，应答者必须在该媒体描述中包含受支持的能力协商扩展属性（“a=csup”），并带有应答者支持的该媒体描述的能力协商扩展的选项标签。
Assuming all required capability negotiation extensions are supported, the answerer now proceeds as follows.
假设所有必需的能力协商扩展都得到支持，应答者现在进行如下操作。
For each media description where capability negotiation is to be performed (i.e., all required capability negotiation extensions are supported and at least one valid potential configuration attribute is present), the answerer MUST perform capability negotiation by using the most preferred potential configuration that is valid to the answerer, subject to any local policies. A potential configuration is valid to the answerer if:
对于要执行能力协商的每个媒体描述（即，支持所有必需的能力协商扩展，并且至少存在一个有效的潜在配置属性），应答者必须使用对应答者有效的最首选潜在配置来执行能力协商，遵守任何当地政策。在以下情况下，潜在配置对回答者有效：
1. It is in accordance with the syntax and semantics provided in Section 3.5.1.
1. 它符合第3.5.1节中提供的语法和语义。
2. It contains a configuration number that is unique within that media description.
2. 它包含在该介质描述中唯一的配置号。
3. All attribute capabilities referenced by the potential configuration are valid themselves (as defined in Section 3.4.1) and each of them is provided either at the session level or within this particular media description.
3. 潜在配置所引用的所有属性功能本身都是有效的（如第3.4.1节所定义），并且每个属性功能都在会话级别或在该特定介质描述中提供。
For session-level attribute capabilities referenced, the attributes contained inside them MUST NOT be media-level-only attributes. Note that the answerer can only determine this for attributes supported by the answerer. If an attribute is not supported, it will simply be ignored by the answerer and hence will not trigger an "invalid" potential configuration.
对于引用的会话级属性功能，其中包含的属性不能是仅媒体级属性。请注意，应答者只能为应答者支持的属性确定这一点。如果某个属性不受支持，应答者将忽略该属性，因此不会触发“无效”的潜在配置。
4. All transport protocol capabilities referenced by the potential configuration are valid themselves (as defined in Section 3.4.2) and each of them is furthermore provided either at the session level or within this particular media description.
4. 潜在配置所引用的所有传输协议功能本身都是有效的（如第3.4.2节所定义），并且在会话级别或在该特定媒体描述中进一步提供了每个传输协议功能。
5. All extension capabilities referenced by the potential configuration and supported by the answerer are valid themselves (as defined by that particular extension) and each of them are furthermore provided either at the session level or within this particular media description. Unknown or unsupported extension
5. 由潜在配置引用并由应答者支持的所有扩展功能本身都是有效的（由该特定扩展定义），并且每个扩展功能都在会话级别或在该特定媒体描述中提供。未知或不支持的扩展名
capabilities MUST be ignored, unless they are prefixed with the plus ("+") sign, which indicates that the extension MUST be supported in order to use that potential configuration. If the extension is not supported, that potential configuration is not valid to the answerer.
必须忽略功能，除非它们的前缀带有加号（“+”），这表示必须支持扩展才能使用该潜在配置。如果不支持扩展，则该潜在配置对应答者无效。
The most preferred valid potential configuration in a media description is the valid potential configuration with the lowest configuration number. The answerer MUST now process the offer for that media stream based on the most preferred valid potential configuration. Conceptually, this entails the answerer constructing an (internal) offer as follows. First, all capability negotiation parameters from the offer SDP session description are removed, thereby yielding an offer SDP session description with the actual configuration as if SDP Capability Negotiation was not done in the first place. Secondly, this actual configuration SDP session description is modified as follows for each media stream offered, based on the capability negotiation parameters included originally:
介质描述中最首选的有效潜在配置是配置号最低的有效潜在配置。应答者现在必须根据最首选的有效潜在配置处理该媒体流的报价。从概念上讲，这需要回答者构建（内部）报价，如下所示。首先，删除要约SDP会话描述中的所有能力协商参数，从而生成具有实际配置的要约SDP会话描述，就好像当初没有进行SDP能力协商一样。其次，根据最初包含的能力协商参数，针对提供的每个媒体流，对该实际配置SDP会话描述进行如下修改：
o If a transport protocol capability is included in the potential configuration, then it replaces the transport protocol provided in the "m=" line for that media description.
o 如果潜在配置中包含传输协议功能，则它将替换“m=”行中为该介质描述提供的传输协议。
o If attribute capabilities are present with a delete-attributes session indication ("-s") or media and session indication ("-ms"), then all session-level attributes from the actual configuration SDP session description MUST be deleted in the resulting potential configuration SDP session description in accordance with the procedures in Section 3.5.1. If attribute capabilities are present with a delete-attributes media indication ("-m") or media and session indication ("-ms"), then all attributes from the actual configuration SDP session description inside this media description MUST be deleted.
o 如果属性功能带有删除属性会话指示（“-s”）或媒体和会话指示（“-ms”），然后，根据第3.5.1节中的程序，必须在生成的潜在配置SDP会话描述中删除实际配置SDP会话描述中的所有会话级属性。如果属性功能带有删除属性介质指示（“-m”）或介质和会话指示（“-ms”），则必须删除该介质描述中实际配置SDP会话描述中的所有属性。
o If a session-level attribute capability is included, the attribute (and its associated value, if any) contained in it MUST be added to the resulting SDP session description. All such added session-level attributes MUST be listed before the session-level attributes that were initially present in the SDP session description. Furthermore, the added session-level attributes MUST be added in the order they were provided in the potential configuration (see also Section 3.5.1).
o 如果包含会话级属性功能，则必须将其中包含的属性（及其关联值，如果有）添加到生成的SDP会话描述中。所有添加的会话级别属性必须列在SDP会话描述中最初出现的会话级别属性之前。此外，必须按照潜在配置中提供的顺序添加添加的会话级属性（另请参见第3.5.1节）。
This allows for attributes with implicit preference ordering to be added in the desired order; the "crypto" attribute [RFC4568] is one such example.
这允许按所需顺序添加具有隐式偏好顺序的属性；“crypto”属性[RFC4568]就是这样一个例子。
o If a media-level attribute capability is included, then the attribute (and its associated value, if any) MUST be added to the resulting SDP session description within the media description in question. All such added media-level attributes MUST be listed before the media-level attributes that were initially present in the media description in question. Furthermore, the added media-level attributes MUST be added in the order they were provided in the potential configuration (see also Section 3.5.1).
o 如果包含媒体级属性功能，则必须将该属性（及其关联值，如果有）添加到相关媒体描述中的结果SDP会话描述中。所有添加的媒体级别属性必须列在相关媒体描述中最初出现的媒体级别属性之前。此外，必须按照潜在配置中提供的顺序添加添加的媒体级属性（另请参见第3.5.1节）。
o If a supported extension capability is included, then it MUST be processed in accordance with the rules provided for that particular extension capability.
o 如果包含受支持的扩展功能，则必须根据为该特定扩展功能提供的规则对其进行处理。
The above steps MUST be performed exactly once per potential configuration, i.e., there MUST NOT be any recursive processing of any additional capability negotiation parameters that may (illegally) have been nested inside capabilities themselves.
上述步骤必须在每个潜在配置中准确执行一次，即，不得对可能（非法）嵌套在功能内部的任何附加功能协商参数进行任何递归处理。
As an example of this, consider the (illegal) attribute capability
作为一个例子，考虑（非法）属性能力。
a=acap:1 acap:2 foo:a
a=acap:1 acap:2 foo:a
The resulting potential configuration SDP session description will, after the above processing has been done, contain the attribute capability
完成上述处理后，生成的潜在配置SDP会话描述将包含属性capability
a=acap:2 foo:a
a=acap:2 foo:a
However, since we do not perform any recursive processing of capability negotiation parameters, this second attribute capability parameter will not be processed by the offer/answer procedure. Instead, it will simply appear as a (useless) attribute in the SDP session description that will be ignored by further processing.
但是，由于我们不对能力协商参数执行任何递归处理，因此第二个属性能力参数将不会由提供/应答过程处理。相反，它将在SDP会话描述中显示为一个（无用）属性，该属性将被进一步处理忽略。
Note that a transport protocol from the potential configuration replaces the transport protocol in the actual configuration, but an attribute capability from the potential configuration is simply added to the actual configuration. In some cases, this can result in having one or more meaningless attributes in the resulting potential configuration SDP session description, or worse, ambiguous or potentially even illegal attributes. Use of delete-attributes for the session- and/or media-level attributes MUST be done to avoid such scenarios. Nevertheless, it is RECOMMENDED that implementations ignore meaningless attributes that may result from potential configurations.
请注意，潜在配置中的传输协议将替换实际配置中的传输协议，但潜在配置中的属性功能仅添加到实际配置中。在某些情况下，这可能导致在生成的潜在配置SDP会话描述中具有一个或多个无意义的属性，或者更糟的是，具有模糊性甚至可能是非法的属性。必须为会话和/或媒体级属性使用删除属性，以避免此类情况。然而，建议实现忽略潜在配置可能导致的无意义属性。
For example, if the actual configuration was using Secure RTP and included an "a=crypto" attribute for the SRTP keying material, then use of a potential configuration that uses plain RTP would make the "crypto" attribute meaningless. The answerer may or may not ignore such a meaningless attribute. The offerer can here ensure correct operation by using delete-attributes to remove the "crypto" attribute (but will then need to provide attribute capabilities to reconstruct the SDP session description with the necessary attributes deleted, e.g., rtpmaps).
例如，如果实际配置使用安全RTP，并且SRTP密钥材料包含“a=crypto”属性，那么使用普通RTP的潜在配置将使“crypto”属性变得毫无意义。回答者可能会也可能不会忽略这种无意义的属性。在此，报价人可通过使用删除属性删除“加密”属性来确保正确操作（但随后需要提供属性功能，以使用删除的必要属性（例如RTPMAP）重建SDP会话描述）。
Also note, that while it is permissible to include media-level attribute capabilities at the session level, the base SDP Capability Negotiation framework defined here does not define any procedures for use of them, i.e., the answerer effectively ignores them.
还请注意，虽然允许在会话级别包括媒体级属性功能，但此处定义的基本SDP能力协商框架并未定义使用这些功能的任何程序，即应答者实际上忽略了这些功能。
Please refer to Section 3.6.2.1 for examples of how the answerer may conceptually "see" the resulting offered alternative potential configurations.
请参考第3.6.2.1节，了解应答者如何在概念上“看到”所提供的备选潜在配置。
The answerer MUST check that he supports all mandatory attribute capabilities from the potential configuration (if any), the transport protocol capability (if any) from the potential configuration, and all mandatory extension capabilities from the potential configuration (if any). If he does not, the answerer MUST proceed to the second most preferred valid potential configuration for the media description, etc.
应答者必须检查其是否支持潜在配置（如有）中的所有强制性属性功能、潜在配置中的传输协议功能（如有）以及潜在配置（如有）中的所有强制性扩展功能。如果回答者没有回答，则必须对媒体描述等进行第二个最首选的有效潜在配置。
o In the case of attribute capabilities, support implies that the attribute name contained in the capability is supported and it can (and will) be negotiated successfully in the offer/answer exchange with the value provided. This does not necessarily imply that the value provided is supported in its entirety. For example, the "a=fmtp" parameter is often provided with one or more values in a list, where the offerer and answerer negotiate use of some subset of the values provided. Other attributes may include mandatory and optional parts to their values; support for the mandatory part is all that is required here.
o 对于属性功能，支持意味着支持该功能中包含的属性名称，并且可以（并且将）在提供/应答交换中使用提供的值成功地协商该属性名称。这并不一定意味着所提供的价值全部得到支持。例如，“a=fmtp”参数通常在列表中提供一个或多个值，其中报价人和应答人协商使用所提供值的某些子集。其他属性可能包括其值的强制性和可选部分；这里只需要支持强制性部分。
A side effect of the above rule is that whenever an "fmtp" or "rtpmap" parameter is provided as a mandatory attribute capability, the corresponding media format (codec) must be supported and use of it negotiated successfully. If this is not the offerer's intent, the corresponding attribute capabilities must be listed as optional instead.
上述规则的一个副作用是，每当“fmtp”或“rtpmap”参数作为强制属性功能提供时，必须支持相应的媒体格式（编解码器），并成功协商使用它。如果这不是报价人的意图，则相应的属性能力必须列为可选。
o In the case of transport protocol capabilities, support implies that the transport protocol contained in the capability is supported and the transport protocol can (and will) be negotiated successfully in the offer/answer exchange.
o 对于传输协议功能，支持意味着支持该功能中包含的传输协议，并且传输协议可以（并且将）在提供/应答交换中成功协商。
o In the case of extension capabilities, the extension MUST define the rules for when the extension capability is considered supported and those rules MUST be satisfied.
o 在扩展能力的情况下，扩展必须定义当扩展能力被认为是受支持的并且必须满足这些规则时的规则。
If the answerer has exhausted all potential configurations for the media description, without finding a valid one that is also supported, then the answerer MUST process the offered media stream based on the actual configuration plus any session-level attributes added by a valid and supported potential configuration from another media description in the offered SDP session description.
如果应答者已用尽媒体描述的所有可能配置，但未找到同样受支持的有效配置，然后，应答者必须根据实际配置加上由有效且受支持的潜在配置从提供的SDP会话描述中的另一个媒体描述添加的任何会话级属性来处理提供的媒体流。
The above process describes potential configuration selection as a per-media-stream process. Inter-media stream coordination of selected potential configurations however is required in some cases. First of all, session-level attributes added by a potential configuration for one media description MUST NOT cause any problems for potential configurations selected by other media descriptions in the offer SDP session description. If the session-level attributes are mandatory, then those session-level attributes MUST furthermore be supported by the session as a whole (i.e., all the media descriptions if relevant). As mentioned earlier, this adds additional complexity to the overall processing and hence it is RECOMMENDED not to use session-level attribute capabilities in potential configurations, unless absolutely necessary.
上述过程将潜在的配置选择描述为每个媒体流过程。但是，在某些情况下，需要对选定的潜在配置进行媒体间流协调。首先，由一个媒体描述的潜在配置添加的会话级属性不得对在offer SDP会话描述中由其他媒体描述选择的潜在配置造成任何问题。如果会话级别属性是强制性的，那么这些会话级别属性还必须得到整个会话的支持（即，所有媒体描述，如果相关）。如前所述，这增加了整体处理的复杂性，因此建议不要在潜在配置中使用会话级属性功能，除非绝对必要。
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 virtual answer SDP session description based on the selected potential configuration SDP session description, as "seen" by the answerer using normal offer/answer rules (see Section 3.6.2.1 for examples). The actual answer SDP session description is formed from the virtual answer SDP session description as follows: if the answerer selected one of the potential configurations in a media description, the answerer MUST include an actual configuration attribute ("a=acfg") within that media description. The "a=acfg" attribute MUST identify the configuration number for the selected potential configuration as well as the actual parameters that were used from that potential configuration; if the potential configuration included alternatives, the selected alternatives only MUST be included. Only the known and supported parameters will be included. Unknown or unsupported parameters MUST NOT be included in the actual configuration attribute. In the case
一旦应答者为所有媒体流选择了有效且受支持的提供的潜在配置（或已退回到实际配置加上任何添加的会话属性），应答者必须根据所选的潜在配置SDP会话描述生成有效的虚拟应答SDP会话描述，如下所示：由应答者使用正常的报价/应答规则“看到”（示例见第3.6.2.1节）。实际应答SDP会话描述由虚拟应答SDP会话描述构成，如下所示：如果应答者在媒体描述中选择了一种潜在配置，应答者必须包括一个实际配置属性（“a=acfg“）在该介质描述中。a=acfg“属性必须标识所选潜在配置的配置号以及该潜在配置中使用的实际参数；如果潜在配置包括备选方案，则必须仅包括选定的备选方案。仅包含已知和支持的参数。实际配置属性中不得包含未知或不受支持的参数。在这种情况下
of attribute capabilities, only the known and supported capabilities are included; unknown or unsupported attribute capabilities MUST NOT be included.
对于属性能力，仅包括已知和支持的能力；不能包括未知或不受支持的属性功能。
If the answerer supports one or more capability negotiation extensions that were not included in a required capability negotiation extensions attribute in the offer, then the answerer SHOULD furthermore include a supported capability negotiation attribute ("a=csup") at the session level with option tags for the extensions supported across media streams. Also, if the answerer supports one or more capability negotiation extensions for only particular media descriptions, then a supported capability negotiation attribute with those option tags SHOULD be included within each relevant media description. The required capability negotiation attribute ("a=creq") MUST NOT be used in an answer.
如果应答者支持一个或多个未包含在报价中所需能力协商扩展属性中的能力协商扩展，则应答者还应包括一个受支持的能力协商属性（“a=csup”）在会话级别，使用跨媒体流支持的扩展的选项标记。此外，如果应答者仅支持特定媒体描述的一个或多个能力协商扩展，则每个相关媒体描述中应包含带有这些选项标记的受支持能力协商属性。回答中不得使用所需的能力协商属性（“a=creq”）。
The offerer's originally provided actual configuration is contained in the offer media description's "m=" line (and associated parameters). The answerer MAY send media to the offerer in accordance with that actual configuration as soon as it receives the offer; however, it MUST NOT send media based on that actual configuration if it selects an alternative potential configuration. If the answerer selects one of the potential configurations, then the answerer MAY immediately start to send media to the offerer in accordance with the selected potential configuration; however, the offerer MAY discard such media or play out garbage until the offerer receives the answer. Please refer to Section 3.9. for additional considerations and possible alternative solutions outside the base SDP Capability Negotiation framework.
报价人最初提供的实际配置包含在报价媒体描述的“m=”行（以及相关参数）中。应答人在收到报价后，可根据实际配置向报价人发送媒体；但是，如果选择了其他可能的配置，则不得基于该实际配置发送媒体。如果应答者选择其中一种潜在配置，则应答者可根据所选潜在配置立即开始向报价者发送媒体；但是，在发盘人收到答复之前，发盘人可以丢弃此类媒体或播放垃圾。请参阅第3.9节。了解基本SDP能力协商框架之外的其他注意事项和可能的替代解决方案。
If the answerer selected a potential configuration instead of the actual configuration, then it is RECOMMENDED that the answerer send back an answer SDP session description as soon as possible. This minimizes the risk of having media discarded or played out as garbage by the offerer. In the case of SIP [RFC3261] without any extensions, this implies that if the offer was received in an INVITE message, then the answer SDP session description should be provided in the first non-100 provisional response sent back (per RFC 3261, the answer would need to be repeated in the 200 response as well, unless a relevant extension such as [RFC3262] is being used).
如果应答者选择了潜在配置而不是实际配置，则建议应答者尽快发回应答SDP会话描述。这最大限度地降低了媒体被丢弃或被提供方当作垃圾播放的风险。在没有任何扩展的SIP[RFC3261]情况下，这意味着如果在INVITE消息中接收到要约，则应答SDP会话描述应在发送回的第一个非100临时响应中提供（根据RFC 3261，应答也需要在200响应中重复，除非相关扩展如[RFC3262]正在使用中）。
The following examples illustrate how the answerer may conceptually "see" a potential configuration. Consider the following offered SDP session description:
以下示例说明了应答者如何在概念上“看到”潜在配置。考虑以下提供的SDP会话描述：
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=tool:foo
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tcap:1 RTP/SAVP RTP/AVP
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1|2
m=video 52000 RTP/AVP 31
a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=pcfg:1 t=1 a=1|3
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=tool:foo
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tcap:1 RTP/SAVP RTP/AVP
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1|2
m=video 52000 RTP/AVP 31
a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=pcfg:1 t=1 a=1|3
This particular SDP session description offers an audio stream and a video stream, each of which can either use plain RTP (actual configuration) or Secure RTP (potential configuration). Furthermore, two different keying mechanisms are offered, namely session-level Key Management Extensions using MIKEY (attribute capability 1) and media-level SDP security descriptions (attribute capabilities 2 and 3). There are several potential configurations here, however, below we show the one the answerer "sees" when using potential configuration 1 for both audio and video, and furthermore using attribute capability 1 (MIKEY) for both (we have removed all the capability negotiation attributes for clarity):
此特定SDP会话描述提供音频流和视频流，每个音频流和视频流可以使用普通RTP（实际配置）或安全RTP（潜在配置）。此外，还提供了两种不同的密钥机制，即使用MIKEY的会话级密钥管理扩展（属性功能1）和媒体级SDP安全描述（属性功能2和3）。这里有几个潜在的配置，但是，下面我们展示了应答者在音频和视频使用潜在配置1时“看到”的配置，并且在音频和视频使用属性能力1（MIKEY）时（为了清晰起见，我们删除了所有能力协商属性）：
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=tool:foo
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=tool:foo
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000
Note that the transport protocol in the media descriptions indicate use of Secure RTP.
请注意，媒体描述中的传输协议表示使用安全RTP。
Below, we show the offer the answerer "sees" when using potential configuration 1 for both audio and video and furthermore using attribute capability 2 and 3, respectively, (SDP security descriptions) for the audio and video stream -- note the order in which the resulting attributes are provided:
下面，我们展示了应答者在为音频和视频使用潜在配置1，并进一步为音频和视频流分别使用属性功能2和3（SDP安全描述）时“看到”的报价——请注意结果属性的提供顺序：
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=tool:foo
m=audio 59000 RTP/SAVP 98
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=rtpmap:98 AMR/8000
m=video 52000 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtpmap:31 H261/90000
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=tool:foo
m=audio 59000 RTP/SAVP 98
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=rtpmap:98 AMR/8000
m=video 52000 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtpmap:31 H261/90000
Again, note that the transport protocol in the media descriptions indicate use of Secure RTP.
再次注意，媒体描述中的传输协议指示使用安全RTP。
And finally, we show the offer the answerer "sees" when using potential configuration 1 with attribute capability 1 (MIKEY) for the audio stream, and potential configuration 1 with attribute capability 3 (SDP security descriptions) for the video stream:
最后，我们展示了应答者在音频流使用具有属性能力1（MIKEY）的潜在配置1，以及视频流使用具有属性能力3（SDP安全描述）的潜在配置1时“看到”的报价：
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tool:foo
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52000 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtpmap:31 H261/90000
v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=
t=0 0
c=IN IP4 lost.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tool:foo
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52000 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtpmap:31 H261/90000
When the offerer attempted to use SDP Capability Negotiation in the offer, the offerer MUST examine the answer for actual use of SDP Capability Negotiation.
当报价人试图在报价中使用SDP能力协商时，报价人必须检查SDP能力协商的实际使用答案。
For each media description where the offerer included a potential configuration attribute ("a=pcfg"), the offerer MUST first examine that media description for the presence of a valid actual configuration attribute ("a=acfg"). An actual configuration attribute is valid if:
对于报价人包含潜在配置属性（“a=pcfg”）的每个媒体描述，报价人必须首先检查该媒体描述是否存在有效的实际配置属性（“a=acfg”）。如果满足以下条件，则实际配置属性有效：
o it refers to a potential configuration that was present in the corresponding offer, and
o 它是指相应报价中存在的潜在配置，以及
o it contains the actual parameters that were used from that potential configuration; if the potential configuration included alternatives, the selected alternatives only MUST be included. Note that the answer will include only parameters and attribute capabilities that are known and supported by the answerer, as described in Section 3.6.2.
o 它包含从该潜在配置使用的实际参数；如果潜在配置包括备选方案，则必须仅包括选定的备选方案。请注意，答案仅包括回答者已知并支持的参数和属性功能，如第3.6.2节所述。
If a valid actual configuration attribute is not present in a media description, then the offerer MUST process the answer SDP session description for that media stream per the normal offer/answer rules defined in [RFC3264]. However, if a valid one is found, the offerer MUST instead process the answer as follows:
如果媒体描述中不存在有效的实际配置属性，则报价人必须按照[RFC3264]中定义的正常报价/应答规则处理该媒体流的应答SDP会话描述。但是，如果找到有效答案，报价人必须按照以下方式处理答案：
o The actual configuration attribute specifies which of the potential configurations was used by the answerer to generate the answer for this media stream. This includes all the supported attribute capabilities and the transport capabilities referenced by the potential configuration selected, where the attribute capabilities have any associated delete-attributes included. Extension capabilities supported by the answerer are included as well.
o “实际配置”属性指定应答者使用哪些潜在配置来生成此媒体流的应答。这包括所有受支持的属性功能和所选潜在配置引用的传输功能，其中属性功能包含任何关联的删除属性。还包括应答者支持的扩展功能。
o The offerer MUST now process the answer in accordance with the rules in [RFC3264], except that it must be done as if the offer consisted of the selected potential configuration instead of the original actual configuration, including any transport protocol changes in the media ("m=") line(s), attributes added and deleted by the potential configuration at the media and session level, and any extensions used. If this derived answer is not a valid answer to the potential configuration offer selected by the answerer, the offerer MUST instead continue further processing as it would have for a regular offer/answer exchange, where the answer received does not adhere to the rules of [RFC3264].
o 报价人现在必须按照[RFC3264]中的规则处理答案，但必须按照所选潜在配置而非原始实际配置（包括媒体（“m=”）行中的任何传输协议更改）进行处理，由媒体和会话级别的潜在配置添加和删除的属性，以及使用的任何扩展。如果此衍生答案不是应答者选择的潜在配置报价的有效答案，则报价者必须继续进行进一步处理，因为在收到的答案不符合[RFC3264]规则的情况下，它将进行常规报价/应答交换。
If the offer/answer exchange was successful, and if the answerer selected one of the potential configurations from the offer as the actual configuration, and the selected potential configuration differs from the actual configuration in the offer (the "m=", "a=", etc., lines), then the offerer SHOULD initiate another offer/answer exchange. This second offer/answer exchange will not modify the session in any way; however, it will help intermediaries (e.g., middleboxes), which look at the SDP session description but do not support the capability negotiation extensions, understand the details of the media stream(s) that were actually negotiated. This new offer MUST contain the selected potential configuration as the actual configuration, i.e., with the actual configuration used in the "m=" line and any other relevant attributes, bandwidth parameters, etc.
如果要约/应答交换成功，并且如果应答者从要约中选择一个潜在配置作为实际配置，并且所选潜在配置与要约中的实际配置不同（“m=”、“a=”等行），则要约者应发起另一个要约/应答交换。第二次报价/应答交换不会以任何方式修改会话；但是，它将帮助查看SDP会话描述但不支持能力协商扩展的中介机构（如中间商）了解实际协商的媒体流的详细信息。此新报价必须包含选定的潜在配置作为实际配置，即“m=”行中使用的实际配置以及任何其他相关属性、带宽参数等。
Note that, per normal offer/answer rules, the second offer/answer exchange still needs to update the version number in the "o=" line (<sess-version> in [RFC4566]). Attribute lines carrying keying material SHOULD repeat the keys from the previous offer, unless re-keying is necessary, e.g., due to a previously forked SIP INVITE request. Please refer to Section 3.12 for additional considerations related to intermediaries.
注意，根据正常的报价/应答规则，第二次报价/应答交换仍然需要更新[RFC4566]中“o=”行（<sess version>）中的版本号。携带键控材料的属性行应重复先前提供的键，除非需要重新键控，例如，由于先前分叉的SIP INVITE请求。有关中介机构的其他注意事项，请参考第3.12节。
Capabilities and potential configurations may be included in subsequent offers as defined in [RFC3264], Section 8. The procedure for doing so is similar to that described above with the answer including an indication of the actual selected configuration used by the answerer.
按照[RFC3264]第8节的规定，后续报价中可能包含功能和潜在配置。这样做的程序与上述程序类似，答案包括回答者使用的实际选定配置的指示。
If the answer indicates use of a potential configuration from the offer, then the guidelines provided in Section 3.6.3 for doing a second offer/answer exchange using that potential configuration as the actual configuration apply.
如果回答表明使用了报价中的潜在配置，则第3.6.3节提供的指南适用于使用该潜在配置作为实际配置进行第二次报价/应答交换。
Interactive Connectivity Establishment (ICE) [RFC5245] provides a mechanism for verifying connectivity between two endpoints by sending Session Traversal Utilities for NAT (STUN) messages directly between the media endpoints. The basic ICE specification [RFC5245] is only defined to support UDP-based connectivity; however, it allows for extensions to support other transport protocols, such as TCP, which is being specified in [ICETCP]. ICE defines a new "a=candidate" attribute, which, among other things, indicates the possible transport protocol(s) to use and then associates a priority with each of them. The most preferred transport protocol that *successfully* verifies connectivity will end up being used.
交互式连接建立（ICE）[RFC5245]通过在媒体端点之间直接发送NAT（STUN）消息的会话遍历实用程序，为验证两个端点之间的连接提供了一种机制。基本ICE规范[RFC5245]仅定义为支持基于UDP的连接；但是，它允许扩展以支持其他传输协议，如[ICETCP]中指定的TCP。ICE定义了一个新的“a=candidate”属性，除其他外，该属性指示可能要使用的传输协议，然后将优先级与每个协议关联。最后将使用*成功*验证连接的最首选传输协议。
When using ICE, it is thus possible that the transport protocol that will be used differs from what is specified in the "m=" line. Since both ICE and SDP Capability Negotiation may specify alternative transport protocols, there is a potentially unintended interaction when using these together.
因此，在使用ICE时，将使用的传输协议可能与“m=”行中指定的不同。由于ICE和SDP能力协商都可能指定替代传输协议，因此在一起使用这些协议时，可能存在潜在的非预期交互。
We provide the following guidelines for addressing that.
我们提供以下准则来解决这一问题。
There are two basic scenarios to consider:
有两种基本情况需要考虑：
1) A particular media stream can run over different transport protocols (e.g., UDP, TCP, or TCP/TLS), and the intent is simply to use the one that works (in the preference order specified).
1) 特定的媒体流可以在不同的传输协议（例如UDP、TCP或TCP/TLS）上运行，目的只是使用有效的传输协议（按照指定的优先顺序）。
2) A particular media stream can run over different transport protocols (e.g., UDP, TCP, or TCP/TLS) and the intent is to have the negotiation process decide which one to use (e.g., T.38 over TCP or UDP).
2) 特定媒体流可以在不同的传输协议（如UDP、TCP或TCP/TLS）上运行，目的是让协商过程决定使用哪一种协议（如TCP或UDP上的T.38）。
In scenario 1, there should be ICE "a=candidate" attributes for UDP, TCP, etc., but otherwise nothing special in the potential configuration attributes to indicate the desire to use different transport protocols (e.g., UDP, or TCP). The ICE procedures essentially cover the capability negotiation required (by having the answerer select something it supports and then use of trial and error connectivity checks).
在场景1中，UDP、TCP等应该有ICE“a=candidate”属性，但在潜在的配置属性中没有特别的属性来表示希望使用不同的传输协议（例如UDP或TCP）。ICE程序基本上涵盖了所需的能力协商（通过让应答者选择其支持的内容，然后使用试错连接检查）。
Scenario 2 does not require a need to support or use ICE. Instead, we simply use transport protocol capabilities and potential configuration attributes to indicate the desired outcome.
场景2不需要支持或使用ICE。相反，我们只需使用传输协议功能和潜在的配置属性来指示所需的结果。
The scenarios may be combined, e.g., by offering potential configuration alternatives where some of them can support only one transport protocol (e.g., UDP), whereas others can support multiple transport protocols (e.g., UDP or TCP). In that case, there is a need for tight control over the ICE candidates that will be used for a particular configuration, yet the actual configuration may want to use all of the ICE candidates. In that case, the ICE candidate attributes can be defined as attribute capabilities and the relevant ones should then be included in the proper potential configurations (for example, candidate attributes for UDP only for potential configurations that are restricted to UDP, whereas there could be candidate attributes for UDP, TCP, and TCP/TLS for potential configurations that can use all three). Furthermore, use of the delete-attributes in a potential configuration can be used to ensure that ICE will not end up using a transport protocol that is not desired for a particular configuration.
可以组合这些场景，例如，通过提供潜在的配置备选方案，其中一些场景只能支持一个传输协议（例如UDP），而另一些场景可以支持多个传输协议（例如UDP或TCP）。在这种情况下，需要对将用于特定配置的候选ICE进行严格控制，但实际配置可能希望使用所有候选ICE。在这种情况下，ICE候选属性可定义为属性能力，相关属性应包含在适当的潜在配置中（例如，UDP的候选属性仅适用于限制为UDP的潜在配置，而UDP、TCP和TCP/TLS的候选属性适用于可以同时使用这三种配置的潜在配置）。此外，在潜在配置中使用删除属性可确保ICE不会使用特定配置不需要的传输协议。
SDP Capability Negotiation recommends use of a second offer/answer exchange when the negotiated actual configuration was one of the potential configurations from the offer (see Section 3.6.3). Similarly, ICE requires use of a second offer/answer exchange if the chosen candidate is not the same as the one in the m/c-line from the offer. When ICE and capability negotiation are used at the same time, the two secondary offer/answer exchanges SHOULD be combined to a single one.
SDP能力协商建议，当协商的实际配置是报价中的潜在配置之一时，使用第二次报价/应答交换（见第3.6.3节）。同样，如果所选候选人与录取通知书m/c行中的候选人不同，ICE要求使用第二次录取/应答交换。当ICE和能力协商同时使用时，两个二级报价/应答交换应合并为一个。
SIP [RFC3261] allows for SIP extensions to define a SIP option tag that identifies the SIP extension. Support for one or more such extensions can be indicated by use of the SIP Supported header, and required support for one or more such extensions can be indicated by use of the SIP Require header. The "a=csup" and "a=creq" attributes defined by the SDP Capability Negotiation framework are similar, except that support for these two attributes by themselves cannot be guaranteed (since they are specified as extensions to the SDP specification [RFC4566] itself).
SIP[RFC3261]允许SIP扩展定义标识SIP扩展的SIP选项标记。对一个或多个这样的扩展的支持可以通过使用SIP-Supported报头来指示，并且对一个或多个这样的扩展的所需支持可以通过使用SIP-Require报头来指示。SDP能力协商框架定义的“a=csup”和“a=creq”属性类似，只是无法保证对这两个属性本身的支持（因为它们被指定为SDP规范[RFC4566]本身的扩展）。
SIP extensions with associated option tags can introduce enhancements to not only SIP, but also SDP. This is for example the case for SIP preconditions defined in [RFC3312]. When using SDP Capability Negotiation, some potential configurations may include certain SDP extensions, whereas others may not. Since the purpose of the SDP Capability Negotiation is to negotiate a session based on the features supported by both sides, use of the SIP Require header for such extensions may not produce the desired result. For example, if one potential configuration requires SIP preconditions support, another does not, and the answerer does not support preconditions, then use of the SIP Require header for preconditions would result in a session failure, in spite of the fact that a valid and supported potential configuration was included in the offer.
带有相关选项标记的SIP扩展不仅可以对SIP，还可以对SDP进行增强。例如，[RFC3312]中定义的SIP先决条件就是这种情况。使用SDP能力协商时，某些潜在配置可能包括某些SDP扩展，而其他可能不包括。由于SDP能力协商的目的是基于双方支持的特性协商会话，因此对此类扩展使用SIP Require报头可能不会产生期望的结果。例如，如果一个潜在配置需要SIP预条件支持，而另一个不需要，并且应答者不支持预条件，那么将SIP Require头用于预条件将导致会话失败，尽管报价中包含有效且受支持的潜在配置。
In general, this can be alleviated by use of mandatory and optional attribute capabilities in a potential configuration. There are however cases where permissible SDP values are tied to the use of the SIP Require header. SIP preconditions [RFC3312] is one such example, where preconditions with a "mandatory" strength-tag can only be used when a SIP Require header with the SIP option tag "precondition" is included. Future SIP extensions that may want to use the SDP Capability Negotiation framework should avoid such coupling.
通常，通过在潜在配置中使用强制和可选属性功能，可以缓解这一问题。然而，在某些情况下，允许的SDP值与SIP Require头的使用相关联。SIP预条件[RFC3312]就是这样一个例子，其中，只有在包含SIP选项标记“Premission”的SIP Require头时，才能使用带有“强制”强度标记的预条件。未来可能希望使用SDP能力协商框架的SIP扩展应该避免这种耦合。
The offer/answer model [RFC3264] requires an offerer to be able to receive media in accordance with the offer prior to receiving the answer. This property is retained with the SDP Capability Negotiation extensions defined here, but only when the actual configuration is selected by the answerer. If a potential configuration is chosen, the offerer may decide not to process any media received before the answer is received. This may lead to clipping. Consequently, the SDP Capability Negotiation framework recommends sending back an answer SDP session description as soon as possible.
报价/应答模型[RFC3264]要求报价人在收到应答之前能够根据报价接收媒体。此属性与此处定义的SDP能力协商扩展一起保留，但仅当应答者选择了实际配置时才保留。如果选择了可能的配置，则报价人可决定在收到答复之前不处理收到的任何媒体。这可能会导致剪切。因此，SDP能力协商框架建议尽快发回应答SDP会话描述。
The issue can be resolved by introducing a three-way handshake. In the case of SIP, this can, for example, be done by defining a precondition [RFC3312] for capability negotiation (or by using an existing precondition that is known to generate a second offer/answer exchange before proceeding with the session). However, preconditions are often viewed as complicated to implement and they may add to overall session establishment delay by requiring an extra offer/answer exchange.
这个问题可以通过引入三方握手来解决。在SIP的情况下，例如，可以通过定义能力协商的先决条件[RFC3312]来实现（或者通过使用已知的在继续会话之前生成第二个提供/应答交换的现有先决条件）。然而，前提条件通常被视为难以实现，它们可能会通过要求额外的提供/应答交换而增加整个会话建立延迟。
An alternative three-way handshake can be performed by use of ICE [RFC5245]. When ICE is being used, and the answerer receives a STUN Binding Request for any one of the accepted media streams from the offerer, the answerer knows the offer has received his answer. At that point, the answerer knows that the offerer will be able to process incoming media according to the negotiated configuration and hence he can start sending media without the risk of the offerer either discarding it or playing garbage.
可使用ICE[RFC5245]执行替代的三向握手。当ICE被使用时，应答者收到来自发盘者的任何一个已接受媒体流的晕眩绑定请求，应答者知道发盘已收到他的答复。在这一点上，应答者知道，发盘者将能够根据协商的配置处理传入的媒体，因此他可以开始发送媒体，而不必担心发盘者丢弃媒体或播放垃圾。
Please note that, the above considerations notwithstanding, this document does not place any requirements on the offerer to process and play media before answer; it merely provides recommendations for how to ensure that media sent by the answerer and received by the offerer prior to receiving the answer can in fact be rendered by the offerer.
请注意，尽管有上述考虑，本文件并未对报价人在回答前处理和播放媒体提出任何要求；它仅仅提供了如何确保答疑人发送的媒体以及发盘人在收到答复之前收到的媒体实际上可以由发盘人提供的建议。
In some use cases, a three-way handshake is not needed. An example is when the offerer does not need information from the answer, such as keying material in the SDP session description, in order to process incoming media. The SDP Capability Negotiation framework does not define any such solutions; however, extensions may do so. For example, one technique proposed for best-effort SRTP in [BESRTP] is to provide different RTP payload type mappings for different transport protocols used, outside of the actual configuration, while still allowing them to be used by the answerer (exchange of keying
在某些用例中，不需要三方握手。例如，当报价人不需要来自答案的信息（例如SDP会话描述中的键入材料）来处理传入媒体时。SDP能力谈判框架未定义任何此类解决方案；但是，扩展可能会这样做。例如，[BESRTP]中为尽力而为的SRTP提出的一种技术是，在实际配置之外，为所使用的不同传输协议提供不同的RTP有效负载类型映射，同时仍然允许应答者使用它们（密钥交换）
material is still needed, e.g., inband). The basic SDP Capability Negotiation framework defined here does not include the ability to do so; however, extensions that enable that may be defined.
仍然需要材料，例如带内）。此处定义的基本SDP能力协商框架不包括这样做的能力；但是，可以定义启用该功能的扩展。
The amount of bandwidth used for a particular media stream depends on the negotiated codecs, transport protocol and other parameters. For example the use of Secure RTP [RFC3711] with integrity protection requires more bandwidth than plain RTP [RFC3551]. SDP defines the bandwidth ("b=") parameter to indicate the proposed bandwidth for the session or media stream.
用于特定媒体流的带宽量取决于协商的编解码器、传输协议和其他参数。例如，使用具有完整性保护的安全RTP[RFC3711]比普通RTP[RFC3551]需要更多带宽。SDP定义带宽（“b=”）参数，以指示会话或媒体流的建议带宽。
In SDP, as defined by [RFC4566], each media description contains one transport protocol and one or more codecs. When specifying the proposed bandwidth, the worst case scenario must be taken into account, i.e., use of the highest bandwidth codec provided, the transport protocol indicated, and the worst case (bandwidth-wise) parameters that can be negotiated (e.g., a 32-bit Hashed Message Authentication Code (HMAC) or an 80-bit HMAC).
在SDP中，如[RFC4566]所定义，每个媒体描述包含一个传输协议和一个或多个编解码器。在指定建议的带宽时，必须考虑最坏情况，即使用提供的最高带宽编解码器、指示的传输协议以及可协商的最坏情况（带宽方面）参数（例如，32位哈希消息认证码（HMAC）或80位HMAC）。
The base SDP Capability Negotiation framework does not provide a way to negotiate bandwidth parameters. The issue thus remains; however, it is potentially worse than with SDP per [RFC4566], since it is easier to negotiate additional codecs, and furthermore possible to negotiate different transport protocols. The recommended approach for addressing this is the same as for plain SDP; the worst case (now including potential configurations) needs to be taken into account when specifying the bandwidth parameters in the actual configuration. This can make the bandwidth value less accurate than in SDP per [RFC4566] (due to potential greater variability in the potential configuration bandwidth use). Extensions can be defined to address this shortcoming.
基本SDP能力协商框架不提供协商带宽参数的方法。因此，问题仍然存在；然而，这可能比SDP per[RFC4566]更糟糕，因为协商其他编解码器更容易，而且还可能协商不同的传输协议。解决这一问题的建议方法与普通SDP相同；在实际配置中指定带宽参数时，需要考虑最坏的情况（现在包括潜在的配置）。这会使带宽值低于SDP per[RFC4566]中的准确度（由于潜在配置带宽使用的潜在更大可变性）。可以定义扩展来解决这个缺点。
Note, that when using RTP retransmission [RFC4588] with the RTCP-based feedback profile [RFC4585] (RTP/AVPF), the retransmitted packets are part of the media stream bandwidth when using synchronization source (SSRC) multiplexing. If a feedback-based protocol is offered as the actual configuration transport protocol, a non-feedback-based protocol is offered as a potential configuration transport protocol and ends up being used, the actual bandwidth usage may be lower than the indicated bandwidth value in the offer (and vice versa).
注意，当使用RTP重传[RFC4588]和基于RTCP的反馈配置文件[RFC4585]（RTP/AVPF）时，当使用同步源（SSRC）复用时，重传的分组是媒体流带宽的一部分。如果提供基于反馈的协议作为实际配置传输协议，则提供基于非反馈的协议作为潜在的配置传输协议并最终被使用，则实际带宽使用可能低于提供中指示的带宽值（反之亦然）。
When using the SDP Capability Negotiation, it is easy to generate offers that contain a large number of potential configurations. For example, in the offer:
使用SDP能力协商时，很容易生成包含大量潜在配置的报价。例如，在报价中：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=acap:2 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=acap:3 rtcp-fb:0 nack
a=pcfg:1 t=1 a=1,3|2,3
a=pcfg:2 t=2 a=1|2
a=pcfg:3 t=3 a=3
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=acap:2 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=acap:3 rtcp-fb:0 nack
a=pcfg:1 t=1 a=1,3|2,3
a=pcfg:2 t=2 a=1|2
a=pcfg:3 t=3 a=3
we have 5 potential configurations on top of the actual configuration for a single media stream. Adding an extension capability with just two alternatives for each would double that number (to 10), and doing the equivalent with two media streams would again double that number (to 20). While it is easy (and inexpensive) for the offerer to generate such offers, processing them at the answering side may not be. Consequently, it is RECOMMENDED that offerers do not create offers with unnecessarily large number of potential configurations in them.
在单个媒体流的实际配置之上，我们有5种可能的配置。添加一个扩展功能，每个扩展功能只包含两个备选方案，这将使该数字翻倍（达到10），而使用两个媒体流进行等效操作将使该数字再次翻倍（达到20）。虽然报价人很容易（而且价格低廉）生成此类报价，但在应答方处理这些报价可能并不容易。因此，建议报价人不要创建包含不必要的大量潜在配置的报价。
On the answering side, implementers MUST take care to avoid excessive memory and CPU consumption. For example, a naive implementation that first generates all the valid potential configuration SDP session descriptions internally, could find itself being memory exhausted, especially if it supports a large number of endpoints. Similarly, a naive implementation that simply performs iterative trial-and-error processing on each possible potential configuration SDP session description (in the preference order specified) could find itself being CPU constrained. An alternative strategy is to prune the search space first by discarding the set of offered potential configurations where the transport protocol indicated (if any) is not supported, and/or one or more mandatory attribute capabilities (if any) are either not supported or not valid. Potential configurations with unsupported mandatory extension configurations in them can be discarded as well.
在回答方面，实现者必须注意避免过多的内存和CPU消耗。例如，一个简单的实现首先在内部生成所有有效的潜在配置SDP会话描述，可能会发现自己内存耗尽，特别是在它支持大量端点的情况下。类似地，简单地对每个可能的配置SDP会话描述（按照指定的优先顺序）执行迭代试错处理的简单实现可能会发现自己受到CPU约束。另一种策略是，首先通过丢弃所提供的一组潜在配置来修剪搜索空间，其中所示的传输协议（如果有）不受支持，和/或一个或多个强制属性功能（如果有）不受支持或无效。也可以放弃包含不受支持的强制扩展配置的潜在配置。
An intermediary is here defined as an entity between a SIP user agent A and a SIP user agent B, that needs to perform some kind of processing on the SDP session descriptions exchanged between A and B, in order for the session establishment to operate as intended. Examples of such intermediaries include Session Border Controllers (SBCs) that may perform media relaying, Proxy Call Session Control Functions (P-CSCFs) that may authorize use of a certain amount of network resources (bandwidth), etc. The presence and design of such intermediaries may not follow the "Internet" model or the SIP requirements for proxies (which are not supposed to look in message bodies such as SDP session descriptions); however, they are a fact of life in some deployment scenarios and hence deserve consideration.
这里，中介被定义为SIP用户代理a和SIP用户代理B之间的实体，其需要对a和B之间交换的SDP会话描述执行某种处理，以便会话建立按预期操作。此类中介体的示例包括可执行媒体中继的会话边界控制器（SBC）、可授权使用一定数量的网络资源（带宽）的代理呼叫会话控制功能（P-CSCF）等。此类中介体的存在和设计可能不遵循“互联网”代理的模型或SIP要求（不应查看消息体，如SDP会话描述）；但是，在某些部署场景中，它们是一个事实，因此值得考虑。
If the intermediary needs to understand the characteristics of the media sessions being negotiated, e.g., the amount of bandwidth used or the transport protocol negotiated, then use of the SDP Capability Negotiation framework may impact them. For example, some intermediaries are known to disallow answers where the transport protocol differs from the one in the offer. Use of the SDP Capability Negotiation framework in the presence of such intermediaries could lead to session failures. Intermediaries that need to authorize use of network resources based on the negotiated media stream parameters are affected as well. If they inspect only the offer, then they may authorize parameters assuming a different transport protocol, codecs, etc., than what is actually being negotiated. For these, and other, reasons it is RECOMMENDED that implementers of intermediaries add support for the SDP Capability Negotiation framework.
如果中介体需要了解正在协商的媒体会话的特征，例如，使用的带宽量或协商的传输协议，那么使用SDP能力协商框架可能会影响它们。例如，已知一些中介机构不允许传输协议与报价中的协议不同的答案。在存在此类中介的情况下使用SDP能力协商框架可能会导致会话失败。需要根据协商的媒体流参数授权使用网络资源的中介也会受到影响。如果他们只检查报价，那么他们可能会授权参数，假设传输协议、编解码器等与实际协商的不同。出于这些和其他原因，建议中介体的实现者添加对SDP能力协商框架的支持。
The SDP Capability Negotiation framework itself attempts to help out these intermediaries as well, by recommending a second offer/answer exchange when use of a potential configuration has been negotiated (see Section 3.6.3). However, there are several limitations with this approach. First of all, although the second offer/answer exchange is RECOMMENDED, it is not required and hence may not be performed. Secondly, the intermediary may refuse the initial answer, e.g., due to perceived transport protocol mismatch. Thirdly, the strategy is not foolproof since the offer/answer procedures [RFC3264] leave the original offer/answer exchange in effect when a subsequent one fails. Consider the following example:
SDP能力协商框架本身也试图通过在协商使用潜在配置时推荐第二次报价/应答交换来帮助这些中介机构（见第3.6.3节）。然而，这种方法有一些局限性。首先，尽管建议进行第二次报价/应答交换，但这不是必需的，因此可能不会执行。第二，中介可以拒绝初始答案，例如，由于感知到的传输协议不匹配。第三，该策略并非万无一失，因为当后续的报价/应答交换失败时，报价/应答过程[RFC3264]会使原始报价/应答交换保持有效。考虑下面的例子：
1. Offerer generates an SDP session description offer with the actual configuration specifying a low-bandwidth configuration (e.g., plain RTP) and a potential configuration specifying a high(er) bandwidth configuration (e.g., Secure RTP with integrity).
1. 报价人生成SDP会话描述报价，实际配置指定低带宽配置（例如，普通RTP），潜在配置指定高（er）带宽配置（例如，具有完整性的安全RTP）。
2. An intermediary (e.g., an SBC or P-CSCF), that does not support SDP Capability Negotiation, authorizes the session based on the actual configuration it sees in the SDP session description.
2. 不支持SDP能力协商的中介（例如，SBC或P-CSCF）根据其在SDP会话描述中看到的实际配置来授权会话。
3. The answerer chooses the high(er) bandwidth potential configuration and generates an answer SDP session description based on that.
3. 应答者选择高（er）带宽潜在配置，并基于该配置生成应答SDP会话描述。
4. The intermediary passes through the answer SDP session description.
4. 中介传递应答SDP会话描述。
5. The offerer sees the accepted answer, and generates an updated offer that contains the selected potential configuration as the actual configuration. In other words, the high(er) bandwidth configuration (which has already been negotiated successfully) is now the actual configuration in the offer SDP session description.
5. 报价人看到接受的答案，并生成更新的报价，其中包含所选的潜在配置作为实际配置。换句话说，高（er）带宽配置（已成功协商）现在是offer SDP会话描述中的实际配置。
6. The intermediary sees the new offer; however, it does not authorize the use of the high(er) bandwidth configuration, and consequently generates a rejection message to the offerer.
6. 中间人看到了新的报价；然而，它不授权使用高（er）带宽配置，并因此生成拒绝消息给报价人。
7. The offerer receives the rejected offer.
7. 报价人收到被拒绝的报价。
After step 7, per RFC 3264, the offer/answer exchange that completed in step 5 remains in effect; however, the intermediary may not have authorized the necessary network resources and hence the media stream may experience quality issues. The solution to this problem is to upgrade the intermediary to support the SDP Capability Negotiation framework.
在步骤7之后，根据RFC 3264，在步骤5中完成的报价/应答交换仍然有效；然而，中介可能没有授权必要的网络资源，因此媒体流可能会遇到质量问题。此问题的解决方案是升级中介以支持SDP能力协商框架。
The base SDP Capability Negotiation framework defines transport capabilities and attribute capabilities. Media capabilities, which can be used to describe media formats and their associated parameters, are not defined in this document; however, the "rtpmap" and "fmtp" attributes can nevertheless be used as attribute capabilities. Using such attribute capabilities in a potential configuration requires a bit of care though.
基本SDP能力协商框架定义了传输能力和属性能力。本文件未定义可用于描述媒体格式及其相关参数的媒体功能；但是，“rtpmap”和“fmtp”属性仍可用作属性功能。不过，在潜在配置中使用此类属性功能需要小心一点。
The rtpmap parameter binds an RTP payload type to a media format (e.g., codec). While it is possible to provide rtpmaps for payload types not found in the corresponding "m=" line, such rtpmaps provide no value in normal offer/answer exchanges, since only the payload types found in the "m=" line are part of the offer (or answer). This applies to the base SDP Capability Negotiation framework as well.
rtpmap参数将RTP有效负载类型绑定到媒体格式（例如编解码器）。虽然可以为相应的“m=”行中未找到的有效负载类型提供RTPMAP，但此类RTPMAP在正常的报价/应答交换中不提供任何价值，因为只有“m=”行中找到的有效负载类型是报价（或应答）的一部分。这也适用于基本SDP能力协商框架。
Only the media formats (e.g., RTP payload types) provided in the "m=" line are actually offered; inclusion of "rtpmap" attributes with other RTP payload types in a potential configuration does not change this fact and hence they do not provide any useful information there. They may still be useful as pure capabilities though (outside a potential configuration) in order to inform a peer of additional codecs supported.
实际上只提供“m=”行中提供的媒体格式（例如RTP有效负载类型）；将“rtpmap”属性与其他RTP有效负载类型一起包含在潜在配置中不会改变这一事实，因此它们不会提供任何有用的信息。它们作为纯功能（在潜在配置之外）可能仍然有用，以便通知对等方支持的其他编解码器。
It is possible to provide an "rtpmap" attribute capability with a payload type mapping to a different codec than a corresponding actual configuration "rtpmap" attribute for the media description has. Such practice is permissible as a way of indicating a capability. If that capability is included in a potential configuration, then delete-attributes (see Section 3.5.1) MUST be used to ensure that there is not multiple "rtpmap" attributes for the same payload type in a given media description (which would not be allowed by SDP [RFC4566]).
可以提供“rtpmap”属性功能，其中有效负载类型映射到与媒体描述的对应实际配置“rtpmap”属性不同的编解码器。这种做法作为一种表示能力的方式是允许的。如果该能力包含在潜在配置中，则必须使用删除属性（见第3.5.1节），以确保给定媒体描述中同一有效负载类型没有多个“rtpmap”属性（SDP[RFC4566]不允许）。
Similar considerations and rules apply to the "fmtp" attribute. An "fmtp" attribute capability for a media format not included in the "m=" line is useless in a potential configuration (but may be useful as a capability by itself). An "fmtp" attribute capability in a potential configuration for a media format that already has an "fmtp" attribute in the actual configuration may lead to multiple fmtp format parameters for that media format and that is not allowed by SDP [RFC4566]. The delete-attributes MUST be used to ensure that there are not multiple "fmtp" attributes for a given media format in a media description.
类似的注意事项和规则适用于“fmtp”属性。“m=”行中未包含的媒体格式的“fmtp”属性功能在潜在配置中是无用的（但作为一种功能本身可能是有用的）。对于在实际配置中已经具有“fmtp”属性的媒体格式，潜在配置中的“fmtp”属性能力可能会导致该媒体格式的多个fmtp格式参数，SDP不允许这些参数[RFC4566]。删除属性必须用于确保媒体描述中给定媒体格式没有多个“fmtp”属性。
Extensions to the base SDP Capability Negotiation framework may change the above behavior.
对基本SDP能力协商框架的扩展可能会改变上述行为。
SDP defines the "inactive", "sendonly", "recvonly", and "sendrecv" direction attributes. The direction attributes can be applied at either the session level or the media level. In either case, it is possible to define attribute capabilities for these direction capabilities; if used by a potential configuration, the normal offer/answer procedures still apply. For example, if an offered potential configuration includes the "sendonly" direction attribute, and it is selected as the actual configuration, then the answer MUST include a corresponding "recvonly" (or "inactive") attribute.
SDP定义了“非活动”、“仅发送”、“仅接收”和“发送接收”方向属性。方向属性可以应用于会话级别或媒体级别。在任何一种情况下，都可以为这些方向能力定义属性能力；如果由潜在配置使用，正常的报价/应答程序仍然适用。例如，如果提供的潜在配置包含“sendonly”方向属性，并且选择该属性作为实际配置，则答案必须包含相应的“RecVoOnly”（或“inactive”）属性。
RFC 3407 defines capability descriptions with limited abilities to describe attributes, bandwidth parameters, transport protocols and media formats. RFC 3407 does not define any negotiation procedures for actually using those capability descriptions.
RFC 3407定义了描述属性、带宽参数、传输协议和媒体格式的能力有限的能力描述。RFC 3407没有为实际使用这些能力描述定义任何协商程序。
This document defines new attributes for describing attribute capabilities and transport capabilities. It also defines procedures for using those capabilities as part of an offer/answer exchange. In contrast to RFC 3407, this document does not define bandwidth parameters, and it also does not define how to express ranges of values. Extensions to this document may be defined in order to fully cover all the capabilities provided by RFC 3407 (for example, more general media capabilities).
本文档定义了用于描述属性能力和传输能力的新属性。它还定义了将这些功能用作报价/应答交换的一部分的过程。与RFC 3407不同，本文档未定义带宽参数，也未定义如何表示值的范围。可以定义本文件的扩展，以完全涵盖RFC 3407提供的所有功能（例如，更通用的媒体功能）。
It is RECOMMENDED that implementations use the attributes and procedures defined in this document instead of those defined in [RFC3407]. If capability description interoperability with legacy RFC 3407 implementations is desired, implementations MAY include both RFC 3407 capability descriptions and capabilities defined by this document. The offer/answer negotiation procedures defined in this document will not use the RFC 3407 capability descriptions.
建议实施使用本文档中定义的属性和过程，而不是[RFC3407]中定义的属性和过程。如果需要与传统RFC 3407实现的能力描述互操作性，则实现可能包括RFC 3407能力描述和本文档定义的能力。本文件中定义的报价/应答谈判程序不使用RFC 3407能力描述。
In this section, we provide examples showing how to use the SDP Capability Negotiation.
在本节中，我们将提供示例，展示如何使用SDP功能协商。
The following example illustrates how to use the SDP Capability Negotiation extensions to negotiate use of one out of several possible transport protocols. The offerer uses the expected least-common-denominator (plain RTP) as the actual configuration, and the alternative transport protocols as the potential configurations.
下面的示例说明了如何使用SDP能力协商扩展来协商使用几种可能的传输协议中的一种。报价人使用预期最小公分母（普通RTP）作为实际配置，使用备选传输协议作为潜在配置。
The example is illustrated by the offer/answer exchange below, where Alice sends an offer to Bob:
下面的报价/应答交换说明了该示例，其中Alice向Bob发送报价：
Alice Bob
艾丽丝·鲍伯
| (1) Offer (RTP/[S]AVP[F]) |
|--------------------------------->|
| |
| (2) Answer (RTP/AVPF) |
|<---------------------------------|
| |
| (3) Offer (RTP/AVPF) |
|--------------------------------->|
| |
| (4) Answer (RTP/AVPF) |
|<---------------------------------|
| |
| (1) Offer (RTP/[S]AVP[F]) |
|--------------------------------->|
| |
| (2) Answer (RTP/AVPF) |
|<---------------------------------|
| |
| (3) Offer (RTP/AVPF) |
|--------------------------------->|
| |
| (4) Answer (RTP/AVPF) |
|<---------------------------------|
| |
Alice's offer includes plain RTP (RTP/AVP), RTP with RTCP-based feedback (RTP/AVPF), Secure RTP (RTP/SAVP), and Secure RTP with RTCP-based feedback (RTP/SAVPF) as alternatives. RTP is the default, with RTP/SAVPF, RTP/SAVP, and RTP/AVPF as the alternatives and preferred in the order listed:
Alice的报价包括普通RTP（RTP/AVP）、基于RTP的反馈的RTP（RTP/AVPF）、安全RTP（RTP/SAVP）和基于RTP的反馈的安全RTP（RTP/SAVPF）作为替代方案。RTP为默认值，RTP/SAVPF、RTP/SAVP和RTP/AVPF为备选方案，优先顺序如下：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=acap:2 rtcp-fb:0 nack
a=pcfg:1 t=1 a=1,[2]
a=pcfg:2 t=2 a=1
a=pcfg:3 t=3 a=[2]
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=acap:2 rtcp-fb:0 nack
a=pcfg:1 t=1 a=1,[2]
a=pcfg:2 t=2 a=1
a=pcfg:3 t=3 a=[2]
The "m=" line indicates that Alice is offering to use plain RTP with PCMU or G.729. The capabilities are provided by the "a=tcap" and "a=acap" attributes. The "tcap" capability indicates that Secure RTP with RTCP-based feedback (RTP/SAVPF), Secure RTP (RTP/SAVP), and RTP with RTCP-based feedback are supported. The first "acap" attribute provides an attribute capability with a handle of 1. The capability is a "crypto" attribute, which provides the keying material for SRTP using SDP security descriptions [RFC4568]. The second "acap" attribute provides an attribute capability with a handle of 2. The
“m=”行表示Alice提供将普通RTP与PCMU或G.729一起使用。这些功能由“a=tcap”和“a=acap”属性提供。“tcap”功能表示支持基于RTCP的反馈的安全RTP（RTP/SAVPF）、基于RTP的反馈的安全RTP（RTP/SAVP）和RTP。第一个“acap”属性提供一个句柄为1的属性功能。该功能是一个“加密”属性，它使用SDP安全描述为SRTP提供密钥材料[RFC4568]。第二个“acap”属性提供了一个句柄为2的属性功能。这个
capability is an "rtcp-fb" attribute, which is used by the RTCP-based feedback profiles to indicate that payload type 0 (PCMU) supports feedback type "nack". The "a=pcfg" attributes provide the potential configurations included in the offer by reference to the capabilities. There are three potential configurations:
能力是一个“rtcp fb”属性，基于rtcp的反馈配置文件使用该属性指示有效负载类型0（PCMU）支持反馈类型“nack”。“a=pcfg”属性通过参考功能提供报价中包含的潜在配置。有三种可能的配置：
o Potential configuration 1, which is the most preferred potential configuration specifies use of transport protocol capability 1 (RTP/SAVPF) and attribute capabilities 1 (the "crypto" attribute) and 2 (the "rtcp-fb" attribute). Support for the first one is mandatory whereas support for the second one is optional.
o 潜在配置1是最优选的潜在配置，它指定了传输协议能力1（RTP/SAVPF）和属性能力1（加密属性）和2（rtcp fb属性）的使用。支持第一个是强制性的，而支持第二个是可选的。
o Potential configuration 2, which is the second most preferred potential configuration specifies use of transport protocol capability 2 (RTP/SAVP) and mandatory attribute capability 1 (the "crypto" attribute).
o 潜在配置2是第二个最优选的潜在配置，指定使用传输协议能力2（RTP/SAVP）和强制属性能力1（“加密”属性）。
o Potential configuration 3, which is the least preferred potential configuration (but the second least preferred configuration overall, since the actual configuration provided by the "m=" line is always the least preferred configuration), specifies use of transport protocol capability 3 (RTP/AVPF) and optional attribute capability 2 (the "rtcp-fb" attribute).
o 潜在配置3是最不受欢迎的潜在配置（但总体上是第二个最不受欢迎的配置，因为“m=”line提供的实际配置始终是最不受欢迎的配置），它指定了传输协议能力3（RTP/AVPF）和可选属性能力2（rtcp fb）的使用属性）。
Bob receives the SDP session description offer from Alice. Bob does not support any Secure RTP profiles; however, he supports plain RTP and RTP with RTCP-based feedback, as well as the SDP Capability Negotiation extensions, and hence he accepts the potential configuration for RTP with RTCP-based feedback provided by Alice:
Bob收到Alice提供的SDP会话描述。Bob不支持任何安全RTP配置文件；但是，他支持普通RTP和基于RTCP的反馈RTP，以及SDP能力协商扩展，因此他接受Alice提供的基于RTCP的反馈RTP的潜在配置：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/AVPF 0 18
a=rtcp-fb:0 nack
a=acfg:1 t=3 a=[2]
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/AVPF 0 18
a=rtcp-fb:0 nack
a=acfg:1 t=3 a=[2]
Bob includes the "a=acfg" attribute in the answer to inform Alice that he based his answer on an offer containing the potential configuration with transport protocol capability 3 and optional attribute capability 2 from the offer SDP session description (i.e., the RTP/AVPF profile using the "rtcp-fb" value provided). Bob also includes an "rtcp-fb" attribute with the value "nack" value for RTP payload type 0.
Bob在回答中包含“a=acfg”属性，以告知Alice，他基于一个包含潜在配置（传输协议能力3和可选属性能力2）的报价，该配置来自报价SDP会话描述（即，使用提供的“rtcp fb”值的RTP/AVPF配置文件）。Bob还包括一个“rtcp fb”属性，其值为RTP有效负载类型0的“nack”值。
When Alice receives Bob's answer, session negotiation has completed, however Alice nevertheless chooses to generate a new offer using the actual configuration. This is done purely to assist any intermediaries that may reside between Alice and Bob but do not support the SDP Capability Negotiation framework (and hence may not understand the negotiation that just took place):
当Alice收到Bob的回答时，会话协商已经完成，但是Alice仍然选择使用实际配置生成新的报价。这样做纯粹是为了帮助可能位于Alice和Bob之间但不支持SDP能力协商框架的任何中介机构（因此可能不理解刚刚发生的协商）：
Alice's updated offer includes only RTP/AVPF, and it is not using the SDP Capability Negotiation framework (Alice could have included the capabilities as well if she wanted):
Alice的最新报价仅包括RTP/AVPF，并且未使用SDP能力协商框架（Alice如果愿意，也可以包括这些能力）：
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVPF 0 18
a=rtcp-fb:0 nack
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVPF 0 18
a=rtcp-fb:0 nack
The "m=" line now indicates that Alice is offering to use RTP with RTCP-based feedback and using PCMU or G.729. The "rtcp-fb" attribute provides the feedback type "nack" for payload type 0 again (but as part of the actual configuration).
“m=”行现在表示Alice提供将RTP与基于RTCP的反馈一起使用，并使用PCMU或G.729。“rtcp fb”属性再次为有效负载类型0提供反馈类型“nack”（但作为实际配置的一部分）。
Bob receives the SDP session description offer from Alice, which he accepts, and then generates an answer to Alice:
Bob收到Alice提供的SDP会话描述，并接受该服务，然后生成Alice的答案：
v=0
o=- 24351 621815 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/AVPF 0 18
a=rtcp-fb:0 nack
v=0
o=- 24351 621815 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 54568 RTP/AVPF 0 18
a=rtcp-fb:0 nack
Bob includes the same "rtcp-fb" attribute as before, and the session proceeds without change. Although Bob did not include any capabilities in his answer, he could have done so if he wanted.
Bob包含与前面相同的“rtcp fb”属性，并且会话继续进行而不进行更改。虽然Bob的回答中没有包含任何能力，但如果他愿意，他可以这样做。
Note that in this particular example, the answerer supported the SDP Capability Negotiation framework and hence the attributes and procedures defined here; however, had he not, the answerer would simply have ignored the new attributes received in step 1 and accepted the offer to use normal RTP. In that case, the following answer would have been generated in step 2 instead:
注意，在这个特定示例中，应答者支持SDP能力协商框架，因此这里定义了属性和过程；然而，如果不是这样，回答者只会忽略步骤1中收到的新属性，并接受使用普通RTP的提议。在这种情况下，将在步骤2中生成以下答案：
v=0 o=- 24351 621814 IN IP4 192.0.2.2 s= c=IN IP4 192.0.2.2 t=0 0 m=audio 54568 RTP/AVP 0 18
v=0 o=-24351 621814在IP4 192.0.2.2中s=c=IP4 192.0.2.2中t=0 0 m=音频54568 RTP/AVP 0 18
The following example illustrates how to use the SDP Capability Negotiation framework to negotiate use of SRTP using either SDP security descriptions or DTLS-SRTP. The offerer (Alice) wants to establish a Secure RTP audio stream but is willing to use plain RTP. Alice prefers to use DTLS-SRTP as the key management protocol, but supports SDP security descriptions as well (note that [RFC5763] contains additional DTLS-SRTP examples).
下面的示例说明了如何使用SDP能力协商框架，使用SDP安全描述或DTLS-SRTP协商SRTP的使用。报价人（Alice）希望建立安全的RTP音频流，但愿意使用普通RTP。Alice倾向于使用DTLS-SRTP作为密钥管理协议，但也支持SDP安全描述（注意，[RFC5763]包含其他DTLS-SRTP示例）。
The example is illustrated by the offer/answer exchange below, where Alice sends an offer to Bob:
下面的报价/应答交换说明了该示例，其中Alice向Bob发送报价：
Alice Bob
艾丽丝·鲍伯
| (1) Offer (RTP/[S]AVP,SDES | DTLS-SRTP)|
|--------------------------------------->|
| |
|<--------- DTLS-SRTP handshake -------->|
| |
| (2) Answer (DTLS-SRTP) |
|<---------------------------------------|
| |
| (3) Offer (DTLS-SRTP) |
|--------------------------------------->|
| |
| (4) Answer (DTLS-SRTP) |
|<---------------------------------------|
| |
| (1) Offer (RTP/[S]AVP,SDES | DTLS-SRTP)|
|--------------------------------------->|
| |
|<--------- DTLS-SRTP handshake -------->|
| |
| (2) Answer (DTLS-SRTP) |
|<---------------------------------------|
| |
| (3) Offer (DTLS-SRTP) |
|--------------------------------------->|
| |
| (4) Answer (DTLS-SRTP) |
|<---------------------------------------|
| |
Alice's offer includes an audio stream that offers use of plain RTP and Secure RTP as alternatives. For the Secure RTP stream, it can be established using either DTLS-SRTP or SDP security descriptions:
Alice的产品包括一个音频流，它提供了普通RTP和安全RTP作为替代品的使用。对于安全RTP流，可以使用DTLS-SRTP或SDP安全描述建立：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 setup:actpass
a=acap:2 fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tcap:1 UDP/TLS/RTP/SAVP RTP/SAVP
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1,2
a=pcfg:2 t=2 a=3
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 setup:actpass
a=acap:2 fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=tcap:1 UDP/TLS/RTP/SAVP RTP/SAVP
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=1 a=1,2
a=pcfg:2 t=2 a=3
The first (and preferred) potential configuration for the audio stream specifies use of transport capability 1 (UDP/TLS/RTP/SAVP), i.e., DTLS-SRTP, and attribute capabilities 1 and 2 (active/passive mode and certificate fingerprint), both of which must be supported to choose this potential configuration. The second (and less preferred) potential configuration specifies use of transport capability 2 (RTP/SAVP) and mandatory attribute capability 3, i.e., the SDP security description.
音频流的第一个（也是首选）潜在配置指定了传输能力1（UDP/TLS/RTP/SAVP）的使用，即DTLS-SRTP，以及属性能力1和2（主动/被动模式和证书指纹），选择此潜在配置时必须支持这两个功能。第二种（也是不太优选的）潜在配置指定了传输能力2（RTP/SAVP）和强制性属性能力3的使用，即SDP安全描述。
Bob receives the SDP session description offer from Alice. Bob supports DTLS-SRTP as preferred by Alice and Bob now initiates the DTLS-SRTP handshake to establish the DTLS-SRTP session (see [RFC5764] for details).
Bob收到Alice提供的SDP会话描述。Bob支持Alice首选的DTLS-SRTP，Bob现在启动DTLS-SRTP握手以建立DTLS-SRTP会话（有关详细信息，请参阅[RFC5764]）。
Bob also sends back an answer to Alice as follows:
Bob还向Alice发回一个答案，如下所示：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 UDP/TLS/RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=1 a=1,2
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 UDP/TLS/RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=1 a=1,2
For the audio stream, Bob accepted the use of DTLS-SRTP, and hence
the profile in the "m=" line is "UDP/TLS/RTP/SAVP". Bob also
includes a "setup:active" attribute to indicate he is the active
For the audio stream, Bob accepted the use of DTLS-SRTP, and hence
the profile in the "m=" line is "UDP/TLS/RTP/SAVP". Bob also
includes a "setup:active" attribute to indicate he is the active
endpoint for the DTLS-SRTP session as well as the fingerprint for Bob's certificate. Bob's "acfg" attribute indicates that he chose potential configuration 1 from Alice's offer.
DTLS-SRTP会话的端点以及Bob证书的指纹。Bob的“acfg”属性表示他从Alice的报价中选择了潜在配置1。
When Alice receives Bob's answer, session negotiation has completed (and Alice can verify the DTLS handshake using Bob's certificate fingerprint in the answer); however, Alice nevertheless chooses to generate a new offer using the actual configuration. This is done purely to assist any intermediaries that may reside between Alice and Bob but do not support the capability negotiation extensions (and hence may not understand the negotiation that just took place).
当Alice收到Bob的答案时，会话协商已完成（Alice可以使用答案中Bob的证书指纹验证DTLS握手）；然而，Alice仍然选择使用实际配置生成新的报价。这样做纯粹是为了帮助可能位于Alice和Bob之间但不支持功能协商扩展（因此可能不理解刚刚发生的协商）的任何中介机构。
Alice's updated offer includes only DTLS-SRTP for the audio stream, and it is not using the SDP Capability Negotiation framework (Alice could have included the capabilities as well if she wanted):
Alice的更新产品仅包括音频流的DTLS-SRTP，并且未使用SDP能力协商框架（Alice如果愿意，也可以包括这些能力）：
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
m=audio 59000 UDP/TLS/RTP/AVP 98
a=rtpmap:98 AMR/8000
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
m=audio 59000 UDP/TLS/RTP/AVP 98
a=rtpmap:98 AMR/8000
The "m=" line for the audio stream now indicates that Alice is offering to use DTLS-SRTP in active/passive mode using her certificate fingerprint provided.
音频流的“m=”行现在表示Alice正在提供证书指纹，以主动/被动模式使用DTLS-SRTP。
Bob receives the SDP session description offer from Alice, which he accepts, and then generates an answer to Alice:
Bob收到Alice提供的SDP会话描述，并接受该服务，然后生成Alice的答案：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 UDP/TLS/RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=1 a=1,2
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 UDP/TLS/RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=1 a=1,2
Bob includes the same "setup:active" and fingerprint attributes as before, and the session proceeds without change. Although Bob did not include any capabilities in his answer, he could have done so if he wanted.
Bob包含与以前相同的“设置：活动”和指纹属性，会话继续进行而不做任何更改。虽然Bob的回答中没有包含任何能力，但如果他愿意，他可以这样做。
Note that in this particular example, the answerer supported the capability extensions defined here; however, had he not, the answerer would simply have ignored the new attributes received in step 1 and accepted the offer to use normal RTP. In that case, the following answer would have been generated in step 2 instead:
注意，在这个特定示例中，应答者支持此处定义的功能扩展；然而，如果不是这样，回答者只会忽略步骤1中收到的新属性，并接受使用普通RTP的提议。在这种情况下，将在步骤2中生成以下答案：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/AVP 98
a=rtpmap:98 AMR/8000
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/AVP 98
a=rtpmap:98 AMR/8000
Finally, if Bob had chosen to use SDP security descriptions instead of DTLS-SRTP, the following answer would have been generated:
最后，如果Bob选择使用SDP安全描述而不是DTLS-SRTP，则会生成以下答案：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:2 t=2 a=3
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:2 t=2 a=3
4.3. Best-Effort SRTP with Session-Level MIKEY and Media-Level Security Descriptions
4.3. 具有会话级MIKEY和媒体级安全描述的尽力而为的SRTP
The following example illustrates how to use the SDP Capability Negotiation extensions to support so-called Best-Effort Secure RTP as well as alternative keying mechanisms, more specifically MIKEY [RFC3830] and SDP security descriptions. The offerer (Alice) wants to establish an audio and video session. Alice prefers to use session-level MIKEY as the key management protocol, but supports SDP security descriptions as well.
以下示例说明了如何使用SDP能力协商扩展来支持所谓的尽力而为安全RTP以及备用密钥机制，更具体地说是MIKEY[RFC3830]和SDP安全描述。报价人（Alice）希望建立音频和视频会话。Alice更喜欢使用会话级别的MIKEY作为密钥管理协议，但也支持SDP安全描述。
The example is illustrated by the offer/answer exchange below, where Alice sends an offer to Bob:
下面的报价/应答交换说明了该示例，其中Alice向Bob发送报价：
Alice Bob
艾丽丝·鲍伯
| (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) |
|--------------------------------------->|
| |
| (2) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |
| (3) Offer (RTP/SAVP, SDES) |
|--------------------------------------->|
| |
| (4) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |
| (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) |
|--------------------------------------->|
| |
| (2) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |
| (3) Offer (RTP/SAVP, SDES) |
|--------------------------------------->|
| |
| (4) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |
Alice's offer includes an audio and a video stream. The audio stream offers use of plain RTP and Secure RTP as alternatives, whereas the video stream offers use of plain RTP, RTP with RTCP-based feedback, Secure RTP, and Secure RTP with RTCP-based feedback as alternatives:
Alice的服务包括音频和视频流。音频流提供使用普通RTP和安全RTP作为备选方案，而视频流提供使用普通RTP、基于RTCP的反馈的RTP、基于RTCP的反馈的安全RTP和基于RTCP的反馈的安全RTP作为备选方案：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=2 a=1|2
m=video 52000 RTP/AVP 31
a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=acap:4 rtcp-fb:* nack
a=pcfg:1 t=1 a=1,4|3,4
a=pcfg:2 t=2 a=1|3
a=pcfg:3 t=3 a=4
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF
m=audio 59000 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 t=2 a=1|2
m=video 52000 RTP/AVP 31
a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=acap:4 rtcp-fb:* nack
a=pcfg:1 t=1 a=1,4|3,4
a=pcfg:2 t=2 a=1|3
a=pcfg:3 t=3 a=4
The potential configuration for the audio stream specifies use of transport capability 2 (RTP/SAVP) and either attribute capability 1 (session-level MIKEY as the keying mechanism) or 2 (SDP security descriptions as the keying mechanism). Support for either of these attribute capabilities is mandatory. There are three potential configurations for the video stream.
音频流的潜在配置指定使用传输能力2（RTP/SAVP）和属性能力1（会话级别MIKEY作为键控机制）或2（SDP安全描述作为键控机制）。必须支持这些属性功能之一。视频流有三种可能的配置。
o The first configuration with configuration number 1 uses transport capability 1 (RTP/SAVPF) with either attribute capabilities 1 and 4 (session-level MIKEY and the "rtcp-fb" attribute) or attribute capabilities 3 and 4 (SDP security descriptions and the "rtcp-fb" attribute). In this example, the offerer insists on not only the keying mechanism being supported, but also that the "rtcp-fb" attribute is supported with the value indicated. Consequently, all the attribute capabilities are marked as mandatory in this potential configuration.
o 配置号为1的第一个配置使用传输能力1（RTP/SAVPF），具有属性能力1和4（会话级别MIKEY和“rtcp fb”属性）或属性能力3和4（SDP安全描述和“rtcp fb”属性）。在本例中，报价人不仅坚持支持键控机制，而且还坚持支持“rtcp fb”属性和指示的值。因此，在该潜在配置中，所有属性功能都标记为必需的。
o The second configuration with configuration number 2 uses transport capability 2 (RTP/SAVP) and either attribute capability 1 (session-level MIKEY) or attribute capability 3 (SDP security descriptions). Both attribute capabilities are mandatory in this configuration.
o 配置号为2的第二个配置使用传输能力2（RTP/SAVP）和属性能力1（会话级MIKEY）或属性能力3（SDP安全描述）。这两种属性功能在此配置中都是必需的。
o The third configuration with configuration number 3 uses transport capability 3 (RTP/AVPF) and mandatory attribute capability 4 (the "rtcp-fb" attribute).
o 配置编号为3的第三种配置使用传输能力3（RTP/AVPF）和强制属性能力4（“rtcp fb”属性）。
Bob receives the SDP session description offer from Alice. Bob supports Secure RTP, Secure RTP with RTCP-based feedback and the SDP Capability Negotiation extensions. Bob also supports SDP security descriptions, but not MIKEY, and hence he generates the following answer:
Bob收到Alice提供的SDP会话描述。Bob支持安全RTP、基于RTCP的反馈安全RTP和SDP能力协商扩展。Bob还支持SDP安全描述，但不支持MIKEY，因此他生成以下答案：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:1 t=2 a=2
m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=rtcp-fb:* nack
a=acfg:1 t=1 a=3,4
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:1 t=2 a=2
m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=rtcp-fb:* nack
a=acfg:1 t=1 a=3,4
For the audio stream, Bob accepted the use of Secure RTP, and hence the profile in the "m=" line is "RTP/SAVP". Bob also includes a "crypto" attribute with his own keying material, and an "acfg" attribute identifying actual configuration 1 for the audio media stream from the offer, using transport capability 2 (RTP/SAVP) and
对于音频流，Bob接受使用安全RTP，因此“m=”行中的配置文件是“RTP/SAVP”。Bob还包括一个带有他自己的键控材料的“加密”属性，以及一个“acfg”属性，该属性使用传输能力2（RTP/SAVP）和
attribute capability 2 (the "crypto" attribute from the offer). For the video stream, Bob accepted the use of Secure RTP with RTCP-based feedback, and hence the profile in the "m=" line is "RTP/SAVPF". Bob also includes a "crypto" attribute with his own keying material, and an "acfg" attribute identifying actual configuration 1 for the video stream from the offer, using transport capability 1 (RTP/SAVPF) and attribute capabilities 3 (the "crypto" attribute from the offer) and 4 (the "rtcp-fb" attribute from the offer).
属性能力2（报价中的“加密”属性）。对于视频流，Bob接受使用基于RTCP的反馈的安全RTP，因此“m=”行中的配置文件是“RTP/SAVPF”。Bob还包括一个带有他自己的键控材料的“加密”属性，以及一个“acfg”属性，该属性使用传输能力1（RTP/SAVPF）和属性能力3（来自要约的“加密”属性）和4（来自要约的“rtcp fb”属性标识来自要约的视频流的实际配置1。
When Alice receives Bob's answer, session negotiation has completed; however, Alice nevertheless chooses to generate a new offer using the actual configuration. This is done purely to assist any intermediaries that may reside between Alice and Bob but do not support the capability negotiation extensions (and hence may not understand the negotiation that just took place).
当Alice收到Bob的回答时，会话协商已完成；然而，Alice仍然选择使用实际配置生成新的报价。这样做纯粹是为了帮助可能位于Alice和Bob之间但不支持功能协商扩展（因此可能不理解刚刚发生的协商）的任何中介机构。
Alice's updated offer includes only SRTP for the audio stream SRTP with RTCP-based feedback for the video stream, and it is not using the SDP Capability Negotiation framework (Alice could have included the capabilities as well is she wanted):
Alice的更新产品仅包括音频流的SRTP和视频流的基于RTCP的反馈，并且没有使用SDP能力协商框架（Alice可能也包括了她想要的能力）：
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=video 52000 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtcp-fb:* nack
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=video 52000 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=rtcp-fb:* nack
The "m=" line for the audio stream now indicates that Alice is offering to use Secure RTP with PCMU or G.729, whereas the "m=" line for the video stream indicates that Alice is offering to use Secure RTP with RTCP-based feedback and H.261. Each media stream includes a "crypto" attribute, which provides the SRTP keying material, with the same value again.
音频流的“m=”行现在表示Alice提供将安全RTP与PCMU或G.729一起使用，而视频流的“m=”行表示Alice提供将安全RTP与基于RTCP的反馈和H.261一起使用。每个媒体流都包含一个“crypto”属性，该属性为SRTP密钥材料提供相同的值。
Bob receives the SDP session description offer from Alice, which he accepts, and then generates an answer to Alice:
Bob收到Alice提供的SDP会话描述，并接受该服务，然后生成Alice的答案：
v=0
o=- 24351 621815 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=rtcp-fb:* nack
v=0
o=- 24351 621815 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=rtcp-fb:* nack
Bob includes the same "crypto" attribute as before, and the session proceeds without change. Although Bob did not include any capabilities in his answer, he could have done so if he wanted.
Bob包含与前面相同的“crypto”属性，会话继续进行而不做任何更改。虽然Bob的回答中没有包含任何能力，但如果他愿意，他可以这样做。
Note that in this particular example, the answerer supported the capability extensions defined here; however, had he not, the answerer would simply have ignored the new attributes received in step 1 and accepted the offer to use normal RTP. In that case, the following answer would have been generated in step 2 instead:
注意，在这个特定示例中，应答者支持此处定义的功能扩展；然而，如果不是这样，回答者只会忽略步骤1中收到的新属性，并接受使用普通RTP的提议。在这种情况下，将在步骤2中生成以下答案：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/AVP 98
a=rtpmap:98 AMR/8000
m=video 55468 RTP/AVP 31
a=rtpmap:31 H261/90000
a=rtcp-fb:* nack
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/AVP 98
a=rtpmap:98 AMR/8000
m=video 55468 RTP/AVP 31
a=rtpmap:31 H261/90000
a=rtcp-fb:* nack
Finally, if Bob had chosen to use session-level MIKEY instead of SDP security descriptions, the following answer would have been generated:
最后，如果Bob选择使用会话级MIKEY而不是SDP安全性描述，则会生成以下答案：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyO...
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=2 a=1
m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=rtcp-fb:* nack
a=acfg:1 t=1 a=1,4
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyO...
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acfg:1 t=2 a=1
m=video 55468 RTP/SAVPF 31
a=rtpmap:31 H261/90000
a=rtcp-fb:* nack
a=acfg:1 t=1 a=1,4
It should be noted, that although Bob could have chosen session-level MIKEY for one media stream, and SDP security descriptions for another media stream, there are no well-defined offerer processing rules of the resulting answer for this, and hence the offerer may incorrectly assume use of MIKEY for both streams. To avoid this, if the answerer chooses session-level MIKEY, then all Secure RTP-based media streams SHOULD use MIKEY (this applies irrespective of whether or not SDP Capability Negotiation is being used). Use of media-level MIKEY does not have a similar constraint.
应该注意的是，虽然Bob可能已经为一个媒体流选择了会话级别的MIKEY，为另一个媒体流选择了SDP安全描述，但是对于这个问题，没有明确定义的报价人处理结果的规则，因此报价人可能错误地假设两个流都使用MIKEY。为了避免这种情况，如果应答者选择会话级MIKEY，那么所有基于安全RTP的媒体流都应该使用MIKEY（这适用于是否使用SDP能力协商）。使用媒体级别的MIKEY没有类似的限制。
4.4. SRTP with Session-Level MIKEY and Media-Level Security Descriptions as Alternatives
4.4. 具有会话级MIKEY和媒体级安全描述的SRTP作为备选方案
The following example illustrates how to use the SDP Capability Negotiation framework to negotiate use of either MIKEY or SDP security descriptions, when one of them is included as part of the actual configuration, and the other one is being selected. The offerer (Alice) wants to establish an audio and video session. Alice prefers to use session-level MIKEY as the key management protocol, but supports SDP security descriptions as well.
以下示例说明了如何使用SDP能力协商框架来协商MIKEY或SDP安全描述的使用，其中一个作为实际配置的一部分，另一个正在被选择。报价人（Alice）希望建立音频和视频会话。Alice更喜欢使用会话级别的MIKEY作为密钥管理协议，但也支持SDP安全描述。
The example is illustrated by the offer/answer exchange below, where Alice sends an offer to Bob:
下面的报价/应答交换说明了该示例，其中Alice向Bob发送报价：
Alice Bob
艾丽丝·鲍伯
| (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) |
|--------------------------------------->|
| |
| (2) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |
| (1) Offer (RTP/[S]AVP[F], SDES|MIKEY) |
|--------------------------------------->|
| |
| (2) Answer (RTP/SAVP, SDES) |
|<---------------------------------------|
| |
Alice's offer includes an audio and a video stream. Both the audio and the video stream offer use of Secure RTP:
Alice的服务包括音频和视频流。音频和视频流都提供了安全RTP的使用：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 a=-s:1
m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=pcfg:1 a=-s:2
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg:1 a=-s:1
m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=pcfg:1 a=-s:2
Alice does not know whether Bob supports MIKEY or SDP security descriptions. She could include attributes for both; however, the resulting procedures and potential interactions are not well-defined. Instead, she places a session-level "key-mgmt" attribute for MIKEY in the actual configuration with SDP security descriptions as an alternative in the potential configuration. The potential configuration for the audio stream specifies that all session-level attributes are to be deleted (i.e., the session-level "a=key-mgmt" attribute) and that mandatory attribute capability 2 is to be used (i.e., the "crypto" attribute). The potential configuration for the video stream is similar, except it uses its own mandatory "crypto" attribute capability (2). Note how the deletion of the session-level attributes does not affect the media-level attributes.
Alice不知道Bob是否支持MIKEY或SDP安全描述。她可以将两者的属性都包括在内；然而，由此产生的程序和潜在的相互作用并没有得到很好的定义。相反，她在实际配置中为MIKEY放置会话级别的“密钥管理”属性，并在潜在配置中使用SDP安全性描述作为替代。音频流的潜在配置指定删除所有会话级属性（即，会话级“a=密钥管理”属性），并使用强制属性能力2（即，“加密”属性）。视频流的潜在配置类似，只是它使用自己的强制“加密”属性功能（2）。请注意，删除会话级别属性不会影响媒体级别属性。
Bob receives the SDP session description offer from Alice. Bob supports Secure RTP and the SDP Capability Negotiation framework. Bob also supports both SDP security descriptions and MIKEY. Since the potential configuration is more preferred than the actual configuration, Bob (conceptually) generates an internal potential configuration SDP session description that contains the "crypto" attributes for the audio and video stream, but not the "key-mgmt" attribute for MIKEY, thereby avoiding any ambiguity between the two keying mechanisms. As a result, he generates the following answer:
Bob收到Alice提供的SDP会话描述。Bob支持安全RTP和SDP能力协商框架。Bob还支持SDP安全描述和MIKEY。由于潜在配置比实际配置更优选，Bob（概念上）生成内部潜在配置SDP会话描述，该描述包含音频和视频流的“加密”属性，但不包含MIKEY的“密钥管理”属性，从而避免了两个键控机制之间的任何歧义。因此，他得出以下答案：
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:1 a=-s:1
m=video 55468 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=acfg:1 a=-s:2
v=0
o=- 24351 621814 IN IP4 192.0.2.2
s=
t=0 0
c=IN IP4 192.0.2.2
m=audio 54568 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:WSJ+PSdFcGdUJShpX1ZjNzB4d1BINUAvLEw6UzF3|2^20|1:32
a=acfg:1 a=-s:1
m=video 55468 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:AwWpVLFJhQX1cfHJSojd0RmdmcmVCspeEc3QGZiN|2^20|1:32
a=acfg:1 a=-s:2
For the audio stream, Bob accepted the use of Secure RTP using SDP security descriptions. Bob therefore includes a "crypto" attribute with his own keying material, and an "acfg" attribute identifying the actual configuration 1 for the audio media stream from the offer, with the delete-attributes ("-s") and attribute capability 1 (the "crypto" attribute from the offer). For the video stream, Bob also accepted the use of Secure RTP using SDP security descriptions. Bob therefore includes a "crypto" attribute with his own keying material, and an "acfg" attribute identifying actual configuration 1 for the video stream from the offer, with the delete-attributes ("-s") and attribute capability 2.
对于音频流，Bob接受使用SDP安全描述的安全RTP。因此，Bob包括一个带有他自己的键控材料的“加密”属性，以及一个标识来自要约的音频媒体流的实际配置1的“acfg”属性，以及删除属性（“-s”）和属性能力1（来自要约的“加密”属性）。对于视频流，Bob还接受使用SDP安全描述的安全RTP。因此，Bob包括一个带有他自己的键控材料的“加密”属性，以及一个标识来自要约的视频流的实际配置1的“acfg”属性，以及删除属性（“-s”）和属性能力2。
Below, we illustrate the offer SDP session description, when Bob instead offers the "crypto" attribute as the actual configuration keying mechanism and "key-mgmt" as the potential configuration:
下面，我们演示了offer SDP会话描述，Bob提供“crypto”属性作为实际配置密钥机制，提供“key mgmt”作为潜在配置：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=acap:2 rtpmap:98 AMR/8000
a=pcfg:1 a=-m:1,2
m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=acap:4 rtpmap:31 H261/90000
a=pcfg:1 a=-m:1,4
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
m=audio 59000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=acap:2 rtpmap:98 AMR/8000
a=pcfg:1 a=-m:1,2
m=video 52000 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=acap:4 rtpmap:31 H261/90000
a=pcfg:1 a=-m:1,4
Note how we this time need to perform delete-attributes at the media level instead of the session level. When doing that, all attributes from the actual configuration SDP session description, including the rtpmaps provided, are removed. Consequently, we had to include these rtpmaps as capabilities as well, and then include them in the potential configuration, thereby effectively recreating the original "rtpmap" attributes in the resulting potential configuration SDP session description.
请注意，这次我们需要在媒体级别而不是会话级别执行删除属性。执行此操作时，将删除实际配置SDP会话描述中的所有属性，包括提供的RTPMAP。因此，我们必须将这些rtpmap也包括在功能中，然后将它们包括在潜在配置中，从而在生成的潜在配置SDP会话描述中有效地重新创建原始的“rtpmap”属性。
The SDP Capability Negotiation framework is defined to be used within the context of the offer/answer model, and hence all the offer/answer security considerations apply here as well [RFC3264]. Similarly, the Session Initiation Protocol (SIP) uses SDP and the offer/answer model, and hence, when used in that context, the SIP security considerations apply as well [RFC3261].
SDP能力协商框架定义为在报价/应答模型的上下文中使用，因此所有报价/应答安全注意事项也适用于此处[RFC3264]。类似地，会话发起协议（SIP）使用SDP和提供/应答模型，因此，当在该上下文中使用时，SIP安全考虑也适用[RFC3261]。
However, SDP Capability Negotiation introduces additional security issues. Its use as a mechanism to enable alternative transport protocol negotiation (secure and non-secure) as well as its ability to negotiate use of more or less secure keying methods and material warrant further security considerations. Also, the (continued) support for receiving media before answer combined with negotiation of alternative transport protocols (secure and non-secure) warrants further security considerations. We discuss these issues below.
然而，SDP能力协商带来了额外的安全问题。使用它作为一种机制来实现替代传输协议协商（安全和非安全），以及它协商使用或多或少安全的密钥方法和材料的能力需要进一步的安全考虑。此外，（继续）支持在应答之前接收媒体，并结合其他传输协议（安全和非安全）的协商，需要进一步考虑安全问题。我们将在下面讨论这些问题。
The SDP Capability Negotiation framework allows for an offered media stream to both indicate and support various levels of security for that media stream. Different levels of security can for example be negotiated by use of alternative attribute capabilities each indicating more or less secure keying methods as well as more or less strong ciphers. Since the offerer indicates support for each of these alternatives, he will presumably accept the answerer seemingly selecting any of the offered alternatives. If an attacker can modify the SDP session description offer, he can thereby force the negotiation of the weakest security mechanism that the offerer is willing to accept. This may enable the attacker to compromise the security of the negotiated media stream. Similarly, if the offerer wishes to negotiate use of a secure media stream (e.g., Secure RTP), but includes a non-secure media stream (e.g., plain RTP) as a valid (but less preferred) alternative, then an attacker that can modify the offered SDP session description will be able to force the establishment of an insecure media stream. The solution to both of these problems involves the use of integrity protection over the SDP session description. Ideally, this integrity protection provides end-to-end integrity protection in order to protect from any man-in-the-middle attack; secure multiparts such as Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751] provide one such solution; however, S/MIME requires use and availability of a Public Key Infrastructure (PKI). A slightly less secure alternative when using SIP, but generally much easier to deploy in practice, is to use SIP Identity [RFC4474]; this requires the existence of an authentication service (see [RFC4474]). Although this mechanism still requires a PKI, it only requires that servers (as opposed to end-users) have third-party validatable certificates, which significantly reduces the barrier to entry by ordinary users. Yet another, and considerably less secure, alternative is to use hop-by-hop security only, e.g., TLS or IPsec thereby ensuring the integrity of the offered SDP session description on a hop-by-hop basis. This is less secure because SIP allows partially trusted intermediaries on the signaling path, and such intermediaries processing the SIP request at each hop would be able to perform a man-in-the-middle attack by modifying the offered SDP session description. In simple architectures where the two UA's proxies communicate directly, the security provided by this method is roughly comparable to that provided by the previously discussed signature-based mechanisms.
SDP能力协商框架允许提供的媒体流指示并支持该媒体流的各种安全级别。例如，可以通过使用替代属性功能来协商不同级别的安全性，每个属性功能指示或多或少的安全密钥方法以及或多或少的强密码。由于报价人表示支持这些备选方案中的每一个，他可能会接受似乎选择了任何一个备选方案的回答人。如果攻击者可以修改SDP会话描述报价，则他可以因此强制协商报价人愿意接受的最弱安全机制。这可能使攻击者破坏协商媒体流的安全性。类似地，如果报价人希望协商安全媒体流（例如，安全RTP）的使用，但包括非安全媒体流（例如，普通RTP）作为有效（但不太首选）备选方案，则可以修改提供的SDP会话描述的攻击者将能够强制建立不安全的媒体流。这两个问题的解决方案都涉及在SDP会话描述上使用完整性保护。理想情况下，这种完整性保护提供端到端的完整性保护，以防止任何中间人攻击；安全多部分，如安全/多用途Internet邮件扩展（S/MIME）[RFC5751]提供了一种这样的解决方案；然而，S/MIME需要使用和提供公钥基础设施（PKI）。当使用SIP时，一个稍微不太安全的替代方案是使用SIP标识[RFC4474]，但在实践中通常更容易部署；这需要存在身份验证服务（请参见[RFC4474]）。尽管这种机制仍然需要PKI，但它只要求服务器（与最终用户相反）具有第三方可验证证书，这大大减少了普通用户进入的障碍。另一种安全性相当低的替代方案是仅使用逐跳安全性，例如TLS或IPsec，从而确保所提供的SDP会话描述在逐跳基础上的完整性。这是不太安全的，因为SIP允许在信令路径上使用部分受信任的中介，并且在每个跃点处处理SIP请求的此类中介将能够通过修改提供的SDP会话描述来执行中间人攻击。在两个UA的代理直接通信的简单体系结构中，该方法提供的安全性与前面讨论的基于签名的机制提供的安全性大致相当。
Per the normal offer/answer procedures, as soon as the offerer has generated an offer, the offerer must be prepared to receive media in accordance with that offer. The SDP Capability Negotiation preserves that behavior for the actual configuration in the offer; however, the offerer has no way of knowing which configuration (actual or potential) was selected by the answerer, until an answer indication is received. This opens up a new security issue where an attacker
根据正常的报价/答复程序，一旦报价人发出报价，报价人必须准备好根据该报价接受媒体。SDP能力协商为报价中的实际配置保留该行为；但是，在收到应答指示之前，报价人无法知道应答人选择了哪种配置（实际配置或潜在配置）。这打开了一个新的安全问题，攻击者
may be able to interject media towards the offerer until the answer is received. For example, the offerer may use plain RTP as the actual configuration and Secure RTP as an alternative potential configuration. Even though the answerer selects Secure RTP, the offerer will not know that until he receives the answer, and hence an attacker will be able to send media to the offerer meanwhile. The easiest protection against such an attack is to not offer use of the non-secure media stream in the actual configuration; however, that may in itself have undesirable side effects: If the answerer does not support the secure media stream and also does not support the capability negotiation framework, then negotiation of the media stream will fail. Alternatively, SDP security preconditions [RFC5027] can be used. This will ensure that media is not flowing until session negotiation has completed and hence the selected configuration is known. Use of preconditions however requires both sides to support them. If they don't, and use of them is required, the session will fail. As a (limited) work around to this, it is RECOMMENDED that SIP entities generate an answer SDP session description and send it to the offerer as soon as possible, for example, in a 183 Session Progress message. This will limit the time during which an attacker can send media to the offerer. Section 3.9 presents other alternatives as well.
在收到答复之前，可以向报价人插入媒体。例如，报价人可以使用普通RTP作为实际配置，使用安全RTP作为替代潜在配置。即使应答者选择安全RTP，发盘者在收到应答之前不会知道，因此攻击者可以同时向发盘者发送媒体。针对此类攻击的最简单保护是在实际配置中不提供对非安全媒体流的使用；然而，这本身可能有不良的副作用：如果应答者不支持安全媒体流，也不支持能力协商框架，那么媒体流的协商将失败。或者，可以使用SDP安全前提条件[RFC5027]。这将确保在会话协商完成并因此知道所选配置之前，介质不会流动。然而，使用先决条件需要双方的支持。如果没有，并且需要使用它们，会话将失败。作为（有限的）解决方法，建议SIP实体生成应答SDP会话描述，并尽快将其发送给报价人，例如，在183会话进度消息中。这将限制攻击者向报价人发送媒体的时间。第3.9节还介绍了其他备选方案。
Additional security considerations apply to the answer SDP session description as well. The actual configuration attribute tells the offerer on which potential configuration the answer was based, and hence an attacker that can either modify or remove the actual configuration attribute in the answer can cause session failure as well as extend the time window during which the offerer will accept incoming media that does not conform to the actual answer. The solutions to this SDP session description answer integrity problem are the same as for the offer, i.e., use of end-to-end integrity protection, SIP identity, or hop-by-hop protection. The mechanism to use depends on the mechanisms supported by the offerer as well as the acceptable security trade offs.
其他安全注意事项也适用于应答SDP会话描述。“实际配置”属性告诉报价人答案所基于的潜在配置，因此，可以修改或删除应答中的实际配置属性的攻击者可能会导致会话失败，并延长报价人接受不符合实际应答的传入媒体的时间窗口。此SDP会话描述应答完整性问题的解决方案与此产品的解决方案相同，即使用端到端完整性保护、SIP标识或逐跳保护。使用的机制取决于报价人支持的机制以及可接受的安全权衡。
As described in Sections 3.1 and 3.11, SDP Capability Negotiation conceptually allows an offerer to include many different offers in a single SDP session description. This can cause the answerer to process a large number of alternative potential offers, which can consume significant memory and CPU resources. An attacker can use this amplification feature to launch a denial-of-service attack against the answerer. The answerer must protect itself from such attacks. As explained in Section 3.11, the answerer can help reduce the effects of such an attack by first discarding all potential configurations that contain unsupported transport protocols, unsupported or invalid mandatory attribute capabilities, or unsupported mandatory extension configurations. The answerer should
如第3.1节和第3.11节所述，SDP能力协商概念上允许报价人在单个SDP会话描述中包括许多不同的报价。这会导致应答者处理大量可能的备选方案，这会消耗大量内存和CPU资源。攻击者可以使用此放大功能对应答者发起拒绝服务攻击。回答者必须保护自己免受此类攻击。如第3.11节所述，应答者可以通过首先丢弃所有包含不受支持的传输协议、不受支持的或无效的强制属性功能或不受支持的强制扩展配置的潜在配置来帮助减少此类攻击的影响。回答者应该
also look out for potential configurations that are designed to pass the above test, but nevertheless produce a large number of potential configuration SDP session descriptions that cannot be supported.
还应注意设计用于通过上述测试的潜在配置，但仍会产生大量无法支持的潜在配置SDP会话描述。
A possible way of achieving that is for an attacker to find a valid session-level attribute that causes conflicts or otherwise interferes with individual media description configurations. At the time of publication of this document, we do not know of such an SDP attribute; however, this does not mean it does not exist, or that it will not exist in the future. If such attributes are found to exist, implementers should explicitly protect against them.
实现这一点的一种可能方法是，攻击者找到一个有效的会话级别属性，该属性会导致冲突或以其他方式干扰各个媒体描述配置。在本文件发布时，我们不知道此类SDP属性；然而，这并不意味着它不存在，也不意味着它将来将不存在。如果发现存在这样的属性，那么实现者应该明确地针对它们进行保护。
A significant number of valid and supported potential configurations may remain. However, since all of those contain only valid and supported transport protocols and attributes, it is expected that only a few of them will need to be processed on average. Still, the answerer must ensure that it does not needlessly consume large amounts of memory or CPU resources when processing those as well as be prepared to handle the case where a large number of potential configurations still need to be processed.
可能会保留大量有效且受支持的潜在配置。但是，由于所有这些都只包含有效且受支持的传输协议和属性，因此平均而言，预计只需要处理其中的少数协议和属性。尽管如此，应答者必须确保在处理这些配置时不会不必要地消耗大量内存或CPU资源，并准备好处理仍需要处理大量潜在配置的情况。
The IANA has registered the following new SDP attributes:
IANA已注册以下新的SDP属性：
Attribute name: csup Long form name: Supported capability negotiation extensions Type of attribute: Session-level and media-level Subject to charset: No Purpose: Option tags for supported SDP Capability Negotiation extensions Appropriate values: See Section 3.3.1 of RFC 5939 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名称：csup长格式名称：支持的功能协商扩展属性类型：会话级别和媒体级别取决于字符集：无用途：支持的SDP功能协商扩展的选项标记适当值：请参阅RFC 5939第3.3.1节联系人姓名：Flemming Andreasen，fandreas@cisco.com
Attribute name: creq Long form name: Required capability negotiation extensions Type of attribute: Session-level and media-level Subject to charset: No Purpose: Option tags for required SDP Capability Negotiation extensions Appropriate values: See Section 3.3.2 of RFC 5939 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名称：creq长格式名称：所需能力协商扩展属性类型：会话级别和媒体级别取决于字符集：无用途：所需SDP能力协商扩展的选项标签适当值：请参阅RFC 5939第3.3.2节联系人姓名：Flemming Andreasen，fandreas@cisco.com
Attribute name: acap Long form name: Attribute capability Type of attribute: Session-level and media-level Subject to charset: No Purpose: Attribute capability containing an attribute name and associated value Appropriate values: See Section 3.4.1 of RFC 5939 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名称：acap长格式名称：属性功能属性类型：会话级别和媒体级别取决于字符集：无用途：包含属性名称和相关值的属性功能适当值：参见RFC 5939第3.4.1节联系人姓名：Flemming Andreasen，fandreas@cisco.com
Attribute name: tcap Long form name: Transport Protocol Capability Type of attribute: Session-level and media-level Subject to charset: No Purpose: Transport protocol capability listing one or more transport protocols Appropriate values: See Section 3.4.2 of RFC 5939 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名称：tcap长格式名称：传输协议功能属性类型：会话级别和媒体级别取决于字符集：无目的：传输协议功能列出一个或多个传输协议适当值：参见RFC 5939第3.4.2节联系人姓名：Flemming Andreasen，fandreas@cisco.com
Attribute name: pcfg Long form name: Potential Configuration Type of attribute: Media-level Subject to charset: No Purpose: Potential configuration for SDP Capability Negotiation Appropriate values: See Section 3.5.1 of RFC 5939 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名称：pcfg长格式名称：属性的潜在配置类型：媒体级别取决于字符集：无目的：SDP能力协商的潜在配置适当值：参见RFC 5939第3.5.1节联系人姓名：Flemming Andreasen，fandreas@cisco.com
Attribute name: acfg Long form name: Actual configuration Type of attribute: Media-level Subject to charset: No Purpose: Actual configuration for SDP Capability Negotiation Appropriate values: See Section 3.5.2 of RFC 5939 Contact name: Flemming Andreasen, fandreas@cisco.com
属性名称：acfg长格式名称：属性的实际配置类型：媒体级别取决于字符集：无目的：SDP能力协商的实际配置适当值：参见RFC 5939第3.5.2节联系人姓名：Flemming Andreasen，fandreas@cisco.com
The IANA has created a new SDP Capability Negotiation Option Tag registry. An IANA SDP Capability Negotiation Option Tag registration MUST be documented in an RFC in accordance with the [RFC5226] IETF Review policy. The RFC MUST provide the name of the option tag, a syntax, and a semantic specification of any new SDP attributes and any extensions to the potential configuration ("a=pcfg") and actual configuration ("a=acfg") attributes provided in this document. If the extension defines any new SDP attributes that are intended to be capabilities for use by the capability negotiation framework (e.g., similar to "a=acap"), those capabilities MUST adhere to the
IANA已经创建了一个新的SDP能力协商选项标记注册表。IANA SDP能力协商选项标签注册必须根据[RFC5226]IETF审查政策记录在RFC中。RFC必须提供选项标签的名称、任何新SDP属性的语法和语义规范以及本文档中提供的潜在配置（“a=pcfg”）和实际配置（“a=acfg”）属性的任何扩展。如果扩展定义了任何新的SDP属性，这些属性将作为能力协商框架使用的能力（例如，类似于“a=acap”），则这些能力必须遵守
guidelines provided in Section 3.4.3. Extensions to the potential and actual configuration attributes MUST adhere to the syntax provided in Sections 3.5.1 and 3.5.2.
第3.4.3节中提供的指南。潜在和实际配置属性的扩展必须遵循第3.5.1节和第3.5.2节中提供的语法。
The option tag "cap-v0" is defined in this document, and the IANA has registered this option tag.
本文件中定义了选项标签“cap-v0”，IANA已注册了该选项标签。
6.3. New SDP Capability Negotiation Potential Configuration Parameter Registry
6.3. 新的SDP能力协商潜在配置参数注册表
The IANA has created a new SDP Capability Negotiation Potential Configuration Parameter registry. An IANA SDP Capability Negotiation Potential Configuration registration MUST be documented in an RFC in accordance with the [RFC5226] IETF Review policy. The RFC MUST define the syntax and semantics of each new potential configuration parameter. The syntax MUST adhere to the syntax provided for extensions in Section 3.5.1 and the semantics MUST adhere to the semantics provided for extensions in Section 3.5.1 and 3.5.2. Associated with each registration MUST be the encoding name for the parameter as well as a short descriptive name for it.
IANA已经创建了一个新的SDP能力协商潜在配置参数注册表。根据[RFC5226]IETF审查政策，IANA SDP能力协商潜在配置注册必须记录在RFC中。RFC必须定义每个新潜在配置参数的语法和语义。语法必须遵守第3.5.1节为扩展提供的语法，语义必须遵守第3.5.1节和第3.5.2节为扩展提供的语义。与每个注册关联的必须是参数的编码名称以及简短的描述性名称。
The potential configuration parameters "a" for "attribute" and "t" for "transport protocol" are defined in this document, and the IANA has registered them.
本文件中定义了“属性”的潜在配置参数“a”和“传输协议”的潜在配置参数“t”，IANA已对其进行了注册。
The SDP Capability Negotiation solution defined in this document draws on the overall capability negotiation framework that was defined by [SDPng]. Also, the SDP Capability Negotiation solution 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 here: Francois Audet, John Elwell, Roni Even, Miguel Garcia, Robert Gilman, Cullen Jennings, Jonathan Lennox, Matt Lepinski, Jean-Francois Mule, Joerg Ott, Colin Perkins, Jonathan Rosenberg, Thomas Stach, and Dan Wing.
本文档中定义的SDP能力协商解决方案借鉴了[SDPng]定义的总体能力协商框架。此外，SDP能力协商解决方案深受SDP能力协商设计团队的讨论和工作的影响。以下人员尤其对文件本身或此处定义的解决方案的总体方向提供了有用的意见和建议：弗朗索瓦·奥德特、约翰·埃尔维尔、罗尼·埃文、米格尔·加西亚、罗伯特·吉尔曼、卡伦·詹宁斯、乔纳森·伦诺克斯、马特·莱宾斯基、让·弗朗索瓦·穆尔、约格·奥特、科林·珀金斯、乔纳森·罗森伯格、，托马斯·斯塔斯和丹·温。
General Area review comments were provided by Christian Vogt, and Stephen Kent provided Security Directorate review comments. Eric Rescorla provided textual input to the Security Considerations. Alexey Melnikov, Robert Sparks, and Magnus Westerlund provided several review comments as well.
一般区域审查意见由Christian Vogt提供，Stephen Kent提供安全理事会审查意见。Eric Rescorla为安全注意事项提供了文本输入。Alexey Melnikov、Robert Sparks和Magnus Westerlund也提供了一些评论意见。
[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., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]Camarillo，G.，Ed.，Marshall，W.，Ed.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 32622，2002年6月。
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002.
[RFC3407]Andreasen，F.，“会话描述协议（SDP）简单能力声明”，RFC3407，2002年10月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 41452005年9月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4567]Arkko，J.，Lindholm，F.，Naslund，M.，Norrman，K.，和E.Carrara，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，2006年7月。
[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月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，2006年7月。
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006.
[RFC4756]李安，“会话描述协议中的前向纠错分组语义”，RFC4756，2006年11月。
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5027, October 2007.
[RFC5027]Andreasen，F.和D.Wing，“会话描述协议（SDP）媒体流的安全先决条件”，RFC 5027，2007年10月。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5124]Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 51242008年2月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010.
[RFC5763]Fischl，J.，Tschofenig，H.，和E.Rescorla，“使用数据报传输层安全性（DTLS）建立安全实时传输协议（SRTP）安全上下文的框架”，RFC 5763，2010年5月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，2010年5月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，2010年6月。
[BESRTP] Kaplan, H. and F. Audet, "Session Description Protocol (SDP) Offer/Answer Negotiation For Best-Effort Secure Real-Time Transport Protocol", Work in Progress, October 2006.
[BESRTP]Kaplan，H.和F.Audet，“会话描述协议（SDP）为尽力而为的安全实时传输协议提供/应答协商”，正在进行的工作，2006年10月。
[ICETCP] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, September 2010.
[ICETCP]Rosenberg，J.，Keranen，A.，Lowekamp，B.，和A.Roach，“具有交互式连接建立（ICE）的TCP候选者”，正在进行的工作，2010年9月。
[SDPMedCap] Gilman, R., Even, R., and F. Andreasen, "SDP media capabilities Negotiation", Work in Progress, July 2010.
[SDPMedCap]吉尔曼，R.，伊恩，R.，和F.安德里亚森，“SDP媒体能力谈判”，正在进行的工作，2010年7月。
[SDPng] Kutscher, D., Ott, J., and C. Bormann, "Session Description and Capability Negotiation", Work in Progress, February 2005.
[SDPng]Kutscher，D.，Ott，J.，和C.Bormann，“会话描述和能力协商”，正在进行的工作，2005年2月。
Author's Address
作者地址
Flemming Andreasen Cisco Systems Iselin, NJ 08830 USA
弗莱明·安德烈森思科系统公司，美国新泽西州伊塞林08830
EMail: fandreas@cisco.com
EMail: fandreas@cisco.com