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

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

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

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

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

ACK：主叫方確認(rèn)收到 200 OK，完成會話建立。

2. 為什么需要 ACK？

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

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

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

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

(2) 防止消息丟失

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

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

(3) 媒體會話啟動

觸發(fā)媒體流：ACK 的發(fā)送標(biāo)志雙方已確認(rèn)媒體參數(shù)（如 IP、端口、編解碼），可開始傳輸 RTP/RTCP 媒體流。

3.ACK 消息的內(nèi)容

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

關(guān)鍵頭部：

Via：保留原始 INVITE 的 branch 參數(shù)。

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

CSeq：序列號遞增（如 CSeq: 2 ACK）。

無消息體：ACK 通常不攜帶 SDP，媒體參數(shù)已在 200 OK 中確認(rèn)。

4. 特殊情況處理

(1) 非 2xx 響應(yīng)（如 404 Not Found）

ACK 仍會發(fā)送：但僅用于確認(rèn)響應(yīng)接收，不建立會話。

會話終止：主叫方收到非 2xx 響應(yīng)后結(jié)束呼叫。

(2) TCP 傳輸

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

5. 抓包驗證（Wireshark 示例）

在 Wireshark 中觀察 SIP 消息流，確認(rèn)流程如下：

INVITE：FreeSWITCH → SIP 終端。

200 OK：SIP 終端 → FreeSWITCH。

ACK：FreeSWITCH → SIP 終端。

6. FreeSWITCH 中的 ACK 處理邏輯

FreeSWITCH 作為 SIP 服務(wù)器，在收到 200 OK 后：

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

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

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