【RFC6405 IP 电话 (VoIP) SIP 对等互连用例 VoIP SIP Peering Use Cases】（翻译）

原文 rfc6405 (ietf.org) Voice over IP (VoIP) SIP Peering Use Cases IP 电话 (VoIP) SIP 对等互连用例

概述

本文档描述了会话发起协议 (SIP) 对等互连的许多常见 IP 语音 (VoIP) 用例。这些用例分为静态的和按需的，然后进一步细分为直接和间接。这些用例并不是一个详尽的集合，而是当今部署的最常见的用例。

本文档不是 Internet Standards Track 规范；它是为了信息化目的而发布的。
本文档是 Internet Engineering Task Force (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导组 (IESG) 批准出版。并非所有 IESG 批准的文件都适用于任何级别的互联网标准；请参阅 RFC 5741 的第 2 节。

有关本文档当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc6405.

1. 简介
2. 术语
3. 参考架构
4. 用例的上下文
5. 用例
5.1.静态对等互连用例
5.2.静态直接对等互连用例
5.2.1.管理特征
5.2.2.选项和细微差别
5.3.静态直接对等互连用例 - 协助 LUF 和 LRF
5.3.1.管理特征
5.3.2.选项和细微差别
5.4.静态间接对等互连用例 - 协助 LUF 和 LRF
5.4.1.管理特征
5.4.2.选项和细微差别
5.5.静态间接对等互连用例
5.5.1.管理特征
5.5.2.选项和细微差别
5.6.按需对等互连用例
5.6.1.管理特征
5.6.2.选项和细微差别
6. 致谢
7. 安全考虑
8. 参考文献
8.1.规范参考
8.2.参考资料

1. 简介

本文档描述了基于 SIP 的 [RFC3261] 对等互连的重要 IP 语音 (VoIP) 用例。这些用例由多媒体互连会话对等互连 (SPEERMINT) 工作组确定，并将有助于确定工作组将来要考虑的要求和其他问题。
本文档仅考虑与 VoIP 相关的用例。其他实时 SIP 通信用例，如即时消息 (IM)、视频聊天和在线状态不在本文档的讨论范围内。
本文档中包含的用例尽可能全面地描述，但不应被视为唯一的用例集。

2. 术语

本文档使用 [RFC5486] 中定义的术语。请参考它的定义。

3. 参考架构

下图为读者提供了本文档中 VoIP 用例的上下文。 [RFC5486] 中定义了诸如 SIP 服务提供商 (SSP)、查找功能 (LUF)、位置路由功能 (LRF)、信令路径边界元素 (SBE) 和数据路径边界元素 (DBE) 等术语。
发起的SSP (O-SSP) 是发起 SIP 请求的 SSP。终止的SSP (T-SSP) 是终止源自 O-SSP 的 SIP 请求的 SSP。辅助 LUF 和 LRF 提供商向 O-SSP 提供 LUF 和 LRF 服务。间接 SSP (I-SSP) 是向 O-SSP 提供间接对等服务以连接到 T-SSP 的 SSP.

请注意，图 1 中包含的某些元素是可选的。

4. 用例的上下文

用例分为两大类：静态的和按需的对等互连 [RFC5486]。每个组可以进一步细分为直接对等和间接对等 [RFC5486]。尽管这些类别中的用例之间可能存在一些重叠，但场景之间存在不同的要求。每个用例都必须指定一组基本的必需操作，以便在对等互连时每个 SSP 执行。

这些可以包括：
o 对等发现 - 通过查找功能 (LUF) 进行对等发现，以确定请求的会话建立数据 (SED [RFC5486]。在 VoIP 用例中，请求通常包含一个电话号码。 O-SSP 会将电话号码输入到 LUF，而 LUF 通常会返回包含域名的 SIP 地址记录 (AOR) [RFC3261]。
o 下一跳路由确定 - 解析 SED 信息是将请求路由到 T-SSP 所必需的。 LRF 用于这个确定。 O-SSP 获得 SED 后，可以使用[RFC3263]中定义的标准流程来发现下一跳地址。
o 呼叫建立 - 相互互连的 SSP 还可以定义在联系下一跳时需要使用什么对等策略的细节，以便 a) 完全到达下一跳和 b) 证明发送方是合法的对等互连伙伴。示例：硬编码传输 (TCP/UDP/TLS)、非标准端口号、特定源 IP 地址（例如，在私有第 3 层网络中）、要使用的 TLS 客户端证书 [RFC5246] 以及其他身份验证方案。
o 呼叫接收 - 此步骤确保了解和接受关系类型（静态或按需、间接或直接）。例如，接收 SBE 需要确定它收到的 INVITE 是否真的来自受信任的成员。

