Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 7345 I. Sedlacek
Category: Standards Track Ericsson
ISSN: 2070-1721 G. Salgueiro
Cisco
August 2014
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 7345 I. Sedlacek
Category: Standards Track Ericsson
ISSN: 2070-1721 G. Salgueiro
Cisco
August 2014
UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)
数据报传输层安全（DTLS）上的UDP传输层（UDPTL）
Abstract
摘要
This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP).
本文件规定了UDP传输层（UDPTL）协议（T.38传真的主要传输协议）如何通过数据报传输层安全（DTLS）协议进行传输，以及在会话描述协议（SDP）中如何指示UDPTL在DTLS上的使用，以及如何在使用会话发起协议（SIP）建立的会话中协商DTLS上的UDPTL。
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/rfc7345.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7345.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions .....................................................5
3. Secure Channel ..................................................5
4. SDP Offerer/Answerer Procedures .................................6
4.1. General ....................................................6
4.2. Generating the Initial Offer ...............................7
4.3. Generating the Answer ......................................7
4.4. Offerer Processing of the Answer ...........................7
4.5. Modifying the Session ......................................7
5. Miscellaneous Considerations ....................................8
5.1. Anonymous Calls ............................................8
5.2. NAT Traversal ..............................................8
5.2.1. ICE Usage ...........................................8
5.2.2. STUN Interaction ....................................8
5.3. Rekeying ...................................................9
5.4. Compatibility with UDPTL over UDP ..........................9
6. Security Considerations .........................................9
7. IANA Considerations ............................................10
8. Acknowledgments ................................................10
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
Appendix A. Examples .............................................13
A.1. General ...................................................13
A.2. Basic Message Flow ........................................13
A.3. Message Flow of T.38 Fax Replacing Audio Media Stream in
an Existing Audio-Only Session ............................20
1. Introduction ....................................................3
2. Conventions .....................................................5
3. Secure Channel ..................................................5
4. SDP Offerer/Answerer Procedures .................................6
4.1. General ....................................................6
4.2. Generating the Initial Offer ...............................7
4.3. Generating the Answer ......................................7
4.4. Offerer Processing of the Answer ...........................7
4.5. Modifying the Session ......................................7
5. Miscellaneous Considerations ....................................8
5.1. Anonymous Calls ............................................8
5.2. NAT Traversal ..............................................8
5.2.1. ICE Usage ...........................................8
5.2.2. STUN Interaction ....................................8
5.3. Rekeying ...................................................9
5.4. Compatibility with UDPTL over UDP ..........................9
6. Security Considerations .........................................9
7. IANA Considerations ............................................10
8. Acknowledgments ................................................10
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
Appendix A. Examples .............................................13
A.1. General ...................................................13
A.2. Basic Message Flow ........................................13
A.3. Message Flow of T.38 Fax Replacing Audio Media Stream in
an Existing Audio-Only Session ............................20
While it is possible to transmit highly sensitive documents using traditional telephony encryption devices, secure fax on the Public Switched Telephone Network (PSTN) was never widely considered or prioritized. This was mainly because of the challenges involved with malevolent physical access to telephony equipment. As real-time communications transition to IP networks, where information might potentially be intercepted or spoofed, an appropriate level of security for fax that offers integrity and confidentiality protection is vital.
虽然可以使用传统的电话加密设备传输高度敏感的文件，但公共交换电话网（PSTN）上的安全传真从未得到广泛考虑或优先考虑。这主要是因为恶意物理访问电话设备所带来的挑战。随着实时通信向IP网络过渡，信息可能被截获或欺骗，为传真提供完整性和机密性保护的适当安全级别至关重要。
The overwhelmingly predominant fax transport protocol is UDPTL-based, as described in Section 9.1 of [ITU.T38.2010]. The protocol stack for fax transport using UDPTL is shown in Figure 1.
如[ITU.T38.2010]第9.1节所述，占绝对优势的传真传输协议基于UDPTL。使用UDPTL进行传真传输的协议栈如图1所示。
+-----------------------------+
| Internet facsimile protocol |
+-----------------------------+
| UDPTL |
+-----------------------------+
| UDP |
+-----------------------------+
| IP |
+-----------------------------+
+-----------------------------+
| Internet facsimile protocol |
+-----------------------------+
| UDPTL |
+-----------------------------+
| UDP |
+-----------------------------+
| IP |
+-----------------------------+
Figure 1: Protocol Stack for UDPTL over UDP
图1:UDP上UDPTL的协议栈
The following mechanisms are available for securing fax:
以下机制可用于保护传真：
o Annex H of [ITU.T30.2005] specifies an application-layer integrity and confidentiality protection of fax that is independent of the transport protocol and is based on the RSA algorithm for use with the T.30 telephony protocol by Group 3 facsimile equipment (G3FE).
o [ITU.T30.2005]的附录H规定了传真的应用层完整性和保密保护，该保护独立于传输协议，并基于RSA算法，供第3组传真设备（G3FE）与T.30电话协议一起使用。
o [ITU.T38.2010] specifies fax transport over RTP/SAVP, which enables integrity and confidentiality protection of fax in IP networks.
o [ITU.T38.2010]规定了RTP/SAVP上的传真传输，该传输支持IP网络中传真的完整性和机密性保护。
Both of these mechanisms have been available for many years and never gained any significant adoption in the market. This has prompted an effort to develop an approach, based on open standards, for securing fax communications over an IP-based transport.
这两种机制已经存在多年，从未在市场上得到任何重大采用。这促使人们努力开发一种基于开放标准的方法，用于通过基于IP的传输保护传真通信。
Telephony-based protocols like T.30 offer application-level security options like the RSA-based approach detailed in Annex H of the T.30 specification [ITU.T30.2005]. The problem is that it is very sparingly implemented and not enforced at the transport level.
基于电话的协议（如T.30）提供了应用级安全选项，如T.30规范[ITU.T30.2005]附录H中详述的基于RSA的方法。问题在于，该计划的实施非常谨慎，在运输层面上没有得到执行。
It is worth noting that while T.38 over RTP offers a very viable option for such standards-based IP security solution using Secure Realtime Transport Protocol (SRTP), this fax-over-IP transport never gained any traction in the marketplace and accounts for a negligible percentage of fax-over-IP implementations.
值得注意的是，虽然T.38 over RTP为使用安全实时传输协议（SRTP）的此类基于标准的IP安全解决方案提供了一个非常可行的选择，但这种IP传真传输从未在市场上获得任何吸引力，并且在IP传真实施中所占的比例微乎其微。
Thus, security mechanisms offering integrity and confidentiality protection should be limited to UDPTL-based fax transport, which is the only broad-based fax-over-IP solution. The 3rd Generation Partnership Project (3GPP) launched a study on how best to provide secure fax in the IP Multimedia Subsystem (IMS) for UDPTL. Results of the study confirmed that this security was best achieved by using UDPTL over DTLS.
因此，提供完整性和机密性保护的安全机制应限于基于UDPTL的传真传输，这是唯一基于广泛的IP传真解决方案。第三代合作伙伴计划（3GPP）启动了一项关于如何在UDPTL的IP多媒体子系统（IMS）中提供安全传真的研究。研究结果证实，通过使用UDPTL而不是DTL，可以最好地实现这种安全性。
This document specifies fax transport using UDPTL over DTLS [RFC6347], which enables integrity and confidentiality protection of fax in IP networks. The protocol stack that enhances fax transport to offer integrity and confidentiality using UDPTL over DTLS is shown in Figure 2.
本文件规定了使用UDPTL over DTLS[RFC6347]进行传真传输，该传输可实现IP网络中传真的完整性和机密性保护。使用UDPTL over DTLS增强传真传输以提供完整性和机密性的协议栈如图2所示。
+-----------------------------+
| Internet facsimile protocol |
+-----------------------------+
| UDPTL |
+-----------------------------+
| DTLS |
+-----------------------------+
| UDP |
+-----------------------------+
| IP |
+-----------------------------+
+-----------------------------+
| Internet facsimile protocol |
+-----------------------------+
| UDPTL |
+-----------------------------+
| DTLS |
+-----------------------------+
| UDP |
+-----------------------------+
| IP |
+-----------------------------+
Figure 2: Protocol Stack for UDPTL over DTLS over UDP
图2:UDP上DTLS上的UDPTL协议栈
The primary motivations for the mechanism in this document are:
本文件中机制的主要动机是：
o The design of DTLS [RFC6347] is clearly defined and well understood, and implementations are widely available.
o DTLS[RFC6347]的设计已明确定义并得到充分理解，并且实现方式也广泛可用。
o No DTLS extensions are required in order to enable UDPTL transport over DTLS.
o 无需DTLS扩展即可通过DTLS实现UDPTL传输。
o Fax transport using UDPTL over DTLS only requires insertion of the DTLS layer between the UDPTL layer and the UDP layer, as shown in Figure 2. The UDPTL layer and the layers above the UDPTL layer require no modifications.
o 使用UDPTL over DTLS的传真传输只需要在UDPTL层和UDP层之间插入DTLS层，如图2所示。UDPTL层和UDPTL层上方的层不需要修改。
o UDPTL [ITU.T38.2010] is by far the most widely deployed fax transport protocol in IP networks.
o UDPTL[ITU.T38.2010]是迄今为止在IP网络中部署最广泛的传真传输协议。
o 3GPP and the IP fax community need a mechanism to transport UDPTL over DTLS in order to provide secure fax in SIP-based networks (including IMS).
o 3GPP和IP传真社区需要一种通过dtl传输UDPTL的机制，以便在基于SIP的网络（包括IMS）中提供安全传真。
This document specifies the transport of UDPTL over DTLS using the DTLS record layer "application_data" packets [RFC5246] [RFC6347].
本文件规定使用DTLS记录层“应用程序数据”数据包[RFC5246][RFC6347]通过DTLS传输UDPTL。
Since the DTLS record layer "application_data" packet does not indicate whether it carries UDPTL or some other protocol, the usage of a dedicated DTLS association for transport of UDPTL needs to be negotiated, e.g., using the Session Description Protocol (SDP) [RFC4566] and the SDP offer/answer mechanism [RFC3264].
由于DTLS记录层“应用程序数据”分组不指示其是否携带UDPTL或某些其他协议，因此需要协商专用DTLS关联用于UDPTL传输的使用，例如，使用会话描述协议（SDP）[RFC4566]和SDP提供/应答机制[RFC3264]。
Therefore, this document specifies a new <proto> value [RFC4566] for the SDP media description ("m=" line) [RFC3264], in order to indicate UDPTL over DTLS in SDP messages [RFC4566].
因此，本文档为SDP媒体描述（“m=”line）[RFC3264]指定了一个新的<proto>值[RFC4566]，以指示SDP消息[RFC4566]中DTL上的UDPTL。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
DTLS uses the term "session" to refer to a long-lived set of keying material that spans DTLS associations. In this document, in order to be consistent with SIP/SDP usage of "session" terminology, we use "session" to refer to a multimedia session and use the term "DTLS session" to refer to the DTLS construct. We use the term "DTLS 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 session can be used to establish the keying material for multiple DTLS 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.
DTLS使用术语“会话”来表示跨越DTLS关联的一组长寿命的键控材质。在本文档中，为了与SIP/SDP对“会话”术语的使用保持一致，我们使用“会话”来表示多媒体会话，并使用术语“DTLS会话”来表示DTLS构造。我们使用术语“DTLS关联”来指代与单个主机/端口关联的特定DTLS密码套件和键控材料集。同一DTLS会话可用于为多个DTLS关联建立键控材料。为了与其他SIP/SDP用法保持一致，当所指的是非特定DTL的多媒体流时，我们使用术语“连接”。
The UDPTL-over-DTLS media stream is negotiated using the SDP offer/ answer mechanism [RFC3264]. See Section 4 for more details.
使用SDP提供/应答机制[RFC3264]协商DTLS媒体流上的UDPTL。详见第4节。
DTLS is used as specified in [RFC6347]. Once the DTLS handshake is successfully completed (in order to prevent facsimile data from being transmitted insecurely), the UDPTL packets MUST be transported in DTLS record layer "application_data" packets.
DTLS按照[RFC6347]中的规定使用。一旦DTLS握手成功完成（为了防止传真数据不安全地传输），UDPTL数据包必须在DTLS记录层“应用程序数据”数据包中传输。
An endpoint (i.e., both the offerer and the answerer) MUST create an SDP media description ("m=" line) for each UDPTL-over-DTLS media stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the "proto" field of the "m=" line.
端点（即，报价人和应答人）必须为DTLS媒体流上的每个UDPTL创建SDP媒体描述（“m=”行），并且必须为“m=”行的“proto”字段分配UDP/TLS/UDPTL值（见表1）。
The procedures in this section apply to an "m=" line associated with a UDPTL-over-DTLS media stream.
本节中的步骤适用于与UDPTL over DTLS媒体流关联的“m=”行。
In order to negotiate a UDPTL-over-DTLS media stream, the following SDP attributes are used:
为了通过DTLS媒体流协商UDPTL，使用以下SDP属性：
o The SDP attributes defined for UDPTL over UDP, as described in [ITU.T38.2010]; and
o 为UDP上的UDPTL定义的SDP属性，如[ITU.T38.2010]所述；和
o The SDP attributes, defined in [RFC4145] and [RFC4572], as described in this section.
o [RFC4145]和[RFC4572]中定义的SDP属性，如本节所述。
The endpoint MUST NOT use the SDP "connection" attribute [RFC4145].
端点不得使用SDP“连接”属性[RFC4145]。
In order to negotiate the TLS roles for the UDPTL-over-DTLS transport connection, the endpoint MUST use the SDP "setup" attribute [RFC4145].
为了协商UDPTL over DTLS传输连接的TLS角色，端点必须使用SDP“setup”属性[RFC4145]。
If the endpoint supports, and is willing to use, a cipher suite with an associated certificate, the endpoint MUST include an SDP "fingerprint" attribute [RFC4572]. The endpoint MUST support SHA-256 for generating and verifying the SDP "fingerprint" attribute value. The use of SHA-256 is preferred. UDPTL over DTLS, at a minimum, MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward Secrecy (PFS) cipher suites over non-PFS cipher suites. Implementations SHOULD disable TLS-level compression.
如果端点支持并愿意使用带有关联证书的密码套件，则端点必须包含SDP“指纹”属性[RFC4572]。端点必须支持SHA-256以生成和验证SDP“指纹”属性值。首选使用SHA-256。DTL上的UDPTL至少必须支持TLS_DHE_RSA_和AES_128_GCM_SHA256，并且必须支持TLS_ECDHE_RSA_和AES_128_GCM_SHA256。UDPTL而非DTL必须优先选择TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256以及任何其他完美前向保密（PFS）密码套件，而不是非PFS密码套件。实现应该禁用TLS级压缩。
If a cipher suite with an associated certificate is selected during the DTLS handshake, the certificate received during the DTLS handshake MUST match the fingerprint received in the SDP "fingerprint" attribute. 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.
如果在DTLS握手期间选择了具有关联证书的密码套件，则在DTLS握手期间接收的证书必须与在SDP“指纹”属性中接收的指纹匹配。如果指纹与哈希证书不匹配，则端点必须立即中断媒体会话。注意，在建立连接之前，允许等待直到接收到另一方的指纹；但是，这可能会产生不良的延迟影响。
The offerer SHOULD assign the SDP "setup" attribute with a value of "actpass", unless the offerer insists on being either the sender or receiver of the DTLS ClientHello message, in which case the offerer can use either a value of "active" (the offerer will be the sender of ClientHello) or "passive" (the offerer will be the receiver of ClientHello). The offerer MUST NOT assign an SDP "setup" attribute with a "holdconn" value.
报价人应将SDP“设置”属性的值指定为“actpass”，除非报价人坚持作为DTLS ClientHello消息的发送方或接收方，在这种情况下，报价人可以使用“主动”（报价人将是ClientHello的发送方）或“被动”（报价人将是ClientHello的接收方）. 报价人不得为SDP“设置”属性分配“holdconn”值。
If the offerer assigns the SDP "setup" attribute with a value of "actpass" or "passive", the offerer MUST be prepared to receive a DTLS ClientHello message before it receives the SDP answer.
如果报价人将SDP“设置”属性的值指定为“actpass”或“被动”，则报价人必须在收到SDP应答之前准备好接收DTLS ClientHello消息。
If the answerer accepts the offered UDPTL-over-DTLS transport connection, in the associated SDP answer, the answerer MUST assign an SDP "setup" attribute with a value of either "active" or "passive", according to the procedures in [RFC4145]. The answerer MUST NOT assign an SDP "setup" attribute with a value of "holdconn".
如果应答者接受提供的UDPTL over DTLS传输连接，则在相关的SDP应答中，应答者必须根据[RFC4145]中的程序分配一个SDP“设置”属性，该属性的值为“主动”或“被动”。应答者不得将SDP“设置”属性的值指定为“holdconn”。
If the answerer assigns an SDP "setup" attribute with a value of "active" value, the answerer MUST initiate a DTLS handshake by sending a DTLS ClientHello message on the negotiated media stream, towards the IP address and port of the offerer.
如果应答者将SDP“设置”属性的值指定为“活动”值，则应答者必须通过在协商的媒体流上向报价者的IP地址和端口发送DTLS ClientHello消息来启动DTLS握手。
When the offerer receives an SDP answer, if the offerer ends up being active it MUST initiate a DTLS handshake by sending a DTLS ClientHello message on the negotiated media stream, towards the IP address and port of the answerer.
当报价人收到SDP应答时，如果报价人最终处于活动状态，则必须通过在协商的媒体流上向应答人的IP地址和端口发送DTLS ClientHello消息来发起DTLS握手。
Once an offer/answer exchange has been completed, either endpoint MAY send a new offer in order to modify the session. The endpoints can reuse the existing DTLS association if the key fingerprint values and transport parameters indicated by each endpoint are unchanged. Otherwise, following the rules for the initial offer/answer exchange, the endpoints can negotiate and create a new DTLS association and, once created, delete the previous DTLS association, following the same rules for the initial offer/answer exchange. Each endpoint needs to be prepared to receive data on both the new and old DTLS associations as long as both are alive.
一旦提供/应答交换完成，任一端点都可以发送新的提供以修改会话。如果每个端点指示的关键指纹值和传输参数不变，则端点可以重用现有DTLS关联。否则，按照初始报价/应答交换的规则，端点可以协商并创建新的DTLS关联，一旦创建，就可以按照初始报价/应答交换的相同规则删除以前的DTLS关联。每个端点都需要准备好接收新的和旧的DTLS关联上的数据，只要它们都是活动的。
When making anonymous calls, a new self-signed certificate SHOULD be used for each call, and attributes inside the certificate MUST NOT contain information that allows either correlation or identification of the user making anonymous calls. This is particularly important for the "subjectAltName" and "commonName" attributes.
进行匿名呼叫时，应为每个呼叫使用新的自签名证书，并且证书中的属性不得包含允许进行匿名呼叫的用户的关联或标识的信息。这对于“subjectAltName”和“commonName”属性尤为重要。
When Interactive Connectivity Establishment (ICE) [RFC5245] 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. User Agents (UAs) 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. In the case of an ICE restart, the DTLS handshake procedure is repeated, and a new DTLS association is created. Once the DTLS handshake is completed and the new DTLS association has been created, the previous DTLS association is deleted.
当使用交互式连接建立（ICE）[RFC5245]时，在DTLS握手开始之前执行ICE连接检查。注意，如果使用积极提名模式，在ICE最终收敛到单个候选对之前，多个候选对可能被标记为有效。用户代理（UAs）必须将与单个组件关联的所有ICE候选对视为同一DTLS关联的一部分。因此，即使存在多个有效候选对，也只有一个DTLS握手。注意，这可能意味着如果所选候选对移位，则调整端点IP地址，就像DTLS分组是普通媒体流一样。在ICE重启的情况下，重复DTLS握手过程，并创建新的DTLS关联。完成DTLS握手并创建新的DTLS关联后，将删除以前的DTLS关联。
The UA MUST send the Session Traversal Utilities for NAT (STUN) packets [RFC5389] directly over UDP, not over DTLS.
UA必须直接通过UDP而不是DTL发送NAT（STUN）数据包[RFC5389]的会话遍历实用程序。
The UA MUST support the following mechanism for demultiplexing packets arriving on the IP address and port associated with the DTLS association:
UA必须支持以下机制来解复用到达与DTLS关联的IP地址和端口的数据包：
o If the value of the first byte of the packet is 0 or 1, then the packet is STUN.
o 如果数据包的第一个字节的值为0或1，则该数据包为STUN。
o If the value of the first byte of the packet is between 20 and 63 (inclusive), the packet is DTLS.
o 如果数据包的第一个字节的值介于20和63之间（包括20和63），则数据包为DTLS。
During rekeying, packets protected by the previous set of keys can arrive after the DTLS handshake caused by rekeying has completed, because packets can be reordered on the wire. To compensate for this fact, receivers MUST maintain both sets of keys for some time in order to be able to decrypt and verify older packets. The duration of maintaining the previous set of keys after the finish of the DTLS handshake is out of the scope of this document.
在重新设置密钥期间，受前一组密钥保护的数据包可以在由重新设置密钥引起的DTLS握手完成后到达，因为数据包可以在线路上重新排序。为了补偿这一事实，接收方必须在一段时间内维护这两组密钥，以便能够解密和验证较旧的数据包。DTLS握手完成后维护前一组密钥的持续时间不在本文档范围内。
If a user requires fax to be transported securely using UDPTL over DTLS, and if the remote user does not support UDPTL over DTLS, then a fax media stream cannot be established.
如果用户要求使用UDPTL over DTLS安全传输传真，并且远程用户不支持UDPTL over DTLS，则无法建立传真媒体流。
If a user prefers fax to be transported securely using UDPTL over DTLS but is willing to transport the fax insecurely in case the remote user does not support UDPTL over DTLS, then the SDP Capability Negotiation mechanism [RFC5939] can be used to offer both UDPTL over DTLS and UDPTL over UDP. Alternatively, if the remote user rejects an SDP offer for UDPTL over DTLS, a new SDP offer for a UDPTL-over-UDP media stream can be sent.
如果用户喜欢使用UDPTL over DTLS安全地传输传真，但如果远程用户不支持UDPTL over DTLS，则可以使用SDP能力协商机制[RFC5939]提供UDPTL over DTLS和UDPTL over UDP。或者，如果远程用户拒绝DTL上UDPTL的SDP提供，则可以发送UDP媒体流上UDPTL的新SDP提供。
Fax may be used to transmit a wide range of sensitive data, including personal, corporate, and governmental information. It is therefore critical to be able to protect against threats to the confidentiality and integrity of the transmitted data.
传真可用于传输范围广泛的敏感数据，包括个人、公司和政府信息。因此，保护传输数据的机密性和完整性免受威胁至关重要。
The mechanism in this document provides integrity and confidentiality protection for fax by specifying fax transport using UDPTL over DTLS [RFC6347].
本文档中的机制通过使用UDPTL over DTLS指定传真传输，为传真提供完整性和机密性保护[RFC6347]。
DTLS media stream negotiated using SIP/SDP requires a mechanism to ensure that the certificate received via DTLS was issued by the remote party of the SIP session.
使用SIP/SDP协商的DTLS媒体流需要一种机制来确保通过DTLS接收的证书由SIP会话的远程方颁发。
The standard 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 and the cost for issuing and deploying PKIX certificates can be justified. Issuing and deploying PKIX certificates to all clients is not realistic in most deployment scenarios.
用于认证通信方的标准DTLS策略是向服务器（以及可选的客户端）提供PKIX[RFC5280]证书。然后，客户端验证证书并检查证书中的名称是否与服务器的域名匹配。这是因为服务器数量相对较少，并且颁发和部署PKIX证书的成本是合理的。在大多数部署场景中，向所有客户端颁发和部署PKIX证书是不现实的。
The design described in this document is intended to leverage the integrity protection of the SIP signaling, 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 via the SIP Identity [RFC4474] mechanism. Other mechanisms, such as the S/MIME mechanism [RFC3261] or perhaps future mechanisms yet to be specified, could also serve this purpose.
本文档中描述的设计旨在利用SIP信令的完整性保护，同时不要求保密。只要连接的每一方都能验证从另一方收到的SDP的完整性，那么DTLS握手就不能通过中间人攻击被劫持。这种完整性保护很容易由调用者通过SIP标识[RFC4474]机制提供给被调用者。其他机制，如S/MIME机制[RFC3261]或可能尚未指定的未来机制，也可以用于此目的。
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）。
This document updates the "Session Description Protocol (SDP) Parameters" registry as specified in Section 8.2.2 of [RFC4566]. Specifically, the values in Table 1 have been added to the SDP "proto" field registry.
本文件更新了[RFC4566]第8.2.2节规定的“会话描述协议（SDP）参数”注册表。具体而言，表1中的值已添加到SDP“proto”字段注册表中。
+-------+---------------+-----------+
| Type | SDP Name | Reference |
+-------+---------------+-----------+
| proto | UDP/TLS/UDPTL | [RFC7345] |
+-------+---------------+-----------+
+-------+---------------+-----------+
| Type | SDP Name | Reference |
+-------+---------------+-----------+
| proto | UDP/TLS/UDPTL | [RFC7345] |
+-------+---------------+-----------+
Table 1: SDP "proto" Field Values
表1:SDP“proto”字段值
Special thanks to Peter Dawes, who provided comments on the initial draft version of the document, and to Paul E. Jones, James Rafferty, Albrecht Schwarz, Oscar Ohlsson, David Hanes, Adam Gensler, Ari Keranen, Flemming Andreasen, John Mattsson, and Marc Petit-Huguenin, who provided valuable feedback and input. Barry Leiba, Spencer Dawkins, Pete Resnick, Kathleen Moriarty, and Stephen Farrell provided valuable feedback during the IESG review. Thanks to Scott Brim for performing the Gen-ART review. Thanks to Alissa Cooper for her help as sponsoring Area Director.
特别感谢彼得·道斯（Peter Dawes），他对文件初稿发表了意见，并感谢保罗·琼斯（Paul E.Jones）、詹姆斯·拉弗蒂（James Rafferty）、阿尔布雷希特·施瓦兹（Albrecht Schwarz）、奥斯卡·奥尔森（Oscar Ohlsson）、大卫·汉斯（David Hanes）、亚当·根斯勒（Adam Gensler）、阿里·凯拉宁（Ari Keranen）、弗莱明·安德烈森（Fleming Andreasen）、约翰·马特森（John Mat。Barry Leiba、Spencer Dawkins、Pete Resnick、Kathleen Moriarty和Stephen Farrell在IESG审查期间提供了宝贵的反馈。感谢Scott Brim完成了Gen ART review。感谢Alissa Cooper作为赞助区域总监的帮助。
[ITU.T30.2005] International Telecommunications Union, "Procedures for document facsimile transmission in the general switched telephone network", ITU-T Recommendation T.30, September 2005.
[ITU.T30.2005]国际电信联盟，“通用交换电话网络中文件传真传输的程序”，ITU-T建议T.30，2005年9月。
[ITU.T38.2010] International Telecommunications Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, September 2010.
[ITU.T38.2010]国际电信联盟，“IP网络实时第3组传真通信程序”，ITU-T建议T.38，2010年9月。
[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月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.translate error, please retry
[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月。
[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月。
[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月。
[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月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[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月。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009.
[RFC5479]Wing，D.，Fries，S.，Tschofenig，H.，和F.Audet，“媒体安全管理协议的要求和分析”，RFC 5479，2009年4月。
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
[RFC5939]Andreasen，F.，“会话描述协议（SDP）能力协商”，RFC 59392010年9月。
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.
在建立会话之前，Alice和Bob都会生成自签名证书，这些证书用于单个会话，或者更可能用于多个会话。
The SIP signaling from Alice to her proxy is transported over TLS to ensure an integrity-protected channel between Alice and her identity service. Alice's identity service asserts identity of Alice and protects the SIP message, e.g., using SIP Identity. Transport between proxies should also be protected, e.g., by use of TLS.
从Alice到她的代理的SIP信令通过TLS传输，以确保Alice和她的身份服务之间的完整性保护通道。Alice的标识服务断言Alice的标识并保护SIP消息，例如，使用SIP标识。代理之间的传输也应受到保护，例如使用TLS。
In order to simplify the flow, only one element is shown for Alice's and Bob's proxies.
为了简化流程，Alice和Bob的代理只显示一个元素。
For the sake of brevity and simplicity, only the mandatory SDP T.38 attributes are shown.
为了简洁和简单起见，仅显示强制的SDP T.38属性。
Figure 3 shows an example message flow of session establishment for T.38 fax securely transported using UDPTL over DTLS.
图3显示了使用UDPTL over DTLS安全传输的T.38传真会话建立的示例消息流。
In this example flow, Alice acts as the passive endpoint of the DTLS association, and Bob acts as the active endpoint of the DTLS association.
在这个示例流中，Alice充当DTLS关联的被动端点，Bob充当DTLS关联的主动端点。
Alice Proxies Bob
| (1) SIP INVITE | |
|----------------------->| |
| | (2) SIP INVITE |
| |----------------------->|
| | (3) DTLS ClientHello |
|<------------------------------------------------|
| (4) remaining messages of DTLS handshake |
|<----------------------------------------------->|
| | |
| | |
| | (5) SIP 200 OK |
| |<-----------------------|
| (6) SIP 200 OK | |
|<-----------------------| |
| (7) SIP ACK | |
|------------------------------------------------>|
| (8) T.38 message using UDPTL over DTLS |
|<----------------------------------------------->|
| | |
Alice Proxies Bob
| (1) SIP INVITE | |
|----------------------->| |
| | (2) SIP INVITE |
| |----------------------->|
| | (3) DTLS ClientHello |
|<------------------------------------------------|
| (4) remaining messages of DTLS handshake |
|<----------------------------------------------->|
| | |
| | |
| | (5) SIP 200 OK |
| |<-----------------------|
| (6) SIP 200 OK | |
|<-----------------------| |
| (7) SIP ACK | |
|------------------------------------------------>|
| (8) T.38 message using UDPTL over DTLS |
|<----------------------------------------------->|
| | |
Figure 3: Basic Message Flow
图3：基本消息流
Message (1):
信息（1）：
Figure 4 shows the initial INVITE request sent by Alice to Alice's proxy. The initial INVITE request contains an SDP offer.
图4显示了Alice向Alice的代理发送的初始INVITE请求。初始INVITE请求包含SDP报价。
The "m=" line in the SDP offer indicates T.38 fax using UDPTL over DTLS.
SDP报价中的“m=”行表示通过DTL使用UDPTL的T.38传真。
The SDP "setup" attribute with a value of "actpass" in the SDP offer indicates that Alice has requested to be either the active or passive endpoint.
SDP提供中值为“actpass”的SDP“setup”属性表示Alice已请求成为主动或被动端点。
The SDP "fingerprint" attribute in the SDP offer contains the certificate fingerprint computed from Alice's self-signed certificate.
SDP提供中的SDP“指纹”属性包含根据Alice的自签名证书计算的证书指纹。
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=-
c=IN IP4 ua1.example.com
t=0 0
m=image 6056 UDP/TLS/UDPTL t38
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
a=T38FaxRateManagement:transferredTCF
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=-
c=IN IP4 ua1.example.com
t=0 0
m=image 6056 UDP/TLS/UDPTL t38
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
a=T38FaxRateManagement:transferredTCF
Figure 4: Message (1)
图4：消息（1）
Message (2):
信息（2）：
Figure 5 shows the SIP INVITE request sent by Bob's proxy to Bob.
图5显示了Bob的代理向Bob发送的SIP INVITE请求。
When received, Bob verifies the identity provided in the SIP INVITE request.
收到后，Bob验证SIP INVITE请求中提供的标识。
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
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
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=-
c=IN IP4 ua1.example.com
t=0 0
m=image 6056 UDP/TLS/UDPTL t38
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
a=T38FaxRateManagement:transferredTCF
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=-
c=IN IP4 ua1.example.com
t=0 0
m=image 6056 UDP/TLS/UDPTL t38
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
a=T38FaxRateManagement:transferredTCF
Figure 5: Message (2)
图5：消息（2）
Message (3):
信息（3）：
Assuming that Alice's identity is valid, Bob sends a DTLS ClientHello directly to Alice.
假设Alice的身份有效，Bob直接向Alice发送DTLS ClientHello。
Message (4):
信息（4）：
Alice and Bob exchange further messages of DTLS handshake (HelloVerifyRequest, ClientHello, ServerHello, Certificate, ServerKeyExchange, CertificateRequest, ServerHelloDone, Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, and Finished).
Alice和Bob进一步交换DTLS握手消息（HelloVerifyRequest、ClientHello、ServerHello、Certificate、ServerKeyExchange、CertificateRequest、ServerHelloDone、Certificate、ClientKeyExchange、CertificateVerify、ChangeCipherSpec和Finished）。
When Bob receives the certificate of Alice via DTLS, Bob checks whether the certificate fingerprint calculated from Alice's certificate received via DTLS matches the certificate fingerprint received in the a=fingerprint SDP attribute of Figure 5. In this message flow, the check is successful; thus, session setup continues.
当Bob通过DTLS接收Alice证书时，Bob检查从Alice通过DTLS接收的证书计算出的证书指纹是否与图5的a=fingerprint SDP属性中接收的证书指纹匹配。在此消息流中，检查成功；因此，会话设置将继续。
Note that, unlike in this example, it is not necessary to wait for the DTLS handshake to finish before the SDP answer is sent. If Bob has sent the SIP 200 (OK) response and later detects that the certificate fingerprints do not match, he will terminate the session.
请注意，与本例不同，在发送SDP应答之前，无需等待DTLS握手完成。如果Bob发送了SIP 200（OK）响应，并且稍后检测到证书指纹不匹配，他将终止会话。
Message (5):
信息（5）：
Figure 6 shows a SIP 200 (OK) response to the initial SIP INVITE request, sent by Bob to Bob's proxy. The SIP 200 (OK) response contains an SDP answer.
图6显示了对初始SIP INVITE请求的SIP 200（OK）响应，该请求由Bob发送到Bob的代理。SIP 200（OK）响应包含SDP应答。
The "m=" line in the SDP answer indicates T.38 fax using UDPTL over DTLS.
SDP答案中的“m=”行表示通过DTL使用UDPTL的T.38传真。
The SDP "setup" attribute with a value of "active" in the SDP answer indicates that Bob has requested to be the active endpoint.
SDP应答中值为“active”的SDP“setup”属性表示Bob已请求成为活动端点。
The SDP "fingerprint" attribute in the SDP answer contains the certificate fingerprint computed from Bob's self-signed certificate.
SDP应答中的SDP“指纹”属性包含根据Bob的自签名证书计算的证书指纹。
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=- 8965454521 2105372818 IN IP4 ua2.example.com
s=-
c=IN IP4 ua2.example.com
t=0 0
m=image 12000 UDP/TLS/UDPTL t38
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
a=T38FaxRateManagement:transferredTCF
v=0
o=- 8965454521 2105372818 IN IP4 ua2.example.com
s=-
c=IN IP4 ua2.example.com
t=0 0
m=image 12000 UDP/TLS/UDPTL t38
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
a=T38FaxRateManagement:transferredTCF
Figure 6: Message (5)
图6：消息（5）
Message (6):
信息（6）：
Figure 7 shows a SIP 200 (OK) response to the initial SIP INVITE request, sent by Alice's proxy to Alice. Alice checks if the certificate fingerprint calculated from the Bob's certificate received via DTLS is the same as the certificate fingerprint received in the a=fingerprint SDP attribute of Figure 7. In this message flow, the check is successful; thus, the session setup continues.
图7显示了对初始SIP INVITE请求的SIP 200（OK）响应，该请求由Alice的代理发送给Alice。Alice检查通过DTLS接收的Bob证书计算出的证书指纹是否与图7的a=fingerprint SDP属性中接收到的证书指纹相同。在此消息流中，检查成功；因此，会话设置将继续。
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 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 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=- 8965454521 2105372818 IN IP4 ua2.example.com
s=-
c=IN IP4 ua2.example.com
t=0 0
m=image 12000 UDP/TLS/UDPTL t38
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
a=T38FaxRateManagement:transferredTCF
v=0
o=- 8965454521 2105372818 IN IP4 ua2.example.com
s=-
c=IN IP4 ua2.example.com
t=0 0
m=image 12000 UDP/TLS/UDPTL t38
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
a=T38FaxRateManagement:transferredTCF
Figure 7: Message (6)
图7：消息（6）
Message (7):
信息（7）：
Alice sends the SIP ACK request to Bob.
Alice向Bob发送SIP ACK请求。
Message (8):
信息（8）：
At this point, Bob and Alice can exchange T.38 fax securely transported using UDPTL over DTLS.
此时，Bob和Alice可以通过DTL使用UDPTL安全地交换T.38传真。
A.3. Message Flow of T.38 Fax Replacing Audio Media Stream in an Existing Audio-Only Session
A.3. T.38传真的消息流替换现有纯音频会话中的音频媒体流
Traditionally, most sessions with non-secure transport of T.38 fax, transported using UDPTL, are established by modifying an ongoing audio session into a fax session. Figure 8 shows an example message flow of modifying an existing audio session into a session with T.38 fax securely transported using UDPTL over DTLS.
Traditionally, most sessions with non-secure transport of T.38 fax, transported using UDPTL, are established by modifying an ongoing audio session into a fax session. Figure 8 shows an example message flow of modifying an existing audio session into a session with T.38 fax securely transported using UDPTL over DTLS.translate error, please retry
In this example flow, Alice acts as the passive endpoint of the DTLS association, and Bob acts as the active endpoint of the DTLS association.
在这个示例流中，Alice充当DTLS关联的被动端点，Bob充当DTLS关联的主动端点。
Alice Proxies Bob
| | |
| (1) Audio-only session initiation |
|<-----------------------+----------------------->|
| | |
| (2) SIP re-INVITE | |
|------------------------------------------------>|
| | (3) DTLS ClientHello |
|<------------------------------------------------|
| (4) remaining messages of DTLS handshake |
|<----------------------------------------------->|
| | |
| | |
| | (5) SIP 200 OK |
|<------------------------------------------------|
| (6) SIP ACK | |
|------------------------------------------------>|
| (7) T.38 message using UDPTL over DTLS |
|<----------------------------------------------->|
| | |
Alice Proxies Bob
| | |
| (1) Audio-only session initiation |
|<-----------------------+----------------------->|
| | |
| (2) SIP re-INVITE | |
|------------------------------------------------>|
| | (3) DTLS ClientHello |
|<------------------------------------------------|
| (4) remaining messages of DTLS handshake |
|<----------------------------------------------->|
| | |
| | |
| | (5) SIP 200 OK |
|<------------------------------------------------|
| (6) SIP ACK | |
|------------------------------------------------>|
| (7) T.38 message using UDPTL over DTLS |
|<----------------------------------------------->|
| | |
Figure 8: Message Flow of T.38 Fax Replacing Audio Media Stream in an Existing Audio-Only Session
图8:T.38传真在现有纯音频会话中替换音频媒体流的消息流
Message (1):
信息（1）：
Session establishment of audio-only session. The proxies decide not to record-route.
仅音频会话的会话建立。代理决定不记录路由。
Message (2):
信息（2）：
Alice sends SIP re-INVITE request. The SDP offer included in the SIP re-INVITE request is shown in Figure 9.
Alice发送SIP重新邀请请求。SIP重新邀请请求中包含的SDP提供如图9所示。
The first "m=" line in the SDP offer indicates audio media stream being removed. The second "m=" line in the SDP offer indicates T.38 fax using UDPTL over DTLS being added.
SDP优惠中的第一行“m=”表示正在删除音频媒体流。SDP报价中的第二行“m=”表示正在添加使用UDPTL over DTL的T.38传真。
The SDP "setup" attribute with a value of "actpass" in the SDP offer indicates that Alice has requested to be either the active or passive endpoint.
SDP提供中值为“actpass”的SDP“setup”属性表示Alice已请求成为主动或被动端点。
The SDP "fingerprint" attribute in the SDP offer contains the certificate fingerprint computed from Alice's self-signed certificate.
SDP提供中的SDP“指纹”属性包含根据Alice的自签名证书计算的证书指纹。
v=0
o=- 2465353433 3524244442 IN IP4 ua1.example.com
s=-
c=IN IP4 ua1.example.com
t=0 0
m=audio 0 UDP/TLS/RTP/SAVP 0
m=image 46056 UDP/TLS/UDPTL t38
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
a=T38FaxRateManagement:transferredTCF
v=0
o=- 2465353433 3524244442 IN IP4 ua1.example.com
s=-
c=IN IP4 ua1.example.com
t=0 0
m=audio 0 UDP/TLS/RTP/SAVP 0
m=image 46056 UDP/TLS/UDPTL t38
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
a=T38FaxRateManagement:transferredTCF
Figure 9: SDP Offer of Message (2)
图9:SDP提供的消息（2）
Message (3):
信息（3）：
Bob sends a DTLS ClientHello directly to Alice.
Bob直接向Alice发送DTLS ClientHello。
Message (4):
信息（4）：
Alice and Bob exchange further messages of DTLS handshake (HelloVerifyRequest, ClientHello, ServerHello, Certificate, ServerKeyExchange, CertificateRequest, ServerHelloDone, Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, and Finished).
Alice和Bob进一步交换DTLS握手消息（HelloVerifyRequest、ClientHello、ServerHello、Certificate、ServerKeyExchange、CertificateRequest、ServerHelloDone、Certificate、ClientKeyExchange、CertificateVerify、ChangeCipherSpec和Finished）。
When Bob receives the certificate of Alice via DTLS, Bob checks whether the certificate fingerprint calculated from Alice's certificate received via DTLS matches the certificate fingerprint received in the SDP "fingerprint" attribute of Figure 9. In this message flow, the check is successful; thus, session setup continues.
当Bob通过DTLS接收Alice证书时，Bob检查从Alice通过DTLS接收的证书计算出的证书指纹是否与图9的SDP“指纹”属性中接收的证书指纹匹配。在此消息流中，检查成功；因此，会话设置将继续。
Message (5):
信息（5）：
Bob sends a SIP 200 (OK) response to the SIP re-INVITE request. The SIP 200 (OK) response contains an SDP answer shown in Figure 10.
Bob向SIP重新邀请请求发送SIP 200（OK）响应。SIP200（OK）响应包含一个SDP应答，如图10所示。
The first "m=" line in the SDP offer indicates audio media stream being removed. The second "m=" line in the SDP answer indicates T.38 fax using UDPTL over DTLS being added.
SDP优惠中的第一行“m=”表示正在删除音频媒体流。SDP答案中的第二行“m=”表示正在添加使用UDPTL over DTL的T.38传真。
The SDP "setup" attribute with a value of "active" in the SDP answer indicates that Bob has requested to be the active endpoint.
SDP应答中值为“active”的SDP“setup”属性表示Bob已请求成为活动端点。
The SDP "fingerprint" attribute in the SDP answer contains the certificate fingerprint computed from Bob's self-signed certificate.
SDP应答中的SDP“指纹”属性包含根据Bob的自签名证书计算的证书指纹。
v=0
o=- 4423478999 5424222292 IN IP4 ua2.example.com
s=-
c=IN IP4 ua2.example.com
t=0 0
m=audio 0 UDP/TLS/RTP/SAVP 0
m=image 32000 UDP/TLS/UDPTL t38
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
a=T38FaxRateManagement:transferredTCF
v=0
o=- 4423478999 5424222292 IN IP4 ua2.example.com
s=-
c=IN IP4 ua2.example.com
t=0 0
m=audio 0 UDP/TLS/RTP/SAVP 0
m=image 32000 UDP/TLS/UDPTL t38
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
a=T38FaxRateManagement:transferredTCF
Figure 10: SDP Answer of Message (5)
图10：消息的SDP应答（5）
Message (6):
信息（6）：
Alice sends the SIP ACK request to Bob.
Alice向Bob发送SIP ACK请求。
Message (7):
信息（7）：
At this point, Bob and Alice can exchange T.38 fax securely transported using UDPTL over DTLS.
此时，Bob和Alice可以通过DTL使用UDPTL安全地交换T.38传真。
Authors' Addresses
作者地址
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: christer.holmberg@ericsson.com
EMail: christer.holmberg@ericsson.com
Ivo Sedlacek Ericsson Sokolovska 79 Praha 18600 Czech Republic
Ivo Sedlacek Ericsson Sokolovska 79普拉哈18600捷克共和国
EMail: ivo.sedlacek@ericsson.com
EMail: ivo.sedlacek@ericsson.com
Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Gonzalo Salgueiro Cisco Systems，Inc.美国北卡罗来纳州Kit Creek Road研究三角公园7200-12号，邮编27709
EMail: gsalguei@cisco.com
EMail: gsalguei@cisco.com