RFC 5373：自动接听没有授权后续麦克风

摘要

Answer-Mode: Auto 请求终端不等待用户界面确认便接受初始 INVITE，但本地身份、授权和媒体风险策略仍然掌握最终决定。
Priv-Answer-Mode 是一次特权待遇申请，不是特权声明；;require 只在策略选了别的模式时要求拒绝，Require: answermode 则只要求理解扩展。
自动接通的纯入站会话若经 re-INVITE 或 UPDATE 变成出站或双向媒体，必须取得新的明确用户接受。授权必须跟随对话状态，而不能停在首个 200。

一台设备可以自动接收调度员的语音，让扬声器播放，而不启用本地麦克风。这种入站动作已经有骚扰、费用和电量风险，但它与让房间里的声音离开设备仍不是同一种权限。

随后到来的 re-INVITE 可能把 SDP 从接收方向改为双向。RFC 5373 的 Answer-Mode 字段只定义在建立对话的初始 INVITE 和相应 200 中；中途请求里的同名字段应被忽略。然而安全义务没有结束。终端必须持续检查媒体状态，未经用户明确接受不得开始发送本地媒体。

因此，auto_answer=true 不是足够的数据模型。记录至少要说明被授权的身份、终端、媒体类型、方向、对话版本和有效时段。方向变化需要独立的接受事件，并与实际启用的采集器对应。

普通 Answer-Mode: Auto 要求 UAS 尽量不等待用户交互就接受。UAS 可以按照本地策略改为手动处理，也可以拒绝。未经认证和授权的请求尤其不能因为字段存在便获得自动播放。

Auto;require 也没有改变权力归属。策略先选模式；若结果不是自动，require 要求拒绝，而不是强迫设备绕过策略。对于诊断回环，这个分支很重要：宁可失败，也不要让本来无人值守的测试突然打扰使用者。

另一个 Require: answermode 只检查协议能力。它要求不理解扩展的设备拒绝，却不能要求理解扩展的设备一定自动接听。REGISTER 中的能力声明和 Accept-Contact 路由偏好同样只证明候选终端声称支持这套词汇。

RFC 把 Priv-Answer-Mode 比作 sudo：它明确请求按更严格的特权策略处理，但前缀本身不会赋予权限。终端应默认拒绝没有经过专门认证和授权的特权请求。

同一个调度员可能有普通与紧急两种意图。若系统看到身份便自动升级所有请求，用户就失去了表达普通意图的渠道。正确记录要保留请求选择了哪张策略表、身份如何建立、规则版本是什么以及最终允许了什么。

如果普通和特权字段同时出现，UAS 先检查特权资格；不合格时再按普通字段处理。这个回退是一个可审计分支，不应被压缩成最后一个 Auto 值。

RFC 5373 当时引用 RFC 4474；该机制后来由 RFC 8224 取代。历史文档证明的是“必须有合适身份机制并另做授权”，不是某一种旧机制今天已普遍部署。

同一 SIP 地址可能解析到多台已注册设备。并行分叉时，多台终端都可能自动返回 200。SIP 通常保留最先建立的对话，再用 BYE 关闭其他对话。

最终只剩一条对话，不代表只有一台设备采取过动作。输掉分叉的终端可能已经打开扬声器并短暂播放媒体。RFC 因而不建议在并行分叉环境中使用自动接听。

审计不能只保存赢家。每个 contact、分支、临时与最终响应、媒体开始时间和 BYE 都要保留。会议或早期媒体可以改变设计，却不会让成员、播放与用户接受自动变成同一个事实。

UAS 可以在 200 中报告 Manual 或 Auto，让呼叫方知道它是否等待过定义的用户界面动作。但 Manual 可能暴露有人就在设备旁边，因此 RFC 建议默认不返回这个字段。

缺失不等于自动，也不等于手动。它只表示这项事实没有在响应上披露。字段即使存在，Manual 也不能确认操作者身份，Auto 也不能确认现场无人。它描述设备流程，不描述人的注意、理解或同意。

普通中间代理忽略这些字段。服务代理只有在与被服务用户存在明确外部协议时，才可插入、删除或修改 Answer-Mode。否则，代理可能把诊断呼叫变成人工打扰，或越过终端用户的选择。

这也说明接收端看到的字段未必就是呼叫者原始意图。应保存原始请求、每次被授权的变换、代理身份、协议版本和 UAS 实际评估的字节。单跳 TLS 不能替代端到端语义来源。

完整证据链包括初始 INVITE、身份与认证方式、普通/特权字段、两种 require、contact 选择、全部分叉、本地策略决定、可选响应披露、每版 SDP 方向、明确用户接受和实际出站包。是否听见、理解或采取行动，要由别的观察面证明。

可公开陈述的结论很窄：某个 UAS 按某版策略处理了一次接听模式请求。它不能把协议请求写成对人的替代决定。