5. 用例

请注意，用例中有域内消息流作为支持背景信息。只有域间通信与本文档密切相关。

5.1.静态对等互连用例

静态对等 [RFC5486] 描述了当两个 SSP 与在交换流量之前建立的某种形式的关联形成对等关系时的用例。预关联是静态对等互连的先决条件。当两个对等点需要一致且严格控制的对等方法时，将使用静态对等互连。在这种情况下，可以预先定义许多变量，例如识别方法（远程代理 IP 地址）和服务质量 (QoS) 参数，并在对等互连之前由每个 SSP 了解。

5.2.静态直接对等互连用例

这是对等互连用例的最简单形式。两个 SSP 协商并同意建立 SIP 对等关系。对等连接是静态配置的，对等 SSP 直接连接。在建立互连之前，对等体可以交换互连参数，例如差分服务代码点 (DSCP) [RFC2474] 策略、每秒最大请求数和代理位置。通常，T-SSP 只接受直接来自受信任对等方的流量。

以下是用例的高级描述：
1. 用户代理客户端 (UAC) 通过 SIP INVITE 向 O-Proxy 发起呼叫。 O-Proxy 是 UAC 的本地代理。

请注意，UAC 在 VIA 和 CONTACT 头部中插入了其完全限定域名 (FQDN)。此示例假设 UAC 有自己的 FQDN。

2. UAC 知道用户代理服务器 (UAS) 的 TN，但不知道 UAS 的域。它附加自己的域以在 Request-URI 和 TO 头部中生成 SIP URI。 O-Proxy 检查 Request-URI 并发现 Request-URI 包含用户参数“user=phone”。此参数表示 Request-URI 是电话号码。因此，O-Proxy 将从请求 URI 中提取 TN 并从路由数据库中查询 LUF 以获取 SED 信息。在这个例子中，LUF 是一个 ENUM [RFC6116] 数据库。 ENUM 条目类似于以下内容：

此 SED 数据可由 O-SSP 提供或由 T-SSP 填充。
3. O-Proxy 检查 SED 并发现域是外部的。鉴于 O-Proxy 的内部路由策略，O-Proxy 决定使用 O-SBE 到达 T-SBE。 O-Proxy 将 INVITE 请求路由到 O-SBE 并添加一个包含 O-SBE 的路由头。

4. O-SBE 接收请求并弹出包含“o-sbe1.example.com”的Route 头的顶部条目。 O-SBE 检查请求 URI 并为“example.net”执行 LRF。在此示例中，LRF 是域名的命名机构指针 (NAPTR) DNS 查询 [RFC3403]。 O-SBE 收到来自 LRF 的 NAPTR 响应。响应类似于以下内容：

5. 鉴于 NAPTR 响应中 TCP 的较低顺序，O-SBE 决定使用 TCP 作为传输协议，因此它为“_sip._tcp.t-sbe.example”发送 SRV 记录 [RFC2782] 的 SRV DNS 查询。"_sip._tcp.t- sbe.example.net." 到 O-LRF.

6. 鉴于“t-sbe1.example.net”的权重较高，O-SBE 会发送“t-sbe1.example.net”的 A 记录 DNS 查询。获取A记录：

