摘要

  • RFC 5118 展示了上下文相反的写法：SIP URI 中的 IPv6 字面量由方括号界定，SDP 连接地址则不使用这对括号。
  • 把本应位于括号外的端口写进压缩 IPv6 地址，消息仍可通过语法解析，却会把端口变成地址的最后一个八位组对，指向不同目的地。
  • 测试通过只能证明特定版本在特定配置下处理了这些固定输入；它不能证明完整 SIP 合规、正确下一跳、会话建立、媒体可达或真实业务结果。

一条 INVITE 可以在 Request-URI 中写 [2001:db8::10]，同时在 SDP 的 c= 行里写 2001:db8::20。第一处去掉括号会破坏 URI 的主机边界；第二处机械加上括号，反而会破坏 SDP 的字段。

如果清洗系统只会寻找冒号，它看见的是两段相似字符串。如果解析器保留所在语法，它看见的是两个不同对象。RFC 5118 用测试消息把这种差别变成可复现的输入，而不是靠操作员猜测。

括号先划定地址，再让端口出现

IPv6 地址内部已经使用冒号。URI 若还要携带端口，就必须先用方括号封住地址，再在右括号之后写端口。RFC 3261 的结构是主机后接可选端口；IPv6 reference 本身则是括号中的地址。RFC 3986 也把 IP literal 与外部端口分开。

RFC 5118 的关键例子把意图中的 5070 写在右括号里面：

sip:[2001:db8::10:5070]

这并非“解析器把端口读错了”。解析器从未看见端口。它得到一个合法的 IPv6 字面量，其中 5070 已成为最后一个十六位组。经核实的勘误进一步纠正原文：这是最后一个八位组对，而不是单个八位组。

若意图是主机 2001:db8::10 和端口 5070，写法应为：

sip:[2001:db8::10]:5070

两者都可能呈现绿色解析结果，只有后者符合独立记录的意图。因此测试系统必须另存预期主机、预期端口、实际组件树与最后选中的 socket；不能让 valid=true 代替目的地证明。

合法、无效与可容忍不是一条直线

RFC 5118 也给出未用方括号包裹 IPv6 URI 的无效消息，并预期 400 响应。它没有主张“越宽松越好”。

与此同时，Via 的 received 参数出现了历史互操作缝隙。RFC 3261 对 sent-by 使用带括号的 IPv6 reference，对 received 却使用裸 IPv6 address。互操作活动中，不同实现对 received 的括号作出不同假设。

文档给出的策略具有方向性：接收端应能解析有括号与无括号两种 received，发送端则不应加括号。容忍发生在已知入口，输出回到规范形态。它不是在授权解析器删除所有方括号。

这三类行为需要三种标签：严格无效并拒绝；语法有效但意图可疑；严格语法不合却基于明确互操作理由容忍。把它们压成通过／失败，会同时损失风险和理由。

页面排版不是网络报文

SIP 是文本协议，但 RFC 页面受行宽限制。长字段可能被视觉换行。RFC 5118 沿用 RFC 4475 的 allOneLine 约定，说明如何拼回原始单行；又附带编码后的精确消息档案。

从网页复制一段看似相同的文本，可能新增空格、改变换行，甚至让 Content-Length 与正文不再一致。若测试平台在调用解析器前已经自动修正输入，绿色结果证明的是修正后的副本。

因此第一份收据不是运行结果，而是输入保全：来源、提取方式、字节数、哈希、换行与是否预处理。只有输入一致，版本间对比才有意义。

同一报文可以跨越多套地址规则

文档还构造了混合 IPv4 与 IPv6 的 Via 列表、分别为音频和视频指定不同地址族的 SDP，以及在信令或 SDP 中出现的 IPv4-mapped IPv6 地址。URI 中一旦带端口，端口仍必须位于右括号之外。

这些例子阻止了一个常见的中央化冲动：先把所有地址“统一格式”，再交给各层。地址规范化只有在知道字段、语法与后续用途时才安全。丢失上下文后，整齐不是一致，而是不可逆的语义擦除。

RFC 5118 还指出 RFC 3261 的 ABNF 路径可能容纳一个额外冒号。接收方可以为了健壮性接受；若继续转发，应去掉额外冒号。输入理解与输出托管从而成为两项独立责任。

解析器之后才开始验证系统

解析器产生组件树，并不决定 DNS 或路由策略，不证明下一跳接受消息，也不建立 SIP 对话。即便对话存在，SDP 中的媒体地址仍可能不可达；即便媒体包出现，用户目标仍可能失败。

反向也成立。一次通话成功，可能是备用 Contact、上游规范化或重试机制遮住了解析差异。拓扑或版本变化后，隐藏分歧才暴露。

证据链至少应包括：原始字节；适用规则；解析树；发送者意图；规范化或原样输出；所选下一跳；事务结果；对话状态；媒体观测；用户结果。任何一层都不替下一层发言。

测试集的权力必须受其范围限制

RFC 5118 明说自己是 Informational，不对 SIP 作规范性更改，也不穷举所有有效或无效消息。有些用例只压测解析器，有些还触达应用。

因此“100% 通过 RFC 5118”是一条有限陈述：某个构建在某个配置下处理了这些输入。它不是产品证书、IPv6 就绪证明，更不是生产呼叫成功率。

测试集最有价值的角色，是公开接缝：页面与字节、头部与正文、主机与端口、容忍输入与规范输出、解析器与应用。共同层保持足够薄，实际承担后果的运营者才能对异常、兼容与退役作出本地决定。

来源