以上示例僅是一個點對點的呼叫示例，當然，在實際生產(chǎn)環(huán)境中，雙方呼叫不僅僅是一個點對點的呼叫。在實際生產(chǎn)環(huán)境中，大部分呼叫需要經(jīng)過一個代理服務器來處理。今天，我們結合幾個具體的示例重新和大家分享一下比較完整的呼叫流程，看看在呼叫過程中到底發(fā)生了多少個Dialog和Transactions。
為了回答這些問題，我們需要首先介紹一下rfc3261的定義細節(jié)，然后結合RFC3261規(guī)范給出幾個示例來解釋Dialog和Transactions發(fā)送的數(shù)量。
因為以前的文章中大量介紹了這些名稱的基本概念，我們不再花費時間過多介紹其它完整的概念和相關背景知識。讀者可查閱我們的歷史文檔或者參考RFC3261來進一步了解學習。
1、Call/Session的定義
通常大家所說的SIP call或者call其實在規(guī)范中沒有非常明確的官方定義，這是一個非常口語化通俗的的說法或表達方式。一般來說，call可以表示為session，一個SIP呼叫至少具有以下幾個方面的特點：
- 首先是一個session 會話
- 其次，它必須包括所有的初始，管理和結束會話的所有消息
- 通過Call-ID 頭來確認其身份
為了能夠讓讀者完整準確理解我們接下來的討論，我們使用一個稍微復雜一點的forking呼叫的示例來說明call，dialog和transactions的關系以及呼叫過程中各自的數(shù)量。
如果我們換一個示例，通過完整的消息流程看到話，表達方式應該是這樣的：
2、Dialog的定義
關于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本質上說是一種對對點關系的確認。呼叫方UA發(fā)起呼叫后，可能導致一個或多個Dialog。Dialog的身份確認通過To tag和From tag組合確認。簡單來說，一個Dialog是有本地呼叫方和遠端被呼叫方構成。
3、Transaction的定義
關于Transaction的定義我們在前面的文章中有過全面地介紹，另外讀者也可以查閱RFC3216來學習。這里，我們重點說明成功呼叫和失敗呼叫的Transactions導致的不同處理流程。不同呼叫結果導致不同的事務處理結果，因此，兩種Transaction具有以下特點：
成功呼叫的transaction：以一個請求開始，以零個或多個最終響應結束，其中可能包含多個臨時響應，ACK除外。
- 失敗呼叫的Transaction：包含失敗響應消息，ACK包括在了INVITE事務中。
- Transaction通過Via頭中的branch參數(shù)和CSeq method來確認。
- 僅留存在一個hop中，經(jīng)過代理處理的請求重新開始一個新的Transaction。
4、關于Dialog數(shù)量討論
根據(jù)前面討論中關于Dialog的定義，結合以下場景，我們知道，場景中產(chǎn)生了2個Dialog。第一個Dialog是A/B之間的Dialog，第二個Dialog是A/C之間的。這兩個Dialog通過To tag和From tag 分別綁定了兩個終端。因此，以下示例生成了2個Dialog。注意，為了容易讓讀者了解場景示例，這里的Dialog綁定關系的標識是簡單化的標識方式，不是規(guī)范的標識。
為了方便理解，很多環(huán)境中，我們也把Dialog稱之為call-leg。所以，讀者不要對其概念產(chǎn)生誤解。
5、關于Transactions 事務的數(shù)量討論
顯然，以上討論中call和Dialog的數(shù)量確認是相對比較簡單的，比較復雜的是確認事務的數(shù)量。首先說明一下，事務生成的數(shù)量取決于多方面的條件和呼叫場景（例如INVITE和非-INVITE事務，客戶端和服務器端事務，失敗呼叫和成功呼叫的事務，點對點呼叫還是經(jīng)過proxy代理的呼叫），我們不能完全解釋所有的應用環(huán)境，因此，筆者現(xiàn)在僅針對相對容易實現(xiàn)，經(jīng)常使用的場景做示例說明。在介紹場景之前，讓我們重新回顧一下關于事務的定義：
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è)務和INVITE相關，因此，我們重點討論關于和INVITE相關的事務處理。在RFC3261中，專門針對INVITE請求和Transaction的關系補充了特別說明：
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ù)以上說明，讀者一定要注意，計算事務生成數(shù)量是根據(jù)響應消息是 2XX響應還是非2XX響應為基礎的。另外，讀者需要注意一個問題，為什么ACK有時需要分開處理，并且獨立為一個新的事務？ 在RFC3261的官方中說明了獨立的ACK的根本原因，這是因為ACK涉及到了UAC和UAS直接重傳機制的處理。關于重傳機制的處理，讀者可以查閱RFC3261的13.3.1.4。
下面，我們根據(jù)一個常用的分叉呼叫的流程，來分別說明成功呼叫和失敗呼叫各自所生成的transaction。以下示例并非按照順序生成，讀者不要誤解。
根據(jù)RFC3261的規(guī)范對事務的定義，以上分叉呼叫發(fā)生了五個事務處理（Transactions）：
- 第一個Transaction發(fā)生在呼叫方A 對服務器的請求，是第一個Transaction。
- 第二個Transaction發(fā)生于服務器對SIP B的INVITE流程中，因為電話B沒有接聽，返回了一個487（非2XX）響應，因此緊接著SIP服務器返回了一個ACK。因為是一個失敗的呼叫，所以，這個ACK是包含在INVITE中的，因此，這是第二個Transaction。
- 第三個Transaction發(fā)生在電話C和服務器端之間。所以，電話C端和服務器端產(chǎn)生了第三個Transaction。另外，因為這是一個成功的呼叫，所以，其響應的ACK是一個獨立的Transaction，因此A和C端之間產(chǎn)生了第四個Transaction。ACK在終端之間互相直接通信。
第五個Transaction產(chǎn)生于SIP服務器和電話B之間的失敗呼叫中，Cancel是一個獨立的Transaction而存在（非INVITE），這是第五個Transaction。
6、三者之間的關系
我們在前面的章節(jié)中討論了call，dialog和transactions的三個SIP呼叫中非常重要的概念，并且對其不同的流程所產(chǎn)生的處理數(shù)量做了比較清晰的介紹。
從其概念和實際場景中，我們可以看出其三者之間的關系。簡單來說，它們之間的關系是：
- 一個Call可能存在至少一個或者多個Dialogs
- 一個Dialog由一系列多個Transactions事務構成
- Transaction事務各自都是互相獨立的
7、總結
在本章節(jié)中，筆者重點介紹了SIP 環(huán)境中call，Dialog和Transaction的基本概念和其三者之間的關系，并且針對典型的SIP INVITE 呼叫環(huán)境下它們各自所生成的數(shù)量進行了討論分析。另外，筆者特別針對比較復雜的事務處理的數(shù)量做了非常詳細地說明和介紹，并且根據(jù)RFC3261對其的定義，對其非2XX響應和2XX響應所產(chǎn)生的事務和獨立生成ACK的原因做了解釋。
筆者希望通過本章節(jié)對事務處理的介紹，幫助讀者能夠完整了解事務生成的數(shù)量和其原因，提高SIP排查技術水平。
補充說明，因為篇幅的關系和時間關系，筆者這里僅介紹了INVITE請求時事務的處理，更多關于其他非INVITE或者其他的事務處理的環(huán)境讀者需要根據(jù)具體的環(huán)境來進行進一步學習。
參考資料：
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
關注微信公眾號：asterisk-cn，獲得有價值的Asterisk行業(yè)分享
Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技術文檔： www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
Asterisk/FreePBX中國合作伙伴，官方qq技術分享群（3000千人）：589995817
Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技術文檔： www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
Asterisk/FreePBX中國合作伙伴，官方qq技術分享群（3000千人）：589995817
