摘要

  • RFC 3054 把 IP 电话描述成一个较简单的 Megaco Media Gateway：稳定的 Termination 名称和最低 profile 让 Media Gateway Controller 无须只凭 Package 猜测设备结构。
  • 电话声明并获控制器接受 IPPhone profile，并不能证明可选能力、当前物理状态、逻辑 Context、RTP 路径、解码声音或用户体验；这些仍是彼此独立的凭据。

2001 年 1 月，互联网电话可以沿两条互补路线来设计。一条把较多呼叫智能放进终端，如端到端会话架构；另一条让桌面设备保持相对简单，把应用控制交给远端控制器。

RFC 3054 展开了后一条路线。电话本身成为 Media Gateway，Media Gateway Controller 掌握大部分应用智能。电话把用户界面、听筒、免提、耳机和 RTP 流暴露为可发现、可操作的逻辑部件。

这是一份 Informational RFC，不是互联网标准，也没有报告某款产品或一次成功通话。它的历史价值在于说明：profile 能把异构设备之间的大量先验约定压缩成一个名字，却不能免除对真实库存的追问，更不能代替对结果的观察。

电话成为桌边的媒体网关

媒体网关控制常让人想到连接不同网络、终结大量线路的设备。RFC 3054 把同一模型推进到一台个人电话：用户桌上的设备就是 MG，直接实现音频输入输出和交互部件；一个 MGC 在框架中可以控制许多这样的电话网关。

分工因此格外清楚。终端执行媒体与界面动作，控制器决定这些部件如何参加一次呼叫。按键产生 Event，由 Notify 上报；显示屏和指示灯响应 Signal；控制器可以把听筒加入 Context，再把免提部件移入同一 Context，或移除一组音频部件。

这些动词都不是通话本身。Notify 可以准确报告按键，却不能证明应用做出了正确决定。Modify 获接受，不证明灯真的亮起。Context 里可以同时存在 RTP Termination 和听筒，而网络路径、解码器、放大器或物理换能器仍可能失效。

架构靠职责分离获得简单性，也要求证据始终只属于产生它的那一层。

名称携带了 Package 无法表达的人类意义

