攜程客服機器人ASR引擎的負載均衡實踐

作者：玉修 2023-12-22 10:04:34

本文主要講解了對于ASR引擎做負載均衡的設(shè)計以及實現(xiàn)方案，希望能對從事智能呼叫中心領(lǐng)域工作或研究的同學(xué)們提供一些幫助。

作者簡介

玉修，攜程技術(shù)專家，專注于電話音視頻通信、智能客服機器人等領(lǐng)域。

一、前言

攜程擁有龐大的呼叫中心，涉及上萬客服人員，覆蓋機票、酒店、火車票、度假等產(chǎn)線的售前售后業(yè)務(wù)，每天的電話業(yè)務(wù)量超百萬通。近年來，通信技術(shù)、人工智能技術(shù)和智能終端等都在不斷革新，我們也一直在思考如何去做更智能化、自動化的呼叫中心，為未來海量的客戶需求提供穩(wěn)定和優(yōu)質(zhì)的服務(wù)。

攜程呼叫中心的智能化包含多個方面：

用戶側(cè)：智能在線聊天機器人（IM）、智能語音導(dǎo)航/智能語音客服機器人/智能邀評插件（電話）
客服側(cè)：智能工單和排班系統(tǒng)、智能質(zhì)檢系統(tǒng)、智能客戶資源管理系統(tǒng)、服務(wù)渠道智能化
系統(tǒng)基建：平臺部署智能化、業(yè)務(wù)監(jiān)控智能化

本文旨在探討攜程實現(xiàn)呼叫中心電話智能語音客服機器人的基建服務(wù)——語音識別服務(wù)（即ASR）的負責(zé)均衡的演進歷程，以及最佳實踐。

二、背景

隨著人工智能技術(shù)的發(fā)展，在呼叫中心業(yè)務(wù)中，傳統(tǒng)的 IVR（交互式語音應(yīng)答）按鍵導(dǎo)航模式逐步向IVR智能客服機器人轉(zhuǎn)變（客戶與IVR機器人進行語音對話的方式來辦理業(yè)務(wù)）。攜程呼叫中心系統(tǒng)下的IVR業(yè)務(wù)也在不斷地向電話智能語音機器人轉(zhuǎn)變，目前攜程酒店、機票、火車票的國內(nèi)IVR呼入業(yè)務(wù)，以及IBU國際英語機票的IVR呼入業(yè)務(wù)，已經(jīng)全部由電話智能語音機器人來為客戶提供自助服務(wù)。

下圖是國內(nèi)酒店業(yè)務(wù)場景中，客戶撥打攜程服務(wù)熱線后，客戶與電話機器人通過語音溝通的記錄。可以看出，客戶順利完成了“取消訂單”的業(yè)務(wù)辦理。

智能客服機器人要想實現(xiàn)上圖的交互效果，離不開ASR服務(wù)的使用，以及功能完善且穩(wěn)定的呼叫中心系統(tǒng)的支撐。攜程呼叫中心的整個平臺依賴了眾多組件，底層包括CC-Gateway（語音網(wǎng)關(guān)）、SBC（會話邊際控制服務(wù)）、REG（分機注冊服務(wù)）、SM（會話管理服務(wù)）、RS（呼叫路由服務(wù)）、CM（呼叫管理服務(wù)，基于FreeSWITCH）、ASR（語音識別服務(wù)）等系列服務(wù)。

下圖是攜程呼叫中心，客戶呼入到智能客服機器人場景，進行語音自助業(yè)務(wù)辦理時所涉及的部分核心組件架構(gòu)圖。

從上圖可以看出，攜程呼叫中心系統(tǒng)底層（如FreeSWITCH）調(diào)用實時ASR完成語音識別是基于MRCP協(xié)議來實現(xiàn)的。我們將上圖中涉及ASR使用部分的組件交互進行簡化，得出其包含下面3種組件：

