Internet Engineering Task Force (IETF) M. Garcia-Martin
Request for Comments: 7006 Ericsson
Category: Standards Track S. Veikkolainen
ISSN: 2070-1721 Nokia
R. Gilman
September 2013
Internet Engineering Task Force (IETF) M. Garcia-Martin
Request for Comments: 7006 Ericsson
Category: Standards Track S. Veikkolainen
ISSN: 2070-1721 Nokia
R. Gilman
September 2013
Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)
会话描述协议（SDP）中的其他功能协商
Abstract
摘要
The Session Description Protocol (SDP) has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely used SDP offer/answer procedures.
会话描述协议（SDP）已通过一个能力协商机制框架进行了扩展，该框架允许端点协商传输协议和属性。此框架已通过媒体功能协商机制进行了扩展，该机制允许端点协商其他媒体相关功能。这种协商被嵌入广泛使用的SDP报价/应答程序中。
This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ("b=" line), connection data ("c=" line), and session or media titles ("i=" line for each session or media).
此备忘录扩展了SDP能力协商框架，允许端点协商三个额外的SDP能力。特别是，此备忘录提供了协商带宽（“b=”line）、连接数据（“c=”line）和会话或媒体标题（“i=”每个会话或媒体的行”）的机制。
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/rfc7006.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7006.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Protocol Description ............................................4
3.1. Extensions to SDP ..........................................4
3.1.1. Bandwidth Capability ................................6
3.1.2. Connection Data Capability ..........................8
3.1.3. Title Capability ...................................12
3.2. Session Level versus Media Level ..........................16
3.3. Offer/Answer Model Extensions .............................17
3.3.1. Generating the Initial Offer .......................17
3.3.2. Generating the Answer ..............................17
3.3.3. Offerer Processing of the Answer ...................18
3.3.4. Modifying the Session ..............................18
4. Field Replacement Rules ........................................18
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
6.1. New SDP Attributes ........................................19
6.2. New Option Tags ...........................................20
6.3. New SDP Capability Negotiation Configuration Parameters ...20
7. Acknowledgments ................................................20
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................21
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Protocol Description ............................................4
3.1. Extensions to SDP ..........................................4
3.1.1. Bandwidth Capability ................................6
3.1.2. Connection Data Capability ..........................8
3.1.3. Title Capability ...................................12
3.2. Session Level versus Media Level ..........................16
3.3. Offer/Answer Model Extensions .............................17
3.3.1. Generating the Initial Offer .......................17
3.3.2. Generating the Answer ..............................17
3.3.3. Offerer Processing of the Answer ...................18
3.3.4. Modifying the Session ..............................18
4. Field Replacement Rules ........................................18
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
6.1. New SDP Attributes ........................................19
6.2. New Option Tags ...........................................20
6.3. New SDP Capability Negotiation Configuration Parameters ...20
7. Acknowledgments ................................................20
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................21
The Session Description Protocol (SDP) [RFC4566] is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP has been extended with an SDP Capability Negotiation Mechanism Framework [RFC5939] that allows the endpoints to negotiate capabilities, such as support for the Real-time Transport Protocol (RTP) [RFC3550] and the Secure Real-time Transport Protocol (SRTP) [RFC3711]. The SDP Media Capabilities Negotiation [RFC6871] provides negotiation capabilities to media lines as well.
会话描述协议（SDP）[RFC4566]旨在描述多媒体会话，用于会话公告、会话邀请和其他形式的多媒体会话启动。SDP已通过SDP能力协商机制框架[RFC5939]进行了扩展，该框架允许端点协商能力，例如支持实时传输协议（RTP）[RFC3550]和安全实时传输协议（SRTP）[RFC3711]。SDP媒体能力协商[RFC6871]也为媒体线路提供协商能力。
The capability negotiation is embedded into the widely used SDP offer/answer procedure [RFC3264]. This memo provides the means to negotiate further capabilities than those specified in the SDP Capability Negotiation Mechanism Framework [RFC5939] and the SDP Media Capabilities Negotiation [RFC6871]. In particular, this memo provides a mechanism to negotiate bandwidth ("b="), connection data ("c="), and session or media titles ("i=").
能力协商嵌入到广泛使用的SDP提供/应答过程[RFC3264]中。本备忘录提供了协商SDP能力协商机制框架[RFC5939]和SDP媒体能力协商[RFC6871]中规定的能力以外的其他能力的方法。特别是，此备忘录提供了协商带宽（“b=”）、连接数据（“c=”）和会话或媒体标题（“i=”）的机制。
Since the three added capabilities are independent, it is not expected that implementations will necessarily support all of them at the same time. Instead, it is expected that applications will choose their needed capability for their specific purpose. For this reason, the normative part pertaining to each capability is in a self-contained section: Section 3.1.1 describes the bandwidth capability extension, Section 3.1.2 describes the connection data capability extension, and Section 3.1.3 describes the title capability extension. Separate SDP Capability Negotiation option tags are defined for each capability, allowing endpoints to indicate and/or require support for these extensions according to procedures defined in SDP Capability Negotiation [RFC5939].
由于这三个新增功能是独立的，因此不希望实现同时支持所有功能。相反，预期应用程序将为其特定目的选择所需的功能。因此，与每个能力相关的规范性部分在一个独立的章节中：第3.1.1节描述带宽能力扩展，第3.1.2节描述连接数据能力扩展，第3.1.3节描述标题能力扩展。为每个功能定义单独的SDP功能协商选项标记，允许端点根据SDP功能协商[RFC5939]中定义的过程指示和/或要求支持这些扩展。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的描述进行解释，并指出合规实施的要求级别。
The SDP Capability Negotiation Framework [RFC5939] and the SDP Media Capabilities Negotiation [RFC6871] specify attributes for negotiating SDP capabilities. These documents specify new attributes (e.g., "acap", "tcap", "rmcap", and "omcap") for achieving their purpose. In this document, we define three new additional capability attributes for SDP lines of the general form:
SDP能力协商框架[RFC5939]和SDP媒体能力协商[RFC6871]指定协商SDP能力的属性。这些文件规定了实现其目的的新属性（例如，“acap”、“tcap”、“rmcap”和“omcap”）。在本文档中，我们为一般形式的SDP行定义了三个新的附加功能属性：
type=value
类型=值
for types "b", "c", and "i". The corresponding capability attributes are respectively defined as:
对于类型“b”、“c”和“i”。相应的能力属性分别定义为：
o "bcap": bandwidth capability
o “bcap”：带宽能力
o "ccap": connection data capability
o “ccap”：连接数据能力
o "icap": title capability
o “icap”：标题能力
From the sub-rules of the attribute ("a=") line in SDP [RFC4566], SDP attributes are of the form:
根据SDP[RFC4566]中属性（“a=”）行的子规则，SDP属性的形式如下：
attribute = (att-field ":" att-value) / att-field
att-field = token
att-value = byte-string
attribute = (att-field ":" att-value) / att-field
att-field = token
att-value = byte-string
Capability attributes use only the "att-field:att-value" form.
能力属性仅使用“att字段：att值”表格。
The new capabilities may be referenced in potential configurations ("a=pcfg") or in latent configurations ("a=lcfg") as productions conforming to the <extension-config-list>, as respectively defined in RFC 5939 [RFC5939] and RFC 6871 [RFC6871].
新功能可在潜在配置（“a=pcfg”）或潜在配置（“a=lcfg”）中引用为符合《扩展配置列表》的产品，分别在RFC 5939[RFC5939]和RFC 6871[RFC6871]中定义。
extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT)
; ALPHA and DIGIT defined in RFC 5234
ext-cap-list = 1*VCHAR ; VCHAR defined in RFC 5234
extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT)
; ALPHA and DIGIT defined in RFC 5234
ext-cap-list = 1*VCHAR ; VCHAR defined in RFC 5234
The optional "+" is used to indicate that the extension is mandatory and MUST be supported in order to use that particular configuration.
可选的“+”用于指示扩展是必需的，并且必须得到支持才能使用该特定配置。
The new capabilities may also be referenced in actual configurations ("a=acfg") as productions conforming to the <sel-extension-config> defined in RFC 5939 [RFC5939].
新功能也可在实际配置（“a=acfg”）中引用为符合RFC 5939[RFC5939]中定义的<sel扩展配置>的产品。
sel-extension-config = ext-cap-name "=" 1*VCHAR
sel-extension-config = ext-cap-name "=" 1*VCHAR
The specific parameters are defined in the individual description of each capability below.
具体参数在以下每个功能的单独描述中定义。
The "bcap", "ccap", and "icap" capability attributes can be provided at the SDP session and/or media level. According to the SDP Capability Negotiation [RFC5939], each extension capability must specify the implication of making it part of a configuration at the media level.
“bcap”、“ccap”和“icap”能力属性可在SDP会话和/或媒体级别提供。根据SDP能力协商[RFC5939]，每个扩展能力必须指定使其成为媒体级配置一部分的含义。
According to SDP [RFC4566], "b=", "c=", and "i=" lines may appear at either session or media level. In line with this, the "bcap", "ccap", and "icap" capability attributes, when declared at session level, are to be interpreted as if that attribute was provided with that value at the session level. The "bcap", "ccap", and "icap" capability attributes declared at media level are to be interpreted as if that capability attribute was declared at the media level.
根据SDP[RFC4566]，“b=”、“c=”和“i=”行可能出现在会话或媒体级别。与此相一致，“bcap”、“ccap”和“icap”能力属性在会话级别声明时，将被解释为该属性在会话级别具有该值。在媒体级别声明的“bcap”、“ccap”和“icap”能力属性将被解释为该能力属性是在媒体级别声明的。
For example, extending the example in [RFC6871] with "icap" and "bcap" capability attributes, we get the following SDP:
例如，使用“icap”和“bcap”能力属性扩展[RFC6871]中的示例，我们得到以下SDP：
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=bcap:1 CT:200
a=icap:1 Video conference
m=audio 54320 RTP/AVP 0
a=rmcap:1 L16/8000/1
a=rmcap:2 L16/16000/2
a=pcfg:1 m=1|2 pt=1:99,2:98
m=video 66544 RTP/AVP 100
a=rmcap:3 H263-1998/90000
a=rtpmap:100 H264/90000
a=pcfg:10 m=3 pt=3:101 b=1 i=1
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=bcap:1 CT:200
a=icap:1 Video conference
m=audio 54320 RTP/AVP 0
a=rmcap:1 L16/8000/1
a=rmcap:2 L16/16000/2
a=pcfg:1 m=1|2 pt=1:99,2:98
m=video 66544 RTP/AVP 100
a=rmcap:3 H263-1998/90000
a=rtpmap:100 H264/90000
a=pcfg:10 m=3 pt=3:101 b=1 i=1
Figure 1: Example SDP offer with bcap and icap efined at session level
图1：在会话级别定义bcap和icap的示例SDP提供
The above SDP defines one PCMU audio stream and one H.264 video stream. It also defines two RTP-based media capabilities ("rmcap" numbered 1 and 2), using 16-bit linear (L16) audio at 8 kbps and 16 kbps, respectively, as well as an RTP-based media capability for H.263 video ("rmcap" numbered 3). The RTP-based media capabilities all appear at the media level. The example also contains a single bandwidth capability ("bcap") and a single title capability ("icap"), both defined at session level. According to the definition above, when the capabilities defined in the "bcap" and "icap" attributes are referenced from the potential configuration, in the resulting SDP they are to be interpreted as session-level attributes (but the RTP-based media capabilities are to be interpreted as media-level attributes).
上述SDP定义了一个PCMU音频流和一个H.264视频流。它还定义了两种基于RTP的媒体功能（“rmcap”编号1和2），分别使用8 kbps和16 kbps的16位线性（L16）音频，以及用于H.263视频的基于RTP的媒体功能（“rmcap”编号3）。基于RTP的媒体功能都出现在媒体级别。该示例还包含单个带宽能力（“bcap”）和单个标题能力（“icap”），两者都是在会话级别定义的。根据上述定义，当从潜在配置引用“bcap”和“icap”属性中定义的功能时，在生成的SDP中，它们将被解释为会话级属性（但基于RTP的媒体功能将被解释为媒体级属性）。
According to RFC 4566 [RFC4566], the bandwidth field denotes the proposed bandwidth to be used by the session or media. In this memo, we specify the bandwidth capability attribute, which can also appear at the SDP session and/or media level. The bandwidth field is specified in RFC 4566 [RFC4566] with the following syntax:
根据RFC 4566[RFC4566]，带宽字段表示会话或媒体使用的建议带宽。在此备忘录中，我们指定带宽能力属性，该属性也可以出现在SDP会话和/或媒体级别。RFC 4566[RFC4566]中使用以下语法指定带宽字段：
b=<bwtype>:<bandwidth>
b=<bwtype>:<bandwidth>
where <bwtype> is an alphanumeric modifier giving the meaning of the <bandwidth> figure.
其中<bwtype>是一个字母数字修饰符，表示<bandwidth>图形的含义。
In this document, we define a new capability attribute: the bandwidth capability attribute "bcap". This attribute lists bandwidth as capabilities, according to the following definition:
在本文中，我们定义了一个新的能力属性：带宽能力属性“bcap”。根据以下定义，此属性将带宽列为功能：
"a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF
"a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF
where <bw-cap-num> is a unique integer within all the bandwidth capabilities in the entire SDP, which is used to number the bandwidth capability and can take a value between 1 and 2^31-1 (both included). The other elements are as defined for the "b=" field in SDP [RFC4566].
其中，<bw cap num>是整个SDP中所有带宽能力内的唯一整数，用于对带宽能力进行编号，取值范围为1到2^31-1（均包括在内）。其他元素的定义与SDP[RFC4566]中的“b=”字段相同。
This format satisfies the general attribute production rules in SDP [RFC4566], according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
此格式符合SDP[RFC4566]中的一般属性生成规则，符合以下扩充的巴科斯诺尔形式（ABNF）[RFC5234]语法：
att-field =/ "bcap"
att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
att-field =/ "bcap"
att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
Figure 2: Syntax of the "bcap" attribute
图2：“bcap”属性的语法
Negotiation of bandwidth per media stream can be useful when negotiating media encoding capabilities with different bandwidths.
当协商具有不同带宽的媒体编码能力时，每个媒体流的带宽协商可能很有用。
The SDP Capability Negotiation Framework [RFC5939] provides for the existence of the "pcfg" and "acfg" attributes. The concept is extended by the SDP Media Capabilities Negotiation [RFC6871] with an "lcfg" attribute that conveys latent configurations.
SDP能力协商框架[RFC5939]规定存在“pcfg”和“acfg”属性。SDP媒体能力协商[RFC6871]扩展了该概念，该协商具有“lcfg”属性，可传达潜在配置。
Extensions to the "pcfg" and "lcfg" attributes are defined through <extension-config-list>, and extensions to the "acfg" attribute are defined through the <sel-extension-config>, as defined in the SDP Capability Negotiation [RFC5939].
“pcfg”和“lcfg”属性的扩展通过<extension config list>定义，“acfg”属性的扩展通过<sel extension config>定义，如SDP能力协商[RFC5939]中所定义。
In this document, we extend the <extension-config-list> field to be able to convey lists of bandwidth capabilities in latent or potential configurations, according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
在本文档中，我们扩展了<extension config list>字段，以便能够根据以下扩展的Backus Naur Form（ABNF）[RFC5234]语法传达潜在或潜在配置中的带宽能力列表：
extension-config-list =/ bandwidth-config-list
bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR bw-cap-list)
; BAR defined in RFC 5939
bw-cap-list = bw-cap-num *("," bw-cap-num)
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
extension-config-list =/ bandwidth-config-list
bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR bw-cap-list)
; BAR defined in RFC 5939
bw-cap-list = bw-cap-num *("," bw-cap-num)
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
Figure 3: Syntax of the bandwidth parameter in "lcfg" and "pcfg" attributes
图3：“lcfg”和“pcfg”属性中带宽参数的语法
Each bandwidth capability configuration is a comma-separated list of bandwidth capability attribute numbers where <bw-cap-num> refers to the <bw-cap-num> bandwidth capability numbers defined explicitly earlier in this document, and hence MUST be between 1 and 2^31-1 (both included). Alternative bandwidth configurations are separated by a vertical bar ("|").
每个带宽能力配置都是一个以逗号分隔的带宽能力属性编号列表，其中<bw cap num>指的是本文档前面明确定义的<bw cap num>带宽能力编号，因此必须介于1和2^31-1之间（均包括在内）。可选带宽配置由垂直条（“|”）分隔。
The above syntax is very flexible, allowing referencing to multiple "b=" lines per configuration, even for the same <bwtype>. While the need for such definitions is not seen, we have not restricted this, as it is not restricted in SDP [RFC4566] either.
上面的语法非常灵活，允许每个配置引用多个“b=”行，即使对于相同的<bwtype>。虽然没有看到对此类定义的需要，但我们没有对其进行限制，因为SDP[RFC4566]中也没有对其进行限制。
The bandwidth parameter to the actual configuration attribute
("a=acfg") is formulated as a <sel-extension-config> with
The bandwidth parameter to the actual configuration attribute
("a=acfg") is formulated as a <sel-extension-config> with
ext-cap-name = "b"
ext-cap-name = "b"
hence
因此
sel-extension-config =/ sel-bandwidth-config sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above.
sel扩展配置=/sel带宽配置sel带宽配置=“b=”bw上限列表；bw上限列表如上所述。
Figure 4: Syntax of the bandwidth parameter in "acfg" attributes
图4：“acfg”属性中带宽参数的语法
The SDP Capability Negotiation Framework [RFC5939] allows for capability negotiation extensions to be defined. Associated with each such extension is an option tag that identifies the extension in question. Hereby, we define a new option tag "bcap-v0" that identifies support for the bandwidth capability. The endpoints using the "bcap" capability attribute SHOULD add the option tag to other existing option tags present in the "csup" and "creq" attributes in SDP, according to the procedures defined in the SDP Capability Negotiation Framework [RFC5939].
SDP能力协商框架[RFC5939]允许定义能力协商扩展。与每个这样的扩展相关联的是一个选项标记，用于标识有问题的扩展。在此，我们定义了一个新的选项标签“bcap-v0”，用于标识对带宽能力的支持。根据SDP能力协商框架[RFC5939]中定义的程序，使用“bcap”能力属性的端点应将选项标记添加到SDP中“csup”和“creq”属性中的其他现有选项标记中。
According to SDP [RFC4566], the connection data field in SDP contains the connection data, and it has the following syntax:
根据SDP[RFC4566]，SDP中的连接数据字段包含连接数据，并且具有以下语法：
c=<nettype> <addrtype> <connection-address>
c=<nettype> <addrtype> <connection-address>
where <nettype> indicates the network type, <addrtype> indicates the address type, and the <connection-address> is the connection address, which is dependent on the address type.
其中<nettype>表示网络类型，<addrtype>表示地址类型，<connection address>表示连接地址，这取决于地址类型。
At the moment, network types already defined include "IN", which indicates Internet network type, and "ATM" (see RFC 3108 [RFC3108]), used for describing Asynchronous Transfer Mode (ATM) bearer connections. The Circuit-Switched (CS) descriptions in the SDP document [SDP-CS] adds a "PSTN" network type for expressing a Public Switched Telephone Network (PSTN) circuit switch.
目前，已经定义的网络类型包括“IN”（表示Internet网络类型）和“ATM”（参见RFC 3108[RFC3108]），用于描述异步传输模式（ATM）承载连接。SDP文档[SDP-CS]中的电路交换（CS）描述添加了“PSTN”网络类型，用于表示公共交换电话网（PSTN）电路交换机。
SDP [RFC4566] permits specification of connection data at the SDP session and/or media level. In order to permit negotiation of connection data at the media level, we define the connection data capability attribute ("a=ccap") in the form:
SDP[RFC4566]允许在SDP会话和/或媒体级别指定连接数据。为了允许在媒体级别协商连接数据，我们定义了连接数据能力属性（“a=ccap”）：
"a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP connection-address CRLF
“a=ccap:“连接帽编号1*WSP网络类型SP地址类型SP连接地址CRLF”
where <conn-cap-num> is a unique integer within all the connection capabilities in the entire SDP, which is used to identify the connection data capability and can take a value between 1 and 2^31-1 (both included). The other elements are as defined in [RFC4566].
其中，<conn cap num>是整个SDP中所有连接功能中的唯一整数，用于标识连接数据功能，可以取1到2^31-1之间的值（两者都包括）。其他元素如[RFC4566]中所定义。
This format corresponds to the [RFC4566] attribute production rules, according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
此格式对应于[RFC4566]属性产生式规则，符合以下扩充的巴科斯诺尔形式（ABNF）[RFC5234]语法：
att-field =/ "ccap"
att-value =/ conn-cap-num 1*WSP nettype SP addrtype
SP connection-address
conn-cap-num = 1*10(DIGIT) ; 1 to 2^31-1, inclusive
; DIGIT defined in RFC 5234
att-field =/ "ccap"
att-value =/ conn-cap-num 1*WSP nettype SP addrtype
SP connection-address
conn-cap-num = 1*10(DIGIT) ; 1 to 2^31-1, inclusive
; DIGIT defined in RFC 5234
Figure 5: Syntax of the "ccap" attribute
图5：“ccap”属性的语法
The "ccap" capability attribute allows for expressing alternative connections address ("c=") lines in SDP as part of the SDP Capability Negotiation process. One of the primary use cases for this is offering alternative connection addresses where the <nettype> is "IN" or "PSTN", i.e., selecting between an IP-based bearer or a circuit-switched bearer.
“ccap”能力属性允许在SDP中表达备用连接地址（“c=”）行，作为SDP能力协商过程的一部分。这方面的一个主要用例是在<nettype>为“IN”或“PSTN”的情况下提供备选连接地址，即在基于IP的承载或电路交换的承载之间进行选择。
By supporting the "IN" <nettype>, the "ccap" attribute enables the signaling of multiple IPv4 and IPv6 addresses; however, the Standards Track mechanism for negotiation of alternative IP addresses in SDP is Interactive Connectivity Establishment (ICE) [RFC5245]. The "ccap" attribute does not change that; hence, the combined set of actual and potential configurations (as defined in [RFC5939]) for any given media description MUST NOT use the "ccap" attribute to negotiate more than one address with an IN network type (i.e., it is not permissible to select between "IPv4" and "IPv6" address families or different IP addresses within the same IP address family.
通过支持“IN”<nettype>，“ccap”属性支持多个IPv4和IPv6地址的信令；然而，SDP中备用IP地址协商的标准跟踪机制是交互式连接建立（ICE）[RFC5245]。“ccap”属性不会改变这一点；因此，任何给定媒体描述的实际和潜在配置组合（如[RFC5939]中所定义）不得使用“ccap”属性与网络内类型协商多个地址（即，不允许在“IPv4”和“IPv6”之间进行选择）地址系列或同一IP地址系列中的不同IP地址。
Figure 6 is an example of an SDP offer that includes a "ccap" capability attribute. An audio stream can be set up with an RTP flow or by establishing a circuit-switched audio stream:
图6是包含“ccap”能力属性的SDP产品的示例。可以使用RTP流或通过建立电路交换音频流来设置音频流：
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
a=creq:med-v0,ccap-v0
m=audio 38902 RTP/AVP 0 8
c=IN IP4 198.51.100.7
a=ccap:1 PSTN E164 +15555556666
a=tcap:2 PSTN
a=omcap:1 -
a=acap:1 setup:actpass
a=acap:2 connection:new
a=acap:3 cs-correlation:callerid:+15555556666
a=pcfg:1 c=1 t=2 m=1 a=1,2,3
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
a=creq:med-v0,ccap-v0
m=audio 38902 RTP/AVP 0 8
c=IN IP4 198.51.100.7
a=ccap:1 PSTN E164 +15555556666
a=tcap:2 PSTN
a=omcap:1 -
a=acap:1 setup:actpass
a=acap:2 connection:new
a=acap:3 cs-correlation:callerid:+15555556666
a=pcfg:1 c=1 t=2 m=1 a=1,2,3
Figure 6: Example SDP offer with a "ccap" attribute
图6：带有“ccap”属性的示例SDP产品
The example in Figure 6 represents an SDP offer indicating an audio flow using RTP, such as the one represented in Figure 7, or an audio flow using a circuit-switched connection, such as the one represented in Figure 8.
图6中的示例表示SDP提供，指示使用RTP的音频流（如图7所示）或使用电路交换连接的音频流（如图8所示）。
v=0 o=2987933123 2987933123 IN IP4 198.51.100.7 s=- t=0 0 m=audio 38902 RTP/AVP 0 8 c=IN IP4 198.51.100.7
v=0 o=2987933123 IP4 198.51.100.7中的2987933123 s=-t=0 0 m=IP4 198.51.100.7中的音频38902 RTP/AVP 0 8 c=
Figure 7: Equivalent SDP offer with the RTP flow
图7:RTP流的等效SDP提供
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
m=audio 9 PSTN -
c=PSTN E164 +15555556666
a=setup:actpass
a=connection:new
a=cs-correlation:callerid:+15555556666
v=0
o=2987933123 2987933123 IN IP4 198.51.100.7
s=-
t=0 0
m=audio 9 PSTN -
c=PSTN E164 +15555556666
a=setup:actpass
a=connection:new
a=cs-correlation:callerid:+15555556666
Figure 8: Equivalent SDP offer with the circuit-switched flow
图8：电路切换流的等效SDP方案
This document does not define any mechanism for negotiating or describing different port numbers; hence, the port number from the "m=" line MUST be used by default. Exceptions to this default can be provided by extension mechanisms or network type specific rules. This document defines an exception when the network type is "PSTN",
本文件未定义协商或描述不同端口号的任何机制；因此，默认情况下必须使用“m=”行中的端口号。扩展机制或特定于网络类型的规则可以提供此默认值的例外情况。本文档定义了网络类型为“PSTN”时的例外情况，
in which case the port number is replaced with 9 (the "discard" port), as described in "Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)" [SDP-CS]. An endpoint offering alternative IP and PSTN bearers MUST include the IP media description in the actual configuration (IP address in the "c=" line and port number in the "m=" line) and the PSTN media description in the potential configuration.
在这种情况下，端口号替换为9（“丢弃”端口），如“公共交换电话网（PSTN）中通过电路交换承载设置音频和视频媒体流的会话描述协议（SDP）扩展”[SDP-CS]所述。提供备用IP和PSTN承载的端点必须在实际配置中包含IP媒体描述（“c=”行中的IP地址和“m=”行中的端口号），并在潜在配置中包含PSTN媒体描述。
Exceptions for other network types, such as for the "ATM" network type defined in [RFC3108], require additional specifications.
其他网络类型的例外情况，如[RFC3108]中定义的“ATM”网络类型，需要额外的规范。
The SDP Capability Negotiation Framework [RFC5939] provides for the existence of the "pcfg" and "acfg" attributes, which can convey one or more configurations to be negotiated. The concept is extended by the SDP Media Capabilities Negotiation [RFC6871] with an "lcfg" attribute that conveys latent configurations.
SDP能力协商框架[RFC5939]规定了“pcfg”和“acfg”属性的存在，这些属性可以传递一个或多个要协商的配置。SDP媒体能力协商[RFC6871]扩展了该概念，该协商具有“lcfg”属性，可传达潜在配置。
In this document, we define a <connection-config> parameter to be used to specify a connection data capability in a potential or latent configuration attribute. The parameter follows the form of an <extension-config-list> with
在本文档中，我们定义了一个<connection config>参数，用于指定潜在或潜在配置属性中的连接数据功能。该参数遵循<extension config list>的形式，带有
ext-cap-name = "c"
ext-cap-name = "c"
ext-cap-list = conn-cap-list
ext-cap-list = conn-cap-list
where, according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
其中，根据以下扩充的巴科斯诺尔形式（ABNF）[RFC5234]语法：
extension-config-list =/ conn-config-list
conn-config-list = ["+"] "c=" conn-cap-list
conn-cap-list = conn-cap-num *(BAR conn-cap-num)
conn-cap-num = 1*10(DIGIT) ; 1 to 2^32-1 inclusive
extension-config-list =/ conn-config-list
conn-config-list = ["+"] "c=" conn-cap-list
conn-cap-list = conn-cap-num *(BAR conn-cap-num)
conn-cap-num = 1*10(DIGIT) ; 1 to 2^32-1 inclusive
Figure 9: Syntax of the connection data parameter in "lcfg" and "pcfg" attributes
图9：“lcfg”和“pcfg”属性中连接数据参数的语法
Each capability configuration alternative contains a single connection data capability attribute number and refers to the conn-cap-num capability number defined explicitly earlier in this document; hence, the values MUST be between 1 and 2^31-1 (both included). The connection data capability allows the expression of only a single capability in each alternative, rather than a list of capabilities, since no more than a single connection data field is
每个能力配置备选方案包含一个连接数据能力属性号，并引用本文件前面明确定义的conn cap num能力号；因此，值必须介于1和2^31-1之间（均包括在内）。连接数据功能只允许在每个备选方案中表达一个功能，而不是一个功能列表，因为只需要一个连接数据字段
permitted per media block. Nevertheless, it is still allowed to express alternative potential connection configurations separated by a vertical bar ("|").
允许每个媒体块使用。尽管如此，仍允许表示由竖条（“|”）分隔的备选潜在连接配置。
An endpoint includes a plus sign ("+") in the configuration attribute to mandate support for this extension. An endpoint that receives this parameter prefixed with a plus sign and does not support this extension MUST treat that potential configuration as not valid.
端点在配置属性中包含加号（“+”），以强制支持此扩展。接收以加号为前缀的此参数且不支持此扩展的端点必须将该潜在配置视为无效。
The connection data parameter to the actual configuration attribute
("a=acfg") is formulated as a <sel-extension-config> with
The connection data parameter to the actual configuration attribute
("a=acfg") is formulated as a <sel-extension-config> with
ext-cap-name = "c"
ext-cap-name = "c"
hence
因此
sel-extension-config =/ sel-connection-config sel-connection-config = "c=" conn-cap-num ; as defined above.
sel extension config=/sel connection config sel connection config=“c=”conn cap num；如上所述。
Figure 10: Syntax of the connection data parameter in "acfg" attributes
图10：“acfg”属性中连接数据参数的语法
The SDP Capability Negotiation Framework [RFC5939] solution allows for capability negotiation extensions to be defined. Associated with each such extension is an option tag that identifies the extension in question. Hereby, we define a new option tag of "ccap-v0" that identifies support for the connection data capability. This option tag SHOULD be added to other existing option tags present in the "csup" and "creq" attributes in SDP, according to the procedures defined in the SDP Capability Negotiation Framework [RFC5939].
SDP能力协商框架[RFC5939]解决方案允许定义能力协商扩展。与每个这样的扩展相关联的是一个选项标记，用于标识有问题的扩展。在此，我们定义了一个新的选项标签“ccap-v0”，用于标识对连接数据能力的支持。根据SDP能力协商框架[RFC5939]中定义的程序，该选项标签应添加到SDP中“csup”和“creq”属性中存在的其他现有选项标签中。
SDP [RFC4566] provides for the existence of an information field expressed in the format of the "i=" line, which can appear at the SDP session and/or media level. An "i=" line that is present at the session level is known as the "session name", and its purpose is to convey human-readable textual information about the session.
SDP[RFC4566]规定存在一个以“i=”行格式表示的信息字段，该字段可以出现在SDP会话和/或媒体级别。会话级别上出现的“i=”行称为“会话名称”，其目的是传递有关会话的可读文本信息。
The "i=" line in SDP can also appear at the media level, in which case it is used to provide human-readable information about the media stream to which it is related; for example, it may indicate the purpose of the media stream. The "i=" line is not to be confused with the label attribute ("a=label:", [RFC4574]), which provides a machine-readable tag. It is foreseen that applications declaring capabilities related to different configurations of a media stream
SDP中的“i=”行也可以出现在媒体级别，在这种情况下，它用于提供与之相关的媒体流的可读信息；例如，它可以指示媒体流的目的。“i=”行不能与label属性（“a=label:，[RFC4574]）混淆，后者提供了一个机器可读的标记。可以预见，应用程序声明与媒体流的不同配置相关的能力
may need to provide different identifying information for each of those configurations. That is, a party might offer alternative media configurations for a stream, each of which represents a different presentation of the same or similar information. For example, an audio stream might offer English or Spanish configurations, or a video stream might offer a choice of video source such as speaker camera, group camera, or document viewer. The title capability is needed to inform the answering user in order to select the proper choice, and the label is used to inform the offering machine which choice the answerer has selected. Hence, there is value in defining a mechanism to provide titles of media streams as capabilities.
可能需要为每个配置提供不同的标识信息。也就是说，一方可以为流提供备选媒体配置，每个媒体配置表示相同或类似信息的不同表示。例如，音频流可以提供英语或西班牙语配置，或者视频流可以提供视频源的选择，例如扬声器摄像机、组摄像机或文档查看器。标题功能需要通知应答用户以选择正确的选项，标签用于通知应答机应答者选择了哪个选项。因此，定义一种机制以提供媒体流标题作为功能是有价值的。
As defined in SDP [RFC4566], the session information field ("i=", referred to as "title" in this document) is subject to the "a=charset" attribute in order to support different character sets and hence internationalization. The title capability attribute itself ("a=icap") is, however, not subject to the "a=charset" attribute as this would preclude the inclusion of alternative session/title information each using different character sets. Instead, the session/title value embedded in an "a=icap" attribute (title capability) will be subject to the "a=charset" value used within a configuration that includes that title capability. This provides for consistent SDP operation while allowing for capabilities and configurations with different session/title information values with different character set encodings (with each such configuration including an "a=charset" value with the relevant character set for the session/title information in question).
如SDP[RFC4566]中所定义，会话信息字段（“i=”，在本文档中称为“title”）受“a=charset”属性的约束，以支持不同的字符集，从而支持国际化。但是，“标题能力”属性本身（“a=icap”）不受“a=charset”属性的约束，因为这将排除包含每个使用不同字符集的备选会话/标题信息。相反，嵌入在“a=icap”属性（标题功能）中的会话/标题值将受制于包含该标题功能的配置中使用的“a=charset”值。这提供了一致的SDP操作，同时允许功能和配置具有不同的会话/标题信息值和不同的字符集编码（每个这样的配置包括一个“a=charset”值和相关的会话/标题信息字符集）。
According to SDP [RFC4566], the session information ("i=") line has the following syntax:
根据SDP[RFC4566]，会话信息（“i=”）行具有以下语法：
"i=" text
“i=”文本
where "text" represents a human-readable text indicating the purpose of the session or media stream.
其中，“文本”表示指示会话或媒体流的目的的人类可读文本。
In this document, we define a new capability attribute: the title capability "icap". This attribute lists session or media titles as capabilities, according to the following definition:
在本文中，我们定义了一个新的能力属性：标题能力“icap”。此属性根据以下定义将会话或媒体标题列为功能：
"a=icap:" title-cap-num 1*WSP text
"a=icap:" title-cap-num 1*WSP text
where <title-cap-num> is a unique integer within all the connection capabilities in the entire SDP, which is used to identify the particular title capability and can take a value between 1 and 2^31-1 (both included). <text> is a human-readable text that indicates the purpose of the session or media stream it is supposed to characterize.
其中，<title cap num>是整个SDP中所有连接功能中的唯一整数，用于标识特定的标题功能，可以取1到2^31-1之间的值（两者都包括）<text>是一种人类可读的文本，它指示会话或媒体流的用途。
As an example, one might use:
例如，可以使用：
a=icap:1 Document Camera
a=icap:1个文件摄像机
to define a title capability number 1 to identify a particular source of a media stream.
定义标题功能编号1，以标识媒体流的特定源。
Or, in another example, one might offer two title capabilities with different character encodings (using the charset attribute defined in "SDP: Session Description Protocol" [RFC4566] and the generic attribute capability attribute ("a=acap:") defined in "Session Description Protocol (SDP) Capability Negotiation" [RFC5939]).
或者，在另一个示例中，可以提供具有不同字符编码的两个标题功能（使用“SDP:会话描述协议”[RFC4566]中定义的字符集属性和“会话描述协议（SDP）能力协商”[RFC5939]中定义的通用属性能力属性（“a=acap:”）。
a=icap:1 [Text encoded in ISO-8859-1]
a=acap:1 charset:ISO-8859-1
a=icap:2 [Text encoded in UTF-8]
a=acap:2 charset:UTF-8
a=icap:1 [Text encoded in ISO-8859-1]
a=acap:1 charset:ISO-8859-1
a=icap:2 [Text encoded in UTF-8]
a=acap:2 charset:UTF-8
NOTE: Due to limitations of the ASCII encoding of RFCs, the actual text with non-printable characters cannot be represented in the text. See the PDF format of this RFC for a figure with non-printable characters.
注：由于RFC ASCII编码的限制，文本中无法表示包含不可打印字符的实际文本。有关不可打印字符的图形，请参阅此RFC的PDF格式。
The title capability attribute satisfies the general attribute production rules in SDP [RFC4566], according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
标题能力属性符合SDP[RFC4566]中的一般属性生成规则，符合以下扩充的巴科斯诺尔形式（ABNF）[RFC5234]语法：
att-field =/ "icap"
att-value =/ title-cap-num 1*WSP text
; text defined in RFC 4566
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
att-field =/ "icap"
att-value =/ title-cap-num 1*WSP text
; text defined in RFC 4566
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
Figure 11: Syntax of the "icap" attribute
图11：“icap”属性的语法
The SDP Capability Negotiation Framework [RFC5939] provides for the existence of the "pcfg" and "acfg" attributes. The concept is extended by the SDP Media Capabilities Negotiation [RFC6871] with an "lcfg" attribute that conveys latent configurations.
SDP能力协商框架[RFC5939]规定存在“pcfg”和“acfg”属性。SDP媒体能力协商[RFC6871]扩展了该概念，该协商具有“lcfg”属性，可传达潜在配置。
In this document, we define a <title-config-list> parameter to be used to convey title capabilities in a potential or latent configuration. This parameter is defined as an <extension-config-list> with the following associations:
在本文档中，我们定义了一个<title config list>参数，用于在潜在或潜在配置中传递标题功能。此参数定义为具有以下关联的<extension config list>：
ext-cap-name = "i"
ext-cap-name = "i"
ext-cap-list = title-cap-list
ext-cap-list = title-cap-list
This leads to the following definition for the title capability parameter:
这将导致标题功能参数的以下定义：
extension-config-list =/ title-config-list
title-config-list = ["+"] "i=" title-cap-list
title-cap-list = title-cap-num *(BAR title-cap-num)
; BAR defined in RFC 5939
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
extension-config-list =/ title-config-list
title-config-list = ["+"] "i=" title-cap-list
title-cap-list = title-cap-num *(BAR title-cap-num)
; BAR defined in RFC 5939
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
Figure 12: Syntax of the title capability parameter in "lcfg" and "pcfg" attributes
图12：“lcfg”和“pcfg”属性中标题能力参数的语法
Each potential capability configuration contains a single title capability attribute number where "title-cap-num" is the title capability number defined explicitly earlier in this document, and hence must be between 1 and 2^31-1 (both included). The title capability allows the expression of only a single capability in each alternative, since no more than a single-title field is permitted per block. Nevertheless, it is still allowed to express alternative potential title configurations separated by a vertical bar ("|").
每个潜在能力配置都包含一个单一的标题能力属性编号，其中“title cap num”是本文档前面明确定义的标题能力编号，因此必须介于1和2^31-1之间（两者都包括在内）。标题功能只允许在每个备选方案中表达单个功能，因为每个区块不允许超过一个标题字段。尽管如此，它仍然可以表示由竖线（“|”）分隔的备选潜在标题配置。
An endpoint includes a plus sign ("+") in the configuration attribute to mandate support for this extension. An endpoint that receives this parameter prefixed with a plus sign and does not support this extension MUST treat that potential configuration as not valid.
端点在配置属性中包含加号（“+”），以强制支持此扩展。接收以加号为前缀的此参数且不支持此扩展的端点必须将该潜在配置视为无效。
The title parameter to the actual configuration attribute ("a=acfg") is formulated as a <sel-extension-config> with
实际配置属性（“a=acfg”）的标题参数表示为<sel extension config>，带有
ext-cap-name = "i"
ext-cap-name = "i"
hence
因此
sel-extension-config =/ sel-title-config sel-title-config = "i=" title-cap-num ; as defined above.
sel extension config=/sel title config sel title config=“i=”title cap num；如上所述。
Figure 13: Syntax of the title parameter in "acfg" attributes
图13：“acfg”属性中title参数的语法
At present, it is difficult to envision a scenario in which the "icap" attribute must be supported or the offer must be rejected. In most cases, if the icap attribute or its contents were to be ignored, an offered configuration could still be chosen based on other criteria such as configuration numbering. However, one might imagine an SDP offer that contained English and Spanish potential configurations for an audio stream. The session might be unintelligible if the choice is based on configuration numbering, rather than informed user selection. Based on such considerations, it may well prove useful to announce the ability to use the icap attribute and its contents to select media configurations, or to inform the user about the selected configuration(s). Therefore, we define a new option tag of "icap-v0" that identifies support for the title capability. This option tag SHOULD be added to other existing option tags present in the "csup" and/or "creq" attributes in SDP, according to the procedures defined in the SDP Capability Negotiation Framework [RFC5939]. The discussion above suggests that "icap-v0" will typically appear in a "csup" attribute, but rarely in a "creq" attribute.
目前，很难设想必须支持“icap”属性或拒绝报价的情况。在大多数情况下，如果要忽略icap属性或其内容，仍然可以根据其他标准（如配置编号）选择提供的配置。然而，有人可能会想象一个SDP产品包含英语和西班牙语的音频流潜在配置。如果选择基于配置编号，而不是知情的用户选择，则会话可能无法理解。基于这些考虑，宣布使用icap属性及其内容来选择媒体配置的能力，或者向用户通知所选配置，可能会很有用。因此，我们定义了一个新的选项标签“icap-v0”，用于标识对标题功能的支持。根据SDP能力协商框架[RFC5939]中定义的程序，该选项标签应添加到SDP中“csup”和/或“creq”属性中存在的其他现有选项标签中。上述讨论表明，“icap-v0”通常出现在“csup”属性中，但很少出现在“creq”属性中。
The "bcap", "ccap", and "icap" attributes can appear at the SDP session and/or media level. Endpoints MUST interpret capabilities declared at session level as part of the session level in the resulting SDP for that particular configuration. Endpoints MUST interpret capabilities declared at media description as part of the media level in the resulting SDP for that particular configuration.
“bcap”、“ccap”和“icap”属性可以出现在SDP会话和/或媒体级别。端点必须将在会话级别声明的功能解释为该特定配置的结果SDP中会话级别的一部分。端点必须将媒体描述中声明的功能解释为该特定配置的结果SDP中媒体级别的一部分。
The presence of the "bcap" capability for the same <bwtype> at both the session and media level is subject to the same constraints and restrictions specified in RFC 4566 [RFC4566] for the bandwidth attribute "b=".
会话和媒体级别上相同<bwtype>的“bcap”功能受RFC 4566[RFC4566]中为带宽属性“b=”指定的相同约束和限制的约束。
To avoid confusion, the <type-attr-num> for each "a=bcap", "a=ccap", and "a=icap" line MUST be unique across all capability attributes of the same type within the entire session description.
为避免混淆，在整个会话描述中，每个“a=bcap”、“a=ccap”和“a=icap”行的<type attr num>在相同类型的所有功能属性中必须是唯一的。
In this section, we define extensions to the offer/answer model defined in SDP Offer/Answer Model [RFC3264] and extended in the SDP Capability Negotiation [RFC5939] to allow for bandwidth, connection, and title capabilities to be used with the SDP Capability Negotiation Framework.
在本节中，我们定义了SDP提供/应答模型[RFC3264]中定义的提供/应答模型的扩展，并在SDP能力协商[RFC5939]中进行了扩展，以允许带宽、连接和标题能力与SDP能力协商框架一起使用。
When an endpoint generates an initial offer and wants to use the functionality described in the current document, it first defines appropriate values for the bandwidth, connection data, and/or title capability attributes according to the rules defined in [RFC4566] for "b=", "c=", and "i=" lines. The endpoint then MUST include the respective capability attributes and associated values in the SDP offer. The preferred configurations for each media stream are identified following the media line in a "pcfg" attribute. Bandwidth and title capabilities may also be referenced in latent configurations in an "lcfg" attribute, as defined in the SDP Media Capabilities Negotiation [RFC6871].
当端点生成初始报价并希望使用当前文档中描述的功能时，它首先根据[RFC4566]中为“b=”、“c=”和“i=”行定义的规则，为带宽、连接数据和/或标题功能属性定义适当的值。然后，端点必须在SDP提供中包含相应的功能属性和关联值。每个媒体流的首选配置在“pcfg”属性中的媒体行之后标识。带宽和标题能力也可以在SDP媒体能力协商[RFC6871]中定义的“lcfg”属性的潜在配置中引用。
Implementations are advised to pay attention to the port number that is used in the "m=" line. By default, a potential configuration that includes a connection data capability will use the port number from the "m=" line, unless the network type is "PSTN", in which case the default port number used will be 9.
建议实施时注意“m=”行中使用的端口号。默认情况下，包括连接数据功能的潜在配置将使用“m=”线路中的端口号，除非网络类型为“PSTN”，在这种情况下，使用的默认端口号为9。
The offer SHOULD include the level of capability negotiation extensions needed to support this functionality in a "creq" attribute.
该产品应在“creq”属性中包含支持此功能所需的能力级别协商扩展。
When the answering party receives the offer, and if it supports the required capability negotiation extensions, it SHOULD select the most preferred configuration it can support for each media stream and build the answer accordingly, as defined in Section 3.6.2 of the SDP Capability Negotiation [RFC5939].
当应答方收到报价时，如果其支持所需的能力协商扩展，则应根据SDP能力协商[RFC5939]第3.6.2节中的定义，为每个媒体流选择其可以支持的最首选配置，并相应地构建应答。
If the connection data capability is used in a selected potential configuration chosen by the answerer, that offer configuration MUST by default use the port number from the actual offer configuration (i.e., the "m=" line), unless the network type is "PSTN", in which case the default port MUST be assumed to be 9. Extensions may be defined to negotiate the port number explicitly instead.
如果连接数据功能用于应答者选择的选定潜在配置，则默认情况下，该报价配置必须使用实际报价配置中的端口号（即“m=”行），除非网络类型为“PSTN”，在这种情况下，默认端口必须假定为9。扩展可以定义为显式协商端口号。
When the offerer receives the answer, it MUST process the media lines according to normal SDP processing rules to identify the media stream(s) accepted by the answer, if any, as defined in Section 3.6.3 of the SDP Capability Negotiation [RFC5939]. The "acfg" attribute, if present, MUST be used to verify the proposed configuration used to form the answer and to infer the lack of acceptability of higher-preference configurations that were not chosen.
当报价人收到答复时，必须根据正常的SDP处理规则处理媒体线路，以识别SDP能力协商[RFC5939]第3.6.3节中定义的答复所接受的媒体流（如有）。“acfg”属性（如果存在）必须用于验证用于形成答案的建议配置，并推断未选择的更高偏好配置缺乏可接受性。
If, at a later time, one of the parties wishes to modify the operating parameters of a session, e.g., by adding a new media stream or by changing the properties used on an existing stream, it may do so via the mechanisms defined for SDP offer/answer [RFC3264] and in accordance with the procedures defined in Section 3.6.4 of the SDP Capability Negotiation [RFC5939].
如果一方希望在稍后修改会话的操作参数，例如，通过添加新媒体流或通过改变现有流上使用的属性，则其可以通过为SDP提供/应答[RFC3264]定义的机制来这样做并根据SDP能力协商[RFC5939]第3.6.4节中定义的程序。
To simplify the construction of SDP records, given the need to include fields within the media description in question for endpoints that do not support capabilities negotiation, we define some simple field-replacement rules for those fields invoked by potential or latent configurations. In particular, any "i=" or "c=" lines invoked by a configuration MUST replace the corresponding line, if present within the media description in question. Any "b=" line invoked by a configuration MUST replace any "b=" of the same bandwidth type at the media level, but not at the session level.
为了简化SDP记录的构造，考虑到需要在不支持功能协商的端点的媒体描述中包含字段，我们为潜在或潜在配置调用的字段定义了一些简单的字段替换规则。特别是，配置调用的任何“i=”或“c=”行必须替换相应的行（如果存在于相关介质描述中）。配置调用的任何“b=”行都必须替换媒体级别上相同带宽类型的任何“b=”，但不能替换会话级别上的任何“b=”。
This document provides an extension on top of the SDP [RFC4566], SDP Offer/Answer Model [RFC3264], SDP Capability Negotiation Framework [RFC5939], and SDP Media Capabilities Negotiation [RFC6871]. As such, the security considerations of those documents apply.
本文档提供了SDP[RFC4566]、SDP提供/应答模型[RFC3264]、SDP能力协商框架[RFC5939]和SDP媒体能力协商[RFC6871]之上的扩展。因此，适用这些文件的安全考虑。
The bandwidth capability attribute may be used for reserving resources at endpoints and intermediaries that inspect SDP. Modification of the bandwidth value by an attacker can lead to the network being underutilized (too high bandwidth value) or congested (too low bandwidth value).
带宽能力属性可用于在检查SDP的端点和中介处保留资源。攻击者修改带宽值可能导致网络未充分利用（带宽值过高）或拥塞（带宽值过低）。
Similarly, by modifying the alternative connection address(es), an attacker would be able to direct media streams to a desired endpoint, thus launching a version of the well-known voice hammer attack (see Section 18.5.1 of [RFC5245]).
类似地，通过修改备用连接地址，攻击者将能够将媒体流定向到所需的端点，从而发起著名的语音锤攻击（参见[RFC5245]第18.5.1节）。
The title capability provides for alternative "i=" line information, which is intended for human consumption. However, manipulating the textual information could be misused to provide false information, leading to a bad user experience or the person using the service making a wrong choice regarding the available media streams.
标题功能提供了供人类使用的备选“i=”行信息。然而，操纵文本信息可能被误用以提供虚假信息，从而导致糟糕的用户体验或使用服务的人在可用媒体流方面做出错误的选择。
In case it is essential to protect the capability attribute values, one of the security mechanisms proposed in [RFC5939] SHOULD be used.
如果必须保护能力属性值，则应使用[RFC5939]中提出的安全机制之一。
The "i=" line, and thus the value carried in the title capability attribute, is intended for human-readable description only. It should not be parsed programmatically.
“i=”行以及title capability属性中包含的值仅用于人类可读的描述。不应以编程方式对其进行分析。
IANA has registered new attributes in the "att-field (both session and media level)" subregistry of the "Session Description Protocol (SDP) Parameters" registry, according to the following registration form:
IANA已根据以下注册表，在“会话描述协议（SDP）参数”注册表的“att字段（会话和媒体级别）”子区中注册了新属性：
Attribute name: bcap Long form name: Bandwidth Capability Type of attribute: Both media and session level Subject to charset: No Purpose: Negotiate session or media-level bandwidths Appropriate values: See RFC 7066, Section 3.1.1 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com
属性名称：bcap长格式名称：带宽能力属性类型：媒体和会话级别取决于字符集：无目的：协商会话或媒体级别带宽适当值：请参阅RFC 7066，第3.1.1节联系人姓名：Miguel A.Garcia Miguel.A。Garcia@ericsson.com
Attribute name: ccap Long form name: Connection Data Capability Type of attribute: Both media and session level Subject to charset: No Purpose: Negotiate media-level connection data Appropriate values: See RFC 7066, Section 3.1.2 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com
属性名称：ccap长格式名称：连接数据功能属性类型：媒体和会话级别取决于字符集：无目的：协商媒体级别连接数据适当值：请参阅RFC 7066，第3.1.2节联系人姓名：Miguel A.Garcia Miguel.A。Garcia@ericsson.com
Attribute name: icap Long form name: Title Capability Type of attribute: Both media and session level Subject to charset: Yes Purpose: Negotiate human-readable information describing the session or media Appropriate values: See RFC 7066, Section 3.1.3 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com
属性名称：icap长格式名称：标题功能属性类型：媒体和会话级别取决于字符集：是目的：协商描述会话或媒体的可读信息适当值：参见RFC 7066，第3.1.3节联系人姓名：Miguel A.Garcia Miguel.A。Garcia@ericsson.com
IANA has added the new option tags "bcap-v0", "ccap-v0", and "icap-v0", defined herein, to the "SDP Capability Negotiation Option Tag" subregistry of the "Session Description Protocol (SDP) Parameters" registry.
IANA已将此处定义的新选项标签“bcap-v0”、“ccap-v0”和“icap-v0”添加到“会话描述协议（SDP）参数”注册表的“SDP能力协商选项标签”子区。
IANA has added the new parameter identifiers "b" for "Bandwidth", "c" for "Connection Data", and "i" for "Title" to the "SDP Capability Negotiation Configuration Parameters" subregistry of the "Session Description Protocol (SDP) Parameters" registry. These parameters are permitted in "lcfg", "acfg", and "pcfg" attributes.
IANA在“会话描述协议（SDP）参数”注册表的“SDP能力协商配置参数”子区添加了新的参数标识符“b”，表示“带宽”，“c”，表示“连接数据”，以及“i”，表示“标题”。这些参数在“lcfg”、“acfg”和“pcfg”属性中是允许的。
Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson for arguing for the existence of this document and reviewing it in the early stages. Thanks to Flemming Andreasen, Andrew Allen, and Jonathan Lennox for a detailed review and many suggestions for improvement.
感谢Christer Holmberg、Alf Heidermark和Ingemar Johansson为本文件的存在进行了论证，并在早期阶段对其进行了审查。感谢Flemming Andreasen、Andrew Allen和Jonathan Lennox的详细审查和许多改进建议。
[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月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
[RFC5939]Andreasen，F.，“会话描述协议（SDP）能力协商”，RFC 59392010年9月。
[RFC6871] Gilman, R., Even, R., and F. Andreasen, "Session Description Protocol (SDP) Media Capabilities Negotiation", RFC 6871, February 2013.
[RFC6871]Gilman，R.，Even，R.，和F.Andreasen，“会话描述协议（SDP）媒体能力协商”，RFC 68712013年2月。
[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001.
[RFC3108]Kumar，R.和M.Mostafa，“ATM承载连接使用会话描述协议（SDP）的约定”，RFC 3108，2001年5月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年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月。
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4574]Levin，O.和G.Camarillo，“会话描述协议（SDP）标签属性”，RFC 45742006年8月。
[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月。
[SDP-CS] Garcia, M. and S. Veikkolainen, "Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)", Work in Progress, June 2013.
[SDP-CS]Garcia，M.和S.Veikkolainen，“公共交换电话网（PSTN）中通过电路交换承载设置音频和视频媒体流的会话描述协议（SDP）扩展”，正在进行的工作，2013年6月。
Authors' Addresses
作者地址
Miguel A. Garcia-Martin Ericsson Calle Via de los Poblados 13 Madrid 28033 Spain
Miguel A.Garcia Martin Ericsson Calle Via de los Poblados 13马德里28033西班牙
Phone: +34 91 339 1000
EMail: miguel.a.garcia@ericsson.com
Phone: +34 91 339 1000
EMail: miguel.a.garcia@ericsson.com
Simo Veikkolainen Nokia P.O. Box 226 NOKIA GROUP, FI 00045 Finland
Simo Veikkolainen诺基亚邮政信箱226诺基亚集团，FI 00045芬兰
Phone: +358 50 486 4463
EMail: simo.veikkolainen@nokia.com
Phone: +358 50 486 4463
EMail: simo.veikkolainen@nokia.com
Robert R. Gilman 3243 W. 11th Ave. Dr. Broomfield, Colorado 80020 U.S.A.
美国科罗拉多州布鲁姆菲尔德博士第11大道西3243号罗伯特R.吉尔曼80020。
Phone: +1 303 898 9780
EMail: bob_gilman@comcast.net
Phone: +1 303 898 9780
EMail: bob_gilman@comcast.net