开源SIP服务器Kamailio/OpenSIPS的三种信令负载均衡算法优化详解以及测试讨论和基于SBC信令语音均衡负载功能实现

Posted 2021-06-07 Asterisk开源派

稳定的SIP软交换或媒体服务器需要通过各种设置资源来保证其稳定性。为了实现SIP服务器端的稳定，让SIP服务器“均衡”分配其呼叫业务是一个非常必要的设置机制。关于SIP服务器的均衡负载和高可靠性通信系统的稳定性可以通过很多措施来保障，除了系统自身设计的稳定性以外，部署人员通过技术架构来分解系统的处理能力达到系统处理能力的均衡也是一种设计思路。

此图例及以下图例均来自于互联网资源

作为运营商级通信系统或者企业级的通信系统，OpenSIPS和Kamailio在市场上有很多的部署案例。它们可以作为媒体服务器的前端服务器实现很多的信令和会话路由功能。均衡负载是它们其中一个重要的功能。今天，笔者针对基于以上两种开源SIP软交换通过SIP信令方面的均衡负载以及其新的三种算法优化做一些分享。

大家可能知道，因为这些开源项目本身不是B2BUA，即使OpenSIPS的B2BUA模块也仅能实现基础的RTP媒体处理，这些开源的SIP服务器可以作为一个简单的SBC。因为它们缺乏媒体服务器的支持能力，需要借助第三方来构建RTP媒体处理能力来实现SBC的“部分功能”。但是，如果用户真正完全实现商业化部署仍然需要一个完整的SBC解决方案来，SBC还需要强大的媒体处理能力满足现在实时语音通信的要求。因此，SBC除了实现SIP呼叫信令本身的均衡负载，还要支持很多用户需要的通过语音质量分析QoS/MOS/PDD实现的智能语音路由功能。最终，一个完整的均衡负载机制，不仅仅支持对呼叫本身的均衡负载处理，而且结合RTP媒体语音智能路由才能实现一个全功能完整的基于SIP均衡负载解决方案。

笔者在以下章节中将重点介绍基于开源SIP服务器Kamailio/OpenSIPS的均衡负载的默认轮询算法和其局限性，并且分享研究人员发表的关于均衡负载三种新算法（Call-Join-Shortest-Queue，Transaction-Join-Shortest-Queue 和Transaction-Least-Work-Left ）的优缺点以及其测试结果分享，最后分享关于SBC均衡负载解决方案中使用SIP呼叫信令均衡负载结合语音分析智能路由的思路。

1

关于均衡负载的基本说明

这里，笔者首先介绍一些关于均衡负载的早期算法和一些基于业务层面的负载的说明，使读者能够了解其他后续章节的讨论。从一般意义来说，均衡负载主要是针对呼叫数量做均衡处理，确保呼叫发起方和呼叫接收方之间的呼叫能够通过不同负载服务器之间的资源平衡，保证平台负荷在一个合理的承受范围之内，维持呼叫和平台的稳定性。SIP均衡负载包括开源SIP软交换基本上使用以下四种均衡负载的处理方式：

• Hash 和 FNVHash-通过hash的静态处理方式对Call-ID进行存储，对新事务绑定的Call-ID进行计算然后进行均衡负载处理。早期的OpenSER采用的这种算法。
• Round Robin（轮询）-通过hash算法对呼叫进行均衡负载的话，很难保证同样数量的呼叫那个路由到相关的服务器端。轮询方式基本上可以实现对呼叫进行轮询路由的均衡处理。第一个呼叫路由到第一个服务器节点，第二个呼叫会路由到下一个节点服务器，上一个呼叫和下一个呼叫不会同时出现在同一服务器，基本上保证了负载的均衡处理。
• 峰值路由方式-此算法是一种静态的算法，根据系统资源和负载的设置策略，设定一个阀值，如果超过阀值则路由到其他的服务器。目前，OpenSIPS也可以实现类似的设置。
  
• Response-time Weighted Moving Average（RWMA），此算法和前面的处理方式完全不同，它是一种动态的算法。RWMA算法是根据服务器端收到的响应时间，然后根据平均响应时间进行加权处理，基本上保证每个服务器的负载均衡。
  

在实际应用场景中，SIP服务器的均衡负载可能需要承担更多的业务层面的均衡负载能力。SIP服务器均衡负载能力可以支持：

• 根据呼叫业务实现负载实现紧急呼叫，电话会议，视频会议还是一般呼叫的负载路由
• 根据媒体类型不同实现负载支持是否需要媒体转码，落地，根据QoS路由负载等
• 根据路由策略实现负载支持国际/国内，计费阀值，VIP线路，系统资源阀值等
  

