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