Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 7584 T. Reddy
Category: Standards Track G. Salgueiro
ISSN: 2070-1721 Cisco
July 2015
Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 7584 T. Reddy
Category: Standards Track G. Salgueiro
ISSN: 2070-1721 Cisco
July 2015
Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs)
SIP背靠背用户代理（B2BUAs）NAT（STUN）消息处理的会话遍历实用程序
Abstract
摘要
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing.
会话发起协议（SIP）背对背用户代理（B2BUA）通常设计为位于媒体路径上，而不仅仅是拦截信令。这意味着B2BUA通常作用于导致B2BUA关联和桥接在一起的分离媒体分支的媒体路径。当在媒体路径上操作时，B2BUA可能会接收NAT（STUN）数据包的会话遍历实用程序，作为交互式连接建立（ICE）处理的一部分。
This document defines behavior for a B2BUA performing ICE processing. The goal of this document is to ensure that B2BUAs properly handle SIP messages that carry ICE semantics in Session Description Protocol (SDP) and STUN messages received as part of the ICE procedures for NAT and Firewall traversal of multimedia sessions.
本文档定义了B2BUA执行ICE处理的行为。本文档的目标是确保B2BUAs正确处理会话描述协议（SDP）中包含ICE语义的SIP消息，以及作为多媒体会话NAT和防火墙穿越ICE过程一部分接收的STUN消息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7584.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7584.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 5
4. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Mandatory ICE Termination with B2BUA . . . . . . . . . . 6
4.3. Optional ICE Termination with B2BUA . . . . . . . . . . . 9
4.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SDP-Modifying Signaling-only B2BUA . . . . . . . . . . . . . 5
4. Media Plane B2BUAs . . . . . . . . . . . . . . . . . . . . . 5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Mandatory ICE Termination with B2BUA . . . . . . . . . . 6
4.3. Optional ICE Termination with B2BUA . . . . . . . . . . . 9
4.4. STUN Handling in B2BUA with Forked Signaling . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
In many SIP deployments, SIP entities exist in the SIP signaling and media path between the originating and final terminating endpoints, which go beyond the definition of a traditional SIP proxy. These SIP entities, commonly known as B2BUAs, are described in [RFC7092] and often perform functions not defined in Standards Track RFCs.
在许多SIP部署中，SIP实体存在于发起和最终终止端点之间的SIP信令和媒体路径中，这超出了传统SIP代理的定义。这些SIP实体（通常称为B2BUA）在[RFC7092]中描述，通常执行标准跟踪RFC中未定义的功能。
SIP [RFC3261] and other session control protocols that try to use a direct path for media are typically difficult to use across Network Address Translators (NATs). These protocols use IP addresses and transport port numbers encoded in the signaling, such as SDP [RFC4566] and, in the case of SIP, various header fields. Such addresses and ports are unreachable if any peers are separated by NATs.
SIP[RFC3261]和其他试图为媒体使用直接路径的会话控制协议通常很难跨网络地址转换器（NAT）使用。这些协议使用在信令中编码的IP地址和传输端口号，例如SDP[RFC4566]，在SIP的情况下，使用各种报头字段。如果任何对等方被NAT分隔，则无法访问这些地址和端口。
Mechanisms such as STUN [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and ICE [RFC5245] did not exist when protocols like SIP began to be deployed. Some mechanisms, such as the early versions of STUN, started appearing, but they were unreliable and suffered a number of issues typical for UNilateral Self-Address Fixing (UNSAF) as described in [RFC3424]. For these reasons, B2BUAs are being used by SIP domains for SIP and media-related purposes. These B2BUAs use proprietary mechanisms to enable SIP devices behind NATs to communicate across the NAT.
当像SIP这样的协议开始部署时，诸如STUN[RFC5389]、使用NAT（TURN）[RFC5766]周围的中继进行遍历以及ICE[RFC5245]等机制并不存在。一些机制，如STUN的早期版本，开始出现，但它们不可靠，并遇到了[RFC3424]中描述的单边自地址修复（UNSAF）的一些典型问题。由于这些原因，SIP域正在将B2BUA用于SIP和媒体相关目的。这些B2BUA使用专有机制使NAT后面的SIP设备能够跨NAT通信。
[RFC7362] describes how B2BUAs can perform Hosted NAT Traversal (HNT) in certain deployments. Section 5 of [RFC7362] describes some of the issues with Session Border Controllers (SBCs) implementing HNT and offers some mitigation strategies. The most commonly used approach to solve these issues is "restricted-latching", defined in Section 5 of [RFC7362], whereby the B2BUA will not latch to any packets from a source public IP address other than the one the SIP User Agent (UA) uses for SIP signaling. However, this is susceptible to attacks where an attacker who is able to see the source IP address of the SIP UA may generate packets using the same IP address. There are other threats described in Section 5 of [RFC7362] for which Secure Real-time Transport Protocol (SRTP) [RFC3711] can be used as a solution. However, this would require the B2BUAs to terminate and reoriginate SRTP, which is not always desirable.
[RFC7362]描述B2BUAs如何在某些部署中执行托管NAT遍历（HNT）。[RFC7362]第5节描述了会话边界控制器（SBC）实施HNT的一些问题，并提供了一些缓解策略。解决这些问题最常用的方法是[RFC7362]第5节中定义的“受限锁存”，其中B2BUA不会锁存到来自源公共IP地址的任何数据包，而不是SIP用户代理（UA）用于SIP信令的数据包。但是，这很容易受到攻击，能够看到SIP UA的源IP地址的攻击者可能会使用相同的IP地址生成数据包。[RFC7362]第5节中描述的其他威胁可以使用安全实时传输协议（SRTP）[RFC3711]作为解决方案。然而，这将要求B2BUA终止SRTP并对其重新排序，这并不总是可取的。
This document describes proper behavior of B2BUAs performing ICE processing. This includes defining consistent handling of SIP messages carrying ICE semantics in SDP and STUN messages received as part of the ICE procedures performed on the media path for NAT and Firewall traversal of multimedia sessions.
本文件描述B2BUAs执行冰处理的正确行为。这包括在SDP中定义对承载ICE语义的SIP消息的一致处理，以及作为在多媒体会话的NAT和防火墙穿越的媒体路径上执行的ICE过程的一部分接收的STUN消息。
A B2BUA can use ICE [RFC5245], which provides authentication tokens (conveyed in the ice-ufrag and ice-pwd attributes) that allow the identity of a peer to be confirmed before engaging in media exchange. This can solve some of the security concerns with HNT solution. Further, ICE has other benefits like selecting an address when more than one address is available (e.g., a dual-stack environment where the host can have both IPv4 and IPv6 addresses), verifying that a path works before connecting the call, etc. For these reasons, endpoints often use ICE to pick a candidate pair for media traffic between two agents.
B2BUA可以使用ICE[RFC5245]，ICE[RFC5245]提供身份验证令牌（在ICE ufrag和ICE pwd属性中传送），允许在进行媒体交换之前确认对等方的身份。这可以解决HNT解决方案的一些安全问题。此外，ICE还有其他好处，如在多个地址可用时选择一个地址（例如，主机可以同时具有IPv4和IPv6地址的双堆栈环境），在连接呼叫之前验证路径是否工作，等等。出于这些原因，端点通常使用ICE为两个代理之间的媒体流量选择候选对。
B2BUAs often operate on the media path and have the ability to modify SIP headers and SDP bodies as part of their normal operation. Such entities, when present on the media path, are likely to take an active role in the session signaling depending on their level of activity on the media path. For example, some B2BUAs modify portions of the SDP body (e.g., IP address, port) and subsequently modify the
B2BUA通常在媒体路径上运行，并且能够修改SIP头和SDP主体，作为其正常运行的一部分。当这些实体存在于媒体路径上时，根据它们在媒体路径上的活动级别，它们可能在会话信令中扮演主动角色。例如，一些B2BUA修改SDP主体的部分（例如，IP地址、端口），并随后修改SDP主体
media packet headers as well. Section 18.6 of ICE [RFC5245] explains two different behaviors when B2BUAs are present. Some B2BUAs are likely to remove all the SDP ICE attributes before sending the SDP across to the other side. Consequently, the call will appear to both endpoints as though the other side doesn't support ICE. There are other types of B2BUAs that pass the ICE attributes without modification, yet modify the default destination for media contained in the "m=" and "c=" lines and the RTCP attribute (defined in [RFC3605]). This will be detected as an ice-mismatch, and ICE processing will be aborted for the session. The session may continue if the endpoints are able to reach each other over the default candidate (sent in "m=" and "c=" lines).
媒体包头也是如此。ICE[RFC5245]第18.6节解释了存在B2BUA时的两种不同行为。一些B2BUA可能会在将SDP发送到另一端之前删除所有SDP ICE属性。因此，调用将显示在两个端点上，就好像另一端不支持ICE一样。还有其他类型的B2BUA不经修改就通过ICE属性，但修改“m=”和“c=”行中包含的媒体的默认目标和RTCP属性（在[RFC3605]中定义）。这将被检测为ice不匹配，并且会话的ice处理将中止。如果端点能够通过默认候选点（以“m=”和“c=”行发送）相互联系，则会话可以继续。
Section 3.1.3 of [RFC7092] defines a SDP-Modifying Signaling-only B2BUA that operates in the signaling plane only and is not in the media path, but it does modify SDP bodies and is thus aware of and understands SDP syntax and semantics. Such B2BUA MUST follow the behavior mentioned in Section 3.
[RFC7092]第3.1.3节定义了仅在信令平面中操作且不在媒体路径中的SDP修改信令B2BUA，但它确实修改了SDP主体，因此了解SDP语法和语义。此类B2BUA必须遵循第3节中提到的行为。
Section 3.2 of [RFC7092] describes three different categories of B2BUAs that operate on both the signaling (SIP and SDP) and media planes according to the level of involvement and active participation in the media plane:
[RFC7092]第3.2节描述了三种不同类型的B2BUA，它们根据媒体平面中的参与程度和积极参与程度在信令（SIP和SDP）和媒体平面上运行：
o A B2BUA that acts as a simple media relay. It is effectively unaware of anything that is transported and only modifies the transport header (could be UDP/IP) of the media packets.
o 充当简单媒体中继的B2BUA。它实际上不知道传输的任何内容，只修改媒体数据包的传输头（可能是UDP/IP）。
o A B2BUA that performs a media-aware role. It inspects and potentially modifies RTP or RTP Control Protocol (RTCP) headers; but it does not modify the payload of RTP/RTCP.
o 执行媒体感知角色的B2BUA。它检查并可能修改RTP或RTP控制协议（RTCP）头；但它不会修改RTP/RTCP的有效负载。
o A B2BUA that performs a media-termination role and operates at the media payload layer, such as RTP/RTCP payload (e.g., a transcoder).
o 一种B2BUA，其执行媒体终止角色并在媒体有效负载层操作，例如RTP/RTCP有效负载（例如转码器）。
When B2BUAs that operate on the media plane (media relay, media aware, or media termination) are involved in a session between two endpoints performing ICE, then it MUST follow the behavior described in Section 4.
当在媒体平面（媒体中继、媒体感知或媒体终止）上运行的B2BUA参与执行ICE的两个端点之间的会话时，必须遵循第4节中描述的行为。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
All of the pertinent B2BUA terminology and taxonomy used in this document is defined in [RFC7092].
[RFC7092]中定义了本文件中使用的所有相关B2BUA术语和分类法。
NATs are widely used in the Internet by consumers and organizations. Although specific NAT behaviors vary, this document uses the term "NAT", which maps to NAT and Network Address Port Translation (NAPT) terms from [RFC3022], for devices that map any IPv4 or IPv6 address and transport port number to another IPv4 or IPv6 address and transport port number. This includes consumer NATs, Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs (CGNs) [RFC6888], etc.
NAT在互联网上被消费者和组织广泛使用。虽然具体的NAT行为各不相同，但本文档使用术语“NAT”，将任何IPv4或IPv6地址和传输端口号映射到另一个IPv4或IPv6地址和传输端口号的设备映射到[RFC3022]中的NAT和网络地址端口转换（NAPT）术语。这包括消费者NAT、防火墙NAT、IPv4-IPv6 NAT、运营商级NAT（CGN）[RFC6888]等。
An SDP-Modifying Signaling-only B2BUA is one that operates in the signaling plane only and is not in the media path, but it modifies SDP bodies as described in Section 3.1.3 of [RFC7092]. Such B2BUAs MUST NOT change the IP address in the "c=" line, the port in the "m=" line, and the ICE semantics of SDP, as doing so can cause an ice-mismatch.
SDP修改仅信令B2BUA是仅在信令平面中操作且不在媒体路径中的SDP，但它修改SDP主体，如[RFC7092]第3.1.3节所述。此类B2BUA不得更改“c=”行中的IP地址、“m=”行中的端口以及SDP的ICE语义，因为这样做可能导致ICE不匹配。
When one or both of the endpoints are behind a NAT, and there is a B2BUA between the endpoints, the B2BUAs MUST support ICE or at a minimum support ICE lite functionality as described in [RFC5245]. Such B2BUAs MUST use the mechanism described in Section 2.2 of [RFC5245] to demultiplex STUN packets that arrive on the RTP/RTCP port.
当一个或两个端点位于NAT之后，且端点之间存在B2BUA时，B2BUA必须支持ICE或至少支持[RFC5245]中所述的ICE lite功能。此类B2BUA必须使用[RFC5245]第2.2节中描述的机制来解复用到达RTP/RTCP端口的STUN数据包。
The subsequent sections describe the behavior B2BUAs MUST follow for handling ICE messages. A B2BUA can terminate ICE and thus have two ICE contexts with either endpoint. The reason for ICE termination could be due to the need for B2BUA to be in the media path (e.g., address hiding for privacy, interworking between ICE to no-ICE, etc.). A B2BUA can also be in optional ICE termination mode and passes across the candidate list and STUN short-term credentials (ice-ufrag and ice-pwd attributes) from one endpoint to the other side after adding its own candidates. A B2BUA can be in optional ICE termination mode when it does not have a need to be on the media path. The below sections describe the behaviors for these two cases.
后续章节描述了B2BUAs处理ICE消息必须遵循的行为。B2BUA可以终止ICE，因此具有两个具有任一端点的ICE上下文。ICE终止的原因可能是由于B2BUA需要位于媒体路径中（例如，出于隐私的地址隐藏、ICE与非ICE之间的互通等）。B2BUA也可以处于可选的ICE终止模式，并在添加自己的候选者后，通过候选者列表并将短期凭证（ICE ufrag和ICE pwd属性）从一个端点传递到另一个端点。当B2BUA不需要位于介质路径上时，它可以处于可选ICE终止模式。以下部分描述了这两种情况下的行为。
A B2BUA that wishes to always be in the media path follows these steps:
希望始终位于媒体路径中的B2BUA遵循以下步骤：
o When a B2BUA sends out the SDP, it MUST advertise support for ICE and MAY include B2BUA's candidates of different types for each component of each media stream.
o 当B2BUA发送SDP时，它必须宣传对ICE的支持，并且可能包括每个媒体流的每个组件的不同类型的B2BUA候选。
o If the B2BUA is in ICE lite mode as described in Section 2.7 of [RFC5245], then it MUST send an a=ice-lite attribute and MUST include B2BUA host candidates for each component of each media stream.
o 如果B2BUA处于[RFC5245]第2.7节所述的ICE lite模式，则必须发送a=ICE lite属性，并且必须包括每个媒体流的每个组件的B2BUA主机候选。
o If the B2BUA supports full ICE, then it MAY include B2BUA's candidates of different types for each component of each media stream.
o 如果B2BUA支持全ICE，那么它可以包括用于每个媒体流的每个组件的不同类型的B2BUA候选。
o The B2BUA MUST generate new username and password values for ice-ufrag and ice-pwd attributes when it sends out the SDP and MUST NOT propagate the ufrag password values it received in the incoming SDP. This ensures that the short-term credentials used for both the legs are different. The short-term credentials include authentication tokens (conveyed in the ice-ufrag and ice-pwd attributes), which the B2BUA can use to verify the identity of the peer. The B2BUA terminates the ICE messages on each leg and does not propagate them.
o B2BUA在发送SDP时必须为ice ufrag和ice pwd属性生成新的用户名和密码值，并且不得传播其在传入SDP中接收到的ufrag密码值。这确保了用于两个分支的短期凭证是不同的。短期凭证包括认证令牌（在ice ufrag和ice pwd属性中传送），B2BUA可以使用这些令牌来验证对等方的身份。B2BUA终止每个分支上的ICE消息，并且不传播它们。
o The B2BUA MUST NOT propagate the candidate list received in the incoming SDP to the outbound SDP and instead only advertise its candidate list. The B2BUA MUST also add its default candidate in the "c=" line (IP address) and "m=" line (port). In this way, the B2BUA will be always in the media path.
o B2BUA不得将传入SDP中接收到的候选列表传播到出站SDP，而只能公布其候选列表。B2BUA还必须在“c=”行（IP地址）和“m=”行（端口）中添加其默认候选项。这样，B2BUA将始终位于媒体路径中。
o Depending on whether the B2BUA supports ICE lite or full ICE, it implements the appropriate procedures mentioned in [RFC5245] for ICE connectivity checks.
o 根据B2BUA是支持ICE lite还是完全ICE，它执行[RFC5245]中提到的ICE连接检查的适当程序。
+-------+ +-------------------+ +-----+
| Alice | | Media Plane B2BUA | | Bob |
+-------+ +-------------------+ +-----+
|(1) INVITE |(3) INVITE |
| a=ice-ufrag1 | a=ice-ufrag2 |
| a=ice-pwd1 | a=ice-pwd2 |
| (Alice's IP, port) | (B2BUA's IP, port) |
| (Alice's candidate list)| (B2BUA's candidate list)|
|------------------------>|-------------------------->|
| | |
|(2) 100 trying | |
|<------------------------| |
| |(4) 100 trying |
| |<--------------------------|
| | |
| |(5) 200 OK |
| | a=ice-ufrag3 |
| | a=ice-pwd3 |
| | (Bob's IP, port) |
| | (Bob's candidate list) |
| |<--------------------------|
|(6) 200 OK | |
| a=ice-ufrag4 |-----------ACK------------>|
| a=ice-pwd4 | (7) |
| (B2BUA's IP, port) | |
|(B2BUA's candidate list1)| |
|<------------------------| |
| | |
|--------ACK------------->| |
| (8) | |
| | |
|<----ICE Connectivity 1->| |
| checks+conclusion |<-----ICE Connectivity 2-->|
| (9) | checks+conclusion |
| | (10) |
| | |
|<-------Media packets--->|<----Media packets-------->|
| (11) | (12) |
| | |
|<---ICE keepalives 1---->| |
| (13) |<----ICE keepalives 2----->|
(13)
+-------+ +-------------------+ +-----+
| Alice | | Media Plane B2BUA | | Bob |
+-------+ +-------------------+ +-----+
|(1) INVITE |(3) INVITE |
| a=ice-ufrag1 | a=ice-ufrag2 |
| a=ice-pwd1 | a=ice-pwd2 |
| (Alice's IP, port) | (B2BUA's IP, port) |
| (Alice's candidate list)| (B2BUA's candidate list)|
|------------------------>|-------------------------->|
| | |
|(2) 100 trying | |
|<------------------------| |
| |(4) 100 trying |
| |<--------------------------|
| | |
| |(5) 200 OK |
| | a=ice-ufrag3 |
| | a=ice-pwd3 |
| | (Bob's IP, port) |
| | (Bob's candidate list) |
| |<--------------------------|
|(6) 200 OK | |
| a=ice-ufrag4 |-----------ACK------------>|
| a=ice-pwd4 | (7) |
| (B2BUA's IP, port) | |
|(B2BUA's candidate list1)| |
|<------------------------| |
| | |
|--------ACK------------->| |
| (8) | |
| | |
|<----ICE Connectivity 1->| |
| checks+conclusion |<-----ICE Connectivity 2-->|
| (9) | checks+conclusion |
| | (10) |
| | |
|<-------Media packets--->|<----Media packets-------->|
| (11) | (12) |
| | |
|<---ICE keepalives 1---->| |
| (13) |<----ICE keepalives 2----->|
(13)
Figure 1: INVITE with SDP Having ICE and with a Media Plane B2BUA Terminating ICE
图1：SDP具有ICE且媒体平面B2BUA终止ICE的INVITE
The above figure shows an example call flow with two endpoints, Alice and Bob, using ICE processing, and a B2BUA handing STUN messages from both the endpoints. For the sake of brevity, the entire list of ICE SDP attributes are not shown. Also, the STUN messages exchanged as part of ICE connectivity checks are not shown. Key steps to note from the call flow are:
上图显示了一个示例调用流，其中两个端点Alice和Bob使用ICE处理，一个B2BUA处理来自两个端点的STUN消息。为简洁起见，不显示ICE SDP属性的整个列表。此外，作为ICE连接检查的一部分交换的STUN消息未显示。呼叫流程中需要注意的关键步骤包括：
o Alice sends an INVITE with SDP having ICE candidates.
o Alice发送邀请，SDP邀请ICE候选人。
o The B2BUA modifies the received SDP from Alice by removing the received candidate list, gathering its own candidates, and generating new username and password values for ice-ufrag and ice-pwd attributes. The B2BUA also changes the "c=" line and "m=" line to have its default candidate and forwards the INVITE (Step 3) to Bob.
o B2BUA通过删除接收到的候选列表、收集自己的候选项并为ice ufrag和ice pwd属性生成新的用户名和密码值，修改从Alice接收到的SDP。B2BUA还将“c=”行和“m=”行更改为其默认候选行，并将邀请（步骤3）转发给Bob。
o Bob responds (Step 5) to the INVITE with his own list of candidates.
o Bob用自己的候选人名单回应邀请（第5步）。
o The B2BUA responds to the INVITE from Alice with SDP having a B2BUA candidate list. The B2BUA generates new username and password values for ice-ufrag and ice-pwd attributes in the 200 OK response (Step 6).
o B2BUA响应Alice的邀请，SDP具有B2BUA候选列表。B2BUA在200 OK响应中为ice ufrag和ice pwd属性生成新的用户名和密码值（步骤6）。
o ICE Connectivity checks happen between Alice and the B2BUA in Step 9. Depending on whether the B2BUA supports ICE or ICE lite, it will follow the appropriate procedures mentioned in [RFC5245]. ICE Connectivity checks also happen between Bob and the B2BUA in Step 10. Steps 9 and 10 happen in parallel. The B2BUA always terminates the ICE messages on each leg and has two independent ICE contexts running.
o ICE连接检查在步骤9中Alice和B2BUA之间进行。根据B2BUA是否支持ICE或ICE lite，它将遵循[RFC5245]中提到的适当程序。在步骤10中，Bob和B2BUA之间也会进行ICE连接检查。第9步和第10步同时进行。B2BUA始终终止每个分支上的ICE消息，并运行两个独立的ICE上下文。
o Media flows between Alice and Bob via B2BUA (Steps 11 and 12).
o Alice和Bob之间通过B2BUA的媒体流（步骤11和12）。
o STUN keepalives would be used between Alice and B2BUA (Step 13) and between Bob and B2BUA (Step 14) to keep NAT and Firewall bindings alive.
o 将在Alice和B2BUA之间（步骤13）和Bob和B2BUA之间（步骤14）使用STUN keepalives来保持NAT和防火墙绑定的活动状态。
Since there are two independent ICE contexts on either side of the B2BUA, it is possible that ICE checks will conclude on one side before concluding on the other side. This could result in an ongoing media session for one end while the other is still being set up. Any such media received by the B2BUA would continue to be sent to the other side on the default candidate address (that was sent in "c=" line).
由于B2BUA的任何一侧都有两个独立的ICE上下文，因此ICE检查有可能在一侧结束，然后在另一侧结束。这可能会导致一端正在进行媒体会话，而另一端仍在设置中。B2BUA接收到的任何此类媒体将继续以默认候选地址（以“c=”行发送）发送给另一方。
A B2BUA willing to be in the media path only for NAT traversal, but that does not otherwise require to be in the media path, can do the following steps mentioned in this section.
B2BUA只希望位于NAT穿越的媒体路径中，但不需要位于媒体路径中，可以执行本节中提到的以下步骤。
o When a B2BUA receives an incoming SDP with ICE semantics, it copies the received candidate list and appends its own candidate list in the outgoing SDP. The B2BUA also copies the ufrag/ password values it received in the incoming SDP to the outgoing SDP and then sends out the SDP.
o 当B2BUA接收到具有ICE语义的传入SDP时，它复制接收到的候选列表并将其自己的候选列表附加到传出SDP中。B2BUA还将其在传入SDP中接收到的ufrag/密码值复制到传出SDP，然后发送SDP。
o The B2BUA's candidates MAY have lower priority than the candidates provided by the endpoint, this way the endpoint and remote peer candidate pairs are tested first before trying candidate pairs with B2BUA's candidates.
o B2BUA的候选者可能比端点提供的候选者具有更低的优先级，这样，在尝试与B2BUA候选者的候选者配对之前，首先测试端点和远程对等候选者配对。
o After offer/answer is complete, the endpoints will have both the B2BUAs and remote peer candidates. It will then use ICE procedures described in Section 8 of [RFC5245] to nominate a candidate pair for sending and receiving media streams.
o 在提供/应答完成后，端点将同时具有B2BUAs和远程对等候选。然后，它将使用[RFC5245]第8节中描述的ICE程序来指定用于发送和接收媒体流的候选对。
o With this approach, the B2BUA will be in the media path only if the ICE checks between all the candidate pairs formed from both the endpoints fail.
o 使用这种方法，只有当从两个端点形成的所有候选对之间的ICE检查失败时，B2BUA才会位于媒体路径中。
+-------+ +-------------------+ +-----+
| Alice | | Media Plane B2BUA | | Bob |
+-------+ +-------------------+ +-----+
|(1) INVITE |(3) INVITE |
| a=ice-ufrag1 | a=ice-ufrag1 |
| a=ice-pwd1 | a=ice-pwd1 |
| (Alice's IP, port) | (Alice's IP, port) |
|(Alice's candidate list) | (Alice's candidate list + |
| | B2BUA's candidate list1) |
|------------------------>|-------------------------->|
| | |
|(2) 100 trying | |
|<------------------------| |
| |(4) 100 trying |
| |<--------------------------|
| | |
| |(5) 200 OK |
| | a=ice-ufrag2 |
| | a=ice-pwd2 |
| | (Bob's IP, port) |
| | (Bob's candidate list) |
| |<--------------------------|
|(6) 200 OK | |
| a=ice-ufrag2 |-----------ACK------------>|
| a=ice-pwd2 | (7) |
| (Bob's IP,port) | |
|(B2BUA's candidate list2 | |
| + Bob's candidate list) | |
|<------------------------| |
| | |
|----------ACK----------->| |
| (8) | |
| | |
|<----ICE Connectivity 1 (9)------------------------->|
| | |
|<----ICE Connectivity 2->| |
| checks+conclusion |<-----ICE Connectivity 2-->|
| (10) | checks+conclusion |
| | (11) |
| | |
|<-------------------Media packets------------------->|
| (12) |
| | |
|<------------------ICE keepalives------------------->|
(13)
+-------+ +-------------------+ +-----+
| Alice | | Media Plane B2BUA | | Bob |
+-------+ +-------------------+ +-----+
|(1) INVITE |(3) INVITE |
| a=ice-ufrag1 | a=ice-ufrag1 |
| a=ice-pwd1 | a=ice-pwd1 |
| (Alice's IP, port) | (Alice's IP, port) |
|(Alice's candidate list) | (Alice's candidate list + |
| | B2BUA's candidate list1) |
|------------------------>|-------------------------->|
| | |
|(2) 100 trying | |
|<------------------------| |
| |(4) 100 trying |
| |<--------------------------|
| | |
| |(5) 200 OK |
| | a=ice-ufrag2 |
| | a=ice-pwd2 |
| | (Bob's IP, port) |
| | (Bob's candidate list) |
| |<--------------------------|
|(6) 200 OK | |
| a=ice-ufrag2 |-----------ACK------------>|
| a=ice-pwd2 | (7) |
| (Bob's IP,port) | |
|(B2BUA's candidate list2 | |
| + Bob's candidate list) | |
|<------------------------| |
| | |
|----------ACK----------->| |
| (8) | |
| | |
|<----ICE Connectivity 1 (9)------------------------->|
| | |
|<----ICE Connectivity 2->| |
| checks+conclusion |<-----ICE Connectivity 2-->|
| (10) | checks+conclusion |
| | (11) |
| | |
|<-------------------Media packets------------------->|
| (12) |
| | |
|<------------------ICE keepalives------------------->|
(13)
Figure 2: INVITE with SDP Having ICE and with a Media Plane B2BUA in Optional ICE Termination Mode
图2：SDP具有ICE且媒体平面B2BUA处于可选ICE终止模式的INVITE
The above figure shows a sample call flow with two endpoints, Alice and Bob, doing ICE, and a B2BUA handing STUN messages from both the endpoints. For the sake of brevity, the entire ICE SDP attributes are not shown. Also, the STUN messages exchanged as part of the ICE connectivity checks are not shown. Key steps to note from the call flow are:
上图显示了一个示例调用流，其中两个端点Alice和Bob执行ICE，一个B2BUA处理来自两个端点的STUN消息。为简洁起见，未显示整个ICE SDP属性。此外，作为ICE连接检查的一部分交换的STUN消息未显示。呼叫流程中需要注意的关键步骤包括：
o Alice sends an INVITE with an SDP having its own candidate list.
o Alice发送一个邀请，SDP有自己的候选列表。
o The B2BUA propagates the received candidate list in incoming SDP from Alice after adding its own candidate list. The B2BUA also propagates the received ice-ufrag and ice-pwd attributes from Alice in the INVITE (Step 3) to Bob. In this example, the B2BUA does not modify the default candidate sent in the "c=" line and "m=" line and retains the values sent originally from Alice. If B2BUA wants to be in the media path when ICE connectivity checks between endpoints fails or one of the endpoints does not support ICE, then it overwrites its candidate address and port as a default candidate in the "m=" and "c=" lines.
o B2BUA在添加自己的候选列表后，在来自Alice的传入SDP中传播接收到的候选列表。B2BUA还将从INVITE（步骤3）中的Alice接收到的ice ufrag和ice pwd属性传播给Bob。在本例中，B2BUA不会修改在“c=”行和“m=”行中发送的默认候选项，并保留最初从Alice发送的值。如果当端点之间的ICE连接检查失败或其中一个端点不支持ICE时，B2BUA希望位于媒体路径中，则B2BUA会在“m=”和“c=”行中将其候选地址和端口覆盖为默认候选地址和端口。
o Bob responds (Step 5) to the INVITE with his own list of candidates.
o Bob用自己的候选人名单回应邀请（第5步）。
o The B2BUA responds to the INVITE from Alice with an SDP having a B2BUA's candidate list and the candidate list received from Bob. The B2BUA would also propagate the received ice-ufrag and ice-pwd attributes from Bob in (Step 5) to Alice in the 200 OK response (Step 6).
o B2BUA使用SDP响应Alice的邀请，SDP具有B2BUA的候选列表和从Bob收到的候选列表。B2BUA还将在200 OK响应（步骤6）中将接收到的ice ufrag和ice pwd属性从Bob in（步骤5）传播到Alice。
o ICE Connectivity checks happen between Alice and Bob in (Step 9). ICE Connectivity checks also happen between Alice and the B2BUA and Bob and the B2BUA as shown in Steps 10 and 11. Steps 9, 10, and 11 happen in parallel. In this example, Alice and Bob conclude ICE with a candidate pair that enables them to send media directly.
o ICE连接检查在Alice和Bob之间进行（步骤9）。ICE连接检查也会在Alice和B2BUA以及Bob和B2BUA之间进行，如步骤10和11所示。步骤9、10和11同时发生。在本例中，Alice和Bob以一对候选对结束ICE，这使他们能够直接发送媒体。
o Media flows between Alice and Bob in Step 12.
o 步骤12中Alice和Bob之间的媒体流。
Because of forking, a B2BUA might receive multiple answers for a single outbound INVITE. When this occurs, the B2BUA SHOULD follow Sections 3.2 or 3.3 for all of those received answers.
由于分叉，B2BUA可能会收到单个出站邀请的多个答案。发生这种情况时，B2BUA应遵循第3.2节或第3.3节的规定，以获取所有收到的答案。
As described in Section 2.5 of [RFC5245], ICE uses the STUN short-term credential mechanism for authentication and message integrity. STUN connectivity checks include the MESSAGE-INTEGRITY attribute that contains HMAC-SHA1 of the STUN message, and the Hashed Message Authentication Code (HMAC) is computed using the key exchanged in the signaling channel. The signaling channel between the endpoints and B2BUA MUST be encrypted so that the key is not visible to eavesdroppers, otherwise the security benefits of short-term authentication would be lost.
如[RFC5245]第2.5节所述，ICE使用STUN短期凭证机制进行身份验证和消息完整性。STUN连接检查包括包含STUN消息的HMAC-SHA1的消息完整性属性，并且使用信令信道中交换的密钥计算哈希消息身份验证码（HMAC）。端点和B2BUA之间的信令通道必须加密，以便窃听者看不到密钥，否则短期身份验证的安全优势将丢失。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<http://www.rfc-editor.org/info/rfc3711>.
[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>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，DOI 10.17487/RFC5766，2010年4月<http://www.rfc-editor.org/info/rfc5766>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <http://www.rfc-editor.org/info/rfc7092>.
[RFC7092]Kaplan，H.和V.Pascual，“会话启动协议（SIP）背对背用户代理的分类”，RFC 7092，DOI 10.17487/RFC7092，2013年12月<http://www.rfc-editor.org/info/rfc7092>.
[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>.
[RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, DOI 10.17487/RFC3424, November 2002, <http://www.rfc-editor.org/info/rfc3424>.
[RFC3424]Daigle，L.，Ed.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 3424DOI 10.17487/RFC3424，2002年11月<http://www.rfc-editor.org/info/rfc3424>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, <http://www.rfc-editor.org/info/rfc3605>.
[RFC3605]Huitema，C.，“会话描述协议（SDP）中的实时控制协议（RTCP）属性”，RFC 3605，DOI 10.17487/RFC3605，2003年10月<http://www.rfc-editor.org/info/rfc3605>.
[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>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <http://www.rfc-editor.org/info/rfc6888>.
[RFC6888]Perreault，S.，Ed.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级NAT（CGN）的通用要求”，BCP 127，RFC 6888，DOI 10.17487/RFC6888，2013年4月<http://www.rfc-editor.org/info/rfc6888>.
[RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication", RFC 7362, DOI 10.17487/RFC7362, September 2014, <http://www.rfc-editor.org/info/rfc7362>.
[RFC7362]Ivov，E.，Kaplan，H.，和D.Wing，“闭锁：实时通信中媒体的托管NAT穿越（HNT）”，RFC 7362，DOI 10.17487/RFC7362，2014年9月<http://www.rfc-editor.org/info/rfc7362>.
Acknowledgements
致谢
Special thanks to Dan Wing, Pal Martinsen, Charles Eckel, Marc Petit-Huguenin, Simon Perreault, Lorenzo Miniero, Ari Keranen, and Parthasarathi Ravindran for their constructive comments, suggestions, and early reviews that were critical to the formulation and refinement of this document.
特别感谢Dan Wing、Pal Martinsen、Charles Eckel、Marc Petit Hugunin、Simon Perreault、Lorenzo Miniero、Ari Keranen和Parthasarathi Ravindran提出的建设性意见、建议以及对本文件的制定和完善至关重要的早期审查。
Thanks to Ben Campbell, Barry Leiba, Nevil Brownlee, Spencer Dawkins, Sam Hartman, Stephen Farrell, Kathleen Moriarty, and Francis Dupont for their thoughtful review comments.
感谢本·坎贝尔、巴里·莱巴、内维尔·布朗利、斯宾塞·道金斯、萨姆·哈特曼、斯蒂芬·法雷尔、凯萨琳·莫里亚蒂和弗朗西斯·杜邦发表了深思熟虑的评论。
Authors' Addresses
作者地址
Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India
Ram Mohan Ravindranath Cisco Systems，Inc.印度卡纳塔克邦班加罗尔市瓦尔图尔霍布里萨尔贾普尔马拉塔哈利外环路塞斯纳商业园560103
Email: rmohanr@cisco.com
Email: rmohanr@cisco.com
Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Tirumaleswar Reddy Cisco Systems，Inc.印度卡纳塔克邦班加罗尔外环路瓦图尔霍布里萨贾普尔马拉塔利塞斯纳商业园560103
Email: tireddy@cisco.com
Email: tireddy@cisco.com
Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States
Gonzalo Salgueiro Cisco Systems，Inc.美国北卡罗来纳州Kit Creek Road研究三角公园7200-12号，邮编：27709
Email: gsalguei@cisco.com
Email: gsalguei@cisco.com