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

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

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

作者簡介

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

一、前言

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

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

用戶側：智能在線聊天機器人（IM）、智能語音導航/智能語音客服機器人/智能邀評插件（電話）
客服側：智能工單和排班系統、智能質檢系統、智能客戶資源管理系統、服務渠道智能化
系統基建：平臺部署智能化、業務監控智能化

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

二、背景

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

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

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

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

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

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

可以發現，對于呼叫中心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服務端集群下有多臺機器，即使客戶端只有一個，負載均衡設備也能將請求均勻分發給服務端的每一個成員。

常規的負載均衡方案，無外乎基于硬件負載均衡設備實現，如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個。

上圖是左側“賣家秀”是我們想要達到的預期效果，右側“買家秀”是我們實驗所得的實際效果，所有的請求都被分配到了同一臺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 來自動探測下游服務的狀態。

四、方案實踐

接下來，我們詳細看看每種方案的具體實現方式。以下方案運行環境為：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" versinotallow="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" descriptinotallow="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集群中的成員，交互的時序圖如下：

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" 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模塊進行選擇具體通過哪個模塊來執行LB。

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產品得以很好地整合，為攜程電話智能客服機器人業務的穩定運行提供了良好的技術保障，提升了攜程客戶的通話體驗。