MRCP客戶端：發(fā)送RTP和SIP/MRCP的發(fā)起者，如FreeSWITCH（下文簡稱FS
MRCP服務(wù)端：處理MRCP/SIP信令，接收并轉(zhuǎn)發(fā)RTP
ASR引擎：解析RTP，將語音轉(zhuǎn)換成文本，并返回給MRCP Server

可以發(fā)現(xiàn)，對于呼叫中心ASR調(diào)用者而言，只需要關(guān)心怎么對接MRCP Server即可，無需關(guān)注ASR Engine部分。在實際使用過程中，如果你采購第三方ASR系統(tǒng)進行私有化部署的話（比如科大訊飛ASR、百度ASR），通常MRCP Server和ASR Engine是打包在一起，并部署在同一機器上。

但無論你采購哪家的ASR產(chǎn)品進行集群化部署，廠商都沒有提供ASR的負載均衡解決方案，需要客戶自行解決。攜程為了讓ASR引擎具備更高的可用性，采用了多集群、多IDC、多供應(yīng)商的ASR產(chǎn)品（如攜程自研、百度、阿里、微軟等）來提供服務(wù)。針對這么多的集群和ASR產(chǎn)品，設(shè)計出一個調(diào)度策略和負載均衡方案來合理有效地利用ASR資源就變得極為重要了。

三、方案探索

目標已經(jīng)理清，接下來深入分析調(diào)用ASR涉及的技術(shù)點，看看如何實現(xiàn)目標。

調(diào)用MRCP Server包含SIP（UDP/TCP）、MRCP（TCP）、RTP（UDP）三部分，MRCP和RTP的服務(wù)端地址是由SIP INVITE的響應(yīng) 200 OK中SDP指定（如下圖），所以只要完成對SIP的負載均衡就能解決另外兩個，要給MRCP Server做負載均衡就變成了給 SIP（UDP/TCP）做負載均衡。

我們期望負載均衡的效果是：只要MRCP-Server服務(wù)端集群下有多臺機器，即使客戶端只有一個，負載均衡設(shè)備也能將請求均勻分發(fā)給服務(wù)端的每一個成員。

常規(guī)的負載均衡方案，無外乎基于硬件負載均衡設(shè)備實現(xiàn)，如A10（即AX）、F5、NetScaler等；或者基于軟負載實現(xiàn)，如LVS、Nginx等。但這些常規(guī)方法，都無法真正做到給MRCP Server實現(xiàn)負載均衡。

攜程的基建服務(wù)中，恰好有AX、Netscaler、TDLB相關(guān)負載均衡服務(wù)，所以我們基于這幾種基建服務(wù)都進行過驗證性測試，可惜最終效果都不盡人意。

以FS作為MRCP Client，AX作為負載均衡設(shè)備為例。假如只有1臺FS設(shè)備，1臺AX設(shè)備，4臺MRCP-Server設(shè)備。從FS依次發(fā)起4次請求，或者同時發(fā)起4次請求，最終使ASR駐留并發(fā)達到4個。

上圖是左側(cè)“賣家秀”是我們想要達到的預(yù)期效果，右側(cè)“買家秀”是我們實驗所得的實際效果，所有的請求都被分配到了同一臺MRCP-Server機器上，沒能均勻的分配給集群下的各成員。理想很豐滿，但現(xiàn)實太骨感。

那么，AX設(shè)備沒能做到均勻分配的原因是什么呢？FS基于AX來給MRCP做負載又存在什么弊端呢？

首先，對于FS和AX設(shè)備相對固定的情況下，SIP請求的IP四元組（Source IP、Source port、Destination IP、Destination port）不會發(fā)生變化，因為FS對接MRCP Server時，會在MRCP配置文件中指定客戶端和服務(wù)端的IP/Port，所以AX每次分配給FS的MRCP Server都是同一臺，這顯然不符合負載均衡的預(yù)期。