基于以上业务层面的均衡负载的实践，关于基本的开源SIP服务器中均衡负载的概念和配置方式，读者可以参考：

在基于SIP服务器端使用均衡负载模块处理SIP请求时，一般用户都使用默认的服务器本身的模块来处理，也有一些非常专业的用户需要对服务器进行更多优化以达到更高的性能来满足业务需求。所以，他们可能对某些算法进行优化。在SIP均衡负载的处理中，均衡负载策略算法是一个非常核心的处理流程，它的算法是否能够应对非常灵活的处理环境是决定SIP服务器性能的一个重要指标。

开源SIP服务器Kamalio或者OpenSIPS的官方说明中，它们一般使用吞吐量来说明其执行性能，例如CPS等。除了CPS以外，响应时间也是非常重要的性能指标，响应时间也可以作为衡量性能的技术指标。运营商级客户对各种响应时间有专门的KPI指标考核参数。关于各种响应时间的讨论读者可以参考：

在关于吞吐量处理方面，除了数据库存储，系统物理资源和模块设置优化以外，均衡负载的算法也决定着吞吐量的指标。在接下来，笔者会根据一些研究人员针对开源SIP服务器的均衡负载算法的优化和改进对吞吐量和响应时间的测试结果做更多分享。

2

基于开源SIP软交换的均衡负载算法讨论

如果我们要讨论SIP呼叫的均衡负载，我们首先需要了解SIP呼叫的相关基本概念。读者可能都知道，SIP呼叫是基于会话处理流程的。一个整个完整的呼叫是通过INVITE发起，呼叫需要经过多种流程进行处理，包括认证签权，查询，更新定时器等，然后通过BYE来拆线，最后结束呼叫。在一个完整的正常呼叫中，INVITE事务和BYE事务是两个最重要的事务。另外，因为发起一个INVITE呼叫流程，其处理过程会占用上面所说的很多资源。因此，INVITE事务和BYE的事务类型所消耗的资源是完全不同的。在整个呼叫的资源占用比中，INVITE事务处理所需要的资源占比超过了70%,  BYE事务占比则很少。研究人员的基本原则是优化一个正常的SIP呼叫中的事务流程，主要针对INVITE事务和BYE事务处理的流程进行均衡负载优化。在具体的算法优化讨论中，一个SIP呼叫需要针对call，dialog，会话和事务等方面的优化处理。因此，SIP均衡负载算法优化的基本设计原则就是通过优化INVITE事务的处理流程，增加系统的吞吐量，并且尽可能地降低响应时间，以达到系统的最佳处理能力。必须说明，在讨论这些新的算法之前，读者必须对我们讨论的问题做基本了解，包括call，dialog，会话和事务概念等。如果读者需要了解更多关于call，dialog和Transaction的详解的话，可以参考以下文章：

针对SIP服务器的均衡负载策略或者算法来说，目前使用比较多的包括Round Robin-RR, Call-Join-Shortest-Queue（CJSQ），Transaction-Join-Shortest-Queue (TJSQ)和Transaction-Least-Work-Left (TLWL)。在以上算法中，第一种是kamailio和OpenSIPS默认支持的算法，以上后三种算法是Hongbo Jiang 针对Kamailio默认算法基础上中提出三种新的算法。这里补充说明，因为早期的Kamailio还是OpenSIPS，它们的均衡负载的处理机制基本上相同，因此，笔者在本文章的后续章节中不再区分Kamailio还是OpenSIPS环境下的LB均衡负载模块。

在针对开源SIP服务器的LB模块的优化方面，最近几年OpenSIPS做了相对比较多的优化和更新，增加了很多动态实时的处理流程，整体处理性能可能有比较大的提升。关于OpenSIPS最新的处理流程的介绍，建议读者参考以上链接或者参考官方文档。这里，我们主要针对Hongbo Jiang和IBM研究院研究人员针对均衡负载中算法策略的优化进行讨论。以下图例是研究人员的算法框架。

SIP服务器均衡负载算法架构

基于开源SIP软交换中，SIP均衡负载的四种算法的具体定义和各自的特点包括：

Round Robin-RR，按照轮询方式对新呼叫进行分配。Kamailio或OpenSIPS默认支持的轮询方式。笔者建议读者参考官方文档获得更多关于RR算法和使用方式的说明。

Call-Join-Shortest-Queue（CJSQ），记录跟踪所有呼叫（call或者session），分配所有呼叫到每个后台服务器，并且路由新呼叫到最少活动呼叫的节点服务器。此算法仅关注到了call或session级别的数据优化，它本身无法对一个呼叫的transaction 事务进行更多细节处理。

