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的处理做更多测试和关注。
以上笔者分享的关于RFC8760更新对SIP应用场景的影响仅是对这种更新做的一点点初探，针对其最新版本的理解可能有误，用户可以进一步根据自己的应用场景以及未来在用户终端和服务器端兼容性方面进行升级测试以后才能发现更多更有价值的思考。
参考资料：
- https://datatracker.ietf.org/doc/html/rfc8760
- www.dinstar.cn
- www.asterisk.org.cn