7. O-SBE 向 T-SBE 发送 INVITE。 O-SBE 是 O-SSP 域的出口点，因此它应该确保后续的中间对话请求通过自身遍历。如果 O-SBE 选择充当背靠背用户代理 (B2BUA) [RFC3261]，它将在下一步生成新的 INVITE 请求。如果 O-SBE 选择充当代理，它应该记录路由(Record-Route)以留在呼叫路径中。在这个例子中，O-SBE 是一个 B2BUA.

请注意，O-SBE 可能会使用 SIP URI 中的目标域重写 Request-URI。如果 Request-URI 包含他们自己的域，一些代理实现将只接受请求。
8. T-SBE 确定被叫方归属代理并将呼叫定向到被叫方。 T-SBE 可以使用 ENUM 查找或其他内部机制来定位本地代理。如果 T-SSP 使用 ENUM 查找，则此内部 ENUM 条目与为 O-SSP 填充的外部 ENUM 条目不同。在这个例子中，内部 ENUM 查询返回 UAS 的本地代理。

9、T-SBE收到NAPTR记录，按照[RFC3263]中的要求，向DNS查询NAPTR结果指示的SRV记录。没有找到，T-SBE 然后查询 DNS 以获取域“t-proxy.example.net.”的 A 记录。

10. T-SBE是一个B2BUA，所以它会生成一个新的INVITE并发送给UAS的家乡代理home proxy：

11. 最后，UAS的家乡代理转发INVITE请求给UAS.

12. UAC 和 UAS 之间建立 RTP。请注意，图 2 中所示的介质通过 O-DBE 和 T-DBE，但 DBE 的使用是可选的。

5.2.1.管理特征
静态直接对等互连用例通常在两个管理域之间存在高度信任的场景中实现。两个管理域通常都会签署一份对等协议，明确说明政策和条款。

5.2.2.选项和细微差别
在图 2 中，O-SSP 和 T-SSP 通过 SBE 对等。通常，运营商将在其管理域的边缘部署 SBE。信令流量将通过 SBE 在两个网络之间传递。运营商部署 SBE 的原因有很多。例如，O-SSP 可以将 [RFC1918] 地址用于他们的 UA 和代理。这些地址在目标网络中不可路由。 SBE 可以执行 NAT 功能。此外，SBE 降低了部署或移除第 5 层网络元素的运营成本。考虑多个代理连接到单个 SBE 的部署架构。运营商无需与对等运营商协调即可添加或删除代理。对等运营商仅“看到”SBE。只要SBE保持在路径中，就不需要通知对端运营商。

当运营商部署SBE时，运营商需要将SBE通告给对等LRF，以便对等运营商定位SBE并相应地将流量路由到SBE。

SBE 部署是管理域内的决策。一个或两个管理域可以决定部署 SBE。对于对等网络，最重要的是识别下一跳地址。这个决定不会影响网络识别下一跳地址的能力。

5.3. 静态直接对等互连用例 - 协助 LUF 和 LRF

此用例与静态直接对等互连用例第 5.2 节共享许多属性。 O-SSP 和 T-SSP 之间必须存在预关联。不同之处在于 O-SSP 将为 LUF 和 LRF 使用 Assisting LUF/LRF Provider。 LUF/LRF Provider 存储 SED 以到达 T-SSP，并在 O-SSP 请求时将其提供给 O-SSP.

除了步骤 2、4、5 和 6 涉及 LUF/LRF 提供程序而不是发生在 O-SSP 域中之外，呼叫流程看起来几乎与静态直接对等互连用例相同。

与静态直接对等互连用例类似，图 3 中的 O-DBE 和 T-DBE 是可选的。

5.3.1. 管理特征
LUF/LRF Provider 为 O-SSP 提供 LUF 和 LRF 服务。 LUF/LRF Provider、O-SSP 和 T-SSP 共同构成了一个受信任的管理域。为了达到 T-SSP，O-SSP 仍然需要预先安排好与 T-SSP 的对等关系的协议。第 5 层策略在 O-SSP 和 T-SSP 域中维护，LUF/LRF 提供者可能不知道 O-SSP 和 T-SSP 之间的任何第 5 层策略。

