企业官网建设流程全解析

SIP/SDP媒体协商是VoIP和WebRTC领域的核心机制，而ICE初始offer的发送更是决定了会话能否穿越NAT、顺利建立连接的关键一步。很多刚接触音视频通信的开发者，往往对offer/answer模型耳熟能详，但真正落实到构造SDP、收集ICE候选、通过SIP信令承载并发送时，还是会踩到不少坑。这篇内容聚焦"初始offer"这个环节，把SIP/SDP/ICE三者串联起来，从协议原理到报文构造、再到实际排查经验，一次性讲透。

1. SIP/SDP/ICE三者的角色定位与协作关系

1.1 为什么媒体协商必须靠SIP和SDP配合

SIP（会话初始协议）负责的是"信令面"——也就是建立、修改、终止会话的控制流程，它本身不传输音视频数据。而SDP（会话描述协议）则负责描述"媒体面"的参数，比如用什么编解码、IP和端口是什么、收发方向如何。

打个比方：SIP是打电话时的"拨号"和"接听"动作，SDP就是电话接通后双方约定"说中文还是英文、在哪个房间见面"的细节。没有SIP，双方不知道什么时候开始协商；没有SDP，协商的内容无从谈起。

值得注意的是，SIP协议本身不关心SDP里的具体内容，它只把SDP当作一个"不透明的负载"来传输。这意味着我们可以在SDP里扩展任何字段——例如ICE的候选信息、SSRC、RTP扩展头等——而SIP信令层面无需做任何改动。这种设计是SIP体系能够兼容WebRTC、IMS、传统VoIP等多种场景的关键原因。

1.2 ICE在协商流程中的介入方式

ICE（交互式连接建立）机制解决的是双方在各自NAT后面时，如何发现一条可达的传输路径。它在SDP协商的基础上增加了候选地址收集、优先级排序、连通性检查三个阶段。

实际会话建立过程中，ICE并不是独立运行的，而是把收集到的候选地址写入SDP的属性中，随offer/answer一起交互。初始offer发送时，SDP中必须携带主用地址、候选地址列表，以及用于连通性检查的凭证信息。

这也解释了为什么我们常说"ICE初始offer"——因为offer里不仅要有媒体描述，还要包含ICE的完整候选集和认证信息。只有当对端拿到这些信息后，才能发起STUN binding请求做连通性检测。

1.3 一次完整协商的基本流程回顾

完整流程大致如下：

1. 主叫方（offerer）配置本地编解码、采集媒体地址，启动ICE候选收集。
2. 主叫方将SDP写入SIP消息（通常是INVITE请求）中发送给被叫方（answerer）。
3. 被叫方解析SDP，根据媒体能力选择交集配置，同样启动自己的ICE候选收集。
4. 被叫方将应答SDP放入SIP响应（通常为200 OK）中返回。
5. 双方各自进行ICE连通性检查，选出可用候选对。
6. 媒体流开始在选定路径上传输。

这个流程看似简单，但每个环节都有细节上的考量，尤其是在初始offer构造与发送阶段。接下来重点剖析这个环节。

2. 初始offer中SDP核心字段的构造要点

2.1 会话级描述：版本、来源、会话ID

初始offer的第一行必须是v=0表示协议版本，然后是o=定义会话来源，格式为o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>。

o=里的会话ID和时间戳虽然看起来只是些数字，但在JSEP（JavaScript会议建立协议）体系里必须使用随机数或时间戳，不能全部填0。因为对端会根据这个值判断是否是同一会话的更新；如果offer里o=的版本不变，对端可能认为这是一次重复的更新而丢弃处理。

会话级还包含s=（会话名，可填-或空串）、t=（激活时间范围，通常为0 0表示不限制）、a=*级别的全局属性。这些字段虽然简单，但在构造时必须完整——缺少任意一行，一些严格的SIP服务器或对端栈会直接返回400错误。

