您當(dāng)前的位置是:  首頁 > 資訊 > 文章精選 >
 首頁 > 資訊 > 文章精選 >

再論SIP呼叫中的Call、Dialog和Transaction

2019-04-10 09:43:20   作者:james.zhu   來源:CTI論壇   評論:0  點(diǎn)擊:


  在我們的文章中和網(wǎng)絡(luò)上的資料中,我們會經(jīng)常使用SIP協(xié)議中一些專有的技術(shù)名稱。對于讀者來說,這些專有名詞基本概念可能非常了解。但是這些名詞在具體的示例中產(chǎn)生的綁定關(guān)系和其生成的流程是一個非常容易讓人費(fèi)解的內(nèi)容,例如呼叫中發(fā)生了幾個Dialog,發(fā)送了幾個Transactions,ACK是否算一個獨(dú)立的事務(wù)等。以下圖例說明了一個最簡單的示例包括了呼叫中Dialog,transaction數(shù)量和它們之間的關(guān)系。讀者了解這些流程和關(guān)系對其分析和排查技術(shù)問題有極大的幫助。
  以上示例僅是一個點(diǎn)對點(diǎn)的呼叫示例,當(dāng)然,在實(shí)際生產(chǎn)環(huán)境中,雙方呼叫不僅僅是一個點(diǎn)對點(diǎn)的呼叫。在實(shí)際生產(chǎn)環(huán)境中,大部分呼叫需要經(jīng)過一個代理服務(wù)器來處理。今天,我們結(jié)合幾個具體的示例重新和大家分享一下比較完整的呼叫流程,看看在呼叫過程中到底發(fā)生了多少個Dialog和Transactions。
  為了回答這些問題,我們需要首先介紹一下rfc3261的定義細(xì)節(jié),然后結(jié)合RFC3261規(guī)范給出幾個示例來解釋Dialog和Transactions發(fā)送的數(shù)量。
  因?yàn)橐郧暗奈恼轮写罅拷榻B了這些名稱的基本概念,我們不再花費(fèi)時間過多介紹其它完整的概念和相關(guān)背景知識。讀者可查閱我們的歷史文檔或者參考RFC3261來進(jìn)一步了解學(xué)習(xí)。
  1、Call/Session的定義
  通常大家所說的SIP call或者call其實(shí)在規(guī)范中沒有非常明確的官方定義,這是一個非常口語化通俗的的說法或表達(dá)方式。一般來說,call可以表示為session,一個SIP呼叫至少具有以下幾個方面的特點(diǎn):
  • 首先是一個session 會話
  • 其次,它必須包括所有的初始,管理和結(jié)束會話的所有消息
  • 通過Call-ID 頭來確認(rèn)其身份
  為了能夠讓讀者完整準(zhǔn)確理解我們接下來的討論,我們使用一個稍微復(fù)雜一點(diǎn)的forking呼叫的示例來說明call,dialog和transactions的關(guān)系以及呼叫過程中各自的數(shù)量。
  如果我們換一個示例,通過完整的消息流程看到話,表達(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)致一個或多個Dialog。Dialog的身份確認(rèn)通過To tag和From tag組合確認(rèn)。簡單來說,一個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:以一個請求開始,以零個或多個最終響應(yīng)結(jié)束,其中可能包含多個臨時響應(yīng),ACK除外。
  • 失敗呼叫的Transaction:包含失敗響應(yīng)消息,ACK包括在了INVITE事務(wù)中。
  • Transaction通過Via頭中的branch參數(shù)和CSeq method來確認(rèn)。
  • 僅留存在一個hop中,經(jīng)過代理處理的請求重新開始一個新的Transaction。
  4、關(guān)于Dialog數(shù)量討論
  根據(jù)前面討論中關(guān)于Dialog的定義,結(jié)合以下場景,我們知道,場景中產(chǎn)生了2個Dialog。第一個Dialog是A/B之間的Dialog,第二個Dialog是A/C之間的。這兩個Dialog通過To tag和From tag 分別綁定了兩個終端。因此,以下示例生成了2個Dialog。注意,為了容易讓讀者了解場景示例,這里的Dialog綁定關(guān)系的標(biāo)識是簡單化的標(biāo)識方式,不是規(guī)范的標(biāo)識。
  為了方便理解,很多環(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ǔ)的。另外,讀者需要注意一個問題,為什么ACK有時需要分開處理,并且獨(dú)立為一個新的事務(wù)? 在RFC3261的官方中說明了獨(dú)立的ACK的根本原因,這是因?yàn)锳CK涉及到了UAC和UAS直接重傳機(jī)制的處理。關(guān)于重傳機(jī)制的處理,讀者可以查閱RFC3261的13.3.1.4。
  下面,我們根據(jù)一個常用的分叉呼叫的流程,來分別說明成功呼叫和失敗呼叫各自所生成的transaction。以下示例并非按照順序生成,讀者不要誤解。
  根據(jù)RFC3261的規(guī)范對事務(wù)的定義,以上分叉呼叫發(fā)生了五個事務(wù)處理(Transactions):
  • 第一個Transaction發(fā)生在呼叫方A 對服務(wù)器的請求,是第一個Transaction。
  • 第二個Transaction發(fā)生于服務(wù)器對SIP B的INVITE流程中,因?yàn)殡娫払沒有接聽,返回了一個487(非2XX)響應(yīng),因此緊接著SIP服務(wù)器返回了一個ACK。因?yàn)槭且粋失敗的呼叫,所以,這個ACK是包含在INVITE中的,因此,這是第二個Transaction。
  • 第三個Transaction發(fā)生在電話C和服務(wù)器端之間。所以,電話C端和服務(wù)器端產(chǎn)生了第三個Transaction。另外,因?yàn)檫@是一個成功的呼叫,所以,其響應(yīng)的ACK是一個獨(dú)立的Transaction,因此A和C端之間產(chǎn)生了第四個Transaction。ACK在終端之間互相直接通信。
  第五個Transaction產(chǎn)生于SIP服務(wù)器和電話B之間的失敗呼叫中,Cancel是一個獨(dú)立的Transaction而存在(非INVITE),這是第五個Transaction。
  6、三者之間的關(guān)系
  我們在前面的章節(jié)中討論了call,dialog和transactions的三個SIP呼叫中非常重要的概念,并且對其不同的流程所產(chǎn)生的處理數(shù)量做了比較清晰的介紹。
  從其概念和實(shí)際場景中,我們可以看出其三者之間的關(guān)系。簡單來說,它們之間的關(guān)系是:
  • 一個Call可能存在至少一個或者多個Dialogs
  • 一個Dialog由一系列多個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)系和時間關(guān)系,筆者這里僅介紹了INVITE請求時事務(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,獲得有價值的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

【免責(zé)聲明】本文僅代表作者本人觀點(diǎn),與CTI論壇無關(guān)。CTI論壇對文中陳述、觀點(diǎn)判斷保持中立,不對所包含內(nèi)容的準(zhǔn)確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔(dān)全部責(zé)任。

專題

CTI論壇會員企業(yè)