为什么需要回复ACK消息

在SIP中，一个典型的呼叫流程包括INVITE、180 Ringing、200 OK和ACK。当被叫方（如SIP终端）接受呼叫时，会发送200 OK响应，而主叫方（如FreeSWITCH）需要发送ACK来确认接收到200 OK。这确保了会话的可靠性。

1. SIP 协议的三次握手流程

SIP 会话的建立遵循 INVITE-200 OK-ACK 三次握手机制，确保双方可靠地确认会话参数：

INVITE：主叫方（如 FreeSWITCH）发起呼叫，携带 SDP 媒体描述。

200 OK：被叫方（SIP 终端）接受呼叫，返回媒体协商参数。

ACK：主叫方确认收到 200 OK，完成会话建立。

2. 为什么需要 ACK？

根据SIP协议，INVITE是一个事务，包含请求和最终响应，而ACK是另一个事务，用于确认最终响应的接收。特别是对于INVITE的2xx响应，ACK是必须的，因为SIP协议基于UDP时可能需要处理丢包的情况，确保双方都确认会话已建立。

(1) 协议规范要求（RFC 3261）

对 2xx 响应的特殊处理：SIP 协议规定，对 INVITE 的 2xx 类响应（如 200 OK）必须通过独立的 ACK 消息确认。

事务分离：INVITE 和 ACK 属于不同的事务，确保可靠性（尤其在 UDP 传输中）。

(2) 防止消息丢失

UDP 的不可靠性：如果 200 OK 在传输中丢失，主叫方会重发 INVITE，被叫方需重新响应。

ACK 的可靠性：通过显式发送 ACK，双方确认媒体参数已协商完成，避免因丢包导致会话状态不一致。

(3) 媒体会话启动

触发媒体流：ACK 的发送标志双方已确认媒体参数（如 IP、端口、编解码），可开始传输 RTP/RTCP 媒体流。

3.ACK 消息的内容

方法类型：ACK sip:user@client_ip SIP/2.0

关键头部：

Via：保留原始 INVITE 的 branch 参数。

From/To/Call-ID：与 INVITE 一致。

CSeq：序列号递增（如 CSeq: 2 ACK）。

无消息体：ACK 通常不携带 SDP，媒体参数已在 200 OK 中确认。

4. 特殊情况处理

(1) 非 2xx 响应（如 404 Not Found）

ACK 仍会发送：但仅用于确认响应接收，不建立会话。

会话终止：主叫方收到非 2xx 响应后结束呼叫。

(2) TCP 传输

ACK 仍必需：尽管 TCP 是可靠传输，但 SIP 协议要求 ACK 作为逻辑确认步骤。

5. 抓包验证（Wireshark 示例）

在 Wireshark 中观察 SIP 消息流，确认流程如下：

INVITE：FreeSWITCH → SIP 终端。

200 OK：SIP 终端 → FreeSWITCH。

ACK：FreeSWITCH → SIP 终端。

6. FreeSWITCH 中的 ACK 处理逻辑

FreeSWITCH 作为 SIP 服务器，在收到 200 OK 后：

验证 SDP 参数：检查媒体地址、端口、编解码是否兼容。

生成 ACK：构造并发送 ACK 消息。

启动媒体引擎：根据协商结果创建 RTP 会话。