• <strike id="fdgpu"><input id="fdgpu"></input></strike>
    <label id="fdgpu"></label>
    <s id="fdgpu"><code id="fdgpu"></code></s>

  • <label id="fdgpu"></label>
  • <span id="fdgpu"><u id="fdgpu"></u></span>

    <s id="fdgpu"><sub id="fdgpu"></sub></s>
    您當前的位置是:  首頁(yè) > 資訊 > 文章精選 >
     首頁(yè) > 資訊 > 文章精選 >

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

    2021-12-07 13:32:11   作者:   來(lái)源:   評論:0  點(diǎn)擊:


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

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

    專(zhuān)題

    CTI論壇會(huì )員企業(yè)

    亚洲精品网站在线观看不卡无广告,国产a不卡片精品免费观看,欧美亚洲一区二区三区在线,国产一区二区三区日韩 怀安县| 安西县| 南靖县| 中西区| 和林格尔县| 大港区| 灵丘县| 莎车县| 潞西市| 皋兰县| 长顺县| 云梦县| 齐齐哈尔市| 新丰县| 福州市| 贵德县| 兖州市| 波密县| 连江县| 永兴县| 东宁县| 新化县| 巫溪县| 五寨县| 松滋市| 萨嘎县| 兴隆县| 房山区| 德令哈市| 东丰县| 穆棱市| 伊春市| 大庆市| 罗城| 辽宁省| 盘锦市| 武定县| 石棉县| 麻江县| 尼玛县| 栖霞市| http://444 http://444 http://444 http://444 http://444 http://444