LUF/LRF Provider 可以为多个管理域提供服务。 LUF/LRF 提供程序通常不会在未经适当许可的情况下将 SED 从一个管理域共享到另一个管理域。

5.3.2.选项和细微差别
LUF/LRF Provider 可以使用多种方法向 O-SSP 提供 SED。最常用的是 ENUM 查找和 SIP 重定向。
在向 LUF/LRF 提供者发送请求之前，O-SSP 应与 LUF/LRF 提供者协商它将使用哪种查询方法。

LUF/LRF 提供者必须填充 T-SSP 的 AOR 和 SED。目前，该程序是非标准化和劳动密集型的。正在进行的工作 [DRINKS] 中记录了对该问题的更详细描述。

5.4.静态间接对等互连用例 - 协助 LUF 和 LRF

静态直接用例和静态间接用例之间的区别在于 O-SSP 和 T-SSP 维护的第 5 层关系。在间接用例中，O-SSP 和 T-SSP 没有直接的第 5 层连接。它们需要一个或多个间接域来帮助路由 SIP 消息和可能的相关媒体。

在这个用例中，O-SSP 和 T-SSP 想要形成对等关系。由于某种原因，O-SSP 和 T-SSP 没有直接的第 5 层连接。原因可能会有所不同，例如，业务需求和/或域策略控制。由于这种间接关系，信令将从O-SSP经过一个或多个I-SSP到达T-SSP。

此外，O-SSP 正在使用 LUF/LRF 提供程序。该 LUF/LRF 提供程序存储由 T-SSP 预先填充的 T-SSP 的 SED。使用 LUF/LRF 提供程序的一个重要动机是 T-SSP 只需向提供程序填充一次其 SED。使用 LUF/LRF Provider 允许 T-SSP 填充其 SED 一次，而任何 O-SSP T-SSP 的 SED 都可以使用此 LUF/LRF Provider。当前的实践表明，T-SSP 将其 SED 填充到每个必须到达 T-SSP 订户的 O-SSP 是相当困难的。在企业环境中尤其如此。

请注意，LUF/LRF Provider 和 I-SSP 可以是相同的提供商，也可以是不同的提供商。

以下是用例的高级描述：

1. UAC通过SIP INVITE向O-Proxy发起呼叫。 O-Proxy 是 UAC 的归属代理。

2. UAC知道UAS的TN，但不知道UAS的域。它附加自己的域以在 Request-URI 和 TO 标头中生成 SIP URI。 O-Proxy 检查 Request-URI 并发现 Request-URI 包含用户参数“user=phone”。该参数表明Request-URI 是一个电话号码。因此，O-Proxy 将从请求 URI 中提取 TN 并从路由数据库中查询 LUF 以获取 SED 信息。在这个例子中，LUF 是一个 ENUM 数据库。 ENUM 条目类似于以下内容：

请注意，响应显示下一跳是 I-SSP 中的 SBE。
或者，O-SSP 可以与 I-SSP 有预关联。因此，O-SSP 会将所有在 Request-URI 中包含外部域或未知 TN 的请求转发给 I-SSP。 O-SSP 将依赖 I-SSP 来确定 T-SSP 并正确路由请求。在这种配置中，O-SSP 可以跳过步骤 2、4、5 和 6，直接将请求转发给 I-SBE。这种配置通常用于企业环境。

3. 给定O-Proxy的内部路由策略，O-Proxy决定使用O-SBE到达I-SBE。 O-Proxy 将 INVITE 请求路由到 O-SBE 并添加包含 O-SBE 的路由头。

4. O-SBE 接收请求并弹出包含“sip:o-sbe1.example.com”的Route 头的顶部条目。 O-SBE 检查请求 URI 并为“example.org”执行 LRF。在本例中，LRF 是域的 NAPTR DNS 查询。 O-SBE 收到与此类似的响应：

