从多个应用环境和其部署优势来说，SBC是目前解决SIP安全问题最有效的手段。SBC作为一个网络边界安全控制手段，IPPBX部署在内网环境中，彻底将IPPBX的网络拓扑隐藏在内网环境中。这样就起到了安全的作用。因为SBC的部署，很多外网终端或者移动终端，如果需要呼叫内网的IPPBX时，SBC和下游的其他服务器就会对SIP用户进行身份确认。通常情况下，SIP呼叫使用了 Authentication Digest 的方式来进行身份认证。
笔者在以前的文章中多次介绍了SBC的作用和其应用场景，和关于SBC部署协议的文章，读者可以查阅。
目前使用SBC的场景很多，包括SIP trunk对接，远端外网SIP终端注册，呼叫，运营商之间的对接服务，IPPBX托管中心的SBC对接。因此，使用配置方式也有所不同，不同的配置需要不同的认证方式来实现。以下是几个典型的示例：
运营商SIP trunk对接企业SBC
托管IPPBX通过SBC对接外网企业电话终端
运营商之间SBC对接
微软365对接SBC
今天，我们针对外网呼叫环境中关于SBC和其他下游服务器的认证方式进行一个比较详细的分析，希望帮助读者能够彻底了解SBC配合IPPBX进行身份认证的流程机制，以便能够在SBC部署时能够及时排查问题。
在下面的示例中，我们可以看到外网远端用户呼叫SBC，然后呼叫到企业内网IPPBX的典型示例（用户可以下载免费FreeSBC在阿里云部署，并且配合IPPBX或者免费开源的freepbx实现外网注册功能）：
在以上示例中，SBC部署在企业网络的边界处，内网IPPBX实现应用功能。但是，还有一些企业内网的部署环境，因为业务控制复杂的原因，可能增加了代理服务器的处理，然后下挂多个IPPBX。
简单来说，在这种典型的外网呼叫的场景中，外网的SIP账号首先需要对SBC发起一个INVITE，然后双方通过Authentication Digest 认证确认。如果SBC通过了外网用户Alice的呼叫认证，则SBC继续对内网Proxy发送P-Asserted-Identity，然后IPPBX确认其身份以后，双方SIP分机创建呼叫流程。为了说明以上示例的流程，我们会分步介绍每个阶段使用的认证方式和SIP信令的处理。
1、Digest Authentication相关概念
在介绍整个SIP user authentication的处理机制之前，我们首先介绍几个和认证相关的概念。这些概念可以帮助读者能够快速了解认证的基础知识。SIP认证的方式场景有两种，一种是代理，转发服务或者注册服务器对UA的认证；另外一种是UA之间的互相认证。
我们文章中使用的是Digest Authentication的认证机制，这种机制相对比较简单，它基于HTTP的一种质疑/响应的模式。一方会对另一方发送质疑询问，另外一方则通过响应的方式来应答核实其身份。
研究人员QiQiu的研究生文章Digest Authentication Report有关于认证流程和SIP学习的文章的介绍，读者可以下载阅读：
Digest Authentication Report
https://www.site.uottawa.ca/~bob/gradstudents/DigestAuthenticationReport.pdf
Digest Authentication使用了MD5 hash算法对用户名称，密码，realm和Digest URL计算出一个哈希值，服务器端生成一个一次性的nonce，双方对比最终的reponse值确认其身份。因为篇幅和内容重点不同，我们这里仅简单介绍其背景基础知识，RFC2069给出了非常完整的示例，读者可以对其流程细节做进一步的了解。
关于如何计算这些哈希值，读者可以通过很多网络工具做计算，发布读者在实际场景中能够完整了解response的生成。示例是如何计算reponse值：
根据以上工具，在实际的SIP注册消息中也同样生成了和工具计算相同的值：
具体双方生成生成响应的处理流程，读者可以参考以下示例：
在Linux环境下，用户可以使用MD5的命令来生成响应消息内容，工具也非常简单易用：
在RFC2617中，为了增加安全认证的可靠性，支持了客户端生成的nonce和QoP。具体的实现方式如下：
Response = MD5（H1 : nonce : nonceCount : nonceClient : QoP : H2）
笔者不是安全方面的专家，如果读者想进一步学习关于SIP安全认证的相关话题，网络上有很多关于SIP Digest 认证的讨论和MD5安全分析，读者可以参考相关链接来进一步学习。
2、SIP呼叫/SBC/Proxy/IPPBX流程
通过上一个章节对SIP认证的基本介绍和其认证机制的讨论，读者应该可以理解基本的认证原理。接下来，我们会比较详细地结合实际的示例来进一步分析其细节过程。
这里提醒读者，以上示例仅说明了身份认证机制的流程，并没有包括我们具体讨论的具体的其他部署的服务，例如SBC，代理和IPPBX等SIP服务器。具体的环境中，我们将涉及SBC，代理和IPPBX，也可能仅包括SBC和IPPBX本身。
在以上的示例中，首先外网SIP终端需要对SBC发起一个INVITE请求，SBC回复407或者401对其终端进行核实认证。外网SIP呼叫通过SBC认证后，SBC对Proxy发送认证P-Asserted-Identity，如果通过则继续其他的流程，包括代理对终端的再次双方确认和IPPBX对分机的身份确认等流程。这里，因为篇幅的关系，我们重点介绍外网SIP呼叫中SBC的身份认证过程，SBC对代理或IPPBX的P-Asserted-Identity身份确认，代理对SIP分机的认证机制。其他步骤基本上重复了代理对分机的认证流程，所以不再做过多讨论。
接下来，我们就指定具体的关于外网SIP终端如何通过SBC呼叫内网IPPBX分机做一个详细介绍。大家知道，SBC是对呼叫方身份认证的第一道防线。首先呼叫方对SBC发送INVITE，SBC返回407 带nonce，仅支持本呼叫方，仅使用一次的验证nonce。呼叫方收到以后，返回ACK。紧接着，使用这个nonce结合用户名称和密码计算出response，SBC也同时计算出这个response。如果双方的resposne一致，说明呼叫方可以通过SBC的身份验证。下面的章节中，我们重点对外网呼叫SBC时的认证过程做一个讨论。
3、外网SIP呼叫SBC端身份认证
在上面的介绍中，我们知道外网SIP分机如果呼叫企业边界的SBC时，首先需要SBC对其身份进行核实认证。通过其身份认证机制，才能保证外网呼叫SBC是一个安全的呼叫，否则SBC不会允许外网的任何SIP终端呼叫内网的IPPBX，解决了内网的IPPBX的安全问题。现在，让我们看看外网SIP是如何一步步进行呼叫验证，最终完成外网SIP分机和SBC之间的身份确认流程的。
首先，外网SIP分机呼叫SBC，SBC返回一个407 响应。这里的响应消息中携带了SBC生成的nonce值，结合外网SIP的realm等参数计算的结果。读者一定要注意Proxy-Authenticate Digest中所包括对计算参数。
其次，外网SIP分机收到401或者407响应后，紧接着对SBC发送一个ACK，确认收到407响应。然后，SIP分机马上对SBC再次发送一个新的INVITE请求（注意下面示例中的Call-ID是完全不同的ID），这次的请求中携带了SIP分机所生成的所有验证的相关消息。这里，最重要的步骤是外网SIP分机根据SBC返回的nonce结合本地SIP账号信息，使用MD5计算出的response。在INVITE中发送了生成的response结果。
最后，笔者在下图中给出了SBC计算response的计算流程。在SBC边界控制器中，SBC根据407的生成的nonce, 结合上次收到的用户账号消息，计算出SBC本地生成的response（42ceXXXX），然后对比SIP分机INVITE中包含的response（42ceXXXXX）结果，如果两个结果是一样的，说明外网SIP终端的呼叫身份是安全的，可以认为是成功的验证，SBC则允许SIP呼叫通过SBC服务器端。
通过双方response的结果对比，SBC确认了这个外网SIP呼叫的安全性，因此，SBC可以允许这个INVITE呼叫继续进入到Proxy的节点上。
4、SBC到Proxy使用P-Asserted-Identity
根据上一节点介绍，SBC通过response的结果对比，确认了这个呼叫的身份，所以，SBC就会把这个请求继续转发到Proxy的处理中。这里笔者提醒读者，一般来说，SBC的下游服务器可能直接面对的是IPPBX或其他SIP服务器，因为业务的关系，这里的示例中增加了Proxy的处理，事实上，SBC也可以直接面对IPPBX应用服务器。
尽管大部分情况下，内网的Proxy对SBC的身份是信任的。但是，因为SBC是一个网络边界设备，所以，Proxy很多情况下也需要对SBC发送过来的呼叫进行二次确认。在SBC对Proxy的身份确认中，通常SBC会对Proxy发送一个P-Asserted-Identity header参数，表示其SIP呼叫是从SBC过来的，对这个呼叫携带一个新的数值，SBC已经对其进行了身份确认，其用户是可信任的，请求Proxy通过这个SIP呼叫的身份确认。Proxy看到是SBC过来的可信任的SIP呼叫，对比Proxy自己保存的AOR值，Proxy就会通过这个认证。
注意，这里的认证仅是Proxy对SBC的确认过程，并不能确认Proxy是绝对信任这个呼叫的，不是Proxy对外网SIP呼叫的认证。Proxy或者IPPBX还会继续对SIP呼叫进行认证。在后续的内容中，我们继续介绍Proxy对SIP呼叫的身份确认。
在前面的讨论中，我们涉及了P-Asserted-Identity，一般的SBC都支持通过P-Asserted-Identity认证的方式。具体的官方定义如下（RFC3255-9.1）：
The P-Asserted-Identity header field is used among trusted SIP entities （typically intermediaries） to carry the identity of the user sending a SIP message as it was verified by authentication.
https://www.ietf.org/rfc/rfc3325.txt
P-Asserted-Identity不是一个标准的SIP core规范，它是一个私有的RFC3325。但是大部分的SBC设备软件使用这个参数来确认SIP用户的安全认证。另外，在很多配置场景中，我们可能会看到另外一个配置参数p-preferred-identity，它和P-Asserted-Identity有一些区别，很多读者可能非常迷惑。关于两者之间的区别，读者可以查阅此链接：
http://www.sharetechnote.com/html/Handbook_IMS_SIP_Param_P_Prefered_Identity.html
以上两种headers其实都来自于IMS规范中的P-CSCF SIP headers， SBC为了获得很好的兼容性，当然也需要支持这些headers:
- P-Called-Party-ID Header
- P-Orig-CA Header
- P-Charging-Vector Header
- P-Charging-Function-Addresses Header
- P-Associated-URI Header
- P-Visited-Network-ID Header
- P-Access-Network-Info Header
- P-Preferred-Identity and P-Asserted-Identity Header
- P-Charge-Info Header
- P-Sig-Info Header
另外，关于P-Asserted-Identity的使用可以成为一个比较大的话题，很多技术论文专门对其使用场景有非常深入的讨论，笔者水平有限，不能非常完整地给出这方面权威的结论。如果读者有兴趣做深入研究，可以查阅此论文：
Updates to Asserted Identity in the Session Initiation Protocol （SIP）
https://tools.ietf.org/id/draft-ietf-sipping-update-pai-08.html#rfc.section.3.1
5、Proxy对SIP呼叫地址的再次验证
在以上的讨论中，SBC通过了Proxy的认证，确认其呼叫是可信任的。但是，很多情况下，因为SBC和外网SIP呼叫都处于外网的边界处，Proxy对外网进入到呼叫地址重新验证。Proxy再次对SIP终端回复407，重新验证。这次验证的流程和SBC对SIP验证的流程是一样的，需要根据双方生成的response来判断SIP呼叫身份。
6、IPPBX对外网SIP呼叫的身份认证
根据以上几个步骤的验证，现在身份验证流程可以继续进行到IPPBX的节点上了。在上面的介绍中，Proxy需要再次确认外网的地址身份，再次对外网的呼叫重新经过407认证以后，SIP终端通过了认证。接下来，Proxy才会继续对下游IPPBX发送INVITE请求，IPPBX可能根据自己本身的认证设置，再次对SIP呼叫进行407认证。所以，IPPBX需要重新对SIP终端结合本次呼叫，此用户通过生成的nonce，再次进行双方的response结果对比流程，重新执行一次在Proxy认证时的流程。
其逻辑流程和上面的基本一样，所以这里不再列出。以上示例仅简单说明最后一步流程的处理方式。双方通过了IPPBX端的认证。然后，IPPBX对双方终端创建呼叫连接，双方成功通话，到此，外网的SIP终端就可以和内网的SIP终端进行通话。一个完整的外网SIP呼叫通过SBC认证，IPPBX的认证的呼叫流程正式形成。
7、总结
在本次讨论中，笔者专门针对外网SIP呼叫SBC和内网IPPBX的呼叫流程做了比较详细地分析。首先，笔者介绍了SBC对SIP的407的认证机制和关于nonce和response，MD5的核实流程。然后，笔者再次介绍了SBC对内网Proxy通过P-Asserted-Identity头声明其用户身份的机制，并且简单介绍了关于P-CSCF SIP的几个核心概念。接下来，笔者介绍了Proxy和IPPBX对SIP分机呼叫的407认证流程，最后，笔者介绍了IPPBX到内网终端的呼叫创建。
读者可以看到，整个呼叫流程中，SBC扮演着核心身份认证的作用，它是SIP网络环境中第一道安全机制，因此需要用户特别注意。此外，因为环境配置的复杂性和外网用户的身份和地址等问题，需要经过多次验证才能完全保证外网呼叫的安全。
最后，SBC的配置场景很多，需要根据不同的场景做针对性的测试，因此，笔者仅说明了外网SIP呼叫的认证机制，其他方面的内容没有过多涉及，希望读者自己根据基本的机制做补充学习。当然，读者也可以下载我们合作伙伴FreeSBC的免费SBC系统，在阿里云部署，并且结合自己的IPPBX直接对接测试。
参考资料：
https://www.vocal.com/sip-2/sip-user-authentication/
https://arxiv.org/ftp/arxiv/papers/1209/1209.1075.pdf
https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication
https://github.com/miconda/md5ha1
https://allenluker.wordpress.com/2014/07/16/sip-digest-authentication-part-1-sip-registration-method/
https://www.sipsorcery.com/mainsite/Help/SIPPasswordSecurity
https://docs.telcobridges.com/tbwiki/FreeSBC:Remote_Workers
作者简介
朱利中（james.zhu）先生供职于深圳星昊通科技有限公司，从事技术市场推广工作。在Asterisk开源领域服务10年，在国外学习工作9年。先后任职于Digium亚太合作伙伴公司，OpenVOX，深圳鼎信通达有限公司。在2010年，朱利中和合作伙伴联合发起举办了第一届Asterisk中国官方大会，负责VOIP88 开源技术社区维护，并联合发布了Elastix中文版本，个人翻译发布了第一本FreePBX使用指南。 目前负责Sangoma 亚太地区的销售和市场推广工作。
作者简介
朱利中（james.zhu）先生供职于深圳星昊通科技有限公司，从事技术市场推广工作。在Asterisk开源领域服务10年，在国外学习工作9年。先后任职于Digium亚太合作伙伴公司，OpenVOX，深圳鼎信通达有限公司。在2010年，朱利中和合作伙伴联合发起举办了第一届Asterisk中国官方大会，负责VOIP88 开源技术社区维护，并联合发布了Elastix中文版本，个人翻译发布了第一本FreePBX使用指南。 目前负责Sangoma 亚太地区的销售和市场推广工作。
关注微信公众号：asterisk-cn，获得有价值的Asterisk行业分享
Asterisk freepbx 中文官方论坛：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技术文档： www.freepbx.org.cn
融合通信商业解决方案，协同解决方案首选产品：www.hiastar.com
Asterisk/FreePBX中国合作伙伴，官方qq技术分享群（3000千人）：589995817
Asterisk freepbx 中文官方论坛：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技术文档： www.freepbx.org.cn
融合通信商业解决方案，协同解决方案首选产品：www.hiastar.com
Asterisk/FreePBX中国合作伙伴，官方qq技术分享群（3000千人）：589995817