其次，電話場景，在收到200 OK后，可能長達半小時不會再有SIP交互，期間的MRCP和RTP都是MRCP-Client和MRCP-Server之間進行直連交互，根本不經(jīng)過AX設(shè)備，而AX設(shè)備默認的會話保持時長為120秒，超過這個時間，SIP通道會被AX關(guān)閉，這會導(dǎo)致后續(xù)的SIP無法送達。

既然此路不通，我們要考慮其他解決方案，經(jīng)過深入研究和各種嘗試，認為下面這兩種解決方案比較適合，但各有優(yōu)缺點：

方案A：通過FreeSWITCH的distributor模塊實現(xiàn)
方案B：通過OpenSIPs實現(xiàn)

	優(yōu)點	缺點
方案A	1、無需依賴第三方負載均衡組件	1、配置繁瑣復(fù)雜 2、MRCP Server節(jié)點增刪，都需要調(diào)整FS配置文件，而且得在無ASR業(yè)務(wù)時，才能加載生效 3、端口數(shù)量消耗大(每個MRCP Server都需要單獨分配端口段) 4、負載均衡策略相對單一，只支持按比例分配。而且單機所占有的最小比例不能小于0
方案B	1、配置簡單 2、MRCP Server節(jié)點增刪，只需調(diào)整OpenSIPs的DB即可，有ASR調(diào)用時，也可更改，實時生效 3、端口數(shù)量消耗小（只需要配置一個MRCP Profile文件，多個MRCP Server共用端口段） 4、負載均衡方案多種多樣，支持按比例、輪詢等多種方式	1、需要依賴第三方負載均衡組件OpenSIPs

我們最終將兩個方案結(jié)合，來實現(xiàn)負載均衡，F(xiàn)S上使用distributor模塊來實現(xiàn)對 OpenSIPs做負載均衡，OpenSIPs上再對MRCP-Server做負載均衡，效果如下：

1）FS、OpenSIPs、MRCP-Server三個組件之間實現(xiàn)了IDC優(yōu)先就近訪問（如上所述，F(xiàn)S未能做到100%的就近訪問）。

2）當相同IDC下的下游服務(wù)全部不可用時，則自動將流量分配到其他IDC下，如下圖，IDC-A 下 FS的ASR請求，優(yōu)先請求到 IDC-A 的OpenSIPs，然后IDC-A的OpenSIPs再根據(jù)分配策略，將請求優(yōu)先分配給 IDC-A下的MRCP-Server，如果IDC-A下的MRCP-Server全宕機了，會自動分配給IDC-B下的MRCP-Server。

3）負載均衡服務(wù)可自動檢測下游集群各成員的狀態(tài)，當某成員服務(wù)不可用時自動拉出，服務(wù)狀態(tài)恢復(fù)后，再自動拉入。FS和OpenSIPs都是通過發(fā)送SIP OPTION 來自動探測下游服務(wù)的狀態(tài)。

四、方案實踐

接下來，我們詳細看看每種方案的具體實現(xiàn)方式。以下方案運行環(huán)境為：CentOS 7.6、FreeSWITCH 1.6.20、OpenSIPs 2.4.2。

本篇文章中，我們不詳細講解每種方式的實現(xiàn)原理，只介紹解決方法，有興趣的同學(xué)可以自行學(xué)習(xí)FS和OpenSIPs的相關(guān)功能點，這里給出幾個鏈接：

mod_unimrcp
mod_distributor
mod_dptools: play_and_detect_speech
Load Balancer Module
Dispatcher Module
Dialplan Module

假設(shè)我們只有一臺FS作為MRCP 客戶端，并且MRCP Server 集群中有兩臺服務(wù)器，分別是 mrcp1 和 mrcp2，希望FS針對每一通電話執(zhí)行ASR命令時，請求可均勻分配給兩個MRCP Server。

4.1 基于FS的distributor模塊實現(xiàn)MRCP Server的LB

該方案的核心思路如下：

1）FS直接與MRCP Server對接，為MRCP Server集群下每一個成員配置一個profile

