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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　企業(yè)用戶(hù)呼叫到運(yùn)營(yíng)商以后，運(yùn)營(yíng)商SBC需要轉(zhuǎn)發(fā)呼叫，通過(guò)SBC驗(yàn)證，然后添加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)于運(yùn)營(yíng)商的SBC處理解決方案，讀者可以ribbon SBC參考以下示例：

　　通過(guò)以上示例，我們可以看出，第三方CA證書(shū)處理中心來(lái)實(shí)現(xiàn)集中實(shí)時(shí)處理。除了SHAKEN的PASSporT需要處理以外，RCD的其他數(shù)據(jù)有時(shí)也可能更新，例如URL，公司地址，或者logo鏈接等。這些數(shù)據(jù)需要在運(yùn)營(yíng)商對(duì)被呼叫方發(fā)送呼叫前都要分別執(zhí)行驗(yàn)證服務(wù)，然后支撐發(fā)送到被呼叫方。這里的呼叫認(rèn)證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àn)證中，運(yùn)營(yíng)商會(huì)對(duì)SHAKEN服務(wù)中心查詢(xún)SHAKEN和RCD的身份，包括x5u， logo鏈接，呼叫方運(yùn)營(yíng)商，目的地運(yùn)營(yíng)商等數(shù)據(jù)。在運(yùn)營(yíng)商B對(duì)被呼叫方執(zhí)行最終呼叫時(shí)，同時(shí)攜帶了SHAKEN，RCD和身份頭。

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

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

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

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

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

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

　　在以上示例中，在現(xiàn)有的TDM網(wǎng)絡(luò)環(huán)境中，一般情況下，終端首先對(duì)運(yùn)營(yíng)商的TDM交換機(jī)進(jìn)行呼叫，然后通過(guò)PSTN網(wǎng)絡(luò)路由到另外一個(gè)目的地運(yùn)營(yíng)商的TDM交換機(jī)，最后呼叫對(duì)端終端。但是，如果實(shí)現(xiàn)IP化的STIR/SHAKEN支持的話(huà)，傳統(tǒng)的TDM交換機(jī)在呼叫PSTN網(wǎng)絡(luò)前，TDM交換機(jī)增加了一個(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)數(shù)據(jù)庫(kù)，返回結(jié)果以后，再對(duì)PSTN網(wǎng)絡(luò)進(jìn)行呼叫。呼叫抵達(dá)對(duì)端以后，TDM交換機(jī)同樣需要進(jìn)行TDM-SIP網(wǎng)關(guān)的STIR/SHAKEN查詢(xún)支持，通過(guò)擴(kuò)展出來(lái)的TDM-SIP網(wǎng)關(guān)執(zhí)行STIR/SHAKEN查詢(xún)，返回查詢(xún)結(jié)果和驗(yàn)證結(jié)果后，決定對(duì)此呼叫進(jìn)行繼續(xù)轉(zhuǎn)發(fā)還是過(guò)濾。關(guān)于傳統(tǒng)TDM交換機(jī)實(shí)現(xiàn)對(duì)STIR/SHAKEN支持的規(guī)范細(xì)節(jié)，讀者可以參考RFC8816以及RFC8224。在此規(guī)范中，羅列了5種關(guān)于實(shí)現(xiàn)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ī)范中介紹了關(guān)于PASSporT的存儲(chǔ)和獲取的處理流程以及Call Placement Service (CPS)數(shù)據(jù)庫(kù)的處理機(jī)制。其實(shí)現(xiàn)流程細(xì)節(jié)如下：

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

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

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

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

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

 

　　針對(duì)SHAKE和div的PASSporT的token 令牌分別是：

 

　　在保護(hù)頭中包含了身份證明信息，例如ppt類(lèi)型，證書(shū)路徑等。在payload中包括了呼叫運(yùn)營(yíng)商，呼叫初始號(hào)碼，轉(zhuǎn)接號(hào)碼和最終目的地號(hào)碼等。關(guān)于div的PASSporT令牌的規(guī)范說(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)于呼叫轉(zhuǎn)移流程中實(shí)現(xiàn)div PASSporT的處理流程。接下來(lái)，我們進(jìn)一步討論在呼叫轉(zhuǎn)移過(guò)程中，如果轉(zhuǎn)移的網(wǎng)絡(luò)是非IP網(wǎng)絡(luò)，例如接入到PSTN網(wǎng)絡(luò)中的技術(shù)處理策略。在以下圖例中，如果發(fā)送呼叫轉(zhuǎn)移的話(huà)，呼叫轉(zhuǎn)移的網(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è)身份。這是呼叫轉(zhuǎn)移到IP網(wǎng)絡(luò)和非IP網(wǎng)絡(luò)（PSTN）它們之間的根本區(qū)別。 在實(shí)現(xiàn)呼叫轉(zhuǎn)移到非IP網(wǎng)絡(luò)或者PSTN網(wǎng)絡(luò)的驗(yàn)證中，這個(gè)流程處理大概經(jīng)過(guò)11個(gè)主要步驟。這個(gè)新的PASSporT存儲(chǔ)到CPS服務(wù)數(shù)據(jù)庫(kù)，并且將會(huì)通過(guò)CPS 數(shù)據(jù)庫(kù)進(jìn)行驗(yàn)證。最終呼叫目的地的PSTN網(wǎng)絡(luò)將根據(jù)從SHAKEN獲得的服務(wù)驗(yàn)證，然后轉(zhuǎn)移此呼叫到最終目的地號(hào)碼。另外，其身份中的PPT類(lèi)型也發(fā)生了變化，ppt現(xiàn)在是div-o， 而不是以前的div類(lèi)型。更多關(guān)于div-o的細(xì)節(jié)，讀者查閱RFC8946的第五章節(jié)關(guān)于div-o的使用。

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

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

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

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

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

　　["vcard"，

　　[

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

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

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

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

　　]

　　]

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

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

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

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

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

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

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

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

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

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

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

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

　　雖然運(yùn)營(yíng)商都在努力部署和支持SHAKEN，但是，打通整個(gè)運(yùn)營(yíng)商的呼叫數(shù)據(jù)仍然需要更高層級(jí)的運(yùn)營(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設(shè)計(jì)的一個(gè)呼叫回溯的組織。目前，其會(huì)員數(shù)量達(dá)到30多個(gè)，會(huì)員基本上都是美國(guó)比較主流的運(yùn)營(yíng)商，這樣可以杜絕大家互相扯皮，踢皮球。Traceback 是一種跟蹤回溯機(jī)制，通過(guò)約定的策略和機(jī)制來(lái)保證呼叫身份的正常和狀態(tài)更新。Traceback根據(jù)認(rèn)定的呼叫身份進(jìn)行互聯(lián)互通和響應(yīng)反饋。關(guān)于 ITG 的POLICIES AND PROCEDURES的細(xì)節(jié)讀者可以查看參考鏈接中的PDF文件。

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

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

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

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

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

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

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

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