2.2 媒体级描述：RTP端口与媒体类型

媒体级描述以m=开头，格式为m=<media> <port> <proto> <fmt>。初始offer中最常见的是：

m=audio 49170 RTP/AVP 96 0 8 m=video 51372 RTP/AVP 97 98

这里有几个容易出错的地方。

端口号从技术上说，ICE可能后续会用其他端口，但SDP中的端口号必须填实际绑定的RTP端口，不能随意填一个占位值。很多开发者直接填0，这在ICE优先的offer里对端能容忍，但为了兼容保守的SIP终端，还是建议填写真实端口。

协议类型最常见的是RTP/AVP或RTP/SAVP。如果是WebRTC场景，通常是RTP/AVP，因为加密由DTLS-SRTP承载，而不是靠SDP的加密属性。部分实现在协商SRTP时会写RTP/SAVP，这在纯WebRTC对接时反而可能引起问题，建议根据实际加密方式选择，不要混用。

fmt是RTP payload type编号列表。这里要注意，payload type数字只是约定的映射关系，不是绝对固定的。例如96可能表示Opus，也可能表示H.264，具体含义要通过rtpmap属性来声明。

2.3 关键属性：rtpmap、fmtp与sendrecv方向

每一个payload type需要配合rtpmap属性说明编解码名称、采样率、声道数：

a=rtpmap:96 opus/48000/2 a=rtpmap:97 H264/90000

对于H.264，通常还需要fmtp指定profile-level-id和packetization-mode，否则对端可能无法正确解码。比如：

a=fmtp:97 profile-level-id=42e01f;packetization-mode=1

方向属性是另一个高频踩坑点。默认情况下，如果缺席方向属性，SDP规范要求按sendrecv处理，但问题在于部分终端实现把缺席理解为inactive或recvonly，导致一方只发不收。初始offer中最好显式写明方向属性，尤其要确认收发方向与真实业务预期一致——例如投屏场景和普通通话场景的方向要求完全不同。

2.4 连接信息：c=行与兼容性

传统的SDP在媒体级必须有c=行指定IP地址，比如c=IN IP4 192.168.1.100。但启用ICE后，真正用于媒体传输的地址由ICE候选决定，c=行更多是"占位"作用。

一个普遍的做法是在媒体级写c=IN IP4 0.0.0.0。这样做的原因是：offer端可能尚未确定最终路径，用0.0.0.0表示"不指定"，实际地址通过ICE候选来通知。

不过有个兼容性细节：某些老旧的SIP栈或者网关以c=行为准，忽略ICE候选。如果对接方确实不支持ICE较老版本，初始offer就不能写0.0.0.0，而要填一个真实可达地址。建议开发前先确认对端完整的ICE能力，不能用唯一方案应对所有场景。

3. ICE候选在offer中的编码方式与实现路径

3.1 候选地址的收集策略

初始offer发送前，必须先完成ICE候选收集。收集过程涉及三个来源：

• 本地接口地址（host候选）：直接绑定网卡上的IPv4/IPv6地址。
• STUN反射地址（srflx候选）：通过向STUN服务器发送binding请求，得到NAT映射后的公网地址。
• TURN中继地址（relay候选）：通过TURN服务器的Allocate请求分配中转地址。

在编码为SDP候选时，每个候选的基本格式为：

a=candidate:<foundation> <component-id> <transport> <priority> <connection-address> <port> typ <type>

例如：

a=candidate:1 1 UDP 2130706431 192.168.1.100 49170 typ host a=candidate:2 1 UDP 1694498815 203.0.113.5 52478 typ srflx raddr 192.168.1.100 rport 52478

3.2 优先级计算与选择次序

优先级是一个32位无符号整数，数值越大越优先。ICE规范中推荐的公式为：

优先级 = (2^24) × type-preference + (2^8) × local-preference + (2^0) × component-id