5. 鉴于 NAPTR 响应中 TCP 的较低顺序，O-SBE 决定使用 TCP 作为传输协议，因此它发送 SRV DNS 查询以获取“_sip._tcp.i-sbe.example.org”的 SRV 记录。 ” 到 O-LRF.

6. 鉴于“i-sbe1.example.org”的较高权重，O-SBE 发送 DNS 查询以获取“i-sbe1.example.org”的 A 记录。获取A记录：

7. O-SBE 向 I-SBE 发送 INVITE。 O-SBE 是 O-SSP 域的入口点，因此它应该确保后续的中间对话请求通过自身遍历。如果 O-SBE 选择充当 B2BUA，它将在下一步中生成一个新的背靠背 INVITE 请求。如果 O-SBE 选择充当代理，它应该记录路由以留在呼叫路径中。在这个例子中，O-SBE 是一个 B2BUA.

8. I-SBE 收到请求并在 TN 上查询其内部路由数据库。它确定目标属于T-SSP。由于I-SBE 是B2BUA，因此I-SBE 向T-SSP 生成新的INVITE 请求。

请注意，如果 I-SSP 希望媒体通过 I-DBE，则 I-SBE 必须修改要约中的会话描述协议 (SDP) 以指向其 DBE。

9. T-SBE 确定被叫方归属代理并将呼叫定向到被叫方。 T-SBE 可以使用 ENUM 查找或其他内部机制来定位归属代理。如果 T-SSP 使用 ENUM 查找，则此内部 ENUM 条目与为 O-SSP 填充的外部 ENUM 条目不同。此内部 ENUM 条目将包含识别到达被叫方的下一跳的信息。在这个例子中，内部 ENUM 查询返回 UAS 的本地代理。

请注意，此步骤是可选的。如果T-SBE有其他方式定位UAS归属代理，T-SBE可以跳过这一步，将请求发送给UAS归属代理。我们展示这一步是为了说明定位 UAS 的本地代理的多种可能方法之一。

10. T-SBE 收到 NAPTR 记录，并按照 [RFC3263] 中的要求，向 DNS 查询 NAPTR 结果指示的 SRV 记录。没有找到，T-SBE 然后查询 DNS 以获取域“t-proxy.example.net.”的 A 记录。

11. T-SBE 向 UAS 的家乡代理发送 INVITE：

12、最后，UAS的家乡代理转发INVITE请求给UAS.

13. 在图 4 中，通过 O-DBE、I-DBE 和 T-DBE 在 UAC 和 UAS 之间建立 RTP。 DBE 的使用是可选的。

5.4.1.管理特征
此用例看起来与具有辅助 LUF 和 LRF 的静态直接对等互连用例非常相似。主要区别在于 O-SSP 和 T-SSP 没有直接的第 5 层连接。相反，O-SSP 通过 I-SSP 间接连接到 T-SSP。

通常，一个 LUF/LRF Provider 服务于多个 O-SSP。两个 O-SSP 可能使用不同的 I-SSP 来达到相同的 T-SSP。例如，O-SSP1 可能使用 I-SSP1 到达 T-SSP，而 O-SSP2 可能使用 I-SSP2 到达 T-SSP。给定 O-SSP 和 T-SSP 对作为输入，LUF/LRF Provider 将返回 O-SSP 信任的 I-SSP 的 SED，以将请求转发给 T-SSP。

在这个用例中，有两个级别的信任关系。第一个信任关系是在 O-SSP 和 LUF/LRF Provider 之间。 O-SSP 信任 LUF/LRF 来提供 T-SSP 的 SED。第二种信任关系是 O-SSP 和 I-SSP 之间的信任关系。 O-SSP 信任 I-SSP 提供第 5 层连接以协助 O-SSP 到达 T-SSP。 O-SSP 和 I-SSP 有预先安排的政策协议。请注意，图 4 显示了一个提供 LUF/LRF 和 I-SSP 的单一提供者，但 O-SSP 可以选择两个不同的提供者。

5.4.2.选项和细微差别
与静态直接对等互连用例类似，O-SSP 和 T-SSP 可以部署 SBE 和 DBE 用于 NAT 穿越、安全、转码等。
I-SSP 也可以出于类似原因部署 SBE 和 DBE（如图 4 所示）。

