- 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
隨著SIP移動性的不斷擴展，網(wǎng)絡(luò)中各種網(wǎng)元形態(tài)可以通過不同的形式不同SIP代理服務(wù)器可以發(fā)起呼叫。一些用戶通過PSTN，SS7網(wǎng)絡(luò)進(jìn)行呼叫，另外一些用戶通過SIP物理話機進(jìn)行呼叫，還有一些用戶可能通過其他瀏覽器端的呼叫源發(fā)起呼叫。在這種復(fù)雜的網(wǎng)絡(luò)環(huán)境中，因為安全和業(yè)務(wù)的要求，需要對呼叫方以及轉(zhuǎn)發(fā)原因等做標(biāo)識說明，通過標(biāo)識說明可以獲悉其身份驗證和呼叫原因。在很多呼叫業(yè)務(wù)場景中，我們有時可能會看到一些接入設(shè)備，例如語音網(wǎng)關(guān)，特別是SBC需要配置Diversion和History-Info來實現(xiàn)呼叫轉(zhuǎn)移等功能支持。但是，這兩個擴展以及其相關(guān)協(xié)議都發(fā)生了變化，有時這兩個頭可能存在同時共存的可能，可能會影響新的SIP工作環(huán)境。一些規(guī)范已是歷史規(guī)范，例如RFC5806，新SIP系統(tǒng)可以不再支持，一些規(guī)范已經(jīng)廢止，使用了新規(guī)范來替代，例如RFC4244使用RFC7044替代。今天，筆者將介紹其相關(guān)規(guī)范的更新背景，Diversion和History-Info的使用，以及RFC5806和RFC7044的兼容性協(xié)議討論。通過這些介紹，結(jié)合最新規(guī)范，為讀者提供一個新的學(xué)習(xí)路徑，幫助讀者進(jìn)一步了解SIP頭中Diversion和History-Info的變化以及映射處理流程。
1RFC5806以及RFC4244更新背景說明
RFC3261為了擴展其呼叫標(biāo)識，支持了擴展協(xié)議RFC5806，通過此擴展協(xié)議定義了呼叫Diversion頭。另外，隨著SIP環(huán)境越來越復(fù)雜，一些場景中支持了非常靈活的業(yè)務(wù)場景，例如，基于瀏覽器的頁面點擊呼叫和業(yè)務(wù)應(yīng)用的綁定，點擊呼叫又涉及了URL地址。RFC4244對History-Info進(jìn)行了定義，支持了Request History請求歷史。但是，因為網(wǎng)絡(luò)環(huán)境已經(jīng)變得更加復(fù)雜，一些業(yè)務(wù)要求也發(fā)生了變化。經(jīng)過多年使用，RFC4244仍然存在很多的問題，例如，我們必須假設(shè)History-Info是需要的，但是在實際呼叫過程中，很多呼叫穿越了多臺設(shè)備和服務(wù)，每個設(shè)備和服務(wù)都可能設(shè)置了一些關(guān)聯(lián)機制和鼓勵規(guī)則，到最終目的地以后，終端可能僅第一個顯示第一個轉(zhuǎn)發(fā)和最后一個轉(zhuǎn)發(fā)記錄，中間各種代理服務(wù)器和設(shè)備的轉(zhuǎn)發(fā)數(shù)據(jù)就被丟棄。當(dāng)然，除了以上舉例以外，RFC4244還有其他的一些問題，具體詳情，讀者可以查閱RFC7044。根據(jù)以上介紹，我們開源看到，目前的結(jié)果是，RFC5806已成為RFC的歷史規(guī)范，不再是一個標(biāo)準(zhǔn)規(guī)范，另外，因為各種問題，RFC4244也已經(jīng)不再進(jìn)行支持。因此，一般新的SIP系統(tǒng)不會將RFC580作為一個規(guī)范。并且，比較重要的是，在IETF中，RFC7044將作為一個新的規(guī)范。
除了筆者以上討論以外，另外提醒讀者，History-Info也同時在3GPP的規(guī)范RFC4458中做了定義。在RFC4458中，它僅針對語音留言的處理做了規(guī)范，沒有涉及其他的業(yè)務(wù)場景。
2關(guān)于RFC5806-Diversion頭說明
RFC5806是SIP協(xié)議的一個擴展協(xié)議，它對被呼叫方提供了一種能力支持，可以獲悉呼叫源身份和呼叫轉(zhuǎn)發(fā)到原因。通過Diversion頭傳輸呼叫源信息和被轉(zhuǎn)發(fā)原因。它可以支持很多的增強服務(wù)，例如融合信息，第三方語音郵箱和自動呼叫分配等應(yīng)用場景中。另外。Diversion頭也被寬泛地運用在和傳統(tǒng)ISDN接入設(shè)備環(huán)境中，通過重轉(zhuǎn)ISDN/ISUP信令信息，這些信令信息可用來支持用戶需要的各種增強服務(wù)。網(wǎng)關(guān)的重要作用就是和SIP網(wǎng)絡(luò)進(jìn)行對接，所以，ISDN接入方使用Diversion也可以充分實現(xiàn)對SIP網(wǎng)絡(luò)的支持。在本文章中，筆者通過一個簡單的呼叫轉(zhuǎn)發(fā)功能來說明，SIP Diversion頭是如何工作的。關(guān)于接入設(shè)備的配置，包括SBC的支持，用戶可以具體廠家的產(chǎn)品配置來獲得其細(xì)節(jié)。
很多用戶對Diversion比較迷惑，其實，對被呼叫方或者接聽方來說，它的作用僅為了回答兩個問題：這個呼叫從哪里轉(zhuǎn)發(fā)過來？為什么轉(zhuǎn)發(fā)這個呼叫？以下是一個呼叫轉(zhuǎn)發(fā)的設(shè)置示例。在以下設(shè)置中，呼叫方（老王）呼叫了被呼叫方（james.zhu）以后，被呼叫方因為某種原因，暫時不能接聽呼叫，他設(shè)置了轉(zhuǎn)發(fā)設(shè)置。呼叫抵達(dá)被呼叫方以后，然后通過SIP代理轉(zhuǎn)發(fā)到了用戶Eric的終端。Eric接聽呼叫時，他知道這個呼叫是來自于誰的呼叫，和為什么他不能接聽呼叫。
SIP Diversion 呼叫轉(zhuǎn)發(fā)示例
在以上的流程中，代理服務(wù)器設(shè)置了呼叫（呼叫未應(yīng)答-CFNA）超時設(shè)置，如果被呼叫方振鈴超時，代理服務(wù)器對其發(fā)送取消，然后被呼叫方返回200 OK。代理服務(wù)器收到了被呼叫方的200 OK以后，根據(jù)其轉(zhuǎn)發(fā)呼叫設(shè)置的地址，對Eric再次進(jìn)行呼叫，并且攜帶了Diversion頭的信息，包括呼叫轉(zhuǎn)發(fā)源地址和轉(zhuǎn)發(fā)原因。Eric接聽呼叫，然后執(zhí)行雙方ACK確認(rèn)。除了以上呼叫未應(yīng)答的示例以外，Diversin也可以支持其他的幾種呼叫轉(zhuǎn)發(fā)原因設(shè)置，這些原因會通過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
以上原因都會通過Diversion傳輸?shù)阶罱K呼叫接聽方地址。所以，如果讀者在問題排查遇到問題時，可以按照以上轉(zhuǎn)發(fā)場景進(jìn)行排查。更多用戶創(chuàng)建中如何實現(xiàn)Diverison的工作流程，筆者建議讀者可以查閱RFC5806來了解具體詳解。不過，此規(guī)范已經(jīng)成為一個歷史規(guī)范，如果讀者想在最新SIP產(chǎn)品中支持類似Diversion的頭控制，讀者需要參考更新的規(guī)范RFC7044。
3關(guān)于RFC7044的History-Info 說明以及和Diversion兼容性問題
在一些應(yīng)用服務(wù)中，特別是SIP參與的服務(wù)中，它們要求SIP具備一種能力，SIP請求為什么，并且是如何抵達(dá)這個具體的應(yīng)用。我們在SIP終端可以經(jīng)�？吹降膽�(yīng)用，例如頁面點擊呼叫和一些終端所支持的呼叫歷史記錄，呼叫l(wèi)og或者語音郵箱等。雖然，目前很多的應(yīng)用可以非常簡單實現(xiàn)重定向這些服務(wù)，能夠?qū)唧w的應(yīng)用提供類似的服務(wù)，但是，這些具體的應(yīng)用缺乏一個完整的機制來實現(xiàn)規(guī)范化處理，保證SIP請求那個重定向到歷史記錄中。具體應(yīng)用也希望歷史請求可以通過規(guī)范機制路由到具體的應(yīng)用環(huán)境中。因此，在RFC7044規(guī)范中，通過請求歷史對機制有了明確的定義，History-Info捕獲請求歷史，它提供了一種機制來保證對各種具體應(yīng)用的支持。筆者仍然以呼叫未應(yīng)答作為一個示例來說明代理服務(wù)器如何傳輸History-Info頭以及各種參數(shù)的。
在以上的呼叫示例中，基本的流程和Diversion完全相似，其區(qū)別主要體現(xiàn)在History-Info頭和其參數(shù)不同。History-Info頭主要包括了hi-targeted-to-uri，hi-index和hi-target-param。其中，hi-target-param包括了rc，mp或者np等不同參數(shù)值。rc和mp指示了新目的地請求決定機制，np則表示目的地?zé)o修改。
通過以上示例，我們可以看出，很多情況下如果設(shè)備和服務(wù)器都涉及了多個呼叫節(jié)點的話，在呼叫轉(zhuǎn)發(fā)業(yè)務(wù)中有可能出現(xiàn)invite中攜帶Diversion頭，也有可能出現(xiàn)攜帶History-Info頭的呼叫。這兩個頭的參數(shù)出現(xiàn)在一個正常轉(zhuǎn)發(fā)呼叫業(yè)務(wù)中，兩種頭可能出現(xiàn)同時并存的狀態(tài)。當(dāng)然，在實際的呼叫會話中，一個會話信令不可能同時存在Diversion和History-Info的互相不兼容的問題，它們之間必須有一個兼容機制或者映射機制來保證呼叫轉(zhuǎn)發(fā)到正常進(jìn)行。從兼容性的角度來說，和Diversion相比，History-Info相對支持的服務(wù)更廣泛一點，因此，Diverison需要進(jìn)一步和History-Info兼容。RFC7544就是為了滿足其映射關(guān)系發(fā)布的一個RFC說明。在關(guān)于Diversion 頭和History-Info映射關(guān)系的RFC7544中，具體討論了關(guān)于Diversion頭映射到History-Info的示例說明，讀者可以根據(jù)其詳解做更深入了解。以下是Diversion Header Field 映射到History-Info Header Field主要參數(shù)列表對比，詳細(xì)說明參考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 |
| 。。。。 | 。。。。。 |
總結(jié)
SIP擴展支持是一個非常復(fù)雜和具體的過程，在技術(shù)發(fā)展過程中，SIP協(xié)議和具體場景之間一直存在多種形態(tài)的兼容性支持問題。Diversion和History-Info的支持，要求各種代理服務(wù)器和終端，接入設(shè)備都都需要完美兼容Diversion和History-Info來保證呼叫轉(zhuǎn)發(fā)的成功。
筆者針對Diversion和History-Info的相關(guān)協(xié)議進(jìn)行了充分討論，針對兩種頭分別通過示例進(jìn)行了具體的流程說明，解釋了幾個相關(guān)協(xié)議的歷史變更和其存在的問題，同時說明了History-Info所支持的最新規(guī)范RFC7044，以及關(guān)于RFC5806到RFC7044轉(zhuǎn)換的說明協(xié)議讀者開源根據(jù)其技術(shù)脈絡(luò)，如果在Diversion或History-Info頭處理發(fā)現(xiàn)有兼容性問題的話，此文章可以作為一個排查指導(dǎo)來對照學(xué)習(xí)。
參考資料：
- 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
