背景

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

圖1使用場(chǎng)景

　　整體流程

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

圖2整體流程

　　如何傳輸

　　1、按鍵信號(hào)如何傳輸

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

圖3DTMF信號(hào)編碼

　　2、SIP如何檢測(cè)DTMF信號(hào)

　　目前傳輸DTMF信號(hào)主要有三個(gè)方式：通過通信協(xié)議傳輸（SIPINFO）、遵循RFC2833規(guī)范傳輸、通過RTP的數(shù)據(jù)內(nèi)容傳輸（INBAND）。

　　1）SIPINFO

　　通過SIP信令I(lǐng)NFO包中的signal字段攜帶DTMF信號(hào)傳輸，這種方式的好處是不影響RTP數(shù)據(jù)包的傳輸，但SIP信令和媒體傳輸是分開的，很容易造成DTMF信號(hào)和媒體包不同步。

　　2）RFC2833

　　通信前使用SDP協(xié)議協(xié)商telephone-event參數(shù)，通過RTP包傳輸，由RTP包包頭的PT（payloadtype）來標(biāo)示RFC2833的數(shù)據(jù)包（如圖4）。

　　3）INBAND

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

圖4RTP包格式

　　如何識(shí)別

　　綜合考慮，遵循RFC2833規(guī)范實(shí)現(xiàn)基于SIP的電話按鍵信號(hào)識(shí)別成本最低，下面將詳細(xì)介紹下SIP會(huì)話如何建立，媒體如何協(xié)商、基于會(huì)話和媒體協(xié)商結(jié)果如何實(shí)現(xiàn)電話按鍵信號(hào)的解析。

　　1、會(huì)話建立

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

　　1）A先發(fā)送INVITE請(qǐng)求至代理服務(wù)器（一般為SIP運(yùn)營商提供），代理服務(wù)器將INVITE請(qǐng)求轉(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收到請(qǐng)求后，發(fā)送ACK消息進(jìn)行確認(rèn)，代理服務(wù)器再將ACK消息轉(zhuǎn)發(fā)給B；

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

圖5SIP信令交互

　　2、媒體協(xié)商

　　SDP（Session Description Protocol）協(xié)議主要用于兩個(gè)會(huì)話實(shí)體的媒體協(xié)商，描述會(huì)話所使用的的流媒體細(xì)節(jié)，協(xié)議格式如圖6，以type>=value>形式存儲(chǔ)，其中：

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

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

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

圖6SDP協(xié)議格式

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

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

　　2）在被叫給主叫回復(fù)180RINGING振鈴消息時(shí)攜帶SDP協(xié)議，同樣也約定了被叫的相關(guān)信息；

　　3）主被叫通信建立，按照SDP協(xié)議約定的媒體信息進(jìn)行通信；

　　3、按鍵信號(hào)解析

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

　　1）在接收RTP包時(shí)，當(dāng)包頭PT=126時(shí)，RTP包體中存儲(chǔ)的內(nèi)容即為按鍵信息；

　　2）由于RTP是基于UDP協(xié)議封裝的，為了防止丟包，同一個(gè)按鍵信號(hào)會(huì)產(chǎn)生多個(gè)RTP包且包頭中Timestamp相同，我們可根據(jù)包頭的時(shí)間戳去重；

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

圖7按鍵解析

　　58同城TEG技術(shù)工程平臺(tái)群AILab，旨在推動(dòng)AI技術(shù)在58生活服務(wù)行業(yè)的落地，打造AI中臺(tái)能力，以提高前臺(tái)業(yè)務(wù)的人效和用戶體驗(yàn)。AILab目前負(fù)責(zé)的產(chǎn)品包括：智能客服、語音機(jī)器人、智能寫稿、AI算法平臺(tái)、智能語音分析平臺(tái)、語音識(shí)別引擎等，未來將持續(xù)加速創(chuàng)新，拓展AI應(yīng)用。

　　58同城TEG技術(shù)工程平臺(tái)群AILab，旨在推動(dòng)AI技術(shù)在58生活服務(wù)行業(yè)的落地，打造AI中臺(tái)能力，以提高前臺(tái)業(yè)務(wù)的人效和用戶體驗(yàn)。AILab目前負(fù)責(zé)的產(chǎn)品包括：智能客服、語音機(jī)器人、智能寫稿、AI算法平臺(tái)、智能語音分析平臺(tái)、語音識(shí)別引擎等，未來將持續(xù)加速創(chuàng)新，拓展AI應(yīng)用。

　　【作者介紹】

　　李鴻勛，58同城AILab資深后端工程師，2017年加入58同城，目前主要負(fù)責(zé)智能語音機(jī)器人后端架構(gòu)設(shè)計(jì)和研發(fā)，曾先后從事58同城推薦系統(tǒng)、智能客服系統(tǒng)后端研發(fā)工作。