2）將MRCP Server集群下的所有成員配置成 FS 的網(wǎng)關(guān)，并開啟網(wǎng)關(guān)的SIP OPTION探測功能，同時確保gateway的name要與mrcp_profile文件中profile的name一致

3）通過FS的distributor 模塊為這些MRCP網(wǎng)關(guān)配置負載均衡策略

4）最后，實際執(zhí)行ASR命令時，先通過 expand eval ${distributor mrcp ${sofia profile external gwlist down}} 負載均衡分配得到一個可用的 MRCP Server Profile的名稱，然后用該MRCP Profile的名稱作為FS play_and_detect_speech ASR命令的參數(shù)即可。

詳細的配置步驟如下所示：

第一步：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" versinotallow="2">   【每個MRCP Server這里配置的名稱都不一樣，但一定有一個相同名稱的網(wǎng)關(guān)】
    <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網(wǎng)關(guān)

在 /usr/local/freeswitch/conf/sip_profiles/external/下配置網(wǎng)關(guān)對接文件
/usr/local/freeswitch/conf/sip_profiles/external
├── mrcp1.xml
└── mrcp2.xml

mrcp1.xml 的詳細配置如下：

<gateway name="mrcp1">  【gateway的name要與mrcp_profile文件中profile的name一致，或可以按照某種規(guī)則轉(zhuǎn)換】
        <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對應(yīng)地址發(fā)送探測的周期】
        <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" descriptinotallow="Distributor Configuration">
  <lists>
    <list name="mrcp">  【權(quán)重配置成一樣，相當于兩個MCRP server 按 1:1 分配】
      <node name="mrcp1" weight="5"/>  【node name值與sip gateway 名稱相同】
      <node name="mrcp2" weight="5"/>
    </list>
  </lists>
</configuration>

最后，來看看使用效果。按照上述配置，將mrcp2服務(wù)宕機后，執(zhí)行負載均衡的效果如下：

freeswitch@LPT0596> sofia profile external gwlist down   【獲取宕機的網(wǎng)關(guān)】
mrcp2
freeswitch@LPT0596> expand eval ${distributor mrcp ${sofia profile external gwlist down}}   【將宕機的網(wǎng)關(guān)排除在外后，獲取分配的SM節(jié)點】
mrcp1
freeswitch@LPT0596> expand eval ${distributor mrcp ${sofia profile external gwlist down}}   【如果mrcp2沒有宕機，這里將返回mrcp2】
mrcp1


使用得到的MRCP Server Profile名稱執(zhí)行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相關(guān)命令：

reload mod_unimrcp : 修改FS與MRCP server對接的文件后，重新加載生效【只有當前沒有正在執(zhí)行的ASR操作時，才能重加載】
sofia profile external rescan : 重新加載FS的網(wǎng)關(guān)配置

4.2 基于OpenSIPs實現(xiàn)MRCP Server的LB

4.2.1 核心思路

FS不直接與MRCP Server對接，而是與OpenSIPs進行對接。對接方式是把OpenSIPs配置成一個MRCP profile，文件中的server-ip 和 server-port 地址配置成OpenSIPS 的服務(wù)地址即可。

FS執(zhí)行ASR命令時，先將SIP請求發(fā)送給OpenSIPs，再由OpenSIPs負載均衡到MRCP Server集群中的成員，交互的時序圖如下：

4.2.2 方案分析

通過OpenSIPs來實現(xiàn)對MRCP的負載均衡需要解決下面幾個問題：

問題1、如何判斷收到的INVITE請求是要執(zhí)行ASR命令，還是普通呼叫命令？

問題2、知道是執(zhí)行ASR命令后，如何選擇MRCP Server，進行分配？

問題3、如果有多套MRCP Server集群，比如一套百度MRCP，一套阿里MRCP，客戶端希望能指定引擎使用，該如何解決？