Transaction-Join-Shortest-Queue (TJSQ)，路由新呼叫到SIP服务器，并且此服务器目前具有最少活动事务（Transaction），而不是最少呼叫（call/session）。此算法就是对CJSQ算法的提升优化，通过对一个SIP呼叫的INVITE事务和BYE事务进行分解，结合各种呼叫变量进一步优化其均衡负载算法。它仍然有其缺点。因为INVITE事务进入状态机的处理流程和非INVITE事务进入状态机的流程的复杂程度不同，所以它们所消耗的资源也完全不同，缺乏对资源比例消耗的进一步控制和处理。关于事务处理的流程和非INVITE状态机等处理策略，读者参考RFC3261-17。

Transaction-Least-Work-Left (TLWL)，此算法路由新的SIP呼叫到一个服务器，此SIP服务器目前承担最小工作负载，此负载是基于相关事务交互成本计算的结果，通过此结果进行呼叫路由。此说法利用了INVITE事务比BYE事务处理成本相对比较高的基本原理，进行资源分配就是而来。在此研究报告中，INVITE事务和BYE事务之间的成本比例是1.75:1时, 这样会取得服务器性能的最佳峰值。以下是研究人员的技术架构实例图和相关系统软硬件配置。

测试环境配置

研究人员在2012年发布的论文中，使用开源压力测试工具SIPp和通过对开源SIP服务器OpenSER（Kamailio和OpenSIPS的早期版本）添加了三种算法功能，使用硬件设备，通过配置集群服务器方式针对四种均衡负载算法进行了针对SIP均衡负载吞吐量（CPS）和响应时间的测试。在其测试结果中，无论从SIP服务器的吞吐量，响应时间和相关网络，CPU资源消耗来说，TLWL的算法无疑是几种算法中的一种最佳的算法。

各种算法测试中的峰值吞吐量结果

各种算法中针对INVITE事务处理的平均响应时间结果

各种算法中针对BYE事务处理的平均响应时间结果

Abdullah Akbar也进行了同样的研究测试，他/她使用Kamailio对以上算法进行了测试对比试验。其基础平台使用Kamailio，并且对dispatcher 调度模块进行了修改，使用以上算法结合SIPp压力测试工具进行了测试。测试架构和其使用的硬件环境包括：

各种算法环境中的SIP服务器的吞吐量对比，TLWL结果最高。

各种算法环境下的BYE消息响应时间对比中，TLWL响应时间最低。

通过以上两个研究团队针对开源SIP软交换的测试结果来看，TLWL的均衡负载结果对比其他负载算法来说，整体测试性能是最好的。这里我们需要说明，虽然当时两个研究团队在测试部署时使用的环境包括硬件环境和今天相比已经有很大变化，网络环境和云计算的网络功能虚拟化也不断应用在SIP网络的场景中，很多集群部署的优化和网络优化可以帮助提升SIP均衡负载的处理能力，但是对SIP呼叫中的会话，事务等基本要素的优化确实为我们提供了非常有价值的参考，为大家提供了更多的关于SIP软交换性能处理的新的思路。关于三种算法的具体介绍和研究手段等论文细节，读者可以查看参考资料的说明。

不过，随着更多网络技术的不断发展，业务系统的需求和场景不断发生变化，在SIP均衡负载的各种方案中，越来越多的用户希望通过SBC来实现均衡负载来满足不同业务，灵活语音编码和逻辑处理的需求。在下一个章节，我们简单介绍如何通过SBC实现均衡负载，实现真正的商业场景的部署。

3

基于云计算和SBC的均衡负载扩展能力示例说明

在以上的讨论中，研究人员更多关注的是基于SIP 软交换信令级均衡负载的算法优化，也仅限于传统CTI环境和硬件网络环境。在现在实际应用场景中，无论是运营商级用户还是企业终端用户，大家都在考虑通过云计算和网络虚拟化的方式实现更多更灵活的分布式网络架构，并且需要满足用户更多终端和不同编码设备的支持。在基于SIP软交换的均衡负载的部署环境中，除了我们需要关心SIP软交换的吞吐量和响应时间以外，我们还要注册请求的均衡负载，安全加密处理，还要关注其他媒体方面的用户体验，例如语音质量，时延等问题。如果我们仅仅考虑基于SIP软交换信令点均衡负载的话，均衡负载的功能支持就会遇到很大限制，不能满足很多实时的业务场景。

比较幸运的是，云计算时代，很多技术已经弥补了以前的一些系统资源的制约，可以通过SD-WAN，网络功能虚拟化部署，云实例部署和弹性网络资源等方式来实现。具体关于针对SIP网络的技术架构的变革，读者可以阅读历史文章： 

