摘要

  • RFC 3332 的 M3UA 用 Routing Key 描述流量范围，用 Routing Context 指向这条键，用 Network Appearance 区分本地 SS7 网络上下文；三者相关，却不能互换。
  • 一个 ASP 可以通过共享 SCTP 关联服务多个 Application Server，而 ASP 状态按 AS 分别维护。因此传输关联正常，不代表相应流量范围已启用、SS7 目的地可达，或 MTP3 用户已经收到消息。

三个名称，三个不同问题

M3UA 的术语起初像是词汇细节；当点码被复用时，它就变成路由问题。一个 SS7 网络分配的信令点编码，可能也出现在另一个网络。如果信令网关通过共同关联承载两个网络，仅有数字并不能说明消息属于哪个网络域。M3UA 因而把网络上下文、流量选择规则、以及指向该规则的标识分开处理。

这一区分从协议边界开始。RFC 3332 于 2002 年 9 月发布，定义了通过 IP 传输 MTP3 用户信令（例如 ISUP 或 SCCP）的适配方式。远端 Application Server Process 获得 MTP3 用户所需的原语，但 M3UA 本身并不成为 SS7 的 MTP3 层。信令网关可以接收 SS7 信令，远端应用则经由适配层使用相应用户部分。控制面必须同时说明哪些消息发往何处，以及这些消息字段应在哪个 SS7 上下文中解释。

Application Server 是面向特定 Routing Key 的逻辑服务。Routing Key 是选择规则：由一组 SS7 参数定义应交由某个服务处理的流量范围。参数可包括目的信令点编码、源信令点编码和业务指示语；应用也可使用 ISUP 电路识别码或 SCCP 子系统号等用户部分字段。这些只是示例，并非所有网络都适用的固定配方。键可以描述不连续的范围，真正有意义的字段取决于应用和网络。

Routing Context 并不是这些条件的缩写。它是标识 Routing Key 的值。SGP 的消息分发功能依据键匹配流量；控制消息则借助相应上下文引用需要启用、停止或注册的流量集合。可以把键理解为规则，把上下文理解为规则的句柄，把 Application Server 理解为规则所选择的服务。用一个替代另一个，就会丢失匹配条件或控制操作所需的引用。

Network Appearance 是本地标记，不是全球编号

Network Appearance 回答另一个问题：这条信令应在哪个 SS7 网络上下文中解释？信令点编码与其网络上下文合在一起，才能识别信令节点。当网关同时接入多个国家级或专用 SS7 网络，而这些网络复用了点码时，这个维度就很重要。缺少网络维度，一个看似精确的地址仍可能指向不同节点。

但 Network Appearance 不是互联网范围的网络编号。RFC 3332 把它设计为在 Signalling Gateway Process 与 Application Server 之间协调的本地引用。2006 年取代 RFC 3332 的 RFC 4666 进一步说明：同一个底层 SS7 网络，在不同 SGP 上可以使用不同的 Network Appearance 值。没有映射记录时，运营者不能只比较网关上的整数，就认定它们代表同一对象。

在边界明确的拓扑中，该字段可以省略。只服务一个 SS7 网络的网关可能不需要它；专用于单一网络上下文的关联也可能如此。共享关联需要区分上下文时，接收方则可通过该值完成区分。因此，字段缺失反映的是已配置的拓扑，并不能证明“所有网络都是一个网络”。类似地，在受限的单键配置中，Routing Context 也可能由配置隐含而不必在每条消息中发送。协议允许在值明确时省略；但要理解为何明确，仍需要配置记录。

一条关联可以承载多份应用状态

故障切换时，这个区分再次变得关键。ASP 是进程实例，不是服务定义。它可以配置为服务多个 Application Server；同一 SCTP 关联也可以承载与多个 AS 有关的流量。RFC 3332 因而按 AS 分别维护 ASP 状态。ACTIVE 不是套接字或机器的单一属性，而是该进程在特定应用服务中的流量状态。

流量模式决定状态如何影响转发。Override 可以选择一个活动 ASP，让其他进程作为备份；Loadshare 可在活动进程间分配流量；Broadcast 则可向所有符合条件的活动进程发送。适合的算法由应用决定。SGP 选择消息接收方时，状态变化、Routing Context 和已配置的键必须保持关联。脱离 AS 或上下文谈“ASP 活跃”并不完整；“SCTP 关联已建立”提供的信息更少。

远端用户所见还有一层。M3UA 可以承载 DATA，也可以报告目的地不可用、可达、受限或拥塞。传输关联只能证明端点能够通信。它不能证明信令点编码与 Network Appearance 的组合解析正确、消息匹配到获授权的 Routing Key、ASP 对应 AS 的状态为 ACTIVE，或远端 ISUP/SCCP 进程完成了工作。每个结论都需要来自相应层的回执。

为什么讲 2002 年版本，也要读 2006 年修订版

本文的历史对象是 RFC 3332，并非声称其文本仍是当前规范版本。RFC 4666 于 2006 年 9 月取代了它。修订文本保留了核心区分：Routing Key 描述流量选择，Routing Context 标识这条键，Network Appearance 提供 SS7 网络上下文且仍具有本地意义。读者应以继任规范理解当前文本，同时也能看到哪些设计边界延续下来。

当前 IANA SCTP 参数登记表为 M3UA 列出协议标识符 3，并引用 RFC 4666；服务名称登记表列出 SCTP 端口 2905，服务名为 m3ua。这些记录说明了分配的代码点和注册端口，却不能证明运营商部署了 M3UA、实现符合规范，或某条关联承载过呼叫。同样，RFC 9260 是当前 SCTP 规范这一事实，也不能证明已部署的 M3UA 系统采用了它。

相邻的 RFC 3331（M2UA）处理不同边界：它承载 MTP2 用户边界，物理链路仍留在网关。M3UA 传输的是 MTP3 用户信令，可包括 ISUP 或 SCCP 负载。RFC 4233 的 IUA 与 RFC 4165 的 M2PA 也有各自的适配边界。它们同属 SIGTRAN 家族或共用 SCTP，不代表协议名称与状态模型可以互换。

实际检查时，应分别询问：哪些 SS7 参数选择了这类流量；哪个 Routing Context 标识该选择；在这一 SGP/ASP 配对中，哪个本地 Network Appearance 让点码具有明确含义；哪个按 AS 维护的 ASP 状态允许交付？完成这些核对之后，才把 SCTP 关联附加为传输路径。RFC 3332 留下的设计要点是：规则的句柄、规则本身、网络域以及承载消息的通道，是不同对象。

来源