RCD富呼叫数据/部署SHAKEN的技术挑战以及CHAKEN-国内主叫用户可信身份鉴别技术规范

　　语音呼叫仍然是目前运营商和企业业务必不可少的营销手段。从获利角度讲，其业务收益虽然在运营商的收入占比中呈下降趋势，但是收入仍然比较可观。因此，无论是运营商还是企业客户都一直对其业务中的灰色地带-骚扰电话/语音营销，或者批量呼叫业务没有完全放弃。随着STIR/SHAKEN的呼叫身份验证技术的不断推进，和FCC的强制要求，其业务量也开始迅速萎缩。运营商的营收也面临巨大压力。如何对语音业务进行升级或者突破，是运营商面临的一个非常大的挑战。最近，一些比较大的国外的运营商正在尝试在呼叫身份验证基础上开发的新业务模式-rich call data或者中文翻译为富呼叫数据。简单来说，企业用户呼出时，通过身份验证的呼叫会携带呼叫方号码，呼叫方地址和公司logo等信息，被呼叫方手机终端会显示企业完整的呼叫身份。通过富呼叫数据提供的增值服务，运营商和企业客户获得了双赢的局面，也避免了传统运营商语音业务的萎缩的态势。Rich call data的技术实现流程相对比较复杂，其处理流程涵盖了多个技术节点和第三方的数据管理等问题。为了让读者全面了解需要的技术支撑，现在，笔者具体介绍关于rich call data或者富呼叫数据的实现流程，rfc7095，PASSporT以及在运营商SBC等处理的相关技术。另外，笔者增加了更多关于呼叫身份确认技术STIR/SHAKEN的实现所面临的各种技术和商业方面的挑战，包括如何实现SIP呼叫转移到传统PSTN的支持，如何通过SBC实现身份验证，以及呼叫身份过滤以后的对用户的更新过滤和sip div 头中使用转移标识和PASSporT 令牌以及绑定的呼叫号码的细节，最后，笔者还补充了马上在国内要执行的关于信息安全技术 基于密码令牌的主叫用户可信身份鉴别技术规范意见稿。还有，此章节内容也是笔者系列文章-SIP协议及新IP企业通信网络技术概论中针对运营商方面的一个最新的补充内容，此文章作为概论的结尾章节。

　　关于SIP协议及新IP企业通信网络技术概论其他章节内容，笔者可以参考最新历史文档和最早的文档，例如：

　　SIP协议及新IP企业通信网络技术概论-SIP网络中完整NAT问题和处理方式和SBC在IMS网络虚拟化NFV中部署讨论分享

　　SIP协议及新IP企业通信网络技术概论-核心SIP技术介绍-1

　　因为此文章章节比较多，多个章节还有一定的关联关系，笔者专门单独列出每个重点章节结合图例做针对性地深入讨论。本文章主要讨论的内容如下：

　　1.关于RCD-rich call data背景介绍

　　2.关于rich call data相关基本介绍

　　3.关于RCD实现方式的讨论

　　4.关于实现STIR/SHAKEN所面临的各种挑战

　　5.关于STIR/SHAKEN技术针对呼叫转移和非IP网络的技术挑战

　　6.关于SIP invite中的div和div-o头处理细节

　　7.关于呼叫身份的后处理问题讨论

　　8.利用呼叫分析引擎技术来过滤骚扰电话

　　9.构建骚扰电话协同处理机制来解决呼叫身份验证问题

　　10.国内关于呼叫身份验证的推动进程

　　在我们日常生活中，我们经常会陌生人打来的电话。一些是客户的咨询电话，一些可能是其他教育机构，金融中介等的电话。这些电话一部分是真正的用户或者其他客户的电话，有一部分是骚扰电话或者骗子打来的电话。陌生人的电话到底是接还是不接？ 如果漏接了客户的电话，担心自己错过一个亿的生意。接的话，这些电话有可能是营销电话或者骗子的电话，浪费时间。

