Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 7879 T. Reddy
Category: Standards Track G. Salgueiro
ISSN: 2070-1721 Cisco
V. Pascual
Oracle
P. Ravindran
Nokia Networks
May 2016
Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 7879 T. Reddy
Category: Standards Track G. Salgueiro
ISSN: 2070-1721 Cisco
V. Pascual
Oracle
P. Ravindran
Nokia Networks
May 2016
DTLS-SRTP Handling in SIP Back-to-Back User Agents
SIP背靠背用户代理中的DTLS-SRTP处理
Abstract
摘要
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) exist on the signaling and media paths between the endpoints. This document describes the behavior of B2BUAs when Secure Real-time Transport (SRTP) security context is set up with the Datagram Transport Layer Security (DTLS) protocol.
会话发起协议（SIP）背靠背用户代理（B2BUA）存在于端点之间的信令和媒体路径上。本文档描述了使用数据报传输层安全（DTLS）协议设置安全实时传输（SRTP）安全上下文时B2BUAs的行为。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7879.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7879.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Goals and Scope of this Document . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. B2BUAs Procedures to Allow End-to-End DTLS-SRTP . . . . . . . 5
4. Signaling-Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . 5
4.1. Proxy-B2BUAs . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Signaling-Only and SDP-Modifying Signaling-Only B2BUAs . 6
5. Media-Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . . . 6
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.1. Media Relay . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. RTP- and RTCP-Aware Media-Aware B2BUA . . . . . . . . 8
6. Forking Considerations . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Goals and Scope of this Document . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. B2BUAs Procedures to Allow End-to-End DTLS-SRTP . . . . . . . 5
4. Signaling-Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . 5
4.1. Proxy-B2BUAs . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Signaling-Only and SDP-Modifying Signaling-Only B2BUAs . 6
5. Media-Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . . . 6
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.1. Media Relay . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. RTP- and RTCP-Aware Media-Aware B2BUA . . . . . . . . 8
6. Forking Considerations . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
[RFC5763] describes how the Session Initiation Protocol (SIP) [RFC3261] can be used to establish a Secure Real-time Transport Protocol (SRTP) [RFC3711] security context with the Datagram Transport Layer Security (DTLS) protocol [RFC6347]. It describes a mechanism for transporting a certificate fingerprint using the Session Description Protocol (SDP) [RFC4566]. The fingerprint identifies the certificate that will be presented during the DTLS handshake. DTLS-SRTP is currently defined for point-to-point media sessions, in which there are exactly two participants. Each DTLS-SRTP session (described in Section 3 of [RFC5764]) contains a single DTLS connection (if RTP and RTP Control Protocol (RTCP) are multiplexed) or two DTLS connections (if RTP and RTCP are not multiplexed), and either two SRTP contexts (if media traffic is flowing in both directions on the same 5-tuple) or one SRTP context (if media traffic is only flowing in one direction).
[RFC5763]描述了如何使用会话启动协议（SIP）[RFC3261]与数据报传输层安全（DTLS）协议[RFC6347]建立安全实时传输协议（SRTP）[RFC3711]安全上下文。它描述了使用会话描述协议（SDP）[RFC4566]传输证书指纹的机制。指纹识别将在DTLS握手期间提供的证书。DTLS-SRTP目前定义为点对点媒体会话，其中正好有两个参与者。每个DTLS-SRTP会话（如[RFC5764]第3节所述）包含一个DTLS连接（如果RTP和RTP控制协议（RTCP）被多路复用）或两个DTLS连接（如果RTP和RTCP未被多路复用），以及两个SRTP上下文（如果媒体流量在同一个5元组上双向流动）或一个SRTP上下文（如果媒体流量仅朝一个方向流动）。
In many SIP deployments, SIP Back-to-Back User Agents (B2BUA) entities exist on the SIP-signaling path between the endpoints. As described in [RFC7092], these B2BUAs can modify SIP and SDP information. For example, as described in Section 3.1.3 of [RFC7092], SDP-modifying signaling-only B2BUAs can potentially modify the SDP. B2BUAs can also be present on the media path, in which case they modify parts of the SDP information (like IP address, port) and subsequently modify the RTP headers as well. Such B2BUAs are referred to as "media-plane B2BUAs". [RFC7092] describes two different categories of media-plane B2BUAs, according to the level of activities performed on the media plane.
在许多SIP部署中，SIP背靠背用户代理（B2BUA）实体存在于端点之间的SIP信令路径上。如[RFC7092]所述，这些B2BUA可以修改SIP和SDP信息。例如，如[RFC7092]第3.1.3节所述，SDP修改信令只有B2BUA可能修改SDP。B2BUA也可以出现在媒体路径上，在这种情况下，它们修改部分SDP信息（如IP地址、端口），并随后修改RTP报头。此类B2BUA被称为“媒体平面B2BUA”。[RFC7092]根据在媒体平面上执行的活动级别，描述了两种不同类型的媒体平面B2BUA。
When B2BUAs are present in a call between two SIP User Agents (UAs), they often make end-to-end DTLS-SRTP sessions impossible. An "end-to-end DTLS-SRTP session" means that man-in-the-middle devices cannot break the DTLS-SRTP session between the endpoints. In other words, the man-in-the-middle device cannot create a separate DTLS-SRTP session between the client and the middle device on one side, and the middle device and the remote peer on the other side. B2BUAs may be deployed for address hiding or media latching [RFC7362], although Traversal Using Relays around NAT (TURN) and Interactive Connectivity Establishment (ICE) are expected to be used more often for this purpose as it provides better security properties. Such B2BUAs are able to perform their functions without requiring termination of DTLS-SRTP sessions, i.e., these B2BUAs need not act as DTLS proxy and decrypt the RTP payload.
当B2BUA出现在两个SIP用户代理（UAs）之间的呼叫中时，它们通常使端到端DTLS-SRTP会话无法进行。“端到端DTLS-SRTP会话”意味着中间人设备无法中断端点之间的DTLS-SRTP会话。换言之，中间人设备无法在一端的客户端和中间设备以及另一端的中间设备和远程对等设备之间创建单独的DTLS-SRTP会话。B2BUA可以部署用于地址隐藏或媒体锁定[RFC7362]，尽管使用NAT（TURN）和交互式连接建立（ICE）周围的中继进行遍历预计将更经常地用于此目的，因为它提供了更好的安全属性。此类B2BUA能够在不需要终止DTLS-SRTP会话的情况下执行其功能，即，这些B2BUA不需要充当DTLS代理并解密RTP有效负载。
A B2BUA could be deployed for address hiding or media latching as described in [RFC7362]. Such B2BUAs only terminate the media plane at the IP and transport (UDP/TCP) layers and may inspect the RTP headers or RTP Control Protocol (RTCP) packets. The goal of this specification is to provide guidance on how such B2BUAs function without breaking the end-to-end DTLS-SRTP session. A B2BUA could also terminate the media, or modify the RTP headers or RTP Control Protocol (RTCP) packets. Such B2BUAs will not allow end-to-end DTLS-SRTP. The recommendations made in this document are not expected to be applied by B2BUAs terminating DTLS-SRTP sessions given deployment reality.
如[RFC7362]所述，可以部署B2BUA进行地址隐藏或媒体锁定。此类B2BUA仅在IP和传输（UDP/TCP）层终止媒体平面，并可检查RTP报头或RTP控制协议（RTCP）数据包。本规范的目标是在不中断端到端DTLS-SRTP会话的情况下，为此类B2BUA的功能提供指导。B2BUA还可以终止媒体，或修改RTP报头或RTP控制协议（RTCP）数据包。此类B2BUA不允许端到端DTLS-SRTP。鉴于部署现实，B2BUAs终止DTLS-SRTP会话时，预计不会应用本文件中提出的建议。
This specification assumes that a B2BUA is not providing identity assurance and is not authorized to terminate the DTLS-SRTP session. A B2BUA that provides identity assurance on behalf of endpoints behind it can modify any portion of SIP and SDP before it generates the identity signature. As the B2BUA is generating the identity signature, it is not possible to detect if a B2BUA has terminated the DTLS-SRTP session. B2BUAs providing identity assurance and terminating DTLS-SRTP sessions are out of scope of this document.
本规范假设B2BUA不提供身份保证，并且未被授权终止DTLS-SRTP会话。代表其背后的端点提供身份保证的B2BUA可以在生成身份签名之前修改SIP和SDP的任何部分。由于B2BUA正在生成身份签名，因此无法检测B2BUA是否已终止DTLS-SRTP会话。提供身份保证和终止DTLS-SRTP会话的B2BUA不在本文档范围内。
The following sections describe the behavior B2BUAs can follow to avoid breaking end-to-end DTLS-SRTP sessions.
以下部分描述B2BUAs可以遵循的行为，以避免中断端到端DTLS-SRTP会话。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Transport Address: The combination of an IP address and port number.
传输地址：IP地址和端口号的组合。
The following generalized terms are defined in [RFC3261], Section 6.
[RFC3261]第6节定义了以下通用术语。
B2BUA: A SIP Back-to-Back User Agent, which is the logical combination of a User Agent Server (UAS) and a User Agent Client (UAC).
B2BUA:SIP背靠背用户代理，是用户代理服务器（UAS）和用户代理客户端（UAC）的逻辑组合。
UAS: A SIP User Agent Server.
UAS：SIP用户代理服务器。
UAC: A SIP User Agent Client.
UAC：SIP用户代理客户端。
All of the pertinent B2BUA terminology and taxonomy used in this document are based on [RFC7092].
本文件中使用的所有相关B2BUA术语和分类法均基于[RFC7092]。
It is assumed the reader is already familiar with the fundamental concepts of the RTP protocol [RFC3550] and its taxonomy [RFC7656], as well as those of SRTP [RFC3711] and DTLS [RFC6347].
假设读者已经熟悉RTP协议[RFC3550]及其分类法[RFC7656]的基本概念，以及SRTP[RFC3711]和DTLS[RFC6347]的基本概念。
A B2BUA MUST follow the rules mentioned below to allow end-to-end DTLS-SRTP sessions.
B2BUA必须遵循以下规则，以允许端到端DTLS-SRTP会话。
1. B2BUAs MUST forward the certificate fingerprint and SDP setup attribute it receives from one endpoint unmodified towards the other endpoint and vice versa.
1. B2BUAs必须将它从一个端点接收的证书指纹和SDP设置属性（未修改）转发到另一个端点，反之亦然。
2. The enhancements described in [RFC4474] provide a means for signing portions of SIP requests in order to provide identity assurance and certificate pinning by providing an identity signature over the SDP that carries the fingerprint of keying for DTLS-SRTP [RFC5763]. B2BUAs can identify that the enhancements in [RFC4474] are used for identity assurance if the SIP request contains both Identity and Identity-Info headers. In cases where endpoints use [RFC4474], B2BUAs MUST ensure that it does not modify any of the information used to construct the identity signature. This includes the entire SDP body and portions of the SIP header as described in [RFC4474]. In this case, a B2BUA cannot act as a media-relay B2BUA.
2. [RFC4474]中描述的增强功能提供了一种对SIP请求部分进行签名的方法，以便通过在SDP上提供身份签名来提供身份保证和证书固定，该SDP携带DTLS-SRTP的密钥指纹[RFC5763]。如果SIP请求同时包含标识和标识信息头，B2BUAs可以确定[RFC4474]中的增强功能用于标识保证。在端点使用[RFC4474]的情况下，B2BUAs必须确保它不会修改用于构造身份签名的任何信息。这包括[RFC4474]中所述的整个SDP主体和SIP头的部分。在这种情况下，B2BUA不能充当媒体中继B2BUA。
3. [SIP-ID] is introduced to overcome the limitations of [RFC4474] (discussed in Section 1 of [SIP-ID]). Unlike [RFC4474], [SIP-ID] does not generate an identity signature over material that intermediaries in the field commonly alter. In this case, a B2BUA can act as a media-relay B2BUA. B2BUAs can identify that [SIP-ID] is used for identity assurance if the SIP request contains an Identity header but does not include an Identity-Info header. The Identity-Info header is deprecated in [SIP-ID]. A B2BUA MUST ensure that it does not modify any of the headers used to construct the identity signature.
3. 引入[SIP-ID]是为了克服[RFC4474]（在[SIP-ID]第1节中讨论）的限制。与[RFC4474]不同，[SIP-ID]不会在该领域的中介机构通常更改的材料上生成身份签名。在这种情况下，B2BUA可以充当媒体中继B2BUA。如果SIP请求包含标识头但不包含标识信息头，B2BUAs可以识别[SIP-ID]用于标识保证。[SIP-ID]中不推荐使用标识信息标头。B2BUA必须确保它不会修改用于构造身份签名的任何头。
4. Both media relays and media-aware relays MUST NOT modify the authenticated portion of RTP and RTCP packets, and MUST NOT modify the authentication tag in the RTP and RTCP packets.
4. 媒体中继和媒体感知中继都不得修改RTP和RTCP数据包的认证部分，也不得修改RTP和RTCP数据包中的认证标签。
Section 3.1 of [RFC7092] describes different categories of signaling-plane B2BUAs. This section explains how these B2BUAs are expected to comply with the recommendations in Section 3.
[RFC7092]第3.1节描述了不同类别的信号平面B2BUA。本节解释了这些B2BUA应如何遵守第3节中的建议。
Proxy-B2BUAs, as defined in Section 3.1.1 of [RFC7092], modify only the Via and Record-Route SIP headers. These B2BUAs can continue to perform their function and still allow end-to-end DTLS-SRTP sessions since none of the headers used to construct the identity signature are modified.
[RFC7092]第3.1.1节中定义的代理B2BUAs仅修改Via并记录路由SIP头。这些B2BUA可以继续执行其功能，并且仍然允许端到端DTLS-SRTP会话，因为没有修改用于构造身份签名的头。
These categories of B2BUAs are likely to modify headers that are used to construct the identity signature. For example, a signaling-only B2BUA can modify the Contact URI. Such B2BUAs are likely to violate rule 2 or rule 3 in Section 3. Depending upon the application requirements, such a B2BUA may be able to limit modification of header fields to those allowed to be modified by [RFC4474] or [SIP-ID].
这些类别的B2BUA可能会修改用于构造身份签名的标头。例如，仅信令B2BUA可以修改联系人URI。此类B2BUA可能违反第3节中的规则2或规则3。根据应用要求，这样的B2BUA可以将头字段的修改限制为[RFC4474]或[SIP-ID]允许修改的那些字段。
This section describes how the different types of media-plane B2BUAs defined in [RFC7092] are expected to comply with the recommendations in Section 3.
本节描述了[RFC7092]中定义的不同类型的媒体平面B2BU如何符合第3节中的建议。
From an application-layer point of view, a media relay (as defined in Section 3.2.1 of [RFC7092]) forwards all packets it receives on a negotiated connection, without inspecting or modifying the packet contents. A media relay only modifies the transport layer (UDP/TCP) and IP headers.
从应用层的角度来看，媒体中继（如[RFC7092]第3.2.1节所定义）转发其在协商连接上接收的所有数据包，而无需检查或修改数据包内容。媒体中继仅修改传输层（UDP/TCP）和IP头。
A media-relay B2BUA follows rule 1 mentioned in Section 3 and forwards the certificate fingerprint and SDP setup attribute it receives from one endpoint unmodified towards the other endpoint and vice versa. The following example shows a SIP call establishment flow, with both SIP endpoints (user agents) using DTLS-SRTP, and a media-relay B2BUA.
媒体中继B2BUA遵循第3节中提到的规则1，并将其从一个端点接收到的未修改的证书指纹和SDP设置属性转发给另一个端点，反之亦然。以下示例显示了SIP呼叫建立流程，其中SIP端点（用户代理）使用DTLS-SRTP，媒体中继B2BUA。
+-------+ +-------------------+ +-----+
| Alice | | Media-Relay B2BUA | | Bob |
+-------+ +-------------------+ +-----+
|(1) INVITE | (3) INVITE |
| a=setup:actpass | a=setup:actpass |
| a=fingerprint1 | a=fingerprint1 |
| (Alice's IP/port) | (B2BUAs IP/port) |
|------------------------>|-------------------------->|
| | |
| (2) 100 trying | |
|<------------------------| |
| | (4) 100 trying |
| |<--------------------------|
| | |
| | (5) 200 OK |
| | a=setup:active |
| | a=fingerprint2 |
| | (Bob's IP/port) |
|<------------------------|<--------------------------|
| (6) 200 OK | |
| a=setup:active | |
| a=fingerprint2 | |
| B2BUAs IP/port | |
| (7, 8) ClientHello + use_srtp |
|<----------------------------------------------------|
|(B2BUA changes transport(UDP/TCP) and IP header) |
| | |
| | |
| (9,10) ServerHello + use_srtp |
|---------------------------------------------------->|
|(B2BUA changes transport(UDP/TCP) and IP header) |
| | |
| | |
| (11) | |
| [Certificate exchange between Alice and Bob over |
| DTLS ] | |
| | |
| (12) | |
|<---------SRTP/SRTCP-----------SRTP/SRTCP----------->|
| [B2BUA changes transport(UDP/TCP) and IP headers] |
+-------+ +-------------------+ +-----+
| Alice | | Media-Relay B2BUA | | Bob |
+-------+ +-------------------+ +-----+
|(1) INVITE | (3) INVITE |
| a=setup:actpass | a=setup:actpass |
| a=fingerprint1 | a=fingerprint1 |
| (Alice's IP/port) | (B2BUAs IP/port) |
|------------------------>|-------------------------->|
| | |
| (2) 100 trying | |
|<------------------------| |
| | (4) 100 trying |
| |<--------------------------|
| | |
| | (5) 200 OK |
| | a=setup:active |
| | a=fingerprint2 |
| | (Bob's IP/port) |
|<------------------------|<--------------------------|
| (6) 200 OK | |
| a=setup:active | |
| a=fingerprint2 | |
| B2BUAs IP/port | |
| (7, 8) ClientHello + use_srtp |
|<----------------------------------------------------|
|(B2BUA changes transport(UDP/TCP) and IP header) |
| | |
| | |
| (9,10) ServerHello + use_srtp |
|---------------------------------------------------->|
|(B2BUA changes transport(UDP/TCP) and IP header) |
| | |
| | |
| (11) | |
| [Certificate exchange between Alice and Bob over |
| DTLS ] | |
| | |
| (12) | |
|<---------SRTP/SRTCP-----------SRTP/SRTCP----------->|
| [B2BUA changes transport(UDP/TCP) and IP headers] |
Figure 1: INVITE with SDP Call Flow for Media-Relay B2BUA
图1：媒体中继B2BUA的INVITE with SDP呼叫流
Note: For brevity, the entire value of the SDP fingerprint attribute is not shown. The example here shows only one DTLS connection for the sake of simplicity. In reality, depending on whether the RTP and RTCP flows are multiplexed or demultiplexed, there will be one or two DTLS connections.
注意：为简洁起见，未显示SDP指纹属性的整个值。为了简单起见，这里的示例仅显示一个DTLS连接。实际上，根据RTP和RTCP流是多路复用还是多路解复用，将有一个或两个DTL连接。
If RTP and RTCP traffic is multiplexed on a single port as described in [RFC5761], then only a single DTLS connection is required between the peers. If RTP and RTCP are not multiplexed, then the peers would have to establish two DTLS connections. In this case, after receiving an INVITE request, Bob triggers the establishment of a DTLS connection. Note that the DTLS handshake and the sending of the INVITE response can happen in parallel; thus, the B2BUA has to be prepared to receive DTLS, Session Traversal Utilities for NAT (STUN), and media on the ports it advertised to Bob in the SDP offer before it receives an SDP answer from Bob. Since a media-relay B2BUA does not differentiate between a DTLS message, RTP, or any packet it receives, it only changes the transport layer (UDP/TCP) and IP headers and forwards the packet towards the other endpoint. The B2BUA cannot decrypt the RTP payload, as the payload is encrypted using the SRTP keys derived from the DTLS connection setup between Alice and Bob.
如[RFC5761]所述，如果RTP和RTCP通信在单个端口上多路传输，则对等方之间只需要一个DTLS连接。如果RTP和RTCP未多路复用，则对等方必须建立两个DTL连接。在这种情况下，在收到INVITE请求后，Bob触发DTLS连接的建立。请注意，DTLS握手和INVITE响应的发送可以并行进行；因此，B2BUA在收到Bob的SDP应答之前，必须准备接收DTL、NAT会话遍历实用程序（STUN）和SDP报价中向Bob公布的端口上的媒体。由于媒体中继B2BUA不区分DTLS消息、RTP或其接收的任何数据包，因此它只更改传输层（UDP/TCP）和IP报头，并将数据包转发到另一个端点。B2BUA无法解密RTP有效负载，因为有效负载是使用从Alice和Bob之间的DTLS连接设置派生的SRTP密钥加密的。
If the endpoints use [RFC4474], a B2BUA cannot function as a media-relay without violating rule 2 in Section 3. If [SIP-ID] is used, a B2BUA can modify the IP address in the c= line and the port in the m= line in the SDP as long as it does not otherwise violate rule 3 in Section 3.
如果端点使用[RFC4474]，B2BUA不能在不违反第3节规则2的情况下充当媒体中继。如果使用[SIP-ID]，B2BUA可以在SDP中修改c=行中的IP地址和m=行中的端口，只要不违反第3节中的规则3。
Unlike the media relay discussed in Section 5.1.1, a media-aware relay as defined in Section 3.2.2 of [RFC7092] is aware of the type of media traffic it is receiving. There are two types of media-aware relays, those that merely inspect the RTP headers and unencrypted portions of RTCP packets, and those that inspect and modify the RTP headers and unencrypted portions of RTCP packets.
与第5.1.1节中讨论的媒体中继不同，[RFC7092]第3.2.2节中定义的媒体感知中继可感知其接收的媒体流量类型。有两种类型的媒体感知中继，一种仅检查RTP报头和RTCP数据包的未加密部分，另一种检查和修改RTP报头和RTCP数据包的未加密部分。
An RTP-/RTCP-aware media relay does not modify the RTP headers and RTCP packets but only inspects the packets. Such B2BUAs follow rule 4 in Section 3 and can continue to do their function while allowing end-to-end DTLS-SRTP. Inspection by the B2BUA will not reveal the clear-text for encrypted parts of the SRTP/SRTCP packets.
支持RTP-/RTCP的媒体中继不会修改RTP报头和RTCP数据包，而只检查数据包。此类B2BUA遵循第3节中的规则4，可以继续执行其功能，同时允许端到端DTLS-SRTP。B2BUA的检查不会显示SRTP/SRTCP数据包加密部分的明文。
A B2BUA cannot modify RTP headers or RTCP packets, as to do so it would need to act as a DTLS endpoint, terminate the DTLS-SRTP session, and decrypt/re-encrypt RTP packets. If a B2BUA modifies unencrypted or encrypted portions of the RTP or RTCP packets, then the integrity check will fail and the packet will be dropped by the endpoint. The unencrypted and encrypted portions of the RTP or RTCP
B2BUA不能修改RTP报头或RTCP数据包，因为要这样做，它需要充当DTLS端点，终止DTLS-SRTP会话，并解密/重新加密RTP数据包。如果B2BUA修改RTP或RTCP数据包的未加密或加密部分，则完整性检查将失败，并且该数据包将被端点丢弃。RTP或RTCP的未加密和加密部分
packets are integrity protected using the HMAC algorithm negotiated during the DTLS handshake (discussed in Section 4.1.2 of [RFC5764]). B2BUAs have to follow the rules in Section 3 to avoid breaking the integrity of SRTP/SRTCP streams.
使用DTLS握手期间协商的HMAC算法（在[RFC5764]第4.1.2节中讨论）对数据包进行完整性保护。B2BUA必须遵守第3节中的规则，以避免破坏SRTP/SRTCP流的完整性。
Due to forking [RFC3261], a SIP request carrying an SDP offer sent by an endpoint (offerer) can reach multiple remote endpoints. As a result, multiple DTLS-SRTP sessions can be established, one between the endpoint that sent the SIP request and each of the remote endpoints that received the request. B2BUAs have to follow rule 1 in Section 3 while handling offer/answer and forward the certificate fingerprints and SDP setup attributes it received in the SDP answer from each endpoint (answerer) unmodified towards the offerer. Since each DTLS connection is set up on a unique 5-tuple, B2BUA replaces the answerer's transport addresses in each answer with its unique transport addresses so that the offerer can establish a DTLS connection with each answerer. The B2BUA, acting as a media relay here, follows rule 4 mentioned in Section 3.
由于分叉[RFC3261]，承载端点（提供方）发送的SDP提供的SIP请求可以到达多个远程端点。因此，可以建立多个DTLS-SRTP会话，其中一个会话位于发送SIP请求的端点和接收该请求的每个远程端点之间。B2BUA在处理报价/应答时必须遵循第3节中的规则1，并将其在SDP应答中从每个端点（应答者）收到的证书指纹和SDP设置属性转发给报价者，而不进行修改。由于每个DTLS连接都建立在一个唯一的5元组上，B2BUA将每个应答中应答者的传输地址替换为其唯一的传输地址，以便报价人可以与每个应答者建立DTLS连接。B2BUA作为媒体中继，遵循第3节中提到的规则4。
Bob (192.0.2.1:6666)
/
/
/ DTLS-SRTP=XXX
/
/
DTLS-SRTP=XXX v
<-----------> (192.0.2.3:7777)
Alice (192.0.2.0:5555) B2BUA
<-----------> (192.0.2.3:8888)
DTLS-SRTP=YYY ^
\
\ DTLS-SRTP=YYY
\
\
\
Charlie (192.0.2.2:6666)
Bob (192.0.2.1:6666)
/
/
/ DTLS-SRTP=XXX
/
/
DTLS-SRTP=XXX v
<-----------> (192.0.2.3:7777)
Alice (192.0.2.0:5555) B2BUA
<-----------> (192.0.2.3:8888)
DTLS-SRTP=YYY ^
\
\ DTLS-SRTP=YYY
\
\
\
Charlie (192.0.2.2:6666)
Figure 2: B2BUA Handling Multiple Answers
图2:B2BUA处理多个答案
For instance, as shown in Figure 2, Alice sends a request with an offer and the request is forked. Alice receives answers from both Bob and Charlie. The B2BUA advertises different B2BUA transport addresses in each answer, as shown in Figure 2, where XXX and YYY represent different DTLS-SRTP sessions. The B2BUA replaces Bob's transport address (192.0.2.1:6666) in the answer with its transport address (192.0.2.3:7777) and Charlie's transport address
例如，如图2所示，Alice发送了一个带有offer的请求，请求被分叉。爱丽丝收到鲍勃和查理的答复。B2BUA在每个应答中公布不同的B2BUA传输地址，如图2所示，其中XXX和YYY代表不同的DTLS-SRTP会话。B2BUA将答案中Bob的传输地址（192.0.2.1:6666）替换为其传输地址（192.0.2.3:7777）和Charlie的传输地址
(192.0.2.2:6666) in the answer with its transport address (192.0.2.3:8888). The B2BUA tracks the remote sources (Bob and Charlie) and associates them to the local sources that are used to send packets to Alice.
（192.0.2.2:6666）及其传输地址（192.0.2.3:8888）。B2BUA跟踪远程源（Bob和Charlie），并将它们与用于向Alice发送数据包的本地源相关联。
This document describes the behavior B2BUAs must follow to avoid breaking end-to-end DTLS-SRTP. Media relays that modify RTP or RTCP, or modify SIP header fields or SDP fields that are protected by the identity signature, are incompatible with end-to-end DTLS-SRTP. Such relays are out of scope for this document. Security considerations discussed in [RFC5763] are also applicable to this document. In addition, the B2BUA behaviors outlined in this document do not impact the security and integrity of a DTLS-SRTP session or the data exchanged over it. A malicious B2BUA can try to break into the DTLS connection, but such an attack can be prevented using the identity validation mechanism discussed in [RFC4474] or [SIP-ID]. Either the endpoints or the authentication service proxies involved in the call can use the identity validation mechanisms discussed in [RFC4474] or [SIP-ID] to validate the identity of peers and detect malicious B2BUAs that can attempt to terminate the DTLS connection to decrypt the RTP payload.
本文档描述了B2BUAs必须遵循的行为，以避免破坏端到端DTLS-SRTP。修改RTP或RTCP，或修改受身份签名保护的SIP头字段或SDP字段的媒体中继与端到端DTLS-SRTP不兼容。此类继电器不在本文件范围内。[RFC5763]中讨论的安全注意事项也适用于本文件。此外，本文档中概述的B2BUA行为不会影响DTLS-SRTP会话或通过其交换的数据的安全性和完整性。恶意B2BUA可尝试闯入DTLS连接，但可使用[RFC4474]或[SIP-ID]中讨论的身份验证机制防止此类攻击。呼叫中涉及的端点或认证服务代理可以使用[RFC4474]或[SIP-ID]中讨论的身份验证机制来验证对等方的身份，并检测可能试图终止DTLS连接以解密RTP有效负载的恶意B2BUA。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<http://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<http://www.rfc-editor.org/info/rfc3711>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <http://www.rfc-editor.org/info/rfc5763>.
[RFC5763]Fischl，J.，Tschofenig，H.，和E.Rescorla，“使用数据报传输层安全性（DTLS）建立安全实时传输协议（SRTP）安全上下文的框架”，RFC 5763，DOI 10.17487/RFC5763，2010年5月<http://www.rfc-editor.org/info/rfc5763>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <http://www.rfc-editor.org/info/rfc5764>.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，DOI 10.17487/RFC5764，2010年5月<http://www.rfc-editor.org/info/rfc5764>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, <http://www.rfc-editor.org/info/rfc4474>.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，DOI 10.17487/RFC4474，2006年8月<http://www.rfc-editor.org/info/rfc4474>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路复用RTP数据和控制数据包”，RFC 5761，DOI 10.17487/RFC5761，2010年4月<http://www.rfc-editor.org/info/rfc5761>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <http://www.rfc-editor.org/info/rfc7092>.
[RFC7092]Kaplan，H.和V.Pascual，“会话启动协议（SIP）背对背用户代理的分类”，RFC 7092，DOI 10.17487/RFC7092，2013年12月<http://www.rfc-editor.org/info/rfc7092>.
[RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication", RFC 7362, DOI 10.17487/RFC7362, September 2014, <http://www.rfc-editor.org/info/rfc7362>.
[RFC7362]Ivov，E.，Kaplan，H.，和D.Wing，“闭锁：实时通信中媒体的托管NAT穿越（HNT）”，RFC 7362，DOI 10.17487/RFC7362，2014年9月<http://www.rfc-editor.org/info/rfc7362>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656]Lennox，J.，Gross，K.，Nandakumar，S.，Salgueiro，G.，和B.Burman，Ed.，“实时传输协议（RTP）源的语义和机制分类”，RFC 7656，DOI 10.17487/RFC7656，2015年11月<http://www.rfc-editor.org/info/rfc7656>.
[SIP-ID] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, draft-ietf-stir-rfc4474bis-09, May 2016
[SIP-ID]Peterson，J.，Jennings，C.，Rescorla，E.，和C.Wendt，“会话启动协议（SIP）中的身份验证管理”，正在进行的工作，草案-ietf-stir-rfc4474bis-09，2016年5月
Acknowledgments
致谢
Special thanks to Lorenzo Miniero, Ranjit Avarsala, Hadriel Kaplan, Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes, Brett Tate, Dan Wing, Charles Eckel, Simon Perreault, Albrecht Schwarz, Jens Guballa, Christer Holmberg, Colin Perkins, Ben Campbell, and Alissa Cooper for their constructive comments, suggestions, and early reviews that were critical to the formulation and refinement of this document. The authors would also like to thank Dan Romascanu, Vijay K. Gurbani, Francis Dupont, Paul Wouters, and Stephen Farrell for their review and feedback of this document.
特别感谢Lorenzo Miniero、Ranjit Avarsala、Hadriel Kaplan、Muthu Arul Mozhi、Paul Kyzivat、Peter Dawes、Brett Tate、Dan Wing、Charles Eckel、Simon Perreault、Albrecht Schwarz、Jens Guballa、Christer Holmberg、Colin Perkins、Ben Campbell和Alissa Cooper提出的建设性意见和建议，以及对本文件的制定和完善至关重要的早期审查。作者还要感谢Dan Romascanu、Vijay K.Gurbani、Francis Dupont、Paul Wouters和Stephen Farrell对本文件的审查和反馈。
Contributors
贡献者
Rajeev Seth provided substantial contributions to this document.
Rajeev Seth对此文件做出了重大贡献。
Authors' Addresses
作者地址
Ram Mohan Ravindranath Cisco Cessna Business Park Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India
Ram Mohan Ravindranath Cisco Cessna商业园印度卡纳塔克邦班加罗尔Sarjapur Marathahalli外环路560103
Email: rmohanr@cisco.com
Email: rmohanr@cisco.com
Tirumaleswar Reddy Cisco Cessna Business Park Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
印度卡纳塔克邦班加罗尔Sarjapur Maratalli外环路Tirumaleswar Reddy Cisco Cessna商业园560103
Email: tireddy@cisco.com
Email: tireddy@cisco.com
Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States
Gonzalo Salgueiro Cisco Systems，Inc.美国北卡罗来纳州Kit Creek Road研究三角公园7200-12号，邮编：27709
Email: gsalguei@cisco.com
Email: gsalguei@cisco.com
Victor Pascual Oracle Barcelona, Spain
西班牙巴塞罗那维克多·帕斯夸尔
Email: victor.pascual.avila@oracle.com
Email: victor.pascual.avila@oracle.com
Parthasarathi Ravindran Nokia Networks Bangalore, Karnataka India
印度卡纳塔克邦班加罗尔Parthasarathi Ravindran诺基亚网络公司
Email: partha@parthasarathi.co.in
Email: partha@parthasarathi.co.in