SIP协议已经使用了几十年，安全加密的框架来自于HTTP。SIP协议初期的关于认证加密的规范是RFC-2617, 包括一直更新支持的RFC7235，RFC7615，RFC7616和比较近的RFC7617。在1991年，Ronald Rives设计了了MD5，基于MD4基础上改进的算法，基于当时的计算机处理器的计算能力，MD5算法相对来说是最安全的。随着计算机处理能力的不断加强和各种破解工具的改进，MD5的安全问题越来越多，MD5不再是一个安全的算法。自从前几年爆出安全算法漏洞以来，人们确实发现以前MD5已经不再作为一个非常安全的加密算法，开始发展使用了比较新的算法SHA-256和SHA-512/256，支持了更强大的256-bit证书签名。

        RFC7216规范在2015年发布以后，正式支持了以上两种算法，并且兼容了MD5算法。这样的话，现在在安全算法加密方面，事实上，SIP技术架构层面需要同时支持三种算法（MD5/SHA-256和SHA-512/256）。另外，最近SIP协议规范RFC3261明确规定需要支持RFC8760。因此，在SIP安全加密中涉及了更多需要更新的处理流程。这些处理流程影响了SIP 服务器端，SIP代理服务器和SIP终端等关于认证加密的处理。

        在过去的基于SIP安全架构的处理中，比较简单的办法就是WWW-Authenticate header使用MD5来进行加密处理，SIP客户端和SIP服务器端都相互发送一个WWW-Authenticate 头来进行加密处理解析。如果SIP呼叫需要经过SIP代理服务器的话，代理服务器一般仅做简单处理或者透传。随着SIP语音逐渐实现云部署和跨网络部署，特别是在SIP运营环境中，经过多个SIP代理做呼叫流程处理是非常普遍的场景。如果需要支持RFC8760的话，UAC和UAS的处理就变得相对比较复杂。针对SIP代理和B2BUA需要做更细节更复杂处理。但是，RFC3261实际上大部分规范内容是针对SIP proxy来说明的，B2BUA需要通过UAC/UAS之间的角色通过不同代理机状态分别进行处理。因此，在呼叫过程中，用户系统对B2BUA场景需要做更多的兼容性支持。

        现在，笔者接下来给大家介绍一下关于RFC8760中一些具体的需要关注的几个问题。在RFC8760（The Session Initiation Protocol (SIP) Digest Access Authentication Scheme）-2对UAS，UAC和forking呼叫分叉呼叫做了更新说明，大家特别需要关注的几点变化：

支持了qop参数，对UAS和UAC表示支持了多个SIP Authorization，WWW-Authenticate和Proxy- Authenticate 头支持，并且包括了处理顺序。对端需要按照qop顺序处理这些头。

        UAS可以支持对同一realm实现多个WWW-Authenticate头支持。如果发送多个头时，每个头必须有不同的安全算法（MD5/SHA-256和SHA-512/256其中之一），UAS端所推荐的必须首先发送。UAS可以使用多个realm 响应。这个规定有点麻烦。从技术角度可以实现，但是在实际环境中可能导致包头数据增加的可能性。在实际的SIP响应回复中，如果一个UAS支持至少两个响应的话，每个响应支持三种算法的话，那么，UAS至少最低支持6个WWW-Authenticate头消息。头包的数据量会非常大。

UAC应该首先处理一个realm中的每个WWW-Authenticate中的第一个到最后一个列表数值。此处理需要通过一定的数据库流程支持才能完整处理所有的WWW-Authenticate头值状态。UAC需要针对realm的每个后续请求发送一个认证头。

针对Proxy，请求被分叉处理以后，代理服务器需要负责聚合分发各种认证方式和加密设置响应处理。分叉处理代理收到下游代理的多个WWW-Authenticate和Proxy- Authenticate头的时候，如果这些WWW-Authenticate和 Proxy- Authenticate头在一个响应中时，分叉处理代理必须维持其原有状态，不能中任何修改。SIP代理聚合这些消息需要耗费大量的系统资源，这是一个新的影响性能瓶颈。

        以上这些在RFC8760中的更新基本上涵盖了规范中对SIP RFC3261更新的所有核心内容。笔者的理解可能有误，如果用户需要关注很多具体细节的话，可以直接参考RFC8760。

        笔者提醒用户，用户需要另外注意一些SIP代理的呼叫场景。在实际SIP proxy的应用场景中，绝大部分的呼叫是针对call transaction（事务状态）进行处理的。事务状态会影响很多的其他业务处理，笔者建议用户针对SIP代理服务器关于有状态呼叫和无状态呼叫，以及关于dialog的处理做更多测试和关注。