1. Toy模板网首页
  2. > Toy博客

干货 | 携程客服机器人ASR引擎的负载均衡实践

7月前 作者：携程技术 分类：Toy博客 阅读(38) 违法举报

这篇具有很好参考价值的文章主要介绍了干货 | 携程客服机器人ASR引擎的负载均衡实践。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

作者简介

玉修，携程技术专家，专注于电话音视频通信、智能客服机器人等领域。

一、前言

携程拥有庞大的呼叫中心，涉及上万客服人员，覆盖机票、酒店、火车票、度假等产线的售前售后业务，每天的电话业务量超百万通。近年来，通信技术、人工智能技术和智能终端等都在不断革新，我们也一直在思考如何去做更智能化、自动化的呼叫中心，为未来海量的客户需求提供稳定和优质的服务。

携程呼叫中心的智能化包含多个方面：

  • 用户侧：智能在线聊天机器人（IM）、智能语音导航/智能语音客服机器人/智能邀评插件（电话）

  • 客服侧：智能工单和排班系统、智能质检系统、智能客户资源管理系统、服务渠道智能化

  • 系统基建：平台部署智能化、业务监控智能化

本文旨在探讨携程实现呼叫中心电话智能语音客服机器人的基建服务——语音识别服务（即ASR）的负责均衡的演进历程，以及最佳实践。

二、背景

随着人工智能技术的发展，在呼叫中心业务中，传统的 IVR（交互式语音应答）按键导航模式逐步向IVR智能客服机器人转变（客户与IVR机器人进行语音对话的方式来办理业务）。携程呼叫中心系统下的IVR业务也在不断地向电话智能语音机器人转变，目前携程酒店、机票、火车票的国内IVR呼入业务，以及IBU国际英语机票的IVR呼入业务，已经全部由电话智能语音机器人来为客户提供自助服务。

下图是国内酒店业务场景中，客户拨打携程服务热线后，客户与电话机器人通过语音沟通的记录。可以看出，客户顺利完成了“取消订单”的业务办理。

干货 | 携程客服机器人ASR引擎的负载均衡实践,机器人,负载均衡,运维

智能客服机器人要想实现上图的交互效果，离不开ASR服务的使用，以及功能完善且稳定的呼叫中心系统的支撑。携程呼叫中心的整个平台依赖了众多组件，底层包括CC-Gateway（语音网关）、SBC（会话边际控制服务）、REG（分机注册服务）、SM（会话管理服务）、RS（呼叫路由服务）、CM（呼叫管理服务，基于FreeSWITCH）、ASR（语音识别服务）等系列服务。

下图是携程呼叫中心，客户呼入到智能客服机器人场景，进行语音自助业务办理时所涉及的部分核心组件架构图。

干货 | 携程客服机器人ASR引擎的负载均衡实践,机器人,负载均衡,运维

从上图可以看出，携程呼叫中心系统底层（如FreeSWITCH）调用实时ASR完成语音识别是基于MRCP协议来实现的。我们将上图中涉及ASR使用部分的组件交互进行简化，得出其包含下面3种组件：

  • MRCP客户端：发送RTP和SIP/MRCP的发起者，如FreeSWITCH（下文简称FS

  • MRCP服务端：处理MRCP/SIP信令，接收并转发RTP

  • ASR引擎  ：解析RTP，将语音转换成文本，并返回给MRCP Server

干货 | 携程客服机器人ASR引擎的负载均衡实践,机器人,负载均衡,运维

可以发现，对于呼叫中心ASR调用者而言，只需要关心怎么对接MRCP Server即可，无需关注ASR Engine部分。在实际使用过程中，如果你采购第三方ASR系统进行私有化部署的话（比如科大讯飞ASR、百度ASR），通常MRCP Server和ASR Engine是打包在一起，并部署在同一机器上。

但无论你采购哪家的ASR产品进行集群化部署，厂商都没有提供ASR的负载均衡解决方案，需要客户自行解决。携程为了让ASR引擎具备更高的可用性，采用了多集群、多IDC、多供应商的ASR产品（如携程自研、百度、阿里、微软等）来提供服务。针对这么多的集群和ASR产品，设计出一个调度策略和负载均衡方案来合理有效地利用ASR资源就变得极为重要了。

三、方案探索

目标已经理清，接下来深入分析调用ASR涉及的技术点，看看如何实现目标。

调用MRCP Server包含SIP（UDP/TCP）、MRCP（TCP）、RTP（UDP）三部分，MRCP和RTP的服务端地址是由SIP INVITE的响应 200 OK中SDP指定（如下图），所以只要完成对SIP的负载均衡就能解决另外两个，要给MRCP Server做负载均衡就变成了给 SIP（UDP/TCP）做负载均衡。

我们期望负载均衡的效果是：只要MRCP-Server服务端集群下有多台机器，即使客户端只有一个，负载均衡设备也能将请求均匀分发给服务端的每一个成员。

干货 | 携程客服机器人ASR引擎的负载均衡实践,机器人,负载均衡,运维

常规的负载均衡方案，无外乎基于硬件负载均衡设备实现，如A10（即AX）、F5、NetScaler等；或者基于软负载实现，如LVS、Nginx等。但这些常规方法，都无法真正做到给MRCP Server实现负载均衡。 

携程的基建服务中，恰好有AX、Netscaler、TDLB相关负载均衡服务，所以我们基于这几种基建服务都进行过验证性测试，可惜最终效果都不尽人意。

