RCD富呼叫數(shù)據(jù)/部署SHAKEN的技術(shù)挑戰(zhàn)以及CHAKEN-國內(nèi)主叫用戶可信身份鑒別技術(shù)規(guī)范

　　語音呼叫仍然是目前運營商和企業(yè)業(yè)務(wù)必不可少的營銷手段。從獲利角度講，其業(yè)務(wù)收益雖然在運營商的收入占比中呈下降趨勢，但是收入仍然比較可觀。因此，無論是運營商還是企業(yè)客戶都一直對其業(yè)務(wù)中的灰色地帶-騷擾電話/語音營銷，或者批量呼叫業(yè)務(wù)沒有完全放棄。隨著STIR/SHAKEN的呼叫身份驗證技術(shù)的不斷推進，和FCC的強制要求，其業(yè)務(wù)量也開始迅速萎縮。運營商的營收也面臨巨大壓力。如何對語音業(yè)務(wù)進行升級或者突破，是運營商面臨的一個非常大的挑戰(zhàn)。最近，一些比較大的國外的運營商正在嘗試在呼叫身份驗證基礎(chǔ)上開發(fā)的新業(yè)務(wù)模式-rich call data或者中文翻譯為富呼叫數(shù)據(jù)。簡單來說，企業(yè)用戶呼出時，通過身份驗證的呼叫會攜帶呼叫方號碼，呼叫方地址和公司logo等信息，被呼叫方手機終端會顯示企業(yè)完整的呼叫身份。通過富呼叫數(shù)據(jù)提供的增值服務(wù)，運營商和企業(yè)客戶獲得了雙贏的局面，也避免了傳統(tǒng)運營商語音業(yè)務(wù)的萎縮的態(tài)勢。Rich call data的技術(shù)實現(xiàn)流程相對比較復(fù)雜，其處理流程涵蓋了多個技術(shù)節(jié)點和第三方的數(shù)據(jù)管理等問題。為了讓讀者全面了解需要的技術(shù)支撐，現(xiàn)在，筆者具體介紹關(guān)于rich call data或者富呼叫數(shù)據(jù)的實現(xiàn)流程，rfc7095，PASSporT以及在運營商SBC等處理的相關(guān)技術(shù)。另外，筆者增加了更多關(guān)于呼叫身份確認(rèn)技術(shù)STIR/SHAKEN的實現(xiàn)所面臨的各種技術(shù)和商業(yè)方面的挑戰(zhàn)，包括如何實現(xiàn)SIP呼叫轉(zhuǎn)移到傳統(tǒng)PSTN的支持，如何通過SBC實現(xiàn)身份驗證，以及呼叫身份過濾以后的對用戶的更新過濾和sip div 頭中使用轉(zhuǎn)移標(biāo)識和PASSporT 令牌以及綁定的呼叫號碼的細(xì)節(jié)，最后，筆者還補充了馬上在國內(nèi)要執(zhí)行的關(guān)于信息安全技術(shù) 基于密碼令牌的主叫用戶可信身份鑒別技術(shù)規(guī)范意見稿。還有，此章節(jié)內(nèi)容也是筆者系列文章-SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò)技術(shù)概論中針對運營商方面的一個最新的補充內(nèi)容，此文章作為概論的結(jié)尾章節(jié)。

　　關(guān)于SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò)技術(shù)概論其他章節(jié)內(nèi)容，筆者可以參考最新歷史文檔和最早的文檔，例如：

　　SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò)技術(shù)概論-SIP網(wǎng)絡(luò)中完整NAT問題和處理方式和SBC在IMS網(wǎng)絡(luò)虛擬化NFV中部署討論分享

　　SIP協(xié)議及新IP企業(yè)通信網(wǎng)絡(luò)技術(shù)概論-核心SIP技術(shù)介紹-1

　　因為此文章章節(jié)比較多，多個章節(jié)還有一定的關(guān)聯(lián)關(guān)系，筆者專門單獨列出每個重點章節(jié)結(jié)合圖例做針對性地深入討論。本文章主要討論的內(nèi)容如下：

　　1.關(guān)于RCD-rich call data背景介紹

　　2.關(guān)于rich call data相關(guān)基本介紹

　　3.關(guān)于RCD實現(xiàn)方式的討論

　　4.關(guān)于實現(xiàn)STIR/SHAKEN所面臨的各種挑戰(zhàn)

　　5.關(guān)于STIR/SHAKEN技術(shù)針對呼叫轉(zhuǎn)移和非IP網(wǎng)絡(luò)的技術(shù)挑戰(zhàn)

　　6.關(guān)于SIP invite中的div和div-o頭處理細(xì)節(jié)

　　7.關(guān)于呼叫身份的后處理問題討論

　　8.利用呼叫分析引擎技術(shù)來過濾騷擾電話

　　9.構(gòu)建騷擾電話協(xié)同處理機制來解決呼叫身份驗證問題

　　10.國內(nèi)關(guān)于呼叫身份驗證的推動進程

　　在我們?nèi)粘Ｉ�活中，我們�?jīng)常會陌生人打來的電話。一些是客戶的咨詢電話，一些可能是其他教育機構(gòu)，金融中介等的電話。這些電話一部分是真正的用戶或者其他客戶的電話，有一部分是騷擾電話或者騙子打來的電話。陌生人的電話到底是接還是不接？ 如果漏接了客戶的電話，擔(dān)心自己錯過一個億的生意。接的話，這些電話有可能是營銷電話或者騙子的電話，浪費時間。

　　此圖例以及以下部分討論來自于互聯(lián)網(wǎng)資源

