Chrome未检测到STUN成功响应问题排查（C语言WebRTC实现）

问题背景 #

我正在用C语言实现一个从零开始的WebRTC开源项目，在STUN连通性检查阶段遇到问题。场景是C客户端Agent1与浏览器Agent2以P2P模式连接，流程如下：

• Agent1（C客户端）→ Agent2（浏览器）：发送Offer
• Agent1 ← Agent2：接收Answer
• Agent1 ↔ Agent2：交换ICE候选地址

完成SDP和ICE候选协商后，启动STUN连通性检查：

• Agent1 ← Agent2：接收STUN绑定请求
• Agent1 → Agent2：返回STUN成功响应

我使用Agent1的ICE密码计算HMAC，计算时消息长度设为包含HMAC属性在内的总长度。通过Wireshark确认响应已发送到正确IP和端口，且HMAC计算正确；指纹计算方式为对包含CRC属性在内的整个STUN包计算CRC，再与0x5354554e异或，代码如下：

uint32_t stun_message_crc32 = 
    crc32(0, stun_message,
          stunpacketsize) ^ 
    0x5354554e;

对比Chrome间P2P连接的正常STUN响应，未发现明显差异，但浏览器WebRTC内部统计显示未收到响应。

可能的原因与排查方向 #

• 事务ID不匹配：Chrome要求STUN响应的事务ID必须与请求的完全一致，包括字节序（大端/小端）。检查响应是否正确复制了请求的事务ID，避免字节序转换错误。
• 属性顺序不符合隐含要求：虽然STUN协议允许属性任意顺序，但Chrome实现可能要求XOR-MAPPED-ADDRESS位于HMAC和FINGERPRINT之前，且HMAC必须在FINGERPRINT之前，这两个属性需作为消息的最后两个属性。
• CRC计算范围错误：计算CRC时，FINGERPRINT属性的CRC值字段应先设为0，再对整个包计算CRC，最后将结果填入该字段。如果直接用包含最终CRC值的包计算，会导致指纹不匹配被Chrome拒绝。
• STUN头长度字段错误：STUN头的长度字段是消息体（不含头）的字节数，且必须是4字节的倍数。检查响应头的长度是否正确计算所有属性的总长度，并对齐到4字节边界。
• XOR-MAPPED-ADDRESS编码错误：该属性的IP和端口需用STUN事务ID进行异或处理，检查IPv4/IPv6地址、端口的异或计算是否正确，字节序是否符合大端标准。
• UDP分片问题：若STUN响应大小超过MTU（通常1500字节），会被分片，Chrome可能无法正确重组分片数据包。检查响应大小是否在MTU范围内，或是否正确处理分片逻辑。
• ICE凭证不匹配：确认响应使用的ICE用户名和密码与协商阶段交换的完全一致，包括大小写、特殊字符。HMAC计算必须使用请求对应的ICE密码。
• STUN版本不兼容：确保实现符合RFC 5389标准，Chrome仅支持该版本，旧的RFC 3489格式的消息会被忽略。

内容的提问来源于stack exchange，提问作者Usama