1、ACK在SIP INVITE中作用
在前面的文章中，我們已經(jīng)完整介紹了關(guān)于100 Trying和可靠性傳輸的關(guān)系，并且我們耗費了很多篇幅討論100 Trying的問(wèn)題和細節。很多讀者可能也想到了，如果要完成一個(gè)完整的可靠性傳輸，200 OK的傳輸也是必不可少的環(huán)節。如果200 OK傳輸出現問(wèn)題，當然，后面也不可能出現ACK的傳輸。因此，在討論ACK之前，首先討論一下簡(jiǎn)單的200 OK傳輸的流程。
在200 OK傳輸過(guò)程啟動(dòng)時(shí)，被呼叫方響應就會(huì )啟動(dòng)另外一個(gè)定時(shí)器來(lái)計時(shí)。如果對端在超時(shí)后沒(méi)有收到200 OK，則說(shuō)明200 OK丟失，重新發(fā)送，直到呼叫方收到200 OK，然后發(fā)送ACK請求，直到被呼叫方最終收到ACK請求消息，確保可靠性傳輸的完全完成。接下來(lái)，我們討論一下ACK的角色。
2、關(guān)于SIP中ACK的疑惑
很多讀者可能對ACK有一些疑惑。ACK好像沒(méi)有自己?jiǎn)?dòng)什么流程，不像其他的請求，例如INVITE那樣可以啟動(dòng)一個(gè)請求。那么，ACK到底是一個(gè)request請求還是response響應？ 根據RFC3261的對request和response的定義，request定義中規定，請求必須有Method 類(lèi)型，而response必須以狀態(tài)碼和響應短語(yǔ)構成。在RFC3261 7.1和7.2中有這樣的語(yǔ)法規范：
- Request：
- Request-Line = Method SP Request-URI SP SIP-Version CRLF
- responses：
- Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
以下示例簡(jiǎn)單說(shuō)明了什么是請求和響應的區別。因此，從定義來(lái)說(shuō)，ACK是一個(gè)請求 method。
但是，讓讀者感到迷惑的是，如果是一個(gè)request的話(huà)，request至少需要啟動(dòng)流程執行什么動(dòng)作，但是好像ACK并自己?jiǎn)?dòng)流程，ACK僅負責發(fā)送了響應消息。實(shí)際上，ACK也僅負責對可靠性傳輸的最終確認。因此，無(wú)論讀者有什么樣的迷惑，根據RFC3261的規范，ACK仍然是一個(gè)request。
3、ACK本身就是一個(gè)transaction
剛才，筆者已經(jīng)在前面提到，ACK的概念好像和請求的規定有一些沖突，但是，ACK的語(yǔ)法是符合對request的定義的，因此它仍然是一個(gè)請求。筆者希望讀者明確這個(gè)概念。但是，如果我們討論到SIP transaction時(shí)，很多用戶(hù)就非常迷惑ACK的使用。為什么在INVITE的示例中，ACK是獨立的一個(gè)transaction呢？為了回答這個(gè)問(wèn)題，我們需要根據RFC3261的規范來(lái)說(shuō)明ACK。
根據SIP transaction-17的定義，一個(gè)transaction必須是以request開(kāi)始，以一個(gè)或者多個(gè)最終response結束，中間可以支持多個(gè)臨時(shí)響應。
- Specifically, a SIP transaction consists of a single request and any responses to
- that request, which include zero or more provisional responses and
- one or more final responses.
但是，在RFC3261-17中，transaction另外有一段對transaction的特別說(shuō)明，可能一般讀者沒(méi)有注意到這段說(shuō)明解釋。它是這樣定義的：
In the case of a transaction where the request was an INVITE （known as an INVITE transaction）
，If the response was a 2xx, the ACK is not considered part of the transaction.
按照這個(gè)定義，ACK就可以構成自己獨立的transaction，因此，如果滿(mǎn)足了以上條件的話(huà)（這里的響應是200 OK），那么，ACK本身自己就是一個(gè)transaction。
如果讀者能夠理解以上解釋?zhuān)x者可能就徹底理解了為什么在一個(gè)完整的呼叫流程中，ACK是一個(gè)獨立的transaction。
4、僅INVITE中才能看到ACK
在SIP呼叫中，我們?yōu)槭裁粗荒茉贗NVITE的請求中看到ACK，其他的請求中卻沒(méi)有看到ACK（例如BYE中）？
BYE中則沒(méi)有看到ACK的出現：
下面，我們解釋一下其中的原因。 其實(shí)原因也很簡(jiǎn)單。大部分情況下，INVITE的請求發(fā)送以后，電話(huà)系統需要人工干預，例如需要等被呼叫方來(lái)接聽(tīng)，而其他的請求則無(wú)需人工干預，例如BYE和注冊。下面，我們解釋一下非INVITE請求中為什么沒(méi)有出現ACK。
BYE請求是一種無(wú)ACK的使用場(chǎng)景。如果一方掛機的話(huà)，無(wú)需另外一方進(jìn)行人工干預。，例如，被呼叫方僅通過(guò)終端自動(dòng)簡(jiǎn)單回復200 OK就可以實(shí)現整個(gè)流程的完整性。
同樣，注冊也是一樣的道理，如果UAC需要對服務(wù)器端發(fā)送注冊請求時(shí)，服務(wù)器端僅根據注冊請求的信息來(lái)驗證其身份即可，無(wú)需進(jìn)行人工干預。服務(wù)器端驗證UAC的信息，則會(huì )自動(dòng)返回一個(gè)最終響應消息。
但是，如果是INVITE請求的話(huà)，則實(shí)現的流程完全不同。因為，如果呼叫方發(fā)起呼叫以后，對端話(huà)機振鈴。在振鈴時(shí)間內，如果被呼叫方不在工作臺的話(huà)，電話(huà)一直振鈴，系統需要花費一定時(shí)間來(lái)等待被呼叫方應答，接聽(tīng)電話(huà)，這時(shí)是需要人工干預來(lái)完成一個(gè)可靠性傳輸過(guò)程。當然，用戶(hù)可以通過(guò)一些軟交換呼叫路由的設置（SIP頭添加alter-info：ring answer），終端電話(huà)（設置 Ring Answer）也可以實(shí)現呼叫的自動(dòng)應答，這是另外一個(gè)話(huà)題。
通過(guò)以上例子，我們可以看到，其他的非INVITE都可以通過(guò)自動(dòng)化的處理方式來(lái)實(shí)現，無(wú)需人工干預。因此，只有INVITE中帶有ACK請求回復，而沒(méi)有看到其他的請求中帶ACK的請求回復。
5、ACK的其他討論
因為篇幅的關(guān)系，筆者還沒(méi)有完全討論ACK的語(yǔ)法和完整的細節，因為ACK請求涉及了很多不同的場(chǎng)景，并且靈活性也很大，具體的細節建議大家查閱RFC3261。這里，我們簡(jiǎn)單討論結果可能經(jīng)常遇到的問(wèn)題。
首先，在涉及到SIP transaction中，大家需要注意，在INVITE的ACK是一個(gè)獨立的transaction（剛才我們已經(jīng)提及）。
其次，ACK在某些場(chǎng)景中可能被忽略，例如在無(wú)狀態(tài)的服務(wù)器端對ACK的處理機制。根據RFC3261 8.2.7的規范，無(wú)狀態(tài)UAS中必須忽略ACK請求。這個(gè)一定要注意。
最后，ACK的處理機制依賴(lài)于最終響應的類(lèi)型。在UAC發(fā)起發(fā)起初始化請求，UAC需要對每個(gè)最終響應（300-699）發(fā)送一個(gè)響應消息，但是處理這個(gè)ACK的機制完全取決于response的響應類(lèi)型。在transaction進(jìn)行處理時(shí)遵從具體的規則。關(guān)于規則的定義，讀者可以查閱REFC3261的17章節。
6、總結
在本文章中，筆者首先介紹了ACK在INVITE呼叫流程中的構成和其必要性，然后筆者解釋了ACK到底是請求還是一個(gè)響應的疑惑，接下來(lái)筆者討論了非INVITE請求中沒(méi)有帶ACK的原因，最后，筆者討論了ACK幾個(gè)其他方面需要特別注意的地方。
通過(guò)以上討論，筆者為讀者提供了相對比較全面的ACK的了解。為了解釋的便利，筆者在示例中僅使用了點(diǎn)對點(diǎn)的呼叫并沒(méi)有涉及多個(gè)代理之間的呼叫和多個(gè)hop的處理。因此，對ACK的流程處理的討論相對比較基礎和簡(jiǎn)單。如果討論討論比較復雜的ACK處理機制，需要涉及其他的SIP的概念和內容，因為篇幅的關(guān)系不再做過(guò)多展開(kāi)討論，希望讀者諒解，我們在未來(lái)的章節中會(huì )根據實(shí)際內容的安排做更加深入地討論。
參考資料：
https://tools.ietf.org/html/rfc3261
https://arxiv.org/pdf/0807.1160.pdf
https://tools.ietf.org/html/rfc5407
關(guān)注微信公眾號：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享
Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技術(shù)文檔： www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