　　此图例以及以下部分讨论来自于互联网资源

　　骚扰电话作为世界性难题，其他国家也面临这些问题。人们已经不再接听未知的呼叫。一些呼叫中心或者金融机构的客服系统产生了大量的垃圾呼叫，接通率逐年下降，呼叫中心效率大大折扣。根据福布斯引用Hiya 2020年呼叫报告，大约94%的未确认身份的呼叫最后成为未接听的呼叫。另外，First Orion的数据表明，90%的比较可靠的呼叫是带标识的呼叫。另外，根据businesswire的报道，美国几大运营商-Verizon， T-Mobile， CTIA and iconectiv在SIPNOC 2022的大会上，针对任何提高Call Answer Rates，恢复消费者信心对部署RCD也做了分享研究。大概73%的行业领导者公司正在评估和考虑使用集中式的数据服务整合STIR/SHAKEN和RCD来降低用户的损失，增加对机器人骚扰电话的过滤作用。目前，美国的一些运营商已经开始强制要求支持STIR/SHAKEN技术，并且运营商也正在积极推动RCD的技术应用，通过呼叫身份识别来进一步加强用户接听电话的安全体验。关于STRI/SHAKEN 骚扰电话的技术实现方式，笔者在历史文档中

　　解决骚扰电话问题，道路是曲折的，前途是光明的-关于电话呼叫方身份验证规范和STIR/SHAKEN骚扰加密技术的再讨论 都做了非常详细的分享说明。

　　对于RCD内容，我们需要进一步补充。让我们大概了解RCD其概念原理。RCD是目前比较好的办法，通过RCD就会更加方便地让被呼叫方能够识别呼叫方的公司标识，呼叫原因等相关的数据，这样的话，被呼叫方也能够明确所接听的目的， 被呼叫方可以根据其验证的信息决定是否接听。

　　用户渴望能够显示更多呼叫方丰富信息的支持。RCD（rich call data）就显得比较重要了，它也是当前呼叫业务的一个的必然选择。我们以前传统的号码显示是通过运营商的CNAM或者其他增值服务来实现，为呼叫方推送和号码相关的一些数据，但是，其数据往往缺乏实时性和准确性。因为骚扰电话的不断增加，被呼叫方的诉求是当呼叫接听时，被呼叫方手机端应该显示准确的呼叫方信息，包括公司信息，呼叫原因等。因此，和以前的CNAM号码服务方式比较，对被呼叫方来说，显然，rich call data增加了很多的实用性。其基本概念也非常简单，rich call data 利用了SHAKEN的呼叫技术，通过呼叫验证，然后对此呼叫添加了部分呼叫号码的属性参数，最后为被呼叫方提供显示呼叫方富数据属性数据。最终，被呼叫方手机终端显示了一些必要的富呼叫数据，例如，公司名称，呼叫原因，公司logo，公司地址，验证状态等必要的富呼叫数据。在以下的示例中，支持了富呼叫数据的呼叫在被呼叫方的手机终端会显示其响应的必要数据。 以下示例也展示了手机端显示的必要信息，帮助被呼叫方判断是否接听此呼叫。

　　RCD的基本的业务处理方式如下：

　　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的五章节的关于PASSporT Claim "rcd" Definition and Usage。这里不再做过多介绍，在此文章的后续部分读者会进一步涉及此内容。

　　以下示例中，我们可以看到，发起呼叫时就带了有效的身份验证的Identity。这里的示例仅说明了呼叫服务发起时带的一个有效身份验证。当然，我们后续还要介绍如何处理更加复杂的非法验证的处理。

　　在发起呼叫时携带的有效的身份验证头