既然已經(jīng)明確了問題點，那咱就各個擊破即可，下面是各問題點的解決方法：

問題1的解決方法

我們來看一條FS發(fā)送給OpenSIPs，請求執(zhí)行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

從上面信令可以看到，F(xiàn)S發(fā)起的INVITE中，沒有主被叫號碼信息，只有FS和OpenSIPs的IP和端口信息。如果我們的OpenSIPs只用來給MRCP Server做負載均衡，那么就很簡單，收到INVITE請求，都認為是請求執(zhí)行ASR命令，分配給MRCP Server即可。但是，OpenSIPs只給MRCP Server做負載豈不是大材小用了！

所以，實際我們不會這樣使用，OpenSIPs通常還會給其他呼叫中心組件做負載均衡，比如給FreeSWITCH、語音網(wǎng)關(guān)、分機注冊服務(wù)等做LB。這樣OpenSIPs就會收到來自各種組件的SIP INVITE請求。那么該如何判斷收到的 INVITE 是要執(zhí)行ASR命令，還是要做其他業(yè)務(wù)呢？

常規(guī)思路，自然是OpenSIPs分析INVITE的SIP消息頭，從中進行判斷。可是由于FS的mod_unimrcp模塊的限制，F(xiàn)S執(zhí)行ASR命令時，發(fā)送的SIP INVITE里不支持增加自定義SIP消息頭，所以只能從標準 SIP 消息頭中進行挖掘。

根據(jù)INVITE請求的源IP：不可行，因為同一個源IP可能發(fā)起多種請求的INVITE，比如FS可能是請求執(zhí)行ASR，也可能是請求呼叫手機；此外，即使可行，源IP也不方便維護。
根據(jù)INVITE請求的目的IP：不可行，所有INVITE請求的該值都一樣
根據(jù)INVITE請求的User-Agent頭：可行，OpenSIPs通過$ua就能獲取該值。雖然不能針對每次INVITE自定義不同的UA頭，但FS對接MRCP Server的Profile中可以指定一個統(tǒng)一的User-Agent頭，默認是FreeSWITCH。
根據(jù)INVITE請求SDP信息中的‘m’頭：可行，OpenSIPs通過$(rb{sdp.line,m})就能獲取該值。如上面報文中“m=application 9 TCP/MRCPv2 1” 里面有MRCPv2，可根據(jù)這個判斷是執(zhí)行ASR。

建議使用User-Agent頭進行區(qū)分，取值方便，效率高。所以，F(xiàn)S對接OpenSIPs時，配置的MRCP Profile時，指定一個特別的User-Agent，比如叫ASR_MRCP_CLIENT_FS，OpenSIPs收到INVITE請求，優(yōu)先判斷UA信息，如果是ASR_MRCP_CLIENT_FS，那么就是要執(zhí)行ASR命令。

問題2的解決方法

可以使用OpenSIPS的load_balancer 或 dispatcher 模塊來實現(xiàn)對 MRCP Server 服務(wù)端的負載均衡，兩種方式的特點如下：

如果MRCP-Server集群下的成員可支持的并發(fā)數(shù)不一樣，想做到哪臺機器剩余的可用資源最多，就優(yōu)先分配給誰，當各成員可用資源數(shù)相同時，在輪訓(xùn)分配，那么可以使用 load_balancer 模塊來實現(xiàn)負載均衡；

如果MRCP-Server集群下的成員可支持的并發(fā)數(shù)完全一樣，無差別，那么建議使用dispatcher模塊來試想負載均衡，可以做到均勻的將請求分配給每一臺服務(wù)器。

	優(yōu)點	缺點
