OpenSIPS学习笔记-dispatcher调度模块概要-失效呼叫处理逻辑及示例演示
说明：因为篇幅关系，笔者不能完全介绍负载均衡模块的全部内容，笔者仅通过重点内容和比较重点的问题加以说明。均衡负载的完整说明和其他笔者可能没有涉及到参数，如果读者有兴趣的话，可以参考官方的在线文档学习。另外，笔者的示例需要OpenSIPS的控制界面来配合实现，如果需要实际配置操作的话，读者需要安装OpenSIPS的配置控制界面。
具体安装方式，请参考：
最完整快速的安装方式安装开源OpenSIPS-3.1和CP控制界面-class 8
在接下来的其他部分章节中，笔者将介绍负载均衡的一些基本的概念，必要的语法和负载均衡关于资源处理的说明，负载均衡中目的地选择处理，负载均衡中选择逻辑处理详解，运行环境下使用命令来实时管理和拓展系统资源方式，前端是OpenSIPS的电话会议中使用负载均衡的挑战和解决方式，使用负载均衡模块的配置示例演示和总结。
1负载均衡模块的背景说明
负载均衡本身不是一个什么新鲜话题，在我们的实际生活中会经常遇到，从单一的个体和其他资源的合作到当前社会发展中资源整合都需要涉及负载均衡的问题。
平衡是为了更好地发展，发展是为了更好地平衡。
亚里士多德的子孙
如果具体到社会政治学的问题中，我们也可以看到负载均衡的实例。政治学之父马基雅维利在他研究的政治学中花费很多篇幅讨论关于各种政体利弊，他非常重视各种政体中各方面势力平衡的研究。另外，现代企业管理学的研究人员也都一直在探究平衡的问题。一些着名的管理学大师在讨论公司运营管理中经常会提醒大家-“一个公司如果只有一个技术核心或者管理核心是非常危险的事情。随着公司规模的扩大，如果没有其他技术核心来对所谓的灵魂人物加以平衡，这样的公司，其状态迟早会失衡”。因此，无论是何种实体，如何在可持续发展同时能够兼顾平衡是一个非常重要的话题。
此图片以及以下所有图例均来自于网络资源
同样，在我们讨论的具体大规模部署的VoIP应用环境中，负载均衡也是一个非常核心的问题。在部署企业通信应用中，特别是在运营层面，我们应该首先考虑到是如何保证用户数量增加和业务需求增加的同时，实现各种资源的整合和保证其基础平台的稳定。面对这样的挑战，在负载均衡时就需要要考虑增加各种资源来满足不断增加的需求。在OpenSIPS或者其他的商业平台，例如FreeSBC/ProSBC，负载可以支持很多资源的负载，因此负载均衡模块的处理，包括目的地处理是一个非常重要的话题。负载均衡可以根据远端媒体服务器的系统资源来决定负载均衡的策略管理，比较典型的就是一个根据QOS的处理来做负载均衡策略，或者其他业务功能的处理。
www.freesbc.cn
具体实现方式，参考：
语音质量好坏谁说了算？会话边界控制器-SBC-MOS告诉你
在OpenSIPS中，通过对LB的模块进行一定的配置，对目的地资源进行查询管理，最后再决定负载处理。这是一个相对比较非常复杂的过程，它不像调度模块那样，它仅对呼叫进行调度，本身其实不关心对目的地对端的能力。但是，在负载均衡中需要根据对端能力来进行负载的均衡处理。因此，相对于调度模块，LB模块需要结合对端资源进行均衡管理。
2LB负载均衡模块介绍
OpenSIPS的负载均衡模块是一个非常复杂的模块，官方对负载均衡模块有一个非常完整的配置说明，用户可以访问此地址来学习。
https://opensips.org/Documentation/Tutorials-LoadBalancing-1-9
本文档是根据官方的说明，通过自己本身的一些初浅了解，结合配置示例给用户演示一个负载均衡的使用场景以及其他应该注意到问题。因此，本章节以及以下章节的说明很多配置示例和官方文档基本相同，如果用户对完整文档有兴趣的话，可以忽略此文档，直接参考官方文档。这里，笔者仅重点强调几个主要的内容。在负载均衡模块中，主要包括了几个方面的内容：
负载均衡模块需要dialog模块的支持。关于dialog模块的作用，读者可以参考历史文档来做进一步了解。LB模块通过dialog模块对呼出的呼叫进行计数处理，记录数据通过dialog模块完成。如果没有dialog模块，LB模块无法对对端peer进行数据监控。
目的地/对端peers 通过它们各自的IP地址来定义。
目的地不一定是同一类型的地址属性，它们可以具备不同的支持能力，可以支持不同的服务和其他功能的支撑能力。
这里，读者一定要注意目的地的类型，它们根据不同的服务或者支撑能力其定义也相对比较宽泛。因为目的地可以基本电话会议能力，媒体转换能力，呼叫落地能力等不同的能力。LB根据不同能力来提供不同的负载管理。
3负载均衡模块的资源介绍
LB模块的资源是目的地能力，对端peer能力的一种支持能力。例如：
一组媒体服务器支持不同的呼叫服务类型
每个服务器可能提供不同服务的组合：
- 编码转换功能，通过媒体服务器能力实现编码转换，例如G.729 转G.711落地。
- 提供语音邮箱服务，媒体服务器可以对呼叫支持语音邮箱的转接功能，漏接电话转语音邮箱。用户稍晚时间再访问媒体服务器的邮箱获取对方语音留言
- 媒体服务器提供电话会议，实现各种会议室功能
- 语音播报功能，语音IVR服务，智能客服功能
- 媒体服务器通过PSTN落地，呼叫运营商PSTN
其实，以上媒体服务器提供的服务相对其他呼叫服务来说，都比较媒体服务器消耗资源，还有一些是受落地PSTN资源的影响或者限制。媒体服务器通过各种服务的组合来实现目的地负载平衡处理。在实际使用场景中，编码转换是媒体服务器负载相当大的一种服务，同时需要花费大量的CPU资源，无论通过软件编码转换还是通过硬件编码卡实现转换，都需要增加媒体服务器的部署成本。
研究人员-Varun C针对G.711转G.729编码的论文中完整介绍了其通过芯片支持的处理流程。读者有兴趣的话，可以参考其发表的论文：
Transcoding of Voice Codecs G.711 to G.729 and Vice-versa Implementation on FPGA
Varun C
具体实践中，通过开源媒体服务器实现Asterisk/FreeSWITCH的基于编码卡的编码能力支持。
另外，如果VMware通过虚拟化方式根据编码转换以后对语音质量的测试也非常有价值，其技术论文是：
Voice over IP （VoIP） Performance Evaluation on VMware vSphere 5
VMware
VMware平台针对编码转换和CPU相互关系的测试
因为媒体服务器的编码转换能力根据编码支持的不同，需要OpenSIPS提前对呼叫进行负载均衡处理，路由到另外一个媒体服务器。如果一些用户仅仅是语音呼叫，不做编码处理的，可以通过LB模块路由到无需编码处理的媒体服务器。媒体服务器的能力状态会实时上报到前端OpenSIPS。
4负载均衡的目的地
通过以上介绍，我们简单了解了媒体服务器的资源的限制问题。因此，在目的地组设置中就可能需要多种目的地的混合。通过LB组对各种负载均衡的场景进行路由管理。例如：
- 呼出和呼入LB模块的混合路由方式
- 通过0组包含所有呼入的PBX
- 过呼叫1组包含所有呼出的网关的路由组等方式
LB目的地组可以包括各种变化的组合，例如，在每个目的地组中可以定义提供不同的资源服务，对每个资源进行最大能力支持和最大负载， 通过SIP URL定义呼叫目的地和通过分组设置呼叫属性。负载均衡模块的目的地组可以设置最大并发呼叫设置来对负载进行均衡处理。例如，以下4个对端peers的能力支持可以设置为：
- 30 通道执行编码转换， 32 for PSTN GW
- 100 语音邮箱通道和 10 for transcoding
- 50 voicemail channels and 300 for conferencing
- 10 voicemail, 10 conference,10 transcoding and 32 PSTN GW
| ID | GROUP | SIP URI | RESOURCES |
| 1 | 1 | sip:10.0.0.11 | tran-30;pstr=32 |
| 2 | 1 | sip:10.0.0.12 | vm=100;tran=10 |
| 3 | 1 | sip:10.0.0.13 | vm=50;conf-300 |
| 4 | 1 | sip:10.0.0.14 | vm= 10;conf=10;tran=10;pstn=32 |
5LB模块的调用
如果使用OpenSIPS的LB模块，用户首先需要添加LB组，设置所要求的媒体资源。OpenSIPS可以根据提供的媒体资源的支持设置来检查其负载状态。实现检查的脚本也非常简单，示例如下：
# 1表示group_id
if （!load_balance（"1","transc;pstn"）） {
sl_send_reply（"500","Service full"）;
exit;
}
load_balance 将会对此组中的媒体服务器进行检查，如果有错误的话（可能编码能力不足，可能FXO/E1端口被占用，不能落地），返回错误消息。
6LB流程选择逻辑和lb资源处理讨论
在OpenSIPS的系统中，和调度模块有着非常大的不同，调度模块无需关心对端的处理能力是否可以支持当前的呼叫，dispatch模块直接会发生到目的地地址。但是，LB需要经过资源计数，最后找到一个平衡的最佳资源。具体来说，OpenSIPS目的地选择的逻辑需要经过以下4个步骤：
通过目的地组ID选择一个可用的对端peers
此目的地组中选择一个支持可用资源的peer。例如，如果一个呼叫需要编码的话，LB模块必须选择到可用的编码服务器
此目的地组的可用服务器中，找到当前每一个服务器的的负载状态，是否到达最大负载
从最小负载的媒体服务器选择一个均衡处理“最佳”媒体服务器资源
以上介绍相对比较难以理解，读者最好结合具体的选择算法来获取最佳的资源目的地。
在以上的示例中，通过执行以上脚本以后，资源选择的逻辑处理结果如下：
1因为脚本呼叫选择的是trans和PSTN，所以只能选择1和4服务器进行处理。
2重新评价呼叫以后的资源占用和剩余资源：
- 服务器1 ，编码占用10个通道，PSTN占用18个通道
- 服务器4，编码占用占用9个通道，PSTN占用16个通道剩余资源：
- 服务器1，编码资源剩余20个通道（默认30-20），PSTN剩余14通道
- 服务器4，编码资源剩余1个通道（默认10-9），PSTN剩余16个通道
3针对每个资源服务器来说，判断最小可用资源：
4服务器1最小可用资源是14（比20下），服务器4最小可用资源是1。注意，这里是针对两个媒体服务器所有资源来说的。
从步骤3中选择最小资源中的最大资源值-因为服务器1的14比服务器4中的1大，因此，服务器1作为一个最终资源来使用。
以上逻辑示例仅说明正常状态下的LB的处理，在实际脚本处理中，我们仍然需要对呼叫失败进行处理。通过t_on_failure做失效转移和关闭目的地的流程。具体示例脚本如下：
route[do_lb] {
If（!lb_start（1, "tran"）） { # 编码转换业务处理
send_reply（503,"Service Unavailable"）；
exit;
t_on_failure（"lb_failover"）；
t_relay（0;
}
failure route[lb_failover]{
if （failure condition） {
Ib_disable_dst）; #避免再次将来的呼叫使用此peer资源
if （!lb_next（）{
t _reply[503,"Service Unavailable"）;
exit;
t_on_failure（"lb_ failover"）;
t relay（）;
}
}
虽然我们从脚本示例中看到的逻辑相对比较简单，但是，在实际应用环境中，负载均衡需要完全自动化的处理，并且在OpenSIPS LB模块启用以后不能再手动调整目的地资源。因为，目的地资源的调用是一个动态的数据，大量呼叫状态下，我们不能完全模拟出当前实时的状态。lb_next 已经启动，当前的动态数据（因为最佳资源是变化的）不可能再次进行处理，所以，LB目的地资源的调用是非常关键的步骤，它要求的系统资源也非常大。另外，因为目的地资源在呼叫过程中已经被locked，我们不能使用其他的外部命令再次对其进行干预管理。所以，其负载处理能力和lb_start 时的负载基本上相同，因此，在使用lb_next方面，它增加了系统的维护复杂程度，如果处理不好的话，可能导致系统性问题，和呼叫失败。
7LB模块在运行状态时的命令执行
比较幸运的是，OpenSIPS通过CLI命令可以提供一定的对LB模块的管理能力，包括reload LB模块刷新DB数据库，重增系统资源对媒体服务器的支持lb_resize。在某些应用场景中（电话会议服务），系统管理员可能不完全了解最终的会议人数，如果最终会议人数超过了系统资源的支持，或者CPU负载很高的话，系统需要针对后续的呼叫进行选择，让其路由到其他的相对空闲的会议服务器。如果会议服务器CPU资源不能支持更多呼叫的话，对会议服务器的呼叫并发进行限制。
8负载均衡在电话会议场景中的挑战和解决思路
电话会议对用户来说是非常熟悉的一个应用场景，用户端操作看起来也非常简单。如果单使用一台媒体服务器实现其应用场景的话，实际部署也不复杂。但是，如果前端使用了OpenSIPS的负载均衡模块以后，系统部署就会面对很多的问题。几个比较有挑战性的问题是：
一个会议室由几个不同的呼叫构成。每个会议人员加入会议有自己的SIP呼叫流程。
为了确保所有会议成员能够进入同一会议室，他们/她们的呼叫必须在同一会议服务器。
一般情况下，因为使用了LB的逻辑，LB需要对资源进行重新路由，他们的呼叫可能进入到了不同会议服务器的会议室。
在OpenSIPS针对会议服务的解决方式可以通过对URL进行检查，然后进行路由。通常的针对会议服务器来说，会议人员需要拨打一个指定的会议室号码才能进入到特定会议室。在LB模块中，会议呼叫首先需要检查Request URL确保进入到同一会议室。如果第一个请求的URL进入到了会议室，会议室启动以后，后续的对此URL的呼叫不再做资源检查，直接通过LB模块路由到此会议室。具体实现方式是通过dialog模块的变量对会议呼叫进行路由，路由到会议室服务器地址。
# 添加一个以拨号码变量"conf_ bridge"
$dlg_ val（conf_ bridge） =$rU ;
# 添加一个目的地会议服务器地址变量
"server'$dlg_ val（server） = $du;
另外，在失败呼叫的路由中也要对以上两个变量进行处理，保证失败的会议呼叫那个正常进入到会议室中。
9负载均衡模块的配置示例演示
在本示例中，我们将通过一个简单示例对两台媒体服务器支持LB负载的处理演示。在此示例的设置过程中，用户需要根据要求完成以下的配置和界面添加工作。
首先，我们需要修改cfg 配置文件，添加对LB模块的支持加载。
loadmodule "load_balancer.so"
modparam（"load_balancer", "db_url",
"mysql://opensips:opensipsrw@localhost/opensips"） # CUSTOMIZE ME
modparam（"load_balancer", "probing_interval", 30）
modparam（"load_balancer", "probing_from", "sip:lb@sip.domain.com"）
然后对to_media 路由脚本增加支持：
route[to_media] {
xlog（"routing to media servers via load balancer\n"）;
if （!lb_start（1, "channel"）） {
send_reply（500,"No route to Media"）;
exit;
}
xlog（"Using media server $du （RURI=$ru） \n"）;
t_on_failure（"media_failover"）;
t_relay（）;
exit;
}
修改失效路由中的路由，支持to_media 路由规则：
failure_route[media_failover] {
if （t_was_cancelled（））
exit;
if （ t_check_status（ "[56][0-9][0-9]" ） ||
（t_local_replied（"all"） && t_check_status（"408"））） {
# media server failover -> mark it as disabled
xlog（"Media server routing failed with reply $T_reply_code\n"）;
lb_disable_dst（）;
# try another media server, if available
if （!lb_next（）） {
xlog（"no more media servers available\n"）;
t_reply（503,"Service Unavailable"）;
exit;
}
# send the call to the new media server
xlog（"Trying the new $du media server\n"）;
t_on_failure（"media_failover"）;
t_relay（）;
}
}
保存cfg文件，重新启动OpenSIPS。
接下来，用户需要访问OpenSIPS控制界面，然后通过界面添加LB模块的配置路由，添加路由以后需要点击reload 按钮重新加载数据库数据。
如果需要重新编辑数据时，用户也可以编辑LB模块资源路由：
添加LB模块以后，注意目的地的状态，确保DB加载和目的地地址可用。
最后对LB模块配置示例进行测试。使用两个UAC终端对不同媒体服务器进行呼叫，查看LB状态和资源占用情况。通过UAC测试呼叫对媒体服务器进行呼叫，sngrep抓包截图：
通过LB模块的负载均衡管理以后，用户可以通过CLI命令或者界面状态查看具体资源的使用情况。对媒体服务器的呼叫需要配置dialplan 的拨号规则，通过拨号规则路由到相关的媒体服务器端（Asterisk或者FreeSWITCH），在媒体服务器端也要确保正确的呼入规则能够被触发，然后UAC才能看到最终的成功呼叫。关于媒体服务器的呼入配置，用户可以自己根据自己的业务场景进行配置，例如进入会议室，呼出到PSTN或者如果有编码转换功能的话，可以测试媒体服务器的编码转换功能。
10总结
OpenSIPS的负载均衡是SIP软交换中核心的功能，但是其使用部署也比较复杂，特别是在实际应用场景中，例如电话会议的处理方面。本文档重点介绍了如何实现负载均衡的资源选择和其4个逻辑步骤，并且介绍了如何处理lb_next问题，还有电话会议中如何确保会议室的进入。最后，笔者给出了一个负载均衡的配置示例和两台媒体服务器的对接呼叫测试，通过界面添加DB，媒体服务器资源进行呼叫测试。
在比较大型的呼叫应用场景中，媒体服务器资源具有不同的支持能力，负载均衡也需要灵活地处理。这是一个非常大的挑战，用户需要在部署负载均衡之前首先考虑到其业务的扩展如何能够保证负载均衡的稳定性。笔者还是建议读者通过多种场景进行不同的测试，预估出其部署风险，保证其平台的正常工作。平衡是为了更好地发展，发展是为了更好地平衡。
参考资料：
https://opensips.org/Documentation/Tutorials-LoadBalancing-1-9
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/voip-performance-vsphere5-white-paper.pdf
Varun C，https://pdfs.semanticscholar.org/c3c4/f143ae0243345276bdd618c9f47a26fbec45.pdf
www.freesbc.cn
www.freepbx.org.cn
www.asterisk.org.cn
- 关于Asterisk文档，参考：www.asterisk.org.cn
- 融合通信/IPPBX/FreePBX商业解决方案：www.hiastar.com
- 最新Asterisk完整中文用户手册详解：www.asterisk.org.cn
- Freepbx/FreeSBC技术文档： www.freepbx.org.cn
- 如何使用免费会话边界控制器-FreeSBC，qq技术分享群：334023047
- 关注微信公众号：asterisk-cn，获得有价值的通信行业技术分享
