摘要

  • 在 RFC 3108 的 SDP 中，“前向”是离开当前所描述 ATM 节点的方向；在 ATM/AAL2 承载信令中，“前向”则是从发起承载建立的一端走向接收请求的一端。反向建立 SVC 时，同一个参数会在两层获得相反名称。
  • 四字节 eecid 把一条业务级呼叫记录与随后到达的承载建立请求作一对一关联。它只是节点本地的连接键，不是用户身份、全球连接编号，也不是媒体已经畅通的证据。

语法正确，方向仍可能完全错误

设想同一台媒体网关旁有两块控制面板。第一块把离开网关的峰值信元速率称作前向；第二块因为远端网关发起了承载建立，便把完全相同的速率称作后向。两块面板都没有写错。真正不同的是它们选择的坐标原点。

2001 年 5 月以 Standards Track 发布的 RFC 3108，把这种冲突正式写进协议边界。它沿用 RFC 2327 的 SDP 语法，为 ATM 与 AAL2 承载连接增加媒体属性：地址、适配层、流量描述、服务质量、承载类型、信道或子信道以及业务选择等。这些描述可以随 SIP、MGCP 或 Megaco/H.248 控制交换传递。

关键不在属性清单，而在控制路径彼此独立。发起电话或多媒体业务的一端，不一定也是发起 ATM 交换虚连接的一端。一旦“业务发起者”与“承载发起者”分开，日常语言中的方向就无法直接跨层搬运。

RFC 3108 的 SDP 以“当前所考虑的 ATM 节点”为原点。远离该节点是前向，朝向该节点是后向；谁发起业务呼叫或承载连接都不改变定义。ATM 与 AAL2 信令采用另一套坐标：从发送建立请求的一端到接收请求的一端才是前向。

如果业务发起网关也发起承载，两种坐标可能重合。可在 backward SVC setup 中，业务发起网关反而接收承载建立请求。离开它的流量描述在 SDP 中仍是前向，在 ATM 信令中却成为后向。网关必须交换方向。逐字节忠实复制，反而会制造语义错误。

方向本身就是必须保存的数据

atmQOSparms 与 atmTrfcDesc 等属性都带 directionFlag，取值可以是 f、b 或 fb，分别表示前向、后向或双向。即使其他字段因为未指定、不适用、隐含或由另一机制提供而写成 ，方向标记仍必须出现。

这些值可以描述峰值与可持续信元速率、突发大小、时延变化、端到端时延以及可接受丢失率。若网关把合法数值挂到错误方向，解析器仍可能接受整行，资源合同却已经颠倒。一侧得到错误容量或 QoS，控制器还可能因为两份消息“数值相同”而误报一致。

因此，RFC 3108 不是简单的“ATM 版 SDP 词典”，而是一条翻译规范。实现至少要保留四项上下文：SDP 描述的是哪一个节点，哪一端发起业务控制，哪一端发起承载建立，以及当前字段服从哪套方向约定。缺少这些信息的“前向”只是一段不完整证据。

通配符进一步说明语法与运行事实不同。多个字段允许用 $ 把可选值交给接收方决定； 依字段可表示无关、隐含、未指定或已由其他机制获知。解析通过，只能证明表达合法，不能证明硬件安装了这个值、策略允许它，或应用真正能够使用它。

一条业务记录，需要找到一条承载请求

两条控制路径分离后还会产生关联问题。业务级指令可能先到达网关，ATM setup request 稍后才从承载网络出现。网关必须知道，新请求究竟属于此前哪一个呼叫上下文。

RFC 3108 用 eecid 完成这次连接。它是 end-to-end connection identifier，在相关 ATM 与 ISUP 语境中等同于四字节 bnc-id，但 SDP 使用更中性的名称。它的功能是把收到的一条承载建立请求与一条业务级呼叫控制记录作一对一匹配。

谁选值取决于建立方向。前向承载建立中，业务终止网关选择 eecid，经 SDP 送到业务发起一侧，再从由发起侧启动的承载请求中收到原值。反向承载建立中，业务发起网关选择它，经 SDP 送往终止侧，随后从终止网关发起的承载请求中取回。

这看似绕一圈，其实是一种准确的职责分配：未来将接收 setup 的节点，先挑选一个自己能够识别该请求的值。唯一性只要求覆盖该承载终止节点，不要求全球唯一，甚至不要求所有网关共享同一命名空间。分配节点控制释放与复用；文档虽允许收到请求后释放，却建议一直保留到连接终止。

