摘要

  • RFC 9607 登记 audio/scip 与 video/scip，规定 SDP 映射，并要求网络把形态可变的 SCIP 负载作为透明数据转发，不转码、不按当前外形过滤、也不修改。
  • SDP 只协商是否使用 SCIP；内部编解码器、RTP 重组、完整性验收、SCIP 版本与安全会话、对端身份以及最终媒体，各有独立收据。
  • RFC 明确说明 IETF 没有对 SCIP 做安全审查，也没有验证文中的安全主张。

安全设备最正确的动作，是停止猜测

一次会话的 SDP 报文里出现了 a=rtpmap:96 scip/8000。边界设备识别出这个媒体子类型，没有像过去那样把陌生编码从 m= 行里删掉，也没有把负载交给转码器。目的端持续收到 RTP 包，链路统计正常。

这组证据足以说明网络完成了自己的任务：它保留了协商语义，为不透明数据提供了通道。过去恰恰因为中间设备“不认识就删除”，SCIP 端点可能根本无法运行。共同登记消除了这类无意否决权。

但“密文到了”不是“安全通话成立”。抓包看不到接收端是否收齐一个 SCIP 单元、补传是否赶上时限、双方版本是否兼容、预期对端是否被认证、内部编解码器是否达成一致，更看不到人是否听懂一句话。网络没有破坏会话，只是证据链的第一段。

一个媒体名称，只授予有限的协调权

audio/scip 使用 8000 Hz 时钟，video/scip 使用 90000 Hz 时钟。在 SDP 中，m= 指出音频或视频，a=rtpmap 把动态负载编号、scip 名称与时钟率绑定。offer/answer 中的排列表示偏好。

动态编号本身不是全球身份。96 在一场会话里表示 SCIP，在另一场会话里可以表示别的格式。只有完整的 SDP 坐标才能解释随后看到的 RTP 包。因此监控系统若只存“payload type 96”，它保存的是一个脱离上下文的符号。

更重要的是，SDP 不负责选择 SCIP 内部封装的音频或视频编解码器。SCIP 会在透明通道中进行自己的能力交换与版本协商。外层信令打开一条可能路径，内层协议才决定如何使用这条路径。

不透明不是缺少治理，而是治理边界

SCIP 负载的大小、间隔和形态会随协议状态与内部媒体变化。RFC 9607 禁止网络转码、进行有损压缩、修改负载，或根据今天观察到的密文模式过滤流量。中间设备无需知道 SCIP-210 的内部格式，也不应把一次观察固化成未来规则。

如果设备厂商把当前比特外形做成“合规识别”，这项功能很快会变成协议升级的隐性审批机关。端点升级后产生合法的新形态，旧设备却把它当成异常。原本为了安全引入的检测，反而造成协议僵化和通信失败。

透明转发并不取消网络政策。设备仍可依据声明的媒体类型、资源预算、拥塞与访问规则决定是否允许通道。它放弃的只是虚假语义权：不能因为看见密文形状，就声称知道内部消息是什么。

小于 MTU 的包，仍可能拼不成消息

SCIP 应用层负责交给 RTP 的流量不超过 MTU。接收侧的 SCIP RTP 层负责包识别、排序和重组；必要时，应用层负责错误检测与重传。

这些步骤不能压成一个“已送达”指标。发送端构造了合适大小的包，是一张收据；网络送达带序号的数据报，是另一张；接收端凑齐并关闭重组，是第三张；完整性检查接受、补传及时完成、解码器实际消费，又分别是后续收据。

最容易误判的是低比例关键丢包。总体丢失率几乎为零，大多数序号连续，但恰好少了关闭一个控制消息所需的片段。网络面板仍为绿色，应用会话却停在原地。运维记录必须把 RTP 序号范围、重组单元、截止时间与应用处置连接起来。

完整性失败证明拒绝，不证明整个会话安全

RFC 9607 描述 SCIP 负载受到完整性保护。负载若被修改，端点会发现违规，随后可能重传，持续失败则终止通信。这使接收端保留了对可接受字节的本地否决权，中间设备无法悄悄“优化”密文。

一次完整性告警的权威范围很窄：某个端点在某种状态下拒绝了某个对象。它没有自动完成攻击归因；差异也可能来自损坏、状态错位或实现缺陷。它没有说明替代包是否到达。反过来，没有告警也不证明所有包齐全、对端身份正确或媒体可解码。

记录应包含方向、对象或片段坐标、RTP 序号、验收结果、补传请求、替代到达时间与最终应用决策。只有这样，才能区分“否决机制正常工作”和“会话正常工作”。

SCIP 加密没有包住 RTP 的每个表面

SCIP 加密的是 RTP payload 中承载的内容。RFC 9607 同时指出，它不保护 RTP header 与 RTCP 包。若应用需要额外保护，可以选用 SRTP，但该负载格式没有把这层机制设为必选。

因此 AVP、AVPF、SAVP、SAVPF 的选择不能被“SCIP 是安全协议”这句话遮住。外层 profile 决定哪些传输与反馈表面受到怎样的处理。AVPF/SAVPF 的丢包反馈也是可选的，因为 SCIP 会在应用层处理部分错误或丢失数据的重传。

内部加密、外层头部保护、控制反馈保护与来源认证是不同问题。有效的 SRTCP 收据不证明 SCIP 内部协商完成；有效的 SCIP 密文也不证明 RTP header 没有暴露或被改写。

Standards Track 不是一枚未做过的安全认证章

RFC 9607 的说明非常直接：IETF 没有对 SCIP 做安全审查，因此也没有验证文中的相关主张。这句话没有削弱媒体格式标准，反而把它的权威范围说得更准确。

可验证的，是 audio/scip 与 video/scip 的共同登记、时钟率、SDP 映射、透明转发义务、RTP 行为与禁止修改规则。需要另行验证的，是密钥管理、对端认证、机密性强度、协议抗攻击能力以及具体部署是否正确。

采购或审计若只写“符合 RFC 9607，所以安全”，就把传输接缝的标准化冒充成内层协议认证。正确做法是逐项列出所需属性、责任端点、测试方法、证据有效期与失败后的回滚。

来源