以FS作为MRCP Client，AX作为负载均衡设备为例。假如只有1台FS设备，1台AX设备，4台MRCP-Server设备。从FS依次发起4次请求，或者同时发起4次请求，最终使ASR驻留并发达到4个。

干货 | 携程客服机器人ASR引擎的负载均衡实践,机器人,负载均衡,运维

上图是左侧“卖家秀”是我们想要达到的预期效果，右侧“买家秀”是我们实验所得的实际效果，所有的请求都被分配到了同一台MRCP-Server机器上，没能均匀的分配给集群下的各成员。理想很丰满，但现实太骨感。

那么，AX设备没能做到均匀分配的原因是什么呢？FS基于AX来给MRCP做负载又存在什么弊端呢？

首先，对于FS和AX设备相对固定的情况下，SIP请求的IP四元组（Source IP、Source port、Destination IP、Destination port）不会发生变化，因为FS对接MRCP Server时，会在MRCP配置文件中指定客户端和服务端的IP/Port，所以AX每次分配给FS的MRCP Server都是同一台，这显然不符合负载均衡的预期。

其次，电话场景，在收到200 OK后，可能长达半小时不会再有SIP交互，期间的MRCP和RTP都是MRCP-Client和MRCP-Server之间进行直连交互，根本不经过AX设备，而AX设备默认的会话保持时长为120秒，超过这个时间，SIP通道会被AX关闭，这会导致后续的SIP无法送达。

既然此路不通，我们要考虑其他解决方案，经过深入研究和各种尝试，认为下面这两种解决方案比较适合，但各有优缺点：

  • 方案A：通过FreeSWITCH的distributor模块实现

  • 方案B：通过OpenSIPs实现

优点

缺点

方案A

1、无需依赖第三方负载均衡组件

1、配置繁琐复杂

2、MRCP Server节点增删，都需要调整FS配置文件，而且得在无ASR业务时，才能加载生效

3、端口数量消耗大(每个MRCP Server都需要单独分配端口段)

4、负载均衡策略相对单一，只支持按比例分配。而且单机所占有的最小比例不能小于0

方案B

1、配置简单

2、MRCP Server节点增删，只需调整OpenSIPs的DB即可，有ASR调用时，也可更改，实时生效

3、端口数量消耗小（只需要配置一个MRCP Profile文件，多个MRCP Server共用端口段）

4、负载均衡方案多种多样，支持按比例、轮询等多种方式

1、需要依赖第三方负载均衡组件OpenSIPs

我们最终将两个方案结合，来实现负载均衡，FS上使用distributor模块来实现对 OpenSIPs做负载均衡，OpenSIPs上再对MRCP-Server做负载均衡，效果如下：

1）FS、OpenSIPs、MRCP-Server三个组件之间实现了IDC优先就近访问（如上所述，FS未能做到100%的就近访问）。

2）当相同IDC下的下游服务全部不可用时，则自动将流量分配到其他IDC下，如下图，IDC-A 下 FS的ASR请求，优先请求到 IDC-A 的OpenSIPs，然后IDC-A的OpenSIPs再根据分配策略，将请求优先分配给 IDC-A下的MRCP-Server，如果IDC-A下的MRCP-Server全宕机了，会自动分配给IDC-B下的MRCP-Server。

3）负载均衡服务可自动检测下游集群各成员的状态，当某成员服务不可用时自动拉出，服务状态恢复后，再自动拉入。FS和OpenSIPs都是通过发送SIP OPTION 来自动探测下游服务的状态。

干货 | 携程客服机器人ASR引擎的负载均衡实践,机器人,负载均衡,运维

四、方案实践

接下来，我们详细看看每种方案的具体实现方式。以下方案运行环境为：CentOS 7.6、FreeSWITCH 1.6.20、OpenSIPs 2.4.2。

本篇文章中，我们不详细讲解每种方式的实现原理，只介绍解决方法，有兴趣的同学可以自行学习FS和OpenSIPs的相关功能点，这里给出几个链接：

  • mod_unimrcp

  • mod_distributor

  • mod_dptools: play_and_detect_speech

  • Load Balancer Module

  • Dispatcher Module

  • Dialplan Module

假设我们只有一台FS作为MRCP 客户端，并且MRCP Server 集群中有两台服务器，分别是 mrcp1 和 mrcp2，希望FS针对每一通电话执行ASR命令时，请求可均匀分配给两个MRCP Server。

4.1 基于FS的distributor模块实现MRCP Server的LB

该方案的核心思路如下：

1）FS直接与MRCP  Server对接，为MRCP Server集群下每一个成员配置一个profile

2）将MRCP Server集群下的所有成员配置成 FS 的网关，并开启网关的SIP OPTION探测功能，同时确保gateway的name要与mrcp_profile文件中profile的name一致

3）通过FS的distributor 模块为这些MRCP网关配置负载均衡策略

4）最后，实际执行ASR命令时，先通过 expand eval ${distributor mrcp ${sofia profile external gwlist down}} 负载均衡分配得到一个可用的 MRCP Server Profile的名称，然后用该MRCP Profile的名称作为FS play_and_detect_speech ASR命令的参数即可。

详细的配置步骤如下所示：

第一步：FS与MRCP Server对接 

在 /usr/local/freeswitch/conf/mrcp_profiles/下配置FS对接MRCP Server的文件
tree /usr/local/freeswitch/conf/mrcp_profiles
├── mrcp1.xml
└── mrcp2.xml