　　在一般的企业支持的RCD呼叫中，大概经过七个步骤。首先，企业呼叫方对自己运营商进行呼叫，运营商查询自己的STIR/SHAKEN 服务数据中心或者第三方的数据中心，然后转发呼叫，返回302临时消息，并且携带RCD数据。运营商收到STIR/SHAKEN服务中心的数据以后，继续对运营商B进行呼叫。接下来，运营商B继续对已签名的呼叫结合RCD数据再次验证，运营商收到返回的已验证的RCD，最后呼叫终端用户。终端用户数据端显示公司C的所有RCD信息。以下是一个典型的企业呼叫使用了RCD业务以后的处理流程示例。

　　我们通过基本的概念介绍和处理流程的说明，读者应该基本了解了其主要的处理步骤。接下来，我们会根据其每个环节的具体细节，为读者说明如何实现RCD的处理。

　　关于RCD实现方式的讨论

　　如果要实现企业用户的RCD数据，运营商或者用户首先需要输入或者通过应用程序添加用户的相关的信息，包括地址，公司名称，JSON card的URL地址等等相关的信息。这些信息可以根据运营商针对STIR/SHAKEN服务部署的策略存储到STIR/SHAKEN服务中。

　　企业用户呼叫到运营商以后，运营商SBC需要转发呼叫，通过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链接等。这些数据需要在运营商对被呼叫方发送呼叫前都要分别执行验证服务，然后支撑发送到被呼叫方。这里的呼叫认证ppt中支持了两个类型，一个是SHAKEN类型，另外一个是RCD类型。具体的身份信息格式如下：

　　Identity： sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9

　　dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt

　　w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=；

　　info=；alg=ES256；

　　ppt="rcd"

　　在以下的验证中，运营商会对SHAKEN服务中心查询SHAKEN和RCD的身份，包括x5u， logo链接，呼叫方运营商，目的地运营商等数据。在运营商B对被呼叫方执行最终呼叫时，同时携带了SHAKEN，RCD和身份头。

　　除了通过RCD显示呼叫方用户呼叫数据的方式以外，笔者也在以前的文章中讨论过关于新呼叫业务的支持。是否可以通过VoNR新通话技术利用数据通道实现其数据的展示？这可能也是未来在VoNR上叠加的功能。

　　对最新5G网络中VoNR新通话技术白皮书的思考和关于SIP/IMS网络/4G-VoLTEG和5G-VoNR中的业务和技术全面解读

　　如果运营商想实现RCD和呼叫身份验证的支持，首先从技术角度来说需要集成或者支持很多的服务。这些服务基本上需要运营商方面努力推动，包括部署新的服务，重新建构呼叫流程设置。这些对运营商来说可能都不是太大的问题。根据一份权威的市场调研报告来看，截止到2022年最近日期，目前用户收到的呼叫绝大部分仍然是未进行SHAKEN认证的呼叫：

　　但是，同时运营商也正在逐渐增加对SHAKEN的支持：

　　实现SHAKEN技术部署的其中一个比较关注的问题是如何实现终端的显示是运营商可能面对的极大挑战。这里可能涉及到了手机操作系统平台的介入问题。实际上，企业客户想显示更多关于呼叫方的信息，方便企业的营销。但是，手机终端操作系统平台可能会过滤或者屏蔽某些信息，这可能影响设计制造商的业务收益。可能运营商会支付一定的费用还是企业客户支付使用，只能作为我们讨论业务方面的话题，也是RCD业务面临的一个比较大的风险。

　　另外一个风险是运营商是否有意愿更换当前比较老旧的传统的PSTN设备。这些设备不能支持网络接口，也不能实现数据集成。传统的PSTN网络环境中，硬件设备已经相当老旧，如果需要支持STIR/SHAKEN只能更新其设备，从传统的PSTN设备更新为支持STIR/SHAKEN的接入网关设备。另外，一般的传统PSTN网络环境中缺乏对数据中心处理的支持，这些呼叫号码如何集成仍然是一个问题，还有各种SIP网络中SIP消息的兼容性支持，例如一些SIP呼叫中的P-Asserted-Identity的处理。另外，一些欧洲国家已经目前截止到2025年，语音网络将全部升级为纯IP网络，而且需要实现STIR/SHAKEN的支持。运营商的固有的TDM网络如何实现对STIR/SHAKEN升级，这也仍然是欧洲很多运营商面临的严峻调整。为了实现其更换目标，运营商只能通过IP化改造来完成STIR/SHAKEN的服务支持。以下示例是一个关于TDM进行IP化改造以后对STIR/SHAKEN的支持。以下示例中，通过带外STIR支持方式，实现STIR/SHAKEN服务。

