1、ACK在SIP INVITE中作用
在前面的文章中，我們已經(jīng)完整介紹了關(guān)于100 Trying和可靠性傳輸?shù)年P(guān)系，并且我們耗費了很多篇幅討論100 Trying的問題和細節(jié)。很多讀者可能也想到了，如果要完成一個完整的可靠性傳輸，200 OK的傳輸也是必不可少的環(huán)節(jié)。如果200 OK傳輸出現(xiàn)問題，當然，后面也不可能出現(xiàn)ACK的傳輸。因此，在討論ACK之前，首先討論一下簡單的200 OK傳輸?shù)牧鞒獭?/div>
在200 OK傳輸過程啟動時，被呼叫方響應(yīng)就會啟動另外一個定時器來計時。如果對端在超時后沒有收到200 OK，則說明200 OK丟失，重新發(fā)送，直到呼叫方收到200 OK，然后發(fā)送ACK請求，直到被呼叫方最終收到ACK請求消息，確�？煽啃詡鬏�?shù)耐耆瓿伞＝酉聛�，我們討論一下ACK的角色。
2、關(guān)于SIP中ACK的疑惑
很多讀者可能對ACK有一些疑惑。ACK好像沒有自己啟動什么流程，不像其他的請求，例如INVITE那樣可以啟動一個請求。那么，ACK到底是一個request請求還是response響應(yīng)？ 根據(jù)RFC3261的對request和response的定義，request定義中規(guī)定，請求必須有Method 類型，而response必須以狀態(tài)碼和響應(yīng)短語構(gòu)成。在RFC3261 7.1和7.2中有這樣的語法規(guī)范：
- Request：
- Request-Line = Method SP Request-URI SP SIP-Version CRLF
- responses：
- Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
以下示例簡單說明了什么是請求和響應(yīng)的區(qū)別。因此，從定義來說，ACK是一個請求 method。
但是，讓讀者感到迷惑的是，如果是一個request的話，request至少需要啟動流程執(zhí)行什么動作，但是好像ACK并自己啟動流程，ACK僅負責發(fā)送了響應(yīng)消息。實際上，ACK也僅負責對可靠性傳輸?shù)淖罱K確認。因此，無論讀者有什么樣的迷惑，根據(jù)RFC3261的規(guī)范，ACK仍然是一個request。
3、ACK本身就是一個transaction
剛才，筆者已經(jīng)在前面提到，ACK的概念好像和請求的規(guī)定有一些沖突，但是，ACK的語法是符合對request的定義的，因此它仍然是一個請求。筆者希望讀者明確這個概念。但是，如果我們討論到SIP transaction時，很多用戶就非常迷惑ACK的使用。為什么在INVITE的示例中，ACK是獨立的一個transaction呢？為了回答這個問題，我們需要根據(jù)RFC3261的規(guī)范來說明ACK。
根據(jù)SIP transaction-17的定義，一個transaction必須是以request開始，以一個或者多個最終response結(jié)束，中間可以支持多個臨時響應(yīng)。
- 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的特別說明，可能一般讀者沒有注意到這段說明解釋。它是這樣定義的：
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.
按照這個定義，ACK就可以構(gòu)成自己獨立的transaction，因此，如果滿足了以上條件的話（這里的響應(yīng)是200 OK），那么，ACK本身自己就是一個transaction。
如果讀者能夠理解以上解釋，讀者可能就徹底理解了為什么在一個完整的呼叫流程中，ACK是一個獨立的transaction。
4、僅INVITE中才能看到ACK
在SIP呼叫中，我們?yōu)槭裁粗荒茉贗NVITE的請求中看到ACK，其他的請求中卻沒有看到ACK（例如BYE中）？
BYE中則沒有看到ACK的出現(xiàn)：
下面，我們解釋一下其中的原因。 其實原因也很簡單。大部分情況下，INVITE的請求發(fā)送以后，電話系統(tǒng)需要人工干預(yù)，例如需要等被呼叫方來接聽，而其他的請求則無需人工干預(yù)，例如BYE和注冊。下面，我們解釋一下非INVITE請求中為什么沒有出現(xiàn)ACK。
BYE請求是一種無ACK的使用場景。如果一方掛機的話，無需另外一方進行人工干預(yù)。，例如，被呼叫方僅通過終端自動簡單回復(fù)200 OK就可以實現(xiàn)整個流程的完整性。
同樣，注冊也是一樣的道理，如果UAC需要對服務(wù)器端發(fā)送注冊請求時，服務(wù)器端僅根據(jù)注冊請求的信息來驗證其身份即可，無需進行人工干預(yù)。服務(wù)器端驗證UAC的信息，則會自動返回一個最終響應(yīng)消息。
但是，如果是INVITE請求的話，則實現(xiàn)的流程完全不同。因為，如果呼叫方發(fā)起呼叫以后，對端話機振鈴。在振鈴時間內(nèi)，如果被呼叫方不在工作臺的話，電話一直振鈴，系統(tǒng)需要花費一定時間來等待被呼叫方應(yīng)答，接聽電話，這時是需要人工干預(yù)來完成一個可靠性傳輸過程。當然，用戶可以通過一些軟交換呼叫路由的設(shè)置（SIP頭添加alter-info：ring answer），終端電話（設(shè)置 Ring Answer）也可以實現(xiàn)呼叫的自動應(yīng)答，這是另外一個話題。
通過以上例子，我們可以看到，其他的非INVITE都可以通過自動化的處理方式來實現(xiàn)，無需人工干預(yù)。因此，只有INVITE中帶有ACK請求回復(fù)，而沒有看到其他的請求中帶ACK的請求回復(fù)。
5、ACK的其他討論
因為篇幅的關(guān)系，筆者還沒有完全討論ACK的語法和完整的細節(jié)，因為ACK請求涉及了很多不同的場景，并且靈活性也很大，具體的細節(jié)建議大家查閱RFC3261。這里，我們簡單討論結(jié)果可能經(jīng)常遇到的問題。
首先，在涉及到SIP transaction中，大家需要注意，在INVITE的ACK是一個獨立的transaction（剛才我們已經(jīng)提及）。
其次，ACK在某些場景中可能被忽略，例如在無狀態(tài)的服務(wù)器端對ACK的處理機制。根據(jù)RFC3261 8.2.7的規(guī)范，無狀態(tài)UAS中必須忽略ACK請求。這個一定要注意。
最后，ACK的處理機制依賴于最終響應(yīng)的類型。在UAC發(fā)起發(fā)起初始化請求，UAC需要對每個最終響應(yīng)（300-699）發(fā)送一個響應(yīng)消息，但是處理這個ACK的機制完全取決于response的響應(yīng)類型。在transaction進行處理時遵從具體的規(guī)則。關(guān)于規(guī)則的定義，讀者可以查閱REFC3261的17章節(jié)。
6、總結(jié)
在本文章中，筆者首先介紹了ACK在INVITE呼叫流程中的構(gòu)成和其必要性，然后筆者解釋了ACK到底是請求還是一個響應(yīng)的疑惑，接下來筆者討論了非INVITE請求中沒有帶ACK的原因，最后，筆者討論了ACK幾個其他方面需要特別注意的地方。
通過以上討論，筆者為讀者提供了相對比較全面的ACK的了解。為了解釋的便利，筆者在示例中僅使用了點對點的呼叫并沒有涉及多個代理之間的呼叫和多個hop的處理。因此，對ACK的流程處理的討論相對比較基礎(chǔ)和簡單。如果討論討論比較復(fù)雜的ACK處理機制，需要涉及其他的SIP的概念和內(nèi)容，因為篇幅的關(guān)系不再做過多展開討論，希望讀者諒解，我們在未來的章節(jié)中會根據(jù)實際內(nèi)容的安排做更加深入地討論。
參考資料：
https://tools.ietf.org/html/rfc3261
https://arxiv.org/pdf/0807.1160.pdf
https://tools.ietf.org/html/rfc5407
關(guān)注微信公眾號：asterisk-cn，獲得有價值的Asterisk行業(yè)分享
Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技術(shù)文檔： www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
【免責聲明】本文僅代表作者本人觀點，與CTI論壇無關(guān)。CTI論壇對文中陳述、觀點判斷保持中立，不對所包含內(nèi)容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考，并請自行承擔全部責任。
相關(guān)閱讀：
- ·再論SIP呼叫中的Call、Dialog和Transaction2019-04-10 09:43:20
- ·淺析SIP響應(yīng)消息100 Trying的作用和傳輸機制2019-03-04 15:27:31
- ·為什么電信業(yè)采用開源時機成熟2019-02-13 10:30:04
- ·OPNFV：推動開源生態(tài)系統(tǒng)融合 加速NFV部署與落地2017-05-27 13:52:33
- ·不了解容器技術(shù)？30分鐘看懂 Docker& Kubernetes！2016-08-09 11:01:05
- ·上手OpenStack必看的10個問題2015-08-28 10:10:39