下面只给出mrcp1.xml的部分核心配置，只需要确保mrcp1.xml和mrcp2.xml里client-port、rtp-port-min、rtp-port-max配置不同即可。

这里可以看到，如果MRCP Server集群有很多机器，那么这里的RTP端口段可能不够用，一通电话进行ASR解析需要2个端口，一个用来传输RTP、一个传RTCP。

<include>
  <profile name="mrcp1" version="2">   【每个MRCP Server这里配置的名称都不一样，但一定有一个相同名称的网关】
    <param name="client-ip" value="192.168.1.99"/>
    <param name="client-port" value="client-port-1"/>
    <param name="server-ip" value="server-ip-1"/>
    <param name="server-port" value="8060"/>
    <param name="sip-transport" value="tcp"/>   【也可以是UDP哦】
    <param name="rtp-ip" value="192.168.1.99"/>
    <param name="rtp-port-min" value="min-port-1"/>
    <param name="rtp-port-max" value="max-port-1"/>
    <param name="ua-name" value="FreeSWITCH"/>
  </profile>
</include>

第二步：配置FS网关

在 /usr/local/freeswitch/conf/sip_profiles/external/下配置网关对接文件
/usr/local/freeswitch/conf/sip_profiles/external
├── mrcp1.xml
└── mrcp2.xml

mrcp1.xml 的详细配置如下：

<gateway name="mrcp1">  【gateway的name要与mrcp_profile文件中profile的name一致，或可以按照某种规则转换】
        <param name="username" value=""/>
        <param name="proxy" value="mrcp1-server-ip:8060"/>  【当然这里端口可能是其他值】
        <param name="realm" value="mrcp1-server-ip"/>
        <param name="register" value="false"/>
        <param name="rtp-autofix-timing" value="false"/>
        <param name="caller-id-in-from" value="true"/>
        <param name="ping" value="10"/>    【FS给proxy对应地址发送探测的周期】
        <param name="ping-max" value="5"/>
        <param name="ping-min" value="2"/>
</gateway>

第三步：配置FS的distributor模块

vim /usr/local/freeswitch/conf/autoload_configs/distributor.conf.xml
<configuration name="distributor.conf" description="Distributor Configuration">
  <lists>
    <list name="mrcp">  【权重配置成一样，相当于两个MCRP server 按 1:1 分配】
      <node name="mrcp1" weight="5"/>  【node name值与sip gateway 名称相同】
      <node name="mrcp2" weight="5"/>
    </list>
  </lists>
</configuration>

最后，来看看使用效果。按照上述配置，将mrcp2服务宕机后，执行负载均衡的效果如下：

freeswitch@LPT0596> sofia profile external gwlist down   【获取宕机的网关】
mrcp2
freeswitch@LPT0596> expand eval ${distributor mrcp ${sofia profile external gwlist down}}   【将宕机的网关排除在外后，获取分配的SM节点】
mrcp1
freeswitch@LPT0596> expand eval ${distributor mrcp ${sofia profile external gwlist down}}   【如果mrcp2没有宕机，这里将返回mrcp2】
mrcp1


使用得到的MRCP Server Profile名称执行ASR命令：play_and_detect_speech
/usr/local/freeswitch/sounds/ivr_prompt_voice.wav detect:unimrcp:mrcp1 
{start-input-timers=false,no-input-timeout=10000,recognition-timeout=10000}ahlt_ats

其他FS相关命令：

  • reload mod_unimrcp : 修改FS与MRCP server对接的文件后，重新加载生效【只有当前没有正在执行的ASR操作时，才能重加载】

  • sofia profile external rescan : 重新加载FS的网关配置

4.2 基于OpenSIPs实现MRCP Server的LB

4.2.1 核心思路

FS不直接与MRCP Server对接，而是与OpenSIPs进行对接。对接方式是把OpenSIPs配置成一个MRCP profile，文件中的server-ip 和 server-port 地址配置成OpenSIPS 的服务地址即可。

FS执行ASR命令时，先将SIP请求发送给OpenSIPs，再由OpenSIPs负载均衡到MRCP Server集群中的成员，交互的时序图如下：

干货 | 携程客服机器人ASR引擎的负载均衡实践,机器人,负载均衡,运维

4.2.2 方案分析

通过OpenSIPs来实现对MRCP的负载均衡需要解决下面几个问题：

问题1、如何判断收到的INVITE请求是要执行ASR命令，还是普通呼叫命令？

问题2、知道是执行ASR命令后，如何选择MRCP Server，进行分配？

问题3、如果有多套MRCP Server集群，比如一套百度MRCP，一套阿里MRCP，客户端希望能指定引擎使用，该如何解决？

既然已经明确了问题点，那咱就各个击破即可，下面是各问题点的解决方法：

  • 问题1的解决方法

我们来看一条FS发送给OpenSIPs，请求执行MRCP负载均衡的SIP INVITE信息，其中 192.168.1.99是FS，192.168.1.18是OpenSIPs。

INVITE sip:192.168.1.18:5070 SIP/2.0
Via:  SIP/2.0/UDP 192.168.1.99:5102;rport;branch=z9hG4bKQ21yZS46ytrgF
Max-Forwards:  70
From:  <sip:192.168.1.99:5102>;tag=4B8SvQe66FNvc
To:  <sip:192.168.1.18:5070>
Call-ID: ed9f5f6b-0673-123b-199a-fa163e72d95e
CSeq:  47770741 INVITE
Contact:  <sip:192.168.1.99:5102>
User-Agent:  FreeSWITCH
Allow:  INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE
Supported:  timer, 100rel
Content-Type:  application/sdp
Content-Disposition:  session
Content-Length:  306


