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

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

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

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

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

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

　　1.關于RCD-rich call data背景介紹

　　2.關于rich call data相關基本介紹

　　3.關于RCD實現方式的討論

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

　　5.關于STIR/SHAKEN技術針對呼叫轉移和非IP網絡的技術挑戰(zhàn)

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

　　7.關于呼叫身份的后處理問題討論

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

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

　　10.國內關于呼叫身份驗證的推動進程

　　在我們日常生活中，我們經常會陌生人打來的電話。一些是客戶的咨詢電話，一些可能是其他教育機構，金融中介等的電話。這些電話一部分是真正的用戶或者其他客戶的電話，有一部分是騷擾電話或者騙子打來的電話。陌生人的電話到底是接還是不接？ 如果漏接了客戶的電話，擔心自己錯過一個億的生意。接的話，這些電話有可能是營銷電話或者騙子的電話，浪費時間。

　　此圖例以及以下部分討論來自于互聯網資源

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

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

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

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

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

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

　　nam – 顯示的公司名稱

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

　　inf – 網站公開的呼叫方描述

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

　　jcl – 托管JCard的主機服務商URL。

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

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

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

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

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

　　關于RCD實現方式的討論

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

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

　　具體示例數據如下：

　　"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"

　　}

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

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

　　Identity： sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9

　　dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt

　　w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=；

　　info=；alg=ES256；

　　ppt="rcd"

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

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

　　對最新5G網絡中VoNR新通話技術白皮書的思考和關于SIP/IMS網絡/4G-VoLTEG和5G-VoNR中的業(yè)務和技術全面解讀

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

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

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

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

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

　　1.VoIP to PSTN Call

　　2.兩個智能終端的呼叫

　　3.PSTN to VoIP Call

　　4.網關帶外處理

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

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

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

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

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

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

　　在討論Call Diversion時，筆者必須首先說明幾個主要的關于呼叫業(yè)務的概念和區(qū)別，避免讓讀者迷糊。從籠統(tǒng)的或者比較寬泛的概念中，呼叫轉移可能存在以下幾個方面的解釋，它們有著非常大的區(qū)別。筆者對部分內容進行了標識，和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。其他兩個概念不再進行討論。讀者如果有興趣的話，可以自己進一步研究。當然，如果需要實現STIR/SHAKEN支持的話，那是另外一個話題，比如IPPBX中的STIR/SHAKEN 呼叫業(yè)務的支持等。筆者將在未來的文章中對其處理過程進行深入討論。以下示例是一個完整的關于經過呼叫轉移的SIP INITE攜帶兩個ldentity，分別支持了不同的ppt 類型，一個是SHAKEN，另外一個就是呼叫轉移的div 擴展。

 

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

 

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

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

　　Original PASSporT）要素。

 

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

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

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

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

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

　　在這個頭中必須包括"jwscard"的目的參數。在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數據是這樣的：

　　["vcard"，

　　[

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

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

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

　　"remediation@blocker.example.net"]  // 聯系方式

　　]

　　]

　　關于呼叫認證過濾后的返回處理機制，讀者可以進一步學習一些RFC。關于607 code， 參考rfc8197，關于608 code，參考rfc8688。

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

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

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

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

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

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

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

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

　　讀者也可以查詢公開的FCC 關于Robocall Mitigation Database

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

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

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

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

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

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

　　讀者有興趣的話，可以查閱此意見稿，通過參考鏈接下載關于信息安全技術 基于密碼令牌的主叫用戶可 信身份鑒別技術規(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，和富呼叫數據-RCD，以及部署SHAKEN所面臨的挑戰(zhàn)和目前國內即將執(zhí)行的CHAKEN技術以及基于密碼令牌的主叫用戶可 信身份鑒別技術規(guī)范。RCD是運營商業(yè)務的新的服務突破點，它會給用戶帶來很多更好的呼叫業(yè)務體驗。通過SHAKEN技術實現呼叫身份驗證，幫助用戶杜絕騷擾電話和騙子電話，以及各種非法呼叫。目前，國內的騷擾電話也非常猖狂，運營商貌似也無可奈何。

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

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

　　另外，部署執(zhí)行FCC的SHAKEN技術，需要各個運營商或者全世界的運營商共同構建一個SHAKEN的聯盟，通過SHAKEN來跟蹤不同國家，不同運營商的呼叫，同時能夠實現實時協(xié)同來提高SHAKEN服務的效率。

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

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