Internet Engineering Task Force (IETF) J. Goldberg
Request for Comments: 7825 Cisco
Category: Standards Track M. Westerlund
ISSN: 2070-1721 Ericsson
T. Zeng
Nextwave Wireless, Inc.
December 2016
Internet Engineering Task Force (IETF) J. Goldberg
Request for Comments: 7825 Cisco
Category: Standards Track M. Westerlund
ISSN: 2070-1721 Ericsson
T. Zeng
Nextwave Wireless, Inc.
December 2016
A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)
实时流协议（RTSP）控制的媒体网络地址转换器（NAT）遍历机制
Abstract
摘要
This document defines a solution for Network Address Translation (NAT) traversal for datagram-based media streams set up and controlled with the Real-Time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures.
本文档定义了一种网络地址转换（NAT）穿越解决方案，用于使用实时流协议版本2（RTSP 2.0）设置和控制基于数据报的媒体流。它使用了交互式连接建立（ICE），适用于将RTSP用作信令信道，定义了必要的RTSP扩展和过程。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7825.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7825.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Key Words .......................................................4
3. Solution Overview ...............................................4
4. RTSP Extensions .................................................6
4.1. ICE Transport Lower Layer ..................................6
4.2. ICE Candidate Transport Header Parameter ...................8
4.3. ICE Password and Username Transport Header Parameters .....11
4.4. ICE Feature Tag ...........................................11
4.5. Status Codes ..............................................12
4.5.1. 150 Server still working on ICE
connectivity checks ................................12
4.5.2. 480 ICE Connectivity check failure .................12
4.6. New Reason for PLAY_NOTIFY ................................12
4.7. Server-Side SDP Attribute for ICE Support .................13
5. ICE-RTSP .......................................................13
5.1. ICE Features Not Required .................................13
5.1.1. ICE-Lite ...........................................13
5.1.2. ICE-Mismatch .......................................13
5.1.3. ICE Remote Candidate Transport Header Parameter ....14
5.2. High-Reachability Configuration ...........................14
6. Detailed Solution ..............................................14
6.1. Session Description and RTSP DESCRIBE (Optional) ..........14
6.2. Setting Up the Media Streams ..............................15
6.3. RTSP SETUP Request ........................................16
6.4. Gathering Candidates ......................................16
6.5. RTSP Server Response ......................................17
6.6. Server-to-Client ICE Connectivity Checks ..................18
6.7. Client-to-Server ICE Connectivity Check ...................19
6.8. Client Connectivity Checks Complete .......................20
6.9. Server Connectivity Checks Complete .......................20
6.10. Freeing Candidates .......................................20
1. Introduction ....................................................3
2. Key Words .......................................................4
3. Solution Overview ...............................................4
4. RTSP Extensions .................................................6
4.1. ICE Transport Lower Layer ..................................6
4.2. ICE Candidate Transport Header Parameter ...................8
4.3. ICE Password and Username Transport Header Parameters .....11
4.4. ICE Feature Tag ...........................................11
4.5. Status Codes ..............................................12
4.5.1. 150 Server still working on ICE
connectivity checks ................................12
4.5.2. 480 ICE Connectivity check failure .................12
4.6. New Reason for PLAY_NOTIFY ................................12
4.7. Server-Side SDP Attribute for ICE Support .................13
5. ICE-RTSP .......................................................13
5.1. ICE Features Not Required .................................13
5.1.1. ICE-Lite ...........................................13
5.1.2. ICE-Mismatch .......................................13
5.1.3. ICE Remote Candidate Transport Header Parameter ....14
5.2. High-Reachability Configuration ...........................14
6. Detailed Solution ..............................................14
6.1. Session Description and RTSP DESCRIBE (Optional) ..........14
6.2. Setting Up the Media Streams ..............................15
6.3. RTSP SETUP Request ........................................16
6.4. Gathering Candidates ......................................16
6.5. RTSP Server Response ......................................17
6.6. Server-to-Client ICE Connectivity Checks ..................18
6.7. Client-to-Server ICE Connectivity Check ...................19
6.8. Client Connectivity Checks Complete .......................20
6.9. Server Connectivity Checks Complete .......................20
6.10. Freeing Candidates .......................................20
6.11. Steady State .............................................21
6.12. Re-SETUP .................................................21
6.13. Server-Side Changes after Steady State ...................22
7. ICE and Proxies ................................................24
7.1. Media-Handling Proxies ....................................24
7.2. Signaling-Only Proxies ....................................25
7.3. Non-supporting Proxies ....................................25
8. RTP and RTCP Multiplexing ......................................26
9. Fallback and Using Partial ICE Functionality to Improve
NAT/Firewall Traversal .........................................27
10. IANA Considerations ...........................................28
10.1. RTSP Feature Tags ........................................28
10.2. Transport Protocol Identifiers ...........................28
10.3. RTSP Transport Parameters ................................29
10.4. RTSP Status Codes ........................................29
10.5. Notify-Reason Value ......................................29
10.6. SDP Attribute ............................................29
11. Security Considerations .......................................30
11.1. ICE and RTSP .............................................30
11.2. Logging ..................................................30
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Acknowledgments ...................................................33
Authors' Addresses ................................................33
6.11. Steady State .............................................21
6.12. Re-SETUP .................................................21
6.13. Server-Side Changes after Steady State ...................22
7. ICE and Proxies ................................................24
7.1. Media-Handling Proxies ....................................24
7.2. Signaling-Only Proxies ....................................25
7.3. Non-supporting Proxies ....................................25
8. RTP and RTCP Multiplexing ......................................26
9. Fallback and Using Partial ICE Functionality to Improve
NAT/Firewall Traversal .........................................27
10. IANA Considerations ...........................................28
10.1. RTSP Feature Tags ........................................28
10.2. Transport Protocol Identifiers ...........................28
10.3. RTSP Transport Parameters ................................29
10.4. RTSP Status Codes ........................................29
10.5. Notify-Reason Value ......................................29
10.6. SDP Attribute ............................................29
11. Security Considerations .......................................30
11.1. ICE and RTSP .............................................30
11.2. Logging ..................................................30
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Acknowledgments ...................................................33
Authors' Addresses ................................................33
"Real Time Streaming Protocol (RTSP)" [RFC2326] and RTSP 2.0 [RFC7826] are protocols used to set up and control one or more media streams delivering media to receivers. It is RTSP's functionality of setting up media streams that causes serious issues with Network Address Translators (NATs) [RFC3022] unless extra provisions are made by the protocol. Thus, there is a need for a NAT traversal mechanism for the media setup using RTSP.
“实时流协议（RTSP）”[RFC2326]和RTSP 2.0[RFC7826]是用于设置和控制一个或多个向接收器传送媒体的媒体流的协议。RTSP设置媒体流的功能会导致网络地址转换器（NAT）[RFC3022]出现严重问题，除非协议另有规定。因此，对于使用RTSP的媒体设置，需要NAT遍历机制。
RTSP 1.0 [RFC2326] has suffered from the lack of a standardized NAT traversal mechanism for a long time; however, due to quality of the RTSP 1.0 specification, the work was difficult to specify in an interoperable fashion. This document is therefore built on the specification of RTSP 2.0 [RFC7826]. RTSP 2.0 is similar to RTSP 1.0 in many respects, but, significantly for this work, it contains a well-defined extension mechanism that allows a NAT traversal extension to be defined that is backwards compatible with RTSP 2.0 peers not supporting the extension. This extension mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0 syntax and cause compatibility issues.
RTSP 1.0[RFC2326]长期以来缺乏标准化的NAT穿越机制；然而，由于RTSP 1.0规范的质量，这项工作很难以可互操作的方式指定。因此，本文件以RTSP 2.0[RFC7826]规范为基础。RTSP 2.0在许多方面类似于RTSP 1.0，但对于这项工作来说，它包含一个定义良好的扩展机制，允许定义NAT遍历扩展，该扩展向后兼容不支持该扩展的RTSP 2.0对等方。这种扩展机制在RTSP 1.0中是不可能的，因为它会破坏RTSP 1.0语法并导致兼容性问题。
There have been a number of suggested ways of resolving the NAT traversal of media for RTSP, most of which are already used in implementations. The evaluation of these NAT-traversal solutions in [RFC7604] has shown that there are many issues to consider. After extensive evaluation, a mechanism based on Interactive Connectivity Establishment (ICE) [RFC5245] was selected. There were mainly two reasons: the mechanism supports RTSP servers behind NATs and the mechanism mitigates the security threat of using RTSP servers as Distributed Denial-of-Service (DDoS) attack tools.
有许多建议的方法可以解决RTSP介质的NAT遍历问题，其中大多数已经在实现中使用。在[RCF7604]中对这些NAT穿越解决方案的评估表明，有许多问题需要考虑。经过广泛评估，选择了一种基于交互式连接建立（ICE）[RFC5245]的机制。主要有两个原因：该机制支持NAT背后的RTSP服务器，以及该机制缓解了将RTSP服务器用作分布式拒绝服务（DDoS）攻击工具的安全威胁。
This document specifies an ICE-based solution that is optimized for media delivery from server to client. If future extensions are specified for other delivery modes than "PLAY", then the optimizations in regard to when PLAY requests are sent needs to be reconsidered.
本文档指定了一个基于ICE的解决方案，该解决方案针对从服务器到客户端的媒体交付进行了优化。如果为“播放”以外的其他交付模式指定了将来的扩展，则需要重新考虑关于何时发送播放请求的优化。
The NAT problem for RTSP signaling traffic is a less prevalent problem than the NAT problem for RTSP media streams. Consequently, the former is left for future study.
RTSP信令流量的NAT问题不如RTSP媒体流的NAT问题普遍。因此，前者留待将来研究。
The ICE usage defined in this specification is called "ICE-RTSP" and does not match the full ICE for SIP/SDP (Session Description Protocol) or ICE-Lite as defined in the ICE specification [RFC5245]. ICE-RTSP is tailored to the needs of RTSP and is slightly simpler than ICE-Full for both clients and servers.
本规范中定义的ICE用途称为“ICE-RTSP”，与ICE规范[RFC5245]中定义的SIP/SDP（会话描述协议）或ICE Lite的完整ICE不匹配。ICE-RTSP是根据RTSP的需要定制的，对于客户端和服务器来说，它比ICE Full稍微简单一些。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
This overview assumes that the reader has some familiarity with how ICE [RFC5245] in the context of "SIP: Session Initiation Protocol" [RFC3261] and "An Offer/Answer Model with the Session Description Protocol (SDP)" [RFC3264] works, as it primarily points out how the different ICE steps are accomplished in RTSP.
本概述假设读者对ICE[RFC5245]在“SIP:会话启动协议”[RFC3261]和“会话描述协议（SDP）的提供/应答模型”[RFC3264]的上下文中的工作方式有一定的了解，因为它主要指出了不同的ICE步骤是如何在RTSP中完成的。
1. The RTSP server should indicate it has support for ICE via a new SDP [RFC4566] attribute ("a=rtsp-ice-d-m") in, for example, the SDP returned in the RTSP DESCRIBE message. This allows RTSP clients to only perform the new ICE exchanges with servers that support ICE. If RTSP DESCRIBE is used, the normal capability determination mechanism should also be used, i.e., Supported
1. RTSP服务器应通过一个新的SDP[RFC4566]属性（“a=RTSP-ICE-d-m”）表明其支持ICE，例如，RTSP描述消息中返回的SDP。这允许RTSP客户端仅与支持ICE的服务器执行新的ICE交换。如果使用RTSP descripe，还应使用正常的能力确定机制，即支持
header with a new ICE feature tag. Note: both mechanisms should be supported, as there are various use cases where only one of them is used.
带有新ICE功能标签的标题。注意：这两种机制都应该得到支持，因为在不同的用例中，只有一种机制被使用。
2. The RTSP client reviews the session description returned, for example by an RTSP DESCRIBE message, to determine what media streams need to be set up. For each of these media streams where the transport protocol supports connectivity checks based on Session Traversal Utilities for (NAT) (STUN) [RFC5389], the client gathers candidate addresses. See Section 4.1.1 in ICE [RFC5245]. The client then runs a STUN server on each of the local candidate's transport addresses it has gathered.
2. RTSP客户端查看返回的会话描述（例如通过RTSP描述消息返回的会话描述），以确定需要设置哪些媒体流。对于传输协议支持基于（NAT）（STUN）[RFC5389]会话遍历实用程序的连接检查的每个媒体流，客户端收集候选地址。参见ICE[RFC5245]中的第4.1.1节。然后，客户端在收集到的每个本地候选传输地址上运行一个STUN服务器。
3. The RTSP client sends SETUP requests containing a transport specification with a lower layer indicating ICE and a new RTSP Transport header parameter "candidates" listing the ICE candidates for each media stream.
3. RTSP客户端发送包含传输规范的设置请求，较低的一层表示ICE，新的RTSP传输头参数“候选者”列出每个媒体流的ICE候选者。
4. After receiving the list of candidates from a client, the RTSP server gathers its own candidates. If the server is not behind a NAT, then a single candidate per address family (e.g., IPv4 and IPv6), media stream, and media component tuple can be included to reduce the number of combinations and speed up the completion.
4. 从客户端接收候选列表后，RTSP服务器收集自己的候选列表。如果服务器不在NAT后面，则可以包括每个地址系列（例如IPv4和IPv6）、媒体流和媒体组件元组的单个候选，以减少组合的数量并加快完成。
5. The server sets up the media and, if successful, responds to the SETUP request with a 200 OK response. In that response, the server selects the transport specification using ICE and includes its candidates in the candidates parameter.
5. 服务器设置媒体，如果成功，则以200 OK响应响应设置请求。在该响应中，服务器使用ICE选择传输规范，并将其候选者包括在候选者参数中。
6. The server starts the connectivity checks following the procedures described in Sections 5.7 and 5.8 of ICE [RFC5245]. If the server is not behind a NAT and uses a public IP address with a single candidate per (media stream, component, address family) tuple, then the server may be configured to not initiate connectivity checks.
6. 服务器按照ICE[RFC5245]第5.7节和第5.8节所述的程序启动连接检查。如果服务器不在NAT后面，并且使用公共IP地址，每个（媒体流、组件、地址系列）元组具有一个候选，则服务器可以被配置为不发起连接检查。
7. The client receives the SETUP response and learns the candidate addresses to use for the connectivity checks and then initiates its connectivity check, following the procedures in Section 6 of ICE [RFC5245].
7. 客户机接收设置响应，并学习用于连接检查的候选地址，然后按照ICE[RFC5245]第6节中的步骤启动其连接检查。
8. When a connectivity check from the client reaches the server, it will result in a triggered check from the server. This is why servers not behind a NAT can wait until this triggered check to send out any checks for itself, so saving resources and mitigating the DDoS potential from server-initiated connectivity checks.
8. 当客户端的连接检查到达服务器时，将导致服务器触发检查。这就是为什么不在NAT后面的服务器可以等到触发检查后再为自己发送任何检查，从而节省资源并降低服务器启动的连接检查可能带来的DDoS。
9. When the client has concluded its connectivity checks, including nominating candidates, and has correspondingly received the server connectivity checks on the nominated candidates for all mandatory components of all media streams, it can issue a PLAY request. If the connectivity checks have not concluded successfully, then the client may send a new SETUP request if it has any new information or believes the server may be able to do more that can result in successful checks.
9. 当客户端完成其连接检查（包括指定候选）并相应地收到所有媒体流的所有必需组件的指定候选上的服务器连接检查时，它可以发出播放请求。如果连接性检查未成功结束，则如果客户端有任何新信息或认为服务器可能能够执行更多操作，从而导致检查成功，则客户端可能会发送新的设置请求。
10. When the RTSP server receives a PLAY request, it checks to see that the connectivity checks have concluded successfully, and only then can it play the stream. If there is a problem with the checks, then the server sends either a 150 (Server still working on ICE connectivity checks) response to show that it is still working on the connectivity checks, or a 480 (ICE Connectivity check failure) response to indicate a failure of the checks. If the checks are successful, then the server sends a 200 OK response and starts delivering media.
10. 当RTSP服务器收到播放请求时，它会检查连接检查是否已成功结束，然后才能播放流。如果检查有问题，则服务器发送150（服务器仍在进行ICE连接检查）响应以表明其仍在进行连接检查，或发送480（ICE连接检查失败）响应以指示检查失败。如果检查成功，则服务器发送200 OK响应并开始传送介质。
The client and server may release unused candidates when the ICE processing has concluded, a single candidate per component has been nominated, and a PLAY response has been received (client) or sent (server).
当ICE处理结束时，客户机和服务器可以释放未使用的候选者，每个组件指定了一个候选者，并且接收到播放响应（客户机）或发送了播放响应（服务器）。
The client needs to continue to use STUN as a keep-alive mechanism for the used candidate pairs to keep their NAT bindings current. RTSP servers behind NATs will also need to send keep-alive messages when not sending media. This is important since RTSP media sessions often contain only media traffic from the server to the client so the bindings in the NAT need to be refreshed by client-to-server traffic provided by the STUN keep-alive.
客户端需要继续使用STUN作为所用候选对的保持活动机制，以保持其NAT绑定的最新状态。NAT后面的RTSP服务器在不发送媒体时也需要发送保持活动状态的消息。这一点很重要，因为RTSP媒体会话通常只包含从服务器到客户端的媒体流量，所以NAT中的绑定需要由STUN保持活动提供的客户端到服务器流量刷新。
This section defines the necessary RTSP extensions for performing ICE with RTSP. Note that these extensions are based on the SDP attributes in the ICE specification unless expressly indicated otherwise.
本节定义了使用RTSP执行ICE所需的RTSP扩展。请注意，除非另有明确说明，否则这些扩展基于ICE规范中的SDP属性。
A new lower layer "D-ICE" for transport specifications is defined. This lower layer is datagram clean except that the protocol used must be possible to demultiplex from STUN messages (see STUN [RFC5389]). By "datagram clean" we mean that it has to be capable of describing the length of the datagram, transport that datagram (as a binary chunk of data), and provide it at the receiving side as one single item. This lower layer can be any transport type defined for ICE
定义了用于运输规范的新下层“D-ICE”。除了所使用的协议必须能够从STUN消息中解复用外（参见STUN[RFC5389]），该下层是数据报干净的。“数据报清理”是指它必须能够描述数据报的长度，传输该数据报（作为二进制数据块），并在接收端作为单个项目提供。该下层可以是为冰定义的任何运输类型
that does provide datagram transport capabilities. UDP-based transport candidates are defined in ICE [RFC5245] and MUST be supported. It is OPTIONAL to also support TCP-based candidates as defined by "TCP Candidates with Interactive Connectivity Establishment (ICE)" [RFC6544]. The TCP-based candidate fulfills the requirements on providing datagram transport and can thus be used in combination with RTP. Additional transport types for candidates may be defined in the future.
这确实提供了数据报传输功能。ICE[RFC5245]中定义了基于UDP的传输候选者，必须支持该候选者。还可以选择支持“具有交互式连接建立（ICE）的TCP候选者”[RFC6544]定义的基于TCP的候选者。基于TCP的候选者满足提供数据报传输的要求，因此可以与RTP结合使用。将来可能会定义候选的其他传输类型。
This lower layer uses ICE to determine which of the different candidates shall be used and then, when the ICE processing has concluded, uses the selected candidate to transport the datagrams over this transport.
该较低层使用ICE来确定应使用哪些不同的候选者，然后，当ICE处理结束时，使用所选候选者通过该传输传输传输数据报。
This lower-layer transport can be combined with all upper-layer media transport protocols that are possible to demultiplex with STUN and that use datagrams. This specification defines the following combinations:
这种下层传输可以与所有上层媒体传输协议结合使用，上层媒体传输协议可以使用STUN解复用并使用数据报。本规范规定了以下组合：
o RTP/AVP/D-ICE
o RTP/AVP/D-ICE
o RTP/AVPF/D-ICE
o RTP/AVPF/D-ICE
o RTP/SAVP/D-ICE
o RTP/SAVP/D-ICE
o RTP/SAVPF/D-ICE
o RTP/SAVPF/D-ICE
This list can be extended with more transport specifications after having performed the evaluation that they are compatible with D-ICE as lower layer. The registration is required to follow the registry rules for the Transport Protocol Identifier (see Section 22.13.1 of [RFC7826]).
在执行了与D-ICE作为较低层兼容的评估后，该列表可以扩展为更多的运输规范。注册需要遵循传输协议标识符的注册规则（见[RFC7826]第22.13.1节）。
The lower-layer "D-ICE" has the following rules for the inclusion of the RTSP Transport header (Section 18.54 of RTSP 2.0 [RFC7826]) parameters:
下层“D-ICE”包含RTSP运输总管（RTSP 2.0[RFC7826]第18.54节）参数的规则如下：
unicast: ICE only supports unicast operations; thus, it is REQUIRED that one include the unicast indicator parameter (see Section 18.54 in RTSP 2.0 [RFC7826]).
单播：ICE仅支持单播操作；因此，需要包括单播指示符参数（参见RTSP 2.0[RFC7826]中的第18.54节）。
candidates: The "candidates" parameter SHALL be included as it specifies at least one candidate with which to try to establish a working transport path.
候选项：“候选项”参数应包括在内，因为它指定了至少一个候选项，用于尝试建立工作传输路径。
dest_addr: This parameter MUST NOT be included since "candidates" is used instead to provide the necessary address information.
dest_addr：不得包含此参数，因为“候选者”用于提供必要的地址信息。
ICE-Password: This parameter SHALL be included (see Section 4.2).
ICE密码：应包括该参数（见第4.2节）。
ICE-ufrag: This parameter SHALL be included (see Section 4.2).
ICE ufrag：应包括该参数（见第4.2节）。
This section defines a new RTSP transport parameter for carrying ICE candidates related to the transport specification they appear within, which may then be validated with an end-to-end connectivity check using STUN [RFC5389]. Transport parameters may only occur once in each transport specification. For transport specifications using "D-ICE" as lower layer, this parameter MUST be present. The parameter can contain one or more ICE candidates. In the SETUP response, there is only a single transport specification; if that uses the "D-ICE" lower layer, this parameter MUST be present and include the server-side candidates.
本节定义了一个新的RTSP传输参数，用于承载与其出现在其中的传输规范相关的ICE候选者，然后可使用STUN[RFC5389]通过端到端连接检查对其进行验证。传输参数在每个传输规范中只能出现一次。对于使用“D-ICE”作为下层的运输规范，必须存在此参数。该参数可以包含一个或多个候选ICE。在设置响应中，只有一个传输规范；如果使用“D-ICE”较低层，则此参数必须存在，并包括服务器端候选者。
The ABNF [RFC5234] for these transport header parameters are:
这些传输头参数的ABNF[RFC5234]为：
trns-parameter = <Defined in Section 20.2.3 of [RFC7826]>
trns-parameter =/ SEMI ice-trn-par
ice-trn-par = "candidates" EQUAL DQUOTE SWS ice-candidate
*(SEMI ice-candidate) SWS DQUOTE
ice-candidate = foundation SP
component-id SP
transport SP
priority SP
connection-address SP
port SP
cand-type
[SP rel-addr]
[SP rel-port]
[SP tcp-type-ext] ; Mandatory if transport = TCP
*(SP extension-att-name SP extension-att-value)
trns-parameter = <Defined in Section 20.2.3 of [RFC7826]>
trns-parameter =/ SEMI ice-trn-par
ice-trn-par = "candidates" EQUAL DQUOTE SWS ice-candidate
*(SEMI ice-candidate) SWS DQUOTE
ice-candidate = foundation SP
component-id SP
transport SP
priority SP
connection-address SP
port SP
cand-type
[SP rel-addr]
[SP rel-port]
[SP tcp-type-ext] ; Mandatory if transport = TCP
*(SP extension-att-name SP extension-att-value)
foundation = <See Section 15.1 of [RFC5245]>
component-id = <See Section 15.1 of [RFC5245]>
transport = <See Section 15.1 of [RFC5245]>
priority = <See Section 15.1 of [RFC5245]>
cand-type = <See Section 15.1 of [RFC5245]>
rel-addr = <See Section 15.1 of [RFC5245]>
rel-port = <See Section 15.1 of [RFC5245]>
tcp-type-ext = <See Section 4.5 of [RFC6544]>
extension-att-name = <See Section 15.1 of [RFC5245]>
extension-att-value = <See Section 15.1 of [RFC5245]>
connection-address = <See [RFC4566]>
port = <See [RFC4566]>
EQUAL = <Defined in [RFC7826]>
foundation = <See Section 15.1 of [RFC5245]>
component-id = <See Section 15.1 of [RFC5245]>
transport = <See Section 15.1 of [RFC5245]>
priority = <See Section 15.1 of [RFC5245]>
cand-type = <See Section 15.1 of [RFC5245]>
rel-addr = <See Section 15.1 of [RFC5245]>
rel-port = <See Section 15.1 of [RFC5245]>
tcp-type-ext = <See Section 4.5 of [RFC6544]>
extension-att-name = <See Section 15.1 of [RFC5245]>
extension-att-value = <See Section 15.1 of [RFC5245]>
connection-address = <See [RFC4566]>
port = <See [RFC4566]>
EQUAL = <Defined in [RFC7826]>
DQUOTE = <Defined in [RFC7826]>
SWS = <Defined in [RFC7826]>
SEMI = <Defined in [RFC7826]>
SP = <Defined in [RFC7826]>
DQUOTE = <Defined in [RFC7826]>
SWS = <Defined in [RFC7826]>
SEMI = <Defined in [RFC7826]>
SP = <Defined in [RFC7826]>
<connection-address>: is the unicast IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and Fully Qualified Domain Names (FQDNs), taken from SDP [RFC4566]. Note, this context MUST have a unicast address for this parameter, even though a multicast address would be syntactically valid. The connection address SHOULD use the same format (explicit IP or FQDN) as in the dest_addr parameter used in the transport specification that express any fallback. An IP address is preferred for simplicity, but both an IP Address and FQDN can be used. In the FQDN case, when receiving a SETUP request or response containing an FQDN in an ice-candidate parameter, the FQDN is looked up in the DNS first using a AAAA record (assuming the agent supports IPv6), and if no result is found or the agent only supports IPv4, using an A record. If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing, which in RTSP is subsequent RTSP SETUPs for the same RTSP session.
<connection address>：候选的单播IP地址，允许IPv4地址、IPv6地址和完全限定域名（FQDN），取自SDP[RFC4566]。注意，此上下文必须具有此参数的单播地址，即使多播地址在语法上是有效的。连接地址应使用与传输规范中表示任何回退的dest_addr参数中相同的格式（显式IP或FQDN）。为了简单起见，最好使用IP地址，但可以同时使用IP地址和FQDN。在FQDN情况下，当接收到在ice候选参数中包含FQDN的设置请求或响应时，首先使用AAAA记录（假设代理支持IPv6）在DNS中查找FQDN，如果未找到结果或代理仅支持IPv4，则使用a记录。如果DNS查询返回多个IP地址，则选择一个，然后用于ICE处理的其余部分，在RTSP中，这是同一RTSP会话的后续RTSP设置。
<port>: is the port of the candidate; the syntax is defined by SDP [RFC4566].
<port>：是候选端口；语法由SDP[RFC4566]定义。
<transport>: indicates the transport protocol for the candidate. The ICE specification defines UDP. "TCP Candidates with Interactive Connectivity Establishment (ICE)" [RFC6544] defines how TCP is used as candidates. Additional extensibility is provided to allow for future transport protocols to be used with ICE, such as the Datagram Congestion Control Protocol (DCCP) [RFC4340].
<transport>：表示候选的传输协议。ICE规范定义了UDP。“具有交互式连接建立（ICE）的TCP候选者”[RFC6544]定义了如何将TCP用作候选者。提供了额外的扩展性，以允许将来的传输协议与ICE一起使用，例如数据报拥塞控制协议（DCCP）[RFC4340]。
<foundation>: is an identifier that is equivalent for two candidates that are of the same type, share the same base IP address, and come from the same STUN server. It is composed of one to thirty two <ice-char>. The foundation is used to optimize ICE performance in the Frozen algorithm (as described in [RFC5245]).
<foundation>：是一个标识符，相当于两个具有相同类型、共享相同基本IP地址且来自同一STUN服务器的候选服务器。它由一到三十二个<ice char>组成。该基础用于优化冻结算法中的冰性能（如在[RCF5245]中描述的）。
<component-id>: identifies the specific component of the media stream for which this is a candidate and is a positive integer belonging to the range 1-256. It MUST start at 1 and MUST increment by 1 for each component of a particular media stream. For media streams based on RTP, candidates for the actual RTP media MUST have a component ID of 1, and candidates for RTCP MUST have a component ID of 2 unless RTP and RTCP Multiplexing
<component id>：标识媒体流的特定组件，该组件是其候选组件，并且是属于范围1-256的正整数。它必须从1开始，并且对于特定媒体流的每个组件必须增加1。对于基于RTP的媒体流，实际RTP媒体的候选组件ID必须为1，RTCP的候选组件ID必须为2，除非RTP和RTCP多路复用
(Section 8) is used, in which case the second component is omitted and RTP and RTCP are both transported over the first component. Other types of media streams that require multiple components MUST develop specifications that define the mapping of components to component IDs. See Section 14 in [RFC5245] for additional discussion on extending ICE to new media streams.
（第8节），在这种情况下，省略第二个组件，RTP和RTCP都通过第一个组件传输。需要多个组件的其他类型的媒体流必须制定规范，定义组件到组件ID的映射。有关将ICE扩展到新媒体流的更多讨论，请参见[RFC5245]中的第14节。
<priority>: is a positive integer in the range 1 to (2**31 - 1).
<priority>：是介于1到（2**31-1）之间的正整数。
<cand-type>: encodes the type of candidate. The ICE specification defines the values "host", "srflx", "prflx", and "relay" for host, server-reflexive, peer-reflexive, and relayed candidates, respectively. The set of candidate types is extensible for the future.
<cand type>：对候选类型进行编码。ICE规范分别为主机、服务器自反、对等自反和中继候选定义了值“主机”、“srflx”、“prflx”和“中继”。候选类型集在将来是可扩展的。
<rel-addr> and <rel-port>: convey transport addresses related to the candidate, useful for diagnostics and other purposes. <rel-addr> and <rel-port> MUST be present for server-reflexive, peer-reflexive, and relayed candidates. If a candidate is server- or peer-reflexive, <rel-addr> and <rel-port> are equal to the base for that server- or peer-reflexive candidate. If the candidate is relayed, <rel-addr> and <rel-port> are equal to the mapped address in the TURN Allocate Response that provided the client with that relayed candidate (see Appendix B.3 of ICE [RFC5245] for a discussion of its purpose). If the candidate is a host candidate, <rel-addr> and <rel-port> MUST be omitted.
<rel addr>和<rel port>：传送与候选者相关的传输地址，用于诊断和其他目的<对于服务器自反、对等自反和中继候选，必须存在rel addr>和<rel port>。如果候选者是服务器或对等自反候选者，<rel addr>和<rel port>等于该服务器或对等自反候选者的基数。如果中继了候选项，<rel addr>和<rel port>等于向客户机提供该中继候选项的轮分配响应中的映射地址（有关其用途的讨论，请参阅ICE[RFC5245]的附录B.3）。如果候选者是主机候选者，则必须省略<rel addr>和<rel port>。
<tcp-type-ext>: conveys the candidate's connection type (active, passive, or simultaneous-open (S-O)) for TCP-based candidates. This MUST be included for candidates that have <transport> set to TCP and MUST NOT be included for other transport types, including UDP.
<tcp type ext>：为基于tcp的候选者传送候选者的连接类型（主动、被动或同时打开（s-O））。对于<传输>设置为TCP的候选者，必须包含此选项，而对于其他传输类型，包括UDP，则不得包含此选项。
<extension-att-name> and <extension-att-value>: These are prototypes for future extensions of the candidate line. The ABNF for these allows any 8-bit value except NUL, CR, or LF. However, the extensions will occur within a structured line that uses the DQUOTE, SEMI, SWS, and SP ABNF constructs as delimiters; thus, those delimiter characters MUST be escaped if they would occur within an extension-att-name or extension-att-value. The escape mechanism that MUST be used is the Percent-Encoding defined in Section 2.1 of [RFC3986]. This mechanism is selected as it needs to be supported in an RTSP implementation to deal with URIs anyway. The byte values (in hex) that MUST be escaped are the following: 0x09, 0x20, 0x22, 0x25, and 0x3B.
<extension att name>和<extension att value>：这些是候选线未来扩展的原型。ABNF允许除NUL、CR或LF之外的任何8位值。但是，扩展将出现在使用DQUOTE、SEMI、SWS和SP ABNF构造作为分隔符的结构化行中；因此，如果这些分隔符字符出现在扩展att名称或扩展att值中，则必须对其进行转义。必须使用的逃逸机制是[RFC3986]第2.1节中定义的百分比编码。选择此机制是因为RTSP实现中需要支持它才能处理URI。必须转义的字节值（十六进制）如下：0x09、0x20、0x22、0x25和0x3B。
The ICE password and username for each agent need to be transported using RTSP. For that purpose, new Transport header parameters are defined (see Section 18.54 of [RFC7826].
需要使用RTSP传输每个代理的ICE密码和用户名。为此，定义了新的传输头参数（见[RFC7826]第18.54节）。
There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each media stream. The ICE-ufrag and ICE-Password parameter values MUST be chosen randomly at the beginning of a session. The ICE-ufrag value MUST contain at least 24 bits of randomness, and the ICE-Password value MUST contain at least 128 bits of randomness. This means that the ICE-ufrag value will be at least 4 characters long, and the ICE-Password value at least 22 characters long, since the grammar for these attributes allows for 6 bits of randomness per character. The values MAY be longer than 4 and 22 characters respectively, of course, up to 256 characters. The upper limit allows for buffer sizing in implementations. Its large upper limit allows for increased amounts of randomness to be added over time.
每个媒体流必须有一个“ICE密码”和“ICE ufrag”参数。ICE ufrag和ICE Password参数值必须在会话开始时随机选择。ICE ufrag值必须包含至少24位随机性，ICE密码值必须包含至少128位随机性。这意味着ICE ufrag值至少有4个字符长，ICE密码值至少有22个字符长，因为这些属性的语法允许每个字符有6位随机性。值可能分别长于4个字符和22个字符，当然，最多可达256个字符。上限允许在实现中调整缓冲区大小。其较大的上限允许随时间增加随机性。
The ABNF [RFC5234] for these parameters is:
这些参数的ABNF[RFC5234]为：
trns-parameter =/ SEMI ice-password-par
trns-parameter =/ SEMI ice-ufrag-par
ice-password-par = "ICE-Password" EQUAL DQUOTE password DQUOTE
ice-ufrag-par = "ICE-ufrag" EQUAL DQUOTE ufrag DQUOTE
password = <Defined in [RFC5245], Section 15.4>
ufrag = <Defined in [RFC5245], Section 15.4>
EQUAL = <Defined in [RFC7826]>
SEMI = <Defined in [RFC7826]>
DQUOTE = <Defined in [RFC7826]>
trns-parameter =/ SEMI ice-password-par
trns-parameter =/ SEMI ice-ufrag-par
ice-password-par = "ICE-Password" EQUAL DQUOTE password DQUOTE
ice-ufrag-par = "ICE-ufrag" EQUAL DQUOTE ufrag DQUOTE
password = <Defined in [RFC5245], Section 15.4>
ufrag = <Defined in [RFC5245], Section 15.4>
EQUAL = <Defined in [RFC7826]>
SEMI = <Defined in [RFC7826]>
DQUOTE = <Defined in [RFC7826]>
A feature tag is defined for use in the RTSP capabilities mechanism for ICE support of media transport using datagrams: "setup.ice-d-m". This feature tag indicates that one supports all the mandatory functions of this specification. It is applicable to all types of RTSP agents: clients, servers, and proxies.
在RTSP功能机制中定义了一个功能标签，用于ICE支持使用数据报的媒体传输：“setup.ICE-d-m”。此功能标签表示支持本规范的所有必需功能。它适用于所有类型的RTSP代理：客户端、服务器和代理。
The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the Supported header in all SETUP requests that contain the "D-ICE" lower-layer transport. Note, this is not a "MUST" as an RTSP client can always attempt to perform a SETUP using ICE to see if it functions or fails. However, including the feature tag in the Supported header ensures that proxies supporting this specification explicitly indicate such support; see Section 7.
RTSP客户端应在包含“d-ice”下层传输的所有设置请求中，在支持的标头中发送功能标签“setup.ice-d-m”。注意，这不是“必须”的，因为RTSP客户端总是可以尝试使用ICE执行设置，以查看它是否正常工作或失败。但是，在受支持的标头中包含特性标记可确保支持此规范的代理明确指示此类支持；见第7节。
For ICE, there are two new RTSP response codes to indicate progress and errors.
对于ICE，有两个新的RTSP响应代码来指示进度和错误。
+------+----------------------------------------------+-------------+
| Code | Description | Method |
+------+----------------------------------------------+-------------+
| 150 | Server still working on ICE connectivity | PLAY |
| | checks | |
| | | |
| 480 | ICE Connectivity check failure | PLAY, SETUP |
+------+----------------------------------------------+-------------+
+------+----------------------------------------------+-------------+
| Code | Description | Method |
+------+----------------------------------------------+-------------+
| 150 | Server still working on ICE connectivity | PLAY |
| | checks | |
| | | |
| 480 | ICE Connectivity check failure | PLAY, SETUP |
+------+----------------------------------------------+-------------+
Table 1: New Status Codes and Their Usage with RTSP Methods
表1：新状态代码及其与RTSP方法的使用
The 150 response code indicates that ICE connectivity checks are still in progress and haven't concluded. This response SHALL be sent within 200 milliseconds of receiving a PLAY request that currently can't be fulfilled because ICE connectivity checks are still running. A client can expect network delays between the server and client resulting in a response longer than 200 milliseconds. Subsequently, every 3 seconds after the previous one was sent, a 150 reply SHALL be sent until the ICE connectivity checks conclude either successfully or in failure, and a final response for the request can be provided.
150响应代码表明ICE连接检查仍在进行中，尚未结束。该响应应在收到播放请求后200毫秒内发送，该请求当前无法完成，因为ICE连接检查仍在运行。客户端可以预期服务器和客户端之间的网络延迟会导致响应时间超过200毫秒。随后，在发送前一个应答后，每隔3秒应发送150个应答，直到ICE连接检查成功或失败结束，并可提供请求的最终响应。
The 480 client error response code is used in cases when the request can't be fulfilled due to a failure in the ICE processing, such as all the connectivity checks have timed out. This error message can appear either in response to a SETUP request to indicate that no candidate pair can be constructed or in response to a PLAY request to indicate that the server's connectivity checks resulted in failure.
480客户端错误响应代码用于因ICE处理失败而无法满足请求的情况，例如所有连接检查已超时。此错误消息可能出现在响应设置请求时，表示无法构造候选对，也可能出现在响应播放请求时，表示服务器的连接检查导致失败。
A new value used in the PLAY_NOTIFY methods Notify-Reason header is defined: "ice-restart". This reason indicates that an ICE restart needs to happen on the identified resource and session.
定义了PLAY_NOTIFY methods NOTIFY Reason标头中使用的新值：“ice重启”。此原因表示需要在已标识的资源和会话上重新启动ICE。
Notify-Reas-val =/ "ice-restart"
通知Reas val=/“ice重启”
If the server supports the media NAT traversal for RTSP-controlled sessions as described in this RFC, then the server SHOULD include the "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing content served by the server. This is a session-level-only attribute; see [RFC4566].
如果服务器支持本RFC中所述的RTSP控制会话的媒体NAT遍历，则服务器应在描述服务器所服务内容的任何SDP（如果使用）中包含“a=RTSP-ice-d-m”SDP属性。这是仅会话级别的属性；见[RFC4566]。
The ABNF [RFC5234] for the "rtsp-ice-d-m" attribute is:
“rtsp-ice-d-m”属性的ABNF[RFC5234]为：
rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m"
rtsp-ice-d-m-attr=“a=”“rtsp-ice-d-m”
This section discusses differences between the regular ICE usage defined in [RFC5245] and ICE-RTSP. The reasons for the differences relate to the clearer client/server roles that RTSP provides and how the RTSP session establishment signaling occurs within RTSP compared to SIP/SDP offer/answer.
本节讨论[RFC5245]中定义的常规ICE使用与ICE-RTSP之间的差异。产生差异的原因与RTSP提供的更清晰的客户端/服务器角色有关，与SIP/SDP提供/应答相比，RTSP会话建立信令是如何在RTSP中发生的。
A number of ICE signaling features are not needed with RTSP and are discussed below.
RTSP不需要许多ICE信号功能，下文将对此进行讨论。
The ICE-Lite attribute SHALL NOT be used in the context of RTSP. The ICE specification describes two implementations of ICE: Full and Lite, where hosts that are not behind a NAT are allowed to implement only Lite. For RTSP, the Lite implementation is insufficient because it does not cause the media server to send a connectivity check, which is used to protect against making the RTSP server a denial-of-service tool.
ICE Lite属性不得用于RTSP环境中。ICE规范描述了ICE的两种实现：Full和Lite，其中不支持NAT的主机只允许实现Lite。对于RTSP，Lite实现是不够的，因为它不会导致媒体服务器发送连接检查，该检查用于防止RTSP服务器成为拒绝服务工具。
The ice-mismatch parameter indicates that the offer arrived with a default destination for a media component that didn't have a corresponding candidate attribute. This is not needed for RTSP as the ICE-based lower-layer transport specification either is supported or another alternative transport is used. This is always explicitly indicated in the SETUP request and response.
ice mismatch参数表示提供的媒体组件的默认目标没有相应的候选属性。RTSP不需要这样做，因为支持基于ICE的下层传输规范，或者使用其他替代传输。设置请求和响应中始终明确指出这一点。
The Remote candidate attribute is not needed for RTSP for the following reasons. Each SETUP request results in an independent ICE processing chain that either fails or results in nominating a single candidate pair to use. If a new SETUP request for the same media is sent, it needs to use a new username fragment and password to avoid any race conditions or uncertainty about to which round of processing the STUN requests relate.
由于以下原因，RTSP不需要远程候选属性。每个设置请求都会导致一个独立的ICE处理链，该链要么失败，要么导致指定一个候选对以供使用。如果发送了针对同一介质的新设置请求，则需要使用新的用户名片段和密码，以避免任何竞争条件或与处理STUN请求的哪一轮相关的不确定性。
ICE-RTSP contains a high-reachability configuration when the RTSP servers are not behind NATs. Please note that "not behind NATs" may apply in some special cases also for RTSP servers behind NATs given that they are in an address space that has reachability for all the RTSP clients intended to able to reach the server. The high-reachability configuration is similar to ICE-Lite as it allows for some reduction in the server's burden. However, due to the need to still verify that the client is actually present and wants to receive the media stream, the server must also initiate binding requests and await binding responses. The reduction for the high-reachability configuration of ICE-RTSP is that they don't need to initiate their own checks and instead rely on triggered checks for verification. This also removes a denial-of-service threat where an RTSP SETUP request will trigger large amount of STUN connectivity checks towards provided candidate addresses.
当RTSP服务器不支持NAT时，ICE-RTSP包含高可达性配置。请注意，“不在NAT后面”可能在某些特殊情况下也适用于NAT后面的RTSP服务器，因为它们位于一个地址空间中，所有RTSP客户端都可以访问该服务器。高可达性配置类似于ICE Lite，因为它允许在一定程度上减少服务器的负担。但是，由于仍然需要验证客户端是否实际存在并希望接收媒体流，服务器还必须启动绑定请求并等待绑定响应。ICE-RTSP的高可达性配置的降低是，它们不需要启动自己的检查，而是依赖触发检查进行验证。这也消除了拒绝服务威胁，RTSP设置请求将触发对提供的候选地址的大量STUN连接检查。
This section describes, in detail, how the interaction and flow of ICE works with RTSP messages.
本节详细描述了ICE与RTSP消息的交互和流是如何工作的。
The RTSP server is RECOMMENDED to indicate it has support for ICE by sending the "a=rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE message if SDP is used. This allows RTSP clients to only send the new ICE exchanges with servers that support ICE thereby limiting the overhead on current non-ICE supporting RTSP servers. When not using RTSP DESCRIBE, it is still RECOMMENDED to use the SDP attribute for the session description.
如果使用SDP，建议RTSP服务器在对RTSP描述消息的响应中发送“a=RTSP-ICE-d-m”SDP属性，以表明其支持ICE。这允许RTSP客户端仅与支持ICE的服务器发送新的ICE交换，从而限制当前不支持ICE的RTSP服务器的开销。当不使用RTSP description时，仍然建议对会话描述使用SDP属性。
A client can also use the DESCRIBE request to determine explicitly if both server and any proxies support ICE. The client includes the Supported header with its supported feature tags, including "setup.ice-d-m". Upon seeing the Supported header, any proxy will include the Proxy-Supported header with the feature tags it supports.
客户端还可以使用descripe请求明确确定服务器和任何代理是否都支持ICE。客户端包括支持的标题及其支持的功能标签，包括“setup.ice-d-m”。在看到受支持的标头时，任何代理都将包括受支持的标头及其支持的功能标记。
The server will echo back the Proxy-Supported header and its own version of the Supported header so enabling a client to determine whether or not all involved parties support ICE. Note that even if a proxy is present in the chain that doesn't indicate support for ICE, it may still work (see Section 7).
服务器将回显支持代理的标头及其自身版本的支持标头，以便客户端能够确定是否所有相关方都支持ICE。请注意，即使链中存在一个不表示支持ICE的代理，它仍然可以工作（参见第7节）。
For example:
例如：
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312
User-Agent: PhonyClient 1.2
Accept: application/sdp, application/example
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312
User-Agent: PhonyClient 1.2
Accept: application/sdp, application/example
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1
Content-Type: application/sdp
Content-Length: 367
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1
Content-Type: application/sdp
Content-Length: 367
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management)
t=2873397496 2873404696
a=recvonly
a=rtsp-ice-d-m
a=control: *
m=audio 3456 RTP/AVP 0
a=control: /audio
m=video 2232 RTP/AVP 31
a=control: /video
v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management)
t=2873397496 2873404696
a=recvonly
a=rtsp-ice-d-m
a=control: *
m=audio 3456 RTP/AVP 0
a=control: /audio
m=video 2232 RTP/AVP 31
a=control: /video
The RTSP client reviews the session description returned, for example, by an RTSP DESCRIBE message, to determine what media resources need to be set up. For each of these media streams where the transport protocol supports ICE connectivity checks, the client SHALL gather candidate addresses for UDP transport as described in Section 4.1.1 in ICE [RFC5245] according to standard ICE rather than the ICE-Lite implementation and according to Section 5 of ICE TCP [RFC6544] for TCP-based candidates.
RTSP客户端查看RTSP描述消息返回的会话描述，以确定需要设置哪些媒体资源。对于传输协议支持ICE连接检查的每个媒体流，客户机应根据标准ICE（而非ICE Lite实现）和ICE TCP（RFC6544）第5节收集ICE[RFC5245]第4.1.1节中所述的UDP传输候选地址，用于基于TCP的候选地址。
The RTSP client will then send at least one SETUP request per media stream to establish the media streams required for the desired session. For each media stream where it desires to use ICE, it MUST include a transport specification with "D-ICE" as the lower layer, and each media stream SHALL have its own unique combination of ICE candidates and ICE-ufrag. This transport specification SHOULD be placed first in the list to give it highest priority. It is RECOMMENDED that additional transport specifications be provided as a fallback in case of proxies that do not support ICE. The RTSP client will be initiating and thus the controlling party in the ICE processing. For example (note that some lines are broken in contradiction with the defined syntax due to space restrictions in the documenting format):
然后，RTSP客户端将为每个媒体流发送至少一个设置请求，以建立所需会话所需的媒体流。对于希望使用ICE的每个媒体流，它必须包括一个以“D-ICE”作为底层的传输规范，并且每个媒体流应具有其自己的ICE候选和ICE ufrag的独特组合。此传输规范应放在列表的第一位，以给予其最高优先级。建议在代理不支持ICE的情况下，提供额外的运输规范作为备用。RTSP客户端将启动，从而成为ICE处理中的控制方。例如（请注意，由于文档格式中的空间限制，某些行被打断，与定义的语法相矛盾）：
C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 313
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY;
ICE-Password=asd88fgpdd777uzjYhagZg; candidates="
1 1 UDP 2130706431 10.0.1.17 8998 typ host;
2 1 UDP 1694498815 192.0.2.3 45664 typ srflx
raddr 10.0.1.17 rport 8998"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP; unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 313
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY;
ICE-Password=asd88fgpdd777uzjYhagZg; candidates="
1 1 UDP 2130706431 10.0.1.17 8998 typ host;
2 1 UDP 1694498815 192.0.2.3 45664 typ srflx
raddr 10.0.1.17 rport 8998"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP; unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
Upon receiving a SETUP request, the server can determine what media resource should be delivered and which transport alternatives the client supports. If one based on D-ICE is on the list of supported transports and preferred among the supported, the below applies.
在收到设置请求后，服务器可以确定应交付的媒体资源以及客户端支持的传输备选方案。如果基于D-ICE的传输在受支持的传输列表中，并且在受支持的传输中是首选的，则以下内容适用。
The transport specification will indicate which media protocol is to be used and, based on this and the client's candidates, the server determines the protocol and if it supports ICE with that protocol. The server SHALL then gather its UDP candidates according to Section 4.1.1 in ICE [RFC5245] and any TCP-based ones according to Section 5 of ICE TCP [RFC6544].
传输规范将指示要使用哪种媒体协议，并且基于此协议和客户端的候选协议，服务器将确定协议，以及它是否支持带有该协议的ICE。然后，服务器应根据ICE[RFC5245]第4.1.1节收集其UDP候选，并根据ICE TCP[RFC6544]第5节收集任何基于TCP的候选。
Servers that have an address that is generally reachable by any client within the address scope the server intends to serve MAY be specially configured (high-reachability configuration). This special configuration has the goal of reducing the server-side candidate to preferably a single one per (address family, media stream, media
对于地址通常可由服务器打算服务的地址范围内的任何客户端访问的服务器，可以进行特殊配置（高可达性配置）。这种特殊配置的目标是将服务器端候选者减少到每个（地址系列、媒体流、媒体）一个候选者
component) tuple. Instead of gathering all possible addresses including relayed and server-reflexive addresses, the server uses a single address per address family that the server knows should be reachable by a client behind one or more NATs. The reason for this special configuration is twofold: Firstly, it reduces the load on the server in address gathering and in ICE processing during the connectivity checks. Secondly, it will reduce the number of permutations for candidate pairs significantly thus potentially speeding up the conclusion of the ICE processing. However, note that using this option on a server that doesn't fulfill the requirement of being reachable is counterproductive, and it is important that this is correctly configured.
组件）元组。服务器不收集所有可能的地址（包括中继地址和服务器自反地址），而是为每个地址族使用一个地址，服务器知道一个或多个NAT后面的客户端应该可以访问这些地址族。这种特殊配置的原因有两个：首先，它减少了连接检查期间服务器在地址收集和ICE处理方面的负载。其次，它将显著减少候选对的置换数量，从而潜在地加快ICE处理的结论。但是，请注意，在不满足可访问性要求的服务器上使用此选项会适得其反，正确配置此选项非常重要。
The above general consideration for servers applies also for TCP-based candidates. A general implementation should support several candidate collection techniques and connection types. For TCP-based candidates, a high-reachability configured server is recommended to only offer Host candidates. In addition to passive connection types, the server can select to provide active or S-O connection types to match the client's candidates.
上述对服务器的一般考虑也适用于基于TCP的候选服务器。一般实现应该支持几种候选收集技术和连接类型。对于基于TCP的候选主机，建议使用高可达性配置的服务器，以便仅提供候选主机。除了被动连接类型外，服务器还可以选择提供主动或S-O连接类型，以匹配客户端的候选连接。
The server determines if the SETUP request is successful and, if so, returns a 200 OK response; otherwise, it returns an error code. At that point, the server, having selected a transport specification using the "D-ICE" lower layer, will need to include that transport specification in the response message. The transport specification SHALL include the candidates gathered in Section 6.4 in the "candidates" transport header parameter as well as the server's ICE username fragment and password. In the case that there are no valid candidate pairs with the combination of the client and server candidates, a 480 (ICE Connectivity check failure) error response SHALL be returned, which MUST include the server's candidates. The return of a 480 error may allow both the server and client to release their candidates; see Section 6.10.
服务器确定设置请求是否成功，如果成功，则返回200 OK响应；否则，它将返回一个错误代码。此时，已使用“D-ICE”较低层选择传输规范的服务器将需要在响应消息中包括该传输规范。传输规范应包括第6.4节中“候选者”传输头参数中收集的候选者以及服务器的ICE用户名片段和密码。如果客户端和服务器候选组合中没有有效的候选对，则应返回480（ICE连接检查失败）错误响应，其中必须包括服务器的候选。返回480错误可能允许服务器和客户端释放其候选对象；见第6.10节。
Below is an example of a successful response to the request in Section 6.3.
下面是对第6.3节中请求的成功响应示例。
S->C: RTSP/2.0 200 OK
CSeq: 313
Session: 12345678
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3;
ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates="
1 1 UDP 2130706431 192.0.2.56 50234 typ host"
Accept-Ranges: NPT
Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK
CSeq: 313
Session: 12345678
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3;
ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates="
1 1 UDP 2130706431 192.0.2.56 50234 typ host"
Accept-Ranges: NPT
Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
The server SHALL start the connectivity checks following the procedures described in Sections 5.7 and 5.8 of ICE [RFC5245] unless it is configured to use the high-reachability option. If it is, then it MAY suppress its own checks until the server's checks are triggered by the client's connectivity checks.
服务器应按照ICE[RFC5245]第5.7节和第5.8节所述程序启动连接检查，除非其配置为使用高可达性选项。如果是，则它可能会抑制自己的检查，直到客户端的连接检查触发服务器的检查。
Please note that Section 5.8 of ICE [RFC5245] does specify that the initiation of the checks are paced and new ones are only started every Ta milliseconds. The motivation for this is documented in Appendix B.1 of ICE [RFC5245] as for SIP/SDP all media streams within an offer/answer dialog are running using the same queue. To ensure the same behavior with RTSP, the server SHALL use a single pacer queue for all media streams within each RTSP session.
请注意，ICE[RFC5245]的第5.8节确实规定，检查的启动是有节奏的，新的检查只在每Ta毫秒启动一次。ICE[RFC5245]的附录B.1中记录了这一动机，因为对于SIP/SDP，提供/应答对话框中的所有媒体流都使用相同的队列运行。为确保RTSP具有相同的行为，服务器应为每个RTSP会话中的所有媒体流使用单个pacer队列。
The values for the pacing of STUN and TURN transactions Ta and RTO can be configured but have the same minimum values defined in the ICE specification.
STUN和TURN事务Ta和RTO的速度调整值可以配置，但具有ICE规范中定义的相同最小值。
When a connectivity check from the client reaches the server, it will result in a triggered check from the server as specified in Section 7.2.1.4 of ICE [RFC5245]. This is why servers with a high-reachability address can wait until this triggered check to send out any checks for itself, so saving resources and mitigating the DDoS potential.
当客户端的连接检查到达服务器时，将导致ICE[RFC5245]第7.2.1.4节中规定的服务器触发检查。这就是为什么具有高可达性地址的服务器可以等到触发检查后再为自己发送任何检查，从而节省资源并降低DDoS的可能性。
The client receives the SETUP response and learns the candidate addresses to use for the connectivity checks. The client SHALL initiate its connectivity check(s), following the procedures in Section 6 of ICE [RFC5245]. The pacing of STUN transactions (Appendix B.1 of [RFC5245]) SHALL be used across all media streams that are part of the same RTSP session.
客户端接收设置响应并学习用于连接检查的候选地址。客户应按照ICE[RFC5245]第6节中的程序启动其连接检查。应在属于同一RTSP会话一部分的所有媒体流中使用STUN事务的步调（RFC5245的附录B.1）。
Aggressive nomination SHOULD be used with RTSP during initial SETUP for a resource. This doesn't have all the negative impact that it has in offer/answer as media playing only starts after issuing a PLAY request. Thus, the issue with a change of the media path being used for delivery can be avoided by not issuing a PLAY request while STUN connectivity checks are still outstanding. Aggressive nomination can result in multiple candidate pairs having their nominated flag set, but according to Section 8.1.1.2 of ICE [RFC5245], when the PLAY request is sent, the media will arrive on the pair with the highest priority. Note, different media resources may still end up with different foundations.
在资源的初始设置期间，应与RTSP一起使用。这并没有在提供/应答中产生的所有负面影响，因为媒体播放仅在发出播放请求后才开始。因此，在STUN连接检查仍然未完成时，通过不发出播放请求，可以避免用于传送的媒体路径发生变化的问题。积极提名可能会导致多个候选对设置其提名标志，但根据ICE[RFC5245]第8.1.1.2节，当发送播放请求时，媒体将到达具有最高优先级的候选对。注意，不同的媒体资源最终可能会有不同的基础。
The above does not change ICE and its handling of aggressive nomination. When using aggressive nomination, a higher-priority candidate pair with an outstanding connectivity check message can move into the Succeeded state and the candidate pair will have its Nominated flag set. This results in the higher-priority candidate pair being used instead of the previous pair, which is also in the Succeeded state.
上述情况不会改变ICE及其对侵略性提名的处理方式。使用主动提名时，具有未完成连接检查消息的高优先级候选对可以进入成功状态，并且该候选对将设置其提名标志。这将导致使用更高优先级的候选对，而不是前一对，前一对也处于成功状态。
To avoid this occurring during actual media transport, the RTSP client can add additional logic when the ICE processing overall is completed to indicate if there are still higher-priority connectivity checks outstanding. If some check is still outstanding, the implementation can choose to wait until some additional timeout is triggered or the outstanding checks complete before progressing with a PLAY request. An alternative is to accept the risk for a path change during media delivery and start playing immediately.
为了避免在实际媒体传输期间发生这种情况，RTSP客户端可以在ICE处理全部完成时添加额外的逻辑，以指示是否还有更高优先级的连接检查未完成。如果某些检查仍然未完成，则实现可以选择等待，直到触发一些额外的超时或未完成的检查完成，然后再继续执行播放请求。另一种选择是接受媒体交付过程中路径更改的风险，并立即开始播放。
RTSP clients that want to ensure that each media resource uses the same path can use regular nomination where both 1) the ICE processing completion criteria and 2) which media streams are nominated for use can be controlled. This does not affect the RTSP server, as its role is the one of being controlled.
要确保每个媒体资源使用相同路径的RTSP客户端可以使用常规指定，其中1）ICE处理完成标准和2）指定使用的媒体流都可以控制。这不会影响RTSP服务器，因为它的角色是被控制的角色之一。
When the client has concluded all of its connectivity checks and has nominated its desired candidate pair for a particular media stream, it MAY issue a PLAY request for that stream. Note that due to the aggressive nomination, there is a risk that any outstanding check may nominate another pair than what was already nominated. The candidate pair with the highest priority will be used for the media. If the client has locally determined that its checks have failed, it may try providing an extended set of candidates and update the server candidate list by issuing a new SETUP request for the media stream.
当客户端完成了其所有连接检查并为特定媒体流指定了其期望的候选对时，它可以为该流发出播放请求。请注意，由于积极的提名，任何未兑现的支票都有可能提名另一对，而不是已经提名的。具有最高优先级的候选对将用于媒体。如果客户端在本地确定其检查失败，它可能会尝试提供扩展的候选集，并通过为媒体流发出新的设置请求来更新服务器候选列表。
If the client concluded its connectivity checks successfully and therefore sent a PLAY request but the server cannot conclude successfully, the server will respond with a 480 (ICE Connectivity check failure) error response. Upon receiving the 480 (ICE Connectivity check failure) response, the client may send a new SETUP request assuming it has any new information that can be included in the candidate list. If the server is still performing the checks when receiving the PLAY request, it will respond with a 150 (Server still working on ICE connectivity checks) response to indicate this.
如果客户端成功完成其连接检查并因此发送播放请求，但服务器无法成功完成，则服务器将以480（ICE连接检查失败）错误响应进行响应。在接收到480（ICE连接检查失败）响应后，客户机可以发送一个新的设置请求，前提是它具有可包括在候选列表中的任何新信息。如果服务器在接收播放请求时仍在执行检查，它将以150（服务器仍在进行ICE连接检查）响应来指示这一点。
When the RTSP server receives a PLAY request, it checks to see that the connectivity checks have concluded successfully and only then will it play the stream. If the PLAY request is for a particular media stream, the server only needs to check that the connectivity checks for that stream completed successfully. If the server has not concluded its connectivity checks, the server indicates that by sending the 150 (Server still working on ICE connectivity checks) (Section 4.5.1). If there is a problem with the checks, then the server sends a 480 response to indicate a failure of the checks. If the checks are successful, then the server sends a 200 OK response and starts delivering media.
当RTSP服务器收到播放请求时，它会检查连接检查是否已成功结束，然后才会播放流。如果播放请求是针对特定媒体流的，则服务器只需检查该流的连接检查是否成功完成。如果服务器尚未完成其连接检查，则服务器通过发送150（服务器仍在进行ICE连接检查）（第4.5.1节）来指示。如果检查有问题，则服务器将发送480响应以指示检查失败。如果检查成功，则服务器发送200 OK响应并开始传送介质。
Both server and client MAY free their non-selected candidates as soon as a 200 OK response has been issued/received for the PLAY request and no outstanding connectivity checks exist.
一旦针对播放请求发出/接收到200 OK响应且不存在未完成的连接检查，服务器和客户端都可以释放其未选择的候选者。
Clients and servers MAY free all their gathered candidates after having received or sent, respectively, a 480 response to a SETUP request. Clients will likely free their candidates first after having tried any additional actions that may resolve the issue, e.g., verifying the address gathering, or use additional STUN or TURN
客户端和服务器在分别收到或发送对设置请求的480响应后，可以释放其收集的所有候选者。客户可能会在尝试了可能解决问题的任何其他操作（例如验证地址收集或使用其他眩晕或转身）后，首先释放他们的候选人
servers. Thus, a server will have to weigh the cost of doing address gathering versus maintaining the gathered address for some time to allow any new SETUP request to be issued by the client.
服务器。因此，服务器必须权衡进行地址收集的成本与在一段时间内维护收集的地址的成本，以允许客户端发出任何新的设置请求。
If the 480 response is sent in response to a PLAY request, the server MUST NOT free its gathered candidates. Instead, it will have to wait for additional actions from the client or terminate the RTSP session due to inactivity.
如果480响应是针对播放请求发送的，则服务器不得释放其收集的候选者。相反，它必须等待来自客户端的其他操作，或者由于不活动而终止RTSP会话。
The client and server SHALL use STUN to send keep-alive messages for the nominated candidate pair(s) following the rules of Section 10 of ICE [RFC5245]. This is important, as normally RTSP play mode sessions only contain traffic from the server to the client so the bindings in the NAT need to be refreshed by the client-to-server traffic provided by the STUN keep-alive.
客户机和服务器应根据ICE[RFC5245]第10节的规则，使用STUN发送指定候选对的保持活动消息。这一点很重要，因为通常RTSP播放模式会话只包含从服务器到客户端的流量，所以NAT中的绑定需要由STUN保持活动提供的客户端到服务器的流量刷新。
A client that decides to change any parameters related to the media stream setup will send a new SETUP request. In this new SETUP request, the client MAY include a new different ICE username fragment and password to use in the ICE processing. The new ICE username and password SHALL cause the ICE processing to start from the beginning again, i.e., an ICE restart (Section 9.1.1.1 of [RFC5245]). The client SHALL in case of ICE restart, gather candidates and include the candidates in the transport specification for D-ICE.
决定更改与媒体流设置相关的任何参数的客户端将发送新的设置请求。在这个新的设置请求中，客户端可能包括一个新的不同的ICE用户名片段和密码，以便在ICE处理中使用。新的ICE用户名和密码应使ICE处理重新从头开始，即ICE重启（RFC5245第9.1.1.1节）。如果ICE重新启动，客户应收集候选人，并将候选人纳入D-ICE的运输规范中。
ICE restarts may be triggered due to changes of client or server attachment to the network, such as changes to the media streams destination or source address or port. Most RTSP parameter changes would not require an ICE restart, but would use existing mechanisms in RTSP to indicate from what point in the RTP stream they apply. These include the following: performing a pause prior to the parameter change and then resume; assuming the server supports using SETUP during the PLAY state; or using the RTP-Info header (Section 18.45 of [RFC7826]) to indicate from where in the media stream the change shall apply.
ICE重启可能由于客户端或服务器连接到网络的更改而触发，例如媒体流目的地或源地址或端口的更改。大多数RTSP参数更改不需要ICE重新启动，但将使用RTSP中的现有机制来指示它们从RTP流中的哪个点开始应用。这些包括：在参数更改之前执行暂停，然后恢复；假设服务器支持在播放状态下使用设置；或者使用RTP信息头（RFC7826第18.45节）指示媒体流中的更改应在何处应用。
Even if the server does not normally support SETUP during PLAY state, it SHALL support SETUP requests in PLAY state for the purpose of changing only the ICE parameters, which are ICE-Password, ICE-ufrag, and the content of ICE candidates.
即使服务器在播放状态下通常不支持设置，也应支持播放状态下的设置请求，以便仅更改ICE参数，即ICE密码、ICE ufrag和ICE候选内容。
If the RTSP session is in playing state at the time of sending the SETUP request requiring ICE restart, then the ICE connectivity checks SHALL use Regular nomination. Any ongoing media delivery continues
如果RTSP会话在发送需要ICE重启的设置请求时处于播放状态，则ICE连接检查应使用常规指定。任何正在进行的媒体交付都将继续
on the previously nominated candidate pairs until the new pairs have been nominated for the individual media stream. Once the nomination of the new candidate pair has completed, all unused candidates may be released. If the ICE processing fails and no new candidate pairs are nominated for use, then the media stream MAY continue to use the previously nominated candidate pairs while they still function. If they appear to fail to transport media packets anymore, then the client can select between two actions: attempting any actions that might make ICE work or terminating the RTSP session. Firstly, it can attempt any actions available that might make ICE work, like trying another STUN/TURN server or changing the transport parameters. In that case, the client modifies the RTSP session, and if ICE is still to be used, the client restarts ICE once more. Secondly, if the client is unable to modify the transport or ICE parameters, it MUST NOT restart the ICE processing, and it SHOULD terminate the RTSP session.
在先前指定的候选对上，直到为单个媒体流指定了新对为止。一旦新候选人的提名完成，所有未使用的候选人都可能被释放。如果ICE处理失败并且没有指定要使用的新候选对，则媒体流可以继续使用先前指定的候选对，而它们仍然工作。如果它们似乎无法再传输媒体数据包，那么客户端可以在两个操作之间进行选择：尝试可能使ICE工作的任何操作或终止RTSP会话。首先，它可以尝试任何可能使ICE工作的可用操作，例如尝试另一个眩晕/转弯服务器或更改传输参数。在这种情况下，客户端修改RTSP会话，如果仍要使用ICE，客户端将再次重新启动ICE。其次，如果客户端无法修改传输或ICE参数，则不得重新启动ICE处理，并应终止RTSP会话。
A server may require an ICE restart because of server-side load balancing or a failure resulting in an IP address and a port number change. In that case, the server SHALL use the PLAY_NOTIFY method to inform the client (Section 13.5 [RFC7826]) with a new Notify-Reason header: ice-restart. The server will identify if the change is for a single media or for the complete session by including the corresponding URI in the PLAY_NOTIFY request.
由于服务器端负载平衡或导致IP地址和端口号更改的故障，服务器可能需要ICE重新启动。在这种情况下，服务器应使用PLAY_NOTIFY方法通知客户机（第13.5节[RFC7826]）一个新的通知原因标题：ice重启。服务器将通过在PLAY_NOTIFY请求中包含相应的URI来确定更改是针对单个媒体还是针对整个会话。
Upon receiving and responding to this PLAY_NOTIFY with an ice-restart reason, the client SHALL gather new ICE candidates and send SETUP requests for each media stream part of the session. The server provides its candidates in the SETUP response the same way as for the first time ICE processing. Both server and client SHALL provide new ICE usernames and passwords. The client MAY issue the SETUP request while the session is in PLAYING state.
在收到并响应带有ice重新启动原因的播放通知后，客户端应收集新的ice候选者，并为会话的每个媒体流部分发送设置请求。服务器在设置响应中提供其候选对象的方式与第一次ICE处理相同。服务器和客户端均应提供新的ICE用户名和密码。会话处于播放状态时，客户端可能会发出设置请求。
If the RTSP session is in PLAYING state when the client issues the SETUP request, the client SHALL use Regular nomination. If not, the client will use the same procedures as for when first creating the session.
当客户端发出设置请求时，如果RTSP会话处于播放状态，客户端应使用常规指定。如果没有，客户端将使用与首次创建会话时相同的过程。
Note that for each media stream keep-alive messages on the previous set of candidate pairs SHOULD continue until new candidate pairs have been nominated. After having nominated a new set of candidate pairs, the client may continue to receive media for some additional time. Even if the server stops delivering media over that candidate pair at the time of nomination, media may arrive for up to one maximum segment lifetime as defined in TCP (2 minutes). Unfortunately, if the RTSP server is divided into a separate controller and media
请注意，对于每个媒体流，前一组候选对上的保持活动消息应继续，直到新的候选对被指定为止。在指定了一组新的候选对之后，客户端可以继续接收媒体一段额外的时间。即使服务器在提名时停止通过该候选对传送媒体，媒体也可能到达TCP中定义的最长段生存期（2分钟）。不幸的是，如果RTSP服务器被划分为单独的控制器和介质
stream, a failure may result in continued media delivery for a longer time than the maximum segment lifetime, thus source filtering is RECOMMENDED.
流，则故障可能会导致媒体持续传送的时间超过最大段生存期，因此建议进行源筛选。
For example:
例如：
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854
Notify-Reason: ice-restart
Session: uZ3ci0K+Ld
Server: PhonyServer 1.1
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854
Notify-Reason: ice-restart
Session: uZ3ci0K+Ld
Server: PhonyServer 1.1
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 314
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C;
ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; candidates="
1 1 UDP 2130706431 10.0.1.17 8998 typ host;
2 1 UDP 1694498815 192.0.2.3 51456 typ srflx
raddr 10.0.1.17 rport 9002"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP; unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 314
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C;
ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; candidates="
1 1 UDP 2130706431 10.0.1.17 8998 typ host;
2 1 UDP 1694498815 192.0.2.3 51456 typ srflx
raddr 10.0.1.17 rport 9002"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP; unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0
CSeq: 315
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9;
ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates="
1 1 UDP 2130706431 10.0.1.17 9000 typ host;
2 1 UDP 1694498815 192.0.2.3 51576 typ srflx
raddr 10.0.1.17 rport 9000"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973",
RTP/AVP/TCP; unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0
CSeq: 315
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9;
ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates="
1 1 UDP 2130706431 10.0.1.17 9000 typ host;
2 1 UDP 1694498815 192.0.2.3 51576 typ srflx
raddr 10.0.1.17 rport 9000"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973",
RTP/AVP/TCP; unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 314
Session: uZ3ci0K+Ld
S->C: RTSP/2.0 200 OK
CSeq: 314
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=CbDm;
ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; candidates="
1 1 UDP 2130706431 192.0.2.56 50234 typ host"
Accept-Ranges: NPT
Date: 11 March 2011 13:17:46 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=CbDm;
ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; candidates="
1 1 UDP 2130706431 192.0.2.56 50234 typ host"
Accept-Ranges: NPT
Date: 11 March 2011 13:17:46 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK
CSeq: 315
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=jigs;
ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates="
1 1 UDP 2130706431 192.0.2.56 47233 typ host"
Accept-Ranges: NPT
Date: 11 March 2011 13:17:47 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK
CSeq: 315
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=jigs;
ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates="
1 1 UDP 2130706431 192.0.2.56 47233 typ host"
Accept-Ranges: NPT
Date: 11 March 2011 13:17:47 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
RTSP allows for proxies that can be of two fundamental types depending on whether or not they relay and potentially cache the media. Their differing impact on the RTSP NAT traversal solution, including backwards compatibility, is explained below.
RTSP允许使用两种基本类型的代理，具体取决于它们是否中继并可能缓存介质。它们对RTSP NAT穿越解决方案的不同影响，包括向后兼容性，将在下面解释。
An RTSP proxy that relays or caches the media stream for a particular media session can be considered to split the media transport into two parts: firstly, a media transport between the server and the proxy according to the proxy's need, and, secondly, delivery from the proxy to the client. This split means that the NAT traversal solution will be run on each individual media leg according to need.
可以将中继或缓存特定媒体会话的媒体流的RTSP代理视为将媒体传输分为两部分：第一，根据代理的需要在服务器和代理之间进行媒体传输，第二，从代理传送到客户端。这种拆分意味着NAT穿越解决方案将根据需要在每个单独的媒体分支上运行。
It is RECOMMENDED that any media-handling proxy support the media NAT traversal defined within this specification. This is for two reasons: firstly, to enable clients to perform NAT traversal for the media between the proxy and itself and secondly to allow the proxy to be topology independent to support performing NAT traversal (to the server) for clients not capable of NAT traversal present in the same address domain as the proxy.
建议任何媒体处理代理都支持本规范中定义的媒体NAT遍历。这有两个原因：第一，使客户端能够对代理和自身之间的媒体执行NAT遍历，第二，允许代理独立于拓扑，以支持对与代理位于同一地址域中的客户端执行NAT遍历（到服务器）。
For a proxy to support the media NAT traversal defined in this specification, a proxy will need to implement the solution fully and be able to act as both a controlling and a controlled ICE peer. The proxy also SHALL include the "setup.ice-d-m" feature tag in any applicable capability negotiation headers, such as Proxy-Supported.
对于支持本规范中定义的媒体NAT遍历的代理，代理需要完全实现解决方案，并且能够充当控制和控制ICE对等方。代理还应在任何适用的能力协商头中包括“setup.ice-d-m”功能标签，如支持代理。
A signaling-only proxy handles only the RTSP signaling and does not have the media relayed through proxy functions. This type of proxy is not likely to work unless the media NAT traversal solution is in place between the client and the server, because the DoS protection measures, as discussed in Section 21.2.1 of RTSP 2.0 [RFC7826], usually prevent media delivery to addresses other than from where the RTSP signaling arrives at the server.
仅信令代理仅处理RTSP信令，不通过代理功能中继媒体。除非媒体NAT穿越解决方案在客户端和服务器之间就位，否则这种类型的代理不太可能工作，因为如RTSP 2.0[RFC7826]第21.2.1节所述，DoS保护措施通常会阻止媒体传递到RTSP信号到达服务器的地址以外的地址。
The solution for the signaling-only proxy is that it must forward the RTSP SETUP requests including any transport specification with the "D-ICE" lower layer and the related transport parameters. A proxy supporting this functionality SHALL indicate its capability by always including the "setup.ice-d-m" feature tag in the Proxy-Supported header in any SETUP request or response.
仅信令代理的解决方案是，它必须转发RTSP设置请求，包括任何具有“D-ICE”较低层的传输规范和相关传输参数。支持此功能的代理应通过始终在任何设置请求或响应中的代理支持标头中包含“setup.ice-d-m”功能标记来指示其功能。
A media-handling proxy that doesn't support the ICE media NAT traversal specified here is assumed to remove the transport specification and use any of the lower prioritized transport specifications if provided by the requester. The specification of such a non-ICE transport enables the negotiation to complete, although with a less preferred method since a NAT between the proxy and the client may result in failure of the media path.
假定不支持此处指定的ICE媒体NAT遍历的媒体处理代理将删除传输规范，并使用任何优先级较低的传输规范（如果由请求者提供）。这种非ICE传输的规范使得协商能够完成，尽管使用的是较不优选的方法，因为代理和客户端之间的NAT可能导致媒体路径失败。
A non-media-handling proxy is expected to ignore and simply forward all unknown transport specifications. However, this can only be guaranteed for proxies following the RTSP 2.0 specification [RFC7826].
非媒体处理代理应忽略并转发所有未知的传输规范。但是，这只能保证符合RTSP 2.0规范[RFC7826]的代理。
The usage of the "setup.ice-d-m" feature tag in the Proxy-Require header is NOT RECOMMENDED because it can have contradictory results. For a proxy that does not support ICE but is media handling, the inclusion of the feature tag will result in aborting the setup and indicating that it isn't supported, which is desirable if providing other fallbacks or other transport configurations to handle the situation is wanted. For non-ICE-supporting non-media-handling proxies, the result will be aborting the setup. However, the setup might have worked if the feature tag wasn't present in the Proxy-Require header. This variance in results is the reason we don't recommend the usage of the Proxy-Require header. Instead, we recommend the usage of the Supported header to force proxies to include the feature tags for the intersection of what the proxy chain supports in the Proxy-Supported header. This will provide a positive indication when all proxies in the chain between the client and server support the functionality.
不建议在Proxy Require标头中使用“setup.ice-d-m”功能标记，因为它可能会产生矛盾的结果。对于不支持ICE但正在处理媒体的代理，包含功能标签将导致中止安装并指示不支持该设置，如果需要提供其他回退或其他传输配置来处理该情况，这是可取的。对于非ICE支持的非介质处理代理，结果将中止安装。但是，如果Proxy Require标头中不存在功能标签，则安装可能会起作用。结果的这种差异是我们不建议使用Proxy Require头的原因。相反，我们建议使用受支持的标头来强制代理在代理支持的标头中包含代理链支持的交集的功能标记。当客户端和服务器之间的链中的所有代理都支持该功能时，这将提供一个积极的指示。
If a proxy doesn't support the "setup.ice-d-m" feature, but that proxy is not a media-handling proxy, the ICE-based setup could still work, since such a proxy may do pass through on any transport parameters. Unfortunately ,the Proxy-Require and Proxy-Supported RTSP headers failed to provide that information. The only way of finding whether or not this is the case is to try perform a SETUP including a Transport header with transport specifications using ICE.
如果代理不支持“setup.ice-d-m”功能，但该代理不是媒体处理代理，则基于ice的设置仍然可以工作，因为这样的代理可能会传递任何传输参数。不幸的是，Proxy Require和Proxy Supported RTSP标头未能提供该信息。确定是否存在这种情况的唯一方法是尝试使用ICE执行一个包含传输标题和传输规范的设置。
"Multiplexing RTP Data and Control Packets on a Single Port" [RFC5761] specifies how and when RTP and RTCP can be multiplexed on the same port. This multiplexing is beneficial when combined with ICE for RTSP as it makes RTP and RTCP need only a single component per media stream instead of two, so reducing the load on the connectivity checks. For details on how to negotiate RTP and RTCP multiplexing, see Appendix C of RTSP 2.0 [RFC7826].
“在单个端口上多路复用RTP数据和控制数据包”[RFC5761]指定如何以及何时在同一端口上多路复用RTP和RTCP。当与ICE for RTSP结合使用时，这种多路复用是有益的，因为它使RTP和RTCP每个媒体流只需要一个组件，而不是两个，因此减少了连接检查的负载。有关如何协商RTP和RTCP多路复用的详细信息，请参阅RTSP 2.0[RFC7826]的附录C。
Multiplexing RTP and RTCP has the benefit that it avoids the need for handling two components per media stream when RTP is used as the media transport protocol. This eliminates at least one STUN check per media stream and will also reduce the time needed to complete the ICE processing by at least the time it takes to pace out the additional STUN checks of up to one complete round-trip time for a single media stream. In addition to the protocol performance improvements, the server and client-side complexities are reduced as multiplexing halves the total number of STUN instances and holding the associated state. Multiplexing will also reduce the combinations and length of the list of possible candidates.
复用RTP和RTCP的好处是，当RTP用作媒体传输协议时，它避免了每个媒体流需要处理两个组件。这消除了每个媒体流至少一次晕眩检查，还将使完成ICE处理所需的时间减少至少一次，使单个媒体流的额外晕眩检查的往返时间缩短一倍。除了协议性能改进之外，由于多路复用将STUN实例总数减半并保持关联状态，服务器和客户端的复杂性也降低了。多路复用还将减少可能候选列表的组合和长度。
The implementation of RTP and RTCP multiplexing is additional work required for this solution. However, when implementing the ICE solution, a server or client will need to implement a demultiplexer between the STUN and RTP or RTCP packets below the RTP/RTCP implementation anyway, so the additional work of one new demultiplexing point directly connected to the STUN and RTP/RTCP seems small relative to the benefits provided.
RTP和RTCP多路复用的实现是该解决方案所需的额外工作。然而，在实施ICE解决方案时，服务器或客户机无论如何都需要在STUN和RTP或RTCP包之间实施RTP/RTCP实施下的解复用器，因此直接连接到STUN和RTP/RTCP的一个新解复用点的额外工作相对于所提供的好处来说似乎很小。
Due to the benefits mentioned above, RTSP servers and clients that support "D-ICE" lower-layer transport in combination with RTP SHALL also implement and use RTP and RTCP multiplexing as specified in Appendix C.1.6.4 of [RFC7826] and [RFC5761].
由于上述优点，支持“D-ICE”低层传输与RTP相结合的RTSP服务器和客户端也应实现并使用[RFC7826]和[RFC5761]附录C.1.6.4中规定的RTP和RTCP多路复用。
9. Fallback and Using Partial ICE Functionality to Improve NAT/Firewall Traversal
9. 回退并使用部分ICE功能改进NAT/防火墙穿越
The need for fallback from ICE in RTSP should be less than for SIP using ICE in SDP offer/answer where a default destination candidate is very important to enable interworking with non-ICE capable endpoints. In RTSP, capability determination for ICE can happen prior to the RTSP SETUP request. This means a client should normally not need to include fallback alternatives when offering ICE, as the capability for ICE will already be determined. However, as described in this section, clients may wish to use part of the ICE functionality to improve NAT/firewall traversal where the server is not ICE capable.
RTSP中对ICE的回退需求应小于在SDP提供/应答中使用ICE的SIP，其中默认目的地候选者对于实现与不支持ICE的端点的互通非常重要。在RTSP中，ICE的能力确定可以在RTSP设置请求之前进行。这意味着客户在提供ICE时通常不需要包括备用方案，因为ICE的能力已经确定。但是，如本节所述，客户端可能希望使用ICE功能的一部分来改进服务器不支持ICE的NAT/防火墙穿越。
Section 4.1.4 of the ICE [RFC5245] specification does recommend that the default destination, i.e., what is used as fallback if the peer isn't ICE capable, is a candidate of relayed type to maximize the likelihood of successful transport of media. This is based on the peer in SIP using SDP offer/answer is almost as likely as the RTSP client to be behind a NAT. For RTSP, the deployment of servers is much more heavily weighted towards deployment with public reachability. In fact, since publicly reachable servers behind NAT either need to support ICE or have static configurations that allow traversal, one can assume that the server will have a public address or support ICE. Thus, the selection of the default destination address for RTSP can be differently prioritized.
ICE[RFC5245]规范第4.1.4节确实建议默认目的地，即当对等方不具备ICE能力时用作回退的目的地，是中继类型的候选者，以最大限度地提高媒体成功传输的可能性。这是基于SIP中使用SDP提供/应答的对等方几乎与RTSP客户端在NAT后面的可能性相同。对于RTSP，服务器的部署更倾向于具有公共可达性的部署。事实上，由于NAT后面的可公开访问的服务器需要支持ICE或具有允许遍历的静态配置，因此可以假设服务器将具有公共地址或支持ICE。因此，RTSP的默认目的地地址的选择可以有不同的优先级。
As an ICE-enabled client behind a NAT needs to be configured with a STUN server address to be able to gather candidates successfully, this can be used to derive a server reflexive candidate for the client's port. How useful this is for a NATed RTSP client as a default candidate depends on the properties of the NAT. As long as the NAT uses an address-independent mapping, then using a STUN-derived reflexive candidate is likely to be successful. However, this is brittle in several ways, and the main reason why the original specification of STUN [RFC3489] and direct usage for NAT traversal was obsoleted. First, if the NAT's behavior is attempted to be determined using STUN as described in [RFC3489], the determined behavior might not be representative of the behavior encountered in another mapping. Secondly, filter state towards the ports used by the server needs to be established. This requires that the server actually includes both address and ports in its response to the SETUP request. Thirdly, messages need to be sent to these ports for keep-alive at a regular interval. How a server reacts to such unsolicited traffic is unknown. This brittleness may be accepted in fallback due to lack of support on the server side.
由于NAT后面的启用ICE的客户机需要配置一个STUN服务器地址，以便能够成功收集候选服务器，因此可以使用该地址为客户机的端口派生一个服务器自反候选服务器。这对于作为默认候选的RTSP客户端来说有多有用取决于NAT的属性。只要NAT使用与地址无关的映射，那么使用STUN派生的自反候选就可能成功。然而，这在几个方面是脆弱的，这也是STUN[RFC3489]的原始规范和NAT遍历的直接使用被淘汰的主要原因。首先，如果试图使用[RFC3489]中所述的STUN确定NAT的行为，则确定的行为可能无法代表在另一个映射中遇到的行为。其次，需要建立服务器使用的端口的过滤器状态。这要求服务器在响应安装请求时实际包括地址和端口。第三，需要将消息发送到这些端口，以便定期保持活动状态。服务器如何对这种未经请求的流量作出反应尚不得而知。由于服务器端缺乏支持，在回退中可以接受这种脆弱性。
To maximize the likelihood that an RTSP client is capable of receiving media, a relay-based address should be chosen as the default fallback address. However, for RTSP clients lacking a relay server, such as a TURN server, or where usage of such a server has significant cost associated with it, the usage of a STUN-derived server reflexive address as client default has a reasonable likelihood of functioning and may be used as an alternative.
为了使RTSP客户端能够接收媒体的可能性最大化，应选择基于中继的地址作为默认回退地址。然而，对于缺少中继服务器（如TURN服务器）的RTSP客户机，或者在使用此类服务器会产生大量相关成本的情况下，使用STUN派生的服务器自反地址作为客户机默认地址具有合理的运行可能性，并且可以用作替代方案。
Fallback addresses need to be provided in their own transport specification using a specifier that does not include the D-ICE lower-layer transport. Instead, the selected protocol, e.g., UDP, needs to be explicitly or implicitly indicated. Secondly, the selected default candidate needs to be included in the SETUP request. If this candidate is server reflexive or relayed, the aspect of keep-alive needs to be ensured.
回退地址需要使用不包括D-ICE低层传输的说明符在其自身的传输规范中提供。相反，所选协议（例如UDP）需要显式或隐式指示。其次，所选的默认候选项需要包含在设置请求中。如果该候选服务器是服务器反射的或中继的，则需要确保保持活动的方面。
Per this document, registrations have been made in a number of registries, both for RTSP and SDP. For all the below registrations, the contact person on behalf of the IETF WG MMUSIC is Magnus Westerlund <magnus.westerlund@ericsson.com>.
根据本文件，已在多个注册中心进行了RTSP和SDP注册。对于以下所有注册，代表IETF工作组MMUSIC的联系人为Magnus Westerlund<Magnus。westerlund@ericsson.com>.
Per this document, one RTSP 2.0 feature tag has been registered in the "RTSP 2.0 Feature-tags" registry.
根据本文档，在“RTSP 2.0功能标签”注册表中注册了一个RTSP 2.0功能标签。
setup.ice-d-m: A feature tag representing the support of the ICE-based establishment of datagram media transport that is capable of transport establishment through NAT and firewalls. This feature tag applies to clients, servers, and proxies and indicates support of all the mandatory functions of this specification.
setup.ice-d-m：一个功能标签，表示支持基于ice建立的数据报媒体传输，能够通过NAT和防火墙建立传输。此功能标签适用于客户端、服务器和代理，并表示支持本规范的所有必需功能。
Per this document, a number of transport protocol combinations have been registered in the RTSP 2.0 "Transport Protocol Identifiers" registry:
根据本文件，许多传输协议组合已在RTSP 2.0“传输协议标识符”注册表中注册：
RTP/AVP/D-ICE: RTP using the AVP profile over an ICE-established datagram flow.
RTP/AVP/D-ICE：在ICE建立的数据报流上使用AVP配置文件的RTP。
RTP/AVPF/D-ICE: RTP using the AVPF profile over an ICE-established datagram flow.
RTP/AVPF/D-ICE：在ICE建立的数据报流上使用AVPF配置文件的RTP。
RTP/SAVP/D-ICE: RTP using the SAVP profile over an ICE-established datagram flow.
RTP/SAVP/D-ICE：在ICE建立的数据报流上使用SAVP配置文件的RTP。
RTP/SAVPF/D-ICE: RTP using the SAVPF profile over an ICE-established datagram flow.
RTP/SAVPF/D-ICE：在ICE建立的数据报流上使用SAVPF配置文件进行RTP。
Per this document, three transport parameters have been registered in the RTSP 2.0's "Transport Parameters" registry.
根据本文件，三个传输参数已在RTSP 2.0的“传输参数”注册表中注册。
candidates: Listing the properties of one or more ICE candidates. See Section 4.2.
候选对象：列出一个或多个ICE候选对象的属性。见第4.2节。
ICE-Password: The ICE password used to authenticate the STUN binding request in the ICE connectivity checks. See Section 4.3.
ICE密码：用于在ICE连接检查中验证STUN绑定请求的ICE密码。见第4.3节。
ICE-ufrag: The ICE username fragment used to authenticate the STUN binding requests in the ICE connectivity checks. See Section 4.3.
ICE ufrag：用于在ICE连接检查中验证STUN绑定请求的ICE用户名片段。见第4.3节。
Per this document, two assignments have been made in the "RTSP 2.0 Status Codes" registry. See Section 4.5.
根据本文件，在“RTSP 2.0状态代码”注册表中进行了两次分配。见第4.5节。
Per this document, one assignment has been made in the RTSP 2.0 Notify-Reason header value registry. The defined value is:
根据本文档，在RTSP 2.0 Notify Reason标头值注册表中进行了一次分配。定义的值为：
ice-restart: This Notify-Reason value allows the server to notify the client about the need for an ICE restart. See Section 4.6.
ice重启：此Notify Reason值允许服务器通知客户端需要ice重启。见第4.6节。
One SDP attribute has been registered:
已注册一个SDP属性：
SDP Attribute ("att-field"):
SDP属性（“att字段”）：
Attribute name: rtsp-ice-d-m
Long form: ICE for RTSP datagram media NAT traversal
Type of attribute: Session-level only
Subject to charset: No
Purpose: RFC 7825, Section 4.7
Values: No values defined
Contact: Magnus Westerlund
Email: magnus.westerlund@ericsson.com
Phone: +46 10 714 82 87
Attribute name: rtsp-ice-d-m
Long form: ICE for RTSP datagram media NAT traversal
Type of attribute: Session-level only
Subject to charset: No
Purpose: RFC 7825, Section 4.7
Values: No values defined
Contact: Magnus Westerlund
Email: magnus.westerlund@ericsson.com
Phone: +46 10 714 82 87
ICE [RFC5245] and ICE TCP [RFC6544] provide an extensive discussion on security considerations that apply here as well.
ICE[RFC5245]和ICE TCP[RFC6544]对此处应用的安全注意事项进行了广泛讨论。
A long-standing risk with transmitting a packet stream over UDP is that the host may not be interested in receiving the stream. On today's Internet, many hosts are behind NATs or operate host firewalls that do not respond to unsolicited packets with an ICMP port unreachable error. Thus, an attacker can construct RTSP SETUP requests with a victim's IP address and cause a flood of media packets to be sent to a victim. The addition of ICE, as described in this document, provides protection from the attack described above. By performing the ICE connectivity check, the media server receives confirmation that the RTSP client wants the media. While this protection could also be implemented by requiring the IP addresses in the SDP match the IP address of the RTSP signaling packet, such a mechanism does not protect other hosts with the same IP address (such as behind the same NAT), and such a mechanism would prohibit separating the RTSP controller from the media play-out device (e.g., an IP-enabled remote control and an IP-enabled television); it also forces RTSP proxies to relay the media streams through them, even if they would otherwise be only signaling proxies.
通过UDP传输数据包流的长期风险是主机可能对接收数据流不感兴趣。在今天的互联网上，许多主机都支持NAT或运行主机防火墙，这些主机防火墙不响应带有ICMP端口不可访问错误的未经请求的数据包。因此，攻击者可以使用受害者的IP地址构造RTSP设置请求，并导致大量媒体数据包发送给受害者。如本文件所述，添加ICE可防止上述攻击。通过执行ICE连接检查，媒体服务器收到RTSP客户端需要媒体的确认。虽然这种保护也可以通过要求SDP中的IP地址与RTSP信令分组的IP地址匹配来实现，但这种机制不保护具有相同IP地址（例如在相同NAT后面）的其他主机，并且这种机制将禁止将RTSP控制器与媒体播放设备分离（例如，启用IP的遥控器和启用IP的电视）；它还强制RTSP代理通过它们中继媒体流，即使它们本来只是信令代理。
To protect against attacks on ICE based on signaling information, RTSP signaling SHOULD be protected using TLS to prevent eavesdropping and modification of information.
为了防止基于信令信息的ICE攻击，应使用TLS保护RTSP信令，以防止窃听和修改信息。
The STUN amplification attack described in Section 18.5.2 in ICE [RFC5245] needs consideration. Servers that are able to run according to the high-reachability option have good mitigation of this attack as they only send connectivity checks towards an address and port pair from which they have received an incoming connectivity check. This means an attacker requires both the capability to spoof source addresses and to signal the RTSP server a set of ICE candidates. Independently, an ICE agent needs to implement the mitigation to reduce the volume of the amplification attack as described in the ICE specification.
ICE[RFC5245]第18.5.2节中描述的眩晕放大攻击需要考虑。能够根据“高可达性”选项运行的服务器可以很好地抵御这种攻击，因为它们只向接收到传入连接检查的地址和端口对发送连接检查。这意味着攻击者既需要欺骗源地址的能力，也需要向RTSP服务器发送一组候选ICE的信号。独立而言，ICE代理需要实施缓解措施，以减少ICE规范中所述的放大攻击量。
The logging of NAT translations is helpful to analysts, particularly in enterprises, who need to be able to map sessions when investigating possible issues where the NAT happens. When using logging on the public Internet, it is possible that the logs are large and privacy invasive, so procedures for log flushing and
NAT翻译的日志记录对分析人员很有帮助，特别是在企业中，他们需要能够在调查NAT发生的可能问题时映射会话。在公共互联网上使用日志记录时，日志可能很大且侵犯隐私，因此日志刷新和
privacy protection SHALL be in place. Care should be taken in the protection of these logs and consideration taken to log integrity, privacy protection, and purging logs (retention policies, etc.). Also, logging of connection errors and other messages established by this document can be important.
隐私保护应到位。应注意保护这些日志，并考虑日志完整性、隐私保护和清除日志（保留策略等）。此外，记录连接错误和本文档建立的其他消息也很重要。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 5245，DOI 10.17487/RFC5245，2010年4月<http://www.rfc-editor.org/info/rfc5245>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，DOI 10.17487/RFC5389，2008年10月<http://www.rfc-editor.org/info/rfc5389>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路复用RTP数据和控制数据包”，RFC 5761，DOI 10.17487/RFC5761，2010年4月<http://www.rfc-editor.org/info/rfc5761>.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, <http://www.rfc-editor.org/info/rfc6544>.
[RFC6544]Rosenberg，J.，Keranen，A.，Lowekamp，B.，和A.Roach，“具有交互式连接建立（ICE）的TCP候选者”，RFC 6544，DOI 10.17487/RFC65442012年3月<http://www.rfc-editor.org/info/rfc6544>.
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, <http://www.rfc-editor.org/info/rfc7826>.
[RFC7826]Schulzrinne，H.，Rao，A.，Lanphier，R.，Westerlund，M.，和M.Stiemering，Ed.，“实时流协议版本2.0”，RFC 7826，DOI 10.17487/RFC78262016年12月<http://www.rfc-editor.org/info/rfc7826>.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, <http://www.rfc-editor.org/info/rfc2326>.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC 2326，DOI 10.17487/RFC2326，1998年4月<http://www.rfc-editor.org/info/rfc2326>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，DOI 10.17487/RFC3022，2001年1月<http://www.rfc-editor.org/info/rfc3022>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<http://www.rfc-editor.org/info/rfc3264>.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, DOI 10.17487/RFC3489, March 2003, <http://www.rfc-editor.org/info/rfc3489>.
[RFC3489]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，DOI 10.17487/RFC3489，2003年3月<http://www.rfc-editor.org/info/rfc3489>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 4340，DOI 10.17487/RFC4340，2006年3月<http://www.rfc-editor.org/info/rfc4340>.
[RFC7604] Westerlund, M. and T. Zeng, "Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP)", RFC 7604, DOI 10.17487/RFC7604, September 2015, <http://www.rfc-editor.org/info/rfc7604>.
[RFC7604]Westerlund，M.和T.Zeng，“实时流协议（RTSP）控制的媒体不同NAT穿越技术的比较”，RFC 7604，DOI 10.17487/RFC7604，2015年9月<http://www.rfc-editor.org/info/rfc7604>.
Acknowledgments
致谢
The authors would like to thank: Remi Denis-Courmont for suggesting the method of integrating ICE in RTSP signaling, Dan Wing for help with the security section and numerous other issues, Ari Keranen for review of the document and its ICE details, and Flemming Andreasen and Alissa Cooper for a thorough review. In addition, Bill Atwood has provided comments and suggestions for improvements.
作者要感谢：Remi Denis Courmont提出了将ICE整合到RTSP信号中的方法，Dan Wing在安全部分和许多其他问题上提供了帮助，Ari Keranen审查了文件及其ICE细节，Flemming Andreasen和Alisa Cooper进行了彻底审查。此外，比尔·阿特伍德还提出了改进意见和建议。
Authors' Addresses
作者地址
Jeff Goldberg Cisco 32 Hamelacha St. South Netanya 42504 Israel
Jeff Goldberg Cisco 32 Hamelacha St.South Netanya 42504以色列
Phone: +972 9 8927222
Email: jgoldber@cisco.com
Phone: +972 9 8927222
Email: jgoldber@cisco.com
Magnus Westerlund Ericsson Farogatan 6 Stockholm SE-164 80 Sweden
Magnus Westerlund Ericsson Farogatan 6斯德哥尔摩SE-164 80瑞典
Phone: +46 8 719 0000
Email: magnus.westerlund@ericsson.com
Phone: +46 8 719 0000
Email: magnus.westerlund@ericsson.com
Thomas Zeng Nextwave Wireless, Inc. 12670 High Bluff Drive San Diego, CA 92130 United States of America
Thomas Zeng Nextwave Wireless，Inc.美国加利福尼亚州圣地亚哥高崖大道12670号，邮编92130
Phone: +1 858 480 3100
Email: thomas.zeng@gmail.com
Phone: +1 858 480 3100
Email: thomas.zeng@gmail.com