背景
隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展和網(wǎng)絡(luò)的普及，線上告警已經(jīng)由早期的短信/郵件通知發(fā)展為微信/電話語音等方式，由于短信/郵件等告警方式存在延時問題，不能及時告知被通知對象，業(yè)內(nèi)開始流行將服務(wù)器接收到的告警內(nèi)容通過TTS（語音合成）合成語音后告知用戶，用戶按鍵選擇主動處理或移交給其他負(fù)責(zé)人，智能語音機器人基于TTS和SIP實現(xiàn)了語音播報功能與按鍵識別功能的結(jié)合，應(yīng)用于58運維告警以更及時、更便捷、更多元的方式通知開發(fā)維護人員，并將此功能應(yīng)用于校招邀約等場景，代替或輔助人工完成一些流程固定的工作，可以有效地節(jié)省成本提高人效，如圖1.
圖1使用場景
整體流程
智能語音機器人基于SIP線路實現(xiàn)的呼出場景下，用戶電話按鍵信號捕獲需要借助SIP線路實現(xiàn)，整體流程如圖2，在代理終端A（用戶）與代理終端B（機器人）持續(xù)通話的過程中，用戶會持續(xù)向機器人發(fā)送媒體流，機器人在接收媒體流時會判斷當(dāng)前流屬于語音流還是按鍵信號，如果當(dāng)前流屬于語音流則經(jīng)過語音解碼器，如果是按鍵信號則經(jīng)過按鍵信號識別模塊，最終產(chǎn)生語音數(shù)據(jù)/按鍵信息再做下一步處理。
圖2整體流程
如何傳輸
1、按鍵信號如何傳輸
目前所有的電話和傳真機按鍵都采用DTMF信號進行編碼和傳輸，DTMF信號是利用模擬信號對數(shù)字符號進行編碼，該編碼方案共使用8個模擬頻率對16個符號進行編碼，分為高音群和低音群，所以稱為雙音多頻（Dual-ToneMultiple-Frequency）編碼，每個符號由一個高音頻率和一個低音頻率唯一確定（0~9*#ABCD），如圖3.
圖3DTMF信號編碼
2、SIP如何檢測DTMF信號
目前傳輸DTMF信號主要有三個方式：通過通信協(xié)議傳輸（SIPINFO）、遵循RFC2833規(guī)范傳輸、通過RTP的數(shù)據(jù)內(nèi)容傳輸（INBAND）。
1）SIPINFO
通過SIP信令I(lǐng)NFO包中的signal字段攜帶DTMF信號傳輸，這種方式的好處是不影響RTP數(shù)據(jù)包的傳輸，但SIP信令和媒體傳輸是分開的，很容易造成DTMF信號和媒體包不同步。
2）RFC2833
通信前使用SDP協(xié)議協(xié)商telephone-event參數(shù)，通過RTP包傳輸，由RTP包包頭的PT（payloadtype）來標(biāo)示RFC2833的數(shù)據(jù)包（如圖4）。
3）INBAND
將DTMF信號不經(jīng)任何處理直接打成RTP包與普通的RTP語音包混在一起傳輸，要獲得DTMF信號則必須提取RTP數(shù)據(jù)包進行頻譜分析，得到高頻和低頻的頻率，然后查表得到對應(yīng)的按鍵。
圖4RTP包格式
如何識別
綜合考慮，遵循RFC2833規(guī)范實現(xiàn)基于SIP的電話按鍵信號識別成本最低，下面將詳細介紹下SIP會話如何建立，媒體如何協(xié)商、基于會話和媒體協(xié)商結(jié)果如何實現(xiàn)電話按鍵信號的解析。
1、會話建立
SIP（Session Initiation Protocol）是一種信令協(xié)議，用于初始化、管理和終止網(wǎng)絡(luò)語音和視頻會話，如圖5，終端代理A為主叫代理，終端代理B為被叫代理，A與B的會話建立流程如下：
1）A先發(fā)送INVITE請求至代理服務(wù)器（一般為SIP運營商提供），代理服務(wù)器將INVITE請求轉(zhuǎn)發(fā)給B；
2）代理服務(wù)器給A返回呼叫處理中的100TRYING應(yīng)答消息；
3）B向代理服務(wù)器發(fā)送呼叫處理中的100TRYING應(yīng)答消息；
4）B發(fā)現(xiàn)用戶振鈴后，向代理服務(wù)器發(fā)送180RINGING振鈴消息，代理服務(wù)器收到后轉(zhuǎn)發(fā)給A；
5）B發(fā)現(xiàn)用戶接聽后，向代理服務(wù)器發(fā)送200OK消息表示連接成功，代理服務(wù)器將200OK轉(zhuǎn)發(fā)給A；
6）A收到請求后，發(fā)送ACK消息進行確認(rèn)，代理服務(wù)器再將ACK消息轉(zhuǎn)發(fā)給B；
7）主被叫用戶之間建立通信連接，開始通信；
圖5SIP信令交互
2、媒體協(xié)商
SDP（Session Description Protocol）協(xié)議主要用于兩個會話實體的媒體協(xié)商，描述會話所使用的的流媒體細節(jié)，協(xié)議格式如圖6，以<type>=<value>形式存儲，其中：
1）c表示連接信息，用于約定IP協(xié)議版本、IP地址等信息；
2）a表示會話信息，用于約定會話使用的編解碼器、按鍵事件（telephone-event）的RTP包包頭等信息；
3）m表示媒體信息，用于約定會話為音頻或視頻通話、接收媒體流的端口等信息；
圖6SDP協(xié)議格式
主被叫通過SDP協(xié)議協(xié)商媒體信息流程如下：
1）在會話建立過程中，主叫向被叫發(fā)送INVITE請求時攜帶SDP協(xié)議，約定主叫接收媒體流的IP地址及端口、編解碼器、按鍵事件等信息；
2）在被叫給主叫回復(fù)180RINGING振鈴消息時攜帶SDP協(xié)議，同樣也約定了被叫的相關(guān)信息；
3）主被叫通信建立，按照SDP協(xié)議約定的媒體信息進行通信；
3、按鍵信號解析
遵循RFC2833規(guī)范，按鍵DTMF信號使用RTP包發(fā)送，通過RTP包頭PT（payloadtype）來標(biāo)示RFC2833數(shù)據(jù)包，基于以上信息并參考圖6中SDP協(xié)議約定信息（a=rtpmap:126telephone-event/8000）可將按鍵解析步驟總結(jié)如下：
1）在接收RTP包時，當(dāng)包頭PT=126時，RTP包體中存儲的內(nèi)容即為按鍵信息；
2）由于RTP是基于UDP協(xié)議封裝的，為了防止丟包，同一個按鍵信號會產(chǎn)生多個RTP包且包頭中Timestamp相同，我們可根據(jù)包頭的時間戳去重；
3）至此我們就可以成功解析基于SIP的電話按鍵信號；
圖7按鍵解析
58同城TEG技術(shù)工程平臺群AILab，旨在推動AI技術(shù)在58生活服務(wù)行業(yè)的落地，打造AI中臺能力，以提高前臺業(yè)務(wù)的人效和用戶體驗。AILab目前負(fù)責(zé)的產(chǎn)品包括：智能客服、語音機器人、智能寫稿、AI算法平臺、智能語音分析平臺、語音識別引擎等，未來將持續(xù)加速創(chuàng)新，拓展AI應(yīng)用。
58同城TEG技術(shù)工程平臺群AILab，旨在推動AI技術(shù)在58生活服務(wù)行業(yè)的落地，打造AI中臺能力，以提高前臺業(yè)務(wù)的人效和用戶體驗。AILab目前負(fù)責(zé)的產(chǎn)品包括：智能客服、語音機器人、智能寫稿、AI算法平臺、智能語音分析平臺、語音識別引擎等，未來將持續(xù)加速創(chuàng)新，拓展AI應(yīng)用。
【作者介紹】
李鴻勛，58同城AILab資深后端工程師，2017年加入58同城，目前主要負(fù)責(zé)智能語音機器人后端架構(gòu)設(shè)計和研發(fā)，曾先后從事58同城推薦系統(tǒng)、智能客服系統(tǒng)后端研發(fā)工作。