　　騷擾電話作為世界性難題，其他國家也面臨這些問題。人們已經(jīng)不再接聽未知的呼叫。一些呼叫中心或者金融機構(gòu)的客服系統(tǒng)產(chǎn)生了大量的垃圾呼叫，接通率逐年下降，呼叫中心效率大大折扣。根據(jù)福布斯引用Hiya 2020年呼叫報告，大約94%的未確認(rèn)身份的呼叫最后成為未接聽的呼叫。另外，F(xiàn)irst Orion的數(shù)據(jù)表明，90%的比較可靠的呼叫是帶標(biāo)識的呼叫。另外，根據(jù)businesswire的報道，美國幾大運營商-Verizon， T-Mobile， CTIA and iconectiv在SIPNOC 2022的大會上，針對任何提高Call Answer Rates，恢復(fù)消費者信心對部署RCD也做了分享研究。大概73%的行業(yè)領(lǐng)導(dǎo)者公司正在評估和考慮使用集中式的數(shù)據(jù)服務(wù)整合STIR/SHAKEN和RCD來降低用戶的損失，增加對機器人騷擾電話的過濾作用。目前，美國的一些運營商已經(jīng)開始強制要求支持STIR/SHAKEN技術(shù)，并且運營商也正在積極推動RCD的技術(shù)應(yīng)用，通過呼叫身份識別來進一步加強用戶接聽電話的安全體驗。關(guān)于STRI/SHAKEN 騷擾電話的技術(shù)實現(xiàn)方式，筆者在歷史文檔中

　　解決騷擾電話問題，道路是曲折的，前途是光明的-關(guān)于電話呼叫方身份驗證規(guī)范和STIR/SHAKEN騷擾加密技術(shù)的再討論 都做了非常詳細(xì)的分享說明。

　　對于RCD內(nèi)容，我們需要進一步補充。讓我們大概了解RCD其概念原理。RCD是目前比較好的辦法，通過RCD就會更加方便地讓被呼叫方能夠識別呼叫方的公司標(biāo)識，呼叫原因等相關(guān)的數(shù)據(jù)，這樣的話，被呼叫方也能夠明確所接聽的目的， 被呼叫方可以根據(jù)其驗證的信息決定是否接聽。

　　用戶渴望能夠顯示更多呼叫方豐富信息的支持。RCD（rich call data）就顯得比較重要了，它也是當(dāng)前呼叫業(yè)務(wù)的一個的必然選擇。我們以前傳統(tǒng)的號碼顯示是通過運營商的CNAM或者其他增值服務(wù)來實現(xiàn)，為呼叫方推送和號碼相關(guān)的一些數(shù)據(jù)，但是，其數(shù)據(jù)往往缺乏實時性和準(zhǔn)確性。因為騷擾電話的不斷增加，被呼叫方的訴求是當(dāng)呼叫接聽時，被呼叫方手機端應(yīng)該顯示準(zhǔn)確的呼叫方信息，包括公司信息，呼叫原因等。因此，和以前的CNAM號碼服務(wù)方式比較，對被呼叫方來說，顯然，rich call data增加了很多的實用性。其基本概念也非常簡單，rich call data 利用了SHAKEN的呼叫技術(shù)，通過呼叫驗證，然后對此呼叫添加了部分呼叫號碼的屬性參數(shù)，最后為被呼叫方提供顯示呼叫方富數(shù)據(jù)屬性數(shù)據(jù)。最終，被呼叫方手機終端顯示了一些必要的富呼叫數(shù)據(jù)，例如，公司名稱，呼叫原因，公司logo，公司地址，驗證狀態(tài)等必要的富呼叫數(shù)據(jù)。在以下的示例中，支持了富呼叫數(shù)據(jù)的呼叫在被呼叫方的手機終端會顯示其響應(yīng)的必要數(shù)據(jù)。 以下示例也展示了手機端顯示的必要信息，幫助被呼叫方判斷是否接聽此呼叫。

　　RCD的基本的業(yè)務(wù)處理方式如下：

　　Rich call data或者富呼叫數(shù)據(jù)利用了筆者已經(jīng)介紹過的STIR/SHAKEN的技術(shù)提供了呼叫驗證，利用網(wǎng)絡(luò)帶外技術(shù)，添加了公司logo和公司地址，呼叫原因等數(shù)據(jù)，同時在STIR/SHAEKN中增加了其PASSporT擴展的支持，通過數(shù)字簽名和身份的方式包括了Rich Call Data (RCD)RCD的支持。RCD的支持格式是通過 JSON支持，其對象中聲明了關(guān)于呼叫的富呼叫數(shù)據(jù)屬性類別，包括了幾個核心的屬性數(shù)據(jù)：

　　nam – 顯示的公司名稱

　　icn – 公司logo的URL或者圖片（可選）

　　inf – 網(wǎng)站公開的呼叫方描述

　　jcd – 呼叫方的jCard object。具體參考RFC 7095

　　jcl – 托管JCard的主機服務(wù)商URL。

　　關(guān)于以上RCD的說明，讀者可以參考PASSporT Extension for Rich Call Data-raft-ietf-stir-passport-rcd-19的五章節(jié)的關(guān)于PASSporT Claim "rcd" Definition and Usage。這里不再做過多介紹，在此文章的后續(xù)部分讀者會進一步涉及此內(nèi)容。

　　以下示例中，我們可以看到，發(fā)起呼叫時就帶了有效的身份驗證的Identity。這里的示例僅說明了呼叫服務(wù)發(fā)起時帶的一個有效身份驗證。當(dāng)然，我們后續(xù)還要介紹如何處理更加復(fù)雜的非法驗證的處理。

