摘要

  • RFC 3351 希望文字、语音、视频、中继服务和用户偏好都能参与一场可变更的 SIP 会话，不必为切换媒体而重新拨号。
  • 这是一份信息类需求文件，不是标准化的 SIP 扩展，也不能证明终端和服务商兑现了其中的场景。

RFC 3351 最有分量的一句话，讲的是会话结构：对话中的任何用户代理，包括转码服务，都应能在不拆除并重建通话的情况下加入或移除媒体流。语音通话可以后来增加文字；中继可以进入会话，把一种媒体转换成另一种，再退出。交流方式改变，不该让整场对话从头开始。

这份文件于 2002 年 8 月发布，它把无障碍问题从“用哪类设备”转向“会话如何处理不同偏好”。它把用户配置描述为可通过 SIP 传递的能力与偏好，并希望这些信息影响会话的处理方式。文字、音频、视频可以单向或双向组合；某条流可以经过转码服务；网关也可以连接 SIP 用户代理与旧式文本电话。用户的选择在会话这个交汇点上实现。

不过，不能忽略文件的性质。RFC 3351 属于 Informational，并明确声明它不制定任何互联网标准。文中的 MUST 和 SHOULD 表达作者希望采用的需求，并不会自动把它变成标准化 SIP 扩展；它也不认证任何实现，更没有统计有多少服务真正可用。文中的对话流程是设计场景，不是部署调查。

用户配置同时带来隐私张力：它能帮通话找到合适路径，也可能暴露用户是谁、偏好什么。RFC 3351 因而设想，即便有中继参与，接听方也不必知道来电者是聋人。文件要求第三方转码服务说明保密政策，并建议服务商允许用户不在每次交易中公开自身能力和偏好。无障碍不仅是文字能否传过去，也包括服务会获知、保存和披露什么信息。

这份 RFC 对成本和选择写得格外具体。用户代理应能识别媒体内容，按能力和政策比较转码服务，并发现替代方案。它还建议在会话开始前显示每分钟费用和最低收费。一个广播场景中，电台没有文字流，转码服务又因担心资源耗尽而拒绝处理音频。会话路径有现实的运营边界；信令协议不会把服务变成无条件保证。

场景不止于字幕。一种流程让语音会话持续进行，同时由中继把语音转成文字，再把用户键入的回复读成语音。另一个会议场景把语音转文字、文字转手语、手语转文字串在一起，以适应不同参与者的偏好。语音菜单也可以经中继获得文字通道。这些设想把用户的交流方式放在中心，但每多一次转换，就多一个服务商、一个政策、一笔潜在费用和一个信息经过的边界。

后续 RFC 展示的是规范不断细化，并非普遍成功。RFC 4103 定义了通过 RTP 承载 T.140 实时文字的格式，并建议用冗余机制补回部分丢失字符。RFC 5194 后来为 SIP/IP 实时文字制定了更细的框架，涵盖文本、转码、呈现和互通，并引用 RFC 3351 的中继指引。RFC 4504 建议 SIP 电话设备支持 RFC 3351 的无障碍要求。再后来，RFC 8865 规定通过可靠、有序的 WebRTC 数据通道传送 T.140 文字；RFC 9071 处理多方 RTP 文字混合并更新 RFC 4103。每份文件都让路径中的一部分更明确，但没有一份能证明所有终端、服务商或紧急服务都提供这条路径。

因此，它的历史贡献并不是宣称问题已经解决，而是把问题放进通话设计：改变媒体不该迫使用户重启会话，用户也应当能影响改变如何发生。技术上可扩展的会话，仍可能因费用、兼容性、服务能力或拒绝请求而不可用；方便选择的配置也可能暴露隐私。RFC 3351 要求设计者认真对待控制、成本和信息披露，却没有声称现实已达到这种平衡。

来源：RFC 3351 · RFC 3351 信息页 · RFC 3351 Datatracker 记录 · RFC 2119 · RFC 8174 · SIP 会话发起协议 RFC 3261 · SDP offer/answer 模型 RFC 3264 · RTP 实时文本负载 RFC 4103 · SIP 实时文本框架 RFC 5194 · SIP 电话设备要求 RFC 4504 · WebRTC 数据通道中的 T.140 文字 RFC 8865 · 多方实时文本的 RTP 混合 RFC 9071 · 最低限度初始规范、本地化未来决策与自愿采用 · 运行代码优先