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

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

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

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

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

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

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

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

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

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

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

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

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

　　8.利用呼叫分析引擎技術(shù)來(lái)過(guò)濾騷擾電話(huà)

　　9.構建騷擾電話(huà)協(xié)同處理機制來(lái)解決呼叫身份驗證問(wèn)題

　　10.國內關(guān)于呼叫身份驗證的推動(dòng)進(jìn)程

　　在我們日常生活中，我們經(jīng)常會(huì )陌生人打來(lái)的電話(huà)。一些是客戶(hù)的咨詢(xún)電話(huà)，一些可能是其他教育機構，金融中介等的電話(huà)。這些電話(huà)一部分是真正的用戶(hù)或者其他客戶(hù)的電話(huà)，有一部分是騷擾電話(huà)或者騙子打來(lái)的電話(huà)。陌生人的電話(huà)到底是接還是不接？ 如果漏接了客戶(hù)的電話(huà)，擔心自己錯過(guò)一個(gè)億的生意。接的話(huà)，這些電話(huà)有可能是營(yíng)銷(xiāo)電話(huà)或者騙子的電話(huà)，浪費時(shí)間。

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

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

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

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

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

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

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

　　nam – 顯示的公司名稱(chēng)

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

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

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

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

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

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

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

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

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

　　關(guān)于RCD實(shí)現方式的討論

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

　　企業(yè)用戶(hù)呼叫到運營(yíng)商以后，運營(yíng)商SBC需要轉發(fā)呼叫，通過(guò)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"

　　}

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

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

　　Identity： sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9

　　dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt

　　w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=；

　　info=；alg=ES256；

　　ppt="rcd"

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

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

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

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

　　但是，同時(shí)運營(yíng)商也正在逐漸增加對SHAKEN的支持：

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

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

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

　　1.VoIP to PSTN Call

　　2.兩個(gè)智能終端的呼叫

　　3.PSTN to VoIP Call

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

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

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

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

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

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

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

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

　　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.

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

 

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

 

　　在保護頭中包含了身份證明信息，例如ppt類(lèi)型，證書(shū)路徑等。在payload中包括了呼叫運營(yíng)商，呼叫初始號碼，轉接號碼和最終目的地號碼等。關(guān)于div的PASSporT令牌的規范說(shuō)明，讀者可以參考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)于呼叫轉移流程中實(shí)現div PASSporT的處理流程。接下來(lái)，我們進(jìn)一步討論在呼叫轉移過(guò)程中，如果轉移的網(wǎng)絡(luò )是非IP網(wǎng)絡(luò )，例如接入到PSTN網(wǎng)絡(luò )中的技術(shù)處理策略。在以下圖例中，如果發(fā)送呼叫轉移的話(huà)，呼叫轉移的網(wǎng)絡(luò )在新的身份中支持了PASSporT-div-o， 并且包含了一個(gè)opt（

　　Original PASSporT）要素。

 

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

　　除了運營(yíng)商通過(guò)本身的SHAKEN驗證中心來(lái)驗證呼叫身份以外，運營(yíng)商也可以以第三方分析引擎結合SHAKEN來(lái)實(shí)現呼叫身份的驗證。呼叫分析引擎具體實(shí)現方式如下：

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

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

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

　　在這個(gè)頭中必須包括"jwscard"的目的參數。在jwscard中必須包含有效的json 格式簽名。下面我們可以看一個(gè)支持了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

　　一個(gè)SIP中介實(shí)體返回了：

　　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

　　最終這個(gè)呼叫的最小的jcard數據是這樣的：

　　["vcard"，

　　[

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

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

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

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

　　]

　　]

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

　　構建騷擾電話(huà)協(xié)同處理機制來(lái)解決呼叫身份驗證問(wèn)題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　其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；

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

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

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

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

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

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