背景

　　隨著互聯網技術的發展和網絡的普及，線上告警已經由早期的短信/郵件通知發展為微信/電話語音等方式，由于短信/郵件等告警方式存在延時問題，不能及時告知被通知對象，業內開始流行將服務器接收到的告警內容通過TTS（語音合成）合成語音后告知用戶，用戶按鍵選擇主動處理或移交給其他負責人，智能語音機器人基于TTS和SIP實現了語音播報功能與按鍵識別功能的結合，應用于58運維告警以更及時、更便捷、更多元的方式通知開發維護人員，并將此功能應用于校招邀約等場景，代替或輔助人工完成一些流程固定的工作，可以有效地節省成本提高人效，如圖1.

圖1使用場景

　　整體流程

　　智能語音機器人基于SIP線路實現的呼出場景下，用戶電話按鍵信號捕獲需要借助SIP線路實現，整體流程如圖2，在代理終端A（用戶）與代理終端B（機器人）持續通話的過程中，用戶會持續向機器人發送媒體流，機器人在接收媒體流時會判斷當前流屬于語音流還是按鍵信號，如果當前流屬于語音流則經過語音解碼器，如果是按鍵信號則經過按鍵信號識別模塊，最終產生語音數據/按鍵信息再做下一步處理。

圖2整體流程

　　如何傳輸

　　1、按鍵信號如何傳輸

　　目前所有的電話和傳真機按鍵都采用DTMF信號進行編碼和傳輸，DTMF信號是利用模擬信號對數字符號進行編碼，該編碼方案共使用8個模擬頻率對16個符號進行編碼，分為高音群和低音群，所以稱為雙音多頻（Dual-ToneMultiple-Frequency）編碼，每個符號由一個高音頻率和一個低音頻率唯一確定（0~9*#ABCD），如圖3.

圖3DTMF信號編碼

　　2、SIP如何檢測DTMF信號

　　目前傳輸DTMF信號主要有三個方式：通過通信協議傳輸（SIPINFO）、遵循RFC2833規范傳輸、通過RTP的數據內容傳輸（INBAND）。

　　1）SIPINFO

　　通過SIP信令INFO包中的signal字段攜帶DTMF信號傳輸，這種方式的好處是不影響RTP數據包的傳輸，但SIP信令和媒體傳輸是分開的，很容易造成DTMF信號和媒體包不同步。

　　2）RFC2833

　　通信前使用SDP協議協商telephone-event參數，通過RTP包傳輸，由RTP包包頭的PT（payloadtype）來標示RFC2833的數據包（如圖4）。

　　3）INBAND

　　將DTMF信號不經任何處理直接打成RTP包與普通的RTP語音包混在一起傳輸，要獲得DTMF信號則必須提取RTP數據包進行頻譜分析，得到高頻和低頻的頻率，然后查表得到對應的按鍵。

圖4RTP包格式

　　如何識別

　　綜合考慮，遵循RFC2833規范實現基于SIP的電話按鍵信號識別成本最低，下面將詳細介紹下SIP會話如何建立，媒體如何協商、基于會話和媒體協商結果如何實現電話按鍵信號的解析。

　　1、會話建立

　　SIP（Session Initiation Protocol）是一種信令協議，用于初始化、管理和終止網絡語音和視頻會話，如圖5，終端代理A為主叫代理，終端代理B為被叫代理，A與B的會話建立流程如下：

　　1）A先發送INVITE請求至代理服務器（一般為SIP運營商提供），代理服務器將INVITE請求轉發給B；

　　2）代理服務器給A返回呼叫處理中的100TRYING應答消息；

　　3）B向代理服務器發送呼叫處理中的100TRYING應答消息；

　　4）B發現用戶振鈴后，向代理服務器發送180RINGING振鈴消息，代理服務器收到后轉發給A；

　　5）B發現用戶接聽后，向代理服務器發送200OK消息表示連接成功，代理服務器將200OK轉發給A；

　　6）A收到請求后，發送ACK消息進行確認，代理服務器再將ACK消息轉發給B；

　　7）主被叫用戶之間建立通信連接，開始通信；

圖5SIP信令交互

　　2、媒體協商

　　SDP（Session Description Protocol）協議主要用于兩個會話實體的媒體協商，描述會話所使用的的流媒體細節，協議格式如圖6，以type>=value>形式存儲，其中：

　　1）c表示連接信息，用于約定IP協議版本、IP地址等信息；

　　2）a表示會話信息，用于約定會話使用的編解碼器、按鍵事件（telephone-event）的RTP包包頭等信息；

　　3）m表示媒體信息，用于約定會話為音頻或視頻通話、接收媒體流的端口等信息；

圖6SDP協議格式

　　主被叫通過SDP協議協商媒體信息流程如下：

　　1）在會話建立過程中，主叫向被叫發送INVITE請求時攜帶SDP協議，約定主叫接收媒體流的IP地址及端口、編解碼器、按鍵事件等信息；

　　2）在被叫給主叫回復180RINGING振鈴消息時攜帶SDP協議，同樣也約定了被叫的相關信息；

　　3）主被叫通信建立，按照SDP協議約定的媒體信息進行通信；

　　3、按鍵信號解析

　　遵循RFC2833規范，按鍵DTMF信號使用RTP包發送，通過RTP包頭PT（payloadtype）來標示RFC2833數據包，基于以上信息并參考圖6中SDP協議約定信息（a=rtpmap:126telephone-event/8000）可將按鍵解析步驟總結如下：

　　1）在接收RTP包時，當包頭PT=126時，RTP包體中存儲的內容即為按鍵信息；

　　2）由于RTP是基于UDP協議封裝的，為了防止丟包，同一個按鍵信號會產生多個RTP包且包頭中Timestamp相同，我們可根據包頭的時間戳去重；

　　3）至此我們就可以成功解析基于SIP的電話按鍵信號；

圖7按鍵解析

　　58同城TEG技術工程平臺群AILab，旨在推動AI技術在58生活服務行業的落地，打造AI中臺能力，以提高前臺業務的人效和用戶體驗。AILab目前負責的產品包括：智能客服、語音機器人、智能寫稿、AI算法平臺、智能語音分析平臺、語音識別引擎等，未來將持續加速創新，拓展AI應用。

　　58同城TEG技術工程平臺群AILab，旨在推動AI技術在58生活服務行業的落地，打造AI中臺能力，以提高前臺業務的人效和用戶體驗。AILab目前負責的產品包括：智能客服、語音機器人、智能寫稿、AI算法平臺、智能語音分析平臺、語音識別引擎等，未來將持續加速創新，拓展AI應用。

　　【作者介紹】

　　李鴻勛，58同城AILab資深后端工程師，2017年加入58同城，目前主要負責智能語音機器人后端架構設計和研發，曾先后從事58同城推薦系統、智能客服系統后端研發工作。