Network Working Group J. Ott
Request for Comments: 5124 Helsinki University of Technology
Category: Standards Track E. Carrara
KTH
February 2008
Network Working Group J. Ott
Request for Comments: 5124 Helsinki University of Technology
Category: Standards Track E. Carrara
KTH
February 2008
Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)
基于实时传输控制协议（RTCP）的反馈（RTP/SAVPF）的扩展安全RTP配置文件
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback.
RFC 3711和RFC 4585中分别定义了用于安全实时通信的RTP简档（SAVP）和用于从接收机向发送方提供及时反馈的另一个简档（AVPF）。此备忘录指定了两种配置文件的组合，以实现带反馈的安全RTP通信。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Definitions ................................................4
1.2. Terminology ................................................4
2. SAVPF Rules .....................................................4
2.1. Packet Formats .............................................5
2.2. Extensions .................................................5
2.3. Implications from Combining AVPF and SAVP ..................6
3. SDP Definitions .................................................6
3.1. Profile Definition .........................................6
3.2. Attribute Definitions ......................................6
3.3. Profile Negotiation ........................................6
3.3.1. Offer/Answer-Based Negotiation of Session
Descriptions ........................................7
3.3.2. RTSP-Based Negotiation of Session Descriptions ......8
3.3.3. Announcing Session Descriptions .....................9
3.3.4. Describing Alternative Session Profiles .............9
3.4. Examples ..................................................10
4. Interworking of AVP, SAVP, AVPF, and SAVPF Entities ............13
5. Security Considerations ........................................14
6. IANA Considerations ............................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
1. Introduction ....................................................3
1.1. Definitions ................................................4
1.2. Terminology ................................................4
2. SAVPF Rules .....................................................4
2.1. Packet Formats .............................................5
2.2. Extensions .................................................5
2.3. Implications from Combining AVPF and SAVP ..................6
3. SDP Definitions .................................................6
3.1. Profile Definition .........................................6
3.2. Attribute Definitions ......................................6
3.3. Profile Negotiation ........................................6
3.3.1. Offer/Answer-Based Negotiation of Session
Descriptions ........................................7
3.3.2. RTSP-Based Negotiation of Session Descriptions ......8
3.3.3. Announcing Session Descriptions .....................9
3.3.4. Describing Alternative Session Profiles .............9
3.4. Examples ..................................................10
4. Interworking of AVP, SAVP, AVPF, and SAVPF Entities ............13
5. Security Considerations ........................................14
6. IANA Considerations ............................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
The Real-time Transport Protocol, the associated RTP Control Protocol (RTP/RTCP, RFC 3550) [1], and the profile for audiovisual communications with minimal control (RFC 3551) [2] define mechanisms for transmitting time-based media across an IP network. RTP provides means to preserve timing and detect packet losses, among other things, and RTP payload formats provide for proper framing of (continuous) media in a packet-based environment. RTCP enables receivers to provide feedback on reception quality and allows all members of an RTP session to learn about each other.
实时传输协议、相关的RTP控制协议（RTP/RTCP，RFC 3550）[1]和具有最小控制的视听通信配置文件（RFC 3551）[2]定义了通过IP网络传输基于时间的媒体的机制。RTP提供了保持定时和检测数据包丢失的方法，RTP有效负载格式在基于数据包的环境中提供了（连续）媒体的正确帧。RTCP使接收者能够提供关于接收质量的反馈，并允许RTP会话的所有成员相互了解。
The RTP specification provides only rudimentary support for encrypting RTP and RTCP packets. Secure RTP (RFC 3711) [4] defines an RTP profile ("SAVP") for secure RTP media sessions, defining methods for proper RTP and RTCP packet encryption, integrity, and replay protection. The initial negotiation of SRTP and its security parameters needs to be done out-of-band, e.g., using the Session Description Protocol (SDP, RFC 4566) [6] together with extensions for conveying keying material (RFC 4567 [7], RFC 4568 [8]).
RTP规范仅提供对RTP和RTCP数据包加密的基本支持。安全RTP（RFC 3711）[4]定义了用于安全RTP媒体会话的RTP配置文件（“SAVP”），定义了正确RTP和RTCP数据包加密、完整性和重播保护的方法。SRTP及其安全参数的初始协商需要在带外进行，例如，使用会话描述协议（SDP，RFC 4566）[6]以及传输密钥材料的扩展（RFC 4567[7]，RFC 4568[8]）。
The RTP specification also provides limited support for timely feedback from receivers to senders, typically by means of reception statistics reporting in somewhat regular intervals depending on the group size, the average RTCP packet size, and the available RTCP bandwidth. The extended RTP profile for RTCP-based feedback ("AVPF") (RFC 4585, [3]) allows session participants statistically to provide immediate feedback while maintaining the average RTCP data rate for all senders. As for SAVP, the use of AVPF and its parameters needs to be negotiated out-of-band by means of SDP (RFC 4566, [6]) and the extensions defined in RFC 4585 [3].
RTP规范还为从接收器到发送者的及时反馈提供了有限的支持，通常是通过根据组大小、平均RTCP数据包大小和可用RTCP带宽以一定的固定间隔报告接收统计数据。基于RTCP的反馈（“AVPF”）的扩展RTP配置文件（RFC 4585[3]）允许会话参与者在统计上提供即时反馈，同时保持所有发送者的平均RTCP数据速率。至于SAVP，AVPF及其参数的使用需要通过SDP（RFC 4566[6]）和RFC 4585[3]中定义的扩展进行带外协商。
Both SRTP and AVPF are RTP profiles and need to be negotiated. This implies that either one or the other may be used, but both profiles cannot be negotiated for the same RTP session (using one SDP session level description). However, using secure communications and timely feedback together is desirable. Therefore, this document specifies a new RTP profile ("SAVPF") that combines the features of SAVP and AVPF.
SRTP和AVPF都是RTP配置文件，需要协商。这意味着可以使用一个或另一个配置文件，但不能为同一RTP会话协商两个配置文件（使用一个SDP会话级别描述）。然而，同时使用安全通信和及时反馈是可取的。因此，本文档指定了一个新的RTP配置文件（“SAVPF”），它结合了SAVP和AVPF的功能。
As SAVP and AVPF are largely orthogonal, the combination of both is mostly straightforward. No sophisticated algorithms need to be specified in this document. Instead, reference is made to both existing profiles and only the implications of their combination and possible deviations from rules of the existing profiles are described as is the negotiation process.
由于SAVP和AVPF在很大程度上是正交的，因此两者的结合非常简单。本文件中不需要指定复杂的算法。取而代之的是，参考了两个现有概要文件，仅描述了它们组合的含义以及与现有概要文件规则的可能偏差，谈判过程也是如此。
The definitions of RFC 3550 [1], RFC 3551 [2], RFC 4585 [3], and RFC 3711 [4] apply.
RFC 3550[1]、RFC 3551[2]、RFC 4585[3]和RFC 3711[4]的定义适用。
The following definitions are specifically used in this document:
本文件中具体使用了以下定义：
RTP session: An association among a set of participants communicating with RTP as defined in RFC 3550 [1].
RTP会话：一组与RTP通信的参与者之间的关联，如RFC 3550[1]中所定义。
(SDP) media description: This term refers to the specification given in a single m= line in an SDP message. An SDP media description may define only one RTP session.
（SDP）媒体描述：该术语指SDP消息中单个m=行中给出的规范。SDP介质描述只能定义一个RTP会话。
Media session: A media session refers to a collection of SDP media descriptions that are semantically grouped to represent alternatives of the same communications means. Out of such a group, one will be negotiated or chosen for a communication relationship and the corresponding RTP session will be instantiated. If no common session parameters suitable for the involved endpoints can be found, the media session will be rejected. In the simplest case, a media session is equivalent to an SDP media description and equivalent to an RTP session.
媒体会话：媒体会话是指SDP媒体描述的集合，这些描述在语义上分组以表示相同通信方式的备选方案。在这样一个组中，将协商或选择一个组作为通信关系，并实例化相应的RTP会话。如果找不到适用于相关端点的公共会话参数，则将拒绝媒体会话。在最简单的情况下，媒体会话相当于SDP媒体描述和RTP会话。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
SAVP is defined as an intermediate layer between RTP (following the regular RTP profile AVP) and the transport layer (usually UDP). This yields a two-layer hierarchy within the Real-time Transport Protocol. In SAVPF, the upper (AVP) layer is replaced by the extended RTP profile for feedback (AVPF).
SAVP被定义为RTP（遵循常规RTP配置文件AVP）和传输层（通常为UDP）之间的中间层。这在实时传输协议中产生了两层层次结构。在SAVPF中，上层（AVP）由扩展RTP反馈配置文件（AVPF）代替。
AVPF modifies timing rules for transmitting RTCP packets and adds extra RTCP packet formats specific to feedback. These functions are independent of whether or not RTCP packets are subsequently encrypted and/or integrity protected. The functioning of the AVPF layer remains unchanged in SAVPF.
AVPF修改传输RTCP数据包的定时规则，并添加特定于反馈的额外RTCP数据包格式。这些功能与RTCP数据包是否随后被加密和/或完整性保护无关。AVPF层的功能在SAVPF中保持不变。
The AVPF profile derives from RFC 3550 [1] the (optional) use of the encryption prefix for RTCP. The encryption prefix MUST NOT be used within the SAVPF profile (it is not used in SAVP, as it is only applicable to the encryption method specified in [1]).
AVPF配置文件源自RFC 3550[1]，即RTCP加密前缀的（可选）使用。加密前缀不得在SAVPF配置文件中使用（不在SAVP中使用，因为它仅适用于[1]中指定的加密方法）。
The SAVP part uses extra fields added to the end of RTP and RTCP packets and executes cryptographic transforms on (some of) the RTP/RTCP packet contents. This behavior remains unchanged in SAVPF. The average RTCP packet size calculation done by the AVPF layer for timing purposes MUST take into account the fields added by the SAVP layer.
SAVP部分使用添加到RTP和RTCP数据包末尾的额外字段，并对（部分）RTP/RTCP数据包内容执行加密转换。这种行为在SAVPF中保持不变。AVPF层出于计时目的进行的平均RTCP数据包大小计算必须考虑SAVP层添加的字段。
The SRTP part becomes active only when the RTP or RTCP was scheduled by the "higher" AVPF layer or received from the transport protocol, irrespective of its timing and contents.
只有当RTP或RTCP由“更高”的AVPF层调度或从传输协议接收时，SRTP部分才变为活动状态，而不管其时间和内容如何。
AVPF defines extra packet formats to provide feedback information. Those extra packet formats defined in RFC 4585 [3] (and further ones defined elsewhere for use with AVPF) MAY be used with SAVPF.
AVPF定义额外的数据包格式以提供反馈信息。RFC 4585[3]中定义的那些额外分组格式（以及其他地方定义的用于AVPF的其他分组格式）可与SAVPF一起使用。
SAVP defines a modified packet format for SRTP and SRTCP packets that essentially consists of the RTP/RTCP packet formats plus some trailing protocol fields for security purposes. For SAVPF, all RTCP packets MUST be encapsulated as defined in Section 3.4 of RFC 3711 [4].
SAVP为SRTP和SRTCP数据包定义了修改后的数据包格式，该数据包格式基本上由RTP/RTCP数据包格式加上一些用于安全目的的后续协议字段组成。对于SAVPF，所有RTCP数据包必须按照RFC 3711[4]第3.4节的规定进行封装。
Extensions to AVPF RTCP feedback packets defined elsewhere MAY be used with the SAVPF profile provided that those extensions are in conformance with the extension rules of RFC 4585 [3].
其他地方定义的AVPF RTCP反馈包扩展可与SAVPF配置文件一起使用，前提是这些扩展符合RFC 4585[3]的扩展规则。
Additional extensions (e.g., transforms) defined for SAVP following the rules of Section 6 of RFC 3711 [4] MAY also be used with the SAVPF profile. The overhead per RTCP packet depends on the extensions and transforms chosen. New extensions and transforms added in the future MAY introduce yet unknown further per-packet overhead.
根据RFC 3711[4]第6节的规则为SAVP定义的附加扩展（例如转换）也可用于SAVPF配置文件。每个RTCP数据包的开销取决于选择的扩展和转换。未来添加的新扩展和转换可能会进一步引入未知的每个数据包开销。
Finally, further extensions specifically to SAVPF MAY be defined elsewhere.
最后，可以在其他地方定义SAVPF的进一步扩展。
The AVPF profile aims at -- statistically -- allowing receivers to provide timely feedback to senders. The frequency at which receivers are, on average, allowed to send feedback information depends on the RTCP bandwidth, the group size, and the average size of an RTCP packet. SRTCP (see Section 3.4 of RFC 3711 [4]) adds extra fields (some of which are of configurable length) at the end of each RTCP packet that are probably at least some 10 to 20 bytes in size (14 bytes as default). Note that extensions and transforms defined in the future, as well as the configuration of each field length, MAY add greater overhead. By using SRTP, the average size of an RTCP packet will increase and thus reduce the frequency at which (timely) feedback can be provided. Application designers need to be aware of this, and take precautions so that the RTCP bandwidth shares are maintained. This MUST be done by adjusting the RTCP variable "avg_rtcp_size" to reflect the size of the SRTCP packets.
AVPF配置文件的目的是——统计上——允许接收者及时向发送者提供反馈。接收机发送反馈信息的平均频率取决于RTCP带宽、组大小和RTCP数据包的平均大小。SRTCP（见RFC 3711[4]第3.4节）在每个RTCP数据包的末尾添加额外字段（其中一些字段的长度可配置），这些字段的大小可能至少为10到20字节（默认为14字节）。请注意，将来定义的扩展和转换以及每个字段长度的配置可能会增加更大的开销。通过使用SRTP，RTCP数据包的平均大小将增加，从而降低（及时）提供反馈的频率。应用程序设计者需要意识到这一点，并采取预防措施，以便维护RTCP带宽共享。这必须通过调整RTCP变量“avg_RTCP_size”来实现，以反映SRTCP数据包的大小。
The AV profiles defined in RFC 3551 [2], RFC 4585 [3], and RFC 3711 [4] are referred to as "AVP", "AVPF", and "SAVP", respectively, in the context of, e.g., the Session Description Protocol (SDP) [3]. The combined profile specified in this document is referred to as "SAVPF".
在例如会话描述协议（SDP）[3]的上下文中，RFC 3551[2]、RFC 4585[3]和RFC 3711[4]中定义的AV配置文件分别称为“AVP”、“AVPF”和“SAVP”。本文件中规定的组合配置文件称为“SAVPF”。
SDP attributes for negotiating SAVP sessions are defined in RFC 4567 [7] and RFC 4568 [8]. Those attributes MAY also be used with SAVPF. The rules defined in [7] and [8] apply.
RFC 4567[7]和RFC 4568[8]中定义了协商SAVP会话的SDP属性。这些属性也可与SAVPF一起使用。[7]和[8]中定义的规则适用。
SDP attributes for negotiating AVPF sessions are defined in RFC 4585 [3]. Those attributes MAY also be used with SAVPF. The rules defined in [3] apply.
RFC 4585[3]中定义了协商AVPF会话的SDP属性。这些属性也可与SAVPF一起使用。[3]中定义的规则适用。
Session descriptions for RTP sessions may be conveyed using protocols dedicated for multimedia communications such as the SDP offer/answer model (RFC 3264, [9]) used with the Session Initiation Protocol (SIP) [15], the Real Time Streaming Protocol (RTSP) [10], or the Session Announcement Protocol (SAP) [11], but may also be distributed using email, NetNews, web pages, etc.
RTP会话的会话描述可以使用专用于多媒体通信的协议来传送，例如与会话发起协议（SIP）[15]、实时流协议（RTSP）[10]或会话公告协议（SAP）[11]一起使用的SDP提供/应答模型（RFC 3264[9]），但也可以使用电子邮件来分发，网络新闻、网页等。
The offer/answer model allows the resulting session parameters to be negotiated using the SDP attributes defined in RFC 4567 [7] and RFC 4568 [8]. In the following subsection, the negotiation process is described in terms of the offer/answer model.
提供/应答模型允许使用RFC 4567[7]和RFC 4568[8]中定义的SDP属性协商生成的会话参数。在下一小节中，将根据报价/应答模型描述协商过程。
Afterwards, the cases that do not use the offer/answer model are addressed: RTSP-specific negotiation support is provided by RFC 4567 [7] as discussed in Section 3.3.2, and support for SAP announcements (with no negotiation at all) is addressed in Section 3.3.3.
之后，将讨论不使用报价/应答模型的情况：RFC 4567[7]提供了RTSP特定的谈判支持，如第3.3.2节所述，并在第3.3.3节中讨论了对SAP公告（完全没有谈判）的支持。
Negotiations (e.g., of RTP profiles, codecs, transport addresses, etc.) are carried out on a per-media session basis (e.g., per m= line in SDP). If negotiating one media session fails, others MAY still succeed.
协商（例如，RTP配置文件、编解码器、传输地址等）在每个媒体会话的基础上进行（例如，SDP中的每个m=行）。如果谈判一个媒体会议失败，其他媒体仍可能成功。
Different RTP profiles MAY be used in different media sessions. For negotiation of a media description, the four profiles AVP, AVPF, SAVP, and SAVPF are mutually exclusive. Note, however, that SAVP and SAVPF entities MAY be mixed in a single RTP session (see Section 4). Also, the offer/answer mechanism MAY be used to offer alternatives for the same media session and allow the answerer to choose one of the profiles.
不同的RTP配置文件可用于不同的媒体会话。对于媒体描述的协商，四个配置文件AVP、AVPF、SAVP和SAVPF是互斥的。但是，请注意，SAVP和SAVPF实体可以在单个RTP会话中混合使用（参见第4节）。此外，提供/应答机制可用于为同一媒体会话提供备选方案，并允许应答者选择其中一个配置文件。
Provided that a mechanism for offering alternative security profiles becomes available (as is presently under development [14]), an offerer that is capable of supporting more than one of these profiles for a certain media session SHOULD always offer all alternatives acceptable in a certain situation. The alternatives SHOULD be listed in order of preference and the offerer SHOULD prefer secure profiles over non-secure ones. The offer SHOULD NOT include both a secure alternative (SAVP and SAVPF) and an insecure alternative (e.g., AVP and AVPF) in the same offer as this may enable bidding down and other attacks. Therefore, if both secure and non-secure RTP profiles are offered (e.g., for best-effort SRTP [14]), the negotiation signaling MUST be protected appropriately to avoid such attacks.
如果提供备选安全配置文件的机制可用（目前正在开发[14]），能够为某个媒体会话支持多个此类配置文件的报价人应始终提供在特定情况下可接受的所有备选方案。备选方案应按优先顺序列出，报价人应优先选择安全配置文件，而不是非安全配置文件。报价中不应同时包含安全备选方案（SAVP和SAVPF）和不安全备选方案（如AVP和AVPF），因为这可能导致出价下降和其他攻击。因此，如果同时提供安全和非安全RTP配置文件（例如，为了尽最大努力SRTP[14]），则必须适当地保护协商信令以避免此类攻击。
If an offer contains multiple alternative profiles, the answerer SHOULD prefer a secure profile (if supported) over non-secure ones. Among the secure or insecure profiles, the answerer SHOULD select the first acceptable alternative to respect the preference of the offerer.
如果报价包含多个备选配置文件，则应答者应选择安全配置文件（如果支持）而不是非安全配置文件。在安全或不安全的配置文件中，应答者应选择第一个可接受的备选方案，以尊重报价人的偏好。
If a media description in an offer uses SAVPF and the answerer does not support SAVPF, the media session MUST be rejected.
如果报价中的媒体描述使用SAVPF，而应答者不支持SAVPF，则必须拒绝媒体会话。
If a media description in an offer does not use SAVPF but the answerer wants to use SAVPF, the answerer MUST reject the media session. The answerer MAY provide a counter-offer with a media description indicating SAVPF in a subsequently initiated offer/answer exchange.
如果报价中的媒体描述不使用SAVPF，但应答者希望使用SAVPF，则应答者必须拒绝媒体会话。回答者可在随后发起的要约/应答交换中提供一份带有媒体说明的还盘，说明SAVPF。
RTSP [10] does not support the offer/answer model. However, RTSP supports exchanging media session parameters (including profile and address information) by means of the Transport header. SDP-based key management as defined in RFC 4567 [7] adds an RTSP header (KeyMgmt) to support conveying a key management protocol (including keying material).
RTSP[10]不支持提供/应答模式。然而，RTSP支持通过传输头交换媒体会话参数（包括配置文件和地址信息）。RFC 4567[7]中定义的基于SDP的密钥管理添加了RTSP头（KeyMgmt），以支持传送密钥管理协议（包括密钥材料）。
The RTSP Transport header MAY be used to determine the profile for the media session. Conceptually, the rules defined in Section 3.3.1 apply accordingly. Detailed operation is as follows: An SDP description (e.g., retrieved from the RTSP server by means of DESCRIBE) contains the description of the media streams of the particular RTSP resource.
RTSP传输报头可用于确定媒体会话的配置文件。在概念上，第3.3.1节中定义的规则适用。具体操作如下：SDP描述（例如，通过descripe从RTSP服务器检索）包含特定RTSP资源的媒体流的描述。
The RTSP client MUST select exactly one of the profiles per media stream it wants to receive. It MUST do so in the SETUP request. The RTSP client MUST indicate the chosen RTP profile by indicating the profile and the full server transport address (IP address and port number) in the Transport header included in the SETUP request. The RTSP server's response to the client's SETUP message MUST confirm this profile selection or refuse the SETUP request (the latter of which it should not do after offering the profiles in the first place).
RTSP客户端必须为每个要接收的媒体流选择一个配置文件。它必须在设置请求中执行此操作。RTSP客户端必须通过在安装请求中包含的传输头中指示配置文件和完整的服务器传输地址（IP地址和端口号）来指示所选RTP配置文件。RTSP服务器对客户端设置消息的响应必须确认此配置文件选择或拒绝设置请求（后者在首先提供配置文件后不应执行）。
Note: To change any of the profiles in use, the client needs to tear down this media stream (and possibly the whole RTSP session) using the TEARDOWN method and re-establish it using SETUP. This may change as soon as media updating (similar to a SIP UPDATE or re-INVITE) becomes specified.
注意：要更改正在使用的任何配置文件，客户端需要使用“拆卸”方法中断此媒体流（可能还有整个RTSP会话），并使用“设置”重新建立它。一旦指定了媒体更新（类似于SIP更新或重新邀请），这可能会改变。
When using the SDP key management [7], the KeyMgmt header MUST be included in the appropriate RTSP messages if a secure profile is chosen. If different secure profiles are offered in the SDP description (e.g., SAVP and SAVPF) and different keying material is provided for these, after choosing one profile in the SETUP message, only the KeyMgmt header for the chosen one MUST be provided. The rules for matching KeyMgmt headers to media streams according to RFC 4567 [7] apply.
使用SDP密钥管理[7]时，如果选择了安全配置文件，则必须在相应的RTSP消息中包含KeyMgmt头。如果SDP说明中提供了不同的安全配置文件（如SAVP和SAVPF），并且为这些文件提供了不同的密钥材料，则在设置消息中选择一个配置文件后，必须仅提供所选配置文件的密钥管理标头。根据RFC 4567[7]将KeyMgmt头与媒体流匹配的规则适用。
Protocols that do not allow negotiating session descriptions interactively (e.g., SAP [11], descriptions posted on a web page or sent by mail) pose the responsibility for adequate access to the media sessions on the initiator of a session.
不允许以交互方式协商会话描述的协议（如SAP[11]、发布在网页上的描述或通过邮件发送的描述）构成了会话发起人对媒体会话充分访问的责任。
The initiator SHOULD provide alternative session descriptions for multiple RTP profiles as far as acceptable to the application and the purpose of the session. If security is desired, SAVP may be offered as alternative to SAVPF -- but AVP or AVPF sessions SHOULD NOT be announced unless other security means not relying on SRTP are employed.
发起方应为多个RTP配置文件提供替代会话描述，只要应用程序和会话目的可以接受。如果需要安全性，SAVP可以作为SAVPF的替代方案提供——但除非采用其他不依赖SRTP的安全手段，否则不应宣布AVP或AVPF会话。
The SDP attributes defined in RFC 4567 [7] and RFC 4568 [8] may also be used for the security parameter distribution of announced session descriptions.
RFC 4567[7]和RFC 4568[8]中定义的SDP属性也可用于公布会话描述的安全参数分布。
The security scheme description defined in RFC 4568 [8] requires a secure communications channel to prevent third parties from eavesdropping on the keying parameters and manipulation. Therefore, SAP security (as defined in RFC 2974 [11]), S/MIME [12], HTTPS [13], or other suitable mechanisms SHOULD be used for distributing or accessing these session descriptions.
RFC 4568[8]中定义的安全方案说明需要一个安全的通信通道，以防止第三方窃听密钥参数和操纵。因此，应使用SAP安全性（如RFC 2974[11]中的定义）、S/MIME[12]、HTTPS[13]或其他合适的机制来分发或访问这些会话描述。
SAVP and SAVPF entities MAY be mixed in the same RTP session (see also Section 4) and so MAY AVP and AVPF entities. Other combinations -- i.e., between secure and insecure profiles -- in the same RTP session are incompatible and MUST NOT be used together.
SAVP和SAVPF实体可以在同一RTP会话中混合（另请参见第4节），AVP和AVPF实体也可以混合。同一RTP会话中的其他组合（即安全和不安全配置文件之间）是不兼容的，不能一起使用。
If negotiation between the involved peers is possible (as with the offer/answer model per Section 3.3.1 or RTSP per Section 3.3.2), alternative (secure and non-secure) profiles MAY be specified by one entity (e.g., the offerer) and a choice of one profile MUST be made by the other. If no such negotiation is possible (e.g., with SAP as per Section 3.3.3), incompatible profiles MUST NOT be specified as alternatives.
如果相关对等方之间可以进行协商（如第3.3.1节中的报价/应答模型或第3.3.2节中的RTSP），备选（安全和非安全）配置文件可由一个实体（如报价人）指定，另一个实体必须选择一个配置文件。如果无法进行此类协商（例如，根据第3.3.3节与SAP进行协商），则不得将不兼容的配置文件指定为备选配置文件。
The negotiation of alternative profiles is for further study.
备选剖面的协商有待进一步研究。
RTP profiles MAY be mixed arbitrarily across different RTP sessions.
RTP配置文件可以在不同的RTP会话中任意混合。
This section includes examples for the use of SDP to negotiate the use of secure and non-secure profiles. Depending on what keying mechanism is being used and how it parameterized, the SDP messages typically require integrity protection and, for some mechanisms, will also need confidentiality protection. For example, one could say integrity protection is required for the a=fingerprint of Datagram Transport Layer Security - Secure Real-time Transport Protocol (DTLS-SRTP) [16], and confidentiality is required for RFC 4568 [8] (Security Descriptions) a=crypto.
本节包括使用SDP协商使用安全和非安全配置文件的示例。根据使用的键控机制及其参数化方式，SDP消息通常需要完整性保护，对于某些机制，还需要保密保护。例如，可以说数据报传输层安全-安全实时传输协议（DTLS-SRTP）[16]的a=指纹需要完整性保护，RFC 4568[8]（安全描述）a=加密需要保密。
Example 1: The following session description indicates a secure session made up from audio and dual tone multi-frequency (DTMF) for point-to-point communication in which the DTMF stream uses Generic NACKs. The key management protocol indicated is MIKEY. This session description (the offer) could be contained in a SIP INVITE or 200 OK message to indicate that its sender is capable of and willing to receive feedback for the DTMF stream it transmits. The corresponding answer may be carried in a 200 OK or an ACK. The parameters for the security protocol are negotiated as described by the SDP extensions defined in RFC 4567 [7].
示例1：以下会话描述表示由音频和双音多频（DTMF）组成的安全会话，用于点对点通信，其中DTMF流使用通用NACK。指示的密钥管理协议是MIKEY。该会话描述（要约）可以包含在SIP INVITE或200 OK消息中，以指示其发送方能够并且愿意接收其发送的DTMF流的反馈。相应的答案可以在200 OK或ACK中携带。安全协议的参数按照RFC 4567[7]中定义的SDP扩展进行协商。
v=0 o=alice 3203093520 3203093520 IN IP4 host.example.com s=Media with feedback t=0 0 c=IN IP4 host.example.com m=audio 49170 RTP/SAVPF 0 96 a=rtpmap:0 PCMU/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=rtcp-fb:96 nack a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
v=0 o=IP4主机中的alice 3203093520.example.com s=Media with feedback t=0 c=IP4主机中的m=audio 49170 RTP/SAVPF 0 96 a=rtpmap:0 PCMU/8000 a=rtpmap:96电话事件/8000 a=fmtp:96 0-16 a=rtcp fb:96 nack a=密钥管理：mikey uiSDF9sdhs727ghsd/DHSOKDOOKDO7EWSNDSJD。。。
Example 2: This example shows the same feedback parameters as example 1 but uses the secure descriptions syntax [8]. Note that the key part of the a=crypto attribute is not protected against eavesdropping and thus the session description needs to be exchanged over a secure communication channel.
示例2：此示例显示与示例1相同的反馈参数，但使用安全描述语法[8]。请注意，a=crypto属性的密钥部分不受窃听保护，因此会话描述需要通过安全通信通道交换。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=crypto:AES_CM_128_HMAC_SHA1_32
inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1
:32
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=crypto:AES_CM_128_HMAC_SHA1_32
inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1
:32
Example 3: This example is replicated from example 1 above, but shows the interaction between the offerer and the answerer in an offer/answer exchange, again using MIKEY to negotiate the keying material:
示例3：该示例复制自上面的示例1，但显示了报价人和应答人在报价/应答交换中的交互，再次使用MIKEY协商键控材料：
Offer:
报价：
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
Answer:
答复:
v=0
o=alice 3203093521 3203093521 IN IP4 host.another.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.another.example.com
a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD...
m=audio 53012 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
v=0
o=alice 3203093521 3203093521 IN IP4 host.another.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.another.example.com
a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD...
m=audio 53012 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
Example 4: This example shows the exchange for video streaming controlled via RTSP. A client acquires a media description from a server using DESCRIBE and obtains a static SDP description without any keying parameters, but the media description shows that both secure and non-secure media sessions using (S)AVPF are available. A mechanism that allows explicit identification of these alternatives (i.e., secure and non-secure sessions) in the session description is presently being defined [14]. The client then issues a SETUP request
示例4：此示例显示通过RTSP控制的视频流交换。客户端使用descripe从服务器获取媒体描述，并获取静态SDP描述，而不使用任何键控参数，但媒体描述显示使用AVPF的安全和非安全媒体会话都可用。目前正在定义一种机制，允许在会话描述中明确标识这些备选方案（即安全会话和非安全会话）[14]。然后，客户端发出安装请求
and indicates its choice by including the respective profile in the Transport parameter. Furthermore, the client includes a KeyMgmt header to convey its security parameters, which is matched by a corresponding KeyMgmt header from the server in the response. Only a single media session is chosen so that the aggregate RTSP URI is sufficient for identification.
并通过在传输参数中包含相应的配置文件来指示其选择。此外，客户机包括用于传送其安全参数的KeyMgmt报头，该安全参数由响应中来自服务器的对应KeyMgmt报头匹配。仅选择单个媒体会话，以便聚合RTSP URI足以进行标识。
RTSP DESCRIBE request-response pair (optional):
RTSP描述请求-响应对（可选）：
DESCRIBE rtsp://movies.example.org/example RTSP/2.0
CSeq: 314
Accept: application/sdp
DESCRIBE rtsp://movies.example.org/example RTSP/2.0
CSeq: 314
Accept: application/sdp
200 OK
CSeq: 314
Date: 25 Nov 2005 22:09:35 GMT
Content-Type: application/sdp
Content-Length: 316
200 OK
CSeq: 314
Date: 25 Nov 2005 22:09:35 GMT
Content-Type: application/sdp
Content-Length: 316
v=0
o=alice 3203093520 3203093520 IN IP4 movies.example.com
s=Media with feedback
t=0 0
c=IN IP4 0.0.0.0
+-Alternative one-----------------+
|m=video 49170 RTP/SAVPF 96 |
|a=rtpmap:96 H263-2000/90000 |
|a=rtcp-fb:96 nack |
+---------------------------------+
+-Alternative two-----------------+
|m=video 49172 RTP/AVPF 96 |
|a=rtpmap:96 H263-2000/90000 |
|a=rtcp-fb:96 nack |
+---------------------------------+
v=0
o=alice 3203093520 3203093520 IN IP4 movies.example.com
s=Media with feedback
t=0 0
c=IN IP4 0.0.0.0
+-Alternative one-----------------+
|m=video 49170 RTP/SAVPF 96 |
|a=rtpmap:96 H263-2000/90000 |
|a=rtcp-fb:96 nack |
+---------------------------------+
+-Alternative two-----------------+
|m=video 49172 RTP/AVPF 96 |
|a=rtpmap:96 H263-2000/90000 |
|a=rtcp-fb:96 nack |
+---------------------------------+
RTSP SETUP request-response pair
RTSP设置请求-响应对
SETUP rtsp://movies.example.org/example RTSP/2.0
CSeq: 315
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..."
SETUP rtsp://movies.example.org/example RTSP/2.0
CSeq: 315
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..."
200 OK CSeq: 315 Date: 25 Nov 2005 22:09:36 GMT Session: 4711
200 OK CSeq:315日期：2005年11月25日22:09:36 GMT会议：4711
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013";
src_addr="192.0.2.15:60000"/"192.0.2.15:60001"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..."
Accept-Ranges: NPT, SMPTE
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013";
src_addr="192.0.2.15:60000"/"192.0.2.15:60001"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..."
Accept-Ranges: NPT, SMPTE
Example 5: The following session description indicates a multicast audio/video session (using PCMU for audio and either H.261 or H.263+) with the video source accepting Generic NACKs for both codecs and Reference Picture Selection for H.263. The parameters for the security protocol are negotiated as described by the SDP extensions defined in RFC 4567 [7], used at the session level. Such a description may have been conveyed using the Session Announcement Protocol (SAP).
示例5：以下会话描述表示多播音频/视频会话（使用PCMU进行音频和H.261或H.263+），视频源接受编解码器的通用NACK和H.263的参考图片选择。安全协议的参数按照RFC 4567[7]中定义的SDP扩展进行协商，用于会话级别。这样的描述可能已经使用会话公告协议（SAP）传达。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/SAVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/SAVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
The SAVPF profile defined in this document is a combination of the SAVP profile [4] and the AVPF profile [3] (which in turn is an extension of the RTP profile as defined in RFC 3551 [2]).
本文件中定义的SAVPF配置文件是SAVP配置文件[4]和AVPF配置文件[3]的组合（后者是RFC 3551[2]中定义的RTP配置文件的扩展）。
SAVP and SAVPF use SRTP [4] to achieve security. AVP and AVPF use plain RTP [1] and hence do not provide security (unless external security mechanisms are applied as discussed in Section 9.1 of RFC 3550 [1]). SRTP and RTP are not meant to interoperate; the respective protocol entities are not supposed to be part of the same RTP session. Hence, AVP and AVPF on one side and SAVP and SAVPF on the other MUST NOT be mixed.
SAVP和SAVPF使用SRTP[4]实现安全性。AVP和AVPF使用普通RTP[1]，因此不提供安全性（除非按照RFC 3550[1]第9.1节的讨论应用了外部安全机制）。SRTP和RTP并不意味着互操作；各个协议实体不应是同一RTP会话的一部分。因此，一侧的AVP和AVPF以及另一侧的SAVP和SAVP不得混合。
RTP entities using the SAVP and the SAVPF profiles MAY be mixed in a single RTP session. The interworking considerations defined in Section 5 of RFC 4585 [3] apply.
使用SAVP和SAVPF配置文件的RTP实体可以在单个RTP会话中混合使用。RFC 4585[3]第5节中定义的互通注意事项适用。
The SAVPF profile inherits its security properties from the SAVP profile; therefore, it is subject to the security considerations discussed in RFC 3711 [4]. When compared to SAVP, the SAVPF profile does not add or take away any security services.
SAVPF配置文件从SAVP配置文件继承其安全属性；因此，它受RFC 3711[4]中讨论的安全考虑因素的影响。与SAVP相比，SAVPF配置文件不会添加或删除任何安全服务。
There is a desire to support security for media streams and, at the same time, for backward compatibility with non-SAVP(F) nodes.
人们希望支持媒体流的安全性，同时支持与非SAVP（F）节点的向后兼容性。
Application designers should be aware that security SHOULD NOT be traded for interoperability. If information is to be distributed to closed groups (i.e., confidentially protected), it is RECOMMENDED not to offer alternatives for a media session other than SAVP and SAVPF as described in Sections 3.3 and 3.4, unless other security mechanisms will be used, e.g., the ones described in Section 9.1 of RFC 3550 [1]. Similarly, if integrity protection is considered important, it is RECOMMENDED not to offer the alternatives other than SAVP and SAVPF, unless other mechanisms are known to be in place that can guarantee it, e.g., lower-layer mechanisms as described in Section 9 of RFC 3550 [1].
应用程序设计者应该意识到，不应该用安全性换取互操作性。如果信息要分发给封闭组（即受保密保护），建议不要提供第3.3节和第3.4节所述SAVP和SAVPF以外的媒体会话替代方案，除非将使用其他安全机制，例如RFC 3550[1]第9.1节所述的机制。同样，如果完整性保护被认为是重要的，建议不要提供SAVP和SAVPF以外的替代方案，除非已知有其他机制可以保证，例如RFC 3550[1]第9节所述的低层机制。
Offering secure and insecure profiles simultaneously may open to bidding down attacks. Therefore, such a mix of profile offer SHOULD NOT be made.
同时提供安全和不安全的配置文件可能会降低攻击。因此，不应提供这种组合的配置文件。
Note that the rules for sharing master keys apply as described in RFC 3711 [4] (e.g., Section 9.1). In particular, the same rules for avoiding the two-time pad (keystream reuse) apply: a master key MUST NOT be shared among different RTP sessions unless the SSRCs used are unique across all the RTP streams of the RTP sessions that share the same master key.
请注意，共享主密钥的规则适用于RFC 3711[4]（例如，第9.1节）。特别是，避免两次pad（密钥流重用）的相同规则适用：主密钥不得在不同RTP会话之间共享，除非在共享相同主密钥的RTP会话的所有RTP流中使用的SSRC是唯一的。
When 2^48 SRTP packets or 2^31 SRTCP packets have been secured with the same key (whichever occurs before), the key management MUST be called to provide new master key(s) (previously stored and used keys MUST NOT be used again), or the session MUST be terminated.
当2^48 SRTP数据包或2^31 SRTCP数据包使用相同的密钥进行安全保护时（以较早发生的为准），必须调用密钥管理以提供新的主密钥（以前存储和使用的密钥不得再次使用），或者必须终止会话。
Different media sessions may use a mix of different profiles, particularly including a secure profile and an insecure profile. However, mixing secure and insecure media sessions may reveal information to third parties and thus the decision to do so MUST be in line with a local security policy. For example, the local policy MUST specify whether it is acceptable to have, e.g., the audio stream not secured and the related video secured.
不同媒体会话可以使用不同配置文件的混合，特别是包括安全配置文件和不安全配置文件。但是，混合使用安全和不安全的媒体会话可能会向第三方泄露信息，因此，这样做的决定必须符合当地的安全政策。例如，本地策略必须指定是否可以接受音频流不安全和相关视频安全。
The security considerations in RFC 4585 [3] are valid, too. Note in particular, applying the SAVPF profile implies mandatory integrity protection on RTCP. While this solves the problem of false packets from members not belonging to the group, it does not solve the issues related to a malicious member acting improperly.
RFC 4585[3]中的安全注意事项也是有效的。特别注意，应用SAVPF配置文件意味着对RTCP进行强制性完整性保护。虽然这解决了来自不属于该组的成员的虚假数据包问题，但它并不能解决与恶意成员行为不当有关的问题。
The following contact information shall be used for all registrations included here:
以下联系信息应用于此处包含的所有注册：
Contact: Joerg Ott
mail: jo@acm.org
tel: +358-9-451-2460
Contact: Joerg Ott
mail: jo@acm.org
tel: +358-9-451-2460
The secure RTP feedback profile, as a combination of Secure RTP and the feedback profile, has been registered for the Session Description Protocol (specifically the type "proto"): "RTP/SAVPF".
安全RTP反馈配置文件，作为安全RTP和反馈配置文件的组合，已经为会话描述协议（特别是类型“proto”）：“RTP/SAVPF”注册。
SDP Protocol ("proto"):
SDP协议（“协议”）：
Name: RTP/SAVPF Long form: Secure RTP Profile with RTCP-based Feedback Type of name: proto Type of attribute: Media level only Purpose: RFC 5124 Reference: RFC 5124
名称：RTP/SAVPF长格式：基于RTCP的反馈的安全RTP配置文件名称类型：属性原型：仅媒体级别用途：RFC 5124参考：RFC 5124
All the SDP attributes defined for RTP/SAVP and RTP/AVPF are valid for RTP/SAVPF, too.
为RTP/SAVP和RTP/AVPF定义的所有SDP属性也对RTP/SAVPF有效。
This document is a product of the Audio-Visual Transport (AVT) Working Group of the IETF. The authors would like to thank Magnus Westerlund, Colin Perkins, and Cullen Jennings for their comments.
本文件是IETF视听传输（AVT）工作组的产品。作者要感谢Magnus Westerlund、Colin Perkins和Cullen Jennings的评论。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[2] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[3] 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.
[3] Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[4] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[4] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[6] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[7] 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.
[7] Arkko，J.，Lindholm，F.，Naslund，M.，Norrman，K.，和E.Carrara，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，2006年7月。
[8] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[8] Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 4568，2006年7月。
[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[10] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[10] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[11] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[11] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[12] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[12] Ramsdell，B.，编辑，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[13] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[13] Rescorla，E.，“TLS上的HTTP”，RFC 2818，2000年5月。
[14] Andreasen, F., "SDP Capability Negotiation", Work in Progress, December 2007.
[14] Andreasen，F.，“SDP能力谈判”，正在进行的工作，2007年12月。
[15] 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.
[15] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[16] McGrew, D. and Rescorla, E., "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", Work in Progress, November 2007.
[16] McGrew，D.和Rescorla，E.，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，正在进行的工作，2007年11月。
Authors' Addresses
作者地址
Joerg Ott Helsinki University of Technology Otakaari 5A FI-02150 Espoo Finland
芬兰埃斯波奥塔卡里5A FI02150赫尔辛基工业大学
EMail: jo@comnet.tkk.fi
Phone: +358-9-451-2460
EMail: jo@comnet.tkk.fi
Phone: +358-9-451-2460
Elisabetta Carrara Royal Institute of Technology Stockholm Sweden
瑞典斯德哥尔摩皇家理工学院Elisabetta Carrara
EMail: carrara@kth.se
EMail: carrara@kth.se
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.