v=0
o=FreeSWITCH 2480643166757753319 6144298267054033408 IN IP4 192.168.1.99
s=-
c=IN IP4 192.168.1.99
t=0 0
m=application 9 TCP/MRCPv2 1
a=setup:active
a=connection:existing
a=resource:speechrecog
a=cmid:1
m=audio 31799 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendonly
a=mid:1

从上面信令可以看到，FS发起的INVITE中，没有主被叫号码信息，只有FS和OpenSIPs的IP和端口信息。如果我们的OpenSIPs只用来给MRCP Server做负载均衡，那么就很简单，收到INVITE请求，都认为是请求执行ASR命令，分配给MRCP Server即可。但是，OpenSIPs只给MRCP Server做负载岂不是大材小用了！

所以，实际我们不会这样使用，OpenSIPs通常还会给其他呼叫中心组件做负载均衡，比如给FreeSWITCH、语音网关、分机注册服务等做LB。这样OpenSIPs就会收到来自各种组件的SIP INVITE请求。那么该如何判断收到的 INVITE 是要执行ASR命令，还是要做其他业务呢？

常规思路，自然是OpenSIPs分析INVITE的SIP消息头，从中进行判断。可是由于FS的mod_unimrcp模块的限制，FS执行ASR命令时，发送的SIP INVITE里不支持增加自定义SIP消息头，所以只能从标准 SIP 消息头中进行挖掘。

  • 根据INVITE请求的源IP：不可行，因为同一个源IP可能发起多种请求的INVITE，比如FS可能是请求执行ASR，也可能是请求呼叫手机；此外，即使可行，源IP也不方便维护。

  • 根据INVITE请求的目的IP：不可行，所有INVITE请求的该值都一样

  • 根据INVITE请求的User-Agent头：可行，OpenSIPs通过$ua就能获取该值。虽然不能针对每次INVITE自定义不同的UA头，但FS对接MRCP Server的Profile中可以指定一个统一的User-Agent头，默认是FreeSWITCH。

  • 根据INVITE请求SDP信息中的‘m’头：可行，OpenSIPs通过$(rb{sdp.line,m})就能获取该值。如 上面报文中“m=application 9 TCP/MRCPv2 1” 里面有MRCPv2，可根据这个判断是执行ASR。

建议使用User-Agent头进行区分，取值方便，效率高。所以，FS对接OpenSIPs时，配置的MRCP Profile时，指定一个特别的User-Agent，比如叫ASR_MRCP_CLIENT_FS，OpenSIPs收到INVITE请求，优先判断UA信息，如果是ASR_MRCP_CLIENT_FS，那么就是要执行ASR命令。

  • 问题2的解决方法

可以使用OpenSIPS的load_balancer 或 dispatcher 模块来实现对 MRCP Server 服务端的负载均衡，两种方式的特点如下：

如果MRCP-Server集群下的成员可支持的并发数不一样，想做到哪台机器剩余的可用资源最多，就优先分配给谁，当各成员可用资源数相同时，在轮训分配，那么可以使用 load_balancer 模块来实现负载均衡；

如果MRCP-Server集群下的成员可支持的并发数完全一样，无差别，那么建议使用dispatcher模块来试想负载均衡，可以做到均匀的将请求分配给每一台服务器。

优点

缺点

load_balancer

可控制每个MRCP Server的最大并发量

支持监控分配给每个MRCP Server的实时并发量

分配策略单一：只支持空闲优先策略分配和按比例分配两种策略，无法支持记忆轮训，这就导致但MRCP Server集群新增成员时，会将流量全部分配给新增的机器，这种情况，新机器的突增压力可能较大

dispatcher    

分配策略多种多样：如支持记忆轮训、Hash分配等

不能控制每个MRCP Server的最大并发量，话务量暴涨时，存在雪崩隐患

不能监控分配给每个MRCP Server的实时并发量（但可以自行通过OpenSIPs其他模块实现）

  • 问题3的解决方法

在FS上为每一套MRCP Server集群，配置一个MRCP Profile并且都指向OpenSIPs，但User-Agent的值配置成不一样，OpenSIPs根据UA的不同，来选择该给哪个集群做LB。

baidu_mrcp_lb.xml  下面只给出特有配置，其他配置被省略了
<include>
  <profile name="baidu_mrcp_lb" version="2">   【阿里的配置，name为ali_mrcp_lb】
    <param name="server-ip" value="opensips-ip"/>
    <param name="ua-name" value="ASR_MRCP_CLIENT_FS_BAIDU"/>    【阿里的配置，ua-name为ASR_MRCP_CLIENT_FS_ALI】
    <param name="sdp-origin" value="FS_MRCP"/>
  </profile>
</include>

OpenSIPs给MRCP Server做负载均衡的处理流程图如下：依赖dialplan模块进行选择具体通过哪个模块来执行LB。

干货 | 携程客服机器人ASR引擎的负载均衡实践,机器人,负载均衡,运维

4.2.3 具体实现

如果OpenSIPs本身也是集群化部署，那么可以通过本文3.1章节的方法实现对OpenSIPs的负载均衡。

下面代码涉及OpenSIPs对dialplan、dispatcher、load_balancer几个模块的使用，本文不讲解这部分的使用方法。

  • 数据库初始化

