Internet Engineering Task Force (IETF) J. Fischl
Request for Comments: 5763 Skype, Inc.
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
E. Rescorla
RTFM, Inc.
May 2010
Internet Engineering Task Force (IETF) J. Fischl
Request for Comments: 5763 Skype, Inc.
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
E. Rescorla
RTFM, Inc.
May 2010
Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)
使用数据报传输层安全性（DTLS）建立安全实时传输协议（SRTP）安全上下文的框架
Abstract
摘要
This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies.
本文档指定如何使用会话启动协议（SIP）使用数据报传输层安全（DTLS）协议建立安全实时传输协议（SRTP）安全上下文。它描述了一种在会话描述协议（SDP）中传输指纹属性的机制，该协议标识了DTLS握手期间将显示的密钥。密钥交换沿着与信令路径相反的媒体路径进行。SIP身份机制可用于保护指纹属性的完整性，防止中间代理修改。
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/rfc5763.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5763.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. Overview ........................................................5
3. Motivation ......................................................7
4. Terminology .....................................................8
5. Establishing a Secure Channel ...................................8
6. Miscellaneous Considerations ...................................10
6.1. Anonymous Calls ...........................................10
6.2. Early Media ...............................................11
6.3. Forking ...................................................11
6.4. Delayed Offer Calls .......................................11
6.5. Multiple Associations .....................................11
6.6. Session Modification ......................................12
6.7. Middlebox Interaction .....................................12
6.7.1. ICE Interaction ....................................12
6.7.2. Latching Control without ICE .......................13
6.8. Rekeying ..................................................13
6.9. Conference Servers and Shared Encryptions Contexts ........13
6.10. Media over SRTP ..........................................14
6.11. Best Effort Encryption ...................................14
1. Introduction ....................................................4
2. Overview ........................................................5
3. Motivation ......................................................7
4. Terminology .....................................................8
5. Establishing a Secure Channel ...................................8
6. Miscellaneous Considerations ...................................10
6.1. Anonymous Calls ...........................................10
6.2. Early Media ...............................................11
6.3. Forking ...................................................11
6.4. Delayed Offer Calls .......................................11
6.5. Multiple Associations .....................................11
6.6. Session Modification ......................................12
6.7. Middlebox Interaction .....................................12
6.7.1. ICE Interaction ....................................12
6.7.2. Latching Control without ICE .......................13
6.8. Rekeying ..................................................13
6.9. Conference Servers and Shared Encryptions Contexts ........13
6.10. Media over SRTP ..........................................14
6.11. Best Effort Encryption ...................................14
7. Example Message Flow ...........................................14
7.1. Basic Message Flow with Early Media and SIP Identity ......14
7.2. Basic Message Flow with Connected Identity (RFC 4916) .....19
7.3. Basic Message Flow with STUN Check for NAT Case ...........23
8. Security Considerations ........................................25
8.1. Responder Identity ........................................25
8.2. SIPS ......................................................26
8.3. S/MIME ....................................................26
8.4. Continuity of Authentication ..............................26
8.5. Short Authentication String ...............................27
8.6. Limits of Identity Assertions .............................27
8.7. Third-Party Certificates ..................................29
8.8. Perfect Forward Secrecy ...................................29
9. Acknowledgments ................................................29
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
Appendix A. Requirements Analysis ................................33
A.1. Forking and Retargeting (R-FORK-RETARGET,
R-BEST-SECURE, R-DISTINCT) ...............................33
A.2. Distinct Cryptographic Contexts (R-DISTINCT) .............33
A.3. Reusage of a Security Context (R-REUSE) ..................33
A.4. Clipping (R-AVOID-CLIPPING) ..............................33
A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) .........33
A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) .......34
A.7. (R-SIG-MEDIA, R-ACT-ACT) .................................34
A.8. Binding to Identifiers (R-ID-BINDING) ....................34
A.9. Perfect Forward Secrecy (R-PFS) ..........................34
A.10. Algorithm Negotiation (R-COMPUTE) ........................35
A.11. RTP Validity Check (R-RTP-VALID) .........................35
A.12. Third-Party Certificates (R-CERTS, R-EXISTING) ...........35
A.13. FIPS 140-2 (R-FIPS) ......................................35
A.14. Linkage between Keying Exchange and SIP Signaling
(R-ASSOC) ................................................35
A.15. Denial-of-Service Vulnerability (R-DOS) ..................35
A.16. Crypto-Agility (R-AGILITY) ...............................35
A.17. Downgrading Protection (R-DOWNGRADE) .....................36
A.18. Media Security Negotiation (R-NEGOTIATE) .................36
A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) ......36
A.20. Media Recording (R-RECORDING) ............................36
A.21. Interworking with Intermediaries (R-TRANSCODER) ..........36
A.22. PSTN Gateway Termination (R-PSTN) ........................36
A.23. R-ALLOW-RTP ..............................................36
A.24. R-HERFP ..................................................37
7. Example Message Flow ...........................................14
7.1. Basic Message Flow with Early Media and SIP Identity ......14
7.2. Basic Message Flow with Connected Identity (RFC 4916) .....19
7.3. Basic Message Flow with STUN Check for NAT Case ...........23
8. Security Considerations ........................................25
8.1. Responder Identity ........................................25
8.2. SIPS ......................................................26
8.3. S/MIME ....................................................26
8.4. Continuity of Authentication ..............................26
8.5. Short Authentication String ...............................27
8.6. Limits of Identity Assertions .............................27
8.7. Third-Party Certificates ..................................29
8.8. Perfect Forward Secrecy ...................................29
9. Acknowledgments ................................................29
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
Appendix A. Requirements Analysis ................................33
A.1. Forking and Retargeting (R-FORK-RETARGET,
R-BEST-SECURE, R-DISTINCT) ...............................33
A.2. Distinct Cryptographic Contexts (R-DISTINCT) .............33
A.3. Reusage of a Security Context (R-REUSE) ..................33
A.4. Clipping (R-AVOID-CLIPPING) ..............................33
A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) .........33
A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) .......34
A.7. (R-SIG-MEDIA, R-ACT-ACT) .................................34
A.8. Binding to Identifiers (R-ID-BINDING) ....................34
A.9. Perfect Forward Secrecy (R-PFS) ..........................34
A.10. Algorithm Negotiation (R-COMPUTE) ........................35
A.11. RTP Validity Check (R-RTP-VALID) .........................35
A.12. Third-Party Certificates (R-CERTS, R-EXISTING) ...........35
A.13. FIPS 140-2 (R-FIPS) ......................................35
A.14. Linkage between Keying Exchange and SIP Signaling
(R-ASSOC) ................................................35
A.15. Denial-of-Service Vulnerability (R-DOS) ..................35
A.16. Crypto-Agility (R-AGILITY) ...............................35
A.17. Downgrading Protection (R-DOWNGRADE) .....................36
A.18. Media Security Negotiation (R-NEGOTIATE) .................36
A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) ......36
A.20. Media Recording (R-RECORDING) ............................36
A.21. Interworking with Intermediaries (R-TRANSCODER) ..........36
A.22. PSTN Gateway Termination (R-PSTN) ........................36
A.23. R-ALLOW-RTP ..............................................36
A.24. R-HERFP ..................................................37
The Session Initiation Protocol (SIP) [RFC3261] and the Session Description Protocol (SDP) [RFC4566] are used to set up multimedia sessions or calls. SDP is also used to set up TCP [RFC4145] and additionally TCP/TLS connections for usage with media sessions [RFC4572]. The Real-time Transport Protocol (RTP) [RFC3550] is used to transmit real-time media on top of UDP and TCP [RFC4571]. Datagram TLS [RFC4347] was introduced to allow TLS functionality to be applied to datagram transport protocols, such as UDP and DCCP. This document provides guidelines on how to establish SRTP [RFC3711] security over UDP using an extension to DTLS (see [RFC5764]).
会话启动协议（SIP）[RFC3261]和会话描述协议（SDP）[RFC4566]用于建立多媒体会话或呼叫。SDP还用于设置TCP[RFC4145]和其他TCP/TLS连接，以便与媒体会话[RFC4572]一起使用。实时传输协议（RTP）[RFC3550]用于在UDP和TCP[RFC4571]之上传输实时媒体。引入数据报TLS[RFC4347]是为了允许将TLS功能应用于数据报传输协议，如UDP和DCCP。本文档提供了有关如何使用DTLS扩展在UDP上建立SRTP[RFC3711]安全性的指南（请参见[RFC5764]）。
The goal of this work is to provide a key negotiation technique that allows encrypted communication between devices with no prior relationships. It also does not require the devices to trust every call signaling element that was involved in routing or session setup. This approach does not require any extra effort by end users and does not require deployment of certificates that are signed by a well-known certificate authority to all devices.
这项工作的目标是提供一种密钥协商技术，允许设备之间进行加密通信，而无需事先建立关系。它也不要求设备信任路由或会话设置中涉及的每个呼叫信令元素。这种方法不需要最终用户付出任何额外的努力，也不需要将由知名的证书颁发机构签名的证书部署到所有设备。
The media is transported over a mutually authenticated DTLS session where both sides have certificates. It is very important to note that certificates are being used purely as a carrier for the public keys of the peers. This is required because DTLS does not have a mode for carrying bare keys, but it is purely an issue of formatting. The certificates can be self-signed and completely self-generated. All major TLS stacks have the capability to generate such certificates on demand. However, third-party certificates MAY also be used if the peers have them (thus reducing the need to trust intermediaries). The certificate fingerprints are sent in SDP over SIP as part of the offer/answer exchange.
介质通过相互认证的DTLS会话传输，其中双方都有证书。需要注意的是，证书仅用作对等方公钥的载体，这一点非常重要。这是必需的，因为DTL没有携带裸键的模式，但这纯粹是一个格式化问题。证书可以是自签名和完全自生成的。所有主要TLS堆栈都能够根据需要生成此类证书。但是，如果对等方拥有第三方证书，也可以使用第三方证书（从而减少信任中介机构的需要）。证书指纹通过SIP在SDP中发送，作为提供/应答交换的一部分。
The fingerprint mechanism allows one side of the connection to verify that the certificate presented in the DTLS handshake matches the certificate used by the party in the signaling. However, this requires some form of integrity protection on the signaling. S/MIME signatures, as described in RFC 3261, or SIP Identity, as described in [RFC4474], provide the highest level of security because they are not susceptible to modification by malicious intermediaries. However, even hop-by-hop security, such as provided by SIPS, offers some protection against modification by attackers who are not in control of on-path signaling elements. Because DTLS-SRTP only requires message integrity and not confidentiality for the signaling, the number of elements that must have credentials and be trusted is significantly reduced. In particular, if RFC 4474 is used, only the Authentication Service need have a certificate and be trusted. Intermediate elements cannot undetectably modify the message and
指纹机制允许连接的一侧验证DTLS握手中提供的证书是否与信令中一方使用的证书匹配。然而，这需要对信令进行某种形式的完整性保护。RFC 3261中所述的S/MIME签名或[RFC4474]中所述的SIP标识提供了最高级别的安全性，因为它们不易被恶意中介修改。然而，即使是SIPS提供的逐跳安全性，也可以提供一些保护，防止不控制路径上信令元素的攻击者进行修改。由于DTLS-SRTP只要求消息完整性，而不要求信令的机密性，因此必须具有凭据且受信任的元素数量显著减少。特别是，如果使用RFC 4474，则只有身份验证服务需要有证书并受信任。中间元素不能不可检测地修改消息和
therefore cannot mount a man-in-the-middle (MITM) attack. By comparison, because SDESCRIPTIONS [RFC4568] requires confidentiality for the signaling, all intermediate elements must be trusted.
因此不能发动中间人（MITM）攻击。相比之下，由于SDESCRIPTIONS[RFC4568]要求信令保密，因此所有中间元素都必须可信。
This approach differs from previous attempts to secure media traffic where the authentication and key exchange protocol (e.g., Multimedia Internet KEYing (MIKEY) [RFC3830]) is piggybacked in the signaling message exchange. With DTLS-SRTP, establishing the protection of the media traffic between the endpoints is done by the media endpoints with only a cryptographic binding of the media keying to the SIP/SDP communication. It allows RTP and SIP to be used in the usual manner when there is no encrypted media.
这种方法不同于先前的保护媒体流量的尝试，其中认证和密钥交换协议（例如，多媒体互联网密钥（MIKEY）[RFC3830]）是在信令消息交换中承载的。使用DTLS-SRTP，在端点之间建立媒体流量的保护由媒体端点完成，只需将媒体密钥加密绑定到SIP/SDP通信。它允许RTP和SIP在没有加密介质时以通常的方式使用。
In SIP, typically the caller sends an offer and the callee may subsequently send one-way media back to the caller before a SIP answer is received by the caller. The approach in this specification, where the media key negotiation is decoupled from the SIP signaling, allows the early media to be set up before the SIP answer is received while preserving the important security property of allowing the media sender to choose some of the keying material for the media. This also allows the media sessions to be changed, rekeyed, and otherwise modified after the initial SIP signaling without any additional SIP signaling.
在SIP中，通常呼叫者发送要约，并且被呼叫者随后可以在呼叫者接收到SIP应答之前将单向媒体发送回呼叫者。本规范中的方法，其中媒体密钥协商与SIP信令分离，允许在接收SIP应答之前设置早期媒体，同时保留允许媒体发送者为媒体选择一些密钥材料的重要安全属性。这还允许在初始SIP信令之后在没有任何附加SIP信令的情况下更改、重新设置密钥以及以其他方式修改媒体会话。
Design decisions that influence the applicability of this specification are discussed in Section 3.
第3节讨论了影响本规范适用性的设计决策。
Endpoints wishing to set up an RTP media session do so by exchanging offers and answers in SDP messages over SIP. In a typical use case, two endpoints would negotiate to transmit audio data over RTP using the UDP protocol.
希望建立RTP媒体会话的端点通过在SIP上交换SDP消息中的提供和应答来实现。在典型用例中，两个端点将协商使用UDP协议通过RTP传输音频数据。
Figure 1 shows a typical message exchange in the SIP trapezoid.
图1显示了SIP梯形中的典型消息交换。
+-----------+ +-----------+
|SIP | SIP/SDP |SIP |
+------>|Proxy |----------->|Proxy |-------+
| |Server X | (+finger- |Server Y | |
| +-----------+ print, +-----------+ |
| +auth.id.) |
| SIP/SDP SIP/SDP |
| (+fingerprint) (+fingerprint,|
| +auth.id.) |
| |
| v
+-----------+ Datagram TLS +-----------+
|SIP | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP |
|User Agent | Media |User Agent |
|Alice@X | <=================================> |Bob@Y |
+-----------+ +-----------+
+-----------+ +-----------+
|SIP | SIP/SDP |SIP |
+------>|Proxy |----------->|Proxy |-------+
| |Server X | (+finger- |Server Y | |
| +-----------+ print, +-----------+ |
| +auth.id.) |
| SIP/SDP SIP/SDP |
| (+fingerprint) (+fingerprint,|
| +auth.id.) |
| |
| v
+-----------+ Datagram TLS +-----------+
|SIP | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP |
|User Agent | Media |User Agent |
|Alice@X | <=================================> |Bob@Y |
+-----------+ +-----------+
Legend:
------>: Signaling Traffic
<-+-+->: Key Management Traffic
<=====>: Data Traffic
Legend:
------>: Signaling Traffic
<-+-+->: Key Management Traffic
<=====>: Data Traffic
Figure 1: DTLS Usage in the SIP Trapezoid
图1:SIP梯形中DTLS的使用
Consider Alice wanting to set up an encrypted audio session with Bob. Both Bob and Alice could use public-key-based authentication in order to establish a confidentiality protected channel using DTLS.
考虑爱丽丝想要建立一个与鲍伯加密的音频会话。Bob和Alice都可以使用基于公钥的身份验证，以便使用DTL建立受保密保护的通道。
Since providing mutual authentication between two arbitrary endpoints on the Internet using public-key-based cryptography tends to be problematic, we consider more deployment-friendly alternatives. This document uses one approach and several others are discussed in Section 8.
由于使用基于公钥的密码学在互联网上提供两个任意端点之间的相互认证往往是有问题的，所以我们考虑更多的部署友好的替代方案。本文件使用一种方法，第8节讨论了其他几种方法。
Alice sends an SDP offer to Bob over SIP. If Alice uses only self-signed certificates for the communication with Bob, a fingerprint is included in the SDP offer/answer exchange. This fingerprint binds the DTLS key exchange in the media plane to the signaling plane.
Alice通过SIP向Bob发送SDP报价。如果Alice仅使用自签名证书与Bob通信，则SDP提供/应答交换中将包含指纹。此指纹将媒体平面中的DTLS密钥交换绑定到信令平面。
The fingerprint alone protects against active attacks on the media but not active attacks on the signaling. In order to prevent active attacks on the signaling, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474] may be used. When Bob receives the offer, the peers establish some number of DTLS connections (depending on the number of media sessions) with mutual DTLS authentication (i.e., both sides provide certificates). At this point, Bob can verify that Alice's credentials offered in TLS match the fingerprint in the SDP offer, and Bob can begin sending
指纹本身可以防止对媒体的主动攻击，但不能防止对信号的主动攻击。为了防止对信令的主动攻击，可以使用“会话发起协议（SIP）中的认证身份管理增强”[RFC4474]。当Bob收到要约时，对等方通过相互DTLS身份验证（即双方提供证书）建立一定数量的DTLS连接（取决于媒体会话的数量）。此时，Bob可以验证TLS中提供的Alice凭据是否与SDP提供中的指纹匹配，Bob可以开始发送
media to Alice. Once Bob accepts Alice's offer and sends an SDP answer to Alice, Alice can begin sending confidential media to Bob over the appropriate streams. Alice and Bob will verify that the fingerprints from the certificates received over the DTLS handshakes match with the fingerprints received in the SDP of the SIP signaling. This provides the security property that Alice knows that the media traffic is going to Bob and vice versa without necessarily requiring global Public Key Infrastructure (PKI) certificates for Alice and Bob. (See Section 8 for detailed security analysis.)
媒体对爱丽丝说。一旦Bob接受Alice的提议并向Alice发送SDP回复，Alice就可以开始通过适当的流向Bob发送机密媒体。Alice和Bob将验证通过DTLS握手接收到的证书指纹是否与SIP信令的SDP中接收到的指纹匹配。这提供了一个安全属性，Alice知道媒体流量将流向Bob，反之亦然，而不需要Alice和Bob的全局公钥基础设施（PKI）证书。（有关详细的安全性分析，请参见第8节。）
Although there is already prior work in this area (e.g., Security Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] combined with MIKEY [RFC3830] for authentication and key exchange), this specification is motivated as follows:
尽管在这方面已有先例（例如，SDP[RFC4568]的安全说明、密钥管理扩展[RFC4567]与用于身份验证和密钥交换的MIKEY[RFC3830]相结合），但本规范的动机如下：
o TLS will be used to offer security for connection-oriented media. The design of TLS is well-known and implementations are widely available.
o TLS将用于为面向连接的媒体提供安全性。TLS的设计是众所周知的，并且实现是广泛可用的。
o This approach deals with forking and early media without requiring support for Provisional Response ACKnowledgement (PRACK) [RFC3262] while preserving the important security property of allowing the offerer to choose keying material for encrypting the media.
o 这种方法处理分叉和早期媒体，无需支持临时响应确认（PRACK）[RFC3262]，同时保留重要的安全属性，允许报价人选择密钥材料对媒体进行加密。
o The establishment of security protection for the media path is also provided along the media path and not over the signaling path. In many deployment scenarios, the signaling and media traffic travel along a different path through the network.
o 还沿媒体路径而不是通过信令路径提供对媒体路径的安全保护的建立。在许多部署场景中，信令和媒体流量沿着不同的路径通过网络。
o When RFC 4474 is used, this solution works even when the SIP proxies downstream of the authentication service are not trusted. There is no need to reveal keys in the SIP signaling or in the SDP message exchange, as is done in SDESCRIPTIONS [RFC4568]. Retargeting of a dialog-forming request (changing the value of the Request-URI), the User Agent (UA) that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. When RFC 4916 is used, then it is possible to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service.
o 当使用RFC 4474时，即使认证服务下游的SIP代理不受信任，该解决方案也可以工作。没有必要像SDESCRIPTIONS[RFC4568]中所做的那样，在SIP信令或SDP消息交换中显示密钥。对形成对话框的请求进行重定目标（更改请求URI的值），接收该请求的用户代理（UA）（用户代理服务器，UAS）可以具有不同于To标头字段中的标识。当使用RFC 4916时，则可以通过反向请求向对等UA提供其身份，并且该身份将由认证服务签名。
o In this method, synchronization source (SSRC) collisions do not result in any extra SIP signaling.
o 在这种方法中，同步源（SSRC）冲突不会导致任何额外的SIP信令。
o Many SIP endpoints already implement TLS. The changes to existing SIP and RTP usage are minimal even when DTLS-SRTP [RFC5764] is used.
o 许多SIP端点已经实现了TLS。即使使用DTLS-SRTP[RFC5764]，对现有SIP和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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
DTLS/TLS uses the term "session" to refer to a long-lived set of keying material that spans associations. In this document, consistent with SIP/SDP usage, we use it to refer to a multimedia session and use the term "TLS session" to refer to the TLS construct. We use the term "association" to refer to a particular DTLS cipher suite and keying material set that is associated with a single host/ port quartet. The same DTLS/TLS session can be used to establish the keying material for multiple associations. For consistency with other SIP/SDP usage, we use the term "connection" when what's being referred to is a multimedia stream that is not specifically DTLS/TLS.
DTLS/TLS使用术语“会话”来指代跨越关联的一组长寿命的键控材料。在本文档中，与SIP/SDP用法一致，我们使用它来表示多媒体会话，并使用术语“TLS会话”来表示TLS构造。我们使用术语“关联”来指代与单个主机/端口关联的特定DTLS密码套件和键控材料集。同一DTLS/TLS会话可用于建立多个关联的键控材料。为了与其他SIP/SDP用法保持一致，当所指的是非特定DTLS/TLS的多媒体流时，我们使用术语“连接”。
In this document, the term "Mutual DTLS" indicates that both the DTLS client and server present certificates even if one or both certificates are self-signed.
在本文档中，术语“相互DTL”表示DTL客户端和服务器都提供证书，即使其中一个或两个证书都是自签名的。
The two endpoints in the exchange present their identities as part of the DTLS handshake procedure using certificates. This document uses certificates in the same style as described in "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)" [RFC4572].
交换中的两个端点使用证书作为DTLS握手过程的一部分显示其身份。本文档使用与“会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输”中所述相同样式的证书[RFC4572]。
If self-signed certificates are used, the content of the subjectAltName attribute inside the certificate MAY use the uniform resource identifier (URI) of the user. This is useful for debugging purposes only and is not required to bind the certificate to one of the communication endpoints. The integrity of the certificate is ensured through the fingerprint attribute in the SDP. The subjectAltName is not an important component of the certificate verification.
如果使用自签名证书，则证书中subjectAltName属性的内容可能使用用户的统一资源标识符（URI）。这仅用于调试目的，不需要将证书绑定到某个通信端点。通过SDP中的指纹属性确保证书的完整性。subjectAltName不是证书验证的重要组成部分。
The generation of public/private key pairs is relatively expensive. Endpoints are not required to generate certificates for each session.
生成公钥/私钥对的成本相对较高。端点不需要为每个会话生成证书。
The offer/answer model, defined in [RFC3264], is used by protocols like the Session Initiation Protocol (SIP) [RFC3261] to set up multimedia sessions. In addition to the usual contents of an SDP
[RFC3264]中定义的提供/应答模型由会话启动协议（SIP）[RFC3261]等协议用于建立多媒体会话。除了SDP的常规内容之外
[RFC4566] message, each media description ("m=" line and associated parameters) will also contain several attributes as specified in [RFC5764], [RFC4145], and [RFC4572].
[RFC4566]消息，每个媒体描述（“m=”行和相关参数）还将包含[RFC5764]、[RFC4145]和[RFC4572]中指定的几个属性。
When an endpoint wishes to set up a secure media session with another endpoint, it sends an offer in a SIP message to the other endpoint. This offer includes, as part of the SDP payload, the fingerprint of the certificate that the endpoint wants to use. The endpoint SHOULD send the SIP message containing the offer to the offerer's SIP proxy over an integrity protected channel. The proxy SHOULD add an Identity header field according to the procedures outlined in [RFC4474]. The SIP message containing the offer SHOULD be sent to the offerer's SIP proxy over an integrity protected channel. When the far endpoint receives the SIP message, it can verify the identity of the sender using the Identity header field. Since the Identity header field is a digital signature across several SIP header fields, in addition to the body of the SIP message, the receiver can also be certain that the message has not been tampered with after the digital signature was applied and added to the SIP message.
当一个端点希望与另一个端点建立安全的媒体会话时，它会向另一个端点发送SIP消息中的要约。作为SDP有效负载的一部分，此服务包括端点想要使用的证书的指纹。端点应通过完整性保护通道将包含要约的SIP消息发送给要约人的SIP代理。代理应根据[RFC4474]中概述的步骤添加标识标头字段。包含报价的SIP消息应通过完整性保护通道发送给报价人的SIP代理。当远端端点接收到SIP消息时，它可以使用identity header字段验证发送方的身份。由于标识报头字段是跨越多个SIP报头字段的数字签名，因此除了SIP消息的主体之外，接收器还可以确定在应用数字签名并将其添加到SIP消息之后消息没有被篡改。
The far endpoint (answerer) may now establish a DTLS association with the offerer. Alternately, it can indicate in its answer that the offerer is to initiate the TLS association. In either case, mutual DTLS certificate-based authentication will be used. After completing the DTLS handshake, information about the authenticated identities, including the certificates, are made available to the endpoint application. The answerer is then able to verify that the offerer's certificate used for authentication in the DTLS handshake can be associated to the certificate fingerprint contained in the offer in the SDP. At this point, the answerer may indicate to the end user that the media is secured. The offerer may only tentatively accept the answerer's certificate since it may not yet have the answerer's certificate fingerprint.
远端端点（应答者）现在可以与报价人建立DTLS关联。或者，它可以在其回答中指出，要约人将发起TLS关联。在任何一种情况下，都将使用基于DTLS证书的相互身份验证。完成DTLS握手后，端点应用程序可以使用有关经过身份验证的身份（包括证书）的信息。然后，应答者能够验证DTLS握手中用于认证的报价人的证书是否可以与SDP中报价中包含的证书指纹相关联。此时，应答者可向最终用户指示媒体已安全。报价人只能暂时接受应答人的证书，因为它可能还没有应答人的证书指纹。
When the answerer accepts the offer, it provides an answer back to the offerer containing the answerer's certificate fingerprint. At this point, the offerer can accept or reject the peer's certificate and the offerer can indicate to the end user that the media is secured.
当回答者接受报价时，它会向报价者提供一个包含回答者证书指纹的回复。此时，报价人可以接受或拒绝对等方的证书，并且报价人可以向最终用户表明媒体是安全的。
Note that the entire authentication and key exchange for securing the media traffic is handled in the media path through DTLS. The signaling path is only used to verify the peers' certificate fingerprints.
请注意，用于保护媒体流量的整个身份验证和密钥交换是通过DTL在媒体路径中处理的。信令路径仅用于验证对等方的证书指纹。
The offer and answer MUST conform to the following requirements.
报价和答复必须符合以下要求。
o The endpoint MUST use the setup attribute defined in [RFC4145]. The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer. The answerer MUST use either a setup attribute value of setup:active or setup:passive. Note that if the answerer uses setup:passive, then the DTLS handshake will not begin until the answerer is received, which adds additional latency. setup:active allows the answer and the DTLS handshake to occur in parallel. Thus, setup:active is RECOMMENDED. Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet).
o 端点必须使用[RFC4145]中定义的设置属性。作为报价人的端点必须使用setup:actpass的setup属性值，并在收到答复之前准备好接收客户_hello。回答者必须使用设置属性值setup:active或setup:passive。请注意，如果应答者使用setup:passive，则DTLS握手将在收到应答者之前不会开始，这会增加额外的延迟。设置：活动允许应答和DTLS握手并行进行。因此，建议使用setup:active。无论哪一方处于活动状态，都必须通过在每个流（主机/端口四方）上发送ClientHello来启动DTLS握手。
o The endpoint MUST NOT use the connection attribute defined in [RFC4145].
o 端点不得使用[RFC4145]中定义的连接属性。
o The endpoint MUST use the certificate fingerprint attribute as specified in [RFC4572].
o 端点必须使用[RFC4572]中指定的证书指纹属性。
o The certificate presented during the DTLS handshake MUST match the fingerprint exchanged via the signaling path in the SDP. The security properties of this mechanism are described in Section 8.
o DTLS握手期间提供的证书必须与通过SDP中的信令路径交换的指纹匹配。第8节描述了该机制的安全属性。
o If the fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side's fingerprint has been received before establishing the connection; however, this may have undesirable latency effects.
o 如果指纹与哈希证书不匹配，则端点必须立即中断媒体会话。注意，在建立连接之前，允许等待直到接收到另一方的指纹；但是，这可能会产生不良的延迟影响。
The use of DTLS-SRTP does not provide anonymous calling; however, it also does not prevent it. However, if care is not taken when anonymous calling features, such as those described in [RFC3325] or [RFC5767] are used, DTLS-SRTP may allow deanonymizing an otherwise anonymous call. When anonymous calls are being made, the following procedures SHOULD be used to prevent deanonymization.
DTLS-SRTP的使用不提供匿名呼叫；然而，它也不能阻止它。然而，如果在使用匿名呼叫功能（如[RFC3325]或[RFC5767]中所述）时不小心，DTLS-SRTP可能允许对其他匿名呼叫进行非对称化。进行匿名呼叫时，应使用以下过程来防止非对称。
When making anonymous calls, a new self-signed certificate SHOULD be used for each call so that the calls cannot be correlated as to being from the same caller. In situations where some degree of correlation is acceptable, the same certificate SHOULD be used for a number of calls in order to enable continuity of authentication; see Section 8.4.
进行匿名呼叫时，应为每个呼叫使用新的自签名证书，以便这些呼叫不能关联为来自同一呼叫方。在某种程度的相关性可以接受的情况下，同一证书应用于多个呼叫，以实现身份验证的连续性；见第8.4节。
Additionally, note that in networks that deploy [RFC3325], RFC 3325 requires that the Privacy header field value defined in [RFC3323] needs to be set to 'id'. This is used in conjunction with the SIP identity mechanism to ensure that the identity of the user is not asserted when enabling anonymous calls. Furthermore, the content of the subjectAltName attribute inside the certificate MUST NOT contain information that either allows correlation or identification of the user that wishes to place an anonymous call. Note that following this recommendation is not sufficient to provide anonymization.
此外，请注意，在部署[RFC3325]的网络中，RFC 3325要求将[RFC3323]中定义的隐私标头字段值设置为“id”。这与SIP标识机制结合使用，以确保在启用匿名呼叫时不会断言用户的标识。此外，证书中subjectAltName属性的内容不得包含允许关联或标识希望进行匿名呼叫的用户的信息。请注意，遵循此建议不足以提供匿名化。
If an offer is received by an endpoint that wishes to provide early media, it MUST take the setup:active role and can immediately establish a DTLS association with the other endpoint and begin sending media. The setup:passive endpoint may not yet have validated the fingerprint of the active endpoint's certificate. The security aspects of media handling in this situation are discussed in Section 8.
如果希望提供早期介质的端点接收到要约，则该端点必须担任setup:active角色，并且可以立即与另一个端点建立DTLS关联并开始发送介质。setup:被动终结点可能尚未验证主动终结点证书的指纹。第8节讨论了这种情况下媒体处理的安全方面。
In SIP, it is possible for a request to fork to multiple endpoints. Each forked request can result in a different answer. Assuming that the requester provided an offer, each of the answerers will provide a unique answer. Each answerer will form a DTLS association with the offerer. The offerer can then securely correlate the SDP answer received in the SIP message by comparing the fingerprint in the answer to the hashed certificate for each DTLS association.
在SIP中，一个请求可以分叉到多个端点。每个分叉请求都可能导致不同的答案。假设请求者提供了报价，每个回答者都将提供唯一的答案。每位答疑人将与报价人组成DTLS协会。然后，通过将应答中的指纹与每个DTLS关联的哈希证书进行比较，报价人可以安全地关联SIP消息中接收到的SDP应答。
An endpoint may send a SIP INVITE request with no offer in it. When this occurs, the receiver(s) of the INVITE will provide the offer in the response and the originator will provide the answer in the subsequent ACK request or in the PRACK request [RFC3262], if both endpoints support reliable provisional responses. In any event, the active endpoint still establishes the DTLS association with the passive endpoint as negotiated in the offer/answer exchange.
端点可以发送SIP INVITE请求，但其中没有提供。发生这种情况时，如果两个端点都支持可靠的临时响应，则INVITE的接收者将在响应中提供要约，而发起者将在后续ACK请求或PRACK请求[RFC3262]中提供答复。在任何情况下，主动端点仍然与在提供/应答交换中协商的被动端点建立DTLS关联。
When there are multiple flows (e.g., multiple media streams, non-multiplexed RTP and RTCP, etc.) the active side MAY perform the DTLS handshakes in any order. Appendix B of [RFC5764] provides some guidance on the performance of parallel DTLS handshakes. Note that if the answerer ends up being active, it may only initiate handshakes on some subset of the potential streams (e.g., if audio and video are
当存在多个流（例如，多个媒体流、非多路复用RTP和RTCP等）时，活动侧可以以任何顺序执行DTLS握手。[RFC5764]的附录B提供了一些关于并行DTLS握手性能的指导。请注意，如果应答者最终处于活动状态，则它可能仅在潜在流的某些子集上发起握手（例如，如果音频和视频被激活）
offered but it only wishes to do audio). If the offerer ends up being active, the complete answer will be received before the offerer begins initiating handshakes.
提供，但它只希望做音频）。如果发盘人最终处于活跃状态，那么在发盘人开始握手之前，将收到完整的答案。
Once an answer is provided to the offerer, either endpoint MAY request a session modification that MAY include an updated offer. This session modification can be carried in either an INVITE or UPDATE request. The peers can reuse the existing associations if they are compatible (i.e., they have the same key fingerprints and transport parameters), or establish a new one following the same rules are for initial exchanges, tearing down the existing association as soon as the offer/answer exchange is completed. Note that if the active/passive status of the endpoints changes, a new connection MUST be established.
一旦向报价人提供了答案，任一端点都可以请求会话修改，该会话修改可以包括更新的报价。此会话修改可以在邀请或更新请求中进行。对等方可以重用兼容的现有关联（即，它们具有相同的密钥指纹和传输参数），或者按照初始交换的相同规则建立新关联，在提供/应答交换完成后立即拆除现有关联。请注意，如果端点的主动/被动状态发生更改，则必须建立新连接。
There are a number of potentially bad interactions between DTLS-SRTP and middleboxes, as documented in [MMUSIC-MEDIA], which also provides recommendations for avoiding such problems.
如[MMUSIC-MEDIA]中所述，DTLS-SRTP和中间盒之间存在许多潜在的不良交互，这也为避免此类问题提供了建议。
Interactive Connectivity Establishment (ICE), as specified in [RFC5245], provides a methodology of allowing participants in multimedia sessions to verify mutual connectivity. When ICE is being used, the ICE connectivity checks are performed before the DTLS handshake begins. Note that if aggressive nomination mode is used, multiple candidate pairs may be marked valid before ICE finally converges on a single candidate pair. Implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. Thus, there will be only one DTLS handshake even if there are multiple valid candidate pairs. Note that this may mean adjusting the endpoint IP addresses if the selected candidate pair shifts, just as if the DTLS packets were an ordinary media stream.
[RFC5245]中规定的交互式连接建立（ICE）提供了一种允许多媒体会话参与者验证相互连接的方法。当使用ICE时，ICE连接检查在DTLS握手开始之前执行。注意，如果使用积极提名模式，在ICE最终收敛到单个候选对之前，多个候选对可能被标记为有效。实现必须将与单个组件关联的所有ICE候选对视为同一DTLS关联的一部分。因此，即使存在多个有效候选对，也只有一个DTLS握手。注意，这可能意味着如果所选候选对移位，则调整端点IP地址，就像DTLS分组是普通媒体流一样。
Note that Simple Traversal of the UDP Protocol through NAT (STUN) packets are sent directly over UDP, not over DTLS. [RFC5764] describes how to demultiplex STUN packets from DTLS packets and SRTP packets.
请注意，通过NAT（STUN）数据包对UDP协议进行的简单遍历直接通过UDP发送，而不是通过DTL发送。[RFC5764]描述了如何从DTLS数据包和SRTP数据包中解复用STUN数据包。
If ICE is not being used, then there is potential for a bad interaction with Session Border Controllers (SBCs) via "latching", as described in [MMUSIC-MEDIA]. In order to avoid this issue, if ICE is not being used and the DTLS handshake has not completed upon receiving the other side's SDP, then the passive side MUST do a single unauthenticated STUN [RFC5389] connectivity check in order to open up the appropriate pinhole. All implementations MUST be prepared to answer this request during the handshake period even if they do not otherwise do ICE. However, the active side MUST proceed with the DTLS handshake as appropriate even if no such STUN check is received and the passive MUST NOT wait for a STUN answer before sending its ServerHello.
如果未使用ICE，则可能会通过“锁存”与会话边界控制器（SBC）发生不良交互，如[MMUSIC-MEDIA]中所述。为了避免此问题，如果未使用ICE且在接收到另一方的SDP时DTLS握手尚未完成，则被动方必须进行一次未经验证的STUN[RFC5389]连接检查，以打开相应的针孔。所有实现都必须准备好在握手期间响应此请求，即使它们不这样做。但是，即使未收到此类眩晕检查，主动方也必须酌情进行DTLS握手，被动方在发送其ServerHello之前不得等待眩晕应答。
As with TLS, DTLS endpoints can rekey at any time by redoing the DTLS handshake. While the rekey is under way, the endpoints continue to use the previously established keying material for usage with DTLS. Once the new session keys are established, the session can switch to using these and abandon the old keys. This ensures that latency is not introduced during the rekeying process.
与TLS一样，DTLS端点可以通过重做DTLS握手随时重新设置密钥。在重新设置密钥的过程中，端点将继续使用先前建立的密钥材料与DTL一起使用。一旦建立了新的会话密钥，会话就可以切换到使用这些密钥并放弃旧密钥。这确保了在重新设置密钥的过程中不会引入延迟。
Further considerations regarding rekeying in case the SRTP security context is established with DTLS can be found in Section 3.7 of [RFC5764].
[RFC5764]第3.7节中有关于在使用DTL建立SRTP安全上下文的情况下重新设置密钥的进一步考虑。
It has been proposed that conference servers might use the same encryption context for all of the participants in a conference. The advantage of this approach is that the conference server only needs to encrypt the output for all speakers instead of once per participant.
有人提议，会议服务器可以为会议的所有参与者使用相同的加密上下文。这种方法的优点是会议服务器只需要加密所有发言者的输出，而不是每个参与者一次。
This shared encryption context approach is not possible under this specification because each DTLS handshake establishes fresh keys that are not completely under the control of either side. However, it is argued that the effort to encrypt each RTP packet is small compared to the other tasks performed by the conference server such as the codec processing.
在本规范下，这种共享加密上下文方法是不可能的，因为每次DTLS握手都会建立新的密钥，而这些密钥并不完全受任何一方的控制。然而，有人认为，与会议服务器执行的其他任务（如编解码器处理）相比，加密每个RTP数据包的工作量较小。
Future extensions, such as [SRTP-EKT] or [KEY-TRANSPORT], could be used to provide this functionality in concert with the mechanisms described in this specification.
将来的扩展，如[SRTP-EKT]或[KEY-TRANSPORT]，可用于提供与本规范中描述的机制一致的功能。
Because DTLS's data transfer protocol is generic, it is less highly optimized for use with RTP than is SRTP [RFC3711], which has been specifically tuned for that purpose. DTLS-SRTP [RFC5764] has been defined to provide for the negotiation of SRTP transport using a DTLS connection, thus allowing the performance benefits of SRTP with the easy key management of DTLS. The ability to reuse existing SRTP software and hardware implementations may in some environments provide another important motivation for using DTLS-SRTP instead of RTP over DTLS. Implementations of this specification MUST support DTLS-SRTP [RFC5764].
由于DTLS的数据传输协议是通用的，因此与SRTP[RFC3711]相比，它在与RTP一起使用时的优化程度较低，SRTP[RFC3711]专门为此进行了调整。DTLS-SRTP[RFC5764]已定义为使用DTLS连接协商SRTP传输，从而通过DTLS的轻松密钥管理实现SRTP的性能优势。在某些环境中，重用现有SRTP软件和硬件实现的能力可能为使用DTLS-SRTP而不是DTLS上的RTP提供了另一个重要动机。本规范的实现必须支持DTLS-SRTP[RFC5764]。
[RFC5479] describes a requirement for best-effort encryption where SRTP is used and where both endpoints support it and key negotiation succeeds, otherwise RTP is used.
[RFC5479]描述了在使用SRTP以及两个端点都支持SRTP且密钥协商成功的情况下，对尽力而为加密的要求，否则使用RTP。
[MMUSIC-SDP] describes a mechanism that can signal both RTP and SRTP as an alternative. This allows an offerer to express a preference for SRTP, but RTP is the default and will be understood by endpoints that do not understand SRTP or this key exchange mechanism. Implementations of this document MUST support [MMUSIC-SDP].
[MMUSIC-SDP]描述了一种可以将RTP和SRTP作为替代信号发送的机制。这允许报价人表示对SRTP的偏好，但RTP是默认值，不了解SRTP或该密钥交换机制的端点将理解RTP。本文档的实现必须支持[MMUSIC-SDP]。
Prior to establishing the session, both Alice and Bob generate self-signed certificates that are used for a single session or, more likely, reused for multiple sessions. In this example, Alice calls Bob. In this example, we assume that Alice and Bob share the same proxy.
在建立会话之前，Alice和Bob都会生成自签名证书，这些证书用于单个会话，或者更可能用于多个会话。在本例中，Alice调用Bob。在本例中，我们假设Alice和Bob共享同一个代理。
This example shows the SIP message flows where Alice acts as the passive endpoint and Bob acts as the active endpoint; meaning that as soon as Bob receives the INVITE from Alice, with DTLS specified in the "m=" line of the offer, Bob will begin to negotiate a DTLS association with Alice for both RTP and RTCP streams. Early media (RTP and RTCP) starts to flow from Bob to Alice as soon as Bob sends the DTLS finished message to Alice. Bi-directional media (RTP and RTCP) can flow after Alice receives the SIP 200 response and once Alice has sent the DTLS finished message.
此示例显示了SIP消息流，其中Alice充当被动端点，Bob充当主动端点；这意味着，一旦Bob收到Alice的邀请，并在要约的“m=”行中指定DTL，Bob将开始与Alice协商RTP和RTCP流的DTL关联。一旦Bob向Alice发送DTLS完成消息，早期媒体（RTP和RTCP）就开始从Bob流向Alice。在Alice接收到SIP 200响应后以及Alice发送DTLS完成消息后，双向媒体（RTP和RTCP）可以流动。
The SIP signaling from Alice to her proxy is transported over TLS to ensure an integrity protected channel between Alice and her identity service. Transport between proxies should also be protected somehow, especially if SIP Identity is not in use.
从Alice到她的代理的SIP信令通过TLS传输，以确保Alice和她的身份服务之间的完整性保护通道。代理之间的传输也应该受到某种保护，特别是在没有使用SIP标识的情况下。
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
|<-----------------------------------|
|(4) hello | |
|----------------------------------->|
| |(5) finished |
|<-----------------------------------|
| |(6) media |
|<-----------------------------------|
|(7) finished | |
|----------------------------------->|
| |(8) 200 OK |
| <------------------|
|(9) 200 OK | |
|<----------------| |
| |(10) media |
|<---------------------------------->|
|(11) ACK | |
|----------------------------------->|
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
|<-----------------------------------|
|(4) hello | |
|----------------------------------->|
| |(5) finished |
|<-----------------------------------|
| |(6) media |
|<-----------------------------------|
|(7) finished | |
|----------------------------------->|
| |(8) 200 OK |
| <------------------|
|(9) 200 OK | |
|<----------------| |
| |(10) media |
|<---------------------------------->|
|(11) ACK | |
|----------------------------------->|
Message (1): INVITE Alice -> Proxy
Message (1): INVITE Alice -> Proxy
This shows the initial INVITE from Alice to Bob carried over the TLS transport protocol to ensure an integrity protected channel between Alice and her proxy that acts as Alice's identity service. Alice has requested to be either the active or passive endpoint by specifying a=setup:actpass in the SDP. Bob chooses to act as the DTLS client and will initiate the session. Also note that there is a fingerprint attribute in the SDP. This is computed from Alice's self-signed certificate.
这显示了通过TLS传输协议从Alice到Bob的初始邀请，以确保Alice与其代理（充当Alice的身份服务）之间的完整性保护通道。Alice通过在SDP中指定a=setup:actpass请求成为主动或被动端点。Bob选择充当DTLS客户端，并将启动会话。还要注意，SDP中有一个指纹属性。这是根据Alice的自签名证书计算的。
This offer includes a default "m=" line offering RTP in case the answerer does not support SRTP. However, the potential configuration utilizing a transport of SRTP is preferred. See [MMUSIC-SDP] for more details on the details of SDP capability negotiation.
如果应答者不支持SRTP，此报价包括默认的“m=”行报价RTP。然而，优选利用SRTP的传输的潜在配置。有关SDP能力协商的详细信息，请参见[MMUSIC-SDP]。
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: "Alice"<sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Contact: <sip:alice@ua1.example.com>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: "Alice"<sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Contact: <sip:alice@ua1.example.com>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1
c=IN IP4 ua1.example.com
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 6056 RTP/AVP 0
a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1
c=IN IP4 ua1.example.com
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 6056 RTP/AVP 0
a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1
Message (2): INVITE Proxy -> Bob
Message (2): INVITE Proxy -> Bob
This shows the INVITE being relayed to Bob from Alice (and Bob's) proxy. Note that Alice's proxy has inserted an Identity and Identity-Info header. This example only shows one element for both proxies for the purposes of simplification. Bob verifies the identity provided with the INVITE.
这显示了从Alice（和Bob的）代理转发给Bob的邀请。请注意，Alice的代理已插入标识和标识信息头。为了简化起见，此示例仅显示两个代理的一个元素。Bob验证随邀请提供的标识。
INVITE sip:bob@ua2.example.com SIP/2.0
To: <sip:bob@example.com>
From: "Alice"<sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Record-Route: <sip:proxy.example.com;lr>
Contact: <sip:alice@ua1.example.com>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Max-Forwards: 69
Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k
3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC
HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI=
Identity-Info: https://example.com/cert
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
INVITE sip:bob@ua2.example.com SIP/2.0
To: <sip:bob@example.com>
From: "Alice"<sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Record-Route: <sip:proxy.example.com;lr>
Contact: <sip:alice@ua1.example.com>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Max-Forwards: 69
Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k
3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC
HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI=
Identity-Info: https://example.com/cert
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1
c=IN IP4 ua1.example.com
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 6056 RTP/AVP 0
a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1
c=IN IP4 ua1.example.com
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 6056 RTP/AVP 0
a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1
Message (3): ClientHello Bob -> Alice
Message (3): ClientHello Bob -> Alice
Assuming that Alice's identity is valid, Line 3 shows Bob sending a DTLS ClientHello(s) directly to Alice. In this case, two DTLS ClientHello messages would be sent to Alice: one to ua1.example.com:6056 for RTP and another to port 6057 for RTCP, but only one arrow is drawn for compactness of the figure.
假设Alice的身份有效，第3行显示Bob直接向Alice发送DTLS ClientHello。在这种情况下，将向Alice发送两条DTLS ClientHello消息：一条发送到ua1.example.com:6056用于RTP，另一条发送到端口6057用于RTCP，但为了图形的紧凑性，只绘制了一个箭头。
Message (4): ServerHello+Certificate Alice -> Bob
Message (4): ServerHello+Certificate Alice -> Bob
Alice sends back a ServerHello, Certificate, and ServerHelloDone for both RTP and RTCP associations. Note that the same certificate is used for both the RTP and RTCP associations. If RTP/RTCP multiplexing [RFC5761] were being used only a single association would be required.
Alice为RTP和RTCP关联发回ServerHello、证书和ServerHelloOne。请注意，RTP和RTCP关联都使用相同的证书。如果使用RTP/RTCP多路复用[RFC5761]，则只需要一个关联。
Message (5): Certificate Bob -> Alice
Message (5): Certificate Bob -> Alice
Bob sends a Certificate, ClientKeyExchange, CertificateVerify, change_cipher_spec, and Finished for both RTP and RTCP associations. Again note that Bob uses the same server certificate for both associations.
Bob为RTP和RTCP关联发送证书、ClientKeyExchange、CertificateVerify、change\u cipher\u spec，并完成。再次注意，Bob对这两个关联使用相同的服务器证书。
Message (6): Early Media Bob -> Alice
Message (6): Early Media Bob -> Alice
At this point, Bob can begin sending early media (RTP and RTCP) to Alice. Note that Alice can't yet trust the media since the fingerprint has not yet been received. This lack of trusted, secure media is indicated to Alice via the UA user interface.
此时，Bob可以开始向Alice发送早期媒体（RTP和RTCP）。请注意，Alice还不能信任媒体，因为尚未收到指纹。通过UA用户界面向Alice指出缺乏可信、安全的媒体。
Message (7): Finished Alice -> Bob
Message (7): Finished Alice -> Bob
After Message 7 is received by Bob, Alice sends change_cipher_spec and Finished.
Bob收到消息7后，Alice发送change\u cipher\u spec并完成。
Message (8): 200 OK Bob -> Alice
Message (8): 200 OK Bob -> Alice
When Bob answers the call, Bob sends a 200 OK SIP message that contains the fingerprint for Bob's certificate. Bob signals the actual transport protocol configuration of SRTP over DTLS in the acfg parameter.
当Bob接听电话时，Bob发送一条200 OK SIP消息，其中包含Bob证书的指纹。Bob在acfg参数中通过DTLS发送SRTP的实际传输协议配置信号。
SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=6418913922105372816
From: "Alice" <sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Record-Route: <sip:proxy.example.com;lr>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=6418913922105372816
From: "Alice" <sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Record-Route: <sip:proxy.example.com;lr>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com
s=example2
c=IN IP4 ua2.example.com
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1
v=0
o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com
s=example2
c=IN IP4 ua2.example.com
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1
Message (9): 200 OK Proxy -> Alice
Message (9): 200 OK Proxy -> Alice
Alice receives the message from her proxy and validates the certificate presented in Message 7. The endpoint now shows Alice that the call as secured.
Alice从她的代理接收消息并验证消息7中提供的证书。端点现在向Alice显示调用是安全的。
Message (10): RTP+RTCP Alice -> Bob
Message (10): RTP+RTCP Alice -> Bob
At this point, Alice can also start sending RTP and RTCP to Bob.
此时，Alice还可以开始向Bob发送RTP和RTCP。
Message (11): ACK Alice -> Bob
Message (11): ACK Alice -> Bob
Finally, Alice sends the SIP ACK to Bob.
最后，Alice将SIP ACK发送给Bob。
The previous example did not show the use of RFC 4916 for connected identity. The following example does:
前面的示例没有显示对已连接标识使用RFC 4916。以下示例不适用于：
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
|<-----------------------------------|
|(4) hello | |
|----------------------------------->|
| |(5) finished |
|<-----------------------------------|
| |(6) media |
|<-----------------------------------|
|(7) finished | |
|----------------------------------->|
| |(8) 200 OK |
|<-----------------------------------|
|(9) ACK | |
|----------------------------------->|
| |(10) UPDATE |
| |<-----------------|
|(11) UPDATE | |
|<----------------| |
|(12) 200 OK | |
|---------------->| |
| |(13) 200 OK |
| |----------------->|
| |(14) media |
|<---------------------------------->|
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
|<-----------------------------------|
|(4) hello | |
|----------------------------------->|
| |(5) finished |
|<-----------------------------------|
| |(6) media |
|<-----------------------------------|
|(7) finished | |
|----------------------------------->|
| |(8) 200 OK |
|<-----------------------------------|
|(9) ACK | |
|----------------------------------->|
| |(10) UPDATE |
| |<-----------------|
|(11) UPDATE | |
|<----------------| |
|(12) 200 OK | |
|---------------->| |
| |(13) 200 OK |
| |----------------->|
| |(14) media |
|<---------------------------------->|
The first 9 messages of this example are the same as before. However, Messages 10-13, performing the RFC 4916 UPDATE, are new.
本例的前9条消息与前面相同。但是，执行RFC 4916更新的消息10-13是新的。
Message (10): UPDATE Bob -> Proxy
Message (10): UPDATE Bob -> Proxy
Bob sends an RFC 4916 UPDATE towards Alice. This update contains his fingerprint. Bob's UPDATE contains the same session information that he provided in his 200 OK (Message 8). Note that in principle an UPDATE here can be used to modify session parameters. However, in this case it's being used solely to confirm the fingerprint.
Bob向Alice发送RFC4916更新。此更新包含他的指纹。Bob的更新包含他在200OK中提供的相同会话信息（消息8）。请注意，原则上，此处的更新可用于修改会话参数。然而，在本例中，它仅用于确认指纹。
UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816
Route: <sip:proxy.example.com;lr>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE
Contact: <sip:ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
Max-Forwards: 70
UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816
Route: <sip:proxy.example.com;lr>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE
Contact: <sip:ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
Max-Forwards: 70
v=0
o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com
s=example2
c=IN IP4 ua2.example.com
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1
v=0
o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com
s=example2
c=IN IP4 ua2.example.com
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1
Message (11): UPDATE Proxy -> Alice
Message (11): UPDATE Proxy -> Alice
This shows the UPDATE being relayed to Alice from Bob (and Alice's proxy). Note that Bob's proxy has inserted an Identity and Identity-Info header. As above, we only show one element for both proxies for purposes of simplification. Alice verifies the identity provided. (Note: the actual identity signatures here are incorrect and provided merely as examples.)
这显示了从Bob（和Alice的代理）中继到Alice的更新。请注意，Bob的代理已插入标识和标识信息头。如上所述，为了简化，我们只为两个代理显示一个元素。Alice验证提供的身份。（注意：此处的实际身份签名不正确，仅作为示例提供。）
UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
Max-Forwards: 69
Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k
3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC
HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI=
Identity-Info: https://example.com/cert
UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
Max-Forwards: 69
Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k
3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC
HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI=
Identity-Info: https://example.com/cert
v=0
o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com
s=example2
c=IN IP4 ua2.example.com
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1
v=0
o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com
s=example2
c=IN IP4 ua2.example.com
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1
Message (12): 200 OK Alice -> Bob
Message (12): 200 OK Alice -> Bob
This shows Alice's 200 OK response to Bob's UPDATE. Because Bob has merely sent the same session parameters he sent in his 200 OK, Alice can simply replay her view of the session parameters as well.
这显示了Alice对Bob更新的200 OK响应。因为Bob只发送了与他在200OK中发送的相同的会话参数，Alice也可以简单地重播她对会话参数的看法。
SIP/2.0 200 OK
To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
SIP/2.0 200 OK
To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 1181923068 1181923196 IN IP4 ua2.example.com
s=example1
c=IN IP4 ua2.example.com
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 6056 RTP/AVP 0
a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1
v=0
o=- 1181923068 1181923196 IN IP4 ua2.example.com
s=example1
c=IN IP4 ua2.example.com
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 6056 RTP/AVP 0
a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1
In the previous examples, the DTLS handshake has already completed by the time Alice receives Bob's 200 OK (8). Therefore, no STUN check is sent. However, if Alice had a NAT, then Bob's ClientHello might get blocked by that NAT, in which case Alice would send the STUN check described in Section 6.7.1 upon receiving the 200 OK, as shown below:
在前面的示例中，当Alice收到Bob的200OK（8）时，DTLS握手已经完成。因此，不会发送眩晕检查。但是，如果Alice有一个NAT，那么Bob的ClientHello可能会被该NAT阻止，在这种情况下，Alice会在收到200 OK后发送第6.7.1节所述的晕眩检查，如下所示：
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
| X<-----------------|
| |(4) 200 OK |
|<-----------------------------------|
| (5) conn-check | |
|----------------------------------->|
| |(6) conn-response |
|<-----------------------------------|
| |(7) hello (rtx) |
|<-----------------------------------|
|(8) hello | |
|----------------------------------->|
| |(9) finished |
|<-----------------------------------|
| |(10) media |
|<-----------------------------------|
|(11) finished | |
|----------------------------------->|
| |(11) media |
|----------------------------------->|
|(12) ACK | |
|----------------------------------->|
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
| X<-----------------|
| |(4) 200 OK |
|<-----------------------------------|
| (5) conn-check | |
|----------------------------------->|
| |(6) conn-response |
|<-----------------------------------|
| |(7) hello (rtx) |
|<-----------------------------------|
|(8) hello | |
|----------------------------------->|
| |(9) finished |
|<-----------------------------------|
| |(10) media |
|<-----------------------------------|
|(11) finished | |
|----------------------------------->|
| |(11) media |
|----------------------------------->|
|(12) ACK | |
|----------------------------------->|
The messages here are the same as in the first example (for simplicity this example omits an UPDATE), with the following three new messages:
此处的消息与第一个示例中的消息相同（为简单起见，本示例省略了更新），其中包含以下三条新消息：
Message (5): STUN connectivity-check Alice -> Bob
Message (5): STUN connectivity-check Alice -> Bob
Section 6.7.1 describes an approach to avoid an SBC interaction issue where the endpoints do not support ICE. Alice (the passive endpoint) sends a STUN connectivity check to Bob. This opens a pinhole in Alice's NAT/firewall.
第6.7.1节描述了一种避免SBC交互问题的方法，其中端点不支持ICE。Alice（被动端点）向Bob发送昏迷连接检查。这会在Alice的NAT/防火墙上打开一个针孔。
Message (6): STUN connectivity-check response Bob -> Alice
Message (6): STUN connectivity-check response Bob -> Alice
Bob (the active endpoint) sends a response to the STUN connectivity check (Message 3) to Alice. This tells Alice that her connectivity check has succeeded and she can stop the retransmit state machine.
Bob（活动端点）向Alice发送对STUN连接检查（消息3）的响应。这告诉Alice，她的连接检查已成功，她可以停止重新传输状态机。
Message (7): Hello (retransmit) Bob -> Alice
Message (7): Hello (retransmit) Bob -> Alice
Bob retransmits his DTLS ClientHello, which now passes through the pinhole created in Alice's firewall. At this point, the DTLS handshake proceeds as before.
Bob重新传输他的DTLS ClientHello，它现在通过Alice防火墙上的针孔。此时，DTLS握手与之前一样进行。
DTLS or TLS media signaled with SIP requires a way to ensure that the communicating peers' certificates are correct.
用SIP发出信号的DTL或TLS媒体需要一种方法来确保通信对等方的证书是正确的。
The standard TLS/DTLS strategy for authenticating the communicating parties is to give the server (and optionally the client) a PKIX [RFC5280] certificate. The client then verifies the certificate and checks that the name in the certificate matches the server's domain name. This works because there are a relatively small number of servers with well-defined names; a situation that does not usually occur in the VoIP context.
认证通信方的标准TLS/DTLS策略是向服务器（以及可选的客户端）提供PKIX[RFC5280]证书。然后，客户端验证证书并检查证书中的名称是否与服务器的域名匹配。这是因为具有定义良好名称的服务器数量相对较少；在VoIP上下文中通常不会发生的情况。
The design described in this document is intended to leverage the authenticity of the signaling channel (while not requiring confidentiality). As long as each side of the connection can verify the integrity of the SDP received from the other side, then the DTLS handshake cannot be hijacked via a man-in-the-middle attack. This integrity protection is easily provided by the caller to the callee (see Alice to Bob in Section 7) via the SIP Identity [RFC4474] mechanism. Other mechanisms, such as the S/MIME mechanism described in RFC 3261, or perhaps future mechanisms yet to be defined could also serve this purpose.
本文档中描述的设计旨在利用信令信道的真实性（同时不要求保密）。只要连接的每一方都能验证从另一方收到的SDP的完整性，那么DTLS握手就不能通过中间人攻击被劫持。这种完整性保护很容易由调用方通过SIP标识[RFC4474]机制提供给被调用方（参见第7节中的Alice to Bob）。其他机制，例如RFC3261中描述的S/MIME机制，或者可能还有待定义的未来机制也可以用于此目的。
While this mechanism can still be used without such integrity mechanisms, the security provided is limited to defense against passive attack by intermediaries. An active attack on the signaling plus an active attack on the media plane can allow an attacker to attack the connection (R-SIG-MEDIA in the notation of [RFC5479]).
虽然此机制在没有此类完整性机制的情况下仍然可以使用，但提供的安全性仅限于防御中介的被动攻击。对信令的主动攻击加上对媒体平面的主动攻击可允许攻击者攻击连接（符号为[RFC5479]的R-SIG-media）。
SIP Identity does not support signatures in responses. Ideally, Alice would want to know that Bob's SDP had not been tampered with and who it was from so that Alice's User Agent could indicate to Alice that there was a secure phone call to Bob. [RFC4916] defines an approach for a UA to supply its identity to its peer UA, and for this identity to be signed by an authentication service. For example, using this approach, Bob sends an answer, then immediately follows up with an UPDATE that includes the fingerprint and uses the SIP Identity mechanism to assert that the message is from Bob@example.com. The downside of this approach is that it requires
SIP标识不支持响应中的签名。理想情况下，Alice希望知道Bob的SDP没有被篡改，以及它来自谁，以便Alice的用户代理可以向Alice指示Bob有一个安全电话。[RFC4916]定义了一种方法，用于UA向其对等UA提供其身份，并由身份验证服务对该身份进行签名。例如，使用这种方法，Bob发送一个答案，然后立即进行包含指纹的更新，并使用SIP标识机制断言消息来自Bob@example.com. 这种方法的缺点是需要
the extra round trip of the UPDATE. However, it is simple and secure even when not all of the proxies are trusted. In this example, Bob only needs to trust his proxy. Offerers SHOULD support this mechanism and answerers SHOULD use it.
更新的额外往返。然而，即使不是所有的代理都是可信的，它也是简单和安全的。在本例中，Bob只需要信任他的代理。报价人应支持该机制，应答人应使用该机制。
In some cases, answerers will not send an UPDATE and in many calls, some media will be sent before the UPDATE is received. In these cases, no integrity is provided for the fingerprint from Bob to Alice. In this approach, an attacker that was on the signaling path could tamper with the fingerprint and insert themselves as a man-in-the-middle on the media. Alice would know that she had a secure call with someone, but would not know if it was with Bob or a man-in-the-middle. Bob would know that an attack was happening. The fact that one side can detect this attack means that in most cases where Alice and Bob both wish for the communications to be encrypted, there is not a problem. Keep in mind that in any of the possible approaches, Bob could always reveal the media that was received to anyone. We are making the assumption that Bob also wants secure communications. In this do nothing case, Bob knows the media has not been tampered with or intercepted by a third party and that it is from Alice@example.com. Alice knows that she is talking to someone and that whoever that is has probably checked that the media is not being intercepted or tampered with. This approach is certainly less than ideal but very usable for many situations.
在某些情况下，应答者不会发送更新，在许多电话中，在收到更新之前会发送一些媒体。在这些情况下，从Bob到Alice的指纹没有完整性。在这种方法中，位于信令路径上的攻击者可以篡改指纹，并将自己作为中间人插入媒体。爱丽丝会知道她和某人有一个安全的电话，但不知道是和鲍勃还是中间的一个男人。鲍勃会知道正在发生袭击。事实上，一方可以检测到这种攻击，这意味着在大多数情况下，如果Alice和Bob都希望对通信进行加密，则不存在问题。请记住，在任何可能的方法中，Bob都可以向任何人透露收到的媒体。我们假设Bob也需要安全通信。在这种不做任何事情的情况下，Bob知道媒体没有被第三方篡改或截获，并且它来自Alice@example.com. 爱丽丝知道她正在和某人谈话，不管是谁，都可能检查过媒体没有被截获或篡改。这种方法当然不太理想，但在许多情况下非常有用。
If SIP Identity is not used, but the signaling is protected by SIPS, the security guarantees are weaker. Some security is still provided as long as all proxies are trusted. This provides integrity for the fingerprint in a chain-of-trust security model. Note, however, that if the proxies are not trusted, then the level of security provided is limited.
如果未使用SIP标识，但信令受SIPS保护，则安全保障较弱。只要所有代理都是可信的，就仍然提供一些安全性。这为信任链安全模型中的指纹提供了完整性。但是，请注意，如果代理不受信任，则提供的安全级别是有限的。
RFC 3261 [RFC3261] defines an S/MIME security mechanism for SIP that could be used to sign that the fingerprint was from Bob. This would be secure.
RFC 3261[RFC3261]为SIP定义了一个S/MIME安全机制，可用于签名指纹来自Bob。这是安全的。
One desirable property of a secure media system is to provide continuity of authentication: being able to ensure cryptographically that you are talking to the same person as before. With DTLS, continuity of authentication is achieved by having each side use the same public key/self-signed certificate for each connection (at least with a given peer entity). It then becomes possible to cache the
安全媒体系统的一个理想特性是提供身份验证的连续性：能够以加密方式确保您与以前的同一个人通话。对于DTLS，认证的连续性是通过让每一方为每个连接使用相同的公钥/自签名证书来实现的（至少与给定的对等实体）。然后就可以缓存
credential (or its hash) and verify that it is unchanged. Thus, once a single secure connection has been established, an implementation can establish a future secure channel even in the face of future insecure signaling.
凭证（或其哈希）并验证其未更改。因此，一旦建立了单个安全连接，即使面对未来的不安全信令，实现也可以建立未来的安全信道。
In order to enable continuity of authentication, implementations SHOULD attempt to keep a constant long-term key. Verifying implementations SHOULD maintain a cache of the key used for each peer identity and alert the user if that key changes.
为了实现身份验证的连续性，实现应该尝试保持一个恒定的长期密钥。验证实现应维护用于每个对等身份的密钥的缓存，并在该密钥发生更改时向用户发出警报。
An alternative available to Alice and Bob is to use human speech to verify each other's identity and then to verify each other's fingerprints also using human speech. Assuming that it is difficult to impersonate another's speech and seamlessly modify the audio contents of a call, this approach is relatively safe. It would not be effective if other forms of communication were being used such as video or instant messaging. DTLS supports this mode of operation. The minimal secure fingerprint length is around 64 bits.
Alice和Bob可用的另一种方法是使用人类语言验证对方的身份，然后也使用人类语言验证对方的指纹。假设很难模拟他人的语音并无缝修改通话的音频内容，这种方法相对安全。如果使用其他形式的通信，如视频或即时消息，则不会有效。DTLS支持这种操作模式。最小安全指纹长度约为64位。
ZRTP [AVT-ZRTP] includes Short Authentication String (SAS) mode in which a unique per-connection bitstring is generated as part of the cryptographic handshake. The SAS can be as short as 25 bits and so is somewhat easier to read. DTLS does not natively support this mode. Based on the level of deployment interest, a TLS extension [RFC5246] could provide support for it. Note that SAS schemes only work well when the endpoints recognize each other's voices, which is not true in many settings (e.g., call centers).
ZRTP[AVT-ZRTP]包括短身份验证字符串（SAS）模式，在该模式下，作为加密握手的一部分，每个连接生成一个唯一的位字符串。SAS可以短至25位，因此更易于阅读。DTLS本机不支持此模式。根据部署兴趣级别，TLS扩展[RFC5246]可以为其提供支持。请注意，SAS方案只有在端点能够识别彼此的语音时才能很好地工作，这在许多设置（例如呼叫中心）中是不正确的。
When RFC 4474 is used to bind the media keying material to the SIP signaling, the assurances about the provenance and security of the media are only as good as those for the signaling. There are two important cases to note here:
当RFC 4474用于将媒体密钥材料绑定到SIP信令时，关于媒体的起源和安全性的保证仅与信令的保证一样好。这里有两个重要的案例需要注意：
o RFC 4474 assumes that the proxy with the certificate "example.com" controls the namespace "example.com". Therefore, the RFC 4474 authentication service that is authoritative for a given namespace can control which user is assigned each name. Thus, the authentication service can take an address formerly assigned to Alice and transfer it to Bob. This is an intentional design feature of RFC 4474 and a direct consequence of the SIP namespace architecture.
o RFC 4474假定具有证书“example.com”的代理控制命名空间“example.com”。因此，对于给定名称空间具有权威性的RFC 4474身份验证服务可以控制为每个名称分配给哪个用户。因此，身份验证服务可以获取以前分配给Alice的地址并将其传输给Bob。这是RFC4474有意设计的特性，也是SIP命名空间体系结构的直接结果。
o When phone number URIs (e.g., 'sip:+17005551008@chicago.example.com' or 'sip:+17005551008@chicago.example.com;user=phone') are used, there is no structural reason to trust that the domain name is authoritative for a given phone number, although individual proxies and UAs may have private arrangements that allow them to trust other domains. This is a structural issue in that Public Switched Telephone Network (PSTN) elements are trusted to assert their phone number correctly and that there is no real concept of a given entity being authoritative for some number space.
o 当电话号码为URI时（例如，“sip:+17005551008@chicago.example.com“或”sip:+17005551008@chicago.example.com使用；user=phone'），没有结构性理由相信域名对给定电话号码具有权威性，尽管个人代理和UAs可能有私人安排，允许他们信任其他域。这是一个结构性问题，因为公共交换电话网（PSTN）元件被信任以正确地断言其电话号码，并且给定实体对于某些号码空间没有权威性的真实概念。
In both of these cases, the assurances that DTLS-SRTP provides in terms of data origin integrity and confidentiality are necessarily no better than SIP provides for signaling integrity when RFC 4474 is used. Implementors should therefore take care not to indicate misleading peer identity information in the user interface. That is, if the peer's identity is sip:+17005551008@chicago.example.com, it is not sufficient to display that the identity of the peer as +17005551008, unless there is some policy that states that the domain "chicago.example.com" is trusted to assert the E.164 numbers it is asserting. In cases where the UA can determine that the peer identity is clearly an E.164 number, it may be less confusing to simply identify the call as encrypted but to an unknown peer.
在这两种情况下，DTLS-SRTP在数据源完整性和机密性方面提供的保证不一定比SIP在使用RFC 4474时提供的信令完整性好。因此，实现者应该注意不要在用户界面中显示误导性的对等身份信息。也就是说，如果对等方的身份是sip：+17005551008@chicago.example.com，仅显示对等方的标识为+17005551008是不够的，除非有某种策略规定域“chicago.example.com”受信任，可以断言其断言的E.164号。在UA可以确定对等方身份显然是E.164号码的情况下，简单地将呼叫识别为加密呼叫，但识别给未知对等方，可能会减少混淆。
In addition, some middleboxes (back-to-back user agents (B2BUAs) and Session Border Controllers) are known to modify portions of the SIP message that are included in the RFC 4474 signature computation, thus breaking the signature. This sort of man-in-the-middle operation is precisely the sort of message modification that RFC 4474 is intended to detect. In cases where the middlebox is itself permitted to generate valid RFC 4474 signatures (e.g., it is within the same administrative domain as the RFC 4474 authentication service), then it may generate a new signature on the modified message. Alternately, the middlebox may be able to sign with some other identity that it is permitted to assert. Otherwise, the recipient cannot rely on the RFC 4474 Identity assertion and the UA MUST NOT indicate to the user that a secure call has been established to the claimed identity. Implementations that are configured to only establish secure calls SHOULD terminate the call in this case.
此外，已知一些中间盒（背对背用户代理（b2bua）和会话边界控制器）修改RFC 4474签名计算中包括的SIP消息的部分，从而破坏签名。这种中间人操作正是RFC4474想要检测的消息修改类型。如果中间盒本身被允许生成有效的RFC 4474签名（例如，它与RFC 4474认证服务在同一管理域内），则它可以在修改后的消息上生成新签名。或者，中间盒可以使用允许其声明的其他身份进行签名。否则，接收方不能依赖RFC 4474标识断言，并且UA不得向用户指示已建立对所声明标识的安全呼叫。在这种情况下，配置为仅建立安全调用的实现应该终止调用。
If SIP Identity or an equivalent mechanism is not used, then only protection against attackers who cannot actively change the signaling is provided. While this is still superior to previous mechanisms, the security provided is inferior to that provided if integrity is provided for the signaling.
如果未使用SIP标识或等效机制，则仅提供针对无法主动更改信令的攻击者的保护。虽然这仍然优于先前的机制，但提供的安全性不如为信令提供完整性时提供的安全性。
This specification does not depend on the certificates being held by endpoints being independently verifiable (e.g., being issued by a trusted third party). However, there is no limitation on such certificates being used. Aside from the difficulty of obtaining such certificates, it is not clear what identities those certificates would contain -- RFC 3261 specifies a convention for S/MIME certificates that could also be used here, but that has seen only minimal deployment. However, in closed or semi-closed contexts where such a convention can be established, third-party certificates can reduce the reliance on trusting even proxies in the endpoint's domains.
此规范不依赖于端点持有的证书是否可独立验证（例如，由受信任的第三方颁发）。但是，对使用此类证书没有限制。除了获取此类证书的困难之外，还不清楚这些证书将包含哪些标识——RFC3261为S/MIME证书指定了一个约定，该约定也可以在这里使用，但只进行了最少的部署。然而，在可以建立这种约定的封闭或半封闭环境中，第三方证书可以减少对端点域中甚至代理的信任。
One concern about the use of a long-term key is that compromise of that key may lead to compromise of past communications. In order to prevent this attack, DTLS supports modes with Perfect Forward Secrecy using Diffie-Hellman and Elliptic-Curve Diffie-Hellman cipher suites. When these modes are in use, the system is secure against such attacks. Note that compromise of a long-term key may still lead to future active attacks. If this is a concern, a backup authentication channel, such as manual fingerprint establishment or a short authentication string, should be used.
使用长期密钥的一个问题是，该密钥的泄露可能会导致过去通信的泄露。为了防止这种攻击，DTLS使用Diffie-Hellman和椭圆曲线Diffie-Hellman密码套件支持具有完美前向保密性的模式。当使用这些模式时，系统可安全抵御此类攻击。请注意，长期密钥泄露仍可能导致未来的主动攻击。如果存在此问题，则应使用备份身份验证通道，如手动指纹建立或短身份验证字符串。
Cullen Jennings contributed substantial text and comments to this document. This document benefited from discussions with Francois Audet, Nagendra Modadugu, and Dan Wing. Thanks also for useful comments by Flemming Andreasen, Jonathan Rosenberg, Rohan Mahy, David McGrew, Miguel Garcia, Steffen Fries, Brian Stucker, Robert Gilman, David Oran, and Peter Schneider.
Cullen Jennings为本文件提供了大量文本和评论。本文件得益于与Francois Audet、Nagendra Modadugu和Dan Wing的讨论。还感谢弗莱明·安德烈森、乔纳森·罗森博格、罗汉·马伊、大卫·麦克格鲁、米格尔·加西亚、斯蒂芬·弗里斯、布赖恩·斯图克、罗伯特·吉尔曼、大卫·奥兰和彼得·施耐德的有用评论。
We would like to thank Thomas Belling, Guenther Horn, Steffen Fries, Brian Stucker, Francois Audet, Dan Wing, Jari Arkko, and Vesa Lehtovirta for their input regarding traversal of SBCs.
我们要感谢Thomas Belling、Guenther Horn、Steffen Fries、Brian Stucker、Francois Audet、Dan Wing、Jari Arkko和Vesa Lehtovirta对SBC穿越的投入。
[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月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[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月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[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月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 41452005年9月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[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月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572]Lennox，J.，“会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输”，RFC 4572，2006年7月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4571]Lazzaro，J.，“面向连接传输上的帧实时传输协议（RTP）和RTP控制协议（RTCP）数据包”，RFC 4571，2006年7月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[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月。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4567]Arkko，J.，Lindholm，F.，Naslund，M.，Norrman，K.，和E.Carrara，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，2006年7月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568]Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 4568，2006年7月。
[AVT-ZRTP] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, March 2009.
[AVT-ZRTP]Zimmermann，P.，Johnston，A.，和J.Callas，“ZRTP：安全RTP的媒体路径密钥协议”，正在进行的工作，2009年3月。
[SRTP-EKT] McGrew, D., Andreasen, F., and L. Dondeti, "Encrypted Key Transport for Secure RTP", Work in Progress, March 2009.
[SRTP-EKT]McGrew，D.，Andreasen，F.，和L.Dondeti，“安全RTP的加密密钥传输”，正在进行的工作，2009年3月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，2010年5月。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, March 2009.
[RFC5479]Wing，D.，Fries，S.，Tschofenig，H.，和F.Audet，“媒体安全管理协议的要求和分析”，RFC 5479，2009年3月。
[MMUSIC-SDP] Andreasen, F., "SDP Capability Negotiation", Work in Progress, February 2010.
[MMUSIC-SDP]Andreasen，F.，“SDP能力谈判”，正在进行的工作，2010年2月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路传输RTP数据和控制数据包”，RFC 5761，2010年4月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 32622，2002年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916]Elwell，J.，“会话启动协议（SIP）中的连接身份”，RFC 4916，2007年6月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[SIPPING-SRTP] Wing, D., Audet, F., Fries, S., Tschofenig, H., and A. Johnston, "Secure Media Recording and Transcoding with the Session Initiation Protocol", Work in Progress, October 2008.
[SIPING-SRTP]Wing，D.，Audet，F.，Fries，S.，Tschofenig，H.，和A.Johnston，“使用会话启动协议的安全媒体录制和转码”，正在进行的工作，2008年10月。
[KEY-TRANSPORT] Wing, D., "DTLS-SRTP Key Transport (KTR)", Work in Progress, March 2009.
[KEY-TRANSPORT]Wing，D.，“DTLS-SRTP KEY TRANSPORT（KTR）”，正在进行的工作，2009年3月。
[MMUSIC-MEDIA] Stucker, B. and H. Tschofenig, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, March 2009.
[MMUSIC-MEDIA]Stucker，B.和H.Tschofenig，“媒体路径上信令协议通信的中间盒交互分析”，正在进行的工作，2009年3月。
[RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-Driven Privacy Mechanism for SIP", RFC 5767, April 2010.
[RFC5767]Munakata，M.，Schubert，S.，和T.Ohba，“SIP的用户代理驱动隐私机制”，RFC 5767，2010年4月。
[RFC5479] describes security requirements for media keying. This section evaluates this proposal with respect to each requirement.
[RFC5479]描述了媒体密钥的安全要求。本节针对每项要求对本建议书进行评估。
A.1. Forking and Retargeting (R-FORK-RETARGET, R-BEST-SECURE, R-DISTINCT)
A.1. 分叉和重定目标（R-FORK-RETARGET、R-BEST-SECURE、R-DISTINCT）
In this document, the SDP offer (in the INVITE) is simply an advertisement of the capability to do security. This advertisement does not depend on the identity of the communicating peer, so forking and retargeting work when all the endpoints will do SRTP. When a mix of SRTP and non-SRTP endpoints are present, we use the SDP capabilities mechanism currently being defined [MMUSIC-SDP] to transparently negotiate security where possible. Because DTLS establishes a new key for each session, only the entity with which the call is finally established gets the media encryption keys (R3).
在本文档中，SDP报价（在INVITE中）只是一个安全功能的广告。此播发不依赖于通信对等方的身份，因此当所有端点都将执行SRTP时，分叉和重定目标是有效的。当存在SRTP和非SRTP端点的混合时，我们使用当前定义的SDP能力机制[MMUSIC-SDP]，尽可能透明地协商安全性。因为DTLS为每个会话建立一个新密钥，所以只有最终建立调用的实体才能获得媒体加密密钥（R3）。
DTLS performs a new DTLS handshake with each endpoint, which establishes distinct keys and cryptographic contexts for each endpoint.
DTLS与每个端点执行新的DTLS握手，从而为每个端点建立不同的密钥和加密上下文。
DTLS allows sessions to be resumed with the 'TLS session resumption' functionality. This feature can be used to lower the amount of cryptographic computation that needs to be done when two peers re-initiate the communication. See [RFC5764] for more on session resumption in this context.
DTLS允许使用“TLS会话恢复”功能恢复会话。此功能可用于降低当两个对等方重新启动通信时需要进行的加密计算量。有关此上下文中会话恢复的更多信息，请参阅[RFC5764]。
Because the key establishment occurs in the media plane, media need not be clipped before the receipt of the SDP answer. Note, however, that only confidentiality is provided until the offerer receives the answer: the answerer knows that they are not sending data to an attacker but the offerer cannot know that they are receiving data from the answerer.
因为密钥建立发生在媒体平面中，所以在收到SDP应答之前不需要剪切媒体。但是，请注意，在报价人收到答复之前，仅提供保密：报价人知道他们没有向攻击者发送数据，但报价人无法知道他们正在从报价人接收数据。
The public key algorithms used by DTLS cipher suites, such as RSA, Diffie-Hellman, and Elliptic Curve Diffie-Hellman, are secure against passive attacks.
DTLS密码套件使用的公钥算法，如RSA、Diffie-Hellman和椭圆曲线Diffie-Hellman，能够抵御被动攻击。
DTLS provides protection against passive attacks by adversaries on the signaling path since only a fingerprint is exchanged using SIP signaling.
DTLS提供了针对信令路径上对手的被动攻击的保护，因为只有指纹使用SIP信令进行交换。
An attacker who controls the media channel but not the signaling channel can perform a MITM attack on the DTLS handshake but this will change the certificates that will cause the fingerprint check to fail. Thus, any successful attack requires that the attacker modify the signaling messages to replace the fingerprints.
控制媒体通道而非信令通道的攻击者可以对DTLS握手执行MITM攻击，但这将更改证书，从而导致指纹检查失败。因此，任何成功的攻击都需要攻击者修改信令消息以替换指纹。
If RFC 4474 Identity or an equivalent mechanism is used, an attacker who controls the signaling channel at any point between the proxies performing the Identity signatures cannot modify the fingerprints without invalidating the signature. Thus, even an attacker who controls both signaling and media paths cannot successfully attack the media traffic. Note that the channel between the UA and the authentication service MUST be secured and the authentication service MUST verify the UA's identity in order for this mechanism to be secure.
如果使用RFC 4474标识或等效机制，则在执行标识签名的代理之间的任意点控制信令信道的攻击者无法修改指纹，而不会使签名无效。因此，即使控制信令和媒体路径的攻击者也无法成功攻击媒体流量。请注意，UA和身份验证服务之间的通道必须是安全的，并且身份验证服务必须验证UA的身份，以便该机制是安全的。
Note that an attacker who controls the authentication service can impersonate the UA using that authentication service. This is an intended feature of SIP Identity -- the authentication service owns the namespace and therefore defines which user has which identity.
请注意，控制身份验证服务的攻击者可以使用该身份验证服务模拟UA。这是SIP标识的一个预期功能——身份验证服务拥有名称空间，因此定义了哪个用户拥有哪个标识。
When an end-to-end mechanism such as SIP-Identity [RFC4474] and SIP-Connected-Identity [RFC4916] or S/MIME are used, they bind the endpoint's certificate fingerprints to the From: address in the signaling. The fingerprint is covered by the Identity signature. When other mechanisms (e.g., SIPS) are used, then the binding is correspondingly weaker.
当使用端到端机制（如SIP标识[RFC4474]和SIP连接标识[RFC4916]或S/MIME）时，它们将端点的证书指纹绑定到信令中的From:地址。指纹由身份签名覆盖。当使用其他机制（例如SIP）时，则绑定相应较弱。
DTLS supports Diffie-Hellman and Elliptic Curve Diffie-Hellman cipher suites that provide PFS.
DTLS支持提供PFS的Diffie-Hellman和椭圆曲线Diffie-Hellman密码套件。
DTLS negotiates cipher suites before performing significant cryptographic computation and therefore supports algorithm negotiation and multiple cipher suites without additional computational expense.
DTLS在执行重要的密码计算之前协商密码套件，因此支持算法协商和多个密码套件，而无需额外的计算费用。
DTLS packets do not pass the RTP validity check. The first byte of a DTLS packet is the content type and all current DTLS content types have the first two bits set to zero, resulting in a version of zero; thus, failing the first validity check. DTLS packets can also be distinguished from STUN packets. See [RFC5764] for details on demultiplexing.
DTLS数据包未通过RTP有效性检查。DTLS数据包的第一个字节是内容类型，所有当前DTLS内容类型的前两位都设置为零，从而产生零版本；因此，第一次有效性检查失败。DTLS数据包也可以与STUN数据包区分开来。有关解复用的详细信息，请参见[RFC5764]。
Third-party certificates are not required because signaling (e.g., [RFC4474]) is used to authenticate the certificates used by DTLS. However, if the parties share an authentication infrastructure that is compatible with TLS (third-party certificates or shared keys) it can be used.
不需要第三方证书，因为信令（例如，[RFC4474]）用于验证DTL使用的证书。但是，如果双方共享与TLS（第三方证书或共享密钥）兼容的身份验证基础设施，则可以使用该基础设施。
TLS implementations already may be FIPS 140-2 approved and the algorithms used here are consistent with the approval of DTLS and DTLS-SRTP.
TLS实施可能已经获得FIPS 140-2批准，此处使用的算法与DTLS和DTLS-SRTP的批准一致。
The signaling exchange is linked to the key management exchange using the fingerprints carried in SIP and the certificates are exchanged in DTLS.
信令交换使用SIP中携带的指纹链接到密钥管理交换，证书在DTL中交换。
DTLS offers some degree of Denial-of-Service (DoS) protection as a built-in feature (see Section 4.2.1 of [RFC4347]).
DTLS作为内置功能提供一定程度的拒绝服务（DoS）保护（见[RFC4347]第4.2.1节）。
DTLS allows cipher suites to be negotiated and hence new algorithms can be incrementally deployed. Work on replacing the fixed MD5/SHA-1 key derivation function is ongoing.
DTLS允许协商密码套件，因此可以增量部署新算法。替换固定MD5/SHA-1密钥派生函数的工作正在进行中。
DTLS provides protection against downgrading attacks since the selection of the offered cipher suites is confirmed in a later stage of the handshake. This protection is efficient unless an adversary is able to break a cipher suite in real-time. RFC 4474 is able to prevent an active attacker on the signaling path from downgrading the call from SRTP to RTP.
DTLS提供了针对降级攻击的保护，因为所提供密码套件的选择在握手的后期阶段得到确认。除非对手能够实时破解密码套件，否则这种保护是有效的。RFC 4474能够防止信令路径上的主动攻击者将呼叫从SRTP降级到RTP。
DTLS allows a User Agent to negotiate media security parameters for each individual session.
DTLS允许用户代理为每个会话协商媒体安全参数。
The DTLS-SRTP framework does not rely on SIP; every protocol that is capable of exchanging a fingerprint and the media description can be secured.
DTLS-SRTP框架不依赖SIP；每个能够交换指纹和媒体描述的协议都是安全的。
An extension, see [SIPPING-SRTP], has been specified to support media recording that does not require intermediaries to act as an MITM.
已指定一个扩展，请参见[SIPING-SRTP]，以支持不需要中介机构充当MITM的媒体录制。
When media recording is done by intermediaries, then they need to act as an MITM.
当媒体录制由中间人完成时，他们需要充当MITM。
In order to interface with any intermediary that transcodes the media, the transcoder must have access to the keying material and be treated as an endpoint for the purposes of this document.
为了与转码媒体的任何中介进行接口，转码器必须能够访问键控材料，并在本文档中被视为端点。
The DTLS-SRTP framework allows the media security to terminate at a PSTN gateway. This does not provide end-to-end security, but is consistent with the security goals of this framework because the gateway is authorized to speak for the PSTN namespace.
DTLS-SRTP框架允许媒体安全终止于PSTN网关。这不提供端到端安全性，但与此框架的安全目标一致，因为网关被授权代表PSTN命名空间。
DTLS-SRTP allows RTP media to be received by the calling party until SRTP has been negotiated with the answerer, after which SRTP is preferred over RTP.
DTLS-SRTP允许呼叫方接收RTP媒体，直到与应答方协商SRTP，然后SRTP优先于RTP。
The Heterogeneous Error Response Forking Problem (HERFP) is not applicable to DTLS-SRTP since the key exchange protocol will be executed along the media path and hence error messages are communicated along this path and proxies do not need to progress them.
异构错误响应分叉问题（HERFP）不适用于DTLS-SRTP，因为密钥交换协议将沿着媒体路径执行，因此错误消息将沿着该路径进行通信，代理不需要对其进行处理。
Authors' Addresses
作者地址
Jason Fischl Skype, Inc. 2145 Hamilton Ave. San Jose, CA 95135 USA
美国加利福尼亚州圣何塞汉密尔顿大道2145号杰森·菲施勒Skype公司，邮编95135
Phone: +1-415-692-1760
EMail: jason.fischl@skype.net
Phone: +1-415-692-1760
EMail: jason.fischl@skype.net
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo, 02600 Finland
芬兰埃斯波6号，邮编02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
Eric Rescorla RTFM，Inc.美国加利福尼亚州帕洛阿尔托埃奇伍德大道2064号，邮编94303
EMail: ekr@rtfm.com
EMail: ekr@rtfm.com