一、为什么学 SIP 还必须学 SDP

SIP 负责“建立、修改、终止会话”的信令控制，但它并不直接承载音频或视频媒体流。真正描述媒体参数、编解码能力、端口、地址、方向等信息的，是 SDP（Session Description Protocol）。

因此在很多场景中，SIP 决定“要不要通话”，而 SDP 决定“通话具体怎么传”。

二、SDP 本质上在描述什么

SDP 是一种文本格式的会话描述协议。它重点回答几个问题：

• 媒体从哪里发、发到哪里
• 使用什么媒体类型（audio、video 等）
• 支持哪些编解码能力
• 媒体方向是什么（sendrecv、sendonly、recvonly、inactive）
• 是否携带额外属性，如 fmtp、ptime、rtcp-mux 等

三、常见 SDP 字段怎么理解

常见字段包括：

• v=：版本号
• o=：会话拥有者与会话标识
• s=：会话名称
• c=：连接地址，说明媒体目标地址
• t=：会话时间范围
• m=：媒体行，描述媒体类型、端口、传输协议、负载类型
• a=：属性行，用于扩展编解码、方向、事件、加密等细节

其中最关键的往往是 c= 和 m=，因为它们直接影响媒体往哪里发、用什么端口发。

四、什么是 Offer/Answer 模型

Offer/Answer 是媒体协商的核心模型。它并不是 SIP 独有的概念，而是 SDP 在会话协商中的使用方式。简单说：

• Offer：一方提出自己希望使用的媒体参数集合
• Answer：另一方从中选择、拒绝或约束可接受的媒体参数

这套模型让双方不必预先完全一致，只要能找到交集，就能建立可工作的媒体会话。

五、Offer 和 Answer 一般出现在哪

在 SIP 中，Offer/Answer 常见于以下几种模式：

• INVITE 中带 Offer，200 OK 中带 Answer
• INVITE 不带 Offer，200 OK 中带 Offer，ACK 中带 Answer
• 会话建立后，由 re-INVITE 或 UPDATE 再次触发新一轮 Offer/Answer

所以媒体协商不一定只发生在第一次 INVITE，也可能在会话进行中重新发生。

六、编码协商为什么不是“谁想发什么就发什么”

在 SDP 中，媒体能力通常体现在 m= 行的负载类型，以及配套的 a=rtpmap、a=fmtp、a=ptime 等属性里。媒体双方只有在能力集合有交集时，协商才可能成功。

这意味着：

• 一方支持的编码，另一方未必支持
• 同一种编码，也可能因为参数不一致而需要额外约束
• 某些 Payload Type 是静态的，某些是动态映射的

七、媒体方向为什么很重要

SDP 并不只描述“地址和端口”，还会通过 a=sendrecv、a=sendonly、a=recvonly、a=inactive 等方向属性来表达媒体方向性。

例如保留、静音、单向广播、回铃音等场景，都可能与媒体方向协商密切相关。

八、为什么很多“信令通了但没声音”其实是 SDP 问题

在 SIP 排障中，最常见的误区之一就是只盯着 INVITE、200 OK、ACK 是否正常，而忽略其中的 SDP 内容。实际上很多无声、单通、早期媒体失败等问题，都与以下因素有关：

• c= 地址不可达
• m= 端口错误
• 编解码协商没有交集
• 方向属性不符合预期
• NAT 导致 SDP 声明地址与真实可达地址不一致

九、Offer/Answer 的核心约束思路

从理论上看，Offer/Answer 不是“双方各说各话”，而是一套带约束的协商机制：

• Answer 不能凭空创造不在 Offer 中的媒体能力
• 被拒绝的媒体流通常表现为端口置零等形式
• 会话中再次修改媒体时，需要重新完成一轮合法的 Offer/Answer

十、总结

如果说 SIP 决定了会话控制的时序，那么 SDP 与 Offer/Answer 决定了媒体协商的内容。理解这两者的关系，可以抓住几个重点：

• SIP 是控制，SDP 是描述
• Offer/Answer 是协商模型，不是单个报文名称
• 媒体问题很多时候本质是 SDP 问题
• 会话建立后仍然可能再次发生媒体协商

把这一层理解清楚，再去看 NAT、Symmetric RTP、re-INVITE、Early Media 等话题，会顺畅很多。