呼叫中心架構設計

背景

• 客戶在打電話給客服（坐席）時需要保護自己的隱私（客戶電話號碼不能透傳給客服）
• 客服在打電話給客戶時可根據(jù)實際對應業(yè)務來設定是否進行號碼透傳（大部分場景是透傳）
• 對一些業(yè)務提供基礎數(shù)據(jù)的支撐（通話開始時間、結束時間、錄音等）
• 不建立真正的呼叫中心，而是接入多個第三方提供的云通話服務完成實際通話過程，降低成本和風險

為此我們需要實現(xiàn)一個能夠能夠支撐業(yè)務實現(xiàn)并能夠接入多個云通話服務渠道的系統(tǒng)，命名為 CC（Call Center，呼叫中心）。

架構設計

從呼叫模式上看，目前業(yè)界大多數(shù)采用的是“回撥”模式，即由呼叫中心發(fā)起兩路呼叫，然后將兩路進行連通。提供回撥服務的廠商比較多，比如玖云、華為、吉亞等，下面以玖云和華為為例進行架構設計。（選擇玖云和華為主要是因為他們正好使用了不同的兩種通話狀態(tài)獲取模式，玖云是回調，而華為是輪詢）

（圖片看不清的話請另存為后查看）

子模塊

• Callback Logging：玖云事件回調持久化，實現(xiàn)上使用 NGINX 寫文件日志
• Scheduled Task：華為事件輪詢
• Dispatch & Handle：處理來自 Callback Logging 和 Scheduled Task 的通話事件
• Unified Call Records：統(tǒng)一格式的通過記錄持久化存儲
• Channel：提供給應用調用，完成“用戶-坐席-渠道”的關聯(lián)管理功能
• User-Agent-Channel：“用戶-坐席-渠道”持久化存儲
• Call：提供給應用調用，完成“回撥”功能
• Call Query：提供給應用調用，完成通話數(shù)據(jù)查詢功能
• Health：渠道及回調日志健康狀態(tài)檢查，以及渠道故障時讓 Channel 自動切換渠道
• Aliyun OSS：將獲取到的通話錄音上傳到阿里云 OSS 進行存儲

通話記錄表

回撥流程

1. 應用發(fā)起回撥請求，調用 Call
2. Call 調用 Channel，有 Channel 選擇適合的渠道，并通過公網(wǎng) HTTP(S) 進行回撥請求

3. 由渠道通過 PSTN 實現(xiàn)電話呼叫：
   3.1 呼叫 A 路（客服），A 路摘機
   3.2 呼叫 B 路（客戶），客戶摘機
   3.3 A-B 接通進行通話
   3.4 通話結束（A/B 掛斷或異常）

   • 在此期間需要接收事件回調（玖云）或進行事件輪詢（華為）并持久化通話狀態(tài)，最終形成統(tǒng)一格式的通話記錄
   • 回撥接口參數(shù)中可以帶上業(yè)務實體標識，以便將通話記錄和業(yè)務實體進行關聯(lián)對應
   • 回撥接口的返回值中會返回一個 callId，用來表示該次回撥，以便將通話記錄和業(yè)務實體進行關聯(lián)對應
   • 在通話期間，應用可以使用 callId 來輪詢 CC 查看通話狀態(tài)

用戶-坐席-渠道

這個模型用于描述業(yè)務系統(tǒng)中的用戶實體以及坐席（可以理解為渠道提供的通話線路，同一時刻同一個線路只能有一通電話在撥打）的關聯(lián)，并卻定了這個用戶所使用的通話渠道。

• 對于玖云，坐席對應的是電話號碼
• 對于華為，坐席對應的是坐席號

默認情況下并不需要指定關聯(lián)，CC 會自動選擇渠道，只有在某些業(yè)務場景下需要應用來指定渠道。

呼叫中心系統(tǒng)方面技術交流： 515229

標簽：馬鞍山 安慶 淮南 十堰 宜昌