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