SBC的核心功能之一就是实现SIP媒体服务器的均衡负载处理。一些SBC厂家的SBC均衡负载功能已经非常成熟。Ribbon/Sonus的SBC 均衡负载服务能力提供了非常专业的运营商级功能，可以通过SIP呼叫和DNS（参考RFC3263）服务方式实现均衡负载，并且它可以通过云平台的各种功能模块，实现SBC 均衡负载集群组。

在SBC均衡负载集群的处理方式中，除了针对CPS进行动态路由以外，它本身也可以实现灵活动态加载各个节点服务器，对所有节点SBC实例实现分布式部署响应，并且可以针对重新加入的INVITE或者注册请求路由到未使用的SBC节点。

除了针对SIP呼叫信令级的均衡负载的管理以外，SBC仍然需要针对媒体级的核心数据实时进行检测和管理，保证用户呼叫的语音质量达到最佳质量。通过SBC实现QoS/MOS的智能路由也是SBC部署时的一个特别需要考虑的问题。笔者以前针对QoS的策略管理有非常详细说明，读者可以阅读此文章：

在运营商级和高级的企业级SIP呼叫均衡负载的解决方案中，除了对CPS和响应时间进行管理以外，SBC的均衡负载功能还需要结合实时语音质量分析的参数来实现更完善的路由处理。SBC需要非常智能化地分析RTP语音流的修改数据，通过QoS这里保障，语音质量评价值和呼叫延迟，抖动等相关数据及时通知SBC路由模块，保障其均衡负载能力能够路由到一个资源消耗状态正常的媒体服务器上。如果缺乏以上分析数据的支持，均衡负载处理机制仍然会路由到一个语音质量差的呼叫节点上，最终用户呼叫体验肯定也非常差，降低了呼叫的成功率和呼叫体验。Ribbon SBC通过语音智能语音分析模块，结合实时数据统计面板对智能路由做了非常专业的实时管理，可以极大提高均衡负载以及智能路由的更强大的功能。PSX是核心的路由策略模块，可以支持本地路由，全球路由管理，trunk管理，安全保护数据，DID管理，分析软件依赖于大数据，AI和行为学习和机器学习来快速分析数据支持均衡负载能力。

4

总结

在本文章中，笔者首先介绍了关于均衡负载的基本要求和基于业务层面均衡负载的处理机制。开源SIP软交换Kamailio和OpenSIPS，包括早期的OpenSER在这方面也有着非常好的表现，它们可以作为SIP软交换的均衡负载服务器来使用。在传统的均衡负载的RR模块中，均衡负载仅针对呼叫或者会话来进行处理，没有再深入到呼叫事务的优化，特别是针对两个重要的INVITE事务和BYE事务的优化。一些研究人员针对两种事务进行了优化处理，并且提供了三种优化算法，通过不同优化算法，研究人员经过对吞吐量和响应时间的测试发现TLWL算法是执行性能最好的算法。这些新优化的算法为大家在未来的基于SIP服务器进行优化提供了非常有深度的技术模型。

但是，随着技术不断发展，用户需求不断增加，这些均衡负载的部署方式如果部署在目前商业环境的话，仍然缺乏很多其他业务方面的支持，仍然需要一些专业的SBC做均衡负载，以及均衡负载集群组来实现，并且需要结合用户迫切需要的实时语音检测机制进行更智能化路由。笔者在后续章节介绍了Ribbon SBC在建议SIP信令层面的均衡负载机制路由以外，和读者分享了基于RTP语音流的智能路由功能，通过QoS，MOS和PDD等比较重要的参数数值，通过语音分析模块实时对呼叫进行路由设置。

随着系统不断扩容，SIP服务器的均衡负载机制和算法也不断需要更新来满足最新的业务需求。其他的算法或者均衡负载机制也可能可以实现某种用户场景，比如，利用云平台技术，HAProxy或DNS SRV等相关技术来实现不同的需求均衡负载或者HA解决方案，因为篇幅关系，笔者没有涉及这方面的讨论。笔者希望从单纯的SIP技术方面，结合所讨论的这些结果对读者将来部署SIP均衡负载解决方案有所帮助，获得更稳定专业的均衡负载解决方案。

参考资料：

https://support.sonus.net/display/SBXDOC62/Load+Balancing+Service

www.rbbn.cn

www.hiastar.com

Hongbo Jiang，Design, Implementation, and Performance of A Load Balancer for SIP Server Clusters

Abdullah Akbar，A Comparative Study on Load Balancing Algorithms for SIP Servers

Georgios，Towards effective SIP load Balancing

https://datatracker.ietf.org/doc/html/rfc3263

https://www.opensips.org/Documentation/Tutorials-LoadBalancing

https://kamailio.org/docs/modules/4.3.x/modules/dispatcher.html