load_balancer	可控制每個MRCP Server的最大并發(fā)量支持監(jiān)控分配給每個MRCP Server的實時并發(fā)量	分配策略單一：只支持空閑優(yōu)先策略分配和按比例分配兩種策略，無法支持記憶輪訓(xùn)，這就導(dǎo)致但MRCP Server集群新增成員時，會將流量全部分配給新增的機器，這種情況，新機器的突增壓力可能較大
dispatcher	分配策略多種多樣：如支持記憶輪訓(xùn)、Hash分配等	不能控制每個MRCP Server的最大并發(fā)量，話務(wù)量暴漲時，存在雪崩隱患不能監(jiān)控分配給每個MRCP Server的實時并發(fā)量（但可以自行通過OpenSIPs其他模塊實現(xiàn)）

問題3的解決方法

在FS上為每一套MRCP Server集群，配置一個MRCP Profile并且都指向OpenSIPs，但User-Agent的值配置成不一樣，OpenSIPs根據(jù)UA的不同，來選擇該給哪個集群做LB。

baidu_mrcp_lb.xml  下面只給出特有配置，其他配置被省略了
<include>
  <profile name="baidu_mrcp_lb" versinotallow="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模塊進行選擇具體通過哪個模塊來執(zhí)行LB。

4.2.3 具體實現(xiàn)

如果OpenSIPs本身也是集群化部署，那么可以通過本文3.1章節(jié)的方法實現(xiàn)對OpenSIPs的負載均衡。

下面代碼涉及OpenSIPs對dialplan、dispatcher、load_balancer幾個模塊的使用，本文不講解這部分的使用方法。

數(shù)據(jù)庫初始化

說明：

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

2）OpenSIPs根據(jù)dialplan撥號方案來為阿里和百度選擇負載均衡的方式，dialplan表中字段“attrs”配置邏輯是：[MRCP集群第一路由的集群ID:負載均衡實現(xiàn)方式:集群名稱]，如“90:DS:ASR_MRCP_SERVER_CTRIP_ALI”代表，阿里MRCP第一路由的集群ID是90，采用dispacher模塊實現(xiàn)LB；"90:DS:ASR_MRCP_SERVER_CTRIP_ALI”代表，百度MRCP第一路由的集群ID是91，采用load_balancer模塊實現(xiàn)LB

3）無論是dispacher，還是load_balancer，都配置了單IDC下負載均衡的基礎(chǔ)上，增加了逃生路由的功能。集群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字段可以控制最大并發(fā)數(shù)
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');

配置好后，可查看集群內(nèi)MRCP成員的狀態(tài)：

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代碼實現(xiàn)

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 發(fā)起的 MRCP INVITE 請求， $rU 為 null, 而不設(shè)置 $rU 將導(dǎo)致 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();
    }


}

如果按照上面腳本執(zhí)行了 $ru = "sip:" + $rU + "@" + $(du{uri.host}) + ":" + $dp;，但是$rU== null 并且不設(shè)置 $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）設(shè)置$rU 為一個非空值

2）直接不修改$ru 的值

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

4.2.4 信令記錄：

FS 發(fā)送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 轉(zhuǎn)發(fā)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 回復(fù)200 OK，返回后續(xù)接收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發(fā)送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轉(zhuǎn)發(fā)給MRCP Server

五、結(jié)語

從上文中提到的攜程呼叫中心客戶呼入到智能客服機器人場景的核心組件架構(gòu)圖可以看出，ASR引擎的負載均衡只是攜程呼叫中心平臺各組件中很小的一個功能點，但也是不可或缺的一部分。

正因為有了這個技術(shù)方案的實現(xiàn)，使得多集群、多數(shù)據(jù)中心、多供應(yīng)商的ASR產(chǎn)品得以很好地整合，為攜程電話智能客服機器人業(yè)務(wù)的穩(wěn)定運行提供了良好的技術(shù)保障，提升了攜程客戶的通話體驗。

本文主要講解了對于ASR引擎做負載均衡的設(shè)計以及實現(xiàn)方案，希望能對從事智能呼叫中心領(lǐng)域工作或研究的同學(xué)們提供一些幫助。

責(zé)任編輯：張燕妮來源：攜程技術(shù)

攜程負載均衡引擎