　　在發(fā)起呼叫時攜帶的有效的身份驗證頭

　　在一般的企業(yè)支持的RCD呼叫中，大概經(jīng)過七個步驟。首先，企業(yè)呼叫方對自己運營商進行呼叫，運營商查詢自己的STIR/SHAKEN 服務(wù)數(shù)據(jù)中心或者第三方的數(shù)據(jù)中心，然后轉(zhuǎn)發(fā)呼叫，返回302臨時消息，并且攜帶RCD數(shù)據(jù)。運營商收到STIR/SHAKEN服務(wù)中心的數(shù)據(jù)以后，繼續(xù)對運營商B進行呼叫。接下來，運營商B繼續(xù)對已簽名的呼叫結(jié)合RCD數(shù)據(jù)再次驗證，運營商收到返回的已驗證的RCD，最后呼叫終端用戶。終端用戶數(shù)據(jù)端顯示公司C的所有RCD信息。以下是一個典型的企業(yè)呼叫使用了RCD業(yè)務(wù)以后的處理流程示例。

　　我們通過基本的概念介紹和處理流程的說明，讀者應(yīng)該基本了解了其主要的處理步驟。接下來，我們會根據(jù)其每個環(huán)節(jié)的具體細(xì)節(jié)，為讀者說明如何實現(xiàn)RCD的處理。

　　關(guān)于RCD實現(xiàn)方式的討論

　　如果要實現(xiàn)企業(yè)用戶的RCD數(shù)據(jù)，運營商或者用戶首先需要輸入或者通過應(yīng)用程序添加用戶的相關(guān)的信息，包括地址，公司名稱，JSON card的URL地址等等相關(guān)的信息。這些信息可以根據(jù)運營商針對STIR/SHAKEN服務(wù)部署的策略存儲到STIR/SHAKEN服務(wù)中。

　　企業(yè)用戶呼叫到運營商以后，運營商SBC需要轉(zhuǎn)發(fā)呼叫，通過SBC驗證，然后添加rich data。

　　具體示例數(shù)據(jù)如下：