profile 要求恰好一个名为 ui 的 User Interface Termination，并要求至少一个 Audio Transducer Termination。听筒用 at/hs，免提用 at/hf，耳机、麦克风、扬声器也各有约定名称；at/* 可以把音频部件作为一组来寻址。

这些不是装饰标签。两个物理部件可能支持完全相同的 Package，对拿着电话的人却意义不同。只看到通用能力的控制器，很难知道哪个是贴耳听筒、哪个是面向房间的扬声器。稳定名称把预期的人类用途交给控制器，不必为每种换能器另造一套 Package。

命名也使发现和批量操作更高效。MGC 可以用通配符审计所有音频 Termination，或把它们一起移出 Context，不必在任意对象集合中逐个猜用途。

但标识符仍是逻辑模型中的陈述。实现可以分别暴露每个物理部件，也可以把多个真实输入输出藏在一个逻辑 Termination 后面，由本机自行选择。at/hs 证明协议对象代表听筒，不证明完整线路清单，也不证明听筒已连接、健康、被选中或发出了声音。

profile 用先验约定替代了大量推断

电话启动或发生 service change 时，会向 MGC 宣告 IPPhone、版本 1。这个名字携带一组预期：一个 ui、有名的音频结构、至少一个音频换能器、至少一个 RTP Termination，以及最低控制传输和编码支持。

这正是 profile 的经济性。控制器一旦认识这个名字，就不必从空白理论理解设备；共同结构和行为可以成为起点，只审计真正会变化的部分。

但交换中仍有决定。MGC 可以接受控制、把电话转介给另一个控制器，或拒绝。电话说“我是 IPPhone version 1”，不等于控制器已经负责。接受之后，双方才受 profile 规则约束，超出规则的协议使用被视为错误。

即使获接受，先验约定也有边界。它规定最低形态和行为，不认证某家实现、某次启动、当前状态或物理输出。共同语法降低了提问成本，却没有回答全部运行问题。

可选性正是产品空间，所以仍须审计

控制器用 AuditValue 获取实际逻辑库存和支持的 Package。对整台电话做通配符审计，可以得到用户界面与音频 Termination；后续审计再检查 ui、某个换能器或 at/* 的 Package。

这一步不可省略，因为 RFC 3054 刻意让用户界面保持开放。文本显示、拨号键、功能键、指示灯、软键与辅助输入全部可选。于是同一 profile 可以描述只有听筒和叉簧的大厅电话、小型会议设备，或功能丰富的商务电话。

缺失不一定是故障：没有显示屏的电话仍可能符合 profile。存在也不等于可用：审计可以报告显示 Package，而屏幕可能损坏、被本地禁用，或无法呈现某项指令。

profile 划定了可控的变化空间，AuditValue 报告空间内的逻辑声明。两者都不能替代对动作及其物理结果的验证。

最小核心容纳扩展，也制造继承问题

RFC 3054 明确只定义最小设计。实现者可以增加 Termination、Package、传输、编码或内置智能。它试图同时满足两件事：给控制器可靠的共同基线，也给产品差异留下空间。

同一灵活性带来生命周期问题。可选扩展只有在控制器和电话能一致识别、解释时才有价值。专有 Package 或本地行为可以改善一套系统，却让更换 MGC 或终端变难。应用智能越集中在控制器，电话越依赖控制器持续理解其 profile 与扩展。

集中模型可以降低终端成本，也集中决策权。MGC 决定 Context 成员，驱动屏幕和指示灯，处理用户 Event。控制器故障、陈旧库存或不兼容扩展，失去的不只是管理页面，也可能是许多仍能通电设备的功能逻辑。

最小规范降低初始互操作负担，却不会消除扩展治理、版本纪律、降级策略与退出路径。

控制传输和媒体传输是两套系统

IPPhone profile 要求支持以 UDP 承载、带 Application Layer Framing 的 Megaco 控制，并要求 ABNF 文本编码；TCP 与 ASN.1 二进制编码是按基础协议实现的可选项。

这些要求描述控制器和电话如何交换命令。声音则经 RTP Termination 传送。两者不能混为一谈：可靠或已认证的控制交换可以建好逻辑媒体路径，而 RTP 包仍不到达；RTP 可以单向到达；包到达后可能无法解码；已经解码的样本也可能因为选错换能器而无声。

profile 要求存在表示 RTP 流的对象，却没有提供一次 packet trace。后来的 RTP、电话事件与 H.248 文档能解释边界和演进，不能倒推某台 RFC 3054 电话实现了全部后来机制，更不能证明它成功通话。

安全边界继承了控制器的触达范围

RFC 3054 说它没有增加 Megaco/H.248 应用固有问题之外的新安全问题。这是在界定新增风险，不是说系统无需安全措施。

控制器能影响音频路径、屏幕、指示灯和按键响应，因此合法控制关系拥有很强的设备权限。认证可以说明谁发了命令，却不能证明命令符合用户意图、媒体保密、物理输出正确，或集中权限没有被滥用。

规模放大了这条边界。一个 MGC 控制许多电话，会简化共同策略和维护，也让错误或被攻陷的权限触及更多终端。降低单机智能的架构杠杆，同时提高了控制器可用性、授权、状态恢复和扩展约束的重要性。

有用的捷径不是最终凭据

RFC 3054 给设备异构性一个克制答案：为设备提供共同 profile，为逻辑部件使用稳定名称，让可选能力保持可选，再通过审计获取差异，最后用普通 Megaco 操作拼出所需媒体与界面状态。

这比两个极端都精确。控制器不必从零重新发现每个对象的意义，也无权把 profile 名称当作机壳后全部事实的证明。

电话给部件起了名字，控制器仍要追问里面有什么。此后，命令、Context 状态、数据包、解码音频和桌边的人，各自提供不同的凭据。

Sources

Lu Heng 没有撰写或认可 RFC 3054 及相关标准；本文仅将他的文章作为明确披露的分析视角。