说明：

1）下方配置了百度、阿里两个MRCP Server集群，并且每个集群都部署在了两个IDC（IDC_A和IDC_B）

2）OpenSIPs根据dialplan拨号方案来为阿里和百度选择负载均衡的方式，dialplan表中字段“attrs”配置逻辑是：[MRCP集群第一路由的集群ID:负载均衡实现方式:集群名称]，如“90:DS:ASR_MRCP_SERVER_CTRIP_ALI”代表，阿里MRCP第一路由的集群ID是90，采用dispacher模块实现LB；"90:DS:ASR_MRCP_SERVER_CTRIP_ALI”代表，百度MRCP第一路由的集群ID是91，采用load_balancer模块实现LB

3）无论是dispacher，还是load_balancer，都配置了单IDC下负载均衡的基础上，增加了逃生路由的功能。集群ID为 90/91代表第一路由，10090/10091代表第二路由

dialplan的attrs字段被赋予了特殊用途
INSERT INTO `dialplan`(`dpid`,`pr`,`match_op`,`match_exp`,`match_flags`,`subst_exp`,`repl_exp`,`timerec`,`disabled`,`attrs`) VALUES
    (90,1000,1,'^ASR_MRCP_CLIENT_CTRIP_FS_ALI$',0,NULL,NULL,NULL,0,'90:DS:ASR_MRCP_SERVER_CTRIP_ALI'),
    (90,1000,1,'^ASR_MRCP_CLIENT_CTRIP_FS_BAIDU$',0,NULL,NULL,NULL,0,'91:LB:ASR_MRCP_SERVER_BAIDU');


dispatcher的attrs字段没有实际作用
INSERT INTO `dispatcher` (`setid`, `destination`, `state`, `weight`, `priority`, `attrs`, `description`) VALUES
    (90, 'sip:192.168.1.190:8060', 0, 1, 100, 'pstn=100', 'IDC_A:ASR_MRCP_SEVER_ALI'),
    (90, 'sip:192.168.1.191:8060', 0, 1, 100, 'pstn=100', 'IDC_A:ASR_MRCP_SEVER_ALI'),
    (10090, 'sip:192.168.2.198:8060', 0, 1, 100, 'pstn=100', 'IDC_B:ASR_MRCP_SEVER_ALI');


load_balancer的resources字段可以控制最大并发数
INSERT INTO `load_balancer`(`group_id`,`dst_uri`,`resources`,`probe_mode`,`description`) VALUES
    (91,'sip:192.168.1.180:8060','pstn=50',2,'IDC_A:ASR_MRCP_SEVER_BAIDU'),
    (91,'sip:192.168.1.181:8060','pstn=50',2,'IDC_A:ASR_MRCP_SEVER_BAIDU'),
    (10091,'sip:192.168.2.188:8060','pstn=50',2,'IDC_B:ASR_MRCP_SEVER_BAIDU');

配置好后，可查看集群内MRCP成员的状态：

sudo /usr/local/opensips/sbin/opensipsctl fifo lb_list
Destination:: sip:192.168.1.180:8060 id=1 group=90 enabled=yes auto-reenable=on
        Resources::
                Resource:: pstn max=50 load=50
Destination:: sip:192.168.1.180:8060 id=2 group=90 enabled=no auto-reenable=on
        Resources::
                Resource:: pstn max=50 load=0
Destination:: sip:192.168.2.188:8060 id=3 group=90 enabled=yes auto-reenable=on
        Resources::
                Resource:: pstn max=50 load=10




sudo /usr/local/opensips/sbin/opensipsctl fifo ds_list
PARTITION:: default
        SET:: 90
                URI:: sip:192.168.1.190:5080 state=Active first_hit_counter=8
                        attr:: pstn=500
                URI:: sip:192.168.1.191:5080 state=Inactive first_hit_counter=0
                        attr:: pstn=500
        SET:: 10090
                URI:: sip:192.168.2.198:8060 state=Active first_hit_counter=0
                        attr:: pstn=100

  • OpenSIPs代码实现