实际取值时，常见的type preference建议为：host=126、srflx=100、relay=0。local preference用于同一类型内部排序，比如多个网卡时可以选择性配置。

一个真实场景的建议是：host候选优先级最高，srflx次之，relay最低。因为host候选直连延迟最低；srflx穿越NAT但路径仍可能最优；relay需要经过TURN服务器中转，链路更长、带宽受限，仅作为最后保底方案。

3.3 附着在SDP中的非媒体属性

ICE的凭证与ufrag是连通性检查的关键：

a=ice-ufrag:qwer a=ice-pwd:asdfghjklzxcvbnm

这两个值必须是随机生成的，长度至少24字节，推荐使用强随机算法生成。密码破解或字典猜测的风险在于：如果用户名片段和密码太弱，攻击者可能伪造STUN binding响应来劫持媒体流。所以生产环境一定要用高熵随机值。

在offer重协商时，ice-ufrag和ice-pwd不变，ICE的候选集和媒体描述可能改变。对端通过ufrag是否变化来判断是全新ICE会话还是已有会话的更新。

3.4 端到端示例：一封完整的ICE初始offer

把前面所有字段组合起来，一段完整的初始offer（媒体级节选）如下：

v=0 o=alice 289083124 289083124 IN IP4 192.168.1.100 s=- t=0 0 m=audio 49170 RTP/AVP 96 c=IN IP4 0.0.0.0 a=rtpmap:96 opus/48000/2 a=sendrecv a=ice-ufrag:qwer a=ice-pwd:asdfghjklzxcvbnm a=candidate:1 1 UDP 2130706431 192.168.1.100 49170 typ host a=candidate:2 1 UDP 1694498815 203.0.113.5 52478 typ srflx raddr 192.168.1.100 rport 52478 a=candidate:3 1 UDP 1677729535 198.51.100.7 3478 typ relay raddr 203.0.113.5 rport 52478

这段SDP既包含媒体描述，又包含ICE的候选、凭证信息，可以放入SIP INVITE的body中直接发送。

4. 初始offer通过SIP发送的完整流程

4.1 信令承载与Content-Type配置

SIP消息体中要携带SDP，就必须明确设置Content-Type头。标准写法是：

Content-Type: application/sdp

有的实现会写成application/sdp;charset=UTF-8或附加其他参数，虽然兼容，但建议保持简洁。另外，SIP还支持多部分MIME，例如同时携带SDP和会话级XML信息时，Content-Type需要改成multipart/mixed并带上boundary定义。

初始offer的SDP大小也可能成为一个实际问题。尤其当候选地址数量较多、频道数多时，SDP payload可能超过UDP承载单个SIP消息的合理上限。这种情况下要考虑切换到TCP传输或用SIP消息分段机制，避免不必要的传输失败。

4.2 主叫方INVITE构造实例

以一个典型SIP客户端发起呼叫为例，构造INVITE请求时：

INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK-3841 Max-Forwards: 70 From: "Alice" <sip:alice@example.com>;tag=12345 To: <sip:bob@example.com> Call-ID: abcdef-12345 CSeq: 1 INVITE Contact: <sip:alice@192.168.1.100:5060> Content-Type: application/sdp Content-Length: 780 [此处为上一节构造的SDP]

从技术角度看，有几个重要细节：

• Via和Contact里的IP必须是实际可达的地址，不能随意填局域网地址而不做NAT映射。如果客户端在NAT后，通常需要借助STUN或人工配置公网映射地址来保证响应能原路返回。
• branch参数必须是唯一的，用于事务匹配。重复branch会导致多个事务消息被错误关联。
• Call-ID在整个会话期间保持不变，重协商或注册刷新都不变。
• CSeq在会话内逐步递增，重协商时用新CSeq。

4.3 被叫方应答与后续握手

被叫方收到INVITE后，首先会返回临时响应（例如100 Trying），随后可能振铃并返回180 Ringing。最终接听后，发送200 OK，其中body携带answer SDP。

