在SIP中，一個典型的呼叫流程包括INVITE、180 Ringing、200 OK和ACK。當被叫方（如SIP終端）接受呼叫時，會發(fā)送200 OK響應，而主叫方（如FreeSWITCH）需要發(fā)送ACK來確認接收到200 OK。這確保了會話的可靠性。

1. SIP 協(xié)議的三次握手流程

SIP 會話的建立遵循 INVITE-200 OK-ACK 三次握手機制，確保雙方可靠地確認會話參數：

INVITE：主叫方（如 FreeSWITCH）發(fā)起呼叫，攜帶 SDP 媒體描述。

200 OK：被叫方（SIP 終端）接受呼叫，返回媒體協(xié)商參數。

ACK：主叫方確認收到 200 OK，完成會話建立。

2. 為什么需要 ACK？

根據SIP協(xié)議，INVITE是一個事務，包含請求和最終響應，而ACK是另一個事務，用于確認最終響應的接收。特別是對于INVITE的2xx響應，ACK是必須的，因為SIP協(xié)議基于UDP時可能需要處理丟包的情況，確保雙方都確認會話已建立。

(1) 協(xié)議規(guī)范要求（RFC 3261）

對 2xx 響應的特殊處理：SIP 協(xié)議規(guī)定，對 INVITE 的 2xx 類響應（如 200 OK）必須通過獨立的 ACK 消息確認。

事務分離：INVITE 和 ACK 屬于不同的事務，確?？煽啃裕ㄓ绕湓?span> UDP 傳輸中）。

(2) 防止消息丟失

UDP 的不可靠性：如果 200 OK 在傳輸中丟失，主叫方會重發(fā) INVITE，被叫方需重新響應。

ACK 的可靠性：通過顯式發(fā)送 ACK，雙方確認媒體參數已協(xié)商完成，避免因丟包導致會話狀態(tài)不一致。

(3) 媒體會話啟動

觸發(fā)媒體流：ACK 的發(fā)送標志雙方已確認媒體參數（如 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 仍會發(fā)送：但僅用于確認響應接收，不建立會話。

會話終止：主叫方收到非 2xx 響應后結束呼叫。

(2) TCP 傳輸

ACK 仍必需：盡管 TCP 是可靠傳輸，但 SIP 協(xié)議要求 ACK 作為邏輯確認步驟。

5. 抓包驗證（Wireshark 示例）

在 Wireshark 中觀察 SIP 消息流，確認流程如下：

INVITE：FreeSWITCH → SIP 終端。

200 OK：SIP 終端 → FreeSWITCH。

ACK：FreeSWITCH → SIP 終端。

6. FreeSWITCH 中的 ACK 處理邏輯

FreeSWITCH 作為 SIP 服務器，在收到 200 OK 后：

驗證 SDP 參數：檢查媒體地址、端口、編解碼是否兼容。

生成 ACK：構造并發(fā)送 ACK 消息。

啟動媒體引擎：根據協(xié)商結果創(chuàng)建 RTP 會話。