　　"rcd"： {

　　"jcd"： ["vcard"，

　　[ ["version"，{}，"text"，"4.0"]，

　　[“fn"，{}，"text"，"Q Branch"]，

　　[“org"，{}，"text"，"MI6；Q Branch Spy Gadgets"]，

　　["photo"，{}，"uri"，

　　"https://example.com/photos/quartermaster-256x256.png"]，

　　["logo"，{}，"uri"，

　　"https://example.com/logos/mi6-256x256.jpg"]，

　　["logo"，{}，"uri"，

　　"https://example.com/logos/mi6-64x64.jpg"]

　　]

　　]，

　　"nam"： "Q Branch Spy Gadgets"

　　}

　　更多關(guān)于JSON card 處理格式，讀者參考rfc7095。 關(guān)于運營商的SBC處理解決方案，讀者可以ribbon SBC參考以下示例：

　　通過以上示例，我們可以看出，第三方CA證書處理中心來實現(xiàn)集中實時處理。除了SHAKEN的PASSporT需要處理以外，RCD的其他數(shù)據(jù)有時也可能更新，例如URL，公司地址，或者logo鏈接等。這些數(shù)據(jù)需要在運營商對被呼叫方發(fā)送呼叫前都要分別執(zhí)行驗證服務(wù)，然后支撐發(fā)送到被呼叫方。這里的呼叫認(rèn)證ppt中支持了兩個類型，一個是SHAKEN類型，另外一個是RCD類型。具體的身份信息格式如下：

　　Identity： sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9

　　dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt

　　w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=；

　　info=；alg=ES256；

　　ppt="rcd"

　　在以下的驗證中，運營商會對SHAKEN服務(wù)中心查詢SHAKEN和RCD的身份，包括x5u， logo鏈接，呼叫方運營商，目的地運營商等數(shù)據(jù)。在運營商B對被呼叫方執(zhí)行最終呼叫時，同時攜帶了SHAKEN，RCD和身份頭。

　　除了通過RCD顯示呼叫方用戶呼叫數(shù)據(jù)的方式以外，筆者也在以前的文章中討論過關(guān)于新呼叫業(yè)務(wù)的支持。是否可以通過VoNR新通話技術(shù)利用數(shù)據(jù)通道實現(xiàn)其數(shù)據(jù)的展示？這可能也是未來在VoNR上疊加的功能。

　　對最新5G網(wǎng)絡(luò)中VoNR新通話技術(shù)白皮書的思考和關(guān)于SIP/IMS網(wǎng)絡(luò)/4G-VoLTEG和5G-VoNR中的業(yè)務(wù)和技術(shù)全面解讀

　　如果運營商想實現(xiàn)RCD和呼叫身份驗證的支持，首先從技術(shù)角度來說需要集成或者支持很多的服務(wù)。這些服務(wù)基本上需要運營商方面努力推動，包括部署新的服務(wù)，重新建構(gòu)呼叫流程設(shè)置。這些對運營商來說可能都不是太大的問題。根據(jù)一份權(quán)威的市場調(diào)研報告來看，截止到2022年最近日期，目前用戶收到的呼叫絕大部分仍然是未進行SHAKEN認(rèn)證的呼叫：

　　但是，同時運營商也正在逐漸增加對SHAKEN的支持：

　　實現(xiàn)SHAKEN技術(shù)部署的其中一個比較關(guān)注的問題是如何實現(xiàn)終端的顯示是運營商可能面對的極大挑戰(zhàn)。這里可能涉及到了手機操作系統(tǒng)平臺的介入問題。實際上，企業(yè)客戶想顯示更多關(guān)于呼叫方的信息，方便企業(yè)的營銷。但是，手機終端操作系統(tǒng)平臺可能會過濾或者屏蔽某些信息，這可能影響設(shè)計制造商的業(yè)務(wù)收益。可能運營商會支付一定的費用還是企業(yè)客戶支付使用，只能作為我們討論業(yè)務(wù)方面的話題，也是RCD業(yè)務(wù)面臨的一個比較大的風(fēng)險。

　　另外一個風(fēng)險是運營商是否有意愿更換當(dāng)前比較老舊的傳統(tǒng)的PSTN設(shè)備。這些設(shè)備不能支持網(wǎng)絡(luò)接口，也不能實現(xiàn)數(shù)據(jù)集成。傳統(tǒng)的PSTN網(wǎng)絡(luò)環(huán)境中，硬件設(shè)備已經(jīng)相當(dāng)老舊，如果需要支持STIR/SHAKEN只能更新其設(shè)備，從傳統(tǒng)的PSTN設(shè)備更新為支持STIR/SHAKEN的接入網(wǎng)關(guān)設(shè)備。另外，一般的傳統(tǒng)PSTN網(wǎng)絡(luò)環(huán)境中缺乏對數(shù)據(jù)中心處理的支持，這些呼叫號碼如何集成仍然是一個問題，還有各種SIP網(wǎng)絡(luò)中SIP消息的兼容性支持，例如一些SIP呼叫中的P-Asserted-Identity的處理。另外，一些歐洲國家已經(jīng)目前截止到2025年，語音網(wǎng)絡(luò)將全部升級為純IP網(wǎng)絡(luò)，而且需要實現(xiàn)STIR/SHAKEN的支持。運營商的固有的TDM網(wǎng)絡(luò)如何實現(xiàn)對STIR/SHAKEN升級，這也仍然是歐洲很多運營商面臨的嚴(yán)峻調(diào)整。為了實現(xiàn)其更換目標(biāo)，運營商只能通過IP化改造來完成STIR/SHAKEN的服務(wù)支持。以下示例是一個關(guān)于TDM進行IP化改造以后對STIR/SHAKEN的支持。以下示例中，通過帶外STIR支持方式，實現(xiàn)STIR/SHAKEN服務(wù)。

　　在以上示例中，在現(xiàn)有的TDM網(wǎng)絡(luò)環(huán)境中，一般情況下，終端首先對運營商的TDM交換機進行呼叫，然后通過PSTN網(wǎng)絡(luò)路由到另外一個目的地運營商的TDM交換機，最后呼叫對端終端。但是，如果實現(xiàn)IP化的STIR/SHAKEN支持的話，傳統(tǒng)的TDM交換機在呼叫PSTN網(wǎng)絡(luò)前，TDM交換機增加了一個TDM-SIP網(wǎng)關(guān)的STIR/SHAKEN服務(wù)支持。首先需要通過一個TDM-SIP網(wǎng)關(guān)的呼叫處理，TDM-SIP支持了STIR/SHAKEN服務(wù)以后，POST PASSporT進行查詢數(shù)據(jù)庫，返回結(jié)果以后，再對PSTN網(wǎng)絡(luò)進行呼叫。呼叫抵達對端以后，TDM交換機同樣需要進行TDM-SIP網(wǎng)關(guān)的STIR/SHAKEN查詢支持，通過擴展出來的TDM-SIP網(wǎng)關(guān)執(zhí)行STIR/SHAKEN查詢，返回查詢結(jié)果和驗證結(jié)果后，決定對此呼叫進行繼續(xù)轉(zhuǎn)發(fā)還是過濾。關(guān)于傳統(tǒng)TDM交換機實現(xiàn)對STIR/SHAKEN支持的規(guī)范細(xì)節(jié)，讀者可以參考RFC8816以及RFC8224。在此規(guī)范中，羅列了5種關(guān)于實現(xiàn)TDM網(wǎng)絡(luò)支持STIR/SHAKEN的用戶場景，包括了：

　　1.VoIP to PSTN Call

　　2.兩個智能終端的呼叫

　　3.PSTN to VoIP Call

　　4.網(wǎng)關(guān)帶外處理

　　5.企業(yè)呼叫中心

　　此規(guī)范中介紹了關(guān)于PASSporT的存儲和獲取的處理流程以及Call Placement Service (CPS)數(shù)據(jù)庫的處理機制。其實現(xiàn)流程細(xì)節(jié)如下：

　　前面我們介紹了關(guān)于傳統(tǒng)TDM交換機支持STIR/SHAKEN的實現(xiàn)方式。在當(dāng)前的網(wǎng)絡(luò)環(huán)境中，基于IP語音的交換方式已經(jīng)在現(xiàn)代企業(yè)通信環(huán)境中起到了絕對的支撐作用。因此，在傳統(tǒng)PSTN線路運營到IP語音交換的呼叫路徑上或者IP呼叫的話，需要通過另外一種處理方式來實現(xiàn)關(guān)于PASSporT的驗證處理。為了實現(xiàn)PASSporT的驗證處理，需要在運營商的SBC實現(xiàn)PASSporT支持。這里我們可以看到，呼叫發(fā)起以后，首先需要通過運營商的STIR/SHAKEN 服務(wù)對呼叫進行認(rèn)證服務(wù)，此呼叫支持了簽名支持以后，運營商通過運營商自己的SBC對CPS服務(wù)數(shù)據(jù)庫發(fā)送PASSporT。然后此呼叫被發(fā)送到PSTN網(wǎng)絡(luò)。在對端運營商接收到呼叫以后，對端運營商的SBC首先需要獲取此呼叫的PASSporT，然后運營商對帶PASSporT的這個呼叫進行STIR/SHAKEN 驗證服務(wù)。獲取到驗證的呼叫以后，運營商根據(jù)驗證結(jié)果決定是否把這個呼叫發(fā)送到目的地終端客戶。

　　綜上所述，結(jié)合目前網(wǎng)絡(luò)的推進速度，從以上網(wǎng)絡(luò)架構(gòu)來看，運營商現(xiàn)在不僅僅面臨繼續(xù)對5G或者6G網(wǎng)絡(luò)的投資，如果想實現(xiàn)對STIR/SHAKEN支持的話，還要對傳統(tǒng)PSTN網(wǎng)絡(luò)投入SBC，增加其驗證流程。所以，很多運營商可能也正在觀望中，沒有太多動力推動來推動此業(yè)務(wù)的升級。

　　在以上的章節(jié)中，筆者介紹了關(guān)于PSTN網(wǎng)絡(luò)和IP網(wǎng)絡(luò)環(huán)境中針對STIR/SHAKEN的業(yè)務(wù)支持的解決方案分享。但是，在具體的業(yè)務(wù)場景中，關(guān)于呼叫身份的驗證仍然具有很多挑戰(zhàn)，例如呼叫轉(zhuǎn)移以后的呼叫身份驗證問題。用戶可以想象一下，假設(shè)，一個號碼呼出以后，到對方接聽以后，然后發(fā)起了一個呼叫轉(zhuǎn)移，呼叫轉(zhuǎn)移以后，號碼身份狀態(tài)就會隨之發(fā)生變化。如果沒有完整更新其呼叫身份的話，那么最終用戶可能看到的是一個未進行呼叫身份驗證的呼叫。這樣的話，整個呼叫身份驗證流程就會失敗。如何跟蹤此呼叫的路徑中完整的身份狀態(tài)是一個需要面對的挑戰(zhàn)。在IP或者SIP網(wǎng)絡(luò)環(huán)境中，轉(zhuǎn)移的呼叫一般稱之為diverted的呼叫。具體的支持策略是，通過在SHAKEN中增加一個擴展支持- “div” PASSporT。通過九個步驟的流程處理來實現(xiàn)全程呼叫轉(zhuǎn)移的身份驗證跟蹤。

　　在以上處理流程中， 對于呼叫轉(zhuǎn)移的號碼進行了完整的驗證和跟蹤處理。具體流程已經(jīng)在圖例中進行了標(biāo)識。在整個呼叫流程的處理過程中，讀者需要注意的是在TN-b 對呼叫進行轉(zhuǎn)移處理時，在INVITE中包含了另外一個身份，此身份的div中添加了orig/dest/div 三個參數(shù)， 它們分別是a/c和b。呼叫接收方然后再次轉(zhuǎn)發(fā)此呼叫到最終呼叫目的地。在最終呼叫目的地仍然需要進行STIR/SHAKEN的三方驗證服務(wù)，檢查其關(guān)聯(lián)性，然后對最終目的地呼叫方返回驗證的INVITE。最終呼叫目的地運營商最后對TN-c 發(fā)起呼叫。從以上對呼叫轉(zhuǎn)移的處理中，我們可以看到一個div頭， 此div header是SIP協(xié)議的一個擴展，它支持了PASSporT來驗證其身份狀態(tài)。在下面的章節(jié)中，筆者進一步為讀者介紹一些關(guān)于div PASSporT的細(xì)節(jié)內(nèi)容。

　　在討論Call Diversion時，筆者必須首先說明幾個主要的關(guān)于呼叫業(yè)務(wù)的概念和區(qū)別，避免讓讀者迷糊。從籠統(tǒng)的或者比較寬泛的概念中，呼叫轉(zhuǎn)移可能存在以下幾個方面的解釋，它們有著非常大的區(qū)別。筆者對部分內(nèi)容進行了標(biāo)識，和Call Diversion，Redirect和Retarget的不同概念說明：

　　Call Diversion： Any call feature that updates the destination telephone number of a call to a new or alternate telephone number. Example call features include the various forms of call forwarding， find-me/follow-me (simultaneous or sequential ringing)， and automatic call distribution.

　　Redirect： As defined in RFC 3261 [Ref 6]， "redirect" refers to the process where a SIP entity redirects a SIP request to a new destination by responding to the request with a 3xx Redirection class response. This specification addresses redirection only for INVITE requests， and only for the case where the 3xx response is handled by a recursing SIP proxy that retargets the INVITE request to the new destination.

　　Retarget： As defined in RFC 7044 [Ref 9]， "retarget" refers to the process where a SIP entity updates the RequestURI of a SIP request. This specification narrows the scope of the RFC 7044 [Ref 9] definition to include only INVITE requests， and only for cases where the update changes the canonical value of the telephone number identified by the INVITE Request-URI.

　　這里我們重點討論Call Diversion。其他兩個概念不再進行討論。讀者如果有興趣的話，可以自己進一步研究。當(dāng)然，如果需要實現(xiàn)STIR/SHAKEN支持的話，那是另外一個話題，比如IPPBX中的STIR/SHAKEN 呼叫業(yè)務(wù)的支持等。筆者將在未來的文章中對其處理過程進行深入討論。以下示例是一個完整的關(guān)于經(jīng)過呼叫轉(zhuǎn)移的SIP INITE攜帶兩個ldentity，分別支持了不同的ppt 類型，一個是SHAKEN，另外一個就是呼叫轉(zhuǎn)移的div 擴展。

 

　　針對SHAKE和div的PASSporT的token 令牌分別是：

 

　　在保護頭中包含了身份證明信息，例如ppt類型，證書路徑等。在payload中包括了呼叫運營商，呼叫初始號碼，轉(zhuǎn)接號碼和最終目的地號碼等。關(guān)于div的PASSporT令牌的規(guī)范說明，讀者可以參考RFC8946(Personal Assertion Token (PASSporT) Extension for Diverted Calls)。關(guān)于SHANEK的PASSporT，讀者可以參考https://art.tools.ietf.org/id/draft-ietf-stir-passport-shaken-03.html和RFC8225 關(guān)于PASSporT的令牌的定義使用。

　　上面我們討論了關(guān)于呼叫轉(zhuǎn)移流程中實現(xiàn)div PASSporT的處理流程。接下來，我們進一步討論在呼叫轉(zhuǎn)移過程中，如果轉(zhuǎn)移的網(wǎng)絡(luò)是非IP網(wǎng)絡(luò)，例如接入到PSTN網(wǎng)絡(luò)中的技術(shù)處理策略。在以下圖例中，如果發(fā)送呼叫轉(zhuǎn)移的話，呼叫轉(zhuǎn)移的網(wǎng)絡(luò)在新的身份中支持了PASSporT-div-o， 并且包含了一個opt（

　　Original PASSporT）要素。

 

　　讀者一定要注意這里的INVITE 呼叫所包含的身份信息。在div-o 的PASSpoorT中，它包含了一個opt 要素， 并且在opt中還包含了一個原始的SHAKEN PASSporT的完整拷貝，而不是在SIP INVITE中包含多個身份的方式。在前面的示例中，INVITE中包含了兩個身份。這是呼叫轉(zhuǎn)移到IP網(wǎng)絡(luò)和非IP網(wǎng)絡(luò)（PSTN）它們之間的根本區(qū)別。 在實現(xiàn)呼叫轉(zhuǎn)移到非IP網(wǎng)絡(luò)或者PSTN網(wǎng)絡(luò)的驗證中，這個流程處理大概經(jīng)過11個主要步驟。這個新的PASSporT存儲到CPS服務(wù)數(shù)據(jù)庫，并且將會通過CPS 數(shù)據(jù)庫進行驗證。最終呼叫目的地的PSTN網(wǎng)絡(luò)將根據(jù)從SHAKEN獲得的服務(wù)驗證，然后轉(zhuǎn)移此呼叫到最終目的地號碼。另外，其身份中的PPT類型也發(fā)生了變化，ppt現(xiàn)在是div-o， 而不是以前的div類型。更多關(guān)于div-o的細(xì)節(jié)，讀者查閱RFC8946的第五章節(jié)關(guān)于div-o的使用。

　　除了運營商通過本身的SHAKEN驗證中心來驗證呼叫身份以外，運營商也可以以第三方分析引擎結(jié)合SHAKEN來實現(xiàn)呼叫身份的驗證。呼叫分析引擎具體實現(xiàn)方式如下：

　　企業(yè)用戶或者其他終端用戶需要呼叫到運營商SBC端，如果非法侵入的用戶可能無有效的PASSporT。呼叫發(fā)送到運營商的SBC端，然后SBC呼叫發(fā)起一個INVITE攜帶PASSporT，通過分析引擎驗證以后，最后符合呼叫的身份，如果是一個非法呼叫或者被標(biāo)識了無效的PASSporT是無法通過其認(rèn)證的。分析引擎可以通過SHAKEN服務(wù)訪問以及匯聚第三方其他數(shù)據(jù)來集中進行判斷分析。

　　前面我們花費了很多精力討論如何實現(xiàn)呼叫身份的確認(rèn)以及其呼叫轉(zhuǎn)移后的SHAKEN處理。運營商通過在呼叫路徑中不同的技術(shù)手段實現(xiàn)了其呼叫身份的驗證。成功驗證的呼叫當(dāng)然可以順利抵達呼叫終端。但是，我們也可能會經(jīng)常遇到未成功認(rèn)證的呼叫身份。未認(rèn)證成功的呼叫可能就被運營商過濾掉了。如何處理過濾掉的呼叫，或者如何讓呼叫方獲悉其呼叫已經(jīng)被過濾，過濾的原因等等。FCC對其處理有一個規(guī)定，要求運營商過濾掉呼叫以后，必須對呼叫方返回過濾提示，推薦使用的SIP錯誤碼為607和608. 在過濾解封的處理流程中，呼叫分析引擎通過和SHAKEN集成，支持了vcard來獲取完整的過濾原因和聯(lián)系方式等信息。

　　如果集成了傳統(tǒng)網(wǎng)絡(luò)的話，返回了608的話，在SIP頭中可以增加Call-Info header。

　　在這個頭中必須包括"jwscard"的目的參數(shù)。在jwscard中必須包含有效的json 格式簽名。下面我們可以看一個支持了SHAKEN的INVITE：

　　INVITE sip：+12155550113@tel.one.example.net SIP/2.0

　　Max-Forwards： 69

　　Contact：

　　To：

　　From： "Alice" ；tag=614bdb40

　　Call-ID： 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI

　　P-Asserted-Identity： "Alice"，

　　

　　CSeq： 2 INVITE

　　Allow： SUBSCRIBE， NOTIFY， INVITE， ACK， CANCEL， BYE， REFER， INFO，

　　MESSAGE， OPTIONS

　　Content-Type： application/sdp

　　Date： Tue， 16 Aug 2016 19：23：38 GMT

　　Feature-Caps： *；+sip.608

　　Identity： eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V

　　uIiwieDV1IjoiaHR0cDovL2NlcnQuZXhhbXBsZTIubmV0L2V4YW1wbGUuY2VydCJ9.eyJ

　　hdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MDExMyJ9LCJpYXQiOiIxNDcx

　　Mzc1NDE4Iiwib3JpZyI6eyJ0biI6IisxMjE1NTU1MDExMiJ9LCJvcmlnaWQiOiIxMjNlN

　　DU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2NTU0NDAwMCJ9.QAht_eFqQlaoVrnEV56Qly-OU

　　tsDGifyCcpYjWcaR661Cz1hutFH2BzIlDswTahO7ujjqsWjeoOb4h97whTQJg；info=

　　；alg=ES256

　　Content-Length： 153

　　v=0

　　o=- 13103070023943130 1 IN IP6 2001：db8：：177

　　c=IN IP6 2001：db8：：177

　　t=0 0

　　m=audio 54242 RTP/AVP 0

　　a=sendrecv

　　一個SIP中介實體返回了：

　　SIP/2.0 608 Rejected

　　Via： SIP/2.0/UDP [2001：db8：：177]：60012；branch=z9hG4bK-524287-1

　　From： "Alice" ；tag=614bdb40

　　To：

　　Call-ID： 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI

　　CSeq： 2 INVITE

　　Call-Info： ；purpose=jwscard

　　最終這個呼叫的最小的jcard數(shù)據(jù)是這樣的：

　　["vcard"，

　　[

　　["version"， {}， "text"， "4.0"]，

　　["fn"， {}， "text"， "Robocall Adjudication"]， // 機器人呼叫

　　["email"， {"type"："work"}， "text"，

　　"remediation@blocker.example.net"]  // 聯(lián)系方式

　　]

　　]

　　關(guān)于呼叫認(rèn)證過濾后的返回處理機制，讀者可以進一步學(xué)習(xí)一些RFC。關(guān)于607 code， 參考rfc8197，關(guān)于608 code，參考rfc8688。

　　構(gòu)建騷擾電話協(xié)同處理機制來解決呼叫身份驗證問題

　　通過筆者的一系列介紹中我們可以看出，技術(shù)手段的實現(xiàn)都最終需要運營商落實。其實，最終要杜絕或者消滅騷擾電話的話，從國家層面或者國際合作的層面才能解決這個問題。目前可以看到的美國運營商已經(jīng)開始行動了，對運營商強制要求執(zhí)行。美國國會議員已經(jīng)正式提交了關(guān)于機器人騷擾電話濫用犯罪的法案-TRACED Act Implementation(Telephone Robocall Abuse Criminal Enforcement and Deterrence). 在此法案中明確規(guī)定運營商必須強制使用STIR/SHAKEN 呼叫身份認(rèn)證工具，并且列出了實施路徑和時間表。

　　FCC已經(jīng)正式發(fā)布了網(wǎng)關(guān)接入的強制要求。美國本土運營商必須支持STIR/SHAKEN的呼叫認(rèn)證服務(wù)， 國外運營商接入到美國本土網(wǎng)絡(luò)時需要通過FCC 數(shù)據(jù)庫進行記錄登記。

　　1.運營商和國外接入運營商必須支持STIR/SHAKEN身份驗證服務(wù)

　　2.呼叫號碼必須注冊到FCC的 Robocall Mitigation Database (RMD)數(shù)據(jù)庫。筆者前面提到過這個號碼數(shù)據(jù)庫。

　　3.必須執(zhí)行相關(guān)的機器人騷擾電話呼叫的集成流程，包括全天候的呼叫跟蹤響應(yīng)，強制過濾非法呼叫，獲知上游運營商呼叫號碼的合法性，要求呼入網(wǎng)關(guān)減輕非法呼叫，部署SHAKEN呼叫認(rèn)證服務(wù)。

　　在部署STIR/SHAKEN時，當(dāng)然各種運營商和國際之間的運營商接入都會發(fā)生一定的變化。如何防范國際呼叫的騷擾電話和對其呼叫進行跟蹤，如何讓國際呼叫支持STIR/SHAKEN身份認(rèn)證服務(wù)，這些都需要通過國際電信組織來完善，例如建立國際間的STIR/SHAKEN服務(wù)方式：

　　如果建立起了比較完善的STIR/SHAKEN 呼叫身份跟蹤機制，支持STIR/SHAKEN的聯(lián)盟之間就可以針對騷擾電話號碼，以及為騷擾電話提供線路服務(wù)的運營商進行標(biāo)識，根據(jù)其令牌和證書進行跟蹤標(biāo)識，對其服務(wù)進行評估，然后采取進一步的強制措施，包括通過公開的Robocall Mitigation Database 查詢其運營商的服務(wù)水平和質(zhì)量，倒逼運營商減少對騷擾電話服務(wù)支持。例如，從SHAKEN的認(rèn)證信息中體現(xiàn)了完整的呼叫身份信息，從x5u中我們可以查詢到證書簽發(fā)機構(gòu)，從origid中可以查詢到騷擾電話的運營商認(rèn)證信息。

　　讀者也可以查詢公開的FCC 關(guān)于Robocall Mitigation Database

　　https://fccprod.servicenowservices.com/rmd？id=rmd_listings

　　另外，除了運營商需要繼續(xù)努力來支持STIR/SHAKEN 呼叫認(rèn)證服務(wù)以外，也可以通過手機平臺對呼叫進行設(shè)置或者標(biāo)識的支持來降低騷擾電話的問題。但是，電話已經(jīng)接入到用戶端，其用戶已經(jīng)受到騷擾，這種方式缺乏規(guī)范性，同時也對解決呼叫身份驗證沒有太大的幫助，只是一種被動防范的方式。

　　雖然運營商都在努力部署和支持SHAKEN，但是，打通整個運營商的呼叫數(shù)據(jù)仍然需要更高層級的運營商之間的協(xié)同。各種非法電話已經(jīng)讓FCC倍感壓力。

　　來自于：https://tracebacks.org/wp-content/uploads/2021/08/ITG-Report-Combatting-Illegal-Robocalls.pdf

　　Industry Traceback Group是FCC設(shè)計的一個呼叫回溯的組織。目前，其會員數(shù)量達到30多個，會員基本上都是美國比較主流的運營商，這樣可以杜絕大家互相扯皮，踢皮球。Traceback 是一種跟蹤回溯機制，通過約定的策略和機制來保證呼叫身份的正常和狀態(tài)更新。Traceback根據(jù)認(rèn)定的呼叫身份進行互聯(lián)互通和響應(yīng)反饋。關(guān)于 ITG 的POLICIES AND PROCEDURES的細(xì)節(jié)讀者可以查看參考鏈接中的PDF文件。

　　前面筆者介紹了大量的關(guān)于SHAKEN的技術(shù)和具體在運營商之間部署的技術(shù)流程，包括了其他呼叫業(yè)務(wù)中所面臨的技術(shù)問題，以及如何支持傳統(tǒng)的PSTN網(wǎng)絡(luò)的SHAKEN認(rèn)證。其實，國內(nèi)的推進速度也非�？臁Ｈ珖�信息安全標(biāo)準(zhǔn)化技術(shù)委員會也根據(jù)SHAKEN的一些缺點，推動發(fā)布了基于SHAKEN的CHAKEN技術(shù)。由牽頭單位中國科學(xué)院大學(xué)、參與單位中國電信集團有限公司和微位 （深圳）網(wǎng)絡(luò)科技有限公司一起對本標(biāo)準(zhǔn)中的 CHAKEN 方案進行了試驗驗證，并且在2022年03月30日發(fā)布了關(guān)于關(guān)于國家標(biāo)準(zhǔn)《信息安全技術(shù) 基于密碼令牌的主叫用戶可信身份鑒別技術(shù)規(guī)范》征求意見稿征求意見的通知。其實現(xiàn)架構(gòu)如下：

　　讀者有興趣的話，可以查閱此意見稿，通過參考鏈接下載關(guān)于信息安全技術(shù) 基于密碼令牌的主叫用戶可 信身份鑒別技術(shù)規(guī)范。

　　其SIP INVITE信息格式如下：

　　INVITE sip：alice@example.com SIP/2.0

　　Via： SIP/2.0/TLS pc33.atlanta.example.com；branch=z9hG4bKnashds8

　　To： Alice

　　From： Bob ；tag=1928301774>

　　Call-ID： a84b4c76e66710@example.com

　　CSeq： 314159 INVITE

　　Max-Forwards： 70

　　Identity： tokenindex=v_tokenIndex@address；ppt=CHAKEN；

　　本文章討論了多個目前運營商針對呼叫身份驗證STIR/SHAKEN，和富呼叫數(shù)據(jù)-RCD，以及部署SHAKEN所面臨的挑戰(zhàn)和目前國內(nèi)即將執(zhí)行的CHAKEN技術(shù)以及基于密碼令牌的主叫用戶可 信身份鑒別技術(shù)規(guī)范。RCD是運營商業(yè)務(wù)的新的服務(wù)突破點，它會給用戶帶來很多更好的呼叫業(yè)務(wù)體驗。通過SHAKEN技術(shù)實現(xiàn)呼叫身份驗證，幫助用戶杜絕騷擾電話和騙子電話，以及各種非法呼叫。目前，國內(nèi)的騷擾電話也非常猖狂，運營商貌似也無可奈何。

　　通過CHAKEN技術(shù)從呼叫源頭對呼叫進行身份跟蹤，能夠極大降低騷擾電話的發(fā)生。

　　在針對SHAKEN的部署環(huán)節(jié)中，筆者主要深入討論了如何實現(xiàn)PSTN網(wǎng)絡(luò)對SHAKEN身份的支持，通過SHAKEN和SBC，以及呼叫分析引擎對呼叫進行全程跟蹤，同時筆者又對呼叫業(yè)務(wù)中呼叫轉(zhuǎn)移的技術(shù)實現(xiàn)進行了詳解，幫助讀者進一步深入了解呼叫轉(zhuǎn)移的流程和對每個節(jié)點的SHAKEN的支持，查詢等。

　　另外，部署執(zhí)行FCC的SHAKEN技術(shù)，需要各個運營商或者全世界的運營商共同構(gòu)建一個SHAKEN的聯(lián)盟，通過SHAKEN來跟蹤不同國家，不同運營商的呼叫，同時能夠?qū)崿F(xiàn)實時協(xié)同來提高SHAKEN服務(wù)的效率。

　　國內(nèi)即將部署的CHAKEN可能也會面對美國運營商所面臨的技術(shù)問題和運營商之間，呼叫業(yè)務(wù)，運營商不同網(wǎng)絡(luò)之間的協(xié)同的問題，我們希望國內(nèi)的CHAKEN技術(shù)能夠更加完善，快速推向市場，提高用戶對呼叫業(yè)務(wù)的體驗。

　　說明，我們討論的RCD，SHAKEN技術(shù)以及CHAKEN技術(shù)都是正在更新的技術(shù)，文章中的一些規(guī)范或者技術(shù)實現(xiàn)方式可能會不斷更新。另外，筆者水平有限。因此，文章中難免會存在很多錯誤，望諒解！關(guān)于此方面的技術(shù)最新的技術(shù)動態(tài)，關(guān)注筆者公眾號。