对于有初始offer的INVITE，answer的生成必须遵循offer/answer模型：

• 编解码理论上有任意选择组合的可能，但实践中必须取两方能力的交际。
• 端口和候选地址由被叫方本地收集。
• 应答中的方向属性可能与offer不同，例如主叫offer是sendrecv，被叫answer可以是sendrecv或recvonly。

最终主叫方收到200 OK后，需要回复ACK，这是SIP三次握手的关键确认。到这里，SIP信令面的协商算是完成了，接下来进入ICE连通性检查阶段。

4.4 信令与ICE的时序关系

媒体流到达前，ICE连通性检查不一定非要在SIP ACK之前完成，但双方都必须尝试在ACK后快速启动检查。

一个常见的实现方式是：被叫方在发出200 OK时，立即开始针对主叫方offer中的候选做连通性检测；主叫方在收到200 OK并解析answer后，同样启动检查。这样总体建立时间可以控制在数百毫秒内。

如果SIP经过代理服务器，而代理服务器又修改了SDP（例如某些B2BUA会改写IP或端口），那么ICE候选信息必须保持同步修改。一旦代理改了SDP里的IP但没有改ICE候选，会导致连通性检测的目标地址错误。这个问题在部署SIP代理时特别常见，排查思路是要确认SDP和候选的一致性。

5. 常见故障场景与问题排查经验

5.1 offer发送后对端回应"488 Not Acceptable Here"

这个错误意味着被叫方无法处理当前offer中的媒体描述。常见原因有：

• SDP中编解码没有交集：主叫只列出一种对端不支持的payload type。
• 缺少必要的属性：例如H.264的fmtp缺失或profile-level-id不匹配。
• m=行格式错误，导致被叫方的SDP解析器无法识别。

排查建议：在收到488后，先检查被叫方支持的编解码列表，确认rtpmap和fmtp声明正确。必要时可以先发一个只带PCMU/PCMA的最简offer来验证基础的协商能力。

5.2 ICE候选对协商成功但媒体不通

SIP协商成功、ICE状态最终却是FAILED，常见原因排查顺序：

1. 确认是否所有候选都进入了SDP：如果候选收集发生在offer构造之前，但网络切换导致IP变化，可能导致候选失效。
2. 检查连通性检查是否使用了正确的权限凭证：ufrag和ice-pwd是否与SDP中公布的一致。
3. 确认STUN binding请求的端口：对端的端口一边来自SDP的候选端口，但不应该混用RTP端口与STUN端口——ICE基于同一端口复用UDP通信。
4. 字节序问题：有些实现可能在转发候选时把IPv6地址的表示形式写错，导致对端无法拼出合法地址。保存原始日志进行比较是必要的排查手段。

5.3 同一条SIP会话中多次重协商导致ICE重启

rfc8445（新版ICE）与之前的RFC 5245相比，一个显著区别在于ICE重启条件的改变。旧版本中以ice-ufrag是否变化作为判断依据；新版本中如果候选集完全相同但ufrag变化，某些实现会视为新会话导致全部检查重头来过。

实际应用的经验是：

• 不要在不需要的情况下重新生成ufrag和ice-pwd。
• 重协商仅改变编解码组合时，保持原ICE凭证不变。
• 只有在媒体地址集合变化时才考虑ICE重启。

5.4 SDP解析错误日志分析

日志里常见的SDP解析错误包括：

• "Bad sdp: no media descriptions"：全部m=行缺失，通常是被对端或代理剥离了media字段。
• "Unknown attribute"：会话或媒体级别出现了对端不认识的a=字段。对标准兼容性要求高的场景，扩展开关需要做好协商。
• "Zero port in m-line"：有一些网关会以端口0来拒绝某种媒体流类型，这对健壮性要求高的双向协商可能导致误判，排查时注意区分这种"显式拒绝"与错误格式。

