以上示例僅是一個(gè)點(diǎn)對點(diǎn)的呼叫示例，當(dāng)然，在實(shí)際生產(chǎn)環(huán)境中，雙方呼叫不僅僅是一個(gè)點(diǎn)對點(diǎn)的呼叫。在實(shí)際生產(chǎn)環(huán)境中，大部分呼叫需要經(jīng)過一個(gè)代理服務(wù)器來處理。今天，我們結(jié)合幾個(gè)具體的示例重新和大家分享一下比較完整的呼叫流程，看看在呼叫過程中到底發(fā)生了多少個(gè)Dialog和Transactions。
為了回答這些問題，我們需要首先介紹一下rfc3261的定義細(xì)節(jié)，然后結(jié)合RFC3261規(guī)范給出幾個(gè)示例來解釋Dialog和Transactions發(fā)送的數(shù)量。
因?yàn)橐郧暗奈恼轮写罅拷榻B了這些名稱的基本概念，我們不再花費(fèi)時(shí)間過多介紹其它完整的概念和相關(guān)背景知識(shí)。讀者可查閱我們的歷史文檔或者參考RFC3261來進(jìn)一步了解學(xué)習(xí)。
1、Call/Session的定義
通常大家所說的SIP call或者call其實(shí)在規(guī)范中沒有非常明確的官方定義，這是一個(gè)非常口語化通俗的的說法或表達(dá)方式。一般來說，call可以表示為session，一個(gè)SIP呼叫至少具有以下幾個(gè)方面的特點(diǎn)：
- 首先是一個(gè)session 會(huì)話
- 其次，它必須包括所有的初始，管理和結(jié)束會(huì)話的所有消息
- 通過Call-ID 頭來確認(rèn)其身份
為了能夠讓讀者完整準(zhǔn)確理解我們接下來的討論，我們使用一個(gè)稍微復(fù)雜一點(diǎn)的forking呼叫的示例來說明call，dialog和transactions的關(guān)系以及呼叫過程中各自的數(shù)量。
如果我們換一個(gè)示例，通過完整的消息流程看到話，表達(dá)方式應(yīng)該是這樣的：
2、Dialog的定義
關(guān)于Dialog的定義，RFC3261是這樣定義Dialog的：
A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them.
https://tools.ietf.org/html/rfc3261#section-12
從定義來看，Dialog本質(zhì)上說是一種對對點(diǎn)關(guān)系的確認(rèn)。呼叫方UA發(fā)起呼叫后，可能導(dǎo)致一個(gè)或多個(gè)Dialog。Dialog的身份確認(rèn)通過To tag和From tag組合確認(rèn)。簡單來說，一個(gè)Dialog是有本地呼叫方和遠(yuǎn)端被呼叫方構(gòu)成。
3、Transaction的定義
關(guān)于Transaction的定義我們在前面的文章中有過全面地介紹，另外讀者也可以查閱RFC3216來學(xué)習(xí)。這里，我們重點(diǎn)說明成功呼叫和失敗呼叫的Transactions導(dǎo)致的不同處理流程。不同呼叫結(jié)果導(dǎo)致不同的事務(wù)處理結(jié)果，因此，兩種Transaction具有以下特點(diǎn)：
成功呼叫的transaction：以一個(gè)請求開始，以零個(gè)或多個(gè)最終響應(yīng)結(jié)束，其中可能包含多個(gè)臨時(shí)響應(yīng)，ACK除外。
- 失敗呼叫的Transaction：包含失敗響應(yīng)消息，ACK包括在了INVITE事務(wù)中。
- Transaction通過Via頭中的branch參數(shù)和CSeq method來確認(rèn)。
- 僅留存在一個(gè)hop中，經(jīng)過代理處理的請求重新開始一個(gè)新的Transaction。
4、關(guān)于Dialog數(shù)量討論
根據(jù)前面討論中關(guān)于Dialog的定義，結(jié)合以下場景，我們知道，場景中產(chǎn)生了2個(gè)Dialog。第一個(gè)Dialog是A/B之間的Dialog，第二個(gè)Dialog是A/C之間的。這兩個(gè)Dialog通過To tag和From tag 分別綁定了兩個(gè)終端。因此，以下示例生成了2個(gè)Dialog。注意，為了容易讓讀者了解場景示例，這里的Dialog綁定關(guān)系的標(biāo)識(shí)是簡單化的標(biāo)識(shí)方式，不是規(guī)范的標(biāo)識(shí)。
為了方便理解，很多環(huán)境中，我們也把Dialog稱之為call-leg。所以，讀者不要對其概念產(chǎn)生誤解。
5、關(guān)于Transactions 事務(wù)的數(shù)量討論
顯然，以上討論中call和Dialog的數(shù)量確認(rèn)是相對比較簡單的，比較復(fù)雜的是確認(rèn)事務(wù)的數(shù)量。首先說明一下，事務(wù)生成的數(shù)量取決于多方面的條件和呼叫場景（例如INVITE和非-INVITE事務(wù)，客戶端和服務(wù)器端事務(wù)，失敗呼叫和成功呼叫的事務(wù)，點(diǎn)對點(diǎn)呼叫還是經(jīng)過proxy代理的呼叫），我們不能完全解釋所有的應(yīng)用環(huán)境，因此，筆者現(xiàn)在僅針對相對容易實(shí)現(xiàn)，經(jīng)常使用的場景做示例說明。在介紹場景之前，讓我們重新回顧一下關(guān)于事務(wù)的定義：
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.
https://tools.ietf.org/html/rfc3261#section-17
因?yàn)槲覀兇蟛糠值臉I(yè)務(wù)和INVITE相關(guān)，因此，我們重點(diǎn)討論關(guān)于和INVITE相關(guān)的事務(wù)處理。在RFC3261中，專門針對INVITE請求和Transaction的關(guān)系補(bǔ)充了特別說明：
In the case of a transaction where the request was an INVITE （known as an INVITE transaction）, the transaction also includes the ACK only if the final response was not a 2xx response. If the response was a 2xx, the ACK is not considered part of the transaction.
https://tools.ietf.org/html/rfc3261#section-17
所以，根據(jù)以上說明，讀者一定要注意，計(jì)算事務(wù)生成數(shù)量是根據(jù)響應(yīng)消息是 2XX響應(yīng)還是非2XX響應(yīng)為基礎(chǔ)的。另外，讀者需要注意一個(gè)問題，為什么ACK有時(shí)需要分開處理，并且獨(dú)立為一個(gè)新的事務(wù)？ 在RFC3261的官方中說明了獨(dú)立的ACK的根本原因，這是因?yàn)锳CK涉及到了UAC和UAS直接重傳機(jī)制的處理。關(guān)于重傳機(jī)制的處理，讀者可以查閱RFC3261的13.3.1.4。
下面，我們根據(jù)一個(gè)常用的分叉呼叫的流程，來分別說明成功呼叫和失敗呼叫各自所生成的transaction。以下示例并非按照順序生成，讀者不要誤解。
根據(jù)RFC3261的規(guī)范對事務(wù)的定義，以上分叉呼叫發(fā)生了五個(gè)事務(wù)處理（Transactions）：
- 第一個(gè)Transaction發(fā)生在呼叫方A 對服務(wù)器的請求，是第一個(gè)Transaction。
- 第二個(gè)Transaction發(fā)生于服務(wù)器對SIP B的INVITE流程中，因?yàn)殡娫払沒有接聽，返回了一個(gè)487（非2XX）響應(yīng)，因此緊接著SIP服務(wù)器返回了一個(gè)ACK。因?yàn)槭且粋�(gè)失敗的呼叫，所以，這個(gè)ACK是包含在INVITE中的，因此，這是第二個(gè)Transaction。
- 第三個(gè)Transaction發(fā)生在電話C和服務(wù)器端之間。所以，電話C端和服務(wù)器端產(chǎn)生了第三個(gè)Transaction。另外，因?yàn)檫@是一個(gè)成功的呼叫，所以，其響應(yīng)的ACK是一個(gè)獨(dú)立的Transaction，因此A和C端之間產(chǎn)生了第四個(gè)Transaction。ACK在終端之間互相直接通信。
第五個(gè)Transaction產(chǎn)生于SIP服務(wù)器和電話B之間的失敗呼叫中，Cancel是一個(gè)獨(dú)立的Transaction而存在（非INVITE），這是第五個(gè)Transaction。
6、三者之間的關(guān)系
我們在前面的章節(jié)中討論了call，dialog和transactions的三個(gè)SIP呼叫中非常重要的概念，并且對其不同的流程所產(chǎn)生的處理數(shù)量做了比較清晰的介紹。
從其概念和實(shí)際場景中，我們可以看出其三者之間的關(guān)系。簡單來說，它們之間的關(guān)系是：
- 一個(gè)Call可能存在至少一個(gè)或者多個(gè)Dialogs
- 一個(gè)Dialog由一系列多個(gè)Transactions事務(wù)構(gòu)成
- Transaction事務(wù)各自都是互相獨(dú)立的
7、總結(jié)
在本章節(jié)中，筆者重點(diǎn)介紹了SIP 環(huán)境中call，Dialog和Transaction的基本概念和其三者之間的關(guān)系，并且針對典型的SIP INVITE 呼叫環(huán)境下它們各自所生成的數(shù)量進(jìn)行了討論分析。另外，筆者特別針對比較復(fù)雜的事務(wù)處理的數(shù)量做了非常詳細(xì)地說明和介紹，并且根據(jù)RFC3261對其的定義，對其非2XX響應(yīng)和2XX響應(yīng)所產(chǎn)生的事務(wù)和獨(dú)立生成ACK的原因做了解釋。
筆者希望通過本章節(jié)對事務(wù)處理的介紹，幫助讀者能夠完整了解事務(wù)生成的數(shù)量和其原因，提高SIP排查技術(shù)水平。
補(bǔ)充說明，因?yàn)槠年P(guān)系和時(shí)間關(guān)系，筆者這里僅介紹了INVITE請求時(shí)事務(wù)的處理，更多關(guān)于其他非INVITE或者其他的事務(wù)處理的環(huán)境讀者需要根據(jù)具體的環(huán)境來進(jìn)行進(jìn)一步學(xué)習(xí)。
參考資料：
http://www.siptutorial.net/SIP/relation.html
http://www.kamailio.org/docs/tutorials/sip-introduction/#sip_transactions
https://subscription.packtpub.com/book/networking_and_servers/9781849510745/1/ch01lvl1sec13/sip-transactions-and-dialogs
https://arstechnica.com/tech-policy/2010/03/voip-in-depth-an-introduction-to-the-sip-protocol-part-2/
https://www.tech-invite.com/fo-sip/tinv-fo-sip-dialog-05.html
Jae Cheon Han，A study on ACK message processing mechanism in SIP transaction layer
關(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
Asterisk/FreePBX中國合作伙伴，官方qq技術(shù)分享群（3000千人）：589995817
Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技術(shù)文檔： www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
Asterisk/FreePBX中國合作伙伴，官方qq技術(shù)分享群（3000千人）：589995817