这个范围排除了许多误读。eecid 不表示人，不认证订户，不自动分配 ATM 电路，也不证明双向媒体存在。它是一枚跨越两条协议路径的本地数据库连接键。值匹配只证明关联；setup/connect 交换证明承载状态；双向数据包与应用测量才证明服务结果。

RFC 3108 也没有夺走承载协议的编码权。它以说明方式列出当时可用于携带该值的信息元素，但具体传输仍由相应承载协议定义。SDP 记录与 ATM 信令记录可以表达同一关联，却仍是受不同规范约束的两份对象。

描述、建立与流量是三类事实

文档中的呼叫流程把三层拆得很清楚。媒体网关控制器交换业务信息，各自向网关下达指令；随后一台网关跨 ATM 网络向另一台网关发送带 eecid 的 setup。接收方用它找到此前控制记录并返回 connect。只有走完这条链，媒体才有可能使用承载。

只保存 SDP，只知道计划描述了什么；控制确认只说明网关接受了指令；setup 只说明有人尝试建立；connect 说明承载进入连接状态，却不能证明双向媒体、时延、丢包或用户体验合格。

chain 属性处理了另一种分层。连续 SDP 描述可能是同一会话的替代方案，也可能描述同一连接的不同层，例如上层 IP 会话与下层 ATM 承载。chain 允许每层保持独立而简洁，同时表明当前描述与前一份或后一份相连。连接描述不等于实现连接；链条不能证明每一层都在运行。

这也阻止我们把后来的 SDP 历史倒灌回 2001 年。RFC 3264 在 2002 年才规范 offer/answer 模型；RFC 4566 与 RFC 8866 后来继续修订 SDP。它们能说明规范谱系，不能证明 RFC 3108 的所有交换都采用后来的模式，更不能证明它被广泛部署。

安全属于承载它的外壳

RFC 3108 对安全边界相当坦率。当时 ATM/AAL2 承载加密不像 RTP payload 加密那样已有惯例，承载信令认证也尚未形成惯例。SDP 的 k= 行可以表达密钥或取得密钥的方法，但写下密钥字段并不证明保护已经启用。

描述可能来自订户自有、甚至位于不可信场所的设备。RFC 没有在描述内部再发明一套安全系统，而是依赖封装它的协议或更低层。SIP、MGCP 与 Megaco 环境可以使用 IPsec 认证，并可选择加密。这里的“可以”绝不能改写成“已经”：规范给出可行构造，不代表某次交换建立了安全关联，也不代表 ATM 承载本身加密。

所以审计必须分别保存：原始 SDP 及其发送者、所描述节点、业务呼叫角色、承载建立发起者、方向翻译前后值、eecid 分配者与作用域、承载请求和 connect、安全关联、实际 QoS 配置、计数器、双向包和应用结果。

历史警告的是“可携带的词”

RFC 3108 很容易被看作某种逐渐远去传输技术的复杂附录。它更持久的意义在于提醒：分布式系统常在不同层重复使用 owner、active、local、primary、forward 之类普通词。词形保持不变，坐标系已经变化。消息可以合法、签名有效、复制准确，却在下一个控制面上完全错误。

2001 年的媒体网关不能靠选择一份“更权威”的文档解决问题，因为两份描述在各自层内都具有权威。它必须翻译，并为每个值保留足够来源，直到知道该用哪一套坐标。关联键把记录连在一起，却没有假装把它们合并成同一事实。

两层都说前向。它们不是对线路意见不一，而是对方向从哪里开始有不同定义。网关必须守住这条差别，直到运行中的承载状态与观测到的媒体把描述替换成证据。

资料来源

  1. https://www.rfc-editor.org/rfc/rfc3108.html
  2. https://www.rfc-editor.org/info/rfc3108
  3. https://datatracker.ietf.org/doc/rfc3108/
  4. https://www.rfc-editor.org/rfc/rfc2327.html
  5. https://www.rfc-editor.org/info/rfc2327
  6. https://datatracker.ietf.org/doc/rfc2327/
  7. https://www.rfc-editor.org/rfc/rfc2543.html
  8. https://www.rfc-editor.org/info/rfc2543
  9. https://www.rfc-editor.org/rfc/rfc2705.html
  10. https://www.rfc-editor.org/rfc/rfc2805.html
  11. https://www.rfc-editor.org/rfc/rfc3015.html
  12. https://www.rfc-editor.org/rfc/rfc3264.html
  13. https://www.rfc-editor.org/rfc/rfc4566.html
  14. https://www.rfc-editor.org/rfc/rfc8866.html