route{
    #省略N多代码...


    # check sip INVITE message source ip and port
    if (is_method("INVITE")) {
        xlog("ua = $ua , callid = $ci, fu = $fu , tu = $tu , ru = $ru , du =$du src:$si, $(rb{sdp.line,m}))");
        $var(dlgPingTag) = "Pp";
        if ( $ua == "ASR_MRCP_CLIENT_FS" ) { #to_asr_mrcp_server
               $var(dlgPingTag) = ""; # ASR 的SIP通道不能做OPTION探测
        }
        if ( !create_dialog("$var(dlgPingTag)") ) {
            route(PRINT_LOG, "create_dialog error :  Internal Server Error");
            send_reply("500","SM Internal Server Error");
            exit();
        }


        if ( $ua =~ "^ASR_MRCP_CLIENT_CTRIP_FS*" ) { #to_asr_mrcp_server 【需要修改FS mrcp client配置文件，<param name="ua-name" value="ASR_MRCP_CLIENT_FS..."/>】
                if ( dp_translate("90", "$ua/$avp(dest)", "$var(attrs)") ) { #拨号方案判断
                        route(exeLb, $(var(attrs){s.int}), "pstn", $(var(attrs){s.select, 1,:}), $(var(attrs){s.select, 2,:}));
                }
        } else { #处理其他呼叫类型，如呼叫手机等
            #省略N多代码...
        }
    }
    exit();
}
#usage : route(exeLb, lb_group_id, resource_type, node_type, lb_method)
#e.g.  route(exeLb, 90, "pstn", "ASR_MRCP_SERVER_ALI", "LB")
#e.g.  route(exeLb, 90, "pstn", "ASR_MRCP_SERVER_ALI", "DS")
route[exeLb]{
    $var(lb_group_id) = $param(1);
    $var(lb_group_id_bak) = $param(1) + 10000;
    $var(resource_type) = $param(2);
    $var(node_type) = $param(3);
    $var(lb_method) = $param(4);


    xlog("[$fU->$rU] Route $rU to '$var(node_type)' by load_balancer group_id : '$var(lb_group_id)' [back_group_id:'$var(lb_group_id_bak)'], resource_type : '$var(resource_type)', node_type : '$var(node_type)' [ci:$ci] [xcid:$hdr(X-CID)]");


    $var(lbRst) = 0;
    if( $var(lb_method) == "DS" ) {
        $var(lbRst) = ds_select_dst("$var(lb_group_id)", "4");
        if($var(lbRst) == -1) {
            xlog("[exeLb4CM] [$fU->$rU] Failed --->lbRst=$var(lbRst) Route $rU to '$var(node_type)' by dispatcher group_id : '$var(lb_group_id)', resource_type : '$var(resource_type)' [ci:$ci]");
            $var(lbRst) = ds_select_dst("$var(lb_group_id_bak)", "4");
            if(!$var(lbRst)) {
                xlog("[exeLb4CM] [$fU->$rU] Failed ===>lbRst=$var(lbRst) Route $rU to '$var(node_type)' by dispatcher [back_group_id:'$var(lb_group_id_bak)'], resource_type : '$var(resource_type)' [ci:$ci]");
                }
        }


    } else {
        $var(lbRst) = lb_start_or_next("$var(lb_group_id)", "$var(resource_type)", "s");
        if( $var(lbRst) < 0) {
            xlog("[$fU->$rU] Failed --->lbRst=$var(lbRst) Route $rU to '$var(node_type)' by load_balancer group_id : '$var(lb_group_id)', resource_type : '$var(resource_type)' [ci:$ci]");
            $var(lbRst) = lb_start("$var(lb_group_id_bak)", "$var(resource_type)", "s");
            if( $var(lbRst) < 0) {
                xlog("[$fU->$rU] Failed ===>lbRst=$var(lbRst) Route $rU to '$var(node_type)' by load_balancer [back_group_id:'$var(lb_group_id_bak)'], resource_type : '$var(resource_type)' [ci:$ci]");
            }
        }


    }


    if ( $var(lbRst) > 0) {
            if ( $rU == null ) {  #对于FS 发起的 MRCP INVITE 请求， $rU 为 null, 而不设置 $rU 将导致 Load balancer 失败，所以需要初始化一个值
                    xlog("[$fU->$rU] rU is null, then initialize to 'Null2Sm' [ci:$ci] [xcid:$hdr(X-CID)]");
                    #$rU = "Null2SM";
                     $ru = "sip:" + $(du{uri.host}) + ":" + $dp;
            } else {
                   $ru = "sip:" + $rU + "@" + $(du{uri.host}) + ":" + $dp;
            }
            xlog("[$fU->$rU] Route to '$var(node_type)' --> [$du] [ci:$ci] [xcid:$hdr(X-CID)]");
            route(relay);
    } else {
            xlog("[$fU->$rU] No available '$var(node_type)' now [ci:$ci] [xcid:$hdr(X-CID)]");
            t_reply("480", "$var(node_type) Unavailable");
            exit();
    }


}

如果按照上面脚本执行了 $ru = "sip:" + $rU + "@" + $(du{uri.host}) + ":" + $dp;，但是$rU== null 并且不设置 $rU="Null2SM"或者其他非空值，会报如下错误：

Feb 12 22:27:35 fat5410 /usr/local/opensips/sbin/opensips[3710]: ERROR:core:parse_uri: bad char '@' in state 0 parsed: <sip:> (4) / <sip:@192.168.1.190:8060> (20)
Feb 12 22:27:35 fat5410 /usr/local/opensips/sbin/opensips[3710]: ERROR:core:parse_sip_msg_uri: bad uri <sip:@192.168.1.190:8060>
Feb 12 22:27:35 fat5410 /usr/local/opensips/sbin/opensips[3710]: ERROR:core:pv_get_ruri_attr: failed to parse the R-URI

解决办法：

1）设置$rU 为一个非空值

2）直接不修改$ru 的值

3）修改 $ru = "sip:" + $(du{uri.host}) + ":" + $dp;

4.2.4 信令记录：

  • FS 发送INVITE给 OpenSIPs

2022-02-13 13:50:53 +0800 : 192.168.1.99:5221 -> 192.168.1.18:5070
INVITE sip:192.168.1.18:5070 SIP/2.0   你可以看到，这里没有被叫号码，所以到了OpenSIPs 后  $rU是null
Via: SIP/2.0/UDP 192.168.1.99:5221;rport;branch=z9hG4bKFUXeX5r0Q0gXp
Max-Forwards: 70
From: <sip:192.168.1.99:5221>;tag=3pU7FrrQBQ1NS
To: <sip:192.168.1.18:5070>
Call-ID: 5c97aeaf-64b4-123a-02b4-fa163ea03f01
CSeq: 38878534 INVITE
Contact: <sip:192.168.1.99:5221>
User-Agent: ASR_MRCP_CLIENT_FS_ALI
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE
Supported: timer, 100rel
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 299


