- 如何通過SBC實(shí)現(xiàn)公網(wǎng)注冊(cè)SIP話機(jī)演示，實(shí)現(xiàn)聯(lián)通COP對(duì)接通話
- 圖解邊界會(huì)話控制器（SBC）的20個(gè)最常用功能
- SIP系列講座-邊界會(huì)話控制器-SBC全面剖析
- 基于OpenSIPS實(shí)現(xiàn)電話錄音解決方案探討
為了進(jìn)一步完善SIP呼叫錄音的討論，今天，筆者在以前的錄音分享技術(shù)討論的基礎(chǔ)上，進(jìn)一步討論一些和SIP電話呼叫中的一些非常細(xì)節(jié)的說明和其相關(guān)的行業(yè)規(guī)范，通過規(guī)范和解決方案的示例討論，讀者獲得更多關(guān)于SIP呼叫錄音的技術(shù)策略和部署方式。
更多技術(shù)分享，關(guān)注SIP技術(shù)學(xué)習(xí)
筆者這里主要討論的內(nèi)容包括：錄音解決方案背景介紹，關(guān)于SIPREC的技術(shù)細(xì)節(jié)說明（Session Recording Protocol），相關(guān)技術(shù)架構(gòu)討論，基于SIP的媒體錄音場景規(guī)范（SIPREC）以及數(shù)據(jù)規(guī)范的討論，SBC對(duì)SIPREC的支持和以及其他問題討論。
1、錄音解決方案背景介紹
呼叫中心或IPPBX是幫助企業(yè)用戶和客戶主要溝通的工具。根據(jù)一家美國公司對(duì)市場的調(diào)查中，在最近幾年，語音仍然是企業(yè)用戶和客戶互動(dòng)的首先方式。
以下部分圖片來自于互聯(lián)網(wǎng)
在呼叫中心或者語音使用比較高的行業(yè)中，服務(wù)行業(yè)是一個(gè)需求非常旺盛的行業(yè)，客服中心是非常關(guān)鍵的部門。為了保證其服務(wù)和其他業(yè)務(wù)那個(gè)在一種可控的環(huán)境下進(jìn)行，雙方的錄音是最好的憑證。另外，語音呼叫結(jié)合電話錄音也是服務(wù)行業(yè)的一個(gè)必然的趨勢，以下是美國行業(yè)調(diào)查數(shù)據(jù)：
資料來源：https://www.telemessage.com/voice-call-recording-latest-market-and-compliancetrends-infographic/
當(dāng)然，錄音也不僅僅局限于客服的一種需求，其他行業(yè)也存在巨大的市場。以下示例說明了各種環(huán)境下對(duì)錄音的需求：
但是，隨著呼叫中心或客服中心技術(shù)的不斷發(fā)展，很多呼叫中心和客服中心的技術(shù)也發(fā)生了巨大的變化，從很早的本地部署方式逐漸升級(jí)為基于云的部署方式，客服或坐席人員也出現(xiàn)了分布式的部署方式。因此，隨著呼叫中心或客服中心技術(shù)和管理方式的變化導(dǎo)致了錄音解決方案的變化。我們知道，傳統(tǒng)的PSTN的錄音或者IP錄音是通過高阻三通方式或鏡像錄音實(shí)現(xiàn)呼叫錄音，但是，這些部署很難滿足對(duì)現(xiàn)代云部署技術(shù)的支撐，它們也滿足不了非常細(xì)節(jié)的業(yè)務(wù)功能。因此，傳統(tǒng)的錄音設(shè)備或者本地錄音方式面臨著很大的挑戰(zhàn)。
隨著呼叫中心或客服系統(tǒng)朝云平臺(tái)的遷移，基于云平臺(tái)的錄音解決方案也逐漸形成了自己的市場。同時(shí)，錄音解決方案可以非常方便地和人工智能的接口實(shí)現(xiàn)無縫對(duì)接支持。因此，基于云的呼叫中心配合云錄音方案將更加普及。
在基于云部署的呼叫中心的使用場景中，絕大部分的呼叫中心使用了基于SIP協(xié)議的解決方案。目前，基于SIP協(xié)議的技術(shù)架構(gòu)中，基于SIP協(xié)議對(duì)媒體錄音的規(guī)范是SBC，軟交換，媒體服務(wù)器部署時(shí)需要支持的協(xié)議規(guī)范（SIPREC）。一些比較主流的SBC廠家，媒體服務(wù)器都已經(jīng)支持了SIPREC-基于SIP的媒體錄音協(xié)議。這看來也是一個(gè)市場發(fā)展的必然趨勢。為了更快了解這些相關(guān)的技術(shù)和規(guī)范，在本文章中，筆者在接下來的章節(jié)中會(huì)逐步介紹SIPREC相關(guān)的技術(shù)規(guī)范，它們包括：
RFC5341-基于SIP的媒體錄音使用場景規(guī)范：
Use Cases and Requirements for SIP-Based Media Recording （SIPREC）
RFC7245-SIP媒體錄音技術(shù)架構(gòu)：
An Architecture for Media Recording Using the Session Initiation Protocol
RFC 7865-SIP錄音時(shí)的metadata：
Session Initiation Protocol （SIP） Recording Metadata
RFC7866-SIP錄音的呼叫流程：
Session Initiation Protocol （SIP） Recording Call Flows
因?yàn)槠年P(guān)系，我們不可能在一篇文章中涵蓋所有的技術(shù)細(xì)節(jié)，除了簡略介紹以上規(guī)范以外，筆者還要結(jié)合目前主流的SBC應(yīng)用場景和其他的問題進(jìn)行多方面的討論來完善目前關(guān)于基于SIP媒體錄音解決方案的討論。
2、SIPREC背景知識(shí)
根據(jù)前面章節(jié)的介紹，因?yàn)槟承┥虡I(yè)環(huán)境的要求，系統(tǒng)可能需要對(duì)呼叫會(huì)話進(jìn)行錄音。SIPREC是基于SIP協(xié)議對(duì)媒體錄音的場景規(guī)范（RFC6341）。其全名為：
Use Cases and Requirements for SIP-Based Media Recording （SIPREC）
在整個(gè)SIPREC的規(guī)范中，包括了SRC和SRS兩個(gè)核心部分。它們之間的通信會(huì)話包括了錄音內(nèi)容本身和一些相關(guān)的metadata，通過錄音內(nèi)容和metadata的關(guān)聯(lián)，系統(tǒng)就可以實(shí)現(xiàn)對(duì)SIP呼叫的媒體錄音的完成流程處理。因?yàn)閷?duì)SIP呼叫的錄音，涉及了很多的業(yè)務(wù)模式和其他相關(guān)的技術(shù)，因此，其規(guī)范也相對(duì)比較寬泛，不可能嚴(yán)格限定到非常細(xì)節(jié)的技術(shù)范疇。讀者一定要清楚，一些其他業(yè)務(wù)要求和技術(shù)要素不在此官方的說明范圍之內(nèi)。這些要素包括：
- 關(guān)于法律強(qiáng)制錄音的規(guī)定流程不在此規(guī)范討論范圍之內(nèi)
- 關(guān)于媒體注入，編碼轉(zhuǎn)換，安全問題不在本規(guī)范討論范圍之內(nèi)
- 通過網(wǎng)絡(luò)鏡像方式錄音Passive 錄音方式不在本規(guī)范討論范圍之內(nèi)
此規(guī)范僅討論active 錄音方式，和如何通過SRC對(duì)SRS發(fā)送媒體流的處理場景。以下是一個(gè)關(guān)于SIPREC和SIP呼叫流程的圖例說明：
在以上的圖例中，用戶端可以是SIP終端， 呼叫中心，或者IPPBX，通過一個(gè)B2BUA實(shí)現(xiàn)對(duì)外網(wǎng)呼叫。這里的SRC是SBC，SRC客戶端再發(fā)送通信會(huì)話包括SIPREC metadata和RTP到第三方的SIPREC服務(wù)器端。在呼叫環(huán)境中，涉及了各種環(huán)境場景和控制流程，具體細(xì)節(jié)和各種錄音場景我們?cè)诘谒恼鹿?jié)中做具體說明。
劇透時(shí)間：可能是東半球網(wǎng)關(guān)銷售量最大的廠家即將震撼發(fā)布一系列融合通信產(chǎn)品，完成融合通信產(chǎn)品生態(tài)鏈部局。
www.dinstar.cn
3、技術(shù)架構(gòu)討論-RFC7245
在上面的章節(jié)中，我們介紹了關(guān)于SIPREC的一些背景知識(shí)和規(guī)范的局限性。SIPREC的工作方式是基于SIP媒體會(huì)話錄音的技術(shù)架構(gòu)來實(shí)現(xiàn)的。因此，我們有必要針對(duì)媒體錄音技術(shù)架構(gòu)進(jìn)行討論包括。關(guān)于SIP媒體會(huì)話錄音的技術(shù)架構(gòu)，RFC7245對(duì)此有明確的規(guī)范說明。在RFC7245中，官方協(xié)議中首先定義了多個(gè)關(guān)鍵詞，然后說明了技術(shù)架構(gòu)中具體的結(jié)構(gòu)，創(chuàng)建錄音會(huì)話和記錄metadata數(shù)據(jù)。
在RFC7245中所規(guī)定的幾個(gè)關(guān)鍵詞包括：
- 支持錄音意識(shí)用戶代理- Recording-aware User Agent （UA）：此UA可以意識(shí)到其拓展已經(jīng)關(guān)聯(lián)到了通信會(huì)話（CS）。其拓展參數(shù)可以通知其UA錄音會(huì)話已啟動(dòng)或表示其狀態(tài)，可以啟動(dòng)，暫停和完全停止等消息。
- 無錄音意識(shí)用戶代理-Recording-unaware User Agent （UA）：此UA意識(shí)不到其拓展已經(jīng)關(guān)聯(lián)到了通信會(huì)話（CS）。無錄音意識(shí)代理將通過其他手段通知其UA錄音會(huì)話已啟動(dòng)或表示其狀態(tài)，可以啟動(dòng)，暫停和完全停止等消息。
- Recording Metadata：描述SRS服務(wù)器端需要的相關(guān)錄音身份確認(rèn)數(shù)據(jù)，包括通信會(huì)話和dialog狀態(tài)信息等。一般情況下，這些metadata會(huì)和復(fù)制媒體錄音一起發(fā)送到SRS服務(wù)器端。
- Replicated Media：由SRC客戶端創(chuàng)建的媒體流復(fù)制數(shù)據(jù)流，發(fā)送到SRS服務(wù)器端。它可能包括語音和視頻數(shù)據(jù)。
其他幾個(gè)概念在下面的章節(jié)中會(huì)加以說明，包括：Session Recording Server，Session Recording Client，Communication Session （CS）和Recording Session （RS）。
對(duì)于介于SRS和SRC之間的錄音會(huì)話來說，它仍然借助了SIP dialogs和SDP的正常處理流程來進(jìn)行處理。但是，它又對(duì)SIP拓展了其他的頭域值（例如，headers，tags等）來滿足媒體錄音的需求。在此規(guī)范中規(guī)定，復(fù)制的媒體數(shù)據(jù)需要通過實(shí)時(shí)方式發(fā)送到SRS服務(wù)器端，不能使用SRC緩存方式發(fā)送。
從媒體錄音的技術(shù)架構(gòu)來說，SRC是一個(gè)邏輯構(gòu)件，它可以介于多個(gè)應(yīng)用部署的環(huán)境中。它本身必須是一個(gè)B2BUA的結(jié)構(gòu)，這樣SRC才能對(duì)RTP媒體，對(duì)SIP信令進(jìn)行控制，最重要的是可以對(duì)會(huì)話進(jìn)行管理。關(guān)于B2BUA的概念，讀者可以查閱筆者的歷史文檔來進(jìn)一步學(xué)習(xí)，這里不再做過多解釋。另外，特別提醒讀者，SIP proxy不能作為SRC來工作，因?yàn)閜roxy不能touch到媒體語音流。這就是為什么opensips如果需要支持SIPREC時(shí)，opensips必須加載B2BUA模塊，作為一個(gè)B2BUA來使用。
當(dāng)然，SIP endpoints也可以作為一個(gè)SRC，這種情況下，終端會(huì)對(duì)SRS發(fā)送復(fù)制的媒體。如果終端需要對(duì)SRS服務(wù)器端發(fā)送錄音時(shí)，它可以發(fā)送一個(gè)INVITE請(qǐng)求，創(chuàng)建會(huì)話后發(fā)送，SRC對(duì)SRS發(fā)送媒體錄音。同樣，如果SRS需要啟動(dòng)錄音時(shí)，它可以對(duì)SRC終端發(fā)送INVITE會(huì)話，然后開始錄音。
錄音會(huì)話可以由SRS或者SRC創(chuàng)建。SRC創(chuàng)建的錄音會(huì)話的目的是對(duì)SRS發(fā)送媒體錄音流數(shù)據(jù)。如果有SRC創(chuàng)建錄音會(huì)話時(shí)，它主要執(zhí)行以下幾個(gè)步驟：
- SRC查詢定位SRS的URL地址，按照解析方式來解析SRS地址。
- 發(fā)送INVITE請(qǐng)求，創(chuàng)建一個(gè)dialog，然后發(fā)送到SRS。
- 在INVITE請(qǐng)求中包括一個(gè)錄音指示，表示會(huì)話已經(jīng)創(chuàng)建，希望發(fā)送媒體錄音。
- 如果馬上要發(fā)送復(fù)制媒體時(shí)，在SDP中包含一個(gè)“a=sendonly”，表示馬上發(fā)送媒體錄音。如果還沒有準(zhǔn)備好發(fā)送媒體的話，包含一個(gè)“a=inactive”。
- 復(fù)制的媒體流被錄音然后發(fā)送到SRS服務(wù)器端。
同樣，SRS也可以對(duì)SRC發(fā)送請(qǐng)求來啟動(dòng)一個(gè)錄音會(huì)話，它需要執(zhí)行以下幾個(gè)流程：
- SRS查詢SRC URL地址，通過地址解析后獲取SRC地址。
- SRS對(duì)SRC發(fā)送INVITE請(qǐng)求。
- 在SRS發(fā)送的INVITE中包括一個(gè)媒體錄音指示，表示要?jiǎng)?chuàng)建一個(gè)錄音會(huì)話來進(jìn)行媒體錄音。
- 確認(rèn)會(huì)話數(shù)據(jù)內(nèi)容。在實(shí)際環(huán)境中，確認(rèn)消息取決于SRC的策略設(shè)置。
- 如果馬上要發(fā)送復(fù)制媒體時(shí)，在SDP中包含一個(gè)“a=sendonly”，表示馬上發(fā)送媒體錄音。如果還沒有準(zhǔn)備好發(fā)送媒體的話，包含一個(gè)“a=inactive”。
如果SRS服務(wù)器端不知道哪個(gè)媒體會(huì)話需要錄音的話，SRS服務(wù)器端可以執(zhí)行一個(gè)協(xié)商機(jī)制，它可以先對(duì)SRC發(fā)送一個(gè)無實(shí)際意義的INVITE，然后SRC客戶端對(duì)其發(fā)送一個(gè)初始的offer。
在媒體錄音進(jìn)行過程中，SRS或者SRC任意一方可以暫停或者重新啟動(dòng)錄音。通過SDP中包含一個(gè)inactive來暫停錄音，或者通過SDP中包含“recvonly”或“sendonly”重新啟動(dòng)錄音。
通常情況下，在一個(gè)簡單的會(huì)話中，在SRC客戶端，RTP媒體流可能包含兩個(gè)媒體數(shù)據(jù)流。這些媒體流必須在發(fā)送到SRS服務(wù)器端之前進(jìn)行混音。如果沒有混音的媒體發(fā)送到SRS時(shí)，需要同時(shí)分開發(fā)送兩個(gè)媒體流的metadata。
在實(shí)際部署環(huán)境中，雙方媒體可能需要進(jìn)行媒體轉(zhuǎn)換處理，B2BUA可以執(zhí)行此功能。如果SRC端不能執(zhí)行媒體轉(zhuǎn)換處理的話，它需要對(duì)SRS發(fā)送不同的媒體格式，SRS服務(wù)器端需要支持多種媒體格式。
4、SIPREC使用場景討論
- 在SIPREC的規(guī)范中，它說明了幾個(gè)基于SIP的錄音使用場景。這些場景都可以支持SIPREC規(guī)范RFC6341。在此規(guī)范中，一些必要的定義需要再次說明一下：
- SRS-全稱是Session Recording Server，它是一個(gè)具體的媒體服務(wù)器或媒體采集服務(wù)器，是一個(gè)用戶代理，同時(shí)匯總各種媒體流的metadata。SRS典型的部署方式是一個(gè)多口可拓展的服務(wù)器類型。
- SRC-全稱是Session Recording Client，它是一個(gè)SIP用戶代理，負(fù)責(zé)對(duì)服務(wù)器端發(fā)送媒體流數(shù)據(jù)，它本身是一個(gè)邏輯功能單元，可以支持多個(gè)物理設(shè)備，在實(shí)際應(yīng)用環(huán)境中，SRC可以是SIP終端話機(jī)，媒體網(wǎng)關(guān)或者SBC。SRC同時(shí)對(duì)SRS服務(wù)器發(fā)送metadata。
- Communication Session （CS），通信會(huì)話創(chuàng)建于一個(gè)SIP或者多個(gè)用戶代理之間的會(huì)話，是一個(gè)正在被錄音的會(huì)話對(duì)象。
- Recording Session （RS）：為通信會(huì)話（CS）錄音目的創(chuàng)建的介于SRS和SRC之間的SIP會(huì)話。
關(guān)于SRS，SRC和CS直接的關(guān)系，讀者可查閱此示例：
在RFC6341中說明了12個(gè)應(yīng)用場景，每一種場景都包含了具體的描述。
- 全時(shí)錄音：對(duì)RS對(duì)一個(gè)CS（參考以下示例），系統(tǒng)對(duì)所有呼叫進(jìn)行錄音，典型的應(yīng)用場景包括呼叫中心，企業(yè)客服和金融呼叫流程等。
- 選擇性錄音：當(dāng)CS錄音創(chuàng)建后，啟動(dòng)RS錄音。如果CS沒有啟動(dòng)，系統(tǒng)不會(huì)錄音。
- 停止啟動(dòng)錄音：當(dāng)呼叫在CS期間時(shí)，可以啟動(dòng)停止RS錄音。系統(tǒng)可以通過用戶界面按鈕或者其他熱鍵啟動(dòng)錄音。這里注意，在CS期間，可能會(huì)生成一個(gè)或者多個(gè)RS錄音。
- 持續(xù)錄音：一個(gè)RS可以捕捉一個(gè)或多個(gè)CS錄音。此錄音方式通常應(yīng)用于某些場景中，例如前臺(tái)總機(jī)，轉(zhuǎn)每個(gè)特定的分機(jī)號(hào)碼或者呼叫。整個(gè)RS需要對(duì)多個(gè)環(huán)節(jié)中的終端錄音，包括了轉(zhuǎn)接時(shí)的靜音等。最后，這些錄音的metadata可以關(guān)聯(lián)在一起，錄音文件可以合并。這里可能涉及了編碼協(xié)商的流程。
6.IVR入口錄音：對(duì)系統(tǒng)IVR進(jìn)行錄音，包括其metadata等。
7.企業(yè)移動(dòng)端錄音：系統(tǒng)對(duì)企業(yè)辦公人員進(jìn)行錄音。這些員工可能經(jīng)常不在辦公室環(huán)境中上班，他們經(jīng)常使用移動(dòng)端和企業(yè)呼叫中心或者通信系統(tǒng)進(jìn)行溝通，這些員工的呼叫需要被錄音。比較常見的場景包括銷售人員，保險(xiǎn)銷售等。
8.分布式錄音或集中式錄音：一些企業(yè)，銀行，連鎖機(jī)構(gòu)等辦公系統(tǒng)的電話呼叫需要通過部署在不同地區(qū)或者集中管理的電話系統(tǒng)進(jìn)行呼叫。系統(tǒng)需要對(duì)呼叫進(jìn)行錄音，并且對(duì)其每個(gè)RS的metadata進(jìn)行存儲(chǔ)。這樣方便管理每一個(gè)呼叫和其相關(guān)人分機(jī)。
9.復(fù)雜呼叫流程：復(fù)雜呼叫流程是一個(gè)比較抽象的說法，沒有特別具體的定義，此場景比較靈活，寬泛。簡單來說，一個(gè)呼叫進(jìn)入到系統(tǒng)用戶，客戶電話可能首先被前臺(tái)人員接聽，然后轉(zhuǎn)到具體的坐席人員。如果坐席人員不能回答客戶問題的話，坐席人員可能需要再呼叫坐席主管，主管來接聽客戶的電話。坐席人員在此呼叫流程中需要首先執(zhí)行呼叫停靠，然后再呼叫他/她的主管，主管接聽客戶電話以后，坐席掛機(jī)。整個(gè)流程稱之為復(fù)雜呼叫流程，所有的呼叫都需要錄音，并且SRC需要對(duì)SRS發(fā)送所有的metadata數(shù)據(jù)。
10.高可靠性和持續(xù)錄音：根據(jù)用戶的需求，此應(yīng)用場景需要SRS服務(wù)器端一直保持工作狀態(tài)，失效還原功能。所有創(chuàng)建的呼叫都能錄音。此場景要求SRS服務(wù)器端必須持續(xù)工作，無呼叫錄音服務(wù)丟失。
11.對(duì)通道和多會(huì)話錄音：一些應(yīng)用場景要求媒體錄音是一個(gè)或者多個(gè)文件，可以實(shí)現(xiàn)同步存儲(chǔ)或者回放等功能。語音識(shí)別引擎可以對(duì)其明顯特定的媒體執(zhí)行ASR/TTS處理。一些多渠道融合的呼叫中心或者IPPBX環(huán)境中可能需要對(duì)視頻，IM，其他數(shù)據(jù)文件進(jìn)行存儲(chǔ)。為了節(jié)省存儲(chǔ)空間，一些應(yīng)用場景中可能需要僅多某些終端在某個(gè)特定時(shí)間段進(jìn)行錄音。
12.實(shí)時(shí)媒體處理：此場景在當(dāng)前的呼叫中心或客服系統(tǒng)中實(shí)時(shí)質(zhì)檢環(huán)境中使用比較廣泛。SRS服務(wù)器端必須有能力支持語音識(shí)別引擎工具，這些偵查工具可以對(duì)某一段媒體進(jìn)行ASR和以及相關(guān)語義識(shí)別，情緒分析等工具處理，如果發(fā)現(xiàn)其錄音中帶有比較敏感的詞，或者客服人員態(tài)度語氣有問題，應(yīng)用系統(tǒng)的主管人員可以及時(shí)處理。通過SIPREC的metadata可以非常方便快捷地查詢到客服人員的電話座席。以下示例是寧衛(wèi)開發(fā)的基于ASR的實(shí)時(shí)質(zhì)系統(tǒng)。系統(tǒng)用戶可以根據(jù)自己的業(yè)務(wù)需求添加一些敏感詞。如果客服人員和客戶之間的溝通有危險(xiǎn)詞匯或者不禮貌用語，系統(tǒng)直接提示其狀態(tài)（紅色標(biāo)識(shí)）。此對(duì)話過程可通過短信，郵箱或者其他第三方接口實(shí)時(shí)推送給坐席主管現(xiàn)在的狀態(tài)告警。
當(dāng)然，實(shí)現(xiàn)以上基于SIPREC錄音解決方案的話，此規(guī)范有31個(gè)要求。筆者這里不立場31個(gè)具體的要求，讀者可以查閱RFC6341。
另外，除了31個(gè)要求以外，此規(guī)范討論了關(guān)于錄音存儲(chǔ)和metadata的安全問題，讀者也可以查閱RFC6341來進(jìn)一步學(xué)習(xí)。
5、SIP錄音時(shí)的metadata
SIP錄音時(shí)的metadata涉及到了錄音會(huì)話的相關(guān)參數(shù)的綁定。這些數(shù)據(jù)通過SRC發(fā)送到SRS服務(wù)器端。RFC7865主要針對(duì)通信會(huì)話的錄音文件進(jìn)行了規(guī)范，其核心包括SRS服務(wù)器端的metadata數(shù)據(jù)模式和數(shù)據(jù)錄音格式規(guī)范描述。在RFC7865中涵蓋了幾個(gè)主要的定義，它們分別是：
- Metedata model：以UML為基礎(chǔ)的抽象metadata表達(dá)方式
- Metedada class：模式中的每一塊為一個(gè)class
- Attributes：class的屬性
- Linkages：模式中每個(gè)class之間的相關(guān)性，每個(gè)linkage表示class之間的一個(gè)邏輯相關(guān)性
以下示例表示了各種class自己的相互關(guān)系和其相關(guān)性，讀者可以查閱RFC7865進(jìn)一步了解這個(gè)數(shù)據(jù)模式。另外，讀者也可以學(xué)習(xí)UML或者軟件工程相關(guān)的文章了解UML背景知識(shí)。
在metadata的數(shù)據(jù)格式方面，涉及了從SRC到SRS的發(fā)送格式。通過XML的格式來表示metadata的內(nèi)容。
錄音文件的metadata有分為不同的class。每個(gè)class有著自己不同的屬性參數(shù)設(shè)置和相關(guān)性設(shè)置。這些class包括：
- Recording session：錄音會(huì)話類別，在XML中使用“recording”，它依賴于SIP和SDP所關(guān)聯(lián)的屬性。
- Commnucation session group: 關(guān)聯(lián)一組通信會(huì)話，例如坐席通過幾次電話轉(zhuǎn)接停靠以后的一系列相關(guān)呼叫。它在XML中使用“group”表示。
- Commnucation session：通信會(huì)話表示其通信屬性和metadata，其屬性包括：session_id，sipSession_ID, group-ref,start-time,stop-time。
- CS-RS Association ：表示通信會(huì)話和錄音會(huì)話的關(guān)聯(lián)性，屬性包括關(guān)聯(lián)時(shí)間，斷開時(shí)間和session_id。
- Participant：錄音參與者進(jìn)入到錄音會(huì)話的雙方，包括終端描述，Participant_id等。
- Participant-CS Association：參與者和通信會(huì)話的關(guān)聯(lián)性綁定關(guān)系。關(guān)聯(lián)性描述參與者和通信會(huì)話關(guān)聯(lián)時(shí)間，session_id，斷開時(shí)間等屬性。
- Media Stream：描述SRC發(fā)送到SRS服務(wù)器端的媒體屬性，包括label，stream_id和session_id等屬性設(shè)置。
- Participant-Stream Association：描述參與者和媒體之間的綁定關(guān)系和時(shí)間段，參與者可能是發(fā)送方，接收方或者兩者角色都支持。
- Syntax of XML Elements for Date and Time：定義XML文件中日期和時(shí)間段規(guī)范，包括關(guān)聯(lián)時(shí)間，斷開時(shí)間，啟動(dòng)錄音時(shí)間，停止錄音時(shí)間等相關(guān)的時(shí)間規(guī)范。此時(shí)間標(biāo)準(zhǔn)需要遵從RFC3339的格式規(guī)范。時(shí)間戳必須使用一個(gè)大寫的T或者Z。
- Format of Unique ID：描述了生成UUID的步驟和解析規(guī)范。UUID解析必須遵從RFC4648。
- Metadata Version Indicator：version指示幫助SRC和SRS確認(rèn)使用的XML文件版本是否一致。目前規(guī)定的是雙方都使用版本1。如果版本不一致的話，可能導(dǎo)致傳輸失敗，目前的規(guī)范中沒有支持任何的協(xié)商機(jī)制。
因?yàn)楸旧韒etadata的數(shù)據(jù)結(jié)構(gòu)比較復(fù)雜，另外，如果SRS處理大量數(shù)據(jù)的時(shí)候需要消耗很多的計(jì)算資源和帶寬。因此，SRS可以明確通知SRC發(fā)送一個(gè)關(guān)于錄音的metadata的概要或者部分相關(guān)內(nèi)容，而不需要發(fā)送一個(gè)完整的XML文件。具體的語法格式如下：
SRS internal error
完整的metadata格式包含了大量的XML數(shù)據(jù)，文件相對(duì)比較大，這里不再介紹，讀者可以查閱RFC7865-8的完整SIP 錄音metadata 示例。
6、SIP會(huì)話錄音協(xié)議
前面的討論中，筆者已經(jīng)介紹了錄音技術(shù)架構(gòu)，使用場景和metadata。在這一章節(jié)，我們重點(diǎn)介紹一下會(huì)話錄音協(xié)議-Session Recording Protocol。此協(xié)議主要規(guī)定了SR之間的實(shí)時(shí)媒體發(fā)送和metadata發(fā)生的邏輯流程，包括SIP使用， SDP使用和RTP的處理規(guī)范。再次說明，此協(xié)議僅支持active 錄音模式，不支持passive 錄音模式（鏡像錄音）。在此協(xié)議中，主要規(guī)范了幾個(gè)方面的處理流程：
基本操作流程規(guī)定，SIP處理流程定義，SDP處理流程定義。RTP處理流程定義，metadata處理，持續(xù)錄音處理和安全處理機(jī)制處理。
基本操作流程規(guī)定中介紹了關(guān)于傳輸媒體流，傳輸metadata，接收錄音指示和提供錄音優(yōu)先設(shè)置。在傳輸媒體流的模式討論中，規(guī)范了兩種傳輸方式。一種傳輸方式是SRC以B2BUA的方式傳輸，一種是以SRC以endpoint的方式來傳輸。SRC以endpoint的模式傳輸媒體：
以下是SRC以B2BUA的模式傳輸，電話會(huì)議就是此工作方式的表現(xiàn)形式。
除了傳輸媒體流錄音以外，metadata也需要實(shí)時(shí)隨著媒體的發(fā)送傳輸?shù)絊RS服務(wù)器端。SRC負(fù)責(zé)傳輸metadata，SRC也可以通過起始的CS的INVITE請(qǐng)求提供初始媒體流錄音的metadata數(shù)據(jù)消息，后續(xù)的metadata可以通過媒體事件的UPDATE（查閱rfc3311）來傳遞，也可以通過SRC發(fā)送到re-INVITE發(fā)送。傳輸metadata通常是逐步遞增的，消息內(nèi)容可能會(huì)不斷增加，文件也可能非常大。因此，SRC發(fā)可以根據(jù)自己的策略重新發(fā)送metadata。meatadata通過INVITE或者UPDATE的消息體來傳輸。一些媒體流的屬性需要通過RS的SDP傳輸。在SRC和SRS傳輸過程中，可能出現(xiàn)其他的故障，丟失了metedata。SRS可以通過一個(gè)失敗消息對(duì)SRC要求重新傳輸metadata，SRS和SRC可以保持?jǐn)?shù)據(jù)的同步。以下是一個(gè)通過SIP UPDATE重新傳輸?shù)牧鞒虒?shí)例：
在CS傳輸過程中，SRC負(fù)責(zé)對(duì)所有的參與者提供錄音指示消息內(nèi)容。一些支持錄音狀態(tài)意識(shí)到UA會(huì)收到一個(gè)SDP帶“a=record”消息，表示SRC開始發(fā)送錄音，同樣UA會(huì)在SDP中設(shè)定一個(gè)“a=recordpref”表示錄音的優(yōu)先偏好設(shè)置。如果UA暫時(shí)因?yàn)楦鞣N原因不能錄音，則可忽略這個(gè)優(yōu)先偏好設(shè)置。以下示例介紹了一個(gè)UA A作為SRC呼叫 終端B的流程，終端A呼叫并且開始錄音，UA B則看到對(duì)方錄音，UA B回復(fù)了一個(gè)off狀態(tài)，不想對(duì)呼叫進(jìn)行錄音。最后，UA A重新發(fā)送消息，停止呼叫錄音。
錄音會(huì)話中同樣涉及了SIP處理，它是一個(gè)SIP 會(huì)話的拓展，很多的消息會(huì)包含在SRS和SRC中。當(dāng)SRC或者SRS收到一個(gè)SIP會(huì)話時(shí)，它不是錄音會(huì)話的話，處理流程完全取決于SRC或者SRS自己。SRC通過SIP INVITE請(qǐng)求對(duì)SRS發(fā)起一個(gè)錄音會(huì)話，無論是SRS還是SRC都是通過SIP的To或From頭來定義。SRC必須在Contact URL的功能標(biāo)簽添加一個(gè)“+sip.src”來表示其拓展。在通過路由代理時(shí)，呼叫方可以添加一個(gè)標(biāo)簽“siprec”表示錄音會(huì)話需要路由到SRC或者SRS服務(wù)器端。SRC收到一個(gè)新的INVITE呼叫時(shí)，它必須通過INVITE中的兩個(gè)功能標(biāo)簽才能確認(rèn)是一個(gè)錄音會(huì)話呼叫，一個(gè)是“+sip.srs”和“siprec”。同樣的原則，當(dāng)SRS服務(wù)器端收到一個(gè)新的INVITE以后，它必須確認(rèn)是否包含兩個(gè)標(biāo)簽“+sip.src”和“siprec”才能確認(rèn)是一個(gè)SRC發(fā)送到錄音請(qǐng)求。有意識(shí)錄音UA（recording-aware UA）可以通過標(biāo)簽字段的形式支持是否錄音，重新啟動(dòng)錄音或者暫停錄音。一些網(wǎng)關(guān)或者終端通過界面來實(shí)現(xiàn)對(duì)DTMF控制也是一種錄音方式。
除了對(duì)會(huì)話的控制以外，媒體錄音也需要metadata傳輸?shù)葯C(jī)制，因此需要涉及到SDP的控制處理策略。在SDP處理模式上，SRC/SRS都遵守SDP offer/answer模式，具體規(guī)范查閱（RFC3264），筆者也曾經(jīng)做過介紹，讀者可對(duì)照學(xué)習(xí)。在SRC和SRS媒體發(fā)送過程中，SRC客戶端本身不希望從SRS服務(wù)器端收到媒體流數(shù)據(jù)，它僅是一個(gè)發(fā)送端，因此對(duì)SRC在SDP的設(shè)置中a字段設(shè)置為“a=sendonly”。SRC對(duì)每個(gè)發(fā)送到SRS服務(wù)器端的媒體錄音參與者必須都提供一個(gè)標(biāo)識(shí)“a=label”，以此來確認(rèn)每個(gè)媒體流的metadata。具體標(biāo)識(shí)的規(guī)范讀者查閱RFC4574。以下示例是一個(gè)標(biāo)識(shí)的示例，包括了具體的內(nèi)容介紹，這里的 是可選的。
媒體錄音也需要處理，因?yàn)楦鞣N原因，SRC可能增加或者刪除一些錄音會(huì)話。刪除增加會(huì)話需要根據(jù)RFC3264的規(guī)范來處理。RS暫停會(huì)話需要在SDP offer中增加一個(gè)a字段“a=inactive”。
在通信會(huì)話中，目前的機(jī)制對(duì)通信會(huì)話錄音是播放一個(gè)語音提示音或者播放一個(gè)廣播，提醒需要UA需要錄音。在SDP中增加了一個(gè)“record”屬性參數(shù)。通過SDP的a字段“a=record”來處理各種環(huán)境的變化設(shè)置，其具體的語法如下：
當(dāng)SRC收到一個(gè)錄音優(yōu)先級(jí)/偏好時(shí)，SRC通過設(shè)定a字段的屬性來控制是否錄音“a=record”，off或者on。
前面我們討論的是SRC的SDP控制，在SRS端的處理流程其實(shí)也具有相同的處理流程和邏輯，可能有一些正好是一個(gè)相反的設(shè)置機(jī)制。SRS通常情況下只是從SRC端接收RTP流，因此其SDP的a字段設(shè)置為“a=recvonly”。示例如下：
在SRS的SDP處理中，對(duì)有錄音意識(shí)UA，錄音指示和優(yōu)先級(jí)/偏好設(shè)置和SRC基本類似，讀者可參考SRC配置說明，這里不再做過多介紹。
RTP處理也是錄音會(huì)話協(xié)議中非常重要的一個(gè)部分。其規(guī)范推薦了RTP/RTCP在SIPREC中的使用機(jī)制，保證SRS，SRC和有錄音意識(shí)終端那個(gè)通過這些推薦的處理機(jī)制來正常工作。在RTP的處理機(jī)制中，推薦了RTCP在SIPREC的兩種功能（數(shù)據(jù)分發(fā)反饋處理機(jī)制，包括持續(xù)的傳輸層身份確認(rèn)（SSRC）），RTP屬性支持能力，SSRC，CSRC，SDES，Keepalive等機(jī)制處理方式。這些處理方式保證了語音傳輸，加密，穩(wěn)定性處理，活動(dòng)偵測，帶寬優(yōu)化，異步傳輸?shù)忍幚頇C(jī)制，用戶在實(shí)際本身時(shí)可靈活調(diào)整其參數(shù)來達(dá)到最佳的RTP處理解決方案。
SRC可以扮演多種角色，它可能是一個(gè)UA也可能是一個(gè)B2BUA代理。因此，在RTP的處理上就會(huì)導(dǎo)致不同的處理方式，也可以靈活運(yùn)用在不同的錄音場景中。SRC可以作為一個(gè)RTP流的轉(zhuǎn)移功能模塊，實(shí)現(xiàn)直接轉(zhuǎn)發(fā)RTP，或者可以作為一個(gè)RTP媒體的編碼轉(zhuǎn)換模塊，它可以針對(duì)不同的媒體格式進(jìn)行轉(zhuǎn)碼處理。SRC也可以作為一個(gè)媒體混音單元，讀者可查閱RFC3550對(duì)混音單元的規(guī)范做進(jìn)一步學(xué)習(xí)。
SRC也可以作為一個(gè)RTP的endpoint，這些我們?cè)谇懊孀鲞^介紹，這里不再討論。
在錄音會(huì)話中，metadata屬性參數(shù)包含在了SDP描述中，其他數(shù)據(jù)包含在了application/rs-metadata。"recording-session"值包含了SRS需要處理的metadata。在SRC的示例如下：
SRS發(fā)送到UPDATE消息如下：
在錄音會(huì)話時(shí)，規(guī)范做對(duì)持續(xù)錄音的場景做了一些規(guī)范推薦。在持續(xù)錄音時(shí)，關(guān)于SRC和SRS的處理機(jī)制可以按照前面的流程處理。一些特殊情況，可能需要用戶針對(duì)特殊環(huán)境做進(jìn)一步處理，例如NAT環(huán)境中端口活動(dòng)檢測，如果是支持ICE的終端可能可以解決這個(gè)問題，如果是不支持ICE的終端，用戶需要按照RFC6263來處理SRC和SRS的端口綁定。
在錄音會(huì)話環(huán)境中，規(guī)范推薦了一些相關(guān)的安全問題的討論，比如，SRC/SRS必須都支持加密，必須考慮RTP加密，metadata的安全處理，用戶簽權(quán)認(rèn)證處理和存儲(chǔ)空間回放文件的處理。這些機(jī)制都和其他的安全機(jī)制是一致的。用戶可以查閱其他協(xié)議的安全處理機(jī)制來執(zhí)行。
7、SBC對(duì)SIPREC的支持
在前面的章節(jié)中，筆者介紹了SIPREC的使用背景，錄音協(xié)議，錄音流程，技術(shù)架構(gòu)和metadata等比較底層的技術(shù)概念。在實(shí)際應(yīng)用場景中，SBC對(duì)SIPREC支持是非常典型的應(yīng)用案例。目前，國外一些主流的SBC廠家產(chǎn)品都已經(jīng)支持了SIPREC（包括FreeSBC即將發(fā)布SIPREC高級(jí)功能），這樣就為SIP呼叫媒體錄音部署提供了可靠的技術(shù)環(huán)境。SBC支持SIPREC主要的應(yīng)用場景包括：
SBC企業(yè)本地部署支持SIPREC： 企業(yè)IPPBX或者呼叫中心和SBC/SRC連接，SRC通過SIPREC和SRS連接。錄音服務(wù)器可以通過終端以各種訪問形式進(jìn)行訪問，運(yùn)營商和SBC進(jìn)行對(duì)接，然后呼叫到用戶終端。
多租戶企業(yè)IPPBX錄音解決方案： 托管型的IPPBX或呼叫中心可以通過遠(yuǎn)端終端呼叫SBC/SRC，然后通過SBC呼叫托管中心的PBX，IPPBX呼叫語音商線路出局。SRC同時(shí)對(duì)SRS發(fā)送RTP媒體流和metadata數(shù)據(jù)。
高可靠性SIPREC錄音解決方案：SIPREC同樣規(guī)范了高可靠性的處理方式，SRS必須實(shí)現(xiàn)媒體流存儲(chǔ)無丟失機(jī)制。所以，SRS可以通過主從處理的方式同步媒體流和metadata數(shù)據(jù)。
同樣，SRS的負(fù)載也是非常重要的技術(shù)要素。一些SBC做了均衡負(fù)載的處理，例如奧科SBC支持了類似的功能：
以上應(yīng)用場景是比較典型的部署方式，SIPREC規(guī)范相對(duì)比較新，廠家仍然需要不斷更新支持一些SIPREC規(guī)范的高級(jí)功能。
8、其他問題討論
前面我們討論了關(guān)于SIPREC錄音的官方協(xié)議和應(yīng)用場景。SIPREC相當(dāng)于鏡像錄音來說，其部署方式更符合目前SIP大型應(yīng)用環(huán)境，云平臺(tái)的處理方式。但是，因?yàn)镾IPREC是基于其他規(guī)范基礎(chǔ)發(fā)展而來的，因此其他規(guī)范的使用限制了一些SRC/SRS工作環(huán)境。另外，一些終端產(chǎn)品還沒有支持SIPREC，只有大部分SBC產(chǎn)品支持了SIPREC，SRS服務(wù)器端的功能仍然處于發(fā)展階段，一些商業(yè)產(chǎn)品支持了基本的SIPREC功能，一些高級(jí)功能仍然受到了限制。大家比較關(guān)心的問題包括：
- SRC客戶端發(fā)送到metadata文件大小影響傳輸結(jié)果和SRS的負(fù)載，SRC可能需要支持更多的傳輸策略來解決類似的問題。
- SRC是否支持混音，如果SBC測來處理這些需求的話，會(huì)導(dǎo)致SBC負(fù)載非常高，直接影響SBC的性能。
- SRS服務(wù)器端的高可靠性設(shè)置問題也是需要用戶面對(duì)的問題�？赡芤恍⿵S家的SBC很好解決了此問題，但是需要真正實(shí)際驗(yàn)證。
- SRC是否很好支持了metadata的拓展支持決定了和SIP會(huì)話處理。如果很好支持很多拓展字段，可能會(huì)幫助SRS服務(wù)器端更加準(zhǔn)確管理metedata和通信會(huì)話處理。另外，SIP會(huì)話的處理也需要終端和其他設(shè)備能夠很好配合，保證其具有良好的兼容性，從而保證metadata的準(zhǔn)確性。
- 隨著融合通信的發(fā)展，用戶溝通增加了更多媒體支持，包括IM消息，共享文件和視頻格式。如何更好處理這些文件和其metadata也是一個(gè)非常大的挑戰(zhàn)。
9、總結(jié)
在本文章中，筆者首先介紹了SIPREC的規(guī)范和其相關(guān)的細(xì)節(jié)�；赟IP協(xié)議的媒體錄音應(yīng)用已經(jīng)非常廣泛，從銀行到企業(yè)客服，保險(xiǎn)業(yè)務(wù)推廣，法律機(jī)構(gòu)和政府要求都需要電話錄音。這些錄音文件需要和其具體的通信會(huì)話相關(guān)人員進(jìn)行正確綁定才能符合真正的客戶要求。然后，筆者針對(duì)SIPREC和其他相關(guān)協(xié)議做了完整介紹，例如12個(gè)使用場景，錄音協(xié)議，metadata規(guī)范，呼叫流程規(guī)范。然后，筆者針對(duì)目前SRC使用最廣泛的SBC做了介紹，通過SBC的集成，企業(yè)客戶可以實(shí)現(xiàn)SIPREC錄音解決方案。最后，筆者討論了目前使用SIPREC可能面對(duì)的挑戰(zhàn)和一些相關(guān)問題，為讀者提供了相對(duì)比較完整的專業(yè)建議。當(dāng)然，隨著技術(shù)的不斷發(fā)展，SIPREC的功能會(huì)更加完善，云平臺(tái)的使用越來越多，SBC部署的廣大，支持的終端也可能越來越多，SIPREC的需求也會(huì)逐漸增加。
以上就是筆者針對(duì)基于SIP協(xié)議的媒體錄音規(guī)范和應(yīng)用方面的概述。這里沒有過度討論各種錄音方式的特點(diǎn)。這些討論通常根據(jù)用戶的需求來決定，所以筆者認(rèn)為沒有必要做過多討論。另外，關(guān)于SIPREC的場景討論也可能遺漏了其他方面的要素，望讀者諒解�？傊�，此文章已經(jīng)基本涵蓋了基于SIP協(xié)議做媒體錄音的大部分內(nèi)容和規(guī)范，也完整敘述了其相關(guān)規(guī)范所有的技術(shù)要點(diǎn)，對(duì)于讀者快速了解這些技術(shù)有著非常大的幫助。
參考資料：
https://tools.ietf.org/html/rfc6341
https://tools.ietf.org/html/rfc7245
https://www.miarec.com/
www.freepbx.org.cn
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-sip-recording.pdf
SIPlab@知識(shí)星球?qū)W習(xí)SIP語音相關(guān)技術(shù)
asterisk@知識(shí)星球免費(fèi)獲取關(guān)于Asterisk的完整知識(shí)資料
關(guān)注微信公眾號(hào)：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享
Asterisk freepbx，F(xiàn)reeSBC技術(shù)文檔： www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
Asterisk/FreePBX中國合作伙伴，官方qq技術(shù)分享群（3000人）：589995817