排除这类问题的通用方法：在发送INVITE前把SDP完整打印到日志，进行本地解析验证；再在接收端另存原始SDP进行一致性比对。

5.5 对端通过ICE成功，但RTP始终无法解出明文

如果ICE已经完成，但媒体数据乱码或无法解密，要优先检查DTLS握手是否成功，而非RTP问题。

WebRTC场景中，SRTP主密钥由DTLS导出，只要DTLS握手失败，RTP即使到达也无法解密。常见诱因是DTLS fingerprint不匹配：

• a=fingerprint:sha-256 XX:XX:...与证书不匹配。
• 协商时选了DTLS 1.0的对端，但本地已经不支持。
• 使用的证书在握手期间过期或无效，导致DTLS alert。

排查方法是用openssl s_client或抓包分析DTLS握手流程中各指纹消息。定位到问题是证书不一致还是版本不匹配，针对性修复。

6. 经验总结与优化建议

6.1 设计SDP与ICE时的务实顺序

在实际开发中，我建议按以下顺序设计初始offer流程：

1. 先确定会话业务类型（音频通话、视频会议、直播推流），据此选择媒体类型和编解码。
2. 配置好ICE的STUN/TURN服务，保证候选收集组件可用。在多种网络环境下都要保证TURN可作为兜底。
3. 构造offer时先写会话级字段，再写媒体级描述，增加ICE候选和凭证。
4. 在SIP栈层面确认Content-Type和其他头部正确。
5. 发送后跟踪信令状态，并开启ICE状态回调进行调试。

6.2 性能与可维护性方面的建议

从短期的信令建立时长看，影响最大的是候选收集等待时间。STUN请求超时重试周期默认按500ms递增，如果网络抖动，可能拖长offer构造时间。实际工程中可以用并发查询STUN/TURN，同时对多个候选地址的应答做超时控制。

从长期可维护性看，将SDP构造、候选收集、连通性状态三部分逻辑分离，编码时容易定位问题，测试也更容易添加用例。尤其注意候选信息的日志结构要利于调试，比如每次协商都输出一个关联会话ID。

6.3 排查问题时的抓手

排查SIP/SDP协商问题，最紧要的是完整抓取信令包与RTP/STUN报文。只依赖应用日志往往不够定位NAT问题。常用的排查组合：

• 在SIP信令层面确认offer/answer内容一致性。
• 在STUN层面查看Binding Request/Response是否成功收到。
• 在RTP/DTLS层面查看是否出现实际操作中的握手或加密错误。

用抓包工具验证时，把每个IP/端口对应关系整理成表格，对着SDP候选逐一比对，通常能很快缩小问题范围。

6.4 若要从零实现一个客户端

如果是从零开始实现一个支持ICE初始offer发送的SIP客户端，建议分步骤验证：

1. 先让两台机器在局域网内完成纯host候选的SIP+SDP协商。
2. 再用一台公网STUN服务器增加srflx候选，验证NAT反射路径。
3. 加入TURN中继候选，验证中继和候选优先级排序是否如期生效。
4. 最后增加ICE重启、DTLS-SRTP等高级功能。

按这个顺序推进，每增加一层特性，排查难度也是逐步递进的，不容易被多个变量纠缠住思路。

初始offer发送这个环节，既是SIP媒体协商的起点，也是ICE机制真正发挥作用的契机。很多人习惯把信令协商和媒体建立拆成两件事来学，但在实际部署中它们是一枚硬币的两面——SDP承载了ICE的信令，ICE的候选又影响了SDP的内容。把offer/answer模型与ICE候选收集、优先级计算、SIP消息承载放在一起理解，才能真正掌握整个媒体会话的建立过程。我个人的体会是：与其死记协议字段，不如亲手抓一次完整的呼叫流程，把offer、answer、STUN、DTLS几个关键阶段的报文逐一对照，很多看似晦涩的规范细节会变得非常直白。