其实针对骚扰电话问题，不同很多国家花费了大量精力，不同国家采取不同方式来解决骚扰电话的问题。认知决定思维，思维决定手段和方法。有的国家靠政策来解决，经常出台各种政策来处理骚扰电话问题；有的国家试图通过法律和技术相结合的手段解决骚扰电话的问题。但是，从目前看，两种处理方式都是殊途同归，貌似实际效果都不理想，我们还要从长远看两种方式的最终结果。靠政策的方法处理骚扰电话，其灵活性很大，也带有一定的强制性，同时具有非常大的不确定性，笔者无从找出其规律，也没有借鉴意义。靠法律和技术手段通过一套规范来解决骚扰电话的问题的话，需要相关的技术手段和明确的规范来执行，我们可以通过这些技术规范来学习获得一定的经验和知识积累。下面，笔者针对美国FCC专门对骚扰电话的处理技术手段加以进一步的论述。在接下来的讨论中，笔者简单回顾关于骚扰电话的形成背景，针对骚扰电话出台的几个核心的规范，FCC强制要求运营商设备软件厂家执行的STIR/SHAKEN技术，关于STIR/SHAKEN的数据验证手段的局限性和未来可能需要的数据验证的几种方式。
关于骚扰电话的前世今生
骚扰电话对我们来说已经不是一个陌生的话题。在实际生活中，我们经常遭遇到各种莫名其妙的电话骚扰。我们知道，商业文明是推动人类社会进步的原动力之一。商业文明成就了契约，契约进一步规范了企业行为。商业也让某些人为了自己的利益，不顾及企业的行为。利益驱动和成熟的软件工具环境是骚扰电话出现的基本要素。一部分人为了所谓的“商业”或者非法利润，可以套取个人信息，非法使用这些信息，例如打骚扰电话进行营销，诈骗等行为。个人的商业目的导致了骚扰电话源源不断发生。另外，在传统的PSTN时代，运营商和各种服务提供商相对比较少，服务费用非常昂贵，呼叫追溯相对比较简单，骚扰电话业务还没有可发展的土壤和环境，随着开源VoIP或者SIP网络，以及云平台的兴起，骚扰电话的基础环境也逐渐形成，大量的公司可以利用开源的Asterisk或者FreeSWITCH平台开发各种呼叫软件，高盈利的欲望，宽松稳定成熟的网络服务资源和底层平台为其业务的发展提供了非常好的时机。
在绝大部分的网络骚扰电话中，SIP协议是核心的协议，通过修改或者转发不同的SIP呼叫号码或者URL等进行修改。为了解决SIP呼叫从何处来，到何处去的呼叫问题，针对SIP头和一些其他参数设置的规范约定。RFC4474规范是一个比较好的开始，对呼叫方进行了加密处理。但是，因为技术发展速度太快，呼叫路径节点复杂，和规范的局限性问题，此规范也是出师未捷身先死，厂家们对RFC4474支持没有真正部署使用。毕竟，当初的大环境和用户还没有意识到这些问题，法律部门也没有对其实施急迫性提出一个日程表，厂家的积极性也不会很高，所以RFC4474规范使用最终搁浅。骚扰电话问题依然存在，客户投诉越来越多，一些有识之士可能仍然不死心，又对RFC4474做了更新，发布了RFC4474bis 版本。基础不好，不断修补也是枉然。RFC4474bis非常短命，基本上没有经过正式的讨论就被废弃了。技术在不断发展，环境在不断演变，RFC4474的加密只能负责自己的呼叫实体，呼出以后，因为很多第三方平台支持了不同的安全策略，不同的呼叫控制机制，和对域名呼叫的管理，到其他第三方平台的身份认证仍然不能得到解决。终于，一些聪明的人找到了解决这些问题的办法，对呼叫认证支持PASSporT，在RFC4474bis的版本上，经过大概五年的不断讨论修正，2018年终于发布了最新的规范RFC8824的16版本. 使用了PASSporT基本上解决了呼叫方身份加密认证的问题。另外，一些其他的验证机制也帮助对呼叫进行验证，例如，增加了P-Asserted-Identity。听起来，好像这些技术手段可以帮助我们解决骚扰电话的技术问题。事实上，我们没有面对真正的业务困扰，困扰乎所有SIP网络的安全部署的四大天问出现了：
-
没有办法确认Caller ID是否有效？ 谁来决定呼叫号码是否有效？ 用户自己随意标识，或者通过数据中心集中处理，数据中心的权威性如何管理等问题。
-
谁插入的P-Asserted-Identity？ 插入P-Asserted-Identity的实体是谁？此实体身份状态如何？
-
插入的P-Asserted-Identity是否有效？ 插入的组织是否有效？
-
“好人”需要一个完整的解决方案来处理以上问题。正常呼叫用户和实体需要一个可回溯的完整的流程，身份验证和数据管理的跟踪解决方案。
更多内容，参考：https://mp.weixin.qq.com/s?__biz=MzA4NjU0NTIwNQ==&mid=2656452108&idx=1&sn=bd0143311145fce33c75c10e08c660b3&chksm=84659856b312114027c69a59a516fbc489571035e7558568759980f59e2ee30d30273f9d30f9&token=58711531&lang=zh_CN#rd