v=0
o=FS_MRCP 1321904497415698834 1659019553944433241 IN IP4 192.168.1.99
s=-
c=IN IP4 192.168.1.99
t=0 0
m=application 9 TCP/MRCPv2 1
a=setup:active
a=connection:new
a=resource:speechrecog
a=cmid:1
m=audio 16416 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendonly
a=mid:1

  • OpenSIPS 转发INVITE给 MRCP server

2022-02-13 13:50:53 +0800 : 192.168.1.18:5070 -> 192.168.1.190:8060
INVITE sip:192.168.1.18:5070 SIP/2.0    [如果修改$rU, 这里就是  INVITE sip:Null2SM@192.168.1.18:5070 SIP/2.0]
Record-Route: <sip:192.168.1.18:5070;lr;did=de7.2517abb1>
Via: SIP/2.0/UDP 192.168.1.18:5070;branch=z9hG4bK9443.c1265465.0
Via: SIP/2.0/UDP 192.168.1.99:5221;received=192.168.1.99;rport=5221;branch=z9hG4bKFUXeX5r0Q0gXp
Max-Forwards: 69
From: <sip:192.168.1.99:5221>;tag=3pU7FrrQBQ1NS
To: <sip:192.168.1.18:5070>
Call-ID: 5c97aeaf-64b4-123a-02b4-fa163ea03f01
CSeq: 38878534 INVITE
Contact: <sip:192.168.1.99:5221>
User-Agent:ASR_MRCP_CLIENT_FS_ALI
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE
Supported: timer, 100rel
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 299
X-UUI: &XCID=0dc0196031626864653EXCIDEND
X-CID: 0dc0196031626864653EXCIDEND


v=0
o=FS_MRCP 1321904497415698834 1659019553944433241 IN IP4 192.168.1.99
s=-
c=IN IP4 192.168.1.99
t=0 0
m=application 9 TCP/MRCPv2 1
a=setup:active
a=connection:new
a=resource:speechrecog
a=cmid:1
m=audio 16416 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendonly
a=mid:1

  • MRCP Server 回复200 OK，返回后续接收RTP的真实地址

2022-02-13 13:50:53 +0800 : 192.168.1.190:8060 -> 192.168.1.18:5070
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.18:5070;branch=z9hG4bK9443.c1265465.0
Via: SIP/2.0/UDP 192.168.1.99:5221;received=192.168.1.99;rport=5221;branch=z9hG4bKFUXeX5r0Q0gXp
Record-Route: <sip:192.168.1.18:5070;lr;did=de7.2517abb1>
From: <sip:192.168.1.99:5221>;tag=3pU7FrrQBQ1NS
To: <sip:192.168.1.18:5070>;tag=45D4K1DvpQQXK
Call-ID: 5c97aeaf-64b4-123a-02b4-fa163ea03f01
CSeq: 38878534 INVITE
Contact: <sip:192.168.1.190:8060>
User-Agent: BaiduSpeech SofiaSIP 1.5.0
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE
Supported: timer, 100rel
Session-Expires: 600;refresher=uac
Min-SE: 120
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 303


v=0
o=BaiduSpeechServer 8512797916186481341 4497985761629564802 IN IP4 192.168.1.190    【接收RTP的IP】
s=-
c=IN IP4 192.168.1.190
t=0 0
m=application 1544 TCP/MRCPv2 1
a=setup:passive
a=connection:new
a=channel:b250b76cea1011eb@speechrecog
a=cmid:1
m=audio 18380 RTP/AVP 0    【接收RTP的端口】
a=rtpmap:0 PCMU/8000
a=recvonly
a=mid:1

  • FS发送ACK给OpenSIPs

2022-02-13 13:50:53 +0800 : 192.168.1.99:5221 -> 192.168.1.18:5070
ACK sip:192.168.1.190:8060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.99:5221;rport;branch=z9hG4bKFUXeX5r0Q0gXp
Route:  <sip:192.168.1.18:5070;lr;did=355.53f8e331>
Max-Forwards:  70
From: <sip:192.168.1.99:5221>;tag=3pU7FrrQBQ1NS
To: <sip:192.168.1.18:5070>
Call-ID: 5c97aeaf-64b4-123a-02b4-fa163ea03f01
CSeq:  38878534 ACK
Contact: <sip:192.168.1.99:5221>
Content-Length:  0

  • 最后，OpenSIPs将ACK转发给MRCP Server

五、结语

从上文中提到的携程呼叫中心客户呼入到智能客服机器人场景的核心组件架构图可以看出，ASR引擎的负载均衡只是携程呼叫中心平台各组件中很小的一个功能点，但也是不可或缺的一部分。

正因为有了这个技术方案的实现，使得多集群、多数据中心、多供应商的ASR产品得以很好地整合，为携程电话智能客服机器人业务的稳定运行提供了良好的技术保障，提升了携程客户的通话体验。

本文主要讲解了对于ASR引擎做负载均衡的设计以及实现方案，希望能对从事智能呼叫中心领域工作或研究的同学们提供一些帮助。

【推荐阅读】

  • 高效联动，携程机票IVR可视化的探索和实践

  • 携程后台低代码平台的探究与实践

  • 提升效率和用户体验，携程门票活动商品结构演进

  • 携程火车票出海架构演进之路