5.5.静态间接对等互连用例

此用例与具有辅助 LUF 和 LRF 的静态间接用例共享许多属性。不同的是，O-SSP 使用其内部的 LUF/LRF 来控制路由数据库。通过控制数据库，O-SSP 可以将不同的路由规则和策略应用于不同的 T-SSP。例如，O-SSP 可以使用 I-SSP1 和 Policy-1 到达 T-SSP1，使用 I-SSP2 和 Policy-2 到达 T-SSP2。请注意，可能有多个 I-SSP 和多个 SIP 路由到达同一个 T-SSP；选择过程超出了本文件的范围。

5.5.1.管理特征
静态间接对等互连用例是在由于业务或物理限制而在始发域和终止域之间不存在直接互连的情况下实施的。
O-SSP <---> I-SSP = Relationship O-I

在 O-I 关系中，认为这种关系必不可少的典型策略、特性或功能是号码可移植性、普遍存在的终止选项、安全证书管理以及伪装原始 VoIP 网络设备。
T-SSP <---> I-SSP = Relationship T-I

在 T-I 关系中，观察到的典型策略、特征或功能包括编解码器“清理”、匿名化和转码。
I-SSP 必须记录路由并留在信令路径中。 T-SSP 将不接受直接从 O-SSP 发送的任何消息。

5.5.2.选项和细微差别
在图 5 中，我们展示了一个 I-DBE。使用 I-DBE 是可选的。例如，当 O-SSP 和 T-SSP 没有共同的编解码器时，可以使用 I-DBE。为了涉及 I-DBE，I-SSP 应该知道 O-SSP 和 T-SSP 支持的编解码器列表。当 I-SBE 收到 INVITE 请求时，它将做出调用 I-DBE 的决定。如果 O-SSP 对媒体使用安全实时传输协议 (SRTP) [RFC3711] 并且 T-SSP 不支持 SRTP，则也可以使用 I-DBE。

5.6.按需对等互连用例

按需对等 [RFC5486] 描述了两个 SSP 如何在没有预先安排的协议的情况下形成对等关系。

此用例的基础建立在 O-SSP 和 T-SSP 之间没有预先建立的关系这一事实之上。 O-SSP 和 T-SSP 在对话发起请求之前不共享任何信息。当 O-Proxy 在 Request-URI 上调用 LUF 和 LRF 时，终止用户信息必须是公开可用的。当 O-Proxy 将请求路由到 T-Proxy 时，T-Proxy 必须接受请求，无需与 O-SSP 达成任何预先安排的协议。

按需对等互连用例在生产中并不常见。在本备忘录中，我们仅捕获高级描述。当此用例变得更加流行时，预计会进行进一步的分析。

5.6.1. 管理特征
按需直接对等互连用例通常在 T-SSP 允许任何 O-SSP 到达其服务订户的场景中实现。 T-SSP 管理域不需要任何预先安排的协议来接受呼叫。 T-SSP 公开其订户信息。此模型模仿 Internet 电子邮件模型。发件人不需要预先安排的协议来向收件人发送电子邮件。

5.6.2.选项和细微差别
与静态直接对等互连用例类似，O-SSP 和 T-SSP 可以决定部署 SBE。由于T-SSP对公众开放，因此O-SSP和T-SSP之间不存在信任关系，因此T-SSP被认为比静态模型具有更高的安全风险。 T-SSP 应该保护自己免受不受信任的 O-SSP 发起的任何攻击。

6. 致谢（略）

7. 安全考虑

VoIP 的会话互连，如本文档中所述，具有应考虑的各种安全问题。例如，如果 O-SSP 和 T-SSP 通过公共 Internet 对等，则 O-SSP 必须保护信令通道并仅接受来自授权 T-SSP 的消息。本文档不详细分析威胁。 [RFC6404] 讨论了与 VoIP 对等相关的不同安全威胁和对策。