　　在以上示例中，在现有的TDM网络环境中，一般情况下，终端首先对运营商的TDM交换机进行呼叫，然后通过PSTN网络路由到另外一个目的地运营商的TDM交换机，最后呼叫对端终端。但是，如果实现IP化的STIR/SHAKEN支持的话，传统的TDM交换机在呼叫PSTN网络前，TDM交换机增加了一个TDM-SIP网关的STIR/SHAKEN服务支持。首先需要通过一个TDM-SIP网关的呼叫处理，TDM-SIP支持了STIR/SHAKEN服务以后，POST PASSporT进行查询数据库，返回结果以后，再对PSTN网络进行呼叫。呼叫抵达对端以后，TDM交换机同样需要进行TDM-SIP网关的STIR/SHAKEN查询支持，通过扩展出来的TDM-SIP网关执行STIR/SHAKEN查询，返回查询结果和验证结果后，决定对此呼叫进行继续转发还是过滤。关于传统TDM交换机实现对STIR/SHAKEN支持的规范细节，读者可以参考RFC8816以及RFC8224。在此规范中，罗列了5种关于实现TDM网络支持STIR/SHAKEN的用户场景，包括了：

　　1.VoIP to PSTN Call

　　2.两个智能终端的呼叫

　　3.PSTN to VoIP Call

　　4.网关带外处理

　　5.企业呼叫中心

　　此规范中介绍了关于PASSporT的存储和获取的处理流程以及Call Placement Service (CPS)数据库的处理机制。其实现流程细节如下：

　　前面我们介绍了关于传统TDM交换机支持STIR/SHAKEN的实现方式。在当前的网络环境中，基于IP语音的交换方式已经在现代企业通信环境中起到了绝对的支撑作用。因此，在传统PSTN线路运营到IP语音交换的呼叫路径上或者IP呼叫的话，需要通过另外一种处理方式来实现关于PASSporT的验证处理。为了实现PASSporT的验证处理，需要在运营商的SBC实现PASSporT支持。这里我们可以看到，呼叫发起以后，首先需要通过运营商的STIR/SHAKEN 服务对呼叫进行认证服务，此呼叫支持了签名支持以后，运营商通过运营商自己的SBC对CPS服务数据库发送PASSporT。然后此呼叫被发送到PSTN网络。在对端运营商接收到呼叫以后，对端运营商的SBC首先需要获取此呼叫的PASSporT，然后运营商对带PASSporT的这个呼叫进行STIR/SHAKEN 验证服务。获取到验证的呼叫以后，运营商根据验证结果决定是否把这个呼叫发送到目的地终端客户。

　　综上所述，结合目前网络的推进速度，从以上网络架构来看，运营商现在不仅仅面临继续对5G或者6G网络的投资，如果想实现对STIR/SHAKEN支持的话，还要对传统PSTN网络投入SBC，增加其验证流程。所以，很多运营商可能也正在观望中，没有太多动力推动来推动此业务的升级。