干货 | 携程客服机器人ASR引擎的负载均衡实践,机器人,负载均衡,运维

 “携程技术”公众号

  分享，交流，成长文章来源地址https://www.toymoban.com/news/detail-780158.html

到了这里，关于干货 | 携程客服机器人ASR引擎的负载均衡实践的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处： 如若内容造成侵权/违法违规/事实不符，请点击违法举报进行投诉反馈，一经查实，立即删除！

分享到：
领支付宝红包 赞助服务器费用

相关文章

  • Chatterbot 打造游戏AI客服机器人

    Chatterbot 打造游戏AI客服机器人

    准备工具 1、开发语言：Python3 2、数据库：MongoDB 3、开源框架：Chatterbot   4、依赖类库： p ip3 install chatterbot p ip3 install spacy # 需要手动编译安装 en_core_web_sm(使用2.1版本) p ip3 install jieba p ip3 install colorama p ip3 install pymongo  Chatterbot 介绍 About ChatterBot — ChatterBot 1.0.8 docu

    2024年02月10日
    浏览(49)

  • FreeSWITCH 电话机器人 VAD 打断 ASR集成 全功能开源代码

    gitcode地址： https://gitcode.net/iyaosan/FreeSWITCH-ASR github地址： https://github.com/cdevelop/FreeSWITCH-ASR 最近很多人都对FreeSWITCH和ASR对接比较感谢兴趣，我之前已经做了一个商业模块（商业模块请点击这里http://www.ddrj.com/callcenter/asr.html），考虑到大部分人，只是研究一下，并不准确购买商

    2024年02月05日
    浏览(36)
  • 国内智能客服机器人都有哪些？

    国内智能客服机器人都有哪些？

    随着人工智能技术的不断发展，智能客服机器人已经成为了企业客户服务的重要工具。国内的智能客服机器人市场也迎来了飞速发展，越来越多的企业开始采用智能客服机器人来提升客户服务效率和质量。 在这篇文章中，我将详细介绍国内知名的智能客服机器人，包括其产品

    2024年02月07日
    浏览(38)
  • 基础课20——从0-1客服机器人生命周期

    基础课20——从0-1客服机器人生命周期

    温馨提示：篇幅较长，可点击目录查看对应节点。 搭建机器人包含：素材整理、问题提炼、相似问题补充、答案编辑、问题分配引擎等等步骤，不同厂商可能有所区别，但关键功能的实现离不开以下步骤。 语料源来自于哪里？ 如果我们计划构建一个知识库，首先需要明确它

    2024年02月04日
    浏览(69)
  • AI智能客服机器人是什么？对企业重要吗？

    AI智能客服机器人是什么？对企业重要吗？

    在数字化时代，客户服务是企业与客户建立牢不可破关系的重要桥梁。AI智能客服机器人，顾名思义，就是利用人工智能技术提升客户服务体验的自动化工具。今天，就让我们来揭开AI智能客服机器人的神秘面纱，并讨论它对企业的重要性。 AI智能客服机器人是什么？ 简单来

    2024年04月10日
    浏览(44)

  • 基于自然语言处理技术的智能客服与机器人

    作者：禅与计算机程序设计艺术 46.《基于自然语言处理技术的智能客服与机器人》 引言 随着互联网技术的快速发展，智能客服和机器人已经成为现代企业重要的运营手段之一。智能客服以自然语言处理技术为基础，能够实现高效、人性化的对话交互，有效提升客户满意度；

    2024年02月13日
    浏览(65)

  • AI智能语音客服机器人系统/方案/案列/技术/项目

    在工作中总是无法避免做一些重复的事，不同的人对待重复的工作做法也是不一样，总有一部分人想办法来提高效优化流程。当然，也有一部分人会选择按部就班。如果拘泥于原本的工作方式，没有创新的重复，只是在做无用功而已。不过，现在有了一种可以解决重复性工作

    2024年02月08日
    浏览(48)

  • 如何利用文本分析技术进行智能客服机器人和智能推荐

    作者：禅与计算机程序设计艺术 随着互联网网站、社交媒体、购物平台等都在蓬勃发展，人们对电子商务、网络服务的需求也越来越高，而目前市场上智能化客服机器人的应用也日益增多。智能客服机器人和智能推荐系统通过巧妙地理解用户的问题并给出相应的回答或者推荐

    2024年02月07日
    浏览(48)
  • 智能客服机器人：基于知识图谱的多轮对话系统

    智能客服机器人：基于知识图谱的多轮对话系统

    ━━ ━━ 近年来， 随着人工智能的快速发展，人机交互能力不断增强，其中问答技术能够在保证一定准确度的情况下极大地简化用户的搜索操作，在节约时间的同时，还能够加深用户对搜索事物的了解程度，百度公司的小度、苹果公司的Siri等正是基于问答技术形成的产品。

    2024年02月15日
    浏览(63)
  • AI智能客服机器人在医疗健康行业中的应用

    AI智能客服机器人在医疗健康行业中的应用

    随着科技的飞速发展，AI智能客服机器人已经逐渐渗透到我们生活的各个领域，而在医疗健康行业中，它的应用更是为人们带来了很多便利。那么，AI智能客服机器人在医疗健康行业中的应用是怎么样的呢？今天，我们就来一起探讨这个话题，并看看有哪些AI智能客服机器人可

    2024年04月16日
    浏览(40)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包，优惠每天领

二维码1

领取红包

二维码2

领红包