摘要

  • RFC 5239 将会议状态和呼叫信令集中起来，却没有把焦点、会议控制、发言权仲裁、媒体混合与通知披露合并为同一种权力。
  • 可审计的操作必须串起请求、身份、授权、对象版本、实际执行和观察者视图；任何单一日志只能证明自己所在的控制面。

“静音”至少有六步

Alice 要求把 Bob 静音。会议控制服务器先依据目标会议对象的策略判断 Alice 是否有权操作。获准后，Bob 的状态被改为其媒体不应进入混音。通知服务可能根据权限告知 Bob 和 Carol。最后，混音器还要真正改变媒体行为。

界面可以把全过程压缩成绿色的“已静音”，架构却不能。接口接受请求，不等于授权成立；授权成立，不等于对象已经写入；对象写入，不等于混音器已执行；一条通知只说明某位观察者被允许看到什么。

争议发生时，需要的是这些凭证之间的连接，而不是最方便的一条日志。

焦点位于中心，但不是全部治理

RFC 5239 对 focus 的定义很窄：它与每个参与者维持独立的呼叫信令关系，因此信令图呈星形。这个中心说明会话在哪里协调，却不能证明所有策略、对象修改、发言权和媒体处理都由同一主体决定。

框架在会议对象周围列出会议控制服务器、发言权控制服务器、一个或多个焦点以及通知服务。它们是逻辑实体，可以部署在同一进程或主机上。但共址不会抹掉职责差异。即使一个程序承担全部角色，审计记录仍要说明它以哪种角色作出了哪项决定。

媒体图也可能集中、分布或按媒体类型混合。集中信令因此不能证明所有音频、视频和文本都经过同一个混音器。

共享对象记录状态，不产生无限授权

会议对象覆盖蓝图、预约、激活和结束等阶段，保存成员、能力、信令和媒体信息。会议策略则规定对对象执行操作时的权利、许可和限制。对象描述事实，策略批准转换，协议承载请求，运行组件落实后果。

标识符也不能混用。会议 ID 面向特定呼叫信令并指向焦点；会议对象 ID 用于访问与修改对象；会议用户 ID 在会议系统内部识别用户，还可能体现不同角色。把这些键压成一个“用户”或“会议”字段，会让界面更整齐，却让责任链失真。

继承关系同样重要。预约可以从蓝图克隆，侧会依赖主会议，父对象的强制值可以限制子对象。当前快照无法告诉调查者，一个值来自蓝图、父级约束、本地覆盖还是后续特权修改。版本谱系是证据的一部分。

获得发言权，不等于声音一定被执行

floor 是对某项资源的临时使用许可。现行 BFCP 明确指出，持有 floor 并不自动保证其他人技术上无法使用该资源。权利授予和媒体执行是两件事。

因此，“发言权已授予”只能证明仲裁结果。它不能证明混音器接纳了持有者的音频、排除了其他来源，或把正确结果送达每位参与者。反过来，出现声音却没有 floor 记录，可能意味着绕过策略、实现缺口，也可能只是该会议没有启用发言权控制。

审计应连接许可、资源映射和真实媒体行为，而不是把控制面的词当作运行结果。

通知是被授权的视图

RFC 5239 允许参与者呈现为公开、匿名或隐藏。主持人可能看到普通参与者看不到的身份。通知还会按角色、策略和隐私规则过滤。

Bob 没出现在 Carol 的名单里，不能证明 Bob 不在会议中。两个内容不同的通知完全可能同时正确。每条通知都应携带观察者、角色、策略版本和披露规则；否则，隐私过滤、传播延迟、审查和系统错误无法区分。

用运行事实重建权力链

敏感操作至少要保存六类相互关联的凭证：谁针对哪个标识符提出请求；用什么机制验证身份；哪项角色与策略授权操作；会议对象的前后版本；哪个组件执行了信令或媒体变化；不同观察者分别看到了什么。

时钟对齐和标识映射不是运维杂务。它们决定能否证明授权先于修改、修改先于执行，以及通知反映的是新状态还是旧快照。

RFC 5239 没有声称某个产品发生故障，也没有给出部署或市场结论。它提供的是架构语法。Lu Heng 的 running-code 原则给出验证方法：权力应从可归责的动作和真实运行后果中确认，不能从“主持人”“焦点”或“中央服务器”这些标签中推断。

来源