摘要

  • RFC 3372 把 PSTN 与 SIP 互通拆成两项独立工作：以 MIME 封装 ISUP，供有能力的终点保留传统信令；把部分参数翻译为 SIP 首部，供中间代理作路由判断。
  • 完整的封装体不等于正确路由，正确抵达也不等于 ISUP 被忠实重建，更不等于媒体接通、功能生效或用户获得预期体验。

2002 年的互通问题，并不是简单地把电话语音装进 IP 分组。公共电话网用 SS7/ISUP 描述呼叫，许多传统功能依赖其中的参数；SIP 网络里的代理却要根据 Request-URI 和可见首部选择下一跳。代理不应被要求理解每一种 ISUP 变体，但出口网关又可能需要原始细节才能继续完成电话网侧的处理。

RFC 3372 以 BCP 63 发布，把这套做法称为 SIP-T。文件特意说明，SIP-T 不是一种新协议，而是一组互通机制。它最重要的历史价值，是承认一通呼叫跨越架构时需要两份彼此相关、却不能互相代替的记录。

第一份记录是封装后的 ISUP。入口网关识别收到的 ISUP 变体，按照 RFC 3204 规定的 MIME 类型，把消息放进 SIP 消息体。对于 PSTN 经 IP 再回到 PSTN 的呼叫，出口网关可以取出这份内容，保留那些在 SIP 中没有直接对应物的功能信息。

第二份记录是 SIP 请求本身。入口网关从 ISUP 中挑选路由所需的信息，例如被叫号码，并翻译成代理能够读取的 URI 或首部。RFC 3372 把前一项称为功能透明，把后一项称为可路由性。二者同时发生，不代表二者的结果必然一致。

一份逐字节完好的 ISUP 消息体，可以跟着错误翻译的被叫号码到达错误网关。反过来，请求也可能沿正确路径抵达，但封装体已被删除、损坏，或使用了出口不支持的 ISUP 变体。协议容器通过检查，只能证明容器；它不能替内容解释、路径选择与最终服务签字。

出口网关的行为进一步说明了这种边界。它可以把封装的 ISUP 当作模板，再用 SIP 首部翻译回来的值覆盖相应参数，并加入本地政策要求的值。若请求没有携带 ISUP，它还可以从预先配置的标准模板开始。因此，重新送入 PSTN 的信令是一次可审计的重建，不是入口消息原封不动地“复活”。

呼叫开始时，入口端往往不知道最终终点属于哪一类。PSTN 发起的呼叫可能抵达另一座网关，也可能抵达原生 SIP 电话。后者通常不使用 ISUP，却仍应按 RFC 2046 的 MIME 规则和 RFC 3261 的 SIP 框架，妥善处理 multipart 与未知内容类型。原生 SIP 电话发起呼叫时，则没有理由为了一个尚不确定的 PSTN 终点而制造 ISUP。

通话中信令又暴露出另一条缝隙。一些 ISUP 信息不会改变 SIP 会话状态或媒体参数，RFC 3372 因而借用 RFC 2976 的 INFO 方法传送它们。INFO 抵达只证明一条消息抵达，不能证明接收端理解其电话语义，也不能证明用户看见了相应功能。

附近的标准解决了不同问题。RFC 3219 的 TRIP 与 RFC 2916 的 ENUM 提供电话路由和号码解析背景，却不能替代封装体中的功能上下文。RFC 2633 所描述的 S/MIME 能保护携带内容；有效签名仍不能证明翻译字段正确、出口选择正当、本地覆盖值获授权或语音媒体已经建立。

RFC 3398 后来细化了 SIP 与 ISUP 的映射。RFC 3326 允许 SIP 携带来自不同协议命名空间的原因值，但“解释为什么”不等于“执行动作”。RFC 3331 与 RFC 3332 讲的是 SS7 适配状态如何通过 SCTP 分布；本篇关注的则是同一通呼叫为何同时需要不透明的旧语义与可见的新路由面。

现有规范记录不能证明 SIP-T 的部署比例、厂商一致性、商业通话结果或今天的使用规模。能够证明的是一种克制的架构选择：互通不是把旧真相压缩成新真相后丢掉原件，而是让不同能力的参与者各自获得可用表示，并保留它们之间的转换责任。

Lu Heng 的“最小初始规范”分析提醒我们，公共层应尽量小，而本地决定必须保持可见；“现实层”分析则要求把收到的 SS7、封装体、翻译首部、代理路径、出口重建、媒体通路和用户体验分别留档。RFC 3372 没有宣布这些层已经统一。它让跨层协作成为可能，并让我们知道应该在哪里寻找丢失的含义。

来源