　　在以上的章节中，笔者介绍了关于PSTN网络和IP网络环境中针对STIR/SHAKEN的业务支持的解决方案分享。但是，在具体的业务场景中，关于呼叫身份的验证仍然具有很多挑战，例如呼叫转移以后的呼叫身份验证问题。用户可以想象一下，假设，一个号码呼出以后，到对方接听以后，然后发起了一个呼叫转移，呼叫转移以后，号码身份状态就会随之发生变化。如果没有完整更新其呼叫身份的话，那么最终用户可能看到的是一个未进行呼叫身份验证的呼叫。这样的话，整个呼叫身份验证流程就会失败。如何跟踪此呼叫的路径中完整的身份状态是一个需要面对的挑战。在IP或者SIP网络环境中，转移的呼叫一般称之为diverted的呼叫。具体的支持策略是，通过在SHAKEN中增加一个扩展支持- “div” PASSporT。通过九个步骤的流程处理来实现全程呼叫转移的身份验证跟踪。

　　在以上处理流程中， 对于呼叫转移的号码进行了完整的验证和跟踪处理。具体流程已经在图例中进行了标识。在整个呼叫流程的处理过程中，读者需要注意的是在TN-b 对呼叫进行转移处理时，在INVITE中包含了另外一个身份，此身份的div中添加了orig/dest/div 三个参数， 它们分别是a/c和b。呼叫接收方然后再次转发此呼叫到最终呼叫目的地。在最终呼叫目的地仍然需要进行STIR/SHAKEN的三方验证服务，检查其关联性，然后对最终目的地呼叫方返回验证的INVITE。最终呼叫目的地运营商最后对TN-c 发起呼叫。从以上对呼叫转移的处理中，我们可以看到一个div头， 此div header是SIP协议的一个扩展，它支持了PASSporT来验证其身份状态。在下面的章节中，笔者进一步为读者介绍一些关于div PASSporT的细节内容。

　　在讨论Call Diversion时，笔者必须首先说明几个主要的关于呼叫业务的概念和区别，避免让读者迷糊。从笼统的或者比较宽泛的概念中，呼叫转移可能存在以下几个方面的解释，它们有着非常大的区别。笔者对部分内容进行了标识，和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 呼叫业务的支持等。笔者将在未来的文章中对其处理过程进行深入讨论。以下示例是一个完整的关于经过呼叫转移的SIP INITE携带两个ldentity，分别支持了不同的ppt 类型，一个是SHAKEN，另外一个就是呼叫转移的div 扩展。

 

　　针对SHAKE和div的PASSporT的token 令牌分别是：

 

　　在保护头中包含了身份证明信息，例如ppt类型，证书路径等。在payload中包括了呼叫运营商，呼叫初始号码，转接号码和最终目的地号码等。关于div的PASSporT令牌的规范说明，读者可以参考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网络中的技术处理策略。在以下图例中，如果发送呼叫转移的话，呼叫转移的网络在新的身份中支持了PASSporT-div-o， 并且包含了一个opt（

　　Original PASSporT）要素。

 

　　读者一定要注意这里的INVITE 呼叫所包含的身份信息。在div-o 的PASSpoorT中，它包含了一个opt 要素， 并且在opt中还包含了一个原始的SHAKEN PASSporT的完整拷贝，而不是在SIP INVITE中包含多个身份的方式。在前面的示例中，INVITE中包含了两个身份。这是呼叫转移到IP网络和非IP网络（PSTN）它们之间的根本区别。 在实现呼叫转移到非IP网络或者PSTN网络的验证中，这个流程处理大概经过11个主要步骤。这个新的PASSporT存储到CPS服务数据库，并且将会通过CPS 数据库进行验证。最终呼叫目的地的PSTN网络将根据从SHAKEN获得的服务验证，然后转移此呼叫到最终目的地号码。另外，其身份中的PPT类型也发生了变化，ppt现在是div-o， 而不是以前的div类型。更多关于div-o的细节，读者查阅RFC8946的第五章节关于div-o的使用。

　　除了运营商通过本身的SHAKEN验证中心来验证呼叫身份以外，运营商也可以以第三方分析引擎结合SHAKEN来实现呼叫身份的验证。呼叫分析引擎具体实现方式如下：

