- SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò )技術(shù)概論-核心SIP技術(shù)介紹-1
- SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò )技術(shù)概論-核心SIP技術(shù)介紹-2
- SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò )技術(shù)概論-核心SIP技術(shù)介紹-3
- SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò )技術(shù)概論-核心SIP技術(shù)介紹-4
- SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò )技術(shù)概論-核心SIP技術(shù)介紹-5
- SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò )技術(shù)概論-核心SIP技術(shù)介紹-6-SDP交互示例
- SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò )技術(shù)概論-核心SIP技術(shù)介紹-7
隨著(zhù)SIP移動(dòng)性的不斷擴展，網(wǎng)絡(luò )中各種網(wǎng)元形態(tài)可以通過(guò)不同的形式不同SIP代理服務(wù)器可以發(fā)起呼叫。一些用戶(hù)通過(guò)PSTN，SS7網(wǎng)絡(luò )進(jìn)行呼叫，另外一些用戶(hù)通過(guò)SIP物理話(huà)機進(jìn)行呼叫，還有一些用戶(hù)可能通過(guò)其他瀏覽器端的呼叫源發(fā)起呼叫。在這種復雜的網(wǎng)絡(luò )環(huán)境中，因為安全和業(yè)務(wù)的要求，需要對呼叫方以及轉發(fā)原因等做標識說(shuō)明，通過(guò)標識說(shuō)明可以獲悉其身份驗證和呼叫原因。在很多呼叫業(yè)務(wù)場(chǎng)景中，我們有時(shí)可能會(huì )看到一些接入設備，例如語(yǔ)音網(wǎng)關(guān)，特別是SBC需要配置Diversion和History-Info來(lái)實(shí)現呼叫轉移等功能支持。但是，這兩個(gè)擴展以及其相關(guān)協(xié)議都發(fā)生了變化，有時(shí)這兩個(gè)頭可能存在同時(shí)共存的可能，可能會(huì )影響新的SIP工作環(huán)境。一些規范已是歷史規范，例如RFC5806，新SIP系統可以不再支持，一些規范已經(jīng)廢止，使用了新規范來(lái)替代，例如RFC4244使用RFC7044替代。今天，筆者將介紹其相關(guān)規范的更新背景，Diversion和History-Info的使用，以及RFC5806和RFC7044的兼容性協(xié)議討論。通過(guò)這些介紹，結合最新規范，為讀者提供一個(gè)新的學(xué)習路徑，幫助讀者進(jìn)一步了解SIP頭中Diversion和History-Info的變化以及映射處理流程。
1RFC5806以及RFC4244更新背景說(shuō)明
RFC3261為了擴展其呼叫標識，支持了擴展協(xié)議RFC5806，通過(guò)此擴展協(xié)議定義了呼叫Diversion頭。另外，隨著(zhù)SIP環(huán)境越來(lái)越復雜，一些場(chǎng)景中支持了非常靈活的業(yè)務(wù)場(chǎng)景，例如，基于瀏覽器的頁(yè)面點(diǎn)擊呼叫和業(yè)務(wù)應用的綁定，點(diǎn)擊呼叫又涉及了URL地址。RFC4244對History-Info進(jìn)行了定義，支持了Request History請求歷史。但是，因為網(wǎng)絡(luò )環(huán)境已經(jīng)變得更加復雜，一些業(yè)務(wù)要求也發(fā)生了變化。經(jīng)過(guò)多年使用，RFC4244仍然存在很多的問(wèn)題，例如，我們必須假設History-Info是需要的，但是在實(shí)際呼叫過(guò)程中，很多呼叫穿越了多臺設備和服務(wù)，每個(gè)設備和服務(wù)都可能設置了一些關(guān)聯(lián)機制和鼓勵規則，到最終目的地以后，終端可能僅第一個(gè)顯示第一個(gè)轉發(fā)和最后一個(gè)轉發(fā)記錄，中間各種代理服務(wù)器和設備的轉發(fā)數據就被丟棄。當然，除了以上舉例以外，RFC4244還有其他的一些問(wèn)題，具體詳情，讀者可以查閱RFC7044。根據以上介紹，我們開(kāi)源看到，目前的結果是，RFC5806已成為RFC的歷史規范，不再是一個(gè)標準規范，另外，因為各種問(wèn)題，RFC4244也已經(jīng)不再進(jìn)行支持。因此，一般新的SIP系統不會(huì )將RFC580作為一個(gè)規范。并且，比較重要的是，在IETF中，RFC7044將作為一個(gè)新的規范。
除了筆者以上討論以外，另外提醒讀者，History-Info也同時(shí)在3GPP的規范RFC4458中做了定義。在RFC4458中，它僅針對語(yǔ)音留言的處理做了規范，沒(méi)有涉及其他的業(yè)務(wù)場(chǎng)景。
2關(guān)于RFC5806-Diversion頭說(shuō)明
RFC5806是SIP協(xié)議的一個(gè)擴展協(xié)議，它對被呼叫方提供了一種能力支持，可以獲悉呼叫源身份和呼叫轉發(fā)到原因。通過(guò)Diversion頭傳輸呼叫源信息和被轉發(fā)原因。它可以支持很多的增強服務(wù)，例如融合信息，第三方語(yǔ)音郵箱和自動(dòng)呼叫分配等應用場(chǎng)景中。另外。Diversion頭也被寬泛地運用在和傳統ISDN接入設備環(huán)境中，通過(guò)重轉ISDN/ISUP信令信息，這些信令信息可用來(lái)支持用戶(hù)需要的各種增強服務(wù)。網(wǎng)關(guān)的重要作用就是和SIP網(wǎng)絡(luò )進(jìn)行對接，所以，ISDN接入方使用Diversion也可以充分實(shí)現對SIP網(wǎng)絡(luò )的支持。在本文章中，筆者通過(guò)一個(gè)簡(jiǎn)單的呼叫轉發(fā)功能來(lái)說(shuō)明，SIP Diversion頭是如何工作的。關(guān)于接入設備的配置，包括SBC的支持，用戶(hù)可以具體廠(chǎng)家的產(chǎn)品配置來(lái)獲得其細節。
很多用戶(hù)對Diversion比較迷惑，其實(shí)，對被呼叫方或者接聽(tīng)方來(lái)說(shuō)，它的作用僅為了回答兩個(gè)問(wèn)題：這個(gè)呼叫從哪里轉發(fā)過(guò)來(lái)？為什么轉發(fā)這個(gè)呼叫？以下是一個(gè)呼叫轉發(fā)的設置示例。在以下設置中，呼叫方（老王）呼叫了被呼叫方（james.zhu）以后，被呼叫方因為某種原因，暫時(shí)不能接聽(tīng)呼叫，他設置了轉發(fā)設置。呼叫抵達被呼叫方以后，然后通過(guò)SIP代理轉發(fā)到了用戶(hù)Eric的終端。Eric接聽(tīng)呼叫時(shí)，他知道這個(gè)呼叫是來(lái)自于誰(shuí)的呼叫，和為什么他不能接聽(tīng)呼叫。
SIP Diversion 呼叫轉發(fā)示例
在以上的流程中，代理服務(wù)器設置了呼叫（呼叫未應答-CFNA）超時(shí)設置，如果被呼叫方振鈴超時(shí)，代理服務(wù)器對其發(fā)送取消，然后被呼叫方返回200 OK。代理服務(wù)器收到了被呼叫方的200 OK以后，根據其轉發(fā)呼叫設置的地址，對Eric再次進(jìn)行呼叫，并且攜帶了Diversion頭的信息，包括呼叫轉發(fā)源地址和轉發(fā)原因。Eric接聽(tīng)呼叫，然后執行雙方ACK確認。除了以上呼叫未應答的示例以外，Diversin也可以支持其他的幾種呼叫轉發(fā)原因設置，這些原因會(huì )通過(guò)Diversion進(jìn)行傳輸，具體包括：
- CFUNC: Call Forward Unconditional
- CFTOD: Call Forward Time-of-Day
- CFB: Call Forward on Busy
- CFNA: Call Forward on No Answer
- CFUNV: Call Forward Unavailable
- ACD: Automatic Call Distribution
以上原因都會(huì )通過(guò)Diversion傳輸到最終呼叫接聽(tīng)方地址。所以，如果讀者在問(wèn)題排查遇到問(wèn)題時(shí)，可以按照以上轉發(fā)場(chǎng)景進(jìn)行排查。更多用戶(hù)創(chuàng )建中如何實(shí)現Diverison的工作流程，筆者建議讀者可以查閱RFC5806來(lái)了解具體詳解。不過(guò)，此規范已經(jīng)成為一個(gè)歷史規范，如果讀者想在最新SIP產(chǎn)品中支持類(lèi)似Diversion的頭控制，讀者需要參考更新的規范RFC7044。
3關(guān)于RFC7044的History-Info 說(shuō)明以及和Diversion兼容性問(wèn)題
在一些應用服務(wù)中，特別是SIP參與的服務(wù)中，它們要求SIP具備一種能力，SIP請求為什么，并且是如何抵達這個(gè)具體的應用。我們在SIP終端可以經(jīng)常看到的應用，例如頁(yè)面點(diǎn)擊呼叫和一些終端所支持的呼叫歷史記錄，呼叫log或者語(yǔ)音郵箱等。雖然，目前很多的應用可以非常簡(jiǎn)單實(shí)現重定向這些服務(wù)，能夠對具體的應用提供類(lèi)似的服務(wù)，但是，這些具體的應用缺乏一個(gè)完整的機制來(lái)實(shí)現規范化處理，保證SIP請求那個(gè)重定向到歷史記錄中。具體應用也希望歷史請求可以通過(guò)規范機制路由到具體的應用環(huán)境中。因此，在RFC7044規范中，通過(guò)請求歷史對機制有了明確的定義，History-Info捕獲請求歷史，它提供了一種機制來(lái)保證對各種具體應用的支持。筆者仍然以呼叫未應答作為一個(gè)示例來(lái)說(shuō)明代理服務(wù)器如何傳輸History-Info頭以及各種參數的。
在以上的呼叫示例中，基本的流程和Diversion完全相似，其區別主要體現在History-Info頭和其參數不同。History-Info頭主要包括了hi-targeted-to-uri，hi-index和hi-target-param。其中，hi-target-param包括了rc，mp或者np等不同參數值。rc和mp指示了新目的地請求決定機制，np則表示目的地無(wú)修改。
通過(guò)以上示例，我們可以看出，很多情況下如果設備和服務(wù)器都涉及了多個(gè)呼叫節點(diǎn)的話(huà)，在呼叫轉發(fā)業(yè)務(wù)中有可能出現invite中攜帶Diversion頭，也有可能出現攜帶History-Info頭的呼叫。這兩個(gè)頭的參數出現在一個(gè)正常轉發(fā)呼叫業(yè)務(wù)中，兩種頭可能出現同時(shí)并存的狀態(tài)。當然，在實(shí)際的呼叫會(huì )話(huà)中，一個(gè)會(huì )話(huà)信令不可能同時(shí)存在Diversion和History-Info的互相不兼容的問(wèn)題，它們之間必須有一個(gè)兼容機制或者映射機制來(lái)保證呼叫轉發(fā)到正常進(jìn)行。從兼容性的角度來(lái)說(shuō)，和Diversion相比，History-Info相對支持的服務(wù)更廣泛一點(diǎn)，因此，Diverison需要進(jìn)一步和History-Info兼容。RFC7544就是為了滿(mǎn)足其映射關(guān)系發(fā)布的一個(gè)RFC說(shuō)明。在關(guān)于Diversion 頭和History-Info映射關(guān)系的RFC7544中，具體討論了關(guān)于Diversion頭映射到History-Info的示例說(shuō)明，讀者可以根據其詳解做更深入了解。以下是Diversion Header Field 映射到History-Info Header Field主要參數列表對比，詳細說(shuō)明參考RFC7544-5。
<table style="margin: 0px 0px 10px; padding: 0px; outline: 0px; border-collapse: collapse; width: 677px; max-width: 100%; color: rgb(51, 51, 51); font-family: -apple-system, BlinkMacSystemFont, " helvetica="" neue",="" "pingfang="" sc",="" "hiragino="" sans="" gb",="" "microsoft="" yahei="" ui",="" yahei",="" arial,="" sans-serif;="" font-size:="" 16px;="" letter-spacing:="" 0.544px;="" text-align:="" justify;="" overflow-wrap:="" break-word="" !important;"="">
Source
Destination
Diversion header component
History-Info header component
name-addr
hi-targeted-to-uri
reason of the previous
Diversion entry
cause URI parameter
"unknown"
404 (default 'cause' value)
"unconditional"
"user-busy"
"no-answer"
"deflection "
480 or 487
"unavailable" |
503 |
"follow-me" |
404 |
"out-of-service" |
404 |
| 。。。。 | 。。。。。 |
總結
SIP擴展支持是一個(gè)非常復雜和具體的過(guò)程，在技術(shù)發(fā)展過(guò)程中，SIP協(xié)議和具體場(chǎng)景之間一直存在多種形態(tài)的兼容性支持問(wèn)題。Diversion和History-Info的支持，要求各種代理服務(wù)器和終端，接入設備都都需要完美兼容Diversion和History-Info來(lái)保證呼叫轉發(fā)的成功。
筆者針對Diversion和History-Info的相關(guān)協(xié)議進(jìn)行了充分討論，針對兩種頭分別通過(guò)示例進(jìn)行了具體的流程說(shuō)明，解釋了幾個(gè)相關(guān)協(xié)議的歷史變更和其存在的問(wèn)題，同時(shí)說(shuō)明了History-Info所支持的最新規范RFC7044，以及關(guān)于RFC5806到RFC7044轉換的說(shuō)明協(xié)議讀者開(kāi)源根據其技術(shù)脈絡(luò )，如果在Diversion或History-Info頭處理發(fā)現有兼容性問(wèn)題的話(huà)，此文章可以作為一個(gè)排查指導來(lái)對照學(xué)習。
參考資料：
- https://datatracker.ietf.org/doc/html/rfc7044
- https://datatracker.ietf.org/doc/html/rfc4244
- www.dinstar.cn
- www.asterisk.org.cn
- https://datatracker.ietf.org/doc/html/rfc5806
- https://datatracker.ietf.org/doc/html/rfc4458
- https://datatracker.ietf.org/doc/html/rfc7544
- http://pike.lysator.liu.se/docs/ietf/rfc/75/rfc7544.xml