　　企业用户或者其他终端用户需要呼叫到运营商SBC端，如果非法侵入的用户可能无有效的PASSporT。呼叫发送到运营商的SBC端，然后SBC呼叫发起一个INVITE携带PASSporT，通过分析引擎验证以后，最后符合呼叫的身份，如果是一个非法呼叫或者被标识了无效的PASSporT是无法通过其认证的。分析引擎可以通过SHAKEN服务访问以及汇聚第三方其他数据来集中进行判断分析。

　　前面我们花费了很多精力讨论如何实现呼叫身份的确认以及其呼叫转移后的SHAKEN处理。运营商通过在呼叫路径中不同的技术手段实现了其呼叫身份的验证。成功验证的呼叫当然可以顺利抵达呼叫终端。但是，我们也可能会经常遇到未成功认证的呼叫身份。未认证成功的呼叫可能就被运营商过滤掉了。如何处理过滤掉的呼叫，或者如何让呼叫方获悉其呼叫已经被过滤，过滤的原因等等。FCC对其处理有一个规定，要求运营商过滤掉呼叫以后，必须对呼叫方返回过滤提示，推荐使用的SIP错误码为607和608. 在过滤解封的处理流程中，呼叫分析引擎通过和SHAKEN集成，支持了vcard来获取完整的过滤原因和联系方式等信息。

　　如果集成了传统网络的话，返回了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。

　　构建骚扰电话协同处理机制来解决呼叫身份验证问题

　　通过笔者的一系列介绍中我们可以看出，技术手段的实现都最终需要运营商落实。其实，最终要杜绝或者消灭骚扰电话的话，从国家层面或者国际合作的层面才能解决这个问题。目前可以看到的美国运营商已经开始行动了，对运营商强制要求执行。美国国会议员已经正式提交了关于机器人骚扰电话滥用犯罪的法案-TRACED Act Implementation(Telephone Robocall Abuse Criminal Enforcement and Deterrence). 在此法案中明确规定运营商必须强制使用STIR/SHAKEN 呼叫身份认证工具，并且列出了实施路径和时间表。

　　FCC已经正式发布了网关接入的强制要求。美国本土运营商必须支持STIR/SHAKEN的呼叫认证服务， 国外运营商接入到美国本土网络时需要通过FCC 数据库进行记录登记。

　　1.运营商和国外接入运营商必须支持STIR/SHAKEN身份验证服务

　　2.呼叫号码必须注册到FCC的 Robocall Mitigation Database (RMD)数据库。笔者前面提到过这个号码数据库。

　　3.必须执行相关的机器人骚扰电话呼叫的集成流程，包括全天候的呼叫跟踪响应，强制过滤非法呼叫，获知上游运营商呼叫号码的合法性，要求呼入网关减轻非法呼叫，部署SHAKEN呼叫认证服务。

　　在部署STIR/SHAKEN时，当然各种运营商和国际之间的运营商接入都会发生一定的变化。如何防范国际呼叫的骚扰电话和对其呼叫进行跟踪，如何让国际呼叫支持STIR/SHAKEN身份认证服务，这些都需要通过国际电信组织来完善，例如建立国际间的STIR/SHAKEN服务方式：

　　如果建立起了比较完善的STIR/SHAKEN 呼叫身份跟踪机制，支持STIR/SHAKEN的联盟之间就可以针对骚扰电话号码，以及为骚扰电话提供线路服务的运营商进行标识，根据其令牌和证书进行跟踪标识，对其服务进行评估，然后采取进一步的强制措施，包括通过公开的Robocall Mitigation Database 查询其运营商的服务水平和质量，倒逼运营商减少对骚扰电话服务支持。例如，从SHAKEN的认证信息中体现了完整的呼叫身份信息，从x5u中我们可以查询到证书签发机构，从origid中可以查询到骚扰电话的运营商认证信息。

　　读者也可以查询公开的FCC 关于Robocall Mitigation Database

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

　　另外，除了运营商需要继续努力来支持STIR/SHAKEN 呼叫认证服务以外，也可以通过手机平台对呼叫进行设置或者标识的支持来降低骚扰电话的问题。但是，电话已经接入到用户端，其用户已经受到骚扰，这种方式缺乏规范性，同时也对解决呼叫身份验证没有太大的帮助，只是一种被动防范的方式。

　　虽然运营商都在努力部署和支持SHAKEN，但是，打通整个运营商的呼叫数据仍然需要更高层级的运营商之间的协同。各种非法电话已经让FCC倍感压力。

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

　　Industry Traceback Group是FCC设计的一个呼叫回溯的组织。目前，其会员数量达到30多个，会员基本上都是美国比较主流的运营商，这样可以杜绝大家互相扯皮，踢皮球。Traceback 是一种跟踪回溯机制，通过约定的策略和机制来保证呼叫身份的正常和状态更新。Traceback根据认定的呼叫身份进行互联互通和响应反馈。关于 ITG 的POLICIES AND PROCEDURES的细节读者可以查看参考链接中的PDF文件。

　　前面笔者介绍了大量的关于SHAKEN的技术和具体在运营商之间部署的技术流程，包括了其他呼叫业务中所面临的技术问题，以及如何支持传统的PSTN网络的SHAKEN认证。其实，国内的推进速度也非常快。全国信息安全标准化技术委员会也根据SHAKEN的一些缺点，推动发布了基于SHAKEN的CHAKEN技术。由牵头单位中国科学院大学、参与单位中国电信集团有限公司和微位 （深圳）网络科技有限公司一起对本标准中的 CHAKEN 方案进行了试验验证，并且在2022年03月30日发布了关于关于国家标准《信息安全技术 基于密码令牌的主叫用户可信身份鉴别技术规范》征求意见稿征求意见的通知。其实现架构如下：

　　读者有兴趣的话，可以查阅此意见稿，通过参考链接下载关于信息安全技术 基于密码令牌的主叫用户可 信身份鉴别技术规范。

　　其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所面临的挑战和目前国内即将执行的CHAKEN技术以及基于密码令牌的主叫用户可 信身份鉴别技术规范。RCD是运营商业务的新的服务突破点，它会给用户带来很多更好的呼叫业务体验。通过SHAKEN技术实现呼叫身份验证，帮助用户杜绝骚扰电话和骗子电话，以及各种非法呼叫。目前，国内的骚扰电话也非常猖狂，运营商貌似也无可奈何。

　　通过CHAKEN技术从呼叫源头对呼叫进行身份跟踪，能够极大降低骚扰电话的发生。

　　在针对SHAKEN的部署环节中，笔者主要深入讨论了如何实现PSTN网络对SHAKEN身份的支持，通过SHAKEN和SBC，以及呼叫分析引擎对呼叫进行全程跟踪，同时笔者又对呼叫业务中呼叫转移的技术实现进行了详解，帮助读者进一步深入了解呼叫转移的流程和对每个节点的SHAKEN的支持，查询等。

　　另外，部署执行FCC的SHAKEN技术，需要各个运营商或者全世界的运营商共同构建一个SHAKEN的联盟，通过SHAKEN来跟踪不同国家，不同运营商的呼叫，同时能够实现实时协同来提高SHAKEN服务的效率。

　　国内即将部署的CHAKEN可能也会面对美国运营商所面临的技术问题和运营商之间，呼叫业务，运营商不同网络之间的协同的问题，我们希望国内的CHAKEN技术能够更加完善，快速推向市场，提高用户对呼叫业务的体验。

　　说明，我们讨论的RCD，SHAKEN技术以及CHAKEN技术都是正在更新的技术，文章中的一些规范或者技术实现方式可能会不断更新。另外，笔者水平有限。因此，文章中难免会存在很多错误，望谅解！关于此方面的技术最新的技术动态，关注笔者公众号。